https://bugs.eclipse.org/bugs/show_bug.cgi?id=340974
diff --git a/epf_prac_151/core.default.cat_def.base/disciplines/architecture_discipline.xmi b/epf_prac_151/core.default.cat_def.base/disciplines/architecture_discipline.xmi
index 945898b..bc9aaa6 100644
--- a/epf_prac_151/core.default.cat_def.base/disciplines/architecture_discipline.xmi
+++ b/epf_prac_151/core.default.cat_def.base/disciplines/architecture_discipline.xmi
@@ -1,15 +1,31 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-IDdeF_boiqzJJnjpXrdLFQ" name="architecture_discipline,_iGSHsFZ-EdyIUdvDLLUdeg" guid="-IDdeF_boiqzJJnjpXrdLFQ" changeDate="2008-02-09T01:24:59.000-0800" version="7.2.0">
- <mainDescription><p> The purpose of this discipline is to evolve a robust architecture for the
- system. </p>
-<p> The Architecture discipline is related to these other disciplines: </p>
-<ul>
- <li> The <a class="elementLink" href="./../../core.default.cat_def.base/disciplines/requirements_discipline_9520664.html" guid="_iGSHtVZ-EdyIUdvDLLUdeg">Requirements</a>&nbsp;discipline
- provides the architecturally significant requirements. </li>
- <li> The <a class="elementLink" href="./../../core.default.cat_def.base/disciplines/development_discipline_44C02445.html" guid="_iGSHsVZ-EdyIUdvDLLUdeg">Development</a>&nbsp;discipline
- designs and implements the architecture. </li>
- <li> The <a class="elementLink" href="./../../core.default.cat_def.base/disciplines/test_discipline_F7EB1A7A.html" guid="_iGSHtlZ-EdyIUdvDLLUdeg">Test</a>&nbsp;discipline
- verifies the stability and correctness of the architecture. </li>
- <li> The <a class="elementLink" href="./../../core.default.cat_def.base/disciplines/project_management_discipline_FEB42654.html" guid="_iGSHtFZ-EdyIUdvDLLUdeg">Project Management</a>&nbsp;discipline plans the project and each iteration. </li>
+ <mainDescription><p>
+ The purpose of this discipline is to evolve a robust architecture for the system.
+</p>
+<p>
+ The Architecture discipline is related to these other disciplines:
+</p>
+<ul>
+ <li>
+ The <a class="elementLink"
+ href="./../../core.default.cat_def.base/disciplines/requirements_discipline_9520664.html"
+ guid="_iGSHtVZ-EdyIUdvDLLUdeg">Requirements</a>&nbsp;discipline provides the architecturally significant
+ requirements.
+ </li>
+ <li>
+ The <a class="elementLink"
+ href="./../../core.default.cat_def.base/disciplines/development_discipline_44C02445.html"
+ guid="_iGSHsVZ-EdyIUdvDLLUdeg">Development</a>&nbsp;discipline designs and implements the architecture.
+ </li>
+ <li>
+ The <a class="elementLink" href="./../../core.default.cat_def.base/disciplines/test_discipline_F7EB1A7A.html"
+ guid="_iGSHtlZ-EdyIUdvDLLUdeg">Test</a>&nbsp;discipline verifies the stability and correctness of the architecture.
+ </li>
+ <li>
+ The <a class="elementLink"
+ href="./../../core.default.cat_def.base/disciplines/project_management_discipline_FEB42654.html"
+ guid="_iGSHtFZ-EdyIUdvDLLUdeg">Project Management</a>&nbsp;discipline plans the project and each iteration.
+ </li>
</ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.cat_def.base/disciplines/project_management_discipline.xmi b/epf_prac_151/core.default.cat_def.base/disciplines/project_management_discipline.xmi
index cb5dca3..0a12939 100644
--- a/epf_prac_151/core.default.cat_def.base/disciplines/project_management_discipline.xmi
+++ b/epf_prac_151/core.default.cat_def.base/disciplines/project_management_discipline.xmi
@@ -1,38 +1,40 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-JR-x8arulRODu1y2tP928w" name="project_management_discipline,_iGSHtFZ-EdyIUdvDLLUdeg" guid="-JR-x8arulRODu1y2tP928w" changeDate="2008-01-18T03:26:47.000-0800" version="7.2.0">
- <mainDescription><p>
- The purpose of this discipline is to: &nbsp;
-</p>
-<ul>
- <li>
- Encourage stakeholder&nbsp;consensus on prioritizing the sequence of work
- </li>
-
- <li> Stimulate team collaboration on creating long-term and short-term plans
- for the project. </li>
- <li>
- Focus the team on continually delivering tested software for stakeholder evaluation
- </li>
- <li>
- Help create an effective working environment to maximize team productivity
- </li>
-
- <li> Keep stakeholders and the team informed of project progress </li>
- <li>
- Provide a framework to manage project risk and continually adapt to change
- </li>
-</ul>
-<p> Project Management is an umbrella discipline that impacts, and is impacted
- by, all other disciplines. Project management activities add value to creating
- a high-performance work environment where: </p>
-<ul>
- <li>
- Stakeholders trust in the team's ability to successfully deliver value and understand the capabilities and
- tradeoffs of the technical platform
- </li>
- <li>
- Project team members understand stakeholder intentions and confirm that understanding by continually producing a
- working software product for evaluation<br />
- </li>
+ <mainDescription><p>
+ The purpose of this discipline is to: &nbsp;
+</p>
+<ul>
+ <li>
+ Encourage stakeholder&nbsp;consensus on prioritizing the sequence of work
+ </li>
+ <li>
+ Stimulate team collaboration on creating long-term and short-term plans for the project.
+ </li>
+ <li>
+ Focus the team on continually delivering tested software for stakeholder evaluation
+ </li>
+ <li>
+ Help create an effective working environment to maximize team productivity
+ </li>
+ <li>
+ Keep stakeholders and the team informed of project progress
+ </li>
+ <li>
+ Provide a framework to manage project risk and continually adapt to change
+ </li>
+</ul>
+<p>
+ Project Management is an umbrella discipline that impacts, and is impacted by, all other disciplines. Project
+ management activities add value to creating a high-performance work environment where:
+</p>
+<ul>
+ <li>
+ Stakeholders trust in the team's ability to successfully deliver value and understand the capabilities and
+ tradeoffs of the technical platform
+ </li>
+ <li>
+ Project team members understand stakeholder intentions and confirm that understanding by continually producing a
+ working software product for evaluation<br />
+ </li>
</ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.cat_def.base/disciplines/test_discipline.xmi b/epf_prac_151/core.default.cat_def.base/disciplines/test_discipline.xmi
index 2a6bee8..b819753 100644
--- a/epf_prac_151/core.default.cat_def.base/disciplines/test_discipline.xmi
+++ b/epf_prac_151/core.default.cat_def.base/disciplines/test_discipline.xmi
@@ -1,64 +1,64 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-yVQcZlwHTZIT9-i97PVUYQ" name="test_discipline,_iGSHtlZ-EdyIUdvDLLUdeg" guid="-yVQcZlwHTZIT9-i97PVUYQ" changeDate="2009-07-29T00:10:07.000-0700" version="7.2.0">
- <mainDescription><p>
- The purpose of this discipline is to:
- </p>
- <ul>
- <li>
- Provide early and frequent <em>feedback</em> about whether the system satisfies the requirements
- </li>
- <li>
- Objectively measure progress in small increments
- </li>
- <li>
- Identify issues with the solution, increasing the probability that the system will behave correctly
- </li>
- <li>
- Provide assurance that changes to the system do not introduce new defects
- </li>
- <li>
- Improve velocity by facilitating the discovery of issues with requirements, designs, and implementations as early
- as possible
- </li>
- </ul>
- <p>
- The Test discipline is iterative and incremental. It applies the strategy of "test early and test often" to retire
- risks as early as possible in the system's lifecycle.
- </p>
- <p>
- Testing occurs in each iteration of the lifecycle, beginning with the earliest builds of the system. In fact, it is
- common for one iteration to have many test cycles, depending on the frequency of new builds.
- </p>
- <p>
- Testing asks the question: "What does the solution have to <em>do</em> for us to consider a requirement implemented?"
- Tests elaborate on the requirements with specific conditions of satisfaction that the solution must meet.
- </p>
- <p>
- This discipline challenges the assumptions, risks, and uncertainty inherent in the development of highly technical
- artifacts and addresses those concerns by using concrete demonstration and impartial evaluation.
- </p>
- <p>
- The Test discipline relates to the other disciplines in the following ways:
- </p>
- <ul>
- <li>
- The <a class="elementLink"
- href="./../../core.default.cat_def.base/disciplines/requirements_discipline_9520664.html"
- guid="_iGSHtVZ-EdyIUdvDLLUdeg">Requirements</a> discipline identifies the <em>intent</em> of the system. Testing
- elaborates on the requirements with detailed tests that measure how the system supports the requirements.
- </li>
- <li>
- The <a class="elementLink"
- href="./../../core.default.cat_def.base/disciplines/development_discipline_44C02445.html"
- guid="_iGSHsVZ-EdyIUdvDLLUdeg">Development</a> discipline creates incremental builds of the system that the Test
- discipline evaluates. In each iteration, testing provides objective feedback. Effective testing enables developers
- to focus on implementing new functionality and improving the design of the system.
- </li>
- <li>
- The <a class="elementLink"
- href="./../../core.default.cat_def.base/disciplines/project_management_discipline_FEB42654.html"
- guid="_iGSHtFZ-EdyIUdvDLLUdeg">Project Management</a> discipline plans the overall project and the scope of work
- for each iteration. The Test discipline provides an objective measure of progress, which enables adaptive planning.
- </li>
- </ul></mainDescription>
+ <mainDescription><p>
+ The purpose of this discipline is to:
+</p>
+<ul>
+ <li>
+ Provide early and frequent <em>feedback</em> about whether the system satisfies the requirements
+ </li>
+ <li>
+ Objectively measure progress in small increments
+ </li>
+ <li>
+ Identify issues with the solution, increasing the probability that the system will behave correctly
+ </li>
+ <li>
+ Provide assurance that changes to the system do not introduce new defects
+ </li>
+ <li>
+ Improve velocity by facilitating the discovery of issues with requirements, designs, and implementations as early
+ as possible
+ </li>
+</ul>
+<p>
+ The Test discipline is iterative and incremental. It applies the strategy of "test early and test often" to retire
+ risks as early as possible in the system's lifecycle.
+</p>
+<p>
+ Testing occurs in each iteration of the lifecycle, beginning with the earliest builds of the system. In fact, it is
+ common for one iteration to have many test cycles, depending on the frequency of new builds.
+</p>
+<p>
+ Testing asks the question: "What does the solution have to <em>do</em> for us to consider a requirement implemented?"
+ Tests elaborate on the requirements with specific conditions of satisfaction that the solution must meet.
+</p>
+<p>
+ This discipline challenges the assumptions, risks, and uncertainty inherent in the development of highly technical
+ artifacts and addresses those concerns by using concrete demonstration and impartial evaluation.
+</p>
+<p>
+ The Test discipline relates to the other disciplines in the following ways:
+</p>
+<ul>
+ <li>
+ The <a class="elementLink"
+ href="./../../core.default.cat_def.base/disciplines/requirements_discipline_9520664.html"
+ guid="_iGSHtVZ-EdyIUdvDLLUdeg">Requirements</a> discipline identifies the <em>intent</em> of the system. Testing
+ elaborates on the requirements with detailed tests that measure how the system supports the requirements.
+ </li>
+ <li>
+ The <a class="elementLink"
+ href="./../../core.default.cat_def.base/disciplines/development_discipline_44C02445.html"
+ guid="_iGSHsVZ-EdyIUdvDLLUdeg">Development</a> discipline creates incremental builds of the system that the Test
+ discipline evaluates. In each iteration, testing provides objective feedback. Effective testing enables developers
+ to focus on implementing new functionality and improving the design of the system.
+ </li>
+ <li>
+ The <a class="elementLink"
+ href="./../../core.default.cat_def.base/disciplines/project_management_discipline_FEB42654.html"
+ guid="_iGSHtFZ-EdyIUdvDLLUdeg">Project Management</a> discipline plans the overall project and the scope of work
+ for each iteration. The Test discipline provides an objective measure of progress, which enables adaptive planning.
+ </li>
+</ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.nav_view.base/customcategories/release_info.xmi b/epf_prac_151/core.default.nav_view.base/customcategories/release_info.xmi
index 7cd087a..5136658 100644
--- a/epf_prac_151/core.default.nav_view.base/customcategories/release_info.xmi
+++ b/epf_prac_151/core.default.nav_view.base/customcategories/release_info.xmi
@@ -1,5 +1,11 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-hUN4Pfxbnmse1E-ThpHJrQ" name="release_info,_irqswCLOEd2ct852UDqXGQ" guid="-hUN4Pfxbnmse1E-ThpHJrQ" changeDate="2008-05-23T03:27:31.000-0700" version="7.5.0">
- <mainDescription><h3> Legal statement (Eclipse) </h3>
-<p class="node"> See <a class="elementLink" href="./../../core.default.release_copyright.base/guidances/supportingmaterials/intellectual_property_notices_B077124A.html" guid="_h88OsO7-EdySOuhNm0Os1w">Eclipse Intellectual Property Notices</a>. </p></mainDescription>
+ <mainDescription><h3>
+ Legal statement (Eclipse)
+</h3>
+<p class="node">
+ See <a class="elementLink"
+ href="./../../core.default.release_copyright.base/guidances/supportingmaterials/intellectual_property_notices_B077124A.html"
+ guid="_h88OsO7-EdySOuhNm0Os1w">Eclipse Intellectual Property Notices</a>.
+</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.nav_view.base/guidances/supportingmaterials/references.xmi b/epf_prac_151/core.default.nav_view.base/guidances/supportingmaterials/references.xmi
index 7dff8c3..f9094ed 100644
--- a/epf_prac_151/core.default.nav_view.base/guidances/supportingmaterials/references.xmi
+++ b/epf_prac_151/core.default.nav_view.base/guidances/supportingmaterials/references.xmi
@@ -1,16 +1,19 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-0aLpkB-z90mAiTJ2xDxrgg" name="new_supporting_material,__nHToFndEd2EdJKkAyeBng" guid="-0aLpkB-z90mAiTJ2xDxrgg" changeDate="2008-07-24T05:11:45.000-0700" version="7.5.0">
- <mainDescription><h3> General<br />
- <br />
-</h3>
-<table width="100%" summary="layout table" border="0">
- <tbody>
- <tr>
- <td valign="top" width="12%"> <a>SPEM08</a> </td>
- <td colspan="2"> Software Process Engineering Meta-Model, Version 2.0y,
- Object Management Group, 2008. </td>
- </tr>
- </tbody>
-</table>
-<br /></mainDescription>
+ <mainDescription><h3>
+ General<br />
+ <br />
+</h3>
+<table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a>SPEM08</a>
+ </td>
+ <td colspan="2">
+ Software Process Engineering Meta-Model, Version 2.0y, Object Management Group, 2008.
+ </td>
+ </tr>
+ </tbody>
+</table><br /></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.nav_view.base/guidances/supportingmaterials/welcome.xmi b/epf_prac_151/core.default.nav_view.base/guidances/supportingmaterials/welcome.xmi
index 97f7ac7..e9aa5c6 100644
--- a/epf_prac_151/core.default.nav_view.base/guidances/supportingmaterials/welcome.xmi
+++ b/epf_prac_151/core.default.nav_view.base/guidances/supportingmaterials/welcome.xmi
@@ -1,113 +1,113 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-GHjXglv-7VqexaeTpzqp3Q" name="new_supporting_material,_g910gCapEd21TMX858E1gw" guid="-GHjXglv-7VqexaeTpzqp3Q" changeDate="2008-08-05T01:32:14.000-0700" version="7.5.0">
- <mainDescription><br />
-<table title="" border="0" cellspacing="0" cellpadding="2" width="85%">
- <tbody>
- <tr>
- <td>
- <img alt="image of jigsaw pieces" src="resources/practices.jpg" width="198" height="165" />
- </td>
- <td>
- <h2>
- <font size="5"><strong>Welcome to Your Process Web Site</strong></font>
- </h2>
- </td>
- </tr>
- </tbody>
-</table>
-<table border="0" width="589" align="center">
- <tbody>
- <tr>
- <td width="96">
- <div align="center">
- <a href="./../../../core.default.nav_view.base/customcategories/getting_started_list_87D18B69.html"
- guid="_WCIHYMRdEdyD76CYS6Ta7A"><img border="0" alt="Getting Started"
- src="resources/get_started_48.gif" width="48" height="48" usemap="#map0" /></a>
- </div>
- </td>
- <td width="95">
- <div align="center">
- <a href="./../../../core.default.nav_view.base/customcategories/structured_practice_list_402CA5A4.html"
- guid="_RJ__ECLJEd2ct852UDqXGQ"><img border="0" alt="Practice" src="resources/practice.gif" width="32"
- height="32" usemap="#map2" /></a>
- </div>
- </td>
- <td width="88">
- <div align="center">
- <a href="./../../../core.default.nav_view.base/customcategories/role_list_4C636D88.html"
- guid="_WCIHZMRdEdyD76CYS6Ta7A"><img border="0" alt="Roles" src="resources/roles_48.gif" width="48"
- height="48" usemap="#map3" /></a>
- </div>
- </td>
- <td width="98">
- <div align="center">
- <a href="./../../../core.default.nav_view.base/customcategories/work_products_FB13601A.html"
- guid="__O1Y8MRgEdyD76CYS6Ta7A"><img border="0" alt="Work Products"
- src="resources/work_products_48.gif" width="48" height="48" usemap="#map4" /></a>
- </div>
- </td>
- <td width="88">
- <div align="center">
- <a href="./../../../core.default.nav_view.base/customcategories/tasks_E310E5A5.html"
- guid="_CXQicMRhEdyD76CYS6Ta7A"><img border="0" alt="Disciplines" src="resources/disciplines_48.gif"
- width="48" height="48" usemap="#map5" /></a>
- </div>
- </td>
- <td width="98">
- <div align="center">
- <a href="./../../../core.default.nav_view.base/customcategories/delivery_process_list_81087F8F.html"
- guid="_WCIHYsRdEdyD76CYS6Ta7A"><img border="0" alt="LifeCycle" src="resources/life_cycle_48.gif"
- width="48" height="48" usemap="#map6" /></a>
- </div>
- </td>
- </tr>
- <tr valign="top" align="middle">
- <td width="96">
- <div align="center">
- <a class="elementLink"
- href="./../../../core.default.nav_view.base/customcategories/getting_started_list_87D18B69.html"
- guid="_WCIHYMRdEdyD76CYS6Ta7A">Getting Started</a>
- </div>
- </td>
- <td width="95">
- <div align="center">
- <a class="elementLink"
- href="./../../../core.default.nav_view.base/customcategories/structured_practice_list_402CA5A4.html"
- guid="_RJ__ECLJEd2ct852UDqXGQ">Practices</a>
- </div>
- </td>
- <td width="88">
- <div align="center">
- <a class="elementLinkWithUserText"
- href="./../../../core.default.nav_view.base/customcategories/role_list_4C636D88.html"
- guid="_WCIHZMRdEdyD76CYS6Ta7A">Roles</a>
- </div>
- </td>
- <td width="98">
- <div align="center">
- <a class="elementLinkWithUserText"
- href="./../../../core.default.nav_view.base/customcategories/work_products_FB13601A.html"
- guid="__O1Y8MRgEdyD76CYS6Ta7A">Work Products</a>
- </div>
- </td>
- <td width="88">
- <div align="center">
- <a class="elementLinkWithUserText"
- href="./../../../core.default.nav_view.base/customcategories/tasks_E310E5A5.html"
- guid="_CXQicMRhEdyD76CYS6Ta7A">Tasks</a>&nbsp;
- </div>
- </td>
- <td width="98">
- <a class="elementLinkWithUserText"
- href="./../../../core.default.nav_view.base/customcategories/delivery_process_list_81087F8F.html"
- guid="_WCIHYsRdEdyD76CYS6Ta7A">Processes</a>
- </td>
- </tr>
- </tbody>
-</table>
-<p>
- This process Web site&nbsp;is the result of selecting and publishing a set of practices. You can navigate this site
- from different perspectives by using the links above or by using the tree browser on the left. You can replace this
- welcome page with your company-specific or process-specific welcome page.
+ <mainDescription><br />
+<table title="" border="0" cellspacing="0" cellpadding="2" width="85%">
+ <tbody>
+ <tr>
+ <td>
+ <img alt="image of jigsaw pieces" src="resources/practices.jpg" width="198" height="165" />
+ </td>
+ <td>
+ <h2>
+ <font size="5"><strong>Welcome to Your Process Web Site</strong></font>
+ </h2>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<table border="0" width="589" align="center">
+ <tbody>
+ <tr>
+ <td width="96">
+ <div align="center">
+ <a href="./../../../core.default.nav_view.base/customcategories/getting_started_list_87D18B69.html"
+ guid="_WCIHYMRdEdyD76CYS6Ta7A"><img border="0" alt="Getting Started" src="resources/get_started_48.gif"
+ width="48" height="48" usemap="#map0" /></a>
+ </div>
+ </td>
+ <td width="95">
+ <div align="center">
+ <a href="./../../../core.default.nav_view.base/customcategories/structured_practice_list_402CA5A4.html"
+ guid="_RJ__ECLJEd2ct852UDqXGQ"><img border="0" alt="Practice" src="resources/practice.gif" width="32"
+ height="32" usemap="#map2" /></a>
+ </div>
+ </td>
+ <td width="88">
+ <div align="center">
+ <a href="./../../../core.default.nav_view.base/customcategories/role_list_4C636D88.html"
+ guid="_WCIHZMRdEdyD76CYS6Ta7A"><img border="0" alt="Roles" src="resources/roles_48.gif" width="48"
+ height="48" usemap="#map3" /></a>
+ </div>
+ </td>
+ <td width="98">
+ <div align="center">
+ <a href="./../../../core.default.nav_view.base/customcategories/work_products_FB13601A.html"
+ guid="__O1Y8MRgEdyD76CYS6Ta7A"><img border="0" alt="Work Products" src="resources/work_products_48.gif"
+ width="48" height="48" usemap="#map4" /></a>
+ </div>
+ </td>
+ <td width="88">
+ <div align="center">
+ <a href="./../../../core.default.nav_view.base/customcategories/tasks_E310E5A5.html"
+ guid="_CXQicMRhEdyD76CYS6Ta7A"><img border="0" alt="Disciplines" src="resources/disciplines_48.gif"
+ width="48" height="48" usemap="#map5" /></a>
+ </div>
+ </td>
+ <td width="98">
+ <div align="center">
+ <a href="./../../../core.default.nav_view.base/customcategories/delivery_process_list_81087F8F.html"
+ guid="_WCIHYsRdEdyD76CYS6Ta7A"><img border="0" alt="LifeCycle" src="resources/life_cycle_48.gif"
+ width="48" height="48" usemap="#map6" /></a>
+ </div>
+ </td>
+ </tr>
+ <tr valign="top" align="middle">
+ <td width="96">
+ <div align="center">
+ <a class="elementLink"
+ href="./../../../core.default.nav_view.base/customcategories/getting_started_list_87D18B69.html"
+ guid="_WCIHYMRdEdyD76CYS6Ta7A">Getting Started</a>
+ </div>
+ </td>
+ <td width="95">
+ <div align="center">
+ <a class="elementLink"
+ href="./../../../core.default.nav_view.base/customcategories/structured_practice_list_402CA5A4.html"
+ guid="_RJ__ECLJEd2ct852UDqXGQ">Practices</a>
+ </div>
+ </td>
+ <td width="88">
+ <div align="center">
+ <a class="elementLinkWithUserText"
+ href="./../../../core.default.nav_view.base/customcategories/role_list_4C636D88.html"
+ guid="_WCIHZMRdEdyD76CYS6Ta7A">Roles</a>
+ </div>
+ </td>
+ <td width="98">
+ <div align="center">
+ <a class="elementLinkWithUserText"
+ href="./../../../core.default.nav_view.base/customcategories/work_products_FB13601A.html"
+ guid="__O1Y8MRgEdyD76CYS6Ta7A">Work Products</a>
+ </div>
+ </td>
+ <td width="88">
+ <div align="center">
+ <a class="elementLinkWithUserText"
+ href="./../../../core.default.nav_view.base/customcategories/tasks_E310E5A5.html"
+ guid="_CXQicMRhEdyD76CYS6Ta7A">Tasks</a>&nbsp;
+ </div>
+ </td>
+ <td width="98">
+ <a class="elementLinkWithUserText"
+ href="./../../../core.default.nav_view.base/customcategories/delivery_process_list_81087F8F.html"
+ guid="_WCIHYsRdEdyD76CYS6Ta7A">Processes</a>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>
+ This process Web site&nbsp;is the result of selecting and publishing a set of practices. You can navigate this site
+ from different perspectives by using the links above or by using the tree browser on the left. You can replace this
+ welcome page with your company-specific or process-specific welcome page.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.release_copyright.base/guidances/supportingmaterials/copyright.xmi b/epf_prac_151/core.default.release_copyright.base/guidances/supportingmaterials/copyright.xmi
index 2a91597..92c6c5c 100644
--- a/epf_prac_151/core.default.release_copyright.base/guidances/supportingmaterials/copyright.xmi
+++ b/epf_prac_151/core.default.release_copyright.base/guidances/supportingmaterials/copyright.xmi
@@ -1,13 +1,13 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_u_Zg4PsDEdmyhNQr5STrZQ" name="copyright,_uuunoPsDEdmyhNQr5STrZQ" guid="_u_Zg4PsDEdmyhNQr5STrZQ" changeDate="2010-08-31T02:02:53.000-0700" version="1.0.0">
- <mainDescription><p>
- This program and the accompanying materials are made available under the<br />
- <a href="http://www.eclipse.org/org/documents/epl-v10.php" target="_blank">Eclipse Public License V1.0</a>, which
- accompanies this distribution.
-</p>
-<p>
- <a class="elementLink"
- href="./../../../core.default.release_copyright.base/guidances/supportingmaterials/epf_copyright_C3031062.html"
- guid="_UaGfECcTEduSX6N2jUafGA">EPF Copyright</a>.
+ <mainDescription><p>
+ This program and the accompanying materials are made available under the<br />
+ <a href="http://www.eclipse.org/org/documents/epl-v10.php" target="_blank">Eclipse Public License V1.0</a>, which
+ accompanies this distribution.
+</p>
+<p>
+ <a class="elementLink"
+ href="./../../../core.default.release_copyright.base/guidances/supportingmaterials/epf_copyright_C3031062.html"
+ guid="_UaGfECcTEduSX6N2jUafGA">EPF Copyright</a>.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.release_copyright.base/guidances/supportingmaterials/intellectual_property_notices.xmi b/epf_prac_151/core.default.release_copyright.base/guidances/supportingmaterials/intellectual_property_notices.xmi
index 103d57a..28f74f3 100644
--- a/epf_prac_151/core.default.release_copyright.base/guidances/supportingmaterials/intellectual_property_notices.xmi
+++ b/epf_prac_151/core.default.release_copyright.base/guidances/supportingmaterials/intellectual_property_notices.xmi
@@ -1,23 +1,31 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-uAmJkciaDVaJ5g3byOMdtg" name=",_h88OsO7-EdySOuhNm0Os1w" guid="-uAmJkciaDVaJ5g3byOMdtg" changeDate="2008-03-10T05:05:11.000-0700" version="7.2.0">
- <mainDescription>NOTICES AND INFORMATION<br />
-<br />
-<p> These Notices apply to portions of this Program. They are not part of the
- license under which you receive the Program and are provided for informational
- purposes. </p>
-<p> About This Content </p>
-<p> May 2, 2006 </p>
-<p> License </p>
-<p> The Eclipse Foundation makes available all content in this plug-in ("Content").
- Unless otherwise indicated below, the Content is provided to you under the terms
- and conditions of the Eclipse Public License Version 1.0 ("EPL"). A copy of
- the EPL is available at http://www.eclipse.org/legal/epl-v10.html. For purposes
- of the EPL, "Program" will mean the Content. </p>
-<p> If you did not receive this Content directly from the Eclipse Foundation,
- the Content is being redistributed by another party ("Redistributor") and different
- terms and conditions may apply to your use of any object code in the Content.
- Check the Redistributor's license that was provided with the Content. If no
- such license exists, contact the Redistributor. Unless otherwise indicated below,
- the terms and conditions of the EPL still apply to any source code in the Content
- and such source code may be obtained at http://www.eclipse.org. </p></mainDescription>
+ <mainDescription>NOTICES AND INFORMATION<br />
+<br />
+<p>
+ These Notices apply to portions of this Program. They are not part of the license under which you receive the Program
+ and are provided for informational purposes.
+</p>
+<p>
+ About This Content
+</p>
+<p>
+ May 2, 2006
+</p>
+<p>
+ License
+</p>
+<p>
+ The Eclipse Foundation makes available all content in this plug-in ("Content"). Unless otherwise indicated below, the
+ Content is provided to you under the terms and conditions of the Eclipse Public License Version 1.0 ("EPL"). A copy of
+ the EPL is available at http://www.eclipse.org/legal/epl-v10.html. For purposes of the EPL, "Program" will mean the
+ Content.
+</p>
+<p>
+ If you did not receive this Content directly from the Eclipse Foundation, the Content is being redistributed by another
+ party ("Redistributor") and different terms and conditions may apply to your use of any object code in the Content.
+ Check the Redistributor's license that was provided with the Content. If no such license exists, contact the
+ Redistributor. Unless otherwise indicated below, the terms and conditions of the EPL still apply to any source code in
+ the Content and such source code may be obtained at http://www.eclipse.org.
+</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.release_copyright.base/guidances/supportingmaterials/release_info.xmi b/epf_prac_151/core.default.release_copyright.base/guidances/supportingmaterials/release_info.xmi
index b372895..ff3f48e 100644
--- a/epf_prac_151/core.default.release_copyright.base/guidances/supportingmaterials/release_info.xmi
+++ b/epf_prac_151/core.default.release_copyright.base/guidances/supportingmaterials/release_info.xmi
@@ -59,13 +59,13 @@
</p>
<ul>
<li>
- Work product slots to allow practices to be independent of each other
+ Work product slots to allow practices to be independent of each other.
</li>
<li>
- Default navigation view so that <i>ad hoc</i> configurations of practices can be published easily with a view
+ Default navigation view that <i>ad hoc</i> configurations of practices can be published easily with a view.
</li>
<li>
- Guidance and work products&nbsp;reusable across practices have been moved into common plug-ins
+ Guidance and work products&nbsp;reusable across practices have been moved into common plug-ins.
</li>
<li>
Category, role, and tool definitions separated into separate plug-ins to allow them to be easily removed and
diff --git a/epf_prac_151/core.default.role_def.base/plugin.xmi b/epf_prac_151/core.default.role_def.base/plugin.xmi
index 671a190..97b4bb3 100644
--- a/epf_prac_151/core.default.role_def.base/plugin.xmi
+++ b/epf_prac_151/core.default.role_def.base/plugin.xmi
@@ -1,5 +1,5 @@
<?xml version="1.0" encoding="UTF-8"?>
-<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1">
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1">
<org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_9KCbULekEd-D7YZN9NgldQ" guid="_9KCbULekEd-D7YZN9NgldQ">
<resourceDescriptors xmi:id="_-jvZMLekEd-D7YZN9NgldQ" id="-xLl5B3qPPdk8LfLut7r8hQ" uri="rolesets/basic_role_set.xmi"/>
<resourceDescriptors xmi:id="_-jvZMbekEd-D7YZN9NgldQ" id="_Nx8icKYdEdmvhNXG0Oc2uA" uri="roles/analyst.xmi"/>
@@ -64,7 +64,7 @@
</contentElements>
</childPackages>
<childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_uLoNoKrzEd-4oa5dU5v0Eg" name="business_rules_dev_roles" guid="_uLoNoKrzEd-4oa5dU5v0Eg" presentationName="Business Rules Development Roles">
- <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_Xh-X4AqBEdyPCr4G1Tb79A" name="business_analyst" guid="_Xh-X4AqBEdyPCr4G1Tb79A" presentationName="Business Analyst" briefDescription="The Business Analyst (BA) acts as the bridge between the business and IT departments. He understands the IT technologies benefits such as BPM and BRMS and how he can use them. He has a good understanding of the business needs and problems. ">
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_Xh-X4AqBEdyPCr4G1Tb79A" name="business_analyst" guid="_Xh-X4AqBEdyPCr4G1Tb79A" presentationName="Business Analyst" briefDescription="The Business Analyst (BA) acts as the bridge between the business and IT departments. He understands the IT technologies benefits such as BPM and BRMS and how he can use them. He has a good understanding of the business needs and problems.">
<presentation xmi:id="-2FZPy2In9T_oVCB3M9kB7w" href="uma://-2FZPy2In9T_oVCB3M9kB7w#-2FZPy2In9T_oVCB3M9kB7w"/>
</contentElements>
<contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_5h_uoKcyEd-VK6zqjMaiPQ" name="business_process_analyst" guid="_5h_uoKcyEd-VK6zqjMaiPQ" presentationName="Business Process Analyst" briefDescription="The role of the Business Process Analyst is to build consensus among the different stakeholders on the as-is and to-be process models, and to look for opportunities to improve the current business process.">
@@ -91,7 +91,7 @@
<contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_jmrVYL9xEd-AG_DXKKgAXg" name="process_engineer" guid="_jmrVYL9xEd-AG_DXKKgAXg" presentationName="Process Engineer" briefDescription="This role equips the project team with an appropriate development process, and makes sure that the team members are not hindered in doing their jobs.">
<presentation xmi:id="-mG2MksMZ8rnYuB_UxF53ow" href="uma://-mG2MksMZ8rnYuB_UxF53ow#-mG2MksMZ8rnYuB_UxF53ow"/>
</contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_jmrVYb9xEd-AG_DXKKgAXg" name="tool_specialist" guid="_jmrVYb9xEd-AG_DXKKgAXg" presentationName="Tool Specialist" briefDescription="This role supports the tools used by the project and provides technical assistance to the project. This includes selecting and acquiring tools, configuring and setting them up, and verifying that they work. ">
+ <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_jmrVYb9xEd-AG_DXKKgAXg" name="tool_specialist" guid="_jmrVYb9xEd-AG_DXKKgAXg" presentationName="Tool Specialist" briefDescription="This role supports the tools used by the project and provides technical assistance to the project. This includes selecting and acquiring tools, configuring and setting them up, and verifying that they work.">
<presentation xmi:id="-58kSfjmClnawXPOPb1aUnQ" href="uma://-58kSfjmClnawXPOPb1aUnQ#-58kSfjmClnawXPOPb1aUnQ"/>
</contentElements>
</childPackages>
diff --git a/epf_prac_151/core.default.role_def.base/roles/analyst.xmi b/epf_prac_151/core.default.role_def.base/roles/analyst.xmi
index 0608281..2759864 100644
--- a/epf_prac_151/core.default.role_def.base/roles/analyst.xmi
+++ b/epf_prac_151/core.default.role_def.base/roles/analyst.xmi
@@ -31,8 +31,8 @@
complex requirements that are difficult to gather.
</li>
<li>
- One (or more) team members performs both this role and tests the software. This is a good option for smaller or
- resource<font color="#ff0000">-</font>constrained test teams.
+ One (or more) team members performs both this role and tests the software. This is a good option for smaller test
+ teams or resource<font color="#ff0000">-</font>constrained test teams.
</li>
<li>
A customer representative performs this role. This approach is suitable to agile teams where the customer is
diff --git a/epf_prac_151/core.default.role_def.base/roles/any_role.xmi b/epf_prac_151/core.default.role_def.base/roles/any_role.xmi
index 14ce982..7a88ac3 100644
--- a/epf_prac_151/core.default.role_def.base/roles/any_role.xmi
+++ b/epf_prac_151/core.default.role_def.base/roles/any_role.xmi
@@ -1,11 +1,20 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:RoleDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_NqqcUqeqEdmKDbQuyzCoqQ" name="any_role,_0dsWoMlgEdmt3adZL5Dmdw" guid="_NqqcUqeqEdmKDbQuyzCoqQ" changeDate="2006-09-11T11:34:17.000-0700" version="7.2.0">
- <mainDescription><p> This role allows anyone on a team to perform general tasks: </p>
-<ul>
- <li> Access artifacts in the configuration control system for development and
- maintenance </li>
- <li> Submit change requests for the project </li>
- <li> Participate in assessments and reviews </li>
- <li> Volunteer to work on a particular iteration </li>
+ <mainDescription><p>
+ This role allows anyone on a team to perform general tasks:
+</p>
+<ul>
+ <li>
+ Access artifacts in the configuration control system for development and maintenance
+ </li>
+ <li>
+ Submit change requests for the project
+ </li>
+ <li>
+ Participate in assessments and reviews
+ </li>
+ <li>
+ Volunteer to work on a particular iteration
+ </li>
</ul></mainDescription>
</org.eclipse.epf.uma:RoleDescription>
diff --git a/epf_prac_151/core.default.role_def.base/roles/architect.xmi b/epf_prac_151/core.default.role_def.base/roles/architect.xmi
index e19faa0..f78d6a1 100644
--- a/epf_prac_151/core.default.role_def.base/roles/architect.xmi
+++ b/epf_prac_151/core.default.role_def.base/roles/architect.xmi
@@ -1,23 +1,23 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:RoleDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_Y6tLEKbXEdm9d-ircVOUCA" name="architect,_0X9iEMlgEdmt3adZL5Dmdw" guid="_Y6tLEKbXEdm9d-ircVOUCA" changeDate="2008-10-14T02:08:08.000-0700" version="1.0.0">
- <mainDescription><p>
- The person in this role leads or coordinates the technical design of the system and has overall responsibility for
- facilitating the major technical decisions expressed as software architecture. This typically includes identifying and
- documenting the architecturally significant aspects of the system as views that describe requirements, design,
- implementation, and deployment.
-</p>
-<p>
- This role is also responsible for providing the rationale for these decisions, balancing the concerns of the various
- stakeholders, reducing technical risks, and ensuring that decisions are effectively communicated, validated, and
- followed.
-</p>
-<p>
- This role works closely with&nbsp;project managers&nbsp;in staffing and planning the project, because it is recommended
- that the team be organized around the architecture.
-</p>
-<p>
- This role also works closely with&nbsp;analysts and developers&nbsp;to make sure that the architecturally significant
- requirements are assigned to the proper components of the system.&nbsp;
+ <mainDescription><p>
+ The person in this role leads or coordinates the technical design of the system and has overall responsibility for
+ facilitating the major technical decisions expressed as software architecture. This typically includes identifying and
+ documenting the architecturally significant aspects of the system as views that describe requirements, design,
+ implementation, and deployment.
+</p>
+<p>
+ This role is also responsible for providing the rationale for these decisions, balancing the concerns of the various
+ stakeholders, reducing technical risks, and ensuring that decisions are effectively communicated, validated, and
+ followed.
+</p>
+<p>
+ This role works closely with&nbsp;project managers&nbsp;in staffing and planning the project, because it is recommended
+ that the team be organized around the architecture.
+</p>
+<p>
+ This role also works closely with&nbsp;analysts and developers&nbsp;to make sure that the architecturally significant
+ requirements are assigned to the proper components of the system.&nbsp;
</p></mainDescription>
<skills><p>
Architects must be well-rounded people with maturity, vision, and a depth of experience that allows for grasping issues
diff --git a/epf_prac_151/core.default.role_def.base/roles/business_analyst.xmi b/epf_prac_151/core.default.role_def.base/roles/business_analyst.xmi
index 0408157..c048c85 100644
--- a/epf_prac_151/core.default.role_def.base/roles/business_analyst.xmi
+++ b/epf_prac_151/core.default.role_def.base/roles/business_analyst.xmi
@@ -1,15 +1,15 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:RoleDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-2FZPy2In9T_oVCB3M9kB7w" name="business_analyst,_eRFOABtcEdu_BZ3CL1I6hw" guid="-2FZPy2In9T_oVCB3M9kB7w" authors="Jerome Boyer" changeDate="2008-08-22T05:01:21.000-0700" version="1.0.0">
- <mainDescription><a id="XE_business_analyst" name="XE_business_analyst"></a>
-<p>
- <a id="1036306" name="1036306">Business Analysts&nbsp;(BA) act as the bridge between the business and IT departments,
- by smoothing the way as corporate policy moves from definition to execution inside a software application. Business
- Analysts must translate policy into a formal specification acceptable to developers, and must validate the formal
- specification with policy managers who may not understand the language of the specification.</a><br />
-</p>
-<p>
- Depending on their level of technical knowledge, Business Analysts may perform tasks that are described as developer
- tasks. However, generally business analysts do not write code.&nbsp;<a id="4942" name="4942">In a BRMS&nbsp;a
- BA&nbsp;also represents a type of user profile who is responsible for modeling business rule application projects</a>.
+ <mainDescription><a id="XE_business_analyst" name="XE_business_analyst"></a> 
+<p>
+ <a id="1036306" name="1036306">Business Analysts&nbsp;(BA) act as the bridge between the business and IT departments,
+ by smoothing the way as corporate policy moves from definition to execution inside a software application. Business
+ Analysts must translate policy into a formal specification acceptable to developers, and must validate the formal
+ specification with policy managers who may not understand the language of the specification.</a><br />
+</p>
+<p>
+ Depending on their level of technical knowledge, Business Analysts may perform tasks that are described as developer
+ tasks. However, generally business analysts do not write code.&nbsp;<a id="4942" name="4942">In a BRMS&nbsp;a
+ BA&nbsp;also represents a type of user profile who is responsible for modeling business rule application projects</a>.
</p></mainDescription>
</org.eclipse.epf.uma:RoleDescription>
diff --git a/epf_prac_151/core.default.role_def.base/roles/business_process_analyst.xmi b/epf_prac_151/core.default.role_def.base/roles/business_process_analyst.xmi
index 0acb606..3676d62 100644
--- a/epf_prac_151/core.default.role_def.base/roles/business_process_analyst.xmi
+++ b/epf_prac_151/core.default.role_def.base/roles/business_process_analyst.xmi
@@ -1,8 +1,8 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:RoleDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-RTY4zT0X_3RNb7lElRMu0Q" name="new_role,_5h_uoKcyEd-VK6zqjMaiPQ" guid="-RTY4zT0X_3RNb7lElRMu0Q" changeDate="2010-08-13T04:56:18.000-0700" version="7.5.0">
- <mainDescription>Business process analyst leads process improvement efforts, from the process discovery, to simulation, monitoring and
-enhancement. He is an expert in process decomposition, process/data analysis, scoping, optimization. He can identifies new
-business case and&nbsp;key opportunities within the enterprise, and enforce the&nbsp;delivery of KPIs, SLAs, and
+ <mainDescription>Business process analyst leads process improvement efforts, from the process discovery, to simulation, monitoring and
+enhancement. He is an expert in process decomposition, process/data analysis, scoping, optimization. He can identifies new
+business case and&nbsp;key opportunities within the enterprise, and enforce the&nbsp;delivery of KPIs, SLAs, and
scoreboards.<br /></mainDescription>
<skills><p>
As a base a BPA is an analyst. He needs:
diff --git a/epf_prac_151/core.default.role_def.base/roles/developer.xmi b/epf_prac_151/core.default.role_def.base/roles/developer.xmi
index fd99d06..3787909 100644
--- a/epf_prac_151/core.default.role_def.base/roles/developer.xmi
+++ b/epf_prac_151/core.default.role_def.base/roles/developer.xmi
@@ -1,20 +1,28 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:RoleDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_NqL7MqeqEdmKDbQuyzCoqQ" name="developer,_0YDosMlgEdmt3adZL5Dmdw" guid="_NqL7MqeqEdmKDbQuyzCoqQ" changeDate="2008-07-02T06:41:08.000-0700" version="1.0.0">
- <skills><p> The person in this role needs the following knowledge, skills, and abilities: 
+ <skills><p>
+ The person in this role needs the following knowledge, skills, and abilities:
</p>
<ul>
- <li>Enough expertise and experience to define and create technical solutions 
- in the project's technology </li>
- <li> Ability to understand and&nbsp;conform to the&nbsp;architecture </li>
- <li> Ability to identify and build developer tests that cover required behavior 
- of the technical components </li>
- <li> Ability to communicate the design in a way that other team members understand 
- </li>
+ <li>
+ Enough expertise and experience to define and create technical solutions in the project's technology
+ </li>
+ <li>
+ Ability to understand and conform to the architecture
+ </li>
+ <li>
+ Ability to identify and build developer tests that cover required behavior of the technical components
+ </li>
+ <li>
+ Ability to communicate the design in a way that other team members understand
+ </li>
</ul></skills>
- <assignmentApproaches><p> A person performing this role can have specialized skills in a particular 
- technical area but should also have a broad understanding of all of the technologies 
- involved to be able to work with other technical team members. </p>
-<p> Even in the smallest team, multiple individuals should be working together 
- to create the technical solution. In small, agile teams, this role is often 
- shared among several team members who also perform other roles.&nbsp;</p> <br /></assignmentApproaches>
+ <assignmentApproaches><p>
+ A person performing this role can have specialized skills in a particular technical area but should also have a broad
+ understanding of all of the technologies involved to be able to work with other technical team members.
+</p>
+<p>
+ Even in the smallest team, multiple individuals should be working together to create the technical solution. In small,
+ agile teams, this role is often shared among several team members who also perform other roles.&nbsp;
+</p><br /></assignmentApproaches>
</org.eclipse.epf.uma:RoleDescription>
diff --git a/epf_prac_151/core.default.role_def.base/roles/project_manager.xmi b/epf_prac_151/core.default.role_def.base/roles/project_manager.xmi
index bddffa0..e79b182 100644
--- a/epf_prac_151/core.default.role_def.base/roles/project_manager.xmi
+++ b/epf_prac_151/core.default.role_def.base/roles/project_manager.xmi
@@ -1,33 +1,39 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:RoleDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_Fdq-8KX4EdmvhNXG0Oc2uA" name="project_manager,_0a0o0MlgEdmt3adZL5Dmdw" guid="_Fdq-8KX4EdmvhNXG0Oc2uA" changeDate="2008-10-14T02:20:12.000-0700" version="1.0.0">
- <mainDescription><p> The person in this role: </p>
-<ul>
-
- <li> Coaches the team to drive a successful outcome of the project and the acceptance
- of the product by the customer</li>
- <li> Is accountable for the outcome of the project and the acceptance of the
- product by the customer</li>
-
- <li> Is responsible for the evaluation of project's risks and for controlling
- those risks through mitigation strategies</li>
-
- <li> Applies management knowledge, skills, tools, and techniques to a broad
- range of tasks to deliver&nbsp;the desired&nbsp;result for a particular project
- in a timely manner</li>
+ <mainDescription><p>
+ The person in this role:
+</p>
+<ul>
+ <li>
+ Coaches the team to drive a successful outcome of the project and the acceptance of the product by the customer
+ </li>
+ <li>
+ Is accountable for the outcome of the project and the acceptance of the product by the customer
+ </li>
+ <li>
+ Is responsible for the evaluation of project's risks and for controlling those risks through mitigation strategies
+ </li>
+ <li>
+ Applies management knowledge, skills, tools, and techniques to a broad range of tasks to deliver&nbsp;the
+ desired&nbsp;result for a particular project in a timely manner
+ </li>
</ul></mainDescription>
<skills><p>
A person performing this role needs the following skills:
</p>
<ul>
- 
- <li> Leadership and team-building capabilities</li>
- 
- <li> Thorough experience in the software development lifecycle to coach, guide, 
- and support other team members</li>
- 
- <li> Proficiency in conflict resolution and problem-solving techniques</li>
- 
- <li> Good skills in presentation, facilitation, communication, and negotiation</li>
+ <li>
+ Leadership and team-building capabilities
+ </li>
+ <li>
+ Thorough experience in the software development lifecycle to coach, guide, and support other team members
+ </li>
+ <li>
+ Proficiency in conflict resolution and problem-solving techniques
+ </li>
+ <li>
+ Good skills in presentation, facilitation, communication, and negotiation
+ </li>
</ul></skills>
<assignmentApproaches><p>
This role is often played by a single person. It is difficult to have this role shared by multiple people, but it might
diff --git a/epf_prac_151/core.default.role_def.base/roles/rule_administrator.xmi b/epf_prac_151/core.default.role_def.base/roles/rule_administrator.xmi
index 53d732b..af0ecb6 100644
--- a/epf_prac_151/core.default.role_def.base/roles/rule_administrator.xmi
+++ b/epf_prac_151/core.default.role_def.base/roles/rule_administrator.xmi
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:RoleDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-zsWMh4kEcZeEXZbUlvLq_g" name="rule_administrator,_XiII4QqBEdyPCr4G1Tb79A" guid="-zsWMh4kEcZeEXZbUlvLq_g" authors="Jerome Boyer" changeDate="2008-01-22T10:25:01.000-0800" version="7.5.1">
- <mainDescription><a id="XE_rule_administrator" name="XE_rule_administrator"></a><a id="4942" name="4942">In a</a> <a id="4926"
-name="4926">BRMS the Rule Administrator is a user who is proficient in system configuration and administration and
-is&nbsp;responsible for administrating the BRMS.</a>&nbsp;In particular he/she will deploy a rule set in the different
+ <mainDescription><a id="XE_rule_administrator" name="XE_rule_administrator"></a><a id="4942" name="4942">In a</a> <a id="4926"
+name="4926">BRMS the Rule Administrator is a user who is proficient in system configuration and administration and
+is&nbsp;responsible for administrating the BRMS.</a>&nbsp;In particular he/she will deploy a rule set in the different
server environments: development, test, production.</mainDescription>
</org.eclipse.epf.uma:RoleDescription>
diff --git a/epf_prac_151/core.default.role_def.base/roles/rule_analyst.xmi b/epf_prac_151/core.default.role_def.base/roles/rule_analyst.xmi
index e07f915..735aae7 100644
--- a/epf_prac_151/core.default.role_def.base/roles/rule_analyst.xmi
+++ b/epf_prac_151/core.default.role_def.base/roles/rule_analyst.xmi
@@ -1,73 +1,73 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:RoleDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-qlAPD9PZWcRLTERMArE6mQ" name="rule_analyst,_gJycEBtcEdu_BZ3CL1I6hw" guid="-qlAPD9PZWcRLTERMArE6mQ" authors="Jerome Boyer" changeDate="2008-10-17T04:15:37.000-0700" version="1.0.0">
- <mainDescription><a id="XE_rule_analyst" name="XE_rule_analyst"></a>
-<p>
- A Rule Analyst is a special business analyst with a strong knowledge of how a business rule application runs and how to
- do rule programming. In his day to day work he is helping the business team to&nbsp;turn business policy into rules,
- but also helps&nbsp;to clearly define the business view, or&nbsp;fact model,&nbsp;for developers to implement.
-</p>
-<p>
- He acts as a bridge between the business side and technical side of an application, translating business policy into a
- formal specification (model) for developers, then validates it with&nbsp;the different business managers. With the IT
- developer he/she will share the definition of the vocabulary used in rules, then he captures, writes, and organizes
- business logic into business rules.<br />
-</p>
-<p>
- In rule-based project his direct involvement includes at least the following activities
-</p>
-<ul>
- <li>
- Identifies business sponsors for issues relating to business rules.
- </li>
- <li>
- Maintain traceability from the business policies to the executable business rules.
- </li>
- <li>
- Assists business in identifying existing business rules.
- </li>
- <li>
- Researches the meaning and origin of the business rules
- </li>
- <li>
- Create rule templates for rule writers and analyst
- </li>
- <li>
- Analyze rules for completeness, correctness, optimization (from a logical, not performance, perspective)
- </li>
- <li>
- Identify how rules are used in processes that implement business policies
- </li>
- <li>
- Ensure the quality of the business rules
- </li>
- <li>
- Ensure that consistent terminology is used in the business rules in order to build a common vocabulary and a domain
- data model
- </li>
- <li>
- Analyze business rules to identify conflicts, redundancies
- </li>
- <li>
- Ensure consistency of business rules across functions, geographies and systems
- </li>
- <li>
- Conduct impact analysis for revision or replacement of business rules
- </li>
- <li>
- Integrate new or revised rules into existing rule set
- </li>
- <li>
- Make recommendations for business rule changes based on business knowledge
- </li>
- <li>
- Facilitate resolution of business rules issues
- </li>
- <li>
- Act as consultant for the project team
- </li>
- <li>
- Act as a liaison between business and IT<br />
- </li>
+ <mainDescription><a id="XE_rule_analyst" name="XE_rule_analyst"></a> 
+<p>
+ A Rule Analyst is a special business analyst with a strong knowledge of how a business rule application runs and how to
+ do rule programming. In his day to day work he is helping the business team to&nbsp;turn business policy into rules,
+ but also helps&nbsp;to clearly define the business view, or&nbsp;fact model,&nbsp;for developers to implement.
+</p>
+<p>
+ He acts as a bridge between the business side and technical side of an application, translating business policy into a
+ formal specification (model) for developers, then validates it with&nbsp;the different business managers. With the IT
+ developer he/she will share the definition of the vocabulary used in rules, then he captures, writes, and organizes
+ business logic into business rules.<br />
+</p>
+<p>
+ In rule-based project his direct involvement includes at least the following activities
+</p>
+<ul>
+ <li>
+ Identifies business sponsors for issues relating to business rules.
+ </li>
+ <li>
+ Maintain traceability from the business policies to the executable business rules.
+ </li>
+ <li>
+ Assists business in identifying existing business rules.
+ </li>
+ <li>
+ Researches the meaning and origin of the business rules
+ </li>
+ <li>
+ Create rule templates for rule writers and analyst
+ </li>
+ <li>
+ Analyze rules for completeness, correctness, optimization (from a logical, not performance, perspective)
+ </li>
+ <li>
+ Identify how rules are used in processes that implement business policies
+ </li>
+ <li>
+ Ensure the quality of the business rules
+ </li>
+ <li>
+ Ensure that consistent terminology is used in the business rules in order to build a common vocabulary and a domain
+ data model
+ </li>
+ <li>
+ Analyze business rules to identify conflicts, redundancies
+ </li>
+ <li>
+ Ensure consistency of business rules across functions, geographies and systems
+ </li>
+ <li>
+ Conduct impact analysis for revision or replacement of business rules
+ </li>
+ <li>
+ Integrate new or revised rules into existing rule set
+ </li>
+ <li>
+ Make recommendations for business rule changes based on business knowledge
+ </li>
+ <li>
+ Facilitate resolution of business rules issues
+ </li>
+ <li>
+ Act as consultant for the project team
+ </li>
+ <li>
+ Act as a liaison between business and IT<br />
+ </li>
</ul></mainDescription>
<skills><p>
He knows how a rule engine works, how to design a conceptual data model, how to do the rule discovery and analysis
diff --git a/epf_prac_151/core.default.role_def.base/roles/rule_architect.xmi b/epf_prac_151/core.default.role_def.base/roles/rule_architect.xmi
index af84a10..41e0245 100644
--- a/epf_prac_151/core.default.role_def.base/roles/rule_architect.xmi
+++ b/epf_prac_151/core.default.role_def.base/roles/rule_architect.xmi
@@ -1,72 +1,72 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:RoleDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-utBebAOL0zjzOcCgAB-7VQ" name="brms_architect,_s7UjMPjqEduTuLQpeq3SiA" guid="-utBebAOL0zjzOcCgAB-7VQ" authors="Jerome Boyer" changeDate="2008-10-17T04:20:48.000-0700" version="1.0.0">
- <mainDescription><a id="XE_rule_architect" name="XE_rule_architect"></a>
-<p>
- A Rule Architect&nbsp;helps the team to:&nbsp;
-</p>
-<ul>
- <li>
- work together in an agile fashion,
- </li>
- <li>
- jointly own the solution, and to
- </li>
- <li>
- interface well with other parts of the organisation.
- </li>
-</ul>
-<p>
- The Rule Architect defines the structure and organisation of the rule-based system. Outside of the standard activities,
- skills, roles and responsibilities of a software architect, his role extends to:
-</p>
-<ul>
- <li>
- <span style="mso-bidi-font-size: 10.0pt">Selecting the&nbsp;technology to ensure performance of the rule execution
- and usability of the BRMS platform</span>
- </li>
- <li>
- <span style="mso-bidi-font-size: 10.0pt">Designing the <a id="1094990" name="1094990">infrastructure necessary for
- editing rules, and producing one or several Rule Sets</a></span>
- </li>
- <li>
- <span style="mso-bidi-font-size: 10.0pt">Building the structure of rule projects, the dependencies on the
- executable domain object model.</span>
- </li>
- <li>
- <span style="mso-bidi-font-size: 10.0pt">Defining the decision services part of a SOA. Those services use Rule
- Sets.</span>
- </li>
- <li>
- <span style="mso-bidi-font-size: 10.0pt">Ensuring that the overall deployment organization of the rules makes sense
- from an application segmentation perspective</span>
- </li>
- <li>
- <span style="mso-bidi-font-size: 10.0pt">Ensuring optimization of rule execution</span>
- </li>
- <li>
- <span style="mso-bidi-font-size: 10.0pt">Establishing traceability for rules within the technical
- architecture</span>
- </li>
- <li>
- <span style="mso-bidi-font-size: 10.0pt">Ensuring rule reuse</span>
- </li>
- <li>
- <span style="mso-bidi-font-size: 10.0pt">Designing the structure of the rule repository (defining the required
- metadata customizations and possibly implementing the structure)</span>
- </li>
- <li>
- <span style="mso-bidi-font-size: 10.0pt">Developing the processes around repository management, rule life-cycle,
- rule set life-cycle, rule governance</span>
- </li>
- <li>
- <span style="mso-bidi-font-size: 10.0pt">Coordinating with application developers on system design, implementation
- and testing</span>
- </li>
- <li>
- <span
- style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Acting
- as a liaison between business and IT</span>
- </li>
+ <mainDescription><a id="XE_rule_architect" name="XE_rule_architect"></a> 
+<p>
+ A Rule Architect&nbsp;helps the team to:&nbsp;
+</p>
+<ul>
+ <li>
+ work together in an agile fashion,
+ </li>
+ <li>
+ jointly own the solution, and to
+ </li>
+ <li>
+ interface well with other parts of the organisation.
+ </li>
+</ul>
+<p>
+ The Rule Architect defines the structure and organisation of the rule-based system. Outside of the standard activities,
+ skills, roles and responsibilities of a software architect, his role extends to:
+</p>
+<ul>
+ <li>
+ <span style="mso-bidi-font-size: 10.0pt">Selecting the&nbsp;technology to ensure performance of the rule execution
+ and usability of the BRMS platform</span>
+ </li>
+ <li>
+ <span style="mso-bidi-font-size: 10.0pt">Designing the <a id="1094990" name="1094990">infrastructure necessary for
+ editing rules, and producing one or several Rule Sets</a></span>
+ </li>
+ <li>
+ <span style="mso-bidi-font-size: 10.0pt">Building the structure of rule projects, the dependencies on the
+ executable domain object model.</span>
+ </li>
+ <li>
+ <span style="mso-bidi-font-size: 10.0pt">Defining the decision services part of a SOA. Those services use Rule
+ Sets.</span>
+ </li>
+ <li>
+ <span style="mso-bidi-font-size: 10.0pt">Ensuring that the overall deployment organization of the rules makes sense
+ from an application segmentation perspective</span>
+ </li>
+ <li>
+ <span style="mso-bidi-font-size: 10.0pt">Ensuring optimization of rule execution</span>
+ </li>
+ <li>
+ <span style="mso-bidi-font-size: 10.0pt">Establishing traceability for rules within the technical
+ architecture</span>
+ </li>
+ <li>
+ <span style="mso-bidi-font-size: 10.0pt">Ensuring rule reuse</span>
+ </li>
+ <li>
+ <span style="mso-bidi-font-size: 10.0pt">Designing the structure of the rule repository (defining the required
+ metadata customizations and possibly implementing the structure)</span>
+ </li>
+ <li>
+ <span style="mso-bidi-font-size: 10.0pt">Developing the processes around repository management, rule life-cycle,
+ rule set life-cycle, rule governance</span>
+ </li>
+ <li>
+ <span style="mso-bidi-font-size: 10.0pt">Coordinating with application developers on system design, implementation
+ and testing</span>
+ </li>
+ <li>
+ <span
+ style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Acting
+ as a liaison between business and IT</span>
+ </li>
</ul></mainDescription>
<skills><p>
<span lang="EN-GB"
diff --git a/epf_prac_151/core.default.role_def.base/roles/rule_writer.xmi b/epf_prac_151/core.default.role_def.base/roles/rule_writer.xmi
index 45511c6..8363596 100644
--- a/epf_prac_151/core.default.role_def.base/roles/rule_writer.xmi
+++ b/epf_prac_151/core.default.role_def.base/roles/rule_writer.xmi
@@ -1,23 +1,23 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:RoleDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-E4OgmOwmF5GP2780rq8BoQ" name=",_u9BRADMwEdubIsnqJvPspQ" guid="-E4OgmOwmF5GP2780rq8BoQ" authors="Jerome Boyer" changeDate="2008-09-03T03:18:43.000-0700" version="1.0.0">
- <mainDescription><a id="XE_rule_writer" name="XE_rule_writer"></a><a id="1036295" name="1036295">In a business environment, business
-policies are ultimately implemented as part of critical business applications as executable rules.&nbsp;Rule
-Writers&nbsp;are experts in business logic and&nbsp;manage executable business rules within an organization. Rule Writers
-are responsible for writing and/or enforcing the business policies of a given enterprise.</a> <a id="1036296"
-name="1036296"></a>
-<p class="Body">
- In a BRMS rule writers participate in the initial process of extracting business rules from existing policy (documents,
- databases, code, SME, etc.). This process, referred to as rule harvesting, is carried out with the business analyst
- whose aim is to determine the vocabulary elements that are necessary to be able to write the rules that implement the
- policy.
-</p>
-<p class="Body">
- During the rule set development life cycle the Rule Writer will use different authoring environments: he uses
- an&nbsp;Integrated Development Environment like&nbsp;Eclipse IDE to develop the structure of the rules set, the
- executable flow of&nbsp;rules, the technical rules, and he can test the execution of the rules in this environment.
- Once the rule set is mature enough Rule Writer will use a web based BRMS platform. The advantage of the web based for
- rule authoring is the ubiquitous access, and the use of wizards to guide the&nbsp;management of the rules and the rule
- sets.
+ <mainDescription><a id="XE_rule_writer" name="XE_rule_writer"></a><a id="1036295" name="1036295">In a business environment, business
+policies are ultimately implemented as part of critical business applications as executable rules.&nbsp;Rule
+Writers&nbsp;are experts in business logic and&nbsp;manage executable business rules within an organization. Rule Writers
+are responsible for writing and/or enforcing the business policies of a given enterprise.</a> <a id="1036296"
+name="1036296"></a> 
+<p class="Body">
+ In a BRMS rule writers participate in the initial process of extracting business rules from existing policy (documents,
+ databases, code, SME, etc.). This process, referred to as rule harvesting, is carried out with the business analyst
+ whose aim is to determine the vocabulary elements that are necessary to be able to write the rules that implement the
+ policy.
+</p>
+<p class="Body">
+ During the rule set development life cycle the Rule Writer will use different authoring environments: he uses
+ an&nbsp;Integrated Development Environment like&nbsp;Eclipse IDE to develop the structure of the rules set, the
+ executable flow of&nbsp;rules, the technical rules, and he can test the execution of the rules in this environment.
+ Once the rule set is mature enough Rule Writer will use a web based BRMS platform. The advantage of the web based for
+ rule authoring is the ubiquitous access, and the use of wizards to guide the&nbsp;management of the rules and the rule
+ sets.
</p></mainDescription>
<skills><p>
Rule Based programming
diff --git a/epf_prac_151/core.default.role_def.base/roles/subject_matter_expert.xmi b/epf_prac_151/core.default.role_def.base/roles/subject_matter_expert.xmi
index ca74bf3..1236a79 100644
--- a/epf_prac_151/core.default.role_def.base/roles/subject_matter_expert.xmi
+++ b/epf_prac_151/core.default.role_def.base/roles/subject_matter_expert.xmi
@@ -1,74 +1,74 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:RoleDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="--6iEQW4eBPeK20vzxlDBMQ" name="subject_matter_expert,_e5BXwBtcEdu_BZ3CL1I6hw" guid="--6iEQW4eBPeK20vzxlDBMQ" authors="Jerome Boyer" changeDate="2010-04-01T03:41:39.000-0700" version="1.0.0">
- <mainDescription><a id="XE_subject_matter_expert" name="XE_subject_matter_expert"></a><a id="XE_SME" name="XE_SME"></a>
-<p class="MsoNormal" style="MARGIN: 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt">
- The SME has the following responsibilities:
-</p>
-<ul>
- <li>
- <div class="MsoNormal" style="MARGIN: 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt">
- Support the definition of business processes
- </div>
- </li>
- <li>
- <div class="MsoNormal" style="MARGIN: 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt">
- Determine and support the implementation of a business policy, generally by providing
- </div>
- <ul>
- <li>
- <div class="MsoNormal" style="MARGIN: 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt">
- the contents for the business rules that enforce the policy and
- </div>
- </li>
- <li>
- <div class="MsoNormal" style="MARGIN: 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt">
- the process contexts in which the rules are applied.
- </div>
- </li>
- </ul>
- </li>
- <li>
- <div class="MsoNormal" style="MARGIN: 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt">
- Oversee the execution of that policy via business rules applied. Such oversight includes confirming that the
- implemented rules fully and faithfully correspond to the intended policy.
- </div>
- </li>
- <li>
- <div class="MsoNormal" style="MARGIN: 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt">
- Once Rule Writers have created the first set of rules, the SME reviews the rules, and the rule flow to give
- feedbacks on the logic and pattern used.
- </div>
- </li>
- <li>
- <div class="MsoNormal" style="MARGIN: 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt">
- Review the results of testing and simulation
- </div>
- </li>
- <li>
- <div class="MsoNormal" style="MARGIN: 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt">
- Manage business vocabulary
- </div>
- </li>
- <li>
- <div class="MsoNormal" style="MARGIN: 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt">
- Resolve business issues relating to business rule execution.
- </div>
- </li>
- <li>
- <div class="MsoNormal" style="MARGIN: 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt">
- Be accountable for the quality of the business rule
- </div>
- </li>
- <li>
- <div class="MsoNormal" style="MARGIN: 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt">
- Approve major changes to business rule
- </div>
- </li>
-</ul>
-<p class="MsoNormal" style="MARGIN: 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt">
- In term of skill and competencies,&nbsp;the&nbsp;Subject matter Expert&nbsp;has a strong business knowledge and
- experience, some management skill, effective communication, leadership, decision making skills.
+ <mainDescription><a id="XE_subject_matter_expert" name="XE_subject_matter_expert"></a><a id="XE_SME" name="XE_SME"></a> 
+<p class="MsoNormal" style="MARGIN: 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt">
+ The SME has the following responsibilities:
+</p>
+<ul>
+ <li>
+ <div class="MsoNormal" style="MARGIN: 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt">
+ Support the definition of business processes
+ </div>
+ </li>
+ <li>
+ <div class="MsoNormal" style="MARGIN: 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt">
+ Determine and support the implementation of a business policy, generally by providing the following:
+ </div>
+ <ul>
+ <li>
+ <div class="MsoNormal" style="MARGIN: 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt">
+ the contents for the business rules that enforce the policy;
+ </div>
+ </li>
+ <li>
+ <div class="MsoNormal" style="MARGIN: 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt">
+ the process contexts in which the rules are applied.
+ </div>
+ </li>
+ </ul>
+ </li>
+ <li>
+ <div class="MsoNormal" style="MARGIN: 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt">
+ Oversee the execution of that policy via business rules applied. Such oversight includes confirming that the
+ implemented rules fully and faithfully correspond to the intended policy.
+ </div>
+ </li>
+ <li>
+ <div class="MsoNormal" style="MARGIN: 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt">
+ Once Rule Writers have created the first set of rules, the SME reviews the rules, and the rule flow to give
+ feedbacks on the logic and pattern used.
+ </div>
+ </li>
+ <li>
+ <div class="MsoNormal" style="MARGIN: 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt">
+ Review the results of testing and simulation
+ </div>
+ </li>
+ <li>
+ <div class="MsoNormal" style="MARGIN: 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt">
+ Manage business vocabulary
+ </div>
+ </li>
+ <li>
+ <div class="MsoNormal" style="MARGIN: 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt">
+ Resolve business issues relating to business rule execution.
+ </div>
+ </li>
+ <li>
+ <div class="MsoNormal" style="MARGIN: 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt">
+ Be accountable for the quality of the business rule
+ </div>
+ </li>
+ <li>
+ <div class="MsoNormal" style="MARGIN: 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt">
+ Approve major changes to business rule
+ </div>
+ </li>
+</ul>
+<p class="MsoNormal" style="MARGIN: 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt">
+ In term of skill and competencies,&nbsp;the&nbsp;Subject matter Expert&nbsp;has a strong business knowledge and
+ experience, some management skill, effective communication, leadership, decision making skills.
</p></mainDescription>
- <keyConsiderations>In ABRD the SME&nbsp;is not responsible as a primary owner, of any task. He is more a source of knowledge to transfer into
+ <keyConsiderations>In ABRD the SME&nbsp;is not responsible as a primary owner, of any task. He is more a source of knowledge to transfer into
the rule base system.</keyConsiderations>
</org.eclipse.epf.uma:RoleDescription>
diff --git a/epf_prac_151/core.default.role_def.base/roles/tester.xmi b/epf_prac_151/core.default.role_def.base/roles/tester.xmi
index 1047c2b..76a6090 100644
--- a/epf_prac_151/core.default.role_def.base/roles/tester.xmi
+++ b/epf_prac_151/core.default.role_def.base/roles/tester.xmi
@@ -1,54 +1,88 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:RoleDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_NqYIcKeqEdmKDbQuyzCoqQ" name="tester,_0ZM4MclgEdmt3adZL5Dmdw" guid="_NqYIcKeqEdmKDbQuyzCoqQ" changeDate="2009-07-29T11:36:50.000-0700" version="1.0.0">
- <mainDescription><p> The person in this role is primarily responsible for the following&nbsp;tasks:
-</p>
-<ul>
- <li> Identifying the tests&nbsp;that need to&nbsp;be performed </li>
- <li> Identifying the most appropriate implementation approach for a given test
- </li>
- <li> Implementing individual tests </li>
- <li> Setting up and running the tests </li>
- <li> Logging outcomes and verifying that the tests have been run </li>
- <li> Analyzing and guiding the recovery from execution errors </li>
- <li> Communicating test results to the team </li>
-</ul></mainDescription>
- <skills><p> A person&nbsp;filling the&nbsp;this role should have these skills: </p>
-<ul>
- <li> Knowledge of testing approaches and techniques </li>
- <li> Diagnostic and problem-solving skills </li>
- <li> Knowledge of the system or application being tested (desirable) </li>
- <li> Knowledge of networking and system architecture (desirable) </li>
-</ul>
-<p> Where automated testing is required, consider requiring these additional qualifications: 
+ <mainDescription><p>
+ The person in this role is primarily responsible for the following&nbsp;tasks:
</p>
<ul>
- <li> Training in the appropriate use of test automation tools </li>
- <li> Experience using test automation tools </li>
- <li> Programming skills </li>
- <li> Debugging and diagnostic skills </li>
+ <li>
+ Identifying the tests&nbsp;that need to&nbsp;be performed
+ </li>
+ <li>
+ Identifying the most appropriate implementation approach for a given test
+ </li>
+ <li>
+ Implementing individual tests
+ </li>
+ <li>
+ Setting up and running the tests
+ </li>
+ <li>
+ Logging outcomes and verifying that the tests have been run
+ </li>
+ <li>
+ Analyzing and guiding the recovery from execution errors
+ </li>
+ <li>
+ Communicating test results to the team
+ </li>
+</ul></mainDescription>
+ <skills><p>
+ A person&nbsp;filling the&nbsp;this role should have these skills:
+</p>
+<ul>
+ <li>
+ Knowledge of testing approaches and techniques
+ </li>
+ <li>
+ Diagnostic and problem-solving skills
+ </li>
+ <li>
+ Knowledge of the system or application being tested (desirable)
+ </li>
+ <li>
+ Knowledge of networking and system architecture (desirable)
+ </li>
</ul>
-<p> <strong>Note:</strong> <br />
- Specific skill requirements vary depending on the type of testing that you are 
- conducting. For example, the skills needed to successfully use system load-testing 
- automation tools are different from those needed for the automation of system 
- functional testing. </p></skills>
- <assignmentApproaches><p>
- This role can be assigned in the following ways:
- </p>
- <ul>
- <li>
- Assign one or more testing staff members to perform this role. This is a fairly standard approach and is
- particularly suitable for small teams, as well as for teams of any size where the team is made up of an experienced
- group of testers of relatively equal skill levels.
- </li>
- <li>
- Assign one or more testing staff members to perform only this role.&nbsp;This works well in large teams. It is also
- useful to separate responsibilities when some of the testing staff has more test automation experience than other
- team members.
- </li>
- <li>
- Assign one (or more) team member who is already playing other role in the project to be responsible for the testing
- of some part of the system's capabilities.&nbsp;The team member must have the appropriate test skills.
- </li>
- </ul></assignmentApproaches>
+<p>
+ Where automated testing is required, consider requiring these additional qualifications:
+</p>
+<ul>
+ <li>
+ Training in the appropriate use of test automation tools
+ </li>
+ <li>
+ Experience using test automation tools
+ </li>
+ <li>
+ Programming skills
+ </li>
+ <li>
+ Debugging and diagnostic skills
+ </li>
+</ul>
+<p>
+ <strong>Note:</strong><br />
+ Specific skill requirements vary depending on the type of testing that you are conducting. For example, the skills
+ needed to successfully use system load-testing automation tools are different from those needed for the automation of
+ system functional testing.
+</p></skills>
+ <assignmentApproaches><p>
+ This role can be assigned in the following ways:
+</p>
+<ul>
+ <li>
+ Assign one or more testing staff members to perform this role. This is a fairly standard approach and is
+ particularly suitable for small teams, as well as for teams of any size where the team is made up of an experienced
+ group of testers of relatively equal skill levels.
+ </li>
+ <li>
+ Assign one or more testing staff members to perform only this role.&nbsp;This works well in large teams. It is also
+ useful to separate responsibilities when some of the testing staff has more test automation experience than other
+ team members.
+ </li>
+ <li>
+ Assign one (or more) team member who is already playing other role in the project to be responsible for the testing
+ of some part of the system's capabilities.&nbsp;The team member must have the appropriate test skills.
+ </li>
+</ul></assignmentApproaches>
</org.eclipse.epf.uma:RoleDescription>
diff --git a/epf_prac_151/core.default.role_def.base/rolesets/basic_role_set.xmi b/epf_prac_151/core.default.role_def.base/rolesets/basic_role_set.xmi
index 78b4c18..8fa0152 100644
--- a/epf_prac_151/core.default.role_def.base/rolesets/basic_role_set.xmi
+++ b/epf_prac_151/core.default.role_def.base/rolesets/basic_role_set.xmi
@@ -1,7 +1,9 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-xLl5B3qPPdk8LfLut7r8hQ" name="new_role_set,_FBekABAaEdyqb5chWQXsPQ" guid="-xLl5B3qPPdk8LfLut7r8hQ" changeDate="2007-06-01T01:28:48.000-0700" version="7.1.0">
- <mainDescription><p> This page allows you to navigate the published configuration from the perspective
- of <a class="elementLinkWithUserText" href="./../../core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html" guid="_yUefQNnmEdmO6L4XMImrsA">Roles</a>.
- You can see the roles that have been included and visit each role page to see
- its definition and relationships to other elements. </p></mainDescription>
+ <mainDescription><p>
+ This page allows you to navigate the published configuration from the perspective of <a class="elementLinkWithUserText"
+ href="./../../core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html"
+ guid="_yUefQNnmEdmO6L4XMImrsA">Roles</a>. You can see the roles that have been included and visit each role page to see
+ its definition and relationships to other elements.
+</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.tool_def.base/guidances/supportingmaterials/epf_resources.xmi b/epf_prac_151/core.default.tool_def.base/guidances/supportingmaterials/epf_resources.xmi
index ba533e5..d959feb 100644
--- a/epf_prac_151/core.default.tool_def.base/guidances/supportingmaterials/epf_resources.xmi
+++ b/epf_prac_151/core.default.tool_def.base/guidances/supportingmaterials/epf_resources.xmi
@@ -1,23 +1,27 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-_R0yxogmlMQUIc_dSzfpUA" name="new_supporting_material,_C2FS4F_lEd2zpKtX6B7lBg" guid="-_R0yxogmlMQUIc_dSzfpUA" changeDate="2008-09-18T00:21:11.000-0700" version="7.5.0">
- <mainDescription><p>
- To learn more about the Eclipse Process Framework (EPF) Project, read Per Kroll's article, <a href="http://www.ibm.com/developerworks/rational/library/05/1011_kroll/index.html">The Eclipse Process Framework
- project</a> (IBM&reg; developerWorks&reg;, November 2005)
-</p>
-<p>
- For more information on EPF Composer, see the following:
-</p>
-<ul>
- <li>
- <a href="http://www.ibm.com/developerworks/rational/library/dec05/haumer/">IBM Rational Method Composer: Part 1:
- Key concepts</a> by Peter Haumer (IBM developerWorks, December 2005)
- </li>
- <li>
- EPF Composer Overview, <a href="http://www.eclipse.org/epf/general/EPFComposerOverviewPart1.pdf" target="_blank">Part 1</a> and <a href="http://www.eclipse.org/epf/general/EPFComposerOverviewPart2.pdf" target="_blank">Part 2</a> .&nbsp;&nbsp;(<a href="http://get.adobe.com/reader/">Get Adobe Reader</a>)
- </li>
- <li>
- For an in-depth explanation of the metamodel on which EPF Composer is based, see OMG: <a href="http://www.omg.org/technology/documents/formal/spem.htm" target="_blank">Software Process Engineering
- Meta-Model,</a> Version 2.0, 2008.<br />
- </li>
+ <mainDescription><p>
+ To learn more about the Eclipse Process Framework (EPF), read Per Kroll's article, <a
+ href="http://www.ibm.com/developerworks/rational/library/05/1011_kroll/index.html">The Eclipse Process Framework
+ project</a> (IBM&reg; developerWorks&reg;, November 2005)
+</p>
+<p>
+ For more information on EPF Composer, see the following:
+</p>
+<ul>
+ <li>
+ <a href="http://www.ibm.com/developerworks/rational/library/dec05/haumer/">IBM Rational Method Composer: Part 1:
+ Key concepts</a> by Peter Haumer (IBM developerWorks, December 2005)
+ </li>
+ <li>
+ EPF Composer Overview, <a href="http://www.eclipse.org/epf/general/EPFComposerOverviewPart1.pdf"
+ target="_blank">Part 1</a> and <a href="http://www.eclipse.org/epf/general/EPFComposerOverviewPart2.pdf"
+ target="_blank">Part 2</a> .&nbsp;&nbsp;(<a href="http://get.adobe.com/reader/">Get Adobe Reader</a>)
+ </li>
+ <li>
+ For an in-depth explanation of the metamodel on which EPF Composer is based, see OMG: <a
+ href="http://www.omg.org/technology/documents/formal/spem.htm" target="_blank">Software Process Engineering
+ Meta-Model,</a> Version 2.0, 2008.<br />
+ </li>
</ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.tool_def.base/guidances/supportingmaterials/rational_method_composer_resources.xmi b/epf_prac_151/core.default.tool_def.base/guidances/supportingmaterials/rational_method_composer_resources.xmi
index 1ec0c45..e696c39 100644
--- a/epf_prac_151/core.default.tool_def.base/guidances/supportingmaterials/rational_method_composer_resources.xmi
+++ b/epf_prac_151/core.default.tool_def.base/guidances/supportingmaterials/rational_method_composer_resources.xmi
@@ -1,12 +1,16 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-SQ05xBXUt6AVSHaSltVFuw" name="new_supporting_material,_dlGBQF_nEd2zpKtX6B7lBg" guid="-SQ05xBXUt6AVSHaSltVFuw" changeDate="2008-08-06T03:30:09.000-0700" version="7.5.0">
- <mainDescription><p> For more information on Rational Method Composer, see these sources: </p>
-<ul>
- <li> The <a href="http://www.ibm.com/software/awdtools/rmc">Rational Method
- Composer</a> product page on IBM developerWorks</li>
- <li> <a href="http://www.ibm.com/developerworks/rational/library/dec05/haumer/index.html%20">IBM
- Rational Method Composer: Part 1. Key concepts</a>, a developerWorks article
- by Peter Haumer (December 2005) <br />
- </li>
+ <mainDescription><p>
+ For more information on Rational Method Composer, see these sources:
+</p>
+<ul>
+ <li>
+ The <a href="http://www.ibm.com/software/awdtools/rmc">Rational Method Composer</a> product page on IBM
+ developerWorks
+ </li>
+ <li>
+ <a href="http://www.ibm.com/developerworks/rational/library/dec05/haumer/index.html%20">IBM Rational Method
+ Composer: Part 1. Key concepts</a>, a developerWorks article by Peter Haumer (December 2005)<br />
+ </li>
</ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.tool_def.base/guidances/supportingmaterials/resources_for_customizing_methods.xmi b/epf_prac_151/core.default.tool_def.base/guidances/supportingmaterials/resources_for_customizing_methods.xmi
index 3db6840..24363d5 100644
--- a/epf_prac_151/core.default.tool_def.base/guidances/supportingmaterials/resources_for_customizing_methods.xmi
+++ b/epf_prac_151/core.default.tool_def.base/guidances/supportingmaterials/resources_for_customizing_methods.xmi
@@ -1,92 +1,130 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-SqArASoV4hTpxAprrWhS1g" name="resources_for_customizing_methods,_omneEMX4EduywMSzPTUUwA" guid="-SqArASoV4hTpxAprrWhS1g" changeDate="2008-08-01T03:33:32.000-0700" version="7.2.0">
- <mainDescription><p> There are several use scenarios for <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/method_configuration_C2B8FA8A.html" guid="__V7pAMaEEduMlb2cQZNTYw">method configuration</a>s produced by using EPF Composer or Rational Method Composer
- (both referred to generically here as "Method Composer"). The simplest&nbsp;is
- to use the&nbsp;published content as-is (either using a prepublished Web site
- or by publishing one using the content that is included with Method Composer).&nbsp;However,
- you may be&nbsp;looking for&nbsp;how to add, remove, suppress, or modify <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/method_content_6972AE81.html" guid="_Ts2joB_MEdq6CKKKq4D7YA">method content</a>&nbsp;or <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/process_68E308B4.html" guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>&nbsp;elements,
- or both, to make an existing method configuration more&nbsp;suitable&nbsp;to
- your teams' needs, while keeping it consistent and understandable. </p>
-This guidance page describes typical customization scenarios and&nbsp;then provides
-references to additional information on how to customize methods.
-<h3> Customization scenarios </h3>
-<p> The following sections describe&nbsp;possible customization scenarios. For
- information on specific tool features, consult the Method Composer online Help.
- For&nbsp;additional information on customizing methods, see the Additional Resources
- section that follows here. </p>
-<h4> Use existing plug-ins and packages to build your own process </h4>
-<p> Some consider this the most straight-forward customization scenario. Based
- on the provided content, you can use Method Composer to pick and choose the
- packages with the content that you want to publish and make available to your
- team. Removing a method package removes all references to the content of that
- package from the published process. For example, you can simplify a process
- to have it contain a minimal subset of its content by removing packages that
- contain elements of work that you do not want to perform. You do this by creating
- a new method configuration (or copying an existing one) into your method library.
- You can select packages as appropriate without affecting the configuration provided.
-</p>
-<h4> Add&nbsp;method content&nbsp;that your team needs </h4>
-<p> Some teams may need to perform a different task that is not covered by the
- standard content. Maybe they need to perform an extra step in an existing task,
- or they may need to add a new guideline for a given technique that they are
- following. Eventually, they need a new template for a document (or they may
- need to add or remove sections in an existing template). </p>
-<p> In such situations, the recommended approach is to create a separate plug-in
- in your library.&nbsp;It is not a good practice&nbsp;to make changes in the
- provided plug-in (meaning any plug-in for which you do not have control), because
- new versions of these plug-ins, when deployed, can override the changes that
- you have made. </p>
-<p> Method Composer provides a series of mechanisms that allow you to indirectly
- modify the content in an existing plug-in by using <i>content variability</i>.
- In your plug-in, you can define an element that contributes, extends, or replaces
- an element in the existing plug-in. For example, in your plug-in, you can define
- a task that contributes a new step to an existing task. You can also define
- a new artifact that replaces an existing artifact, and this new artifact can
- have a different name, structure, and associated template, for example. Then
- all you need to do is make sure that the existing plug-in and your new plug-in
- are part of the configuration to be published. During publication, Method Composer
- will resolve the content variability that you defined by adding the new content
- into the existing content where appropriate, replacing existing content with
- the content you defined, and so on.&nbsp;&nbsp; </p>
-<h4> Define a different development lifecycle </h4>
-<p> Both method content and process are created independently from&nbsp;each other.
- For example, you create tasks in the method content (and define their&nbsp;inputs,
- outputs, and responsible roles), but you do not necessarily define the lifecycle
- of your process, meaning the sequence in which the various tasks will be performed.
- On the process side, you then define the lifecycle (such as phases, iterations,
- activities, and tasks), as well as the precedence among these elements. </p>
-<p> Some teams may find the method content appropriate without any further customization,
- but they may want to work by following a different software development lifecycle.
- For example, some teams may like the four development phases and iterations
- from the unified process, but some may want to develop iteratively, without
- being tied to a specific phase structure. Again, you can add, remove and replace
- elements in the work breakdown structure of an existing process by applying
- process variability. </p>
-<p> As an alternative to tailoring an existing process, you can write a completely
- new process that reuses activities from one or more existing processes. In cases
- where you cannot find any reusable material at all, you can also create a completely
- new process from scratch. In most cases, however, you will start developing
- your own process by assembling reusable building blocks from method content,
- as well as predefined process patterns&nbsp;called <a class="elementLinkWithUserText" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/capability_pattern_F5DDC5F.html" guid="_2RUJACO4EdqaNq6Ptg8uyA">capability
- patterns</a>. The resulting assembled process is called a&nbsp;<a class="elementLinkWithUserText" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/delivery_process_BCDF50B7.html" guid="_ZufeMCO3EdqaNq6Ptg8uyA">delivery
- process</a>. This newly created delivery process&nbsp;is part of a configuration
- that you publish and make available to members of your team. </p>
-<h4> Publish the process Web site </h4>
-<p> Every customization scenario is finalized by publishing content as HTML (on
- a Web site). Method Composer enables you to publish&nbsp;content based on a
- given configuration, which will publish all of the content available from the&nbsp;method
- and process packages selected in that configuration. Another option for publishing
- is to select only the capability patterns or delivery process of interest. This
- will make available only the content related to the process packages that you
- select. </p>
-<p> For the published Web site look and feel, you can customize the views and
- nodes in the directory (tree) browser by defining <a class="elementLinkWithUserText" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/custom_category_554AC4D6.html" guid="_eqw94MaFEduMlb2cQZNTYw">custom
- categories</a> that will be part of your configuration. </p>
-<h3> Additional resources&nbsp; </h3>
-<p> For more information on the fundamental concepts of method content and process,
- see <a class="elementLinkWithType" href="./../../../core.default.uma_concept.base/guidances/concepts/basic_process_concepts_C90EF089.html" guid="_FxJEkFUKEd2_rMtRMt_EMg">Concept: Basic Process Concepts</a>. </p>
-<p> For information on EPF Composer, see <a class="elementLink" href="./../../../core.default.tool_def.base/guidances/supportingmaterials/epf_resources_446F3946.html" guid="_C2FS4F_lEd2zpKtX6B7lBg">EPF Resources</a>. </p>
-<p> For information on Rational Method Composer, see <a class="elementLink" href="./../../../core.default.tool_def.base/guidances/supportingmaterials/rational_method_composer_resources_ADE2B192.html" guid="_dlGBQF_nEd2zpKtX6B7lBg">Rational Method Composer Resources</a>. </p>
-<p> For detailed customization scenarios, consult the tutorials included in the
- Method Composer online Help, as well the general authoring topics. </p></mainDescription>
+ <mainDescription><p>
+ There are several use scenarios for <a class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/method_configuration_C2B8FA8A.html"
+ guid="__V7pAMaEEduMlb2cQZNTYw">method configuration</a>s produced by using EPF Composer or Rational Method Composer
+ (both referred to generically here as "Method Composer"). The simplest&nbsp;is to use the&nbsp;published content as-is
+ (either using a prepublished Web site or by publishing one using the content that is included with Method
+ Composer).&nbsp;However, you may be&nbsp;looking for&nbsp;how to add, remove, suppress, or modify <a
+ class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/method_content_6972AE81.html"
+ guid="_Ts2joB_MEdq6CKKKq4D7YA">method content</a>&nbsp;or <a class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/process_68E308B4.html"
+ guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>&nbsp;elements, or both, to make an existing method configuration
+ more&nbsp;suitable&nbsp;to your teams' needs, while keeping it consistent and understandable.
+</p>This guidance page describes typical customization scenarios and&nbsp;then provides references to additional
+information on how to customize methods. 
+<h3>
+ Customization scenarios
+</h3>
+<p>
+ The following sections describe&nbsp;possible customization scenarios. For information on specific tool features,
+ consult the Method Composer online Help. For&nbsp;additional information on customizing methods, see the Additional
+ Resources section that follows here.
+</p>
+<h4>
+ Use existing plug-ins and packages to build your own process
+</h4>
+<p>
+ Some consider this the most straight-forward customization scenario. Based on the provided content, you can use Method
+ Composer to pick and choose the packages with the content that you want to publish and make available to your team.
+ Removing a method package removes all references to the content of that package from the published process. For
+ example, you can simplify a process to have it contain a minimal subset of its content by removing packages that
+ contain elements of work that you do not want to perform. You do this by creating a new method configuration (or
+ copying an existing one) into your method library. You can select packages as appropriate without affecting the
+ configuration provided.
+</p>
+<h4>
+ Add&nbsp;method content&nbsp;that your team needs
+</h4>
+<p>
+ Some teams may need to perform a different task that is not covered by the standard content. Maybe they need to perform
+ an extra step in an existing task, or they may need to add a new guideline for a given technique that they are
+ following. Eventually, they need a new template for a document (or they may need to add or remove sections in an
+ existing template).
+</p>
+<p>
+ In such situations, the recommended approach is to create a separate plug-in in your library.&nbsp;It is not a good
+ practice&nbsp;to make changes in the provided plug-in (meaning any plug-in for which you do not have control), because
+ new versions of these plug-ins, when deployed, can override the changes that you have made.
+</p>
+<p>
+ Method Composer provides a series of mechanisms that allow you to indirectly modify the content in an existing plug-in
+ by using <i>content variability</i>. In your plug-in, you can define an element that contributes, extends, or replaces
+ an element in the existing plug-in. For example, in your plug-in, you can define a task that contributes a new step to
+ an existing task. You can also define a new artifact that replaces an existing artifact, and this new artifact can have
+ a different name, structure, and associated template, for example. Then all you need to do is make sure that the
+ existing plug-in and your new plug-in are part of the configuration to be published. During publication, Method
+ Composer will resolve the content variability that you defined by adding the new content into the existing content
+ where appropriate, replacing existing content with the content you defined, and so on.&nbsp;&nbsp;
+</p>
+<h4>
+ Define a different development lifecycle
+</h4>
+<p>
+ Both method content and process are created independently from&nbsp;each other. For example, you create tasks in the
+ method content (and define their&nbsp;inputs, outputs, and responsible roles), but you do not necessarily define the
+ lifecycle of your process, meaning the sequence in which the various tasks will be performed. On the process side, you
+ then define the lifecycle (such as phases, iterations, activities, and tasks), as well as the precedence among these
+ elements.
+</p>
+<p>
+ Some teams may find the method content appropriate without any further customization, but they may want to work by
+ following a different software development lifecycle. For example, some teams may like the four development phases and
+ iterations from the unified process, but some may want to develop iteratively, without being tied to a specific phase
+ structure. Again, you can add, remove and replace elements in the work breakdown structure of an existing process by
+ applying process variability.
+</p>
+<p>
+ As an alternative to tailoring an existing process, you can write a completely new process that reuses activities from
+ one or more existing processes. In cases where you cannot find any reusable material at all, you can also create a
+ completely new process from scratch. In most cases, however, you will start developing your own process by assembling
+ reusable building blocks from method content, as well as predefined process patterns&nbsp;called <a
+ class="elementLinkWithUserText"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/capability_pattern_F5DDC5F.html"
+ guid="_2RUJACO4EdqaNq6Ptg8uyA">capability patterns</a>. The resulting assembled process is called a&nbsp;<a
+ class="elementLinkWithUserText"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/delivery_process_BCDF50B7.html"
+ guid="_ZufeMCO3EdqaNq6Ptg8uyA">delivery process</a>. This newly created delivery process&nbsp;is part of a
+ configuration that you publish and make available to members of your team.
+</p>
+<h4>
+ Publish the process Web site
+</h4>
+<p>
+ Every customization scenario is finalized by publishing content as HTML (on a Web site). Method Composer enables you to
+ publish&nbsp;content based on a given configuration, which will publish all of the content available from
+ the&nbsp;method and process packages selected in that configuration. Another option for publishing is to select only
+ the capability patterns or delivery process of interest. This will make available only the content related to the
+ process packages that you select.
+</p>
+<p>
+ For the published Web site look and feel, you can customize the views and nodes in the directory (tree) browser by
+ defining <a class="elementLinkWithUserText"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/custom_category_554AC4D6.html"
+ guid="_eqw94MaFEduMlb2cQZNTYw">custom categories</a> that will be part of your configuration.
+</p>
+<h3>
+ Additional resources&nbsp;
+</h3>
+<p>
+ For more information on the fundamental concepts of method content and process, see <a class="elementLinkWithType"
+ href="./../../../core.default.uma_concept.base/guidances/concepts/basic_process_concepts_C90EF089.html"
+ guid="_FxJEkFUKEd2_rMtRMt_EMg">Concept: Basic Process Concepts</a>.
+</p>
+<p>
+ For information on EPF Composer, see <a class="elementLink"
+ href="./../../../core.default.tool_def.base/guidances/supportingmaterials/epf_resources_446F3946.html"
+ guid="_C2FS4F_lEd2zpKtX6B7lBg">EPF Resources</a>.
+</p>
+<p>
+ For information on Rational Method Composer, see <a class="elementLink"
+ href="./../../../core.default.tool_def.base/guidances/supportingmaterials/rational_method_composer_resources_ADE2B192.html"
+ guid="_dlGBQF_nEd2zpKtX6B7lBg">Rational Method Composer Resources</a>.
+</p>
+<p>
+ For detailed customization scenarios, consult the tutorials included in the Method Composer online Help, as well the
+ general authoring topics.
+</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.tool_def.base/tools/method_composer_tool.xmi b/epf_prac_151/core.default.tool_def.base/tools/method_composer_tool.xmi
index b47a506..8138f09 100644
--- a/epf_prac_151/core.default.tool_def.base/tools/method_composer_tool.xmi
+++ b/epf_prac_151/core.default.tool_def.base/tools/method_composer_tool.xmi
@@ -1,25 +1,29 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-8L-j0rJzgDkBNd0igOyN0A" name="method_composer_tool,_mHQIMMYbEdyXeo04os5BOw" guid="-8L-j0rJzgDkBNd0igOyN0A" changeDate="2008-08-01T03:37:56.000-0700" version="7.5.0">
- <mainDescription><p>
- Method Composer is generic term that is used to apply to EPF Composer and its extensions, such as Rational (R) Method
- Composer.&nbsp; Method Composer has two purposes:
-</p>
-<p>
- 1. To provide a knowledge base of intellectual capital.&nbsp; This knowledge base can be used for reference and
- education.&nbsp; It can be used to communicate best practices across an organization in a consistent form.
-</p>
-<p>
- 2. To provide process engineering capabilities by supporting process engineers and project managers in selecting,
- tailoring, and rapidly assembling processes for different kinds of development projects. Method Composer provides
- catalogs of pre-defined processes for typical project situations that can be adapted to individual needs. It also
- provides process building blocks that represent best development practices for specific disciplines, technologies, or
- development styles. These building blocks form a toolkit for quickly assembling processes based on project specific
- needs. The resulting processes created with Method Composer can be published and deployed as Web sites.
-</p>
-<p>
- For more&nbsp;information on the Eclipse Process Framework (EPF) project and on EPF Composer, see <a class="elementLink" href="./../../core.default.tool_def.base/guidances/supportingmaterials/epf_resources_446F3946.html" guid="_C2FS4F_lEd2zpKtX6B7lBg">EPF Resources</a>
-</p>
-<p>
- For additional information on Rational Method Composer, see <a class="elementLink" href="./../../core.default.tool_def.base/guidances/supportingmaterials/rational_method_composer_resources_ADE2B192.html" guid="_dlGBQF_nEd2zpKtX6B7lBg">Rational Method Composer Resources</a>.
+ <mainDescription><p>
+ Method Composer is generic term that is used to apply to EPF Composer and its extensions, such as Rational (R) Method
+ Composer.&nbsp; Method Composer has two purposes:
+</p>
+<p>
+ 1. To provide a knowledge base of intellectual capital.&nbsp; This knowledge base can be used for reference and
+ education.&nbsp; It can be used to communicate best practices across an organization in a consistent form.
+</p>
+<p>
+ 2. To provide process engineering capabilities by supporting process engineers and project managers in selecting,
+ tailoring, and rapidly assembling processes for different kinds of development projects. Method Composer provides
+ catalogs of pre-defined processes for typical project situations that can be adapted to individual needs. It also
+ provides process building blocks that represent best development practices for specific disciplines, technologies, or
+ development styles. These building blocks form a toolkit for quickly assembling processes based on project specific
+ needs. The resulting processes created with Method Composer can be published and deployed as Web sites.
+</p>
+<p>
+ For more&nbsp;information on the Eclipse Process Framework (EPF) project and on EPF Composer, see <a
+ class="elementLink" href="./../../core.default.tool_def.base/guidances/supportingmaterials/epf_resources_446F3946.html"
+ guid="_C2FS4F_lEd2zpKtX6B7lBg">EPF Resources</a>
+</p>
+<p>
+ For additional information on Rational Method Composer, see <a class="elementLink"
+ href="./../../core.default.tool_def.base/guidances/supportingmaterials/rational_method_composer_resources_ADE2B192.html"
+ guid="_dlGBQF_nEd2zpKtX6B7lBg">Rational Method Composer Resources</a>.
</p><br /></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/concepts/basic_process_concepts.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/concepts/basic_process_concepts.xmi
index 37da1d1..46eba26 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/concepts/basic_process_concepts.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/concepts/basic_process_concepts.xmi
@@ -1,185 +1,194 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-xL8v-tHFI6eyHLEaZ4rblA" name="new_concept,_FxJEkFUKEd2_rMtRMt_EMg" guid="-xL8v-tHFI6eyHLEaZ4rblA" changeDate="2008-09-04T05:19:51.000-0700" version="7.5.0">
- <mainDescription><h3>
- The Basic Elements
-</h3>
-<p>
- The basic elements of a process website are:
-</p>
-<ul>
- <li>
- <strong>Work product</strong>: what is produced
- </li>
- <li>
- <strong>Task</strong>: how to perform the work
- </li>
- <li>
- <strong>Role</strong>: who performs the work
- </li>
- <li>
- <strong>Process</strong>: used to define work breakdown and workflow
- </li>
- <li>
- <strong>Guidance</strong>: templates, checklists, examples, guidelines, concepts, and so on.
- </li>
-</ul>
-<p>
- These "basic elements" are the building blocks from which processes are composed.
-</p>
-<h3>
- Organizing Elements
-</h3>
-<p>
- The basic elements are organized using the following elements.
-</p>
-<h4>
- Practice
-</h4>
-<p>
- A practice is a documented approach to solving one or several commonly occurring problems. Practices are intended as
- "chunks" of process for adoption, enablement, and configuration. Practices are built from the basic elements described
- above.
-</p>
-<h4>
- Configuration
-</h4>
-<p>
- From the end-user perspective, a configuration is a selection of method content to be published.&nbsp; Most
- configurations consist of a selection of practices plus some&nbsp;content to tie the practices together. The published
- configuration is often loosely referred to as a process website.
-</p>
-<h3>
- Details and Examples
-</h3>
-<p>
- The following provides more detail about the basic elements and provides some examples.
-</p>
-<h4>
- Work product
-</h4>
-<p>
- Work products may take various shapes or forms, such as:
-</p>
-<ul>
- <li>
- Documents, such as a Vision, or a Project Plan.
- </li>
- <li>
- A model, such as a Use-Case Model or a Design Model. These can contain model elements (sub-artifacts) such as
- Design Classes, Use Cases, and Design Subsystems.
- </li>
- <li>
- Databases, spreadsheets, and other information repositories.
- </li>
- <li>
- Source code and executables.
- </li>
-</ul>
-<p>
- Work products can be classified as "artifacts" if they are concrete things, "outcomes" if they are not concrete, and
- "deliverables" if they are a packaging of artifacts.
-</p>
-<h4>
- Role
-</h4>
-<p>
- A role defines the behavior and responsibilities of an individual, or a set of individuals working together as a team,
- within the context of a software engineering organization.<br />
- Note that roles are not individuals; instead, roles describe responsibilities. An individual will typically take on
- several roles at one time, and frequently will change roles over the duration of the project.
-</p>
-<p>
- Some examples:
-</p>
-<ul>
- <li>
- <strong>Analyst&nbsp;-</strong>&nbsp;Represents customers and end users, gathers input from stakeholders and
- defines requirements.
- </li>
- <li>
- <strong>Developer -</strong> Develops a part of the system, including designing, implementing, unit testing, and
- integrating.
- </li>
-</ul>
-<h4>
- Task
-</h4>
-<p>
- A task is work performed by a role. It is usually defined as a series of steps that involve creating or updating one or
- more work products.
-</p>
-<p>
- Some examples:
-</p>
-<ul>
- <li>
- <strong>Develop a vision -</strong> Develop an overall vision for the system, including capturing the problem to be
- solved, the key stakeholders, the scope and boundary of the system, the system's key features, and any constraints.
- </li>
- <li>
- <strong>Plan Iteration -</strong> Define the scope and responsibilities of a single iteration.
- </li>
-</ul><br />
-<h4>
- Process
-</h4>
-<p>
- Processes pull together tasks, work products, and roles, and add structure and sequencing information.&nbsp; Tasks or
- work products can be grouped into higher level activities, called a work breakdown structure
- (WBS).&nbsp;&nbsp;Activities or tasks can be marked as "planned" to identify work that you expect to assign and track.
-</p><br />
-<br />
-<center>
- <img alt="This is an example work breakdown structure, showing a hierarchy of activities with sub-activities and tasks." src="resources/wbs_example.jpg" align="center" />&nbsp;<br />
- Figure 1: Example Work Breakdown
-</center><br />
-<br />
-<p>
- Diagrams can be added to providing sequencing information.&nbsp; The following example shows an initial activity, "Plan
- Test Cycle", followed by two activities that go in parallel, "Monitor and Control Test" and "Test".
-</p><br />
-<br />
-<center>
- <img height="453" alt="Example UML activity diagram, showing a start, an initial activity, then two activities in parallel, and an end." src="resources/activity_diag_ex.jpg" width="566" align="center" /><br />
- Figure&nbsp;2: Example Activity Diagram
-</center><br />
-<br />
-<p>
- Note that a&nbsp;reusable partial process is sometimes referred to as a capability pattern.
-</p>
-<h3>
- For More Information
-</h3>
-<p>
- More in-depth material on these concepts is generally found in articles on EPF Composer and Rational(R) Method
- Composer, which use these concepts as building blocks.
-</p>
-<ul>
- <li>
- To learn more about the Eclipse Process Framework Project and EPF Composer,&nbsp;&nbsp;visit <a href="http://www.eclipse.org/epf">http://www.eclipse.org/epf</a>&nbsp;and <a href="http://www-128.ibm.com/developerworks/rational/library/05/1011_kroll/index.html">http://www-128.ibm.com/developerworks/rational/library/05/1011_kroll/index.html</a>
- </li>
- <li>
- For more information on Rational Method Composer, see:
- <ul>
- <li>
- The RMC Product Page on developer works <a href="http://www-306.ibm.com/software/awdtools/rmc/">http://www-306.ibm.com/software/awdtools/rmc/</a>
- </li>
- <li>
- Article: "IBM Rational Method Composer: Part 1: Key concepts" at <a href="http://www.ibm.com/developerworks/rational/library/dec05/haumer/index.html">http://www.ibm.com/developerworks/rational/library/dec05/haumer/index.html</a>
- </li>
- </ul>
- </li>
- <li>
- For an in-depth explanation of the meta-model on which EPF Composer and Rational Method Composer are based, see:
- </li>
- <li style="LIST-STYLE-TYPE: none">
- <ul>
- <li>
- OMG, "Software Process Engineering Meta model," version 1.1, formal/2005-01-06, 2005. <a href="http://www.omg.org/technology/documents/formal/spem.htm">http://www.omg.org/technology/documents/formal/spem.htm</a><br />
- <br />
- <br />
- </li>
- </ul>
- </li>
+ <mainDescription><h3>
+ The Basic Elements
+</h3>
+<p>
+ The basic elements of a process website are:
+</p>
+<ul>
+ <li>
+ <strong>Work product</strong>: what is produced
+ </li>
+ <li>
+ <strong>Task</strong>: how to perform the work
+ </li>
+ <li>
+ <strong>Role</strong>: who performs the work
+ </li>
+ <li>
+ <strong>Process</strong>: used to define work breakdown and workflow
+ </li>
+ <li>
+ <strong>Guidance</strong>: templates, checklists, examples, guidelines, concepts, and so on.
+ </li>
+</ul>
+<p>
+ These "basic elements" are the building blocks from which processes are composed.
+</p>
+<h3>
+ Organizing Elements
+</h3>
+<p>
+ The basic elements are organized using the following elements.
+</p>
+<h4>
+ Practice
+</h4>
+<p>
+ A practice is a documented approach to solving one or several commonly occurring problems. Practices are intended as
+ "chunks" of process for adoption, enablement, and configuration. Practices are built from the basic elements described
+ above.
+</p>
+<h4>
+ Configuration
+</h4>
+<p>
+ From the end-user perspective, a configuration is a selection of method content to be published.&nbsp; Most
+ configurations consist of a selection of practices plus some&nbsp;content to tie the practices together. The published
+ configuration is often loosely referred to as a process website.
+</p>
+<h3>
+ Details and Examples
+</h3>
+<p>
+ The following provides more detail about the basic elements and provides some examples.
+</p>
+<h4>
+ Work product
+</h4>
+<p>
+ Work products may take various shapes or forms, such as:
+</p>
+<ul>
+ <li>
+ Documents, such as a Vision, or a Project Plan.
+ </li>
+ <li>
+ A model, such as a Use-Case Model or a Design Model. These can contain model elements (sub-artifacts) such as
+ Design Classes, Use Cases, and Design Subsystems.
+ </li>
+ <li>
+ Databases, spreadsheets, and other information repositories.
+ </li>
+ <li>
+ Source code and executables.
+ </li>
+</ul>
+<p>
+ Work products can be classified as "artifacts" if they are concrete things, "outcomes" if they are not concrete, and
+ "deliverables" if they are a packaging of artifacts.
+</p>
+<h4>
+ Role
+</h4>
+<p>
+ A role defines the behavior and responsibilities of an individual, or a set of individuals working together as a team,
+ within the context of a software engineering organization.<br />
+ Note that roles are not individuals; instead, roles describe responsibilities. An individual will typically take on
+ several roles at one time, and frequently will change roles over the duration of the project.
+</p>
+<p>
+ Some examples:
+</p>
+<ul>
+ <li>
+ <strong>Analyst&nbsp;-</strong>&nbsp;Represents customers and end users, gathers input from stakeholders and
+ defines requirements.
+ </li>
+ <li>
+ <strong>Developer -</strong> Develops a part of the system, including designing, implementing, unit testing, and
+ integrating.
+ </li>
+</ul>
+<h4>
+ Task
+</h4>
+<p>
+ A task is work performed by a role. It is usually defined as a series of steps that involve creating or updating one or
+ more work products.
+</p>
+<p>
+ Some examples:
+</p>
+<ul>
+ <li>
+ <strong>Develop a vision -</strong> Develop an overall vision for the system, including capturing the problem to be
+ solved, the key stakeholders, the scope and boundary of the system, the system's key features, and any constraints.
+ </li>
+ <li>
+ <strong>Plan Iteration -</strong> Define the scope and responsibilities of a single iteration.
+ </li>
+</ul><br />
+<h4>
+ Process
+</h4>
+<p>
+ Processes pull together tasks, work products, and roles, and add structure and sequencing information.&nbsp; Tasks or
+ work products can be grouped into higher level activities, called a work breakdown structure
+ (WBS).&nbsp;&nbsp;Activities or tasks can be marked as "planned" to identify work that you expect to assign and track.
+</p><br />
+<br />
+<center>
+ <img
+ alt="This is an example work breakdown structure, showing a hierarchy of activities with sub-activities and tasks."
+ src="resources/wbs_example.jpg" align="center" />&nbsp;<br />
+ Figure 1: Example Work Breakdown
+</center><br />
+<br />
+<p>
+ Diagrams can be added to providing sequencing information.&nbsp; The following example shows an initial activity, "Plan
+ Test Cycle", followed by two activities that go in parallel, "Monitor and Control Test" and "Test".
+</p><br />
+<br />
+<center>
+ <img height="453"
+ alt="Example UML activity diagram, showing a start, an initial activity, then two activities in parallel, and an end."
+ src="resources/activity_diag_ex.jpg" width="566" align="center" /><br />
+ Figure&nbsp;2: Example Activity Diagram
+</center><br />
+<br />
+<p>
+ Note that a&nbsp;reusable partial process is sometimes referred to as a capability pattern.
+</p>
+<h3>
+ For More Information
+</h3>
+<p>
+ More in-depth material on these concepts is generally found in articles on EPF Composer and Rational(R) Method
+ Composer, which use these concepts as building blocks.
+</p>
+<ul>
+ <li>
+ To learn more about the Eclipse Process Framework Project and EPF Composer,&nbsp;&nbsp;visit <a
+ href="http://www.eclipse.org/epf">http://www.eclipse.org/epf</a>&nbsp;and <a
+ href="http://www-128.ibm.com/developerworks/rational/library/05/1011_kroll/index.html">http://www-128.ibm.com/developerworks/rational/library/05/1011_kroll/index.html</a>
+ </li>
+ <li>
+ For more information on Rational Method Composer, see: 
+ <ul>
+ <li>
+ The RMC Product Page on developer works <a
+ href="http://www-306.ibm.com/software/awdtools/rmc/">http://www-306.ibm.com/software/awdtools/rmc/</a>
+ </li>
+ <li>
+ Article: "IBM Rational Method Composer: Part 1: Key concepts" at <a
+ href="http://www.ibm.com/developerworks/rational/library/dec05/haumer/index.html">http://www.ibm.com/developerworks/rational/library/dec05/haumer/index.html</a>
+ </li>
+ </ul>
+ </li>
+ <li>
+ For an in-depth explanation of the meta-model on which EPF Composer and Rational Method Composer are based, see:
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <ul>
+ <li>
+ OMG, "Software Process Engineering Meta model," version 1.1, formal/2005-01-06, 2005. <a
+ href="http://www.omg.org/technology/documents/formal/spem.htm">http://www.omg.org/technology/documents/formal/spem.htm</a><br />
+ <br />
+ <br />
+ </li>
+ </ul>
+ </li>
</ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/concepts/practice.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/concepts/practice.xmi
index d2daf67..1ec8f42 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/concepts/practice.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/concepts/practice.xmi
@@ -1,78 +1,78 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-vY5HfUn9RSoqJC3J7QtxhA" name="new_concept,_qhCTAFRREd2CWscN8Mx6rg" guid="-vY5HfUn9RSoqJC3J7QtxhA" changeDate="2008-09-04T05:59:01.000-0700" version="7.5.0">
- <mainDescription><h3>
- Why Practices?
-</h3>
-<p>
- Practices enable a compositional approach to building methods. This approach offers the following benefits:
-</p>
-<ul>
- <li>
- Adaptability and scalability
- </li>
- <li>
- Incremental adoption
- </li>
- <li>
- Easy to configure and use
- </li>
- <li>
- Community development
- </li>
-</ul>
-<h3>
- Adaptability and Scalability
-</h3>
-<p>
- Practices can be adapted to&nbsp;support a range of solutions.&nbsp;In particular, practices can be adapted to suit
- your organization and supplemented by your own practices.
-</p>
-<p>
- The core practices are based on a common framework that allows them to be composed.&nbsp; These core practices&nbsp;are
- tool-agnostic, low-ceremony practices that can be extended to address a broad variety of development concerns, such as
- SOA, geographical distribution, model-driven architecture and embedded systems. Tool and technology specific guidance
- can be added, such as guidance on J2EE, and a variety of development tools. Some of these extensions can be quite
- modest, adding&nbsp;for example&nbsp;just tool specific guidance to existing tasks, while others can be comprehensive,
- defining processes that provide a radically expanded scope with new or altered artifacts, new or altered tasks, and new
- or altered roles.
-</p>
-<p>
- Extensions and additions to&nbsp;the practices&nbsp;can be:
-</p>
-<ul>
- <li>
- used internally by an organization
- </li>
- <li>
- open source as a part of the Eclipse Process Framework (EPF) project
- </li>
- <li>
- made freely available outside the open source licenses of Eclipse (EPL)
- </li>
- <li>
- sold commercially as an extension to the basic framework, such as the IBM(R) Practices.
- </li>
-</ul>
-<h3>
- Incremental Adoption
-</h3>
-<p>
- Each practice is described as a standalone capability that can be adopted by an organization or project.&nbsp;Each
- practice may include enablement materials that explain how to get started.&nbsp;&nbsp;
-</p>
-<h3>
- Easy to Configure and Use
-</h3>
-<p>
- Creating a method is as simple as selecting the practices that you wish to adopt, and then publishing the
- results.&nbsp;Each practice adds itself into the framework so that content can be viewed by practice, or across
- practices by work product, role, task and so on.
-</p>
-<h3>
- Community Development
-</h3>
-<p>
- Since a practice can be easily authored on its own, practices are ideal for community development.&nbsp;The basic agile
- practices for the&nbsp;EPF Practices are, in fact, developed by the Eclipse Process Framework community.&nbsp;
+ <mainDescription><h3>
+ Why Practices?
+</h3>
+<p>
+ Practices enable a compositional approach to building methods. This approach offers the following benefits:
+</p>
+<ul>
+ <li>
+ Adaptability and scalability
+ </li>
+ <li>
+ Incremental adoption
+ </li>
+ <li>
+ Easy to configure and use
+ </li>
+ <li>
+ Community development
+ </li>
+</ul>
+<h3>
+ Adaptability and Scalability
+</h3>
+<p>
+ Practices can be adapted to&nbsp;support a range of solutions.&nbsp;In particular, practices can be adapted to suit
+ your organization and supplemented by your own practices.
+</p>
+<p>
+ The core practices are based on a common framework that allows them to be composed.&nbsp; These core practices&nbsp;are
+ tool-agnostic, low-ceremony practices that can be extended to address a broad variety of development concerns, such as
+ SOA, geographical distribution, model-driven architecture and embedded systems. Tool and technology specific guidance
+ can be added, such as guidance on J2EE, and a variety of development tools. Some of these extensions can be quite
+ modest, adding&nbsp;for example&nbsp;just tool specific guidance to existing tasks, while others can be comprehensive,
+ defining processes that provide a radically expanded scope with new or altered artifacts, new or altered tasks, and new
+ or altered roles.
+</p>
+<p>
+ Extensions and additions to the practices can be the following:
+</p>
+<ul>
+ <li>
+ being used internally by an organization;
+ </li>
+ <li>
+ open source as a part of the Eclipse Process Framework (EPF) project;
+ </li>
+ <li>
+ made freely available outside the open source licenses of Eclipse (EPL);
+ </li>
+ <li>
+ sold commercially as an extension to the basic framework, such as the IBM(R) Practices.
+ </li>
+</ul>
+<h3>
+ Incremental Adoption
+</h3>
+<p>
+ Each practice is described as a standalone capability that can be adopted by an organization or project.&nbsp;Each
+ practice may include enablement materials that explain how to get started.&nbsp;&nbsp;
+</p>
+<h3>
+ Easy to Configure and Use
+</h3>
+<p>
+ Creating a method is as simple as selecting the practices that you wish to adopt, and then publishing the
+ results.&nbsp;Each practice adds itself into the framework so that content can be viewed by practice, or across
+ practices by work product, role, task and so on.
+</p>
+<h3>
+ Community Development
+</h3>
+<p>
+ Since a practice can be easily authored on its own, practices are ideal for community development.&nbsp;The basic agile
+ practices for the&nbsp;EPF Practices are, in fact, developed by the Eclipse Process Framework community.&nbsp;
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/activity.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/activity.xmi
index dd23c10..32a4c25 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/activity.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/activity.xmi
@@ -1,7 +1,15 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-67u6-WRUmTOB9IdLgQg6aw" name="activity,_yoVhMB_IEdq6CKKKq4D7YA" guid="-67u6-WRUmTOB9IdLgQg6aw" changeDate="2007-12-05T09:58:30.000-0800" version="1.0.0">
- <mainDescription><p>
- In the <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/uma_73BA0C0C.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>&nbsp;, an activity is a <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/breakdown_element_E6E32412.html" guid="_cvdpEB_LEdq6CKKKq4D7YA">breakdown element</a>&nbsp;which supports the nesting and logical grouping of related
- process elements such as <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/descriptor_D52B7BB3.html" guid="_7rS6AB_JEdq6CKKKq4D7YA">descriptor</a>&nbsp;and sub-activities, thus forming <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/breakdown_structure_C53514C1.html" guid="_95LCoB_QEdq6CKKKq4D7YA">breakdown structure</a>s.
+ <mainDescription><p>
+ In the <a class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/uma_73BA0C0C.html"
+ guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>&nbsp;, an activity is a <a class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/breakdown_element_E6E32412.html"
+ guid="_cvdpEB_LEdq6CKKKq4D7YA">breakdown element</a>&nbsp;which supports the nesting and logical grouping of related
+ process elements such as <a class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/descriptor_D52B7BB3.html"
+ guid="_7rS6AB_JEdq6CKKKq4D7YA">descriptor</a>&nbsp;and sub-activities, thus forming <a class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/breakdown_structure_C53514C1.html"
+ guid="_95LCoB_QEdq6CKKKq4D7YA">breakdown structure</a>s.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/activity_detail_diagram.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/activity_detail_diagram.xmi
index 78b9441..2909894 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/activity_detail_diagram.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/activity_detail_diagram.xmi
@@ -1,6 +1,14 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_ycE8HdnmEdmO6L4XMImrsA" name="activity_detail_diagram,_ycE8HNnmEdmO6L4XMImrsA" guid="_ycE8HdnmEdmO6L4XMImrsA" changeDate="2006-09-28T01:40:16.000-0700" version="7.2.0">
- <mainDescription>Diagram depicting all the <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/breakdown_element_E6E32412.html" guid="_cvdpEB_LEdq6CKKKq4D7YA">breakdown element</a>s within the scope of the selected process element. This diagram also
-depicts input/output relationships between <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html" guid="_x459ktnmEdmO6L4XMImrsA">task</a>s,&nbsp;activities, and <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html" guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s;&nbsp;as well as responsibility relationships between <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html" guid="_yUefQNnmEdmO6L4XMImrsA">role</a>s and tasks. Activity detail diagrams are used to provide a complete summary of an
+ <mainDescription>Diagram depicting all the <a class="elementLink"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/breakdown_element_E6E32412.html"
+guid="_cvdpEB_LEdq6CKKKq4D7YA">breakdown element</a>s within the scope of the selected process element. This diagram also
+depicts input/output relationships between <a class="elementLink"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html"
+guid="_x459ktnmEdmO6L4XMImrsA">task</a>s,&nbsp;activities, and <a class="elementLink"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
+guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s;&nbsp;as well as responsibility relationships between <a
+class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html"
+guid="_yUefQNnmEdmO6L4XMImrsA">role</a>s and tasks. Activity detail diagrams are used to provide a complete summary of an
activity&nbsp;and thus&nbsp;improve their comprehensibility.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/artifact.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/artifact.xmi
index a8a4a87..098438b 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/artifact.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/artifact.xmi
@@ -1,5 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_x7cUNNnmEdmO6L4XMImrsA" name="artifact,_x7cUM9nmEdmO6L4XMImrsA" guid="_x7cUNNnmEdmO6L4XMImrsA" changeDate="2007-12-05T10:14:47.000-0800" version="7.2.0">
- <mainDescription>Artifacts are a specialized type of <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html" guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a> that represents tangible, non-trivial items that are consumed, produced, or
+ <mainDescription>Artifacts are a specialized type of <a class="elementLink"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
+guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a> that represents tangible, non-trivial items that are consumed, produced, or
modified by tasks. Artifacts may be composed of other artifacts and often serve as a basis for defining reusable assets.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/breakdown_element.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/breakdown_element.xmi
index f95a2e9..3823693 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/breakdown_element.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/breakdown_element.xmi
@@ -1,4 +1,8 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-7pbyO29v0VnsosWHabeZDQ" name="breakdown_element,_cvdpEB_LEdq6CKKKq4D7YA" guid="-7pbyO29v0VnsosWHabeZDQ" changeDate="2005-09-22T07:07:46.000-0700" version="7.2.0">
- <mainDescription>Any element modeled in <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/uma_73BA0C0C.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>&nbsp;that is part of <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/process_68E308B4.html" guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>&nbsp;structure.<!--EndFragment--></mainDescription>
+ <mainDescription>Any element modeled in <a class="elementLink"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/uma_73BA0C0C.html"
+guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>&nbsp;that is part of <a class="elementLink"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/process_68E308B4.html"
+guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>&nbsp;structure.<!--EndFragment--></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/breakdown_structure.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/breakdown_structure.xmi
index 7a2104a..e87253f 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/breakdown_structure.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/breakdown_structure.xmi
@@ -1,6 +1,11 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-dpUlq7kJXlJBUjvh7lHW7Q" name="breakdown_structure,_95LCoB_QEdq6CKKKq4D7YA" guid="-dpUlq7kJXlJBUjvh7lHW7Q" changeDate="2006-09-28T01:44:00.000-0700" version="7.2.0">
- <mainDescription><p>
- A <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/uma_73BA0C0C.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>&nbsp;construct that specifies a <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/process_68E308B4.html" guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>&nbsp;as the hierarchical composition of <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/breakdown_element_E6E32412.html" guid="_cvdpEB_LEdq6CKKKq4D7YA">breakdown element</a>s.
+ <mainDescription><p>
+ A <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/uma_73BA0C0C.html"
+ guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>&nbsp;construct that specifies a <a class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/process_68E308B4.html"
+ guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>&nbsp;as the hierarchical composition of <a class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/breakdown_element_E6E32412.html"
+ guid="_cvdpEB_LEdq6CKKKq4D7YA">breakdown element</a>s.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/capability_pattern.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/capability_pattern.xmi
index 608c3c5..5a95010 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/capability_pattern.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/capability_pattern.xmi
@@ -1,8 +1,10 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-AY7-wWpxUmZp4c-odX8e7g" name="capability_pattern,_2RUJACO4EdqaNq6Ptg8uyA" guid="-AY7-wWpxUmZp4c-odX8e7g" changeDate="2007-12-05T10:00:44.000-0800" version="1.0.0">
- <mainDescription><p>
- <!--StartFragment-->A&nbsp;special type of&nbsp;<a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/process_68E308B4.html" guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>&nbsp;used to define a stereotypical way of performing work related to a
- particular subject.&nbsp; Capability Patterns are often used as course grained building blocks to assemble delivery
- processes.<!--EndFragment-->
+ <mainDescription><p>
+ <!--StartFragment-->A&nbsp;special type of&nbsp;<a class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/process_68E308B4.html"
+ guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>&nbsp;used to define a stereotypical way of performing work related to a
+ particular subject.&nbsp; Capability Patterns are often used as course grained building blocks to assemble delivery
+ processes.<!--EndFragment-->
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/checklist.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/checklist.xmi
index d6e5177..658722d 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/checklist.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/checklist.xmi
@@ -1,5 +1,5 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-d9uOWrjeHbE_1Xu2RIs-0A" name="new_term_definition,_7vpJsMaCEduMlb2cQZNTYw" guid="-d9uOWrjeHbE_1Xu2RIs-0A" changeDate="2007-02-27T09:01:08.000-0800" version="7.2.0">
- <mainDescription>A specialized type of guidance that identifies a series of items that need to be completed or verified. Checklists are
+ <mainDescription>A specialized type of guidance that identifies a series of items that need to be completed or verified. Checklists are
often used in reviews such as walkthroughs or inspections.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/composite_role.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/composite_role.xmi
index 21b9e31..3939c88 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/composite_role.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/composite_role.xmi
@@ -1,5 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-KNw2PnSSEEogCvg4sj1ebg" name="new_term_definition,_PzL7EMaEEduMlb2cQZNTYw" guid="-KNw2PnSSEEogCvg4sj1ebg" changeDate="2007-02-27T09:02:53.000-0800" version="7.2.0">
- <mainDescription>A special role descriptor that relates to more than one <a class="elementLinkWithUserText" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html" guid="_yUefQNnmEdmO6L4XMImrsA">role</a>. It represents a grouping of roles with the main purpose of reducing the number of
+ <mainDescription>A special role descriptor that relates to more than one <a class="elementLinkWithUserText"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html"
+guid="_yUefQNnmEdmO6L4XMImrsA">role</a>. It represents a grouping of roles with the main purpose of reducing the number of
roles defined in method content for a process.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/concept.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/concept.xmi
index 14e9136..aac47d1 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/concept.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/concept.xmi
@@ -1,5 +1,5 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-5bvXXNVzF7mZf0R7Oez5_g" name="new_term_definition,_wMchYMaEEduMlb2cQZNTYw" guid="-5bvXXNVzF7mZf0R7Oez5_g" changeDate="2007-02-27T09:06:17.000-0800" version="7.2.0">
- <mainDescription>A specialized type of guidance that outlines key ideas or basic principles that serve as foundation for additional
+ <mainDescription>A specialized type of guidance that outlines key ideas or basic principles that serve as foundation for additional
information.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/custom_category.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/custom_category.xmi
index 3e38729..d9dd58b 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/custom_category.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/custom_category.xmi
@@ -1,4 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-G9dXZH2IkpWGi4NZK-2vEw" name="new_term_definition,_eqw94MaFEduMlb2cQZNTYw" guid="-G9dXZH2IkpWGi4NZK-2vEw" changeDate="2007-12-05T10:01:49.000-0800" version="7.2.0">
- <mainDescription>Used to categorize content based on the user's criteria. One important use is for constructing <a class="elementLinkWithUserText" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/view_953B6A0D.html" guid="_GH6WUMaJEduMlb2cQZNTYw">views</a>&nbsp;for publishing.</mainDescription>
+ <mainDescription>Used to categorize content based on the user's criteria. One important use is for constructing <a
+class="elementLinkWithUserText"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/view_953B6A0D.html"
+guid="_GH6WUMaJEduMlb2cQZNTYw">views</a>&nbsp;for publishing.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/deliverable.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/deliverable.xmi
index 0400d7b..bee8ea9 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/deliverable.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/deliverable.xmi
@@ -1,8 +1,8 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_yFbWodnmEdmO6L4XMImrsA" name="deliverable,_yFbWoNnmEdmO6L4XMImrsA" guid="_yFbWodnmEdmO6L4XMImrsA" changeDate="2007-12-05T10:02:02.000-0800" version="7.2.0">
- <mainDescription><p>
- A&nbsp;specialized type of work product&nbsp;used to define the primary outputs that represent value, material or
- otherwise,&nbsp;to the client, customer or other stakeholders.&nbsp; These are typically the result of packaging
- other&nbsp;work products for sign-off and delivery.
+ <mainDescription><p>
+ A&nbsp;specialized type of work product&nbsp;used to define the primary outputs that represent value, material or
+ otherwise,&nbsp;to the client, customer or other stakeholders.&nbsp; These are typically the result of packaging
+ other&nbsp;work products for sign-off and delivery.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/delivery_process.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/delivery_process.xmi
index 5eab38f..04b4c5d 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/delivery_process.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/delivery_process.xmi
@@ -1,6 +1,8 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-IsV3QdyMdwFlqznd4UAYhw" name="delivery_process,_ZufeMCO3EdqaNq6Ptg8uyA" guid="-IsV3QdyMdwFlqznd4UAYhw" changeDate="2007-12-05T10:02:37.000-0800" version="7.2.0">
- <mainDescription>A delivery process is a special <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/process_68E308B4.html" guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a> describing a complete and integrated approach for performing a specific project
-type. <!--StartFragment-->It provides a complete end-to-end lifecycle (for it's scope) and can be used as a reference for
+ <mainDescription>A delivery process is a special <a class="elementLink"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/process_68E308B4.html"
+guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a> describing a complete and integrated approach for performing a specific project
+type. <!--StartFragment-->It provides a complete end-to-end lifecycle (for it's scope) and can be used as a reference for
running projects with similar characteristics.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/descriptor.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/descriptor.xmi
index b1741f4..0ec3d85 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/descriptor.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/descriptor.xmi
@@ -1,6 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-TI6lqoTE1op3-SnmGa2S9Q" name="descriptor,_7rS6AB_JEdq6CKKKq4D7YA" guid="-TI6lqoTE1op3-SnmGa2S9Q" changeDate="2006-09-28T01:52:03.000-0700" version="7.2.0">
- <mainDescription>Defines how method content is represented in a process.&nbsp;&nbsp;Descriptors are the key concept for realizing the
-separation of process&nbsp;from method content.&nbsp;A&nbsp;descriptor&nbsp;has its own relationships and properties which
+ <mainDescription>Defines how method content is represented in a process.&nbsp;&nbsp;Descriptors are the key concept for realizing the
+separation of process&nbsp;from method content.&nbsp;A&nbsp;descriptor&nbsp;has its own relationships and properties which
can be modified independent of the default relationships&nbsp;defined in the method content.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/discipline.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/discipline.xmi
index 25e8b10..407bd8a 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/discipline.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/discipline.xmi
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_yGUuitnmEdmO6L4XMImrsA" name="discipline,_yGUuidnmEdmO6L4XMImrsA" guid="_yGUuitnmEdmO6L4XMImrsA" changeDate="2006-09-28T01:52:55.000-0700" version="7.2.0">
- <mainDescription><p>
- Primary categorization mechanism for organizing&nbsp;tasks that&nbsp;define&nbsp;a major 'area of concern' and/or
- cooperation of work effort.
+ <mainDescription><p>
+ Primary categorization mechanism for organizing&nbsp;tasks that&nbsp;define&nbsp;a major 'area of concern' and/or
+ cooperation of work effort.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/domain.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/domain.xmi
index 8d5ed7a..cfa0b2d 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/domain.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/domain.xmi
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_yHEVYtnmEdmO6L4XMImrsA" name="domain,_yHEVYdnmEdmO6L4XMImrsA" guid="_yHEVYtnmEdmO6L4XMImrsA" changeDate="2007-02-27T11:45:19.000-0800" version="7.2.0">
- <mainDescription><p>
- Primary categorization mechanism for organizing work products that have an affinity to each other based on resources,
- timing, relationships or general subject area.
+ <mainDescription><p>
+ Primary categorization mechanism for organizing work products that have an affinity to each other based on resources,
+ timing, relationships or general subject area.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/estimation_considerations.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/estimation_considerations.xmi
index 7ddb96d..6d5716b 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/estimation_considerations.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/estimation_considerations.xmi
@@ -1,5 +1,5 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-uIAjd6ptx9yCso_AZSbTUw" name="estimation_considerations,_cSEDoKNcEdyMFYhoCpD11Q" guid="-uIAjd6ptx9yCso_AZSbTUw" changeDate="2007-12-05T10:04:08.000-0800" version="7.2.0">
- <mainDescription>A specialized type&nbsp;of guidance&nbsp;that describes&nbsp;the amount of effort to produce a work product&nbsp;or perform
+ <mainDescription>A specialized type&nbsp;of guidance&nbsp;that describes&nbsp;the amount of effort to produce a work product&nbsp;or perform
a task&nbsp;including any influencing factors.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/example.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/example.xmi
index 1c9966b..c58a3c3 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/example.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/example.xmi
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-WGi50KpVG9oQbP82Xvk1UA" name="new_term_definition,_nE6fsMaFEduMlb2cQZNTYw" guid="-WGi50KpVG9oQbP82Xvk1UA" changeDate="2007-02-27T09:12:23.000-0800" version="7.2.0">
- <mainDescription><p>
- A specialized type&nbsp;of&nbsp; guidance&nbsp;used to include typical samples of the items to be produced, may often
- only be a partial sample that is intended as further guidance rather than something to be reused.
+ <mainDescription><p>
+ A specialized type&nbsp;of&nbsp; guidance&nbsp;used to include typical samples of the items to be produced, may often
+ only be a partial sample that is intended as further guidance rather than something to be reused.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/guidance.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/guidance.xmi
index 6ce6af9..e4a86bc 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/guidance.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/guidance.xmi
@@ -1,6 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-CTatxBir28UK-VwWwDij-g" name="guidance,_83ttAB_NEdq6CKKKq4D7YA" guid="-CTatxBir28UK-VwWwDij-g" changeDate="2007-12-05T10:04:49.000-0800" version="7.2.0">
- <mainDescription><p>
- General term referring to all types of material that provide additional detail on other types of elements.
+ <mainDescription><p>
+ General term referring to all types of material that provide additional detail on other types of elements.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/guideline.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/guideline.xmi
index 5d0b332..68a2c35 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/guideline.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/guideline.xmi
@@ -1,5 +1,14 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-EEF1Y386HZ1XRsyHmGLE3g" name="new_term_definition,_uK8HMMaFEduMlb2cQZNTYw" guid="-EEF1Y386HZ1XRsyHmGLE3g" changeDate="2008-07-31T01:27:36.000-0700" version="7.2.0">
- <mainDescription>A specialized type of&nbsp;<a class="elementLinkWithUserText" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html" guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;that provides additional detail on how to handle a particular <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/method_element_A8EA8685.html" guid="_4svVUO7bEdyYoPJ0YfnNbQ">method element</a>. Guidelines most commonly describe how to perform some set of actions
-related to&nbsp;<a class="elementLinkWithUserText" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html" guid="_x459ktnmEdmO6L4XMImrsA">tasks</a> or provide additional rules or recommendations related to the representation of <a class="elementLinkWithUserText" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html" guid="_H4JXwB_SEdq6CKKKq4D7YA">work products</a>.</mainDescription>
+ <mainDescription>A specialized type of&nbsp;<a class="elementLinkWithUserText"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;that provides additional detail on how to handle a particular <a
+class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/method_element_A8EA8685.html"
+guid="_4svVUO7bEdyYoPJ0YfnNbQ">method element</a>. Guidelines most commonly describe how to perform some set of actions
+related to&nbsp;<a class="elementLinkWithUserText"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html"
+guid="_x459ktnmEdmO6L4XMImrsA">tasks</a> or provide additional rules or recommendations related to the representation of <a
+class="elementLinkWithUserText"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
+guid="_H4JXwB_SEdq6CKKKq4D7YA">work products</a>.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/input.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/input.xmi
index 998962e..3eda6ea 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/input.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/input.xmi
@@ -1,7 +1,12 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_yK8IydnmEdmO6L4XMImrsA" name="input,_yK8IyNnmEdmO6L4XMImrsA" guid="_yK8IydnmEdmO6L4XMImrsA" changeDate="2007-12-05T10:05:45.000-0800" version="7.2.0">
- <mainDescription>In the <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/uma_73BA0C0C.html" guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>, input defines the&nbsp;<a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html" guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s needed to perform a <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html" guid="_x459ktnmEdmO6L4XMImrsA">task</a>.&nbsp; These inputs are further categorized as being optional, mandatory or
-external.&nbsp; Optional inputs may be excluded from the task in some cases without consequences, while without mandatory
-inputs it is typically not possible to complete the task.&nbsp; External inputs are used to defined mandatory inputs that
+ <mainDescription>In the <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/uma_73BA0C0C.html"
+guid="_cj6jkB_PEdq6CKKKq4D7YA">UMA</a>, input defines the&nbsp;<a class="elementLink"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
+guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s needed to perform a <a class="elementLink"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html"
+guid="_x459ktnmEdmO6L4XMImrsA">task</a>.&nbsp; These inputs are further categorized as being optional, mandatory or
+external.&nbsp; Optional inputs may be excluded from the task in some cases without consequences, while without mandatory
+inputs it is typically not possible to complete the task.&nbsp; External inputs are used to defined mandatory inputs that
are the result of work outside the scope of the defined process.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/iteration.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/iteration.xmi
index eee17bc..4188b8f 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/iteration.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/iteration.xmi
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-FxDDt6uNV4K2c04hoFKBpQ" name="new_term_definition,_5vWoEKNcEdyMFYhoCpD11Q" guid="-FxDDt6uNV4K2c04hoFKBpQ" changeDate="2008-05-08T00:41:45.000-0700" version="7.2.0">
- <mainDescription><p>
- A grouping of repeatable activities based on a set period of time&nbsp;that produces an expected set of results that
- has value.&nbsp; These results may be further refined in successive iterations.
+ <mainDescription><p>
+ A grouping of repeatable activities based on a set period of time&nbsp;that produces an expected set of results that
+ has value.&nbsp; These results may be further refined in successive iterations.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/method_architecture.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/method_architecture.xmi
index a2c8809..3874465 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/method_architecture.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/method_architecture.xmi
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-kbyERT7ThI5QD4X7GME9pQ" name="new_term_definition,_A6we0KNdEdyMFYhoCpD11Q" guid="-kbyERT7ThI5QD4X7GME9pQ" version="7.2.0">
- <mainDescription>A method architecture defines the concepts, their properties, and relationships for defining methods and processes. It is
-typically compromised of a meta-model, modeling language, or schema (synonyms) that is used for organizing large amounts of
-descriptions for management development methods and processes, such as software engineering, mechanical engineering,
+ <mainDescription>A method architecture defines the concepts, their properties, and relationships for defining methods and processes. It is
+typically compromised of a meta-model, modeling language, or schema (synonyms) that is used for organizing large amounts of
+descriptions for management development methods and processes, such as software engineering, mechanical engineering,
business transformation, sales cycles etc.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/method_configuration.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/method_configuration.xmi
index e56e88f..d878384 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/method_configuration.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/method_configuration.xmi
@@ -1,5 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-kzN6-iqn9zDtfnJc7IWkIg" name="new_term_definition,__V7pAMaEEduMlb2cQZNTYw" guid="-kzN6-iqn9zDtfnJc7IWkIg" changeDate="2007-12-05T10:09:22.000-0800" version="7.2.0">
- <mainDescription>A method configuration specifies the selection of a logical subset of a <a class="elementLinkWithUserText" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/method_library_6E08F9E5.html" guid="_1xELEMaFEduMlb2cQZNTYw">method library</a>, defined in terms of selected packages within plug-ins and any necessary
+ <mainDescription>A method configuration specifies the selection of a logical subset of a <a class="elementLinkWithUserText"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/method_library_6E08F9E5.html"
+guid="_1xELEMaFEduMlb2cQZNTYw">method library</a>, defined in terms of selected packages within plug-ins and any necessary
views.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/method_content.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/method_content.xmi
index 3994244..d1017c3 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/method_content.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/method_content.xmi
@@ -1,7 +1,15 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-akU0PqDaad4Ns5MQhVBJ7Q" name="method_content,_Ts2joB_MEdq6CKKKq4D7YA" guid="-akU0PqDaad4Ns5MQhVBJ7Q" changeDate="2007-12-05T10:10:15.000-0800" version="7.2.0">
- <mainDescription><p>
- Defines the primary reusable building blocks or reference materials of the method framework that exist outside of any
- predefined lifecycle.&nbsp;The basic content elements are: <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html" guid="_yUefQNnmEdmO6L4XMImrsA">role</a>s, <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html" guid="_x459ktnmEdmO6L4XMImrsA">task</a>s, <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html" guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s and <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html" guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>.
+ <mainDescription><p>
+ Defines the primary reusable building blocks or reference materials of the method framework that exist outside of any
+ predefined lifecycle.&nbsp;The basic content elements are: <a class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html"
+ guid="_yUefQNnmEdmO6L4XMImrsA">role</a>s, <a class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html"
+ guid="_x459ktnmEdmO6L4XMImrsA">task</a>s, <a class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
+ guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s and <a class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html"
+ guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/method_element.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/method_element.xmi
index 0951d80..4ded246 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/method_element.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/method_element.xmi
@@ -1,4 +1,8 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-iC-ATf6wJ3U7W6qqS_wJEg" name="new_term_definition,_4svVUO7bEdyYoPJ0YfnNbQ" guid="-iC-ATf6wJ3U7W6qqS_wJEg" changeDate="2008-03-10T00:58:16.000-0700" version="7.2.0">
- <mainDescription>There are two kinds of method element: &nbsp;<a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/method_content_6972AE81.html" guid="_Ts2joB_MEdq6CKKKq4D7YA">method content</a>&nbsp;and <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/process_68E308B4.html" guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>.</mainDescription>
+ <mainDescription>There are two kinds of method element: &nbsp;<a class="elementLink"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/method_content_6972AE81.html"
+guid="_Ts2joB_MEdq6CKKKq4D7YA">method content</a>&nbsp;and <a class="elementLink"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/process_68E308B4.html"
+guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/method_library.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/method_library.xmi
index 57819af..5e58412 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/method_library.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/method_library.xmi
@@ -1,4 +1,10 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-m6mx-VR4CReQNhrf4b8ykQ" name="new_term_definition,_1xELEMaFEduMlb2cQZNTYw" guid="-m6mx-VR4CReQNhrf4b8ykQ" changeDate="2008-03-10T00:59:48.000-0700" version="7.2.0">
- <mainDescription>A&nbsp;physical container for <a class="elementLinkWithUserText" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/method_plugin_190B9F5E.html" guid="_D4TLgMaGEduMlb2cQZNTYw">method plug-ins</a> and <a class="elementLinkWithUserText" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/method_configuration_C2B8FA8A.html" guid="__V7pAMaEEduMlb2cQZNTYw">method configuration</a> definitions. All&nbsp;<a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/method_element_A8EA8685.html" guid="_4svVUO7bEdyYoPJ0YfnNbQ">method element</a>s are stored in a method library.</mainDescription>
+ <mainDescription>A&nbsp;physical container for <a class="elementLinkWithUserText"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/method_plugin_190B9F5E.html"
+guid="_D4TLgMaGEduMlb2cQZNTYw">method plug-ins</a> and <a class="elementLinkWithUserText"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/method_configuration_C2B8FA8A.html"
+guid="__V7pAMaEEduMlb2cQZNTYw">method configuration</a> definitions. All&nbsp;<a class="elementLink"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/method_element_A8EA8685.html"
+guid="_4svVUO7bEdyYoPJ0YfnNbQ">method element</a>s are stored in a method library.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/method_plugin.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/method_plugin.xmi
index 5a5b442..ddcefb5 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/method_plugin.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/method_plugin.xmi
@@ -1,4 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-q0ixH8duU7qb8agEywAFHQ" name="new_term_definition,_D4TLgMaGEduMlb2cQZNTYw" guid="-q0ixH8duU7qb8agEywAFHQ" changeDate="2008-03-10T00:04:54.000-0700" version="7.2.0">
- <mainDescription>Represents a physical container for <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/method_element_A8EA8685.html" guid="_4svVUO7bEdyYoPJ0YfnNbQ">method element</a>s.</mainDescription>
+ <mainDescription>Represents a physical container for <a class="elementLink"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/method_element_A8EA8685.html"
+guid="_4svVUO7bEdyYoPJ0YfnNbQ">method element</a>s.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/outcome.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/outcome.xmi
index 5e490ac..75197d6 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/outcome.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/outcome.xmi
@@ -1,11 +1,11 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-SQyJsrOEI73uLZzjRVmSBA" name="outcome,_LNAAcB_iEdqAHrsQ7-jSbw" guid="-SQyJsrOEI73uLZzjRVmSBA" changeDate="2007-12-05T10:13:31.000-0800" version="7.2.0">
- <mainDescription><p>
- <!--StartFragment-->Specialized type of <a class="elementLink"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
- guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s used to describe intangible items such as the completion of some set
- of activities, a result or state. A key differentiator for outcomes against artifacts is that outcomes are not
- candidates for harvesting as reusable assets. Outcomes can not have associated templates or examples and are not
- possible to reuse as assets on other projects.
+ <mainDescription><p>
+ <!--StartFragment-->Specialized type of <a class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
+ guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s used to describe intangible items such as the completion of some set
+ of activities, a result or state. A key differentiator for outcomes against artifacts is that outcomes are not
+ candidates for harvesting as reusable assets. Outcomes can not have associated templates or examples and are not
+ possible to reuse as assets on other projects.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/output.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/output.xmi
index 12f18b6..38f4870 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/output.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/output.xmi
@@ -1,6 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_yPaZGtnmEdmO6L4XMImrsA" name="output,_yPaZGdnmEdmO6L4XMImrsA" guid="_yPaZGtnmEdmO6L4XMImrsA" changeDate="2007-12-05T10:14:15.000-0800" version="7.2.0">
- <mainDescription>Defines the results of performing some task in terms of the <a class="elementLink"
-href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
+ <mainDescription>Defines the results of performing some task in terms of the <a class="elementLink"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s produced or modified.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/performer.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/performer.xmi
index ddab6c0..6f1d77b 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/performer.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/performer.xmi
@@ -1,6 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-EF5eqKSqgTApRj_uXeG39w" name="new_term_definition,_GL2vkKNeEdyMFYhoCpD11Q" guid="-EF5eqKSqgTApRj_uXeG39w" version="7.2.0">
- <mainDescription>Describes the roles that will be executing a task.&nbsp; There are two types of performs roles, a single primary performer
-responsible for the completion of the tasks and additional performers.&nbsp; There may be any number of additional
+ <mainDescription>Describes the roles that will be executing a task.&nbsp; There are two types of performs roles, a single primary performer
+responsible for the completion of the tasks and additional performers.&nbsp; There may be any number of additional
performers and both are considered as allocated resources for the purposed of project scheduling.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/phase.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/phase.xmi
index 65ba1a1..d257ab0 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/phase.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/phase.xmi
@@ -1,8 +1,8 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-88Vj7cM5EcVnfesDYaAkww" name="new_term_definition,_K9eecMaGEduMlb2cQZNTYw" guid="-88Vj7cM5EcVnfesDYaAkww" changeDate="2007-12-05T10:15:10.000-0800" version="7.2.0">
- <mainDescription><p>
- A specialized type of activity&nbsp;that represents a significant period in a project normally ending with a decision
- checkpoint, major milestones, or a set of deliverables.&nbsp; Phases typically have well defined objectives and provide
- the basis for how the project work will be structured.
+ <mainDescription><p>
+ A specialized type of activity&nbsp;that represents a significant period in a project normally ending with a decision
+ checkpoint, major milestones, or a set of deliverables.&nbsp; Phases typically have well defined objectives and provide
+ the basis for how the project work will be structured.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/practice.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/practice.xmi
index 1ea2395..624c4dd 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/practice.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/practice.xmi
@@ -1,6 +1,8 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-kxtQBsUei9KRl8Z6tOSQ-g" name="new_term_definition,_wxYvkMaGEduMlb2cQZNTYw" guid="-kxtQBsUei9KRl8Z6tOSQ-g" changeDate="2007-12-05T10:15:29.000-0800" version="7.2.0">
- <mainDescription>A specialized type&nbsp;of&nbsp;<a class="elementLinkWithUserText" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html" guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a> that describes&nbsp;a proven way&nbsp;of doing something or common approaches
-and strategies that represent best practices.&nbsp; This is also used to&nbsp;represent standards and policies related to
+ <mainDescription>A specialized type&nbsp;of&nbsp;<a class="elementLinkWithUserText"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a> that describes&nbsp;a proven way&nbsp;of doing something or common approaches
+and strategies that represent best practices.&nbsp; This is also used to&nbsp;represent standards and policies related to
methods.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/process.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/process.xmi
index 129875e..8339a62 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/process.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/process.xmi
@@ -1,7 +1,11 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_yQ5m2dnmEdmO6L4XMImrsA" name="process,_yQ5m2NnmEdmO6L4XMImrsA" guid="_yQ5m2dnmEdmO6L4XMImrsA" changeDate="2008-03-11T10:40:20.000-0700" version="7.2.0">
- <mainDescription><p>
- Describes the assembly of method content&nbsp;in a sequence or workflow that defines how the work will be executed.
- There are two types of processes:&nbsp; <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/capability_pattern_F5DDC5F.html" guid="_2RUJACO4EdqaNq6Ptg8uyA">capability pattern</a>s and <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/delivery_process_BCDF50B7.html" guid="_ZufeMCO3EdqaNq6Ptg8uyA">delivery process</a>es.
+ <mainDescription><p>
+ Describes the assembly of method content&nbsp;in a sequence or workflow that defines how the work will be executed.
+ There are two types of processes:&nbsp; <a class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/capability_pattern_F5DDC5F.html"
+ guid="_2RUJACO4EdqaNq6Ptg8uyA">capability pattern</a>s and <a class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/delivery_process_BCDF50B7.html"
+ guid="_ZufeMCO3EdqaNq6Ptg8uyA">delivery process</a>es.
</p><!--EndFragment--><!--EndFragment--></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/report.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/report.xmi
index 2a3ab67..3d1d636 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/report.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/report.xmi
@@ -1,5 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-lEbg0SKqsikKdCRXPVvRmw" name="new_term_definition,_bDCXUMaHEduMlb2cQZNTYw" guid="-lEbg0SKqsikKdCRXPVvRmw" changeDate="2007-12-05T10:20:32.000-0800" version="7.2.0">
- <mainDescription>A&nbsp;specialized type&nbsp;of&nbsp;&nbsp;<a class="elementLinkWithUserText" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html" guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a> used to provide guidance on representing the output of an automated tool that
+ <mainDescription>A&nbsp;specialized type&nbsp;of&nbsp;&nbsp;<a class="elementLinkWithUserText"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a> used to provide guidance on representing the output of an automated tool that
may be a combination of information from one or more other work products. .</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/reusable_asset.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/reusable_asset.xmi
index bc4e550..3003acd 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/reusable_asset.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/reusable_asset.xmi
@@ -1,7 +1,9 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-H9RSfWhEhOJscNkDKGPcBA" name="new_term_definition,_kSKZUMaHEduMlb2cQZNTYw" guid="-H9RSfWhEhOJscNkDKGPcBA" changeDate="2007-12-05T10:20:56.000-0800" version="7.2.0">
- <mainDescription>A specialized type&nbsp;of <a class="elementLinkWithUserText" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html" guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a> linking to intellectual capital that can be utilized to perform some task or
-leveraged as a starting point for the creation of a solution.&nbsp; This type of guidance&nbsp;is usually represented a
-link to some external source.&nbsp; This may include assets such as source code, templates, patterns, architectural
+ <mainDescription>A specialized type&nbsp;of <a class="elementLinkWithUserText"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a> linking to intellectual capital that can be utilized to perform some task or
+leveraged as a starting point for the creation of a solution.&nbsp; This type of guidance&nbsp;is usually represented a
+link to some external source.&nbsp; This may include assets such as source code, templates, patterns, architectural
frameworks, domain models, and so on - that can be reused in a different contexts.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/roadmap.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/roadmap.xmi
index 4d7375a..53f6fca 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/roadmap.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/roadmap.xmi
@@ -1,5 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-gCtPvpHU3vmCQKQ1ymqBvw" name="new_term_definition,_19dWYMaHEduMlb2cQZNTYw" guid="-gCtPvpHU3vmCQKQ1ymqBvw" changeDate="2007-12-05T10:21:39.000-0800" version="7.2.0">
- <mainDescription>A specialized type&nbsp;of&nbsp;<a class="elementLinkWithUserText" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html" guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;that is specific to a process that represents a linear walkthrough of
+ <mainDescription>A specialized type&nbsp;of&nbsp;<a class="elementLinkWithUserText"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;that is specific to a process that represents a linear walkthrough of
those items from a particular perspective.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/role.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/role.xmi
index 3e88741..76c3ed8 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/role.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/role.xmi
@@ -1,9 +1,9 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_yUefQdnmEdmO6L4XMImrsA" name="role,_yUefQNnmEdmO6L4XMImrsA" guid="_yUefQdnmEdmO6L4XMImrsA" changeDate="2008-01-08T04:58:05.000-0800" version="1.0.0">
- <mainDescription><p>
- Describes a standard set of responsibilities and corresponding skills necessary to perform a task&nbsp;or create a work
- product.&nbsp; A Role is <strong>not</strong> a job description the same person may execute several roles
- simultaneously or during the course of a project and a role may likewise be defined to represent a group such as a
- review board.
+ <mainDescription><p>
+ Describes a standard set of responsibilities and corresponding skills necessary to perform a task&nbsp;or create a work
+ product.&nbsp; A Role is <strong>not</strong> a job description the same person may execute several roles
+ simultaneously or during the course of a project and a role may likewise be defined to represent a group such as a
+ review board.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/role_set.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/role_set.xmi
index ffff48a..894442b 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/role_set.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/role_set.xmi
@@ -1,4 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-gOXu6EqfZHMmtekNk8IDqA" name="new_term_definition,_Fs8HAMaIEduMlb2cQZNTYw" guid="-gOXu6EqfZHMmtekNk8IDqA" changeDate="2007-12-05T10:22:19.000-0800" version="7.2.0">
- <mainDescription>A specialized type of category used to organize <a class="elementLinkWithUserText" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html" guid="_yUefQNnmEdmO6L4XMImrsA">roles</a> by certain commonalities such as type of work, profession or area of knowledge.</mainDescription>
+ <mainDescription>A specialized type of category used to organize <a class="elementLinkWithUserText"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html"
+guid="_yUefQNnmEdmO6L4XMImrsA">roles</a> by certain commonalities such as type of work, profession or area of knowledge.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/step.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/step.xmi
index c9e3f02..0ba7299 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/step.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/step.xmi
@@ -1,5 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-KfXoeGTRnQImE1byTBtryQ" name="step,_BqZloB_eEdqAHrsQ7-jSbw" guid="-KfXoeGTRnQImE1byTBtryQ" changeDate="2007-12-05T10:23:34.000-0800" version="7.2.0">
- <mainDescription>Sub-section of a <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html" guid="_x459ktnmEdmO6L4XMImrsA">task</a>&nbsp;used to organize the work to be performed to achieve the overall goal of the
+ <mainDescription>Sub-section of a <a class="elementLink"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html"
+guid="_x459ktnmEdmO6L4XMImrsA">task</a>&nbsp;used to organize the work to be performed to achieve the overall goal of the
task. Not all Steps are necessarily performed each time a task is executed in a process.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/supporting_material.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/supporting_material.xmi
index 30f39ab..2febffd 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/supporting_material.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/supporting_material.xmi
@@ -1,5 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-_-iQ4eQyiQVM7YhXcb90-g" name="new_term_definition,_SwvUgMaIEduMlb2cQZNTYw" guid="-_-iQ4eQyiQVM7YhXcb90-g" changeDate="2007-02-27T09:33:31.000-0800" version="7.2.0">
- <mainDescription>A&nbsp;<a class="elementLinkWithUserText" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html" guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;that is a catch-all for other types of guidance not specifically defined
+ <mainDescription>A&nbsp;<a class="elementLinkWithUserText"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;that is a catch-all for other types of guidance not specifically defined
elsewhere.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/task.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/task.xmi
index a03b31f..83ad214 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/task.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/task.xmi
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_x459k9nmEdmO6L4XMImrsA" name="task,_x459ktnmEdmO6L4XMImrsA" guid="_x459k9nmEdmO6L4XMImrsA" changeDate="2005-08-11T09:05:04.000-0700" version="7.2.0">
- <mainDescription><p>
- Defines a unit of work that needs to be done in order to&nbsp;transform inputs into outputs through a series&nbsp;of
- steps&nbsp;performed by one or more roles&nbsp;independent of a particular work breakdown structure (WBS).
+ <mainDescription><p>
+ Defines a unit of work that needs to be done in order to&nbsp;transform inputs into outputs through a series&nbsp;of
+ steps&nbsp;performed by one or more roles&nbsp;independent of a particular work breakdown structure (WBS).
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/team_profile.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/team_profile.xmi
index d92c760..0801e90 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/team_profile.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/team_profile.xmi
@@ -1,5 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-0cxbeJahkc1eqGKztRpcPw" name="new_term_definition,_rZOGIMaIEduMlb2cQZNTYw" guid="-0cxbeJahkc1eqGKztRpcPw" changeDate="2007-02-27T09:34:15.000-0800" version="7.2.0">
- <mainDescription>A&nbsp;<a class="elementLinkWithUserText" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/breakdown_element_E6E32412.html" guid="_cvdpEB_LEdq6CKKKq4D7YA">breakdown element</a> that groups role descriptors or composite roles, thus defining a
+ <mainDescription>A&nbsp;<a class="elementLinkWithUserText"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/breakdown_element_E6E32412.html"
+guid="_cvdpEB_LEdq6CKKKq4D7YA">breakdown element</a> that groups role descriptors or composite roles, thus defining a
nested hierarchy of teams and team members.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/template.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/template.xmi
index 78f0db1..996c3e3 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/template.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/template.xmi
@@ -1,7 +1,9 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="--SOXfR7BTPs3CqtNP8R6Rw" name="new_term_definition,_1MLN8MaIEduMlb2cQZNTYw" guid="--SOXfR7BTPs3CqtNP8R6Rw" changeDate="2007-12-05T10:24:41.000-0800" version="7.2.0">
- <mainDescription>A specialized type of <a class="elementLinkWithUserText" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html" guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;that specifies the structure of a work product by providing a pre-defined
-table of contents, sections, packages, and/or headings, a standardized format, as well as descriptions on how the sections
-and packages are supposed to be used and completed.&nbsp; Often provided as a form or empty instanced of a work product
+ <mainDescription>A specialized type of <a class="elementLinkWithUserText"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;that specifies the structure of a work product by providing a pre-defined
+table of contents, sections, packages, and/or headings, a standardized format, as well as descriptions on how the sections
+and packages are supposed to be used and completed.&nbsp; Often provided as a form or empty instanced of a work product
that can be used as starting point for the creation of a new one.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/term_definition.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/term_definition.xmi
index 492ba0a..feed302 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/term_definition.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/term_definition.xmi
@@ -1,4 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-4JztP2JNqE36rtSC0UoYDw" name="new_term_definition,_6SluIMaIEduMlb2cQZNTYw" guid="-4JztP2JNqE36rtSC0UoYDw" changeDate="2007-12-05T10:25:06.000-0800" version="7.2.0">
- <mainDescription>A specialized form of&nbsp;<a class="elementLinkWithUserText" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html" guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;that provides definitions that are used to build up the glossary</mainDescription>
+ <mainDescription>A specialized form of&nbsp;<a class="elementLinkWithUserText"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;that provides definitions that are used to build up the glossary</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/tool.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/tool.xmi
index f9dd56d..06814ec 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/tool.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/tool.xmi
@@ -1,5 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-XnXEM7GkN21zwj7pKPmu3A" name="new_term_definition,_BangwMaJEduMlb2cQZNTYw" guid="-XnXEM7GkN21zwj7pKPmu3A" changeDate="2007-02-27T09:36:33.000-0800" version="7.2.0">
- <mainDescription>A&nbsp;standard category used as a container for <a class="elementLinkWithUserText" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/tool_mentor_264766F3.html" guid="_yYy-mdnmEdmO6L4XMImrsA">tool mentors</a>. It can also provide general descriptions of the tool and its general
+ <mainDescription>A&nbsp;standard category used as a container for <a class="elementLinkWithUserText"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/tool_mentor_264766F3.html"
+guid="_yYy-mdnmEdmO6L4XMImrsA">tool mentors</a>. It can also provide general descriptions of the tool and its general
capabilities.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/tool_mentor.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/tool_mentor.xmi
index 457be35..7ed24a8 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/tool_mentor.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/tool_mentor.xmi
@@ -1,12 +1,12 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_yYy-mtnmEdmO6L4XMImrsA" name="tool_mentor,_yYy-mdnmEdmO6L4XMImrsA" guid="_yYy-mtnmEdmO6L4XMImrsA" changeDate="2008-08-06T03:28:56.000-0700" version="7.2.0">
- <mainDescription>A tool mentor is a type of <a class="elementLink"
-href="./../../../core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html"
-guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;that explains how to apply a specific tool to accomplish a <a
-class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html"
-guid="_x459ktnmEdmO6L4XMImrsA">task</a>, perform&nbsp;a set of&nbsp;<a class="elementLink"
-href="./../../../core.default.uma_concept.base/guidances/termdefinitions/step_EB040824.html"
-guid="_BqZloB_eEdqAHrsQ7-jSbw">step</a>s or instantiate a particular <a class="elementLink"
-href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
+ <mainDescription>A tool mentor is a type of <a class="elementLink"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html"
+guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;that explains how to apply a specific tool to accomplish a <a
+class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html"
+guid="_x459ktnmEdmO6L4XMImrsA">task</a>, perform&nbsp;a set of&nbsp;<a class="elementLink"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/step_EB040824.html"
+guid="_BqZloB_eEdqAHrsQ7-jSbw">step</a>s or instantiate a particular <a class="elementLink"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/uma.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/uma.xmi
index f784d49..b6d39bb 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/uma.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/uma.xmi
@@ -1,5 +1,5 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-QBSZ9hFRr8q6kvRyq1cESQ" name="uma,_cj6jkB_PEdq6CKKKq4D7YA" guid="-QBSZ9hFRr8q6kvRyq1cESQ" changeDate="2005-09-07T11:44:46.000-0700" version="7.2.0">
- <mainDescription>Stands for&nbsp;Unified Method&nbsp;Architecture. UMA is a state-of-the-art architecture for the conceiving, specifying,
+ <mainDescription>Stands for&nbsp;Unified Method&nbsp;Architecture. UMA is a state-of-the-art architecture for the conceiving, specifying,
and storing of method and process metadata.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/view.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/view.xmi
index a932837..85cf9fe 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/view.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/view.xmi
@@ -1,4 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-dLRBfqnBlgy_0_H13LmV3A" name="new_term_definition,_GH6WUMaJEduMlb2cQZNTYw" guid="-dLRBfqnBlgy_0_H13LmV3A" changeDate="2007-02-27T09:37:06.000-0800" version="7.2.0">
- <mainDescription>Structured content collections designed to drive publication and facilitate browsing. They are specified using <a class="elementLinkWithUserText" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/custom_category_554AC4D6.html" guid="_eqw94MaFEduMlb2cQZNTYw">custom categories</a>.</mainDescription>
+ <mainDescription>Structured content collections designed to drive publication and facilitate browsing. They are specified using <a
+class="elementLinkWithUserText"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/custom_category_554AC4D6.html"
+guid="_eqw94MaFEduMlb2cQZNTYw">custom categories</a>.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/white_paper.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/white_paper.xmi
index 1c2ec22..5f71e76 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/white_paper.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/white_paper.xmi
@@ -1,7 +1,9 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-QLPRVsXtlVpWZiWmQPSsnw" name="new_term_definition,_Kc1IIMaJEduMlb2cQZNTYw" guid="-QLPRVsXtlVpWZiWmQPSsnw" changeDate="2007-12-05T10:27:55.000-0800" version="7.2.0">
- <mainDescription><p>
- A specialized type of&nbsp;<a class="elementLinkWithUserText" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html" guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;for externally&nbsp;published papers&nbsp;that can be read and
- understood in isolation of other content elements.
+ <mainDescription><p>
+ A specialized type of&nbsp;<a class="elementLinkWithUserText"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html"
+ guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;for externally&nbsp;published papers&nbsp;that can be read and
+ understood in isolation of other content elements.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/work_product.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/work_product.xmi
index 98db37a..8ab3835 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/work_product.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/work_product.xmi
@@ -1,6 +1,14 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-dcYwPivhczonAxeyXweyIQ" name="work_product,_H4JXwB_SEdq6CKKKq4D7YA" guid="-dcYwPivhczonAxeyXweyIQ" changeDate="2007-12-05T10:29:03.000-0800" version="7.2.0">
- <mainDescription><p>
- Used to define and describe the items needed as input or created as output of one or more&nbsp;<a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html" guid="_x459ktnmEdmO6L4XMImrsA">task</a>s that are the responsibility of a single role.&nbsp; See: <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html" guid="_x7cUM9nmEdmO6L4XMImrsA">artifact</a>, <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html" guid="_yFbWoNnmEdmO6L4XMImrsA">deliverable</a>, <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html" guid="_LNAAcB_iEdqAHrsQ7-jSbw">outcome</a>.
+ <mainDescription><p>
+ Used to define and describe the items needed as input or created as output of one or more&nbsp;<a class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html"
+ guid="_x459ktnmEdmO6L4XMImrsA">task</a>s that are the responsibility of a single role.&nbsp; See: <a
+ class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html"
+ guid="_x7cUM9nmEdmO6L4XMImrsA">artifact</a>, <a class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html"
+ guid="_yFbWoNnmEdmO6L4XMImrsA">deliverable</a>, <a class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html"
+ guid="_LNAAcB_iEdqAHrsQ7-jSbw">outcome</a>.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/work_product_kind.xmi b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/work_product_kind.xmi
index 5a51be7..a0bab22 100644
--- a/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/work_product_kind.xmi
+++ b/epf_prac_151/core.default.uma_concept.base/guidances/termdefinitions/work_product_kind.xmi
@@ -1,4 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-on4oCT1DzfksdshYPKAqGg" name="new_term_definition,_QWhfYMaJEduMlb2cQZNTYw" guid="-on4oCT1DzfksdshYPKAqGg" changeDate="2007-12-05T10:28:32.000-0800" version="7.2.0">
- <mainDescription>A specialized type of category used to organized <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html" guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s based on their intended usage&nbsp;or type.</mainDescription>
+ <mainDescription>A specialized type of category used to organized <a class="elementLink"
+href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
+guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s based on their intended usage&nbsp;or type.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.gen.common.base/workproducts/glossary.xmi b/epf_prac_151/core.gen.common.base/workproducts/glossary.xmi
index e4c54b8..e227949 100644
--- a/epf_prac_151/core.gen.common.base/workproducts/glossary.xmi
+++ b/epf_prac_151/core.gen.common.base/workproducts/glossary.xmi
@@ -1,51 +1,72 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ArtifactDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-iOn7_gfX_iELWRNGJ2JKPQ" name="glossary,_Wn7HcNcEEdqz_d2XWoVt6Q" guid="-iOn7_gfX_iELWRNGJ2JKPQ" changeDate="2008-08-15T00:43:08.000-0700" version="1.0.0">
- <mainDescription><p> This artifact&nbsp;helps you avoid miscommunication by providing two essential
- resources: </p>
-<ul>
- <li> A central location to look for terms and abbreviations that are new to
- development team members </li>
- <li> Definitions of terms that are used in specific ways within the domain </li>
-</ul>
-<p> Definitions for the glossary terms come from several sources, such as requirements
- documents, specifications, and discussions with stakeholders and domain experts.
+ <mainDescription><p>
+ This artifact&nbsp;helps you avoid miscommunication by providing two essential resources:
+</p>
+<ul>
+ <li>
+ A central location to look for terms and abbreviations that are new to development team members
+ </li>
+ <li>
+ Definitions of terms that are used in specific ways within the domain
+ </li>
+</ul>
+<p>
+ Definitions for the glossary terms come from several sources, such as requirements documents, specifications, and
+ discussions with stakeholders and domain experts.
</p></mainDescription>
- <keyConsiderations><p> Although listed as an <i>output from</i> and an<i> input to</i> tasks associated
- with the requirements discipline, this artifact can be updated at any time and
- by any role as new terms are identified. The terms defined should be used according
- to the recorded definitions in all project documentation so that all stakeholders
- can clearly see that terms are being used consistently. </p>
-<p> One of the primary decisions when developing&nbsp;this artifact&nbsp;is whether
- to have all terms in a single glossary or to maintain terms in several glossaries,
- business terms artifacts, or models.&nbsp;If terms are defined in multiple places,
- you need to communicate all of those sources to the team and decide which take
- precedence. </p>
-<p> It may be important, even in small projects, to reference and use existing
- broader glossaries, business terms artifacts, or data models, where they exist.
-</p>
-<p> Industry- and organization-wide glossaries may be referenced, and compliance
- with such specific chosen standards may be required. </p></keyConsiderations>
- <purpose><p> These are the purposes of&nbsp;this artifact: </p>
-<ul>
- <li> To record the terms that are being used on the project so that everyone
- has a common understanding of them </li>
- <li> To achieve consistency by promoting the use of common terminology across
- the project </li>
- <li> To make explicit different stakeholders' use of the same terms to mean
- different things or different terms to mean the same thing </li>
- <li> To provide important terms to the Analysis and Design team. </li>
+ <keyConsiderations><p>
+ Although listed as an <i>output from</i> and an <i>input to</i> tasks associated with the requirements discipline, this
+ artifact can be updated at any time and by any role as new terms are identified. The terms defined should be used
+ according to the recorded definitions in all project documentation so that all stakeholders can clearly see that terms
+ are being used consistently.
+</p>
+<p>
+ One of the primary decisions when developing&nbsp;this artifact&nbsp;is whether to have all terms in a single glossary
+ or to maintain terms in several glossaries, business terms artifacts, or models.&nbsp;If terms are defined in multiple
+ places, you need to communicate all of those sources to the team and decide which take precedence.
+</p>
+<p>
+ It may be important, even in small projects, to reference and use existing broader glossaries, business terms
+ artifacts, or data models, where they exist.
+</p>
+<p>
+ Industry- and organization-wide glossaries may be referenced, and compliance with such specific chosen standards may be
+ required.
+</p></keyConsiderations>
+ <purpose><p>
+ These are the purposes of&nbsp;this artifact:
+</p>
+<ul>
+ <li>
+ To record the terms that are being used on the project so that everyone has a common understanding of them
+ </li>
+ <li>
+ To achieve consistency by promoting the use of common terminology across the project
+ </li>
+ <li>
+ To make explicit different stakeholders' use of the same terms to mean different things or different terms to mean
+ the same thing
+ </li>
+ <li>
+ To provide important terms to the Analysis and Design team.
+ </li>
</ul></purpose>
- <impactOfNotHaving>Misunderstandings about the meanings of data items account for many failed projects. 
-Increased costs and delayed schedules are associated with projects that lack a 
-common understanding of the terms being used.</impactOfNotHaving>
- <reasonsForNotNeeding><p> On small projects (for example,&nbsp;enhancement projects), which rely on 
- a team very familiar with the terms, this artifact may be omitted. </p>
-<p> If a project team has access to the glossary terms in some other form, this&nbsp;artifact 
- may be disregarded.&nbsp;&nbsp;</p><br /></reasonsForNotNeeding>
+ <impactOfNotHaving>Misunderstandings about the meanings of data items account for many failed projects. Increased costs and delayed schedules
+are associated with projects that lack a common understanding of the terms being used.</impactOfNotHaving>
+ <reasonsForNotNeeding><p>
+ On small projects (for example,&nbsp;enhancement projects), which rely on a team very familiar with the terms, this
+ artifact may be omitted.
+</p>
+<p>
+ If a project team has access to the glossary terms in some other form, this&nbsp;artifact may be
+ disregarded.&nbsp;&nbsp;
+</p><br /></reasonsForNotNeeding>
<briefOutline><p>
A project glossary defines the terms used during all phases of the project. There is a short definition for each term.
</p></briefOutline>
- <representationOptions><p> This is a simple alphabetical listing of domain terms and their definitions. 
- It can be captured in a spreadsheet, document, or published on a Wiki site to 
- simplify access and maintenance. </p></representationOptions>
+ <representationOptions><p>
+ This is a simple alphabetical listing of domain terms and their definitions. It can be captured in a spreadsheet,
+ document, or published on a Wiki site to simplify access and maintenance.
+</p></representationOptions>
</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/epf_prac_151/core.mgmt.common.base/guidances/supportingmaterials/references.mgmt.xmi b/epf_prac_151/core.mgmt.common.base/guidances/supportingmaterials/references.mgmt.xmi
index 469fabc..ab70b60 100644
--- a/epf_prac_151/core.mgmt.common.base/guidances/supportingmaterials/references.mgmt.xmi
+++ b/epf_prac_151/core.mgmt.common.base/guidances/supportingmaterials/references.mgmt.xmi
@@ -1,281 +1,281 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-BUHtqig5wrabMIpZgZChMg" name="new_supporting_material,_JlTPUM6aEdyuBO4ZIzcyig" guid="-BUHtqig5wrabMIpZgZChMg" changeDate="2010-09-02T00:33:36.000-0700" version="7.2.0">
- <mainDescription><h3>
- Management
-</h3>
-<table width="100%" summary="layout table" border="0">
- <tbody>
- <tr>
- <td valign="top" width="12%">
- <a>AMB03</a>
- </td>
- <td colspan="2">
- Ambler, S. <em>Generalizing Specialists: Improving Your IT Career Skills</em>, <a
- href="http://www.agilemodeling.com/essays/generalizingSpecialists.htm">http://www.agilemodeling.com/essays/generalizingSpecialists.htm</a>
- </td>
- </tr>
- </tbody>
-</table>
-<table width="100%" summary="layout table" border="0">
- <tbody>
- <tr>
- <td valign="top" width="12%">
- <a id="BOE91" name="BOE91">BOE91</a>
- </td>
- <td colspan="2">
- Barry W. Boehm 1991. <i>Software Risk Management: Principles and Practices</i>, <i>IEEE Software,</i> Jan.
- 1991, IEEE, pp.32-41.
- </td>
- </tr>
- </tbody>
-</table>
-<table width="100%" summary="layout table" border="0">
- <tbody>
- <tr>
- <td valign="top" width="12%">
- <a>BOE95</a>
- </td>
- <td colspan="2">
- Boehm, B. <em>Anchoring the Software Process</em>, <a
- href="http://sunset.usc.edu/publications/TECHRPTS/1995/usccse95-507/ASP.pdf">http://sunset.usc.edu/publications/TECHRPTS/1995/usccse95-507/ASP.pdf</a>.&nbsp;&nbsp;(<a
- href="http://get.adobe.com/reader/">Get Adobe Reader</a>)
- </td>
- </tr>
- </tbody>
-</table>
-<table width="100%" summary="layout table" border="0">
- <tbody>
- <tr>
- <td valign="top" width="12%">
- <a>BRO95</a>
- </td>
- <td colspan="2">
- <p>
- Brooks, F.P <em>The Mythical Man Month: Essays on Software Engineering, 20th Anniversary
- Edition</em>.&nbsp;Addison Wesley Professional, 1995.
- </p>
- </td>
- </tr>
- </tbody>
-</table>
-<table width="100%" summary="layout table" border="0">
- <tbody>
- <tr>
- <td valign="top" width="12%">
- <a>CRO79</a>
- </td>
- <td colspan="2">
- Crosby, Philip. <em>Quality is Free: The Art of Making Quality Certain</em>, McGraw-Hill, 1979.
- </td>
- </tr>
- </tbody>
-</table>
-<table width="100%" summary="layout table" border="0">
- <tbody>
- <tr>
- <td valign="top" width="12%">
- <a>DOD94</a>
- </td>
- <td colspan="2">
- Software Development and Documentation, MIL-STD-498, U.S. Department of Defense, December 1994.
- </td>
- </tr>
- </tbody>
-</table>
-<table width="100%" summary="layout table" border="0">
- <tbody>
- <tr>
- <td valign="top" width="12%">
- <a>GIL88</a>
- </td>
- <td colspan="2">
- Tom Gilb 1988. Principles of Software Engineering Management. Harlow, England: Addison Wesley Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- A great book by a pioneer of iterative development, it's full of pragmatic advice for the project manager.
- </td>
- </tr>
- </tbody>
-</table>
-<table width="100%" summary="layout table" border="0">
- <tbody>
- <tr>
- <td valign="top" width="12%">
- <a>KAN07</a>
- </td>
- <td colspan="2">
- Kaner, S. <em>Facilitator's Guide to Participatory Decision-Making.</em> Jossey-Bass, 2007.<br />
- </td>
- </tr>
- </tbody>
-</table>
-<table width="100%" summary="layout table" border="0">
- <tbody>
- <tr>
- <td valign="top" width="12%">
- <a>KAT93</a>
- </td>
- <td colspan="2">
- Katzenbach, Jon&nbsp;and Smith, Douglas K.&nbsp;&nbsp;<em>The Wisdom of Teams,</em> New York, NY: Harper
- Business, 1993.&nbsp;&nbsp;<br />
- The secret of effective teams.
- </td>
- </tr>
- </tbody>
-</table>
-<table width="100%" summary="layout table" border="0">
- <tbody>
- <tr>
- <td valign="top" width="12%">
- <a>KER01</a>
- </td>
- <td colspan="2">
- Kerth, N. <em>Project Retrospectives: A Handbook for Team Reviews</em>. Dorset House, 2001.
- </td>
- </tr>
- </tbody>
-</table>
-<table width="100%" summary="layout table" border="0">
- <tbody>
- <tr>
- <td valign="top" width="12%">
- <a>KRO03</a>
- </td>
- <td colspan="2">
- Kroll, P. and&nbsp;Kruchten, P. <em>The Rational Unified Process Made Easy</em>, Addison Wesley, 2003.
- </td>
- </tr>
- </tbody>
-</table>
-<table width="100%" summary="layout table" border="0">
- <tbody>
- <tr>
- <td valign="top" width="12%">
- <a>KRO05</a>
- </td>
- <td colspan="2">
- Kroll, P. and&nbsp;MacIsaac, B. <em>Agility and Discipline Made Easy</em>, Addison Wesley, 2005.
- </td>
- </tr>
- </tbody>
-</table>
-<table width="100%" summary="layout table" border="0">
- <tbody>
- <tr>
- <td valign="top" width="12%">
- <a>KRU00</a>
- </td>
- <td colspan="2">
- Kruchten, P. <em>From Waterfall to Iterative Development - A Challenging Transition for Project
- Managers</em>, The Rational Edge e-zine, 2000. <a
- href="http://download.boulder.ibm.com/ibmdl/pub/software/dw/rationaledge/dec00/FromWaterfalltoIterativeDevelopmentDec00.pdf">http://download.boulder.ibm.com/ibmdl/pub/software/dw/rationaledge/dec00/FromWaterfalltoIterativeDevelopmentDec00.pdf</a>.&nbsp;&nbsp;(<a
- href="http://get.adobe.com/reader/">Get Adobe Reader</a>)
- </td>
- </tr>
- </tbody>
-</table>
-<table width="100%" summary="layout table" border="0">
- <tbody>
- <tr>
- <td valign="top" width="12%">
- <a>LEF07</a>
- </td>
- <td colspan="2">
- Leffingwell, Dean. <em>Scaling Software Agility</em>, Addison Wesley, 2007.
- </td>
- </tr>
- </tbody>
-</table>
-<table width="100%" summary="layout table" border="0">
- <tbody>
- <tr>
- <td valign="top" width="12%">
- <a>PMI</a>
- </td>
- <td colspan="2">
- Project Management Institute (PMI), Project Management Body of Knowledge (PMBOK(r)): <a
- href="http://www.pmi.org/">http://www.pmi.org/</a>
- </td>
- </tr>
- </tbody>
-</table>
-<table width="100%" summary="layout table" border="0">
- <tbody>
- <tr>
- <td valign="top" width="12%">
- <a>POL08</a>
- </td>
- <td colspan="2">
- Pollice, G. <em>Collaboration Support: The next evolutionary step</em>, The Rational Edge e-zine, 2008. <a
- href="http://www.ibm.com/developerworks/rational/library/edge/08/jul08/pollice/index.html">http://www.ibm.com/developerworks/rational/library/edge/08/jul08/pollice/index.html</a>
- </td>
- </tr>
- </tbody>
-</table>
-<table width="100%" summary="layout table" border="0">
- <tbody>
- <tr>
- <td valign="top" width="12%">
- <a>RUP06</a>
- </td>
- <td colspan="2">
- IBM Rational 2006. <em>The Rational Unified Process.</em>
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- A commercial methodology, also based on the Eclipse Process Framework, and advanced guidance on topics such
- as business modeling, portfolio management, asset-based development, real-time design, user experience, and
- so on.
- </td>
- </tr>
- </tbody>
-</table>
-<table width="100%" summary="layout table" border="0">
- <tbody>
- <tr>
- <td valign="top" width="12%">
- <a>SCH04</a>
- </td>
- <td colspan="2">
- Schwaber, K. <em>Agile Project Management with Scrum.</em> Microsoft Press 2004.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- <p>
- An excellent reference by one of the co-inventors of the Scrum project management method.
- </p>
- </td>
- </tr>
- </tbody>
-</table>
-<table width="100%" summary="layout table" border="0">
- <tbody>
- <tr>
- <td valign="top" width="12%">
- <a>SEI99</a>
- </td>
- <td colspan="2">
- SEI, 1999. <em>Software Risk Evaluation (SRE) Method Description, v2.0.</em><br />
- <a href="http://www.sei.cmu.edu/reports/99tr029.pdf">http://www.sei.cmu.edu/reports/99tr029.pdf</a>
- .&nbsp;&nbsp;(<a href="http://get.adobe.com/reader/">Get Adobe Reader</a>)
- </td>
- </tr>
- </tbody>
+ <mainDescription><h3>
+ Management
+</h3>
+<table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a>AMB03</a>
+ </td>
+ <td colspan="2">
+ Ambler, S. <em>Generalizing Specialists: Improving Your IT Career Skills</em>, <a
+ href="http://www.agilemodeling.com/essays/generalizingSpecialists.htm">http://www.agilemodeling.com/essays/generalizingSpecialists.htm</a>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a id="BOE91" name="BOE91">BOE91</a>
+ </td>
+ <td colspan="2">
+ Barry W. Boehm 1991. <i>Software Risk Management: Principles and Practices</i>, <i>IEEE Software,</i> Jan.
+ 1991, IEEE, pp.32-41.
+ </td>
+ </tr>
+ </tbody>
+</table>
+<table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a>BOE95</a>
+ </td>
+ <td colspan="2">
+ Boehm, B. <em>Anchoring the Software Process</em>, <a
+ href="http://sunset.usc.edu/publications/TECHRPTS/1995/usccse95-507/ASP.pdf">http://sunset.usc.edu/publications/TECHRPTS/1995/usccse95-507/ASP.pdf</a>.&nbsp;&nbsp;(<a
+ href="http://get.adobe.com/reader/">Get Adobe Reader</a>)
+ </td>
+ </tr>
+ </tbody>
+</table>
+<table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a>BRO95</a>
+ </td>
+ <td colspan="2">
+ <p>
+ Brooks, F.P <em>The Mythical Man Month: Essays on Software Engineering, 20th Anniversary
+ Edition</em>.&nbsp;Addison Wesley Professional, 1995.
+ </p>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a>CRO79</a>
+ </td>
+ <td colspan="2">
+ Crosby, Philip. <em>Quality is Free: The Art of Making Quality Certain</em>, McGraw-Hill, 1979.
+ </td>
+ </tr>
+ </tbody>
+</table>
+<table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a>DOD94</a>
+ </td>
+ <td colspan="2">
+ Software Development and Documentation, MIL-STD-498, U.S. Department of Defense, December 1994.
+ </td>
+ </tr>
+ </tbody>
+</table>
+<table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a>GIL88</a>
+ </td>
+ <td colspan="2">
+ Tom Gilb 1988. Principles of Software Engineering Management. Harlow, England: Addison Wesley Longman.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A great book by a pioneer of iterative development, it's full of pragmatic advice for the project manager.
+ </td>
+ </tr>
+ </tbody>
+</table>
+<table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a>KAN07</a>
+ </td>
+ <td colspan="2">
+ Kaner, S. <em>Facilitator's Guide to Participatory Decision-Making.</em> Jossey-Bass, 2007.<br />
+ </td>
+ </tr>
+ </tbody>
+</table>
+<table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a>KAT93</a>
+ </td>
+ <td colspan="2">
+ Katzenbach, Jon&nbsp;and Smith, Douglas K.&nbsp;&nbsp;<em>The Wisdom of Teams,</em> New York, NY: Harper
+ Business, 1993.&nbsp;&nbsp;<br />
+ The secret of effective teams.
+ </td>
+ </tr>
+ </tbody>
+</table>
+<table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a>KER01</a>
+ </td>
+ <td colspan="2">
+ Kerth, N. <em>Project Retrospectives: A Handbook for Team Reviews</em>. Dorset House, 2001.
+ </td>
+ </tr>
+ </tbody>
+</table>
+<table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a>KRO03</a>
+ </td>
+ <td colspan="2">
+ Kroll, P. and&nbsp;Kruchten, P. <em>The Rational Unified Process Made Easy</em>, Addison Wesley, 2003.
+ </td>
+ </tr>
+ </tbody>
+</table>
+<table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a>KRO05</a>
+ </td>
+ <td colspan="2">
+ Kroll, P. and&nbsp;MacIsaac, B. <em>Agility and Discipline Made Easy</em>, Addison Wesley, 2005.
+ </td>
+ </tr>
+ </tbody>
+</table>
+<table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a>KRU00</a>
+ </td>
+ <td colspan="2">
+ Kruchten, P. <em>From Waterfall to Iterative Development - A Challenging Transition for Project
+ Managers</em>, The Rational Edge e-zine, 2000. <a
+ href="http://download.boulder.ibm.com/ibmdl/pub/software/dw/rationaledge/dec00/FromWaterfalltoIterativeDevelopmentDec00.pdf">http://download.boulder.ibm.com/ibmdl/pub/software/dw/rationaledge/dec00/FromWaterfalltoIterativeDevelopmentDec00.pdf</a>.&nbsp;&nbsp;(<a
+ href="http://get.adobe.com/reader/">Get Adobe Reader</a>)
+ </td>
+ </tr>
+ </tbody>
+</table>
+<table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a>LEF07</a>
+ </td>
+ <td colspan="2">
+ Leffingwell, Dean. <em>Scaling Software Agility</em>, Addison Wesley, 2007.
+ </td>
+ </tr>
+ </tbody>
+</table>
+<table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a>PMI</a>
+ </td>
+ <td colspan="2">
+ Project Management Institute (PMI), Project Management Body of Knowledge (PMBOK(r)): <a
+ href="http://www.pmi.org/">http://www.pmi.org/</a>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a>POL08</a>
+ </td>
+ <td colspan="2">
+ Pollice, G. <em>Collaboration Support: The next evolutionary step</em>, The Rational Edge e-zine, 2008. <a
+ href="http://www.ibm.com/developerworks/rational/library/edge/08/jul08/pollice/index.html">http://www.ibm.com/developerworks/rational/library/edge/08/jul08/pollice/index.html</a>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a>RUP06</a>
+ </td>
+ <td colspan="2">
+ IBM Rational 2006. <em>The Rational Unified Process.</em>
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ A commercial methodology, also based on the Eclipse Process Framework, and advanced guidance on topics such
+ as business modeling, portfolio management, asset-based development, real-time design, user experience, and
+ so on.
+ </td>
+ </tr>
+ </tbody>
+</table>
+<table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a>SCH04</a>
+ </td>
+ <td colspan="2">
+ Schwaber, K. <em>Agile Project Management with Scrum.</em> Microsoft Press 2004.
+ </td>
+ </tr>
+ <tr>
+ <td valign="top" width="12%">
+ </td>
+ <td width="10%">
+ </td>
+ <td style="PADDING-BOTTOM: 10px" width="78%">
+ <p>
+ An excellent reference by one of the co-inventors of the Scrum project management method.
+ </p>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<table width="100%" summary="layout table" border="0">
+ <tbody>
+ <tr>
+ <td valign="top" width="12%">
+ <a>SEI99</a>
+ </td>
+ <td colspan="2">
+ SEI, 1999. <em>Software Risk Evaluation (SRE) Method Description, v2.0.</em><br />
+ <a href="http://www.sei.cmu.edu/reports/99tr029.pdf">http://www.sei.cmu.edu/reports/99tr029.pdf</a>
+ .&nbsp;&nbsp;(<a href="http://get.adobe.com/reader/">Get Adobe Reader</a>)
+ </td>
+ </tr>
+ </tbody>
</table></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.mgmt.common.base/guidances/termdefinitions/agile.xmi b/epf_prac_151/core.mgmt.common.base/guidances/termdefinitions/agile.xmi
index 8233b22..cce58c7 100644
--- a/epf_prac_151/core.mgmt.common.base/guidances/termdefinitions/agile.xmi
+++ b/epf_prac_151/core.mgmt.common.base/guidances/termdefinitions/agile.xmi
@@ -1,5 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-qZE4XgeMK93LmJMKuQWGFg" name=",_3PJ38EvqEdunZcj9T5hrMQ" guid="-qZE4XgeMK93LmJMKuQWGFg" changeDate="2008-07-15T11:29:19.000-0700" version="7.2.0">
- <mainDescription>A set of values and principles for software development that use lean production techniques to deliver value to
-stakeholders quickly and frequently. See the agile manifesto at: <a href="http://agilemanifesto.org/">http://agilemanifesto.org/</a></mainDescription>
+ <mainDescription>A set of values and principles for software development that use lean production techniques to deliver value to
+stakeholders quickly and frequently. See the agile manifesto at: <a
+href="http://agilemanifesto.org/">http://agilemanifesto.org/</a></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.mgmt.common.base/guidances/termdefinitions/effort.xmi b/epf_prac_151/core.mgmt.common.base/guidances/termdefinitions/effort.xmi
index 32960bf..4c533cb 100644
--- a/epf_prac_151/core.mgmt.common.base/guidances/termdefinitions/effort.xmi
+++ b/epf_prac_151/core.mgmt.common.base/guidances/termdefinitions/effort.xmi
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-WIgtkwJN71D51FdcQs-TzQ" name=",_nJSDwEvuEdunZcj9T5hrMQ" guid="-WIgtkwJN71D51FdcQs-TzQ" changeDate="2008-09-12T02:38:29.000-0700" version="7.2.0">
- <mainDescription><p>
- The number of labor units required to complete an activity or other project element. Usually expressed as staff hours,
- staff days, or staff weeks. Should not be confused with duration.
+ <mainDescription><p>
+ The number of labor units required to complete an activity or other project element. Usually expressed as staff hours,
+ staff days, or staff weeks. Should not be confused with duration.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.mgmt.common.base/guidances/termdefinitions/milestone.xmi b/epf_prac_151/core.mgmt.common.base/guidances/termdefinitions/milestone.xmi
index fde607a..4099719 100644
--- a/epf_prac_151/core.mgmt.common.base/guidances/termdefinitions/milestone.xmi
+++ b/epf_prac_151/core.mgmt.common.base/guidances/termdefinitions/milestone.xmi
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-9fXEOvMc4t7y6s5GscBD1Q" name=",_ByXNcEvqEdunZcj9T5hrMQ" guid="-9fXEOvMc4t7y6s5GscBD1Q" changeDate="2008-05-08T00:35:38.000-0700" version="7.2.0">
- <mainDescription><p>
- A significant event in the project or sub-project, such as a major decision, completion of a deliverable, or meeting of
- a major dependency (like completion of a phase).
+ <mainDescription><p>
+ A significant event in the project or sub-project, such as a major decision, completion of a deliverable, or meeting of
+ a major dependency (like completion of a phase).
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.mgmt.common.base/guidances/termdefinitions/risk.xmi b/epf_prac_151/core.mgmt.common.base/guidances/termdefinitions/risk.xmi
index 6eaf33a..7f72277 100644
--- a/epf_prac_151/core.mgmt.common.base/guidances/termdefinitions/risk.xmi
+++ b/epf_prac_151/core.mgmt.common.base/guidances/termdefinitions/risk.xmi
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-hOtatvr8wIjqW8UD0MSGhQ" name="risk,_ii2LUEvGEdunZcj9T5hrMQ" guid="-hOtatvr8wIjqW8UD0MSGhQ" changeDate="2008-09-12T02:39:02.000-0700" version="1.0.0">
- <mainDescription><p>
- A potential event or future situation that can potentially affect, prevent, or limit a project's success. Project risks
- may be seen as threats or opportunities.
+ <mainDescription><p>
+ A potential event or future situation that can potentially affect, prevent, or limit a project's success. Project risks
+ may be seen as threats or opportunities.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.mgmt.common.base/guidances/termdefinitions/scope.xmi b/epf_prac_151/core.mgmt.common.base/guidances/termdefinitions/scope.xmi
index 1a31d78..3b5d552 100644
--- a/epf_prac_151/core.mgmt.common.base/guidances/termdefinitions/scope.xmi
+++ b/epf_prac_151/core.mgmt.common.base/guidances/termdefinitions/scope.xmi
@@ -1,8 +1,8 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-h1poMaxtQbmg6hD5772oVw" name=",_t7JOkEvtEdunZcj9T5hrMQ" guid="-h1poMaxtQbmg6hD5772oVw" changeDate="2008-09-12T02:42:22.000-0700" version="7.2.0">
- <mainDescription><p>
- The boundaries for inclusions and exclusions that define the depth and breadth of the project. Example of areas for
- consideration are included functionality, affected organizations, lifecycle phases performed, included and excluded
- deliverables, involved geographic areas, and so on.
+ <mainDescription><p>
+ The boundaries for inclusions and exclusions that define the depth and breadth of the project. Example of areas for
+ consideration are included functionality, affected organizations, lifecycle phases performed, included and excluded
+ deliverables, involved geographic areas, and so on.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.mgmt.common.base/guidances/termdefinitions/work_breakdown_structure.xmi b/epf_prac_151/core.mgmt.common.base/guidances/termdefinitions/work_breakdown_structure.xmi
index edd153e..bd84998 100644
--- a/epf_prac_151/core.mgmt.common.base/guidances/termdefinitions/work_breakdown_structure.xmi
+++ b/epf_prac_151/core.mgmt.common.base/guidances/termdefinitions/work_breakdown_structure.xmi
@@ -1,8 +1,8 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-KQTbqDSJXR8KLBxIgGVquA" name=",_RK9nwEvtEdunZcj9T5hrMQ" guid="-KQTbqDSJXR8KLBxIgGVquA" changeDate="2009-02-24T11:43:31.000-0800" version="7.2.0">
- <mainDescription><p>
- A hierarchical structured list of all the project activities, in which the work of the project is broken down into
- smaller work units to achieve an appropriate level of granularity that ensures that the full scope of work to be
- performed is understood.
+ <mainDescription><p>
+ A hierarchical structured list of all the project activities, in which the work of the project is broken down into
+ smaller work units to achieve an appropriate level of granularity that ensures that the full scope of work to be
+ performed is understood.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.mgmt.common.extend_supp/guidances/concepts/change_set.xmi b/epf_prac_151/core.mgmt.common.extend_supp/guidances/concepts/change_set.xmi
index a0ea414..b4bca7b 100644
--- a/epf_prac_151/core.mgmt.common.extend_supp/guidances/concepts/change_set.xmi
+++ b/epf_prac_151/core.mgmt.common.extend_supp/guidances/concepts/change_set.xmi
@@ -1,37 +1,37 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-QpMXBM5_A8w0pRyIT5n5yA" name="change_set,_1QU9MAIoEdyLh7vsrHZ4YA" guid="-QpMXBM5_A8w0pRyIT5n5yA" changeDate="2007-05-31T04:18:27.000-0700" version="7.5.1">
- <mainDescription><p>
- A change set is a logical grouping of related changes made to the implementation and supporting artifacts. Change sets
- are defined for a specific purpose and encompass all changes made to achieve that purpose.
-</p>
-<p>
- Change sets allow for multiple related changes to be referred to as single item, simplifying tracking of&nbsp;that
- item's progress through the development lifecycle.
-</p>
-<p>
- The change set forms the basic unit of configuration control, accountability, and collaboration on the development
- team.&nbsp; Additionally, change sets track the dependencies between artifact changes that facilitate discovery and
- correction of configuration inconsistencies. The relationship between items in a change set can be used to verify that
- all related changes have been included in a build.
-</p>
-<p>
- Change sets have the following characteristics:
-</p>
-<ol>
- <li>
- Change sets consist of changes that belong together and can be built and tested together.
- </li>
- <li>
- Change sets are owned by a single developer.
- </li>
- <li>
- Change sets represent small, testable changes to the system.
- </li>
-</ol>
-<p>
- Multiple change sets&nbsp;may be&nbsp;related to&nbsp;a single work item.
-</p>
-<p>
- Change sets are also known as CM tasks, activity change sets, change lists or change packages.
+ <mainDescription><p>
+ A change set is a logical grouping of related changes made to the implementation and supporting artifacts. Change sets
+ are defined for a specific purpose and encompass all changes made to achieve that purpose.
+</p>
+<p>
+ Change sets allow for multiple related changes to be referred to as single item, simplifying tracking of&nbsp;that
+ item's progress through the development lifecycle.
+</p>
+<p>
+ The change set forms the basic unit of configuration control, accountability, and collaboration on the development
+ team.&nbsp; Additionally, change sets track the dependencies between artifact changes that facilitate discovery and
+ correction of configuration inconsistencies. The relationship between items in a change set can be used to verify that
+ all related changes have been included in a build.
+</p>
+<p>
+ Change sets have the following characteristics:
+</p>
+<ol>
+ <li>
+ Change sets consist of changes that belong together and can be built and tested together.
+ </li>
+ <li>
+ Change sets are owned by a single developer.
+ </li>
+ <li>
+ Change sets represent small, testable changes to the system.
+ </li>
+</ol>
+<p>
+ Multiple change sets&nbsp;may be&nbsp;related to&nbsp;a single work item.
+</p>
+<p>
+ Change sets are also known as CM tasks, activity change sets, change lists or change packages.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.mgmt.common.extend_supp/guidances/concepts/metrics.xmi b/epf_prac_151/core.mgmt.common.extend_supp/guidances/concepts/metrics.xmi
index 16c9619..3349131 100644
--- a/epf_prac_151/core.mgmt.common.extend_supp/guidances/concepts/metrics.xmi
+++ b/epf_prac_151/core.mgmt.common.extend_supp/guidances/concepts/metrics.xmi
@@ -1,148 +1,148 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_7ygXoMM3EdmSIPI87WLu3g" name="metrics,_0mYYkMlgEdmt3adZL5Dmdw" guid="_7ygXoMM3EdmSIPI87WLu3g" changeDate="2008-10-13T01:20:11.000-0700" version="7.2.0">
- <mainDescription><h3>
- <font size="5">What is a Metric?</font>
-</h3>
-<p>
- We distinguish between measure and metric. To clarify, let's start by defining what is meant by measure and by metric.
-</p>
-<ul>
- <li>
- <b>Measure</b>: A raw data item that is directly measured, and that will be used to calculate a metric.
- </li>
- <li>
- <b>Metric</b>: An interpretation of a measure or a set of measures that you use to guide your project. For example,
- recording how many test cases have passed and how many have failed are measures. Interpreting what level of quality
- this indicates and how it reflects the team's progress within the current iteration is a metric.
- </li>
-</ul>
-<h3>
- <font size="5">Why Measure?</font>
-</h3>
-<p>
- Measurements will mainly help you to:
-</p>
-<ul>
- <li>
- <b>Communicate effectively</b>. Measurement supports effective communication among team members and project
- stakeholders.
- </li>
- <li>
- <b>Identify and correct problems early</b>. Measurement enables you to identify and manage potential problems early
- in the development lifecycle.
- </li>
- <li>
- <b>Make informed trade-offs</b>. Measurement helps objectively assess the impact of decisions, helping&nbsp;the
- team&nbsp;make trade-off decisions to best meet project goals.
- </li>
- <li>
- <b>Tune estimations</b>. Recording schedule, progress, and expenditures for projects will help team members to make
- more reliable estimations in the future.
- </li>
-</ul>
-<h3>
- <font size="5">Potential Challenges</font>
-</h3>
-<p>
- There are several dangers when it comes to metrics:
-</p>
-<ul>
- <li>
- <div align="left">
- <b>They can be too costly</b>. The benefit provided by the metric must exceed the cost of collecting it. Keep
- your measurements simple and easy to collect.
- </div>
- </li>
- <li>
- <div align="left">
- <b>They're a poor substitute for communication</b>. Do not use metrics as a substitute for communication. Team
- members may help to decide which metrics make sense for the project. Apply metrics not so much to control the
- project but to help team to collaborate better. Asking people about their progress is a co-dependent way of
- gaining insight into progress.
- </div>
- </li>
- <li>
- <div align="left">
- <b>They can be misleading</b>. No metric or collection of metrics is perfect. Furthermore, the measurements
- upon which they are based can be manipulated by the people capturing them. Don't rely simply upon metrics to
- manage a project.
- </div>
- </li>
-</ul>
-<p>
- Effective metrics programs can be challenging to implement, though typically not because of the statistics and complex
- analysis often associated with metrics. Rather, the challenge lies in understanding which metrics add value to the
- project and to the company, and which procedures are most efficient for collecting and using these metrics.
-</p>
-<p>
- Consider implementing only a handful metrics. Importantly, do not collect metrics unless they help contribute to a goal
- of improving a defined area of your software development process. If you will not act on a metric, do not collect it.
- It is much more important to focus on a small number of metrics that are important to what you are trying to achieve
- right now, versus a larger set of metrics that may be "good to track".&nbsp;
-</p>
-<h3>
- <font size="5">Common Metrics</font>
-</h3>
-<p>
- Below are some common measures and associated metrics used in software development projects. These metrics help teams
- communicate, identify and correct problems early, make informed trade-offs, and tune estimations. Example of metrics
- coverage areas are listed below.
-</p>
-<ul>
- <li>
- Software quality
- <ul>
- <li>
- Defect backlog: Number of defects discovered respectively resolved per iteration
- </li>
- <li>
- Test case coverage: Number of test cases executed over total number of test cases
- </li>
- <li>
- Code coverage: % of code that have been tested
- </li>
- </ul>
- </li>
- <li>
- Development productivity
- <ul>
- <li>
- Velocity: Number of delivered points by iteration (see <a class="elementLink"
- href="./../../../core.mgmt.common.extend_supp/guidances/guidelines/agile_estimation_A4EF42B3.html"
- guid="_CGHskBEdEdqY7JB6N6CW2w">Agile Estimation</a>)
- </li>
- </ul>
- </li>
- <li>
- Development process effectiveness
- <ul>
- <li>
- Responsiveness to quality issues: Number of defects discovered versus resolved per iteration
- </li>
- <li>
- Responsiveness to process improvement proposal: Number of process enhancements proposed versus implemented
- </li>
- </ul>
- </li>
- <li>
- Cost and schedule estimate and variance
- <ul>
- <li>
- Effort: Actual effort spent per iteration
- </li>
- <li>
- Cost: Cost per iteration
- </li>
- <li>
- Effort remaining: Track&nbsp;project burndown&nbsp;
- </li>
- </ul>
- </li>
-</ul>
-<p>
- There are many other measures and metrics that may make sense, based on what you are trying to accomplish. For example,
- if you want to measure the quality of your architecture, you may choose to collect metrics related to coupling between
- different software packages (groups of related classes) by measuring extensibility, dependency, and responsibility of
- each package.
+ <mainDescription><h3>
+ <font size="5">What is a Metric?</font>
+</h3>
+<p>
+ We distinguish between measure and metric. To clarify, let's start by defining what is meant by measure and by metric.
+</p>
+<ul>
+ <li>
+ <b>Measure</b>: A raw data item that is directly measured, and that will be used to calculate a metric.
+ </li>
+ <li>
+ <b>Metric</b>: An interpretation of a measure or a set of measures that you use to guide your project. For example,
+ recording how many test cases have passed and how many have failed are measures. Interpreting what level of quality
+ this indicates and how it reflects the team's progress within the current iteration is a metric.
+ </li>
+</ul>
+<h3>
+ <font size="5">Why Measure?</font>
+</h3>
+<p>
+ Measurements will mainly help you to:
+</p>
+<ul>
+ <li>
+ <b>Communicate effectively</b>. Measurement supports effective communication among team members and project
+ stakeholders.
+ </li>
+ <li>
+ <b>Identify and correct problems early</b>. Measurement enables you to identify and manage potential problems early
+ in the development lifecycle.
+ </li>
+ <li>
+ <b>Make informed trade-offs</b>. Measurement helps objectively assess the impact of decisions, helping&nbsp;the
+ team&nbsp;make trade-off decisions to best meet project goals.
+ </li>
+ <li>
+ <b>Tune estimations</b>. Recording schedule, progress, and expenditures for projects will help team members to make
+ more reliable estimations in the future.
+ </li>
+</ul>
+<h3>
+ <font size="5">Potential Challenges</font>
+</h3>
+<p>
+ There are several dangers when it comes to metrics:
+</p>
+<ul>
+ <li>
+ <div align="left">
+ <b>They can be too costly</b>. The benefit provided by the metric must exceed the cost of collecting it. Keep
+ your measurements simple and easy to collect.
+ </div>
+ </li>
+ <li>
+ <div align="left">
+ <b>They're a poor substitute for communication</b>. Do not use metrics as a substitute for communication. Team
+ members may help to decide which metrics make sense for the project. Apply metrics not so much to control the
+ project but to help team to collaborate better. Asking people about their progress is a co-dependent way of
+ gaining insight into progress.
+ </div>
+ </li>
+ <li>
+ <div align="left">
+ <b>They can be misleading</b>. No metric or collection of metrics is perfect. Furthermore, the measurements
+ upon which they are based can be manipulated by the people capturing them. Don't rely simply upon metrics to
+ manage a project.
+ </div>
+ </li>
+</ul>
+<p>
+ Effective metrics programs can be challenging to implement, though typically not because of the statistics and complex
+ analysis often associated with metrics. Rather, the challenge lies in understanding which metrics add value to the
+ project and to the company, and which procedures are most efficient for collecting and using these metrics.
+</p>
+<p>
+ Consider implementing only a handful metrics. Importantly, do not collect metrics unless they help contribute to a goal
+ of improving a defined area of your software development process. If you will not act on a metric, do not collect it.
+ It is much more important to focus on a small number of metrics that are important to what you are trying to achieve
+ right now, versus a larger set of metrics that may be "good to track".&nbsp;
+</p>
+<h3>
+ <font size="5">Common Metrics</font>
+</h3>
+<p>
+ Below are some common measures and associated metrics used in software development projects. These metrics help teams
+ communicate, identify and correct problems early, make informed trade-offs, and tune estimations. Example of metrics
+ coverage areas are listed below.
+</p>
+<ul>
+ <li>
+ Software quality 
+ <ul>
+ <li>
+ Defect backlog: Number of defects discovered respectively resolved per iteration
+ </li>
+ <li>
+ Test case coverage: Number of test cases executed over total number of test cases
+ </li>
+ <li>
+ Code coverage: % of code that have been tested
+ </li>
+ </ul>
+ </li>
+ <li>
+ Development productivity 
+ <ul>
+ <li>
+ Velocity: Number of delivered points by iteration (see <a class="elementLink"
+ href="./../../../core.mgmt.common.extend_supp/guidances/guidelines/agile_estimation_A4EF42B3.html"
+ guid="_CGHskBEdEdqY7JB6N6CW2w">Agile Estimation</a>)
+ </li>
+ </ul>
+ </li>
+ <li>
+ Development process effectiveness 
+ <ul>
+ <li>
+ Responsiveness to quality issues: Number of defects discovered versus resolved per iteration
+ </li>
+ <li>
+ Responsiveness to process improvement proposal: Number of process enhancements proposed versus implemented
+ </li>
+ </ul>
+ </li>
+ <li>
+ Cost and schedule estimate and variance 
+ <ul>
+ <li>
+ Effort: Actual effort spent per iteration
+ </li>
+ <li>
+ Cost: Cost per iteration
+ </li>
+ <li>
+ Effort remaining: Track&nbsp;project burndown&nbsp;
+ </li>
+ </ul>
+ </li>
+</ul>
+<p>
+ There are many other measures and metrics that may make sense, based on what you are trying to accomplish. For example,
+ if you want to measure the quality of your architecture, you may choose to collect metrics related to coupling between
+ different software packages (groups of related classes) by measuring extensibility, dependency, and responsibility of
+ each package.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.mgmt.common.extend_supp/guidances/concepts/risk.xmi b/epf_prac_151/core.mgmt.common.extend_supp/guidances/concepts/risk.xmi
index 508b40c..2ad3184 100644
--- a/epf_prac_151/core.mgmt.common.extend_supp/guidances/concepts/risk.xmi
+++ b/epf_prac_151/core.mgmt.common.extend_supp/guidances/concepts/risk.xmi
@@ -1,171 +1,171 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_u6enMMM1EdmSIPI87WLu3g" name="risk,_0bsLgMlgEdmt3adZL5Dmdw" guid="_u6enMMM1EdmSIPI87WLu3g" changeDate="2010-07-19T11:29:32.000-0700" version="7.2.0">
- <mainDescription><h1>
- What is a Risk?
-</h1>
-<p>
- A risk is an uncertain event or condition that, if it occurs, will have a negative or positive effect on one or more
- project objectives [<a class="elementLinkWithUserText"
- href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#PMI"
- guid="_JlTPUM6aEdyuBO4ZIzcyig">PMI</a>]. Project risks may be seen as threats or opportunities. The latter means that
- taking a calculated risk may bring, for example, competitive advantage for a product or organization. If there are
- benefits associated with an opportunity, then you can take certain degrees of risk for a project to be successful [<a
- class="elementLinkWithUserText"
- href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#SEI99"
- guid="_JlTPUM6aEdyuBO4ZIzcyig">SEI99</a>].
-</p>
-<p>
- In everyday life a risk is an exposure to loss or injury: A factor, thing, element, or course involving uncertain
- danger. Similarly, in software development a risk is something that can compromise the success of a project. Examples
- of potential sources of risk in software development are listed below (see [<a class="elementLinkWithUserText"
- href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#SEI99"
- guid="_JlTPUM6aEdyuBO4ZIzcyig">SEI99</a>] for more details):
-</p>
-<ul>
- <li>
- Requirements
- </li>
- <li>
- Design
- </li>
- <li>
- Development process
- </li>
- <li>
- Work environment
- </li>
- <li>
- Resources
- </li>
- <li>
- Contract
- </li>
- <li>
- Project interdependencies
- </li>
- <li>
- And so on
- </li>
-</ul>
-<h1>
- Risk Attributes
-</h1>
-<p>
- You can record as much information as you like or need about your risks. You will find a list of common risk attributes
- following.
-</p>
-<ul>
- <li>
- <b>Risk Description:</b> A description of the risk detailing the impact for the project if this risk becomes a
- problem (that is, it becomes a reality).
- </li>
- <li>
- <b>Risk Category</b>: Risk identification is usually more easily done when there is a "mental framework" in place
- to ensure that potential areas of risk are not overlooked. One way of doing this is to divide risks into categories
- (such as technical, project management, organizational, and external), to ensure that all aspects of the project
- which are prone to risk are covered.
- </li>
- <li>
- <b>Risk Type:</b> Used to classify the risk as:
- </li>
- <li style="LIST-STYLE-TYPE: none">
- <ul>
- <li>
- Direct or Indirect risk: if the project has or does not have a large degree of control over the risk
- </li>
- <li>
- Resource&nbsp;risk: organization, people, funding, or time
- </li>
- <li>
- Business risk
- </li>
- <li>
- Technical risk: scope, technology, or external dependency
- </li>
- <li>
- Schedule risk
- </li>
- </ul>
- </li>
- <li>
- <b>Risk Probability:</b> How likely the risk event will happen. This is usually represented as a scale of values
- (for example: High, Medium, Low). Probability is one of the most difficult quantities to judge accurately.
- </li>
- <li>
- <b>Risk Impact</b> (level): If this risk becomes a problem, what will the impact on the project be? This is not the
- actual <b>description</b> of the impact, but the <b>level</b> of impact. As the risk probability, it is usually
- represented as a scale. This attribute is also sometimes called the <b>severity</b> of the risk.
- </li>
- <li>
- <b>Risk Magnitude</b>: To be able to rank and define which risks need to be mitigate first, the <b>Risk
- Probability</b> and <b>Risk Impact</b> attributes are often combined in a single <b>Risk</b> <b>Magnitude</b>
- indicator represented as a scale similar to the combined attributes.
- </li>
-</ul>
-<h1>
- Risk Response Strategies
-</h1>
-<p>
- The risk response should be in line with the significance of the risk. The strategies for handling risk cover two main
- types: negative risks and positive risks (or opportunities). Common response strategies for negative risks or threats
- include [<a class="elementLinkWithUserText"
- href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html"
- guid="_JlTPUM6aEdyuBO4ZIzcyig">BOE91</a>]:
-</p>
-<ul>
- <li>
- <b>Avoid</b>: Reorganize the project so that it cannot be affected by that risk (for example, removing work)
- </li>
- <li>
- <b>Mitigate</b>: Define actions to reduce the probability or the impact of the risk, removing it from the top of
- the list
- </li>
- <li>
- <b>Transfer</b>: Reorganize the project so that someone or something else bears the risk. It simply gives another
- party responsibility for its management. It doesn't eliminate the risk.
- </li>
-</ul>
-<p>
- Common response strategies for positive risks or opportunities include:
-</p>
-<ul class="noindent">
- <li>
- <b>Exploit</b>: Add work or reorganize the project to make sure that the opportunity occurs (it is the reverse of
- avoid)
- </li>
- <li>
- <b>Enhance</b>: Define actions to increase the probability or the positive impact of the risk (this is the reverse
- of mitigate)
- </li>
- <li>
- <b>Share</b>: Allocate the ownership of the opportunity to a third party who is best able to capture the
- opportunity for the benefit of the project.
- </li>
-</ul>
-<p>
- Another response strategy for both threats or opportunities is to <b>Accept</b>: Decide to live with the risk, and
- define a contingency plan.
-</p>
-<p>
- Some scenarios for software development may help to make these concepts more clear:
-</p>
-<ul>
- <li>
- You need to use a new framework. A risk avoidance strategy could be to drop this new framework and use another one
- that is already understood by the team.
- </li>
- <li>
- The application you are developing needs to communicate with a legacy system. A risk transfer strategy would be to
- have the legacy support team be responsible for providing the APIs to access the legacy system.
- </li>
- <li>
- You need to use new middleware. A risk mitigation strategy could be to build a prototype using this new middleware
- to validate that it will provide the features you need for your application.
- </li>
- <li>
- Your integrator is the only one who knows how to integrate the different components of your application. A
- contingency plan could be to identify a resource on another project that you could bring on if your integrator is
- sick, leaves the company, and so on.
- </li>
+ <mainDescription><h3>
+ What is a Risk?
+</h3>
+<p>
+ A risk is an uncertain event or condition that, if it occurs, will have a negative or positive effect on one or more
+ project objectives [<a class="elementLinkWithUserText"
+ href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#PMI"
+ guid="_JlTPUM6aEdyuBO4ZIzcyig">PMI</a>]. Project risks may be seen as threats or opportunities. The latter means that
+ taking a calculated risk may bring, for example, competitive advantage for a product or organization. If there are
+ benefits associated with an opportunity, then you can take certain degrees of risk for a project to be successful [<a
+ class="elementLinkWithUserText"
+ href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#SEI99"
+ guid="_JlTPUM6aEdyuBO4ZIzcyig">SEI99</a>].
+</p>
+<p>
+ In everyday life a risk is an exposure to loss or injury: A factor, thing, element, or course involving uncertain
+ danger. Similarly, in software development a risk is something that can compromise the success of a project. Examples
+ of potential sources of risk in software development are listed below (see [<a class="elementLinkWithUserText"
+ href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#SEI99"
+ guid="_JlTPUM6aEdyuBO4ZIzcyig">SEI99</a>] for more details):
+</p>
+<ul>
+ <li>
+ Requirements
+ </li>
+ <li>
+ Design
+ </li>
+ <li>
+ Development process
+ </li>
+ <li>
+ Work environment
+ </li>
+ <li>
+ Resources
+ </li>
+ <li>
+ Contract
+ </li>
+ <li>
+ Project interdependencies
+ </li>
+ <li>
+ And so on
+ </li>
+</ul>
+<h3>
+ Risk Attributes
+</h3>
+<p>
+ You can record as much information as you like or need about your risks. You will find a list of common risk attributes
+ following.
+</p>
+<ul>
+ <li>
+ <b>Risk Description:</b> A description of the risk detailing the impact for the project if this risk becomes a
+ problem (that is, it becomes a reality).
+ </li>
+ <li>
+ <b>Risk Category</b>: Risk identification is usually more easily done when there is a "mental framework" in place
+ to ensure that potential areas of risk are not overlooked. One way of doing this is to divide risks into categories
+ (such as technical, project management, organizational, and external), to ensure that all aspects of the project
+ which are prone to risk are covered.
+ </li>
+ <li>
+ <b>Risk Type:</b> Used to classify the risk as:
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <ul>
+ <li>
+ Direct or Indirect risk: if the project has or does not have a large degree of control over the risk
+ </li>
+ <li>
+ Resource&nbsp;risk: organization, people, funding, or time
+ </li>
+ <li>
+ Business risk
+ </li>
+ <li>
+ Technical risk: scope, technology, or external dependency
+ </li>
+ <li>
+ Schedule risk
+ </li>
+ </ul>
+ </li>
+ <li>
+ <b>Risk Probability:</b> How likely the risk event will happen. This is usually represented as a scale of values
+ (for example: High, Medium, Low). Probability is one of the most difficult quantities to judge accurately.
+ </li>
+ <li>
+ <b>Risk Impact</b> (level): If this risk becomes a problem, what will the impact on the project be? This is not the
+ actual <b>description</b> of the impact, but the <b>level</b> of impact. As the risk probability, it is usually
+ represented as a scale. This attribute is also sometimes called the <b>severity</b> of the risk.
+ </li>
+ <li>
+ <b>Risk Magnitude</b>: To be able to rank and define which risks need to be mitigate first, the <b>Risk
+ Probability</b> and <b>Risk Impact</b> attributes are often combined in a single <b>Risk</b> <b>Magnitude</b>
+ indicator represented as a scale similar to the combined attributes.
+ </li>
+</ul>
+<h3>
+ Risk Response Strategies
+</h3>
+<p>
+ The risk response should be in line with the significance of the risk. The strategies for handling risk cover two main
+ types: negative risks and positive risks (or opportunities). Common response strategies for negative risks or threats
+ include [<a class="elementLinkWithUserText"
+ href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html"
+ guid="_JlTPUM6aEdyuBO4ZIzcyig">BOE91</a>]:
+</p>
+<ul>
+ <li>
+ <b>Avoid</b>: Reorganize the project so that it cannot be affected by that risk (for example, removing work)
+ </li>
+ <li>
+ <b>Mitigate</b>: Define actions to reduce the probability or the impact of the risk, removing it from the top of
+ the list
+ </li>
+ <li>
+ <b>Transfer</b>: Reorganize the project so that someone or something else bears the risk. It simply gives another
+ party responsibility for its management. It doesn't eliminate the risk.
+ </li>
+</ul>
+<p>
+ Common response strategies for positive risks or opportunities include:
+</p>
+<ul class="noindent">
+ <li>
+ <b>Exploit</b>: Add work or reorganize the project to make sure that the opportunity occurs (it is the reverse of
+ avoid)
+ </li>
+ <li>
+ <b>Enhance</b>: Define actions to increase the probability or the positive impact of the risk (this is the reverse
+ of mitigate)
+ </li>
+ <li>
+ <b>Share</b>: Allocate the ownership of the opportunity to a third party who is best able to capture the
+ opportunity for the benefit of the project.
+ </li>
+</ul>
+<p>
+ Another response strategy for both threats or opportunities is to <b>Accept</b>: Decide to live with the risk, and
+ define a contingency plan.
+</p>
+<p>
+ Some scenarios for software development may help to make these concepts more clear:
+</p>
+<ul>
+ <li>
+ You need to use a new framework. A risk avoidance strategy could be to drop this new framework and use another one
+ that is already understood by the team.
+ </li>
+ <li>
+ The application you are developing needs to communicate with a legacy system. A risk transfer strategy would be to
+ have the legacy support team be responsible for providing the APIs to access the legacy system.
+ </li>
+ <li>
+ You need to use new middleware. A risk mitigation strategy could be to build a prototype using this new middleware
+ to validate that it will provide the features you need for your application.
+ </li>
+ <li>
+ Your integrator is the only one who knows how to integrate the different components of your application. A
+ contingency plan could be to identify a resource on another project that you could bring on if your integrator is
+ sick, leaves the company, and so on.
+ </li>
</ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.mgmt.common.extend_supp/guidances/guidelines/agile_estimation.xmi b/epf_prac_151/core.mgmt.common.extend_supp/guidances/guidelines/agile_estimation.xmi
index 3110d4d..8ca078e 100644
--- a/epf_prac_151/core.mgmt.common.extend_supp/guidances/guidelines/agile_estimation.xmi
+++ b/epf_prac_151/core.mgmt.common.extend_supp/guidances/guidelines/agile_estimation.xmi
@@ -1,129 +1,134 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_CYRMgBEdEdqY7JB6N6CW2w" name="agile_estimation,_CGHskBEdEdqY7JB6N6CW2w" guid="_CYRMgBEdEdqY7JB6N6CW2w" changeDate="2008-07-11T09:20:35.000-0700" version="7.2.0">
- <mainDescription><h3>
- Agile Estimation
-</h3>
-<p>
- There are three main concepts you need to understand to do agile estimation, see [<a class="elementLinkWithUserText" href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#COH05" guid="_9ToeIB83Edqsvps02rpOOg">COH05</a>] for more information:
-</p>
-<ul>
- <li>
- <strong>Estimation of Size</strong> gives a high-level estimate for the work item, typically measured using a
- neutral unit such as points
- </li>
- <li>
- <strong>Velocity</strong> tells us how many points this project team can deliver within an iteration;
- </li>
- <li>
- <strong>Estimation of Effort</strong> translates the size (measured in points) to a detailed estimate of effort
- typically using the units of Actual Days or Actual Hours. The estimation of effort indicates how long it will take
- the team member(s) to complete the assigned work item(s).
- </li>
-</ul>
-<h4>
- Estimation of Size
-</h4>
-<p>
- <strong>Points</strong> is a relative measure that can be used for agile estimation of size.&nbsp;The team decides how
- big a point is, and based on that size, determines how many points each work item is. To make estimation go fast, use
- only full points, 1, 2, 3, 5, 8, and so on, rather than fractions of a point, such 0.25, or 1.65 points. To get
- started, look at 10 or so representative work items, give the smallest the size of one point, and then go through all
- other work items and give them a relative point estimate based on that point. Note that points are used for high-level
- estimates, so do not spend too much time on any one item. This is especially true for work items of lower priority, to
- avoid wasting effort on things that are unlikely to be addressed within the current iteration.
-</p>
-<p>
- A key benefit of points is that they are neutral and relative. Let's say that Ann is 3 times more productive than Jack.
- If Ann and Jack agree that work item A is worth 1 point, and they both think work item B is roughly 5 times as big,
- they can rapidly agree that work item B is worth 5 points. Ann may however think work item B can be done in 12 hours,
- while Jack thinks it can be done in 36 hours. That is fine, they may disagree about the actual effort required to do
- it, but we do not care at this point in time, we only want the team to agree on the relative size. We will later use
- Velocity to determine how much 'size', or how many points, the team can take on within an iteration.
-</p>
-<p>
- One project team may say that a work item of a certain size is worth 1 point. Another project team would estimate the
- same sized work item to be worth 5 points. That is fine, as long as you are consistent within the same project. Make
- sure that the entire team is involved in assessing size, or at least that the same people are involved in all your size
- estimates, to ensure consistency within your project. We will see how the concept of velocity will fix also this
- discrepancy in a point meaning different things to different project teams.
-</p>
-<p>
- You can also use other measures of size, where the most common alternative is Ideal Days. See for example [<a class="elementLinkWithUserText" href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html" guid="_9ToeIB83Edqsvps02rpOOg">COH05</a>] for more information.
-</p>
-<h4>
- Velocity
-</h4>
-<p>
- Velocity is a key metric used for iteration planning. It indicates how many points are delivered upon within an
- iteration for a certain team and project. As an example, a team planned to accomplish 20 points in the first iteration.
- At the end of the iteration, they noticed that they only delivered upon 14 points, their velocity was hence 14. For the
- next iteration, they may plan for fewer points, let's say 18 points, since they think they can do a little better than
- in previous iteration. In this iteration, they delivered 17 points, giving them a velocity of 17.
-</p>
-<p>
- Expect the velocity to change from iteration to iteration. Some iterations go smoother than others, and points are not
- always identical in terms of effort. Some team members are more effective than others, and some problems end up being
- harder than others. Also, changes to the team structure, learning new skills, changes to the tool environment, better
- teaming, or more overhead with meetings or tasks external to the project will all impact velocity. In general, velocity
- typically increases during the project as the team builds skills and becomes more cohesive.
-</p>
-<p>
- Velocity compensates for differences between teams in terms of how big a point is. Let's assume that project team Alpha
- and project team Beta are equally efficient in developing software, and they run the same project in parallel. Team
- Alpha, however, assesses all work items as being worth 3 times as many points as team Beta's estimates. Team Alpha
- assesses work item A, B, C, and D to correspond to 30 points, and team Beta estimates the same work items to correspond
- to 10 points. Both teams deliver upon those 4 work items in the next iteration, giving team Alpha a velocity of 30, and
- team Beta a velocity of 10. It may sound as if team Alpha is more effective, but let's look at what happens when they
- plan the next iteration. They both want to take on work item E-H, which team Alpha has estimated to be 30 points, and
- team Beta as normal has estimated to be 1/3 as many points, or 10 points. Since a team can typically take on as many
- points as indicated by their velocity, they can both take on all of E-H. The end result is that it does not matter how
- big a point is, as long as you are consistent within your team.
-</p>
-<p>
- Velocity also averages out the efficiency of different team members. Let's look at an example; Let's assume that Ann
- always works 3 times as fast as Jack and Jane. Ann will perhaps deliver 9 points per iteration, and Jack and Jane 3
- points each per iteration. The velocity of that 3-person team will be 15 points. As mentioned above, Ann and Jack may
- not agree on how much effort is associated with a work item, but they can agree on how many points it is worth. Since
- the team velocity is 15, the velocity will automatically translate the point estimate to how much work can be taken on.
- As you switch team members, or as team members become more or less efficient, your velocity will change, and you can
- hence take on more or less points. This does however not require you to change the estimate of the size. The size is
- still the same, and the velocity will help you to calculate how much size you can deliver upon with the team at hand
- for that iteration.
-</p>
-<h4>
- Estimation of Effort
-</h4>
-<p>
- Estimation of Effort translates the size (measured in points) to a detailed estimate of effort typically using the
- units of Actual Days or Actual Hours. As you plan an iteration, you will take on a work item, such as detail, design,
- implement and test a scenario, which may be sized to 5 points. Since this is still a reasonably big work item, break it
- down&nbsp;into a number of smaller work items, such as 4 separate work items for Detailing, Designing, Implementing and
- Testing Server portion, and Implementing and Testing Client portion of the scenario. Team members are asked to sign up
- for the tasks, and then detail the&nbsp;estimate of the actual effort, measured in hours or days, for their tasks. In
- this case, the following actual estimates were done (with person responsible within parenthesis):
-</p>
-<ul>
- <li>
- Detailing scenario (Ann): 4 hours
- </li>
- <li>
- Designing scenario (Ann and Jack):&nbsp; 6 hours
- </li>
- <li>
- Implementing and Testing Server portion of scenario (Jack): 22 hours&nbsp;
- </li>
- <li>
- Implementing and Testing Client portion of scenario (Ann): 12 hours
- </li>
- <li>
- <strong>Total Effort Estimate for Scenario:</strong> 44 hours
- </li>
-</ul>
-<p>
- If other people would be assigned to the tasks, the estimated actual hours could be quite different. There is hence no
- point doing detailed estimates until you know who will do the work, and what actual problems you will run into. Often,
- some level of analysis and design of the work item needs to take place before a reasonable estimate can be done.
- Remember that estimates are still estimates, and a person assigned to a task should feel free (and be encouraged) to
- re-estimate the effort required to complete the task, so we have a realistic view of progress within an iteration.
+ <mainDescription><h3>
+ Agile Estimation
+</h3>
+<p>
+ There are three main concepts you need to understand to do agile estimation, see [<a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#COH05"
+ guid="_9ToeIB83Edqsvps02rpOOg">COH05</a>] for more information:
+</p>
+<ul>
+ <li>
+ <strong>Estimation of Size</strong> gives a high-level estimate for the work item, typically measured using a
+ neutral unit such as points
+ </li>
+ <li>
+ <strong>Velocity</strong> tells us how many points this project team can deliver within an iteration;
+ </li>
+ <li>
+ <strong>Estimation of Effort</strong> translates the size (measured in points) to a detailed estimate of effort
+ typically using the units of Actual Days or Actual Hours. The estimation of effort indicates how long it will take
+ the team member(s) to complete the assigned work item(s).
+ </li>
+</ul>
+<h4>
+ Estimation of Size
+</h4>
+<p>
+ <strong>Points</strong> is a relative measure that can be used for agile estimation of size.&nbsp;The team decides how
+ big a point is, and based on that size, determines how many points each work item is. To make estimation go fast, use
+ only full points, 1, 2, 3, 5, 8, and so on, rather than fractions of a point, such 0.25, or 1.65 points. To get
+ started, look at 10 or so representative work items, give the smallest the size of one point, and then go through all
+ other work items and give them a relative point estimate based on that point. Note that points are used for high-level
+ estimates, so do not spend too much time on any one item. This is especially true for work items of lower priority, to
+ avoid wasting effort on things that are unlikely to be addressed within the current iteration.
+</p>
+<p>
+ A key benefit of points is that they are neutral and relative. Let's say that Ann is 3 times more productive than Jack.
+ If Ann and Jack agree that work item A is worth 1 point, and they both think work item B is roughly 5 times as big,
+ they can rapidly agree that work item B is worth 5 points. Ann may however think work item B can be done in 12 hours,
+ while Jack thinks it can be done in 36 hours. That is fine, they may disagree about the actual effort required to do
+ it, but we do not care at this point in time, we only want the team to agree on the relative size. We will later use
+ Velocity to determine how much 'size', or how many points, the team can take on within an iteration.
+</p>
+<p>
+ One project team may say that a work item of a certain size is worth 1 point. Another project team would estimate the
+ same sized work item to be worth 5 points. That is fine, as long as you are consistent within the same project. Make
+ sure that the entire team is involved in assessing size, or at least that the same people are involved in all your size
+ estimates, to ensure consistency within your project. We will see how the concept of velocity will fix also this
+ discrepancy in a point meaning different things to different project teams.
+</p>
+<p>
+ You can also use other measures of size, where the most common alternative is Ideal Days. See for example [<a
+ class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">COH05</a>] for more information.
+</p>
+<h4>
+ Velocity
+</h4>
+<p>
+ Velocity is a key metric used for iteration planning. It indicates how many points are delivered upon within an
+ iteration for a certain team and project. As an example, a team planned to accomplish 20 points in the first iteration.
+ At the end of the iteration, they noticed that they only delivered upon 14 points, their velocity was hence 14. For the
+ next iteration, they may plan for fewer points, let's say 18 points, since they think they can do a little better than
+ in previous iteration. In this iteration, they delivered 17 points, giving them a velocity of 17.
+</p>
+<p>
+ Expect the velocity to change from iteration to iteration. Some iterations go smoother than others, and points are not
+ always identical in terms of effort. Some team members are more effective than others, and some problems end up being
+ harder than others. Also, changes to the team structure, learning new skills, changes to the tool environment, better
+ teaming, or more overhead with meetings or tasks external to the project will all impact velocity. In general, velocity
+ typically increases during the project as the team builds skills and becomes more cohesive.
+</p>
+<p>
+ Velocity compensates for differences between teams in terms of how big a point is. Let's assume that project team Alpha
+ and project team Beta are equally efficient in developing software, and they run the same project in parallel. Team
+ Alpha, however, assesses all work items as being worth 3 times as many points as team Beta's estimates. Team Alpha
+ assesses work item A, B, C, and D to correspond to 30 points, and team Beta estimates the same work items to correspond
+ to 10 points. Both teams deliver upon those 4 work items in the next iteration, giving team Alpha a velocity of 30, and
+ team Beta a velocity of 10. It may sound as if team Alpha is more effective, but let's look at what happens when they
+ plan the next iteration. They both want to take on work item E-H, which team Alpha has estimated to be 30 points, and
+ team Beta as normal has estimated to be 1/3 as many points, or 10 points. Since a team can typically take on as many
+ points as indicated by their velocity, they can both take on all of E-H. The end result is that it does not matter how
+ big a point is, as long as you are consistent within your team.
+</p>
+<p>
+ Velocity also averages out the efficiency of different team members. Let's look at an example; Let's assume that Ann
+ always works 3 times as fast as Jack and Jane. Ann will perhaps deliver 9 points per iteration, and Jack and Jane 3
+ points each per iteration. The velocity of that 3-person team will be 15 points. As mentioned above, Ann and Jack may
+ not agree on how much effort is associated with a work item, but they can agree on how many points it is worth. Since
+ the team velocity is 15, the velocity will automatically translate the point estimate to how much work can be taken on.
+ As you switch team members, or as team members become more or less efficient, your velocity will change, and you can
+ hence take on more or less points. This does however not require you to change the estimate of the size. The size is
+ still the same, and the velocity will help you to calculate how much size you can deliver upon with the team at hand
+ for that iteration.
+</p>
+<h4>
+ Estimation of Effort
+</h4>
+<p>
+ Estimation of Effort translates the size (measured in points) to a detailed estimate of effort typically using the
+ units of Actual Days or Actual Hours. As you plan an iteration, you will take on a work item, such as detail, design,
+ implement and test a scenario, which may be sized to 5 points. Since this is still a reasonably big work item, break it
+ down&nbsp;into a number of smaller work items, such as 4 separate work items for Detailing, Designing, Implementing and
+ Testing Server portion, and Implementing and Testing Client portion of the scenario. Team members are asked to sign up
+ for the tasks, and then detail the&nbsp;estimate of the actual effort, measured in hours or days, for their tasks. In
+ this case, the following actual estimates were done (with person responsible within parenthesis):
+</p>
+<ul>
+ <li>
+ Detailing scenario (Ann): 4 hours
+ </li>
+ <li>
+ Designing scenario (Ann and Jack):&nbsp; 6 hours
+ </li>
+ <li>
+ Implementing and Testing Server portion of scenario (Jack): 22 hours&nbsp;
+ </li>
+ <li>
+ Implementing and Testing Client portion of scenario (Ann): 12 hours
+ </li>
+ <li>
+ <strong>Total Effort Estimate for Scenario:</strong> 44 hours
+ </li>
+</ul>
+<p>
+ If other people would be assigned to the tasks, the estimated actual hours could be quite different. There is hence no
+ point doing detailed estimates until you know who will do the work, and what actual problems you will run into. Often,
+ some level of analysis and design of the work item needs to take place before a reasonable estimate can be done.
+ Remember that estimates are still estimates, and a person assigned to a task should feel free (and be encouraged) to
+ re-estimate the effort required to complete the task, so we have a realistic view of progress within an iteration.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.mgmt.common.extend_supp/guidances/guidelines/assign_changes_to_iteration.xmi b/epf_prac_151/core.mgmt.common.extend_supp/guidances/guidelines/assign_changes_to_iteration.xmi
index 94deb5c..ef24e33 100644
--- a/epf_prac_151/core.mgmt.common.extend_supp/guidances/guidelines/assign_changes_to_iteration.xmi
+++ b/epf_prac_151/core.mgmt.common.extend_supp/guidances/guidelines/assign_changes_to_iteration.xmi
@@ -1,32 +1,32 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-bUmvEAAtFf6B0aUCux8k9Q" name="changes_at_iter_bound,__yQQ4L6REdqti4GwqTkbsQ" guid="-bUmvEAAtFf6B0aUCux8k9Q" changeDate="2008-07-11T11:49:31.000-0700" version="7.2.0">
- <mainDescription><p>
- Most iterative software development processes recommend that changes not be introduced during an iteration. The main
- idea is that the iterations should be short and with clearly defined scope so that they can be time-boxed.
-</p>
-<p>
- To limit scope within an iteration, change requests are reviewed and prioritized as soon as possible, but are not
- assigned for implementation until a future iteration via the work items list.
-</p>
-<p>
- Since iterations are relatively short this should not cause undue delay in dealing with urgent and important change
- requests.
-</p>
-<p>
- One notable exception is a defect discovered during testing that prevents the team from meeting the objectives of the
- iteration. In this case it is reasonable to assign the work item to the current iteration as this does not represent a
- scope change, it represents unfinished work.
-</p>
-<p>
- Consider the following when choosing the future iteration where the change request will be addressed:
-</p>
-<ul>
- <li>
- Group similar change requests in the same iteration. For example multiple change requests focused on the same
- functionality or that are dependent on each other.
- </li>
- <li>
- Assign change requests that mitigate high risks to the earliest iteration possible.
- </li>
+ <mainDescription><p>
+ Most iterative software development processes recommend that changes not be introduced during an iteration. The main
+ idea is that the iterations should be short and with clearly defined scope so that they can be time-boxed.
+</p>
+<p>
+ To limit scope within an iteration, change requests are reviewed and prioritized as soon as possible, but are not
+ assigned for implementation until a future iteration via the work items list.
+</p>
+<p>
+ Since iterations are relatively short this should not cause undue delay in dealing with urgent and important change
+ requests.
+</p>
+<p>
+ One notable exception is a defect discovered during testing that prevents the team from meeting the objectives of the
+ iteration. In this case it is reasonable to assign the work item to the current iteration as this does not represent a
+ scope change, it represents unfinished work.
+</p>
+<p>
+ Consider the following when choosing the future iteration where the change request will be addressed:
+</p>
+<ul>
+ <li>
+ Group similar change requests in the same iteration. For example multiple change requests focused on the same
+ functionality or that are dependent on each other.
+ </li>
+ <li>
+ Assign change requests that mitigate high risks to the earliest iteration possible.
+ </li>
</ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.mgmt.common.extend_supp/guidances/guidelines/deploying_the_solution.xmi b/epf_prac_151/core.mgmt.common.extend_supp/guidances/guidelines/deploying_the_solution.xmi
index 45f6e4e..723bc20 100644
--- a/epf_prac_151/core.mgmt.common.extend_supp/guidances/guidelines/deploying_the_solution.xmi
+++ b/epf_prac_151/core.mgmt.common.extend_supp/guidances/guidelines/deploying_the_solution.xmi
@@ -1,88 +1,88 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-aOaMjqW4RZWOiHT1_U1NNw" name="deploying_the_solution,_yYlQoC3xEdycYKq0PulnEQ" guid="-aOaMjqW4RZWOiHT1_U1NNw" changeDate="2009-07-08T01:22:35.000-0700" version="7.5.0">
- <mainDescription><h3>
- Planning transition iterations
-</h3>
-<p>
- Software may be deployed into a production environment at the end of any Construction or Transition iteration.
- Deployment to production before the end of the project may be done to drive down risk by validating the application,
- deployment scripts, deployment environment, and to get valuable feedback from operations and systems teams, as well as
- end users. These early deployments are often done on a limited scale in terms of target audience or only partial
- applications are deployed. For the deployment to work, one or several iterations are focused on work necessary to
- successfully release the system. In the Transition phase, one or several iterations may be dedicated to preparing for a
- smooth deployment. The number of iterations depends on the complexity of the system and various other factors, as
- listed here. When planning for deployment, the Work Items list should be updated with relevant tasks related to these
- considerations:
-</p>
-<ul>
- <li>
- Resolving defects
- </li>
- <li>
- Testing installation or deployment scripts to avoid surprises in actual deployment&nbsp;
- </li>
- <li>
- Updating any&nbsp;operations&nbsp;and support test environments used to simulate production problems
- </li>
- <li>
- Performing release-specific testing efforts, such as pilot or beta testing,to a subset of your end-user community
- where the system is deployed
- </li>
- <li>
- Conducting acceptance reviews with stakeholders, including a&nbsp;final release acceptance testing effort where
- people outside of the team are involved and decide whether it truly meets their needs
- </li>
- <li>
- Finalizing relevant documentation, such as operations and system manuals, end-user documentation and release notes
- </li>
- <li>
- Creating&nbsp;physical collateral, such as installation media
- </li>
- <li>
- Replacing or installing physical assets, or both, including workstations, servers, and network components
- </li>
- <li>
- Replacing existing software with new versions
- </li>
- <li>
- Updating existing databases, including any relevant data migration and database schema changes
- </li>
- <li>
- Production data population
- </li>
- <li>
- Training end users and operations&nbsp;and support staff
- </li>
- <li>
- Fixing any discrepancies discovered during the transition phase
- </li>
- <li>
- Setting up management and operational systems and processes
- </li>
- <li>
- Training the team that is taking over maintenance and evolution of the system
- </li>
- <li>
- Deploying the software to the production environment
- </li>
-</ul>
-<p>
- When the team and stakeholders are reviewing late Construction and early Transition iterations, the team should gather
- feedback from actual stakeholders' use of the product and take that information into consideration when prioritizing
- the work for the next iteration.
-</p>
-<p>
- See [<a class="elementLinkWithUserText"
- href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#AMB07"
- guid="_9ToeIB83Edqsvps02rpOOg">AMB07</a>]&nbsp; for more information.
-</p>
-<h3>
- Reviewing transition iterations
-</h3>
-<p>
- Transition iteration reviews have a different focus from other iterations in the project lifecycle. The goal is not to
- brainstorm about what&nbsp;features to develop next. Instead, reviews will assess the release management resources and
- procedures, the quality of the software,&nbsp;and how prepared users and operations teams are to face a move of the
- software into the production environment.
+ <mainDescription><h3>
+ Planning transition iterations
+</h3>
+<p>
+ Software may be deployed into a production environment at the end of any Construction or Transition iteration.
+ Deployment to production before the end of the project may be done to drive down risk by validating the application,
+ deployment scripts, deployment environment, and to get valuable feedback from operations and systems teams, as well as
+ end users. These early deployments are often done on a limited scale in terms of target audience or only partial
+ applications are deployed. For the deployment to work, one or several iterations are focused on work necessary to
+ successfully release the system. In the Transition phase, one or several iterations may be dedicated to preparing for a
+ smooth deployment. The number of iterations depends on the complexity of the system and various other factors, as
+ listed here. When planning for deployment, the Work Items list should be updated with relevant tasks related to these
+ considerations:
+</p>
+<ul>
+ <li>
+ Resolving defects
+ </li>
+ <li>
+ Testing installation or deployment scripts to avoid surprises in actual deployment&nbsp;
+ </li>
+ <li>
+ Updating any&nbsp;operations&nbsp;and support test environments used to simulate production problems
+ </li>
+ <li>
+ Performing release-specific testing efforts, such as pilot or beta testing,to a subset of your end-user community
+ where the system is deployed
+ </li>
+ <li>
+ Conducting acceptance reviews with stakeholders, including a&nbsp;final release acceptance testing effort where
+ people outside of the team are involved and decide whether it truly meets their needs
+ </li>
+ <li>
+ Finalizing relevant documentation, such as operations and system manuals, end-user documentation and release notes
+ </li>
+ <li>
+ Creating&nbsp;physical collateral, such as installation media
+ </li>
+ <li>
+ Replacing or installing physical assets, or both, including workstations, servers, and network components
+ </li>
+ <li>
+ Replacing existing software with new versions
+ </li>
+ <li>
+ Updating existing databases, including any relevant data migration and database schema changes
+ </li>
+ <li>
+ Production data population
+ </li>
+ <li>
+ Training end users and operations&nbsp;and support staff
+ </li>
+ <li>
+ Fixing any discrepancies discovered during the transition phase
+ </li>
+ <li>
+ Setting up management and operational systems and processes
+ </li>
+ <li>
+ Training the team that is taking over maintenance and evolution of the system
+ </li>
+ <li>
+ Deploying the software to the production environment
+ </li>
+</ul>
+<p>
+ When the team and stakeholders are reviewing late Construction and early Transition iterations, the team should gather
+ feedback from actual stakeholders' use of the product and take that information into consideration when prioritizing
+ the work for the next iteration.
+</p>
+<p>
+ See [<a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#AMB07"
+ guid="_9ToeIB83Edqsvps02rpOOg">AMB07</a>]&nbsp; for more information.
+</p>
+<h3>
+ Reviewing transition iterations
+</h3>
+<p>
+ Transition iteration reviews have a different focus from other iterations in the project lifecycle. The goal is not to
+ brainstorm about what&nbsp;features to develop next. Instead, reviews will assess the release management resources and
+ procedures, the quality of the software,&nbsp;and how prepared users and operations teams are to face a move of the
+ software into the production environment.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.mgmt.common.extend_supp/plugin.xmi b/epf_prac_151/core.mgmt.common.extend_supp/plugin.xmi
index 2357bd0..4cab90b 100644
--- a/epf_prac_151/core.mgmt.common.extend_supp/plugin.xmi
+++ b/epf_prac_151/core.mgmt.common.extend_supp/plugin.xmi
@@ -76,7 +76,7 @@
<contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_xlrdEAVtEdy3F_fZDaPZVA" name="work_items_list" guid="_xlrdEAVtEdy3F_fZDaPZVA" presentationName="Work Items List" briefDescription="This checklist is used to verify that every kind of work to be done in the project 
is being tracked">
<presentation xmi:id="-BTXdT-1bO6nbAPf25q0_yA" href="uma://-BTXdT-1bO6nbAPf25q0_yA#-BTXdT-1bO6nbAPf25q0_yA"/>
</contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_2CEzsLrREd-0rKmWr1vEGQ" name="project_defined_process" guid="_2CEzsLrREd-0rKmWr1vEGQ" presentationName="Project Defined Process" briefDescription="This work product describes the process that a project is to follow in order to produce the project's desired results. ">
+ <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_2CEzsLrREd-0rKmWr1vEGQ" name="project_defined_process" guid="_2CEzsLrREd-0rKmWr1vEGQ" presentationName="Project Defined Process" briefDescription="This work product describes the process that a project is to follow in order to produce the project's desired results.">
<presentation xmi:id="-wBOoiWwZUP1LDeCTqoNMBQ" href="uma://-wBOoiWwZUP1LDeCTqoNMBQ#-wBOoiWwZUP1LDeCTqoNMBQ"/>
</contentElements>
<contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_wGK8ULrZEd-0rKmWr1vEGQ" name="project_defined_process" guid="_wGK8ULrZEd-0rKmWr1vEGQ" presentationName="Project Defined Process">
diff --git a/epf_prac_151/core.mgmt.common.extend_supp/workproducts/project_defined_process 2.xmi b/epf_prac_151/core.mgmt.common.extend_supp/workproducts/project_defined_process 2.xmi
index 380021d..f41f3b6 100644
--- a/epf_prac_151/core.mgmt.common.extend_supp/workproducts/project_defined_process 2.xmi
+++ b/epf_prac_151/core.mgmt.common.extend_supp/workproducts/project_defined_process 2.xmi
@@ -1,33 +1,36 @@
<?xml version="1.0" encoding="UTF-8"?>
-<org.eclipse.epf.uma:ArtifactDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmi:id="-wBOoiWwZUP1LDeCTqoNMBQ" name="new_artifact,_2CEzsLrREd-0rKmWr1vEGQ" guid="-wBOoiWwZUP1LDeCTqoNMBQ" changeDate="2010-09-07T15:48:43.389-0700">
+<org.eclipse.epf.uma:ArtifactDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-wBOoiWwZUP1LDeCTqoNMBQ" name="new_artifact,_2CEzsLrREd-0rKmWr1vEGQ" guid="-wBOoiWwZUP1LDeCTqoNMBQ" changeDate="2010-09-07T15:48:43.389-0700" version="7.5.1">
<mainDescription><p>
A project process typically describes or references the following items:
</p>
<ul>
<li>
- what organizational processes and policies must be adhered to
+ what organizational processes and policies must be adhered to.
</li>
<li>
- what standard process, if any, is being adopted by the project
+ what standard process, if any, is being adopted by the project.
</li>
<li>
- any tailoring of the standard process, or deviations from policy mandates
+ any tailoring of the standard process, or deviations from policy mandates.
</li>
<li>
- rationale for tailoring and deviations (and approvals if required)
+ rationale for tailoring and deviations.
</li>
<li>
- which work products are reviewed at which milestones, and their level of completion
+ approvals for deviations.
</li>
<li>
- guidelines and information that the project wants to use in addition to the information contained in the main
+ which work products are reviewed at which milestones, and their level of completion.
+ </li>
+ <li>
+ guidelines and information that the project wants to use in addition to the information contained in the main.
process
</li>
<li>
- what reviews will be performed, and their level of formality
+ what reviews will be performed, and their level of formality.
</li>
<li>
- what approvals are required, by whom, and when<br />
+ what approvals are required, by whom, and when.
</li>
</ul></mainDescription>
<purpose>The purpose of the project process is to provide guidance and support for the members of the project. "Information at your
diff --git a/epf_prac_151/core.mgmt.common.extend_supp/workproducts/risk_list.xmi b/epf_prac_151/core.mgmt.common.extend_supp/workproducts/risk_list.xmi
index c9f1c6e..830c7c1 100644
--- a/epf_prac_151/core.mgmt.common.extend_supp/workproducts/risk_list.xmi
+++ b/epf_prac_151/core.mgmt.common.extend_supp/workproducts/risk_list.xmi
@@ -1,15 +1,18 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ArtifactDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-4VJ_0upihz-bR7VRlm63Vw" name="risk_list,_Ckay8Cc_EduIsqH1Q6ZuqA" guid="-4VJ_0upihz-bR7VRlm63Vw" changeDate="2008-09-15T01:32:19.000-0700" version="7.2.0">
- <mainDescription><p>
- This list identifies, in decreasing order of priority, all the <a class="elementLinkWithUserText" href="./../../core.mgmt.common.base/guidances/termdefinitions/risk_33255339.html" guid="_ii2LUEvGEdunZcj9T5hrMQ">risks</a> associated to a project.&nbsp;It serves as a focal point for project
- activities, and is the basis around which iterations are organized.
-</p>
-<p>
- See <a class="elementLinkWithType" href="./../../core.mgmt.common.extend_supp/guidances/concepts/risk_AF5840DA.html" guid="_0bsLgMlgEdmt3adZL5Dmdw">Concept: Risk</a>&nbsp;for more details.<!--EndFragment-->
+ <mainDescription><p>
+ This list identifies, in decreasing order of priority, all the <a class="elementLinkWithUserText"
+ href="./../../core.mgmt.common.base/guidances/termdefinitions/risk_33255339.html"
+ guid="_ii2LUEvGEdunZcj9T5hrMQ">risks</a> associated to a project.&nbsp;It serves as a focal point for project
+ activities, and is the basis around which iterations are organized.
+</p>
+<p>
+ See <a class="elementLinkWithType" href="./../../core.mgmt.common.extend_supp/guidances/concepts/risk_AF5840DA.html"
+ guid="_0bsLgMlgEdmt3adZL5Dmdw">Concept: Risk</a>&nbsp;for more details.<!--EndFragment-->
</p></mainDescription>
- <keyConsiderations><p>
- This list should capture the critical and serious risks. If you find this list extending beyond 20 items, carefully consider
- whether they are really serious risks. Tracking more than 20 risks is an onerous task.
+ <keyConsiderations><p>
+ This list should capture the critical and serious risks. If you find this list extending beyond 20 items, carefully
+ consider whether they are really serious risks. Tracking more than 20 risks is an onerous task.
</p></keyConsiderations>
<purpose>To&nbsp;capture the perceived risks to the success of the project.</purpose>
<impactOfNotHaving>If risks are not identified, then the required mitigation strategies will not be in place, and&nbsp;any adverse events that
diff --git a/epf_prac_151/core.mgmt.common.extend_supp/workproducts/work_items_list.xmi b/epf_prac_151/core.mgmt.common.extend_supp/workproducts/work_items_list.xmi
index 1c26ebf..50bd522 100644
--- a/epf_prac_151/core.mgmt.common.extend_supp/workproducts/work_items_list.xmi
+++ b/epf_prac_151/core.mgmt.common.extend_supp/workproducts/work_items_list.xmi
@@ -1,55 +1,55 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ArtifactDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-buxz4BVToq97bSxaqyjySg" name="work_items_list,_rGNWsCbSEdqh1LYUOGRh2A" guid="-buxz4BVToq97bSxaqyjySg" changeDate="2008-10-08T09:41:03.000-0700" version="1.0.0">
- <mainDescription><p>
- This artifact provides a focal point for the entire team:
-</p>
-<ul>
- <li>
- It provides one list containing all requests for additional capabilities or enhancement for that application. Note
- that some of these requests may never be implemented, or be implemented in later projects.
- </li>
- <li>
- It provides one list of all the work to be prioritized, estimated, and assigned within the project. The risk list
- is prioritized separately.
- </li>
- <li>
- It provides one place to go to for the development team to understand what&nbsp;micro-increments&nbsp;need to be
- delivered, get references to material required to carry out the work, and report progress made.
- </li>
-</ul>
-<p>
- These are the typical work items that go on this list:
-</p>
-<ul>
- <li>
- Use cases (and references to use-case specifications)
- </li>
- <li>
- System-wide requirements
- </li>
- <li>
- Changes and enhancement requests
- </li>
- <li>
- Defects
- </li>
- <li>
- Development tasks
- </li>
-</ul>
-<p>
- Work items can be very large in scope, especially when capturing requests for enhancements, such as "Support Financial
- Planning" for a personal finance application. To allow the application to be developed in micro-increments, work items
- are analyzed and broken down into smaller work items so that they can be assigned to an iteration, such as a use-case
- scenario for&nbsp;"Calculate Net Worth". Further breakdown may be required to identify suitable tasks to be assigned to
- developers, such as "Develop UI for Calculate Net Worth". This means that work items often have parent/child
- relationships, where the lowest level is a specification and tracking device for micro-increments.
+ <mainDescription><p>
+ This artifact provides a focal point for the entire team:
+</p>
+<ul>
+ <li>
+ It provides one list containing all requests for additional capabilities or enhancement for that application. Note
+ that some of these requests may never be implemented, or be implemented in later projects.
+ </li>
+ <li>
+ It provides one list of all the work to be prioritized, estimated, and assigned within the project. The risk list
+ is prioritized separately.
+ </li>
+ <li>
+ It provides one place to go to for the development team to understand what&nbsp;micro-increments&nbsp;need to be
+ delivered, get references to material required to carry out the work, and report progress made.
+ </li>
+</ul>
+<p>
+ These are the typical work items that go on this list:
+</p>
+<ul>
+ <li>
+ Use cases (and references to use-case specifications)
+ </li>
+ <li>
+ System-wide requirements
+ </li>
+ <li>
+ Changes and enhancement requests
+ </li>
+ <li>
+ Defects
+ </li>
+ <li>
+ Development tasks
+ </li>
+</ul>
+<p>
+ Work items can be very large in scope, especially when capturing requests for enhancements, such as "Support Financial
+ Planning" for a personal finance application. To allow the application to be developed in micro-increments, work items
+ are analyzed and broken down into smaller work items so that they can be assigned to an iteration, such as a use-case
+ scenario for&nbsp;"Calculate Net Worth". Further breakdown may be required to identify suitable tasks to be assigned to
+ developers, such as "Develop UI for Calculate Net Worth". This means that work items often have parent/child
+ relationships, where the lowest level is a specification and tracking device for micro-increments.
</p></mainDescription>
- <keyConsiderations><p>
- Work Items should contain estimates. See guidelines on managing work items and agile estimation.
+ <keyConsiderations><p>
+ Work Items should contain estimates. See guidelines on managing work items and agile estimation.
</p></keyConsiderations>
- <purpose>To collect all requests for work that will potentially be taken on within the project, so that work can be prioritized, effort
-estimated, and progress tracked.</purpose>
+ <purpose>To collect all requests for work that will potentially be taken on within the project, so that work can be prioritized,
+effort estimated, and progress tracked.</purpose>
<impactOfNotHaving>Without this artifact, there is not a single place that provides a list of all of the work to be done and its current
status.&nbsp; Individual team members may also be unclear as to&nbsp;what work has been&nbsp;assigned to them.</impactOfNotHaving>
<reasonsForNotNeeding>This artifact may not be needed&nbsp;if the work assignments are going to be managed using a different technique or
@@ -93,7 +93,9 @@
</ul></briefOutline>
<representationOptions><p>
The recommended representation for the&nbsp;work items list is to&nbsp;capture it&nbsp;as a separate artifact,
- represented by a spreadsheet or database table. See <a class="elementLinkWithType" href="./../../core.mgmt.common.extend_supp/guidances/examples/work_items_list_F527B77D.html" guid="_nHomIDgzEdu4E8ZdmlYjtA">Example: Work Items List</a>.
+ represented by a spreadsheet or database table. See <a class="elementLinkWithType"
+ href="./../../core.mgmt.common.extend_supp/guidances/examples/work_items_list_F527B77D.html"
+ guid="_nHomIDgzEdu4E8ZdmlYjtA">Example: Work Items List</a>.
</p>
<p>
Alternatively, the work items list may be captured in tools such as project management, requirements management, or
diff --git a/epf_prac_151/core.mgmt.slot.base/guidances/guidelines/collaboration_guidance_slot.xmi b/epf_prac_151/core.mgmt.slot.base/guidances/guidelines/collaboration_guidance_slot.xmi
index dfd379e..2ea80b0 100644
--- a/epf_prac_151/core.mgmt.slot.base/guidances/guidelines/collaboration_guidance_slot.xmi
+++ b/epf_prac_151/core.mgmt.slot.base/guidances/guidelines/collaboration_guidance_slot.xmi
@@ -1,13 +1,16 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-_gTtsZg2sOCefRSeAo-bJg" name="collaboration_guidance_slot,_68JUYN8-Edyhmsbt0Xyl8A" guid="-_gTtsZg2sOCefRSeAo-bJg" changeDate="2008-08-11T09:50:50.000-0700" version="7.5.0">
- <mainDescription><p>
- Effective communication and collaboration among the whole team are important aspects of successful projects, no matter
- the size of the project or methodology followed by the team. The whole team (including customers, developers, managers,
- quality assurance team, technical writers, and everyone else involved with the project) collaborates with one purpose
- in mind: to achieve the goals for a project, delivering the results of a project on time and within budget. The whole
- team collaborates and constantly communicates on what the goals are and how they will be attained. <a class="elementlinkwithusertext" href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#POL08" guid="_JlTPUM6aEdyuBO4ZIzcyig">[POL08]</a>
-</p>
-<p>
- This guideline is a placeholder for&nbsp;collaboration guidelines contributed by other practices.
+ <mainDescription><p>
+ Effective communication and collaboration among the whole team are important aspects of successful projects, no matter
+ the size of the project or methodology followed by the team. The whole team (including customers, developers, managers,
+ quality assurance team, technical writers, and everyone else involved with the project) collaborates with one purpose
+ in mind: to achieve the goals for a project, delivering the results of a project on time and within budget. The whole
+ team collaborates and constantly communicates on what the goals are and how they will be attained. <a
+ class="elementlinkwithusertext"
+ href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#POL08"
+ guid="_JlTPUM6aEdyuBO4ZIzcyig">[POL08]</a>
+</p>
+<p>
+ This guideline is a placeholder for&nbsp;collaboration guidelines contributed by other practices.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.mgmt.slot.base/guidances/guidelines/project_planning_guidance_slot.xmi b/epf_prac_151/core.mgmt.slot.base/guidances/guidelines/project_planning_guidance_slot.xmi
index 40a8a1e..f517897 100644
--- a/epf_prac_151/core.mgmt.slot.base/guidances/guidelines/project_planning_guidance_slot.xmi
+++ b/epf_prac_151/core.mgmt.slot.base/guidances/guidelines/project_planning_guidance_slot.xmi
@@ -1,9 +1,9 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-WHNPkIsytVNbT2cosOFSCA" name="project_planning_guidance_slot,_sLQ6AN8-Edyhmsbt0Xyl8A" guid="-WHNPkIsytVNbT2cosOFSCA" changeDate="2008-08-11T09:50:19.000-0700" version="7.5.0">
- <mainDescription><p>
- Project planning can be affected by other practices, such as practices for risk, requirements, and test management.
-</p>
-<p>
- This guideline is a placeholder for project planning guidelines contributed by other practices.
+ <mainDescription><p>
+ Project planning can be affected by other practices, such as practices for risk, requirements, and test management.
+</p>
+<p>
+ This guideline is a placeholder for project planning guidelines contributed by other practices.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.mgmt.slot.base/guidances/guidelines/work_assignment_guidance_slot.xmi b/epf_prac_151/core.mgmt.slot.base/guidances/guidelines/work_assignment_guidance_slot.xmi
index ea13a75..e546e2d 100644
--- a/epf_prac_151/core.mgmt.slot.base/guidances/guidelines/work_assignment_guidance_slot.xmi
+++ b/epf_prac_151/core.mgmt.slot.base/guidances/guidelines/work_assignment_guidance_slot.xmi
@@ -1,10 +1,10 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-J3F-VWcgroOkoPGMGKyl8A" name="work_assignment_guidance_slot,_BslGYN8_Edyhmsbt0Xyl8A" guid="-J3F-VWcgroOkoPGMGKyl8A" changeDate="2008-08-11T09:51:20.000-0700" version="7.5.0">
- <mainDescription><p>
- One of the basic responsibilities of the project manager is to make sure work is taken by team members, whether team
- members sign up for doing work or the project manager assigns work to individuals.
-</p>
-<p>
- This guideline is a placeholder for&nbsp;work assignment&nbsp;guidelines contributed by other practices.
+ <mainDescription><p>
+ One of the basic responsibilities of the project manager is to make sure work is taken by team members, whether team
+ members sign up for doing work or the project manager assigns work to individuals.
+</p>
+<p>
+ This guideline is a placeholder for&nbsp;work assignment&nbsp;guidelines contributed by other practices.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.base/guidances/termdefinitions/architectural_mechanism.xmi b/epf_prac_151/core.tech.common.base/guidances/termdefinitions/architectural_mechanism.xmi
index 7529b1b..81f5db3 100644
--- a/epf_prac_151/core.tech.common.base/guidances/termdefinitions/architectural_mechanism.xmi
+++ b/epf_prac_151/core.tech.common.base/guidances/termdefinitions/architectural_mechanism.xmi
@@ -1,5 +1,5 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-Vvwb6EupIB9kfSQ_mhjURA" name="architectural_mechanism,_VHFGkEvCEdunZcj9T5hrMQ" guid="-Vvwb6EupIB9kfSQ_mhjURA" changeDate="2006-09-24T05:46:41.000-0700" version="7.2.0">
- <mainDescription>Architectural mechanisms represent common concrete solutions to frequently encountered problems. They may be patterns of
+ <mainDescription>Architectural mechanisms represent common concrete solutions to frequently encountered problems. They may be patterns of
structure, patterns of behavior, or both.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.base/guidances/termdefinitions/architecture.xmi b/epf_prac_151/core.tech.common.base/guidances/termdefinitions/architecture.xmi
index b92e918..a3ffdda 100644
--- a/epf_prac_151/core.tech.common.base/guidances/termdefinitions/architecture.xmi
+++ b/epf_prac_151/core.tech.common.base/guidances/termdefinitions/architecture.xmi
@@ -1,8 +1,8 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-YMvJ5LwexkcVWWqLdm5-nQ" name=",_siyjEEvCEdunZcj9T5hrMQ" guid="-YMvJ5LwexkcVWWqLdm5-nQ" changeDate="2008-08-11T10:02:44.000-0700" version="7.2.0">
- <mainDescription><p>
- Describes the blueprint for software development, frequently represented using a number of architectural views. It also
- contains the rationale, assumptions, explanations and implications of the decisions that were made in forming the
- architecture as well as the global mapping between views.
+ <mainDescription><p>
+ Describes the blueprint for software development, frequently represented using a number of architectural views. It also
+ contains the rationale, assumptions, explanations and implications of the decisions that were made in forming the
+ architecture as well as the global mapping between views.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.base/guidances/termdefinitions/build.xmi b/epf_prac_151/core.tech.common.base/guidances/termdefinitions/build.xmi
index b9375a3..2adee1a 100644
--- a/epf_prac_151/core.tech.common.base/guidances/termdefinitions/build.xmi
+++ b/epf_prac_151/core.tech.common.base/guidances/termdefinitions/build.xmi
@@ -1,5 +1,5 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-Wh-byAGHoy_gGry0Jq6VaA" name=",_Z-AukEvpEdunZcj9T5hrMQ" guid="-Wh-byAGHoy_gGry0Jq6VaA" version="7.2.0">
- <mainDescription>An operational version of a system or part of a system that demonstrates a subset of the capabilities to be provided in the
+ <mainDescription>An operational version of a system or part of a system that demonstrates a subset of the capabilities to be provided in the
final product</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.base/guidances/termdefinitions/component.xmi b/epf_prac_151/core.tech.common.base/guidances/termdefinitions/component.xmi
index cdf6f45..a35b958 100644
--- a/epf_prac_151/core.tech.common.base/guidances/termdefinitions/component.xmi
+++ b/epf_prac_151/core.tech.common.base/guidances/termdefinitions/component.xmi
@@ -1,8 +1,8 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-BWZsh3vKrqSOzfkBJmDTLA" name=",_d82_AEvDEdunZcj9T5hrMQ" guid="-BWZsh3vKrqSOzfkBJmDTLA" version="7.2.0">
- <mainDescription><p>
- An encapsulated part of the system that is nontrivial, nearly independent, and replaceable and that fulfills a clear
- function in the context of well-defined architecture. A component conforms to and provides the realization of a set of
- interfaces.
+ <mainDescription><p>
+ An encapsulated part of the system that is nontrivial, nearly independent, and replaceable and that fulfills a clear
+ function in the context of well-defined architecture. A component conforms to and provides the realization of a set of
+ interfaces.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.base/guidances/termdefinitions/furps.xmi b/epf_prac_151/core.tech.common.base/guidances/termdefinitions/furps.xmi
index 59f1286..3d70b4d 100644
--- a/epf_prac_151/core.tech.common.base/guidances/termdefinitions/furps.xmi
+++ b/epf_prac_151/core.tech.common.base/guidances/termdefinitions/furps.xmi
@@ -1,5 +1,5 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-vq2pL6yQuqGhql9Wo_Av4w" name=",_ZH6M0EvEEdunZcj9T5hrMQ" guid="-vq2pL6yQuqGhql9Wo_Av4w" changeDate="2008-02-11T03:46:42.000-0800" version="1.0.0">
- <mainDescription>Functional, usability, reliability, performance, supportability&nbsp;and others. This acronym represents categories that
+ <mainDescription>Functional, usability, reliability, performance, supportability&nbsp;and others. This acronym represents categories that
can be used in the definition of product requirements.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.base/guidances/termdefinitions/requirement.xmi b/epf_prac_151/core.tech.common.base/guidances/termdefinitions/requirement.xmi
index 158e599..eba9020 100644
--- a/epf_prac_151/core.tech.common.base/guidances/termdefinitions/requirement.xmi
+++ b/epf_prac_151/core.tech.common.base/guidances/termdefinitions/requirement.xmi
@@ -1,12 +1,14 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-0sCBiohjw_wBDKk0WEeDJQ" name="new_term_definition,_feKVQLULEdqI644ssJaKYg" guid="-0sCBiohjw_wBDKk0WEeDJQ" authors="Chris Sibbald" changeDate="2006-12-22T06:19:44.000-0800" changeDescription="Added term definition for "requirement"." version="0.2">
- <mainDescription><ol>
- <li>
- A capability needed by the user to solve a problem [in order to] to achieve an objective
- </li>
- <li>
- A capability that must be met or possessed by a system or system component to satisfy a contract, standard,
- specification, or other formally imposed documentation <a class="elementLinkWithUserText" href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html" guid="_9ToeIB83Edqsvps02rpOOg">[THA00]</a><br />
- </li>
+ <mainDescription><ol>
+ <li>
+ A capability needed by the user to solve a problem [in order to] to achieve an objective
+ </li>
+ <li>
+ A capability that must be met or possessed by a system or system component to satisfy a contract, standard,
+ specification, or other formally imposed documentation <a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[THA00]</a><br />
+ </li>
</ol></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/checklists/developer_test.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/checklists/developer_test.xmi
index ba1503b..467e5c9 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/checklists/developer_test.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/checklists/developer_test.xmi
@@ -16,7 +16,7 @@
<sections xmi:id="_KfXE8F-DEd2T0JdVjRyaQA" name="Branch coverage is acceptable." guid="_KfXE8F-DEd2T0JdVjRyaQA">
<sectionDescription>Assure conditional logic been tested in all combinations.<br /></sectionDescription>
</sections>
- <sections xmi:id="_UNewEF-DEd2T0JdVjRyaQA" name="The test is easy to maintain" guid="_UNewEF-DEd2T0JdVjRyaQA">
+ <sections xmi:id="_UNewEF-DEd2T0JdVjRyaQA" name="The test is easy to maintain." guid="_UNewEF-DEd2T0JdVjRyaQA">
<sectionDescription>Has the test been implemented to account for expected ongoing changes in the application state, such as system date fields,
transaction numbers, and so on?<br /></sectionDescription>
</sections>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/checklists/implementation.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/checklists/implementation.xmi
index d6078d3..c947510 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/checklists/implementation.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/checklists/implementation.xmi
@@ -1,8 +1,8 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-cev1w72zE7XqPYsSv19prg" name="new_checklist,_OhJKUNWsEduaE6F4-SvXzg" guid="-cev1w72zE7XqPYsSv19prg" changeDate="2008-08-12T04:20:23.000-0700" version="1.0.0">
- <mainDescription><p>
- Appropriate divergence from the quality criteria described here could be worthy of a comment in the implementation so
- that developers examining the code in the future know why the exception occurred.
+ <mainDescription><p>
+ Appropriate divergence from the quality criteria described here could be worthy of a comment in the implementation so
+ that developers examining the code in the future know why the exception occurred.
</p></mainDescription>
<sections xmi:id="_etwusZ01EdyQ3oTO93enUw" name="The implementation conforms to the architecture and design" guid="_etwusZ01EdyQ3oTO93enUw">
<sectionDescription><ul>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/checklists/vision.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/checklists/vision.xmi
index f3e130c..c4bd497 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/checklists/vision.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/checklists/vision.xmi
@@ -24,7 +24,7 @@
<sections xmi:id="_z1uG4AeiEduWycDgioo5rg" name="Constraints on the system have been sufficiently explored" guid="_z1uG4AeiEduWycDgioo5rg">
<sectionDescription>Don't forget about the non-functional requirements and constraints. These are often the largest cost of development.</sectionDescription>
</sections>
- <sections xmi:id="_7KzeEAeiEduWycDgioo5rg" name="All kinds of constraints, including political, economic, and environmental, have been covered" guid="_7KzeEAeiEduWycDgioo5rg">
+ <sections xmi:id="_7KzeEAeiEduWycDgioo5rg" name="All kinds of constraints, including political, economic, and environmental, have been covered." guid="_7KzeEAeiEduWycDgioo5rg">
<sectionDescription><p>
These non-technical constraints often lead to problems later.
</p></sectionDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/actor.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/actor.xmi
index 9c81397..d6c5650 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/actor.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/actor.xmi
@@ -1,50 +1,50 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-aN0zy068ovKHgmkkoYqoYQ" name=",_zGqO0MDpEduTGJ8i4u8TMw" guid="-aN0zy068ovKHgmkkoYqoYQ" changeDate="2009-08-07T01:39:22.000-0700" version="7.2.0">
- <mainDescription><p>
- To fully understand the system's purpose, you must know who the system is for, that is: Who will use the system? The
- answer to this question is: the Actors.
-</p>
-<p>
- An Actor is a role that a person or external system plays&nbsp;when interacting with the system.&nbsp; Instances of an
- Actor can be an individual or an external system, however each Actor&nbsp;provides a
- unique&nbsp;and&nbsp;important&nbsp;perspective on the system that is shared by every instance of the Actor.
-</p>
-<p>
- This difference between an actor and an instance of an actor is illustrated below.&nbsp;&nbsp;Figure 1 shows a case in
- which Ivar and Mark are operators of a recycling machine. When they are using the machine in this capacity, each is
- represented by an instance of the actor called Operator that expects certain functionality of the system (Print Daily
- Reports in this example).
-</p>
-<p>
- <img alt="" src="resources/md_acto2.gif" width="396" height="322" />&nbsp;
-</p>
-<blockquote style="MARGIN-RIGHT: 0px" dir="ltr">
- <p>
- <strong>Figure 1:&nbsp;Example Actor with multiple instances</strong>&nbsp;
- </p>
-</blockquote>
-<p>
- Conversely, the same user can act as several actors (that is, the same person can take on different roles). In Figure
- 2, Charlie uses the Depot-Handling System primarily as Depot Manager, but sometimes he also uses the Depot-Handling
- System as an ordinary Depot Staff member. Each of these actors expects different functionality of the system.
-</p>
-<p>
- <img alt="" src="resources/md_acto3.gif" width="367" height="139" />
-</p>
-<blockquote style="MARGIN-RIGHT: 0px" dir="ltr">
- <p>
- <strong>Figure 2: Example of user playing different roles</strong><br />
- </p>
-</blockquote>
-<p>
- Actors help you to identify external interfaces and to determine the scope the system (what is in the system, vs. what
- is outside the system boundary).&nbsp; Each&nbsp;Actor typically has associated use cases which describe what that
- particular&nbsp;actor expects of the system.&nbsp; It will be very difficult, if not impossible,&nbsp;to assess the
- completeness of the set of Use Cases without the context provided by the associated Actors. Furthermore, missing an
- actor may result in&nbsp;missing important stakeholder perspectives, resulting&nbsp;in a solution that does not meet
- all&nbsp;stakeholder needs.
-</p>
-<p>
- Hence, identifying the Actors for the system&nbsp;should be done early in the lifecycle.
+ <mainDescription><p>
+ To fully understand the system's purpose, you must know who the system is for, that is: Who will use the system? The
+ answer to this question is: the Actors.
+</p>
+<p>
+ An Actor is a role that a person or external system plays&nbsp;when interacting with the system.&nbsp; Instances of an
+ Actor can be an individual or an external system, however each Actor&nbsp;provides a
+ unique&nbsp;and&nbsp;important&nbsp;perspective on the system that is shared by every instance of the Actor.
+</p>
+<p>
+ This difference between an actor and an instance of an actor is illustrated below.&nbsp;&nbsp;Figure 1 shows a case in
+ which Ivar and Mark are operators of a recycling machine. When they are using the machine in this capacity, each is
+ represented by an instance of the actor called Operator that expects certain functionality of the system (Print Daily
+ Reports in this example).
+</p>
+<p>
+ <img alt="" src="resources/md_acto2.gif" width="396" height="322" />&nbsp;
+</p>
+<blockquote style="MARGIN-RIGHT: 0px" dir="ltr">
+ <p>
+ <strong>Figure 1:&nbsp;Example Actor with multiple instances</strong>&nbsp;
+ </p>
+</blockquote>
+<p>
+ Conversely, the same user can act as several actors (that is, the same person can take on different roles). In Figure
+ 2, Charlie uses the Depot-Handling System primarily as Depot Manager, but sometimes he also uses the Depot-Handling
+ System as an ordinary Depot Staff member. Each of these actors expects different functionality of the system.
+</p>
+<p>
+ <img alt="" src="resources/md_acto3.gif" width="367" height="139" />
+</p>
+<blockquote style="MARGIN-RIGHT: 0px" dir="ltr">
+ <p>
+ <strong>Figure 2: Example of user playing different roles</strong><br />
+ </p>
+</blockquote>
+<p>
+ Actors help you to identify external interfaces and to determine the scope the system (what is in the system, vs. what
+ is outside the system boundary).&nbsp; Each&nbsp;Actor typically has associated use cases which describe what that
+ particular&nbsp;actor expects of the system.&nbsp; It will be very difficult, if not impossible,&nbsp;to assess the
+ completeness of the set of Use Cases without the context provided by the associated Actors. Furthermore, missing an
+ actor may result in&nbsp;missing important stakeholder perspectives, resulting&nbsp;in a solution that does not meet
+ all&nbsp;stakeholder needs.
+</p>
+<p>
+ Hence, identifying the Actors for the system&nbsp;should be done early in the lifecycle.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/analysis_mechanism.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/analysis_mechanism.xmi
index be5b2e0..8b68a17 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/analysis_mechanism.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/analysis_mechanism.xmi
@@ -1,61 +1,71 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_S8KCcMP2EdmWKcx6ixEiwg" name="analysis_mechanism,_0gvqoMlgEdmt3adZL5Dmdw" guid="_S8KCcMP2EdmWKcx6ixEiwg" changeDate="2008-02-09T01:19:23.000-0800" version="1.0.0">
- <mainDescription><p>
- An Analysis Mechanism is a conceptual representation of an <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_mechanism_2932DFB6.html" guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanisms</a>. Over time, Analysis Mechanisms are refined into <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/concepts/design_mechanism_CE197B4E.html" guid="_w2ACwA4LEduibvKwrGxWxA">Design Mechanism</a>s&nbsp;and, later, into <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/concepts/implementation_mechanism_C92E670B.html" guid="_0LcUkA4LEduibvKwrGxWxA">Implementation Mechanism</a>s.
-</p>
-<p>
- Analysis Mechanisms&nbsp;allow the developer to focus on understanding the requirements without getting distracted by
- the specifics of a complex implementation. They are a way of abstracting away the complexity of the solution, so people
- can better comprehend the problem.
-</p>
-<p>
- Analysis Mechanisms are described in simple terms:
-</p>
-<ul>
- <li>
- <strong>Name:</strong> Identifies the mechanism.
- </li>
- <li>
- <strong>Basic attributes:</strong> Define the requirements of the mechanism.
- </li>
-</ul>
-<p>
- You can identify Analysis Mechanisms top-down, from previous knowledge, or bottom-up, meaning that you discover them as
- you proceed.
-</p>
-<p>
- In the top-down mode, you are guided by experience -- you know that certain problems are present in the domain and will
- require certain kinds of solutions. Examples of common architectural problems that might be expressed as mechanisms
- during analysis are: persistence, transaction management, fault management, messaging, and inference engines. The
- common aspect of all of these is that each is a general capability of a broad class of systems, and each provides
- functionality that interacts with or supports the basic application functionality. The Analysis Mechanisms support
- capabilities required in the basic functional requirements of the system, regardless of the platform that it is
- deployed upon or the implementation language. Analysis Mechanisms also can be designed and implemented in different
- ways. Generally, there will be more than one design mechanism that corresponds with each Analysis Mechanism. There may
- also be more than one way of implementing each design mechanism.
-</p>
-<p>
- The bottom-up approach is where Analysis Mechanisms ultimately originate. They are created as the you see, perhaps
- faintly at first, a common theme emerging from a set of solutions to various problems. For example: There is a need to
- provide a way for elements in different threads to synchronize their clocks, and there is a need for a common way of
- allocating resources. <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/concepts/analysis_mechanism_8369C159.html" guid="_0gvqoMlgEdmt3adZL5Dmdw">Analysis Mechanism</a>s, which simplify the language of analysis, emerge from these
- patterns.
-</p>
-<p>
- Identifying an Analysis Mechanism means that you identify a common, perhaps implicit&nbsp;subproblem, and you give it a
- name. Initially, the name might be all that exists. For example, the system will require a persistence
- mechanism.&nbsp;Ultimately, this mechanism will be implemented through the collaboration of various classes, some of
- which do not deliver application functionality directly, but exist only to support it. Very often these support classes
- are located in the middle or lower layers of a layered architecture, thereby providing a common support service to all
- application-level classes.
-</p>
-<p>
- If the subproblem that you identify is common enough, perhaps a pattern exists from which the mechanism can be
- instantiated, probably by binding existing classes and implementing new ones, as required by the pattern. An Analysis
- Mechanism produced this way will be abstract, and it will require further refinement throughout design and
- implementation work.
-</p>
-<p>
- You can see examples of how Architectural Mechanisms can be represented in <a class="elementLinkWithType" href="./../../../core.tech.common.extend_supp/guidances/examples/architectural_mechanism_attributes_B0ECA2F7.html" guid="_eQ_s8Om5Edupia_tZIXEqg">Example: Architectural Mechanism Attributes</a>.
+ <mainDescription><p>
+ An Analysis Mechanism is a conceptual representation of an <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_mechanism_2932DFB6.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a>. Over time, Analysis Mechanisms are refined into <a
+ class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/concepts/design_mechanism_CE197B4E.html"
+ guid="_w2ACwA4LEduibvKwrGxWxA">Design Mechanism</a>s&nbsp;and, later, into <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/implementation_mechanism_C92E670B.html"
+ guid="_0LcUkA4LEduibvKwrGxWxA">Implementation Mechanism</a>s.
+</p>
+<p>
+ Analysis Mechanisms&nbsp;allow the developer to focus on understanding the requirements without getting distracted by
+ the specifics of a complex implementation. They are a way of abstracting away the complexity of the solution, so people
+ can better comprehend the problem.
+</p>
+<p>
+ Analysis Mechanisms are described in simple terms:
+</p>
+<ul>
+ <li>
+ <strong>Name:</strong> Identifies the mechanism.
+ </li>
+ <li>
+ <strong>Basic attributes:</strong> Define the requirements of the mechanism.
+ </li>
+</ul>
+<p>
+ You can identify Analysis Mechanisms top-down, from previous knowledge, or bottom-up, meaning that you discover them as
+ you proceed.
+</p>
+<p>
+ In the top-down mode, you are guided by experience -- you know that certain problems are present in the domain and will
+ require certain kinds of solutions. Examples of common architectural problems that might be expressed as mechanisms
+ during analysis are: persistence, transaction management, fault management, messaging, and inference engines. The
+ common aspect of all of these is that each is a general capability of a broad class of systems, and each provides
+ functionality that interacts with or supports the basic application functionality. The Analysis Mechanisms support
+ capabilities required in the basic functional requirements of the system, regardless of the platform that it is
+ deployed upon or the implementation language. Analysis Mechanisms also can be designed and implemented in different
+ ways. Generally, there will be more than one design mechanism that corresponds with each Analysis Mechanism. There may
+ also be more than one way of implementing each design mechanism.
+</p>
+<p>
+ The bottom-up approach is where Analysis Mechanisms ultimately originate. They are created as the you see, perhaps
+ faintly at first, a common theme emerging from a set of solutions to various problems. For example: There is a need to
+ provide a way for elements in different threads to synchronize their clocks, and there is a need for a common way of
+ allocating resources. <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/analysis_mechanism_8369C159.html"
+ guid="_0gvqoMlgEdmt3adZL5Dmdw">Analysis Mechanism</a>s, which simplify the language of analysis, emerge from these
+ patterns.
+</p>
+<p>
+ Identifying an Analysis Mechanism means that you identify a common, perhaps implicit&nbsp;subproblem, and you give it a
+ name. Initially, the name might be all that exists. For example, the system will require a persistence
+ mechanism.&nbsp;Ultimately, this mechanism will be implemented through the collaboration of various classes, some of
+ which do not deliver application functionality directly, but exist only to support it. Very often these support classes
+ are located in the middle or lower layers of a layered architecture, thereby providing a common support service to all
+ application-level classes.
+</p>
+<p>
+ If the subproblem that you identify is common enough, perhaps a pattern exists from which the mechanism can be
+ instantiated, probably by binding existing classes and implementing new ones, as required by the pattern. An Analysis
+ Mechanism produced this way will be abstract, and it will require further refinement throughout design and
+ implementation work.
+</p>
+<p>
+ You can see examples of how Architectural Mechanisms can be represented in <a class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/examples/architectural_mechanism_attributes_B0ECA2F7.html"
+ guid="_eQ_s8Om5Edupia_tZIXEqg">Example: Architectural Mechanism Attributes</a>.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/arch_constraints.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/arch_constraints.xmi
index 873e6b0..5af7d68 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/arch_constraints.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/arch_constraints.xmi
@@ -1,37 +1,37 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-je0zRqgX0Tg_761Z77cIkg" name="arch_constraints,_jdKSsNpiEdyP58ppo1Ieaw" guid="-je0zRqgX0Tg_761Z77cIkg" changeDate="2008-02-13T10:37:37.000-0800" version="7.2.0">
- <mainDescription><p>
- A variety of factors may place constraints on the architecture being developed:
-</p>
-<div style="MARGIN-LEFT: 2em">
- <ul>
- <li>
- Network topology
- </li>
- <li>
- Use of a given database vendor or an existing database
- </li>
- <li>
- Web environment (server configurations, firewall, DMZs, and so forth)
- </li>
- <li>
- Servers (hardware model, operating system)
- </li>
- <li>
- Use of third-party software or a particular technology
- </li>
- <li>
- Compliance with existing standards
- </li>
- </ul>
-</div>
-<p>
- For example, if the company uses only one type of database, you will probably try to use it as much as possible to
- leverage&nbsp;the existing database administration skills, rather than introducing a new one.
-</p>
-<p>
- These architectural constraints, combined with the requirements, help you define&nbsp;an appropriate&nbsp;candidate for
- the system architecture. Capturing these constraints will ease integration with the environment; and may reduce risk,
- cost and duplication of solution elements.
+ <mainDescription><p>
+ A variety of factors may place constraints on the architecture being developed:
+</p>
+<div style="MARGIN-LEFT: 2em">
+ <ul>
+ <li>
+ Network topology
+ </li>
+ <li>
+ Use of a given database vendor or an existing database
+ </li>
+ <li>
+ Web environment (server configurations, firewall, DMZs, and so forth)
+ </li>
+ <li>
+ Servers (hardware model, operating system)
+ </li>
+ <li>
+ Use of third-party software or a particular technology
+ </li>
+ <li>
+ Compliance with existing standards
+ </li>
+ </ul>
+</div>
+<p>
+ For example, if the company uses only one type of database, you will probably try to use it as much as possible to
+ leverage&nbsp;the existing database administration skills, rather than introducing a new one.
+</p>
+<p>
+ These architectural constraints, combined with the requirements, help you define&nbsp;an appropriate&nbsp;candidate for
+ the system architecture. Capturing these constraints will ease integration with the environment; and may reduce risk,
+ cost and duplication of solution elements.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/arch_goals.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/arch_goals.xmi
index efd6ce6..67f004b 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/arch_goals.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/arch_goals.xmi
@@ -1,29 +1,31 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-Mm7s8vlK5CaZZ_Msx8reCQ" name="new_concept,_HlRqANpbEdyP58ppo1Ieaw" guid="-Mm7s8vlK5CaZZ_Msx8reCQ" version="7.2.0">
- <mainDescription><p>
- Architectural goals provide the motivation and rationale&nbsp;for decisions. These goals are&nbsp;often driven
- by&nbsp;the software requirements, particularly system-wide requirements [<a class="elementLinkWithUserText" href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html" guid="_9ToeIB83Edqsvps02rpOOg">ALL02</a>].
-</p>
-<p>
- Architectural goals define how the system needs to respond to change over time. Architectural goals tend to address the
- following questions:
-</p>
-<ul>
- <li>
- What is the expected lifespan of the system?
- </li>
- <li>
- Will the system need to respond to technological changes over that time, such as new versions of middleware or
- other products?
- </li>
- <li>
- How&nbsp;frequently is&nbsp;the system&nbsp;expected to adapt to change?
- </li>
- <li>
- What changes can we anticipate in the future, and how can we make them easier to accommodate?
- </li>
-</ul>
-<p>
- These considerations will have a significant effect on the structure of the system.
+ <mainDescription><p>
+ Architectural goals provide the motivation and rationale&nbsp;for decisions. These goals are&nbsp;often driven
+ by&nbsp;the software requirements, particularly system-wide requirements [<a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">ALL02</a>].
+</p>
+<p>
+ Architectural goals define how the system needs to respond to change over time. Architectural goals tend to address the
+ following questions:
+</p>
+<ul>
+ <li>
+ What is the expected lifespan of the system?
+ </li>
+ <li>
+ Will the system need to respond to technological changes over that time, such as new versions of middleware or
+ other products?
+ </li>
+ <li>
+ How&nbsp;frequently is&nbsp;the system&nbsp;expected to adapt to change?
+ </li>
+ <li>
+ What changes can we anticipate in the future, and how can we make them easier to accommodate?
+ </li>
+</ul>
+<p>
+ These considerations will have a significant effect on the structure of the system.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/arch_mechanism.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/arch_mechanism.xmi
index a160bb7..30bab77 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/arch_mechanism.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/arch_mechanism.xmi
@@ -1,210 +1,210 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-SJrpVySJ2npYs8NwGvnHjw" name="arch_mechanism,_mzxI0A4LEduibvKwrGxWxA" guid="-SJrpVySJ2npYs8NwGvnHjw" authors="Mark Dickson" changeDate="2009-08-14T03:33:43.000-0700" changeDescription="Simplified text explaining mechanism concept" version="1.0.0">
- <mainDescription><h3>
- What are Architectural Mechanisms?
-</h3>
-<p>
- Architectural Mechanisms are common solutions to common problems that can be used during development to minimize
- complexity.&nbsp; They represent key technical concepts that&nbsp;will be standardized across the solution.&nbsp;
- Architecture mechanisms facilitate the evolution of architecturally significant aspects of the system. They allow the
- team to maintain a cohesive architecture while enabling implementation details to be deferred until they really need to
- be made.
-</p>
-<p>
- Architectural Mechanisms are&nbsp;used to satisfy architecturally significant requirements. Usually those are
- non-functional requirements such as performance and security issues.&nbsp;When fully described, Architectural
- Mechanisms show patterns of structure and behavior in the software. They&nbsp;form the basis of&nbsp;common
- software&nbsp;that will be&nbsp;consistently applied&nbsp;across the product being developed. They also form the basis
- for standardizing the way that the software works; therefore, they are an important element of the overall software
- architecture. The definition of architecture mechanisms also enable decisions on whether existing software components
- can be leveraged to provide the required behavior; or whether new software should be bought or built.
-</p>
-<p>
- The value in defining architecture mechanisms is that they:
-</p>
-<ol>
- <li>
- Explicitly call out&nbsp;aspects of the solution mechanics that are common across the system. This helps you plan.
- </li>
- <li>
- Put down markers for the developers to build those aspects of the system once and then re-use them. This reduces
- the workload.
- </li>
- <li>
- Promote the development of a consistent set of services. This makes the system easier to maintain.
- </li>
-</ol>
-<p>
- An&nbsp;Architectural Mechanism can have three states: Analysis, Design and Implementation.&nbsp;These
- categories&nbsp;reflect the maturity of the mechanism's description. The state changes as successive levels of detail
- are uncovered during when you refine <a class="elementLink"
- href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_significant_requirements_1EE5D757.html"
- guid="_HrZGIA4MEduibvKwrGxWxA">Architecturally Significant Requirements</a>&nbsp;into working software. The categories
- are summarized in the table that follows.
-</p><strong>States of an Architectural Mechanism</strong>
-<table style="WIDTH: 806px; HEIGHT: 228px" border="1" cellspacing="0" summary="Types of Architectural Mechanism"
-cellpadding="2" width="806">
- <tbody valign="top">
- <tr>
- <th scope="col">
- State
- </th>
- <th scope="col">
- Description
- </th>
- </tr>
- <tr>
- <td>
- Analysis
- </td>
- <td>
- <p>
- A conceptual solution to a common technical problem. For example,&nbsp;persistence is an abstract
- solution to the common requirement to store data. The purpose of this category is simply to identify
- the need for an Architectural Mechanism to be designed and implemented; and capture basic attributes
- for that mechanism.
- </p>
- </td>
- </tr>
- <tr>
- <td>
- Design
- </td>
- <td>
- <p>
- A refinement of an Analysis Mechanism into a concrete technology (for example, RDBMS). The purpose of
- this category is to guide precise product or technology selection.
- </p>
- </td>
- </tr>
- <tr>
- <td>
- Implementation
- </td>
- <td>
- <p>
- A further refinement from a design mechanism into a specification for the software. This can be
- presented as a design pattern or example code.
- </p>
- </td>
- </tr>
- </tbody>
-</table><br />
-<p>
- For more information on these different types of mechanisms, see the attached concepts.
-</p>
-<p>
- Be aware that these states are frequently referred to themselves as Analysis, Design and Implementation
- mechanisms.&nbsp;These are synonyms and merely represent the architecture mechanisms in different states of
- development. The transition from one state to another&nbsp;can often be obvious or intuitive. Therefore, it can be
- achieved in a matter of seconds. It can also require more considered analysis and design, thus take longer.&nbsp;The
- important point here is that these categories of mechanisms apply to the same concept in different states. The only
- difference between them is one of refinement or detail.
-</p>
-<p>
- The following diagram illustrates the transition of Architectural Mechanisms from one state to another.
-</p>
-<p>
- <strong>State Machine for Architectural Mechanisms</strong>
-</p>
-<p>
- <img style="WIDTH: 876px; HEIGHT: 115px" alt="Architectural Mechanism States" src="resources/arch_mech_states.jpg"
- width="600" height="113" />&nbsp;
-</p>
-<h3>
- What Information Should be Captured for Architectural Mechanisms?
-</h3>
-<p>
- The information captured for each architectural mechanism category/state is different (though the information can be
- seen as refinements of each other):
-</p>
-<ul>
- <li>
- <strong>Analysis Mechanisms</strong>, which give the mechanism a name, brief description and some basic
- attributes&nbsp;derived from&nbsp;the project requirements
- </li>
- <li>
- <strong>Design Mechanisms</strong>, which are more concrete and assume some details of the implementation
- environment
- </li>
- <li>
- <strong>Implementation Mechanisms</strong>, which specify the&nbsp;exact implementation of&nbsp;each mechanism
- </li>
-</ul>
-<p>
- When&nbsp;a mechanism is&nbsp;initially identified, it can be considered a marker that says to the team, "We are going
- to handle this aspect of the system in a standard way. We'll figure out the details later." As the project proceeds,
- the architectural mechanisms are gradually refined until they become part of the software.
-</p>
-<h4>
- Analysis Mechanisms
-</h4>
-<p>
- Analysis mechanisms&nbsp;are the initial state for an architectural mechanism. They are identified early in the project
- and represent&nbsp;bookmarks for future software development. They allow the&nbsp;team to focus on understanding the
- requirements without getting distracted by the specifics of a complex implementation. Analysis mechanisms are
- discovered by surveying the requirements and looking for recurrent technical concepts.&nbsp;Security, persistence and
- legacy interface are some examples of these. In effect, the analysis mechanism is where the requirements that
- describe&nbsp;architecturally significant topics&nbsp;are collated and brought&nbsp;together in a single list. This
- makes them easier to manage.
-</p>
-<p>
- Analysis mechanisms are described in simple terms:
-</p>
-<ul>
- <li>
- <strong>Name:</strong> Identifies the mechanism.
- </li>
- <li>
- <strong>Basic attributes:</strong> Define the requirements of the mechanism. These attributes can vary depending
- upon the mechanism being analyzed. Refer to <a class="elementLinkWithType"
- href="./../../../core.tech.common.extend_supp/guidances/examples/architectural_mechanism_attributes_B0ECA2F7.html"
- guid="_eQ_s8Om5Edupia_tZIXEqg">Example: Architectural Mechanism Attributes</a>&nbsp;for more guidance.
- </li>
-</ul>
-<p>
- Once the list of analysis mechanisms has been defined it can be prioritized and the mechanisms refined in line
- with&nbsp;iteration&nbsp;objectives. It is not necessary to develop the entire set of architecture mechanisms into
- working software in a single pass. It is often more sensible to develop only those mechanisms required to support the
- functionality to be delivered in the current iteration.
-</p>
-<h4>
- Design Mechanisms
-</h4>
-<p>
- Design mechanisms&nbsp;represent decisions about the concrete technologies that are going to be used to&nbsp;develop
- architectural mechanisms. For example, the decision to use an RDBMS for persistence. It's often no more complicated
- than that (though of course, the effort involved in making the decision can sometimes be quite complex).
-</p>
-<p>
- The decision on when to refine an architectural mechanism from an analysis state to a design state is largely
- arbitrary. Often there will be constraints on the project that&nbsp;force the decision on some of these issues. For
- example, there may be a corporate standard for databases which mean that the decision&nbsp;for the&nbsp;persistence
- mechanism can be made on day 1 of the project.
-</p>
-<p>
- On other occasions the decision may point to products that the project team has not yet acquired.&nbsp;If so,&nbsp;the
- decision needs to be made in time to enable the required products to be made available to the team.
-</p>
-<p>
- It can often be useful to develop some prototype code to prove that these decisions are sound. The architect should be
- confident that the technologies being selected are able to fulfill the requirements. The attributes captured against
- the corresponding analysis mechanisms should be used as criteria to prove the validity of the decisions.
-</p>
-<h4>
- Implementation Mechanism
-</h4>
-<p>
- An implementation mechanism&nbsp;specifies the actual implementation for the architectural mechanism (hence the
- name).&nbsp;It can be modeled as a design pattern or presented as&nbsp;example code.
-</p>
-<p>
- The best time to&nbsp;produce the&nbsp;implementation mechanism is usually when the first piece of functionality that
- needs it is scheduled for development. Architects and developers work together to develop this.
-</p>
-<p>
- For examples of the kinds of information that you might capture for a mechanism, see <a class="elementLinkWithType"
- href="./../../../core.tech.common.extend_supp/guidances/examples/architectural_mechanism_attributes_B0ECA2F7.html"
- guid="_eQ_s8Om5Edupia_tZIXEqg">Example: Architectural Mechanism Attributes</a>.
+ <mainDescription><h3>
+ What are Architectural Mechanisms?
+</h3>
+<p>
+ Architectural Mechanisms are common solutions to common problems that can be used during development to minimize
+ complexity.&nbsp; They represent key technical concepts that&nbsp;will be standardized across the solution.&nbsp;
+ Architecture mechanisms facilitate the evolution of architecturally significant aspects of the system. They allow the
+ team to maintain a cohesive architecture while enabling implementation details to be deferred until they really need to
+ be made.
+</p>
+<p>
+ Architectural Mechanisms are&nbsp;used to satisfy architecturally significant requirements. Usually those are
+ non-functional requirements such as performance and security issues.&nbsp;When fully described, Architectural
+ Mechanisms show patterns of structure and behavior in the software. They&nbsp;form the basis of&nbsp;common
+ software&nbsp;that will be&nbsp;consistently applied&nbsp;across the product being developed. They also form the basis
+ for standardizing the way that the software works; therefore, they are an important element of the overall software
+ architecture. The definition of architecture mechanisms also enable decisions on whether existing software components
+ can be leveraged to provide the required behavior; or whether new software should be bought or built.
+</p>
+<p>
+ The value in defining architecture mechanisms is that they:
+</p>
+<ol>
+ <li>
+ Explicitly call out&nbsp;aspects of the solution mechanics that are common across the system. This helps you plan.
+ </li>
+ <li>
+ Put down markers for the developers to build those aspects of the system once and then re-use them. This reduces
+ the workload.
+ </li>
+ <li>
+ Promote the development of a consistent set of services. This makes the system easier to maintain.
+ </li>
+</ol>
+<p>
+ An&nbsp;Architectural Mechanism can have three states: Analysis, Design and Implementation.&nbsp;These
+ categories&nbsp;reflect the maturity of the mechanism's description. The state changes as successive levels of detail
+ are uncovered during when you refine <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_significant_requirements_1EE5D757.html"
+ guid="_HrZGIA4MEduibvKwrGxWxA">Architecturally Significant Requirements</a>&nbsp;into working software. The categories
+ are summarized in the table that follows.
+</p><strong>States of an Architectural Mechanism</strong> 
+<table style="WIDTH: 806px; HEIGHT: 228px" border="1" cellspacing="0" summary="Types of Architectural Mechanism"
+cellpadding="2" width="806">
+ <tbody valign="top">
+ <tr>
+ <th scope="col">
+ State
+ </th>
+ <th scope="col">
+ Description
+ </th>
+ </tr>
+ <tr>
+ <td>
+ Analysis
+ </td>
+ <td>
+ <p>
+ A conceptual solution to a common technical problem. For example,&nbsp;persistence is an abstract
+ solution to the common requirement to store data. The purpose of this category is simply to identify
+ the need for an Architectural Mechanism to be designed and implemented; and capture basic attributes
+ for that mechanism.
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Design
+ </td>
+ <td>
+ <p>
+ A refinement of an Analysis Mechanism into a concrete technology (for example, RDBMS). The purpose of
+ this category is to guide precise product or technology selection.
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Implementation
+ </td>
+ <td>
+ <p>
+ A further refinement from a design mechanism into a specification for the software. This can be
+ presented as a design pattern or example code.
+ </p>
+ </td>
+ </tr>
+ </tbody>
+</table><br />
+<p>
+ For more information on these different types of mechanisms, see the attached concepts.
+</p>
+<p>
+ Be aware that these states are frequently referred to themselves as Analysis, Design and Implementation
+ mechanisms.&nbsp;These are synonyms and merely represent the architecture mechanisms in different states of
+ development. The transition from one state to another&nbsp;can often be obvious or intuitive. Therefore, it can be
+ achieved in a matter of seconds. It can also require more considered analysis and design, thus take longer.&nbsp;The
+ important point here is that these categories of mechanisms apply to the same concept in different states. The only
+ difference between them is one of refinement or detail.
+</p>
+<p>
+ The following diagram illustrates the transition of Architectural Mechanisms from one state to another.
+</p>
+<p>
+ <strong>State Machine for Architectural Mechanisms</strong>
+</p>
+<p>
+ <img style="WIDTH: 876px; HEIGHT: 115px" alt="Architectural Mechanism States" src="resources/arch_mech_states.jpg"
+ width="600" height="113" />&nbsp;
+</p>
+<h3>
+ What Information Should be Captured for Architectural Mechanisms?
+</h3>
+<p>
+ The information captured for each architectural mechanism category/state is different (though the information can be
+ seen as refinements of each other):
+</p>
+<ul>
+ <li>
+ <strong>Analysis Mechanisms</strong>, which give the mechanism a name, brief description and some basic
+ attributes&nbsp;derived from&nbsp;the project requirements
+ </li>
+ <li>
+ <strong>Design Mechanisms</strong>, which are more concrete and assume some details of the implementation
+ environment
+ </li>
+ <li>
+ <strong>Implementation Mechanisms</strong>, which specify the&nbsp;exact implementation of&nbsp;each mechanism
+ </li>
+</ul>
+<p>
+ When&nbsp;a mechanism is&nbsp;initially identified, it can be considered a marker that says to the team, "We are going
+ to handle this aspect of the system in a standard way. We'll figure out the details later." As the project proceeds,
+ the architectural mechanisms are gradually refined until they become part of the software.
+</p>
+<h4>
+ Analysis Mechanisms
+</h4>
+<p>
+ Analysis mechanisms&nbsp;are the initial state for an architectural mechanism. They are identified early in the project
+ and represent&nbsp;bookmarks for future software development. They allow the&nbsp;team to focus on understanding the
+ requirements without getting distracted by the specifics of a complex implementation. Analysis mechanisms are
+ discovered by surveying the requirements and looking for recurrent technical concepts.&nbsp;Security, persistence and
+ legacy interface are some examples of these. In effect, the analysis mechanism is where the requirements that
+ describe&nbsp;architecturally significant topics&nbsp;are collated and brought&nbsp;together in a single list. This
+ makes them easier to manage.
+</p>
+<p>
+ Analysis mechanisms are described in simple terms:
+</p>
+<ul>
+ <li>
+ <strong>Name:</strong> Identifies the mechanism.
+ </li>
+ <li>
+ <strong>Basic attributes:</strong> Define the requirements of the mechanism. These attributes can vary depending
+ upon the mechanism being analyzed. Refer to <a class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/examples/architectural_mechanism_attributes_B0ECA2F7.html"
+ guid="_eQ_s8Om5Edupia_tZIXEqg">Example: Architectural Mechanism Attributes</a>&nbsp;for more guidance.
+ </li>
+</ul>
+<p>
+ Once the list of analysis mechanisms has been defined it can be prioritized and the mechanisms refined in line
+ with&nbsp;iteration&nbsp;objectives. It is not necessary to develop the entire set of architecture mechanisms into
+ working software in a single pass. It is often more sensible to develop only those mechanisms required to support the
+ functionality to be delivered in the current iteration.
+</p>
+<h4>
+ Design Mechanisms
+</h4>
+<p>
+ Design mechanisms&nbsp;represent decisions about the concrete technologies that are going to be used to&nbsp;develop
+ architectural mechanisms. For example, the decision to use an RDBMS for persistence. It's often no more complicated
+ than that (though of course, the effort involved in making the decision can sometimes be quite complex).
+</p>
+<p>
+ The decision on when to refine an architectural mechanism from an analysis state to a design state is largely
+ arbitrary. Often there will be constraints on the project that&nbsp;force the decision on some of these issues. For
+ example, there may be a corporate standard for databases which mean that the decision&nbsp;for the&nbsp;persistence
+ mechanism can be made on day 1 of the project.
+</p>
+<p>
+ On other occasions the decision may point to products that the project team has not yet acquired.&nbsp;If so,&nbsp;the
+ decision needs to be made in time to enable the required products to be made available to the team.
+</p>
+<p>
+ It can often be useful to develop some prototype code to prove that these decisions are sound. The architect should be
+ confident that the technologies being selected are able to fulfill the requirements. The attributes captured against
+ the corresponding analysis mechanisms should be used as criteria to prove the validity of the decisions.
+</p>
+<h4>
+ Implementation Mechanism
+</h4>
+<p>
+ An implementation mechanism&nbsp;specifies the actual implementation for the architectural mechanism (hence the
+ name).&nbsp;It can be modeled as a design pattern or presented as&nbsp;example code.
+</p>
+<p>
+ The best time to&nbsp;produce the&nbsp;implementation mechanism is usually when the first piece of functionality that
+ needs it is scheduled for development. Architects and developers work together to develop this.
+</p>
+<p>
+ For examples of the kinds of information that you might capture for a mechanism, see <a class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/examples/architectural_mechanism_attributes_B0ECA2F7.html"
+ guid="_eQ_s8Om5Edupia_tZIXEqg">Example: Architectural Mechanism Attributes</a>.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/arch_significant_requirements.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/arch_significant_requirements.xmi
index 4c42a5f..030d772 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/arch_significant_requirements.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/arch_significant_requirements.xmi
@@ -1,79 +1,79 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-EytH4BCNGiHF6pZrp8ISCw" name="new_concept,_eFElAOK2EdqHEo0wLIc5jg" guid="-EytH4BCNGiHF6pZrp8ISCw" authors="Mark Dickson" changeDate="2008-10-15T08:24:39.000-0700" changeDescription="First Draft" version="1.0">
- <mainDescription><p>
- Architecturally significant requirements are those requirements that play an important role in determining the
- architecture of the system.&nbsp; Such requirements require special attention. Not all requirements have equal
- significance with regards to the architecture.
-</p>
-<p>
- Architecturally significant requirements&nbsp;are a subset of the requirements that need to be satisfied before the
- architecture can be considered "stable". Typically, these are requirements that are technically challenging,
- technically constraining, or central to the system's purpose. Furthermore, the system will generally be more sensitive
- to changes&nbsp;against architecturally significant requirements, so identifying and communicating this subset will
- help others understand the potential implications of change.
-</p>
-<p>
- Requirements can be explicitly or implicitly architecturally significant. Explicitly significant requirements are often
- overtly technical in nature, such as performance targets; the need to interface to other systems; the number of users
- that must be supported; or security requirements. Implicitly significant requirements may define the essence of the
- functional behaviour of the system (for example, making a purchase from an on-line store).
-</p>
-<p>
- Deciding whether a specific requirement is architecturally significant is often a matter of judgment. The selection of
- requirements that are considered "architecturally significant" is driven by several key driving factors:
-</p>
-<ul>
- <li>
- The benefit of the requirement to stakeholders: critical, <b>important</b>, or <b>useful</b>.
- </li>
- <li>
- The architectural impact of the requirement: <b>none</b>, <b>extends</b>, or <b>modifies</b>. There may be critical
- requirements that have little or no impact on the architecture and low-benefit requirements that have a big impact.
- Low-benefit requirements with big architectural impacts should be reviewed by the project manager for possible
- removal from the scope of the project.
- </li>
- <li>
- The risks to be mitigated: performance, availability of a product, and suitability of a component.
- </li>
- <li>
- The completion of the coverage of the architecture.
- </li>
- <li>
- Other tactical objectives or constraints, such as demonstration to the user, and so on.
- </li>
-</ul>
-<p>
- There may be two requirements that hit the same components and address similar risks. If you implement A first, then B
- is not architecturally significant. If you implement B first, then A is not architecturally significant. Thus these
- attributes can depend on the order the requirements are realized, and should be re-evaluated when the order changes, as
- well as when the requirements themselves change.
-</p>
-<p>
- The following are good examples of Architecturally Significant Requirements:
-</p>
-<ul>
- <li>
- The system must record every modification to customer records for audit purposes.
- </li>
- <li>
- The system must respond within 5 seconds.
- </li>
- <li>
- The system must&nbsp;deploy on Microsoft Windows XP and Linux.
- </li>
- <li>
- The system must encrypt all network traffic.
- </li>
- <li>
- The ATM system must dispense cash on&nbsp;demand&nbsp;to validated account holders with sufficient cleared funds.
- </li>
-</ul>
-<p>
- Architecturally significant requirements also describe key behaviors that the system needs to perform.&nbsp; Such
- scenarios represent the important interactions between key abstractions.and should be identified as architecturally
- significant requirements. For example, for an on-line book store describing the way the software handles the scenarios
- for ordering a book and checking out the shopping cart are often enough to communicate the essence of the architecture.
-</p><br />
-<br />
+ <mainDescription><p>
+ Architecturally significant requirements are those requirements that play an important role in determining the
+ architecture of the system.&nbsp; Such requirements require special attention. Not all requirements have equal
+ significance with regards to the architecture.
+</p>
+<p>
+ Architecturally significant requirements&nbsp;are a subset of the requirements that need to be satisfied before the
+ architecture can be considered "stable". Typically, these are requirements that are technically challenging,
+ technically constraining, or central to the system's purpose. Furthermore, the system will generally be more sensitive
+ to changes&nbsp;against architecturally significant requirements, so identifying and communicating this subset will
+ help others understand the potential implications of change.
+</p>
+<p>
+ Requirements can be explicitly or implicitly architecturally significant. Explicitly significant requirements are often
+ overtly technical in nature, such as performance targets; the need to interface to other systems; the number of users
+ that must be supported; or security requirements. Implicitly significant requirements may define the essence of the
+ functional behaviour of the system (for example, making a purchase from an on-line store).
+</p>
+<p>
+ Deciding whether a specific requirement is architecturally significant is often a matter of judgment. The selection of
+ requirements that are considered "architecturally significant" is driven by several key driving factors:
+</p>
+<ul>
+ <li>
+ The benefit of the requirement to stakeholders: critical, <b>important</b>, or <b>useful</b>.
+ </li>
+ <li>
+ The architectural impact of the requirement: <b>none</b>, <b>extends</b>, or <b>modifies</b>. There may be critical
+ requirements that have little or no impact on the architecture and low-benefit requirements that have a big impact.
+ Low-benefit requirements with big architectural impacts should be reviewed by the project manager for possible
+ removal from the scope of the project.
+ </li>
+ <li>
+ The risks to be mitigated: performance, availability of a product, and suitability of a component.
+ </li>
+ <li>
+ The completion of the coverage of the architecture.
+ </li>
+ <li>
+ Other tactical objectives or constraints, such as demonstration to the user, and so on.
+ </li>
+</ul>
+<p>
+ There may be two requirements that hit the same components and address similar risks. If you implement A first, then B
+ is not architecturally significant. If you implement B first, then A is not architecturally significant. Thus these
+ attributes can depend on the order the requirements are realized, and should be re-evaluated when the order changes, as
+ well as when the requirements themselves change.
+</p>
+<p>
+ The following are good examples of Architecturally Significant Requirements:
+</p>
+<ul>
+ <li>
+ The system must record every modification to customer records for audit purposes.
+ </li>
+ <li>
+ The system must respond within 5 seconds.
+ </li>
+ <li>
+ The system must&nbsp;deploy on Microsoft Windows XP and Linux.
+ </li>
+ <li>
+ The system must encrypt all network traffic.
+ </li>
+ <li>
+ The ATM system must dispense cash on&nbsp;demand&nbsp;to validated account holders with sufficient cleared funds.
+ </li>
+</ul>
+<p>
+ Architecturally significant requirements also describe key behaviors that the system needs to perform.&nbsp; Such
+ scenarios represent the important interactions between key abstractions.and should be identified as architecturally
+ significant requirements. For example, for an on-line book store describing the way the software handles the scenarios
+ for ordering a book and checking out the shopping cart are often enough to communicate the essence of the architecture.
+</p><br />
+<br />
<br /></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/arch_views_viewpoints.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/arch_views_viewpoints.xmi
index 25bc6fb..5612f6b 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/arch_views_viewpoints.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/arch_views_viewpoints.xmi
@@ -1,50 +1,50 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-QB0WnHnpcK1VJbdJJ5QJ5A" name="new_concept,_kgtcoNc8Edyd7OybSySFxg" guid="-QB0WnHnpcK1VJbdJJ5QJ5A" changeDate="2010-08-24T05:16:41.000-0700" version="7.2.0">
- <mainDescription><p>
- Architecture can be represented from a variety of viewpoints, all of which can be combined to create a holistic view of
- the system. Each architectural view addresses some specific set of concerns, specific to stakeholders in the
- development process: users, designers, managers, system engineers, maintainers, and so on.
-</p>
-<p>
- The views capture the major structural design decisions by showing how the software architecture is decomposed into
- components, and how components are connected by connectors to produce useful forms <a class="elementlinkwithusertext"
- href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#PW92"
- guid="_9ToeIB83Edqsvps02rpOOg">[PW92]</a>. These design choices must be tied to the requirements -- functional and
- supplementary -- and other constraints. But these choices in turn put further constraints on the requirements, and on
- future design decisions at a lower level.&nbsp;
-</p>
-<p>
- In essence, architectural views are abstractions, or simplifications, of the entire design, in which important
- characteristics are made more visible by leaving details aside. These characteristics are important when reasoning
- about:
-</p>
-<ul>
- <li>
- System evolution-going to the next development cycle.
- </li>
- <li>
- Reuse of the architecture, or parts of it, in the context of a product line.
- </li>
- <li>
- Assessment of supplementary qualities, such as performance, availability, portability, and safety.
- </li>
- <li>
- Assignment of development work to teams or subcontractors.
- </li>
- <li>
- Decisions about including off-the-shelf components.
- </li>
- <li>
- Insertion in a wider system.&nbsp;
- </li>
-</ul>
-<p>
- To choose the appropriate set of views,&nbsp;identify the stakeholders who depend on software architecture
- documentation and the information that they need. For an example of a set of views that have been used to represent
- architecture, see <a class="elementLinkWithType"
- href="./../../../core.tech.common.extend_supp/guidances/examples/four_plus_one_view_of_arch_9A93ACE5.html"
- guid="_4bC4cNs_EdyEW4klSH3vRA">Example: 4+1 Views of Software Architecture</a>.&nbsp; A more comprehensive set of views
- can be found in the <a href="http://www.ibm.com/developerworks/rational/library/08/0108_cooks-cripps-spaas/"
- target="_blank">IBM Views and Viewpoints Framework for IT systems</a>.
+ <mainDescription><p>
+ Architecture can be represented from a variety of viewpoints, all of which can be combined to create a holistic view of
+ the system. Each architectural view addresses some specific set of concerns, specific to stakeholders in the
+ development process: users, designers, managers, system engineers, maintainers, and so on.
+</p>
+<p>
+ The views capture the major structural design decisions by showing how the software architecture is decomposed into
+ components, and how components are connected by connectors to produce useful forms <a class="elementlinkwithusertext"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#PW92"
+ guid="_9ToeIB83Edqsvps02rpOOg">[PW92]</a>. These design choices must be tied to the requirements -- functional and
+ supplementary -- and other constraints. But these choices in turn put further constraints on the requirements, and on
+ future design decisions at a lower level.&nbsp;
+</p>
+<p>
+ In essence, architectural views are abstractions, or simplifications, of the entire design, in which important
+ characteristics are made more visible by leaving details aside. These characteristics are important when reasoning
+ about:
+</p>
+<ul>
+ <li>
+ System evolution-going to the next development cycle.
+ </li>
+ <li>
+ Reuse of the architecture, or parts of it, in the context of a product line.
+ </li>
+ <li>
+ Assessment of supplementary qualities, such as performance, availability, portability, and safety.
+ </li>
+ <li>
+ Assignment of development work to teams or subcontractors.
+ </li>
+ <li>
+ Decisions about including off-the-shelf components.
+ </li>
+ <li>
+ Insertion in a wider system.&nbsp;
+ </li>
+</ul>
+<p>
+ To choose the appropriate set of views,&nbsp;identify the stakeholders who depend on software architecture
+ documentation and the information that they need. For an example of a set of views that have been used to represent
+ architecture, see <a class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/examples/four_plus_one_view_of_arch_9A93ACE5.html"
+ guid="_4bC4cNs_EdyEW4klSH3vRA">Example: 4+1 Views of Software Architecture</a>.&nbsp; A more comprehensive set of views
+ can be found in the <a href="http://www.ibm.com/developerworks/rational/library/08/0108_cooks-cripps-spaas/"
+ target="_blank">IBM Views and Viewpoints Framework for IT systems</a>.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/business_pattern.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/business_pattern.xmi
index 64b445d..46877a8 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/business_pattern.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/business_pattern.xmi
@@ -1,15 +1,20 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-Of51hmgdsO_U2-pnbJ67Cg" name="new_concept,_RoSdMBWYEduCK502eDgjUQ" guid="-Of51hmgdsO_U2-pnbJ67Cg" changeDate="2008-02-10T07:39:04.000-0800" version="7.2.0">
- <mainDescription><p>
- Business Patterns are a form of Design Pattern&nbsp;(see <a class="elementLinkWithType" href="./../../../core.tech.common.extend_supp/guidances/concepts/pattern_10BE6D96.html" guid="_0YJvUMlgEdmt3adZL5Dmdw">Concept: Pattern</a>) and are the business-domain counterpart of <a class="elementLinkWithType" href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_mechanism_2932DFB6.html" guid="_mzxI0A4LEduibvKwrGxWxA">Concept: Architectural Mechanisms</a>. Just as similar problems in the technical domain
- may be solved by using Architecture Mechanisms, similar problems in the business domain can be solved by using Business
- Patterns.
-</p>
-<p>
- Business Patterns are often found in COTS products. For example, packaged applications that support Enterprise Resource
- Planning or Customer Relationship Management ship with functionality to support a variety of generic business
- processes. Similarly, it is frequently possible to identify related or similar behavior in the Use
- Case&nbsp;Scenarios&nbsp;and thereby derive generic designs that you can use in the design of the system. These
- elements of generic behavior can be&nbsp;expressed as Design&nbsp;Patterns and applied to the system design.
+ <mainDescription><p>
+ Business Patterns are a form of Design Pattern&nbsp;(see <a class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/pattern_10BE6D96.html"
+ guid="_0YJvUMlgEdmt3adZL5Dmdw">Concept: Pattern</a>) and are the business-domain counterpart of <a
+ class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_mechanism_2932DFB6.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Concept: Architectural Mechanism</a>. Just as similar problems in the technical domain
+ may be solved by using Architecture Mechanisms, similar problems in the business domain can be solved by using Business
+ Patterns.
+</p>
+<p>
+ Business Patterns are often found in COTS products. For example, packaged applications that support Enterprise Resource
+ Planning or Customer Relationship Management ship with functionality to support a variety of generic business
+ processes. Similarly, it is frequently possible to identify related or similar behavior in the Use
+ Case&nbsp;Scenarios&nbsp;and thereby derive generic designs that you can use in the design of the system. These
+ elements of generic behavior can be&nbsp;expressed as Design&nbsp;Patterns and applied to the system design.
</p><br /></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/coding_standard.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/coding_standard.xmi
index d7ac6d7..c3eddfd 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/coding_standard.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/coding_standard.xmi
@@ -1,51 +1,53 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-xo5gft-2zQGWhxjKcGxSQQ" name="new_concept,_0lnRMMqOEduwrYVlQ9zp3w" guid="-xo5gft-2zQGWhxjKcGxSQQ" changeDate="2008-01-08T05:21:22.000-0800" version="1.0.0">
- <mainDescription><p>
- Using a coding standard is a widely accepted software development practice. The need for this practice takes on added
- importance in a highly collaborative environment. The team should have a standard way of naming and formatting things
- so they can understand the code quickly and know where to look at all times. This enables shared code ownership since
- any team member should be able to quickly understand the code written by others.&nbsp;
-</p>
-<p>
- Ideally, the coding standard should be the result of team consensus. Involving the team members will aid adoption of
- the standards.
-</p>
-<p>
- Coding Standards cover such areas as:
-</p>
-<ul>
- <li>
- Naming standards. This includes the naming of elements all the way down to the smallest variable. In covering
- larger-scale elements, this overlaps into what could be considered design standards.
- </li>
- <li>
- File organization. This includes file naming conventions and how the files will be organized on the file system.
- </li>
- <li>
- Comment standards. Too much emphasis on comments implies a lack of confidence that readable code is being written,
- plus there is always a concern that the comments are not up to date. Yet, a consistent approach to comments
- improves understandability and can support the ability to generate documentation from the code.
- </li>
- <li>
- Coding conventions. Consistent application of specific code-level conventions and the exclusion of some considered
- poor form improve the quality of the code.
- </li>
- <li>
- White space. Though it can be argued to be less critical than the other items listed here, a consistent usage of
- white space as indentation and blank lines also improves readability.
- </li>
-</ul>
-<p>
- In some cases, decisions will be arbitrary (like how much to indent). Each item in the standard should support one or
- more goals, improved communication being one of the most critical goals. Once the team agrees on a standard, all
- members of the teams are expected to follow it. With time, the team will use and modify the standard to develop a style
- that is well adapted to the environment.
-</p>
-<p>
- Though some standards can transcend any language, coding standards must be language specific for the most part.
-</p>
-<p>
- For example coding standards, see the <a href="http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html" target="_blank">Code Conventions for the JavaTM Programming Language</a> or these <a href="http://blogs.msdn.com/brada/articles/361363.aspx" target="_blank">Internal Coding Guidelines</a> for .NET
- development.
+ <mainDescription><p>
+ Using a coding standard is a widely accepted software development practice. The need for this practice takes on added
+ importance in a highly collaborative environment. The team should have a standard way of naming and formatting things
+ so they can understand the code quickly and know where to look at all times. This enables shared code ownership since
+ any team member should be able to quickly understand the code written by others.&nbsp;
+</p>
+<p>
+ Ideally, the coding standard should be the result of team consensus. Involving the team members will aid adoption of
+ the standards.
+</p>
+<p>
+ Coding Standards cover such areas as:
+</p>
+<ul>
+ <li>
+ Naming standards. This includes the naming of elements all the way down to the smallest variable. In covering
+ larger-scale elements, this overlaps into what could be considered design standards.
+ </li>
+ <li>
+ File organization. This includes file naming conventions and how the files will be organized on the file system.
+ </li>
+ <li>
+ Comment standards. Too much emphasis on comments implies a lack of confidence that readable code is being written,
+ plus there is always a concern that the comments are not up to date. Yet, a consistent approach to comments
+ improves understandability and can support the ability to generate documentation from the code.
+ </li>
+ <li>
+ Coding conventions. Consistent application of specific code-level conventions and the exclusion of some considered
+ poor form improve the quality of the code.
+ </li>
+ <li>
+ White space. Though it can be argued to be less critical than the other items listed here, a consistent usage of
+ white space as indentation and blank lines also improves readability.
+ </li>
+</ul>
+<p>
+ In some cases, decisions will be arbitrary (like how much to indent). Each item in the standard should support one or
+ more goals, improved communication being one of the most critical goals. Once the team agrees on a standard, all
+ members of the teams are expected to follow it. With time, the team will use and modify the standard to develop a style
+ that is well adapted to the environment.
+</p>
+<p>
+ Though some standards can transcend any language, coding standards must be language specific for the most part.
+</p>
+<p>
+ For example coding standards, see the <a href="http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html"
+ target="_blank">Code Conventions for the JavaTM Programming Language</a> or these <a
+ href="http://blogs.msdn.com/brada/articles/361363.aspx" target="_blank">Internal Coding Guidelines</a> for .NET
+ development.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/component.vm.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/component.vm.xmi
index 4af02aa..8841df6 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/component.vm.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/component.vm.xmi
@@ -1,99 +1,99 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-zfl87vJBFdinDB02ArLXOQ" name="new_concept,_HZGFsKrPEdu6T6WyNqBzqQ" guid="-zfl87vJBFdinDB02ArLXOQ" changeDate="2008-02-14T05:48:12.000-0800" version="7.2.0">
- <mainDescription><h3 align="left">
- Modeling Components
-</h3>
-<p align="left">
- The UML component is a modeling construct that provides the following capabilities:
-</p>
-<div align="left">
- <ul>
- <li>
- Group classes to define a larger granularity part of a system
- </li>
- <li>
- Separate the visible interfaces from internal implementation
- </li>
- <li>
- Execute instances run-time
- </li>
- </ul>
-</div>
-<p align="left">
- A component includes <strong>provided</strong> and <strong>required</strong> interfaces that form the basis for wiring
- components together. A <strong>provided interface</strong> is one that is either implemented directly by the component
- or one of its realizing classes or subcomponents, or it is the type of a provided port of the component. A
- <strong>required interface</strong> is designated by a usage dependency of the component or one of its realizing
- classes or subcomponents, or it is the type of a required port.
-</p>
-<p align="left">
- A component has an external view (or <em>black box</em> view) through its publicly visible properties and operations
- .Optionally, a behavior such as a protocol state machine may be attached to an interface, a port, and the component
- itself to define the external view more precisely by making dynamic constraints in the sequence of operation calls
- explicit. The wiring between components in a system or other context can be structurally defined by using dependencies
- between component interfaces (typically on component diagrams).
-</p>
-<p align="left">
- Optionally, you can make a more detailed specification of the structural collaboration by using parts and connectors in
- composite structures to specify the role or instance-level collaboration between components. That is the component's
- internal view (or <em>white-box</em> view) through its private properties and realizing classes or subcomponents. This
- view shows how the external behavior is realized internally. The mapping between external and internal views is by
- dependencies on components diagrams or delegation connectors to internal parts on composite structure diagrams.
-</p>
-<p align="left">
- A number of UML standard stereotypes exist that apply to components, including &lt;&lt;subsystem&gt;&gt; to model
- large-scale components, and &lt;&lt;specification&gt;&gt; and &lt;&lt;realization&gt;&gt; to model components with
- distinct specification and realization definitions, where one specification may have multiple realizations.&nbsp;
-</p>
-<p align="left">
- The recommendation is to&nbsp;use components as the representation for design subsystems.
-</p>
-<h3 align="left">
- UML Definitions -- A History
-</h3>
-<p align="left">
- The definition of <em>component</em> with the UML has changed over time with the release of different versions. The
- version of UML you use may be constrained by the capabilities of the modeling tools you use. That is why the
- definitions from 1.3 to 2.0 are provided here.
-</p>
-<p align="left">
- UML 2.0 defined <em>component</em> as the following:
-</p>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <blockquote>
- <p align="left">
- ...a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its
- environment.
- </p>
- <p align="left">
- A component defines its behavior in terms of provided and required interfaces. As such, a component serves as a
- type whose conformance is defined by these provided and required interfaces (encompassing both their static as
- well as dynamic semantics).
- </p>
- </blockquote>
-</blockquote>
-<p align="left">
- UML 1.5 defined <em>component</em> as the following:
-</p>
-<blockquote>
- <blockquote>
- <div align="left">
- A modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of
- interfaces. A component is typically specified by one or more classes or subcomponents that reside on it and
- may be implemented by one or more artifacts (e.g., binary, executable, or script files).
- </div>
- <div align="left">
- <p>
- In UML 1.3 and earlier versions of the UML, the component notation was used to represent files in the
- implementation. Files are no longer considered components by the latest UML definitions. However, many
- tools and UML profiles still use the component notation to represent files.
- </p>
- <p>
- <br />
- <br />
- &nbsp;
- </p>
- </div>
- </blockquote>
+ <mainDescription><h3 align="left">
+ Modeling Components
+</h3>
+<p align="left">
+ The UML component is a modeling construct that provides the following capabilities:
+</p>
+<div align="left">
+ <ul>
+ <li>
+ Group classes to define a larger granularity part of a system
+ </li>
+ <li>
+ Separate the visible interfaces from internal implementation
+ </li>
+ <li>
+ Execute instances run-time
+ </li>
+ </ul>
+</div>
+<p align="left">
+ A component includes <strong>provided</strong> and <strong>required</strong> interfaces that form the basis for wiring
+ components together. A <strong>provided interface</strong> is one that is either implemented directly by the component
+ or one of its realizing classes or subcomponents, or it is the type of a provided port of the component. A
+ <strong>required interface</strong> is designated by a usage dependency of the component or one of its realizing
+ classes or subcomponents, or it is the type of a required port.
+</p>
+<p align="left">
+ A component has an external view (or <em>black box</em> view) through its publicly visible properties and operations
+ .Optionally, a behavior such as a protocol state machine may be attached to an interface, a port, and the component
+ itself to define the external view more precisely by making dynamic constraints in the sequence of operation calls
+ explicit. The wiring between components in a system or other context can be structurally defined by using dependencies
+ between component interfaces (typically on component diagrams).
+</p>
+<p align="left">
+ Optionally, you can make a more detailed specification of the structural collaboration by using parts and connectors in
+ composite structures to specify the role or instance-level collaboration between components. That is the component's
+ internal view (or <em>white-box</em> view) through its private properties and realizing classes or subcomponents. This
+ view shows how the external behavior is realized internally. The mapping between external and internal views is by
+ dependencies on components diagrams or delegation connectors to internal parts on composite structure diagrams.
+</p>
+<p align="left">
+ A number of UML standard stereotypes exist that apply to components, including &lt;&lt;subsystem&gt;&gt; to model
+ large-scale components, and &lt;&lt;specification&gt;&gt; and &lt;&lt;realization&gt;&gt; to model components with
+ distinct specification and realization definitions, where one specification may have multiple realizations.&nbsp;
+</p>
+<p align="left">
+ The recommendation is to&nbsp;use components as the representation for design subsystems.
+</p>
+<h3 align="left">
+ UML Definitions -- A History
+</h3>
+<p align="left">
+ The definition of <em>component</em> with the UML has changed over time with the release of different versions. The
+ version of UML you use may be constrained by the capabilities of the modeling tools you use. That is why the
+ definitions from 1.3 to 2.0 are provided here.
+</p>
+<p align="left">
+ UML 2.0 defined <em>component</em> as the following:
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote>
+ <p align="left">
+ ...a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its
+ environment.
+ </p>
+ <p align="left">
+ A component defines its behavior in terms of provided and required interfaces. As such, a component serves as a
+ type whose conformance is defined by these provided and required interfaces (encompassing both their static as
+ well as dynamic semantics).
+ </p>
+ </blockquote>
+</blockquote>
+<p align="left">
+ UML 1.5 defined <em>component</em> as the following:
+</p>
+<blockquote>
+ <blockquote>
+ <div align="left">
+ A modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of
+ interfaces. A component is typically specified by one or more classes or subcomponents that reside on it and
+ may be implemented by one or more artifacts (e.g., binary, executable, or script files).
+ </div>
+ <div align="left">
+ <p>
+ In UML 1.3 and earlier versions of the UML, the component notation was used to represent files in the
+ implementation. Files are no longer considered components by the latest UML definitions. However, many
+ tools and UML profiles still use the component notation to represent files.
+ </p>
+ <p>
+ <br />
+ <br />
+ &nbsp;
+ </p>
+ </div>
+ </blockquote>
</blockquote></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/component.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/component.xmi
index 3dea941..0ae956f 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/component.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/component.xmi
@@ -1,121 +1,123 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_TZiasMM1EdmSIPI87WLu3g" name="component,_0YP18MlgEdmt3adZL5Dmdw" guid="_TZiasMM1EdmSIPI87WLu3g" changeDate="2008-02-16T11:28:21.000-0800" version="1.0.0">
- <mainDescription><p align="left">
- The software industry and literature use the term <strong>componen</strong>t to refer to many different things. It is
- often used in the broad sense to mean a constituent part. It is also frequently used in a narrow sense to denote
- specific characteristics that enable replacement and assembly in larger systems.
-</p>
-<p align="left">
- The Unified Modeling Language [<a class="elementLinkWithUserText" href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html" guid="_9ToeIB83Edqsvps02rpOOg">UML05</a>] defines <em>component</em> as follows:
-</p>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <blockquote>
- <p>
- A modular part of a system that encapsulates its contents and whose manifestation is replaceable within its
- environment. A component defines its behavior in terms of provided and required interfaces. As such, a
- component serves as a type, whose conformance is defined by these provided and required interfaces
- (encompassing both their static as well as dynamic semantics).
- </p>
- <p>
- A <em>component</em> is defined as a subtype of structured class. Therefore, a component has attributes and
- operations, is able to participate in associations and generalizations, and has internal structure and ports.
- </p>
- </blockquote>
-</blockquote>
-<p align="left">
- Here, we use&nbsp;the term <em>component&nbsp;</em>in a&nbsp;broader way than the UML definition. Rather than defining
- components as having characteristics, such as modularity, deployability, and replaceability, we instead recommend these
- as desirable characteristics of components. We use <em>component</em> to mean <strong>an encapsulated part of a
- system</strong> that is nontrivial, nearly independent, and replaceable part of a system that fulfills a clear function
- in the context of well-defined architecture. This includes two types of components:
-</p>
-<ul>
- <li>
- <div align="left">
- <p>
- <strong>Design component.</strong> A significant encapsulated part of the design that includes design
- subsystems and, sometimes, significant design classes and design packages.
- </p>
- </div>
- </li>
- <li>
- <div align="left">
- <p>
- <strong>Implementation component.</strong> A significant encapsulated part of the implementation, generally
- code that implements a design component.
- </p>
- </div>
- </li>
-</ul>
-<p align="left">
- Ideally, the design reflects the implementation; therefore, you can simply refer to <em>components</em>, with each
- component having a design and an implementation.
-</p>
-<p align="left">
- Components interact through interfaces&nbsp;and&nbsp;may be composed of successively smaller components and interfaces.
-</p>
-<h3 align="left">
- Component replaceability
-</h3>
-<p align="left">
- In UML terminology, components should be replaceable. However, this may mean only that the component exposes a set of
- interfaces that hide an underlying implementation.
-</p>
-<p align="left">
- There are other, stronger, kinds of replaceability: .
-</p>
-<div align="left">
- <ul>
- <li>
- <p>
- <strong>Source file replaceability:</strong> If two classes are implemented in a single source code file,
- then those classes cannot usually be separately versioned and controlled. However, if a set of files fully
- implements a single component (and no other component), then the component source files are replaceable.
- This characteristic makes it easier to use version control, to use the file as a baseline, and to reuse the
- source file.
- </p>
- </li>
- <li>
- <p>
- <strong>Deployment replaceability:</strong> If two classes are deployed in a single executable file, then
- each class is not independently replaceable in a deployed system. It is desirable for larger-granularity
- components to be replaceable during deployment, which allows new versions of the component to be deployed
- without having to rebuild the other components. This usually means that there is one file or one set of
- files that deploy the component, and no other component.
- </p>
- </li>
- <li>
- <p>
- <strong>Run-time replaceability:</strong> If a component can be redeployed into a running system, then it
- is referred to as <em>run-time replaceable</em>. This enables you to upgrade software without loss of
- availability.
- </p>
- </li>
- <li>
- <p>
- <strong>Location transparency:</strong> Components with network-addressable interfaces are referred to as
- having <em>location transparency</em>. This allows components to be relocated to other servers or to be
- replicated on multiple servers to support fault tolerance, load balancing, and so on. These kinds of
- components are often referred to as <em>distributed</em> or <em>distributable</em> components.
- </p>
- </li>
- </ul>
-</div>
-<h3 align="left">
- Component instantiation
-</h3>
-<p align="left">
- A component may or may not be directly instantiated at run time.
-</p>
-<p align="left">
- An indirectly instantiated component is implemented, or realized, by a set of classes, subcomponents, or parts. The
- component itself does not appear in the implementation; it merely serves as a design that an implementation must
- follow. The set of realizing classes, subcomponents, or parts must cover the entire set of operations specified in the
- provided interface of the component. The manner of implementing the component is the responsibility of the implementer.
-</p>
-<p align="left">
- A directly instantiated component specifies its own encapsulated implementation. It is instantiated as an addressable
- object, which means that a design component has a corresponding construct in the implementation language; therefore, it
- can be referenced explicitly.
+ <mainDescription><p align="left">
+ The software industry and literature use the term <strong>componen</strong>t to refer to many different things. It is
+ often used in the broad sense to mean a constituent part. It is also frequently used in a narrow sense to denote
+ specific characteristics that enable replacement and assembly in larger systems.
+</p>
+<p align="left">
+ The Unified Modeling Language [<a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">UML05</a>] defines <em>component</em> as follows:
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote>
+ <p>
+ A modular part of a system that encapsulates its contents and whose manifestation is replaceable within its
+ environment. A component defines its behavior in terms of provided and required interfaces. As such, a
+ component serves as a type, whose conformance is defined by these provided and required interfaces
+ (encompassing both their static as well as dynamic semantics).
+ </p>
+ <p>
+ A <em>component</em> is defined as a subtype of structured class. Therefore, a component has attributes and
+ operations, is able to participate in associations and generalizations, and has internal structure and ports.
+ </p>
+ </blockquote>
+</blockquote>
+<p align="left">
+ Here, we use&nbsp;the term <em>component&nbsp;</em>in a&nbsp;broader way than the UML definition. Rather than defining
+ components as having characteristics, such as modularity, deployability, and replaceability, we instead recommend these
+ as desirable characteristics of components. We use <em>component</em> to mean <strong>an encapsulated part of a
+ system</strong> that is nontrivial, nearly independent, and replaceable part of a system that fulfills a clear function
+ in the context of well-defined architecture. This includes two types of components:
+</p>
+<ul>
+ <li>
+ <div align="left">
+ <p>
+ <strong>Design component.</strong> A significant encapsulated part of the design that includes design
+ subsystems and, sometimes, significant design classes and design packages.
+ </p>
+ </div>
+ </li>
+ <li>
+ <div align="left">
+ <p>
+ <strong>Implementation component.</strong> A significant encapsulated part of the implementation, generally
+ code that implements a design component.
+ </p>
+ </div>
+ </li>
+</ul>
+<p align="left">
+ Ideally, the design reflects the implementation; therefore, you can simply refer to <em>components</em>, with each
+ component having a design and an implementation.
+</p>
+<p align="left">
+ Components interact through interfaces&nbsp;and&nbsp;may be composed of successively smaller components and interfaces.
+</p>
+<h3 align="left">
+ Component replaceability
+</h3>
+<p align="left">
+ In UML terminology, components should be replaceable. However, this may mean only that the component exposes a set of
+ interfaces that hide an underlying implementation.
+</p>
+<p align="left">
+ There are other, stronger, kinds of replaceability: .
+</p>
+<div align="left">
+ <ul>
+ <li>
+ <p>
+ <strong>Source file replaceability:</strong> If two classes are implemented in a single source code file,
+ then those classes cannot usually be separately versioned and controlled. However, if a set of files fully
+ implements a single component (and no other component), then the component source files are replaceable.
+ This characteristic makes it easier to use version control, to use the file as a baseline, and to reuse the
+ source file.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Deployment replaceability:</strong> If two classes are deployed in a single executable file, then
+ each class is not independently replaceable in a deployed system. It is desirable for larger-granularity
+ components to be replaceable during deployment, which allows new versions of the component to be deployed
+ without having to rebuild the other components. This usually means that there is one file or one set of
+ files that deploy the component, and no other component.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Run-time replaceability:</strong> If a component can be redeployed into a running system, then it
+ is referred to as <em>run-time replaceable</em>. This enables you to upgrade software without loss of
+ availability.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Location transparency:</strong> Components with network-addressable interfaces are referred to as
+ having <em>location transparency</em>. This allows components to be relocated to other servers or to be
+ replicated on multiple servers to support fault tolerance, load balancing, and so on. These kinds of
+ components are often referred to as <em>distributed</em> or <em>distributable</em> components.
+ </p>
+ </li>
+ </ul>
+</div>
+<h3 align="left">
+ Component instantiation
+</h3>
+<p align="left">
+ A component may or may not be directly instantiated at run time.
+</p>
+<p align="left">
+ An indirectly instantiated component is implemented, or realized, by a set of classes, subcomponents, or parts. The
+ component itself does not appear in the implementation; it merely serves as a design that an implementation must
+ follow. The set of realizing classes, subcomponents, or parts must cover the entire set of operations specified in the
+ provided interface of the component. The manner of implementing the component is the responsibility of the implementer.
+</p>
+<p align="left">
+ A directly instantiated component specifies its own encapsulated implementation. It is instantiated as an addressable
+ object, which means that a design component has a corresponding construct in the implementation language; therefore, it
+ can be referenced explicitly.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/design_mechanism.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/design_mechanism.xmi
index da7e361..86b3d19 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/design_mechanism.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/design_mechanism.xmi
@@ -1,22 +1,22 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-EG22TRyJ5TDKW6U88AXfhw" name="design_mechanism,_hNXugOUuEdqGCpzGJ4tJOw" guid="-EG22TRyJ5TDKW6U88AXfhw" changeDate="2008-10-13T01:54:58.000-0700" version="1.0.0">
- <mainDescription><p align="left">
- A Design Mechanism is a concrete representation of an <a class="elementLink"
- href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_mechanism_2932DFB6.html"
- guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a>. It is refined from an <a class="elementLink"
- href="./../../../core.tech.common.extend_supp/guidances/concepts/analysis_mechanism_8369C159.html"
- guid="_0gvqoMlgEdmt3adZL5Dmdw">Analysis Mechanism</a>&nbsp;and is further refined into an <a class="elementLink"
- href="./../../../core.tech.common.extend_supp/guidances/concepts/implementation_mechanism_C92E670B.html"
- guid="_0LcUkA4LEduibvKwrGxWxA">Implementation Mechanism</a>&nbsp;as the design becomes more detailed.
-</p>
-<p align="left">
- Design Mechanisms can be&nbsp;represented as specific design patterns and frameworks&nbsp;in the design.&nbsp; They are
- used&nbsp;to guide development. Design Mechanisms should still be relatively independent of implementation but provide
- enough detailed information for implementation choices to be made and software to be developed with confidence.
-</p>
-<p align="left">
- See <a class="elementLink"
- href="./../../../core.tech.common.extend_supp/guidances/guidelines/example_design_mechanisms_7762C0FB.html"
- guid="_4k_Hsg4LEduibvKwrGxWxA">Example: Design Mechanisms</a>.
+ <mainDescription><p align="left">
+ A Design Mechanism is a concrete representation of an <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_mechanism_2932DFB6.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a>. It is refined from an <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/analysis_mechanism_8369C159.html"
+ guid="_0gvqoMlgEdmt3adZL5Dmdw">Analysis Mechanism</a>&nbsp;and is further refined into an <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/implementation_mechanism_C92E670B.html"
+ guid="_0LcUkA4LEduibvKwrGxWxA">Implementation Mechanism</a>&nbsp;as the design becomes more detailed.
+</p>
+<p align="left">
+ Design Mechanisms can be&nbsp;represented as specific design patterns and frameworks&nbsp;in the design.&nbsp; They are
+ used&nbsp;to guide development. Design Mechanisms should still be relatively independent of implementation but provide
+ enough detailed information for implementation choices to be made and software to be developed with confidence.
+</p>
+<p align="left">
+ See <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/guidances/guidelines/example_design_mechanisms_7762C0FB.html"
+ guid="_4k_Hsg4LEduibvKwrGxWxA">Example: Design Mechanisms</a>.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/developer_testing.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/developer_testing.xmi
index 19fca97..6677adf 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/developer_testing.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/developer_testing.xmi
@@ -1,63 +1,63 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-EOoqKeF2SEXao6XhNXBD-w" name=",_ADwlAJRtEdyrdaw_xGakyw" guid="-EOoqKeF2SEXao6XhNXBD-w" changeDate="2008-08-12T05:15:16.000-0700" version="7.2.0">
- <mainDescription><p>
- Developer testing is the act of regression testing source code by developers. This is sometimes called "unit regression
- testing" but many developer tests go beyond unit testing to address integration testing as well.
-</p>
-<h3>
- Testing Philosophies
-</h3>
-<p>
- Here are some important philosophies with regard to developer testing:
-</p>
-<ol>
- <li>
- The goal is to find defects. Successful tests find bugs, but correcting the bugs falls into other areas.
- </li>
- <li>
- Test early and often. The cost of change rises exponentially the longer it takes to find and then remove a defect.
- The implication is that you want to test as early as possible.
- </li>
- <li>
- Testing builds confidence. Many people fear making a change to their code because they are afraid that they will
- break it, but with a full test suite in place if you do break something you know you will detect it and then fix
- it.
- </li>
- <li>
- One test is worth a thousand opinions. You can say that your application works, but until you show the test results
- you might not be believed.
- </li>
- <li>
- Test to the risk. The riskier something is, the more it needs to be reviewed and tested. For example, you should
- invest significantly more&nbsp;effort testing a safety-critical algorithm for measuring radiation doses, and far
- less effort testing the "change font size" function of the same application.
- </li>
- <li>
- You can validate all artifacts. You can test all your artifacts, not just your source code, although the focus of
- this guidance is testing code.
- </li>
-</ol>
-<h3>
- Qualities of a Good Developer Test
-</h3>These are the qualities of a good developer test:
-<ul class="noindent">
- <li>
- It runs fast. It has short setup, run time, and clean-up.
- </li>
- <li>
- It runs in isolation. You should be able to reorder your tests.
- </li>
- <li>
- It is understandable. Good tests have consistent and informative names and use data that makes them easy to read
- and to understand.
- </li>
- <li>
- It uses real data. For example, use copies of production data when appropriate, but remember that you'll typically
- have to create some specific "artificial" test data as well.
- </li>
- <li>
- It is minimally cohesive. The test represents one step toward your overall goal. The test should address one and
- one only issue.
- </li>
+ <mainDescription><p>
+ Developer testing is the act of regression testing source code by developers. This is sometimes called "unit regression
+ testing" but many developer tests go beyond unit testing to address integration testing as well.
+</p>
+<h3>
+ Testing Philosophies
+</h3>
+<p>
+ Here are some important philosophies with regard to developer testing:
+</p>
+<ol>
+ <li>
+ The goal is to find defects. Successful tests find bugs, but correcting the bugs falls into other areas.
+ </li>
+ <li>
+ Test early and often. The cost of change rises exponentially the longer it takes to find and then remove a defect.
+ The implication is that you want to test as early as possible.
+ </li>
+ <li>
+ Testing builds confidence. Many people fear making a change to their code because they are afraid that they will
+ break it, but with a full test suite in place if you do break something you know you will detect it and then fix
+ it.
+ </li>
+ <li>
+ One test is worth a thousand opinions. You can say that your application works, but until you show the test results
+ you might not be believed.
+ </li>
+ <li>
+ Test to the risk. The riskier something is, the more it needs to be reviewed and tested. For example, you should
+ invest significantly more&nbsp;effort testing a safety-critical algorithm for measuring radiation doses, and far
+ less effort testing the "change font size" function of the same application.
+ </li>
+ <li>
+ You can validate all artifacts. You can test all your artifacts, not just your source code, although the focus of
+ this guidance is testing code.
+ </li>
+</ol>
+<h3>
+ Qualities of a Good Developer Test
+</h3>These are the qualities of a good developer test: 
+<ul class="noindent">
+ <li>
+ It runs fast. It has short setup, run time, and clean-up.
+ </li>
+ <li>
+ It runs in isolation. You should be able to reorder your tests.
+ </li>
+ <li>
+ It is understandable. Good tests have consistent and informative names and use data that makes them easy to read
+ and to understand.
+ </li>
+ <li>
+ It uses real data. For example, use copies of production data when appropriate, but remember that you'll typically
+ have to create some specific "artificial" test data as well.
+ </li>
+ <li>
+ It is minimally cohesive. The test represents one step toward your overall goal. The test should address one and
+ one only issue.
+ </li>
</ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/executable_arch.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/executable_arch.xmi
index 037545e..19f1fb1 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/executable_arch.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/executable_arch.xmi
@@ -1,39 +1,43 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-0R8BZWlcCQ3Rj84jY2M3Kw" name="new_concept,_O1kAANvfEduv2KOT-Teh6w" guid="-0R8BZWlcCQ3Rj84jY2M3Kw" changeDate="2008-09-03T05:26:10.000-0700" version="1.0.0">
- <mainDescription><p>
- An executable architecture is an implementation that realizes the <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/concepts/software_architecture_59A08DE0.html" guid="__O7tAMVvEduLYZUGfgZrkQ">Software Architecture</a>. It is used to validate that the <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_significant_requirements_1EE5D757.html" guid="_HrZGIA4MEduibvKwrGxWxA">Architecturally Significant Requirements</a>&nbsp;are correctly implemented. It
- validates the architecture as an integrated whole through integration tests. The team gains feedback about the
- architecture from the customer or stakeholder by providing the executable architecture for verification. This way the
- executable architecture helps to assure that the core functionality is stable enough to build the remainder of the
- system.
-</p>
-<p>
- An executable architecture is not a work product. It's an identification or attribute of the implementation,
- indicating&nbsp;that the implementation&nbsp;contains stable architecturally significant functionality.&nbsp;
-</p>
-<p>
- Each version of an executable architecture should be more complete and robust than previous versions. The final
- executable architecture contains all the elements that make up the architecture and should validate all architecturally
- significant requirements. There may be rare exceptions where a portion of the architecture can't practically be
- implemented until later due to uncontrollable circumstances such as constraints with third part software or unique
- resources that are unavailable.&nbsp;Delaying any part of the architecture should be avoided as it raises significant
- technical risk later in the project. But if circumstances dictate that some architectural risk can't be mitigated
- until&nbsp;later in development, a&nbsp;conscious decision can be made to carry this risk forward until the
- architecture can be fully implemented.
-</p>
-<p>
- It's also possible to include non-architectural elements into an executable architecture. This will most likely happen
- when addressing high risk issues early in the development cycle, which is an excellent practice. Two examples of
- non-technical risks are resource risks and competitive risks. It may be desirable to obtain a difficult-to-get resource
- early so they can work on a unique piece of the software now, rather than hoping the resource will be available later.
- Or it may be useful to implement and deploy some early features to maintain market share against a competitor. Think of
- the executable architecture as a way to mitigate architectural risk, which is the most significant technical risk in a
- project. From this perspective, it's appropriate to mitigate other risks in the executable architecture.
-</p>
-<p>
- The difference between the executable architecture and the implementation later in the development cycle is that the
- executable architecture is the result of a period of development (for example&nbsp;an iteration) that's dedicated to
- elaborating the architecture. Later iterations build onto the executable architecture but are not flagged as an
- executable architecture because they extend the system's functionality beyond the architectural framework.
+ <mainDescription><p>
+ An executable architecture is an implementation that realizes the <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/software_architecture_59A08DE0.html"
+ guid="__O7tAMVvEduLYZUGfgZrkQ">Software Architecture</a>. It is used to validate that the <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_significant_requirements_1EE5D757.html"
+ guid="_HrZGIA4MEduibvKwrGxWxA">Architecturally Significant Requirements</a>&nbsp;are correctly implemented. It
+ validates the architecture as an integrated whole through integration tests. The team gains feedback about the
+ architecture from the customer or stakeholder by providing the executable architecture for verification. This way the
+ executable architecture helps to assure that the core functionality is stable enough to build the remainder of the
+ system.
+</p>
+<p>
+ An executable architecture is not a work product. It's an identification or attribute of the implementation,
+ indicating&nbsp;that the implementation&nbsp;contains stable architecturally significant functionality.&nbsp;
+</p>
+<p>
+ Each version of an executable architecture should be more complete and robust than previous versions. The final
+ executable architecture contains all the elements that make up the architecture and should validate all architecturally
+ significant requirements. There may be rare exceptions where a portion of the architecture can't practically be
+ implemented until later due to uncontrollable circumstances such as constraints with third part software or unique
+ resources that are unavailable.&nbsp;Delaying any part of the architecture should be avoided as it raises significant
+ technical risk later in the project. But if circumstances dictate that some architectural risk can't be mitigated
+ until&nbsp;later in development, a&nbsp;conscious decision can be made to carry this risk forward until the
+ architecture can be fully implemented.
+</p>
+<p>
+ It's also possible to include non-architectural elements into an executable architecture. This will most likely happen
+ when addressing high risk issues early in the development cycle, which is an excellent practice. Two examples of
+ non-technical risks are resource risks and competitive risks. It may be desirable to obtain a difficult-to-get resource
+ early so they can work on a unique piece of the software now, rather than hoping the resource will be available later.
+ Or it may be useful to implement and deploy some early features to maintain market share against a competitor. Think of
+ the executable architecture as a way to mitigate architectural risk, which is the most significant technical risk in a
+ project. From this perspective, it's appropriate to mitigate other risks in the executable architecture.
+</p>
+<p>
+ The difference between the executable architecture and the implementation later in the development cycle is that the
+ executable architecture is the result of a period of development (for example&nbsp;an iteration) that's dedicated to
+ elaborating the architecture. Later iterations build onto the executable architecture but are not flagged as an
+ executable architecture because they extend the system's functionality beyond the architectural framework.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/failure_analysis_rpt_creation.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/failure_analysis_rpt_creation.xmi
index a20c605..d6f2862 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/failure_analysis_rpt_creation.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/failure_analysis_rpt_creation.xmi
@@ -1,76 +1,76 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-9gUpkUYqONF3x8UWwAO_zw" name="failure_analysis_rpt_creation,_0jhR0MlgEdmt3adZL5Dmdw" guid="-9gUpkUYqONF3x8UWwAO_zw" changeDate="2006-09-29T01:52:52.000-0700" version="1.0.0">
- <mainDescription><h3>
- Introduction
-</h3>
-<p>
- During testing, you will encounter failures related to the execution of your tests in different forms, such as code
- defects, user errors, program malfunctions, and general problems. This&nbsp;concept discusses some ways to conduct
- failure analysis and then to report your findings.
-</p>
-<h3>
- Failure Analysis
-</h3>
-<p>
- After you have run your tests, it is good practice to identify inputs for review of the results of the testing effort.
- Some likely sources are defects that occurred during the execution of test scripts, change request metrics, and test
- log details.
-</p>
-<p>
- Running test scripts results in errors of different kinds such as uncovered defects, unexpected behavior, or general
- failure of the test script to run properly. When you run test scripts, one of the most important things to do is to
- identify causes and effects of failure. It is important to differentiate failures in the system under test&nbsp;from
- those related to the tests themselves.
-</p>
-<p>
- Change request metrics are useful in analyzing and correcting failures in the testing. Select metrics that will
- facilitate creation of incident reports from a collection of change requests.
-</p>
-<p>
- Change request metrics that you may find useful in your failure analysis include:
-</p>
-<ul>
- <li>
- test coverage
- </li>
- <li>
- priority
- </li>
- <li>
- impact
- </li>
- <li>
- defect trends
- </li>
- <li>
- density
- </li>
-</ul>
-<p>
- Finally, one of the most critical sources of your failure analysis is the test log. Start by gathering the test log's
- output during the implementation and execution of the tests. Relevant logs might come from many sources; they might be
- captured by the tools you use (both test execution and diagnostic tools), generated by custom-written routines your
- team has developed, output from the target test items themselves, and recorded manually be the tester. Gather all of
- the available test log sources and examine their content. Check that all the scheduled testing executed to completion,
- and that all the needed tests&nbsp;have been scheduled.
-</p>
-<h3>
- Self-Documenting Tests
-</h3>
-<p>
- For automated tests it is a best practice for the test itself to examine the results and clearly report itself as
- passing or failing. This provides the most efficient way to run tests such that whole suites of tests can be run with
- each test in turn determining whether it has passed or failed without the need for human intervention. When authoring
- self-documenting tests, take extra care to ensure that the analysis of the results considers all possibilities.
-</p>
-<h3>
- Recording Your Findings
-</h3>
-<p>
- Once you have conducted your failure analysis, you may decide to formalize the results of this analysis by recording
- your findings in a report. There are several factors that go into deciding whether to record your failure analysis in a
- report. Some of the key factors include: level of testing formality, complexity of the testing effort, and the need to
- communicate the testing results to the entire development team. In less formal environments, it may be sufficient to
- record your failure analysis in&nbsp;a test evaluation summary.
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ During testing, you will encounter failures related to the execution of your tests in different forms, such as code
+ defects, user errors, program malfunctions, and general problems. This&nbsp;concept discusses some ways to conduct
+ failure analysis and then to report your findings.
+</p>
+<h3>
+ Failure Analysis
+</h3>
+<p>
+ After you have run your tests, it is good practice to identify inputs for review of the results of the testing effort.
+ Some likely sources are defects that occurred during the execution of test scripts, change request metrics, and test
+ log details.
+</p>
+<p>
+ Running test scripts results in errors of different kinds such as uncovered defects, unexpected behavior, or general
+ failure of the test script to run properly. When you run test scripts, one of the most important things to do is to
+ identify causes and effects of failure. It is important to differentiate failures in the system under test&nbsp;from
+ those related to the tests themselves.
+</p>
+<p>
+ Change request metrics are useful in analyzing and correcting failures in the testing. Select metrics that will
+ facilitate creation of incident reports from a collection of change requests.
+</p>
+<p>
+ Change request metrics that you may find useful in your failure analysis include:
+</p>
+<ul>
+ <li>
+ test coverage
+ </li>
+ <li>
+ priority
+ </li>
+ <li>
+ impact
+ </li>
+ <li>
+ defect trends
+ </li>
+ <li>
+ density
+ </li>
+</ul>
+<p>
+ Finally, one of the most critical sources of your failure analysis is the test log. Start by gathering the test log's
+ output during the implementation and execution of the tests. Relevant logs might come from many sources; they might be
+ captured by the tools you use (both test execution and diagnostic tools), generated by custom-written routines your
+ team has developed, output from the target test items themselves, and recorded manually be the tester. Gather all of
+ the available test log sources and examine their content. Check that all the scheduled testing executed to completion,
+ and that all the needed tests&nbsp;have been scheduled.
+</p>
+<h3>
+ Self-Documenting Tests
+</h3>
+<p>
+ For automated tests it is a best practice for the test itself to examine the results and clearly report itself as
+ passing or failing. This provides the most efficient way to run tests such that whole suites of tests can be run with
+ each test in turn determining whether it has passed or failed without the need for human intervention. When authoring
+ self-documenting tests, take extra care to ensure that the analysis of the results considers all possibilities.
+</p>
+<h3>
+ Recording Your Findings
+</h3>
+<p>
+ Once you have conducted your failure analysis, you may decide to formalize the results of this analysis by recording
+ your findings in a report. There are several factors that go into deciding whether to record your failure analysis in a
+ report. Some of the key factors include: level of testing formality, complexity of the testing effort, and the need to
+ communicate the testing results to the entire development team. In less formal environments, it may be sufficient to
+ record your failure analysis in&nbsp;a test evaluation summary.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/implementation_mechanism.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/implementation_mechanism.xmi
index 7e39661..8ea6ee5 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/implementation_mechanism.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/implementation_mechanism.xmi
@@ -1,40 +1,40 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-Rex8oOBv985RruZNrCW0rg" name="implementation_mechanisms,_3ANskOK5EdqHEo0wLIc5jg" guid="-Rex8oOBv985RruZNrCW0rg" changeDate="2006-09-25T01:09:13.000-0700" version="1.0.0">
- <mainDescription><p>
- An Implementation Mechanism is a refinement of a corresponding Design Mechanism that uses, for example, a particular
- programming language and other implementation technology (such as a particular vendor's middleware product). An
- Implementation Mechanism may instantiate one or more idioms or implementation patterns.
-</p>
-<p>
- Review these points when you are considering Implementation Mechanisms:
-</p>
-<ul>
- <li>
- <p>
- <b>Determine the ranges of characteristics.</b> Take the characteristics that you identified for the Design
- Mechanisms into consideration to determine reasonable, economical, or feasible ranges of values to use in the
- Implementation Mechanism candidate.
- </p>
- </li>
- <li>
- <p>
- <b>Consider the cost of purchased components</b>. For Implementation Mechanism candidates, consider the cost of
- licensing, the maturity of the product, your history or relationship with the vendor, support, and so forth in
- addition to purely technical criteria.
- </p>
- </li>
- <li>
- <p>
- <b>Conduct a search for the right components, or build the components.</b> You will often find that there is no
- apparently suitable Implementation Mechanism for a particular Design Mechanism. This will either trigger a
- search for the right product or make the need for in-house development apparent. You may also find that some
- Implementation Mechanisms are not used at all.<br />
- <br />
- The choice of Implementation Mechanisms is based not only on a good match for the technical characteristics,
- but also on the non-technical characteristics, such as cost. Some of the choices may be provisional. Almost all
- have some risks attached to them. Performance, robustness, and scalability are nearly always concerns and must
- be validated by evaluation, exploratory prototyping, or inclusion in the architectural prototype.
- </p>
- </li>
+ <mainDescription><p>
+ An Implementation Mechanism is a refinement of a corresponding Design Mechanism that uses, for example, a particular
+ programming language and other implementation technology (such as a particular vendor's middleware product). An
+ Implementation Mechanism may instantiate one or more idioms or implementation patterns.
+</p>
+<p>
+ Review these points when you are considering Implementation Mechanisms:
+</p>
+<ul>
+ <li>
+ <p>
+ <b>Determine the ranges of characteristics.</b> Take the characteristics that you identified for the Design
+ Mechanisms into consideration to determine reasonable, economical, or feasible ranges of values to use in the
+ Implementation Mechanism candidate.
+ </p>
+ </li>
+ <li>
+ <p>
+ <b>Consider the cost of purchased components</b>. For Implementation Mechanism candidates, consider the cost of
+ licensing, the maturity of the product, your history or relationship with the vendor, support, and so forth in
+ addition to purely technical criteria.
+ </p>
+ </li>
+ <li>
+ <p>
+ <b>Conduct a search for the right components, or build the components.</b> You will often find that there is no
+ apparently suitable Implementation Mechanism for a particular Design Mechanism. This will either trigger a
+ search for the right product or make the need for in-house development apparent. You may also find that some
+ Implementation Mechanisms are not used at all.<br />
+ <br />
+ The choice of Implementation Mechanisms is based not only on a good match for the technical characteristics,
+ but also on the non-technical characteristics, such as cost. Some of the choices may be provisional. Almost all
+ have some risks attached to them. Performance, robustness, and scalability are nearly always concerns and must
+ be validated by evaluation, exploratory prototyping, or inclusion in the architectural prototype.
+ </p>
+ </li>
</ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/key_abstractions.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/key_abstractions.xmi
index daa718b..9b2411d 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/key_abstractions.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/key_abstractions.xmi
@@ -1,21 +1,21 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-HJbvivaRmrZ6rdQcdFd78Q" name="new_concept,_pLEGUNqGEdy88NBoQgfGyg" guid="-HJbvivaRmrZ6rdQcdFd78Q" version="7.2.0">
- <mainDescription><p>
- Key abstractions are the key concepts and abstractions that the system needs to handle. They are those things that,
- without which, you could not describe the system.
-</p>
-<p>
- The requirements are good sources for key abstractions. These abstractions are often easily identified because they
- represent things that are significant to the business. For example, Customer and Account are typical key abstractions
- in the banking business.
-</p>
-<p>
- Each key abstraction should have a short description.&nbsp; The are usually not described in detail as they will change
- and evolve&nbsp;during the course of the project (as they are refined into actual design elements).&nbsp;
-</p>
-<p>
- The value of defining the key abstractions (and any obvious relationships between them) is that they establish a common
- understanding of the key concepts amongst the team, thereby enabling them to develop a&nbsp;coherent solution that
- handles them consistently.&nbsp;
+ <mainDescription><p>
+ Key abstractions are the key concepts and abstractions that the system needs to handle. They are those things that,
+ without which, you could not describe the system.
+</p>
+<p>
+ The requirements are good sources for key abstractions. These abstractions are often easily identified because they
+ represent things that are significant to the business. For example, Customer and Account are typical key abstractions
+ in the banking business.
+</p>
+<p>
+ Each key abstraction should have a short description.&nbsp; The are usually not described in detail as they will change
+ and evolve&nbsp;during the course of the project (as they are refined into actual design elements).&nbsp;
+</p>
+<p>
+ The value of defining the key abstractions (and any obvious relationships between them) is that they establish a common
+ understanding of the key concepts amongst the team, thereby enabling them to develop a&nbsp;coherent solution that
+ handles them consistently.&nbsp;
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/pattern.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/pattern.xmi
index 615cb92..d4782a2 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/pattern.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/pattern.xmi
@@ -1,288 +1,288 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_QvmkAMM1EdmSIPI87WLu3g" name="patterns,_0YJvUMlgEdmt3adZL5Dmdw" guid="_QvmkAMM1EdmSIPI87WLu3g" changeDate="2008-09-03T05:26:48.000-0700" version="1.0.0">
- <mainDescription><h4>
- Origins
-</h4>
-<p>
- The idea of patterns as it is now applied to software design comes from the work of Christopher Alexander. He has
- written widely on the subject of applying patterns to the design and construction of towns and buildings. Two of his
- books, <em>A Pattern Language</em> [<a class="elementLinkWithUserText"
- href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
- guid="_9ToeIB83Edqsvps02rpOOg">ALE77</a>] and <em>The Timeless Way of Building</em> [<a class="elementLinkWithUserText"
- href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
- guid="_9ToeIB83Edqsvps02rpOOg">ALE79</a>] have had the greatest impact on the software community and the adoption of
- software patterns for the design of software. His concepts of patterns and pattern language provide a model for the
- capture of software design expertise in a form that can then be reapplied in recurring situations.&nbsp;
-</p>
-<h4>
- A definition of patterns
-</h4>
-<p>
- Today, the most commonly used definition of software patterns is from [<a class="elementLinkWithUserText"
- href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
- guid="_9ToeIB83Edqsvps02rpOOg">GAM95</a>]:
-</p>
-<blockquote>
- <p>
- "A design pattern describes the problem, a solution to the problem consisting of a general arrangement of objects
- and classes, when to apply the solution, and the consequences of applying the solution."
- </p>
-</blockquote>
-<p>
- This definition often serves only as a starting point, however. A richer definition, based on Alexander's work, is
- offered by Gabriel in his book, <em>A Timeless Way of Hacking</em> [<a class="elementLinkWithUserText"
- href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
- guid="_9ToeIB83Edqsvps02rpOOg">ALU03</a>], in which each pattern is a three-part rule that expresses relationships
- among a certain context, a certain system of forces that occur repeatedly in that context, and a certain software
- configuration that allows these forces to resolve themselves.
-</p>
-<h4>
- Describing patterns
-</h4>
-<p>
- It is commonplace to describe patterns&nbsp;using the&nbsp;format made popular by Erich Gamma and his three colleagues
- [<a class="elementLinkWithUserText"
- href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
- guid="_9ToeIB83Edqsvps02rpOOg">GAM95</a>]. They have come to be known as the Gang of Four (GoF); therefore, their
- description is known as the <strong>GoF format</strong>. The GoF format uses the following keywords to describe
- object-oriented design patterns:
-</p>
-<ul>
- <li>
- <p>
- <strong>Pattern name and classification:</strong> Naming the pattern allows design to work at a higher level of
- abstraction, using a vocabulary of patterns. Gamma says that finding a good name is one of the hardest problems
- of developing a catalogue of patterns (see <strong>Pattern catalogues</strong> later in this section).
- </p>
- </li>
- <li>
- <p>
- <strong>Intent:</strong> An answer to questions such as: What does the pattern do? What problem does it
- address?
- </p>
- </li>
- <li>
- <p>
- <strong>Also known as:</strong> Other names for the pattern.
- </p>
- </li>
- <li>
- <p>
- <strong>Motivation:</strong> A concrete scenario that illustrates a design problem and how the pattern solves
- the problem.
- </p>
- </li>
- <li>
- <p>
- <strong>Applicability:</strong> Instructions for how you can recognize situations in which patterns are
- applicable.
- </p>
- </li>
- <li>
- <p>
- <strong>Structure:</strong> A graphical representation of the classes in the pattern.
- </p>
- </li>
- <li>
- <p>
- <strong>Participants:</strong> The responsibilities of the classes and objects that participate in the pattern.
- </p>
- </li>
- <li>
- <p>
- <strong>Collaborations:</strong> How participants collaborate to fulfill their responsibilities.
- </p>
- </li>
- <li>
- <p>
- <strong>Consequences:</strong> The results, side effects and trade offs caused by using the pattern.
- </p>
- </li>
- <li>
- <p>
- <strong>Implementation:</strong> Guidance on the implementation of the pattern.
- </p>
- </li>
- <li>
- <p>
- <strong>Sample code:</strong> Code fragments that illustrate the pattern's implementation.
- </p>
- </li>
- <li>
- <p>
- <strong>Known uses:</strong> Where to find real-world examples of the pattern.
- </p>
- </li>
- <li>
- <p>
- <strong>Related patterns:</strong> Synergies, differences, and other pattern relationships.
- </p>
- </li>
-</ul>
-<p>
- Although the GoF format is specifically intended for object-oriented development, you can use it, with slight
- modification, to address other software patterns. A more general keyword format for software patterns based on
- Alexander's principles uses keywords such as <em>problem</em>, <em>context</em>, <em>forces</em> and <em>solution</em>.
-</p>
-<h4>
- Pattern catalogs
-</h4>
-<p>
- To assist with the identification and selection of patterns, various classification schemes have been proposed. One of
- the early schemes, proposed by Buschmann and his associates, [<a class="elementLinkWithUserText"
- href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
- guid="_9ToeIB83Edqsvps02rpOOg">BUS96</a>] uses three classifiers: granularity, functionality, and structured
- principles. Of those three classifiers, it is their granularity classifier that has remained popular. Granularity
- classifies patterns into three levels of abstraction:
-</p>
-<ul>
- <li>
- <p>
- <strong>Architectural patterns:</strong> Architectural patterns express the fundamental structure of a software
- scheme. Examples of architectural pattern include: layers, pipes and filters, and the model view controller
- pattern.
- </p>
- </li>
- <li>
- <p>
- <strong>Design patterns:</strong> Software architecture usually consists of smaller architectural units that
- are described by design patterns. The GoF pattern is an example of a design pattern.
- </p>
- </li>
- <li>
- <p>
- <strong>Idioms.</strong> An idiom is the lowest-level pattern, and it is specific to a programming language.
- </p>
- </li>
-</ul>
-<p>
- Buschmann and his colleagues introduced four groups for categorizing architectural patterns:
-</p>
-<ul>
- <li>
- Structure
- </li>
- <li>
- Distributed systems
- </li>
- <li>
- Interactive systems
- </li>
- <li>
- Adaptable systems
- </li>
-</ul>
-<p>
- The following table shows the categorization of their architectural patterns.
-</p>
-<table cellspacing="0" cellpadding="2" width="85%" summary="Categories for Architectural Patterns [BUS96]" border="1"
-valign="top">
- <caption>
- <strong>Categories for Architectural Patterns<br />
- </strong>
- </caption>
- <tbody>
- <tr>
- <th scope="col">
- <div align="center">
- <strong>Category</strong>
- </div>
- </th>
- <th scope="col">
- <div align="center">
- <strong>Pattern</strong>
- </div>
- </th>
- </tr>
- <tr>
- <td>
- Structure
- </td>
- <td>
- <p>
- Layers<br />
- Pipes and filters<br />
- Blackboard
- </p>
- </td>
- </tr>
- <tr>
- <td>
- Distributed systems
- </td>
- <td>
- Broker
- </td>
- </tr>
- <tr>
- <td>
- Interactive systems
- </td>
- <td>
- Model view controller<br />
- Presentation abstraction control
- </td>
- </tr>
- <tr>
- <td>
- <p>
- Adaptable systems
- </p>
- </td>
- <td>
- <p>
- Reflection<br />
- Micro kernel
- </p>
- </td>
- </tr>
- </tbody>
-</table>
-<p>
- For design patterns, Gamma's group categorized their design patterns by purpose, using three categories:
-</p>
-<ul>
- <li>
- Creational
- </li>
- <li>
- Structural
- </li>
- <li>
- Behavioral
- </li>
-</ul>
-<h4>
- Pattern languages
-</h4>
-<p>
- In addition to the concept of patterns, Alexander also gave the software community the concept of a pattern language.
- The purpose of developing a pattern language was to provide a vocabulary of design principles (patterns) that would
- allow those who work, study, or live in buildings to communicate effectively with the planners and designers of those
- buildings. Alexander explains that when using a pattern language:
-</p>
-<blockquote>
- <p>
- We always use it as a sequence, going through the patterns, moving always from the larger patterns to the smaller,
- always from the ones that create structure to the ones which then embellish those structures, and then to those
- that embellish the embellishments.
- </p>
-</blockquote>
-<p>
- In applying patterns in this way, Alexander advocated the use of generative pattern languages, ones that, given an
- initial context, would always lead to good design.&nbsp; Alexander&nbsp;states:
-</p>
-<blockquote>
- <p>
- Thus, as in the case of natural languages, the pattern language is generative. It not only tells us the rules of
- arrangement, but shows us how to construct arrangements - as many as we want - which satisfies the rules.
- </p>
-</blockquote>
-<p>
- In the application of software patterns, pattern names provide a vocabulary for the communication of software ideas.
- The sequential application of patterns finds application in software design processes, both waterfall and iterative,
- that successively apply architectural patterns, and then design patterns, and, finally, idioms to design and implement
- a software system. Software processes, however, rely on the skills of the Architect and Developer roles to guide the
- application of patterns, rather than a generative pattern language.
+ <mainDescription><h4>
+ Origins
+</h4>
+<p>
+ The idea of patterns as it is now applied to software design comes from the work of Christopher Alexander. He has
+ written widely on the subject of applying patterns to the design and construction of towns and buildings. Two of his
+ books, <em>A Pattern Language</em> [<a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">ALE77</a>] and <em>The Timeless Way of Building</em> [<a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">ALE79</a>] have had the greatest impact on the software community and the adoption of
+ software patterns for the design of software. His concepts of patterns and pattern language provide a model for the
+ capture of software design expertise in a form that can then be reapplied in recurring situations.&nbsp;
+</p>
+<h4>
+ A definition of patterns
+</h4>
+<p>
+ Today, the most commonly used definition of software patterns is from [<a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">GAM95</a>]:
+</p>
+<blockquote>
+ <p>
+ "A design pattern describes the problem, a solution to the problem consisting of a general arrangement of objects
+ and classes, when to apply the solution, and the consequences of applying the solution."
+ </p>
+</blockquote>
+<p>
+ This definition often serves only as a starting point, however. A richer definition, based on Alexander's work, is
+ offered by Gabriel in his book, <em>A Timeless Way of Hacking</em> [<a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">ALU03</a>], in which each pattern is a three-part rule that expresses relationships
+ among a certain context, a certain system of forces that occur repeatedly in that context, and a certain software
+ configuration that allows these forces to resolve themselves.
+</p>
+<h4>
+ Describing patterns
+</h4>
+<p>
+ It is commonplace to describe patterns&nbsp;using the&nbsp;format made popular by Erich Gamma and his three colleagues
+ [<a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">GAM95</a>]. They have come to be known as the Gang of Four (GoF); therefore, their
+ description is known as the <strong>GoF format</strong>. The GoF format uses the following keywords to describe
+ object-oriented design patterns:
+</p>
+<ul>
+ <li>
+ <p>
+ <strong>Pattern name and classification:</strong> Naming the pattern allows design to work at a higher level of
+ abstraction, using a vocabulary of patterns. Gamma says that finding a good name is one of the hardest problems
+ of developing a catalogue of patterns (see <strong>Pattern catalogues</strong> later in this section).
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Intent:</strong> An answer to questions such as: What does the pattern do? What problem does it
+ address?
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Also known as:</strong> Other names for the pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Motivation:</strong> A concrete scenario that illustrates a design problem and how the pattern solves
+ the problem.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Applicability:</strong> Instructions for how you can recognize situations in which patterns are
+ applicable.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Structure:</strong> A graphical representation of the classes in the pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Participants:</strong> The responsibilities of the classes and objects that participate in the pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Collaborations:</strong> How participants collaborate to fulfill their responsibilities.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Consequences:</strong> The results, side effects and trade offs caused by using the pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Implementation:</strong> Guidance on the implementation of the pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Sample code:</strong> Code fragments that illustrate the pattern's implementation.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Known uses:</strong> Where to find real-world examples of the pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Related patterns:</strong> Synergies, differences, and other pattern relationships.
+ </p>
+ </li>
+</ul>
+<p>
+ Although the GoF format is specifically intended for object-oriented development, you can use it, with slight
+ modification, to address other software patterns. A more general keyword format for software patterns based on
+ Alexander's principles uses keywords such as <em>problem</em>, <em>context</em>, <em>forces</em> and <em>solution</em>.
+</p>
+<h4>
+ Pattern catalogs
+</h4>
+<p>
+ To assist with the identification and selection of patterns, various classification schemes have been proposed. One of
+ the early schemes, proposed by Buschmann and his associates, [<a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">BUS96</a>] uses three classifiers: granularity, functionality, and structured
+ principles. Of those three classifiers, it is their granularity classifier that has remained popular. Granularity
+ classifies patterns into three levels of abstraction:
+</p>
+<ul>
+ <li>
+ <p>
+ <strong>Architectural patterns:</strong> Architectural patterns express the fundamental structure of a software
+ scheme. Examples of architectural pattern include: layers, pipes and filters, and the model view controller
+ pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Design patterns:</strong> Software architecture usually consists of smaller architectural units that
+ are described by design patterns. The GoF pattern is an example of a design pattern.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Idioms.</strong> An idiom is the lowest-level pattern, and it is specific to a programming language.
+ </p>
+ </li>
+</ul>
+<p>
+ Buschmann and his colleagues introduced four groups for categorizing architectural patterns:
+</p>
+<ul>
+ <li>
+ Structure
+ </li>
+ <li>
+ Distributed systems
+ </li>
+ <li>
+ Interactive systems
+ </li>
+ <li>
+ Adaptable systems
+ </li>
+</ul>
+<p>
+ The following table shows the categorization of their architectural patterns.
+</p>
+<table cellspacing="0" cellpadding="2" width="85%" summary="Categories for Architectural Patterns [BUS96]" border="1"
+valign="top">
+ <caption>
+ <strong>Categories for Architectural Patterns<br />
+ </strong>
+ </caption>
+ <tbody>
+ <tr>
+ <th scope="col">
+ <div align="center">
+ <strong>Category</strong>
+ </div>
+ </th>
+ <th scope="col">
+ <div align="center">
+ <strong>Pattern</strong>
+ </div>
+ </th>
+ </tr>
+ <tr>
+ <td>
+ Structure
+ </td>
+ <td>
+ <p>
+ Layers<br />
+ Pipes and filters<br />
+ Blackboard
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Distributed systems
+ </td>
+ <td>
+ Broker
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Interactive systems
+ </td>
+ <td>
+ Model view controller<br />
+ Presentation abstraction control
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <p>
+ Adaptable systems
+ </p>
+ </td>
+ <td>
+ <p>
+ Reflection<br />
+ Micro kernel
+ </p>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>
+ For design patterns, Gamma's group categorized their design patterns by purpose, using three categories:
+</p>
+<ul>
+ <li>
+ Creational
+ </li>
+ <li>
+ Structural
+ </li>
+ <li>
+ Behavioral
+ </li>
+</ul>
+<h4>
+ Pattern languages
+</h4>
+<p>
+ In addition to the concept of patterns, Alexander also gave the software community the concept of a pattern language.
+ The purpose of developing a pattern language was to provide a vocabulary of design principles (patterns) that would
+ allow those who work, study, or live in buildings to communicate effectively with the planners and designers of those
+ buildings. Alexander explains that when using a pattern language:
+</p>
+<blockquote>
+ <p>
+ We always use it as a sequence, going through the patterns, moving always from the larger patterns to the smaller,
+ always from the ones that create structure to the ones which then embellish those structures, and then to those
+ that embellish the embellishments.
+ </p>
+</blockquote>
+<p>
+ In applying patterns in this way, Alexander advocated the use of generative pattern languages, ones that, given an
+ initial context, would always lead to good design.&nbsp; Alexander&nbsp;states:
+</p>
+<blockquote>
+ <p>
+ Thus, as in the case of natural languages, the pattern language is generative. It not only tells us the rules of
+ arrangement, but shows us how to construct arrangements - as many as we want - which satisfies the rules.
+ </p>
+</blockquote>
+<p>
+ In the application of software patterns, pattern names provide a vocabulary for the communication of software ideas.
+ The sequential application of patterns finds application in software design processes, both waterfall and iterative,
+ that successively apply architectural patterns, and then design patterns, and, finally, idioms to design and implement
+ a software system. Software processes, however, rely on the skills of the Architect and Developer roles to guide the
+ application of patterns, rather than a generative pattern language.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/refactoring.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/refactoring.xmi
index db8e3a3..d3d2328 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/refactoring.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/refactoring.xmi
@@ -1,76 +1,80 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-fj_9xjbrpaYNSETyCz5yJg" name="refactoring,_Poc7IPDzEdqYgerqi84oCA" guid="-fj_9xjbrpaYNSETyCz5yJg" changeDate="2008-01-16T05:54:37.000-0800" version="1.0.0">
- <mainDescription><p>
- Refactoring is a disciplined way to restructure code when small changes are made to the code to improve its design. An
- important aspect of a refactoring is that it improves the design while not changing the behavior of the design; a
- refactoring neither adds nor removes functionality.
-</p>
-<p>
- Refactoring enables you to evolve the code slowly over time, to take an iterative and incremental approach to
- implementation.
-</p>
-<p>
- These are the types of refactoring:
-</p>
-<ol>
- <li>
- Code refactoring. Often referred to simply as refactoring, this is the refactoring of programming source code.
- Examples of code refactorings include Rename Method, Encapsulate Field, Extract Class, Introduce Assertion, and
- Pushdown Method.
- </li>
- <li>
- Database refactoring. A database refactoring is a simple change to a database schema that improves its design while
- retaining both its behavioral and informational semantics. Examples of database refactorings include Rename Column,
- Split Table, Move Method to Database, Replace LOB with Table, Introduce Column Constraint, and Use Official Data
- Source.
- </li>
- <li>
- User interface (UI) refactoring. A UI refactoring is a simple change to the UI which retains its semantics.
- Examples of UI refactorings include Align Entry Fields, Apply Common Button Size, Apply Common Font, Indicate
- Format, Reword in Active Voice, and Increase Color Contrast.
- </li>
-</ol>
-<p>
- Martin Fowler [<a class="elementLinkWithUserText" href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#FOW99" guid="_9ToeIB83Edqsvps02rpOOg">FOW99</a>] identifies four key reasons to refactor:
-</p>
-<ul>
- <li>
- Refactoring improves the design of software
- </li>
- <li>
- Refactoring makes software easier to understand
- </li>
- <li>
- Refactoring helps you find bugs
- </li>
- <li>
- Refactoring helps you program faster
- </li>
-</ul>
-<p>
- Refactoring can improve the design of existing code, but it does not take the place of considering the design before
- writing code. Refactoring instead changes the role of up-front design, allowing the strictly design work to be more
- abstract. Small-scale, very tactical decisions can be made during the implementation of the solution with confidence
- that refactoring will ensure a quality implementation at that level. The designing of the solution before
- implementation will be more lightweight and focused on broad factors that will drive the implementation.
-</p>
-<p>
- There is an additional benefit of refactoring: it changes the way a developer thinks about the implementation when not
- refactoring. The basic task of implementing a solution becomes solely about getting the solution to pass its developer
- tests in the simplest way possible. Then the design of that solution can be examined and refactored separately. Even if
- these two things -- implementation of the solution and then improvement -- are just a minute apart, it can be freeing
- for a developer to single-mindedly create code that causes a test to pass, and then separately single-mindedly improve
- that code.
-</p>
-<p>
- These are some additional resources:
-</p>
-<ul>
- <li>
- <a href="http://www.refactoring.com/" target="_blank"><u><font color="#0000ff">http://www.refactoring.com/</font></u></a>
- </li>
- <li>
- <a href="http://www.agiledata.org/essays/databaseRefactoring.html"><u><font color="#0000ff">http://www.agiledata.org/essays/databaseRefactoring.html</font></u></a>
- </li>
+ <mainDescription><p>
+ Refactoring is a disciplined way to restructure code when small changes are made to the code to improve its design. An
+ important aspect of a refactoring is that it improves the design while not changing the behavior of the design; a
+ refactoring neither adds nor removes functionality.
+</p>
+<p>
+ Refactoring enables you to evolve the code slowly over time, to take an iterative and incremental approach to
+ implementation.
+</p>
+<p>
+ These are the types of refactoring:
+</p>
+<ol>
+ <li>
+ Code refactoring. Often referred to simply as refactoring, this is the refactoring of programming source code.
+ Examples of code refactorings include Rename Method, Encapsulate Field, Extract Class, Introduce Assertion, and
+ Pushdown Method.
+ </li>
+ <li>
+ Database refactoring. A database refactoring is a simple change to a database schema that improves its design while
+ retaining both its behavioral and informational semantics. Examples of database refactorings include Rename Column,
+ Split Table, Move Method to Database, Replace LOB with Table, Introduce Column Constraint, and Use Official Data
+ Source.
+ </li>
+ <li>
+ User interface (UI) refactoring. A UI refactoring is a simple change to the UI which retains its semantics.
+ Examples of UI refactorings include Align Entry Fields, Apply Common Button Size, Apply Common Font, Indicate
+ Format, Reword in Active Voice, and Increase Color Contrast.
+ </li>
+</ol>
+<p>
+ Martin Fowler [<a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#FOW99"
+ guid="_9ToeIB83Edqsvps02rpOOg">FOW99</a>] identifies four key reasons to refactor:
+</p>
+<ul>
+ <li>
+ Refactoring improves the design of software.
+ </li>
+ <li>
+ Refactoring makes software easier to understand.
+ </li>
+ <li>
+ Refactoring helps you find bugs.
+ </li>
+ <li>
+ Refactoring helps you program faster.
+ </li>
+</ul>
+<p>
+ Refactoring can improve the design of existing code, but it does not take the place of considering the design before
+ writing code. Refactoring instead changes the role of up-front design, allowing the strictly design work to be more
+ abstract. Small-scale, very tactical decisions can be made during the implementation of the solution with confidence
+ that refactoring will ensure a quality implementation at that level. The designing of the solution before
+ implementation will be more lightweight and focused on broad factors that will drive the implementation.
+</p>
+<p>
+ There is an additional benefit of refactoring: it changes the way a developer thinks about the implementation when not
+ refactoring. The basic task of implementing a solution becomes solely about getting the solution to pass its developer
+ tests in the simplest way possible. Then the design of that solution can be examined and refactored separately. Even if
+ these two things -- implementation of the solution and then improvement -- are just a minute apart, it can be freeing
+ for a developer to single-mindedly create code that causes a test to pass, and then separately single-mindedly improve
+ that code.
+</p>
+<p>
+ These are some additional resources:
+</p>
+<ul>
+ <li>
+ <a href="http://www.refactoring.com/" target="_blank"><u><font
+ color="#0000ff">http://www.refactoring.com/</font></u></a>
+ </li>
+ <li>
+ <a href="http://www.agiledata.org/essays/databaseRefactoring.html"><u><font
+ color="#0000ff">http://www.agiledata.org/essays/databaseRefactoring.html</font></u></a>
+ </li>
</ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/requirement_attributes.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/requirement_attributes.xmi
index 3febc5f..be796e2 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/requirement_attributes.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/requirement_attributes.xmi
@@ -1,66 +1,67 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-fCBrf_5JlrmuKgyrCaKGOA" name="requirement_attributes_1,_VQ268O0KEdqHTdbLTmC5IQ" guid="-fCBrf_5JlrmuKgyrCaKGOA" authors="Chris Sibbald" changeDate="2006-09-20T11:41:34.000-0700" version="0.2">
- <mainDescription><p>
- Attributes are a very important source of requirements information. Just as every person has attributes (age, hair
- color, gender), each requirement has a source, a relative importance, and time it was created. Attributes do more than
- simply clarify a&nbsp;requirement.&nbsp; If created properly, they can yield significant information about the state of
- the system. Just as you can run a database query to find all men with brown hair over age 30, given our human example,
- you can run queries on the status of requirements to find&nbsp;all high-priority requirements from the customer in the
- last 30 days. <a href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html" guid="_9ToeIB83Edqsvps02rpOOg">[TEL06]</a>
-</p>
-<h4>
- Examples of attributes
-</h4>
-<p>
- Listed below is a partial list of some common attributes and a brief description of their meaning. Some attributes are
- best described as a number, date, Boolean (true or false) or a text field for entering free format comments. Other
- attributes can be expressed as lists. For instance, priority type is a list of high, medium, and low; Weekday is a list
- which includes Monday, Tuesday, and so on.
-</p>
-<p>
- <em>Source</em> - Person, document or other origin of a given requirement.&nbsp; This is&nbsp;useful&nbsp;for
- determining whom to call for questions or for grouping&nbsp;requirements according to the person making the demands.
-</p>
-<p>
- <em>Priority</em> - Statement of relative importance of the requirement, either to the system (mandatory, critical,
- optional) or to other requirements (high, medium, low). It is good to track the mandatory or high-priority
- items&nbsp;as an indication of how well the system will meet the greatest needs or for compliance-related metrics.
-</p>
-<p>
- <em>Assigned to</em> - Who in the organization is responsible for making sure the requirement is met (person's name or
- organizational name).
-</p>
-<p>
- <em>Comments</em> - Reviewer's or writer's comments on a requirement.
-</p>
-<p>
- <em>Difficulty</em> - An indication of the level of effort needed or how hard it will be to implement the requirement
- (high, medium, low).
-</p>
-<p>
- <em>Status</em> - Degree of completeness (completed, partial, not started).
-</p>
-<p>
- <em>Risk</em> - Confidence measure on the likelihood of meeting (or not meeting) a requirement. Could be high, medium,
- low or the integers one through ten.
-</p>
-<p>
- <em>Due By</em> - Date the requirement must be provided.
-</p>
-<p>
- <em>Method of verification</em> - Qualification type to be used to verify that a requirement has been met: analysis,
- demonstration, inspection, test, and walkthrough.
-</p>
-<p>
- <em>Level of Test</em> - Describes the verification lifecycle stage at which the requirement is determined to be met:
- unit test, component, system or product.
-</p>
-<p>
- <em>Subsystem Allocation</em> - Name of system or subsystem a requirement is to be assigned to (for instance, flight
- control module, wing assembly, passenger cabin).
-</p>
-<p>
- <em>Test Number</em> - Identification of a specific test or other method of verification.
-</p><br />
+ <mainDescription><p>
+ Attributes are a very important source of requirements information. Just as every person has attributes (age, hair
+ color, gender), each requirement has a source, a relative importance, and time it was created. Attributes do more than
+ simply clarify a&nbsp;requirement.&nbsp; If created properly, they can yield significant information about the state of
+ the system. Just as you can run a database query to find all men with brown hair over age 30, given our human example,
+ you can run queries on the status of requirements to find&nbsp;all high-priority requirements from the customer in the
+ last 30 days. <a href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[TEL06]</a>
+</p>
+<h4>
+ Examples of attributes
+</h4>
+<p>
+ Listed below is a partial list of some common attributes and a brief description of their meaning. Some attributes are
+ best described as a number, date, Boolean (true or false) or a text field for entering free format comments. Other
+ attributes can be expressed as lists. For instance, priority type is a list of high, medium, and low; Weekday is a list
+ which includes Monday, Tuesday, and so on.
+</p>
+<p>
+ <em>Source</em> - Person, document or other origin of a given requirement.&nbsp; This is&nbsp;useful&nbsp;for
+ determining whom to call for questions or for grouping&nbsp;requirements according to the person making the demands.
+</p>
+<p>
+ <em>Priority</em> - Statement of relative importance of the requirement, either to the system (mandatory, critical,
+ optional) or to other requirements (high, medium, low). It is good to track the mandatory or high-priority
+ items&nbsp;as an indication of how well the system will meet the greatest needs or for compliance-related metrics.
+</p>
+<p>
+ <em>Assigned to</em> - Who in the organization is responsible for making sure the requirement is met (person's name or
+ organizational name).
+</p>
+<p>
+ <em>Comments</em> - Reviewer's or writer's comments on a requirement.
+</p>
+<p>
+ <em>Difficulty</em> - An indication of the level of effort needed or how hard it will be to implement the requirement
+ (high, medium, low).
+</p>
+<p>
+ <em>Status</em> - Degree of completeness (completed, partial, not started).
+</p>
+<p>
+ <em>Risk</em> - Confidence measure on the likelihood of meeting (or not meeting) a requirement. Could be high, medium,
+ low or the integers one through ten.
+</p>
+<p>
+ <em>Due By</em> - Date the requirement must be provided.
+</p>
+<p>
+ <em>Method of verification</em> - Qualification type to be used to verify that a requirement has been met: analysis,
+ demonstration, inspection, test, and walkthrough.
+</p>
+<p>
+ <em>Level of Test</em> - Describes the verification lifecycle stage at which the requirement is determined to be met:
+ unit test, component, system or product.
+</p>
+<p>
+ <em>Subsystem Allocation</em> - Name of system or subsystem a requirement is to be assigned to (for instance, flight
+ control module, wing assembly, passenger cabin).
+</p>
+<p>
+ <em>Test Number</em> - Identification of a specific test or other method of verification.
+</p><br />
<br /></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/requirements.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/requirements.xmi
index 585b95d..0a11db4 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/requirements.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/requirements.xmi
@@ -1,53 +1,53 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_eUfzwMMyEdmdo9HxCRR_Gw" name="requirements,_0Wh-sMlgEdmt3adZL5Dmdw" guid="_eUfzwMMyEdmdo9HxCRR_Gw" changeDate="2008-03-18T00:14:57.000-0700" version="1.0.0">
- <mainDescription><p>
- Requirements are the project team's to-do list.
-</p>
-<p>
- Requirements define what is needed and focus the project team. They are the primary method used to communicate the
- goals of the project to everyone on the team.
-</p>
-<p>
- Requirements define:
-</p>
-<ul>
- <li>
- What the stakeholders need; and
- </li>
- <li>
- What the system must include to satisfy the stakeholders' needs.
- </li>
-</ul>
-<p>
- Requirements are the basis for capturing and communicating needs, managing expectations, prioritizing and assigning
- work, verifying and validating the system (acceptance), and managing the scope of the project.
-</p>
-<p>
- Requirements may take different forms, including scenarios, unstructured text, structured text, or a
- combination, and they may be stated at different levels of granularity. At the highest level of granularity,
- features&nbsp;define the services that the system must provide to solve the customer's problem. These are captured as
- structured or unstructured text in the project vision. At the next level of granularity, use cases can be used to
- define the functionality that the system must provide to deliver the required features.&nbsp;Use cases&nbsp;describe
- the sequence of actions performed by the system to yield an observable result of value.
-</p>
-<p>
- As mentioned, a&nbsp;system must perform according to the behavior that can be specified as use cases. However, there
- are system requirements that do not represent a specific behavior, also&nbsp;known as system-wide requirements,
- including:
-</p>
-<ul>
- <li>
- Legal and regulatory requirements, as well as application standards
- </li>
- <li>
- Quality attributes of the system to be built, including usability, reliability, performance, and supportability
- requirements
- </li>
- <li>
- Interface requirements to be able to communicate with external systems
- </li>
- <li>
- Design constraints, such as those for operating systems and environments and for compatibility with other software
- </li>
+ <mainDescription><p>
+ Requirements are the project team's to-do list.
+</p>
+<p>
+ Requirements define what is needed and focus the project team. They are the primary method used to communicate the
+ goals of the project to everyone on the team.
+</p>
+<p>
+ Requirements define:
+</p>
+<ul>
+ <li>
+ What the stakeholders need; and
+ </li>
+ <li>
+ What the system must include to satisfy the stakeholders' needs.
+ </li>
+</ul>
+<p>
+ Requirements are the basis for capturing and communicating needs, managing expectations, prioritizing and assigning
+ work, verifying and validating the system (acceptance), and managing the scope of the project.
+</p>
+<p>
+ Requirements may take different forms, including scenarios, unstructured text, structured text, or a combination, and
+ they may be stated at different levels of granularity. At the highest level of granularity, features&nbsp;define the
+ services that the system must provide to solve the customer's problem. These are captured as structured or unstructured
+ text in the project vision. At the next level of granularity, use cases can be used to define the functionality that
+ the system must provide to deliver the required features.&nbsp;Use cases&nbsp;describe the sequence of actions
+ performed by the system to yield an observable result of value.
+</p>
+<p>
+ As mentioned, a&nbsp;system must perform according to the behavior that can be specified as use cases. However, there
+ are system requirements that do not represent a specific behavior, also&nbsp;known as system-wide requirements,
+ including:
+</p>
+<ul>
+ <li>
+ Legal and regulatory requirements, as well as application standards
+ </li>
+ <li>
+ Quality attributes of the system to be built, including usability, reliability, performance, and supportability
+ requirements
+ </li>
+ <li>
+ Interface requirements to be able to communicate with external systems
+ </li>
+ <li>
+ Design constraints, such as those for operating systems and environments and for compatibility with other software
+ </li>
</ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/software_architecture.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/software_architecture.xmi
index 20d257c..42e590a 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/software_architecture.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/software_architecture.xmi
@@ -1,309 +1,309 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-UQ_e8kozIP11Xu008RJd-A" name="new_concept,__O7tAMVvEduLYZUGfgZrkQ" guid="-UQ_e8kozIP11Xu008RJd-A" changeDate="2008-10-15T06:28:05.000-0700" version="7.2.0">
- <mainDescription><h3>
- Introduction
-</h3>
-<p>
- Software architecture is a concept that is easy to understand, and that most engineers intuitively feel, especially
- with a little experience, but it is hard to define precisely. In particular, it is difficult to draw a sharp line
- between design and architecture-architecture is one aspect of design that concentrates on some specific features.
-</p>
-<p>
- In An Introduction to Software Architecture, David Garlan and Mary Shaw suggest that software architecture is a level
- of design concerned with issues: "Beyond the algorithms and data structures of the computation; designing and
- specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization
- and global control structure; protocols for communication, synchronization, and data access; assignment of
- functionality to design elements; physical distribution; composition of design elements; scaling and performance; and
- selection among design alternatives." <a class="elementlinkwithusertext"
- href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
- guid="_9ToeIB83Edqsvps02rpOOg">[GAR93]</a>
-</p>
-<p>
- But there is more to architecture than just structure; the IEEE Working Group on Architecture defines it as "the
- highest-level concept of a system in its environment" <a class="elementlinkwithusertext"
- href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
- guid="_9ToeIB83Edqsvps02rpOOg">[IEP1471]</a>. It also encompasses the "fit" with system integrity, with economical
- constraints, with aesthetic concerns, and with style. It is not limited to an inward focus, but takes into
- consideration the system as a whole in its user environment and its development environment - an outward focus.
-</p>
-<p>
- The architecture focuses on specific aspects of the overall system design, concentrating on structure, essential
- elements, key scenarios and those aspects that have a lasting impact on system qualities such as performance,
- reliability, adaptability and cost. It also defines the set of <a class="elementLink"
- href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_mechanism_2932DFB6.html"
- guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a>s, <a class="elementLink"
- href="./../../../core.tech.common.extend_supp/guidances/concepts/pattern_10BE6D96.html"
- guid="_0YJvUMlgEdmt3adZL5Dmdw">Pattern</a>s and styles that will guide the rest of the design, assuring its integrity.
-</p>
-<h3>
- Purpose of Architecture
-</h3>
-<p>
- The architecture can be used for many things:
-</p>
-<ul>
- <li>
- <strong>To describe the essential structure of the system and the decisions guiding the structure of the
- system</strong> so the integrity and understandability of the system is assured.
- </li>
- <li>
- <a id="Comment71_" name="Comment71_"><strong>To identify and attack risks to the system</strong> (using the
- architecture as an artifact of governance)</a>
- </li>
- <li>
- <strong>To provide context and guidance for developers</strong> to construct the system by describing the
- motivations behind the architectural decisions so those decisions can be robustly implemented. The architecture
- services as the blueprint for development.&nbsp;For example, the architect may place constraints on how data is
- packaged and communicated between different parts of the system. This may appear to be a burden, but the
- justification in the Architecture Notebook can explain that there is a significant performance bottleneck when
- communicating with a legacy system. The rest of the system must adapt to this bottleneck by following a specific
- data packaging scheme.
- </li>
- <li>
- <strong>To provide an overview of the system to whoever must maintain the architecture</strong>, as well as an
- understanding of the motivation behind the important technical decisions.&nbsp; Team members who were not involved
- in those architectural decisions need to understand the reasoning behind the&nbsp;context of the architecture so
- they can best address the needs of the system.
- </li>
- <li>
- <strong>To define the project structure and team organization.</strong> Architectural elements make excellent units
- of implementation, unit testing, integration, configuration management and&nbsp;documentation.&nbsp;&nbsp; They can
- also be used to define&nbsp; so that managers can plan the project.
- </li>
-</ul>
-<h3>
- Architecture Description
-</h3>
-<p>
- To speak and reason about software architecture, you must first define an architectural representation, a way of
- describing important aspects of an architecture.
-</p>
-<p>
- The following is some information that is worth capturing as part of the software architecture:
-</p>
-<ul>
- <li>
- Architectural goals (see <a class="elementLinkWithType"
- href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_goals_CB41D8AE.html"
- guid="_HlRqANpbEdyP58ppo1Ieaw">Concept: Architectural Goals</a>)
- </li>
- <li>
- References to architecturally significant requirements and how the architecture addresses those requirements,
- including&nbsp;key scenarios that describe critical behavior of the system (see <a class="elementLinkWithType"
- href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_significant_requirements_1EE5D757.html"
- guid="_HrZGIA4MEduibvKwrGxWxA">Concept: Architecturally Significant Requirements</a>)
- </li>
- <li>
- Constraints on the architecture and how the architecture addresses those constraints (see <a
- class="elementLinkWithType"
- href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_constraints_AE56B662.html"
- guid="_jdKSsNpiEdyP58ppo1Ieaw">Concept: Architectural Constraints</a>)
- </li>
- <li>
- Key abstractions (see <a class="elementLinkWithType"
- href="./../../../core.tech.common.extend_supp/guidances/concepts/key_abstractions_1474DBF2.html"
- guid="_pLEGUNqGEdy88NBoQgfGyg">Concept: Key Abstractions</a>)
- </li>
- <li>
- <a class="elementLink"
- href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_mechanism_2932DFB6.html"
- guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a> and where they should be applied (see <a
- class="elementLinkWithType"
- href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_mechanism_2932DFB6.html"
- guid="_mzxI0A4LEduibvKwrGxWxA">Concept: Architectural Mechanism</a>).
- </li>
- <li>
- Description of the partitioning approach, as well as a description of the key partitions.&nbsp; For example,
- Layering&nbsp;(see <a class="elementLinkWithType"
- href="./../../../core.tech.common.extend_supp/guidances/guidelines/layering_F169CF07.html"
- guid="_0gpkAMlgEdmt3adZL5Dmdw">Guideline: Layering</a>)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
- </li>
- <li>
- Description of the deployment approach, as well as how key components are allocated to deployment
- nodes.&nbsp;&nbsp;&nbsp;&nbsp;
- </li>
- <li>
- References to architecturally significant design elements (see <a class="elementLinkWithType"
- href="./../../../core.tech.common.extend_supp/guidances/concepts/component_CB167D48.html"
- guid="_0YP18MlgEdmt3adZL5Dmdw">Concept: Component</a>)&nbsp;
- </li>
- <li>
- Critical system interfaces (see <a class="elementLinkWithType"
- href="./../../../core.tech.common.extend_supp/guidances/guidelines/repres_interfaces_to_ext_systems_51A34F6E.html"
- guid="_0gjdYMlgEdmt3adZL5Dmdw">Guideline: Representing Interfaces to External Systems</a>)
- </li>
- <li>
- Assets that have been reused and/or assets that have been developed to be reused (for more information, see <a
- class="elementLinkWithType"
- href="./../../../core.tech.common.extend_supp/guidances/guidelines/software_reuse_B6B04C26.html"
- guid="_vO2uoO0OEduUpsu85bVhiQ">Guideline: Software Reuse</a>)
- </li>
- <li>
- Guidance, decisions, and constraints the developers must follow in building the system, along with justification
- </li>
-</ul>
-<p>
- The architecture can contain any information and references that are appropriate in communicating how developers should
- build the system.
-</p>
-<h4>
- Architectural Representation
-</h4>
-<p>
- The architecture can be represented in many forms and from many viewpoints, depending on the needs of the project and
- the preferences of the project team. It need not be a formal document. The essence of the architecture can often be
- communicated through a series of simple diagrams on a whiteboard; or as a list of decisions. The illustration just
- needs to show the nature of the proposed solution, convey the governing ideas, and represent the major building blocks
- to make it easier to communicate the architecture to the project team and stakeholders.
-</p>
-<p>
- If a more complex system is required, then the architecture can be represented as a more comprehensive set
- of&nbsp;views that describe the architecture from a number of viewpoints. For more information, see <a
- class="elementLinkWithType"
- href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_views_viewpoints_7A6CD31.html"
- guid="_kgtcoNc8Edyd7OybSySFxg">Concept: Architectural Views and Viewpoints</a>.
-</p>
-<p>
- The architecture can be expressed as a simple metaphor or as a comparison to a predefined architectural style or set of
- styles. It may be a precise set of models or documents that describe the various aspects of the system's key elements.
- Expressing it as skeletal implementation is another option - although this may need to be baselined and preserved to
- ensure that the essence of the system can be understood as the system grows. Choose the medium that best meets the
- needs of the project.
-</p>
-<h3>
- Architectural Patterns
-</h3>
-<p>
- Architectural <a class="elementLink"
- href="./../../../core.tech.common.extend_supp/guidances/concepts/pattern_10BE6D96.html"
- guid="_0YJvUMlgEdmt3adZL5Dmdw">Pattern</a>s are ready-made forms that solve recurring architectural problems. An
- architectural framework or an architectural infrastructure (middleware) is a set of components on which you can build a
- certain kind of architecture. Many of the major architectural difficulties should be resolved in the framework or in
- the infrastructure, usually targeted to a specific domain: command and control, MIS, control system, and so on.
-</p>
-<p>
- <a class="elementlinkwithusertext"
- href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
- guid="_9ToeIB83Edqsvps02rpOOg">[BUS96]</a> groups architectural patterns according to the characteristics of the
- systems in which they are most applicable, with one category dealing with more general structuring issues. The table
- shows the categories presented in <a class="elementlinkwithusertext"
- href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
- guid="_9ToeIB83Edqsvps02rpOOg">[BUS96]</a> and the patterns they contain.
-</p>
-<div align="center">
- <table
- style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
- cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
- <tbody>
- <tr>
- <th id="col1" width="50%">
- Category
- </th>
- <th id="col2" width="50%">
- Pattern
- </th>
- </tr>
- <tr>
- <th id="row2" align="left" headers="col1" width="50%" rowspan="3">
- Structure
- </th>
- <td headers="row2 col2" width="50%">
- Layers
- </td>
- </tr>
- <tr>
- <td headers="row2 col2" width="50%">
- Pipes and Filters
- </td>
- </tr>
- <tr>
- <td headers="row2 col2" width="50%">
- Blackboard
- </td>
- </tr>
- <tr>
- <th id="row3" align="left" headers="col1" width="50%">
- Distributed Systems
- </th>
- <td headers="row3 col2" width="50%">
- Broker
- </td>
- </tr>
- <tr>
- <th id="row4" align="left" headers="col1" width="50%" rowspan="2">
- Interactive Systems
- </th>
- <td headers="row4 col2" width="50%">
- Model-View-Controller
- </td>
- </tr>
- <tr>
- <td headers="row4 col2" width="50%">
- Presentation-Abstraction-Control
- </td>
- </tr>
- <tr>
- <th id="row5" align="left" headers="col1" width="50%" rowspan="2">
- Adaptable Systems
- </th>
- <td headers="row5 col2" width="50%">
- Reflection
- </td>
- </tr>
- <tr>
- <td headers="row5 col2" width="50%">
- Microkernel
- </td>
- </tr>
- </tbody>
- </table><br />
-</div>
-<p>
- Refer to <a class="elementlinkwithusertext"
- href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
- guid="_9ToeIB83Edqsvps02rpOOg">[BUS96]</a> for a complete description of these patterns.
-</p>
-<h3>
- <a id="Architectural Style" name="Architectural Style">Architectural Style</a>
-</h3>
-<p>
- A software architecture (or an architectural view) may have an attribute called <b>architectural style</b>, which
- reduces the set of possible forms to choose from, and imposes a certain degree of uniformity to the architecture. The
- style may be defined by a set of patterns, or by the choice of specific components or connectors as the basic building
- blocks.
-</p>
-<h3>
- Architectural Timing
-</h3>
-<p>
- Teams should expect to spend more time on architectural issues early in the project.&nbsp; This allows the team to
- reduce risk associated to technology early in the project, hence allowing the team to more rapidly reduce the variance
- in their estimate on what they can deliver at what time. Examples of architectural issues that needs to be resolved
- early on include
-</p>
-<ul>
- <li>
- Component and their major interfaces
- </li>
- <li>
- Major technology choices (platform, languages, architecture frameworks / reference architectures, etc.)
- </li>
- <li>
- Interfaces to external systems
- </li>
- <li>
- Common services (persistence mechanisms, logging mechanisms, garbage collection, etc.)
- </li>
- <li>
- Key patterns
- </li>
-</ul>
-<h3>
- Validating the Architecture
-</h3>
-<p>
- The best way to validate the architecture is to actually implement it.&nbsp; For more information, see <a
- class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/concepts/executable_arch_D4E68CBD.html"
- guid="_O1kAANvfEduv2KOT-Teh6w">Executable Architecture</a>.
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ Software architecture is a concept that is easy to understand, and that most engineers intuitively feel, especially
+ with a little experience, but it is hard to define precisely. In particular, it is difficult to draw a sharp line
+ between design and architecture-architecture is one aspect of design that concentrates on some specific features.
+</p>
+<p>
+ In An Introduction to Software Architecture, David Garlan and Mary Shaw suggest that software architecture is a level
+ of design concerned with issues: "Beyond the algorithms and data structures of the computation; designing and
+ specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization
+ and global control structure; protocols for communication, synchronization, and data access; assignment of
+ functionality to design elements; physical distribution; composition of design elements; scaling and performance; and
+ selection among design alternatives." <a class="elementlinkwithusertext"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[GAR93]</a>
+</p>
+<p>
+ But there is more to architecture than just structure; the IEEE Working Group on Architecture defines it as "the
+ highest-level concept of a system in its environment" <a class="elementlinkwithusertext"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[IEP1471]</a>. It also encompasses the "fit" with system integrity, with economical
+ constraints, with aesthetic concerns, and with style. It is not limited to an inward focus, but takes into
+ consideration the system as a whole in its user environment and its development environment - an outward focus.
+</p>
+<p>
+ The architecture focuses on specific aspects of the overall system design, concentrating on structure, essential
+ elements, key scenarios and those aspects that have a lasting impact on system qualities such as performance,
+ reliability, adaptability and cost. It also defines the set of <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_mechanism_2932DFB6.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a>s, <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/pattern_10BE6D96.html"
+ guid="_0YJvUMlgEdmt3adZL5Dmdw">Pattern</a>s and styles that will guide the rest of the design, assuring its integrity.
+</p>
+<h3>
+ Purpose of Architecture
+</h3>
+<p>
+ The architecture can be used for many things:
+</p>
+<ul>
+ <li>
+ <strong>To describe the essential structure of the system and the decisions guiding the structure of the
+ system</strong> so the integrity and understandability of the system is assured.
+ </li>
+ <li>
+ <a id="Comment71_" name="Comment71_"><strong>To identify and attack risks to the system</strong> (using the
+ architecture as an artifact of governance)</a>
+ </li>
+ <li>
+ <strong>To provide context and guidance for developers</strong> to construct the system by describing the
+ motivations behind the architectural decisions so those decisions can be robustly implemented. The architecture
+ services as the blueprint for development.&nbsp;For example, the architect may place constraints on how data is
+ packaged and communicated between different parts of the system. This may appear to be a burden, but the
+ justification in the Architecture Notebook can explain that there is a significant performance bottleneck when
+ communicating with a legacy system. The rest of the system must adapt to this bottleneck by following a specific
+ data packaging scheme.
+ </li>
+ <li>
+ <strong>To provide an overview of the system to whoever must maintain the architecture</strong>, as well as an
+ understanding of the motivation behind the important technical decisions.&nbsp; Team members who were not involved
+ in those architectural decisions need to understand the reasoning behind the&nbsp;context of the architecture so
+ they can best address the needs of the system.
+ </li>
+ <li>
+ <strong>To define the project structure and team organization.</strong> Architectural elements make excellent units
+ of implementation, unit testing, integration, configuration management and&nbsp;documentation.&nbsp;&nbsp; They can
+ also be used to define&nbsp; so that managers can plan the project.
+ </li>
+</ul>
+<h3>
+ Architecture Description
+</h3>
+<p>
+ To speak and reason about software architecture, you must first define an architectural representation, a way of
+ describing important aspects of an architecture.
+</p>
+<p>
+ The following is some information that is worth capturing as part of the software architecture:
+</p>
+<ul>
+ <li>
+ Architectural goals (see <a class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_goals_CB41D8AE.html"
+ guid="_HlRqANpbEdyP58ppo1Ieaw">Concept: Architectural Goals</a>)
+ </li>
+ <li>
+ References to architecturally significant requirements and how the architecture addresses those requirements,
+ including&nbsp;key scenarios that describe critical behavior of the system (see <a class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_significant_requirements_1EE5D757.html"
+ guid="_HrZGIA4MEduibvKwrGxWxA">Concept: Architecturally Significant Requirements</a>)
+ </li>
+ <li>
+ Constraints on the architecture and how the architecture addresses those constraints (see <a
+ class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_constraints_AE56B662.html"
+ guid="_jdKSsNpiEdyP58ppo1Ieaw">Concept: Architectural Constraints</a>)
+ </li>
+ <li>
+ Key abstractions (see <a class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/key_abstractions_1474DBF2.html"
+ guid="_pLEGUNqGEdy88NBoQgfGyg">Concept: Key Abstractions</a>)
+ </li>
+ <li>
+ <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_mechanism_2932DFB6.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a> and where they should be applied (see <a
+ class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_mechanism_2932DFB6.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Concept: Architectural Mechanism</a>).
+ </li>
+ <li>
+ Description of the partitioning approach, as well as a description of the key partitions.&nbsp; For example,
+ Layering&nbsp;(see <a class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/guidelines/layering_F169CF07.html"
+ guid="_0gpkAMlgEdmt3adZL5Dmdw">Guideline: Layering</a>)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+ </li>
+ <li>
+ Description of the deployment approach, as well as how key components are allocated to deployment
+ nodes.&nbsp;&nbsp;&nbsp;&nbsp;
+ </li>
+ <li>
+ References to architecturally significant design elements (see <a class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/component_CB167D48.html"
+ guid="_0YP18MlgEdmt3adZL5Dmdw">Concept: Component</a>)&nbsp;
+ </li>
+ <li>
+ Critical system interfaces (see <a class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/guidelines/repres_interfaces_to_ext_systems_51A34F6E.html"
+ guid="_0gjdYMlgEdmt3adZL5Dmdw">Guideline: Representing Interfaces to External Systems</a>)
+ </li>
+ <li>
+ Assets that have been reused and/or assets that have been developed to be reused (for more information, see <a
+ class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/guidelines/software_reuse_B6B04C26.html"
+ guid="_vO2uoO0OEduUpsu85bVhiQ">Guideline: Software Reuse</a>)
+ </li>
+ <li>
+ Guidance, decisions, and constraints the developers must follow in building the system, along with justification
+ </li>
+</ul>
+<p>
+ The architecture can contain any information and references that are appropriate in communicating how developers should
+ build the system.
+</p>
+<h4>
+ Architectural Representation
+</h4>
+<p>
+ The architecture can be represented in many forms and from many viewpoints, depending on the needs of the project and
+ the preferences of the project team. It need not be a formal document. The essence of the architecture can often be
+ communicated through a series of simple diagrams on a whiteboard; or as a list of decisions. The illustration just
+ needs to show the nature of the proposed solution, convey the governing ideas, and represent the major building blocks
+ to make it easier to communicate the architecture to the project team and stakeholders.
+</p>
+<p>
+ If a more complex system is required, then the architecture can be represented as a more comprehensive set
+ of&nbsp;views that describe the architecture from a number of viewpoints. For more information, see <a
+ class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_views_viewpoints_7A6CD31.html"
+ guid="_kgtcoNc8Edyd7OybSySFxg">Concept: Architectural Views and Viewpoints</a>.
+</p>
+<p>
+ The architecture can be expressed as a simple metaphor or as a comparison to a predefined architectural style or set of
+ styles. It may be a precise set of models or documents that describe the various aspects of the system's key elements.
+ Expressing it as skeletal implementation is another option - although this may need to be baselined and preserved to
+ ensure that the essence of the system can be understood as the system grows. Choose the medium that best meets the
+ needs of the project.
+</p>
+<h3>
+ Architectural Patterns
+</h3>
+<p>
+ Architectural <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/pattern_10BE6D96.html"
+ guid="_0YJvUMlgEdmt3adZL5Dmdw">Pattern</a>s are ready-made forms that solve recurring architectural problems. An
+ architectural framework or an architectural infrastructure (middleware) is a set of components on which you can build a
+ certain kind of architecture. Many of the major architectural difficulties should be resolved in the framework or in
+ the infrastructure, usually targeted to a specific domain: command and control, MIS, control system, and so on.
+</p>
+<p>
+ <a class="elementlinkwithusertext"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[BUS96]</a> groups architectural patterns according to the characteristics of the
+ systems in which they are most applicable, with one category dealing with more general structuring issues. The table
+ shows the categories presented in <a class="elementlinkwithusertext"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[BUS96]</a> and the patterns they contain.
+</p>
+<div align="center">
+ <table
+ style="BORDER-RIGHT: rgb(128,128,128) 1px solid; BORDER-TOP: rgb(128,128,128) 1px solid; BORDER-LEFT: rgb(128,128,128) 1px solid; BORDER-BOTTOM: rgb(128,128,128) 1px solid"
+ cellspacing="0" bordercolordark="#808080" cellpadding="4" width="85%" bordercolorlight="#808080" border="1">
+ <tbody>
+ <tr>
+ <th id="col1" width="50%">
+ Category
+ </th>
+ <th id="col2" width="50%">
+ Pattern
+ </th>
+ </tr>
+ <tr>
+ <th id="row2" align="left" headers="col1" width="50%" rowspan="3">
+ Structure
+ </th>
+ <td headers="row2 col2" width="50%">
+ Layers
+ </td>
+ </tr>
+ <tr>
+ <td headers="row2 col2" width="50%">
+ Pipes and Filters
+ </td>
+ </tr>
+ <tr>
+ <td headers="row2 col2" width="50%">
+ Blackboard
+ </td>
+ </tr>
+ <tr>
+ <th id="row3" align="left" headers="col1" width="50%">
+ Distributed Systems
+ </th>
+ <td headers="row3 col2" width="50%">
+ Broker
+ </td>
+ </tr>
+ <tr>
+ <th id="row4" align="left" headers="col1" width="50%" rowspan="2">
+ Interactive Systems
+ </th>
+ <td headers="row4 col2" width="50%">
+ Model-View-Controller
+ </td>
+ </tr>
+ <tr>
+ <td headers="row4 col2" width="50%">
+ Presentation-Abstraction-Control
+ </td>
+ </tr>
+ <tr>
+ <th id="row5" align="left" headers="col1" width="50%" rowspan="2">
+ Adaptable Systems
+ </th>
+ <td headers="row5 col2" width="50%">
+ Reflection
+ </td>
+ </tr>
+ <tr>
+ <td headers="row5 col2" width="50%">
+ Microkernel
+ </td>
+ </tr>
+ </tbody>
+ </table><br />
+</div>
+<p>
+ Refer to <a class="elementlinkwithusertext"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[BUS96]</a> for a complete description of these patterns.
+</p>
+<h3>
+ <a id="Architectural Style" name="Architectural Style">Architectural Style</a>
+</h3>
+<p>
+ A software architecture (or an architectural view) may have an attribute called <b>architectural style</b>, which
+ reduces the set of possible forms to choose from, and imposes a certain degree of uniformity to the architecture. The
+ style may be defined by a set of patterns, or by the choice of specific components or connectors as the basic building
+ blocks.
+</p>
+<h3>
+ Architectural Timing
+</h3>
+<p>
+ Teams should expect to spend more time on architectural issues early in the project.&nbsp; This allows the team to
+ reduce risk associated to technology early in the project, hence allowing the team to more rapidly reduce the variance
+ in their estimate on what they can deliver at what time. Examples of architectural issues that needs to be resolved
+ early on include the following:
+</p>
+<ul>
+ <li>
+ Component and their major interfaces.
+ </li>
+ <li>
+ Major technology choices (platform, languages, architecture frameworks / reference architectures, etc.).
+ </li>
+ <li>
+ Interfaces to external systems.
+ </li>
+ <li>
+ Common services (persistence mechanisms, logging mechanisms, garbage collection, etc.).
+ </li>
+ <li>
+ Key patterns.
+ </li>
+</ul>
+<h3>
+ Validating the Architecture
+</h3>
+<p>
+ The best way to validate the architecture is to actually implement it.&nbsp; For more information, see <a
+ class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/concepts/executable_arch_D4E68CBD.html"
+ guid="_O1kAANvfEduv2KOT-Teh6w">Executable Architecture</a>.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/system_wide_requirements.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/system_wide_requirements.xmi
index 22bc8cf..ce3ef38 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/system_wide_requirements.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/system_wide_requirements.xmi
@@ -1,98 +1,98 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-3SXuKijeVOZalgLPgWRyFA" name="supporting_requirements_1,_VXZ5wO0IEdqHTdbLTmC5IQ" guid="-3SXuKijeVOZalgLPgWRyFA" authors="Chris Sibbald" changeDate="2008-02-11T01:54:28.000-0800" version="0.2">
- <mainDescription><h3>
- Definition
-</h3>
-<p>
- System-wide requirements are requirements that&nbsp;define necessary system quality attributes&nbsp;such as
- performance, usability and reliability, as well as global functional requirements&nbsp;that are not captured in
- behavioral requirements artifacts such as use cases.
-</p>
-<h3>
- System-wide&nbsp;Requirements Categories
-</h3>
-<p>
- System-wide&nbsp;requirements are categorized according to the FURPS+ model (Functional, Usability, Reliability,
- Performance, Supportability + constraints). Constraints&nbsp;include design, implementation, interfaces, physical
- constraints, and business rules. A description of each of these types of requirements follows.
-</p>
-<p>
- System-wide requirements and use cases, together, define the requirements of the system. These requirements support the
- features listed in the vision statement. Each requirement should&nbsp;support at least one feature, and each feature
- should be supported by at least one requirement.
-</p>
-<p>
- In general, <strong>functional</strong> requirements describe behavior and can be captured as&nbsp;use cases.
- <strong>Non-functional</strong> requirements are captured in a system-wide requirements specification.&nbsp;However,
- nonfunctional requirements that are closely associated with a particular use case are often captured within the
- use-case specification itself to simplify communication and maintenance.&nbsp;Similarly, there are global, or
- system-wide functional requirements that are often captured among the system-wide requirements for the same
- reasons.&nbsp;
-</p>
-<h4>
- Functional requirements
-</h4>
-<p>
- Functional requirements include all the overarching, system-wide functional requirements that are not expressed as use
- cases. These functional requirements represent the main system features that are familiar within the business domain or
- technically oriented requirements such as auditing, licensing, localization, e-mail, online help, printing, reporting,
- security, system management, or workflow.
-</p>
-<h4>
- Usability requirements
-</h4>
-<p>
- Usability requirements include requirements based on human factors and user-interface issues such as accessibility,
- interface aesthetics, and consistency within the user interface.
-</p>
-<h4>
- Reliability requirements
-</h4>
-<p>
- Reliability requirements include aspects such as availability, accuracy, predictability, frequency of failure or
- recoverability of the system from shut-down failure.
-</p>
-<h4>
- Performance requirements
-</h4>
-<p>
- Performance requirements address concerns such as throughput of information through the system, system response time
- and resource usage.
-</p>
-<h4>
- Supportability requirements
-</h4>
-<p>
- Supportability requirements include&nbsp;requirements such as compatibility and the abilities to test, adapt, maintain,
- configure, install, scale, and localize the system.
-</p>
-<h4>
- + Constraints
-</h4>
-<p>
- The <strong>+</strong> of the FURPS+ acronym allows you to specify constraints, such as design, implementation,
- interfaces, physical constraints, and business rules:
-</p>
-<ul>
- <li>
- <strong>Design constraints</strong> limit the design and state requirements on the approach that should be taken in
- developing the system.
- </li>
- <li>
- <strong>Implementation constraints</strong> put limits on coding or construction (required standards, languages,
- tools, or platform)
- </li>
- <li>
- <strong>Interface constraints</strong> are requirements to interact with external systems, describing protocols or
- the nature of the information that is passed across that interface.
- </li>
- <li>
- <strong>Physical constraints</strong> affect the hardware or packaging housing the system (shape, size, and
- weight).
- </li>
- <li>
- <strong>Business rules</strong> are policies or decisions that govern how the business operates. They may constrain
- the steps described in the us-case flow.
- </li>
+ <mainDescription><h3>
+ Definition
+</h3>
+<p>
+ System-wide requirements are requirements that&nbsp;define necessary system quality attributes&nbsp;such as
+ performance, usability and reliability, as well as global functional requirements&nbsp;that are not captured in
+ behavioral requirements artifacts such as use cases.
+</p>
+<h3>
+ System-wide&nbsp;Requirements Categories
+</h3>
+<p>
+ System-wide&nbsp;requirements are categorized according to the FURPS+ model (Functional, Usability, Reliability,
+ Performance, Supportability + constraints). Constraints&nbsp;include design, implementation, interfaces, physical
+ constraints, and business rules. A description of each of these types of requirements follows.
+</p>
+<p>
+ System-wide requirements and use cases, together, define the requirements of the system. These requirements support the
+ features listed in the vision statement. Each requirement should&nbsp;support at least one feature, and each feature
+ should be supported by at least one requirement.
+</p>
+<p>
+ In general, <strong>functional</strong> requirements describe behavior and can be captured as&nbsp;use cases.
+ <strong>Non-functional</strong> requirements are captured in a system-wide requirements specification.&nbsp;However,
+ nonfunctional requirements that are closely associated with a particular use case are often captured within the
+ use-case specification itself to simplify communication and maintenance.&nbsp;Similarly, there are global, or
+ system-wide functional requirements that are often captured among the system-wide requirements for the same
+ reasons.&nbsp;
+</p>
+<h4>
+ Functional requirements
+</h4>
+<p>
+ Functional requirements include all the overarching, system-wide functional requirements that are not expressed as use
+ cases. These functional requirements represent the main system features that are familiar within the business domain or
+ technically oriented requirements such as auditing, licensing, localization, e-mail, online help, printing, reporting,
+ security, system management, or workflow.
+</p>
+<h4>
+ Usability requirements
+</h4>
+<p>
+ Usability requirements include requirements based on human factors and user-interface issues such as accessibility,
+ interface aesthetics, and consistency within the user interface.
+</p>
+<h4>
+ Reliability requirements
+</h4>
+<p>
+ Reliability requirements include aspects such as availability, accuracy, predictability, frequency of failure or
+ recoverability of the system from shut-down failure.
+</p>
+<h4>
+ Performance requirements
+</h4>
+<p>
+ Performance requirements address concerns such as throughput of information through the system, system response time
+ and resource usage.
+</p>
+<h4>
+ Supportability requirements
+</h4>
+<p>
+ Supportability requirements include&nbsp;requirements such as compatibility and the abilities to test, adapt, maintain,
+ configure, install, scale, and localize the system.
+</p>
+<h4>
+ + Constraints
+</h4>
+<p>
+ The <strong>+</strong> of the FURPS+ acronym allows you to specify constraints, such as design, implementation,
+ interfaces, physical constraints, and business rules:
+</p>
+<ul>
+ <li>
+ <strong>Design constraints</strong> limit the design and state requirements on the approach that should be taken in
+ developing the system.
+ </li>
+ <li>
+ <strong>Implementation constraints</strong> put limits on coding or construction (required standards, languages,
+ tools, or platform)
+ </li>
+ <li>
+ <strong>Interface constraints</strong> are requirements to interact with external systems, describing protocols or
+ the nature of the information that is passed across that interface.
+ </li>
+ <li>
+ <strong>Physical constraints</strong> affect the hardware or packaging housing the system (shape, size, and
+ weight).
+ </li>
+ <li>
+ <strong>Business rules</strong> are policies or decisions that govern how the business operates. They may constrain
+ the steps described in the us-case flow.
+ </li>
</ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/test_ideas.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/test_ideas.xmi
index 1bcd910..7bd8b4d 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/test_ideas.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/test_ideas.xmi
@@ -1,37 +1,37 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_uqL2gMM3EdmSIPI87WLu3g" name="test_ideas,_0jnYcMlgEdmt3adZL5Dmdw" guid="_uqL2gMM3EdmSIPI87WLu3g" changeDate="2006-07-20T03:10:39.000-0700" version="7.2.0">
- <mainDescription><p>
- <strong>Test Ideas List</strong> - A list of brief statements identifying tests that are potentially useful to conduct.
-</p>
-<p>
- <strong>Test Ideas Catalog</strong> - A catalog of common faults and mistakes done when developing software.
-</p>
-<ul>
- <li>
- Test Ideas will describe any of the elements of an executable test.&nbsp;
- </li>
- <li>
- Test ideas ensure the important ideas are not forgotten and are detailed later in test cases.&nbsp;&nbsp;
- </li>
- <li>
- Test Ideas are to be captured at a less-specific level in an intermediate form.
- </li>
- <li>
- Test ideas are more reviewable and understandable then complete tests.&nbsp; Making the reasoning behind the test
- idea clearer.&nbsp;
- </li>
- <li>
- Test ideas support more powerful test, by not constraining the tester.&nbsp; Making it easier to create tests that
- validate more then just the defined requirements.
- </li>
- <li>
- Test Ideas are often based on explicit and implicit fault modules, to include but not limited to Booleans,
- boundaries and method calls.&nbsp; Test Ideas Lists will contain test ideas from many faults models derived for one
- or many work products.
- </li>
-</ul>
-<p>
- Creating test ideas before testing for review and inspection of design work products assists in discovering design or
- analysis errors.
+ <mainDescription><p>
+ <strong>Test Ideas List</strong> - A list of brief statements identifying tests that are potentially useful to conduct.
+</p>
+<p>
+ <strong>Test Ideas Catalog</strong> - A catalog of common faults and mistakes done when developing software.
+</p>
+<ul>
+ <li>
+ Test Ideas will describe any of the elements of an executable test.&nbsp;
+ </li>
+ <li>
+ Test ideas ensure the important ideas are not forgotten and are detailed later in test cases.&nbsp;&nbsp;
+ </li>
+ <li>
+ Test Ideas are to be captured at a less-specific level in an intermediate form.
+ </li>
+ <li>
+ Test ideas are more reviewable and understandable then complete tests.&nbsp; Making the reasoning behind the test
+ idea clearer.&nbsp;
+ </li>
+ <li>
+ Test ideas support more powerful test, by not constraining the tester.&nbsp; Making it easier to create tests that
+ validate more then just the defined requirements.
+ </li>
+ <li>
+ Test Ideas are often based on explicit and implicit fault modules, to include but not limited to Booleans,
+ boundaries and method calls.&nbsp; Test Ideas Lists will contain test ideas from many faults models derived for one
+ or many work products.
+ </li>
+</ul>
+<p>
+ Creating test ideas before testing for review and inspection of design work products assists in discovering design or
+ analysis errors.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/testing_qualitative_rqmts.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/testing_qualitative_rqmts.xmi
index 016f1e8..bd6f295 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/testing_qualitative_rqmts.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/testing_qualitative_rqmts.xmi
@@ -1,132 +1,132 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_y-_PIMPdEdmbOvqy4O0adg" name="testing_qualitative_rqmts,_0aJ6cMlgEdmt3adZL5Dmdw" guid="_y-_PIMPdEdmbOvqy4O0adg" changeDate="2008-10-14T10:51:17.000-0700" version="7.2.0">
- <mainDescription><h3>
- Introduction
-</h3>
-<p>
- There is much more to testing computer software than simply evaluating the functions, interface, and response-time
- characteristics of a target-of-test.&nbsp;Additional tests must focus on characteristics and attributes, such as the
- target-of-test.
-</p>
-<ul>
- <li>
- integrity (resistance to failure)
- </li>
- <li>
- ability to be installed and executed on different platforms
- </li>
- <li>
- ability to handle many requests simultaneously
- </li>
-</ul>
-<p>
- To achieve this, many different types of tests are implemented and executed.&nbsp;Each test type has a specific
- objective and support technique.&nbsp;Each technique focuses on testing one or more characteristics or attributes of
- the target-of-test.
-</p>
-<p>
- The following sections list the types of test based on the most obvious quality&nbsp;attributes they address.
-</p>
-<h3>
- Types of test for&nbsp;Functionality
-</h3>
-<p>
- <strong>Function test:</strong>&nbsp;Tests focused on validating the target-of-test functions as intended, providing
- the required services, methods, or use cases. This test is implemented and executed against different targets-of-test,
- including units, integrated units, applications, and systems.
-</p>
-<p>
- <strong>Security test:</strong>&nbsp;Tests focused on ensuring the target-of-test data (or systems) are accessible only
- to those actors for which they are intended. This test is implemented and executed on various targets-of-test.
-</p>
-<p>
- <strong>Volume test:</strong>&nbsp;Tests focused on verifying the target-of-test's ability to handle large amounts of
- data, either as input and output or resident within the database.&nbsp;Volume testing includes test strategies such as
- creating queries that would return the entire contents of the database, or that would have so many restrictions that no
- data is returned, or where the data entry has the maximum amount of data for each field.
-</p>
-<h3>
- Types of test for&nbsp;Usability
-</h3>
-<p>
- <strong>Usability test:</strong>&nbsp;Tests that focus on:
-</p>
-<ul>
- <li>
- human factors
- </li>
- <li>
- esthetics
- </li>
- <li>
- consistency in the user interface
- </li>
- <li>
- online and context-sensitive help
- </li>
- <li>
- wizards and agents
- </li>
- <li>
- user documentation
- </li>
- <li>
- training materials
- </li>
-</ul>
-<p>
- <strong>Integrity test:</strong>&nbsp;Tests that focus on assessing the target-of-test's robustness (resistance to
- failure), and technical compliance to language, syntax, and resource usage.&nbsp;This test is implemented and executed
- against different targets-of-tests, including units and integrated units.
-</p>
-<p>
- <strong>Structure test</strong>: Tests that focus on assessing the target-of-test's adherence to its design and
- formation.&nbsp;Typically, this test is done for Web-enabled applications ensuring that all links are connected,
- appropriate content is displayed, and no content is orphaned.
-</p>
-<h3>
- Types of test for&nbsp;Reliability
-</h3>
-<p>
- <strong>Stress test:</strong>&nbsp; A type of reliability test that focuses on evaluating how the system responds under
- abnormal conditions.&nbsp;Stresses on the system could include extreme workloads, insufficient memory, unavailable
- services and hardware, or limited shared resources.&nbsp;These tests are often performed to gain a better understanding
- of how and in what areas the system will break, so that contingency plans and upgrade maintenance can be planned and
- budgeted for well in advance.
-</p>
-<p>
- <strong>Benchmark test:</strong>&nbsp; A type of performance test that compares the performance of a new or unknown
- target-of-test to a known reference-workload and system.
-</p>
-<p>
- <strong>Contention test:</strong>&nbsp; Tests focused on validating the target-of-test's ability to acceptably handle
- multiple actor demands on the same resource (data records, memory, and so on).
-</p>
-<h3>
- Types of test for Performance
-</h3>
-<p>
- <strong>Load test:</strong>&nbsp; A type of performance test used to validate and assess acceptability of the
- operational limits of a system under varying workloads while the system-under-test remains constant.&nbsp;In some
- variants, the workload remains constant and the configuration of the system-under-test is varied.&nbsp; Measurements
- are usually taken based on the workload throughout and in-line transaction response time.&nbsp;The variations in
- workload usually include emulation of average and peak workloads that occur within normal operational tolerances.
-</p>
-<p>
- <strong>Performance profile:</strong> A test in which the target-of-test's timing profile is monitored, including
- execution flow, data access, function and system calls to identify and address both performance bottlenecks and
- inefficient processes.
-</p>
-<p>
- <strong>Configuration test:</strong>&nbsp; Tests focused on ensuring the target-of-test functions as intended on
- different hardware and software configurations.&nbsp;This test might also be implemented as a system performance test.
-</p>
-<h3>
- Types of test for Supportability
-</h3>
-<p>
- <strong>Installation test:</strong>&nbsp; Tests focused on ensuring the target-of-test installs as intended on
- different hardware and software configurations, and under different conditions (such as insufficient disk space or
- power interruptions).&nbsp;This test is implemented and executed against applications and systems.
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ There is much more to testing computer software than simply evaluating the functions, interface, and response-time
+ characteristics of a target-of-test.&nbsp;Additional tests must focus on characteristics and attributes, such as the
+ target-of-test.
+</p>
+<ul>
+ <li>
+ integrity (resistance to failure)
+ </li>
+ <li>
+ ability to be installed and executed on different platforms
+ </li>
+ <li>
+ ability to handle many requests simultaneously
+ </li>
+</ul>
+<p>
+ To achieve this, many different types of tests are implemented and executed.&nbsp;Each test type has a specific
+ objective and support technique.&nbsp;Each technique focuses on testing one or more characteristics or attributes of
+ the target-of-test.
+</p>
+<p>
+ The following sections list the types of test based on the most obvious quality&nbsp;attributes they address.
+</p>
+<h3>
+ Types of test for&nbsp;Functionality
+</h3>
+<p>
+ <strong>Function test:</strong>&nbsp;Tests focused on validating the target-of-test functions as intended, providing
+ the required services, methods, or use cases. This test is implemented and executed against different targets-of-test,
+ including units, integrated units, applications, and systems.
+</p>
+<p>
+ <strong>Security test:</strong>&nbsp;Tests focused on ensuring the target-of-test data (or systems) are accessible only
+ to those actors for which they are intended. This test is implemented and executed on various targets-of-test.
+</p>
+<p>
+ <strong>Volume test:</strong>&nbsp;Tests focused on verifying the target-of-test's ability to handle large amounts of
+ data, either as input and output or resident within the database.&nbsp;Volume testing includes test strategies such as
+ creating queries that would return the entire contents of the database, or that would have so many restrictions that no
+ data is returned, or where the data entry has the maximum amount of data for each field.
+</p>
+<h3>
+ Types of test for&nbsp;Usability
+</h3>
+<p>
+ <strong>Usability test:</strong>&nbsp;Tests that focus on:
+</p>
+<ul>
+ <li>
+ human factors
+ </li>
+ <li>
+ esthetics
+ </li>
+ <li>
+ consistency in the user interface
+ </li>
+ <li>
+ online and context-sensitive help
+ </li>
+ <li>
+ wizards and agents
+ </li>
+ <li>
+ user documentation
+ </li>
+ <li>
+ training materials
+ </li>
+</ul>
+<p>
+ <strong>Integrity test:</strong>&nbsp;Tests that focus on assessing the target-of-test's robustness (resistance to
+ failure), and technical compliance to language, syntax, and resource usage.&nbsp;This test is implemented and executed
+ against different targets-of-tests, including units and integrated units.
+</p>
+<p>
+ <strong>Structure test</strong>: Tests that focus on assessing the target-of-test's adherence to its design and
+ formation.&nbsp;Typically, this test is done for Web-enabled applications ensuring that all links are connected,
+ appropriate content is displayed, and no content is orphaned.
+</p>
+<h3>
+ Types of test for&nbsp;Reliability
+</h3>
+<p>
+ <strong>Stress test:</strong>&nbsp; A type of reliability test that focuses on evaluating how the system responds under
+ abnormal conditions.&nbsp;Stresses on the system could include extreme workloads, insufficient memory, unavailable
+ services and hardware, or limited shared resources.&nbsp;These tests are often performed to gain a better understanding
+ of how and in what areas the system will break, so that contingency plans and upgrade maintenance can be planned and
+ budgeted for well in advance.
+</p>
+<p>
+ <strong>Benchmark test:</strong>&nbsp; A type of performance test that compares the performance of a new or unknown
+ target-of-test to a known reference-workload and system.
+</p>
+<p>
+ <strong>Contention test:</strong>&nbsp; Tests focused on validating the target-of-test's ability to acceptably handle
+ multiple actor demands on the same resource (data records, memory, and so on).
+</p>
+<h3>
+ Types of test for Performance
+</h3>
+<p>
+ <strong>Load test:</strong>&nbsp; A type of performance test used to validate and assess acceptability of the
+ operational limits of a system under varying workloads while the system-under-test remains constant.&nbsp;In some
+ variants, the workload remains constant and the configuration of the system-under-test is varied.&nbsp; Measurements
+ are usually taken based on the workload throughout and in-line transaction response time.&nbsp;The variations in
+ workload usually include emulation of average and peak workloads that occur within normal operational tolerances.
+</p>
+<p>
+ <strong>Performance profile:</strong> A test in which the target-of-test's timing profile is monitored, including
+ execution flow, data access, function and system calls to identify and address both performance bottlenecks and
+ inefficient processes.
+</p>
+<p>
+ <strong>Configuration test:</strong>&nbsp; Tests focused on ensuring the target-of-test functions as intended on
+ different hardware and software configurations.&nbsp;This test might also be implemented as a system performance test.
+</p>
+<h3>
+ Types of test for Supportability
+</h3>
+<p>
+ <strong>Installation test:</strong>&nbsp; Tests focused on ensuring the target-of-test installs as intended on
+ different hardware and software configurations, and under different conditions (such as insufficient disk space or
+ power interruptions).&nbsp;This test is implemented and executed against applications and systems.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/traceability.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/traceability.xmi
index fe6be70..16d40d8 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/traceability.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/traceability.xmi
@@ -1,66 +1,68 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-TksCtMgc0b4QqzwzniGvIw" name="traceability_1,_eYtQQO0KEdqHTdbLTmC5IQ" guid="-TksCtMgc0b4QqzwzniGvIw" authors="Chris Sibbald" changeDate="2006-05-01T03:37:44.000-0700" changeDescription="Added concept in accordance with Feb 23, 2006 minutes of RM SIG meeting." version="0.1">
- <mainDescription><p align="left">
- Traceability is about understanding how high-level requirements (objectives, goals, aims, aspirations, expectations,
- needs) are transformed into low-level requirements, how they are implemented, and how they are verified.
-</p>
-<p>
- Using traceability can provide the following benefits <a class="elementlinkwithusertext" href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#HUL05" guid="_9ToeIB83Edqsvps02rpOOg">[HUL05]</a>:
-</p>
-<ul>
- <li>
- <strong>Greater confidence in meeting objectives</strong>
- </li>
-</ul>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <p>
- Establishing traceability engenders greater reflection on how objectives are satisfied.&nbsp; Traceability permits
- coverage analysis to ensure that everything you have done everything that you agreed to do and only what you agreed
- to do.
- </p>
-</blockquote>
-<ul>
- <li>
- <strong>Ability to assess the impact of change</strong>
- </li>
-</ul>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <p>
- Traceability permits various forms of impact analysis that can be used to assess the impact of a proposed change on
- the cost, schedule, and technical aspects of the project.
- </p>
-</blockquote>
-<ul>
- <li>
- <strong>Improved accountability</strong>
- </li>
-</ul>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <p>
- Traceability provides greater clarity about how work contributes to the whole.
- </p>
-</blockquote>
-<ul>
- <li>
- <strong>Ability to track progress</strong>
- </li>
-</ul>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <p>
- It is notoriously difficult to measure progress when all that you are doing is creating and revising artifacts.
- Traceability processes allow precise measures of progress, such as: Is there a design artifact for each
- requirement? Is there a test case for each requirement?.
- </p>
-</blockquote>
-<ul>
- <li>
- <strong>Ability to balance cost against benefit</strong>
- </li>
-</ul>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <p>
- Relating product components to the requirements allows you to compare benefits to costs.
- </p>
-</blockquote><br dir="ltr" />
+ <mainDescription><p align="left">
+ Traceability is about understanding how high-level requirements (objectives, goals, aims, aspirations, expectations,
+ needs) are transformed into low-level requirements, how they are implemented, and how they are verified.
+</p>
+<p>
+ Using traceability can provide the following benefits <a class="elementlinkwithusertext"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#HUL05"
+ guid="_9ToeIB83Edqsvps02rpOOg">[HUL05]</a>:
+</p>
+<ul>
+ <li>
+ <strong>Greater confidence in meeting objectives</strong>
+ </li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ Establishing traceability engenders greater reflection on how objectives are satisfied.&nbsp; Traceability permits
+ coverage analysis to ensure that everything you have done everything that you agreed to do and only what you agreed
+ to do.
+ </p>
+</blockquote>
+<ul>
+ <li>
+ <strong>Ability to assess the impact of change</strong>
+ </li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ Traceability permits various forms of impact analysis that can be used to assess the impact of a proposed change on
+ the cost, schedule, and technical aspects of the project.
+ </p>
+</blockquote>
+<ul>
+ <li>
+ <strong>Improved accountability</strong>
+ </li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ Traceability provides greater clarity about how work contributes to the whole.
+ </p>
+</blockquote>
+<ul>
+ <li>
+ <strong>Ability to track progress</strong>
+ </li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ It is notoriously difficult to measure progress when all that you are doing is creating and revising artifacts.
+ Traceability processes allow precise measures of progress, such as: Is there a design artifact for each
+ requirement? Is there a test case for each requirement?.
+ </p>
+</blockquote>
+<ul>
+ <li>
+ <strong>Ability to balance cost against benefit</strong>
+ </li>
+</ul>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ Relating product components to the requirements allows you to compare benefits to costs.
+ </p>
+</blockquote><br dir="ltr" />
<br /></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/use_case.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/use_case.xmi
index 9ee204b..31ed89c 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/use_case.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/use_case.xmi
@@ -1,203 +1,207 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-BQLZ5GRUNrMdU6XeZAfe9Q" name="use_case,_KudM0NcJEdqz_d2XWoVt6Q" guid="-BQLZ5GRUNrMdU6XeZAfe9Q" changeDate="2008-09-03T05:28:03.000-0700" version="7.2.0">
- <mainDescription><h3>
- Overview
-</h3>
-<p>
- A use case describes the interactions between one of more&nbsp;<a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/concepts/actor_411726C.html" guid="_zGqO0MDpEduTGJ8i4u8TMw">Actor</a>s and the system in order to provide an observable result of value for the
- initiating actor.
-</p>
-<p>
- The functionality of a system is defined by different use cases, each of which represents a specific goal (to obtain
- the observable result of value) for a particular actor.
-</p>
-<p>
- In an automated teller machine shown in Figure 1, the Bank Customer can withdraw cash from an account, transfer funds
- between accounts, or deposit funds to an account. These correspond to specific goals that the actor has in using the
- system.&nbsp;
-</p><br />
-<p>
- <img height="321" alt="Figure 1: ATM Use-Case Example" src="resources/fig1_atm_ex.gif" width="456" />
-</p>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <p>
- Figure 1: ATM Use-Case Example
- </p>
- </blockquote>
-</blockquote>
-<p>
- Each use case is associated with a goal of one of the actors. The collection of use cases constitutes all the possible
- ways of using the system. You should be able to determine the goal of a use case simply by observing its name.
-</p>
-<p>
- A use case describes the interactions between the actor(s) and the system in the form of a dialog between the actor(s)
- and the system, structured as follows:
-</p>
-<ol>
- <li>
- The actor &lt;&lt;does something&gt;&gt;
- </li>
- <li>
- The system &lt;&lt;does something in response&gt;&gt;
- </li>
- <li>
- The actor &lt;&lt;does something else&gt;&gt;
- </li>
- <li>
- The system ...
- </li>
-</ol>
-<p>
- Each dialog of this form is called a "Flow of Events".
-</p>
-<p>
- Because there are many flows of events possible for achieving the goal (for example, the flow may differ depending upon
- specific input from the actor), and there are situations in which the goal cannot be achieved (for example, a required
- network connection is currently unavailable), each use case will contain several flows, including one "Basic Flow of
- Events" and several "Alternative Flows".
-</p>
-<p>
- The Basic Flow of Events specifies the interactions between the actor(s) and the system for the ideal case, where
- everything goes as planned, and the actor's goal (the observable result of value) is met. The basic flow represents the
- main capability provided by the system for this use case.
-</p>
-<p>
- As the name implies, Alternative Flows specify alternative interactions associated with the same goal.
-</p>
-<p>
- Closely related to use cases is the concept of a scenario. A scenario is a <em><strong>specific</strong></em> flow of
- events, for a <em><strong>specific</strong></em> set of inputs to the system, states of the system, and states of the
- system's environment. Scenarios are closely related to test cases.
-</p>
-<h3>
- Properties of Use Cases
-</h3>
-<h4>
- <a id="Name" name="Name">Name</a>
-</h4>
-<p>
- Each use case should have a name that indicates what is achieved by its interaction with the actors. The name may have
- to be several words to be understood. Note: No two use cases can have the same name.
-</p>
-<h4>
- <a id="Brief Description" name="Brief Description">Brief Description</a>
-</h4>
-<p>
- The brief description of the use case should reflect its purpose.
-</p>
-<h4>
- Flow of Events
-</h4>
-<h5>
- <a id="Flow of Events - Contents" name="Flow of Events - Contents">Flow of Events - Contents</a>
-</h5>
-<p>
- The flow of events should describe the use case's flow of events clearly enough for an outsider to easily understand.
- Remember, the flow of events should represent <em>what</em> the system does, not <em>how</em> the system is design to
- perform the required behavior.
-</p>
-<p>
- Follow these guidelines for the contents of the flow of events:
-</p>
-<ul>
- <li>
- Describe how the use case starts and ends.
- </li>
- <li>
- Describe what data is exchanged between the actor and the use case.
- </li>
- <li>
- Do not describe the details of the user interface, unless it is necessary to understand the behavior of the
- system.&nbsp;Specifying user interface details too early will limit design options.&nbsp;
- </li>
- <li>
- Describe the flow of events, not only the functionality. To enforce this, start every action with "When the actor
- ... ".
- </li>
- <li>
- Describe only the events that belong to the use case, and not what happens in other use cases or outside of the
- system.
- </li>
- <li>
- Avoid vague terminology.
- </li>
- <li>
- Detail the flow of events. Specify what happens when, for each action. Remember this text will be used to identify
- test cases.
- </li>
-</ul>
-<p>
- If you have used certain terms in other use cases, be sure to use the exact same terms in this use case, and
- that&nbsp;the meaning of the terms is consistent. To manage common terms, put them in a glossary.
-</p>
-<h5>
- <a id="Flow of Events - Structure" name="Flow of Events - Structure">Flow of Events - Structure</a>
-</h5>
-<p>
- The two main parts of the flow of events are <b>basic flow of events</b> and <b>alternative flows of events</b>. The
- basic flow of events should cover what "normally" happens when the use case is performed. The alternative flows of
- events cover behavior of optional or exceptional character in relation to the normal behavior, and also variations of
- the normal behavior. You can think of the alternative flows of events as detours from the basic flow of events, some of
- which will return to the basic flow of events and some of which will end the execution of the use case.
-</p>
-<p>
- The straight arrow in Figure 2 represents the basic flow of events, and the curves represent alternative paths in
- relation to the normal. Some alternative paths return to the basic flow of events, whereas others end the use case.
-</p>
-<p>
- <img height="212" alt="Diagram described in caption." src="resources/ucstrct.gif" width="231" />&nbsp;
-</p>
-<p>
- Figure 2: Typical structure of a use case flow of events
-</p>
-<p class="picturetext">
- Both the basic and alternative flows should be further structured into steps or sub-flows. In doing this, your main
- goal should be readability of the text. A&nbsp;guideline is that a sub-flow should be a segment of behavior within the
- use case that has a clear purpose, and is "atomic" in the sense that you do either all or none of the actions
- described.
-</p>
-<h4 class="picturetext">
- <a id="Special Requirements" name="Special Requirements">Special Requirements</a>
-</h4>
-<p>
- In the Special Requirements of a use case, you describe all the requirements associated with&nbsp;the use case that are
- not covered by the flow of events. These are non-functional requirements that will influence the design. See also the
- discussion on non-functional requirements in <a class="elementLinkWithType" href="./../../../core.tech.common.extend_supp/guidances/concepts/requirements_8006414F.html" guid="_0Wh-sMlgEdmt3adZL5Dmdw">Concept: Requirements</a>.
-</p>
-<h4>
- <a id="preconditions and Postconditions" name="preconditions and Postconditions">Preconditions and Post-conditions</a>
-</h4>
-<p>
- A <strong>precondition</strong> is the state of the system and its&nbsp;environment that is required before the use
- case can be started.&nbsp;Post-Conditions are&nbsp;the states the system can be in after the use case has ended. It can
- be&nbsp;helpful to use the&nbsp;concepts of <b>precondition</b> and <b>post-condition</b> to clarify how the flow of
- events starts and ends. However, only use them only if the audience for the description of the use case agrees that it
- is helpful. Figure 3 shows an example.
-</p>
-<p>
- <img height="278" alt="Diagram described in caption." src="resources/ucprepst.gif" width="344" />
-</p><br class="picturetext" />
-<br />
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <p>
- Figure 3: Illustration of preconditions and resulting post-conditions
- </p>
- </blockquote>
- </blockquote>
-</blockquote>
-<p class="exampleheading" dir="ltr">
- Examples
-</p>
-<p class="example" dir="ltr">
- <strong>A precondition for the use case Cash Withdrawal in the ATM machine:</strong> The customer has a personally
- issued card that fits in the card reader, has been issued a PIN number, and is registered with the banking system.
-</p>
-<p class="example" dir="ltr" style="MARGIN-RIGHT: 0px">
- <strong>A post-condition for the use case Cash Withdrawal in the ATM machine:</strong> At the end of the use case, all
- account and transaction logs are balanced, communication with the banking system is reinitialized and the card is
- returned to the customer.
+ <mainDescription><h3>
+ Overview
+</h3>
+<p>
+ A use case describes the interactions between one of more&nbsp;<a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/actor_411726C.html"
+ guid="_zGqO0MDpEduTGJ8i4u8TMw">Actor</a>s and the system in order to provide an observable result of value for the
+ initiating actor.
+</p>
+<p>
+ The functionality of a system is defined by different use cases, each of which represents a specific goal (to obtain
+ the observable result of value) for a particular actor.
+</p>
+<p>
+ In an automated teller machine shown in Figure 1, the Bank Customer can withdraw cash from an account, transfer funds
+ between accounts, or deposit funds to an account. These correspond to specific goals that the actor has in using the
+ system.&nbsp;
+</p><br />
+<p>
+ <img height="321" alt="Figure 1: ATM Use-Case Example" src="resources/fig1_atm_ex.gif" width="456" />
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ Figure 1: ATM Use-Case Example
+ </p>
+ </blockquote>
+</blockquote>
+<p>
+ Each use case is associated with a goal of one of the actors. The collection of use cases constitutes all the possible
+ ways of using the system. You should be able to determine the goal of a use case simply by observing its name.
+</p>
+<p>
+ A use case describes the interactions between the actor(s) and the system in the form of a dialog between the actor(s)
+ and the system, structured as follows:
+</p>
+<ol>
+ <li>
+ The actor &lt;&lt;does something&gt;&gt;
+ </li>
+ <li>
+ The system &lt;&lt;does something in response&gt;&gt;
+ </li>
+ <li>
+ The actor &lt;&lt;does something else&gt;&gt;
+ </li>
+ <li>
+ The system ...
+ </li>
+</ol>
+<p>
+ Each dialog of this form is called a "Flow of Events".
+</p>
+<p>
+ Because there are many flows of events possible for achieving the goal (for example, the flow may differ depending upon
+ specific input from the actor), and there are situations in which the goal cannot be achieved (for example, a required
+ network connection is currently unavailable), each use case will contain several flows, including one "Basic Flow of
+ Events" and several "Alternative Flows".
+</p>
+<p>
+ The Basic Flow of Events specifies the interactions between the actor(s) and the system for the ideal case, where
+ everything goes as planned, and the actor's goal (the observable result of value) is met. The basic flow represents the
+ main capability provided by the system for this use case.
+</p>
+<p>
+ As the name implies, Alternative Flows specify alternative interactions associated with the same goal.
+</p>
+<p>
+ Closely related to use cases is the concept of a scenario. A scenario is a <em><strong>specific</strong></em> flow of
+ events, for a <em><strong>specific</strong></em> set of inputs to the system, states of the system, and states of the
+ system's environment. Scenarios are closely related to test cases.
+</p>
+<h3>
+ Properties of Use Cases
+</h3>
+<h4>
+ <a id="Name" name="Name">Name</a>
+</h4>
+<p>
+ Each use case should have a name that indicates what is achieved by its interaction with the actors. The name may have
+ to be several words to be understood. Note: No two use cases can have the same name.
+</p>
+<h4>
+ <a id="Brief Description" name="Brief Description">Brief Description</a>
+</h4>
+<p>
+ The brief description of the use case should reflect its purpose.
+</p>
+<h4>
+ Flow of Events
+</h4>
+<h5>
+ <a id="Flow of Events - Contents" name="Flow of Events - Contents">Flow of Events - Contents</a>
+</h5>
+<p>
+ The flow of events should describe the use case's flow of events clearly enough for an outsider to easily understand.
+ Remember, the flow of events should represent <em>what</em> the system does, not <em>how</em> the system is design to
+ perform the required behavior.
+</p>
+<p>
+ Follow these guidelines for the contents of the flow of events:
+</p>
+<ul>
+ <li>
+ Describe how the use case starts and ends.
+ </li>
+ <li>
+ Describe what data is exchanged between the actor and the use case.
+ </li>
+ <li>
+ Do not describe the details of the user interface, unless it is necessary to understand the behavior of the
+ system.&nbsp;Specifying user interface details too early will limit design options.&nbsp;
+ </li>
+ <li>
+ Describe the flow of events, not only the functionality. To enforce this, start every action with "When the actor
+ ... ".
+ </li>
+ <li>
+ Describe only the events that belong to the use case, and not what happens in other use cases or outside of the
+ system.
+ </li>
+ <li>
+ Avoid vague terminology.
+ </li>
+ <li>
+ Detail the flow of events. Specify what happens when, for each action. Remember this text will be used to identify
+ test cases.
+ </li>
+</ul>
+<p>
+ If you have used certain terms in other use cases, be sure to use the exact same terms in this use case, and
+ that&nbsp;the meaning of the terms is consistent. To manage common terms, put them in a glossary.
+</p>
+<h5>
+ <a id="Flow of Events - Structure" name="Flow of Events - Structure">Flow of Events - Structure</a>
+</h5>
+<p>
+ The two main parts of the flow of events are <b>basic flow of events</b> and <b>alternative flows of events</b>. The
+ basic flow of events should cover what "normally" happens when the use case is performed. The alternative flows of
+ events cover behavior of optional or exceptional character in relation to the normal behavior, and also variations of
+ the normal behavior. You can think of the alternative flows of events as detours from the basic flow of events, some of
+ which will return to the basic flow of events and some of which will end the execution of the use case.
+</p>
+<p>
+ The straight arrow in Figure 2 represents the basic flow of events, and the curves represent alternative paths in
+ relation to the normal. Some alternative paths return to the basic flow of events, whereas others end the use case.
+</p>
+<p>
+ <img height="212" alt="Diagram described in caption." src="resources/ucstrct.gif" width="231" />&nbsp;
+</p>
+<p>
+ Figure 2: Typical structure of a use case flow of events
+</p>
+<p class="picturetext">
+ Both the basic and alternative flows should be further structured into steps or sub-flows. In doing this, your main
+ goal should be readability of the text. A&nbsp;guideline is that a sub-flow should be a segment of behavior within the
+ use case that has a clear purpose, and is "atomic" in the sense that you do either all or none of the actions
+ described.
+</p>
+<h4 class="picturetext">
+ <a id="Special Requirements" name="Special Requirements">Special Requirements</a>
+</h4>
+<p>
+ In the Special Requirements of a use case, you describe all the requirements associated with&nbsp;the use case that are
+ not covered by the flow of events. These are non-functional requirements that will influence the design. See also the
+ discussion on non-functional requirements in <a class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/requirements_8006414F.html"
+ guid="_0Wh-sMlgEdmt3adZL5Dmdw">Concept: Requirements</a>.
+</p>
+<h4>
+ <a id="preconditions and Postconditions" name="preconditions and Postconditions">Preconditions and Post-conditions</a>
+</h4>
+<p>
+ A <strong>precondition</strong> is the state of the system and its&nbsp;environment that is required before the use
+ case can be started.&nbsp;Post-Conditions are&nbsp;the states the system can be in after the use case has ended. It can
+ be&nbsp;helpful to use the&nbsp;concepts of <b>precondition</b> and <b>post-condition</b> to clarify how the flow of
+ events starts and ends. However, only use them only if the audience for the description of the use case agrees that it
+ is helpful. Figure 3 shows an example.
+</p>
+<p>
+ <img height="278" alt="Diagram described in caption." src="resources/ucprepst.gif" width="344" />
+</p><br class="picturetext" />
+<br />
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ Figure 3: Illustration of preconditions and resulting post-conditions
+ </p>
+ </blockquote>
+ </blockquote>
+</blockquote>
+<p class="exampleheading" dir="ltr">
+ Examples
+</p>
+<p class="example" dir="ltr">
+ <strong>A precondition for the use case Cash Withdrawal in the ATM machine:</strong> The customer has a personally
+ issued card that fits in the card reader, has been issued a PIN number, and is registered with the banking system.
+</p>
+<p class="example" dir="ltr" style="MARGIN-RIGHT: 0px">
+ <strong>A post-condition for the use case Cash Withdrawal in the ATM machine:</strong> At the end of the use case, all
+ account and transaction logs are balanced, communication with the banking system is reinitialized and the card is
+ returned to the customer.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/visual_modeling.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/visual_modeling.xmi
index 150b24c..88e64e8 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/visual_modeling.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/concepts/visual_modeling.xmi
@@ -1,148 +1,148 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_SB1n8MM1EdmSIPI87WLu3g" name="visual_modeling,_0XY6UMlgEdmt3adZL5Dmdw" guid="_SB1n8MM1EdmSIPI87WLu3g" changeDate="2008-02-14T04:58:00.000-0800" version="1.0.0">
- <mainDescription><p align="center">
- <img height="229" alt="visual modeling" src="resources/visual.gif" width="447" />
-</p>
-<p align="center">
- Visual modeling raises the level of abstraction
-</p>
-<p>
- Visual modeling is the use of semantically rich, graphical and textual design notations to capture software designs. A
- notation, such as UML, allows the level of abstraction to be raised, while maintaining rigorous syntax and semantics.
- In this way, it improves communication in the design team, as the design is formed and reviewed, allowing the reader to
- reason about the design, and it provides an unambiguous basis for implementation.
-</p>
-<h3>
- How visual models help
-</h3>
-<p>
- A model is a simplified view of a system. It shows the essentials of the system from a particular perspective and hides
- the nonessential details. Visual models help you:
-</p>
-<ul>
- <li>
- Increase understanding of complex systems
- </li>
- <li>
- Explore and compare design alternatives at a low cost
- </li>
- <li>
- Form a foundation for implementation
- </li>
- <li>
- Capture requirements precisely
- </li>
- <li>
- Communicate decisions unambiguously
- </li>
-</ul>
-<h4>
- Increase understanding of complex systems
-</h4>
-<p>
- The importance of models increases as systems become more complex. For example, you can build a doghouse without
- blueprints. However, as you progress to building houses and then to skyscrapers, your need for blueprints becomes
- pronounced.
-</p>
-<p>
- Similarly, a small application built by one person in a few days may be easily understood in its entirety. However, an
- e&nbsp;-&nbsp;commerce system with tens of thousands of source lines of code (SLOCs) or an air traffic control system
- with hundreds of thousands of SLOCs can no longer be easily understood by one person. Constructing models allows a
- developer to focus on the big picture, understand how components interact, and identify fatal flaws.&nbsp;
-</p>
-<p>
- Among the various types of models are these examples:
-</p>
-<ul>
- <li>
- Use cases to specify behavior unambiguously
- </li>
- <li>
- Class diagrams and data model diagrams to capture design
- </li>
- <li>
- State transition diagrams to model dynamic behavior
- </li>
-</ul>
-<p>
- Modeling is important because it helps the team visualize, construct, and document the structure and behavior of the
- system without getting lost in complexity.
-</p>
-<h4>
- Explore and compare design alternatives at a low cost
-</h4>
-<p>
- You can create and modify simple models inexpensively to explore design alternatives. Innovative ideas can be captured
- and reviewed by other developers before investing in costly code development. When coupled with iterative development,
- visual modeling helps developers assess design changes and communicate these changes to the entire development team.
-</p>
-<h4>
- Form a foundation for implementation
-</h4>
-<p>
- Today, many projects employ object-oriented programming languages to build reusable, change-tolerant, and stable
- systems. To get these benefits, it is even more important to use object technology in design.
-</p>
-<p>
- The creation of visual models, whether&nbsp;on paper; around a whiteboard; or in a modeling tool,&nbsp;can help a team
- to gain agreement on key aspects of the system before investing time&nbsp;in proving&nbsp;their ideas&nbsp;with code.
- Having a shared model of the system promotes collaboration within the team, encouraging everyone to work towards the
- same goal.
-</p>
-<p>
- With the support of appropriate tools, you can use a design model to generate an initial code for implementation. This
- is referred to as <strong>forward engineering</strong> or <strong>code generation</strong>. You can also enhance design
- models to include enough information to build the system.
-</p>
-<p>
- <strong>Reverse engineering</strong> may also be applied to generate design models from existing implementations. You
- can use this method to evaluate existing implementations.&nbsp;&nbsp;
-</p>
-<p>
- <strong>Round-trip engineering</strong> combines both forward and reverse engineering techniques to ensure consistent
- design and code. Combined with an iterative process and the right tools, round-trip engineering allows you to
- synchronize the design and code during each iteration.
-</p>
-<h4>
- Capture requirements precisely
-</h4>
-<p>
- Before building a system, it's critical to capture the requirements. Specifying the requirements using a precise and
- unambiguous model helps to ensure that all stakeholders can understand and agree on the requirements.
-</p>
-<p>
- A model that separates the external behavior of the system from the implementation of it helps you focus on the
- intended use of the system, without getting bogged down in implementation details.
-</p>
-<h4>
- Communicate decisions unambiguously
-</h4>
-<p>
- The Unified Modeling Language (UML) is&nbsp;a consistent notation that can be applied for system engineering, as well
- as for business engineering. According to these excerpts from the UML specification, a standard notation::
-</p>
-<ul>
- <li>
- <p>
- Serves as a language for communicating decisions that are not obvious or cannot be inferred from the code
- itself.
- </p>
- </li>
- <li>
- <p>
- Provides semantics that are rich enough to capture all important strategic and tactical decisions.
- </p>
- </li>
- <li>
- <p>
- Offers a form concrete enough for humans to reason [about] and for tools to manipulate.
- </p>
- </li>
-</ul>
-<p>
- UML represents the convergence of the best practice in software modeling throughout the object-technology industry. For
- more information on the UML, see <a class="elementLinkWithUserText"
- href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
- guid="_9ToeIB83Edqsvps02rpOOg">[UML05]</a>.
+ <mainDescription><p align="center">
+ <img height="229" alt="visual modeling" src="resources/visual.gif" width="447" />
+</p>
+<p align="center">
+ Visual modeling raises the level of abstraction
+</p>
+<p>
+ Visual modeling is the use of semantically rich, graphical and textual design notations to capture software designs. A
+ notation, such as UML, allows the level of abstraction to be raised, while maintaining rigorous syntax and semantics.
+ In this way, it improves communication in the design team, as the design is formed and reviewed, allowing the reader to
+ reason about the design, and it provides an unambiguous basis for implementation.
+</p>
+<h3>
+ How visual models help
+</h3>
+<p>
+ A model is a simplified view of a system. It shows the essentials of the system from a particular perspective and hides
+ the nonessential details. Visual models help you:
+</p>
+<ul>
+ <li>
+ Increase understanding of complex systems
+ </li>
+ <li>
+ Explore and compare design alternatives at a low cost
+ </li>
+ <li>
+ Form a foundation for implementation
+ </li>
+ <li>
+ Capture requirements precisely
+ </li>
+ <li>
+ Communicate decisions unambiguously
+ </li>
+</ul>
+<h4>
+ Increase understanding of complex systems
+</h4>
+<p>
+ The importance of models increases as systems become more complex. For example, you can build a doghouse without
+ blueprints. However, as you progress to building houses and then to skyscrapers, your need for blueprints becomes
+ pronounced.
+</p>
+<p>
+ Similarly, a small application built by one person in a few days may be easily understood in its entirety. However, an
+ e&nbsp;-&nbsp;commerce system with tens of thousands of source lines of code (SLOCs) or an air traffic control system
+ with hundreds of thousands of SLOCs can no longer be easily understood by one person. Constructing models allows a
+ developer to focus on the big picture, understand how components interact, and identify fatal flaws.&nbsp;
+</p>
+<p>
+ Among the various types of models are these examples:
+</p>
+<ul>
+ <li>
+ Use cases to specify behavior unambiguously
+ </li>
+ <li>
+ Class diagrams and data model diagrams to capture design
+ </li>
+ <li>
+ State transition diagrams to model dynamic behavior
+ </li>
+</ul>
+<p>
+ Modeling is important because it helps the team visualize, construct, and document the structure and behavior of the
+ system without getting lost in complexity.
+</p>
+<h4>
+ Explore and compare design alternatives at a low cost
+</h4>
+<p>
+ You can create and modify simple models inexpensively to explore design alternatives. Innovative ideas can be captured
+ and reviewed by other developers before investing in costly code development. When coupled with iterative development,
+ visual modeling helps developers assess design changes and communicate these changes to the entire development team.
+</p>
+<h4>
+ Form a foundation for implementation
+</h4>
+<p>
+ Today, many projects employ object-oriented programming languages to build reusable, change-tolerant, and stable
+ systems. To get these benefits, it is even more important to use object technology in design.
+</p>
+<p>
+ The creation of visual models, whether&nbsp;on paper; around a whiteboard; or in a modeling tool,&nbsp;can help a team
+ to gain agreement on key aspects of the system before investing time&nbsp;in proving&nbsp;their ideas&nbsp;with code.
+ Having a shared model of the system promotes collaboration within the team, encouraging everyone to work towards the
+ same goal.
+</p>
+<p>
+ With the support of appropriate tools, you can use a design model to generate an initial code for implementation. This
+ is referred to as <strong>forward engineering</strong> or <strong>code generation</strong>. You can also enhance design
+ models to include enough information to build the system.
+</p>
+<p>
+ <strong>Reverse engineering</strong> may also be applied to generate design models from existing implementations. You
+ can use this method to evaluate existing implementations.&nbsp;&nbsp;
+</p>
+<p>
+ <strong>Round-trip engineering</strong> combines both forward and reverse engineering techniques to ensure consistent
+ design and code. Combined with an iterative process and the right tools, round-trip engineering allows you to
+ synchronize the design and code during each iteration.
+</p>
+<h4>
+ Capture requirements precisely
+</h4>
+<p>
+ Before building a system, it's critical to capture the requirements. Specifying the requirements using a precise and
+ unambiguous model helps to ensure that all stakeholders can understand and agree on the requirements.
+</p>
+<p>
+ A model that separates the external behavior of the system from the implementation of it helps you focus on the
+ intended use of the system, without getting bogged down in implementation details.
+</p>
+<h4>
+ Communicate decisions unambiguously
+</h4>
+<p>
+ The Unified Modeling Language (UML) is&nbsp;a consistent notation that can be applied for system engineering, as well
+ as for business engineering. According to these excerpts from the UML specification, a standard notation::
+</p>
+<ul>
+ <li>
+ <p>
+ Serves as a language for communicating decisions that are not obvious or cannot be inferred from the code
+ itself.
+ </p>
+ </li>
+ <li>
+ <p>
+ Provides semantics that are rich enough to capture all important strategic and tactical decisions.
+ </p>
+ </li>
+ <li>
+ <p>
+ Offers a form concrete enough for humans to reason [about] and for tools to manipulate.
+ </p>
+ </li>
+</ul>
+<p>
+ UML represents the convergence of the best practice in software modeling throughout the object-technology industry. For
+ more information on the UML, see <a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[UML05]</a>.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/examples/architectural_mechanism_attributes.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/examples/architectural_mechanism_attributes.xmi
index 0202b64..80a8530 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/examples/architectural_mechanism_attributes.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/examples/architectural_mechanism_attributes.xmi
@@ -1,81 +1,81 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:GuidanceDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-8LfKJab2khAUjdmnImaXPA" name="architecture_mechanism_attributes,_eQ_s8Om5Edupia_tZIXEqg" guid="-8LfKJab2khAUjdmnImaXPA" changeDate="2008-10-13T05:07:16.000-0700" version="7.2.0">
- <mainDescription><p>
- The following shows an example of how to capture information for <a class="elementLink"
- href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_mechanism_2932DFB6.html"
- guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanisms</a>. The attributes of two possible mechanisms are shown:
- Persistence and Communication.
-</p>
-<h1>
- Persistence
-</h1>
-<p>
- For all classes with instances that may become persistent, you need to identify:
-</p>
-<ul>
- <li>
- <p>
- <b>Granularity</b><b>:</b> What is the range of size of the objects to keep persistent?
- </p>
- </li>
- <li>
- <p>
- <b>Volume</b><b>:</b> How many objects (number) do you need to keep persistent?
- </p>
- </li>
- <li>
- <p>
- <b>Duration</b><b>:</b> How long does the object typically need to be kept?
- </p>
- </li>
- <li>
- <p>
- <b>Retrieval mechanism</b><b>:</b> How is a given object uniquely identified and retrieved?
- </p>
- </li>
- <li>
- <p>
- <b>Update frequency</b><b>:</b> Are the objects more or less constant? Are they permanently updated?
- </p>
- </li>
- <li>
- <p>
- <b>Reliability</b><b>:</b> Do the objects need to survive a crash of the process, the processor, or the whole
- system?
- </p>
- </li>
-</ul>
-<h1>
- Communication
-</h1>
-<p>
- For all model elements that need to communicate with components or services that are running in other processes or
- threads, you need to identify:
-</p>
-<ul>
- <li>
- <p>
- <b>Latency</b><b>:</b> How fast must processes communicate with another?
- </p>
- </li>
- <li>
- <p>
- <b>Synchronicity</b><b>:</b> Asynchronous communication
- </p>
- </li>
- <li>
- <p>
- <b>Size of message</b><b>:</b> A spectrum might be more appropriate than a single number
- </p>
- </li>
- <li>
- <p>
- <b>Protocol:</b> Flow control, buffering, and so on
- </p>
- </li>
-</ul>
-<p>
- Notice that there is no design-level information or specification here. Instead, this is more about collating and
- refining architecturally significant requirements.
+ <mainDescription><p>
+ The following shows an example of how to capture information for <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_mechanism_2932DFB6.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a>. The attributes of two possible mechanisms are shown:
+ Persistence and Communication.
+</p>
+<h3>
+ Persistence
+</h3>
+<p>
+ For all classes with instances that may become persistent, you need to identify:
+</p>
+<ul>
+ <li>
+ <p>
+ <b>Granularity</b><b>:</b> What is the range of size of the objects to keep persistent?
+ </p>
+ </li>
+ <li>
+ <p>
+ <b>Volume</b><b>:</b> How many objects (number) do you need to keep persistent?
+ </p>
+ </li>
+ <li>
+ <p>
+ <b>Duration</b><b>:</b> How long does the object typically need to be kept?
+ </p>
+ </li>
+ <li>
+ <p>
+ <b>Retrieval mechanism</b><b>:</b> How is a given object uniquely identified and retrieved?
+ </p>
+ </li>
+ <li>
+ <p>
+ <b>Update frequency</b><b>:</b> Are the objects more or less constant? Are they permanently updated?
+ </p>
+ </li>
+ <li>
+ <p>
+ <b>Reliability</b><b>:</b> Do the objects need to survive a crash of the process, the processor, or the whole
+ system?
+ </p>
+ </li>
+</ul>
+<h3>
+ Communication
+</h3>
+<p>
+ For all model elements that need to communicate with components or services that are running in other processes or
+ threads, you need to identify:
+</p>
+<ul>
+ <li>
+ <p>
+ <b>Latency</b><b>:</b> How fast must processes communicate with another?
+ </p>
+ </li>
+ <li>
+ <p>
+ <b>Synchronicity</b><b>:</b> Asynchronous communication
+ </p>
+ </li>
+ <li>
+ <p>
+ <b>Size of message</b><b>:</b> A spectrum might be more appropriate than a single number
+ </p>
+ </li>
+ <li>
+ <p>
+ <b>Protocol:</b> Flow control, buffering, and so on
+ </p>
+ </li>
+</ul>
+<p>
+ Notice that there is no design-level information or specification here. Instead, this is more about collating and
+ refining architecturally significant requirements.
</p></mainDescription>
</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/examples/four_plus_one_view_of_arch.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/examples/four_plus_one_view_of_arch.xmi
index f7438f2..1d9988b 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/examples/four_plus_one_view_of_arch.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/examples/four_plus_one_view_of_arch.xmi
@@ -1,63 +1,65 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:GuidanceDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-sKBCb98PYCcliL0zVljcyQ" name="new_example,_4bC4cNs_EdyEW4klSH3vRA" guid="-sKBCb98PYCcliL0zVljcyQ" changeDate="2008-02-15T06:14:05.000-0800" version="7.2.0">
- <mainDescription><p>
- You may want to consider the following views (not all views are relevant to all systems or all the stakeholders). This
- set of views is known as the 4+1 Views of Software Architecture [<a class="elementLinkWithUserText" href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html" guid="_9ToeIB83Edqsvps02rpOOg">KRU95</a>].
-</p>
-<p>
- <img height="254" alt="4+1 Views of Software Architecture" src="resources/4plus1_2.jpg" width="405" />
-</p>
-<ul>
- <li>
- <p>
- <strong>Use-case view</strong>: Describes functionality of the system, its external interfaces, and its
- principal users. This view is mandatory when using the 4+1 Views, because all elements of the architecture
- should be derived from requirements.
- </p>
- </li>
- <li>
- <p>
- <strong>Logical view</strong>: Describes how the system is structured in terms of units of implementation. The
- elements are packages, classes, and interfaces. The relationship between elements shows dependencies, interface
- realizations, part-whole relationships, and so forth. Note: This view is mandatory when using the 4+1 Views of
- Software Architecture.
- </p>
- </li>
- <li>
- <p>
- <strong>Implementation view</strong>: Describes how development artifacts are organized in the file system. The
- elements are files and directories (any configuration items). This includes development artifacts and
- deployment artifacts. This view is optional when using the 4+1 Views.
- </p>
- </li>
- <li>
- <p>
- <strong>Process view</strong>: Describes how the run-time system is structured as a set of elements that have
- run-time behavior and interactions. Run-time structure often bears little resemblance to the code structure. It
- consists of rapidly changing networks of communication objects. The elements are components that have run-time
- presence (processes, threads, Enterprise JavaBeans&trade; (EJB&trade;), servlets, DLLs, and so on), data stores, and
- complex connectors, such as queues. Interaction between elements varies, based on technology. This view is
- useful for thinking about run-time system quality attributes, such as performance and reliability. This view is
- optional when using the 4+1 Views.
- </p>
- </li>
- <li>
- <p>
- <strong>Deployment view</strong>: Describe how the system is mapped to the hardware. This view is optional when
- using the 4+1 Views.
- </p>
- </li>
-</ul>
-<p>
- In addition, you may wish to represent the following,
-</p>
-<ul>
- <li>
- <p>
- <strong>Data view</strong>: A specialization of the logical view. Use this view if persistence is a significant
- aspect of the system, and the translation from the design model to the data model is not done automatically by
- the persistence mechanism.
- </p>
- </li>
+ <mainDescription><p>
+ You may want to consider the following views (not all views are relevant to all systems or all the stakeholders). This
+ set of views is known as the 4+1 Views of Software Architecture [<a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">KRU95</a>].
+</p>
+<p>
+ <img height="254" alt="4+1 Views of Software Architecture" src="resources/4plus1_2.jpg" width="405" />
+</p>
+<ul>
+ <li>
+ <p>
+ <strong>Use-case view</strong>: Describes functionality of the system, its external interfaces, and its
+ principal users. This view is mandatory when using the 4+1 Views, because all elements of the architecture
+ should be derived from requirements.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Logical view</strong>: Describes how the system is structured in terms of units of implementation. The
+ elements are packages, classes, and interfaces. The relationship between elements shows dependencies, interface
+ realizations, part-whole relationships, and so forth. Note: This view is mandatory when using the 4+1 Views of
+ Software Architecture.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Implementation view</strong>: Describes how development artifacts are organized in the file system. The
+ elements are files and directories (any configuration items). This includes development artifacts and
+ deployment artifacts. This view is optional when using the 4+1 Views.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Process view</strong>: Describes how the run-time system is structured as a set of elements that have
+ run-time behavior and interactions. Run-time structure often bears little resemblance to the code structure. It
+ consists of rapidly changing networks of communication objects. The elements are components that have run-time
+ presence (processes, threads, Enterprise JavaBeans&trade; (EJB&trade;), servlets, DLLs, and so on), data stores, and
+ complex connectors, such as queues. Interaction between elements varies, based on technology. This view is
+ useful for thinking about run-time system quality attributes, such as performance and reliability. This view is
+ optional when using the 4+1 Views.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Deployment view</strong>: Describe how the system is mapped to the hardware. This view is optional when
+ using the 4+1 Views.
+ </p>
+ </li>
+</ul>
+<p>
+ In addition, you may wish to represent the following,
+</p>
+<ul>
+ <li>
+ <p>
+ <strong>Data view</strong>: A specialization of the logical view. Use this view if persistence is a significant
+ aspect of the system, and the translation from the design model to the data model is not done automatically by
+ the persistence mechanism.
+ </p>
+ </li>
</ul></mainDescription>
</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/examples/uc_deposit_funds_outline.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/examples/uc_deposit_funds_outline.xmi
index d9e8d57..1a0495b 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/examples/uc_deposit_funds_outline.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/examples/uc_deposit_funds_outline.xmi
@@ -1,60 +1,60 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:GuidanceDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-SzcBYJR6jUy4WgOhWVpTjA" name="new_example,_jiwo4IHGEd6NhZnUM27HMQ" guid="-SzcBYJR6jUy4WgOhWVpTjA" changeDate="2009-08-05T06:49:25.000-0700" version="7.5.0">
- <mainDescription><h3>
- Step-by-step outline
-</h3>
-<ol>
- <li>
- Insert card
- </li>
- <li>
- Enter PIN
- </li>
- <li>
- Select deposit
- </li>
- <li>
- Select amount
- </li>
- <li>
- Put money in envelope
- </li>
- <li>
- Receive envelope print transaction id on envelope
- </li>
- <li>
- Send deferred transaction
- </li>
- <li>
- Print receipt
- </li>
- <li>
- Eject card
- </li>
- <li>
- The next day open security box
- </li>
- <li>
- Count money
- </li>
- <li>
- Commit transactions
- </li>
-</ol>
-<p>
- Is the counting and committing within our system? Is this a part of some other system at the bank? Where is the
- boundary?
-</p>
-<h3>
- List of Alternative flows
-</h3>
-<p>
- A1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Wrong PIN<br />
- A2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Invalid "to account"<br />
- A3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No envelope inserted<br />
- A4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Two envelopes inserted (or more)<br />
- A5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No money in envelope<br />
- A6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Too much money in envelope<br />
- A7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Envelopes missing
+ <mainDescription><h3>
+ Step-by-step outline
+</h3>
+<ol>
+ <li>
+ Insert card
+ </li>
+ <li>
+ Enter PIN
+ </li>
+ <li>
+ Select deposit
+ </li>
+ <li>
+ Select amount
+ </li>
+ <li>
+ Put money in envelope
+ </li>
+ <li>
+ Receive envelope print transaction id on envelope
+ </li>
+ <li>
+ Send deferred transaction
+ </li>
+ <li>
+ Print receipt
+ </li>
+ <li>
+ Eject card
+ </li>
+ <li>
+ The next day open security box
+ </li>
+ <li>
+ Count money
+ </li>
+ <li>
+ Commit transactions
+ </li>
+</ol>
+<p>
+ Is the counting and committing within our system? Is this a part of some other system at the bank? Where is the
+ boundary?
+</p>
+<h3>
+ List of Alternative flows
+</h3>
+<p>
+ A1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Wrong PIN<br />
+ A2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Invalid "to account"<br />
+ A3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No envelope inserted<br />
+ A4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Two envelopes inserted (or more)<br />
+ A5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No money in envelope<br />
+ A6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Too much money in envelope<br />
+ A7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Envelopes missing
</p></mainDescription>
</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/examples/uc_model_elaboration_phase.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/examples/uc_model_elaboration_phase.xmi
index bb588eb..e97b578 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/examples/uc_model_elaboration_phase.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/examples/uc_model_elaboration_phase.xmi
@@ -1,95 +1,95 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:GuidanceDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-4MpXAgL3mj3i4Huqt5gctA" name="new_example,_MNZ2kIHHEd6NhZnUM27HMQ" guid="-4MpXAgL3mj3i4Huqt5gctA" changeDate="2009-08-05T06:54:07.000-0700" version="7.5.0">
- <mainDescription><h3>
- 1 Introduction
-</h3>
-<p>
- This is an example of a Use-Case Model as it would appear in Elaboration. Primary actors and use cases are identified,
- and key scenarios (those that will be implemented first) are detailed. Each use case has an associated use-case
- specification.
-</p>
-<h3>
- 2 Overview
-</h3>
-<p>
- The Automated Teller Machine is a remote unit connected to the bank computer systems. The purpose of the system is to
- bring regular bank services closer to the customer and increase the working hours to around the clock. It is also
- important to decrease the amount of bank cashiers. An ATM withdrawal is less expensive for the Bank than a withdrawal
- from a teller.<br />
- <br />
- The ATM system requires that each bank customer has an ATM card and remembers his PIN code. The whole security of this
- system builds on the PIN code.
-</p>
-<h3>
- 3 Use-Case Diagram
-</h3>
-<p>
- The figure&nbsp;below shows the use-case diagram for the ATM.<br />
- <br />
- <img height="466" alt="ATM Use-Case Diagram" src="resources/atm_elab_uc_diagram.gif" width="564" />
-</p>
-<h3>
- 4 Actors
-</h3>
-<h4>
- 4.1 Bank Customer
-</h4>
-<p>
- This actor represents a person with a valid Bank Card. The Bank Card is theirs and they know the PIN Code.
-</p>
-<h4>
- 4.2 Cashier
-</h4>
-<p>
- From the ATM system point of view, the Cashier's only responsibility is to count the money in the security box to
- verify all deposits.
-</p>
-<h4>
- 4.3 Bank
-</h4>
-<p>
- This actor represents the financial institution that provides services to the ATM. Responsible for verifying Bank
- Customers, authorizing transactions and recording completed transactions.
-</p>
-<h4>
- 4.4 Maintenance Person
-</h4>
-<p>
- This actor represents the person responsible for maintaining the Automated Teller Machine, refilling paper, and
- replenishing cash.
-</p>
-<h3>
- 5 Use Cases
-</h3>
-<h5>
- 5.1.1 Validate User
-</h5>
-<p>
- This use case describes general behavior for the ATM to validate the Bank Customer. It includes all steps that are the
- same no matter what kind of transaction the Bank Customer does.
-</p>
-<h5>
- 5.1.2 Withdraw Cash
-</h5>
-<p>
- This use case describes how the Bank Customer uses the ATM to withdraw money his/her bank account.
-</p>
-<h5>
- 5.1.3 Transfer Funds
-</h5>
-<p>
- This use case describes how the Bank Customer uses the ATM to transfer money between different bank accounts.
-</p>
-<h5>
- 5.1.4 Deposit Funds
-</h5>
-<p>
- This use case describes how the Bank Customer deposits money to an account.
-</p>
-<h5>
- 5.1.5 Refill Machine
-</h5>
-<p>
- This use case describes how the Maintenance Person refills money, receipt paper and envelopes.
+ <mainDescription><h3>
+ 1 Introduction
+</h3>
+<p>
+ This is an example of a Use-Case Model as it would appear in Elaboration. Primary actors and use cases are identified,
+ and key scenarios (those that will be implemented first) are detailed. Each use case has an associated use-case
+ specification.
+</p>
+<h3>
+ 2 Overview
+</h3>
+<p>
+ The Automated Teller Machine is a remote unit connected to the bank computer systems. The purpose of the system is to
+ bring regular bank services closer to the customer and increase the working hours to around the clock. It is also
+ important to decrease the amount of bank cashiers. An ATM withdrawal is less expensive for the Bank than a withdrawal
+ from a teller.<br />
+ <br />
+ The ATM system requires that each bank customer has an ATM card and remembers his PIN code. The whole security of this
+ system builds on the PIN code.
+</p>
+<h3>
+ 3 Use-Case Diagram
+</h3>
+<p>
+ The figure&nbsp;below shows the use-case diagram for the ATM.<br />
+ <br />
+ <img height="466" alt="ATM Use-Case Diagram" src="resources/atm_elab_uc_diagram.gif" width="564" />
+</p>
+<h3>
+ 4 Actors
+</h3>
+<h4>
+ 4.1 Bank Customer
+</h4>
+<p>
+ This actor represents a person with a valid Bank Card. The Bank Card is theirs and they know the PIN Code.
+</p>
+<h4>
+ 4.2 Cashier
+</h4>
+<p>
+ From the ATM system point of view, the Cashier's only responsibility is to count the money in the security box to
+ verify all deposits.
+</p>
+<h4>
+ 4.3 Bank
+</h4>
+<p>
+ This actor represents the financial institution that provides services to the ATM. Responsible for verifying Bank
+ Customers, authorizing transactions and recording completed transactions.
+</p>
+<h4>
+ 4.4 Maintenance Person
+</h4>
+<p>
+ This actor represents the person responsible for maintaining the Automated Teller Machine, refilling paper, and
+ replenishing cash.
+</p>
+<h3>
+ 5 Use Cases
+</h3>
+<h5>
+ 5.1.1 Validate User
+</h5>
+<p>
+ This use case describes general behavior for the ATM to validate the Bank Customer. It includes all steps that are the
+ same no matter what kind of transaction the Bank Customer does.
+</p>
+<h5>
+ 5.1.2 Withdraw Cash
+</h5>
+<p>
+ This use case describes how the Bank Customer uses the ATM to withdraw money his/her bank account.
+</p>
+<h5>
+ 5.1.3 Transfer Funds
+</h5>
+<p>
+ This use case describes how the Bank Customer uses the ATM to transfer money between different bank accounts.
+</p>
+<h5>
+ 5.1.4 Deposit Funds
+</h5>
+<p>
+ This use case describes how the Bank Customer deposits money to an account.
+</p>
+<h5>
+ 5.1.5 Refill Machine
+</h5>
+<p>
+ This use case describes how the Maintenance Person refills money, receipt paper and envelopes.
</p></mainDescription>
</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/examples/uc_model_evolve.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/examples/uc_model_evolve.xmi
index b866417..b78bb73 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/examples/uc_model_evolve.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/examples/uc_model_evolve.xmi
@@ -1,97 +1,97 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:GuidanceDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-JviMIao63C7w9C8W6iPJrw" name="new_example,_t4QdAMNqEdu2IdAIaWZyAw" guid="-JviMIao63C7w9C8W6iPJrw" authors="Chris Sibbald" changeDate="2008-09-03T05:28:43.000-0700" version="7.2.0">
- <mainDescription><h1>
- Introduction
-</h1>
-<p>
- This example illustrates how the use-case model and associated use-case specification will evolve during the lifecycle.
- It shows the state of the use case model at two points in the lifecycle: early inception and towards the end of
- elaboration. The purpose is to illustrate how one would identify, outline and detail requirements so as to maximize
- stakeholder value and minimize risk early in the project, as well as to minimize re-work later.&nbsp;
-</p>
-<p>
- The example uses an Automated Teller Machine as the example system, because it is familiar to most people. This
- familiarity simplifies understanding the principles without getting lost in domain specific terminology.
-</p>
-<h2>
- Early inception
-</h2>
-<p>
- Assume you have just started on the project as the Analyst. You have identified the key stakeholders and met with them
- to discuss their needs. During your meetings, you identified a number of key actors, use cases, and supporting
- requirements for the ATM system. You captured the use cases and actors, with names and brief descriptions only, in the
- use-case model. An example of this work is given in the document <strong>ATM UC Model Inception</strong>.
-</p>
-<p>
- Prior to committing significant time to detailing these use cases now, you recognize that a "breadth before depth"
- approach can save you valuable time and permit you to identify the highest value and highest risk items so that you can
- concentrate on those first.
-</p>
-<p>
- You hold a brainstorming session with the stakeholders and outline the basic flow of each of the main use cases. As you
- are working through, you may identify some additional alternative flows. Fight the urge to "dive-in" to the details on
- these alternative flows at this point, simply list them and come back later when you have a better understanding of the
- "big picture".
-</p>
-<p>
- Examples of the notes you took during this exercise are attached (<strong>Withdraw Cash Outline</strong>,
- <strong>Deposit Funds Outline</strong> and <strong>Transfer</strong> <strong>Funds Outline</strong>).<br />
- <b>Note:</b> the choice of font is intentional to illustrate that these are notes, not formal documents.
-</p>
-<p>
- Reviewing your notes, you recognize that there is some behavior that is common to most of the use cases, namely the
- steps required to validate the Bank Customer. Factoring this behavior out into an &lt;&lt;included&gt;&gt; use case
- will simplify communications, iteration planning, and maintenance.
-</p>
-<p>
- You update the use case model accordingly: <strong>ATM UC Model Elaboration</strong>.
-</p>
-<h2>
- Elaboration
-</h2>
-<p>
- With a better understanding of the system, you can now prioritize your effort to maximize value and minimize risk. You
- start by detailing the common behavior captured in the use case: Validate User. This use case captures key
- architectural requirements that will exercise a significant portion of the system (communications with the Bank, card
- reader interface, and so on). Implementing this one key scenario will go a long way to reducing risk.
-</p>
-<p>
- An example of the Validate User use-case specification is attached: <strong>Use Case Spec - Validate User.</strong>
-</p>
-<p>
- Note that there may still be some un-answered questions, but that's OK. Capture these directly in the use-case
- specification and get them answered (see Section 5.6 of the <strong>Validate User UC Specification</strong>, for an
- example).
-</p>
-<p>
- Continuing with another architecturally significant thread, you detail the basic flow and some key alternative flows of
- the use case: Withdraw Cash. You know that if the team can implement this, much of the other functionality will be low
- risk.
-</p>
-<p>
- An example of the Withdraw Cash use-case specification is attached:&nbsp;<strong>Use Case Spec - Withdraw
- Cash</strong>.
-</p>
-<h1>
- Summary
-</h1>
-<p>
- By following a breadth before depth approach to outlining and detailing use cases, you can make better decisions on
- priorities. Start by identifying actors. Then for each actor, ask "What is the main purpose this actor would like to
- use the system?". This will lead to the identification of the use cases. Capture the actors and use cases in the
- use-case model along with a brief description.
-</p>
-<p>
- Prioritize the use cases, and then draft the main scenario or basic flow. As you are working through this you may
- identify alternate flows (what can go wrong, what options are available, and so on). Capture these, along with a brief
- description.
-</p>
-<p>
- Review the use-case model and reprioritize and assess risk. For the high priority (based on value to the stakeholders)
- or high risk use cases,&nbsp;detail the main scenario and the critical alternate flows.
-</p>
-<p>
- If you follow this approach, you will increase the likelihood of delivering value early, minimizing risk, and
- minimizing re-work.<br />
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ This example illustrates how the use-case model and associated use-case specification will evolve during the lifecycle.
+ It shows the state of the use case model at two points in the lifecycle: early inception and towards the end of
+ elaboration. The purpose is to illustrate how one would identify, outline and detail requirements so as to maximize
+ stakeholder value and minimize risk early in the project, as well as to minimize re-work later.&nbsp;
+</p>
+<p>
+ The example uses an Automated Teller Machine as the example system, because it is familiar to most people. This
+ familiarity simplifies understanding the principles without getting lost in domain specific terminology.
+</p>
+<h4>
+ Early inception
+</h4>
+<p>
+ Assume you have just started on the project as the Analyst. You have identified the key stakeholders and met with them
+ to discuss their needs. During your meetings, you identified a number of key actors, use cases, and supporting
+ requirements for the ATM system. You captured the use cases and actors, with names and brief descriptions only, in the
+ use-case model. An example of this work is given in the document <strong>ATM UC Model Inception</strong>.
+</p>
+<p>
+ Prior to committing significant time to detailing these use cases now, you recognize that a "breadth before depth"
+ approach can save you valuable time and permit you to identify the highest value and highest risk items so that you can
+ concentrate on those first.
+</p>
+<p>
+ You hold a brainstorming session with the stakeholders and outline the basic flow of each of the main use cases. As you
+ are working through, you may identify some additional alternative flows. Fight the urge to "dive-in" to the details on
+ these alternative flows at this point, simply list them and come back later when you have a better understanding of the
+ "big picture".
+</p>
+<p>
+ Examples of the notes you took during this exercise are attached (<strong>Withdraw Cash Outline</strong>,
+ <strong>Deposit Funds Outline</strong> and <strong>Transfer</strong> <strong>Funds Outline</strong>).<br />
+ <b>Note:</b> the choice of font is intentional to illustrate that these are notes, not formal documents.
+</p>
+<p>
+ Reviewing your notes, you recognize that there is some behavior that is common to most of the use cases, namely the
+ steps required to validate the Bank Customer. Factoring this behavior out into an &lt;&lt;included&gt;&gt; use case
+ will simplify communications, iteration planning, and maintenance.
+</p>
+<p>
+ You update the use case model accordingly: <strong>ATM UC Model Elaboration</strong>.
+</p>
+<h4>
+ Elaboration
+</h4>
+<p>
+ With a better understanding of the system, you can now prioritize your effort to maximize value and minimize risk. You
+ start by detailing the common behavior captured in the use case: Validate User. This use case captures key
+ architectural requirements that will exercise a significant portion of the system (communications with the Bank, card
+ reader interface, and so on). Implementing this one key scenario will go a long way to reducing risk.
+</p>
+<p>
+ An example of the Validate User use-case specification is attached: <strong>Use Case Spec - Validate User.</strong>
+</p>
+<p>
+ Note that there may still be some un-answered questions, but that's OK. Capture these directly in the use-case
+ specification and get them answered (see Section 5.6 of the <strong>Validate User UC Specification</strong>, for an
+ example).
+</p>
+<p>
+ Continuing with another architecturally significant thread, you detail the basic flow and some key alternative flows of
+ the use case: Withdraw Cash. You know that if the team can implement this, much of the other functionality will be low
+ risk.
+</p>
+<p>
+ An example of the Withdraw Cash use-case specification is attached:&nbsp;<strong>Use Case Spec - Withdraw
+ Cash</strong>.
+</p>
+<h3>
+ Summary
+</h3>
+<p>
+ By following a breadth before depth approach to outlining and detailing use cases, you can make better decisions on
+ priorities. Start by identifying actors. Then for each actor, ask "What is the main purpose this actor would like to
+ use the system?". This will lead to the identification of the use cases. Capture the actors and use cases in the
+ use-case model along with a brief description.
+</p>
+<p>
+ Prioritize the use cases, and then draft the main scenario or basic flow. As you are working through this you may
+ identify alternate flows (what can go wrong, what options are available, and so on). Capture these, along with a brief
+ description.
+</p>
+<p>
+ Review the use-case model and reprioritize and assess risk. For the high priority (based on value to the stakeholders)
+ or high risk use cases,&nbsp;detail the main scenario and the critical alternate flows.
+</p>
+<p>
+ If you follow this approach, you will increase the likelihood of delivering value early, minimizing risk, and
+ minimizing re-work.<br />
</p></mainDescription>
</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/examples/uc_model_inception_phase.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/examples/uc_model_inception_phase.xmi
index 283b2b4..15b95b2 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/examples/uc_model_inception_phase.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/examples/uc_model_inception_phase.xmi
@@ -1,81 +1,81 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:GuidanceDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-zmbyaoBRHeaLpd8RiE-lDA" name="new_example,_gbL6UIHOEd6NhZnUM27HMQ" guid="-zmbyaoBRHeaLpd8RiE-lDA" changeDate="2009-08-05T07:45:36.000-0700" version="7.5.0">
- <mainDescription><h3>
- 1 Introduction
-</h3>
-<p>
- This is an example of a Use-Case Model as it would appear in the Inception. Primary actors and use cases are
- identified. There may or may not be an outline of the basic flows yet.
-</p>
-<h3>
- 2 Overview
-</h3>
-<p>
- The Automated Teller Machine is a remote unit connected to the bank computer systems. The purpose of the system is to
- bring regular bank services closer to the customer and increase the working hours to around the clock. It is also
- important to decrease the amount of bank cashiers. An ATM withdrawal is less expensive for the Bank than a withdrawal
- from a teller.<br />
- <br />
- The ATM system requires that each bank customer has an ATM card and remembers his PIN code. The whole security of this
- system builds on the PIN code.
-</p>
-<h3>
- 3 Use-Case Diagram
-</h3>
-<p>
- The figure&nbsp;below shows the use-case diagram for the ATM.<br />
- <br />
- <img height="435" alt="Automated Teller Machine Elaboration Use-Case Diagram"
- src="resources/atm_incept_uc_diagram.gif" width="540" /><br />
-</p>
-<h3>
- 4 Actors
-</h3>
-<h4>
- 4.1 Bank Customer
-</h4>
-<p>
- This actor represents a person with a valid Bank Card. The Bank Card is theirs and they know the PIN Code.
-</p>
-<h4>
- 4.2 Bank
-</h4>
-<p>
- This actor represents the financial institution that provides services to the ATM. Responsible for verifying Bank
- Customers, authorizing transactions and recording completed transactions.
-</p>
-<h4>
- 4.3 Maintenance Person
-</h4>
-<p>
- This actor represents the person responsible for maintaining the Automated Teller Machine, refilling paper, and
- replenishing cash.
-</p>
-<h3>
- 5 Use Cases
-</h3>
-<h5>
- 5.1.1 Withdraw Cash
-</h5>
-<p>
- This use case describes how the Bank Customer uses the ATM to withdraw money his/her bank account.
-</p>
-<h5>
- 5.1.2 Transfer Funds
-</h5>
-<p>
- This use case describes how the Bank Customer uses the ATM to transfer money between different bank accounts.
-</p>
-<h5>
- 5.1.3 Deposit Funds
-</h5>
-<p>
- This use case describes how the Bank Customer deposits money to an account.
-</p>
-<h5>
- 5.1.4 Refill Machine
-</h5>
-<p>
- This use case describes how the Maintenance Person refills money, receipt paper and envelopes.
+ <mainDescription><h3>
+ 1 Introduction
+</h3>
+<p>
+ This is an example of a Use-Case Model as it would appear in the Inception. Primary actors and use cases are
+ identified. There may or may not be an outline of the basic flows yet.
+</p>
+<h3>
+ 2 Overview
+</h3>
+<p>
+ The Automated Teller Machine is a remote unit connected to the bank computer systems. The purpose of the system is to
+ bring regular bank services closer to the customer and increase the working hours to around the clock. It is also
+ important to decrease the amount of bank cashiers. An ATM withdrawal is less expensive for the Bank than a withdrawal
+ from a teller.<br />
+ <br />
+ The ATM system requires that each bank customer has an ATM card and remembers his PIN code. The whole security of this
+ system builds on the PIN code.
+</p>
+<h3>
+ 3 Use-Case Diagram
+</h3>
+<p>
+ The figure&nbsp;below shows the use-case diagram for the ATM.<br />
+ <br />
+ <img height="435" alt="Automated Teller Machine Elaboration Use-Case Diagram" src="resources/atm_incept_uc_diagram.gif"
+ width="540" /><br />
+</p>
+<h3>
+ 4 Actors
+</h3>
+<h4>
+ 4.1 Bank Customer
+</h4>
+<p>
+ This actor represents a person with a valid Bank Card. The Bank Card is theirs and they know the PIN Code.
+</p>
+<h4>
+ 4.2 Bank
+</h4>
+<p>
+ This actor represents the financial institution that provides services to the ATM. Responsible for verifying Bank
+ Customers, authorizing transactions and recording completed transactions.
+</p>
+<h4>
+ 4.3 Maintenance Person
+</h4>
+<p>
+ This actor represents the person responsible for maintaining the Automated Teller Machine, refilling paper, and
+ replenishing cash.
+</p>
+<h3>
+ 5 Use Cases
+</h3>
+<h5>
+ 5.1.1 Withdraw Cash
+</h5>
+<p>
+ This use case describes how the Bank Customer uses the ATM to withdraw money his/her bank account.
+</p>
+<h5>
+ 5.1.2 Transfer Funds
+</h5>
+<p>
+ This use case describes how the Bank Customer uses the ATM to transfer money between different bank accounts.
+</p>
+<h5>
+ 5.1.3 Deposit Funds
+</h5>
+<p>
+ This use case describes how the Bank Customer deposits money to an account.
+</p>
+<h5>
+ 5.1.4 Refill Machine
+</h5>
+<p>
+ This use case describes how the Maintenance Person refills money, receipt paper and envelopes.
</p></mainDescription>
</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/examples/uc_spec_validate_user.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/examples/uc_spec_validate_user.xmi
index 4974573..5fc598a 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/examples/uc_spec_validate_user.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/examples/uc_spec_validate_user.xmi
@@ -1,178 +1,178 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:GuidanceDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-BYG2r_TAmU4OL3BapLIU1A" name="new_example,_BkKmAIHSEd6NhZnUM27HMQ" guid="-BYG2r_TAmU4OL3BapLIU1A" changeDate="2010-08-30T11:44:21.000-0700" version="7.5.0">
- <mainDescription><h3>
- 1 Brief Description
-</h3>
-<p>
- This use case describes general behavior for the ATM to validate the user. It includes all steps that are the same no
- matter what kind of transaction the Bank Customer does.
-</p>
-<h3>
- 2 Actors
-</h3>
-<h4>
- 2.1 Bank Customer
-</h4>
-<h4>
- 2.2 Bank
-</h4>
-<h3>
- 3 Preconditions
-</h3>
-<p>
- There is an active network connection to the Bank.
-</p>
-<h3>
- 4 Basic Flow of Events
-</h3>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <p>
- 1. The use case begins when the Bank Customer inserts their Bank Card.
- </p>
- <p>
- 2. The ATM reads the code from the magnetic strip of the Bank Card and checks with the Bank to see if it is an
- acceptable Bank Card. The Bank confirms the card is valid.
- </p>
- <p>
- 3. The ATM asks for the customer PIN code (4 digits).
- </p>
- <p>
- 4. The Bank Customer enters a PIN.
- </p>
- <p>
- 5. The ATM validates the PIN with the Bank. The Bank confirms the PIN is valid.
- </p>
- <p>
- 6. The ATM displays the different alternatives that are available on this unit.
- </p>
- <p>
- 7. The use case ends. (The flow continues according to the flow of the specific transaction).
- </p>
-</blockquote>
-<h3>
- 5 Alternative Flows
-</h3>
-<h4>
- 5.1 Not a valid card
-</h4>
-<p>
- If in step 2 of the basic flow the card is invalid, then
-</p>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <p>
- 1. The ATM shall display a "sorry not a valid card" message and return the card.
- </p>
- <p>
- 2. The use case ends with an indication of the failure.
- </p>
-</blockquote>
-<h4>
- 5.2 Wrong PIN (1st and 2nd time)
-</h4>
-<p>
- If in step 5 of the basic flow the PIN is invalid, then
-</p>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <p>
- 1. The ATM shall display a "sorry invalid PIN" message.
- </p>
- <p>
- 2. The use case resumes at step 3.
- </p>
-</blockquote>
-<h4>
- 5.3 Wrong PIN (third time)
-</h4>
-<p>
- If in step 5 of the basic flow an incorrect PIN is entered for the third time, then
-</p>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <p>
- 1. The ATM shall display a "sorry invalid PIN – Please contact your branch" message.
- </p>
- <p>
- 2. The card is kept by the ATM and a receipt is printed telling how and where to get a new card.
- </p>
- <p>
- 3. The use case ends with an indication of the failure.
- </p>
-</blockquote>
-<h4>
- 5.4 No Response from Bank
-</h4>
-<p>
- If in steps 2 or 5 of the basic flow there is no response from the Bank within 3 seconds, then
-</p>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <p>
- 1. The ATM will re-try, up to three times.
- </p>
- <p>
- 2. If there is still no response from the Bank, the ATM shall display the message "Network unavailable – try again
- later".
- </p>
- <p>
- 3. The ATM shall return the card.
- </p>
- <p>
- 4. The ATM shall indicate that it is "Closed".
- </p>
- <p>
- 5. The use case ends with an indication of the failure.
- </p>
-</blockquote>
-<h4>
- 5.5 No Response from Bank Customer
-</h4>
-<p>
- If in step 4 of the basic flow there is no response from the Bank Customer within 15 seconds, then
-</p>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <p>
- 1. The ATM shall issue a warning sound and display the message "Please enter PIN".<br />
- <br />
- 2. If there is still no response from the Bank Customer within 15 seconds the ATM will store the card internally.
- </p>
- <p>
- 3. The use case ends with an indication of the failure.
- </p>
-</blockquote>
-<h4>
- 5.6 Stolen Card
-</h4>
-<p>
- If in step 2, the Bank indicates that this is a stolen card, then
-</p>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <p>
- 1. What shall we do? Take a picture of the user? Notify the police?
- </p>
-</blockquote>
-<p>
- [This is a typical way to use Use Cases. You can write your questions right down in the text and when you get your
- answers you'll have to correct it. Another way to do it: is to assume one way either they like it or they tell you
- how it should be]
-</p>
-<h3>
- 6 Post-conditions
-</h3>
-<h4>
- 6.1 Successful Completion
-</h4>
-<p>
- If the use case ends in success, the user is validated and may continue with the specific transaction.
-</p>
-<h4>
- 6.2 Failure Condition
-</h4>
-<p>
- If there is a failure to validate the user, the ATM shall log the event including the reason for the failure.
-</p>
-<h3>
- 7 Special Requirements
-</h3>
-<p>
- [SpReq:VU-1] The ATM shall keep a log, including date and time, of all complete and incomplete transactions with the
- Bank.
+ <mainDescription><h3>
+ 1 Brief Description
+</h3>
+<p>
+ This use case describes general behavior for the ATM to validate the user. It includes all steps that are the same no
+ matter what kind of transaction the Bank Customer does.
+</p>
+<h3>
+ 2 Actors
+</h3>
+<h4>
+ 2.1 Bank Customer
+</h4>
+<h4>
+ 2.2 Bank
+</h4>
+<h3>
+ 3 Preconditions
+</h3>
+<p>
+ There is an active network connection to the Bank.
+</p>
+<h3>
+ 4 Basic Flow of Events
+</h3>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ 1. The use case begins when the Bank Customer inserts their Bank Card.
+ </p>
+ <p>
+ 2. The ATM reads the code from the magnetic strip of the Bank Card and checks with the Bank to see if it is an
+ acceptable Bank Card. The Bank confirms the card is valid.
+ </p>
+ <p>
+ 3. The ATM asks for the customer PIN code (4 digits).
+ </p>
+ <p>
+ 4. The Bank Customer enters a PIN.
+ </p>
+ <p>
+ 5. The ATM validates the PIN with the Bank. The Bank confirms the PIN is valid.
+ </p>
+ <p>
+ 6. The ATM displays the different alternatives that are available on this unit.
+ </p>
+ <p>
+ 7. The use case ends. (The flow continues according to the flow of the specific transaction).
+ </p>
+</blockquote>
+<h3>
+ 5 Alternative Flows
+</h3>
+<h4>
+ 5.1 Not a valid card
+</h4>
+<p>
+ If in step 2 of the basic flow the card is invalid, then
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ 1. The ATM shall display a "sorry not a valid card" message and return the card.
+ </p>
+ <p>
+ 2. The use case ends with an indication of the failure.
+ </p>
+</blockquote>
+<h4>
+ 5.2 Wrong PIN (1st and 2nd time)
+</h4>
+<p>
+ If in step 5 of the basic flow the PIN is invalid, then
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ 1. The ATM shall display a "sorry invalid PIN" message.
+ </p>
+ <p>
+ 2. The use case resumes at step 3.
+ </p>
+</blockquote>
+<h4>
+ 5.3 Wrong PIN (third time)
+</h4>
+<p>
+ If in step 5 of the basic flow an incorrect PIN is entered for the third time, then
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ 1. The ATM shall display a "sorry invalid PIN – Please contact your branch" message.
+ </p>
+ <p>
+ 2. The card is kept by the ATM and a receipt is printed telling how and where to get a new card.
+ </p>
+ <p>
+ 3. The use case ends with an indication of the failure.
+ </p>
+</blockquote>
+<h4>
+ 5.4 No Response from Bank
+</h4>
+<p>
+ If in steps 2 or 5 of the basic flow there is no response from the Bank within 3 seconds, then
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ 1. The ATM will re-try, up to three times.
+ </p>
+ <p>
+ 2. If there is still no response from the Bank, the ATM shall display the message "Network unavailable – try again
+ later".
+ </p>
+ <p>
+ 3. The ATM shall return the card.
+ </p>
+ <p>
+ 4. The ATM shall indicate that it is "Closed".
+ </p>
+ <p>
+ 5. The use case ends with an indication of the failure.
+ </p>
+</blockquote>
+<h4>
+ 5.5 No Response from Bank Customer
+</h4>
+<p>
+ If in step 4 of the basic flow there is no response from the Bank Customer within 15 seconds, then
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ 1. The ATM shall issue a warning sound and display the message "Please enter PIN".<br />
+ <br />
+ 2. If there is still no response from the Bank Customer within 15 seconds the ATM will store the card internally.
+ </p>
+ <p>
+ 3. The use case ends with an indication of the failure.
+ </p>
+</blockquote>
+<h4>
+ 5.6 Stolen Card
+</h4>
+<p>
+ If in step 2, the Bank indicates that this is a stolen card, then
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ 1. What shall we do? Take a picture of the user? Notify the police?
+ </p>
+</blockquote>
+<p>
+ [This is a typical way to use Use Cases. You can write your questions right down in the text and when you get your
+ answers you'll have to correct it. Another way to do it: is to assume one way either they like it or they tell you
+ how it should be]
+</p>
+<h3>
+ 6 Post-conditions
+</h3>
+<h4>
+ 6.1 Successful Completion
+</h4>
+<p>
+ If the use case ends in success, the user is validated and may continue with the specific transaction.
+</p>
+<h4>
+ 6.2 Failure Condition
+</h4>
+<p>
+ If there is a failure to validate the user, the ATM shall log the event including the reason for the failure.
+</p>
+<h3>
+ 7 Special Requirements
+</h3>
+<p>
+ [SpReq:VU-1] The ATM shall keep a log, including date and time, of all complete and incomplete transactions with the
+ Bank.
</p></mainDescription>
</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/examples/uc_transfer_funds_outline.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/examples/uc_transfer_funds_outline.xmi
index 9deb7f1..acf07fa 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/examples/uc_transfer_funds_outline.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/examples/uc_transfer_funds_outline.xmi
@@ -1,51 +1,51 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:GuidanceDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-iVXniR1KNrwul19oCHSvMQ" name="new_example,_nwykAIHQEd6NhZnUM27HMQ" guid="-iVXniR1KNrwul19oCHSvMQ" changeDate="2009-08-05T08:02:14.000-0700" version="7.5.0">
- <mainDescription><h3>
- Step-by-step outline
-</h3>
-<ol>
- <li>
- Insert card
- </li>
- <li>
- Enter PIN
- </li>
- <li>
- Select transfer
- </li>
- <li>
- Select amount
- </li>
- <li>
- Select from account
- </li>
- <li>
- Select to account
- </li>
- <li>
- Send transaction
- </li>
- <li>
- Receive confirmation
- </li>
- <li>
- Print receipt
- </li>
- <li>
- Eject card
- </li>
-</ol>
-<h3>
- List of Alternative flows
-</h3>
-<p dir="ltr" style="MARGIN-RIGHT: 0px">
- A1 Wrong PIN<br />
- A2 No money<br />
- A3 From account does not exists<br />
- A4 To account does not exists<br />
- A5 No confirmation<br />
- A6 Card stuck<br />
- A7 Out of paper<br />
- A8 Card stuck
+ <mainDescription><h3>
+ Step-by-step outline
+</h3>
+<ol>
+ <li>
+ Insert card
+ </li>
+ <li>
+ Enter PIN
+ </li>
+ <li>
+ Select transfer
+ </li>
+ <li>
+ Select amount
+ </li>
+ <li>
+ Select from account
+ </li>
+ <li>
+ Select to account
+ </li>
+ <li>
+ Send transaction
+ </li>
+ <li>
+ Receive confirmation
+ </li>
+ <li>
+ Print receipt
+ </li>
+ <li>
+ Eject card
+ </li>
+</ol>
+<h3>
+ List of Alternative flows
+</h3>
+<p dir="ltr" style="MARGIN-RIGHT: 0px">
+ A1 Wrong PIN<br />
+ A2 No money<br />
+ A3 From account does not exists<br />
+ A4 To account does not exists<br />
+ A5 No confirmation<br />
+ A6 Card stuck<br />
+ A7 Out of paper<br />
+ A8 Card stuck
</p></mainDescription>
</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/examples/uc_withdraw_cash_outline.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/examples/uc_withdraw_cash_outline.xmi
index f0af727..86cf56b 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/examples/uc_withdraw_cash_outline.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/examples/uc_withdraw_cash_outline.xmi
@@ -1,60 +1,60 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:GuidanceDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-xHyqz01D_uL6xXLgQUG7Tw" name="new_example,_7MzegIHVEd6NhZnUM27HMQ" guid="-xHyqz01D_uL6xXLgQUG7Tw" changeDate="2009-08-05T08:39:32.000-0700" version="7.5.0">
- <mainDescription><h3>
- Step-by-step outline
-</h3>
-<ol>
- <li>
- Insert Card
- </li>
- <li>
- Validate card
- </li>
- <li>
- Enter pin
- </li>
- <li>
- Select withdraw
- </li>
- <li>
- Select account
- </li>
- <li>
- Select amount
- </li>
- <li>
- Send transaction
- </li>
- <li>
- Receive ok
- </li>
- <li>
- Dispense money
- </li>
- <li>
- Print receipt
- </li>
- <li>
- Eject card
- </li>
-</ol>
-<h3>
- List of Alternative flows
-</h3>
-<p dir="ltr" style="MARGIN-RIGHT: 0px">
- A1 Wrong PIN<br />
- A2 No money<br />
- A3 Attempt to withdraw more than daily amount<br />
- A4 No contact<br />
- A5 Link goes down <br />
- &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; i)&nbsp; If the link goes down before the transaction reaches the actual account. Not
- a big&nbsp;problem.<br />
- &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ii)&nbsp; If the transaction reaches the account and then the link is down. The money is
- withdrawn but never dispensed! Do we&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; need some kind of two- phase-
- commit?<br />
- A6 Stolen card<br />
- A7 Out of money<br />
- <br />
- <br />
+ <mainDescription><h3>
+ Step-by-step outline
+</h3>
+<ol>
+ <li>
+ Insert Card
+ </li>
+ <li>
+ Validate card
+ </li>
+ <li>
+ Enter pin
+ </li>
+ <li>
+ Select withdraw
+ </li>
+ <li>
+ Select account
+ </li>
+ <li>
+ Select amount
+ </li>
+ <li>
+ Send transaction
+ </li>
+ <li>
+ Receive ok
+ </li>
+ <li>
+ Dispense money
+ </li>
+ <li>
+ Print receipt
+ </li>
+ <li>
+ Eject card
+ </li>
+</ol>
+<h3>
+ List of Alternative flows
+</h3>
+<p dir="ltr" style="MARGIN-RIGHT: 0px">
+ A1 Wrong PIN<br />
+ A2 No money<br />
+ A3 Attempt to withdraw more than daily amount<br />
+ A4 No contact<br />
+ A5 Link goes down <br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; i)&nbsp; If the link goes down before the transaction reaches the actual account. Not
+ a big&nbsp;problem.<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ii)&nbsp; If the transaction reaches the account and then the link is down. The money is
+ withdrawn but never dispensed! Do we&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; need some kind of two- phase-
+ commit?<br />
+ A6 Stolen card<br />
+ A7 Out of money<br />
+ <br />
+ <br />
</p></mainDescription>
</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/examples/use_case_spec.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/examples/use_case_spec.xmi
index f107f3f..50b8988 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/examples/use_case_spec.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/examples/use_case_spec.xmi
@@ -1,247 +1,247 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:GuidanceDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-qq-9Brh5oa6H3lsdp-m8mQ" name=",_JLOiIMNvEdu2IdAIaWZyAw" guid="-qq-9Brh5oa6H3lsdp-m8mQ" changeDate="2009-08-05T09:49:49.000-0700" version="7.2.0">
- <mainDescription><h3>
- 1 Brief Description
-</h3>
-<p>
- This use case describes how the Bank Customer uses the ATM to withdraw money to his/her bank account.
-</p>
-<h3>
- 2 Actors
-</h3>
-<h4>
- 2.1 Bank Customer
-</h4>
-<h4>
- 2.2 Bank
-</h4>
-<h3>
- 3 Preconditions
-</h3>
-<p>
- There is an active network connection to the Bank.<br />
- <br />
- The ATM has cash available.
-</p>
-<h3>
- 4 Basic Flow of Events
-</h3>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <p>
- 1. The use case begins when Bank Customer inserts their Bank Card.
- </p>
- <p>
- 2. Use Case: Validate User is performed.
- </p>
- <p>
- 3. The ATM displays the different alternatives that are available on this unit. [See Supporting Requirement SR-xxx
- for list of alternatives]. In this case the Bank Customer always selects "Withdraw Cash".
- </p>
- <p>
- 4. The ATM prompts for an account. See Supporting Requirement SR-yyy for account types that shall be supported.
- </p>
- <p>
- 5. The Bank Customer selects an account.
- </p>
- <p>
- 6. The ATM prompts for an amount.
- </p>
- <p>
- 7. The Bank Customer enters an amount.
- </p>
- <p>
- 8. Card ID, PIN, amount and account is sent to Bank as a transaction. The Bank Consortium replies with a go/no go
- reply telling if the transaction is ok.
- </p>
- <p>
- 9. Then money is dispensed.
- </p>
- <p>
- 10. The Bank Card is returned.
- </p>
- <p>
- 11. The receipt is printed.
- </p>
- <p>
- 12. The use case ends successfully.
- </p>
-</blockquote>
-<h3>
- 5 Alternative Flows
-</h3>
-<h4>
- 5.1 Invalid User
-</h4>
-<p>
- If in step 2 of the basic flow Bank Customer the use case: Validate User does not complete successfully, then
-</p>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <p>
- 1. The use case ends with a failure condition
- </p>
-</blockquote>
-<h4>
- 5.2 Wrong account
-</h4>
-<p>
- If in step 8 of the basic flow the account selected by the Bank Customer is not associated with this bank card, then
-</p>
-<p>
- 1. The ATM shall display the message "Invalid Account – please try again".
-</p>
-<p>
- 2. The use case resumes at step 4.
-</p>
-<h4>
- 5.3 Wrong amount
-</h4>
-<p>
- If in step 7 in the basic flow, the Bank Customer enters an amount that can't be 'created' with the kind of in the ATM
- (See Special Requirement WC-1 for valid amounts), then
-</p>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <p>
- 1. The ATM shall display a the message indicating that the amount must be a multiple of the bills on hand, and ask
- the Bank Customer to reenter the amount.
- </p>
- <p>
- 2. The use case resumes at step 7.
- </p>
-</blockquote>
-<h4>
- 5.4 Amount Exceeds Withdrawal Limit
-</h4>
-<p>
- If in step 7 in the basic flow, the Bank Customer enters an amount that exceeds the withdrawal limit (See Special
- Requirement WC-2 for maximum amount), then
-</p>
-<p>
- 1. the ATM shall display a warning message, and ask the Bank Customer to reenter the amount
-</p>
-<p>
- 2. The use case resumes at step 7
-</p>
-<h4>
- 5.5 Amount Exceeds Daily Withdrawal Limit
-</h4>
-<p>
- If in step 8 in the basic flow, the Bank response indicates the daily withdrawal limit has been exceeded (this is
- determined by the Bank and depends upon the specific account), then
-</p>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <p>
- 1. The ATM shall display a warning message, and ask the Bank Customer to reenter the amount.
- </p>
- <p>
- 2. The use case resumes at step 7.
- </p>
-</blockquote>
-<h4>
- 5.6 Insufficient Cash
-</h4>
-<p>
- If in step 7 in the basic flow, the Bank Customer enters an amount that exceeds the amount of cash available in the
- ATM, then
-</p>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <p>
- 1. The ATM will display a warning message, and ask the Bank Customer to reenter the amount.
- </p>
- <p>
- 2. The use case resumes at step 7.
- </p>
-</blockquote>
-<h4>
- 5.7 No Response from Bank
-</h4>
-<p>
- If in step 8 of the basic there is no response from the Bank within 3 seconds, then
-</p>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <p>
- 1. The ATM will re-try, up to three times.
- </p>
- <p>
- 2. If there is still no response from the Bank, the ATM shall display the message "Network unavailable – try again
- later".
- </p>
- <p>
- 3. The ATM shall return the card.
- </p>
- <p>
- 4. The ATM shall indicate that it is "Closed".
- </p>
- <p>
- 5. The use case ends with a failure condition.
- </p>
-</blockquote>
-<h4>
- 5.8 Money Not Removed
-</h4>
-<p>
- If in step 9 of the basic flow the money is not removed from the machine within 15 seconds, then
-</p>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <p>
- 1. the ATM shall issue a warning sound and display the message "Please remove cash".
- </p>
- <p>
- 2. If there is still no response from the Bank Customer within 15 seconds the ATM will re-tract the money and note
- the failure in the log.
- </p>
- <p>
- 3. the use case end with a failure condition.
- </p>
-</blockquote>
-<h4>
- 5.9 Quit
-</h4>
-<p>
- If at point prior to step 8 in the basic flow the Bank Customer selects Quit, then
-</p>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <p>
- 1. The ATM shall print a receipt indicating the transaction was cancelled.
- </p>
- <p>
- 2. The ATM shall return the card.
- </p>
- <p>
- 3. The use case ends.
- </p>
-</blockquote>
-<h3>
- 6 Key Scenarios
-</h3>
-<h4>
- 6.1 No Response from Bank
-</h4>
-<h3>
- 7 Post-conditions
-</h3>
-<h4>
- 7.1 Successful Completion
-</h4>
-<p>
- The user has received their cash and the internal logs have been updated.
-</p>
-<h4>
- 7.2 Failure Condition
-</h4>
-<p>
- The logs have been updated accordingly.
-</p>
-<h3>
- 8 Special Requirements
-</h3>
-<p>
- [SpReq:WC-1] The ATM shall dispense cash in multiples of $20.
-</p>
-<p>
- [SpReq2:WC-2] The maximum individual withdrawal is $500.
-</p>
-<p>
- [SpReq:WC-1] The ATM shall keep a log, including date and time, of all complete and incomplete transactions with the
- Bank.
+ <mainDescription><h3>
+ 1 Brief Description
+</h3>
+<p>
+ This use case describes how the Bank Customer uses the ATM to withdraw money to his/her bank account.
+</p>
+<h3>
+ 2 Actors
+</h3>
+<h4>
+ 2.1 Bank Customer
+</h4>
+<h4>
+ 2.2 Bank
+</h4>
+<h3>
+ 3 Preconditions
+</h3>
+<p>
+ There is an active network connection to the Bank.<br />
+ <br />
+ The ATM has cash available.
+</p>
+<h3>
+ 4 Basic Flow of Events
+</h3>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ 1. The use case begins when Bank Customer inserts their Bank Card.
+ </p>
+ <p>
+ 2. Use Case: Validate User is performed.
+ </p>
+ <p>
+ 3. The ATM displays the different alternatives that are available on this unit. [See Supporting Requirement SR-xxx
+ for list of alternatives]. In this case the Bank Customer always selects "Withdraw Cash".
+ </p>
+ <p>
+ 4. The ATM prompts for an account. See Supporting Requirement SR-yyy for account types that shall be supported.
+ </p>
+ <p>
+ 5. The Bank Customer selects an account.
+ </p>
+ <p>
+ 6. The ATM prompts for an amount.
+ </p>
+ <p>
+ 7. The Bank Customer enters an amount.
+ </p>
+ <p>
+ 8. Card ID, PIN, amount and account is sent to Bank as a transaction. The Bank Consortium replies with a go/no go
+ reply telling if the transaction is ok.
+ </p>
+ <p>
+ 9. Then money is dispensed.
+ </p>
+ <p>
+ 10. The Bank Card is returned.
+ </p>
+ <p>
+ 11. The receipt is printed.
+ </p>
+ <p>
+ 12. The use case ends successfully.
+ </p>
+</blockquote>
+<h3>
+ 5 Alternative Flows
+</h3>
+<h4>
+ 5.1 Invalid User
+</h4>
+<p>
+ If in step 2 of the basic flow Bank Customer the use case: Validate User does not complete this successfully, then
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ 1. The use case ends with a failure condition.
+ </p>
+</blockquote>
+<h4>
+ 5.2 Wrong account
+</h4>
+<p>
+ If in step 8 of the basic flow the account selected by the Bank Customer is not associated with this bank card, then
+</p>
+<p>
+ 1. The ATM shall display the message "Invalid Account – please try again".
+</p>
+<p>
+ 2. The use case resumes at step 4.
+</p>
+<h4>
+ 5.3 Wrong amount
+</h4>
+<p>
+ If in step 7 in the basic flow, the Bank Customer enters an amount that can't be 'created' with the kind of in the ATM
+ (See Special Requirement WC-1 for valid amounts), then
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ 1. The ATM shall display a the message indicating that the amount must be a multiple of the bills on hand, and ask
+ the Bank Customer to reenter the amount.
+ </p>
+ <p>
+ 2. The use case resumes at step 7.
+ </p>
+</blockquote>
+<h4>
+ 5.4 Amount Exceeds Withdrawal Limit
+</h4>
+<p>
+ If in step 7 in the basic flow, the Bank Customer enters an amount that exceeds the withdrawal limit (See Special
+ Requirement WC-2 for maximum amount), then
+</p>
+<p>
+ 1. the ATM shall display a warning message, and ask the Bank Customer to reenter the amount
+</p>
+<p>
+ 2. The use case resumes at step 7
+</p>
+<h4>
+ 5.5 Amount Exceeds Daily Withdrawal Limit
+</h4>
+<p>
+ If in step 8 in the basic flow, the Bank response indicates the daily withdrawal limit has been exceeded (this is
+ determined by the Bank and depends upon the specific account), then
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ 1. The ATM shall display a warning message, and ask the Bank Customer to reenter the amount.
+ </p>
+ <p>
+ 2. The use case resumes at step 7.
+ </p>
+</blockquote>
+<h4>
+ 5.6 Insufficient Cash
+</h4>
+<p>
+ If in step 7 in the basic flow, the Bank Customer enters an amount that exceeds the amount of cash available in the
+ ATM, then
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ 1. The ATM will display a warning message, and ask the Bank Customer to reenter the amount.
+ </p>
+ <p>
+ 2. The use case resumes at step 7.
+ </p>
+</blockquote>
+<h4>
+ 5.7 No Response from Bank
+</h4>
+<p>
+ If in step 8 of the basic there is no response from the Bank within 3 seconds, then
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ 1. The ATM will re-try, up to three times.
+ </p>
+ <p>
+ 2. If there is still no response from the Bank, the ATM shall display the message "Network unavailable – try again
+ later".
+ </p>
+ <p>
+ 3. The ATM shall return the card.
+ </p>
+ <p>
+ 4. The ATM shall indicate that it is "Closed".
+ </p>
+ <p>
+ 5. The use case ends with a failure condition.
+ </p>
+</blockquote>
+<h4>
+ 5.8 Money Not Removed
+</h4>
+<p>
+ If in step 9 of the basic flow the money is not removed from the machine within 15 seconds, then
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ 1. the ATM shall issue a warning sound and display the message "Please remove cash".
+ </p>
+ <p>
+ 2. If there is still no response from the Bank Customer within 15 seconds the ATM will re-tract the money and note
+ the failure in the log.
+ </p>
+ <p>
+ 3. the use case end with a failure condition.
+ </p>
+</blockquote>
+<h4>
+ 5.9 Quit
+</h4>
+<p>
+ If at point prior to step 8 in the basic flow the Bank Customer selects Quit, then
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ 1. The ATM shall print a receipt indicating the transaction was cancelled.
+ </p>
+ <p>
+ 2. The ATM shall return the card.
+ </p>
+ <p>
+ 3. The use case ends.
+ </p>
+</blockquote>
+<h3>
+ 6 Key Scenarios
+</h3>
+<h4>
+ 6.1 No Response from Bank
+</h4>
+<h3>
+ 7 Post-conditions
+</h3>
+<h4>
+ 7.1 Successful Completion
+</h4>
+<p>
+ The user has received their cash and the internal logs have been updated.
+</p>
+<h4>
+ 7.2 Failure Condition
+</h4>
+<p>
+ The logs have been updated accordingly.
+</p>
+<h3>
+ 8 Special Requirements
+</h3>
+<p>
+ [SpReq:WC-1] The ATM shall dispense cash in multiples of $20.
+</p>
+<p>
+ [SpReq2:WC-2] The maximum individual withdrawal is $500.
+</p>
+<p>
+ [SpReq:WC-1] The ATM shall keep a log, including date and time, of all complete and incomplete transactions with the
+ Bank.
</p></mainDescription>
</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/abstract_away_complexity.vm.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/abstract_away_complexity.vm.xmi
index 3a9dd90..4c88aea 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/abstract_away_complexity.vm.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/abstract_away_complexity.vm.xmi
@@ -1,14 +1,16 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-OcMsciNn-UtD9fTHj26LGA" name="new_guideline,_34jWsLcIEduRNaXpzCOLXQ" guid="-OcMsciNn-UtD9fTHj26LGA" changeDate="2008-02-14T05:04:57.000-0800" version="1.0.0">
- <mainDescription><h3>
- Model key perspectives
-</h3>
-<p>
- Modeling helps raise the level of abstraction because you simplify complex ideas and represent them visually, as
- illustrations. Good models can convey information that helps the team visualize, specify, construct, and document
- software.
-</p>
-<p>
- For more information, see <a class="elementLinkWithType" href="./../../../core.tech.common.extend_supp/guidances/guidelines/using_visual_modeling_DA1CA6E4.html" guid="_0SsecNr8EdyXE6np2_hUMA">Guideline: Using Visual Modeling</a>.
+ <mainDescription><h3>
+ Model key perspectives
+</h3>
+<p>
+ Modeling helps raise the level of abstraction because you simplify complex ideas and represent them visually, as
+ illustrations. Good models can convey information that helps the team visualize, specify, construct, and document
+ software.
+</p>
+<p>
+ For more information, see <a class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/guidelines/using_visual_modeling_DA1CA6E4.html"
+ guid="_0SsecNr8EdyXE6np2_hUMA">Guideline: Using Visual Modeling</a>.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/abstract_away_complexity.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/abstract_away_complexity.xmi
index 7430ea3..4ae9cab 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/abstract_away_complexity.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/abstract_away_complexity.xmi
@@ -1,49 +1,55 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-X7QSjItNBz7w8603yBCv0Q" name="abstract_away_complexity,_we3F4ACpEdu8m4dIntu6jA" guid="-X7QSjItNBz7w8603yBCv0Q" changeDate="2008-08-12T04:36:49.000-0700" version="1.0.0">
- <mainDescription><p>
- Software&nbsp;development is a pursuit characterized by complexity. This can take many forms, such as accommodating
- complex requirements, technology, or team dynamics. Elevating the level of abstraction helps you manage this complexity
- and make measurable progress, despite the inherent difficulty of the task.
-</p>
-<p>
- Suggestions for several strategies that help abstract away complexity follow.
-</p>
-<h3>
- Leverage patterns
-</h3>
-<p>
- Patterns help you take advantage of proven techniques for solving common problems. You can benefit from the experience
- of seasoned practitioners and avoid "re-inventing the wheel," as the saying goes. The use of patterns is a crucial
- aspect of an architecture-centric approach to development, because it helps reduce the novelty and diversity of a
- solution, thus improves quality.
-</p>
-<p>
- See <a class="elementLinkWithType" href="./../../../core.tech.common.extend_supp/guidances/concepts/pattern_10BE6D96.html" guid="_0YJvUMlgEdmt3adZL5Dmdw">Concept: Pattern</a>&nbsp;for more information.
-</p>
-<h3>
- Design the architecture with components and services
-</h3>
-<p>
- This strategy helps manage software complexity through&nbsp;partitioning&nbsp;a system into a set of loosely coupled
- and highly cohesive components. The benefits of this approach include the ability to organize the team around a set of
- smaller, more manageable objectives, and the ability to substitute parts of the system without disturbing the overall
- cohesion of the system. Exposing services encourages re-use by making the functionality of the system easier to
- comprehend. Focusing on services makes it possible to understand what the system does from a technical perspective
- without necessarily having to understand the details of how the system works.
-</p>
-<p>
- See <a class="elementLinkWithType" href="./../../../core.tech.common.extend_supp/guidances/concepts/component_CB167D48.html" guid="_0YP18MlgEdmt3adZL5Dmdw">Concept: Component</a>&nbsp;for more information.
-</p>
-<h3>
- Actively promote reuse
-</h3>
-<p>
- Incorporating existing software into an overall architecture helps reduce cost and improve quality by reusing proven
- working software, rather than developing from scratch. It also helps reduce the burden of maintenance by eliminating
- duplication in the software. Although often difficult to manage, a project or enterprise can reap significant benefits
- from a well-executed re-use strategy.
-</p>
-<p>
- See <a class="elementLinkWithType" href="./../../../core.tech.common.extend_supp/guidances/guidelines/software_reuse_B6B04C26.html" guid="_vO2uoO0OEduUpsu85bVhiQ">Guideline: Software Reuse</a>&nbsp;for more information.
+ <mainDescription><p>
+ Software&nbsp;development is a pursuit characterized by complexity. This can take many forms, such as accommodating
+ complex requirements, technology, or team dynamics. Elevating the level of abstraction helps you manage this complexity
+ and make measurable progress, despite the inherent difficulty of the task.
+</p>
+<p>
+ Suggestions for several strategies that help abstract away complexity follow.
+</p>
+<h3>
+ Leverage patterns
+</h3>
+<p>
+ Patterns help you take advantage of proven techniques for solving common problems. You can benefit from the experience
+ of seasoned practitioners and avoid "re-inventing the wheel," as the saying goes. The use of patterns is a crucial
+ aspect of an architecture-centric approach to development, because it helps reduce the novelty and diversity of a
+ solution, thus improves quality.
+</p>
+<p>
+ See <a class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/pattern_10BE6D96.html"
+ guid="_0YJvUMlgEdmt3adZL5Dmdw">Concept: Pattern</a>&nbsp;for more information.
+</p>
+<h3>
+ Design the architecture with components and services
+</h3>
+<p>
+ This strategy helps manage software complexity through&nbsp;partitioning&nbsp;a system into a set of loosely coupled
+ and highly cohesive components. The benefits of this approach include the ability to organize the team around a set of
+ smaller, more manageable objectives, and the ability to substitute parts of the system without disturbing the overall
+ cohesion of the system. Exposing services encourages re-use by making the functionality of the system easier to
+ comprehend. Focusing on services makes it possible to understand what the system does from a technical perspective
+ without necessarily having to understand the details of how the system works.
+</p>
+<p>
+ See <a class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/component_CB167D48.html"
+ guid="_0YP18MlgEdmt3adZL5Dmdw">Concept: Component</a>&nbsp;for more information.
+</p>
+<h3>
+ Actively promote reuse
+</h3>
+<p>
+ Incorporating existing software into an overall architecture helps reduce cost and improve quality by reusing proven
+ working software, rather than developing from scratch. It also helps reduce the burden of maintenance by eliminating
+ duplication in the software. Although often difficult to manage, a project or enterprise can reap significant benefits
+ from a well-executed re-use strategy.
+</p>
+<p>
+ See <a class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/guidelines/software_reuse_B6B04C26.html"
+ guid="_vO2uoO0OEduUpsu85bVhiQ">Guideline: Software Reuse</a>&nbsp;for more information.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/developer_testing.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/developer_testing.xmi
index 8e03663..7cdacaf 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/developer_testing.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/developer_testing.xmi
@@ -1,480 +1,499 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-wuu2cNRUPlrBuaO0OdzLFg" name=",_ByOd4O6pEduvoopEslG-4g" guid="-wuu2cNRUPlrBuaO0OdzLFg" changeDate="2008-08-14T04:53:04.000-0700" version="1.0.0">
- <mainDescription><h3>
- Establish expectations
-</h3>
-<p>
- Those who find developer testing rewarding do it. Those who view it as a chore find ways to avoid it. This is simply in
- the nature of most developers in most industries, and treating it as a shameful lack of discipline hasn't historically
- been successful. Therefore, as a developer you should expect testing to be rewarding and do what it takes to make it
- rewarding.
-</p>
-<p>
- Ideal developer testing follows a very tight edit-test loop. You make a small change to the product, such as adding a
- new method to a class, then you immediately rerun your tests. If any test breaks, you know exactly what code is the
- cause. This easy, steady pace of development is the greatest reward of developer testing. A long debugging session
- should be exceptional.
-</p>
-<p>
- Because it's not unusual for a change made in one class to break something in another, you should expect to rerun not
- just the changed class's tests, but many tests. Ideally, you rerun the complete test suite for your implementation
- element many times per hour. Every time you make a significant change, you rerun the suite, watch the results, and
- either proceed to the next change or fix the last change. Expect to spend some effort making that rapid feedback
- possible.
-</p>
-<h3>
- Write and maintain&nbsp;tests
-</h3>
-<h4>
- Automate your tests
-</h4>
-<p>
- Running tests often is not practical if tests are manual. For some implementation elements, automated tests are easy.
- An example would be an in-memory database. It communicates to its clients through an API and has no other interface to
- the outside world. Tests for it would look something like this:
-</p>
-<blockquote>
-<pre>
-/* Check that elements can be added at most once. */
-// Setup
-Database db = new Database();
-db.add("key1", "value1");
-// Test
-boolean result = db.add("key1", "another value");
-expect(result == false);
-</pre>
-</blockquote>
-<p>
- The tests are different from ordinary client code in only one way: instead of believing the results of API calls, they
- check. If the API makes client code easy to write, it makes test code easy to write. If the test code is <i>not</i>
- easy to write, you've received an early warning that the API could be improved. Test-first design is thus consistent
- with the iterative processes' focus on addressing important risks early.
-</p>
-<p>
- The more tightly connected the element is to the outside world, however, the harder it will be to test. There are two
- common cases: graphical user interfaces and back-end components.
-</p>
-<h5>
- Graphical user interfaces
-</h5>
-<p>
- Suppose the database in the example above receives its data via a callback from a user-interface object. The callback
- is invoked when the user fills in some text fields and pushes a button. Testing this by manually filling in the fields
- and pushing the button isn't something you want to do many times an hour. You must arrange a way to deliver the input
- under programmatic control, typically by "pushing" the button in code.
-</p>
-<p>
- Pushing the button causes some code in the implementation element to be executed. Most likely, that code changes the
- state of some user-interface objects. So you must also arrange a way to query those objects programmatically.
-</p>
-<h5>
- Back-end components
-</h5>
-<p>
- Suppose the element under test doesn't implement a database. Instead, it's a wrapper around a real, on-disk database.
- Testing against that real database might be difficult. It might be hard to install and configure. Licenses for it might
- be expensive. The database might slow down the tests enough that you're not inclined to run them often. In such cases,
- it's worthwhile to "stub out" the database with a simpler element that does just enough to support the tests.
-</p>
-<p>
- Stubs are also useful when a component that your element talks to isn't ready yet. You don't want your testing to wait
- on someone else's code.
-</p>
-<h4>
- Don't write your own tools
-</h4>
-<p>
- Developer testing seems pretty straightforward. You set up some objects, make a call through an API, check the result,
- and announce a test failure if the results aren't as expected. It's also convenient to have some way to group tests so
- that they can be run individually or as complete suites. Tools that support those requirements are called <i>test
- frameworks</i>.
-</p>
-<p>
- Developer testing <b>is</b> straightforward, and the requirements for test frameworks are not complicated. If, however,
- you yield to the temptation of writing your own test framework, you'll spend much more time tinkering with the
- framework than you probably expect. There are many test frameworks available, both commercial and open source, and
- there's no reason not to use one of those.
-</p>
-<h4>
- Do create support code
-</h4>
-<p>
- Test code tends to be repetitive. It's common to see sequences of code like this:
-</p>
-<blockquote>
-<pre>
-// null name not allowed
-retval = o.createName("");
-expect(retval == null);
-// leading spaces not allowed
-retval = o.createName(" l");
-expect(retval == null);
-// trailing spaces not allowed
-retval = o.createName("name ");
-expect(retval == null);
-// first character may not be numeric
-retval = o.createName("5allpha");
-expect(retval == null);
-</pre>
-</blockquote>
-<p>
- This code is created by copying one check, pasting it, then editing it to make another check.
-</p>
-<p>
- The danger here is twofold. If the interface changes, much editing will have to be done. (In more complicated cases, a
- simple global replacement won't suffice.) Also, if the code is at all complicated, the intent of the test can be lost
- amid all the text.
-</p>
-<p>
- When you find yourself repeating yourself, seriously consider factoring out the repetition into support code. Even
- though the code above is a simple example, it's more readable and maintainable if written like this:
-</p>
-<blockquote>
-<pre>
-void expectNameRejected(MyClass o, String s) {
-Object retval = o.createName(s);
-expect(retval == null);
-}
-...
-// null name not allowed
-expectNameRejected(o, "");
-// leading spaces not allowed.
-expectNameRejected(o, " l");
-// trailing spaces not allowed.
-expectNameRejected(o, "name ");
-// first character may not be numeric.
-expectNameRejected(o, "5alpha");
-</pre>
-</blockquote>
-<p>
- Developers writing tests often err on the side of too much copying-and-pasting. If you suspect yourself of that
- tendency, it's useful to consciously err in the other direction. Resolve that you will strip your code of all duplicate
- text.
-</p>
-<h4>
- Keep the tests understandable
-</h4>
-<p>
- You should expect that you, or someone else, will have to modify the tests later. A typical situation is that a later
- iteration calls for a change to the element's behavior. As a simple example, suppose the element once declared a square
- root method like this:
-</p>
-<blockquote>
- <p>
- <font size="+0">double sqrt(double x);</font>
- </p>
-</blockquote>
-<p>
- In that version, a negative argument caused <font size="+0">sqrt</font> to return NaN ("not a number" from the IEEE
- 754-1985 <i>Standard for Binary Floating-Point Arithmetic</i>). In the new iteration, the square root method will
- accept negative numbers and return a complex result:
-</p>
-<blockquote>
- <p>
- <font size="+0">Complex sqrt(double x);</font>
- </p>
-</blockquote>
-<p>
- Old tests for <font size="+0">sqrt</font> will have to change. That means understanding what they do, and updating them
- so that they work with the new <font size="+0">sqrt</font>. When updating tests, you must take care not to destroy
- their bug-finding power. One way that sometimes happens is this:
-</p>
-<blockquote>
-<pre>
-void testSQRT () {
-// Update these tests for Complex
-// when I have time -- bem
-/*
-double result = sqrt(0.0);
-...
-*/
-}
-</pre>
-</blockquote>
-<p>
- Other ways are more subtle: the tests are changed so that they actually run, but they no longer test what they were
- originally intended to test. The end result, over many iterations, can be a test suite that is too weak to catch many
- bugs. This is sometimes called "test suite decay". A decayed suite will be abandoned, because it's not worth the
- upkeep.
-</p>
-<p>
- Test suite decay is less likely in the direct tests for <font size="+0">sqrt</font> than in indirect tests. There will
- be code that calls <font size="+0">sqrt</font>. That code will have tests. When <font size="+0">sqrt</font> changes,
- some of those tests will fail. The person who changes <font size="+0">sqrt</font> will probably have to change those
- tests. Because he's less familiar with them, and because their relationship to the change is less clear, he's more
- likely to weaken them in the process of making them pass.
-</p>
-<p>
- When you're creating support code for tests (as urged above), be careful: the support code should clarify, not obscure,
- the purpose of the tests that use it. A common complaint about object-oriented programs is that there's no one place
- where anything's done. If you look at any one method, all you discover is that it forwards its work somewhere else.
- Such a structure has advantages, but it makes it harder for new people to understand the code. Unless they make an
- effort, their changes are likely to be incorrect or to make the code even more complicated and fragile. The same is
- true of test code, except that later maintainers are even less likely to take due care. You must head off the problem
- by writing understandable tests.
-</p>
-<h4>
- Match the test structure to the product structure
-</h4>
-<p>
- Suppose someone has inherited your implementation element. They need to change a part of it. They may want to examine
- the old tests to help them in their new design. They want to update the old tests before writing the code (test-first
- design).
-</p>
-<p>
- All those good intentions will go by the wayside if they can't find the appropriate tests. What they'll do is make the
- change, see what tests fail, then fix those. That will contribute to test suite decay.
-</p>
-<p>
- For that reason, it's important that the test suite be well structured, and that the location of tests be predictable
- from the structure of the product. Most usually, developers arrange tests in a parallel hierarchy, with one test class
- per product class. So if someone is changing a class named <font size="+0">Log</font>, they know the test class is
- <font size="+0">TestLog</font>, and they know where the source file can be found.
-</p>
-<h4>
- Let tests violate encapsulation
-</h4>
-<p>
- You might limit your tests to interacting with your implementation element exactly as client code does, through the
- same interface that client code uses. However, this has disadvantages. Suppose you're testing a simple class that
- maintains a doubly linked list:
-</p>
-<p>
- In particular, you're testing the <font size="+0">DoublyLinkedList.insertBefore(Object existing, Object
- newObject)</font> method. In one of your tests, you want to insert an element in the middle of the list, then check if
- it's been inserted successfully. The test uses the list above to create this updated list:
-</p>
-<p>
- It checks the list correctness like this:
-</p>
-<blockquote>
-<pre>
-// the list is now one longer.
-expect(list.size()==3);
-// the new element is in the correct position
-expect(list.get(1)==m);
-// check that other elements are still there.
-expect(list.get(0)==a);
-expect(list.get(2)==z);
-</pre>
-</blockquote>
-<p>
- That seems sufficient, but it's not. Suppose the list implementation is incorrect and backward pointers are not set
- correctly. That is, suppose the updated list actually looks like this:
-</p>
-<p>
- If <font size="+0">DoublyLinkedList.get(int index)</font> traverses the list from the beginning to the end (likely),
- the test would miss this failure. If the class provides <font size="+0">elementBefore</font> and <font size="+0">elementAfter</font> methods, checking for such failures is straightforward:
-</p>
-<blockquote>
-<pre>
-// Check that links were all updated
-expect(list.elementAfter(a)==m);
-expect(list.elementAfter(m)==z);
-expect(list.elementBefore(z)==m); //this will fail
-expect(list.elementBefore(m)==a);
-</pre>
-</blockquote>
-<p>
- But what if it doesn't provide those methods? You could devise more elaborate sequences of method calls that will fail
- if the suspected defect is present. For example, this would work:
-</p>
-<blockquote>
-<pre>
-// Check whether back-link from Z is correct.
-list.insertBefore(z, x);
-// If it was incorrectly not updated, X will have
-// been inserted just after A.
-expect(list.get(1)==m);
-</pre>
-</blockquote>
-<p>
- But such a test is more work to create and is likely to be significantly harder to maintain. (Unless you write good
- comments, it will not be at all clear why the test is doing what it's doing.) There are two solutions:
-</p>
-<ol>
- <li>
- Add the <font size="+0">elementBefore</font> and <font size="+0">elementAfter</font> methods to the public
- interface. But that effectively exposes the implementation to everyone and makes future change more difficult.
- </li>
- <li>
- Let the tests "look under the hood" and check pointers directly.
- </li>
-</ol>
-<p>
- The latter is usually the best solution, even for a simple class like <font size="+0">DoublyLinkedList</font> and
- especially for the more complex classes that occur in your products.
-</p>
-<p>
- Typically, tests are put in the same package as the class they test. They are given protected or friend access.
-</p>
-<h4>
- Approaches for Test Setup
-</h4>
-<p>
- To successfully run a test, the system must be in a known state. To do this you will need objects or components in
- memory, rows in the database, etc. that you will test against. The easiest approach is to hardcode the required data
- and the setup code within the test itself. The primary advantage is that all the information that you need about the
- test is in one place and that the test is potentially self-sufficient.
-</p>
-<p>
- Another approach is to define an external data set which is loaded into memory or into the database at the beginning of
- the test run. There are several advantages to this approach:
-</p>
-<ul>
- <li>
- It decouples the test data from the test.
- </li>
- <li>
- More than one test can use the same data set.
- </li>
- <li>
- It is easy to modify and/or multiply the test data.
- </li>
-</ul>
-<p>
- There are some disadvantages to this approach:
-</p>
-<ul>
- <li>
- Increased complexity for maintaining the external data
- </li>
- <li>
- Potential coupling between test cases. When they share a common test data bed it becomes very easy to write tests
- that depend on other tests running first, thereby coupling them together.
- </li>
-</ul>
-<h4>
- Coding for Testability
-</h4>
-<p>
- Add&nbsp;<a class="elementLink" href="./../../../core.tech.common.base/guidances/termdefinitions/code_instrumentation_3060875F.html" guid="_lzAWkK9eEdyltJ0KgEd9WQ">code instrumentation</a> for testing and debugging. Pay special attention to the
- implementation of the observation/control points, such as critical functions or objects, as these aspects might need
- special support that has to be implemented in the application under test.
-</p>
-<h4>
- Reviewing Tests
-</h4>
-<p>
- If a test will be long-lived, ask a person with less inside knowledge of the implementation element to run it and check
- if there is enough support information. Review it with other people within the development team and other interested
- parties as needed.
-</p>
-<h3>
- <a id="TestDesignMistakes" name="TestDesignMistakes"></a>Characteristic Test Design Mistakes
-</h3>
-<p>
- Each test exercises an implementation element and checks for correct results. The design of the test-the inputs it uses
- and how it checks for correctness-can be good at revealing defects, or it can inadvertently hide them. Here are some
- characteristic test design mistakes.
-</p>
-<h4>
- Failure to specify expected results in advance
-</h4>
-<p>
- Suppose you're testing an implementation element that converts XML into HTML. A temptation is to take some sample XML,
- run it through the conversion, then look at the results in a browser. If the screen looks right, you "bless" the HTML
- by saving it as the official expected results. Thereafter, a test compares the actual output of the conversion to the
- expected results.
-</p>
-<p>
- This is a dangerous practice. Even sophisticated computer users are used to believing what the computer does. You are
- likely to overlook mistakes in the screen appearance. (Not to mention that browsers are quite tolerant of misformatted
- HTML.) By making that incorrect HTML the official expected results, you make sure that the test can never find the
- problem.
-</p>
-<p>
- It's less dangerous to doubly-check by looking directly at the HTML, but it's still dangerous. Because the output is
- complicated, it will be easy to overlook errors. You'll find more defects if you write the expected output by hand
- first.
-</p>
-<h4>
- Failure to check the background
-</h4>
-<p>
- Tests usually check that what should have been changed has been, but their creators often forget to check that what
- should have been left alone has been left alone. For example, suppose a program is supposed to change the first 100
- records in a file. It's a good idea to check that the 101<sup>st</sup> hasn't been changed.
-</p>
-<p>
- In theory, you would check that nothing in the "background"-the entire file system, all of memory, everything reachable
- through the network-has been left alone. In practice, you have to choose carefully what you can afford to check. But
- it's important to make that choice.
-</p>
-<h4>
- Failure to check persistence
-</h4>
-<p>
- Just because the implementation element tells you a change has been made, that doesn't mean it has actually been
- committed to the database. You need to check the database via another route.
-</p>
-<h4>
- Failure to add variety
-</h4>
-<p>
- A test might be designed to check the effect of three fields in a database record, but many other fields need to be
- filled in to execute the test. Testers will often use the same values over and over again for these "irrelevant"
- fields. For example, they'll always use the name of their lover in a text field, or 999 in a numeric field.
-</p>
-<p>
- The problem is that sometimes what shouldn't matter actually does. Every so often, there's a bug that depends on some
- obscure combination of unlikely inputs. If you always use the same inputs, you stand no chance of finding such bugs. If
- you persistently vary inputs, you might. Quite often, it costs almost nothing to use a number different than 999 or to
- use someone else's name. When varying the values used in tests costs almost nothing and it has some potential benefit,
- then vary. (Note: It's unwise to use names of old lovers instead of your current one if your current lover works with
- you.)
-</p>
-<p>
- Here's another benefit. One plausible fault is for the program to use field <i>X</i> when it should have used field
- <i>Y</i>. If both fields contain "Dawn", the fault can't be detected.
-</p>
-<h4>
- Failure to use realistic data
-</h4>
-<p>
- It's common to use made-up data in tests. That data is often unrealistically simple. For example, customer names might
- be "Mickey", "Snoopy", and "Donald". Because that data is different from what real users enter - for example, it's
- characteristically shorter - it can miss defects real customers will see. For example, these one-word names wouldn't
- detect that the code doesn't handle names with spaces.
-</p>
-<p>
- It's prudent to make a slight extra effort to use realistic data.
-</p>
-<h4>
- Failure to notice that the code does nothing at all
-</h4>
-<p>
- Suppose you initialize a database record to zero, run a calculation that should result in zero being stored in the
- record, then check that the record is zero. What has your test demonstrated? The calculation might not have taken place
- at all. Nothing might have been stored, and the test couldn't tell.
-</p>
-<p>
- That example sounds unlikely. But this same mistake can crop up in subtler ways. For example, you might write a test
- for a complicated installer program. The test is intended to check that all temporary files are removed after a
- successful installation. But, because of all the installer options, in that test, one particular temporary file wasn't
- created. Sure enough, that's the one the program forgot to remove.
-</p>
-<h4>
- Failure to notice that the code does the wrong thing
-</h4>
-<p>
- Sometimes a program does the right thing for the wrong reasons. As a trivial example, consider this code:
-</p>
-<blockquote>
-<pre>
-if (a &lt; b &amp;&amp; c)
-return 2 * x;
-else
-return x * x;
-</pre>
-</blockquote>
-<p>
- The logical expression is wrong, and you've written a test that causes it to evaluate incorrectly and take the wrong
- branch. Unfortunately, purely by coincidence, the variable X has the value 2 in that test. So the result of the wrong
- branch is accidentally correct - the same as the result the right branch would have given.
-</p>
-<p>
- For each expected result, you should ask if there's a plausible way in which that result could be&nbsp;achieved for the
- wrong reason. While it's often impossible to know, sometimes it's not.
+ <mainDescription><h3>
+ Establish expectations
+</h3>
+<p>
+ Those who find developer testing rewarding do it. Those who view it as a chore find ways to avoid it. This is simply in
+ the nature of most developers in most industries, and treating it as a shameful lack of discipline hasn't historically
+ been successful. Therefore, as a developer you should expect testing to be rewarding and do what it takes to make it
+ rewarding.
+</p>
+<p>
+ Ideal developer testing follows a very tight edit-test loop. You make a small change to the product, such as adding a
+ new method to a class, then you immediately rerun your tests. If any test breaks, you know exactly what code is the
+ cause. This easy, steady pace of development is the greatest reward of developer testing. A long debugging session
+ should be exceptional.
+</p>
+<p>
+ Because it's not unusual for a change made in one class to break something in another, you should expect to rerun not
+ just the changed class's tests, but many tests. Ideally, you rerun the complete test suite for your implementation
+ element many times per hour. Every time you make a significant change, you rerun the suite, watch the results, and
+ either proceed to the next change or fix the last change. Expect to spend some effort making that rapid feedback
+ possible.
+</p>
+<h3>
+ Write and maintain&nbsp;tests
+</h3>
+<h4>
+ Automate your tests
+</h4>
+<p>
+ Running tests often is not practical if tests are manual. For some implementation elements, automated tests are easy.
+ An example would be an in-memory database. It communicates to its clients through an API and has no other interface to
+ the outside world. Tests for it would look something like this:
+</p>
+<blockquote>
+<pre>
+<!-- START NON-TRANSLATABLE -->
+/* Check that elements can be added at most once. */
+// Setup
+Database db = new Database();
+db.add("key1", "value1");
+// Test
+boolean result = db.add("key1", "another value");
+expect(result == false);
+<!-- END NON-TRANSLATABLE -->
+</pre>
+</blockquote>
+<p>
+ The tests are different from ordinary client code in only one way: instead of believing the results of API calls, they
+ check. If the API makes client code easy to write, it makes test code easy to write. If the test code is <i>not</i>
+ easy to write, you've received an early warning that the API could be improved. Test-first design is thus consistent
+ with the iterative processes' focus on addressing important risks early.
+</p>
+<p>
+ The more tightly connected the element is to the outside world, however, the harder it will be to test. There are two
+ common cases: graphical user interfaces and back-end components.
+</p>
+<h5>
+ Graphical user interfaces
+</h5>
+<p>
+ Suppose the database in the example above receives its data via a callback from a user-interface object. The callback
+ is invoked when the user fills in some text fields and pushes a button. Testing this by manually filling in the fields
+ and pushing the button isn't something you want to do many times an hour. You must arrange a way to deliver the input
+ under programmatic control, typically by "pushing" the button in code.
+</p>
+<p>
+ Pushing the button causes some code in the implementation element to be executed. Most likely, that code changes the
+ state of some user-interface objects. So you must also arrange a way to query those objects programmatically.
+</p>
+<h5>
+ Back-end components
+</h5>
+<p>
+ Suppose the element under test doesn't implement a database. Instead, it's a wrapper around a real, on-disk database.
+ Testing against that real database might be difficult. It might be hard to install and configure. Licenses for it might
+ be expensive. The database might slow down the tests enough that you're not inclined to run them often. In such cases,
+ it's worthwhile to "stub out" the database with a simpler element that does just enough to support the tests.
+</p>
+<p>
+ Stubs are also useful when a component that your element talks to isn't ready yet. You don't want your testing to wait
+ on someone else's code.
+</p>
+<h4>
+ Don't write your own tools
+</h4>
+<p>
+ Developer testing seems pretty straightforward. You set up some objects, make a call through an API, check the result,
+ and announce a test failure if the results aren't as expected. It's also convenient to have some way to group tests so
+ that they can be run individually or as complete suites. Tools that support those requirements are called <i>test
+ frameworks</i>.
+</p>
+<p>
+ Developer testing <b>is</b> straightforward, and the requirements for test frameworks are not complicated. If, however,
+ you yield to the temptation of writing your own test framework, you'll spend much more time tinkering with the
+ framework than you probably expect. There are many test frameworks available, both commercial and open source, and
+ there's no reason not to use one of those.
+</p>
+<h4>
+ Do create support code
+</h4>
+<p>
+ Test code tends to be repetitive. It's common to see sequences of code like this:
+</p>
+<blockquote>
+<pre>
+<!-- START NON-TRANSLATABLE -->
+// null name not allowed
+retval = o.createName(""); 
+expect(retval == null);
+// leading spaces not allowed
+retval = o.createName(" l"); 
+expect(retval == null);
+// trailing spaces not allowed
+retval = o.createName("name "); 
+expect(retval == null);
+// first character may not be numeric
+retval = o.createName("5allpha"); 
+expect(retval == null);
+<!-- END NON-TRANSLATABLE -->
+</pre>
+</blockquote>
+<p>
+ This code is created by copying one check, pasting it, then editing it to make another check.
+</p>
+<p>
+ The danger here is twofold. If the interface changes, much editing will have to be done. (In more complicated cases, a
+ simple global replacement won't suffice.) Also, if the code is at all complicated, the intent of the test can be lost
+ amid all the text.
+</p>
+<p>
+ When you find yourself repeating yourself, seriously consider factoring out the repetition into support code. Even
+ though the code above is a simple example, it's more readable and maintainable if written like this:
+</p>
+<blockquote>
+<pre>
+<!-- START NON-TRANSLATABLE -->
+void expectNameRejected(MyClass o, String s) {
+Object retval = o.createName(s);
+expect(retval == null);
+}
+...
+// null name not allowed
+expectNameRejected(o, ""); 
+// leading spaces not allowed.
+expectNameRejected(o, " l"); 
+// trailing spaces not allowed.
+expectNameRejected(o, "name "); 
+// first character may not be numeric.
+expectNameRejected(o, "5alpha"); 
+<!-- END NON-TRANSLATABLE -->
+</pre>
+</blockquote>
+<p>
+ Developers writing tests often err on the side of too much copying-and-pasting. If you suspect yourself of that
+ tendency, it's useful to consciously err in the other direction. Resolve that you will strip your code of all duplicate
+ text.
+</p>
+<h4>
+ Keep the tests understandable
+</h4>
+<p>
+ You should expect that you, or someone else, will have to modify the tests later. A typical situation is that a later
+ iteration calls for a change to the element's behavior. As a simple example, suppose the element once declared a square
+ root method like this:
+</p>
+<blockquote>
+ <p>
+ <font size="+0">double sqrt(double x);</font>
+ </p>
+</blockquote>
+<p>
+ In that version, a negative argument caused the function "sqrt" to return NaN ("not a number" from the IEEE 754-1985
+ <i>Standard for Binary Floating-Point Arithmetic</i>). In the new iteration, the square root method will accept
+ negative numbers and return a complex result:
+</p>
+<blockquote>
+ <p>
+ <font size="+0">Complex sqrt(double x);</font>
+ </p>
+</blockquote>
+<p>
+ Old tests for the function "sqrt" will have to change. That means understanding what they do, and updating them so that
+ they work with the new "sqrt". When updating tests, you must take care not to destroy their bug-finding power. One way
+ that sometimes happens is this:
+</p>
+<blockquote>
+<pre>
+<!-- START NON-TRANSLATABLE -->
+void testSQRT () {
+// Update these tests for Complex 
+// when I have time -- bem
+/*
+double result = sqrt(0.0);
+...
+*/
+}
+<!-- END NON-TRANSLATABLE -->
+</pre>
+</blockquote>
+<p>
+ Other ways are more subtle: the tests are changed so that they actually run, but they no longer test what they were
+ originally intended to test. The end result, over many iterations, can be a test suite that is too weak to catch many
+ bugs. This is sometimes called "test suite decay". A decayed suite will be abandoned, because it's not worth the
+ upkeep.
+</p>
+<p>
+ Test suite decay is less likely in the direct tests for the function "sqrt" than in indirect tests. There will be code
+ that calls the function "sqrt". That code will have tests. When the function "sqrt" changes, some of those tests will
+ fail. The person who changes the function "sqrt" will probably have to change those tests. Because he's less familiar
+ with them, and because their relationship to the change is less clear, he's more likely to weaken them in the process
+ of making them pass.
+</p>
+<p>
+ When you're creating support code for tests (as urged above), be careful: the support code should clarify, not obscure,
+ the purpose of the tests that use it. A common complaint about object-oriented programs is that there's no one place
+ where anything's done. If you look at any one method, all you discover is that it forwards its work somewhere else.
+ Such a structure has advantages, but it makes it harder for new people to understand the code. Unless they make an
+ effort, their changes are likely to be incorrect or to make the code even more complicated and fragile. The same is
+ true of test code, except that later maintainers are even less likely to take due care. You must head off the problem
+ by writing understandable tests.
+</p>
+<h4>
+ Match the test structure to the product structure
+</h4>
+<p>
+ Suppose someone has inherited your implementation element. They need to change a part of it. They may want to examine
+ the old tests to help them in their new design. They want to update the old tests before writing the code (test-first
+ design).
+</p>
+<p>
+ All those good intentions will go by the wayside if they can't find the appropriate tests. What they'll do is make the
+ change, see what tests fail, then fix those. That will contribute to test suite decay.
+</p>
+<p>
+ For that reason, it's important that the test suite be well structured, and that the location of tests be predictable
+ from the structure of the product. Most usually, developers arrange tests in a parallel hierarchy, with one test class
+ per product class. So if someone is changing a class named "Log", they know the test class is "TestLog", and they know
+ where the source file can be found.
+</p>
+<h4>
+ Let tests violate encapsulation
+</h4>
+<p>
+ You might limit your tests to interacting with your implementation element exactly as client code does, through the
+ same interface that client code uses. However, this has disadvantages. Suppose you're testing a simple class that
+ maintains a doubly linked list:
+</p>
+<p>
+ In particular, you're testing the "DoublyLinkedList.insertBefore(Object existing, Object newObject)" method. In one of
+ your tests, you want to insert an element in the middle of the list, then check if it's been inserted successfully. The
+ test uses the list above to create this updated list:
+</p>
+<p>
+ It checks the list correctness like this:
+</p>
+<blockquote>
+<pre>
+<!-- START NON-TRANSLATABLE -->
+// the list is now one longer. 
+expect(list.size()==3);
+// the new element is in the correct position
+expect(list.get(1)==m);
+// check that other elements are still there.
+expect(list.get(0)==a);
+expect(list.get(2)==z);
+<!-- END NON-TRANSLATABLE -->
+</pre>
+</blockquote>
+<p>
+ That seems sufficient, but it's not. Suppose the list implementation is incorrect and backward pointers are not set
+ correctly. That is, suppose the updated list actually looks like this:
+</p>
+<p>
+ If the function "DoublyLinkedList.get(int index)" traverses the list from the beginning to the end (likely), the test
+ would miss this failure. If the class provides "elementBefore" and "elementAfter" methods, checking for such failures
+ is straightforward:
+</p>
+<blockquote>
+<pre>
+<!-- START NON-TRANSLATABLE -->
+// Check that links were all updated
+expect(list.elementAfter(a)==m);
+expect(list.elementAfter(m)==z);
+expect(list.elementBefore(z)==m); //this will fail
+expect(list.elementBefore(m)==a);
+<!-- END NON-TRANSLATABLE -->
+</pre>
+</blockquote>
+<p>
+ But what if it doesn't provide those methods? You could devise more elaborate sequences of method calls that will fail
+ if the suspected defect is present. For example, this would work:
+</p>
+<blockquote>
+<pre>
+<!-- START NON-TRANSLATABLE -->
+// Check whether back-link from Z is correct.
+list.insertBefore(z, x);
+// If it was incorrectly not updated, X will have 
+// been inserted just after A.
+expect(list.get(1)==m); 
+<!-- END NON-TRANSLATABLE -->
+</pre>
+</blockquote>
+<p>
+ But such a test is more work to create and is likely to be significantly harder to maintain. (Unless you write good
+ comments, it will not be at all clear why the test is doing what it's doing.) There are two solutions:
+</p>
+<ol>
+ <li>
+ Add the "elementBefore" and "elementAfter" methods to the public interface. But that effectively exposes the
+ implementation to everyone and makes future change more difficult.
+ </li>
+ <li>
+ Let the tests "look under the hood" and check pointers directly.
+ </li>
+</ol>
+<p>
+ The latter is usually the best solution, even for a simple class like "DoublyLinkedList" and especially for the more
+ complex classes that occur in your products.
+</p>
+<p>
+ Typically, tests are put in the same package as the class they test. They are given protected or friend access.
+</p>
+<h4>
+ Approaches for Test Setup
+</h4>
+<p>
+ To successfully run a test, the system must be in a known state. To do this you will need objects or components in
+ memory, rows in the database, etc. that you will test against. The easiest approach is to hardcode the required data
+ and the setup code within the test itself. The primary advantage is that all the information that you need about the
+ test is in one place and that the test is potentially self-sufficient.
+</p>
+<p>
+ Another approach is to define an external data set which is loaded into memory or into the database at the beginning of
+ the test run. There are several advantages to this approach:
+</p>
+<ul>
+ <li>
+ It decouples the test data from the test.
+ </li>
+ <li>
+ More than one test can use the same data set.
+ </li>
+ <li>
+ It is easy to modify and/or multiply the test data.
+ </li>
+</ul>
+<p>
+ There are some disadvantages to this approach:
+</p>
+<ul>
+ <li>
+ Increased complexity for maintaining the external data
+ </li>
+ <li>
+ Potential coupling between test cases. When they share a common test data bed it becomes very easy to write tests
+ that depend on other tests running first, thereby coupling them together.
+ </li>
+</ul>
+<h4>
+ Coding for Testability
+</h4>
+<p>
+ Add&nbsp;<a class="elementLink"
+ href="./../../../core.tech.common.base/guidances/termdefinitions/code_instrumentation_3060875F.html"
+ guid="_lzAWkK9eEdyltJ0KgEd9WQ">code instrumentation</a> for testing and debugging. Pay special attention to the
+ implementation of the observation/control points, such as critical functions or objects, as these aspects might need
+ special support that has to be implemented in the application under test.
+</p>
+<h4>
+ Reviewing Tests
+</h4>
+<p>
+ If a test will be long-lived, ask a person with less inside knowledge of the implementation element to run it and check
+ if there is enough support information. Review it with other people within the development team and other interested
+ parties as needed.
+</p>
+<h3>
+ <a id="TestDesignMistakes" name="TestDesignMistakes"></a>Characteristic Test Design Mistakes
+</h3>
+<p>
+ Each test exercises an implementation element and checks for correct results. The design of the test-the inputs it uses
+ and how it checks for correctness-can be good at revealing defects, or it can inadvertently hide them. Here are some
+ characteristic test design mistakes.
+</p>
+<h4>
+ Failure to specify expected results in advance
+</h4>
+<p>
+ Suppose you're testing an implementation element that converts XML into HTML. A temptation is to take some sample XML,
+ run it through the conversion, then look at the results in a browser. If the screen looks right, you "bless" the HTML
+ by saving it as the official expected results. Thereafter, a test compares the actual output of the conversion to the
+ expected results.
+</p>
+<p>
+ This is a dangerous practice. Even sophisticated computer users are used to believing what the computer does. You are
+ likely to overlook mistakes in the screen appearance. (Not to mention that browsers are quite tolerant of misformatted
+ HTML.) By making that incorrect HTML the official expected results, you make sure that the test can never find the
+ problem.
+</p>
+<p>
+ It's less dangerous to doubly-check by looking directly at the HTML, but it's still dangerous. Because the output is
+ complicated, it will be easy to overlook errors. You'll find more defects if you write the expected output by hand
+ first.
+</p>
+<h4>
+ Failure to check the background
+</h4>
+<p>
+ Tests usually check that what should have been changed has been, but their creators often forget to check that what
+ should have been left alone has been left alone. For example, suppose a program is supposed to change the first 100
+ records in a file. It's a good idea to check that the 101<sup>st</sup> hasn't been changed.
+</p>
+<p>
+ In theory, you would check that nothing in the "background"-the entire file system, all of memory, everything reachable
+ through the network-has been left alone. In practice, you have to choose carefully what you can afford to check. But
+ it's important to make that choice.
+</p>
+<h4>
+ Failure to check persistence
+</h4>
+<p>
+ Just because the implementation element tells you a change has been made, that doesn't mean it has actually been
+ committed to the database. You need to check the database via another route.
+</p>
+<h4>
+ Failure to add variety
+</h4>
+<p>
+ A test might be designed to check the effect of three fields in a database record, but many other fields need to be
+ filled in to execute the test. Testers will often use the same values over and over again for these "irrelevant"
+ fields. For example, they'll always use the name of their lover in a text field, or 999 in a numeric field.
+</p>
+<p>
+ The problem is that sometimes what shouldn't matter actually does. Every so often, there's a bug that depends on some
+ obscure combination of unlikely inputs. If you always use the same inputs, you stand no chance of finding such bugs. If
+ you persistently vary inputs, you might. Quite often, it costs almost nothing to use a number different than 999 or to
+ use someone else's name. When varying the values used in tests costs almost nothing and it has some potential benefit,
+ then vary. (Note: It's unwise to use names of old lovers instead of your current one if your current lover works with
+ you.)
+</p>
+<p>
+ Here's another benefit. One plausible fault is for the program to use field <i>X</i> when it should have used field
+ <i>Y</i>. If both fields contain "Dawn", the fault can't be detected.
+</p>
+<h4>
+ Failure to use realistic data
+</h4>
+<p>
+ It's common to use made-up data in tests. That data is often unrealistically simple. For example, customer names might
+ be "Mickey", "Snoopy", and "Donald". Because that data is different from what real users enter - for example, it's
+ characteristically shorter - it can miss defects real customers will see. For example, these one-word names wouldn't
+ detect that the code doesn't handle names with spaces.
+</p>
+<p>
+ It's prudent to make a slight extra effort to use realistic data.
+</p>
+<h4>
+ Failure to notice that the code does nothing at all
+</h4>
+<p>
+ Suppose you initialize a database record to zero, run a calculation that should result in zero being stored in the
+ record, then check that the record is zero. What has your test demonstrated? The calculation might not have taken place
+ at all. Nothing might have been stored, and the test couldn't tell.
+</p>
+<p>
+ That example sounds unlikely. But this same mistake can crop up in subtler ways. For example, you might write a test
+ for a complicated installer program. The test is intended to check that all temporary files are removed after a
+ successful installation. But, because of all the installer options, in that test, one particular temporary file wasn't
+ created. Sure enough, that's the one the program forgot to remove.
+</p>
+<h4>
+ Failure to notice that the code does the wrong thing
+</h4>
+<p>
+ Sometimes a program does the right thing for the wrong reasons. As a trivial example, consider this code:
+</p>
+<blockquote>
+<pre>
+<!-- START NON-TRANSLATABLE -->
+if (a &lt; b &amp;&amp; c) 
+return 2 * x;
+else
+return x * x;
+<!-- END NON-TRANSLATABLE -->
+</pre>
+</blockquote>
+<p>
+ The logical expression is wrong, and you've written a test that causes it to evaluate incorrectly and take the wrong
+ branch. Unfortunately, purely by coincidence, the variable X has the value 2 in that test. So the result of the wrong
+ branch is accidentally correct - the same as the result the right branch would have given.
+</p>
+<p>
+ For each expected result, you should ask if there's a plausible way in which that result could be&nbsp;achieved for the
+ wrong reason. While it's often impossible to know, sometimes it's not.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/effective_req_reviews.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/effective_req_reviews.xmi
index d5aaf6c..3dbb02f 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/effective_req_reviews.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/effective_req_reviews.xmi
@@ -1,113 +1,113 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-pNA0DbSdSoUqnjQIiOeHcQ" name="achieving_concurrence,_E-dPIL-GEdqb7N6KIeDL8Q" guid="-pNA0DbSdSoUqnjQIiOeHcQ" changeDate="2010-05-26T09:25:24.000-0700" version="1.0.0">
- <mainDescription><p>
- The cost of correcting errors increases exponentially throughout the development lifecycle <a
- class="elementLinkWithUserText"
- href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
- guid="_9ToeIB83Edqsvps02rpOOg">[BOE88]</a>. Therefore, it is important to discover problems early enough to solve them
- quickly and inexpensively.
-</p>
-<p>
- Requirements reviews are intended to discover problems with the <a class="elementLink"
- href="./../../../core.tech.common.extend_supp/guidances/concepts/requirements_8006414F.html"
- guid="_0Wh-sMlgEdmt3adZL5Dmdw">Requirements</a>&nbsp;before you spend significant time and work in implementing the
- wrong thing. This is not to say that you must have a complete set of requirements before implementation, but be sure to
- review, internally and with stakeholders, those that are selected for implementation in the early iterations and those
- that will have a broad impact on the system (often called <a class="elementLink"
- href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_significant_requirements_1EE5D757.html"
- guid="_HrZGIA4MEduibvKwrGxWxA">Architecturally Significant Requirements</a>) to ensure everyone's concurrence before
- investing significant effort in implementation.
-</p>
-<h3>
- Informal reviews
-</h3>
-<p>
- Requirements reviews can be informal, such as simply showing draft requirements to your colleagues or demonstrating a
- prototype.
-</p>
-<p>
- These informal reviews are excellent for getting the structure of the requirements correct and removing obvious
- mistakes. By keeping the review team small, it is easier to make rapid progress. However, informal reviews can miss
- important perspectives&nbsp;of&nbsp;critical stakeholders.
-</p>
-<h3>
- Formal reviews
-</h3>
-<p>
- Requirement reviews can be formal meetings. Start with careful preparation, so that you receive and organize comments
- before the meeting. The meeting itself should produce decisions on all review items. After the meeting, you must pursue
- the review actions to completion. If these actions involve a substantial amount of work or require a change to an
- artifact that is under configuration control, consider submitting change requests to prioritize and track the work.
-</p>
-<p>
- Formal reviews are more wide-ranging and expensive. They provide for more balanced reviews from multiple
- perspectives.&nbsp; However, formal reviews involve more people, which makes them more difficult to coordinate (thus
- the need for formality) and expensive in terms of work hours.
-</p>
-<h3>
- Two-tier reviews
-</h3>
-<p>
- One technique to get the best of both worlds is to use staged, or "two-tier", reviews&nbsp;<a
- class="elementLinkWithUserText"
- href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
- guid="_9ToeIB83Edqsvps02rpOOg">[ADO03]</a>. The&nbsp;first tier is informal and performed by a smaller team, possibly
- many times. The second&nbsp;tier is more formal and performed by the complete group, perhaps only once.
-</p>
-<p>
- <strong>First-tier review:</strong> The authors of the requirements and the development team&nbsp;review the
- requirements during the first-tier reviews to ensure that they are&nbsp;unambiguous, complete,&nbsp;correct and
- consistent.&nbsp; It is important to include testers and developers to ensure that the requirements are verifiable and
- feasible.&nbsp;These reviews&nbsp;determine whether the requirements are ready for the larger community to
- review.&nbsp; First-tier reviews may be informal, formal, or a combination of the two.
-</p>
-<p>
- <strong>Second-tier review:</strong> Involve the larger group&nbsp;during the higher-tier review to get more minds
- working on the problem and to achieve concurrence that the requirements are suitable for implementation and validation.
-</p>
-<p>
- At both stages, the checklists for the requirements work products are helpful.
-</p>
-<p>
- Tiered reviews offer several benefits:
-</p>
-<ol>
- <li>
- Eliminate the noise caused by minor edits during the first-tier reviews, allowing subsequent reviews to focus on
- functionality
- </li>
- <li>
- Provide a professional look to the requirements, presenting both the requirements and their authors in the best
- possible light
- </li>
- <li>
- Safeguard the time of stakeholders who are reviewing the requirements, thus preventing "review burnout", or
- diminished effectiveness from overload and stress
- </li>
- <li>
- Provide the best opportunity for full, effective reviews.
- </li>
-</ol>
-<h3>
- Golden rules of reviewing
-</h3>
-<p>
- Follow these golden&nbsp;rules of reviewing <a class="elementLinkWithUserText"
- href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
- guid="_9ToeIB83Edqsvps02rpOOg">[TEL06]</a>:
-</p>
-<ol>
- <li>
- <strong>Encourage criticism:</strong> Remember that people are improving the requirements, not criticizing you.
- Even the harshest criticism often contains a grain of truth. Adopt the attitude that every suggestion is a gift.
- </li>
- <li>
- <strong>Choose your best reviewers:</strong> A few specific people make the best reviewers, time and again.
- Cultivate them.
- </li>
- <li>
- <strong>Allow adequate time:</strong> It's not over until you have agreed upon and made the corrections.<br />
- &nbsp;
- </li>
+ <mainDescription><p>
+ The cost of correcting errors increases exponentially throughout the development lifecycle <a
+ class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[BOE88]</a>. Therefore, it is important to discover problems early enough to solve them
+ quickly and inexpensively.
+</p>
+<p>
+ Requirements reviews are intended to discover problems with the <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/requirements_8006414F.html"
+ guid="_0Wh-sMlgEdmt3adZL5Dmdw">Requirements</a>&nbsp;before you spend significant time and work in implementing the
+ wrong thing. This is not to say that you must have a complete set of requirements before implementation, but be sure to
+ review, internally and with stakeholders, those that are selected for implementation in the early iterations and those
+ that will have a broad impact on the system (often called <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_significant_requirements_1EE5D757.html"
+ guid="_HrZGIA4MEduibvKwrGxWxA">Architecturally Significant Requirements</a>) to ensure everyone's concurrence before
+ investing significant effort in implementation.
+</p>
+<h3>
+ Informal reviews
+</h3>
+<p>
+ Requirements reviews can be informal, such as simply showing draft requirements to your colleagues or demonstrating a
+ prototype.
+</p>
+<p>
+ These informal reviews are excellent for getting the structure of the requirements correct and removing obvious
+ mistakes. By keeping the review team small, it is easier to make rapid progress. However, informal reviews can miss
+ important perspectives&nbsp;of&nbsp;critical stakeholders.
+</p>
+<h3>
+ Formal reviews
+</h3>
+<p>
+ Requirement reviews can be formal meetings. Start with careful preparation, so that you receive and organize comments
+ before the meeting. The meeting itself should produce decisions on all review items. After the meeting, you must pursue
+ the review actions to completion. If these actions involve a substantial amount of work or require a change to an
+ artifact that is under configuration control, consider submitting change requests to prioritize and track the work.
+</p>
+<p>
+ Formal reviews are more wide-ranging and expensive. They provide for more balanced reviews from multiple
+ perspectives.&nbsp; However, formal reviews involve more people, which makes them more difficult to coordinate (thus
+ the need for formality) and expensive in terms of work hours.
+</p>
+<h3>
+ Two-tier reviews
+</h3>
+<p>
+ One technique to get the best of both worlds is to use staged, or "two-tier", reviews&nbsp;<a
+ class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[ADO03]</a>. The&nbsp;first tier is informal and performed by a smaller team, possibly
+ many times. The second&nbsp;tier is more formal and performed by the complete group, perhaps only once.
+</p>
+<p>
+ <strong>First-tier review:</strong> The authors of the requirements and the development team&nbsp;review the
+ requirements during the first-tier reviews to ensure that they are&nbsp;unambiguous, complete,&nbsp;correct and
+ consistent.&nbsp; It is important to include testers and developers to ensure that the requirements are verifiable and
+ feasible.&nbsp;These reviews&nbsp;determine whether the requirements are ready for the larger community to
+ review.&nbsp; First-tier reviews may be informal, formal, or a combination of the two.
+</p>
+<p>
+ <strong>Second-tier review:</strong> Involve the larger group&nbsp;during the higher-tier review to get more minds
+ working on the problem and to achieve concurrence that the requirements are suitable for implementation and validation.
+</p>
+<p>
+ At both stages, the checklists for the requirements work products are helpful.
+</p>
+<p>
+ Tiered reviews offer several benefits:
+</p>
+<ol>
+ <li>
+ Eliminate the noise caused by minor edits during the first-tier reviews, allowing subsequent reviews to focus on
+ functionality
+ </li>
+ <li>
+ Provide a professional look to the requirements, presenting both the requirements and their authors in the best
+ possible light
+ </li>
+ <li>
+ Safeguard the time of stakeholders who are reviewing the requirements, thus preventing "review burnout", or
+ diminished effectiveness from overload and stress
+ </li>
+ <li>
+ Provide the best opportunity for full, effective reviews.
+ </li>
+</ol>
+<h3>
+ Golden rules of reviewing
+</h3>
+<p>
+ Follow these golden&nbsp;rules of reviewing <a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[TEL06]</a>:
+</p>
+<ol>
+ <li>
+ <strong>Encourage criticism:</strong> Remember that people are improving the requirements, not criticizing you.
+ Even the harshest criticism often contains a grain of truth. Adopt the attitude that every suggestion is a gift.
+ </li>
+ <li>
+ <strong>Choose your best reviewers:</strong> A few specific people make the best reviewers, time and again.
+ Cultivate them.
+ </li>
+ <li>
+ <strong>Allow adequate time:</strong> It's not over until you have agreed upon and made the corrections.<br />
+ &nbsp;
+ </li>
</ol></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/entity_control_boundary_pattern.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/entity_control_boundary_pattern.xmi
index 3ca8222..ea603d5 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/entity_control_boundary_pattern.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/entity_control_boundary_pattern.xmi
@@ -1,201 +1,205 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-awaQ_2dwhGyKRoVKQ-esPQ" name="finding_analysis_classes,_uF-QYEAhEdq_UJTvM1DM2Q" guid="-awaQ_2dwhGyKRoVKQ-esPQ" changeDate="2008-09-04T03:21:52.000-0700" version="1.0.0">
- <mainDescription><p>
- When identifying the elements for a scenario of system behavior, you can align each participating element with one of
- three key perspectives: <b>Entity</b>, <b>Control</b>, or <b>Boundary</b>. Although specifics of languages, frameworks,
- and heuristics of quality design will drive the final design, a first cut that covers required system behavior can
- always be assembled with elements of these three perspectives.
-</p>
-<p>
- This pattern is similar to the Model View Controller pattern (described here [<a class="elementLinkWithUserText" href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#BUS96" guid="_9ToeIB83Edqsvps02rpOOg">BUS96</a>] and here [<a class="elementLinkWithUserText" href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#WIKP-MVC" guid="_9ToeIB83Edqsvps02rpOOg">WIKP-MVC</a>], among other places), but the Entity Control Boundary (ECB) pattern is not
- solely appropriate for dealing with user interfaces, and it gives the controller a slightly different role to play.
-</p>
-<h4 align="left">
- ECB&nbsp;pattern example
-</h4>
-<p>
- &nbsp;<img alt="" src="resources/ebc_diagram.jpg" />
-</p>
-<h1>
- Entity elements
-</h1>
-<p>
- An entity is a long-lived, passive element that is responsible for some meaningful chunk of information. This is not to
- say that entities are "data," while other design elements are "function." Entities perform behavior organized around
- some cohesive amount of data.
-</p>
-<p>
- An example of an entity for a customer service application is a Customer entity that manages all information about a
- customer. A design element for&nbsp;this entity would include data about the customer, behavior to manage the data,
- behavior to validate customer information&nbsp;and to perform other business calculations, such as "Is this customer
- allowed to purchase product X?"
-</p>
-<p>
- The identification of the entities as part of this pattern can be done many times at different levels of abstraction
- from the code, at different levels of granularity in size, and from the perspectives of different contexts. For
- example, you could do an analysis pass on a scenario of creating a marketing campaign and identify the customer element
- with various customer data elements, such as name and address, plus various required behaviors, such as the management
- of the name and address data and the ability to rate the customer based on some algorithm (such an application of this
- pattern would be abstract from code, coarse-grained, and have no specific context). Later, you could do a pass on the
- same scenario applying an architectural mechanism for database access that breaks the address out as its own element,
- moves the responsibility for storing and retrieving customers to a new control element, and identifies specific
- database decisions, such as the use of primary keys in the entities. (Such an application of this pattern would be
- closer to the code, finer-grained, and aligned with a database&nbsp;context.)
-</p>
-<h1>
- Control elements
-</h1>
-<p>
- A control element manages the flow of interaction of the scenario. A control element could manage the end-to-end
- behavior of a scenario or it could manage the interactions between a subset of the elements. Behavior and business
- rules relating to the information relevant to the scenario should be assigned to the entities; the control elements are
- responsible only for the flow of the scenario.
-</p>
-<p>
- CreateMarketingCampaign is an example of a control element for a customer service application. This design element
- would&nbsp;be responsive to certain front-end boundary elements and would collaborate with other entities,
- control&nbsp;elements, and back-end boundary elements to support the creation of a marketing campaign.
-</p>
-<p>
- As with the entity example here, there might be many passes over the identification of control elements. A first pass
- might be an analysis pass that identifies one control element for a scenario, with behavior to make sure that the
- design can support the flow of events. A&nbsp;subsequent pass might find controllers to manage reusable collaborations
- of low-level elements that will map to a specific code&nbsp;unit to be written.
-</p>
-<h1>
- Boundary elements
-</h1>
-<p>
- A boundary element lies on the periphery of a system or subsystem, but within it. For any scenario being considered
- either across the whole system or within some subsystem, some boundary elements will be "front end" elements that
- accept input from outside of the area under design, and other elements will be "back end," managing communication to
- supporting elements outside of the system or subsystem.
-</p>
-<p>
- Two examples of boundary elements for a customer service application might be a front end MarketingCampaignForm and a
- back end BudgetSystem element. The MarketingCampaignForm would manage the exchange of information between a user and
- the system, and the BudgetSystem would manage the exchange of information between the system and an external system
- that manages budgets.
-</p>
-<p>
- If the system communicates with another system (where that system could be anything from software to hardware units
- that the current system will use, such as printers, terminals, alarm devices, and sensors).&nbsp; An analysis pass
- could identify one boundary element for each external relevant to a scenario.
-</p>
-<p>
- Example:
-</p>
-<blockquote>
- <p>
- An automated teller machine (ATM) must communicate with the ATM network to ascertain whether a customer's bank
- number and PIN are correct, and whether the customer has sufficient funds to withdrawal the requested amount. The
- ATM network is an external system (from the perspective of the ATM); therefore, you would use a
- <strong>boundary</strong> class to represent it in a use-case analysis.
- </p>
-</blockquote>
-<p>
- Subsequently, these could be broken down into multiple boundary elements or small communities made up of collaborating
- elements of all three stereotypes. If the interfaces with the system are simple and well-defined, a single class may be
- sufficient to represent the external system. Often, however, these interfaces are too complex to be represented by
- using a single class; they often require complex collaborations of many classes. Moreover, interfaces between systems
- are often highly reusable across applications. As a result, in many cases, a component models the system interfaces
- more appropriately.&nbsp; The use of a component allows the interface to the external system to be defined and
- stabilized, while leaving the design details of the system interface hidden as the system evolves.
-</p>
-<h1>
- Walking through the scenario
-</h1>
-<p>
- You can walk through a scenario initiated by something outside of the boundaries of the system or subsystem being
- designed and distribute the responsibility to perform behavior supporting the scenario to the elements identified of
- each type. The appropriate design element responsible for each action in the scenario will be as described in the
- definition of each of the element types described here previously.
-</p>
-<p>
- In addition to identifying the behavior necessary to perform the scenario, the initiation of this behavior from design
- element to design element identifies the necessary relationships. There are certain appropriate relations between the
- participating elements. An element can communicate with other elements of the same kind. Control elements can
- communicate with each of the other two kinds, but entities and boundary elements should not communicate directly.
-</p>
-<p>
- This table shows appropriate links between design elements.
-</p>
-<table cellspacing="2" cellpadding="2" width="400" summary="Appropriate Links" border="1">
- <tbody>
- <tr>
- <td>
- </td>
- <th scope="col">
- <center>
- Entity
- </center>
- </th>
- <th scope="col">
- <center>
- Boundary
- </center>
- </th>
- <th scope="col">
- <center>
- Control
- </center>
- </th>
- </tr>
- <tr>
- <th scope="row">
- Entity
- </th>
- <td>
- <center>
- X
- </center>
- </td>
- <td>
- </td>
- <td>
- <center>
- X
- </center>
- </td>
- </tr>
- <tr>
- <th scope="row">
- Boundary
- </th>
- <td>
- </td>
- <td>
- </td>
- <td>
- <center>
- X
- </center>
- </td>
- </tr>
- <tr>
- <th scope="row">
- Control
- </th>
- <td>
- <center>
- X
- </center>
- </td>
- <td>
- <center>
- X
- </center>
- </td>
- <td>
- <center>
- X
- </center>
- </td>
- </tr>
- </tbody>
-</table>
-<p>
- By applying this pattern, you can put a robust design together that identifies the elements, behavior, and
- relationships necessary to support a scenario.
+ <mainDescription><p>
+ When identifying the elements for a scenario of system behavior, you can align each participating element with one of
+ three key perspectives: <b>Entity</b>, <b>Control</b>, or <b>Boundary</b>. Although specifics of languages, frameworks,
+ and heuristics of quality design will drive the final design, a first cut that covers required system behavior can
+ always be assembled with elements of these three perspectives.
+</p>
+<p>
+ This pattern is similar to the Model View Controller pattern (described here [<a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#BUS96"
+ guid="_9ToeIB83Edqsvps02rpOOg">BUS96</a>] and here [<a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#WIKP-MVC"
+ guid="_9ToeIB83Edqsvps02rpOOg">WIKP-MVC</a>], among other places), but the Entity Control Boundary (ECB) pattern is not
+ solely appropriate for dealing with user interfaces, and it gives the controller a slightly different role to play.
+</p>
+<h4 align="left">
+ ECB&nbsp;pattern example
+</h4>
+<p>
+ &nbsp;<img alt="" src="resources/ebc_diagram.jpg" />
+</p>
+<h3>
+ Entity elements
+</h3>
+<p>
+ An entity is a long-lived, passive element that is responsible for some meaningful chunk of information. This is not to
+ say that entities are "data," while other design elements are "function." Entities perform behavior organized around
+ some cohesive amount of data.
+</p>
+<p>
+ An example of an entity for a customer service application is a Customer entity that manages all information about a
+ customer. A design element for&nbsp;this entity would include data about the customer, behavior to manage the data,
+ behavior to validate customer information&nbsp;and to perform other business calculations, such as "Is this customer
+ allowed to purchase product X?"
+</p>
+<p>
+ The identification of the entities as part of this pattern can be done many times at different levels of abstraction
+ from the code, at different levels of granularity in size, and from the perspectives of different contexts. For
+ example, you could do an analysis pass on a scenario of creating a marketing campaign and identify the customer element
+ with various customer data elements, such as name and address, plus various required behaviors, such as the management
+ of the name and address data and the ability to rate the customer based on some algorithm (such an application of this
+ pattern would be abstract from code, coarse-grained, and have no specific context). Later, you could do a pass on the
+ same scenario applying an architectural mechanism for database access that breaks the address out as its own element,
+ moves the responsibility for storing and retrieving customers to a new control element, and identifies specific
+ database decisions, such as the use of primary keys in the entities. (Such an application of this pattern would be
+ closer to the code, finer-grained, and aligned with a database&nbsp;context.)
+</p>
+<h3>
+ Control elements
+</h3>
+<p>
+ A control element manages the flow of interaction of the scenario. A control element could manage the end-to-end
+ behavior of a scenario or it could manage the interactions between a subset of the elements. Behavior and business
+ rules relating to the information relevant to the scenario should be assigned to the entities; the control elements are
+ responsible only for the flow of the scenario.
+</p>
+<p>
+ CreateMarketingCampaign is an example of a control element for a customer service application. This design element
+ would&nbsp;be responsive to certain front-end boundary elements and would collaborate with other entities,
+ control&nbsp;elements, and back-end boundary elements to support the creation of a marketing campaign.
+</p>
+<p>
+ As with the entity example here, there might be many passes over the identification of control elements. A first pass
+ might be an analysis pass that identifies one control element for a scenario, with behavior to make sure that the
+ design can support the flow of events. A&nbsp;subsequent pass might find controllers to manage reusable collaborations
+ of low-level elements that will map to a specific code&nbsp;unit to be written.
+</p>
+<h3>
+ Boundary elements
+</h3>
+<p>
+ A boundary element lies on the periphery of a system or subsystem, but within it. For any scenario being considered
+ either across the whole system or within some subsystem, some boundary elements will be "front end" elements that
+ accept input from outside of the area under design, and other elements will be "back end," managing communication to
+ supporting elements outside of the system or subsystem.
+</p>
+<p>
+ Two examples of boundary elements for a customer service application might be a front end MarketingCampaignForm and a
+ back end BudgetSystem element. The MarketingCampaignForm would manage the exchange of information between a user and
+ the system, and the BudgetSystem would manage the exchange of information between the system and an external system
+ that manages budgets.
+</p>
+<p>
+ If the system communicates with another system (where that system could be anything from software to hardware units
+ that the current system will use, such as printers, terminals, alarm devices, and sensors).&nbsp; An analysis pass
+ could identify one boundary element for each external relevant to a scenario.
+</p>
+<p>
+ Example:
+</p>
+<blockquote>
+ <p>
+ An automated teller machine (ATM) must communicate with the ATM network to ascertain whether a customer's bank
+ number and PIN are correct, and whether the customer has sufficient funds to withdrawal the requested amount. The
+ ATM network is an external system (from the perspective of the ATM); therefore, you would use a
+ <strong>boundary</strong> class to represent it in a use-case analysis.
+ </p>
+</blockquote>
+<p>
+ Subsequently, these could be broken down into multiple boundary elements or small communities made up of collaborating
+ elements of all three stereotypes. If the interfaces with the system are simple and well-defined, a single class may be
+ sufficient to represent the external system. Often, however, these interfaces are too complex to be represented by
+ using a single class; they often require complex collaborations of many classes. Moreover, interfaces between systems
+ are often highly reusable across applications. As a result, in many cases, a component models the system interfaces
+ more appropriately.&nbsp; The use of a component allows the interface to the external system to be defined and
+ stabilized, while leaving the design details of the system interface hidden as the system evolves.
+</p>
+<h3>
+ Walking through the scenario
+</h3>
+<p>
+ You can walk through a scenario initiated by something outside of the boundaries of the system or subsystem being
+ designed and distribute the responsibility to perform behavior supporting the scenario to the elements identified of
+ each type. The appropriate design element responsible for each action in the scenario will be as described in the
+ definition of each of the element types described here previously.
+</p>
+<p>
+ In addition to identifying the behavior necessary to perform the scenario, the initiation of this behavior from design
+ element to design element identifies the necessary relationships. There are certain appropriate relations between the
+ participating elements. An element can communicate with other elements of the same kind. Control elements can
+ communicate with each of the other two kinds, but entities and boundary elements should not communicate directly.
+</p>
+<p>
+ This table shows appropriate links between design elements.
+</p>
+<table cellspacing="2" cellpadding="2" width="400" summary="Appropriate Links" border="1">
+ <tbody>
+ <tr>
+ <td>
+ </td>
+ <th scope="col">
+ <center>
+ Entity
+ </center>
+ </th>
+ <th scope="col">
+ <center>
+ Boundary
+ </center>
+ </th>
+ <th scope="col">
+ <center>
+ Control
+ </center>
+ </th>
+ </tr>
+ <tr>
+ <th scope="row">
+ Entity
+ </th>
+ <td>
+ <center>
+ X
+ </center>
+ </td>
+ <td>
+ </td>
+ <td>
+ <center>
+ X
+ </center>
+ </td>
+ </tr>
+ <tr>
+ <th scope="row">
+ Boundary
+ </th>
+ <td>
+ </td>
+ <td>
+ </td>
+ <td>
+ <center>
+ X
+ </center>
+ </td>
+ </tr>
+ <tr>
+ <th scope="row">
+ Control
+ </th>
+ <td>
+ <center>
+ X
+ </center>
+ </td>
+ <td>
+ <center>
+ X
+ </center>
+ </td>
+ <td>
+ <center>
+ X
+ </center>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>
+ By applying this pattern, you can put a robust design together that identifies the elements, behavior, and
+ relationships necessary to support a scenario.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/example_design_mechanisms.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/example_design_mechanisms.xmi
index 6438819..e180b5a 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/example_design_mechanisms.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/example_design_mechanisms.xmi
@@ -1,382 +1,379 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-mAo18f36rZ1R98kpZX7HMw" name="new_guideline,_K32gYAoBEdu0OeEVPFogVA" guid="-mAo18f36rZ1R98kpZX7HMw" changeDate="2008-03-11T11:28:25.000-0700" version="1.0.0">
- <mainDescription><h3>
- Design Mechanism Characteristics and Mapping
-</h3>
-<p>
- Consider the analysis mechanism for <strong>persistence</strong>.
-</p>
-<ul>
- <li>
- There might be a need for many (2,000) small objects (200 bytes each) to be stored for a few seconds, with no need
- for them to survive thereafter.
- </li>
- <li>
- There might be a need for several very large objects to be stored permanently on disk for several months, never
- updated, but with sophisticated means of retrieval.
- </li>
-</ul>
-<p>
- These objects require different support for persistency. The best option depends on the characteristics of the design
- mechanism:
-</p>
-<ul>
- <li>
- <b>In-memory storag</b><strong>e:</strong> For up to 1 Mb total (size x volume); very fast access for read, write,
- update.
- </li>
- <li>
- <b>Flash card</b><strong>:</strong> For up to 8 Mb; slow update and write access; moderate read access.
- </li>
- <li>
- <b>Binary file</b><strong>:</strong> For 100 Kb to 200 Mb; slow update; slow read-and-write access.
- </li>
- <li>
- <b>Database management system (DBMS)</b><strong>:</strong> For 100 Kb and upward (essentially no upper limit); even
- slower update and read-and-write access.
- </li>
-</ul>
-<p>
- Note that these speeds are rated as slow only as compared to in-memory storage. Obviously, in some environments,
- caching can improve apparent access times. (See Figure 1.)
-</p>
-<blockquote>
- <p align="center">
- <img title="Figure 1. Mapping Analysis Mechanisms to Design Mechanisms and Classes" height="221"
- alt="Mapping Analysis Mechanisms to Design Mechanisms and Classes" src="resources/co_dmec1.gif" width="372" />
- </p>
-</blockquote>
-<div align="center">
- <p>
- <strong>Figure 1. Mapping Analysis Mechanisms to Design Mechanisms and Classes</strong>
- </p>
- <h3 align="left">
- Mapping Design Mechanisms to Implementation Mechanisms
- </h3>
- <p align="left">
- The <b>persistence</b> design mechanisms can be mapped to implementation mechanisms as Figure 2 shows:
- </p>
- <p align="center">
- <img title="Figure 2. How persistence design mechanism map to implementation mechanism" height="216"
- alt="How persistence design mechanism map to implementation mechanism" src="resources/co_dmec2.gif"
- width="325" />
- </p>
- <p align="center">
- <strong>Figure 2. How persistence design mechanism map to implementation mechanism</strong>
- </p>
- <p align="left">
- A possible mapping between analysis mechanisms and design mechanisms. Dotted arrows mean "is specialized by,"
- implying that the characteristics of the design mechanisms are inherited from the analysis mechanisms but that they
- will be specialized and refined.
- </p>
- <p align="left">
- After you have finished optimizing the mechanisms, the following mappings exist (see Figure 3):
- </p>
- <blockquote>
- <p align="center">
- <img title="Figure 3. Mapping structure after optimizing the mechanisms" height="110"
- alt="Illustration of mapping structure after optimizing the mechanisms" src="resources/co_dmec3.gif"
- width="418" />
- </p>
- <p class="picturetext" align="center">
- <strong>Figure 3. Mapping structure after optimizing the mechanisms</strong>
- </p>
- <p class="picturetext" align="left">
- The design decisions for a client class in terms of mappings between mechanisms. The <font
- face="Courier New, Courier, mono">Flight</font> class needs two forms of persistency<strong>:</strong>
- <strong>in-memory storage</strong>, implemented by a predefined library routine, and <strong>a
- database,</strong> implemented with an off-the-shelf ObjectStorage product.
- </p>
- </blockquote>
- <p align="left">
- The map must be navigable in both directions to make it easy to determine client classes when changing
- implementation mechanisms.
- </p>
- <h4 align="left">
- Refining the mapping between design and implementation mechanisms
- </h4>
-</div>
-<p>
- Initially, the mapping between design mechanisms and implementation mechanisms is likely to be less than optimal, but
- it will get the project running, identify unforeseen risks, and trigger further investigations and evaluations. As the
- project continues and you gain more knowledge, you will need to refine the mapping.
-</p>
-<p>
- Proceed iteratively to refine the mapping between design and implementation mechanisms. Eliminate redundant paths,
- working both top-down and bottom-up.
-</p>
-<p>
- <b>Working top-down:</b> When working top-down (from top to bottom), new and refined use-case realizations will put new
- requirements on the necessary design mechanisms through the analysis mechanisms that you need. These new requirements
- might uncover additional characteristics of a design mechanism, forcing a split between mechanisms. A compromise
- between the system's complexity and its performance is also necessary:
-</p>
-<ul>
- <li>
- Too many different design mechanisms make the system too complex.
- </li>
- <li>
- Too few design mechanisms can create performance problems for implementation mechanisms that stretch the limits of
- the reasonable ranges of the values of their characteristics.
- </li>
-</ul>
-<p>
- <b>Working bottom-up:</b> When working bottom-up (from bottom to top) and investigating the available implementation
- mechanisms, you might find products that satisfy several design mechanisms at once, but force some adaptation or
- repartitioning of your design mechanisms. You want to minimize the number of implementation mechanisms you use, but too
- few of them can also lead to performance problems.
-</p>
-<p>
- After you decide to use a DBMS to store class A objects, you might be tempted to use it to store all objects in the
- system. This could be very inefficient or very cumbersome. Not all objects that require persistency need to be stored
- in the DBMS. Some objects may be persistent, but one application may access them frequently, while other applications
- access them only infrequently. A hybrid strategy, in which the object is read from the DBMS into memory and
- periodically synchronized, may be the best approach.
-</p>
-<blockquote>
- <p class="example">
- <b>Example</b>
- </p>
- <p class="example">
- A flight can be stored both in memory for fast access and in a DBMS for long-term persistency. However, this
- triggers a need for a mechanism to synchronize both.
- </p>
-</blockquote>
-<p>
- It is not uncommon to have more than one design mechanism associated with a client class as a compromise between
- different characteristics.
-</p>
-<p>
- Because implementation mechanisms often come in bundles in off-the-shelf components (operating systems and middleware
- products), some optimization based on cost, impedance mismatch, or uniformity of style needs to occur. Also, mechanisms
- are often interdependent, which makes clear separation of services into design mechanisms difficult.
-</p>
-<blockquote>
- <p class="example">
- <b>Examples</b>
- </p>
- <ul>
- <li>
- The notification mechanism can be based on the inter-process communication mechanism.
- </li>
- <li>
- The error reporting mechanism can be based on the persistency mechanism.
- </li>
- </ul>
-</blockquote>
-<p>
- Refinement continues over the whole Elaboration phase, and is always a compromise between:
-</p>
-<ul>
- <li>
- An exact fit with the requirements of the clients of the design mechanism, in terms of the expected
- characteristics.
- </li>
- <li>
- The cost and complexity of having too many different implementation mechanisms to acquire and integrate.
- </li>
-</ul>
-<p>
- The overall goal is always to have a simple, clean set of mechanisms that give conceptual integrity, simplicity, and
- elegance to a large system.
-</p>
-<h3>
- Describing Design Mechanisms
-</h3>
-<p>
- As with analysis mechanisms, design mechanisms can be modeled using a collaboration, which may instantiate one or more
- architectural or design patterns.
-</p>
-<blockquote>
- <p>
- <strong>Example: A persistence mechanism</strong>
- </p>
- <p>
- This example uses an instance of a pattern for RDBMS-based persistency drawn from <a
- href="http://java.sun.com/products/jdbc/index.html" target="_blank"><u>Java&trade; Database Connectivity (JDBC)</u></a>.
- Although we present the design here, JDBC supplies actual code for some of the classes. Therefore, it is a short
- step from what is presented here to an implementation mechanism.
- </p>
-</blockquote>
-<p>
- Figure 4, titled <strong>JDBC: Static view,</strong> shows the classes (actually, the classifier roles) in the
- collaboration.
-</p>
-<p align="center">
- <img title="Figure 4. JDBC: Static View" height="382"
- alt="Diagram of the figure titled Static View: JDBC shows the classes (actually, the classifier roles) in the collaboration. "
- src="resources/jdbc1.gif" width="571" />
-</p>
-<p align="center">
- <strong>Figure 4. JDBC: Static view</strong>
-</p>
-<p align="left">
- The yellow classes are the ones that were supplied. The others, in tan (<font
- face="Courier New, Courier, mono">myDBClass</font> and so on), were bound by the designer to create the mechanism.
-</p>
-<p align="left">
- In a Java database class, a client will work with a <b>DBClass</b> to read and write persistent data. The <font
- face="Courier New, Courier, mono">DBClass</font> is responsible for accessing the JDBC database, using the
- <b>DriverManager</b> class. Once a database <b>connection</b> is open, the <font
- face="Courier New, Courier, mono">DBClass</font> can then create SQL statements that will be sent to the underlying
- RDBMS and executed using the <b>Statement</b> class. The <font face="Courier New, Courier, mono">Statement</font> class
- is what communicates with the database. The result of the SQL query is returned in a <b>ResultSet</b> object.<span
- style="mso-spacerun: yes">&nbsp;</span>
-</p>
-<p align="left">
- The <b>DBClass</b> is responsible for making another class instance persistent. It understands the OO-to-RDBMS mapping
- and can interface with the RDBMS. The <font face="Courier New, Courier, mono">DBClass</font> flattens the object,
- writes it to the RDBMS, and then reads the object data from the RDBMS and builds the object. Every class that is
- persistent has a corresponding <font face="Courier New, Courier, mono">DBClass</font>.&nbsp;
-</p>
-<p align="left">
- The <b>PersistentClassList</b> is used to return a set of persistent objects as a result of a database query, for
- example: <font face="Courier New, Courier, mono">DBClass.read()</font>.
-</p>
-<p align="left">
- A series of dynamic views follow, in Figures 5 thorough 9, to show how the mechanism actually works.
-</p>
-<p align="center">
- <img title="Figure 5. JDBC: Initialize" height="146" alt="Diagram of JDBC: Initialize" src="resources/jdbc2.gif"
- width="285" />
-</p>
-<p align="center">
- <b>Figure5. JDBC: Initialize</b>
-</p>
-<p>
- Initialization must occur before any persistent class can be accessed.
-</p>
-<p>
- To initialize the connection to the database, the <font face="Courier New, Courier, mono">DBClass</font> must load the
- appropriate driver by calling the <font face="Courier New, Courier, mono">DriverManager getConnection()</font>
- operation with a URL, user, and password.
-</p>
-<p>
- The operation <font face="Courier New, Courier, mono">getConnection()</font> attempts to establish a connection to the
- given database URL. The driver manager attempts to select an appropriate driver from the set of registered JDBC
- drivers.
-</p>
-<blockquote>
- <p>
- <strong>Parameters</strong>
- </p>
- <blockquote>
- <p>
- <b>URL</b><strong>:</strong> A database URL in the form <font
- face="Courier New, Courier, mono">jdbc:subprotocol:subname</font>. This URL is used to locate the actual
- database server and is not Web-related, in this instance.
- </p>
- <p>
- <b>user</b><strong>:</strong> The database user who is making the connection.
- </p>
- <p>
- <b>pass</b><strong>:</strong> The user's password
- </p>
- </blockquote>
- <p>
- <strong>Returns</strong>
- </p>
- <blockquote>
- <p>
- A connection to the URL.
- </p>
- </blockquote>
-</blockquote>
-<p align="center">
- <img title="Figure 6. JDBC: Create" height="253" alt="Diagram of JDBC: Create" src="resources/jdbc3.gif"
- width="478" />
-</p>
-<p align="center">
- <b>Figure 6. JDBC: Create</b>
-</p>
-<p align="left">
- To create a new class, the persistency client asks the <font face="Courier New, Courier, mono">DBClass</font> to create
- the new class. The <font face="Courier New, Courier, mono">DBClass</font> creates a new instance of <font
- face="Courier New, Courier, mono">PersistentClass</font> with default values. The <font
- face="Courier New, Courier, mono">DBClass</font> then creates a new <font
- face="Courier New, Courier, mono">Statement</font> using the <font face="Courier New, Courier, mono">Connection class
- createStatement()</font> operation. The <font face="Courier New, Courier, mono">Statement</font> runs, and the data is
- added to the database.
-</p>
-<p align="center">
- <img title="Figure 7. JDBC: Read" height="352" alt="Diagram of JDBC: Read" src="resources/jdbc4.gif" width="600" />
-</p>
-<p align="center">
- <b>Figure 7. JDBC: Read</b>
-</p>
-<p>
- To read a persistent class, the persistency client asks the <font face="Courier New, Courier, mono">DBClass</font> to
- read. The <font face="Courier New, Courier, mono">DBClass</font> creates a new <font
- face="Courier New, Courier, mono">Statement</font> using the <font face="Courier New, Courier, mono">Connection class
- createStatement()</font> operation. The Statement is executed, and the data is returned in a <font
- face="Courier New, Courier, mono">ResultSet</font> object. The <font face="Courier New, Courier, mono">DBClass</font>
- then creates a new instance of the <font face="Courier New, Courier, mono">PersistentClass</font> and populates it with
- the retrieved data. The data is returned in a collection object, an instance of the <font
- face="Courier New, Courier, mono">PersistentClassList</font> class.
-</p>
-<p>
- <strong>Note:</strong>
-</p>
-<p>
- The string passed to <font face="Courier New, Courier, mono">executeQuery()</font> is not necessarily exactly the same
- string as the one passed into the <font face="Courier New, Courier, mono">read()</font>. The <font
- face="Courier New, Courier, mono">DBClass</font> will build the SQL query to retrieve the persistent data from the
- database, using the criteria passed into the <font face="Courier New, Courier, mono">read()</font>. This is because it
- is not useful for the client of the <font face="Courier New, Courier, mono">DBClass</font> to know the internal
- structure of the database to create a valid query. This knowledge is encapsulated within <font
- face="Courier New, Courier, mono">DBClass</font>.
-</p>
-<p align="center">
- <img title="Figure 8. JDBC: Update" height="255" alt="Diagram of JDBC: Update" src="resources/jdbc5.gif"
- width="473" />
-</p>
-<p align="center">
- <b>Figure 8. JDBC: Update</b>
-</p>
-<p>
- To update a class, the persistency client asks the <font face="Courier New, Courier, mono">DBClass</font> to update.
- The <font face="Courier New, Courier, mono">DBClass</font> retrieves the data from the given <font
- face="Courier New, Courier, mono">PersistentClass</font> object, and creates a new <font
- face="Courier New, Courier, mono">Statement</font> using the <font face="Courier New, Courier, mono">Connection class
- createStatement()</font> operation. Once the <font face="Courier New, Courier, mono">Statement</font> is built, the
- database is updated with the new data from the class.
-</p>
-<p>
- <strong>Remember:</strong> It is the job of the <font face="Courier New, Courier, mono">DBClass</font> to flatten the
- <font face="Courier New, Courier, mono">PersistentClass</font> and write it to the database. That is why it must be
- retrieved from the given <font face="Courier New, Courier, mono">PersistentClass</font> before creating the SQL <font
- face="Courier New, Courier, mono">Statement</font>.
-</p>
-<p>
- <strong>Note:</strong>
-</p>
-<p>
- In the above mechanism, the <font face="Courier New, Courier, mono">PersistentClass</font> must provide access routines
- for all persistent data so that <font face="Courier New, Courier, mono">DBClass</font> can access them. This provides
- external access to certain persistent attributes that would have been private otherwise. This is a price you have to
- pay to pull the persistence knowledge out of the class that encapsulates the data.
-</p>
-<p align="center">
- <img title="Figure 9. JDBC: Delete" height="255" alt="Diagram of JDBC: Delete" src="resources/jdbc6.gif"
- width="473" />
-</p>
-<p align="center">
- <b>Figure 9. JDBC: Delete</b>
-</p>
-<p align="left">
- To delete a class, the persistency client asks the <font face="Courier New, Courier, mono">DBClass</font> to delete the
- <font face="Courier New, Courier, mono">PersistentClass</font>. The <font
- face="Courier New, Courier, mono">DBClass</font> creates a new <font face="Courier New, Courier, mono">Statement</font>
- using the <font face="Courier New, Courier, mono">Connection class createStatement()</font> operation. The <font
- face="Courier New, Courier, mono">Statement</font> is executed and the data is removed from the database.
-</p>
-<p align="left">
- In the actual implementation of this design, you would make some decisions about the mapping of <font
- face="Courier New, Courier, mono">DBClass</font> to the persistent classes, such as having one <font
- face="Courier New, Courier, mono">DBClass</font> per persistent class and allocating them to appropriate packages.
- These packages will depend on the supplied java.sql file (see <a
- href="http://java.sun.com/products/jdbc/index.jsp">JDBC: API Documentation</a>) package that contains the supporting
- classes <font face="Courier New, Courier, mono">DriverManager, Connection, Statement</font>, and <font
- face="Courier New, Courier, mono">ResultSet</font>.
+ <mainDescription><h3>
+ Design Mechanism Characteristics and Mapping
+</h3>
+<p>
+ Consider the analysis mechanism for <strong>persistence</strong>.
+</p>
+<ul>
+ <li>
+ There might be a need for many (2,000) small objects (200 bytes each) to be stored for a few seconds, with no need
+ for them to survive thereafter.
+ </li>
+ <li>
+ There might be a need for several very large objects to be stored permanently on disk for several months, never
+ updated, but with sophisticated means of retrieval.
+ </li>
+</ul>
+<p>
+ These objects require different support for persistency. The best option depends on the characteristics of the design
+ mechanism:
+</p>
+<ul>
+ <li>
+ <b>In-memory storag</b><strong>e:</strong> For up to 1 Mb total (size x volume); very fast access for read, write,
+ update.
+ </li>
+ <li>
+ <b>Flash card</b><strong>:</strong> For up to 8 Mb; slow update and write access; moderate read access.
+ </li>
+ <li>
+ <b>Binary file</b><strong>:</strong> For 100 Kb to 200 Mb; slow update; slow read-and-write access.
+ </li>
+ <li>
+ <b>Database management system (DBMS)</b><strong>:</strong> For 100 Kb and upward (essentially no upper limit); even
+ slower update and read-and-write access.
+ </li>
+</ul>
+<p>
+ Note that these speeds are rated as slow only as compared to in-memory storage. Obviously, in some environments,
+ caching can improve apparent access times. (See Figure 1.)
+</p>
+<blockquote>
+ <p align="center">
+ <img title="Figure 1. Mapping Analysis Mechanisms to Design Mechanisms and Classes" height="221"
+ alt="Mapping Analysis Mechanisms to Design Mechanisms and Classes" src="resources/co_dmec1.gif" width="372" />
+ </p>
+</blockquote>
+<div align="center">
+ <p>
+ <strong>Figure 1. Mapping Analysis Mechanisms to Design Mechanisms and Classes</strong>
+ </p>
+ <h3 align="left">
+ Mapping Design Mechanisms to Implementation Mechanisms
+ </h3>
+ <p align="left">
+ The <b>persistence</b> design mechanisms can be mapped to implementation mechanisms as Figure 2 shows:
+ </p>
+ <p align="center">
+ <img title="Figure 2. How persistence design mechanism map to implementation mechanism" height="216"
+ alt="How persistence design mechanism map to implementation mechanism" src="resources/co_dmec2.gif" width="325" />
+ </p>
+ <p align="center">
+ <strong>Figure 2. How persistence design mechanism map to implementation mechanism</strong>
+ </p>
+ <p align="left">
+ A possible mapping between analysis mechanisms and design mechanisms. Dotted arrows mean "is specialized by,"
+ implying that the characteristics of the design mechanisms are inherited from the analysis mechanisms but that they
+ will be specialized and refined.
+ </p>
+ <p align="left">
+ After you have finished optimizing the mechanisms, the following mappings exist (see Figure 3):
+ </p>
+ <blockquote>
+ <p align="center">
+ <img title="Figure 3. Mapping structure after optimizing the mechanisms" height="110"
+ alt="Illustration of mapping structure after optimizing the mechanisms" src="resources/co_dmec3.gif"
+ width="418" />
+ </p>
+ <p class="picturetext" align="center">
+ <strong>Figure 3. Mapping structure after optimizing the mechanisms</strong>
+ </p>
+ <p class="picturetext" align="left">
+ The design decisions for a client class in terms of mappings between mechanisms. <font
+ face="Courier New, Courier, mono">Flight</font> class needs two forms of persistency<strong>:</strong>
+ <strong>in-memory storage</strong>, implemented by a predefined library routine, and <strong>a
+ database,</strong> implemented with an off-the-shelf ObjectStorage product.
+ </p>
+ </blockquote>
+ <p align="left">
+ The map must be navigable in both directions to make it easy to determine client classes when changing
+ implementation mechanisms.
+ </p>
+ <h4 align="left">
+ Refining the mapping between design and implementation mechanisms
+ </h4>
+</div>
+<p>
+ Initially, the mapping between design mechanisms and implementation mechanisms is likely to be less than optimal, but
+ it will get the project running, identify unforeseen risks, and trigger further investigations and evaluations. As the
+ project continues and you gain more knowledge, you will need to refine the mapping.
+</p>
+<p>
+ Proceed iteratively to refine the mapping between design and implementation mechanisms. Eliminate redundant paths,
+ working both top-down and bottom-up.
+</p>
+<p>
+ <b>Working top-down:</b> When working top-down (from top to bottom), new and refined use-case realizations will put new
+ requirements on the necessary design mechanisms through the analysis mechanisms that you need. These new requirements
+ might uncover additional characteristics of a design mechanism, forcing a split between mechanisms. A compromise
+ between the system's complexity and its performance is also necessary:
+</p>
+<ul>
+ <li>
+ Too many different design mechanisms make the system too complex.
+ </li>
+ <li>
+ Too few design mechanisms can create performance problems for implementation mechanisms that stretch the limits of
+ the reasonable ranges of the values of their characteristics.
+ </li>
+</ul>
+<p>
+ <b>Working bottom-up:</b> When working bottom-up (from bottom to top) and investigating the available implementation
+ mechanisms, you might find products that satisfy several design mechanisms at once, but force some adaptation or
+ repartitioning of your design mechanisms. You want to minimize the number of implementation mechanisms you use, but too
+ few of them can also lead to performance problems.
+</p>
+<p>
+ After you decide to use a DBMS to store class A objects, you might be tempted to use it to store all objects in the
+ system. This could be very inefficient or very cumbersome. Not all objects that require persistency need to be stored
+ in the DBMS. Some objects may be persistent, but one application may access them frequently, while other applications
+ access them only infrequently. A hybrid strategy, in which the object is read from the DBMS into memory and
+ periodically synchronized, may be the best approach.
+</p>
+<blockquote>
+ <p class="example">
+ <b>Example</b>
+ </p>
+ <p class="example">
+ A flight can be stored both in memory for fast access and in a DBMS for long-term persistency. However, this
+ triggers a need for a mechanism to synchronize both.
+ </p>
+</blockquote>
+<p>
+ It is not uncommon to have more than one design mechanism associated with a client class as a compromise between
+ different characteristics.
+</p>
+<p>
+ Because implementation mechanisms often come in bundles in off-the-shelf components (operating systems and middleware
+ products), some optimization based on cost, impedance mismatch, or uniformity of style needs to occur. Also, mechanisms
+ are often interdependent, which makes clear separation of services into design mechanisms difficult.
+</p>
+<blockquote>
+ <p class="example">
+ <b>Examples</b>
+ </p>
+ <ul>
+ <li>
+ The notification mechanism can be based on the inter-process communication mechanism.
+ </li>
+ <li>
+ The error reporting mechanism can be based on the persistency mechanism.
+ </li>
+ </ul>
+</blockquote>
+<p>
+ Refinement continues over the whole Elaboration phase, and is always a compromise between:
+</p>
+<ul>
+ <li>
+ An exact fit with the requirements of the clients of the design mechanism, in terms of the expected
+ characteristics.
+ </li>
+ <li>
+ The cost and complexity of having too many different implementation mechanisms to acquire and integrate.
+ </li>
+</ul>
+<p>
+ The overall goal is always to have a simple, clean set of mechanisms that give conceptual integrity, simplicity, and
+ elegance to a large system.
+</p>
+<h3>
+ Describing Design Mechanisms
+</h3>
+<p>
+ As with analysis mechanisms, design mechanisms can be modeled using a collaboration, which may instantiate one or more
+ architectural or design patterns.
+</p>
+<blockquote>
+ <p>
+ <strong>Example: A persistence mechanism</strong>
+ </p>
+ <p>
+ This example uses an instance of a pattern for RDBMS-based persistency drawn from <a
+ href="http://java.sun.com/products/jdbc/index.html" target="_blank"><u>Java&trade; Database Connectivity (JDBC)</u></a>.
+ Although we present the design here, JDBC supplies actual code for some of the classes. Therefore, it is a short
+ step from what is presented here to an implementation mechanism.
+ </p>
+</blockquote>
+<p>
+ Figure 4, titled <strong>JDBC: Static view,</strong> shows the classes (actually, the classifier roles) in the
+ collaboration.
+</p>
+<p align="center">
+ <img title="Figure 4. JDBC: Static View" height="382"
+ alt="Diagram of the figure titled Static View: JDBC shows the classes (actually, the classifier roles) in the collaboration. "
+ src="resources/jdbc1.gif" width="571" />
+</p>
+<p align="center">
+ <strong>Figure 4. JDBC: Static view</strong>
+</p>
+<p align="left">
+ The yellow classes are the ones that were supplied. The others, in tan (<font
+ face="Courier New, Courier, mono">myDBClass</font> class and so on), were bound by the designer to create the
+ mechanism.
+</p>
+<p align="left">
+ In a Java database class, a client will work with a <b>DBClass</b> to read and write persistent data. <font
+ face="Courier New, Courier, mono">DBClass</font> is responsible for accessing the JDBC database, using the
+ <b>DriverManager</b> class. Once a database <b>connection</b> is open, the <font
+ face="Courier New, Courier, mono">DBClass</font> can then create SQL statements that will be sent to the underlying
+ RDBMS and executed using the <b>Statement</b> class. <font face="Courier New, Courier, mono">Statement</font> class is
+ what communicates with the database. The result of the SQL query is returned in a <b>ResultSet</b> object.<span
+ style="mso-spacerun: yes">&nbsp;</span>
+</p>
+<p align="left">
+ The <b>DBClass</b> is responsible for making another class instance persistent. It understands the OO-to-RDBMS mapping
+ and can interface with the RDBMS. <font face="Courier New, Courier, mono">DBClass</font> flattens the object, writes it
+ to the RDBMS, and then reads the object data from the RDBMS and builds the object. Every class that is persistent has a
+ corresponding <font face="Courier New, Courier, mono">DBClass</font>.&nbsp;
+</p>
+<p align="left">
+ The <b>PersistentClassList</b> is used to return a set of persistent objects as a result of a database query, for
+ example: <font face="Courier New, Courier, mono">"DBClass.read()"</font>.
+</p>
+<p align="left">
+ A series of dynamic views follow, in Figures 5 thorough 9, to show how the mechanism actually works.
+</p>
+<p align="center">
+ <img title="Figure 5. JDBC: Initialize" height="146" alt="Diagram of JDBC: Initialize" src="resources/jdbc2.gif"
+ width="285" />
+</p>
+<p align="center">
+ <b>Figure5. JDBC: Initialize</b>
+</p>
+<p>
+ Initialization must occur before any persistent class can be accessed.
+</p>
+<p>
+ To initialize the connection to the database, the <font face="Courier New, Courier, mono">DBClass</font> must load the
+ appropriate driver by calling the <font face="Courier New, Courier, mono">DriverManager getConnection()</font>
+ operation with a URL, user, and password.
+</p>
+<p>
+ The operation <font face="Courier New, Courier, mono">getConnection()</font> attempts to establish a connection to the
+ given database URL. The driver manager attempts to select an appropriate driver from the set of registered JDBC
+ drivers.
+</p>
+<blockquote>
+ <p>
+ <strong>Parameters</strong>
+ </p>
+ <blockquote>
+ <p>
+ <b>URL</b><strong>:</strong> A database URL in the form <font
+ face="Courier New, Courier, mono">jdbc:subprotocol:subname</font>. This URL is used to locate the actual
+ database server and is not Web-related, in this instance.
+ </p>
+ <p>
+ <b>user</b><strong>:</strong> The database user who is making the connection.
+ </p>
+ <p>
+ <b>pass</b><strong>:</strong> The user's password
+ </p>
+ </blockquote>
+ <p>
+ <strong>Returns</strong>
+ </p>
+ <blockquote>
+ <p>
+ A connection to the URL.
+ </p>
+ </blockquote>
+</blockquote>
+<p align="center">
+ <img title="Figure 6. JDBC: Create" height="253" alt="Diagram of JDBC: Create" src="resources/jdbc3.gif" width="478" />
+</p>
+<p align="center">
+ <b>Figure 6. JDBC: Create</b>
+</p>
+<p align="left">
+ To create a new class, the persistency client asks the <font face="Courier New, Courier, mono">DBClass</font> object to
+ create the new class. <font face="Courier New, Courier, mono">DBClass</font> creates a new instance of a class "<font
+ face="Courier New, Courier, mono">PersistentClass</font>". <font face="Courier New, Courier, mono">DBClass</font>
+ object then creates a new <font face="Courier New, Courier, mono">Statement</font> object using <font
+ face="Courier New, Courier, mono">Connection class createStatement()</font> operation. <font
+ face="Courier New, Courier, mono">Statement</font> object runs, and the data is added to the database.
+</p>
+<p align="center">
+ <img title="Figure 7. JDBC: Read" height="352" alt="Diagram of JDBC: Read" src="resources/jdbc4.gif" width="600" />
+</p>
+<p align="center">
+ <b>Figure 7. JDBC: Read</b>
+</p>
+<p>
+ To read a persistent class, the persistency client asks the <font face="Courier New, Courier, mono">DBClass</font>
+ object to read. <font face="Courier New, Courier, mono">DBClass</font> object creates a new <font
+ face="Courier New, Courier, mono">Statement</font> object using <font face="Courier New, Courier, mono">Connection
+ class createStatement()</font> operation. The Statement is executed, and the data is returned in the <font
+ face="Courier New, Courier, mono">ResultSet</font> object. <font face="Courier New, Courier, mono">DBClass</font>
+ object then creates a new instance of the <font face="Courier New, Courier, mono">PersistentClass</font> class and
+ populates it with the retrieved data. The data is returned in a collection object, an instance of <font
+ face="Courier New, Courier, mono">PersistentClassList</font> class.
+</p>
+<p>
+ <strong>Note:</strong>
+</p>
+<p>
+ The string passed to the <font face="Courier New, Courier, mono">"executeQuery()"</font> method is not necessarily
+ exactly the same string as the one passed into the method <font face="Courier New, Courier, mono">"read()"</font>.
+ <font face="Courier New, Courier, mono">DBClass</font> object will build the SQL query to retrieve the persistent data
+ from the database, using the criteria passed into the method <font face="Courier New, Courier, mono">"read()"</font>.
+ This is because the client of the <font face="Courier New, Courier, mono">DBClass</font> object does not need to know
+ the internal structure of the database to create a valid query. This knowledge is encapsulated within the object <font
+ face="Courier New, Courier, mono">"DBClass"</font>.
+</p>
+<p align="center">
+ <img title="Figure 8. JDBC: Update" height="255" alt="Diagram of JDBC: Update" src="resources/jdbc5.gif" width="473" />
+</p>
+<p align="center">
+ <b>Figure 8. JDBC: Update</b>
+</p>
+<p>
+ To update a class, the persistency client asks the <font face="Courier New, Courier, mono">DBClass</font> object to
+ update. <font face="Courier New, Courier, mono">DBClass</font> object retrieves the data from the given object "<font
+ face="Courier New, Courier, mono">PersistentClass</font>". It creates a new object "<font
+ face="Courier New, Courier, mono">Statement</font>" using the operation "<font
+ face="Courier New, Courier, mono">Connection class createStatement()</font>". Once <font
+ face="Courier New, Courier, mono">Statement</font> object is built, the database is updated with the new data from the
+ class.
+</p>
+<p>
+ <strong>Remember:</strong> It is the job of <font face="Courier New, Courier, mono">DBClass</font> object to flatten
+ the object <font face="Courier New, Courier, mono">"PersistentClass"</font>, and write it to the database. That is why
+ it must be retrieved from the given object "<font face="Courier New, Courier, mono">PersistentClass</font>" before
+ creating the SQL <font face="Courier New, Courier, mono">Statement</font>.
+</p>
+<p>
+ <strong>Note:</strong>
+</p>
+<p>
+ In the above mechanism, the <font face="Courier New, Courier, mono">PersistentClass</font> must provide access routines
+ for all persistent data so that the <font face="Courier New, Courier, mono">DBClass</font> can access them. This
+ provides external access to certain persistent attributes that would have been private otherwise. This is a price you
+ have to pay to pull the persistence knowledge out of the class that encapsulates the data.
+</p>
+<p align="center">
+ <img title="Figure 9. JDBC: Delete" height="255" alt="Diagram of JDBC: Delete" src="resources/jdbc6.gif" width="473" />
+</p>
+<p align="center">
+ <b>Figure 9. JDBC: Delete</b>
+</p>
+<p align="left">
+ To delete a class, the persistency client asks the <font face="Courier New, Courier, mono">DBClass</font> object to
+ delete <font face="Courier New, Courier, mono">PersistentClass</font>. <font
+ face="Courier New, Courier, mono">DBClass</font> object creates a new object "<font
+ face="Courier New, Courier, mono">Statement</font>" using the operation "<font
+ face="Courier New, Courier, mono">Connection class createStatement()</font>". <font
+ face="Courier New, Courier, mono">Statement</font> object is executed and the data is removed from the database.
+</p>
+<p align="left">
+ In the actual implementation of this design, you would make some decisions about the mapping of the <font
+ face="Courier New, Courier, mono">DBClass</font> object to the persistent classes, such as having one <font
+ face="Courier New, Courier, mono">DBClass</font> per persistent class and allocating them to appropriate packages.
+ These packages will depend on the supplied java.sql file (see <a
+ href="http://java.sun.com/products/jdbc/index.jsp">JDBC: API Documentation</a>) package that contains the supporting
+ classes <font face="Courier New, Courier, mono">"DriverManager", "Connection", "Statement", "ResultSet"</font>.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/identify_common_architectural_mechanisms.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/identify_common_architectural_mechanisms.xmi
index dc4c132..9d25bdd 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/identify_common_architectural_mechanisms.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/identify_common_architectural_mechanisms.xmi
@@ -1,242 +1,242 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-oG4WGxO_LjkvjTlqyYrCqA" name=",_M2lNcJo7Ed2Jdb_Cbj3yAA" guid="-oG4WGxO_LjkvjTlqyYrCqA" changeDate="2008-10-14T03:01:06.000-0700" version="7.5.0">
- <mainDescription><table cellspacing="0" cellpadding="2" width="85%" summary="Example Architectural Mechanisms" border="1" valign="top">
- <tbody>
- <tr>
- <th scope="col">
- Architectural Mechanism
- </th>
- <th scope="col">
- Description
- </th>
- </tr>
- <tr>
- <td>
- Availability
- </td>
- <td>
- The percentage of time that the system must be available for use, including planned outages.
- </td>
- </tr>
- <tr>
- <td>
- Archiving
- </td>
- <td>
- Provides a means to move data from active storage when it has reached a specific state.
- </td>
- </tr>
- <tr>
- <td>
- Auditing
- </td>
- <td>
- Provides audit trails of system execution.
- </td>
- </tr>
- <tr>
- <td>
- Communication
- </td>
- <td>
- A mechanism for handling inter-process communication.
- </td>
- </tr>
- <tr>
- <td>
- Debugging
- </td>
- <td>
- Provides elements to support application debugging.
- </td>
- </tr>
- <tr>
- <td>
- Disaster Recovery
- </td>
- <td>
- Provides facilities to recover systems, application, data and networks.
- </td>
- </tr>
- <tr>
- <td>
- Error Management
- </td>
- <td>
- Allows errors to be detected, propagated, and reported.
- </td>
- </tr>
- <tr>
- <td>
- Event Management
- </td>
- <td>
- Supports the use of asynchronous events within a system.
- </td>
- </tr>
- <tr>
- <td>
- Graphics
- </td>
- <td>
- Supports user interface services, such as 3D rendering.
- </td>
- </tr>
- <tr>
- <td>
- Information Exchange
- </td>
- <td>
- Supports information interchange across technical and organizational boundaries with appropriate semantic
- and format translations.
- </td>
- </tr>
- <tr>
- <td>
- Licensing
- </td>
- <td>
- Provides services for acquiring, installing, tracking, and monitoring license usage. Might be required as
- part of authorizing corporate bodies.
- </td>
- </tr>
- <tr>
- <td>
- Localization / Internationalization
- </td>
- <td>
- Provides facilities for supporting multiple human languages and rendering the language preferred by the
- user.
- </td>
- </tr>
- <tr>
- <td>
- Mail
- </td>
- <td>
- Services that allow applications to send and receive electronic mail.
- </td>
- </tr>
- <tr>
- <td>
- Mega-data
- </td>
- <td>
- Support for handling very large amounts of data.
- </td>
- </tr>
- <tr>
- <td>
- Memory Management
- </td>
- <td>
- Services for abstracting how memory is allocated and freed.
- </td>
- </tr>
- <tr>
- <td>
- Meta-data
- </td>
- <td>
- Supports the runtime introspection of components and data.
- </td>
- </tr>
- <tr>
- <td>
- Online help
- </td>
- <td>
- Provides online help capability
- </td>
- </tr>
- <tr>
- <td>
- Persistence
- </td>
- <td>
- Services to handle the reading and writing of stored data.
- </td>
- </tr>
- <tr>
- <td>
- Printing
- </td>
- <td>
- Provides facilities for interfacing with printers.
- </td>
- </tr>
- <tr>
- <td>
- Process Management
- </td>
- <td>
- Provides support for the management of processes and threads.
- </td>
- </tr>
- <tr>
- <td>
- Reporting
- </td>
- <td>
- Provides flexible reporting facilities
- </td>
- </tr>
- <tr>
- <td>
- Resource Management
- </td>
- <td>
- Provides support for the management of expensive resources, such as database connections.
- </td>
- </tr>
- <tr>
- <td>
- Scheduling
- </td>
- <td>
- Provides the ability to execute tasks at a specified time.
- </td>
- </tr>
- <tr>
- <td>
- Security
- </td>
- <td>
- Provides services to protect access to certain resources or information.
- </td>
- </tr>
- <tr>
- <td>
- System Management
- </td>
- <td>
- Services that facilitate management of applications in an operational environment.
- </td>
- </tr>
- <tr>
- <td>
- Time
- </td>
- <td>
- Services to synchronize time on a network, and to translate times into different time zones.
- </td>
- </tr>
- <tr>
- <td>
- Transaction Management
- </td>
- <td>
- A mechanism for handling ACID transactions.
- </td>
- </tr>
- <tr>
- <td>
- Workflow
- </td>
- <td>
- Support for the movement of documents and other items of work, typically through an organization.
- </td>
- </tr>
- </tbody>
+ <mainDescription><table cellspacing="0" cellpadding="2" width="85%" summary="Example Architectural Mechanisms" border="1" valign="top">
+ <tbody>
+ <tr>
+ <th scope="col">
+ Architectural Mechanism
+ </th>
+ <th scope="col">
+ Description
+ </th>
+ </tr>
+ <tr>
+ <td>
+ Availability
+ </td>
+ <td>
+ The percentage of time that the system must be available for use, including planned outages.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Archiving
+ </td>
+ <td>
+ Provides a means to move data from active storage when it has reached a specific state.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Auditing
+ </td>
+ <td>
+ Provides audit trails of system execution.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Communication
+ </td>
+ <td>
+ A mechanism for handling inter-process communication.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Debugging
+ </td>
+ <td>
+ Provides elements to support application debugging.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Disaster Recovery
+ </td>
+ <td>
+ Provides facilities to recover systems, application, data and networks.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Error Management
+ </td>
+ <td>
+ Allows errors to be detected, propagated, and reported.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Event Management
+ </td>
+ <td>
+ Supports the use of asynchronous events within a system.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Graphics
+ </td>
+ <td>
+ Supports user interface services, such as 3D rendering.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Information Exchange
+ </td>
+ <td>
+ Supports information interchange across technical and organizational boundaries with appropriate semantic
+ and format translations.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Licensing
+ </td>
+ <td>
+ Provides services for acquiring, installing, tracking, and monitoring license usage. Might be required as
+ part of authorizing corporate bodies.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Localization / Internationalization
+ </td>
+ <td>
+ Provides facilities for supporting multiple human languages and rendering the language preferred by the
+ user.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Mail
+ </td>
+ <td>
+ Services that allow applications to send and receive electronic mail.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Mega-data
+ </td>
+ <td>
+ Support for handling very large amounts of data.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Memory Management
+ </td>
+ <td>
+ Services for abstracting how memory is allocated and freed.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Meta-data
+ </td>
+ <td>
+ Supports the runtime introspection of components and data.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Online help
+ </td>
+ <td>
+ Provides online help capability
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Persistence
+ </td>
+ <td>
+ Services to handle the reading and writing of stored data.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Printing
+ </td>
+ <td>
+ Provides facilities for interfacing with printers.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Process Management
+ </td>
+ <td>
+ Provides support for the management of processes and threads.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Reporting
+ </td>
+ <td>
+ Provides flexible reporting facilities
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Resource Management
+ </td>
+ <td>
+ Provides support for the management of expensive resources, such as database connections.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Scheduling
+ </td>
+ <td>
+ Provides the ability to execute tasks at a specified time.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Security
+ </td>
+ <td>
+ Provides services to protect access to certain resources or information.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ System Management
+ </td>
+ <td>
+ Services that facilitate management of applications in an operational environment.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Time
+ </td>
+ <td>
+ Services to synchronize time on a network, and to translate times into different time zones.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Transaction Management
+ </td>
+ <td>
+ A mechanism for handling ACID transactions.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Workflow
+ </td>
+ <td>
+ Support for the movement of documents and other items of work, typically through an organization.
+ </td>
+ </tr>
+ </tbody>
</table></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/layering.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/layering.xmi
index 00fb588..e3c2288 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/layering.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/layering.xmi
@@ -1,134 +1,137 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_lbGQwMM3EdmSIPI87WLu3g" name="layering,_0gpkAMlgEdmt3adZL5Dmdw" guid="_lbGQwMM3EdmSIPI87WLu3g" changeDate="2008-02-11T10:31:51.000-0800" version="1.0.0">
- <mainDescription><p>
- Layering&nbsp; is&nbsp;one of the most&nbsp;commonly used&nbsp;approaches for structuring and decomposing systems.
- Layering logically partitions the system into sets of components with certain rules regarding how relationships can be
- formed between them. Layering provides a way to restrict inter-subsystem dependencies, with the result that the system
- is more loosely coupled and more easily maintained.
-</p>
-<p>
- Consider the number and purpose of the layers carefully. Do not over-complicate the solution by defining more layers
- than are needed to meet the needs of the solution. More layers can always be added in the future to meet new
- requirements. Removing layers is not always as easy and may introduce risks into the project.
-</p>
-<p>
- The criteria for grouping elements into layers follows a few patterns:
-</p>
-<ul>
- <li>
- <b>Visibility</b><strong>:</strong> Elements may depend only on components in the same layer and the next-lower
- layer.
- </li>
- <li>
- <b>Volatility</b><strong>:</strong>
- <ul>
- <li>
- <b>In the highest layers</b>, put elements that vary when user requirements change.
- </li>
- <li>
- <b>In the lowest layers</b>, put elements that vary when the implementation platform changes (hardware,
- language, operating system, database, and so forth).
- </li>
- <li>
- <strong>Sandwiched in the middle</strong>, put elements that are generally applicable across wide ranges of
- systems and implementation environments.
- </li>
- <li>
- <strong>Add layers</strong> when additional partitions within these broad categories help to organize the
- model.
- </li>
- </ul>
- </li>
- <li>
- <b>Generality</b><strong>:</strong> Abstract elements tend to be placed in the lower layers. If not
- implementation-specific, they tend to gravitate toward the middle layers.
- </li>
- <li>
- <b>Number of layers.</b> For a small system, three layers are typically sufficient.&nbsp;A three-layer architecture
- of&nbsp;Presentation, Business, and Data layers is very common in information systems.&nbsp; For a complex system,
- five to seven layers could be appropriate. For any degree of complexity, more than 10 layers should be viewed with
- suspicion that increases with the number of layers.
- </li>
-</ul>
-<p>
- Failure to restrict dependencies according to the visibility criteria mentioned above can cause architectural
- degradation and make the system difficult to extend and maintain.
-</p>
-<p>
- Allowable exceptions to the visibility rule include cases where components need direct access to lower-layer services
- beyond the next-lower layer. Make a decision about how to handle primitive services that are needed throughout the
- system, such as printing, sending messages, and so forth. There is little value in restricting messages to lower layers
- if the solution is to effectively implement call pass-throughs in the intermediate layers.&nbsp;&nbsp;This usage of a
- less strict rule on dependencies down through the layers is sometimes called a Relaxed Layered Architecture (<a class="elementlinkwithusertext" href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#BUS96" guid="_9ToeIB83Edqsvps02rpOOg">[BUS96]</a>).
-</p>
-<h4>
- <a id="PartitioningPatterns" name="PartitioningPatterns">Partitioning patterns</a>
-</h4>
-<p>
- Within the top layers of the system, additional partitioning may help organize the model. The following guidelines for
- partitioning present different issues to consider:
-</p>
-<p>
- <b>User organization</b><strong>:</strong> Elements may be organized along lines that mirror the organization of
- functionality in the business organization (partitioning occurs along departmental or user role lines). This
- partitioning often occurs early in the design&nbsp;due to&nbsp;an existing enterprise model that is strongly
- partitioned according to the structure of the organization. This pattern usually affects only the top few layers of
- application-specific services and can often disappear as the design evolves.
-</p>
-<ul>
- <li>
- <p>
- Partitioning along user-organization lines can be a good starting point for the model.
- </p>
- </li>
- <li>
- <p>
- The structure of the user organization is not stable over a long period of time because business
- reorganizations occur; therefore, it is not a good long-term basis for system partitioning. The internal
- organization of the system should enable the system to evolve and be maintained independently of the
- organization of the business that it supports.
- </p>
- </li>
-</ul>
-<p>
- <b>Areas of competence and skills:</b> Elements may be organized to partition responsibilities among different groups
- within the development organization. Typically, this occurs in the middle and lower layers of the system, and reflects
- the need for specialization in skills during the development and support of an infrastructure based on complex
- technology. Examples of such technologies include network and distribution management, database management,
- communication management, and process control, among others. Partitioning along competence lines may also occur in
- upper layers, where special competency in the problem domain is required to understand and support key business
- functionality. Examples include telecommunication call management, securities trading, insurance claims processing, and
- air traffic control, to name a few.
-</p>
-<p>
- <b>System distribution:</b> Within any of the layers of the system, the layers may be further partitioned horizontally,
- so to speak, to reflect the distribution of functionality.
-</p>
-<ul>
- <li>
- <p>
- Partitioning to reflect distribution of functionality can help you visualize the network communication that
- will occur as the system runs.
- </p>
- </li>
- <li>
- <p>
- Partitioning to reflect distribution can also, however, make the system more difficult to change if the
- deployment model changes significantly.
- </p>
- </li>
-</ul>
-<p>
- <b>Secrecy areas</b><strong>:</strong> Some applications, especially those requiring special security clearance to
- develop or support, require additional partitioning according to security access privileges. Software that controls
- access to secrecy areas must be developed and maintained by personnel with appropriate clearance. If the number of
- people with this background on the project is limited, the functionality requiring special clearance must be
- partitioned into subsystems that will be developed independently from other subsystems, with the interfaces to the
- secrecy areas the only visible aspect of these subsystems.
-</p>
-<p>
- <b>Variability areas:</b> Functionality that is likely to be optional, and therefore delivered only in some variants of
- the system, should be organized into independent components that are developed and delivered independently from the
- mandatory functionality of the system.
+ <mainDescription><p>
+ Layering&nbsp; is&nbsp;one of the most&nbsp;commonly used&nbsp;approaches for structuring and decomposing systems.
+ Layering logically partitions the system into sets of components with certain rules regarding how relationships can be
+ formed between them. Layering provides a way to restrict inter-subsystem dependencies, with the result that the system
+ is more loosely coupled and more easily maintained.
+</p>
+<p>
+ Consider the number and purpose of the layers carefully. Do not over-complicate the solution by defining more layers
+ than are needed to meet the needs of the solution. More layers can always be added in the future to meet new
+ requirements. Removing layers is not always as easy and may introduce risks into the project.
+</p>
+<p>
+ The criteria for grouping elements into layers follows a few patterns:
+</p>
+<ul>
+ <li>
+ <b>Visibility</b><strong>:</strong> Elements may depend only on components in the same layer and the next-lower
+ layer.
+ </li>
+ <li>
+ <b>Volatility</b><strong>:</strong> 
+ <ul>
+ <li>
+ <b>In the highest layers</b>, put elements that vary when user requirements change.
+ </li>
+ <li>
+ <b>In the lowest layers</b>, put elements that vary when the implementation platform changes (hardware,
+ language, operating system, database, and so forth).
+ </li>
+ <li>
+ <strong>Sandwiched in the middle</strong>, put elements that are generally applicable across wide ranges of
+ systems and implementation environments.
+ </li>
+ <li>
+ <strong>Add layers</strong> when additional partitions within these broad categories help to organize the
+ model.
+ </li>
+ </ul>
+ </li>
+ <li>
+ <b>Generality</b><strong>:</strong> Abstract elements tend to be placed in the lower layers. If not
+ implementation-specific, they tend to gravitate toward the middle layers.
+ </li>
+ <li>
+ <b>Number of layers.</b> For a small system, three layers are typically sufficient.&nbsp;A three-layer architecture
+ of&nbsp;Presentation, Business, and Data layers is very common in information systems.&nbsp; For a complex system,
+ five to seven layers could be appropriate. For any degree of complexity, more than 10 layers should be viewed with
+ suspicion that increases with the number of layers.
+ </li>
+</ul>
+<p>
+ Failure to restrict dependencies according to the visibility criteria mentioned above can cause architectural
+ degradation and make the system difficult to extend and maintain.
+</p>
+<p>
+ Allowable exceptions to the visibility rule include cases where components need direct access to lower-layer services
+ beyond the next-lower layer. Make a decision about how to handle primitive services that are needed throughout the
+ system, such as printing, sending messages, and so forth. There is little value in restricting messages to lower layers
+ if the solution is to effectively implement call pass-throughs in the intermediate layers.&nbsp;&nbsp;This usage of a
+ less strict rule on dependencies down through the layers is sometimes called a Relaxed Layered Architecture (<a
+ class="elementlinkwithusertext"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#BUS96"
+ guid="_9ToeIB83Edqsvps02rpOOg">[BUS96]</a>).
+</p>
+<h4>
+ <a id="PartitioningPatterns" name="PartitioningPatterns">Partitioning patterns</a>
+</h4>
+<p>
+ Within the top layers of the system, additional partitioning may help organize the model. The following guidelines for
+ partitioning present different issues to consider:
+</p>
+<p>
+ <b>User organization</b><strong>:</strong> Elements may be organized along lines that mirror the organization of
+ functionality in the business organization (partitioning occurs along departmental or user role lines). This
+ partitioning often occurs early in the design&nbsp;due to&nbsp;an existing enterprise model that is strongly
+ partitioned according to the structure of the organization. This pattern usually affects only the top few layers of
+ application-specific services and can often disappear as the design evolves.
+</p>
+<ul>
+ <li>
+ <p>
+ Partitioning along user-organization lines can be a good starting point for the model.
+ </p>
+ </li>
+ <li>
+ <p>
+ The structure of the user organization is not stable over a long period of time because business
+ reorganizations occur; therefore, it is not a good long-term basis for system partitioning. The internal
+ organization of the system should enable the system to evolve and be maintained independently of the
+ organization of the business that it supports.
+ </p>
+ </li>
+</ul>
+<p>
+ <b>Areas of competence and skills:</b> Elements may be organized to partition responsibilities among different groups
+ within the development organization. Typically, this occurs in the middle and lower layers of the system, and reflects
+ the need for specialization in skills during the development and support of an infrastructure based on complex
+ technology. Examples of such technologies include network and distribution management, database management,
+ communication management, and process control, among others. Partitioning along competence lines may also occur in
+ upper layers, where special competency in the problem domain is required to understand and support key business
+ functionality. Examples include telecommunication call management, securities trading, insurance claims processing, and
+ air traffic control, to name a few.
+</p>
+<p>
+ <b>System distribution:</b> Within any of the layers of the system, the layers may be further partitioned horizontally,
+ so to speak, to reflect the distribution of functionality.
+</p>
+<ul>
+ <li>
+ <p>
+ Partitioning to reflect distribution of functionality can help you visualize the network communication that
+ will occur as the system runs.
+ </p>
+ </li>
+ <li>
+ <p>
+ Partitioning to reflect distribution can also, however, make the system more difficult to change if the
+ deployment model changes significantly.
+ </p>
+ </li>
+</ul>
+<p>
+ <b>Secrecy areas</b><strong>:</strong> Some applications, especially those requiring special security clearance to
+ develop or support, require additional partitioning according to security access privileges. Software that controls
+ access to secrecy areas must be developed and maintained by personnel with appropriate clearance. If the number of
+ people with this background on the project is limited, the functionality requiring special clearance must be
+ partitioned into subsystems that will be developed independently from other subsystems, with the interfaces to the
+ secrecy areas the only visible aspect of these subsystems.
+</p>
+<p>
+ <b>Variability areas:</b> Functionality that is likely to be optional, and therefore delivered only in some variants of
+ the system, should be organized into independent components that are developed and delivered independently from the
+ mandatory functionality of the system.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/maintaining_automated_test_suite.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/maintaining_automated_test_suite.xmi
index 1f14934..bc3dc05 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/maintaining_automated_test_suite.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/maintaining_automated_test_suite.xmi
@@ -1,104 +1,104 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_8ngBgMPdEdmbOvqy4O0adg" name="maintaining_automated_test_suite,_0kF5kMlgEdmt3adZL5Dmdw" guid="_8ngBgMPdEdmbOvqy4O0adg" changeDate="2006-09-26T11:31:15.000-0700" version="7.2.0">
- <mainDescription><h3>
- Introduction
-</h3>
-<p>
- At some point in your test effort, you may find it necessary to manage your test effort by creating test suites for
- your test assets.&nbsp;Maintaining test suites can take many different forms. To facilitate your testing, you may want
- to introduce some&nbsp;level of&nbsp;automation of your test suites.&nbsp;The fact that you've automated your test
- suites does not necessarily make your testing easier however. It may actually increase the maintenance burden of your
- suites.
-</p>
-<p>
- This guideline introduces you to useful heuristics on how to facilitate the maintenance of your automated test suites.
-</p>
-<h4>
- Plan your test&nbsp;suites
-</h4>
-<p>
- Automating your testing without planning increases&nbsp;the chances that testing will be ineffective
- and&nbsp;inefficient.&nbsp;Some level of planning should take place whether implicit or explicit.&nbsp;An essential
- part of any test plan is the definition of a strategy for test automation.&nbsp;Use your plan to articulate to the
- development team how you plan to maintain your test assets.&nbsp;In many cases, this is never done.&nbsp;The rest of
- the development team may be unaware of how you intend to maintain your tests.&nbsp;It is also a good practice to get
- the rest of the development team to understand that this maintenance can be a substantial part of the overall
- development effort.&nbsp;Use your test tooling to capture this information and treat this plan just like you would
- treat any other test asset in your test repository.
-</p>
-<h4>
- Centrally locate your test assets
-</h4>
-<p>
- To facilitate the maintenance of your automated test suites, locate your test assets in a repository that can be
- accessed by the development team.&nbsp;Many test automation environments provide test management tools that make it
- easier to organize and access your test assets by maintaining the test assets (test cases, test scripts, and test
- suites) in a common repository.
-</p>
-<p>
- In addition, some form of access control is enforced by the automation test tool.&nbsp;This eases the maintenance
- burden by ensuring the integrity of your test suites.&nbsp;You may choose to grant stakeholders and managers read-only
- access, whereas developers and testers at the practitioner level may have read/write access.
-</p>
-<h4>
- Treat your test assets like any other software
-</h4>
-<p>
- Software must be maintained.&nbsp;This also applies to the software in your test suites.&nbsp;Test cases and their
- associated test scripts, whether recorded or programmed, should be maintained.&nbsp;And just as software has different
- kinds of maintenance (e.g., corrective, preventative, or adaptive) so too do the assets in your automated test suites.
- As you lifecycle your test suites, identify, if only informally,&nbsp;how&nbsp;you plan to disposition the test suite
- corrective maintenance (e.g., syntactical errors in your scripts),&nbsp;preventative maintenance (e.g., where possible
- to write generalized test scripts), and adaptive maintenance (e.g., how you&nbsp;can use your test tooling to re-assign
- test&nbsp;assets within one suite to&nbsp;another suite or suites).&nbsp;This can be captured, as described in the
- section <strong>Plan Your Test Suites</strong> above, in your test plan.
-</p>
-<h4>
- Improve the testability of your test suites through collaboration with developers
-</h4>
-<p>
- It's one thing to say that your test suites will need to be maintained due to changes in the application, changes in
- the testing target, etc.&nbsp;It's quite another thing to actually determine whether a test suite needs to be
- revamped&nbsp;and, if it does, what test assets within it need to be addressed.
-</p>
-<p>
- One way to facilitate this is to use test suites as a way to communicate test decision to the developers.&nbsp;One way
- to perform continuous perfective maintenance of test suites is to think of your test suites as assets that belong to
- the development team rather than just the testers.&nbsp; You can perform a kind of perfective maintenance on test in
- the following ways:
-</p>
-<ul>
- <li>
- use test suites to raise the level of abstraction
- </li>
- <li>
- use test suites to provide focus for the developer
- </li>
- <li>
- use test suites to articulate areas that the developers would like testers to focus on
- </li>
- <li>
- make the construction and maintenance&nbsp;of test suites more efficient&nbsp;by understanding what area(s)
- developers want to focus on
- </li>
- <li>
- use test suites to clarify test targets with developers
- </li>
-</ul>
-<h4>
- Don't be afraid to clean up your suites
-</h4>
-<p>
- Your test assets will evolve just as the application under test will.&nbsp;As requirements to the system change, the
- application will change as well.&nbsp;To maintain your test suites, you should continually&nbsp;check whether test
- assets are valid.&nbsp;If possible, validity checks should be performed after each new release of the software,
- preferably more frequently.&nbsp;Keeping your test suites relevant is a full-time job.&nbsp;Assume that changes in the
- software will lead to some degree of invalid tests within your test suites.&nbsp;Once these test assets have been
- identified as invalid, get rid of them.&nbsp;This will make the maintenance burden much more tolerable.&nbsp;Some
- automated test tooling environments make this task easier by providing ways to package outdated or invalid
- tests.&nbsp;In some cases, you may not be absolutely sure whether you want to completely get rid of tests within your
- test suite or even of getting rid of test suites altogether.&nbsp; To alleviate this burden, you can create packages
- for obsolete tests or test suites and dispose of tests or test suites by putting them in packages labeled for this
- purpose.
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ At some point in your test effort, you may find it necessary to manage your test effort by creating test suites for
+ your test assets.&nbsp;Maintaining test suites can take many different forms. To facilitate your testing, you may want
+ to introduce some&nbsp;level of&nbsp;automation of your test suites.&nbsp;The fact that you've automated your test
+ suites does not necessarily make your testing easier however. It may actually increase the maintenance burden of your
+ suites.
+</p>
+<p>
+ This guideline introduces you to useful heuristics on how to facilitate the maintenance of your automated test suites.
+</p>
+<h4>
+ Plan your test&nbsp;suites
+</h4>
+<p>
+ Automating your testing without planning increases&nbsp;the chances that testing will be ineffective
+ and&nbsp;inefficient.&nbsp;Some level of planning should take place whether implicit or explicit.&nbsp;An essential
+ part of any test plan is the definition of a strategy for test automation.&nbsp;Use your plan to articulate to the
+ development team how you plan to maintain your test assets.&nbsp;In many cases, this is never done.&nbsp;The rest of
+ the development team may be unaware of how you intend to maintain your tests.&nbsp;It is also a good practice to get
+ the rest of the development team to understand that this maintenance can be a substantial part of the overall
+ development effort.&nbsp;Use your test tooling to capture this information and treat this plan just like you would
+ treat any other test asset in your test repository.
+</p>
+<h4>
+ Centrally locate your test assets
+</h4>
+<p>
+ To facilitate the maintenance of your automated test suites, locate your test assets in a repository that can be
+ accessed by the development team.&nbsp;Many test automation environments provide test management tools that make it
+ easier to organize and access your test assets by maintaining the test assets (test cases, test scripts, and test
+ suites) in a common repository.
+</p>
+<p>
+ In addition, some form of access control is enforced by the automation test tool.&nbsp;This eases the maintenance
+ burden by ensuring the integrity of your test suites.&nbsp;You may choose to grant stakeholders and managers read-only
+ access, whereas developers and testers at the practitioner level may have read/write access.
+</p>
+<h4>
+ Treat your test assets like any other software
+</h4>
+<p>
+ Software must be maintained.&nbsp;This also applies to the software in your test suites.&nbsp;Test cases and their
+ associated test scripts, whether recorded or programmed, should be maintained.&nbsp;And just as software has different
+ kinds of maintenance (e.g., corrective, preventative, or adaptive) so too do the assets in your automated test suites.
+ As you lifecycle your test suites, identify, if only informally,&nbsp;how&nbsp;you plan to disposition the test suite
+ corrective maintenance (e.g., syntactical errors in your scripts),&nbsp;preventative maintenance (e.g., where possible
+ to write generalized test scripts), and adaptive maintenance (e.g., how you&nbsp;can use your test tooling to re-assign
+ test&nbsp;assets within one suite to&nbsp;another suite or suites).&nbsp;This can be captured, as described in the
+ section <strong>Plan Your Test Suites</strong> above, in your test plan.
+</p>
+<h4>
+ Improve the testability of your test suites through collaboration with developers
+</h4>
+<p>
+ It's one thing to say that your test suites will need to be maintained due to changes in the application, changes in
+ the testing target, etc.&nbsp;It's quite another thing to actually determine whether a test suite needs to be
+ revamped&nbsp;and, if it does, what test assets within it need to be addressed.
+</p>
+<p>
+ One way to facilitate this is to use test suites as a way to communicate test decision to the developers.&nbsp;One way
+ to perform continuous perfective maintenance of test suites is to think of your test suites as assets that belong to
+ the development team rather than just the testers.&nbsp; You can perform a kind of perfective maintenance on test in
+ the following ways:
+</p>
+<ul>
+ <li>
+ use test suites to raise the level of abstraction
+ </li>
+ <li>
+ use test suites to provide focus for the developer
+ </li>
+ <li>
+ use test suites to articulate areas that the developers would like testers to focus on
+ </li>
+ <li>
+ make the construction and maintenance&nbsp;of test suites more efficient&nbsp;by understanding what area(s)
+ developers want to focus on
+ </li>
+ <li>
+ use test suites to clarify test targets with developers
+ </li>
+</ul>
+<h4>
+ Don't be afraid to clean up your suites
+</h4>
+<p>
+ Your test assets will evolve just as the application under test will.&nbsp;As requirements to the system change, the
+ application will change as well.&nbsp;To maintain your test suites, you should continually&nbsp;check whether test
+ assets are valid.&nbsp;If possible, validity checks should be performed after each new release of the software,
+ preferably more frequently.&nbsp;Keeping your test suites relevant is a full-time job.&nbsp;Assume that changes in the
+ software will lead to some degree of invalid tests within your test suites.&nbsp;Once these test assets have been
+ identified as invalid, get rid of them.&nbsp;This will make the maintenance burden much more tolerable.&nbsp;Some
+ automated test tooling environments make this task easier by providing ways to package outdated or invalid
+ tests.&nbsp;In some cases, you may not be absolutely sure whether you want to completely get rid of tests within your
+ test suite or even of getting rid of test suites altogether.&nbsp; To alleviate this burden, you can create packages
+ for obsolete tests or test suites and dispose of tests or test suites by putting them in packages labeled for this
+ purpose.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/mapping_design_to_code.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/mapping_design_to_code.xmi
index ccbe144..ca5a2fd 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/mapping_design_to_code.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/mapping_design_to_code.xmi
@@ -1,140 +1,141 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-4HHmcQny_Q08Xj_3Q7Sfig" name="new_concept,_mlKb8JyJEdy9brKHb521mQ" guid="-4HHmcQny_Q08Xj_3Q7Sfig" changeDate="2008-08-07T04:56:11.000-0700" version="7.2.0">
- <mainDescription><h4>
- <a id="Introduction" name="Introduction">Introduction</a>
-</h4>
-<p>
- Design must define enough of the system so that it can be implemented unambiguously. What constitutes enough varies
- from project to project and company to company.
-</p>
-<p>
- In some cases the design resembles a sketch, elaborated only far enough to ensure that the implementer can proceed (a
- "sketch and code" approach). The degree of specification varies with the expertise of the implementer, the complexity
- of the design, and the risk that the design might be misconstrued.
-</p>
-<p>
- In other cases, the design is elaborated to the point that the design can be transformed automatically into code. This
- typically involves extensions to standard UML to represent language and/or environment specific semantics.
-</p>
-<p>
- The design may also be hierarchical, such as the following:
-</p>
-<ul>
- <li>
- a high level design model which sketches an overview of the overall system
- </li>
- <li>
- a subsystem specification model which precisely specifies the required interfaces and behavior of major subsystems
- within the system
- </li>
- <li>
- a detailed design model for the internals of subsystems
- </li>
-</ul>
-<p>
- The sections below describe some different options for relating a design and implementation, and discuss benefits and
- drawbacks of these approaches.
-</p>
-<h4>
- <a id="sketch" name="sketch">Sketch and Code</a>
-</h4>
-<p>
- One common approach to design is to sketch out the design at a fairly abstract level, and then move directly to code.
- Maintenance of the design model is manual.
-</p>
-<p>
- In this approach, we let a design class be an abstraction of several code-level classes. We recommend that you map each
- design class to one "head" class that, in turn, can use several "helper" classes to perform its behavior. You can use
- "helper" classes to implement a complex attribute or to build a data structure that you need for the implementation of
- an operation. In design, you don't model the "helper" classes and you only model the key attributes, relationships, and
- operations defined by the head class. The purpose of such a model is to abstract away details that can be completed by
- the implementer.
-</p>
-<p>
- This approach is extended to apply to the other design model elements. You may have design interfaces which are more
- abstract than the code-level interfaces, and so on.
-</p>
-<h4>
- <a id="round" name="round">Round-Trip Engineering</a>
-</h4>
-<p>
- In round-trip engineering environments, the design model evolves to a level of detail where it becomes a visual
- representation of the code. The code and its visual representation are synchronized (with tool support).
-</p>
-<p>
- The following are some options for representing a Design Model in a round-trip engineering context.
-</p>
-<p>
- <b><a id="trace" name="trace">High Level Design Model and Detailed Design Model</a></b>
-</p>
-<p>
- In this approach, there are two levels of design model maintained. Each high level design element is an abstraction of
- one or more detailed elements in the round-tripped model. For example, a design class may map to one "head" class and
- several "helper" classes, just as in the "sketch and code" approach described previously. Traceability from the high
- level design model elements to round-trip model elements can help maintain consistency between the two models.
-</p>
-<p>
- Although this can help abstract away less important details, this benefit must be balanced against the effort required
- to maintain consistency between the models.
-</p>
-<p>
- <b><a id="evolves" name="evolves">Single Evolving Design Model</a></b>
-</p>
-<p>
- In this approach, there is a single Design Model. Initial sketches of design elements evolve to the point where they
- can be synchronized with code. Diagrams, such as those used to describe design use-case realizations, initially
- reference sketched design classes, but eventually reference language-specific classes. High level descriptions of the
- design are maintained as needed, such as:
-</p>
-<ul>
- <li>
- diagrams of the logical structure of the system,
- </li>
- <li>
- subsystem/component specifications,
- </li>
- <li>
- design patterns / mechanisms.<br />
- </li>
-</ul>
-<p>
- Such a model is easier to maintain consistent with the implementation.
-</p>
-<h4>
- <a id="specification" name="specification">Specification and Realization Models</a>
-</h4>
-<p>
- A related approach is to define the design in terms of specifications for major subsystems, detailed to the point where
- client implementations can compile against them.
-</p>
-<p>
- The detailed design of the subsystem realization can be modeled and maintained separately from this specification
- model.
-</p>
-<p>
- Models can be detailed and used to generate an implementation. Both structure (class and package diagrams) and behavior
- diagrams (such as collaboration, state, and activity diagrams) can be used to generate executable code. These initial
- versions can be further refined as needed.
-</p>
-<p>
- The design may be platform-independent to varying degrees. Platform-specific design models or even code can be
- generated by transformations that apply various rules to map high-level abstractions of platform-specific elements.
- This is the focus of the Object Management Group (OMG) Model-Driven Architecture (MDA) <a href="http://www.omg.org/" target="_blank">(http://www.omg.org</a>) initiative.
-</p>
-<p>
- Platform-specific visual models can be used to generate an initial code framework. This framework can be further
- elaborated with additional code not specified in the design.
-</p>
-<h4>
- Patterns
-</h4>
-<p>
- Standard patterns can be applied to generate design and code elements from related design and implementation. For
- example, a standard transformation pattern can be applied to a data table to create Java&trade; classes to access the data
- table. Another example is using an <a href="http://www.eclipse.org/emf/" target="_blank">Eclipse Modeling Framework</a>
- to generate code for storing data that matches the model and to generate a user interface implementation for populating
- data. A pattern or transformation engine can be used to create the implementation, or the implementation can be done by
- hand. Pattern engines are easier and more reliable, but handwritten code implementing a defined pattern will have fewer
- errors than handwritten code implementing a novel or unique design.
+ <mainDescription><h4>
+ <a id="Introduction" name="Introduction">Introduction</a>
+</h4>
+<p>
+ Design must define enough of the system so that it can be implemented unambiguously. What constitutes enough varies
+ from project to project and company to company.
+</p>
+<p>
+ In some cases the design resembles a sketch, elaborated only far enough to ensure that the implementer can proceed (a
+ "sketch and code" approach). The degree of specification varies with the expertise of the implementer, the complexity
+ of the design, and the risk that the design might be misconstrued.
+</p>
+<p>
+ In other cases, the design is elaborated to the point that the design can be transformed automatically into code. This
+ typically involves extensions to standard UML to represent language and/or environment specific semantics.
+</p>
+<p>
+ The design may also be hierarchical, such as the following:
+</p>
+<ul>
+ <li>
+ a high level design model which sketches an overview of the overall system
+ </li>
+ <li>
+ a subsystem specification model which precisely specifies the required interfaces and behavior of major subsystems
+ within the system
+ </li>
+ <li>
+ a detailed design model for the internals of subsystems
+ </li>
+</ul>
+<p>
+ The sections below describe some different options for relating a design and implementation, and discuss benefits and
+ drawbacks of these approaches.
+</p>
+<h4>
+ <a id="sketch" name="sketch">Sketch and Code</a>
+</h4>
+<p>
+ One common approach to design is to sketch out the design at a fairly abstract level, and then move directly to code.
+ Maintenance of the design model is manual.
+</p>
+<p>
+ In this approach, we let a design class be an abstraction of several code-level classes. We recommend that you map each
+ design class to one "head" class that, in turn, can use several "helper" classes to perform its behavior. You can use
+ "helper" classes to implement a complex attribute or to build a data structure that you need for the implementation of
+ an operation. In design, you don't model the "helper" classes and you only model the key attributes, relationships, and
+ operations defined by the head class. The purpose of such a model is to abstract away details that can be completed by
+ the implementer.
+</p>
+<p>
+ This approach is extended to apply to the other design model elements. You may have design interfaces which are more
+ abstract than the code-level interfaces, and so on.
+</p>
+<h4>
+ <a id="round" name="round">Round-Trip Engineering</a>
+</h4>
+<p>
+ In round-trip engineering environments, the design model evolves to a level of detail where it becomes a visual
+ representation of the code. The code and its visual representation are synchronized (with tool support).
+</p>
+<p>
+ The following are some options for representing a Design Model in a round-trip engineering context.
+</p>
+<p>
+ <b><a id="trace" name="trace">High Level Design Model and Detailed Design Model</a></b>
+</p>
+<p>
+ In this approach, there are two levels of design model maintained. Each high level design element is an abstraction of
+ one or more detailed elements in the round-tripped model. For example, a design class may map to one "head" class and
+ several "helper" classes, just as in the "sketch and code" approach described previously. Traceability from the high
+ level design model elements to round-trip model elements can help maintain consistency between the two models.
+</p>
+<p>
+ Although this can help abstract away less important details, this benefit must be balanced against the effort required
+ to maintain consistency between the models.
+</p>
+<p>
+ <b><a id="evolves" name="evolves">Single Evolving Design Model</a></b>
+</p>
+<p>
+ In this approach, there is a single Design Model. Initial sketches of design elements evolve to the point where they
+ can be synchronized with code. Diagrams, such as those used to describe design use-case realizations, initially
+ reference sketched design classes, but eventually reference language-specific classes. High level descriptions of the
+ design are maintained as needed, such as:
+</p>
+<ul>
+ <li>
+ diagrams of the logical structure of the system,
+ </li>
+ <li>
+ subsystem/component specifications,
+ </li>
+ <li>
+ design patterns / mechanisms.<br />
+ </li>
+</ul>
+<p>
+ Such a model is easier to maintain consistent with the implementation.
+</p>
+<h4>
+ <a id="specification" name="specification">Specification and Realization Models</a>
+</h4>
+<p>
+ A related approach is to define the design in terms of specifications for major subsystems, detailed to the point where
+ client implementations can compile against them.
+</p>
+<p>
+ The detailed design of the subsystem realization can be modeled and maintained separately from this specification
+ model.
+</p>
+<p>
+ Models can be detailed and used to generate an implementation. Both structure (class and package diagrams) and behavior
+ diagrams (such as collaboration, state, and activity diagrams) can be used to generate executable code. These initial
+ versions can be further refined as needed.
+</p>
+<p>
+ The design may be platform-independent to varying degrees. Platform-specific design models or even code can be
+ generated by transformations that apply various rules to map high-level abstractions of platform-specific elements.
+ This is the focus of the Object Management Group (OMG) Model-Driven Architecture (MDA) <a href="http://www.omg.org/"
+ target="_blank">(http://www.omg.org</a>) initiative.
+</p>
+<p>
+ Platform-specific visual models can be used to generate an initial code framework. This framework can be further
+ elaborated with additional code not specified in the design.
+</p>
+<h4>
+ Patterns
+</h4>
+<p>
+ Standard patterns can be applied to generate design and code elements from related design and implementation. For
+ example, a standard transformation pattern can be applied to a data table to create Java&trade; classes to access the data
+ table. Another example is using an <a href="http://www.eclipse.org/emf/" target="_blank">Eclipse Modeling Framework</a>
+ to generate code for storing data that matches the model and to generate a user interface implementation for populating
+ data. A pattern or transformation engine can be used to create the implementation, or the implementation can be done by
+ hand. Pattern engines are easier and more reliable, but handwritten code implementing a defined pattern will have fewer
+ errors than handwritten code implementing a novel or unique design.
</p><br /></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/programming_automated_tests.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/programming_automated_tests.xmi
index 41fb1db..8a1f080 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/programming_automated_tests.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/programming_automated_tests.xmi
@@ -1,73 +1,73 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_vuwC4MPcEdmbOvqy4O0adg" name="programming_automated_tests,_0j5sUMlgEdmt3adZL5Dmdw" guid="_vuwC4MPcEdmbOvqy4O0adg" changeDate="2006-12-07T01:06:38.000-0800" version="1.0.0">
- <mainDescription><h3>
- Introduction
-</h3>
-<p>
- Although the programming of automated tests should contribute to the overall test effort, it usually does not make up
- the entire test effort. In fact, test environments that are based on a complete automation approach end up spending
- more time on test automation than on testing. Before you begin developing automated test scripts, consider first
- whether it is more efficient to perform manual testing. Some aspects of an application are more efficiently tested
- manually (for example, GUI testing versus data-drive testing). If you decide to program automated test scripts, examine
- what aspects of your test scripting can be automated and begin designing your scripts.
-</p>
-<h3>
- Design your automated tests
-</h3>
-<p>
- Without some level of design of your automated tests, introducing automation into your testing effort can lead to more
- problems than it solves. You should consider developing your automated tests according to a lifecycle with automation
- test requirements, design, testing of the automation tests, and implementation of the automation tests. This approach
- can be informal or formal depending on your project needs. By designing the programming of your automated tests, you
- can avoid spending time programming the wrong tests, re-working programmed tests, deciphering different coding styles
- in the programming of the tests, etc.
-</p>
-<h3>
- Recorded versus programmed scripts
-</h3>
-<p>
- Although there are clear benefits to recorded scripts (for example, ease of creation or ability for novice testers to
- learn a scripting language), recorded scripts also present their own problems. The disadvantages of playback scripts
- are well known. They are deceptively easy to create but very difficult to update. Problems with script reliability,
- hard-coded data values, or changes to the application under test and the need to re-record are well-documented. On the
- other hand, programming scripts can present difficulties of their own: they are difficult for the novice tester to
- create, they can require substantial time and effort to develop, and they can be difficult to debug. Most test tooling
- makes these issues less problematic by providing the tester script support functions, such as ways to establish target
- of test lists, systematic ways to program verification point, point to datapools, build commands into the script (for
- example, sleeper commands), comment the script, and document the script. Another major advantage, which is often
- overlooked, of using testing tooling to mitigate these risks is the ability to add to an existing script in the form of
- making corrections to an existing script, testing new features of a test target or application under test, or resuming
- a recording after an interruption.
-</p>
-<h3>
- Functional and performance test scripts
-</h3>
-<p>
- When discussing automating test scripts, it is important to distinguish between functional and performance tests. Most
- discussions of programming automated test scripts focus on testing the functionality of an application. This is not
- inappropriate, since a lot of automated testing focuses on functional testing. Performance test scripting, however, has
- its unique characteristics. Performance test automation provides you with the ability to programmatically set workloads
- by adding user groups to test loads under group usage, setting think time behavior, running tests randomly or at set
- rates, or setting the duration of a run. Performance test automation also allows you to create and maintain schedules
- for your tests.
-</p>
-<h3>
- Testing test scripts
-</h3>
-<p>
- When testing your test scripts, keep in mind whether you are testing recorded or programmed test scripts. For recorded
- scripts, much of the debugging of the script consists of errors that are introduced due to changes in the test target
- or test environment. When you run a recorded test script, consider the test target of the script. Some test automation
- tools capture this information as a part of the test script. Debugging a recorded script consists largely of
- determining whether changes in the target have created error conditions in the script. In general, there are two main
- categories to examine here: changes in the UI and test session sensitive data (for example, date stamped data). In most
- cases, discrepancies between recording and playback cause errors in your recorded test scripts.
-</p>
-<p>
- Testing programmed test scripts involves many of the same debugging techniques you would apply to debugging an
- application. Consider both the flow control logic and the data aspects of your script. Automated testing tools provide
- you with test script debugging IDEs as well as datapool management features that facilitate this type of testing.
- During execution of test scripts, a test that uses a datapool can replace values in the programmed test with variable
- test data that is stored in the datapool.
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ Although the programming of automated tests should contribute to the overall test effort, it usually does not make up
+ the entire test effort. In fact, test environments that are based on a complete automation approach end up spending
+ more time on test automation than on testing. Before you begin developing automated test scripts, consider first
+ whether it is more efficient to perform manual testing. Some aspects of an application are more efficiently tested
+ manually (for example, GUI testing versus data-drive testing). If you decide to program automated test scripts, examine
+ what aspects of your test scripting can be automated and begin designing your scripts.
+</p>
+<h3>
+ Design your automated tests
+</h3>
+<p>
+ Without some level of design of your automated tests, introducing automation into your testing effort can lead to more
+ problems than it solves. You should consider developing your automated tests according to a lifecycle with automation
+ test requirements, design, testing of the automation tests, and implementation of the automation tests. This approach
+ can be informal or formal depending on your project needs. By designing the programming of your automated tests, you
+ can avoid spending time programming the wrong tests, re-working programmed tests, deciphering different coding styles
+ in the programming of the tests, etc.
+</p>
+<h3>
+ Recorded versus programmed scripts
+</h3>
+<p>
+ Although there are clear benefits to recorded scripts (for example, ease of creation or ability for novice testers to
+ learn a scripting language), recorded scripts also present their own problems. The disadvantages of playback scripts
+ are well known. They are deceptively easy to create but very difficult to update. Problems with script reliability,
+ hard-coded data values, or changes to the application under test and the need to re-record are well-documented. On the
+ other hand, programming scripts can present difficulties of their own: they are difficult for the novice tester to
+ create, they can require substantial time and effort to develop, and they can be difficult to debug. Most test tooling
+ makes these issues less problematic by providing the tester script support functions, such as ways to establish target
+ of test lists, systematic ways to program verification point, point to datapools, build commands into the script (for
+ example, sleeper commands), comment the script, and document the script. Another major advantage, which is often
+ overlooked, of using testing tooling to mitigate these risks is the ability to add to an existing script in the form of
+ making corrections to an existing script, testing new features of a test target or application under test, or resuming
+ a recording after an interruption.
+</p>
+<h3>
+ Functional and performance test scripts
+</h3>
+<p>
+ When discussing automating test scripts, it is important to distinguish between functional and performance tests. Most
+ discussions of programming automated test scripts focus on testing the functionality of an application. This is not
+ inappropriate, since a lot of automated testing focuses on functional testing. Performance test scripting, however, has
+ its unique characteristics. Performance test automation provides you with the ability to programmatically set workloads
+ by adding user groups to test loads under group usage, setting think time behavior, running tests randomly or at set
+ rates, or setting the duration of a run. Performance test automation also allows you to create and maintain schedules
+ for your tests.
+</p>
+<h3>
+ Testing test scripts
+</h3>
+<p>
+ When testing your test scripts, keep in mind whether you are testing recorded or programmed test scripts. For recorded
+ scripts, much of the debugging of the script consists of errors that are introduced due to changes in the test target
+ or test environment. When you run a recorded test script, consider the test target of the script. Some test automation
+ tools capture this information as a part of the test script. Debugging a recorded script consists largely of
+ determining whether changes in the target have created error conditions in the script. In general, there are two main
+ categories to examine here: changes in the UI and test session sensitive data (for example, date stamped data). In most
+ cases, discrepancies between recording and playback cause errors in your recorded test scripts.
+</p>
+<p>
+ Testing programmed test scripts involves many of the same debugging techniques you would apply to debugging an
+ application. Consider both the flow control logic and the data aspects of your script. Automated testing tools provide
+ you with test script debugging IDEs as well as datapool management features that facilitate this type of testing.
+ During execution of test scripts, a test that uses a datapool can replace values in the programmed test with variable
+ test data that is stored in the datapool.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/refactoring.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/refactoring.xmi
index 0d8a146..00f9287 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/refactoring.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/refactoring.xmi
@@ -1,83 +1,85 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-i7KKltG_fEgqAjlVlIBGFA" name="refactoring,_YNx2sJ05EdyQ3oTO93enUw" guid="-i7KKltG_fEgqAjlVlIBGFA" changeDate="2008-08-12T05:00:22.000-0700" version="1.0.0">
- <mainDescription><p>
- Refactoring involves improving the quality of existing code without changing the system's behavior. It is explicitly
- not about adding or changing behavior, but about improving the implementation quality of existing behavior.
-</p>
-<p>
- A full set of developer tests is required before refactoring can be safely applied. It is critical that the system
- behavior be in a known, verifiably correct state before modifying the implementation so that you can improve the
- quality without fear that the modified implementation will break something. Refactoring is a safe transformation to
- improve code, but it is safe only if there are tests that can verify that the system still works as intended.
-</p>
-<p>
- Refactoring is initiated when an area that needs improvement is identified in the system by examining either the code
- or&nbsp;some other&nbsp;representation of the design. The issues identified are sometimes called "smells."
-</p>
-<p>
- Here are several smells to look for that might lead to implementation or design refactoring:
-</p>
-<ul>
- <li>
- <b>Duplicated code:</b> Duplicated code makes the system harder to understand and harder to maintain.
- </li>
- <li>
- <b>Large design element or method:</b> Large design elements or methods diminish the ability of people to
- understand the code, reduce the potential for reuse, and make developer testing more difficult.
- </li>
- <li>
- <b>Poorly named element:</b> Whether the element be a variable, function, class, or implementation element, its
- name should connote what it is so that the code can be maintained.
- </li>
- <li>
- <strong>Tight coupling:</strong> Each design element should work with minimal concern for the internal aspects of
- other design elements. Otherwise, changes to one element can have undesirable effects in other elements.
- </li>
-</ul>
-<p>
- As you can see from this list, refactoring can improve the "internals" of an element or&nbsp;the interface of the
- element. Also, many of the smells&nbsp;are characterized as making the software more difficult to understand; whereas
- refactoring is about making the system simpler.
-</p>
-<p>
- After an issue is identified, a refactoring method can be selected that will improve the situation. There are catalogs
- of refactoring methods available that are change patterns that will fix common problems while retaining the behavior of
- the system.
-</p>
-<p>
- These are examples of refactoring methods:
-</p>
-<ul>
- <li>
- <b>Extract Method:</b> Pull out the duplicated code into its own single method or extract part of a large method
- into its own method.
- </li>
- <li>
- <b>Extract Class:</b> Pull some cohesive part of a class into its own class to reduce the size of a design element
- that is too big.
- </li>
- <li>
- <b>Rename Method</b>, <b>Rename Class</b>, or <b>Rename Variable:</b> Give a more meaningful name to an element to
- make it more understandable.
- </li>
- <li>
- <b>Extract Interface:</b> Create a clean interface.
- </li>
-</ul>
-<p>
- After refactoring has been applied, developer tests are run again to ensure that the system still behaves correctly. It
- is important that the system is working correctly after each small refactoring. Although many refactorings can be put
- together to drive broad change across the code base, the tests should run correctly between each refactoring applied.
- Refactoring must be applied as small behavior-preserving transformations.
-</p>
-<p>
- As mentioned previously, refactoring requires full developer test coverage of the area under consideration. There are
- additional techniques that enable refactoring. Coding standards define a common style and make it easier to refactor
- consistently. An attitude of&nbsp;collective code ownership within the team is important. Each developer should feel
- that refactoring can be applied across the code base to improve the implementation.
-</p>
-<p>
- For deeper coverage on this topic, including a listing of "smells" and a catalog of refactorings to respond to them,
- see [<a class="elementLinkWithUserText" href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#FOW99" guid="_9ToeIB83Edqsvps02rpOOg">FOW99</a>].
+ <mainDescription><p>
+ Refactoring involves improving the quality of existing code without changing the system's behavior. It is explicitly
+ not about adding or changing behavior, but about improving the implementation quality of existing behavior.
+</p>
+<p>
+ A full set of developer tests is required before refactoring can be safely applied. It is critical that the system
+ behavior be in a known, verifiably correct state before modifying the implementation so that you can improve the
+ quality without fear that the modified implementation will break something. Refactoring is a safe transformation to
+ improve code, but it is safe only if there are tests that can verify that the system still works as intended.
+</p>
+<p>
+ Refactoring is initiated when an area that needs improvement is identified in the system by examining either the code
+ or&nbsp;some other&nbsp;representation of the design. The issues identified are sometimes called "smells."
+</p>
+<p>
+ Here are several smells to look for that might lead to implementation or design refactoring:
+</p>
+<ul>
+ <li>
+ <b>Duplicated code:</b> Duplicated code makes the system harder to understand and harder to maintain.
+ </li>
+ <li>
+ <b>Large design element or method:</b> Large design elements or methods diminish the ability of people to
+ understand the code, reduce the potential for reuse, and make developer testing more difficult.
+ </li>
+ <li>
+ <b>Poorly named element:</b> Whether the element be a variable, function, class, or implementation element, its
+ name should connote what it is so that the code can be maintained.
+ </li>
+ <li>
+ <strong>Tight coupling:</strong> Each design element should work with minimal concern for the internal aspects of
+ other design elements. Otherwise, changes to one element can have undesirable effects in other elements.
+ </li>
+</ul>
+<p>
+ As you can see from this list, refactoring can improve the "internals" of an element or&nbsp;the interface of the
+ element. Also, many of the smells&nbsp;are characterized as making the software more difficult to understand; whereas
+ refactoring is about making the system simpler.
+</p>
+<p>
+ After an issue is identified, a refactoring method can be selected that will improve the situation. There are catalogs
+ of refactoring methods available that are change patterns that will fix common problems while retaining the behavior of
+ the system.
+</p>
+<p>
+ These are examples of refactoring methods:
+</p>
+<ul>
+ <li>
+ <b>Extract Method:</b> Pull out the duplicated code into its own single method or extract part of a large method
+ into its own method.
+ </li>
+ <li>
+ <b>Extract Class:</b> Pull some cohesive part of a class into its own class to reduce the size of a design element
+ that is too big.
+ </li>
+ <li>
+ <b>Rename Method</b>, <b>Rename Class</b>, or <b>Rename Variable:</b> Give a more meaningful name to an element to
+ make it more understandable.
+ </li>
+ <li>
+ <b>Extract Interface:</b> Create a clean interface.
+ </li>
+</ul>
+<p>
+ After refactoring has been applied, developer tests are run again to ensure that the system still behaves correctly. It
+ is important that the system is working correctly after each small refactoring. Although many refactorings can be put
+ together to drive broad change across the code base, the tests should run correctly between each refactoring applied.
+ Refactoring must be applied as small behavior-preserving transformations.
+</p>
+<p>
+ As mentioned previously, refactoring requires full developer test coverage of the area under consideration. There are
+ additional techniques that enable refactoring. Coding standards define a common style and make it easier to refactor
+ consistently. An attitude of&nbsp;collective code ownership within the team is important. Each developer should feel
+ that refactoring can be applied across the code base to improve the implementation.
+</p>
+<p>
+ For deeper coverage on this topic, including a listing of "smells" and a catalog of refactorings to respond to them,
+ see [<a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#FOW99"
+ guid="_9ToeIB83Edqsvps02rpOOg">FOW99</a>].
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/repres_interfaces_to_ext_systems.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/repres_interfaces_to_ext_systems.xmi
index ac19366..5f11308 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/repres_interfaces_to_ext_systems.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/repres_interfaces_to_ext_systems.xmi
@@ -1,14 +1,18 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_iCwb8MM3EdmSIPI87WLu3g" name="repres_interfaces_to_ext_systems,_0gjdYMlgEdmt3adZL5Dmdw" guid="_iCwb8MM3EdmSIPI87WLu3g" changeDate="2008-08-06T06:07:25.000-0700" version="1.0.0">
- <mainDescription><p>
- Interfaces with external systems should be consistently handled throughout the system. The architecture need not
- include a specific, detailed design for each system interface. It is often enough to simply identify the existence of
- the interface as a significant part of the architecture and create a <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/concepts/component_CB167D48.html" guid="_0YP18MlgEdmt3adZL5Dmdw">Component</a>&nbsp;to encapsulate the detail, so that it can be developed later.
-</p>
-<p>
- The <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/guidelines/entity_control_boundary_pattern_C4047897.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a>&nbsp;provides the basis for a useful technique to
- support this.&nbsp;Specifically, if the system communicates with another system, define one or more components to
- describe the communication protocol.&nbsp; The use of a component allows the interface to the external system to be
- defined and stabilized, while leaving the design details of the system interface hidden as the system evolves.
+ <mainDescription><p>
+ Interfaces with external systems should be consistently handled throughout the system. The architecture need not
+ include a specific, detailed design for each system interface. It is often enough to simply identify the existence of
+ the interface as a significant part of the architecture and create a <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/component_CB167D48.html"
+ guid="_0YP18MlgEdmt3adZL5Dmdw">Component</a>&nbsp;to encapsulate the detail, so that it can be developed later.
+</p>
+<p>
+ The <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/guidances/guidelines/entity_control_boundary_pattern_C4047897.html"
+ guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a>&nbsp;provides the basis for a useful technique to
+ support this.&nbsp;Specifically, if the system communicates with another system, define one or more components to
+ describe the communication protocol.&nbsp; The use of a component allows the interface to the external system to be
+ defined and stabilized, while leaving the design details of the system interface hidden as the system evolves.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/req_gathering_techniques.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/req_gathering_techniques.xmi
index 7c76d44..0240860 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/req_gathering_techniques.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/req_gathering_techniques.xmi
@@ -1,349 +1,349 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_On0agNSAEdmLhZ9H5Plxyw" name="req_gathering_techniques,_OnoNQNSAEdmLhZ9H5Plxyw" guid="_On0agNSAEdmLhZ9H5Plxyw" changeDate="2008-10-15T06:42:15.000-0700" version="7.2.0">
- <mainDescription><h3>
- Sources of Requirements
-</h3>
-<p>
- Good requirements start with good sources. Finding those quality sources is an important task and, fortunately, one
- that&nbsp;takes few&nbsp;resources. Examples of sources of requirements include:
-</p>
-<ul>
- <li>
- Customers
- </li>
- <li>
- Users
- </li>
- <li>
- Administrators and maintenance&nbsp;staff
- </li>
- <li>
- Partners
- </li>
- <li>
- Domain Experts
- </li>
- <li>
- Industry Analysts
- </li>
- <li>
- Information about competitors&nbsp;
- </li>
-</ul>
-<h3>
- Requirements Gathering Techniques
-</h3>
-<p>
- After you have identified these sources, there are a number of techniques that may be used to gather requirements. The
- following will describe the various techniques, followed by a brief discussion of when to use each technique.
-</p>
-<p>
- To get the requirements down on paper, you&nbsp;can to do one or more of the following:
-</p>
-<ul>
- <li>
- Conduct a brainstorming session
- </li>
- <li>
- Interview users
- </li>
- <li>
- Send questionnaires
- </li>
- <li>
- Work in the target environment
- </li>
- <li>
- Study analogous systems
- </li>
- <li>
- Examine suggestions and problem reports
- </li>
- <li>
- Talk to support teams
- </li>
- <li>
- Study improvements made by users
- </li>
- <li>
- Look at unintended uses
- </li>
- <li>
- Conduct workshops
- </li>
- <li>
- Demonstrate prototypes to stakeholders
- </li>
-</ul>
-<p>
- The best idea is to get the requirements down quickly and then to encourage the users to correct and improve them. Put
- in those corrections, and repeat the cycle. Do it now, keep it small, and correct it at once. Start off with the best
- structure you can devise, but expect to keep on correcting it throughout the process.&nbsp; Success tips: Do it now,
- keep it small, and correct it immediately.
-</p>
-<h4>
- Conduct a brainstorming session
-</h4>
-<p>
- Brainstorming is a short group session where everyone is allowed to say whatever they feel is important to the topic of
- discussion. After that, a facilitator leads the group in organizing and prioritizing the results.&nbsp; The following
- basic rules for brainstorming&nbsp;ensures better results:
-</p>
-<ul>
- <li>
- Start out by clearly stating the objective of the brainstorming session.
- </li>
- <li>
- Generate as may ideas as possible.
- </li>
- <li>
- Let your imagination soar.
- </li>
- <li>
- Do not allow criticism or debate while you are gathering information.
- </li>
- <li>
- Once information is gathered,&nbsp;reshape and combine ideas.
- </li>
-</ul>
-<h4>
- Interview users
-</h4>
-<p>
- Face-to-face contact with users through individual interviewing is the primary source of requirements and an important
- way you gather and validate their requirements. Remember that it is not the only possible technique, and that you can
- conduct interviews many different ways. Develop a repertoire of styles to&nbsp;fit different situations. Unless you use
- the system yourself, you will need to make an effort to understand and experience the user's problem to describe it
- clearly and correctly.
-</p>
-<h4>
- Send Questionnaires
-</h4>
-<p>
- If face-to-face meetings are possible, they are always preferable, because they provide a better means of uncovering
- the problem behind the problem. Sometimes, though,&nbsp;face-to-face meetings with stakeholders are not feasible (when
- developing products for the consumer market, for example). In those situations, consider using questionnaires.&nbsp;
- Send a set of questions, possibly with multiple choice responses, to the relevant stakeholders, and ask them to
- complete it and return it to you.&nbsp; Success&nbsp;tips: Keep it short and given them a deadline.&nbsp;
-</p>
-<p>
- This technique has the advantage of providing a lot of information for statistical analysis. However, the questions
- must be well designed to be clear and to avoid so-called "leading questions", which bias the responses.&nbsp;
-</p>
-<h4>
- Work in the target environment
-</h4>
-<p>
- Experience the work of the users for yourself. Working with users helps you understand problems that have resisted
- previous solutions. Familiar systems developed in this way inevitably include tools for programmers, such as
- interactive editors and compilers, as the developers naturally have both the expertise in the subject area, and the
- desire to solve their own problems. It would be good to see the same dedication devoted to solving problems in other
- areas too. Where the work cannot easily be experienced in this way, it may still be possible to do a bit more than just
- sit quietly and observe. Users can give you a commentary on what they are doing, what the problems are, and what they
- would like to have to make the work easier.
-</p>
-<h4>
- Study analogous systems
-</h4>
-<p>
- The starting point for many projects is often a similar or an existing system. Sometimes, comparable products and
- systems contain working versions of good ideas for solving user problems. You can save the time lost in reinventing the
- wheel by looking at systems already on the market, whether they are systems installed at the user's site or products
- made by rival organizations. Even if they are trying to solve slightly different problems, they often&nbsp;provide
- valuable clues as to what you need to do.
-</p>
-<p>
- Listen when a customer asks why a product couldn't do something that the customer wants, and keep a list of these
- suggestions. Later, use it to start discussions with other users. You should be able to obtain some requirements
- directly this way. If not, capture and store suggestions for future use.
-</p>
-<p>
- You can describe to users selected features of other products. Explain that the system is designed for&nbsp;another
- purpose&nbsp;but contains an interesting feature, and you wonder it or something similar&nbsp;would help them.
- Sometimes these systems are described in documents, such as a contract from another organization or a report written
- for management. Often, these documents were never intended as formal requirements, and were written merely to
- communicate a stream-of-consciousness idea. Define a process of going from disorganized to organized information.
-</p>
-<p>
- Such a process might involve the following activities:
-</p>
-<ul>
- <li>
- Read the document from end to end (several times) to comprehend what the customer wants and what actually has been
- written.
- </li>
- <li>
- Classify all of the types of information in the document. (user, system requirements, design elements, plans,
- background material, irrelevant detail)
- </li>
- <li>
- Mark up the original text to separate out such requirements.
- </li>
- <li>
- Find a good structure for each of the different types of information such as: a scenario for the user requirements,
- functional breakdown for the system requirements, and architecture for the design.
- </li>
- <li>
- Organize the information to show gaps and overlaps. Feel free to add missing elements, but confirm these decisions
- with the users.
- </li>
- <li>
- Create traceability links between these information elements to show the designers exactly what the users want.
- </li>
- <li>
- Convince the customer to accept the new information as the basis for the contract.
- </li>
-</ul>
-<h4>
- Examine suggestions and problem reports
-</h4>
-<p>
- Requirements can come from change suggestions and user problems. A direct road to finding requirements is to look at
- suggestions and problems as first described. Most organizations have a form for reporting system problems or software
- defects. You can ask to look through the reports (and there will probably be many). Sort them into groups so you can
- identify the key areas that are troubling users. Ask users some questions about these areas to clarify the users'
- actual needs.
-</p>
-<h4>
- Talk to support teams
-</h4>
-<p>
- Most large sales organizations have a help desk that keeps a log of problems and fixes, and support engineers who do
- the fixing. Many organizations have similar facilities to support their own operations. Talking to the help desk staff
- and the support engineers may give you good leads into the requirements, and save you time. Also talk to the training
- team and installation teams about what users find to be&nbsp;difficult.
-</p>
-<h4>
- Study improvements made by users
-</h4>
-<p>
- This is an excellent source of requirements. Users of a standard company spreadsheet may have added a few fields, or
- related different sheets together, or drawn a graph, that exactly meets their individual needs. You need only ask: Why
- did you add that? Their answers help you&nbsp;get to the heart of the actual requirement. This applies also to hardware
- and non-computer devices. For example, a lathe operator may have manufactured a special clamp, or an arm that prevents
- movement of the tool beyond a certain point. Any such modification points to something wrong with the existing product,
- which makes it&nbsp;a valid&nbsp;requirement for the new version.
-</p>
-<h4>
- Look at unintended uses
-</h4>
-<p>
- People often use things for purposes for which they were not designed.&nbsp; This is&nbsp;a good way to get new ideas
- and to think of innovations. For example, an observant product manager noticed that an engineer was staying in the
- office late to use an advanced computer-aided design system to design a new kitchen layout for his home. Inexpensive
- commercial products are now widely available for home use.
-</p>
-<h4>
- Conduct workshops
-</h4>
-<p>
- Workshops can rapidly pull together a good set of requirements. In two to five days, you can create a set of
- requirements, and then review and improve them. If everyone in a workshop tries to estimate the cost and value of each
- requirement, the document becomes much more useful and cost-effective.
-</p>
-<p>
- Workshops are quicker and better at discovering requirements than other techniques, such as sending questionnaires. You
- are bringing the right collection of people together, and getting them to correct and improve on their requirements
- document.
-</p>
-<p>
- A workshop is inherently expensive because of the number of people involved, but it saves a large amount of time. If
- you can define the product right the first time and cut three months off the requirements gathering, the savings could
- be enormous. The workshop has to be thoroughly organized to take advantage of people's time.
-</p>
-<p>
- Choose a quiet location for the workshop so that people are not disturbed by day-to-day business. Mobile phones should
- be discouraged; arrange to take messages externally. Take advantage of informal interactions by choosing a site so that
- people don't go home at night or go out separately. The example&nbsp;in Figure 1&nbsp;shows the logic of a requirements
- workshop. Note that the workshop provides the environment in which to apply other requirements-gathering techniques
- such as brainstorming.
-</p>
-<p>
- <img height="381" alt="" src="resources/workshop_activity_diagram.gif" width="542" />
-</p>
-<p>
- <strong>Figure 1: Conducting Workshops</strong>
-</p>
-<h4>
- Demonstrate prototypes to stakeholders
-</h4>
-<p>
- Prototypes allow us to immediately see some aspects of the system. Showing users a simple prototype can
- provoke&nbsp;them into giving good requirements information or changing their mind about existing requirements. The
- techniques described here help you gather ideas for requirements. Prototypes and models are an excellent way of
- presenting ideas to users. They can illustrate how an approach might work, or give users a glimpse of what they might
- be able to do. More requirements are likely to emerge when users see what you are suggesting.
-</p>
-<p>
- A presentation can use a sequence of slides, storyboard, an artist's impression, or even an animation to give users a
- vision of the possibilities. When prototyping software, make a mock-up of the user interface screens, emphasizing that
- there is no code and that the system has not been designed or even specified yet (fair warning: there are dangers here
- for the unwary).
-</p>
-<p>
- This prototyping aims to get users to express (missing) requirements. You are not trying to sell users an idea or
- product, you are finding out what they actually want. Seeing a prototype, which invariably is wrong in some ways and
- right in others, is a powerful stimulus to users to start saying what they want. They may point out plenty of problems
- with the prototype! This is excellent,&nbsp;because each problem leads to a new requirement.
-</p>
-<h3>
- Which Technique to Apply?
-</h3>
-<p>
- Which technique to apply depends on a number of factors, such as:
-</p>
-<ul>
- <li>
- Availability and location of stakeholders
- </li>
- <li>
- Development team knowledge of the problem domain
- </li>
- <li>
- Customers' and users' knowledge of the problem domain
- </li>
- <li>
- Customers' and users' knowledge of the development process and methods
- </li>
-</ul>
-<p>
- If the stakeholders are not co-located or readily available, for example in the case of a product being developed for
- mass market,&nbsp;techniques such as brainstorming, interviews and workshops that require face-to-face contact with the
- stakeholders may be difficult or impossible.
-</p>
-<p>
- If the stakeholders are available for face-to-face meetings, this is a much better situation and almost all of the
- techniques described, or combination of them, may be applied. In this case, the domain and development experience of
- both the stakeholders and the development team are critical factors in selecting the appropriate technique.
-</p>
-<p>
- Figure 2, adapted from <a
- href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
- guid="_9ToeIB83Edqsvps02rpOOg">[HIC03]</a>, provides a framework for determining the appropriate techniques. It defines
- four main categories of customer or user experience and development team experience: "Fuzzy problem",
- "Selling/Teaching", "Catch up", and "Mature".
-</p>
-<p>
- <img height="470" alt="" src="resources/which_req_gathering_technique.gif" width="514" />
-</p>
-<p>
- <strong>Figure 2: Selection of Techniques</strong>
-</p>
-<p>
- There is no "right answer", but these guidelines may help you decide which method to use:
-</p>
-<ul>
- <li>
- Catch-up: Interviews, work in target environment
- </li>
- <li>
- Fuzzy: Brainstorming, workshops
- </li>
- <li>
- Mature: Questionnaires, workshops, prototypes
- </li>
- <li>
- Selling/Teaching: prototypes
- </li>
+ <mainDescription><h3>
+ Sources of Requirements
+</h3>
+<p>
+ Good requirements start with good sources. Finding those quality sources is an important task and, fortunately, one
+ that&nbsp;takes few&nbsp;resources. Examples of sources of requirements include:
+</p>
+<ul>
+ <li>
+ Customers
+ </li>
+ <li>
+ Users
+ </li>
+ <li>
+ Administrators and maintenance&nbsp;staff
+ </li>
+ <li>
+ Partners
+ </li>
+ <li>
+ Domain Experts
+ </li>
+ <li>
+ Industry Analysts
+ </li>
+ <li>
+ Information about competitors&nbsp;
+ </li>
+</ul>
+<h3>
+ Requirements Gathering Techniques
+</h3>
+<p>
+ After you have identified these sources, there are a number of techniques that may be used to gather requirements. The
+ following will describe the various techniques, followed by a brief discussion of when to use each technique.
+</p>
+<p>
+ To get the requirements down on paper, you&nbsp;can to do one or more of the following:
+</p>
+<ul>
+ <li>
+ Conduct a brainstorming session
+ </li>
+ <li>
+ Interview users
+ </li>
+ <li>
+ Send questionnaires
+ </li>
+ <li>
+ Work in the target environment
+ </li>
+ <li>
+ Study analogous systems
+ </li>
+ <li>
+ Examine suggestions and problem reports
+ </li>
+ <li>
+ Talk to support teams
+ </li>
+ <li>
+ Study improvements made by users
+ </li>
+ <li>
+ Look at unintended uses
+ </li>
+ <li>
+ Conduct workshops
+ </li>
+ <li>
+ Demonstrate prototypes to stakeholders
+ </li>
+</ul>
+<p>
+ The best idea is to get the requirements down quickly and then to encourage the users to correct and improve them. Put
+ in those corrections, and repeat the cycle. Do it now, keep it small, and correct it at once. Start off with the best
+ structure you can devise, but expect to keep on correcting it throughout the process.&nbsp; Success tips: Do it now,
+ keep it small, and correct it immediately.
+</p>
+<h4>
+ Conduct a brainstorming session
+</h4>
+<p>
+ Brainstorming is a short group session where everyone is allowed to say whatever they feel is important to the topic of
+ discussion. After that, a facilitator leads the group in organizing and prioritizing the results.&nbsp; The following
+ basic rules for brainstorming&nbsp;ensures better results:
+</p>
+<ul>
+ <li>
+ Start out by clearly stating the objective of the brainstorming session.
+ </li>
+ <li>
+ Generate as may ideas as possible.
+ </li>
+ <li>
+ Let your imagination soar.
+ </li>
+ <li>
+ Do not allow criticism or debate while you are gathering information.
+ </li>
+ <li>
+ Once information is gathered,&nbsp;reshape and combine ideas.
+ </li>
+</ul>
+<h4>
+ Interview users
+</h4>
+<p>
+ Face-to-face contact with users through individual interviewing is the primary source of requirements and an important
+ way you gather and validate their requirements. Remember that it is not the only possible technique, and that you can
+ conduct interviews many different ways. Develop a repertoire of styles to&nbsp;fit different situations. Unless you use
+ the system yourself, you will need to make an effort to understand and experience the user's problem to describe it
+ clearly and correctly.
+</p>
+<h4>
+ Send Questionnaires
+</h4>
+<p>
+ If face-to-face meetings are possible, they are always preferable, because they provide a better means of uncovering
+ the problem behind the problem. Sometimes, though,&nbsp;face-to-face meetings with stakeholders are not feasible (when
+ developing products for the consumer market, for example). In those situations, consider using questionnaires.&nbsp;
+ Send a set of questions, possibly with multiple choice responses, to the relevant stakeholders, and ask them to
+ complete it and return it to you.&nbsp; Success&nbsp;tips: Keep it short and given them a deadline.&nbsp;
+</p>
+<p>
+ This technique has the advantage of providing a lot of information for statistical analysis. However, the questions
+ must be well designed to be clear and to avoid so-called "leading questions", which bias the responses.&nbsp;
+</p>
+<h4>
+ Work in the target environment
+</h4>
+<p>
+ Experience the work of the users for yourself. Working with users helps you understand problems that have resisted
+ previous solutions. Familiar systems developed in this way inevitably include tools for programmers, such as
+ interactive editors and compilers, as the developers naturally have both the expertise in the subject area, and the
+ desire to solve their own problems. It would be good to see the same dedication devoted to solving problems in other
+ areas too. Where the work cannot easily be experienced in this way, it may still be possible to do a bit more than just
+ sit quietly and observe. Users can give you a commentary on what they are doing, what the problems are, and what they
+ would like to have to make the work easier.
+</p>
+<h4>
+ Study analogous systems
+</h4>
+<p>
+ The starting point for many projects is often a similar or an existing system. Sometimes, comparable products and
+ systems contain working versions of good ideas for solving user problems. You can save the time lost in reinventing the
+ wheel by looking at systems already on the market, whether they are systems installed at the user's site or products
+ made by rival organizations. Even if they are trying to solve slightly different problems, they often&nbsp;provide
+ valuable clues as to what you need to do.
+</p>
+<p>
+ Listen when a customer asks why a product couldn't do something that the customer wants, and keep a list of these
+ suggestions. Later, use it to start discussions with other users. You should be able to obtain some requirements
+ directly this way. If not, capture and store suggestions for future use.
+</p>
+<p>
+ You can describe to users selected features of other products. Explain that the system is designed for&nbsp;another
+ purpose&nbsp;but contains an interesting feature, and you wonder it or something similar&nbsp;would help them.
+ Sometimes these systems are described in documents, such as a contract from another organization or a report written
+ for management. Often, these documents were never intended as formal requirements, and were written merely to
+ communicate a stream-of-consciousness idea. Define a process of going from disorganized to organized information.
+</p>
+<p>
+ Such a process might involve the following activities:
+</p>
+<ul>
+ <li>
+ Read the document from end to end (several times) to comprehend what the customer wants and what actually has been
+ written.
+ </li>
+ <li>
+ Classify all of the types of information in the document. (user, system requirements, design elements, plans,
+ background material, irrelevant detail)
+ </li>
+ <li>
+ Mark up the original text to separate out such requirements.
+ </li>
+ <li>
+ Find a good structure for each of the different types of information such as: a scenario for the user requirements,
+ functional breakdown for the system requirements, and architecture for the design.
+ </li>
+ <li>
+ Organize the information to show gaps and overlaps. Feel free to add missing elements, but confirm these decisions
+ with the users.
+ </li>
+ <li>
+ Create traceability links between these information elements to show the designers exactly what the users want.
+ </li>
+ <li>
+ Convince the customer to accept the new information as the basis for the contract.
+ </li>
+</ul>
+<h4>
+ Examine suggestions and problem reports
+</h4>
+<p>
+ Requirements can come from change suggestions and user problems. A direct road to finding requirements is to look at
+ suggestions and problems as first described. Most organizations have a form for reporting system problems or software
+ defects. You can ask to look through the reports (and there will probably be many). Sort them into groups so you can
+ identify the key areas that are troubling users. Ask users some questions about these areas to clarify the users'
+ actual needs.
+</p>
+<h4>
+ Talk to support teams
+</h4>
+<p>
+ Most large sales organizations have a help desk that keeps a log of problems and fixes, and support engineers who do
+ the fixing. Many organizations have similar facilities to support their own operations. Talking to the help desk staff
+ and the support engineers may give you good leads into the requirements, and save you time. Also talk to the training
+ team and installation teams about what users find to be&nbsp;difficult.
+</p>
+<h4>
+ Study improvements made by users
+</h4>
+<p>
+ This is an excellent source of requirements. Users of a standard company spreadsheet may have added a few fields, or
+ related different sheets together, or drawn a graph, that exactly meets their individual needs. You need only ask: Why
+ did you add that? Their answers help you&nbsp;get to the heart of the actual requirement. This applies also to hardware
+ and non-computer devices. For example, a lathe operator may have manufactured a special clamp, or an arm that prevents
+ movement of the tool beyond a certain point. Any such modification points to something wrong with the existing product,
+ which makes it&nbsp;a valid&nbsp;requirement for the new version.
+</p>
+<h4>
+ Look at unintended uses
+</h4>
+<p>
+ People often use things for purposes for which they were not designed.&nbsp; This is&nbsp;a good way to get new ideas
+ and to think of innovations. For example, an observant product manager noticed that an engineer was staying in the
+ office late to use an advanced computer-aided design system to design a new kitchen layout for his home. Inexpensive
+ commercial products are now widely available for home use.
+</p>
+<h4>
+ Conduct workshops
+</h4>
+<p>
+ Workshops can rapidly pull together a good set of requirements. In two to five days, you can create a set of
+ requirements, and then review and improve them. If everyone in a workshop tries to estimate the cost and value of each
+ requirement, the document becomes much more useful and cost-effective.
+</p>
+<p>
+ Workshops are quicker and better at discovering requirements than other techniques, such as sending questionnaires. You
+ are bringing the right collection of people together, and getting them to correct and improve on their requirements
+ document.
+</p>
+<p>
+ A workshop is inherently expensive because of the number of people involved, but it saves a large amount of time. If
+ you can define the product right the first time and cut three months off the requirements gathering, the savings could
+ be enormous. The workshop has to be thoroughly organized to take advantage of people's time.
+</p>
+<p>
+ Choose a quiet location for the workshop so that people are not disturbed by day-to-day business. Mobile phones should
+ be discouraged; arrange to take messages externally. Take advantage of informal interactions by choosing a site so that
+ people don't go home at night or go out separately. The example&nbsp;in Figure 1&nbsp;shows the logic of a requirements
+ workshop. Note that the workshop provides the environment in which to apply other requirements-gathering techniques
+ such as brainstorming.
+</p>
+<p>
+ <img height="381" alt="" src="resources/workshop_activity_diagram.gif" width="542" />
+</p>
+<p>
+ <strong>Figure 1: Conducting Workshops</strong>
+</p>
+<h4>
+ Demonstrate prototypes to stakeholders
+</h4>
+<p>
+ Prototypes allow us to immediately see some aspects of the system. Showing users a simple prototype can
+ provoke&nbsp;them into giving good requirements information or changing their mind about existing requirements. The
+ techniques described here help you gather ideas for requirements. Prototypes and models are an excellent way of
+ presenting ideas to users. They can illustrate how an approach might work, or give users a glimpse of what they might
+ be able to do. More requirements are likely to emerge when users see what you are suggesting.
+</p>
+<p>
+ A presentation can use a sequence of slides, storyboard, an artist's impression, or even an animation to give users a
+ vision of the possibilities. When prototyping software, make a mock-up of the user interface screens, emphasizing that
+ there is no code and that the system has not been designed or even specified yet (fair warning: there are dangers here
+ for the unwary).
+</p>
+<p>
+ This prototyping aims to get users to express (missing) requirements. You are not trying to sell users an idea or
+ product, you are finding out what they actually want. Seeing a prototype, which invariably is wrong in some ways and
+ right in others, is a powerful stimulus to users to start saying what they want. They may point out plenty of problems
+ with the prototype! This is excellent,&nbsp;because each problem leads to a new requirement.
+</p>
+<h3>
+ Which Technique to Apply?
+</h3>
+<p>
+ Which technique to apply depends on a number of factors, such as:
+</p>
+<ul>
+ <li>
+ Availability and location of stakeholders
+ </li>
+ <li>
+ Development team knowledge of the problem domain
+ </li>
+ <li>
+ Customers' and users' knowledge of the problem domain
+ </li>
+ <li>
+ Customers' and users' knowledge of the development process and methods
+ </li>
+</ul>
+<p>
+ If the stakeholders are not co-located or readily available, for example in the case of a product being developed for
+ mass market,&nbsp;techniques such as brainstorming, interviews and workshops that require face-to-face contact with the
+ stakeholders may be difficult or impossible.
+</p>
+<p>
+ If the stakeholders are available for face-to-face meetings, this is a much better situation and almost all of the
+ techniques described, or combination of them, may be applied. In this case, the domain and development experience of
+ both the stakeholders and the development team are critical factors in selecting the appropriate technique.
+</p>
+<p>
+ Figure 2, adapted from <a
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[HIC03]</a>, provides a framework for determining the appropriate techniques. It defines
+ four main categories of customer or user experience and development team experience: "Fuzzy problem",
+ "Selling/Teaching", "Catch up", and "Mature".
+</p>
+<p>
+ <img height="470" alt="" src="resources/which_req_gathering_technique.gif" width="514" />
+</p>
+<p>
+ <strong>Figure 2: Selection of Techniques</strong>
+</p>
+<p>
+ There is no "right answer", but these guidelines may help you decide which method to use:
+</p>
+<ul>
+ <li>
+ Catch-up: Interviews, work in target environment
+ </li>
+ <li>
+ Fuzzy: Brainstorming, workshops
+ </li>
+ <li>
+ Mature: Questionnaires, workshops, prototypes
+ </li>
+ <li>
+ Selling/Teaching: prototypes
+ </li>
</ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/requirement_pitfalls.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/requirement_pitfalls.xmi
index 894973c..e16e778 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/requirement_pitfalls.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/requirement_pitfalls.xmi
@@ -1,250 +1,252 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-Q72-dNdHnZ93aRXAB_d34A" name="requirement_pitfalls_1,_1AOsMO0JEdqHTdbLTmC5IQ" guid="-Q72-dNdHnZ93aRXAB_d34A" authors="Chris Sibbald" changeDate="2006-09-27T10:14:43.000-0700" version="0.2">
- <mainDescription><p>
- Explanations and examples follow for each of the following common pitfalls to avoid in defining and writing
- requirements (for more information, see <a href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html" guid="_9ToeIB83Edqsvps02rpOOg">[TEL06]</a>):
-</p>
-<ul>
- <li>
- Avoid ambiguity
- </li>
- <li>
- Don't make multiple requirements
- </li>
- <li>
- Never use let-out or escape words
- </li>
- <li>
- Don't ramble
- </li>
- <li>
- Resist designing the system
- </li>
- <li>
- Avoid mixing different kinds of requirements
- </li>
- <li>
- Do not speculate
- </li>
- <li>
- Do not use vague, undefined terms
- </li>
- <li>
- Do not express possibilities
- </li>
- <li>
- Avoid wishful thinking
- </li>
-</ul>
-<h4>
- Avoid ambiguity
-</h4>
-<p>
- Avoidance of ambiguity is one of the subtlest and most difficult issues in writing requirements. Try to write as
- clearly and explicitly as possible. Be specific. Remember, though, that if you carry this too far, the text becomes
- dull and unreadable, which makes it difficult for other people to review. Although this guideline emphasizes
- structured, written expression of requirements, informal text, diagrams, conversations, and phone calls are excellent
- ways of removing ambiguity.
-</p>
-<p>
- Some constructions (such as the use of or and unless in requirements) allow different groups of readers to understand
- different things from the same wording. Developers could use this technique deliberately, so as to postpone, until too
- late, any possibility of the customer's asking for what was truly wanted. This is dangerous and could easily backfire.
-</p>
-<p>
- The only approach that works is for developers to make requirements as clear as possible, and for all stakeholders to
- co-operate. In the long run, project success is in everybody's interest.
-</p>
-<p>
- Dangerous ambiguities can be caused by the word <strong>or</strong> and also by many more-subtle errors.
-</p>
-<h5>
- Example
-</h5>
-<p>
- <em>The same subsystem shall also be able to generate a visible or audible caution/warning signal for the attention of
- the co-pilot or navigator.</em>
-</p>
-<p>
- Which subsystem? Is the signal to be visible, audible, or both? Is it both caution and warning, just caution, or just
- warning? Is it for both the co-pilot and the navigator, or just one of them? If just one of them, which one and under
- what conditions?
-</p>
-<h4>
- Don't make multiple requirements
-</h4>
-<p>
- Requirements which contain conjunctions (words that join independent clauses together) are dangerous. Problems arise
- when readers try to figure out which part applies, especially if the different clauses seem to conflict, or if the
- individual parts apply separately. Multiple requirements also make verification more complex.
-</p>
-<p>
- Dangerous conjunctions include: and, or, but
-</p>
-<h5>
- Example
-</h5>
-<p>
- <em>The battery low warning lamp shall light up when the voltage drops below 3.6 Volts, and the current workspace or
- input data shall be saved.</em>
-</p>
-<p>
- Should the battery low warning lamp light up when the voltage drops and the workspace is saved? Should the battery low
- warning lamp light up and the workspace be saved when the voltage drops?
-</p>
-<h4>
- Never use let-out or escape words
-</h4>
-<p>
- Requirements that include options or exceptions are dangerous. They seem to ask for something definite, but at the last
- moment they back down and allow for other options. Problems arise when the requirements are to be tested, and someone
- has to decide what (if anything) could prove the requirement was met.
-</p>
-<p>
- Dangerous words that imply exceptions include: if, when, but, except, unless, although.
-</p>
-<h5>
- Examples
-</h5>
-<p>
- <em>The forward passenger doors shall open automatically when the aircraft has halted, except when the rear ramp is
- deployed.</em>
-</p>
-<p>
- <em>The fire alarm shall always be sounded when smoke is detected, unless the alarm is being tested or the engineer has
- suppressed the alarm.</em>
-</p>
-<p>
- The latter sentence is a truly dangerous requirement!
-</p>
-<h4>
- Don't ramble
-</h4>
-<p>
- Long rambling sentences, especially when combined with arcane language, references to unreachable documents, and other
- defects of writing, quickly lead to confusion and error.
-</p>
-<h5>
- Example
-</h5>
-<p>
- <em>Provided that the designated input signals from the specified devices are received in the correct order where the
- system is able to differentiate the designators, the output signal shall comply with the required framework of section
- 3.1.5 to indicate the desired input state.</em>
-</p>
-<h4>
- Resist designing the system
-</h4>
-<p>
- Requirements should specify the design envelope without unnecessary constraints on a specific design. If we supply too
- much detail we start to design the system. Going too far is tempting for designers, especially when they come to their
- favorite bits.
-</p>
-<p>
- Danger signs include names of components, materials, software objects/procedures, and database fields.
-</p>
-<h5>
- Example
-</h5>
-<p>
- <em>The antenna shall be capable of receiving FM signals, using a copper core with nylon covering and a waterproof
- hardened rubber shield.</em>
-</p>
-<p>
- Specifying design rather than actual need increases the cost of systems by placing needless constraints on development
- and manufacture. Often knowing why is much better than knowing what.
-</p>
-<h4>
- Avoid mixing different kinds of requirements
-</h4>
-<p>
- The user requirements form a complete model of what users want. They need to be organized coherently to show gaps and
- overlaps. The same applies to system requirements, which form a complete functional model of the proposed system. A
- quick road to confusion is to mix up requirements for users, systems, and how the system should be designed, tested, or
- installed.
-</p>
-<p>
- Danger signs are any references to system, design, testing, or installation.
-</p>
-<h5>
- Example
-</h5>
-<p>
- <em>The user shall be able to view the currently selected channel number which shall be displayed in 14pt Swiss type on
- an LCD panel tested to Federal Regulation Standard 567-89 and mounted with shockproof rubber washers.</em>
-</p>
-<h4>
- Do not speculate
-</h4>
-<p>
- Requirements are part of a contract between customer and developer. There is no room for wish lists, meaning general
- terms about things that somebody probably wants.
-</p>
-<p>
- Danger signs include vagueness about which type of user is speaking, and generalization such as: usually, generally,
- often, normally, typically
-</p>
-<h5>
- Example
-</h5>
-<p>
- <em>Users normally require early indication of intrusion into the system.</em>
-</p>
-<h4>
- Do not use vague, undefined terms
-</h4>
-<p>
- Many words used informally to indicate system quality are too vague for use in requirements. Vague terms include, among
- others: user-friendly, versatile, flexible, approximately, as possible
-</p>
-<p>
- Requirements using these terms are unverifiable because there is no definite test to show whether the system has the
- indicated property.
-</p>
-<h5>
- Examples
-</h5>
-<p>
- <em>The print dialog shall be versatile and user-friendly.</em>
-</p>
-<p>
- <em>The OK status indicator lamp shall be illuminated as soon as possible after the system self-check is
- completed.</em>
-</p>
-<h4>
- Do not express possibilities
-</h4>
-<p>
- Suggestions that are not explicitly stated as requirements are invariably ignored by developers.
-</p>
-<p>
- "Possible options" are indicated with terms such as: may, might, should, ought, could, perhaps, probably
-</p>
-<h5>
- Example
-</h5>
-<p>
- <em>The reception subsystem probably ought to be powerful enough to receive a signal inside a steel-framed
- building.</em>
-</p>
-<h4>
- Avoid wishful thinking
-</h4>
-<p>
- Engineering is a real-world activity. No system or component is perfect. Wishful thinking means asking for the
- impossible.
-</p>
-<p>
- Wishful-thinking terms include: reliable, safe, handle all unexpected failures, please all users, run on all platforms,
- never fail, upgradeable to all future situations
-</p>
-<h5>
- Examples
-</h5>
-<p>
- <em>The gearbox shall be 100% safe in normal operation.</em>
-</p>
-<p>
- <em>The network shall handle all unexpected errors without crashing.</em>
+ <mainDescription><p>
+ Explanations and examples follow for each of the following common pitfalls to avoid in defining and writing
+ requirements (for more information, see <a
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[TEL06]</a>):
+</p>
+<ul>
+ <li>
+ Avoid ambiguity.
+ </li>
+ <li>
+ Don't make multiple requirements.
+ </li>
+ <li>
+ Never use let-out or escape words.
+ </li>
+ <li>
+ Don't ramble.
+ </li>
+ <li>
+ Resist designing the system.
+ </li>
+ <li>
+ Avoid mixing different kinds of requirements.
+ </li>
+ <li>
+ Do not speculate.
+ </li>
+ <li>
+ Do not use vague, undefined terms.
+ </li>
+ <li>
+ Do not express possibilities.
+ </li>
+ <li>
+ Avoid wishful thinking.
+ </li>
+</ul>
+<h4>
+ Avoid ambiguity.
+</h4>
+<p>
+ Avoidance of ambiguity is one of the subtlest and most difficult issues in writing requirements. Try to write as
+ clearly and explicitly as possible. Be specific. Remember, though, that if you carry this too far, the text becomes
+ dull and unreadable, which makes it difficult for other people to review. Although this guideline emphasizes
+ structured, written expression of requirements, informal text, diagrams, conversations, and phone calls are excellent
+ ways of removing ambiguity.
+</p>
+<p>
+ Some constructions (such as the use of or and unless in requirements) allow different groups of readers to understand
+ different things from the same wording. Developers could use this technique deliberately, so as to postpone, until too
+ late, any possibility of the customer's asking for what was truly wanted. This is dangerous and could easily backfire.
+</p>
+<p>
+ The only approach that works is for developers to make requirements as clear as possible, and for all stakeholders to
+ co-operate. In the long run, project success is in everybody's interest.
+</p>
+<p>
+ Dangerous ambiguities can be caused by the word <strong>or</strong> and also by many more-subtle errors.
+</p>
+<h5>
+ Example
+</h5>
+<p>
+ <em>The same subsystem shall also be able to generate a visible or audible caution/warning signal for the attention of
+ the co-pilot or navigator.</em>
+</p>
+<p>
+ Which subsystem? Is the signal to be visible, audible, or both? Is it both caution and warning, just caution, or just
+ warning? Is it for both the co-pilot and the navigator, or just one of them? If just one of them, which one and under
+ what conditions?
+</p>
+<h4>
+ Don't make multiple requirements.
+</h4>
+<p>
+ Requirements which contain conjunctions (words that join independent clauses together) are dangerous. Problems arise
+ when readers try to figure out which part applies, especially if the different clauses seem to conflict, or if the
+ individual parts apply separately. Multiple requirements also make verification more complex.
+</p>
+<p>
+ Dangerous conjunctions include: and, or, but.
+</p>
+<h5>
+ Example
+</h5>
+<p>
+ <em>The battery low warning lamp shall light up when the voltage drops below 3.6 Volts, and the current workspace or
+ input data shall be saved.</em>
+</p>
+<p>
+ Should the battery low warning lamp light up when the voltage drops and the workspace is saved? Should the battery low
+ warning lamp light up and the workspace be saved when the voltage drops?
+</p>
+<h4>
+ Never use let-out or escape words
+</h4>
+<p>
+ Requirements that include options or exceptions are dangerous. They seem to ask for something definite, but at the last
+ moment they back down and allow for other options. Problems arise when the requirements are to be tested, and someone
+ has to decide what (if anything) could prove the requirement was met.
+</p>
+<p>
+ Dangerous words that imply exceptions include: if, when, but, except, unless, although.
+</p>
+<h5>
+ Examples
+</h5>
+<p>
+ <em>The forward passenger doors shall open automatically when the aircraft has halted, except when the rear ramp is
+ deployed.</em>
+</p>
+<p>
+ <em>The fire alarm shall always be sounded when smoke is detected, unless the alarm is being tested or the engineer has
+ suppressed the alarm.</em>
+</p>
+<p>
+ The latter sentence is a truly dangerous requirement!
+</p>
+<h4>
+ Don't ramble.
+</h4>
+<p>
+ Long rambling sentences, especially when combined with arcane language, references to unreachable documents, and other
+ defects of writing, quickly lead to confusion and error.
+</p>
+<h5>
+ Example
+</h5>
+<p>
+ <em>Provided that the designated input signals from the specified devices are received in the correct order where the
+ system is able to differentiate the designators, the output signal shall comply with the required framework of section
+ 3.1.5 to indicate the desired input state.</em>
+</p>
+<h4>
+ Resist designing the system
+</h4>
+<p>
+ Requirements should specify the design envelope without unnecessary constraints on a specific design. If we supply too
+ much detail we start to design the system. Going too far is tempting for designers, especially when they come to their
+ favorite bits.
+</p>
+<p>
+ Danger signs include names of components, materials, software objects/procedures, and database fields.
+</p>
+<h5>
+ Example
+</h5>
+<p>
+ <em>The antenna shall be capable of receiving FM signals, using a copper core with nylon covering and a waterproof
+ hardened rubber shield.</em>
+</p>
+<p>
+ Specifying design rather than actual need increases the cost of systems by placing needless constraints on development
+ and manufacture. Often knowing why is much better than knowing what.
+</p>
+<h4>
+ Avoid mixing different kinds of requirements
+</h4>
+<p>
+ The user requirements form a complete model of what users want. They need to be organized coherently to show gaps and
+ overlaps. The same applies to system requirements, which form a complete functional model of the proposed system. A
+ quick road to confusion is to mix up requirements for users, systems, and how the system should be designed, tested, or
+ installed.
+</p>
+<p>
+ Danger signs are any references to system, design, testing, or installation.
+</p>
+<h5>
+ Example
+</h5>
+<p>
+ <em>The user shall be able to view the currently selected channel number which shall be displayed in 14pt Swiss type on
+ an LCD panel tested to Federal Regulation Standard 567-89 and mounted with shockproof rubber washers.</em>
+</p>
+<h4>
+ Do not speculate.
+</h4>
+<p>
+ Requirements are part of a contract between customer and developer. There is no room for wish lists, meaning general
+ terms about things that somebody probably wants.
+</p>
+<p>
+ Danger signs include vagueness about which type of user is speaking, and generalization such as: usually, generally,
+ often, normally, typically.
+</p>
+<h5>
+ Example
+</h5>
+<p>
+ <em>Users normally require early indication of intrusion into the system.</em>
+</p>
+<h4>
+ Do not use vague, undefined terms
+</h4>
+<p>
+ Many words used informally to indicate system quality are too vague for use in requirements. Vague terms include, among
+ others: user-friendly, versatile, flexible, approximately, as possible.
+</p>
+<p>
+ Requirements using these terms are unverifiable because there is no definite test to show whether the system has the
+ indicated property.
+</p>
+<h5>
+ Examples
+</h5>
+<p>
+ <em>The print dialog shall be versatile and user-friendly.</em>
+</p>
+<p>
+ <em>The OK status indicator lamp shall be illuminated as soon as possible after the system self-check is
+ completed.</em>
+</p>
+<h4>
+ Do not express possibilities.
+</h4>
+<p>
+ Suggestions that are not explicitly stated as requirements are invariably ignored by developers.
+</p>
+<p>
+ "Possible options" are indicated with terms such as: may, might, should, ought, could, perhaps, probably
+</p>
+<h5>
+ Example
+</h5>
+<p>
+ <em>The reception subsystem probably ought to be powerful enough to receive a signal inside a steel-framed
+ building.</em>
+</p>
+<h4>
+ Avoid wishful thinking.
+</h4>
+<p>
+ Engineering is a real-world activity. No system or component is perfect. Wishful thinking means asking for the
+ impossible.
+</p>
+<p>
+ Wishful-thinking terms include: reliable, safe, handle all unexpected failures, please all users, run on all platforms,
+ never fail, upgradeable to all future situations.
+</p>
+<h5>
+ Examples
+</h5>
+<p>
+ <em>The gearbox shall be 100% safe in normal operation.</em>
+</p>
+<p>
+ <em>The network shall handle all unexpected errors without crashing.</em>
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/software_reuse.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/software_reuse.xmi
index 3214e75..ca22812 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/software_reuse.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/software_reuse.xmi
@@ -1,229 +1,238 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-Vp61zQMUoP-Icm5jgDar7A" name="new_guideline,_vO2uoO0OEduUpsu85bVhiQ" guid="-Vp61zQMUoP-Icm5jgDar7A" changeDate="2008-02-15T05:30:27.000-0800" version="1.0.0">
- <mainDescription><p>
- Maximizing reuse has always been an important goal of software development. It's better to re-use than to expend the
- cost of creating something new, testing it, and releasing it for the first time with the risk of hidden problems that
- all new software has. Languages, particularly object-oriented ones, have been developed to make reuse easier. But a
- language alone isn't enough to provide cost effective reuse. The bulk of reusable software comes from skilled
- developers and architects who are able to identify and leverage reuse opportunities.
-</p>
-<h3>
- What is a Reusable Asset?
-</h3>
-<p>
- The following are some examples of reusable software assets:
-</p>
-<ul>
- <li>
- Architectural frameworks
- </li>
- <li>
- Architectural mechanisms
- </li>
- <li>
- Architectural decisions
- </li>
- <li>
- Constraints
- </li>
- <li>
- Applications
- </li>
- <li>
- Components
- </li>
- <li>
- COTS software&nbsp;
- </li>
-</ul>
-<h3>
- Identifying Reuse Opportunities
-</h3>
-<p>
- There are three perspectives to look at when reusing software: code (implementation), design, and framework or
- architecture.&nbsp; Architects should look to reuse significant application frameworks such as layers that can be
- applied to many different types of applications (for more information, see <a class="elementLinkWithType" href="./../../../core.tech.common.extend_supp/guidances/guidelines/layering_F169CF07.html" guid="_0gpkAMlgEdmt3adZL5Dmdw">Guideline: Layering</a>. Developers should look to designs and <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/concepts/pattern_10BE6D96.html" guid="_0YJvUMlgEdmt3adZL5Dmdw">Pattern</a>s that can be reused to produce desired behavior or robust structures. They
- should also look at how to reduce the amount of code that needs to be written by leveraging stable components and code
- that has been proven in production environments.
-</p>
-<p>
- The best way to enable a team to find opportunities for reuse is to exercise excellent design and coding practices.
- It's difficult to find code and design that can be reused when dealing with large classes, classes that don't have a
- clearly defined focus, or classes with relationships that are difficult to understand. Classes should be small, easy to
- understand, and highly cohesive to make it easier to identify reuse opportunities. Any functionality that can be
- reasonably separated into another class should be. Another way of saying this is that any concept that could be applied
- to more than one type of class should be its own class.
-</p>
-<p>
- For example, if some calculations are added to an existing class, it may make sense to then refactor those calculations
- into a new helper class. Those calculations can&nbsp;then be re-used in any number of other classes without the burden
- of having to know about the functionality of the original class.
-</p>
-<p>
- The simplest but least efficient way to identify reuse opportunities is to "smell" similar code. A developer may recall
- doing something similar to what they're designing or implementing now. Once the previous implementation has been
- discovered or recalled it can be reused. Developers will always find reuse opportunities this way. But the unstructured
- nature of it won't maximize the potential areas for reuse.
-</p>
-<p>
- Collaboration is a good technique for identifying reuse opportunities. It provides a structure where identifying reuse
- - instead of writing code - is the goal of the exercise. And the more brains that are looking for reuse opportunities,
- the more likely it is that they'll be found. A brainstorming or review meeting that focuses on identifying reuse
- opportunities would be useful to support this.
-</p>
-<p>
- Patterns are good ways to find reuse opportunities in designs and frameworks. See <a class="elementLinkWithType" href="./../../../core.tech.common.extend_supp/guidances/concepts/pattern_10BE6D96.html" guid="_0YJvUMlgEdmt3adZL5Dmdw">Concept: Pattern</a>&nbsp;for more information.
-</p>
-<p>
- Analyzing behavior is another good way to identify potential areas for reuse. Analyze how classes need to collaborate
- in order to deliver some specific functionality such as a requirement or feature. This collaboration can be documented
- in sequence (behavior) and class (structure) diagrams and can be reused in similar circumstances.
-</p>
-<p>
- After looking for similar behavior and returned values, then look for similarity of parameters. If their
- interfaces&nbsp;are not an exact match for the component interfaces being proposed, you can modify the
- proposed&nbsp;signatures to increase the degree of reuse. Some design mechanisms, such as performance or security
- requirements, may disqualify a component from reuse even when there is&nbsp;a perfect match between operation
- signatures.
-</p>
-<p align="left">
- A common set of components may exist that provides many of the <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_mechanism_2932DFB6.html" guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanisms</a> that you need&nbsp;for the new system. These components may
- be available either because they were developed or purchased previously for&nbsp;similar systems. Given their
- suitability and compatibility within the software architecture, there may be a need to reverse-engineer these
- components to represent them in a design model and reuse them in a project.
-</p>
-<p align="left">
- Similar thinking applies to&nbsp;existing databases. Part of the information to be used by the application under
- development may already reside in a database. You may be able to get the classes that represent the database structures
- that hold this information by reverse-engineering the database.
-</p>
-<p>
- <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/concepts/refactoring_1B63BA3B.html" guid="_Poc7IPDzEdqYgerqi84oCA">Refactoring</a> should always be considered when reusing code. Code (or design) is often
- not originally written for re-use, or reusable code may not be a perfect fit for a new situation.
-</p>
-<h3>
- Assessing and Selecting Assets to Reuse
-</h3>
-<p>
- To assess and select assets to reuse on your project, you need to understand the requirements of the system's
- environment. You also need to understand the scope and general functionality of the system that the stakeholders
- require. There are several types of assets to consider, including (but not limited to): reference architectures;
- frameworks; patterns; analysis mechanisms; classes; and experience. You can search asset&nbsp;repositories (internal or
- external to your organization) and industry literature to identify assets or similar projects.
-</p>
-<p>
- You need to assess whether available assets contribute to solving the key challenges of the current project and whether
- they are compatible with the project's architectural constraints. You also need to analyze the extent of the fit
- between assets and requirements, considering whether any of the requirements are negotiable (to enable use of the
- asset). Also, assess whether the asset could be modified or extended to satisfy requirements, as well as what the
- tradeoffs in adopting it are, in terms of cost, risk, and functionality.
-</p>
-<p>
- Leverage reuse of existing components by evaluating their interfaces and the behavior that they provide. Reuse
- components when their interfaces are similar or match the interfaces of components you would need to develop from
- scratch. If not similar, modify the newly identified interfaces so you improve the fit with existing components
- interfaces. Work with developers to gain consensus on the suitability of using existing components.
-</p>
-<p>
- Finally, decide, in principle, whether to use one or more assets, and record the rationale for this decision.
-</p>
-<h3>
- Reuse Techniques
-</h3>
-<p>
- Reuse can be performed differently depending on the capabilities of the implementation environment. The simplest
- technique is to copy the code from one place to another. This isn't advisable because it's not really reuse. Multiple
- copies of source code are difficult to maintain and can eventually diverge from each other. Reuse is about using the
- same code to perform similar tasks as a way to increase quality and reduce overhead.
-</p>
-<p>
- Some languages, such as C++, support templates. Templates, sometimes referred to as parameterized code, are a precursor
- to patterns. Templates are code with parameters that are applied just when the code's needed, at compile time. The C++
- Standard Template Library (STL) is one example. It provides many types of reusable containers (lists, sets, safe
- arrays, etc) that don't have some of the drawbacks of inheritance. Templates such as these are also useful as mix-in
- classes in languages like C++ that support multiple inheritance. Because mix-ins are implemented as templates, they
- allow for a type of multiple inheritance without the baggage.
-</p>
-<h3>
- Inheritance and Aggregation
-</h3>
-<p>
- Inheritance (also known as generalization) is an easy way to implement polymorphism and has been used as the primary
- mechanism for reuse in modern object-oriented languages. This is unfortunate, as inheritance imposes a rigid structure
- on the software's design that is difficult to change. Any inheritance hierarchy that shares code from parents to
- children will have problems when it grows to be three or more levels deep. Too many exceptions occur to maintain a pure
- "is-a" relationship between parents and children, where children are always considered to have all the properties and
- behaviors of the parents. Inheritance should be used to share definitions (interfaces), not implementations. Years of
- difficulties with inheriting implementations have made this practice a primary object-oriented design principle.
-</p>
-<p>
- Whenever inheritance is used, it is best to have only the last child class (leaf node) of the inheritance hierarchy be
- instantiated. All parent classes should be abstract. This is because a class that tries to be both reusable and
- concrete - to provide reusable and specific behavior at the same time - almost always fails to fulfill either goal.
- This is a dimension of cohesiveness. One thing that makes a class cohesive is that it's dedicated to reuse or dedicated
- to a specific implementation, but not both.
-</p>
-<p>
- Aggregation is a technique that collects or aggregates functionality into larger elements of functionality. It provides
- a structure that's far more flexible and reusable than inheritance. It's better to reuse implementation and design by
- aggregating small pieces of functionality together rather than trying to inherit the functionality from a parent.
-</p>
-<p>
- You may also find reuse opportunities by reviewing interfaces. If interfaces describe similar behavior it may be
- possible to eliminate one of the interfaces, have just one implementation realize both interfaces, or refactor the
- interfaces to put redundant content in a new, simpler interface.
-</p>
-<h3>
- Finding Reusable Code
-</h3>
-<p>
- There are many sources of reusable code beyond what the developers are writing for a specific project. Other places
- from which to harvest code include the following:
-</p>
-<ul>
- <li>
- Internal (corporate) code libraries
- </li>
- <li>
- Third party libraries
- </li>
- <li>
- Built-in language libraries
- </li>
- <li>
- Code samples from tutorials, examples, books, etc.
- </li>
- <li>
- Local code guru or knowledgeable colleague
- </li>
- <li>
- Existing system code
- </li>
- <li>
- Open source products (be sure to follow any licensing agreements)
- </li>
-</ul>
-<p>
- Also, many tools that generate code will generate comprehensive code based on minimal specification. For example, a
- design tool might generate the member variable plus a get and a set operation when the designer specifies an attribute.
- Other more sophisticated tools with knowledge of a specific framework can generate voluminous code to ensure that a
- class conforms to the framework. An example of this would be a tool that generates significant additional code when a
- class is marked as a Java entity bean. This sort of consistent transformation from a specification (the design) to an
- implementation (the code) could be considered a form of code reuse as well.
-</p>
-<h3>
- Don't Reuse Everything
-</h3>
-<p>
- Reuse makes code and design cheap to use but expensive to build. It requires experience and thoughtful consideration to
- create an implementation or design that's abstract enough for others to re-use, but concrete enough to be truly useful.
- Reusable code must also be maintained. Many organizations have difficulty assigning responsibility for maintaining
- reusable code if they don't have a group dedicated to reuse.
-</p>
-<p>
- It's usually not a good idea to create code or designs for reuse unless you know it's going to be reused. It's better
- to refactor software to be more reusable after it's discovered that they can be reused. One rule of thumb is to write
- for reuse only when you know you'll use it at least 3 times. Otherwise the cost of building and maintaining that part
- of the software will not be recovered by reduced overhead in other areas of development.
+ <mainDescription><p>
+ Maximizing reuse has always been an important goal of software development. It's better to re-use than to expend the
+ cost of creating something new, testing it, and releasing it for the first time with the risk of hidden problems that
+ all new software has. Languages, particularly object-oriented ones, have been developed to make reuse easier. But a
+ language alone isn't enough to provide cost effective reuse. The bulk of reusable software comes from skilled
+ developers and architects who are able to identify and leverage reuse opportunities.
+</p>
+<h3>
+ What is a Reusable Asset?
+</h3>
+<p>
+ The following are some examples of reusable software assets:
+</p>
+<ul>
+ <li>
+ Architectural frameworks
+ </li>
+ <li>
+ Architectural mechanisms
+ </li>
+ <li>
+ Architectural decisions
+ </li>
+ <li>
+ Constraints
+ </li>
+ <li>
+ Applications
+ </li>
+ <li>
+ Components
+ </li>
+ <li>
+ COTS software&nbsp;
+ </li>
+</ul>
+<h3>
+ Identifying Reuse Opportunities
+</h3>
+<p>
+ There are three perspectives to look at when reusing software: code (implementation), design, and framework or
+ architecture.&nbsp; Architects should look to reuse significant application frameworks such as layers that can be
+ applied to many different types of applications (for more information, see <a class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/guidelines/layering_F169CF07.html"
+ guid="_0gpkAMlgEdmt3adZL5Dmdw">Guideline: Layering</a>. Developers should look to designs and <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/pattern_10BE6D96.html"
+ guid="_0YJvUMlgEdmt3adZL5Dmdw">Pattern</a>s that can be reused to produce desired behavior or robust structures. They
+ should also look at how to reduce the amount of code that needs to be written by leveraging stable components and code
+ that has been proven in production environments.
+</p>
+<p>
+ The best way to enable a team to find opportunities for reuse is to exercise excellent design and coding practices.
+ It's difficult to find code and design that can be reused when dealing with large classes, classes that don't have a
+ clearly defined focus, or classes with relationships that are difficult to understand. Classes should be small, easy to
+ understand, and highly cohesive to make it easier to identify reuse opportunities. Any functionality that can be
+ reasonably separated into another class should be. Another way of saying this is that any concept that could be applied
+ to more than one type of class should be its own class.
+</p>
+<p>
+ For example, if some calculations are added to an existing class, it may make sense to then refactor those calculations
+ into a new helper class. Those calculations can&nbsp;then be re-used in any number of other classes without the burden
+ of having to know about the functionality of the original class.
+</p>
+<p>
+ The simplest but least efficient way to identify reuse opportunities is to "smell" similar code. A developer may recall
+ doing something similar to what they're designing or implementing now. Once the previous implementation has been
+ discovered or recalled it can be reused. Developers will always find reuse opportunities this way. But the unstructured
+ nature of it won't maximize the potential areas for reuse.
+</p>
+<p>
+ Collaboration is a good technique for identifying reuse opportunities. It provides a structure where identifying reuse
+ - instead of writing code - is the goal of the exercise. And the more brains that are looking for reuse opportunities,
+ the more likely it is that they'll be found. A brainstorming or review meeting that focuses on identifying reuse
+ opportunities would be useful to support this.
+</p>
+<p>
+ Patterns are good ways to find reuse opportunities in designs and frameworks. See <a class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/pattern_10BE6D96.html"
+ guid="_0YJvUMlgEdmt3adZL5Dmdw">Concept: Pattern</a>&nbsp;for more information.
+</p>
+<p>
+ Analyzing behavior is another good way to identify potential areas for reuse. Analyze how classes need to collaborate
+ in order to deliver some specific functionality such as a requirement or feature. This collaboration can be documented
+ in sequence (behavior) and class (structure) diagrams and can be reused in similar circumstances.
+</p>
+<p>
+ After looking for similar behavior and returned values, then look for similarity of parameters. If their
+ interfaces&nbsp;are not an exact match for the component interfaces being proposed, you can modify the
+ proposed&nbsp;signatures to increase the degree of reuse. Some design mechanisms, such as performance or security
+ requirements, may disqualify a component from reuse even when there is&nbsp;a perfect match between operation
+ signatures.
+</p>
+<p align="left">
+ A common set of components may exist that provides many of the <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_mechanism_2932DFB6.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a> that you need&nbsp;for the new system. These components may
+ be available either because they were developed or purchased previously for&nbsp;similar systems. Given their
+ suitability and compatibility within the software architecture, there may be a need to reverse-engineer these
+ components to represent them in a design model and reuse them in a project.
+</p>
+<p align="left">
+ Similar thinking applies to&nbsp;existing databases. Part of the information to be used by the application under
+ development may already reside in a database. You may be able to get the classes that represent the database structures
+ that hold this information by reverse-engineering the database.
+</p>
+<p>
+ <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/concepts/refactoring_1B63BA3B.html"
+ guid="_Poc7IPDzEdqYgerqi84oCA">Refactoring</a> should always be considered when reusing code. Code (or design) is often
+ not originally written for re-use, or reusable code may not be a perfect fit for a new situation.
+</p>
+<h3>
+ Assessing and Selecting Assets to Reuse
+</h3>
+<p>
+ To assess and select assets to reuse on your project, you need to understand the requirements of the system's
+ environment. You also need to understand the scope and general functionality of the system that the stakeholders
+ require. There are several types of assets to consider, including (but not limited to): reference architectures;
+ frameworks; patterns; analysis mechanisms; classes; and experience. You can search asset&nbsp;repositories (internal or
+ external to your organization) and industry literature to identify assets or similar projects.
+</p>
+<p>
+ You need to assess whether available assets contribute to solving the key challenges of the current project and whether
+ they are compatible with the project's architectural constraints. You also need to analyze the extent of the fit
+ between assets and requirements, considering whether any of the requirements are negotiable (to enable use of the
+ asset). Also, assess whether the asset could be modified or extended to satisfy requirements, as well as what the
+ tradeoffs in adopting it are, in terms of cost, risk, and functionality.
+</p>
+<p>
+ Leverage reuse of existing components by evaluating their interfaces and the behavior that they provide. Reuse
+ components when their interfaces are similar or match the interfaces of components you would need to develop from
+ scratch. If not similar, modify the newly identified interfaces so you improve the fit with existing components
+ interfaces. Work with developers to gain consensus on the suitability of using existing components.
+</p>
+<p>
+ Finally, decide, in principle, whether to use one or more assets, and record the rationale for this decision.
+</p>
+<h3>
+ Reuse Techniques
+</h3>
+<p>
+ Reuse can be performed differently depending on the capabilities of the implementation environment. The simplest
+ technique is to copy the code from one place to another. This isn't advisable because it's not really reuse. Multiple
+ copies of source code are difficult to maintain and can eventually diverge from each other. Reuse is about using the
+ same code to perform similar tasks as a way to increase quality and reduce overhead.
+</p>
+<p>
+ Some languages, such as C++, support templates. Templates, sometimes referred to as parameterized code, are a precursor
+ to patterns. Templates are code with parameters that are applied just when the code's needed, at compile time. The C++
+ Standard Template Library (STL) is one example. It provides many types of reusable containers (lists, sets, safe
+ arrays, etc) that don't have some of the drawbacks of inheritance. Templates such as these are also useful as mix-in
+ classes in languages like C++ that support multiple inheritance. Because mix-ins are implemented as templates, they
+ allow for a type of multiple inheritance without the baggage.
+</p>
+<h3>
+ Inheritance and Aggregation
+</h3>
+<p>
+ Inheritance (also known as generalization) is an easy way to implement polymorphism and has been used as the primary
+ mechanism for reuse in modern object-oriented languages. This is unfortunate, as inheritance imposes a rigid structure
+ on the software's design that is difficult to change. Any inheritance hierarchy that shares code from parents to
+ children will have problems when it grows to be three or more levels deep. Too many exceptions occur to maintain a pure
+ "is-a" relationship between parents and children, where children are always considered to have all the properties and
+ behaviors of the parents. Inheritance should be used to share definitions (interfaces), not implementations. Years of
+ difficulties with inheriting implementations have made this practice a primary object-oriented design principle.
+</p>
+<p>
+ Whenever inheritance is used, it is best to have only the last child class (leaf node) of the inheritance hierarchy be
+ instantiated. All parent classes should be abstract. This is because a class that tries to be both reusable and
+ concrete - to provide reusable and specific behavior at the same time - almost always fails to fulfill either goal.
+ This is a dimension of cohesiveness. One thing that makes a class cohesive is that it's dedicated to reuse or dedicated
+ to a specific implementation, but not both.
+</p>
+<p>
+ Aggregation is a technique that collects or aggregates functionality into larger elements of functionality. It provides
+ a structure that's far more flexible and reusable than inheritance. It's better to reuse implementation and design by
+ aggregating small pieces of functionality together rather than trying to inherit the functionality from a parent.
+</p>
+<p>
+ You may also find reuse opportunities by reviewing interfaces. If interfaces describe similar behavior it may be
+ possible to eliminate one of the interfaces, have just one implementation realize both interfaces, or refactor the
+ interfaces to put redundant content in a new, simpler interface.
+</p>
+<h3>
+ Finding Reusable Code
+</h3>
+<p>
+ There are many sources of reusable code beyond what the developers are writing for a specific project. Other places
+ from which to harvest code include the following:
+</p>
+<ul>
+ <li>
+ Internal (corporate) code libraries
+ </li>
+ <li>
+ Third party libraries
+ </li>
+ <li>
+ Built-in language libraries
+ </li>
+ <li>
+ Code samples from tutorials, examples, books, etc.
+ </li>
+ <li>
+ Local code guru or knowledgeable colleague
+ </li>
+ <li>
+ Existing system code
+ </li>
+ <li>
+ Open source products (be sure to follow any licensing agreements)
+ </li>
+</ul>
+<p>
+ Also, many tools that generate code will generate comprehensive code based on minimal specification. For example, a
+ design tool might generate the member variable plus a get and a set operation when the designer specifies an attribute.
+ Other more sophisticated tools with knowledge of a specific framework can generate voluminous code to ensure that a
+ class conforms to the framework. An example of this would be a tool that generates significant additional code when a
+ class is marked as a Java entity bean. This sort of consistent transformation from a specification (the design) to an
+ implementation (the code) could be considered a form of code reuse as well.
+</p>
+<h3>
+ Don't Reuse Everything
+</h3>
+<p>
+ Reuse makes code and design cheap to use but expensive to build. It requires experience and thoughtful consideration to
+ create an implementation or design that's abstract enough for others to re-use, but concrete enough to be truly useful.
+ Reusable code must also be maintained. Many organizations have difficulty assigning responsibility for maintaining
+ reusable code if they don't have a group dedicated to reuse.
+</p>
+<p>
+ It's usually not a good idea to create code or designs for reuse unless you know it's going to be reused. It's better
+ to refactor software to be more reusable after it's discovered that they can be reused. One rule of thumb is to write
+ for reuse only when you know you'll use it at least 3 times. Otherwise the cost of building and maintaining that part
+ of the software will not be recovered by reduced overhead in other areas of development.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/test_ideas.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/test_ideas.xmi
index 9dcb8f6..36311a7 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/test_ideas.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/test_ideas.xmi
@@ -1,144 +1,146 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_y3rxsMM3EdmSIPI87WLu3g" name="test_ideas,_0jzlsMlgEdmt3adZL5Dmdw" guid="_y3rxsMM3EdmSIPI87WLu3g" changeDate="2006-09-29T09:37:59.000-0700" version="1.0.0">
- <mainDescription><h3>
- Introduction
-</h3>
-<p>
- Test ideas are used to generate tests.&nbsp;Test ideas can come from many different sources.&nbsp;In general, they can
- be derived in different ways depending on the given development domain, the kind of application being developed, and
- the sophistication of the testers.&nbsp;Although test ideas are derived in many different ways, there are some useful
- categories for generating them.&nbsp;This guideline will describe some of these categories as well as some general
- heuristics for creating good test ideas.
-</p>
-<h4>
- Test Ideas and Functions
-</h4>
-<p>
- Below are some test ideas to calculate the square root:
-</p>
-<ol>
- <li>
- A number that's barely less than zero as input
- </li>
- <li>
- Zero as the input
- </li>
- <li>
- Number that's a perfect square, like 4 or 16 (is the result exactly 2 or 4?)
- </li>
- <li>
- Print to a LaserJet IIIp
- </li>
- <li>
- Test with database full
- </li>
-</ol>
-<p>
- The first&nbsp;3 test ideas validate input while the last 2 address environmental issues.&nbsp; Even though these
- statements are very incomplete they ensure that an idea is not forgotten.
-</p>
-<h4>
- Test Ideas and Boundaries
-</h4>
-<p>
- Test ideas are often based on fault models.&nbsp; Consider boundaries. It's safe to assume the square root function can
- be implemented something like this:<br />
- double sqrt(double x) {<br />
- &nbsp;&nbsp;&nbsp; if (x &lt; 0)<br />
- &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // signal error<br />
- &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...<br />
- It's also plausible that the &lt; will be incorrectly typed as &lt;=. People often make that kind of mistake, so it's
- worth checking. The fault cannot be detected with X having the value 2, because both the incorrect expression (x&lt;=0)
- and the correct expression (x&lt;0) will take the same branch of the if statement. Similarly, giving X the value -5
- cannot find the fault. The only way to find it is to give X the value 0, which justifies the second test idea.
-</p>
-<h4>
- Test Idea and Methods
-</h4>
-<p>
- Let's suppose you're designing tests for a method that searches for a string in a sequential collection. It can either
- obey case or ignore case in its search, and it returns the index of the first match found or -1 if no match is
- found.<br />
- int Collection.find(String string, Boolean ignoreCase);
-</p>
-<p>
- Here are some test ideas for this method, each of which could be implemented as a test.&nbsp;
-</p>
-<ol>
- <li>
- Match found in the first position
- </li>
- <li>
- Match found in the last position
- </li>
- <li>
- No match found
- </li>
- <li>
- Two or more matches found in the collection
- </li>
- <li>
- Case is ignored; match found, but it wouldn't match if case was obeyed
- </li>
- <li>
- Case is obeyed; an exact match is found
- </li>
- <li>
- Case is obeyed; a string that would have matched if case were ignored is skipped
- </li>
-</ol>
-<p>
- However, different test ideas can be combined into a single test; for example, the following test satisfies test ideas
- 2, 6, and 7:
-</p>
-<p>
- <strong>Setup:</strong> Collection initialized to ["dawn", "Dawn"]<br />
- <strong>Invocation:</strong> Collection.find("Dawn", false)<br />
- <strong>Expected result:</strong> Return value is 1 (it would be 0 if "dawn" were not skipped)
-</p>
-<h4>
- Test Idea Simplicity and Complexity
-</h4>
-<p>
- Making test ideas nonspecific makes them easier to combine.<br />
- Creating many several small tests that satisfy a few test ideas makes it simpler to:
-</p>
-<ul>
- <li>
- "Copy and Tweak" the tests to meet other test idea
- </li>
- <li>
- Easy of debugging - if you have test that covers 2 test ideas then you know the fault is one or two area, but if
- the test covers 7 test ideas you will spend more time debugging the issue.&nbsp;
- </li>
-</ul>
-<p>
- If the test ideas list were complete, with a test idea for every fault in the program, it wouldn't matter how you wrote
- the tests. But the list is always missing some test ideas that could find bugs. Smaller more complex tests increase the
- chance the test will satisfy a test idea that you didn't know you needed.
-</p>
-<h4>
- Complex Tests
-</h4>
-<p>
- Sometimes when you're creating more complex tests, new test ideas come to mind. However, there are reasons for not
- creating complex tests.
-</p>
-<ul>
- <li>
- Complex test are more difficult to debug because they usually cover multiple test ideas
- </li>
- <li>
- Complex tests are more difficult to understand and maintain. The intent of the test is less obvious.
- </li>
- <li>
- Complex tests are more difficult to create.
- </li>
-</ul>
-<p>
- Constructing a test that satisfies five test ideas often takes more time than constructing five tests that each
- satisfies one. Moreover, it's easier to make mistakes - to think you're satisfying all five when you're only satisfying
- four.<br />
- In practice, find a reasonable balance between complexity and simplicity.<br />
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ Test ideas are used to generate tests.&nbsp;Test ideas can come from many different sources.&nbsp;In general, they can
+ be derived in different ways depending on the given development domain, the kind of application being developed, and
+ the sophistication of the testers.&nbsp;Although test ideas are derived in many different ways, there are some useful
+ categories for generating them.&nbsp;This guideline will describe some of these categories as well as some general
+ heuristics for creating good test ideas.
+</p>
+<h4>
+ Test Ideas and Functions
+</h4>
+<p>
+ Below are some test ideas to calculate the square root:
+</p>
+<ol>
+ <li>
+ A number that's barely less than zero as input
+ </li>
+ <li>
+ Zero as the input
+ </li>
+ <li>
+ Number that's a perfect square, like 4 or 16 (is the result exactly 2 or 4?)
+ </li>
+ <li>
+ Print to a LaserJet IIIp
+ </li>
+ <li>
+ Test with database full
+ </li>
+</ol>
+<p>
+ The first&nbsp;3 test ideas validate input while the last 2 address environmental issues.&nbsp; Even though these
+ statements are very incomplete they ensure that an idea is not forgotten.
+</p>
+<h4>
+ Test Ideas and Boundaries
+</h4>
+<p>
+ Test ideas are often based on fault models.&nbsp; Consider boundaries. It's safe to assume the square root function can
+ be implemented something like this:<br />
+ <!-- START NON-TRANSLATABLE -->
+ double sqrt(double x) {<br />
+ &nbsp;&nbsp;&nbsp; if (x &lt; 0)<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // signal error<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...<br />
+ <!-- END NON-TRANSLATABLE -->
+ It's also plausible that the &lt; will be incorrectly typed as &lt;=. People often make that kind of mistake, so it's
+ worth checking. The fault cannot be detected with X having the value 2, because both the incorrect expression (x&lt;=0)
+ and the correct expression (x&lt;0) will take the same branch of the if statement. Similarly, giving X the value -5
+ cannot find the fault. The only way to find it is to give X the value 0, which justifies the second test idea.
+</p>
+<h4>
+ Test Idea and Methods
+</h4>
+<p>
+ Let's suppose you're designing tests for a method that searches for a string in a sequential collection. It can either
+ obey case or ignore case in its search, and it returns the index of the first match found or -1 if no match is
+ found.<br />
+ int Collection.find(String string, Boolean ignoreCase);
+</p>
+<p>
+ Here are some test ideas for this method, each of which could be implemented as a test.&nbsp;
+</p>
+<ol>
+ <li>
+ Match found in the first position
+ </li>
+ <li>
+ Match found in the last position
+ </li>
+ <li>
+ No match found
+ </li>
+ <li>
+ Two or more matches found in the collection
+ </li>
+ <li>
+ Case is ignored; match found, but it wouldn't match if case was obeyed
+ </li>
+ <li>
+ Case is obeyed; an exact match is found
+ </li>
+ <li>
+ Case is obeyed; a string that would have matched if case were ignored is skipped
+ </li>
+</ol>
+<p>
+ However, different test ideas can be combined into a single test; for example, the following test satisfies test ideas
+ 2, 6, and 7:
+</p>
+<p>
+ <strong>Setup:</strong> Collection initialized to ["dawn", "Dawn"]<br />
+ <strong>Invocation:</strong> Collection.find("Dawn", false)<br />
+ <strong>Expected result:</strong> Return value is 1 (it would be 0 if "dawn" were not skipped)
+</p>
+<h4>
+ Test Idea Simplicity and Complexity
+</h4>
+<p>
+ Making test ideas nonspecific makes them easier to combine.<br />
+ Creating many several small tests that satisfy a few test ideas makes it simpler to:
+</p>
+<ul>
+ <li>
+ "Copy and Tweak" the tests to meet other test idea
+ </li>
+ <li>
+ Easy of debugging - if you have test that covers 2 test ideas then you know the fault is one or two area, but if
+ the test covers 7 test ideas you will spend more time debugging the issue.&nbsp;
+ </li>
+</ul>
+<p>
+ If the test ideas list were complete, with a test idea for every fault in the program, it wouldn't matter how you wrote
+ the tests. But the list is always missing some test ideas that could find bugs. Smaller more complex tests increase the
+ chance the test will satisfy a test idea that you didn't know you needed.
+</p>
+<h4>
+ Complex Tests
+</h4>
+<p>
+ Sometimes when you're creating more complex tests, new test ideas come to mind. However, there are reasons for not
+ creating complex tests.
+</p>
+<ul>
+ <li>
+ Complex test are more difficult to debug because they usually cover multiple test ideas
+ </li>
+ <li>
+ Complex tests are more difficult to understand and maintain. The intent of the test is less obvious.
+ </li>
+ <li>
+ Complex tests are more difficult to create.
+ </li>
+</ul>
+<p>
+ Constructing a test that satisfies five test ideas often takes more time than constructing five tests that each
+ satisfies one. Moreover, it's easier to make mistakes - to think you're satisfying all five when you're only satisfying
+ four.<br />
+ In practice, find a reasonable balance between complexity and simplicity.<br />
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/test_suite.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/test_suite.xmi
index 3356c9e..7494eae 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/test_suite.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/test_suite.xmi
@@ -1,163 +1,163 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_s60KoMM3EdmSIPI87WLu3g" name="test_suite,_0aDz0MlgEdmt3adZL5Dmdw" guid="_s60KoMM3EdmSIPI87WLu3g" changeDate="2006-09-29T09:48:57.000-0700" version="1.0.0">
- <mainDescription><h3>
- Introduction
-</h3>
-<p>
- The test suite provides a means of managing the complexity of the test implementation. Many system test efforts fail
- because the team gets lost in the minutia of all of the detailed tests, and subsequently loses control of the test
- effort. Similar to UML packages, test suites provide a hierarchy of encapsulating containers to help manage the test
- implementation. They provide a means of managing the strategic aspects of the test effort by collecting tests together
- in related groups that can be planned, managed, and assessed in a meaningful way.
-</p>
-<p>
- The test suite represents a container for organizing arbitrary collections of related test scripts. This may be
- realized (implemented) as one or more automated regression test suites, but the test suite can also be a work plan for
- the implementation of a group of related manual test scripts. Note also that test suites can be nested hierarchically,
- therefore one test suite may be enclosed within another.
-</p>
-<p>
- Sometimes these groups of tests will relate directly to a subsystem or other system design element, but other times
- they'll relate directly to things such as quality dimensions, core "mission critical" functions, requirements
- compliance, standards adherence, and many others concerns that are organized based on requirements and therefore cut
- across the internal system elements.
-</p>
-<p>
- Consider creating test suites that arrange the available test scripts, in addition to other test suites, in many
- different combinations: the more variations you have, the more you'll increase coverage and the potential for finding
- errors. Give thought to a variety of test suites that will cover the breadth and depth of the target test items.
- Remember the corresponding implication that a single test script (or test suite) may appear in many different test
- suites.
-</p>
-<p>
- Some test automation tools provide the ability to automatically generate or assemble test suites. There are also
- implementation techniques that enable automated test suites to dynamically select all or part of their component test
- scripts for each test cycle run.
-</p>
-<p>
- Test suites can help you maintain your test assets and impose a level of organization that facilitates the entire
- testing effort.&nbsp; Like physical objects, tests can break. It's not that they wear down, it's that something changed
- in their environment. Perhaps they've been ported to a new operating system. Or, more likely, the code they exercise
- has changed in a way that correctly causes the test to fail. Suppose you're working on version 2.0 of an e-banking
- application. In version 1.0, this method was used to log in:
-</p>
-<p class="codeSample">
- public boolean login (String username);
-</p>
-<p>
- In version 2.0, the marketing department has realized that password protection might be a good idea. So the method is
- changed to this:
-</p>
-<p class="codeSample">
- public boolean login (String username, String password);
-</p>
-<p>
- Any test that uses the first form of the login will fail. It won't even compile. In this example you could find that,
- not many useful tests can be written that don't use login. You might be faced with hundreds or thousands of failing
- tests.
-</p>
-<p>
- These tests can be fixed by using a global search-and-replace tool that finds every instance of login(something) and
- replaces it with login(something, "dummy password"). Then arrange for all the testing accounts to use that password,
- and you're on your way.
-</p>
-<p>
- Then, when marketing decides that passwords should not be allowed to contain spaces, you get to do it all over again.
-</p>
-<p>
- This kind of thing is a wasteful burden, especially when, as is often the case, the test changes aren't so easily made.
- There is a better way.
-</p>
-<p>
- Suppose that the test scripts originally did not call the product's login method. Rather, they called a library method
- that does whatever it takes to get the test logged in and ready to proceed. Initially, that method might look like
- this:
-</p>
-<p class="codeSample">
- public boolean testLogin (String username) {<br />
- &nbsp; return product.login(username);<br />
- }
-</p>
-<p>
- When the version 2.0 change happens, the utility library is changed to match:
-</p>
-<p class="codeSample">
- public Boolean testLogin (String username) {<br />
- &nbsp; return product.login(username, "dummy password");<br />
- }
-</p>
-<p>
- Instead of a changing a thousand tests, you change one method.
-</p>
-<p>
- Ideally, all the needed library methods would be available at the beginning of the testing effort. In practice, they
- can't all be anticipated-you might not realize you need a testLogin utility method until the first time the product
- login changes. So test utility methods are often "factored out" of existing tests as needed. It is very important that
- you perform this ongoing test repair, even under schedule pressure. If you do not, you will waste much time dealing
- with an ugly and un-maintainable test suite. You might well find yourself throwing it away, or being unable to write
- the needed numbers of new tests because all your available testing time is spent maintaining old ones.
-</p>
-<p>
- Note: the tests of the product's login method will still call it directly. If its behavior changes, some or all of
- those tests will need to be updated. (If none of the login tests fail when its behavior changes, they're probably not
- very good at detecting defects.)
-</p>
-<h3>
- Abstraction helps manage complexity
-</h3>
-<p>
- The previous example showed how tests can abstract away from the concrete application. Most likely you can do
- considerably more abstraction. You might find that a number of tests begin with a common sequence of method calls: they
- log in, set up some state, and navigate to the part of the application you're testing. Only then does each test do
- something different. All this setup could-and should-be contained in a single method with an evocative name such as
- readyAccountForWireTransfer. By doing that, you're saving considerable time when new tests of a particular type are
- written, and you're also making the intent of each test much more understandable.
-</p>
-<p>
- Understandable tests are important. A common problem with old test suites is that no one knows what the tests are doing
- or why. When they break, the tendency is to fix them in the simplest possible way. That often results in tests that are
- weaker at finding defects. They no longer test what they were originally intended to test.
-</p>
-<h3>
- Throwing away tests
-</h3>
-<p>
- Even with utility libraries, a test might periodically be broken by behavior changes that have nothing to do with what
- it checks. Fixing the test doesn't stand much of a chance of finding a defect due to the change; it's something you do
- to preserve the chance of the test finding some other defect someday. But the cost of such a series of fixes might
- exceed the value of the tests hypothetically finding a defect. It might be better to simply throw the test away and
- devote the effort to creating new tests with greater value.
-</p>
-<p>
- Most people resist the notion of throwing away a test, at least until they're so overwhelmed by the maintenance burden
- that they throw all the tests away. It is better to make the decision carefully and continuously, test by test, asking:
-</p>
-<ul>
- <li>
- How much work will it be to fix this test well, perhaps adding to the utility library?
- </li>
- <li>
- How else might the time be used?
- </li>
- <li>
- How likely is it that the test will find serious defects in the future? What's been the track record of it and
- related tests?
- </li>
- <li>
- How long will it be before the test breaks again?
- </li>
-</ul>
-<p>
- The answers to these questions will be rough estimates or even guesses. But asking them will yield better results than
- simply having a policy of fixing all tests.
-</p>
-<p>
- Another reason to throw away tests is that they are now redundant. For example, early in development, there might be a
- multitude of simple tests of basic parse-tree construction methods (the LessOp constructor and the like). Later, during
- the writing of the parser, there will be a number of parser tests. Since the parser uses the construction methods, the
- parser tests will also indirectly test them. As code changes break the construction tests, it's reasonable to discard
- some of them as being redundant. Of course, any new or changed construction behavior will need new tests. They might be
- implemented directly (if they're hard to test thoroughly through the parser) or indirectly (if tests through the parser
- are adequate and more maintainable).
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ The test suite provides a means of managing the complexity of the test implementation. Many system test efforts fail
+ because the team gets lost in the minutia of all of the detailed tests, and subsequently loses control of the test
+ effort. Similar to UML packages, test suites provide a hierarchy of encapsulating containers to help manage the test
+ implementation. They provide a means of managing the strategic aspects of the test effort by collecting tests together
+ in related groups that can be planned, managed, and assessed in a meaningful way.
+</p>
+<p>
+ The test suite represents a container for organizing arbitrary collections of related test scripts. This may be
+ realized (implemented) as one or more automated regression test suites, but the test suite can also be a work plan for
+ the implementation of a group of related manual test scripts. Note also that test suites can be nested hierarchically,
+ therefore one test suite may be enclosed within another.
+</p>
+<p>
+ Sometimes these groups of tests will relate directly to a subsystem or other system design element, but other times
+ they'll relate directly to things such as quality dimensions, core "mission critical" functions, requirements
+ compliance, standards adherence, and many others concerns that are organized based on requirements and therefore cut
+ across the internal system elements.
+</p>
+<p>
+ Consider creating test suites that arrange the available test scripts, in addition to other test suites, in many
+ different combinations: the more variations you have, the more you'll increase coverage and the potential for finding
+ errors. Give thought to a variety of test suites that will cover the breadth and depth of the target test items.
+ Remember the corresponding implication that a single test script (or test suite) may appear in many different test
+ suites.
+</p>
+<p>
+ Some test automation tools provide the ability to automatically generate or assemble test suites. There are also
+ implementation techniques that enable automated test suites to dynamically select all or part of their component test
+ scripts for each test cycle run.
+</p>
+<p>
+ Test suites can help you maintain your test assets and impose a level of organization that facilitates the entire
+ testing effort.&nbsp; Like physical objects, tests can break. It's not that they wear down, it's that something changed
+ in their environment. Perhaps they've been ported to a new operating system. Or, more likely, the code they exercise
+ has changed in a way that correctly causes the test to fail. Suppose you're working on version 2.0 of an e-banking
+ application. In version 1.0, this method was used to log in:
+</p>
+<p class="codeSample">
+ public boolean login (String username);
+</p>
+<p>
+ In version 2.0, the marketing department has realized that password protection might be a good idea. So the method is
+ changed to this:
+</p>
+<p class="codeSample">
+ public boolean login (String username, String password);
+</p>
+<p>
+ Any test that uses the first form of the login will fail. It won't even compile. In this example you could find that,
+ not many useful tests can be written that don't use login. You might be faced with hundreds or thousands of failing
+ tests.
+</p>
+<p>
+ These tests can be fixed by using a global search-and-replace tool that finds every instance of login(something) and
+ replaces it with login(something, "dummy password"). Then arrange for all the testing accounts to use that password,
+ and you're on your way.
+</p>
+<p>
+ Then, when marketing decides that passwords should not be allowed to contain spaces, you get to do it all over again.
+</p>
+<p>
+ This kind of thing is a wasteful burden, especially when, as is often the case, the test changes aren't so easily made.
+ There is a better way.
+</p>
+<p>
+ Suppose that the test scripts originally did not call the product's login method. Rather, they called a library method
+ that does whatever it takes to get the test logged in and ready to proceed. Initially, that method might look like
+ this:
+</p>
+<p class="codeSample">
+ public boolean testLogin (String username) {<br />
+ &nbsp; return product.login(username);<br />
+ }
+</p>
+<p>
+ When the version 2.0 change happens, the utility library is changed to match:
+</p>
+<p class="codeSample">
+ public Boolean testLogin (String username) {<br />
+ &nbsp; return product.login(username, "dummy password");<br />
+ }
+</p>
+<p>
+ Instead of a changing a thousand tests, you change one method.
+</p>
+<p>
+ Ideally, all the needed library methods would be available at the beginning of the testing effort. In practice, they
+ can't all be anticipated-you might not realize you need a testLogin utility method until the first time the product
+ login changes. So test utility methods are often "factored out" of existing tests as needed. It is very important that
+ you perform this ongoing test repair, even under schedule pressure. If you do not, you will waste much time dealing
+ with an ugly and un-maintainable test suite. You might well find yourself throwing it away, or being unable to write
+ the needed numbers of new tests because all your available testing time is spent maintaining old ones.
+</p>
+<p>
+ Note: the tests of the product's login method will still call it directly. If its behavior changes, some or all of
+ those tests will need to be updated. (If none of the login tests fail when its behavior changes, they're probably not
+ very good at detecting defects.)
+</p>
+<h3>
+ Abstraction helps manage complexity
+</h3>
+<p>
+ The previous example showed how tests can abstract away from the concrete application. Most likely you can do
+ considerably more abstraction. You might find that a number of tests begin with a common sequence of method calls: they
+ log in, set up some state, and navigate to the part of the application you're testing. Only then does each test do
+ something different. All this setup could-and should-be contained in a single method with an evocative name such as
+ readyAccountForWireTransfer. By doing that, you're saving considerable time when new tests of a particular type are
+ written, and you're also making the intent of each test much more understandable.
+</p>
+<p>
+ Understandable tests are important. A common problem with old test suites is that no one knows what the tests are doing
+ or why. When they break, the tendency is to fix them in the simplest possible way. That often results in tests that are
+ weaker at finding defects. They no longer test what they were originally intended to test.
+</p>
+<h3>
+ Throwing away tests
+</h3>
+<p>
+ Even with utility libraries, a test might periodically be broken by behavior changes that have nothing to do with what
+ it checks. Fixing the test doesn't stand much of a chance of finding a defect due to the change; it's something you do
+ to preserve the chance of the test finding some other defect someday. But the cost of such a series of fixes might
+ exceed the value of the tests hypothetically finding a defect. It might be better to simply throw the test away and
+ devote the effort to creating new tests with greater value.
+</p>
+<p>
+ Most people resist the notion of throwing away a test, at least until they're so overwhelmed by the maintenance burden
+ that they throw all the tests away. It is better to make the decision carefully and continuously, test by test, asking:
+</p>
+<ul>
+ <li>
+ How much work will it be to fix this test well, perhaps adding to the utility library?
+ </li>
+ <li>
+ How else might the time be used?
+ </li>
+ <li>
+ How likely is it that the test will find serious defects in the future? What's been the track record of it and
+ related tests?
+ </li>
+ <li>
+ How long will it be before the test breaks again?
+ </li>
+</ul>
+<p>
+ The answers to these questions will be rough estimates or even guesses. But asking them will yield better results than
+ simply having a policy of fixing all tests.
+</p>
+<p>
+ Another reason to throw away tests is that they are now redundant. For example, early in development, there might be a
+ multitude of simple tests of basic parse-tree construction methods (the LessOp constructor and the like). Later, during
+ the writing of the parser, there will be a number of parser tests. Since the parser uses the construction methods, the
+ parser tests will also indirectly test them. As code changes break the construction tests, it's reasonable to discard
+ some of them as being redundant. Of course, any new or changed construction behavior will need new tests. They might be
+ implemented directly (if they're hard to test thoroughly through the parser) or indirectly (if tests through the parser
+ are adequate and more maintainable).
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/using_visual_modeling.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/using_visual_modeling.xmi
index dbb82e1..f83596c 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/using_visual_modeling.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/using_visual_modeling.xmi
@@ -1,41 +1,43 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-QklqSGB4aD07vUpfubpMJg" name="new_guideline,_0SsecNr8EdyXE6np2_hUMA" guid="-QklqSGB4aD07vUpfubpMJg" changeDate="2008-02-14T05:06:27.000-0800" version="7.2.0">
- <mainDescription><p>
- When applying visual modeling, you can use various techniques:
-</p>
-<ul>
- <li>
- <strong>Identify the key perspectives:</strong> Focus on modeling the things that count. Few (if any) projects
- benefit from modeling the entire design to a great level of detail. Make sure that you understand why you are
- modeling something and who will benefit.
- </li>
- <li>
- <strong>Communicate key architectural perspectives:</strong> Even if you choose to model very little&nbsp;of your
- design, it is often advantageous to produce diagrams that communicate the key architectural aspects of the system.
- Conveying the "big picture" to the rest of the team helps them understand the overall approach and develop cohesive
- software.&nbsp;
- </li>
- <li>
- <strong>Sketch the design:</strong> Not all models need to be detailed completely and presented in a software
- modeling tool. It is often perfectly acceptable (if not desirable) to produce hand-drawn sketches on paper or on a
- whiteboard when you are exploring and communicating the architecture and design with your team. You can use a
- digital camera or an electronic whiteboard to capture these diagrams and share them. For many small projects, this
- is often all you need. See <a href="http://www.agilemodeling.com/">http://www.agilemodeling.com/</a> for more
- information.
- </li>
- <li>
- <strong>Use a modeling tool as needed</strong>:&nbsp;If the team members are changing models throughout the
- project, sharing patterns/structure, debugging design, describing behavior, etc., then static photos or paper will
- become difficult to work with. The team may want to capture design in a software modeling tool. Other than
- communicating the design to the team, another benefit of a such a tool is the&nbsp;generation of structural code
- from the models. Many software development tools allow you to view the code as models, making it easier to
- comprehend static and dynamic aspects of a complex code base.
- </li>
- <li>
- <strong>Agree on a standard notation:</strong> In a team environment, it is important that others can understand
- your diagrams without much explanation. Choosing a standard notation enables others to quickly comprehend your
- diagrams without ambiguity. The Unified Modeling Language (UML) provides an industry-standard approach to software
- modeling and is an example of a widely understood notation.
- </li>
-</ul>For more information, see <a class="elementLinkWithType" href="./../../../core.tech.common.extend_supp/guidances/concepts/visual_modeling_2C089766.html" guid="_0XY6UMlgEdmt3adZL5Dmdw">Concept: Visual Modeling</a>.<br /></mainDescription>
+ <mainDescription><p>
+ When applying visual modeling, you can use various techniques:
+</p>
+<ul>
+ <li>
+ <strong>Identify the key perspectives:</strong> Focus on modeling the things that count. Few (if any) projects
+ benefit from modeling the entire design to a great level of detail. Make sure that you understand why you are
+ modeling something and who will benefit.
+ </li>
+ <li>
+ <strong>Communicate key architectural perspectives:</strong> Even if you choose to model very little&nbsp;of your
+ design, it is often advantageous to produce diagrams that communicate the key architectural aspects of the system.
+ Conveying the "big picture" to the rest of the team helps them understand the overall approach and develop cohesive
+ software.&nbsp;
+ </li>
+ <li>
+ <strong>Sketch the design:</strong> Not all models need to be detailed completely and presented in a software
+ modeling tool. It is often perfectly acceptable (if not desirable) to produce hand-drawn sketches on paper or on a
+ whiteboard when you are exploring and communicating the architecture and design with your team. You can use a
+ digital camera or an electronic whiteboard to capture these diagrams and share them. For many small projects, this
+ is often all you need. See <a href="http://www.agilemodeling.com/">http://www.agilemodeling.com/</a> for more
+ information.
+ </li>
+ <li>
+ <strong>Use a modeling tool as needed</strong>:&nbsp;If the team members are changing models throughout the
+ project, sharing patterns/structure, debugging design, describing behavior, etc., then static photos or paper will
+ become difficult to work with. The team may want to capture design in a software modeling tool. Other than
+ communicating the design to the team, another benefit of a such a tool is the&nbsp;generation of structural code
+ from the models. Many software development tools allow you to view the code as models, making it easier to
+ comprehend static and dynamic aspects of a complex code base.
+ </li>
+ <li>
+ <strong>Agree on a standard notation:</strong> In a team environment, it is important that others can understand
+ your diagrams without much explanation. Choosing a standard notation enables others to quickly comprehend your
+ diagrams without ambiguity. The Unified Modeling Language (UML) provides an industry-standard approach to software
+ modeling and is an example of a widely understood notation.
+ </li>
+</ul>For more information, see <a class="elementLinkWithType"
+href="./../../../core.tech.common.extend_supp/guidances/concepts/visual_modeling_2C089766.html"
+guid="_0XY6UMlgEdmt3adZL5Dmdw">Concept: Visual Modeling</a>.<br /></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/writing_good_requirements.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/writing_good_requirements.xmi
index 49c70d3..f341e66 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/writing_good_requirements.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/guidelines/writing_good_requirements.xmi
@@ -1,134 +1,136 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-AJQLv2ldVv5KN9eUbdQe_g" name="new_guideline,_6jXzYNcKEdqz_d2XWoVt6Q" guid="-AJQLv2ldVv5KN9eUbdQe_g" changeDate="2006-05-01T03:33:21.000-0700" version="7.1.0">
- <mainDescription><p>
- To write a good requirement, you must write it as a complete sentence, with a subject and a predicate (usually a verb).
- The subject&nbsp;is an Actor, a stakeholder, the system under development, or a design entity that is related to the
- requirement. The predicate specifies a condition, action, or intended result that is done for, by, with, or to the
- subject.
-</p>
-<p>
- Consistent use of the verb <strong>to be</strong> solidifies the link between the subject and the predicate. Thus, you
- can analyze a requirement from a grammatical point of view.
-</p>
-<p>
- Beware of lists, bullets, and words such as <strong>all</strong>, <strong>every</strong>. and <strong>some</strong>.
- For example:
-</p>
-<blockquote>
- <p>
- The order entry clerk must be able to complete 10 customer orders in less than two hours.
- </p>
-</blockquote>
-<p>
- This requirement has a subject (the order entry clerk, who is an Actor), a specific and measurable end state (10
- customer orders completed), and a performance criterion (in less than two hours).
-</p>
-<p>
- Follow these simple guidelines in writing any requirement. For consistency, these examples are all in the context of
- an aircraft. [[WAS: is used throughout.]] <a class="elementlinkwithusertext" href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html" guid="_9ToeIB83Edqsvps02rpOOg">[TEL06]</a>
-</p>
-<ul>
- <li>
- Define one requirement at a time.
- <blockquote>
- <p>
- The pilot shall be able to control the aircraft's angle of climb with one hand.
- </p>
- </blockquote>
- </li>
-</ul>
-<blockquote>
- <blockquote>
- <p>
- The pilot shall be able to feel the angle of climb from the climb control.
- </p>
- </blockquote>
-</blockquote>
-<ul>
- <li>
- Avoid conjunctions (and, or) that make multiple requirements.
- </li>
-</ul>
-<blockquote>
- <blockquote>
- <p>
- The navigator shall be able to view the aircraft's position relative to the route's radio beacons.
- </p>
- <p>
- The navigator shall be able to view the aircraft's position as estimated by inertial guidance.
- </p>
- </blockquote>
-</blockquote>
-<ul>
- <li>
- Avoid let-out clauses or words that imply options or exceptions (unless, except, if necessary, but).
- </li>
- <li style="list-style: none">
- <blockquote>
- <p>
- The design shall provide a rear-facing seat for each cabin crew member.
- </p>
- </blockquote>
- </li>
- <li>
- Use simple, direct sentences.
- </li>
-</ul>
-<ul>
- <li style="list-style: none">
- <blockquote>
- <p>
- The pilot shall be able to see the airspeed indicator.
- </p>
- </blockquote>
- </li>
- <li>
- Use a limited (500-word) vocabulary, especially if your audience is international.
- <blockquote>
- <p>
- The airline shall be able to convert the aircraft from business to holiday charter use in less than 12
- hours
- </p>
- </blockquote>
- </li>
- <li style="list-style: none">
- <blockquote>
- <p>
- <strong>Note:</strong> There is no need to use words such as <strong>reconfigured.</strong>
- </p>
- </blockquote>
- </li>
- <li>
- Identify the type of user who needs each requirement.
- </li>
-</ul>
-<ul>
- <li style="list-style: none">
- <blockquote>
- <p>
- The navigator shall be able to...
- </p>
- </blockquote>
- </li>
- <li>
- Focus on stating what result you will provide for that type of user.
- </li>
-</ul>
-<ul>
- <li style="list-style: none">
- <blockquote>
- <p>
- ...view storm clouds by radar...
- </p>
- </blockquote>
- </li>
- <li>
- Define verifiable criteria
- <blockquote>
- <p>
- ...at least 100 miles ahead.
- </p>
- </blockquote>
- </li>
+ <mainDescription><p>
+ To write a good requirement, you must write it as a complete sentence, with a subject and a predicate (usually a verb).
+ The subject&nbsp;is an Actor, a stakeholder, the system under development, or a design entity that is related to the
+ requirement. The predicate specifies a condition, action, or intended result that is done for, by, with, or to the
+ subject.
+</p>
+<p>
+ Consistent use of the verb <strong>to be</strong> solidifies the link between the subject and the predicate. Thus, you
+ can analyze a requirement from a grammatical point of view.
+</p>
+<p>
+ Beware of lists, bullets, and words such as <strong>all</strong>, <strong>every</strong>, and <strong>some</strong>.
+ For example:
+</p>
+<blockquote>
+ <p>
+ The order entry clerk must be able to complete 10 customer orders in less than two hours.
+ </p>
+</blockquote>
+<p>
+ This requirement has a subject (the order entry clerk, who is an Actor), a specific and measurable end state (10
+ customer orders completed), and a performance criterion (in less than two hours).
+</p>
+<p>
+ Follow these simple guidelines in writing any requirement. For consistency, these examples are all in the context of an
+ aircraft. [[WAS: is used throughout.]] <a class="elementlinkwithusertext"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[TEL06]</a>
+</p>
+<ul>
+ <li>
+ Define one requirement at a time. 
+ <blockquote>
+ <p>
+ The pilot shall be able to control the aircraft's angle of climb with one hand.
+ </p>
+ </blockquote>
+ </li>
+</ul>
+<blockquote>
+ <blockquote>
+ <p>
+ The pilot shall be able to feel the angle of climb from the climb control.
+ </p>
+ </blockquote>
+</blockquote>
+<ul>
+ <li>
+ Avoid conjunctions (and, or) that make multiple requirements.
+ </li>
+</ul>
+<blockquote>
+ <blockquote>
+ <p>
+ The navigator shall be able to view the aircraft's position relative to the route's radio beacons.
+ </p>
+ <p>
+ The navigator shall be able to view the aircraft's position as estimated by inertial guidance.
+ </p>
+ </blockquote>
+</blockquote>
+<ul>
+ <li>
+ Avoid let-out clauses or words that imply options or exceptions (unless, except, if necessary, but).
+ </li>
+ <li style="list-style: none">
+ <blockquote>
+ <p>
+ The design shall provide a rear-facing seat for each cabin crew member.
+ </p>
+ </blockquote>
+ </li>
+ <li>
+ Use simple, direct sentences.
+ </li>
+</ul>
+<ul>
+ <li style="list-style: none">
+ <blockquote>
+ <p>
+ The pilot shall be able to see the airspeed indicator.
+ </p>
+ </blockquote>
+ </li>
+ <li>
+ Use a limited (500-word) vocabulary, especially if your audience is international. 
+ <blockquote>
+ <p>
+ The airline shall be able to convert the aircraft from business to holiday charter use in less than 12
+ hours
+ </p>
+ </blockquote>
+ </li>
+ <li style="list-style: none">
+ <blockquote>
+ <p>
+ <strong>Note:</strong> There is no need to use words such as <strong>reconfigured.</strong>
+ </p>
+ </blockquote>
+ </li>
+ <li>
+ Identify the type of user who needs each requirement.
+ </li>
+</ul>
+<ul>
+ <li style="list-style: none">
+ <blockquote>
+ <p>
+ The navigator shall be able to...
+ </p>
+ </blockquote>
+ </li>
+ <li>
+ Focus on stating what result you will provide for that type of user.
+ </li>
+</ul>
+<ul>
+ <li style="list-style: none">
+ <blockquote>
+ <p>
+ ...view storm clouds by radar...
+ </p>
+ </blockquote>
+ </li>
+ <li>
+ Define verifiable criteria 
+ <blockquote>
+ <p>
+ ...at least 100 miles ahead.
+ </p>
+ </blockquote>
+ </li>
</ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/guidances/templates/systemwide_requirements_specification.xmi b/epf_prac_151/core.tech.common.extend_supp/guidances/templates/systemwide_requirements_specification.xmi
index 7fbfd8a..b54e1b5 100644
--- a/epf_prac_151/core.tech.common.extend_supp/guidances/templates/systemwide_requirements_specification.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/guidances/templates/systemwide_requirements_specification.xmi
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:GuidanceDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-13wK-dfNa9N1G8Ob27m-Og" name="new_template,_m7p-AI5fEdyO5aWob1UGDA" guid="-13wK-dfNa9N1G8Ob27m-Og" changeDate="2008-02-11T03:48:39.000-0800" version="7.2.0">
- <mainDescription>This template provides a starting point for capturing system-wide requirements in a consistent manner and to provide a
-useful checklist when determining the types of requirements that may apply. It is not expected that one would complete
+ <mainDescription>This template provides a starting point for capturing system-wide requirements in a consistent manner and to provide a
+useful checklist when determining the types of requirements that may apply. It is not expected that one would complete
every section of this template in all circumstances. Tailor as you see fit for your particular circumstances.</mainDescription>
<attachments>resources/systemwide_req_spec.dot</attachments>
</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/workproducts/build.xmi b/epf_prac_151/core.tech.common.extend_supp/workproducts/build.xmi
index 053b978..cd4b749 100644
--- a/epf_prac_151/core.tech.common.extend_supp/workproducts/build.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/workproducts/build.xmi
@@ -1,20 +1,21 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ArtifactDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_NqSB0KeqEdmKDbQuyzCoqQ" name="build,_0YuXEMlgEdmt3adZL5Dmdw" guid="_NqSB0KeqEdmKDbQuyzCoqQ" changeDate="2010-08-20T00:30:16.000-0700" version="7.5.0">
- <mainDescription><p>
- This working version of the system or part of the system&nbsp;is the result of putting the implementation through a
- build process (typically an automated build script) that creates an executable version, or one that runs. This
- executable version will typically have a number of supporting files that are also considered part of this artifact.
+ <mainDescription><p>
+ This working version of the system or part of the system&nbsp;is the result of putting the implementation through a
+ build process (typically an automated build script) that creates an executable version, or one that runs. This
+ executable version will typically have a number of supporting files that are also considered part of this artifact.
</p></mainDescription>
- <purpose>Deliver incremental value to the user and customer, and provide a testable artifact
-for verification.</purpose>
- <impactOfNotHaving><p> Without this artifact, there is no operational version of the system. </p></impactOfNotHaving>
+ <purpose>Deliver incremental value to the user and customer, and provide a testable artifact for verification.</purpose>
+ <impactOfNotHaving><p>
+ Without this artifact, there is no operational version of the system.
+</p></impactOfNotHaving>
<reasonsForNotNeeding><p>
This artifact is not needed if the development of an application is not within the scope of the solution.
</p></reasonsForNotNeeding>
- <representationOptions><p> This work product is&nbsp;almost always a composite product made up of numerous 
- parts required to make the executable system. Therefore, a build is more than 
- just executable files; it also includes such things as configuration files, 
- Help files, and data repositories that will be put together, resulting in the 
- product that the users will run. The specifics of those parts will vary by technology 
- in use. </p></representationOptions>
+ <representationOptions><p>
+ This work product is&nbsp;almost always a composite product made up of numerous parts required to make the executable
+ system. Therefore, a build is more than just executable files; it also includes such things as configuration files,
+ Help files, and data repositories that will be put together, resulting in the product that the users will run. The
+ specifics of those parts will vary by technology in use.
+</p></representationOptions>
</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/workproducts/developer_test.xmi b/epf_prac_151/core.tech.common.extend_supp/workproducts/developer_test.xmi
index 59fa3dd..84e22c1 100644
--- a/epf_prac_151/core.tech.common.extend_supp/workproducts/developer_test.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/workproducts/developer_test.xmi
@@ -1,54 +1,78 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ArtifactDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-1QQ8ajRx-ZzZnCjhkuaMXQ" name="developer_test,_0YuXEclgEdmt3adZL5Dmdw" guid="-1QQ8ajRx-ZzZnCjhkuaMXQ" changeDate="2009-07-28T01:16:53.000-0700" version="1.0.0">
- <mainDescription><p>
- This artifact covers all of the steps to validate a specific aspect of an implementation element. For example, a test
- could ensure that the parameters of a method properly accept the uppermost and lowermost required values. A developer
- test specifies test entries, execution conditions, and expected results. These details are identified to evaluate a
- particular aspect of a scenario.
-</p>
-<p>
- When you collect developer tests for a specific implementation element, you can validate that the element performs as
- specified.
-</p>
-<p>
- The tests be self-documenting so that it is clear upon completion of the test whether the implementation element has
- run correctly.
+ <mainDescription><p>
+ This artifact covers all of the steps to validate a specific aspect of an implementation element. For example, a test
+ could ensure that the parameters of a method properly accept the uppermost and lowermost required values. A developer
+ test specifies test entries, execution conditions, and expected results. These details are identified to evaluate a
+ particular aspect of a scenario.
+</p>
+<p>
+ When you collect developer tests for a specific implementation element, you can validate that the element performs as
+ specified.
+</p>
+<p>
+ The tests be self-documenting so that it is clear upon completion of the test whether the implementation element has
+ run correctly.
</p></mainDescription>
- <purpose>This
-artifact is used to evaluate whether an implementation element performs as
-specified.</purpose>
- <impactOfNotHaving>If
-you do not run developer tests, you cannot ensure that elements that you modify
-over time are working. This can inhibit iterative development and maintenance.</impactOfNotHaving>
- <reasonsForNotNeeding>If
-you can embed the tests into the production code, you might not need a separate
-work product. Nonetheless, some level of support for developer testing is
-always necessary when you develop application software.</reasonsForNotNeeding>
- <briefOutline><p>Although
-there is no predefined template for this work product, and testing tools affect
-how the work product is handled, you should address the following issues:</p> <ul>
-<li> Setup </li>
-<li> Inputs </li>
-<li> Script </li>
-<li> Expected Results </li>
-<li> Evaluation Criteria </li>
-<li> Clean-Up </li>
+ <purpose>This artifact is used to evaluate whether an implementation element performs as specified.</purpose>
+ <impactOfNotHaving>If you do not run developer tests, you cannot ensure that elements that you modify over time are working. This can inhibit
+iterative development and maintenance.</impactOfNotHaving>
+ <reasonsForNotNeeding>If you can embed the tests into the production code, you might not need a separate work product. Nonetheless, some level of
+support for developer testing is always necessary when you develop application software.</reasonsForNotNeeding>
+ <briefOutline><p>
+ Although there is no predefined template for this work product, and testing tools affect how the work product is
+ handled, you should address the following issues:
+</p>
+<ul>
+ <li>
+ Setup
+ </li>
+ <li>
+ Inputs
+ </li>
+ <li>
+ Script
+ </li>
+ <li>
+ Expected Results
+ </li>
+ <li>
+ Evaluation Criteria
+ </li>
+ <li>
+ Clean-Up
+ </li>
</ul></briefOutline>
- <representationOptions><p align="left"> Suggestions and options for representing this work product: </p> <h4> 
- Suggestion: Automated code unit </h4> <p> The most appropriate technique
-for running these tests is to use code that tests the implementation element
-scenarios and that you can run regularly as you update the system during development. </p> <p> When
-code is the sole form of the tests, ensure that the code is self-documenting.
-The code should document the specifications of the conditions you are testing
-and the setup or clean-up that is required for the test to run properly. </p> <h4> 
- Option: Manual instructions </h4> <p>In some cases, you can use manual
-instructions. For example, when testing a user interface, a developer might
-follow a script, explaining the implementation element. In this case, it is
-still valuable to create a test harness that goes straight to the user interface.
-That way, the developer can follow the script without having to follow a complicated
-set of instructions to find a particular screen or page. </p> <h4> Option:
-Embedded code </h4> <p> You can use certain technologies (such as Java(TM)5 Test Annotation) to embed tests in the implementation. In these cases, there
-will be a logical work product, but it will be assimilated into
-the code that you are testing. When you use this option, ensure that the code
-is self-documenting.</p></representationOptions>
+ <representationOptions><p align="left">
+ Suggestions and options for representing this work product:
+</p>
+<h4>
+ Suggestion: Automated code unit
+</h4>
+<p>
+ The most appropriate technique for running these tests is to use code that tests the implementation element scenarios
+ and that you can run regularly as you update the system during development.
+</p>
+<p>
+ When code is the sole form of the tests, ensure that the code is self-documenting. The code should document the
+ specifications of the conditions you are testing and the setup or clean-up that is required for the test to run
+ properly.
+</p>
+<h4>
+ Option: Manual instructions
+</h4>
+<p>
+ In some cases, you can use manual instructions. For example, when testing a user interface, a developer might follow a
+ script, explaining the implementation element. In this case, it is still valuable to create a test harness that goes
+ straight to the user interface. That way, the developer can follow the script without having to follow a complicated
+ set of instructions to find a particular screen or page.
+</p>
+<h4>
+ Option: Embedded code
+</h4>
+<p>
+ You can use certain technologies (such as Java(TM)5 Test Annotation) to embed tests in the implementation. In these
+ cases, there will be a logical work product, but it will be assimilated into the code that you are testing. When you
+ use this option, ensure that the code is self-documenting.
+</p></representationOptions>
</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/workproducts/implementation.xmi b/epf_prac_151/core.tech.common.extend_supp/workproducts/implementation.xmi
index 98abd6f..1b3e377 100644
--- a/epf_prac_151/core.tech.common.extend_supp/workproducts/implementation.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/workproducts/implementation.xmi
@@ -1,24 +1,30 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ArtifactDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-HPCdXGOQ2SGSCHZaDEKJRg" name="implementation,_0YoQcMlgEdmt3adZL5Dmdw" guid="-HPCdXGOQ2SGSCHZaDEKJRg" authors="Jim Ruehlin" changeDate="2008-08-14T09:13:19.000-0700" version="1.0.0">
- <mainDescription><p>
- This artifact is the collection of one or more of these elements: </p> <ul>
-<li> Source code files </li>
-<li> Data files </li>
-<li> Build scripts </li>
-<li> Other files that are transformed into the executable system
- </li>
+ <mainDescription><p>
+ This artifact is the collection of one or more of these elements:
+</p>
+<ul>
+ <li>
+ Source code files
+ </li>
+ <li>
+ Data files
+ </li>
+ <li>
+ Build scripts
+ </li>
+ <li>
+ Other files that are transformed into the executable system
+ </li>
</ul></mainDescription>
- <purpose><p>To
-represent the physical parts that compose the system to be built, and to organize
-the parts in a way that is understandable and manageable. </p></purpose>
- <impactOfNotHaving>Without
-this artifact, there is no way to produce the application to
-be delivered as part of the solution.</impactOfNotHaving>
- <reasonsForNotNeeding>You
-do not need to produce this artifact if the actual development of an application
-is not in the scope of the solution.</reasonsForNotNeeding>
- <representationOptions><p
->Implementation files are represented as files in the local file system. File
-folders (directories) are represented as packages, which group the files into
-logical units. </p></representationOptions>
+ <purpose><p>
+ To represent the physical parts that compose the system to be built, and to organize the parts in a way that is
+ understandable and manageable.
+</p></purpose>
+ <impactOfNotHaving>Without this artifact, there is no way to produce the application to be delivered as part of the solution.</impactOfNotHaving>
+ <reasonsForNotNeeding>You do not need to produce this artifact if the actual development of an application is not in the scope of the solution.</reasonsForNotNeeding>
+ <representationOptions><p>
+ Implementation files are represented as files in the local file system. File folders (directories) are represented as
+ packages, which group the files into logical units.
+</p></representationOptions>
</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/workproducts/system_wide_requirements.xmi b/epf_prac_151/core.tech.common.extend_supp/workproducts/system_wide_requirements.xmi
index 4364b7c..bd8b572 100644
--- a/epf_prac_151/core.tech.common.extend_supp/workproducts/system_wide_requirements.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/workproducts/system_wide_requirements.xmi
@@ -1,64 +1,75 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ArtifactDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-_dNuyh-0q5vpCiIiLfbj6w" name="system_wide_requirements,_BVh9cL-CEdqb7N6KIeDL8Q" guid="-_dNuyh-0q5vpCiIiLfbj6w" changeDate="2008-08-15T00:49:32.000-0700" version="1.0.0">
- <keyConsiderations><ul>
-<li> When you document system-wide requirements, ensure that the needs
-of all of the stakeholders are represented. In particular, include
-the needs of those who are responsible for maintaining or supporting the system
-after it is delivered. </li>
-<li> Typically, there are some overlaps and gray areas between system-wide
-requirements and other requirements work products. For example, the
-authorization behavior of a system can be specified as use cases or as statements
-within system-wide requirements. The overall driving need is that no important
-requirements are missed or duplicated, and that there is an agreed upon approach
-for capturing and processing every type of requirement. </li>
-<li> System-wide requirements originate from many places. Documenting
-the source of the requirement is particularly important when you separate
-externally mandated requirements. </li>
-<li> Requirements are often thought of as "Qualitative" (specifying
-a quality or desirable characteristic) versus "Quantitative" (specifying
-a quantity). Qualitative requirements can sometimes be elaborated into quantitative
-requirements. </li>
-<li> A good quality requirement is one that you can verify, either
-through testing or some other objective evaluation. </li>
-<li> You must evaluate system-wide requirements for cost, schedule
-impact, and level of contribution to business goals. Based on your
-evaluation, the system-wide requirements should be iteratively challenged,
-defended, and amended. </li>
+ <keyConsiderations><ul>
+ <li>
+ When you document system-wide requirements, ensure that the needs of all of the stakeholders are represented. In
+ particular, include the needs of those who are responsible for maintaining or supporting the system after it is
+ delivered.
+ </li>
+ <li>
+ Typically, there are some overlaps and gray areas between system-wide requirements and other requirements work
+ products. For example, the authorization behavior of a system can be specified as use cases or as statements within
+ system-wide requirements. The overall driving need is that no important requirements are missed or duplicated, and
+ that there is an agreed upon approach for capturing and processing every type of requirement.
+ </li>
+ <li>
+ System-wide requirements originate from many places. Documenting the source of the requirement is particularly
+ important when you separate externally mandated requirements.
+ </li>
+ <li>
+ Requirements are often thought of as "Qualitative" (specifying a quality or desirable characteristic) versus
+ "Quantitative" (specifying a quantity). Qualitative requirements can sometimes be elaborated into quantitative
+ requirements.
+ </li>
+ <li>
+ A good quality requirement is one that you can verify, either through testing or some other objective evaluation.
+ </li>
+ <li>
+ You must evaluate system-wide requirements for cost, schedule impact, and level of contribution to business goals.
+ Based on your evaluation, the system-wide requirements should be iteratively challenged, defended, and amended.
+ </li>
</ul></keyConsiderations>
- <purpose><p>
- This artifact is used for the following purposes: </p> <ul>
-<li> To describe the quality attributes of the system, and the constraints
-that the design options must satisfy to deliver the business goals, objectives,
-or capabilities </li>
-<li> To capture functional requirements that are not expressed as
-use cases </li>
-<li> To negotiate between, and select from, competing design options
- </li>
-<li> To assess the sizing, cost, and viability of the proposed system
- </li>
-<li> To understand the service-level requirements for operational
-management of the solution </li>
+ <purpose><p>
+ This artifact is used for the following purposes:
+</p>
+<ul>
+ <li>
+ To describe the quality attributes of the system, and the constraints that the design options must satisfy to
+ deliver the business goals, objectives, or capabilities
+ </li>
+ <li>
+ To capture functional requirements that are not expressed as use cases
+ </li>
+ <li>
+ To negotiate between, and select from, competing design options
+ </li>
+ <li>
+ To assess the sizing, cost, and viability of the proposed system
+ </li>
+ <li>
+ To understand the service-level requirements for operational management of the solution
+ </li>
</ul></purpose>
- <impactOfNotHaving><p> If
-you do not adequately manage and meet system-wide requirements, you risk delivering
-a system that might be unacceptable to stakeholders.<br/> </p></impactOfNotHaving>
- <reasonsForNotNeeding><p
-> You do not need to use this artifact if none of the categories of system-wide
-requirements apply to the project under consideration. </p></reasonsForNotNeeding>
- <briefOutline><p> Organize
-system-wide requirements by a number of common themes or subcategories: the
-areas of performance and capacity, availability, usability, security and privacy,
-maintainability, manageability, and flexibility. See the supporting guidance
-for a description of the recommended categorization approach. </p> <p>For
-each system-wide requirement, capture attributes such as the source and priority
-of the requirements, as described by the associated requirements management
-guidance. </p></briefOutline>
- <representationOptions>This
-artifact represents the influences on the design and delivery of a system,
-which cover a broad range of themes. Document the requirements for each theme
-under separate headings within a document or under appropriate category identifiers
-in a requirements gathering tool. Give categories easy-to-recognize identifiers,
-so individual requirements can be readily associated with the appropriate
-category. The format of requirements vary from category to category; some
-are heavily textual, and others are more structured and quantitative.</representationOptions>
+ <impactOfNotHaving><p>
+ If you do not adequately manage and meet system-wide requirements, you risk delivering a system that might be
+ unacceptable to stakeholders.<br />
+</p></impactOfNotHaving>
+ <reasonsForNotNeeding><p>
+ You do not need to use this artifact if none of the categories of system-wide requirements apply to the project under
+ consideration.
+</p></reasonsForNotNeeding>
+ <briefOutline><p>
+ Organize system-wide requirements by a number of common themes or subcategories: the areas of performance and capacity,
+ availability, usability, security and privacy, maintainability, manageability, and flexibility. See the supporting
+ guidance for a description of the recommended categorization approach.
+</p>
+<p>
+ For each system-wide requirement, capture attributes such as the source and priority of the requirements, as described
+ by the associated requirements management guidance.
+</p></briefOutline>
+ <representationOptions>This artifact represents the influences on the design and delivery of a system, which cover a broad range of themes.
+Document the requirements for each theme under separate headings within a document or under appropriate category
+identifiers in a requirements gathering tool. Give categories easy-to-recognize identifiers, so individual requirements can
+be readily associated with the appropriate category. The format of requirements vary from category to category; some are
+heavily textual, and others are more structured and quantitative.</representationOptions>
</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/workproducts/test_case.xmi b/epf_prac_151/core.tech.common.extend_supp/workproducts/test_case.xmi
index 20aaf69..43875ad 100644
--- a/epf_prac_151/core.tech.common.extend_supp/workproducts/test_case.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/workproducts/test_case.xmi
@@ -1,36 +1,42 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ArtifactDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_NqYIdKeqEdmKDbQuyzCoqQ" name="test_case,_0ZS-0MlgEdmt3adZL5Dmdw" guid="_NqYIdKeqEdmKDbQuyzCoqQ" changeDate="2008-08-15T00:50:34.000-0700" version="7.2.0">
- <mainDescription><p>A
-test case specifies the conditions that must be validated to enable an assessment
-of aspects of the system under test. A test case is more formal than a test
-idea; typically, a test case takes the form of a specification. In less formal
-environments, you can create test cases by identifying a unique ID, name,
-associated test data, and expected results. </p> <p> Test cases can be derived
-from many sources, and typically include a subset of the requirements (such
-as use cases, performance characteristics, and reliability concerns) and other
-types of quality attributes. For more information on types of tests and their
-relationships to quality test attributes, see <a class="elementLinkWithType"
-href="./../../core.tech.common.extend_supp/guidances/concepts/testing_qualitative_rqmts_CAE80710.html"
-guid="_0aJ6cMlgEdmt3adZL5Dmdw">Concept: Testing Qualitative Requirements</a>. </p></mainDescription>
- <purpose><p
-> Use this artifact for the following purposes: </p> <ul>
-<li> To provide a way to capture test inputs, conditions, and expected
-results for a system </li>
-<li> To systematically identify aspects of the software to test
- </li>
-<li> To specify whether an expected result has been reached, based
-on the verification of a system requirement, set of requirements,
-or scenario </li>
+ <mainDescription><p>
+ A test case specifies the conditions that must be validated to enable an assessment of aspects of the system under
+ test. A test case is more formal than a test idea; typically, a test case takes the form of a specification. In less
+ formal environments, you can create test cases by identifying a unique ID, name, associated test data, and expected
+ results.
+</p>
+<p>
+ Test cases can be derived from many sources, and typically include a subset of the requirements (such as use cases,
+ performance characteristics, and reliability concerns) and other types of quality attributes. For more information on
+ types of tests and their relationships to quality test attributes, see <a class="elementLinkWithType"
+ href="./../../core.tech.common.extend_supp/guidances/concepts/testing_qualitative_rqmts_CAE80710.html"
+ guid="_0aJ6cMlgEdmt3adZL5Dmdw">Concept: Testing Qualitative Requirements</a>.
+</p></mainDescription>
+ <purpose><p>
+ Use this artifact for the following purposes:
+</p>
+<ul>
+ <li>
+ To provide a way to capture test inputs, conditions, and expected results for a system
+ </li>
+ <li>
+ To systematically identify aspects of the software to test
+ </li>
+ <li>
+ To specify whether an expected result has been reached, based on the verification of a system requirement, set of
+ requirements, or scenario
+ </li>
</ul></purpose>
- <impactOfNotHaving><p> 
- Without this artifact, it is difficult to validate system functionality.
-Because this artifact specifies the conditions of acceptance between the stakeholders
-and the developers, without the artifact, it is difficult to establish exit
-criteria and to demonstrate that the exit criteria have been met. If the original
-test cases have not been documented, it is impossible to do regression testing. </p></impactOfNotHaving>
- <reasonsForNotNeeding><p
-> It might not be necessary to create this artifact to maintain or make small
-enhancements to existing systems, which likely have existing test assets that
-you can use. You also might not need this artifact if you use a package application
-that has its own set of test cases. </p></reasonsForNotNeeding>
+ <impactOfNotHaving><p>
+ Without this artifact, it is difficult to validate system functionality. Because this artifact specifies the conditions
+ of acceptance between the stakeholders and the developers, without the artifact, it is difficult to establish exit
+ criteria and to demonstrate that the exit criteria have been met. If the original test cases have not been documented,
+ it is impossible to do regression testing.
+</p></impactOfNotHaving>
+ <reasonsForNotNeeding><p>
+ It might not be necessary to create this artifact to maintain or make small enhancements to existing systems, which
+ likely have existing test assets that you can use. You also might not need this artifact if you use a package
+ application that has its own set of test cases.
+</p></reasonsForNotNeeding>
</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/workproducts/test_log.xmi b/epf_prac_151/core.tech.common.extend_supp/workproducts/test_log.xmi
index b46a696..716a373 100644
--- a/epf_prac_151/core.tech.common.extend_supp/workproducts/test_log.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/workproducts/test_log.xmi
@@ -1,42 +1,52 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ArtifactDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_NqePEKeqEdmKDbQuyzCoqQ" name="test_log,_0ZlSsMlgEdmt3adZL5Dmdw" guid="_NqePEKeqEdmKDbQuyzCoqQ" changeDate="2008-08-15T00:57:11.000-0700" version="7.2.0">
- <mainDescription>This
-artifact provides a detailed, typically time-based record that both verifies
-that a set of tests were run, and provides information that relates to the
-success of those tests. The focus is typically on providing an accurate audit
-trail, which enables you to undertake a post-run diagnosis of failures. This
-raw data is subsequently analyzed to determine the results of an aspect of
-the test effort.</mainDescription>
- <purpose><ul>
-<li> To provide verification that a set of tests was run </li>
-<li> To provide information that relates to the success of those tests
- </li>
+ <mainDescription>This artifact provides a detailed, typically time-based record that both verifies that a set of tests were run, and
+provides information that relates to the success of those tests. The focus is typically on providing an accurate audit
+trail, which enables you to undertake a post-run diagnosis of failures. This raw data is subsequently analyzed to determine
+the results of an aspect of the test effort.</mainDescription>
+ <purpose><ul>
+ <li>
+ To provide verification that a set of tests was run
+ </li>
+ <li>
+ To provide information that relates to the success of those tests
+ </li>
</ul></purpose>
- <impactOfNotHaving><p> 
- Without this or similar documentation, there is no record of which tests
-were run, what variances were discovered, and what action was taken. If this
-information is not available: </p> <ul>
-<li> There is no way to know which tests passed and which failed 
- </li>
-<li> There is no way to assess the status of testing and the quality
-of the product at that level of testing </li>
-<li> It is difficult to know how many tests remain outstanding 
- </li>
-<li> Contractual and legal issues might arise </li>
+ <impactOfNotHaving><p>
+ Without this or similar documentation, there is no record of which tests were run, what variances were discovered, and
+ what action was taken. If this information is not available:
+</p>
+<ul>
+ <li>
+ There is no way to know which tests passed and which failed.
+ </li>
+ <li>
+ There is no way to assess the status of testing and the quality of the product at that level of testing.
+ </li>
+ <li>
+ It is difficult to know how many tests remain outstanding.
+ </li>
+ <li>
+ There can be contractual and legal issues.
+ </li>
</ul></impactOfNotHaving>
- <reasonsForNotNeeding><p
-> When you execute automated tests, test logs are automatically produced.
-Typically, the issue is not whether to produce the test log, but whether
-to keep a record, and where to keep the records. For manual testing, the issue
-is whether to keep a separate test log or to summarize the test results in
-another form. </p></reasonsForNotNeeding>
- <representationOptions><p
-> Because this is a collection of raw data for subsequent analysis, it can
-be represented in a number of ways: </p> <ul>
-<li> For manual tests, log the actual results on a copy
-of the manual Test Script </li>
-<li> For automated tests, direct the output to log files that you
-can trace back to the automated Test Script </li>
-<li> Track raw results data in a test management tool </li>
+ <reasonsForNotNeeding><p>
+ When you execute automated tests, test logs are automatically produced. Typically, the issue is not whether to produce
+ the test log, but whether to keep a record, and where to keep the records. For manual testing, the issue is whether to
+ keep a separate test log or to summarize the test results in another form.
+</p></reasonsForNotNeeding>
+ <representationOptions><p>
+ Because this is a collection of raw data for subsequent analysis, it can be represented in a number of ways:
+</p>
+<ul>
+ <li>
+ For manual tests, log the actual results on a copy of the manual Test Script
+ </li>
+ <li>
+ For automated tests, direct the output to log files that you can trace back to the automated Test Script
+ </li>
+ <li>
+ Track raw results data in a test management tool
+ </li>
</ul></representationOptions>
</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/workproducts/test_script.xmi b/epf_prac_151/core.tech.common.extend_supp/workproducts/test_script.xmi
index e4e592a..3b60e0a 100644
--- a/epf_prac_151/core.tech.common.extend_supp/workproducts/test_script.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/workproducts/test_script.xmi
@@ -1,17 +1,14 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ArtifactDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_NqYIcqeqEdmKDbQuyzCoqQ" name="test_script,_0ZfMEMlgEdmt3adZL5Dmdw" guid="_NqYIcqeqEdmKDbQuyzCoqQ" changeDate="2008-08-15T00:55:57.000-0700" version="7.2.0">
- <purpose><p>
- Test scripts implement a subset of required tests in an efficient and effective
-manner. </p></purpose>
- <impactOfNotHaving>Without
-this artifact, it is difficult to ensure that tests are run consistently so
-that results are repeatable and errors can be recreated. If you do not use
-a test script, it is more difficult to verify that errors were not caused
-because of the way tests were run.</impactOfNotHaving>
- <reasonsForNotNeeding><p
->This artifact might not be required if the tests are simple or if testing
-is done on an informal basis. However, for this approach to be successful,
-testers must track their processes, as they might need to recreate a problem
-scenario. Alternatively, you can use automatic capture and playback tools
-to provide a record of testing. </p></reasonsForNotNeeding>
+ <purpose><p>
+ Test scripts implement a subset of required tests in an efficient and effective manner.
+</p></purpose>
+ <impactOfNotHaving>Without this artifact, it is difficult to ensure that tests are run consistently so that results are repeatable and errors
+can be recreated. If you do not use a test script, it is more difficult to verify that errors were not caused because of
+the way tests were run.</impactOfNotHaving>
+ <reasonsForNotNeeding><p>
+ This artifact might not be required if the tests are simple or if testing is done on an informal basis. However, for
+ this approach to be successful, testers must track their processes, as they might need to recreate a problem scenario.
+ Alternatively, you can use automatic capture and playback tools to provide a record of testing.
+</p></reasonsForNotNeeding>
</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/workproducts/use_case.xmi b/epf_prac_151/core.tech.common.extend_supp/workproducts/use_case.xmi
index 05d0f6b..4df58e1 100644
--- a/epf_prac_151/core.tech.common.extend_supp/workproducts/use_case.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/workproducts/use_case.xmi
@@ -1,43 +1,66 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ArtifactDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_zHZW8qYSEdmvhNXG0Oc2uA" name="use_case,_0VGbUMlgEdmt3adZL5Dmdw" guid="_zHZW8qYSEdmvhNXG0Oc2uA" changeDate="2008-09-03T05:31:44.000-0700" version="1.0.0">
- <purpose><p>
- Use cases are used for the following purposes: </p> <ul>
-<li> To reach a common understanding of system behavior </li>
-<li> To design elements that support the required behavior </li>
-<li> To identify test cases </li>
-<li> To plan and assess work </li>
-<li> To write user documentation. </li>
+ <purpose><p>
+ Use cases are used for the following purposes:
+</p>
+<ul>
+ <li>
+ To reach a common understanding of system behavior
+ </li>
+ <li>
+ To design elements that support the required behavior
+ </li>
+ <li>
+ To identify test cases
+ </li>
+ <li>
+ To plan and assess work
+ </li>
+ <li>
+ To write user documentation.
+ </li>
</ul></purpose>
- <impactOfNotHaving>Without
-this artifact, it might be unclear which functionality the solution needs
-to support.</impactOfNotHaving>
- <reasonsForNotNeeding>You
-might not need to use a use case if your project uses alternative requirements
-practices (for example, "The system shall..." statements).<br/></reasonsForNotNeeding>
- <briefOutline><p > A use case typically includes the following information: </p> <ul>
-<li> <strong>Name:</strong> The name of the use case </li>
-<li> <strong>Brief Description:</strong> A brief description of the
-role and purpose of the use case </li>
-<li> <strong>Flow of Events:</strong> A textual description of what
-the system does in regard to a use case scenario (not how specific
-problems are solved by the system). Write the description so that the customer
-can understand it. The flows can include a basic flow, alternative flows,
-and subflows. </li>
-<li> <strong>Key scenarios:</strong> A textual description of the
-most important or frequently discussed scenarios </li>
-<li> <strong>Special Requirements:</strong> A textual description
-that collects all of the requirements of the use case that are not considered
-in the use-case model, but that must be taken care of during design or implementation
-(for example, non-functional requirements)</li>
-<li> <strong>Preconditions:</strong> A textual description that defines
-a constraint on the system when the use case starts </li>
-<li> <strong>Post-conditions:</strong> A textual description that
-defines a constraint on the system when the use case ends </li>
-<li> <strong>Extension points:</strong> A list of locations within
-the flow of events of the use case at which additional behavior can
-be inserted by using the extend-relationship </li>
+ <impactOfNotHaving>Without this artifact, it might be unclear which functionality the solution needs to support.</impactOfNotHaving>
+ <reasonsForNotNeeding>You might not need to use a use case if your project uses alternative requirements practices (for example, "The system
+shall..." statements).<br /></reasonsForNotNeeding>
+ <briefOutline><p>
+ A use case typically includes the following information:
+</p>
+<ul>
+ <li>
+ <strong>Name:</strong> The name of the use case
+ </li>
+ <li>
+ <strong>Brief Description:</strong> A brief description of the role and purpose of the use case
+ </li>
+ <li>
+ <strong>Flow of Events:</strong> A textual description of what the system does in regard to a use case scenario
+ (not how specific problems are solved by the system). Write the description so that the customer can understand it.
+ The flows can include a basic flow, alternative flows, and subflows.
+ </li>
+ <li>
+ <strong>Key scenarios:</strong> A textual description of the most important or frequently discussed scenarios
+ </li>
+ <li>
+ <strong>Special Requirements:</strong> A textual description that collects all of the requirements of the use case
+ that are not considered in the use-case model, but that must be taken care of during design or implementation (for
+ example, non-functional requirements)
+ </li>
+ <li>
+ <strong>Preconditions:</strong> A textual description that defines a constraint on the system when the use case
+ starts
+ </li>
+ <li>
+ <strong>Post-conditions:</strong> A textual description that defines a constraint on the system when the use case
+ ends
+ </li>
+ <li>
+ <strong>Extension points:</strong> A list of locations within the flow of events of the use case at which
+ additional behavior can be inserted by using the extend-relationship
+ </li>
</ul></briefOutline>
- <representationOptions><p > You can document the use case as a use-case specification document or you
-can incorporate the use case in a use-case model. You can also use a requirements
-management tool to capture use cases and parts of use cases. </p></representationOptions>
+ <representationOptions><p>
+ You can document the use case as a use-case specification document or you can incorporate the use case in a use-case
+ model. You can also use a requirements management tool to capture use cases and parts of use cases.
+</p></representationOptions>
</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/workproducts/use_case_model.xmi b/epf_prac_151/core.tech.common.extend_supp/workproducts/use_case_model.xmi
index f925a19..8c24c0d 100644
--- a/epf_prac_151/core.tech.common.extend_supp/workproducts/use_case_model.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/workproducts/use_case_model.xmi
@@ -1,21 +1,21 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ArtifactDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-kQg7MSGPB3RPjrplyxwimQ" name="uc_model,_W2SgEDR5EdutE_HNDTJk5Q" guid="-kQg7MSGPB3RPjrplyxwimQ" changeDate="2008-08-15T00:59:12.000-0700" version="1.0.0">
- <purpose><p>This
-artifact presents an overview of the intended behavior of the system. It is
-the basis for agreement between stakeholders and the project team in regards
-to the intended functionality of the system. It also guides various tasks
-in the software development lifecycle. </p></purpose>
- <impactOfNotHaving>Without
-this artifact, it is difficult to determine all of the relationships between
-actors and use cases. It is also difficult to gain an understanding of how
-different use cases relate.</impactOfNotHaving>
- <reasonsForNotNeeding><p
-> You might not need this requirement if the overall set of use cases is small
-and has no complex relationships. </p> <p> You also might not need a use-case
-model if you use an alternative approach to document functional requirements. </p></reasonsForNotNeeding>
- <representationOptions><p
->Representation options include reports and diagrams from UML modeling tools,
-graphical representations created by using drawing tools, and drawings on
-whiteboards. Most of the information in the use-case model is
-captured in the use-case specifications. </p></representationOptions>
+ <purpose><p>
+ This artifact presents an overview of the intended behavior of the system. It is the basis for agreement between
+ stakeholders and the project team in regards to the intended functionality of the system. It also guides various tasks
+ in the software development lifecycle.
+</p></purpose>
+ <impactOfNotHaving>Without this artifact, it is difficult to determine all of the relationships between actors and use cases. It is also
+difficult to gain an understanding of how different use cases relate.</impactOfNotHaving>
+ <reasonsForNotNeeding><p>
+ You might not need this requirement if the overall set of use cases is small and has no complex relationships.
+</p>
+<p>
+ You also might not need a use-case model if you use an alternative approach to document functional requirements.
+</p></reasonsForNotNeeding>
+ <representationOptions><p>
+ Representation options include reports and diagrams from UML modeling tools, graphical representations created by using
+ drawing tools, and drawings on whiteboards. Most of the information in the use-case model is captured in the use-case
+ specifications.
+</p></representationOptions>
</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/epf_prac_151/core.tech.common.extend_supp/workproducts/vision.xmi b/epf_prac_151/core.tech.common.extend_supp/workproducts/vision.xmi
index 00c0bac..bc4415c 100644
--- a/epf_prac_151/core.tech.common.extend_supp/workproducts/vision.xmi
+++ b/epf_prac_151/core.tech.common.extend_supp/workproducts/vision.xmi
@@ -1,35 +1,35 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ArtifactDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_zHTQUKYSEdmvhNXG0Oc2uA" name="vision,_0WVxcMlgEdmt3adZL5Dmdw" guid="_zHTQUKYSEdmvhNXG0Oc2uA" changeDate="2007-10-24T09:47:27.000-0700" version="1.0.0">
- <keyConsiderations><p> It
-is good practice to keep this artifact brief, so you can release it to stakeholders
-as soon as possible, and to make the artifact easy for stakeholders to read
-and understand. You can accomplish this by including only the most important
-features and avoiding details of requirements. </p> <p> Projects that focus
-on product development might extend the marketing section and include a more
-detailed product position statement that is based on their needs and research. </p></keyConsiderations>
- <purpose><p
-> This artifact provides a high-level basis for more detailed technical requirements.
-It captures the technical solution by describing the high-level stakeholder
-requests and constraints that give an overview of the reasoning, background,
-and context for detailed requirements. The vision serves as input for communicating
-the fundamental "what and why" for the project and provides a strategy against
-which all future decisions can be validated. </p> <p>The vision should rally
-team members behind an idea and give them the context for decision-making
-in the requirements area. The vision must be visible to everyone on the team.<br/> </p></purpose>
- <impactOfNotHaving>If
-you do not state a vision, stakeholders and the development team might have
-different expectations of the project. This can lead to cancellation of the
-project. Misunderstandings and miscommunication about the strategy can cause
-the project to move from the original vision and create discrepancies in stakeholder
-expectations.</impactOfNotHaving>
- <reasonsForNotNeeding>Use
-this artifact for all but trivial projects.</reasonsForNotNeeding>
- <representationOptions><p
->Typically, the vision is represented in a document. If key stakeholder needs
-are captured in a requirements management tool, this part of the document
-can be generated by using reporting capabilities. </p> <p>If the vision serves
-a set of projects or an entire program, the overall vision might be divided
-into several vision work products. In this case, the vision
-of the program brings the visions together by providing program-specific content
-and referencing the subordinate visions.<br/> </p></representationOptions>
+ <keyConsiderations><p>
+ It is good practice to keep this artifact brief, so you can release it to stakeholders as soon as possible, and to make
+ the artifact easy for stakeholders to read and understand. You can accomplish this by including only the most important
+ features and avoiding details of requirements.
+</p>
+<p>
+ Projects that focus on product development might extend the marketing section and include a more detailed product
+ position statement that is based on their needs and research.
+</p></keyConsiderations>
+ <purpose><p>
+ This artifact provides a high-level basis for more detailed technical requirements. It captures the technical solution
+ by describing the high-level stakeholder requests and constraints that give an overview of the reasoning, background,
+ and context for detailed requirements. The vision serves as input for communicating the fundamental "what and why" for
+ the project and provides a strategy against which all future decisions can be validated.
+</p>
+<p>
+ The vision should rally team members behind an idea and give them the context for decision-making in the requirements
+ area. The vision must be visible to everyone on the team.<br />
+</p></purpose>
+ <impactOfNotHaving>If you do not state a vision, stakeholders and the development team might have different expectations of the project. This
+can lead to cancellation of the project. Misunderstandings and miscommunication about the strategy can cause the project to
+move from the original vision and create discrepancies in stakeholder expectations.</impactOfNotHaving>
+ <reasonsForNotNeeding>Use this artifact for all but trivial projects.</reasonsForNotNeeding>
+ <representationOptions><p>
+ Typically, the vision is represented in a document. If key stakeholder needs are captured in a requirements management
+ tool, this part of the document can be generated by using reporting capabilities.
+</p>
+<p>
+ If the vision serves a set of projects or an entire program, the overall vision might be divided into several vision
+ work products. In this case, the vision of the program brings the visions together by providing program-specific
+ content and referencing the subordinate visions.<br />
+</p></representationOptions>
</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/checklists/iteration_plan.xmi b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/checklists/iteration_plan.xmi
index 6ae98a1..22134a4 100644
--- a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/checklists/iteration_plan.xmi
+++ b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/checklists/iteration_plan.xmi
@@ -1,14 +1,18 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-z4NERMW6W4_X_5DuTTXv6A" name="new_checklist,_OHRDMAarEdy1uLAzgK8btg" guid="-z4NERMW6W4_X_5DuTTXv6A" version="7.5.0">
<sections xmi:id="_EQJdAAa_Edy1uLAzgK8btg" name="Have you elaborated on the plan with the team?" guid="_EQJdAAa_Edy1uLAzgK8btg">
- <sectionDescription><p> Iteration planning should not be done in isolation, and every member of the 
- team should be involved. </p></sectionDescription>
+ <sectionDescription><p>
+ Iteration planning should not be done in isolation, and every member of the team should be involved.
+</p></sectionDescription>
</sections>
<sections xmi:id="_lmIhYAarEdy1uLAzgK8btg" name="Are iteration objectives clear?" guid="_lmIhYAarEdy1uLAzgK8btg">
<sectionDescription><ul>
- <li> Are the objectives based on stakeholder priorities? </li>
- <li> Do they help the team target what should be targeted for the iteration? 
- </li>
+ <li>
+ Are the objectives based on stakeholder priorities?
+ </li>
+ <li>
+ Do they help the team target what should be targeted for the iteration?
+ </li>
</ul></sectionDescription>
</sections>
<sections xmi:id="_i2r4kAarEdy1uLAzgK8btg" name="Have key milestones for the iteration been identified?" guid="_i2r4kAarEdy1uLAzgK8btg">
@@ -17,9 +21,12 @@
</p></sectionDescription>
</sections>
<sections xmi:id="_oKlbIAarEdy1uLAzgK8btg" name="Do the team members feel confident about their Work Item assignments?" guid="_oKlbIAarEdy1uLAzgK8btg">
- <sectionDescription><p align="left"> Looking at results from previous iterations, does the amount 
- of work selected for the current iteration seem feasible? </p>
-<p align="left"> If the team feels that there is too much to do, discuss with stakeholders 
- whether some work items can be scheduled for future iterations. </p></sectionDescription>
+ <sectionDescription><p align="left">
+ Looking at results from previous iterations, does the amount of work selected for the current iteration seem feasible?
+</p>
+<p align="left">
+ If the team feels that there is too much to do, discuss with stakeholders whether some work items can be scheduled for
+ future iterations.
+</p></sectionDescription>
</sections>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/concepts/iteration_lifecycle.xmi b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/concepts/iteration_lifecycle.xmi
index b8b3ea4..48f6559 100644
--- a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/concepts/iteration_lifecycle.xmi
+++ b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/concepts/iteration_lifecycle.xmi
@@ -1,45 +1,45 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-5xbLr54QjpynnPU8ZJ3_fw" name="new_concept,_DI_tICNaEdyCq8v2ZO4QcA" guid="-5xbLr54QjpynnPU8ZJ3_fw" changeDate="2008-09-30T01:18:11.000-0700" version="7.5.0">
- <mainDescription><p>
- Iterations&nbsp;keep the team focused on delivering incremental customer value every few weeks by delivering a fully
- tested, demonstrable or shippable build (product increment). This creates a healthy focus on ensuring that whatever is
- worked on is of value to the stakeholders. Decision making must happen faster than in a process without iterations,
- because there is no time for endless debate. Iterative development focuses on producing working code, reducing the risk
- of analysis-paralysis. Frequent demonstration of working code provides feedback mechanisms that allow course
- corrections to be taken as needed.
-</p>
-<p>
- Iteration planning, estimation, and progress tracking are centered on work items. The iteration plan is created by
- selecting the top-priority work items. Agile estimation techniques are used to understand how many work items can
- safely fit within the time-boxed iteration, and work items are filtered to ensure that the chosen work items will allow
- the team to deliver upon iteration objectives agreed to by stakeholders. Progress is demonstrated through continuous
- completion of many small work items (see <a class="elementLink"
- href="./../../../practice.mgmt.iterative_dev.base/guidances/concepts/micro_increments_C8773066.html"
- guid="_S80VwCNbEdyCq8v2ZO4QcA">Micro-Increments</a>).
-</p>
-<p>
- Just as a project goes through a lifecycle, iterations go through a lifecycle with a different focus for the team,
- depending on whether you are in the first or the last week of the iteration (see Figure 1 below). An iteration starts
- with an iteration planning meeting that is a few hours long. The initial one or two days are typically focused on
- further planning and architecture to, among other things, understand the dependencies and logical ordering of work
- items, and the architectural impacts of the work to be done. Most of the time during an iteration is spent on executing
- the micro increments. Each micro increment should deliver tested code to a build, as well as validated artifacts. To
- give additional discipline, stable builds are produced at the end of each week. More attention is spent on these builds
- to make sure that the quality is not eroding, and issues are dealt with early so that the success of the iteration
- isn't jeopardized. The last week or last few days of the iteration typically have a stronger emphasis on polishing and
- bug fixing than earlier weeks, even though new features are added as appropriate. The goal is to never let quality
- erode, thus ensuring&nbsp;that a high-quality useful product increment is produced at the end of the iteration. The
- iteration ends with an assessment (with stakeholders) of what was built, and a retrospective to understand how to
- improve the process for next iteration.
-</p>
-<p>
- <b>Figure 1. An iteration goes through a lifecycle with a stronger focus on planning and architecture early on, and a
- stronger focus on bug fixing and stabilization toward the end.</b>
-</p>
-<p>
- <img
- alt="Picture shows an iteration that starts with a planning meeting, has stable weekly builds, and ends with an iteration review."
- src="resources/iteration_lifecycle.jpg" />
-</p><br />
+ <mainDescription><p>
+ Iterations&nbsp;keep the team focused on delivering incremental customer value every few weeks by delivering a fully
+ tested, demonstrable or shippable build (product increment). This creates a healthy focus on ensuring that whatever is
+ worked on is of value to the stakeholders. Decision making must happen faster than in a process without iterations,
+ because there is no time for endless debate. Iterative development focuses on producing working code, reducing the risk
+ of analysis-paralysis. Frequent demonstration of working code provides feedback mechanisms that allow course
+ corrections to be taken as needed.
+</p>
+<p>
+ Iteration planning, estimation, and progress tracking are centered on work items. The iteration plan is created by
+ selecting the top-priority work items. Agile estimation techniques are used to understand how many work items can
+ safely fit within the time-boxed iteration, and work items are filtered to ensure that the chosen work items will allow
+ the team to deliver upon iteration objectives agreed to by stakeholders. Progress is demonstrated through continuous
+ completion of many small work items (see <a class="elementLink"
+ href="./../../../practice.mgmt.iterative_dev.base/guidances/concepts/micro_increments_C8773066.html"
+ guid="_S80VwCNbEdyCq8v2ZO4QcA">Micro-Increments</a>).
+</p>
+<p>
+ Just as a project goes through a lifecycle, iterations go through a lifecycle with a different focus for the team,
+ depending on whether you are in the first or the last week of the iteration (see Figure 1 below). An iteration starts
+ with an iteration planning meeting that is a few hours long. The initial one or two days are typically focused on
+ further planning and architecture to, among other things, understand the dependencies and logical ordering of work
+ items, and the architectural impacts of the work to be done. Most of the time during an iteration is spent on executing
+ the micro increments. Each micro increment should deliver tested code to a build, as well as validated artifacts. To
+ give additional discipline, stable builds are produced at the end of each week. More attention is spent on these builds
+ to make sure that the quality is not eroding, and issues are dealt with early so that the success of the iteration
+ isn't jeopardized. The last week or last few days of the iteration typically have a stronger emphasis on polishing and
+ bug fixing than earlier weeks, even though new features are added as appropriate. The goal is to never let quality
+ erode, thus ensuring&nbsp;that a high-quality useful product increment is produced at the end of the iteration. The
+ iteration ends with an assessment (with stakeholders) of what was built, and a retrospective to understand how to
+ improve the process for next iteration.
+</p>
+<p>
+ <b>Figure 1. An iteration goes through a lifecycle with a stronger focus on planning and architecture early on, and a
+ stronger focus on bug fixing and stabilization toward the end.</b>
+</p>
+<p>
+ <img
+ alt="Picture shows an iteration that starts with a planning meeting, has stable weekly builds, and ends with an iteration review."
+ src="resources/iteration_lifecycle.jpg" />
+</p><br />
<br /></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/concepts/micro_increments.xmi b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/concepts/micro_increments.xmi
index 2effc4e..5bd5a21 100644
--- a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/concepts/micro_increments.xmi
+++ b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/concepts/micro_increments.xmi
@@ -1,56 +1,56 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-vysTxqikgsqd3pYIkSofjg" name="new_concept,_S80VwCNbEdyCq8v2ZO4QcA" guid="-vysTxqikgsqd3pYIkSofjg" changeDate="2010-05-17T01:06:48.000-0700" version="7.2.0">
- <mainDescription><p>
- Personal contribution on an&nbsp;iterative project is organized in <strong>micro-increments</strong>. A micro-increment
- represents the outcome of a few hours to a few days of work for one person (or typically a few people collaborating) to
- reach the goals of the iteration. The concept of a micro-increment helps the individual team member to partition their
- work into small units, each of which delivers something of measurable value to the team. Micro-increments provide an
- extremely short feedback loop that drives adaptive decisions within each iteration.
-</p>
-<p>
- A micro-increment should be well-defined, and you should be able to track daily progress of each micro-increment.
- Micro-increments are specified and tracked by a work item. Change sets represent the physical outcome in terms of the
- files that are modified as a part of completing the work item. Let's have a look at some sample micro-increments:
-</p>
-<ul>
- <li>
- <b>Identify Stakeholders<em>.</em></b> Defining a shared vision is a task that can drag on for weeks, so to ensure
- that you make and track daily progress, divide the task into small and well-defined micro-increments. Describing
- and getting buy-in on which Stakeholders to put into a Vision document is a meaningful result, and may take a few
- hours or at most a few days, and thus represents a suitable micro-increment.
- </li>
- <li>
- <b>Develop Solution Increment.</b> Defining, designing, implementing, and testing a use case or even a scenario can
- take weeks or longer. To ensure continuous progress, divide the work into smaller increments, each of which can be
- done in a couple of days. A more suitable micro-increment may be to only define, design, implement, and test a
- subflow of a use-case or step within a scenario.
- </li>
- <li>
- <b>Agree on Technical Approach for Persistency.</b> Agreeing on your technical solution may take quite some time,
- so you need to narrow the task to something that can be defined and agreed to in a short time. One way to partition
- the work is according to the issues that you need to resolve, such as persistency or reporting. This
- micro-increment will probably involve defining requirements, surveying available assets, prototyping, and
- documenting the decisions.
- </li>
- <li>
- <b>Plan Iteration.</b> This micro-increment could include setting up a meeting for creating the iteration plan,
- doing some preparation for the meeting (such as reviewing candidate work items), coaching the team through the
- iteration planning meeting, and posting the iteration plan for easy access. The end result is something complete
- and measurable, a posted plan that has buy-in from the team.
- </li>
-</ul>
-<p>
- Your project evolves in micro-increments through simultaneous execution of a number of work items. By openly sharing
- progress on your micro-increments through daily team meetings and team collaboration tools, you achieve the
- transparency and insight into each other's work required for effective teamwork. At the same time, you demonstrate
- continuous progress by evolving your application one micro-increment at a time.
-</p>
-<p>
- Typically,&nbsp;practices&nbsp;provide a set of activities to be performed. Each activity is captured as a set of
- tasks, steps within tasks, and guidance. Even though micro-increments are not explicit constructs in the practices,
- within the activities you will find descriptions of how to carry out a set of related micro-increments that are
- commonly found in projects.&nbsp;This guidance does&nbsp;not provide a complete description of all potential
- micro-increments:&nbsp;each organization should consider adding their own "recipes" for commonly occurring
- micro-increments.
+ <mainDescription><p>
+ Personal contribution on an&nbsp;iterative project is organized in <strong>micro-increments</strong>. A micro-increment
+ represents the outcome of a few hours to a few days of work for one person (or typically a few people collaborating) to
+ reach the goals of the iteration. The concept of a micro-increment helps the individual team member to partition their
+ work into small units, each of which delivers something of measurable value to the team. Micro-increments provide an
+ extremely short feedback loop that drives adaptive decisions within each iteration.
+</p>
+<p>
+ A micro-increment should be well-defined, and you should be able to track daily progress of each micro-increment.
+ Micro-increments are specified and tracked by a work item. Change sets represent the physical outcome in terms of the
+ files that are modified as a part of completing the work item. Let's have a look at some sample micro-increments:
+</p>
+<ul>
+ <li>
+ <b>Identify Stakeholders<em>.</em></b> Defining a shared vision is a task that can drag on for weeks, so to ensure
+ that you make and track daily progress, divide the task into small and well-defined micro-increments. Describing
+ and getting buy-in on which Stakeholders to put into a Vision document is a meaningful result, and may take a few
+ hours or at most a few days, and thus represents a suitable micro-increment.
+ </li>
+ <li>
+ <b>Develop Solution Increment.</b> Defining, designing, implementing, and testing a use case or even a scenario can
+ take weeks or longer. To ensure continuous progress, divide the work into smaller increments, each of which can be
+ done in a couple of days. A more suitable micro-increment may be to only define, design, implement, and test a
+ subflow of a use-case or step within a scenario.
+ </li>
+ <li>
+ <b>Agree on Technical Approach for Persistency.</b> Agreeing on your technical solution may take quite some time,
+ so you need to narrow the task to something that can be defined and agreed to in a short time. One way to partition
+ the work is according to the issues that you need to resolve, such as persistency or reporting. This
+ micro-increment will probably involve defining requirements, surveying available assets, prototyping, and
+ documenting the decisions.
+ </li>
+ <li>
+ <b>Plan Iteration.</b> This micro-increment could include setting up a meeting for creating the iteration plan,
+ doing some preparation for the meeting (such as reviewing candidate work items), coaching the team through the
+ iteration planning meeting, and posting the iteration plan for easy access. The end result is something complete
+ and measurable, a posted plan that has buy-in from the team.
+ </li>
+</ul>
+<p>
+ Your project evolves in micro-increments through simultaneous execution of a number of work items. By openly sharing
+ progress on your micro-increments through daily team meetings and team collaboration tools, you achieve the
+ transparency and insight into each other's work required for effective teamwork. At the same time, you demonstrate
+ continuous progress by evolving your application one micro-increment at a time.
+</p>
+<p>
+ Typically,&nbsp;practices&nbsp;provide a set of activities to be performed. Each activity is captured as a set of
+ tasks, steps within tasks, and guidance. Even though micro-increments are not explicit constructs in the practices,
+ within the activities you will find descriptions of how to carry out a set of related micro-increments that are
+ commonly found in projects.&nbsp;This guidance does&nbsp;not provide a complete description of all potential
+ micro-increments:&nbsp;each organization should consider adding their own "recipes" for commonly occurring
+ micro-increments.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/concepts/retrospective.xmi b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/concepts/retrospective.xmi
index 6d6a14c..729d0c8 100644
--- a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/concepts/retrospective.xmi
+++ b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/concepts/retrospective.xmi
@@ -1,71 +1,71 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-ENSD2TqUsFcf3Sf-oeozUA" name="retrospective,_2PfbIA4QEdy2q5zsU8WDnA" guid="-ENSD2TqUsFcf3Sf-oeozUA" changeDate="2008-09-30T00:05:27.000-0700" version="7.5.0">
- <mainDescription><p>
- Retrospectives, as applied in software development, have historical roots in Project Retrospectives described as:
-</p>
-<blockquote>
- "A ritual held <b>at the end</b> of a project to learn from the experience and plan changes for the next effort." [<a
- class="elementLinkWithUserText"
- href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#KER01"
- guid="_9ToeIB83Edqsvps02rpOOg">KER01</a>]
-</blockquote>
-<p>
- While Retrospectives conducted at the end of a project remain valuable, the spirit of Retrospectives should be imbued
- across the project continuum, conducted at key project milestones:
-</p>
-<ul>
- <li>
- At the end of project iterations
- </li>
- <li>
- After releases
- </li>
- <li>
- Immediately upon occurrences of key project incidents (significant unexpected events).
- </li>
-</ul>
-<p>
- When the practice of Retrospectives is intimately intertwined with the processes of the project, the health of the team
- is constantly monitored, the "heartbeat" of project progress is readily measured, and the team hones an awareness of
- opportunities for improvement and increased productivity. A symbiotic relationship emerges between an evolutionary
- development process and a Retrospective that supports the various methods of inspection and adaptation.
-</p>
-<p>
- The iteration, incident, and project Retrospectives are designed, in part, to calibrate the team's progress with the
- goals of the project. Several methods can be used to incite the Retrospective team to begin their collective
- investigative work, such as posing the following three driving questions to the team:
-</p>
-<ul>
- <li>
- "What worked well for us during the past iteration (or project, and so on)?"
- </li>
- <li>
- "What did not work well for us during the past iteration (or project, and so on)?"
- </li>
- <li>
- "What should we do differently, or what improvements should we undertake during our next iteration (or project, and
- so on)".
- </li>
-</ul>
-<p>
- The questions are expected to generate actions that will assist the team in prioritizing suggested improvements for the
- project, to be implemented during the subsequent cycle. In addition to the aforementioned investigative questions, a
- Retrospective should include steps that provide structure for the team's focus and resulting work.
-</p>
-<p>
- An effectively facilitated Retrospective will create an environment that is conducive to various practices of
- inspection and adaptation. The methods of inspection and adaptation are project control mechanisms that assume, and
- respond to, the existence of complexity, unpredictability, and constant change. Practiced in the context of a
- Retrospective, the methods of inspection and adaptation produce a feedback loop from which flexibility, responsiveness,
- and reliability are realized.
-</p>
-<p>
- The mere execution of Retrospectives is insufficient without an organizational commitment to a collaborative culture.
- The success of Retrospectives is directly proportional to, and necessarily contingent on, an environment that engenders
- highly motivated and performing teams (not the individual), nurtures open and frequent communication, and provides a
- thriving sense of dedication to the team community. Retrospectives embody the spirit of team collaboration and
- self-reflection by offering an environment in which teams are encouraged to provide feedback and identify lessons
- learned. The compositional aspects of the team are crucial in supporting the highly collaborative nature of
- Retrospectives, enabling the team to produce insight(s) into improving the processes of the project.
+ <mainDescription><p>
+ Retrospectives, as applied in software development, have historical roots in Project Retrospectives described as:
+</p>
+<blockquote>
+ "A ritual held <b>at the end</b> of a project to learn from the experience and plan changes for the next effort." [<a
+ class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#KER01"
+ guid="_9ToeIB83Edqsvps02rpOOg">KER01</a>]
+</blockquote>
+<p>
+ While Retrospectives conducted at the end of a project remain valuable, the spirit of Retrospectives should be imbued
+ across the project continuum, conducted at key project milestones:
+</p>
+<ul>
+ <li>
+ At the end of project iterations
+ </li>
+ <li>
+ After releases
+ </li>
+ <li>
+ Immediately upon occurrences of key project incidents (significant unexpected events).
+ </li>
+</ul>
+<p>
+ When the practice of Retrospectives is intimately intertwined with the processes of the project, the health of the team
+ is constantly monitored, the "heartbeat" of project progress is readily measured, and the team hones an awareness of
+ opportunities for improvement and increased productivity. A symbiotic relationship emerges between an evolutionary
+ development process and a Retrospective that supports the various methods of inspection and adaptation.
+</p>
+<p>
+ The iteration, incident, and project Retrospectives are designed, in part, to calibrate the team's progress with the
+ goals of the project. Several methods can be used to incite the Retrospective team to begin their collective
+ investigative work, such as posing the following three driving questions to the team:
+</p>
+<ul>
+ <li>
+ "What worked well for us during the past iteration (or project, and so on)?"
+ </li>
+ <li>
+ "What did not work well for us during the past iteration (or project, and so on)?"
+ </li>
+ <li>
+ "What should we do differently, or what improvements should we undertake during our next iteration (or project, and
+ so on)".
+ </li>
+</ul>
+<p>
+ The questions are expected to generate actions that will assist the team in prioritizing suggested improvements for the
+ project, to be implemented during the subsequent cycle. In addition to the aforementioned investigative questions, a
+ Retrospective should include steps that provide structure for the team's focus and resulting work.
+</p>
+<p>
+ An effectively facilitated Retrospective will create an environment that is conducive to various practices of
+ inspection and adaptation. The methods of inspection and adaptation are project control mechanisms that assume, and
+ respond to, the existence of complexity, unpredictability, and constant change. Practiced in the context of a
+ Retrospective, the methods of inspection and adaptation produce a feedback loop from which flexibility, responsiveness,
+ and reliability are realized.
+</p>
+<p>
+ The mere execution of Retrospectives is insufficient without an organizational commitment to a collaborative culture.
+ The success of Retrospectives is directly proportional to, and necessarily contingent on, an environment that engenders
+ highly motivated and performing teams (not the individual), nurtures open and frequent communication, and provides a
+ thriving sense of dedication to the team community. Retrospectives embody the spirit of team collaboration and
+ self-reflection by offering an environment in which teams are encouraged to provide feedback and identify lessons
+ learned. The compositional aspects of the team are crucial in supporting the highly collaborative nature of
+ Retrospectives, enabling the team to produce insight(s) into improving the processes of the project.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/examples/iteration_plan.xmi b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/examples/iteration_plan.xmi
index f52abd5..8e518b0 100644
--- a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/examples/iteration_plan.xmi
+++ b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/examples/iteration_plan.xmi
@@ -1,287 +1,287 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:GuidanceDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-nDr0XNiUWBo6VS1YS6KAqA" name=",_TuNhIEE4EdulKujnGUuxbg" guid="-nDr0XNiUWBo6VS1YS6KAqA" changeDate="2010-07-19T10:40:32.000-0700" version="7.1.0">
- <mainDescription><h3>
- 1. Key Milestones
-</h3>
-<table title="" cellspacing="0" cellpadding="2" width="85%" border="1">
- <tbody>
- <tr>
- <td>
- <strong>Milestone</strong>
- </td>
- <td>
- <strong>Date</strong>
- </td>
- </tr>
- <tr>
- <td>
- Iteration Start
- </td>
- <td>
- 7/1
- </td>
- </tr>
- <tr>
- <td>
- EXPOWEST Demo
- </td>
- <td>
- 7/24
- </td>
- </tr>
- <tr>
- <td>
- Iteration Stop
- </td>
- <td>
- 7/31
- </td>
- </tr>
- </tbody>
-</table><br />
-<h3>
- 2. High-level Objectives
-</h3>
-<ul>
- <li>
- Address usability issues raised by the Order Management department.
- </li>
- <li>
- Deliver key scenarios showcasing meaningful integration with SAP.
- </li>
- <li>
- Enable early adopters to download and install new builds without requiring constant handholding by the development
- team.
- </li>
- <li>
- Deliver a technical demo at EXPOWEST.
- </li>
-</ul>
-<h3>
- 3. Work Item Assignments
-</h3>
-<table title="" cellspacing="0" cellpadding="2" width="85%" border="1">
- <tbody>
- <tr>
- <td>
- <strong>Name / Description</strong>
- </td>
- <td>
- <strong>Priority</strong>
- </td>
- <td>
- <strong>Size Estimate (Points)</strong>
- </td>
- <td>
- <strong>Assigned To</strong>
- </td>
- <td>
- <strong>Effort estimate (hours)</strong>
- </td>
- </tr>
- <tr>
- <td>
- Support simple inventory control
- </td>
- <td>
- 2
- </td>
- <td>
- 8
- </td>
- <td>
- Lisa
- </td>
- <td>
- 70
- </td>
- </tr>
- <tr>
- <td>
- Do the design
- </td>
- <td>
- &nbsp;
- </td>
- <td>
- &nbsp;
- </td>
- <td>
- Lisa, Ann, Johan
- </td>
- <td>
- 12
- </td>
- </tr>
- <tr>
- <td>
- Implement and test server portion
- </td>
- <td>
- &nbsp;
- </td>
- <td>
- &nbsp;
- </td>
- <td>
- Ann
- </td>
- <td>
- 14
- </td>
- </tr>
- <tr>
- <td>
- Implement and test client portion
- </td>
- <td>
- &nbsp;
- </td>
- <td>
- &nbsp;
- </td>
- <td>
- Johan
- </td>
- <td>
- 28
- </td>
- </tr>
- <tr>
- <td>
- Update end user documentation
- </td>
- <td>
- &nbsp;
- </td>
- <td>
- &nbsp;
- </td>
- <td>
- Lisa
- </td>
- <td>
- 6
- </td>
- </tr>
- <tr>
- <td>
- Produce demo for Supply Chain 2007 Conference
- </td>
- <td>
- 3
- </td>
- <td>
- 5
- </td>
- <td>
- Ann
- </td>
- <td>
- 18
- </td>
- </tr>
- <tr>
- <td>
- Edit end user documentation
- </td>
- <td>
- 2
- </td>
- <td>
- 5
- </td>
- <td>
- Lisa
- </td>
- <td>
- 65
- </td>
- </tr>
- <tr>
- <td>
- <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <p>
- Edit install manual
- </p>
- </blockquote>
- </td>
- <td>
- 2
- </td>
- <td>
- 1
- </td>
- <td>
- Lisa
- </td>
- <td>
- 5
- </td>
- </tr>
- <tr>
- <td>
- <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <p>
- Edit release notes
- </p>
- </blockquote>
- </td>
- <td>
- 2
- </td>
- <td>
- 1
- </td>
- <td>
- Johan
- </td>
- <td>
- 4
- </td>
- </tr>
- <tr>
- <td>
- <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <p>
- Edit online help
- </p>
- </blockquote>
- </td>
- <td>
- 3
- </td>
- <td>
- 2
- </td>
- <td>
- Ann
- </td>
- <td>
- 22
- </td>
- </tr>
- </tbody>
-</table><br />
-<br />
-<h3>
- 4. Evaluation Criteria
-</h3>
-<ul>
- <li>
- 97% of system-level test cases passed.
- </li>
- <li>
- Scenarios for Simple inventory control properly tested and demonstrated to key stakeholders.
- </li>
- <li>
- End user documentation get favorable acceptance by end users.
- </li>
- <li>
- Walkthrough of iteration build with Order Management and Financial Services departments are well received.
- </li>
- <li>
- Favorable response to technical demo at Supply Chain 2007 Conference.<br />
- </li>
+ <mainDescription><h3>
+ 1. Key Milestones
+</h3>
+<table title="" cellspacing="0" cellpadding="2" width="85%" border="1">
+ <tbody>
+ <tr>
+ <td>
+ <strong>Milestone</strong>
+ </td>
+ <td>
+ <strong>Date</strong>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Iteration Start
+ </td>
+ <td>
+ 7/1
+ </td>
+ </tr>
+ <tr>
+ <td>
+ EXPOWEST Demo
+ </td>
+ <td>
+ 7/24
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Iteration Stop
+ </td>
+ <td>
+ 7/31
+ </td>
+ </tr>
+ </tbody>
+</table><br />
+<h3>
+ 2. High-level Objectives
+</h3>
+<ul>
+ <li>
+ Address usability issues raised by the Order Management department.
+ </li>
+ <li>
+ Deliver key scenarios showcasing meaningful integration with SAP.
+ </li>
+ <li>
+ Enable early adopters to download and install new builds without requiring constant handholding by the development
+ team.
+ </li>
+ <li>
+ Deliver a technical demo at EXPOWEST.
+ </li>
+</ul>
+<h3>
+ 3. Work Item Assignments
+</h3>
+<table title="" cellspacing="0" cellpadding="2" width="85%" border="1">
+ <tbody>
+ <tr>
+ <td>
+ <strong>Name / Description</strong>
+ </td>
+ <td>
+ <strong>Priority</strong>
+ </td>
+ <td>
+ <strong>Size Estimate (Points)</strong>
+ </td>
+ <td>
+ <strong>Assigned To</strong>
+ </td>
+ <td>
+ <strong>Effort estimate (hours)</strong>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Support simple inventory control
+ </td>
+ <td>
+ 2
+ </td>
+ <td>
+ 8
+ </td>
+ <td>
+ Lisa
+ </td>
+ <td>
+ 70
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Do the design
+ </td>
+ <td>
+ &nbsp;
+ </td>
+ <td>
+ &nbsp;
+ </td>
+ <td>
+ Lisa, Ann, Johan
+ </td>
+ <td>
+ 12
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Implement and test server portion
+ </td>
+ <td>
+ &nbsp;
+ </td>
+ <td>
+ &nbsp;
+ </td>
+ <td>
+ Ann
+ </td>
+ <td>
+ 14
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Implement and test client portion
+ </td>
+ <td>
+ &nbsp;
+ </td>
+ <td>
+ &nbsp;
+ </td>
+ <td>
+ Johan
+ </td>
+ <td>
+ 28
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Update end user documentation
+ </td>
+ <td>
+ &nbsp;
+ </td>
+ <td>
+ &nbsp;
+ </td>
+ <td>
+ Lisa
+ </td>
+ <td>
+ 6
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Produce demo for Supply Chain 2007 Conference
+ </td>
+ <td>
+ 3
+ </td>
+ <td>
+ 5
+ </td>
+ <td>
+ Ann
+ </td>
+ <td>
+ 18
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Edit end user documentation
+ </td>
+ <td>
+ 2
+ </td>
+ <td>
+ 5
+ </td>
+ <td>
+ Lisa
+ </td>
+ <td>
+ 65
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ Edit install manual
+ </p>
+ </blockquote>
+ </td>
+ <td>
+ 2
+ </td>
+ <td>
+ 1
+ </td>
+ <td>
+ Lisa
+ </td>
+ <td>
+ 5
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ Edit release notes
+ </p>
+ </blockquote>
+ </td>
+ <td>
+ 2
+ </td>
+ <td>
+ 1
+ </td>
+ <td>
+ Johan
+ </td>
+ <td>
+ 4
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ Edit online help
+ </p>
+ </blockquote>
+ </td>
+ <td>
+ 3
+ </td>
+ <td>
+ 2
+ </td>
+ <td>
+ Ann
+ </td>
+ <td>
+ 22
+ </td>
+ </tr>
+ </tbody>
+</table><br />
+<br />
+<h3>
+ 4. Evaluation Criteria
+</h3>
+<ul>
+ <li>
+ 97% of system-level test cases passed.
+ </li>
+ <li>
+ Scenarios for Simple inventory control properly tested and demonstrated to key stakeholders.
+ </li>
+ <li>
+ End user documentation get favorable acceptance by end users.
+ </li>
+ <li>
+ Walkthrough of iteration build with Order Management and Financial Services departments are well received.
+ </li>
+ <li>
+ Favorable response to technical demo at Supply Chain 2007 Conference.<br />
+ </li>
</ul></mainDescription>
</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/guidelines/conduct_retrospective.xmi b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/guidelines/conduct_retrospective.xmi
index 25be27d..3e7592d 100644
--- a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/guidelines/conduct_retrospective.xmi
+++ b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/guidelines/conduct_retrospective.xmi
@@ -1,244 +1,244 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-i-UeSpBxKd6YtGLz_NW8GQ" name=",_277QEA4gEdy63f1yVoPyfA" guid="-i-UeSpBxKd6YtGLz_NW8GQ" changeDate="2008-07-11T11:25:08.000-0700" version="7.5.0">
- <mainDescription><h1>
- Participants and facilitator
-</h1>
-<p>
- The participants that gather in the context of a Retrospective constitute more than a "working group". The participants
- should be thought of as "a small number of people with complementary skills who are committed to a common purpose,
- performance goals, and approach for which they hold themselves mutually accountable." [<a
- class="elementLinkWithUserText"
- href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#KAT93"
- guid="_9ToeIB83Edqsvps02rpOOg">KAT93</a>]
-</p>
-<p>
- The participants should consist of individuals representing cross-functional groups, having been involved in the
- project period or project incident for which the Retrospective will be conducted. The size of the team is important,
- for the rigorously participative environment of the Retrospective may be difficult to achieve with an overwhelmingly
- large group (25+ individuals), and a set period of time in which to conduct the Retrospective. Conversely, a small set
- of participants that is under-represented by the appropriate functional groups will limit the benefits and productivity
- of team collaboration and self-organization. Although a Retrospective achieves productive results by actualizing team
- responsibility and self-organization, and opposing traditional imposed authority, the work conducted in a Retrospective
- (involving the members of cross-functional groups) demands the presence of a designated facilitator.
-</p>
-<p>
- The individual that is designated to assume the role of facilitator, or Retrospective leader, should possess
- fundamental skills of a facilitative management approach:
-</p>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <p class="quote">
- "A facilitator is an individual who enables groups and organizations to work more effectively; to collaborate and
- achieve synergy. She or he is a "content-neutral" party who by not taking sides or expressing or advocating a point
- of view during the meeting, can advocate for fair, open, and inclusive procedures to accomplish the group's work. A
- facilitator can also be a learning or dialogue guide to assist a group in thinking deeply about its assumptions,
- beliefs and values and about its systemic processes and context." [<a class="elementLinkWithUserText"
- href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#KAN07"
- guid="_9ToeIB83Edqsvps02rpOOg">KAN07</a>]
- </p>
-</blockquote>
-<p>
- The facilitator can be expected to allow the participants to exercise a sense of ownership in the operating mode of
- thought, act to remove impediments to the team's effort to reach targeted goals, foster an environment of trust and
- thriving collaboration, and support the team in a manner that allows the team to achieve its best thinking. Ultimately,
- the facilitator focuses on managing the format of the Retrospective, while the participants hone their skills in
- managing the Retrospective content and maintaining a high-performance, participatory group dynamic.
-</p>
-<h1>
- Establish norms and agreements
-</h1>
-<p>
- Begin the Project Retrospective by establishing the duration, goals, and expectations of the session. The following are
- typical durations for various Retrospectives:
-</p>
-<ul>
- <li>
- <b>Iteration:</b> 2 to 4 hours
- </li>
- <li>
- <b>Incident:</b> 15 to 45 minutes
- </li>
- <li>
- <b>Project:</b> 1 to several days
- </li>
-</ul>
-<p>
- Select the facilitator of the Retrospective.
-</p>
-<p>
- If the team is gathering to conduct the first Retrospective, the group will need to create the cultural norms that will
- be used in the future Retrospectives. If the team is regrouping to conduct a Retrospective, the existing cultural norms
- will be used. Norm Kerth's Prime Directive is an excellent and widely referenced guiding principle for each
- Retrospective:
-</p>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <p class="quote">
- <strong>Prime Directive</strong>: "Regardless of what we discover, we understand and truly believe that everyone
- did the best job they could, given what they knew at the time, their skills and abilities, the resources available,
- and the situation at hand." [<a class="elementLinkWithUserText"
- href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#KER01"
- guid="_9ToeIB83Edqsvps02rpOOg">KER01</a>]
- </p>
-</blockquote>
-<p>
- Remind the team that the Prime Directive and cultural norms of the Retrospective are in place to establish an
- environment in which the members can safely expose sensitive topics and manage meaningful, if provocative, dialogue.
- The cultural norms guide the team by a "social contract" that clearly outlines the <i>team values and working
- agreements</i> that have been established by the team. The social contract needs to include organizational value
- statements that govern acceptable behavior and interactions, supplemented by inviolable principles that govern the
- conduct and ethics of the team. The team must establish these rules of group engagement before the Retrospective
- continues to the core of the group's intended gathering. Examples of working agreements include:
-</p>
-<ul>
- <li>
- Tardiness is not acceptable
- </li>
- <li>
- Mobile phones must be powered off during the session
- </li>
- <li>
- All participants must be in attendance throughout the duration of the Retrospective or ask permission from the
- group for early departure
- </li>
- <li>
- All opinions are welcome
- </li>
- <li>
- The team must strive for healthy, high-quality interaction
- </li>
-</ul>
-<p>
- The team's working agreements (and&nbsp;the Prime Directive statement) should be displayed prominently in the
- Retrospective session, so that they are clearly visible to all members of the team and, if required, easily accessible
- so that the team can edit the content. After it is defined, future Retrospectives can begin with a review of these
- working agreements.
-</p>
-<p>
- After the team has established a safe environment in which to conduct the Retrospective, the facilitator of the
- Retrospective should elicit participation from the group, thereby granting tacit permission to members who are hesitant
- to participate immediately.
-</p>
-<h1>
- Collect and analyze data
-</h1>
-<p>
- The team begins this step of the Retrospective with a review of the meaningful characteristics of the iteration,
- release, incident, or project period. The focus of the team's work in this step includes:
-</p>
-<ul>
- <li>
- Critical developments,
- </li>
- <li>
- Notable discoveries
- </li>
- <li>
- Work completed
- </li>
- <li>
- Project metrics (velocity, number of defects, and so forth)
- </li>
- <li>
- Review of project artifacts (requirements artifacts, project plans, and such)
- </li>
-</ul>
-<p>
- Encourage the team to capture all information (project data, opinions, and so on) by using various tools (white boards,
- charts, timelines) that provide a visual representation, so that the team can identify relationships and emerging
- patterns.
-</p>
-<p>
- The team uses guiding questions to collect and analyze meaningful project data. You can use these examples of key
- questions to elicit relevant information:
-</p>
-<ul>
- <li>
- Were the defined goals and objectives met? Did the release meet its functionality and quality goals? Did the
- release meet performance and capacity goals?
- </li>
- <li>
- Were risks reduced or eliminated? Can we identify new risks?
- </li>
- <li>
- Were all planned work items addressed? What was the team's velocity relative to the plan?
- </li>
- <li>
- Did the end users provide favorable feedback on what we built in this iteration?
- </li>
- <li>
- Are changes to the project plan required?
- </li>
- <li>
- What portion of the current release will be used to establish the baseline? What portion will need to be reworked?
- </li>
- <li>
- Have there been external changes, such as changes in the marketplace, in the user community, or in the
- requirements?
- </li>
- <li>
- Was the development process appropriate? How can it be fine-tuned for the specific needs of this project?
- </li>
-</ul>
-<p>
- The team has generated a list of candidate topics to focus on for its collective inquiry, or heightened analysis. The
- team's methods of analysis need to facilitate a deepening understanding of the events characterizing the iteration,
- incident, release, or Project Retrospective. The team will be evaluating these driving factors, which ultimately
- documents a roadmap for the next cycle:
-</p>
-<ul>
- <li>
- <b>Success:</b> "What worked well for us during the past iteration (or project or phase)?"
- </li>
- <li>
- <b>Failure:</b> "What did not work well for us during the past iteration [or project or phase)?"
- </li>
- <li>
- <b>Opportunities for improvement:</b> "What should we do differently, or what improvements should we undertake
- during our next iteration (or project or phase)?"
- </li>
-</ul>
-<p>
- With increasing emphasis, the thread of team collaboration continues throughout the Retrospective, thereby fostering an
- environment conducive to candid, unimpeded examination by the team: a rigorous style of examination that will be
- required to unearth the details lurking in the interactions of the team, the conditions of the project, fortuitous
- events, failures, risks, and examples of flourishing success.
-</p>
-<p>
- After the team has collected and analyzed the key data in the Retrospective, the team will have evaluated key project
- content. For each item evaluated, they will have established a root cause. The team will know what worked well, what
- did not, and what to do differently this time, so that they can carry forward a list of suggested improvements that
- will be prioritized by the team.
-</p>
-<h1>
- Set priorities
-</h1>
-<p>
- By referencing the project data collected and analyzed in the Retrospective, the team now creates a list of suggested
- improvements, assigning a priority to each item on the list.
-</p>
-<p>
- The selection of improvements should be limited to a subset that will be applied in the next iteration cycle. This list
- should be considered as input to update the next Iteration Plan, so that you can ensure an integrated relationship
- between the changes identified in the Retrospective and the normal course of the team's work plans.
-</p>
-<p>
- Get commitment from members to complete, the suggested improvements that have been chosen for application in the next
- iteration cycle. The visibility and commitment among the members of the team imbue a sense that the Retrospective was
- worthy of the team's investment of time, and that the results of the work on the Retrospective will be tracked in the
- next iteration cycle.
-</p>
-<p>
- Maintain a backlog of the suggested improvements that were not chosen for the next iteration cycle. This will preserve
- the work of the Retrospective. The selected content will be available for convenient access and monitoring for
- progress, and the unselected items will be available for consideration during future iteration cycles.
-</p>
-<h1>
- Conclude and document the process
-</h1>
-<p>
- The team's honed methods of investigation and analysis&nbsp;are now applied to the Retrospective itself. During the
- evaluation of the Retrospective, the team considers the moments of empowering thought and interaction, considers ideas
- for improving future Retrospectives, revisits the team's social contract, extends appreciation throughout the group,
- and preserves the discoveries of the team (for example,&nbsp;through the use of Retrospective documentation,
- or&nbsp;pictures from a digital camera taken during the Retrospective).
+ <mainDescription><h3>
+ Participants and facilitator
+</h3>
+<p>
+ The participants that gather in the context of a Retrospective constitute more than a "working group". The participants
+ should be thought of as "a small number of people with complementary skills who are committed to a common purpose,
+ performance goals, and approach for which they hold themselves mutually accountable." [<a
+ class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#KAT93"
+ guid="_9ToeIB83Edqsvps02rpOOg">KAT93</a>]
+</p>
+<p>
+ The participants should consist of individuals representing cross-functional groups, having been involved in the
+ project period or project incident for which the Retrospective will be conducted. The size of the team is important,
+ for the rigorously participative environment of the Retrospective may be difficult to achieve with an overwhelmingly
+ large group (25+ individuals), and a set period of time in which to conduct the Retrospective. Conversely, a small set
+ of participants that is under-represented by the appropriate functional groups will limit the benefits and productivity
+ of team collaboration and self-organization. Although a Retrospective achieves productive results by actualizing team
+ responsibility and self-organization, and opposing traditional imposed authority, the work conducted in a Retrospective
+ (involving the members of cross-functional groups) demands the presence of a designated facilitator.
+</p>
+<p>
+ The individual that is designated to assume the role of facilitator, or Retrospective leader, should possess
+ fundamental skills of a facilitative management approach:
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="quote">
+ "A facilitator is an individual who enables groups and organizations to work more effectively; to collaborate and
+ achieve synergy. She or he is a "content-neutral" party who by not taking sides or expressing or advocating a point
+ of view during the meeting, can advocate for fair, open, and inclusive procedures to accomplish the group's work. A
+ facilitator can also be a learning or dialogue guide to assist a group in thinking deeply about its assumptions,
+ beliefs and values and about its systemic processes and context." [<a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#KAN07"
+ guid="_9ToeIB83Edqsvps02rpOOg">KAN07</a>]
+ </p>
+</blockquote>
+<p>
+ The facilitator can be expected to allow the participants to exercise a sense of ownership in the operating mode of
+ thought, act to remove impediments to the team's effort to reach targeted goals, foster an environment of trust and
+ thriving collaboration, and support the team in a manner that allows the team to achieve its best thinking. Ultimately,
+ the facilitator focuses on managing the format of the Retrospective, while the participants hone their skills in
+ managing the Retrospective content and maintaining a high-performance, participatory group dynamic.
+</p>
+<h3>
+ Establish norms and agreements
+</h3>
+<p>
+ Begin the Project Retrospective by establishing the duration, goals, and expectations of the session. The following are
+ typical durations for various Retrospectives:
+</p>
+<ul>
+ <li>
+ <b>Iteration:</b> 2 to 4 hours
+ </li>
+ <li>
+ <b>Incident:</b> 15 to 45 minutes
+ </li>
+ <li>
+ <b>Project:</b> 1 to several days
+ </li>
+</ul>
+<p>
+ Select the facilitator of the Retrospective.
+</p>
+<p>
+ If the team is gathering to conduct the first Retrospective, the group will need to create the cultural norms that will
+ be used in the future Retrospectives. If the team is regrouping to conduct a Retrospective, the existing cultural norms
+ will be used. Norm Kerth's Prime Directive is an excellent and widely referenced guiding principle for each
+ Retrospective:
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p class="quote">
+ <strong>Prime Directive</strong>: "Regardless of what we discover, we understand and truly believe that everyone
+ did the best job they could, given what they knew at the time, their skills and abilities, the resources available,
+ and the situation at hand." [<a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#KER01"
+ guid="_9ToeIB83Edqsvps02rpOOg">KER01</a>]
+ </p>
+</blockquote>
+<p>
+ Remind the team that the Prime Directive and cultural norms of the Retrospective are in place to establish an
+ environment in which the members can safely expose sensitive topics and manage meaningful, if provocative, dialogue.
+ The cultural norms guide the team by a "social contract" that clearly outlines the <i>team values and working
+ agreements</i> that have been established by the team. The social contract needs to include organizational value
+ statements that govern acceptable behavior and interactions, supplemented by inviolable principles that govern the
+ conduct and ethics of the team. The team must establish these rules of group engagement before the Retrospective
+ continues to the core of the group's intended gathering. Examples of working agreements include:
+</p>
+<ul>
+ <li>
+ Tardiness is not acceptable
+ </li>
+ <li>
+ Mobile phones must be powered off during the session
+ </li>
+ <li>
+ All participants must be in attendance throughout the duration of the Retrospective or ask permission from the
+ group for early departure
+ </li>
+ <li>
+ All opinions are welcome
+ </li>
+ <li>
+ The team must strive for healthy, high-quality interaction
+ </li>
+</ul>
+<p>
+ The team's working agreements (and&nbsp;the Prime Directive statement) should be displayed prominently in the
+ Retrospective session, so that they are clearly visible to all members of the team and, if required, easily accessible
+ so that the team can edit the content. After it is defined, future Retrospectives can begin with a review of these
+ working agreements.
+</p>
+<p>
+ After the team has established a safe environment in which to conduct the Retrospective, the facilitator of the
+ Retrospective should elicit participation from the group, thereby granting tacit permission to members who are hesitant
+ to participate immediately.
+</p>
+<h3>
+ Collect and analyze data
+</h3>
+<p>
+ The team begins this step of the Retrospective with a review of the meaningful characteristics of the iteration,
+ release, incident, or project period. The focus of the team's work in this step includes:
+</p>
+<ul>
+ <li>
+ Critical developments,
+ </li>
+ <li>
+ Notable discoveries
+ </li>
+ <li>
+ Work completed
+ </li>
+ <li>
+ Project metrics (velocity, number of defects, and so forth)
+ </li>
+ <li>
+ Review of project artifacts (requirements artifacts, project plans, and such)
+ </li>
+</ul>
+<p>
+ Encourage the team to capture all information (project data, opinions, and so on) by using various tools (white boards,
+ charts, timelines) that provide a visual representation, so that the team can identify relationships and emerging
+ patterns.
+</p>
+<p>
+ The team uses guiding questions to collect and analyze meaningful project data. You can use these examples of key
+ questions to elicit relevant information:
+</p>
+<ul>
+ <li>
+ Were the defined goals and objectives met? Did the release meet its functionality and quality goals? Did the
+ release meet performance and capacity goals?
+ </li>
+ <li>
+ Were risks reduced or eliminated? Can we identify new risks?
+ </li>
+ <li>
+ Were all planned work items addressed? What was the team's velocity relative to the plan?
+ </li>
+ <li>
+ Did the end users provide favorable feedback on what we built in this iteration?
+ </li>
+ <li>
+ Are changes to the project plan required?
+ </li>
+ <li>
+ What portion of the current release will be used to establish the baseline? What portion will need to be reworked?
+ </li>
+ <li>
+ Have there been external changes, such as changes in the marketplace, in the user community, or in the
+ requirements?
+ </li>
+ <li>
+ Was the development process appropriate? How can it be fine-tuned for the specific needs of this project?
+ </li>
+</ul>
+<p>
+ The team has generated a list of candidate topics to focus on for its collective inquiry, or heightened analysis. The
+ team's methods of analysis need to facilitate a deepening understanding of the events characterizing the iteration,
+ incident, release, or Project Retrospective. The team will be evaluating these driving factors, which ultimately
+ documents a roadmap for the next cycle:
+</p>
+<ul>
+ <li>
+ <b>Success:</b> "What worked well for us during the past iteration (or project or phase)?"
+ </li>
+ <li>
+ <b>Failure:</b> "What did not work well for us during the past iteration [or project or phase)?"
+ </li>
+ <li>
+ <b>Opportunities for improvement:</b> "What should we do differently, or what improvements should we undertake
+ during our next iteration (or project or phase)?"
+ </li>
+</ul>
+<p>
+ With increasing emphasis, the thread of team collaboration continues throughout the Retrospective, thereby fostering an
+ environment conducive to candid, unimpeded examination by the team: a rigorous style of examination that will be
+ required to unearth the details lurking in the interactions of the team, the conditions of the project, fortuitous
+ events, failures, risks, and examples of flourishing success.
+</p>
+<p>
+ After the team has collected and analyzed the key data in the Retrospective, the team will have evaluated key project
+ content. For each item evaluated, they will have established a root cause. The team will know what worked well, what
+ did not, and what to do differently this time, so that they can carry forward a list of suggested improvements that
+ will be prioritized by the team.
+</p>
+<h3>
+ Set priorities
+</h3>
+<p>
+ By referencing the project data collected and analyzed in the Retrospective, the team now creates a list of suggested
+ improvements, assigning a priority to each item on the list.
+</p>
+<p>
+ The selection of improvements should be limited to a subset that will be applied in the next iteration cycle. This list
+ should be considered as input to update the next Iteration Plan, so that you can ensure an integrated relationship
+ between the changes identified in the Retrospective and the normal course of the team's work plans.
+</p>
+<p>
+ Get commitment from members to complete, the suggested improvements that have been chosen for application in the next
+ iteration cycle. The visibility and commitment among the members of the team imbue a sense that the Retrospective was
+ worthy of the team's investment of time, and that the results of the work on the Retrospective will be tracked in the
+ next iteration cycle.
+</p>
+<p>
+ Maintain a backlog of the suggested improvements that were not chosen for the next iteration cycle. This will preserve
+ the work of the Retrospective. The selected content will be available for convenient access and monitoring for
+ progress, and the unselected items will be available for consideration during future iteration cycles.
+</p>
+<h3>
+ Conclude and document the process
+</h3>
+<p>
+ The team's honed methods of investigation and analysis&nbsp;are now applied to the Retrospective itself. During the
+ evaluation of the Retrospective, the team considers the moments of empowering thought and interaction, considers ideas
+ for improving future Retrospectives, revisits the team's social contract, extends appreciation throughout the group,
+ and preserves the discoveries of the team (for example,&nbsp;through the use of Retrospective documentation,
+ or&nbsp;pictures from a digital camera taken during the Retrospective).
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/guidelines/iteration_assessment.xmi b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/guidelines/iteration_assessment.xmi
index 30d6c08..a988d44 100644
--- a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/guidelines/iteration_assessment.xmi
+++ b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/guidelines/iteration_assessment.xmi
@@ -1,59 +1,64 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-Cn1EflOAHbfuEjRZeLMyzA" name="new_guideline,_FekBAC4IEdyhZrtGEIITGQ" guid="-Cn1EflOAHbfuEjRZeLMyzA" changeDate="2008-06-30T10:21:13.000-0700" version="7.2.0">
- <mainDescription><h3>
- Practice
-</h3>
-An iteration assessment is a short meeting (up to 4 hours) involving the team and stakeholders.&nbsp;The solution
-increment is used as the focal point for brainstorming, and&nbsp;for considering what functionality might be added in the next
-Iteration. It is a low ceremony meeting, so the team should not waste too much time preparing the demo and formal
-presentations. Preparations can, instead, be focused on making the demo fast-paced, and thinking about a good story to
-present the scenarios planned for the demo [<a class="elementLinkWithUserText" href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#STZ07" guid="_9ToeIB83Edqsvps02rpOOg">STZ07</a>].<br />
-<br />
-The team should start the meeting by reviewing the iteration goal before presenting&nbsp;the functionality. The demo should
-be kept at a business-oriented level, leaving out the technical details. It should be focused on what was
-accomplished&nbsp;rather than how it was done. If possible, the audience should try to use the product. Minor bug fixes and
-trivial features should not be demonstrated, but just mentioned, because the audience&nbsp;may lose focus on more important
-scenarios. Functionality that isn't <span style="BACKGROUND-COLOR: rgb(255,255,255)">really completed (acceptance
-tested)</span>&nbsp;should not&nbsp;be presented. <br />
-<br />
-Team members present the system functionality and answer stakeholders' questions. They also record changes, missing
-functionality, and&nbsp;ideas for new features in the work item list. At the end of the presentation, the stakeholders are
-asked for their impressions and the priority of the changes. The potential rearrangement of the <a class="elementLink" href="./../../../core.mgmt.slot.base/workproducts/project_work_slot_F12BAC46.html" guid="_1QZI8EfUEdyiPI8btkmvmw">[Project Work]</a> is discussed with the team. Other points of discussion may include:
-<ul>
- <li>
- Were the defined goals and objectives met? Did the release meet its functionality and quality goals? Did the
- release meet performance and capacity goals?
- </li>
- <li>
- Were risks reduced or eliminated?&nbsp;Were new risks&nbsp;identified?
- </li>
- <li>
- Were all planned work items addressed? What was the team's velocity relative to plan?
- </li>
- <li>
- Did the end-users provide favorable feedback on what was built in this iteration?
- </li>
- <li>
- Are any changes to the project plan required?
- </li>
- <li>
- What portion of the current release will be baselined? What portion will need to be reworked?
- </li>
- <li>
- Have there been external changes (such as changes in the marketplace, in the user community, or in the requirements)
- that will affect the project plan?
- </li>
-</ul>
-<p>
- Stakeholders and the team may also agree that there is sufficient functionality in the system to provide immediate
- business value, and they may decide to put the solution into production. In that case, discuss what deployment-related
- work items should be added to the <a class="elementLink" href="./../../../core.mgmt.slot.base/workproducts/project_work_slot_F12BAC46.html" guid="_1QZI8EfUEdyiPI8btkmvmw">[Project Work]</a>.
-</p>
-<h3>
- Value
-</h3>
-<p>
- Iteration assessments provide an opportunity for everybody to learn about the solution being built, and obtain vital
- feedback from stakeholders. It also forces the team to actually finish work and release it.
+ <mainDescription><h3>
+ Practice
+</h3>An iteration assessment is a short meeting (up to 4 hours) involving the team and stakeholders.&nbsp;The solution
+increment is used as the focal point for brainstorming, and&nbsp;for considering what functionality might be added in the
+next Iteration. It is a low ceremony meeting, so the team should not waste too much time preparing the demo and formal
+presentations. Preparations can, instead, be focused on making the demo fast-paced, and thinking about a good story to
+present the scenarios planned for the demo [<a class="elementLinkWithUserText"
+href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#STZ07"
+guid="_9ToeIB83Edqsvps02rpOOg">STZ07</a>].<br />
+<br />
+The team should start the meeting by reviewing the iteration goal before presenting&nbsp;the functionality. The demo should
+be kept at a business-oriented level, leaving out the technical details. It should be focused on what was
+accomplished&nbsp;rather than how it was done. If possible, the audience should try to use the product. Minor bug fixes and
+trivial features should not be demonstrated, but just mentioned, because the audience&nbsp;may lose focus on more important
+scenarios. Functionality that isn't <span style="BACKGROUND-COLOR: rgb(255,255,255)">really completed (acceptance
+tested)</span>&nbsp;should not&nbsp;be presented. <br />
+<br />
+Team members present the system functionality and answer stakeholders' questions. They also record changes, missing
+functionality, and&nbsp;ideas for new features in the work item list. At the end of the presentation, the stakeholders are
+asked for their impressions and the priority of the changes. The potential rearrangement of the <a class="elementLink"
+href="./../../../core.mgmt.slot.base/workproducts/project_work_slot_F12BAC46.html" guid="_1QZI8EfUEdyiPI8btkmvmw">[Project
+Work]</a> is discussed with the team. Other points of discussion may include: 
+<ul>
+ <li>
+ Were the defined goals and objectives met? Did the release meet its functionality and quality goals? Did the
+ release meet performance and capacity goals?
+ </li>
+ <li>
+ Were risks reduced or eliminated?&nbsp;Were new risks&nbsp;identified?
+ </li>
+ <li>
+ Were all planned work items addressed? What was the team's velocity relative to plan?
+ </li>
+ <li>
+ Did the end-users provide favorable feedback on what was built in this iteration?
+ </li>
+ <li>
+ Are any changes to the project plan required?
+ </li>
+ <li>
+ What portion of the current release will be baselined? What portion will need to be reworked?
+ </li>
+ <li>
+ Have there been external changes (such as changes in the marketplace, in the user community, or in the
+ requirements) that will affect the project plan?
+ </li>
+</ul>
+<p>
+ Stakeholders and the team may also agree that there is sufficient functionality in the system to provide immediate
+ business value, and they may decide to put the solution into production. In that case, discuss what deployment-related
+ work items should be added to the <a class="elementLink"
+ href="./../../../core.mgmt.slot.base/workproducts/project_work_slot_F12BAC46.html"
+ guid="_1QZI8EfUEdyiPI8btkmvmw">[Project Work]</a>.
+</p>
+<h3>
+ Value
+</h3>
+<p>
+ Iteration assessments provide an opportunity for everybody to learn about the solution being built, and obtain vital
+ feedback from stakeholders. It also forces the team to actually finish work and release it.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/guidelines/iteration_planning.xmi b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/guidelines/iteration_planning.xmi
index c8bcfeb..4ebbc8f 100644
--- a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/guidelines/iteration_planning.xmi
+++ b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/guidelines/iteration_planning.xmi
@@ -1,129 +1,136 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_71hDkMPgEdmbOvqy4O0adg" name="iteration_plan,_0auiMMlgEdmt3adZL5Dmdw" guid="_71hDkMPgEdmbOvqy4O0adg" changeDate="2006-11-01T11:17:34.000-0800" version="7.2.0">
- <mainDescription><h3>
- Introduction
-</h3>
-<p>
- The goal with iteration planning is to establish a few high-level objectives for what to accomplish during the
- iteration, produce a sufficiently detailed plan outlining who needs to do what to accomplish those objectives, and
- define how to assess that you accomplished what you set out to accomplish.
-</p>
-<p>
- Iteration planning is ideally done with the entire team (including key stakeholders) in a meeting (typically lasting one
- to a few hours), at the beginning of an iteration. This ensures that the entire team understands what needs to be done,
- and they become committed to the success of the team. In some cases, it is preferred to have a smaller subset of
- people (such as the Project Manager, an Architect, and an Analyst) to meet in advance to prepare the meeting with a draft
- iteration plan.
-</p>
-<h3>
- Define high-level objectives
-</h3>
-<p>
- A key aspect of an iteration is to focus the team on a short-term deliverable of measurable value. Document between one and five
- high-level objectives to make sure that you do not lose focus on what to accomplish during the iteration. Typically, the
- project plan should outline one or several objectives for each iteration, and those objectives are used as a starting
- point. If you need to further detail or clarify the objectives as you plan your iteration, do so.
-</p>
-<p>
- The objectives are usually based on the following factors:
-</p>
-<ul>
- <li>
- <strong>Critical risks not yet mitigated:</strong> Iteration goals often include driving down the most critical
- risks.
- </li>
- <li>
- <strong>The time allocated to the iteration:</strong> Iterations are fixed in duration, so the Project Manager must ensure
- that the goals for the iteration are realistic relative to the time and the resources allocated to the iteration.
- </li>
- <li>
- <strong>The highest priority features:</strong> Requirements are prioritized to ensure that the critical features
- of the application will be developed and tested early on.
- </li>
-</ul>
-<h3>
- Produce an Iteration Plan
-</h3>
-<p>
- There is an Iteration Plan per iteration that should outline who will implement which work item in how long a time.
- Since iterations are time-boxed, you need to understand how big your &quot;box&quot; is by assessing how many hours of actual work
- can be taken on (see <a class="elementLinkWithType" href="./../../../core.mgmt.common.extend_supp/guidances/guidelines/agile_estimation_A4EF42B3.html" guid="_CGHskBEdEdqY7JB6N6CW2w">Guideline: Agile Estimation</a>. Let's assume that you have six team members, and you have 15 working days in your iteration, and
- you on average can do five actual hours of work per person and day. This will give you 6x15x5h = 450 hours of actual work.
- Note that the average team member only performs between four and six hours of actual project work per day, with the rest being consumed
- by e-mails, meetings, and other overhead activities not directly related to the project.
-</p>
-<p>
- The team should then revisit and update priorities for all of the high-priority items in the Work Items List, to make sure
- that an important work item is not missed that would otherwise fall just below the list of what can be taken on in this
- iteration.
-</p>
-<p>
- Pick the top-priority work item and see if it matches the objectives of the iteration. If it does, assess whether the
- work item is too big to take on within an iteration. If it is too big, break it down into smaller work items. Once the
- work item has been decomposed, the team determines whether to take on one or several child work items.
-</p>
-<p><b> Example:</b> The team would like to take on the work item called <i>Develop Use Case A</i>, but it would take roughly 300 hours to
- develop, so they feel that it is only necessary to do a subset of the use case to achieve their iteration objectives,
- allowing them to take on other high-priority work items. They divide the work item into five smaller work items
- representing different scenarios of use case A. The team decides to take on one out of the five identified scenarios in
- this iteration.
-</p>
-<p>
- When a team has decided to take on a work item, it will assign the work to one or several team members. Ideally, this
- is done by team members signing up to do the work, because this makes people motivated and committed to doing the job. However, based on your team culture, you may instead have the project manager assign the work.
-</p>
-<p>
- The next step is for team member(s) to assess how many actual hours or days it will take to do the work. Ideally, you
- want to have each work assignment to be from a few hours up to&nbsp;two days of work. If the work item is too big,
- consider breaking it down into smaller work items.
-</p>
-<p>
- The team sums up the actual estimate for each work item they have committed to, and checks if they can commit to any
- more work.
-</p>
-<p>
- <b>Example:</b> Jack signed up to develop the chosen scenario for use case A. He thinks that it would take 50 hours, so he
- decided to develop the work into a set of tasks, and he asks other team members to help out with various subtasks:
-</p>
-<ul>
- <li>
- Detail the requirements (Jack): five hours
- </li>
- <li>
- Design the scenario (Jack, Ann, and David): five hours
- </li>
- <li>
- Implement and test the dB changes (Ann): 12 hours
- </li>
- <li>
- Implement and test the server portion (David): 16 hours
- </li>
- <li>
- Implement and test the client portion (Jack): 12 hours
- </li>
- <li>
- Total: 50 hours
- </li>
-</ul>
-<p> As work items are decomposed into smaller tasks, estimates can typically be improved. You also better come to
- understand what is involved, and whether other team members may be better suited to take on a subset of the task.
-</p>
-<p>
- The team now determines whether they are willing to take on another work item by comparing actual hours signed up for
- to the actual hours available. In this case, the team has only signed up for 50 hours so far, and hence has another
- 400 hours available.
-</p>
-<h3>
- Define Evaluation Criteria
-</h3>
-<p>
- It is critical that it is clear to all team members and other stakeholders how you will measure success at the end of
- the iteration. Obvious success criteria should include that you can test the functionality implemented, and that no or few
- defects are detected. Having too many defects makes it impossible to use the functionality, and it will prevent
- meaningful feedback. Test objectives and test cases need to be clearly outlined.
-</p>
-<p>
- There may be other success criteria, such as that you demo the capabilities to a certain set of stakeholders with
- favorable review comments, or that you can successfully demonstrate or make available a tech preview at a conference.
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ The goal with iteration planning is to establish a few high-level objectives for what to accomplish during the
+ iteration, produce a sufficiently detailed plan outlining who needs to do what to accomplish those objectives, and
+ define how to assess that you accomplished what you set out to accomplish.
+</p>
+<p>
+ Iteration planning is ideally done with the entire team (including key stakeholders) in a meeting (typically lasting
+ one to a few hours), at the beginning of an iteration. This ensures that the entire team understands what needs to be
+ done, and they become committed to the success of the team. In some cases, it is preferred to have a smaller subset of
+ people (such as the Project Manager, an Architect, and an Analyst) to meet in advance to prepare the meeting with a
+ draft iteration plan.
+</p>
+<h3>
+ Define high-level objectives
+</h3>
+<p>
+ A key aspect of an iteration is to focus the team on a short-term deliverable of measurable value. Document between one
+ and five high-level objectives to make sure that you do not lose focus on what to accomplish during the iteration.
+ Typically, the project plan should outline one or several objectives for each iteration, and those objectives are used
+ as a starting point. If you need to further detail or clarify the objectives as you plan your iteration, do so.
+</p>
+<p>
+ The objectives are usually based on the following factors:
+</p>
+<ul>
+ <li>
+ <strong>Critical risks not yet mitigated:</strong> Iteration goals often include driving down the most critical
+ risks.
+ </li>
+ <li>
+ <strong>The time allocated to the iteration:</strong> Iterations are fixed in duration, so the Project Manager must
+ ensure that the goals for the iteration are realistic relative to the time and the resources allocated to the
+ iteration.
+ </li>
+ <li>
+ <strong>The highest priority features:</strong> Requirements are prioritized to ensure that the critical features
+ of the application will be developed and tested early on.
+ </li>
+</ul>
+<h3>
+ Produce an Iteration Plan
+</h3>
+<p>
+ There is an Iteration Plan per iteration that should outline who will implement which work item in how long a time.
+ Since iterations are time-boxed, you need to understand how big your "box" is by assessing how many hours of actual
+ work can be taken on (see <a class="elementLinkWithType"
+ href="./../../../core.mgmt.common.extend_supp/guidances/guidelines/agile_estimation_A4EF42B3.html"
+ guid="_CGHskBEdEdqY7JB6N6CW2w">Guideline: Agile Estimation</a>. Let's assume that you have six team members, and you
+ have 15 working days in your iteration, and you on average can do five actual hours of work per person and day. This
+ will give you 6x15x5h = 450 hours of actual work. Note that the average team member only performs between four and six
+ hours of actual project work per day, with the rest being consumed by e-mails, meetings, and other overhead activities
+ not directly related to the project.
+</p>
+<p>
+ The team should then revisit and update priorities for all of the high-priority items in the Work Items List, to make
+ sure that an important work item is not missed that would otherwise fall just below the list of what can be taken on in
+ this iteration.
+</p>
+<p>
+ Pick the top-priority work item and see if it matches the objectives of the iteration. If it does, assess whether the
+ work item is too big to take on within an iteration. If it is too big, break it down into smaller work items. Once the
+ work item has been decomposed, the team determines whether to take on one or several child work items.
+</p>
+<p>
+ <b>Example:</b> The team would like to take on the work item called <i>Develop Use Case A</i>, but it would take
+ roughly 300 hours to develop, so they feel that it is only necessary to do a subset of the use case to achieve their
+ iteration objectives, allowing them to take on other high-priority work items. They divide the work item into five
+ smaller work items representing different scenarios of use case A. The team decides to take on one out of the five
+ identified scenarios in this iteration.
+</p>
+<p>
+ When a team has decided to take on a work item, it will assign the work to one or several team members. Ideally, this
+ is done by team members signing up to do the work, because this makes people motivated and committed to doing the job.
+ However, based on your team culture, you may instead have the project manager assign the work.
+</p>
+<p>
+ The next step is for team member(s) to assess how many actual hours or days it will take to do the work. Ideally, you
+ want to have each work assignment to be from a few hours up to&nbsp;two days of work. If the work item is too big,
+ consider breaking it down into smaller work items.
+</p>
+<p>
+ The team sums up the actual estimate for each work item they have committed to, and checks if they can commit to any
+ more work.
+</p>
+<p>
+ <b>Example:</b> Jack signed up to develop the chosen scenario for use case A. He thinks that it would take 50 hours, so
+ he decided to develop the work into a set of tasks, and he asks other team members to help out with various subtasks:
+</p>
+<ul>
+ <li>
+ Detail the requirements (Jack): five hours
+ </li>
+ <li>
+ Design the scenario (Jack, Ann, and David): five hours
+ </li>
+ <li>
+ Implement and test the dB changes (Ann): 12 hours
+ </li>
+ <li>
+ Implement and test the server portion (David): 16 hours
+ </li>
+ <li>
+ Implement and test the client portion (Jack): 12 hours
+ </li>
+ <li>
+ Total: 50 hours
+ </li>
+</ul>
+<p>
+ As work items are decomposed into smaller tasks, estimates can typically be improved. You also better come to
+ understand what is involved, and whether other team members may be better suited to take on a subset of the task.
+</p>
+<p>
+ The team now determines whether they are willing to take on another work item by comparing actual hours signed up for
+ to the actual hours available. In this case, the team has only signed up for 50 hours so far, and hence has another 400
+ hours available.
+</p>
+<h3>
+ Define Evaluation Criteria
+</h3>
+<p>
+ It is critical that it is clear to all team members and other stakeholders how you will measure success at the end of
+ the iteration. Obvious success criteria should include that you can test the functionality implemented, and that no or
+ few defects are detected. Having too many defects makes it impossible to use the functionality, and it will prevent
+ meaningful feedback. Test objectives and test cases need to be clearly outlined.
+</p>
+<p>
+ There may be other success criteria, such as that you demo the capabilities to a certain set of stakeholders with
+ favorable review comments, or that you can successfully demonstrate or make available a tech preview at a conference.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/guidelines/managing_work_items.xmi b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/guidelines/managing_work_items.xmi
index 30da31f..8eecf70 100644
--- a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/guidelines/managing_work_items.xmi
+++ b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/guidelines/managing_work_items.xmi
@@ -1,155 +1,155 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-G1Oxlk6F0R09vClqy1EzOw" name="managing_work_items,_7vEXEMA4EdqSgKaj2SZBmg" guid="-G1Oxlk6F0R09vClqy1EzOw" changeDate="2010-05-25T04:50:17.000-0700" version="7.2.0">
- <mainDescription><h3>
- Overview
-</h3>
-<p>
- The <a class="elementLinkWithType"
- href="./../../../core.mgmt.common.extend_supp/workproducts/work_items_list_39D03CC8.html"
- guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>&nbsp;captures all scheduled work to be done within the
- project, as well as proposed work that may affect the product. Some of the work items may be implemented in this
- project, some of them may be implemented in a future project, and some of them may never be implemented.
-</p>
-<p>
- Some of the work items may still be poorly defined; therefore, it could represent a big chunk of work, requiring
- potentially several staff months of effort. As the priority of these work items increases, they are typically
- decomposed into smaller work items that represent specific and well-defined tasks that may take hours or days to
- address, see <a class="elementLink"
- href="./../../../practice.mgmt.iterative_dev.base/guidances/concepts/micro_increments_C8773066.html"
- guid="_S80VwCNbEdyCq8v2ZO4QcA">Micro-Increments</a>. In other cases, specific and well-defined work items are created
- directly, representing, for example, a defect to be addressed, as Figure 1illustrates.
-</p>
-<p align="left">
- <strong><font face="Verdana, Arial, Helvetica, sans-serif" size="2"><strong><font
- face="Verdana, Arial, Helvetica, sans-serif" size="2">Figure 1. Work Items List provides one prioritized list of
- scheduled and proposed work</font></strong></font></strong>
-</p>
-<div align="left">
- <strong><br />
- <img alt="" src="resources/work_item_prioritization_diagram.jpg" /></strong>
-</div>
-<p>
- A work item may represent work associated with a defect, enhancement request, change request, use case, scenario, user
- story, supporting requirement, stakeholder request, or anything else that captures a potential requirement or
- improvement to your system. A work item may reference any type of requirement or other useful information that guides
- you in what needs to be done.
-</p>
-<p>
- A big advantage with the <a class="elementLinkWithType"
- href="./../../../core.mgmt.common.extend_supp/workproducts/work_items_list_39D03CC8.html"
- guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>&nbsp;is that it enables you to prioritize only one list
- containing all of the things that may need to be addressed, whether the work item represents work related to a
- requirement, enhancement, or defect. The one exception is that you should prioritize the risk list separately.
-</p>
-<p>
- Nothing in the project will get done if it is not represented or mapped to a work item. This means that all
- requirements, defect reports, and change requests have to be mapped to a work item at some stage. Also, a developer
- will not take on work that is not represented in a work item. Only work items need to be prioritized. This also means
- that tracking work items is a primary means of understanding the status of the project.
-</p>
-<p>
- There are two major types of work items:
-</p>
-<ul>
- <li>
- <strong>Unscheduled work items:</strong> These work items have not yet been assigned to an iteration, and there is
- no detailed effort estimate for the work item yet.<br />
- </li>
- <li>
- <strong>Scheduled work items:</strong> These work items are assigned to an iteration, and they typically have an
- additional set of attributes filled in, such as detailed effort estimates.
- </li>
-</ul>
-<h3>
- Unscheduled work items
-</h3>
-<p>
- Most work items are initially unscheduled, meaning that it has not yet been decided whether to do them and when to do
- them. Unscheduled work items should always represent something meaningful to deliver to stakeholders, such as a
- scenario to be detailed, designed, implemented, and tested. You may consider capturing the following data for such work
- items:
-</p>
-<ul>
- <li>
- Name
- </li>
- <li>
- Description
- </li>
- <li>
- Priority
- </li>
- <li>
- Size estimate, such as a point estimate (see <a class="elementLinkWithType"
- href="./../../../core.mgmt.common.extend_supp/guidances/guidelines/agile_estimation_A4EF42B3.html"
- guid="_CGHskBEdEdqY7JB6N6CW2w">Guideline: Agile Estimation</a>)
- </li>
- <li>
- State, such as New, Assigned, Resolved, Verified, Closed (see work items states section below)
- </li>
- <li>
- Links to other reference material, such as requirements or detailed specifications of what needs to be done
- </li>
-</ul>
-<h3>
- Scheduled work items
-</h3>
-<p>
- After a work item has been assigned to an iteration, it becomes <i>scheduled</i>. You assign work items only to the
- current or next iteration. There is no point in assigning work items to a specific future iteration, because you cannot
- predict what a meaningful schedule will be more than an iteration in advance (see <a class="elementLinkWithType"
- href="./../../../practice.mgmt.iterative_dev.base/guidances/guidelines/iteration_planning_C77F13CE.html"
- guid="_0auiMMlgEdmt3adZL5Dmdw">Guideline: Iteration Planning</a>).
-</p>
-<p>
- The following additional attributes are useful for Scheduled work items:
-</p>
-<ul>
- <li>
- Target iteration
- </li>
- <li>
- Responsible team member
- </li>
- <li>
- Effort estimate left, such as actual hours of work (see <a class="elementLinkWithType"
- href="./../../../core.mgmt.common.extend_supp/guidances/guidelines/agile_estimation_A4EF42B3.html"
- guid="_CGHskBEdEdqY7JB6N6CW2w">Guideline: Agile Estimation</a>)
- </li>
- <li>
- Hours worked
- </li>
-</ul>
-<p>
- This provides the information required to plan and manage an iteration. You can plan iterations by understanding effort
- involved, and you can manage iterations by tracking how much work is left to do (see <a class="elementLinkWithType"
- href="./../../../practice.mgmt.iterative_dev.base/guidances/reports/iteration_burndown_9C1C96F5.html"
- guid="_uAzgkDg3Edu4E8ZdmlYjtA">Report: Iteration Burndown</a>).
-</p>
-<h3>
- Work item states
-</h3>
-<p>
- The following states are useful for tracking work items:
-</p>
-<ul>
- <li>
- <b>New:</b> The work item has been created, but not yet assigned to a team member.
- </li>
- <li>
- <b>Assigned:</b> A team member has been identified as responsible for the work item.
- </li>
- <li>
- <b>Resolved:</b> The team member responsible for the work items has implemented and tested the work item.
- </li>
- <li>
- <b>Verified:</b> The work item has been independently tested.
- </li>
- <li>
- <b>Closed:</b> The work item is no longer active.
- </li>
-</ul>
-<p>
- You may choose another set of states, based on your needs.
+ <mainDescription><h3>
+ Overview
+</h3>
+<p>
+ The <a class="elementLinkWithType"
+ href="./../../../core.mgmt.common.extend_supp/workproducts/work_items_list_39D03CC8.html"
+ guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>&nbsp;captures all scheduled work to be done within the
+ project, as well as proposed work that may affect the product. Some of the work items may be implemented in this
+ project, some of them may be implemented in a future project, and some of them may never be implemented.
+</p>
+<p>
+ Some of the work items may still be poorly defined; therefore, it could represent a big chunk of work, requiring
+ potentially several staff months of effort. As the priority of these work items increases, they are typically
+ decomposed into smaller work items that represent specific and well-defined tasks that may take hours or days to
+ address, see <a class="elementLink"
+ href="./../../../practice.mgmt.iterative_dev.base/guidances/concepts/micro_increments_C8773066.html"
+ guid="_S80VwCNbEdyCq8v2ZO4QcA">Micro-Increments</a>. In other cases, specific and well-defined work items are created
+ directly, representing, for example, a defect to be addressed, as Figure 1illustrates.
+</p>
+<p align="left">
+ <strong><font face="Verdana, Arial, Helvetica, sans-serif" size="2"><strong><font
+ face="Verdana, Arial, Helvetica, sans-serif" size="2">Figure 1. Work Items List provides one prioritized list of
+ scheduled and proposed work</font></strong></font></strong>
+</p>
+<div align="left">
+ <strong><br />
+ <img alt="" src="resources/work_item_prioritization_diagram.jpg" /></strong>
+</div>
+<p>
+ A work item may represent work associated with a defect, enhancement request, change request, use case, scenario, user
+ story, supporting requirement, stakeholder request, or anything else that captures a potential requirement or
+ improvement to your system. A work item may reference any type of requirement or other useful information that guides
+ you in what needs to be done.
+</p>
+<p>
+ A big advantage with the <a class="elementLinkWithType"
+ href="./../../../core.mgmt.common.extend_supp/workproducts/work_items_list_39D03CC8.html"
+ guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>&nbsp;is that it enables you to prioritize only one list
+ containing all of the things that may need to be addressed, whether the work item represents work related to a
+ requirement, enhancement, or defect. The one exception is that you should prioritize the risk list separately.
+</p>
+<p>
+ Nothing in the project will get done if it is not represented or mapped to a work item. This means that all
+ requirements, defect reports, and change requests have to be mapped to a work item at some stage. Also, a developer
+ will not take on work that is not represented in a work item. Only work items need to be prioritized. This also means
+ that tracking work items is a primary means of understanding the status of the project.
+</p>
+<p>
+ There are two major types of work items:
+</p>
+<ul>
+ <li>
+ <strong>Unscheduled work items:</strong> These work items have not yet been assigned to an iteration, and there is
+ no detailed effort estimate for the work item yet.<br />
+ </li>
+ <li>
+ <strong>Scheduled work items:</strong> These work items are assigned to an iteration, and they typically have an
+ additional set of attributes filled in, such as detailed effort estimates.
+ </li>
+</ul>
+<h3>
+ Unscheduled work items
+</h3>
+<p>
+ Most work items are initially unscheduled, meaning that it has not yet been decided whether to do them and when to do
+ them. Unscheduled work items should always represent something meaningful to deliver to stakeholders, such as a
+ scenario to be detailed, designed, implemented, and tested. You may consider capturing the following data for such work
+ items:
+</p>
+<ul>
+ <li>
+ Name
+ </li>
+ <li>
+ Description
+ </li>
+ <li>
+ Priority
+ </li>
+ <li>
+ Size estimate, such as a point estimate (see <a class="elementLinkWithType"
+ href="./../../../core.mgmt.common.extend_supp/guidances/guidelines/agile_estimation_A4EF42B3.html"
+ guid="_CGHskBEdEdqY7JB6N6CW2w">Guideline: Agile Estimation</a>)
+ </li>
+ <li>
+ State, such as New, Assigned, Resolved, Verified, Closed (see work items states section below)
+ </li>
+ <li>
+ Links to other reference material, such as requirements or detailed specifications of what needs to be done
+ </li>
+</ul>
+<h3>
+ Scheduled work items
+</h3>
+<p>
+ After a work item has been assigned to an iteration, it becomes <i>scheduled</i>. You assign work items only to the
+ current or next iteration. There is no point in assigning work items to a specific future iteration, because you cannot
+ predict what a meaningful schedule will be more than an iteration in advance (see <a class="elementLinkWithType"
+ href="./../../../practice.mgmt.iterative_dev.base/guidances/guidelines/iteration_planning_C77F13CE.html"
+ guid="_0auiMMlgEdmt3adZL5Dmdw">Guideline: Iteration Planning</a>).
+</p>
+<p>
+ The following additional attributes are useful for Scheduled work items:
+</p>
+<ul>
+ <li>
+ Target iteration
+ </li>
+ <li>
+ Responsible team member
+ </li>
+ <li>
+ Effort estimate left, such as actual hours of work (see <a class="elementLinkWithType"
+ href="./../../../core.mgmt.common.extend_supp/guidances/guidelines/agile_estimation_A4EF42B3.html"
+ guid="_CGHskBEdEdqY7JB6N6CW2w">Guideline: Agile Estimation</a>)
+ </li>
+ <li>
+ Hours worked
+ </li>
+</ul>
+<p>
+ This provides the information required to plan and manage an iteration. You can plan iterations by understanding effort
+ involved, and you can manage iterations by tracking how much work is left to do (see <a class="elementLinkWithType"
+ href="./../../../practice.mgmt.iterative_dev.base/guidances/reports/iteration_burndown_9C1C96F5.html"
+ guid="_uAzgkDg3Edu4E8ZdmlYjtA">Report: Iteration Burndown</a>).
+</p>
+<h3>
+ Work item states
+</h3>
+<p>
+ The following states are useful for tracking work items:
+</p>
+<ul>
+ <li>
+ <b>New:</b> The work item has been created, but not yet assigned to a team member.
+ </li>
+ <li>
+ <b>Assigned:</b> A team member has been identified as responsible for the work item.
+ </li>
+ <li>
+ <b>Resolved:</b> The team member responsible for the work items has implemented and tested the work item.
+ </li>
+ <li>
+ <b>Verified:</b> The work item has been independently tested.
+ </li>
+ <li>
+ <b>Closed:</b> The work item is no longer active.
+ </li>
+</ul>
+<p>
+ You may choose another set of states, based on your needs.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/guidelines/prioritizing_work_items.xmi b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/guidelines/prioritizing_work_items.xmi
index 2b746e4..0bd49c7 100644
--- a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/guidelines/prioritizing_work_items.xmi
+++ b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/guidelines/prioritizing_work_items.xmi
@@ -1,100 +1,102 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-b0rH1AkPSmj1YKyweFWSuQ" name="new_guideline,_oVMZADSoEdy07ZJqOGUGaQ" guid="-b0rH1AkPSmj1YKyweFWSuQ" changeDate="2008-07-11T01:04:38.000-0700" version="7.2.0">
- <mainDescription><h3>
- What is prioritized?
-</h3>
-<p>
- Prioritization should happen for work items, such as enhancement requests,&nbsp;requirements, defects, project tasks, and so on.
- The work items list provides one place for prioritizing work. Prioritizing units of work that are too small may lead to
- analysis-paralysis.
-</p>
-<h3>
- Who prioritizes?
-</h3>
-<p>
- Prioritization is done by the extended team. Here are some examples on how different team members contribute to the
- prioritization:
-</p>
-<ul>
- <li>
- Analysts&nbsp;collaborate with stakeholders to establish the initial priorities for work items to implement, such
- as features, use cases, and scenarios.
- </li>
- <li>
- Architects&nbsp;collaborate with stakeholders and the development team to identify the architecturally significant use
- cases and scenarios, and re-prioritize these so that the team understands what needs to be done to drive down technical
- risk, and&nbsp;to make progress&nbsp;on&nbsp;evolving the product in a technically sensible fashion.
- </li>
- <li>
- Developers&nbsp;and&nbsp;testers help define&nbsp;(but do not decide) the priorities of defects relative to achieving
- iteration objectives.
- </li>
- <li>
- Project managers facilitate (but do not decide), driving convergence on what the team should focus on when planning a
- project, planning an iteration, and managing an iteration. They do this in order to ensure smooth execution, and that the
- perspectives of all team members are properly heard. When the team cannot gain consensus in a reasonable time, the
- project manager has final say on the priority of work items that are too small to warrant the attention of the
- paying stakeholders.
- </li>
- <li>
- Stakeholders&nbsp;that pay for the application have the final say on what capabilities to prioritize.
- </li>
-</ul>
-<h3>
- When do you prioritize?
-</h3>
-<p>
- When you&nbsp;enter a new work item in&nbsp;the Work Items List, give it an initial priority. Priorities are always
- changing. The sections below describe what re-prioritization is done when you are planning a project,
- planning an iteration,&nbsp;or managing an iteration.
-</p>
-<h4>
- Prioritizing when planning a project
-</h4>
-<p>
- During project planning,&nbsp;prioritize the key features, use cases, and scenarios. Also, potentially assign them
- to&nbsp;iterations as a part of laying out the project plan, by defining at a high level what should be done when.
- These priorities will be revised later on as iterations are planned.
-</p>
-<p>
- When starting a project where an existing application will be enhanced,&nbsp;a Work Items List may exist from past
- projects and usage of the application. If this is the case,&nbsp;go through the Work Items List to survey and
- re-prioritize existing work items, so&nbsp;that the team understands what to focus on.
-</p>
-<h4>
- Prioritizing when planning an iteration
-</h4>
-<p>
- When planning what to deliver for an iteration,&nbsp;the team needs to balance what delivers immediate value to the
- stakeholders with what risks need to be mitigated.The chosen balance should be reflected in the iteration objectives,
- which then drive further prioritization and assignments of work items to the next iteration. This exercise should be
- done by the entire team to reflect all of the key perspectives, such as technical ("doing task A before task B saves you
- time"), managerial ("we do not have anybody that knows that legacy application until next iteration", or business
- ("this scenario is more important than that scenario").
-</p>
-<h4>
- Prioritizing when managing an iteration
-</h4>
-<p>
- The recommendation is not to&nbsp;expand or change the scope of an iteration, because this will almost certainly lead to
- scope creep, as well as potential confusion among the team on what to work on. As new features and enhancements are requested,
- capture them in the Work Items List, but do not assign them to the current iteration.
-</p>
-<p>
- During an iteration, you are developing and testing code. As you develop solution increments, you will find defects. In
- most cases, you will directly fix trivial&nbsp;defects as you find them during development. Examples of such defects
- are the many problems you find as you implement your code (for example, using a test-driven development approach or
- doing your regular unit tests). In other cases, the defect should be captured as a work item. This allows it to be
- prioritized, and potentially developed by somebody else or at a different time. If a defect needs to be addressed to
- provide an iteration build of reasonable quality&nbsp;and that&nbsp;aligns with the&nbsp;iteration objectives,&nbsp;the
- defect&nbsp;should be&nbsp;fixed&nbsp;during the current iteration. Note that this is not a creep or change of scope,
- since it merely indicates that something needs to be fixed to deliver what&nbsp;the team&nbsp;already committed to.
-</p>
-<h3>
- How do you prioritize?
-</h3>
-<p>
- Prioritizing is the difficult balancing of frequently competing priorities. For more information on the art of
- prioritizing, see for example [<a class="elementLinkWithUserText" href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#COH05" guid="_9ToeIB83Edqsvps02rpOOg">COH05</a>].
+ <mainDescription><h3>
+ What is prioritized?
+</h3>
+<p>
+ Prioritization should happen for work items, such as enhancement requests,&nbsp;requirements, defects, project tasks,
+ and so on. The work items list provides one place for prioritizing work. Prioritizing units of work that are too small
+ may lead to analysis-paralysis.
+</p>
+<h3>
+ Who prioritizes?
+</h3>
+<p>
+ Prioritization is done by the extended team. Here are some examples on how different team members contribute to the
+ prioritization:
+</p>
+<ul>
+ <li>
+ Analysts&nbsp;collaborate with stakeholders to establish the initial priorities for work items to implement, such
+ as features, use cases, and scenarios.
+ </li>
+ <li>
+ Architects&nbsp;collaborate with stakeholders and the development team to identify the architecturally significant
+ use cases and scenarios, and re-prioritize these so that the team understands what needs to be done to drive down
+ technical risk, and&nbsp;to make progress&nbsp;on&nbsp;evolving the product in a technically sensible fashion.
+ </li>
+ <li>
+ Developers&nbsp;and&nbsp;testers help define&nbsp;(but do not decide) the priorities of defects relative to
+ achieving iteration objectives.
+ </li>
+ <li>
+ Project managers facilitate (but do not decide), driving convergence on what the team should focus on when planning
+ a project, planning an iteration, and managing an iteration. They do this in order to ensure smooth execution, and
+ that the perspectives of all team members are properly heard. When the team cannot gain consensus in a reasonable
+ time, the project manager has final say on the priority of work items that are too small to warrant the attention
+ of the paying stakeholders.
+ </li>
+ <li>
+ Stakeholders&nbsp;that pay for the application have the final say on what capabilities to prioritize.
+ </li>
+</ul>
+<h3>
+ When do you prioritize?
+</h3>
+<p>
+ When you&nbsp;enter a new work item in&nbsp;the Work Items List, give it an initial priority. Priorities are always
+ changing. The sections below describe what re-prioritization is done when you are planning a project, planning an
+ iteration,&nbsp;or managing an iteration.
+</p>
+<h4>
+ Prioritizing when planning a project
+</h4>
+<p>
+ During project planning,&nbsp;prioritize the key features, use cases, and scenarios. Also, potentially assign them
+ to&nbsp;iterations as a part of laying out the project plan, by defining at a high level what should be done when.
+ These priorities will be revised later on as iterations are planned.
+</p>
+<p>
+ When starting a project where an existing application will be enhanced,&nbsp;a Work Items List may exist from past
+ projects and usage of the application. If this is the case,&nbsp;go through the Work Items List to survey and
+ re-prioritize existing work items, so&nbsp;that the team understands what to focus on.
+</p>
+<h4>
+ Prioritizing when planning an iteration
+</h4>
+<p>
+ When planning what to deliver for an iteration,&nbsp;the team needs to balance what delivers immediate value to the
+ stakeholders with what risks need to be mitigated.The chosen balance should be reflected in the iteration objectives,
+ which then drive further prioritization and assignments of work items to the next iteration. This exercise should be
+ done by the entire team to reflect all of the key perspectives, such as technical ("doing task A before task B saves
+ you time"), managerial ("we do not have anybody that knows that legacy application until next iteration", or business
+ ("this scenario is more important than that scenario").
+</p>
+<h4>
+ Prioritizing when managing an iteration
+</h4>
+<p>
+ The recommendation is not to&nbsp;expand or change the scope of an iteration, because this will almost certainly lead
+ to scope creep, as well as potential confusion among the team on what to work on. As new features and enhancements are
+ requested, capture them in the Work Items List, but do not assign them to the current iteration.
+</p>
+<p>
+ During an iteration, you are developing and testing code. As you develop solution increments, you will find defects. In
+ most cases, you will directly fix trivial&nbsp;defects as you find them during development. Examples of such defects
+ are the many problems you find as you implement your code (for example, using a test-driven development approach or
+ doing your regular unit tests). In other cases, the defect should be captured as a work item. This allows it to be
+ prioritized, and potentially developed by somebody else or at a different time. If a defect needs to be addressed to
+ provide an iteration build of reasonable quality&nbsp;and that&nbsp;aligns with the&nbsp;iteration objectives,&nbsp;the
+ defect&nbsp;should be&nbsp;fixed&nbsp;during the current iteration. Note that this is not a creep or change of scope,
+ since it merely indicates that something needs to be fixed to deliver what&nbsp;the team&nbsp;already committed to.
+</p>
+<h3>
+ How do you prioritize?
+</h3>
+<p>
+ Prioritizing is the difficult balancing of frequently competing priorities. For more information on the art of
+ prioritizing, see for example [<a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#COH05"
+ guid="_9ToeIB83Edqsvps02rpOOg">COH05</a>].
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/practices/iterative_development.xmi b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/practices/iterative_development.xmi
index 97deea2..4f07d17 100644
--- a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/practices/iterative_development.xmi
+++ b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/practices/iterative_development.xmi
@@ -1,5 +1,5 @@
<?xml version="1.0" encoding="UTF-8"?>
-<org.eclipse.epf.uma:PracticeDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmi:id="-Yvy3AKQTjSqBPNxsWkizkQ" name="iterative_development,_LR_g4J9WEdy3Nc4rvuj7bA" guid="-Yvy3AKQTjSqBPNxsWkizkQ" changeDate="2011-02-18T13:31:33.922-0800" version="7.2.0">
+<org.eclipse.epf.uma:PracticeDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-Yvy3AKQTjSqBPNxsWkizkQ" name="iterative_development,_LR_g4J9WEdy3Nc4rvuj7bA" guid="-Yvy3AKQTjSqBPNxsWkizkQ" changeDate="2011-02-18T13:31:33.922-0800" version="7.2.0">
<additionalInfo><h3>
Additional Resources
</h3>
@@ -14,7 +14,9 @@
</ul>
<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
<p>
- Retrieved from <a href="http://www-128.ibm.com/developerworks/rational/library/content/RationalEdge/dec00/FromWaterfalltoIterativeDevelopmentDec00.pdf">http://www-128.ibm.com/developerworks/rational/library/content/RationalEdge/dec00/FromWaterfalltoIterativeDevelopmentDec00.pdf</a>.&nbsp;&nbsp;(<a href="http://get.adobe.com/reader/">Get Adobe Reader</a>)
+ Retrieved from <a
+ href="http://www-128.ibm.com/developerworks/rational/library/content/RationalEdge/dec00/FromWaterfalltoIterativeDevelopmentDec00.pdf">http://www-128.ibm.com/developerworks/rational/library/content/RationalEdge/dec00/FromWaterfalltoIterativeDevelopmentDec00.pdf</a>.&nbsp;&nbsp;(<a
+ href="http://get.adobe.com/reader/">Get Adobe Reader</a>)
</p>
</blockquote>
<ul>
diff --git a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/reports/iteration_burndown.xmi b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/reports/iteration_burndown.xmi
index cce0922..bfce359 100644
--- a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/reports/iteration_burndown.xmi
+++ b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/reports/iteration_burndown.xmi
@@ -1,33 +1,35 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-Aw8p59vJ9rWsOV82rljQiQ" name="iteration_burndown,_uAzgkDg3Edu4E8ZdmlYjtA" guid="-Aw8p59vJ9rWsOV82rljQiQ" changeDate="2006-11-03T07:59:14.000-0800" version="1.0.0">
- <mainDescription><p>
- The iteration burndown report is the primary tool for understanding the status of the current iteration. It shows
- the trend for how much work is left to do within the iteration. This is accomplished by adding the estimated effort
- left for each of the work items to be addressed within the iteration, and showing how the estimated effort is changing
- over the duration of the iteration. The iteration backlog should be updated frequently, preferably daily.
-</p>
-<p>
- These factors affect the team's assessment of how much work remains:
-</p>
-<ul>
- <li>
- Work that has been completed, which means there is less work remaining
- </li>
- <li>
- The developer responsible for a work item changes the assessment of effort required to complete the work item. This
- should be expected, because you typically understand what it really takes to complete a task after you have done a
- subset of the task. It is common for estimates of the work remaining to increase in the beginning of the
- iteration, especially for inexperienced teams, because they often underestimate efforts. Expect estimates to
- continue changing as teams become more experienced, but the modifications are upward as often as downward.
- </li>
-</ul>
-<p>
- Daily or frequent updates of the iteration burndown report allow the team to react to changes. For example, changes can
- include cutting the project scope by removing work items from the iteration, reducing the ambition level associated
- with a work item, or finding better ways of approaching work items (such as having an expert team member help with
- difficult work items).
-</p>
-<p>
- See <a class="elementLink" href="./../../../practice.mgmt.iterative_dev.base/guidances/examples/iteration_burndown_report_example_1AE62791.html" guid="_GtGisDcGEdyTZ9G7ByfQTw">Iteration Burndown Report</a> for an example of an iteration burndown report.<br />
+ <mainDescription><p>
+ The iteration burndown report is the primary tool for understanding the status of the current iteration. It shows the
+ trend for how much work is left to do within the iteration. This is accomplished by adding the estimated effort left
+ for each of the work items to be addressed within the iteration, and showing how the estimated effort is changing over
+ the duration of the iteration. The iteration backlog should be updated frequently, preferably daily.
+</p>
+<p>
+ These factors affect the team's assessment of how much work remains:
+</p>
+<ul>
+ <li>
+ Work that has been completed, which means there is less work remaining
+ </li>
+ <li>
+ The developer responsible for a work item changes the assessment of effort required to complete the work item. This
+ should be expected, because you typically understand what it really takes to complete a task after you have done a
+ subset of the task. It is common for estimates of the work remaining to increase in the beginning of the iteration,
+ especially for inexperienced teams, because they often underestimate efforts. Expect estimates to continue changing
+ as teams become more experienced, but the modifications are upward as often as downward.
+ </li>
+</ul>
+<p>
+ Daily or frequent updates of the iteration burndown report allow the team to react to changes. For example, changes can
+ include cutting the project scope by removing work items from the iteration, reducing the ambition level associated
+ with a work item, or finding better ways of approaching work items (such as having an expert team member help with
+ difficult work items).
+</p>
+<p>
+ See <a class="elementLink"
+ href="./../../../practice.mgmt.iterative_dev.base/guidances/examples/iteration_burndown_report_example_1AE62791.html"
+ guid="_GtGisDcGEdyTZ9G7ByfQTw">Iteration Burndown Report</a> for an example of an iteration burndown report.<br />
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/roadmaps/how_to_adopt.xmi b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/roadmaps/how_to_adopt.xmi
index 6334de2..e68d0da 100644
--- a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/roadmaps/how_to_adopt.xmi
+++ b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/roadmaps/how_to_adopt.xmi
@@ -1,123 +1,143 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-hWKKNia-vOmQZTZWO24u5w" name="how_to_adopt,_ERIDQOMPEdyM47cGD2jiaQ" guid="-hWKKNia-vOmQZTZWO24u5w" changeDate="2008-07-18T09:54:49.000-0700" version="7.2.0">
- <mainDescription><h3>
- Getting started
-</h3>
-<p>
- Iterative development is based on the idea that a software system is built iteratively in a series of increments. Each
- increment adds a subset of the final system's functionality, and the system grows to become more and more complete over
- the course of the project's iterations.
-</p>
-<p>
- Consider making all of your iterations have the same duration. This is important for two reasons: it establishes the "heart
- beat" of the project, and it helps understand the project team's performance. This supports the creation of successively
- more accurate estimates of remaining work. Attack the hardest problems on the first iterations, but do not overload the
- first iteration too much. Make sure that you can show progress at the end of each iteration. Do not extend an iteration in
- order to finish work, but also do not finish an iteration without any software to be demonstrated. If needed, break the problem
- into smaller, more manageable pieces so that this balance can be achieved.
-</p>
-<p>
- Plan an iteration in detail only when it is due to start. Each iteration starts with an iteration planning
- meeting with the whole project team. In this meeting, the objectives of the iteration are defined in terms of work
- items, tasks are identified for these work items, and team members sign up for tasks and provide their estimates. At
- the end of the iteration planning meeting, the iteration plan is comprised of a set of work items, decomposed into
- tasks that individual team members sign up for. The iteration can be started. Once an iteration is under way, it should
- be allowed to proceed according to its plan, with as little external interruption as possible.
-</p>
-<p>
- During the course of the iteration, team members provide frequent status of their tasks in focused meetings. The
- frequency of these meetings is decided by team: it could be daily, a couple times a week, or weekly. Team members work
- on the tasks they signed up for, following the appropriate priority. Allow detailed informal peer coordination to
- happen, and mark completed work items in the iteration plan. The overall iteration status is hence readily available in
- the iteration plan at all times. Any work items that have not been justifiably completed by the end of the iteration
- are removed from the iteration and re-assigned to the next one (or just returned to the work items list).
-</p>
-<p>
- Make all iterations follow the same pattern. This helps the team to focus on activities that are specific to the
- beginning, middle, and end of an iteration. For example, some common activities performed during an iteration are:</p>
-<ul>
-<li>Iteration planning</li>
-<li>Iteration architecture work</li>
-<li>Continuous development of micro-increments</li>
-<li>Creation of stable weekly builds</li>
-<li>Bug fixing</li>
-<li>Iteration review and Retrospective</li>
-</ul>
- <p>See <a class="elementLink" href="./../../../practice.mgmt.iterative_dev.base/guidances/concepts/iteration_lifecycle_B16552E2.html" guid="_DI_tICNaEdyCq8v2ZO4QcA">Iteration Lifecycle</a> for more information.
-</p>
-<h3>
- Common Pitfalls
-</h3>
-<p>
- There are common pitfalls experienced when adopting an iterative approach, including the ones listed in the following
- sections. Fore more information on challenges when transitioning from waterfall to an iterative development approach,
- see <a class="elementlinkwithusertext" href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#KRU00" guid="_JlTPUM6aEdyuBO4ZIzcyig">[KRU00]</a>.
-</p>
-<h4>
- What project managers should plan for
-</h4>
-<p>
- One of the most difficult situations for project managers is to transition from a traditional development approach
- (such as waterfall) to an iterative approach. There is more planning with iterative development than with waterfall: one
- plan per iteration. At every iteration, there is negotiation with stakeholders, changes in scope, and re-planning.
- Project managers need to avoid detailed planning upfront, and should work with their best estimates for the tasks at
- hand in a given iteration. </p>
- <p>
- However, this behavior should not result in unplanned and non-prioritized requirements
- creating scope-creep, nor unnecessary rework happening on elements that are not broken. The iteration plan, with iteration
- objectives and planned tasks, should be collaboratively created by the project manager, the team, and stakeholders in order
- to promote a common understanding and buy-in into what is expected at the end of an iteration.
-</p>
-<h4>
- Which comes first: specifications or software?
-</h4>
-<p>
- In a waterfall approach, progress is often measured by the completion of specifications. For example, if the design
- specification is completed and signed-off, the team advances to the implementation based on the design specification.</p>
-<p>
- With iterative development, artifacts evolve throughout the iterations, and every iteration should result in an
- increment in the capabilities offered by the solution: in other words, implemented, tested software that is able to be
- demonstrated (and potentially shipped) to customers. Software comes first. Planning is more important than the plans.
- Designing and architecting an evolving solution is more important than capturing and polishing design and architecture
- models. At the end of each iteration, perform an assessment to gauge the completion of requirements that have
- passed test cases. Another way to make significant progress is by focusing on the harder problems (or risks) as
- early as possible, thus making sure that you create and use a sound, executable architecture as the basis for the other
- requirements.
-</p>
-<h4>
- Different iterations for the different disciplines
-</h4>
-<p>
- A common problem found in organizations moving from a waterfall to an iterative process is that they use the iteration
- concept only as an "envelope" for their engineering disciplines. For example, it is common to hear people in those
- organizations talk about "requirements iteration" or "test iteration". A fundamental tenet of iterative
- development is that it takes a holistic view of work items: each work item assigned to an iteration is completed in
- that iteration. For example, a "Login User" work item would see all required tasks (such as design, code, and test) to
- complete that work item. At the end of the iteration, the Login User behavior can be demonstrated as an integral part of
- the executable system.
-</p>
-<h4>
- No visible progress
-</h4>
-<p>
- Some teams will have work items that are not completed during an iteration as expected, and will not report problems.
- This creates a false impression that work items planned for the iteration are being closed, thus showing an inaccurate
- iteration burndown.<br />
- In order to avoid this, monitor active tasks closely, and address any slippage promptly. Use frequent, short status
- meetings to gauge progress and detect issues. Create a "no blame" environment where everyone feels empowered by the
- team and actively seeks advice and help from the team.
-</p>
-<h4>
- Adding work to an ongoing iteration
-</h4>
-<p>
- Management or stakeholders may impose more work to be added to an on-going iteration. While this is sometimes
- legitimate (for business reasons), there is a risk that this work just gets informally accepted by the team, without
- passing through the Work Items List, where it gets prioritized with the remaining work.<br />
- In order to minimize the impact of new work being added to an iteration, make sure to involve stakeholders in the
- planning process, so that they understand the impact a new work item brings to the current iteration. Be prepared to
- negotiate the removal of lower priority work from the iteration, in order to accommodate the new requested work.
- Another approach is to convince stakeholders that in a few weeks the iteration will end (with demonstrable progress),
- and that the new work item can be prioritized and assigned to the next iteration.
+ <mainDescription><h3>
+ Getting started&nbsp;
+</h3>
+<p>
+ Iterative development is based on the idea that a software system is built iteratively in a series of increments. Each
+ increment adds a subset of the final system's functionality, and the system grows to become more and more complete over
+ the course of the project's iterations.
+</p>
+<p>
+ Consider making all of your iterations have the same duration. This is important for two reasons: it establishes the
+ "heart beat" of the project, and it helps understand the project team's performance. This supports the creation of
+ successively more accurate estimates of remaining work. Attack the hardest problems on the first iterations, but do not
+ overload the first iteration too much. Make sure that you can show progress at the end of each iteration. Do not extend
+ an iteration in order to finish work, but also do not finish an iteration without any software to be demonstrated. If
+ needed, break the problem into smaller, more manageable pieces so that this balance can be achieved.
+</p>
+<p>
+ Plan an iteration in detail only when it is due to start. Each iteration starts with an iteration planning meeting with
+ the whole project team. In this meeting, the objectives of the iteration are defined in terms of work items, tasks are
+ identified for these work items, and team members sign up for tasks and provide their estimates. At the end of the
+ iteration planning meeting, the iteration plan is comprised of a set of work items, decomposed into tasks that
+ individual team members sign up for. The iteration can be started. Once an iteration is under way, it should be allowed
+ to proceed according to its plan, with as little external interruption as possible.
+</p>
+<p>
+ During the course of the iteration, team members provide frequent status of their tasks in focused meetings. The
+ frequency of these meetings is decided by team: it could be daily, a couple times a week, or weekly. Team members work
+ on the tasks they signed up for, following the appropriate priority. Allow detailed informal peer coordination to
+ happen, and mark completed work items in the iteration plan. The overall iteration status is hence readily available in
+ the iteration plan at all times. Any work items that have not been justifiably completed by the end of the iteration
+ are removed from the iteration and re-assigned to the next one (or just returned to the work items list).
+</p>
+<p>
+ Make all iterations follow the same pattern. This helps the team to focus on activities that are specific to the
+ beginning, middle, and end of an iteration. For example, some common activities performed during an iteration are:
+</p>
+<ul>
+ <li>
+ Iteration planning
+ </li>
+ <li>
+ Iteration architecture work
+ </li>
+ <li>
+ Continuous development of micro-increments
+ </li>
+ <li>
+ Creation of stable weekly builds
+ </li>
+ <li>
+ Bug fixing
+ </li>
+ <li>
+ Iteration review and Retrospective
+ </li>
+</ul>
+<p>
+ See <a class="elementLink"
+ href="./../../../practice.mgmt.iterative_dev.base/guidances/concepts/iteration_lifecycle_B16552E2.html"
+ guid="_DI_tICNaEdyCq8v2ZO4QcA">Iteration Lifecycle</a> for more information.
+</p>
+<h3>
+ Common Pitfalls
+</h3>
+<p>
+ There are common pitfalls experienced when adopting an iterative approach, including the ones listed in the following
+ sections. Fore more information on challenges when transitioning from waterfall to an iterative development approach,
+ see <a class="elementlinkwithusertext"
+ href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#KRU00"
+ guid="_JlTPUM6aEdyuBO4ZIzcyig">[KRU00]</a>.
+</p>
+<h4>
+ What project managers should plan for
+</h4>
+<p>
+ One of the most difficult situations for project managers is to transition from a traditional development approach
+ (such as waterfall) to an iterative approach. There is more planning with iterative development than with waterfall:
+ one plan per iteration. At every iteration, there is negotiation with stakeholders, changes in scope, and re-planning.
+ Project managers need to avoid detailed planning upfront, and should work with their best estimates for the tasks at
+ hand in a given iteration.
+</p>
+<p>
+ However, this behavior should not result in unplanned and non-prioritized requirements creating scope-creep, nor
+ unnecessary rework happening on elements that are not broken. The iteration plan, with iteration objectives and planned
+ tasks, should be collaboratively created by the project manager, the team, and stakeholders in order to promote a
+ common understanding and buy-in into what is expected at the end of an iteration.
+</p>
+<h4>
+ Which comes first: specifications or software?
+</h4>
+<p>
+ In a waterfall approach, progress is often measured by the completion of specifications. For example, if the design
+ specification is completed and signed-off, the team advances to the implementation based on the design specification.
+</p>
+<p>
+ With iterative development, artifacts evolve throughout the iterations, and every iteration should result in an
+ increment in the capabilities offered by the solution: in other words, implemented, tested software that is able to be
+ demonstrated (and potentially shipped) to customers. Software comes first. Planning is more important than the plans.
+ Designing and architecting an evolving solution is more important than capturing and polishing design and architecture
+ models. At the end of each iteration, perform an assessment to gauge the completion of requirements that have passed
+ test cases. Another way to make significant progress is by focusing on the harder problems (or risks) as early as
+ possible, thus making sure that you create and use a sound, executable architecture as the basis for the other
+ requirements.
+</p>
+<h4>
+ Different iterations for the different disciplines
+</h4>
+<p>
+ A common problem found in organizations moving from a waterfall to an iterative process is that they use the iteration
+ concept only as an "envelope" for their engineering disciplines. For example, it is common to hear people in those
+ organizations talk about "requirements iteration" or "test iteration". A fundamental tenet of iterative development is
+ that it takes a holistic view of work items: each work item assigned to an iteration is completed in that iteration.
+ For example, a "Login User" work item would see all required tasks (such as design, code, and test) to complete that
+ work item. At the end of the iteration, the Login User behavior can be demonstrated as an integral part of the
+ executable system.
+</p>
+<h4>
+ No visible progress
+</h4>
+<p>
+ Some teams will have work items that are not completed during an iteration as expected, and will not report problems.
+ This creates a false impression that work items planned for the iteration are being closed, thus showing an inaccurate
+ iteration burndown.<br />
+ In order to avoid this, monitor active tasks closely, and address any slippage promptly. Use frequent, short status
+ meetings to gauge progress and detect issues. Create a "no blame" environment where everyone feels empowered by the
+ team and actively seeks advice and help from the team.
+</p>
+<h4>
+ Adding work to an ongoing iteration
+</h4>
+<p>
+ Management or stakeholders may impose more work to be added to an on-going iteration. While this is sometimes
+ legitimate (for business reasons), there is a risk that this work just gets informally accepted by the team, without
+ passing through the Work Items List, where it gets prioritized with the remaining work.<br />
+ In order to minimize the impact of new work being added to an iteration, make sure to involve stakeholders in the
+ planning process, so that they understand the impact a new work item brings to the current iteration. Be prepared to
+ negotiate the removal of lower priority work from the iteration, in order to accommodate the new requested work.
+ Another approach is to convince stakeholders that in a few weeks the iteration will end (with demonstrable progress),
+ and that the new work item can be prioritized and assigned to the next iteration.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/termdefinitions/iteration.xmi b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/termdefinitions/iteration.xmi
index 291b4af..0214026 100644
--- a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/termdefinitions/iteration.xmi
+++ b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/termdefinitions/iteration.xmi
@@ -1,4 +1,5 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-_G0VvVOdMoajk615LwFtxg" name=",_ZBUnMEvFEdunZcj9T5hrMQ" guid="-_G0VvVOdMoajk615LwFtxg" changeDate="2006-09-24T06:23:38.000-0700" version="7.2.0">
- <mainDescription>Short and set duration division of a project. Iterations allow you to demonstrate incremental value and obtain early and continuous feedback.</mainDescription>
+ <mainDescription>Short and set duration division of a project. Iterations allow you to demonstrate incremental value and obtain early and
+continuous feedback.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/termdefinitions/iteration_burndown.xmi b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/termdefinitions/iteration_burndown.xmi
index e192e59..4c17f2b 100644
--- a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/termdefinitions/iteration_burndown.xmi
+++ b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/termdefinitions/iteration_burndown.xmi
@@ -1,4 +1,5 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-3G3HV0opAmFWGxYgsD5AhA" name=",_8b20EEvvEdunZcj9T5hrMQ" guid="-3G3HV0opAmFWGxYgsD5AhA" version="7.2.0">
- <mainDescription>A primary report for understanding the status of an iteration. It shows the trend for how much work is left to do within that iteration.</mainDescription>
+ <mainDescription>A primary report for understanding the status of an iteration. It shows the trend for how much work is left to do within
+that iteration.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/termdefinitions/velocity.xmi b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/termdefinitions/velocity.xmi
index 6a8b424..d3bca6b 100644
--- a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/termdefinitions/velocity.xmi
+++ b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/termdefinitions/velocity.xmi
@@ -1,4 +1,5 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-mgWkuUy3q0zzFaxE7DY1ag" name=",_Nj2hsEvuEdunZcj9T5hrMQ" guid="-mgWkuUy3q0zzFaxE7DY1ag" version="7.2.0">
- <mainDescription>A key metric used for iteration planning. It indicates how many points are delivered upon within an iteration for a certain team and project.</mainDescription>
+ <mainDescription>A key metric used for iteration planning. It indicates how many points are delivered upon within an iteration for a certain
+team and project.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/toolmentors/use_method_composer_to_update_process.xmi b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/toolmentors/use_method_composer_to_update_process.xmi
index 05ffc3e..15624de 100644
--- a/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/toolmentors/use_method_composer_to_update_process.xmi
+++ b/epf_prac_151/practice.mgmt.iterative_dev.base/guidances/toolmentors/use_method_composer_to_update_process.xmi
@@ -1,5 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-5xHoLfZa5sXxhjnW81VZbQ" name="new_toolmentor,_pJJuIOFSEdyhmsbt0Xyl8A" guid="-5xHoLfZa5sXxhjnW81VZbQ" changeDate="2008-09-25T04:15:29.000-0700" version="7.2.0">
- <mainDescription>You may wish to leverage the Method Composer tool to improve the process by incorporating the lessons that have been
-successfully piloted in the project by enhancing templates, checklists, activities, steps, or introducing new practices and guidance.</mainDescription>
+ <mainDescription>You may wish to leverage the Method Composer tool to improve the process by incorporating the lessons that have been
+successfully piloted in the project by enhancing templates, checklists, activities, steps, or introducing new practices and
+guidance.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.iterative_dev.base/tasks/assess_results.xmi b/epf_prac_151/practice.mgmt.iterative_dev.base/tasks/assess_results.xmi
index 3cde89e..3b75734 100644
--- a/epf_prac_151/practice.mgmt.iterative_dev.base/tasks/assess_results.xmi
+++ b/epf_prac_151/practice.mgmt.iterative_dev.base/tasks/assess_results.xmi
@@ -1,24 +1,25 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:TaskDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_a3uz4LBYEdm7Eph_l9Cn9w" name="assess_results,_0l53cMlgEdmt3adZL5Dmdw" guid="_a3uz4LBYEdm7Eph_l9Cn9w" changeDate="2008-07-14T09:22:56.000-0700" version="1.0.0">
- <mainDescription>Coordinate the assessment and discuss with the team how the iteration results will be best presented to stakeholders, so that
-they can learn as much about the solution as possible. Listen to what the team has to say about what went wrong (and what went
-right) during the iteration. This knowledge will help everybody make informed decisions about the next iteration planning,
-and determine the best course of action for the project. This task is performed at the end of every iteration until the end
-of the project.</mainDescription>
+ <mainDescription>Coordinate the assessment and discuss with the team how the iteration results will be best presented to stakeholders, so
+that they can learn as much about the solution as possible. Listen to what the team has to say about what went wrong (and
+what went right) during the iteration. This knowledge will help everybody make informed decisions about the next iteration
+planning, and determine the best course of action for the project. This task is performed at the end of every iteration
+until the end of the project.</mainDescription>
<sections xmi:id="_o28GgMMsEdmdo9HxCRR_Gw" name="Prepare for iteration assessment" guid="_o28GgMMsEdmdo9HxCRR_Gw">
<sectionDescription><p>
Towards the end of the iteration, the team jointly assesses whether the objectives and evaluation criteria established
- in the <a class="elementLink" href="./../../practice.mgmt.iterative_dev.base/workproducts/iteration_plan_B46FED39.html" guid="_0aQBEslgEdmt3adZL5Dmdw">Iteration Plan</a> were met, and whether the team adhered to the plan and completed all
- of the work items committed to the iteration. The team makes use of objective measures to the greatest
- extent possible. To assess that a given work item is completed, the team ensures that the corresponding test cases were
- successfully run against it.
+ in the <a class="elementLink" href="./../../practice.mgmt.iterative_dev.base/workproducts/iteration_plan_B46FED39.html"
+ guid="_0aQBEslgEdmt3adZL5Dmdw">Iteration Plan</a> were met, and whether the team adhered to the plan and completed all
+ of the work items committed to the iteration. The team makes use of objective measures to the greatest extent possible.
+ To assess that a given work item is completed, the team ensures that the corresponding test cases were successfully run
+ against it.
</p>
<p>
- The team prepares a demonstration of the features implemented at that point, so that during the iteration assessment stakeholders can
- have a real sense of progress made. The team decides whether each developer should demonstrate the features that they
- implemented, or if the project manager or senior developer demonstrates it all, with other team members present to answer
- questions. The project manager prepares reports that show project status, such as work burndown and
- test case reports. 
+ The team prepares a demonstration of the features implemented at that point, so that during the iteration assessment
+ stakeholders can have a real sense of progress made. The team decides whether each developer should demonstrate the
+ features that they implemented, or if the project manager or senior developer demonstrates it all, with other team
+ members present to answer questions. The project manager prepares reports that show project status, such as work
+ burndown and test case reports.
</p>
<p>
These activities happen in preparation for the iteration assessment meeting with stakeholders that occurs on the last
@@ -28,22 +29,28 @@
<sections xmi:id="_iSiDEIx4Edyzd4h-mxj9YA" name="Demonstrate value and gather feedback" guid="_iSiDEIx4Edyzd4h-mxj9YA">
<sectionDescription><p>
The team demonstrates the product to customers, end-users, and other stakeholders to collect their feedback or, better
- yet, have end users use the product themselves. This can be done throughout the iteration, but at least during
- the iteration assessment that occurs at the end of the iteration (see <a class="elementLinkWithType" href="./../../practice.mgmt.iterative_dev.base/guidances/guidelines/iteration_assessment_E27E9DDE.html" guid="_FekBAC4IEdyhZrtGEIITGQ">Guideline: Iteration Assessment</a>). Work that is not completed should not be
+ yet, have end users use the product themselves. This can be done throughout the iteration, but at least during the
+ iteration assessment that occurs at the end of the iteration (see <a class="elementLinkWithType"
+ href="./../../practice.mgmt.iterative_dev.base/guidances/guidelines/iteration_assessment_E27E9DDE.html"
+ guid="_FekBAC4IEdyhZrtGEIITGQ">Guideline: Iteration Assessment</a>). Work that is not completed should not be
demonstrated.
</p>
<p>
- Resulting knowledge (such as new functionality, requested changes, and defects) are recorded in the <a class="elementLink" href="./../../core.mgmt.common.extend_supp/workproducts/work_items_list_39D03CC8.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Work Items List</a>, so that project priorities, scope, and duration can be refined in the
- next iteration planning.
+ Resulting knowledge (such as new functionality, requested changes, and defects) are recorded in the <a
+ class="elementLink" href="./../../core.mgmt.common.extend_supp/workproducts/work_items_list_39D03CC8.html"
+ guid="_rGNWsCbSEdqh1LYUOGRh2A">Work Items List</a>, so that project priorities, scope, and duration can be refined in
+ the next iteration planning.
</p></sectionDescription>
</sections>
<sections xmi:id="_iL7cQEpqEdup0IY9DKDPkg" name="Perform a retrospective" guid="_iL7cQEpqEdup0IY9DKDPkg">
<sectionDescription><p>
Review with the team the approach taken to development and collaboration, the effectiveness of the development
environment, the suitability of the working environment, and other factors. Discuss what things went well, what could
- have gone better, and how things could be changed to deliver better results. Capture in the current <a class="elementLink" href="./../../practice.mgmt.iterative_dev.base/workproducts/iteration_plan_B46FED39.html" guid="_0aQBEslgEdmt3adZL5Dmdw">Iteration Plan</a> the assessment results, stakeholder feedback, and actions
- to be taken to improve the development approach for the next iteration. Record lessons learned in this iteration
- with a collection of lessons learned for the entire project. 
+ have gone better, and how things could be changed to deliver better results. Capture in the current <a
+ class="elementLink" href="./../../practice.mgmt.iterative_dev.base/workproducts/iteration_plan_B46FED39.html"
+ guid="_0aQBEslgEdmt3adZL5Dmdw">Iteration Plan</a> the assessment results, stakeholder feedback, and actions to be taken
+ to improve the development approach for the next iteration. Record lessons learned in this iteration with a collection
+ of lessons learned for the entire project.
</p></sectionDescription>
</sections>
<sections xmi:id="_1YHH8DLqEdueZPye-FaNgA" name="Close-out project" guid="_1YHH8DLqEdueZPye-FaNgA">
@@ -54,6 +61,6 @@
and reassigning the remaining staff.
</p></sectionDescription>
</sections>
- <purpose>Demonstrate the value of the solution increment that was built during the iteration and apply the lessons learned to modify
+ <purpose>Demonstrate the value of the solution increment that was built during the iteration and apply the lessons learned to modify
the project or improve the process.</purpose>
</org.eclipse.epf.uma:TaskDescription>
diff --git a/epf_prac_151/practice.mgmt.iterative_dev.base/tasks/manage_iteration.xmi b/epf_prac_151/practice.mgmt.iterative_dev.base/tasks/manage_iteration.xmi
index 88b777e..30945b9 100644
--- a/epf_prac_151/practice.mgmt.iterative_dev.base/tasks/manage_iteration.xmi
+++ b/epf_prac_151/practice.mgmt.iterative_dev.base/tasks/manage_iteration.xmi
@@ -1,41 +1,50 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:TaskDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-PbfqVxB_j9KN-Jx39_pEUA" name="manage_iteration,_8S2aICbYEdqh1LYUOGRh2A" guid="-PbfqVxB_j9KN-Jx39_pEUA" changeDate="2008-07-14T09:47:00.000-0700" version="1.0.0">
- <mainDescription><p>
- Developing the team is part of executing the project. The project manager is responsible for improving the interactions and trust
- between team members, incorporating team building into project activities, and empowering the
- team to make decisions. Management is done by objectives and not by time reporting.
-</p>
-<p>
- The project manager helps the team meet the iteration objectives by removing constraints, and by monitoring the progress
- and work remaining to completion. When the team is falling behind, the project manager helps the team
- assess how it can reduce work and still meet the iteration goals. Involve stakeholders in approving changes and actions
- that affect them, so that their objectives for the iteration can be met, and the issues they raise can be solved throughout
- the iteration.
+ <mainDescription><p>
+ Developing the team is part of executing the project. The project manager is responsible for improving the interactions
+ and trust between team members, incorporating team building into project activities, and empowering the team to make
+ decisions. Management is done by objectives and not by time reporting.
+</p>
+<p>
+ The project manager helps the team meet the iteration objectives by removing constraints, and by monitoring the
+ progress and work remaining to completion. When the team is falling behind, the project manager helps the team assess
+ how it can reduce work and still meet the iteration goals. Involve stakeholders in approving changes and actions that
+ affect them, so that their objectives for the iteration can be met, and the issues they raise can be solved throughout
+ the iteration.
</p></mainDescription>
- <keyConsiderations><p>
- Select an approach for the collection of basic metrics: ideally, they are automatically generated from the tools at
- hand, but can be manually assembled, or both. <span style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Outline
- which metrics the project should use in the <a class="elementLink" href="./../../core.mgmt.slot.base/workproducts/project_definition_and_scope_slot_BB8EB6F7.html" guid="_RJMUcNpUEdyzZqGyZ7hwdw">[Project Definition and Scope]</a>.</span>
+ <keyConsiderations><p>
+ Select an approach for the collection of basic metrics: ideally, they are automatically generated from the tools at
+ hand, but can be manually assembled, or both. <span
+ style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Outline
+ which metrics the project should use in the <a class="elementLink"
+ href="./../../core.mgmt.slot.base/workproducts/project_definition_and_scope_slot_BB8EB6F7.html"
+ guid="_RJMUcNpUEdyzZqGyZ7hwdw">[Project Definition and Scope]</a>.</span>
</p></keyConsiderations>
<sections xmi:id="_OE65ICuxEdqTIKp3l5PtzQ" name="Track current iteration progress" guid="_OE65ICuxEdqTIKp3l5PtzQ">
<sectionDescription><p>
Continuously monitor the iteration to ensure that it is progressing appropriately. Track the progress of the current
iteration by maintaining visibility on the status of the items that are being worked on during the iteration. In
particular, it is important to be able to understand how quickly the team is moving through the work scheduled for the
- iteration, and how accurate the estimates were <a class="elementlinkwithusertext" href="./../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#LEF07" guid="_JlTPUM6aEdyuBO4ZIzcyig">[LEF07]</a>.
+ iteration, and how accurate the estimates were <a class="elementlinkwithusertext"
+ href="./../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#LEF07"
+ guid="_JlTPUM6aEdyuBO4ZIzcyig">[LEF07]</a>.
</p>
<p>
Share information about the progress being made by having quick, frequent meetings with the entire project team. These
meetings are useful to understand what team members have accomplished since the last meeting, and what they plan to
- accomplish before the next meeting. It also allows the team to identify any blocking issues. See <a class="elementLink" href="./../../core.mgmt.slot.base/guidances/guidelines/collaboration_guidance_slot_D3B8DD40.html" guid="_68JUYN8-Edyhmsbt0Xyl8A">[Collaboration Guidance]</a> for more information.
+ accomplish before the next meeting. It also allows the team to identify any blocking issues. See <a class="elementLink"
+ href="./../../core.mgmt.slot.base/guidances/guidelines/collaboration_guidance_slot_D3B8DD40.html"
+ guid="_68JUYN8-Edyhmsbt0Xyl8A">[Collaboration Guidance]</a> for more information.
</p>
<p>
Track the status of each work item by using visual indicators of state information (for example: defined, completed,
- accepted) in a wall or automated tool. Since iterations are typically fixed in duration, another primary way to
- gauge progress is to continuously monitor current status and also estimate how much work remains. Plot an
- iteration burndown chart on a daily basis in order to visualize progress on a given iteration. This chart is plotted
- with the total estimates for all the items that are not yet started and the estimated remaining effort for any item in
- progress. See <a class="elementLinkWithType" href="./../../practice.mgmt.iterative_dev.base/guidances/reports/iteration_burndown_9C1C96F5.html" guid="_uAzgkDg3Edu4E8ZdmlYjtA">Report: Iteration Burndown</a> for more information.
+ accepted) in a wall or automated tool. Since iterations are typically fixed in duration, another primary way to gauge
+ progress is to continuously monitor current status and also estimate how much work remains. Plot an iteration burndown
+ chart on a daily basis in order to visualize progress on a given iteration. This chart is plotted with the total
+ estimates for all the items that are not yet started and the estimated remaining effort for any item in progress. See
+ <a class="elementLinkWithType"
+ href="./../../practice.mgmt.iterative_dev.base/guidances/reports/iteration_burndown_9C1C96F5.html"
+ guid="_uAzgkDg3Edu4E8ZdmlYjtA">Report: Iteration Burndown</a> for more information.
</p>
<p>
Take corrective actions to adjust the course of the iteration if the burndown chart shows that the work will not be
@@ -45,16 +54,16 @@
<sections xmi:id="_urvQkGSyEd2DNqLAFatITA" name="Capture and communicate project status" guid="_urvQkGSyEd2DNqLAFatITA">
<sectionDescription><p>
Because outside stakeholders do not participate in the daily activities of the team, it is important that the status of
- the project should be communicated to them as often as possible. This communication significantly lowers
- the risk of disconnect between the development team and the stakeholders. The status provides the team with
- data they can use to improve their development process.
+ the project should be communicated to them as often as possible. This communication significantly lowers the risk of
+ disconnect between the development team and the stakeholders. The status provides the team with data they can use to
+ improve their development process.
</p>
<p>
- Besides the iteration status, the overall project status can be captured and communicated in
- a burndown report for the whole project. This report should show the progress toward the release
- date, and should be updated at the end of every iteration (when metrics, such as the team's velocity, can also be
- provided). This allows the team to predict what it can accomplish on the remaining project iterations. Other
- metrics (such as number of test cases passed) can also be used to present iteration and project status.
+ Besides the iteration status, the overall project status can be captured and communicated in a burndown report for the
+ whole project. This report should show the progress toward the release date, and should be updated at the end of every
+ iteration (when metrics, such as the team's velocity, can also be provided). This allows the team to predict what it
+ can accomplish on the remaining project iterations. Other metrics (such as number of test cases passed) can also be
+ used to present iteration and project status.
</p>
<p>
Keep the status information visible to stakeholders and the project team at all times in a project workspace (walls or
@@ -65,32 +74,36 @@
<sectionDescription><p>
One of the project manager's key responsibilities is to know about the project team's problems and issues. The manager
needs to focus on problems that are blocking progress. A quick, daily meeting is usually a good way to monitor those
- problems and issues. A record of issues that have to be solved within the team may be kept in the <a class="elementLink" href="./../../practice.mgmt.iterative_dev.base/workproducts/iteration_plan_B46FED39.html" guid="_0aQBEslgEdmt3adZL5Dmdw">Iteration Plan</a><font color="#003399">.</font> If a critical problem or
- issue is likely to take a lot of time to solve, capture it in the Work Items List so that it can be assigned to an
- individual.
+ problems and issues. A record of issues that have to be solved within the team may be kept in the <a
+ class="elementLink" href="./../../practice.mgmt.iterative_dev.base/workproducts/iteration_plan_B46FED39.html"
+ guid="_0aQBEslgEdmt3adZL5Dmdw">Iteration Plan</a><font color="#003399">.</font> If a critical problem or issue is
+ likely to take a lot of time to solve, capture it in the Work Items List so that it can be assigned to an individual.
</p>
<p>
Identify the cause and impact of problems and exceptions as they arise. Identify possible solutions for problems that
- have an immediate impact on the short-term goals and objectives. Identify who needs to be involved in implementing
- the solution. Define the corrective actions and implement them.
+ have an immediate impact on the short-term goals and objectives. Identify who needs to be involved in implementing the
+ solution. Define the corrective actions and implement them.
</p></sectionDescription>
</sections>
<sections xmi:id="_xiFJwCbZEdqh1LYUOGRh2A" name="Identify and manage risks" guid="_xiFJwCbZEdqh1LYUOGRh2A">
<sectionDescription><p>
- Identify risks as soon as the project starts, and continue identifying and managing risks throughout the project. The <a class="elementLink" href="./../../core.mgmt.common.extend_supp/workproducts/risk_list_C4B6F290.html" guid="_Ckay8Cc_EduIsqH1Q6ZuqA">Risk List</a> should be revisited weekly, or at a minimum once per iteration. The
- entire team should be involved in identifying and mitigating risks.
+ Identify risks as soon as the project starts, and continue identifying and managing risks throughout the project. The
+ <a class="elementLink" href="./../../core.mgmt.common.extend_supp/workproducts/risk_list_C4B6F290.html"
+ guid="_Ckay8Cc_EduIsqH1Q6ZuqA">Risk List</a> should be revisited weekly, or at a minimum once per iteration. The entire
+ team should be involved in identifying and mitigating risks.
</p></sectionDescription>
</sections>
<sections xmi:id="_Br6VECuxEdqTIKp3l5PtzQ" name="Manage objectives" guid="_Br6VECuxEdqTIKp3l5PtzQ">
- <sectionDescription>When a team is falling significantly behind, or critical problems occur that prevent the team from meeting the
-iteration objectives, it may be necessary to descope work to ensure that the team delivers a useful product increment by
-the end of the iteration, while maximizing stakeholder value. The project manager should work with the team and
-stakeholders to revise the <a class="elementLink" href="./../../practice.mgmt.iterative_dev.base/workproducts/iteration_plan_B46FED39.html" guid="_0aQBEslgEdmt3adZL5Dmdw">Iteration Plan</a> and, as necessary, reduce the emphasis on less critical tasks by postponing
-them to a subsequent iteration. In rare cases, if the iteration objectives still seem impossible to meet, the team might
-consider terminating the iteration or reformulating the iteration to a new objective.</sectionDescription>
+ <sectionDescription>When a team is falling significantly behind, or critical problems occur that prevent the team from meeting the iteration
+objectives, it may be necessary to descope work to ensure that the team delivers a useful product increment by the end of
+the iteration, while maximizing stakeholder value. The project manager should work with the team and stakeholders to revise
+the <a class="elementLink" href="./../../practice.mgmt.iterative_dev.base/workproducts/iteration_plan_B46FED39.html"
+guid="_0aQBEslgEdmt3adZL5Dmdw">Iteration Plan</a> and, as necessary, reduce the emphasis on less critical tasks by
+postponing them to a subsequent iteration. In rare cases, if the iteration objectives still seem impossible to meet, the
+team might consider terminating the iteration or reformulating the iteration to a new objective.</sectionDescription>
</sections>
- <purpose><p>
- To help the team meet the iteration objectives and keep the project on track. Manage stakeholders'
- expectations as technical and practical discoveries are made during the project.
+ <purpose><p>
+ To help the team meet the iteration objectives and keep the project on track. Manage stakeholders' expectations as
+ technical and practical discoveries are made during the project.
</p></purpose>
</org.eclipse.epf.uma:TaskDescription>
diff --git a/epf_prac_151/practice.mgmt.iterative_dev.base/tasks/plan_iteration.xmi b/epf_prac_151/practice.mgmt.iterative_dev.base/tasks/plan_iteration.xmi
index fcdef17..6d0df39 100644
--- a/epf_prac_151/practice.mgmt.iterative_dev.base/tasks/plan_iteration.xmi
+++ b/epf_prac_151/practice.mgmt.iterative_dev.base/tasks/plan_iteration.xmi
@@ -1,11 +1,11 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:TaskDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_Wk7noKe1EdmGSrcKGOYDGg" name="plan_iteration,_0keUEMlgEdmt3adZL5Dmdw" guid="_Wk7noKe1EdmGSrcKGOYDGg" changeDate="2008-02-21T00:32:50.000-0800" version="7.2.0">
- <mainDescription><p>
- During project planning, iterations are identified, but the estimates have an acceptable uncertainty due to the lack of
- detail at the project inception. This task is repeated for each iteration within a release. It allows the team to
- increase the accuracy of the estimates for one iteration, as more detail is known along the project. The project
- manager has the responsibility of ensuring that the team commits to a reasonable amount of work for the
- iteration, based on team performance from previous iterations.
+ <mainDescription><p>
+ During project planning, iterations are identified, but the estimates have an acceptable uncertainty due to the lack of
+ detail at the project inception. This task is repeated for each iteration within a release. It allows the team to
+ increase the accuracy of the estimates for one iteration, as more detail is known along the project. The project
+ manager has the responsibility of ensuring that the team commits to a reasonable amount of work for the iteration,
+ based on team performance from previous iterations.
</p></mainDescription>
<sections xmi:id="_7bz7AIyAEdyhZb-MhCJrlA" name="Prioritize Work Items List" guid="_7bz7AIyAEdyhZb-MhCJrlA">
<sectionDescription>The work items list should be prioritized before you plan the next iteration. Consider what has changed since the last
@@ -48,27 +48,21 @@
</sections>
<sections xmi:id="_7Hqr4MMsEdmdo9HxCRR_Gw" name="Define evaluation criteria" guid="_7Hqr4MMsEdmdo9HxCRR_Gw">
<sectionDescription><p>
- Each iteration should include testing as a part of the evaluation, as well as the test objectives and test cases
- that need to be detailed. Other evaluation criteria may include successful demonstrations to key stakeholders, or
- favorable usage by a small group of target users. Document evaluation criteria in the iteration plan.
+ Each iteration should include testing as a part of the evaluation, as well as the test objectives and test cases that
+ need to be detailed. Other evaluation criteria may include successful demonstrations to key stakeholders, or favorable
+ usage by a small group of target users. Document evaluation criteria in the iteration plan.
</p></sectionDescription>
</sections>
<sections xmi:id="_-tp18FHjEd2IaYFd32DrjQ" name="Refine project definition and scope" guid="_-tp18FHjEd2IaYFd32DrjQ">
<sectionDescription><p>
- Depending on the results of the previous iteration assessment, update the project definition work products as
- needed. Necessary changes can encompass the need to acquire new resources, to absorb an unplanned effort increase, or
- to implement a specific change request. If a change affects defined project milestones, consult with the
- stakeholders before committing to it.
+ Depending on the results of the previous iteration assessment, update the project definition work products as needed.
+ Necessary changes can encompass the need to acquire new resources, to absorb an unplanned effort increase, or to
+ implement a specific change request. If a change affects defined project milestones, consult with the stakeholders
+ before committing to it.
</p></sectionDescription>
</sections>
- <purpose><p>
-
-
- To identify the next increment of system capability, and create a fine-grained plan for achieving that capability
-
-
- within a single iteration.
-
-
+ <purpose><p>
+ The purpose of this task is to identify the next increment of system capability, and create a fine-grained plan for
+ achieving that capability within a single iteration.
</p></purpose>
</org.eclipse.epf.uma:TaskDescription>
diff --git a/epf_prac_151/practice.mgmt.iterative_dev.base/workproducts/iteration_plan.xmi b/epf_prac_151/practice.mgmt.iterative_dev.base/workproducts/iteration_plan.xmi
index f096849..b24cf1b 100644
--- a/epf_prac_151/practice.mgmt.iterative_dev.base/workproducts/iteration_plan.xmi
+++ b/epf_prac_151/practice.mgmt.iterative_dev.base/workproducts/iteration_plan.xmi
@@ -1,64 +1,64 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ArtifactDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_BcBR8KX5EdmvhNXG0Oc2uA" name="iteration_plan,_0aQBEslgEdmt3adZL5Dmdw" guid="_BcBR8KX5EdmvhNXG0Oc2uA" changeDate="2008-08-18T04:06:22.000-0700" version="7.2.0">
- <mainDescription><p>
- This artifact captures the key milestones of an iteration, showing start and end dates, intermediate milestones,
- synchronization points with other teams, demos, and so on. This artifact is also used to capture issues that need to be
- solved during the iteration.
-</p>
-<p>
- You should list a few objectives for the iteration, which will help guide you throughout the iteration. Also, assess
- at the end if those objectives have been achieved.
-</p>
-<p>
- The task assignments for an iteration are a subset of all tasks on the <a class="elementLinkWithType" href="./../../core.mgmt.common.extend_supp/workproducts/work_items_list_39D03CC8.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>. Therefore, the iteration plan ideally references
- those work items.
-</p>
-<p>
- The evaluation criteria and iteration assessment information are captured in this artifact, so that you can communicate results and actions from
- assessments.
+ <mainDescription><p>
+ This artifact captures the key milestones of an iteration, showing start and end dates, intermediate milestones,
+ synchronization points with other teams, demos, and so on. This artifact is also used to capture issues that need to be
+ solved during the iteration.
+</p>
+<p>
+ You should list a few objectives for the iteration, which will help guide you throughout the iteration. Also, assess at
+ the end if those objectives have been achieved.
+</p>
+<p>
+ The task assignments for an iteration are a subset of all tasks on the <a class="elementLinkWithType"
+ href="./../../core.mgmt.common.extend_supp/workproducts/work_items_list_39D03CC8.html"
+ guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>. Therefore, the iteration plan ideally references those
+ work items.
+</p>
+<p>
+ The evaluation criteria and iteration assessment information are captured in this artifact, so that you can communicate
+ results and actions from assessments.
</p></mainDescription>
- <keyConsiderations><p>
-
- Work items assigned to an iteration do not necessarily have the same priority. When selecting work items from the Work
-
- Items List, the iteration plan may end up having work items with different priorities (for example, you assign the
-
- remaining high priority work items, plus a few mid-priority ones from the Work Items List). When work items are assigned
-
- to an iteration, no matter what their previous priorities, the team has to make sure that they are able to develop
-
- what has been assigned to the iteration. Deciding what to develop first (or
-
- even to develop things in parallel) on an iteration will vary from project to project, from iteration to iteration.
-
+ <keyConsiderations><p>
+ Work items assigned to an iteration do not necessarily have the same priority. When selecting work items from the Work
+ Items List, the iteration plan may end up having work items with different priorities (for example, you assign the
+ remaining high priority work items, plus a few mid-priority ones from the Work Items List). Once work items have been
+ assigned to the iteration, the team ensures that they can complete all work, regardless of original work item
+ priorities. Deciding what to develop first on an iteration will vary across projects and iterations.
</p></keyConsiderations>
- <purpose><p>
- The main objectives of the iteration plan are to provide the team with:</p>
- <ul>
- <li>One central place for information regarding iteration objectives</li>
- <li>A detailed plan with task assignments</li>
- <li>Evaluation results</li>
- </ul>
- <p>
- This artifact also helps the team to
- monitor the progress of the iteration, and keeps the results of the iteration assessment that may be useful for
- improving the next one.
+ <purpose><p>
+ The main objectives of the iteration plan are to provide the team with the following:
+</p>
+<ul>
+ <li>
+ One central place for information regarding iteration objectives
+ </li>
+ <li>
+ A detailed plan with task assignments
+ </li>
+ <li>
+ Evaluation results
+ </li>
+</ul>
+<p>
+ This artifact also helps the team to monitor the progress of the iteration, and keeps the results of the iteration
+ assessment that may be useful for improving the next one.
</p></purpose>
<impactOfNotHaving>Without this artifact, it will be difficult to assess the results of an iteration to determine whether or not the
objectives have been met.</impactOfNotHaving>
<reasonsForNotNeeding>This artifact is not required if no iterations are being performed, or if the scope of the project and each iteration is
sufficiently small as to be handled informally amongst the team.</reasonsForNotNeeding>
<representationOptions><p>
- The level of detail or formality of the plan must be adapted to what you need in order to meet these objectives successfully. The
- plan could, for example, be captured on the following places:
+ The level of detail or formality of the plan must be adapted to what you need in order to meet these objectives
+ successfully. The plan could, for example, be captured on the following places:
</p>
<ul>
<li>
A whiteboard listing the objectives, task assignments, and evaluation criteria
</li>
<li>
- A one-page document listing the objectives and evaluation criteria of the iteration, as well as referencing the Work
- Items List for assignments for that iteration
+ A one-page document listing the objectives and evaluation criteria of the iteration, as well as referencing the
+ Work Items List for assignments for that iteration
</li>
<li>
A more complex document, supported by a Gantt or Pert chart in a project planning tool
diff --git a/epf_prac_151/practice.mgmt.iterative_dev.base/workproducts/work_items_list.contributes.xmi b/epf_prac_151/practice.mgmt.iterative_dev.base/workproducts/work_items_list.contributes.xmi
index 4a20905..400d132 100644
--- a/epf_prac_151/practice.mgmt.iterative_dev.base/workproducts/work_items_list.contributes.xmi
+++ b/epf_prac_151/practice.mgmt.iterative_dev.base/workproducts/work_items_list.contributes.xmi
@@ -4,7 +4,9 @@
As part of the Iteration Plan
</h3>
<p>
- The&nbsp;<a class="elementLink" href="./../../practice.mgmt.iterative_dev.base/workproducts/iteration_plan_B46FED39.html" guid="_0aQBEslgEdmt3adZL5Dmdw">Iteration Plan</a> typically references work items that are assigned to that iteration.
+ The&nbsp;<a class="elementLink"
+ href="./../../practice.mgmt.iterative_dev.base/workproducts/iteration_plan_B46FED39.html"
+ guid="_0aQBEslgEdmt3adZL5Dmdw">Iteration Plan</a> typically references work items that are assigned to that iteration.
If the team is capturing the iteration plan on a whiteboard, for example, the team may choose to reference high-level
work items in the Work Items List that are assigned to the iteration, and maintain low-level child work items used to
track day-to-day work only in an iteration plan.
diff --git a/epf_prac_151/practice.mgmt.release_planning.assign/roles/analyst.assign_guidance.xmi b/epf_prac_151/practice.mgmt.release_planning.assign/roles/analyst.assign_guidance.xmi
index 747ed4a..9f952b2 100644
--- a/epf_prac_151/practice.mgmt.release_planning.assign/roles/analyst.assign_guidance.xmi
+++ b/epf_prac_151/practice.mgmt.release_planning.assign/roles/analyst.assign_guidance.xmi
@@ -2,7 +2,9 @@
<org.eclipse.epf.uma:RoleDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-rZqO0o7t94PG0CUh3wZe3w" name=",_T-dywEIuEd2GCesTWQms8Q" guid="-rZqO0o7t94PG0CUh3wZe3w" changeDate="2008-06-24T01:45:29.000-0700" version="7.5.0">
<assignmentApproaches><ul>
<li>
- See <a class="elementLinkWithType" href="./../../practice.mgmt.two_level_project_planning.base/guidances/guidelines/staffing_project_70705561.html" guid="_Jq64EJjsEduad8I_c-ogIA">Guideline: Staffing a Project</a>&nbsp;to see how members of small agile teams can
+ See <a class="elementLinkWithType"
+ href="./../../practice.mgmt.release_planning.base/guidances/guidelines/staffing_project_70705561.html"
+ guid="_Jq64EJjsEduad8I_c-ogIA">Guideline: Staffing a Project</a>&nbsp;to see how members of small agile teams can
share in this role.
</li>
</ul></assignmentApproaches>
diff --git a/epf_prac_151/practice.mgmt.release_planning.assign/roles/developer.assign_guidance.xmi b/epf_prac_151/practice.mgmt.release_planning.assign/roles/developer.assign_guidance.xmi
index d158ac4..432c462 100644
--- a/epf_prac_151/practice.mgmt.release_planning.assign/roles/developer.assign_guidance.xmi
+++ b/epf_prac_151/practice.mgmt.release_planning.assign/roles/developer.assign_guidance.xmi
@@ -1,5 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:RoleDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-UH4bpYyCuhaEFAe4De1mzA" name=",_42BPkEigEd2O0_STOCj1Ow" guid="-UH4bpYyCuhaEFAe4De1mzA" changeDate="2008-07-02T06:41:15.000-0700" version="7.5.0">
- <assignmentApproaches>See <a class="elementLinkWithType" href="./../../practice.mgmt.two_level_project_planning.base/guidances/guidelines/staffing_project_70705561.html" guid="_Jq64EJjsEduad8I_c-ogIA">Guideline: Staffing a Project</a>&nbsp;for more information about how several team members
+ <assignmentApproaches>See <a class="elementLinkWithType"
+href="./../../practice.mgmt.release_planning.base/guidances/guidelines/staffing_project_70705561.html"
+guid="_Jq64EJjsEduad8I_c-ogIA">Guideline: Staffing a Project</a>&nbsp;for more information about how several team members
can fill this role.</assignmentApproaches>
</org.eclipse.epf.uma:RoleDescription>
diff --git a/epf_prac_151/practice.mgmt.release_planning.base/guidances/guidelines/staffing_project.xmi b/epf_prac_151/practice.mgmt.release_planning.base/guidances/guidelines/staffing_project.xmi
index 45389eb..95763e3 100644
--- a/epf_prac_151/practice.mgmt.release_planning.base/guidances/guidelines/staffing_project.xmi
+++ b/epf_prac_151/practice.mgmt.release_planning.base/guidances/guidelines/staffing_project.xmi
@@ -1,59 +1,62 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-HYO1lwAFOxlT7ncq8EjSng" name="new_guideline,_Jq64EJjsEduad8I_c-ogIA" guid="-HYO1lwAFOxlT7ncq8EjSng" changeDate="2007-01-31T10:46:21.000-0800" version="1.0.0">
- <mainDescription><p>
- Good software development teams are made up of a collection of people who collaborate effectively. How the project team
- is staffed, by either adding or removing people, will greatly impact the team's productivity.
-</p>
-<p>
- When staffing a development project, consider the following advice:
-</p>
-<ul>
- <li>
- Include people who fit into the existing team culture. Good teams do not just appear magically one day, but instead
- are grown and nurtured over time. Invite people onto the team who will add value and, furthermore, who will not be
- disruptive. Similarly, you may need to invite someone to leave the team if they do not fit well with the existing
- team and they do not seem to be able to change.
- </li>
- <li>
- People should want to be on the team. People are far more productive when they are working on a project that they
- believe in and want to see succeed.
- </li>
- <li>
- Build your team with "generalizing specialists". A generalizing specialist is someone with one or more technical
- specialties who actively seeks to gain new skills in their existing specialties as well as in other areas,
- including both technical and domain areas. Generalizing specialists add value to the team because they have
- specialized skills that you need, while at the same time appreciate the full range of issues that a general
- understanding of the software development process and the business domain offers.
- </li>
- <li>
- Include stakeholders. Stakeholders, including business stakeholders (such as end users) and technical stakeholders
- (such as operations staff), can add significant value to your team. Instead of just interviewing them to gain
- information from them, or asking them to review your work, why not include them as active participants on the team?
- </li>
- <li>
- Include specialists for short-term, specialized work. Specialists can still add value on an agile development team,
- particularly when they have specific skills and experience that existing team members do not have. It can often be
- very effective to bring a specialist into the team for a short period of time to help with a specific task (such as
- installation and setup of an application server, the development of an architectural spike, or simply taking part
- in a review).
- </li>
- <li>
- Give people opportunities to evolve their skills. At the beginning of a project, the team may not have the full
- range of skills that it needs, or perhaps a few individuals may not have the skills required to fulfill the roles
- they are filling. This is a very common risk taken by the majority of project teams for the simple reasons that
- you often cannot find the perfect combination of people and, even if you could, you still want to provide people with
- opportunities to grow as professionals.
- </li>
- <li>
- Remember Brook's Law. Adding people to a late project will only make it later [<a href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#BRO95" guid="_JlTPUM6aEdyuBO4ZIzcyig">BRO95</a>]. The corollary is that removing people from a late project may speed
- things up [<a href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html" guid="_9ToeIB83Edqsvps02rpOOg">AMB04</a>].
- </li>
-</ul>
-<p>
- Sometimes you will need to go against some of this advice due to environmental constraints. Perhaps only specialists
- are available (although there is nothing stopping a specialist from becoming a generalizing specialist), perhaps there
- are not as many opportunities for people to try new things as they would like, or perhaps the stakeholders are not
- available to be active members of the team. The advice above is designed to lead to as high-performing a team as
- possible, but even partial adherence to this guideline will improve the team.
+ <mainDescription><p>
+ Good software development teams are made up of a collection of people who collaborate effectively. How the project team
+ is staffed, by either adding or removing people, will greatly impact the team's productivity.
+</p>
+<p>
+ When staffing a development project, consider the following advice:
+</p>
+<ul>
+ <li>
+ Include people who fit into the existing team culture. Good teams do not just appear magically one day, but instead
+ are grown and nurtured over time. Invite people onto the team who will add value and, furthermore, who will not be
+ disruptive. Similarly, you may need to invite someone to leave the team if they do not fit well with the existing
+ team and they do not seem to be able to change.
+ </li>
+ <li>
+ People should want to be on the team. People are far more productive when they are working on a project that they
+ believe in and want to see succeed.
+ </li>
+ <li>
+ Build your team with "generalizing specialists". A generalizing specialist is someone with one or more technical
+ specialties who actively seeks to gain new skills in their existing specialties as well as in other areas,
+ including both technical and domain areas. Generalizing specialists add value to the team because they have
+ specialized skills that you need, while at the same time appreciate the full range of issues that a general
+ understanding of the software development process and the business domain offers.
+ </li>
+ <li>
+ Include stakeholders. Stakeholders, including business stakeholders (such as end users) and technical stakeholders
+ (such as operations staff), can add significant value to your team. Instead of just interviewing them to gain
+ information from them, or asking them to review your work, why not include them as active participants on the team?
+ </li>
+ <li>
+ Include specialists for short-term, specialized work. Specialists can still add value on an agile development team,
+ particularly when they have specific skills and experience that existing team members do not have. It can often be
+ very effective to bring a specialist into the team for a short period of time to help with a specific task (such as
+ installation and setup of an application server, the development of an architectural spike, or simply taking part
+ in a review).
+ </li>
+ <li>
+ Give people opportunities to evolve their skills. At the beginning of a project, the team may not have the full
+ range of skills that it needs, or perhaps a few individuals may not have the skills required to fulfill the roles
+ they are filling. This is a very common risk taken by the majority of project teams for the simple reasons that you
+ often cannot find the perfect combination of people and, even if you could, you still want to provide people with
+ opportunities to grow as professionals.
+ </li>
+ <li>
+ Remember Brook's Law. Adding people to a late project will only make it later [<a
+ href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#BRO95"
+ guid="_JlTPUM6aEdyuBO4ZIzcyig">BRO95</a>]. The corollary is that removing people from a late project may speed
+ things up [<a href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">AMB04</a>].
+ </li>
+</ul>
+<p>
+ Sometimes you will need to go against some of this advice due to environmental constraints. Perhaps only specialists
+ are available (although there is nothing stopping a specialist from becoming a generalizing specialist), perhaps there
+ are not as many opportunities for people to try new things as they would like, or perhaps the stakeholders are not
+ available to be active members of the team. The advice above is designed to lead to as high-performing a team as
+ possible, but even partial adherence to this guideline will improve the team.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.release_planning.base/guidances/practices/release_planning.xmi b/epf_prac_151/practice.mgmt.release_planning.base/guidances/practices/release_planning.xmi
index 7dfcd22..733c782 100644
--- a/epf_prac_151/practice.mgmt.release_planning.base/guidances/practices/release_planning.xmi
+++ b/epf_prac_151/practice.mgmt.release_planning.base/guidances/practices/release_planning.xmi
@@ -58,7 +58,7 @@
<ul>
<li>
<a class="elementLink"
- href="./../../../practice.mgmt.two_level_project_planning.base/workproducts/project_plan_1CDBB7E4.html"
+ href="./../../../practice.mgmt.release_planning.base/workproducts/project_plan_1CDBB7E4.html"
guid="_0a6vcMlgEdmt3adZL5Dmdw">Project Plan</a>
</li>
<li>
@@ -72,33 +72,32 @@
<ul>
<li>
<a class="elementLink"
- href="./../../../practice.mgmt.two_level_project_planning.base/guidances/templates/project_plan_1534BA2B.html"
+ href="./../../../practice.mgmt.release_planning.base/guidances/templates/project_plan_1534BA2B.html"
guid="_0c7hoMlgEdmt3adZL5Dmdw">Project Plan</a> template
</li>
<li>
<a class="elementLink"
- href="./../../../practice.mgmt.two_level_project_planning.base/guidances/examples/project_burndown_report_example_847643C1.html"
+ href="./../../../practice.mgmt.release_planning.base/guidances/examples/project_burndown_report_example_847643C1.html"
guid="_Yiq2EDcGEdyTZ9G7ByfQTw">Project Burndown Report</a> example
</li>
</ul>
<p>
- Finally, get more details on how to perform project planning and staff a project by looking at:
+ Finally, get more details on how to perform project planning and staff a project by looking at the following:
</p>
<ul>
<li>
- <a class="elementLink"
- href="./../../../practice.mgmt.two_level_project_planning.base/tasks/plan_the_project_A4A80C96.html"
+ <a class="elementLink" href="./../../../practice.mgmt.release_planning.base/tasks/plan_the_project_A4A80C96.html"
guid="_0lC70MlgEdmt3adZL5Dmdw">Plan Project</a>&nbsp;task
</li>
<li>
<a class="elementLink"
- href="./../../../practice.mgmt.two_level_project_planning.base/guidances/guidelines/staffing_project_70705561.html"
+ href="./../../../practice.mgmt.release_planning.base/guidances/guidelines/staffing_project_70705561.html"
guid="_Jq64EJjsEduad8I_c-ogIA">Staffing a Project</a> guideline
</li>
</ul>
<p>
See more information on <a class="elementLink"
- href="./../../../practice.mgmt.two_level_project_planning.base/guidances/roadmaps/how_to_adopt_520D7115.html"
- guid="_ihr3sOMPEdyM47cGD2jiaQ">How to Adopt the Two-Level Project Planning Practice</a>.
+ href="./../../../practice.mgmt.release_planning.base/guidances/roadmaps/how_to_adopt_520D7115.html"
+ guid="_ihr3sOMPEdyM47cGD2jiaQ">How to Adopt the Release Planning Practice</a>.
</p></application>
</org.eclipse.epf.uma:PracticeDescription>
diff --git a/epf_prac_151/practice.mgmt.release_planning.base/guidances/reports/project_burndown.xmi b/epf_prac_151/practice.mgmt.release_planning.base/guidances/reports/project_burndown.xmi
index ef3f338..dff0c06 100644
--- a/epf_prac_151/practice.mgmt.release_planning.base/guidances/reports/project_burndown.xmi
+++ b/epf_prac_151/practice.mgmt.release_planning.base/guidances/reports/project_burndown.xmi
@@ -1,19 +1,21 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-hrDndmFd0zexB0HNYX3gww" name="project_burndown,_ePrt8Dj3EduxovfWMDsntw" guid="-hrDndmFd0zexB0HNYX3gww" changeDate="2008-06-17T10:56:57.000-0700" version="1.0.0">
- <mainDescription><p>
- The project burndown report is&nbsp;the primary tool for understanding the status of a project. It shows the trend for
- how much work is left to do within that project. This is done by adding the estimated effort left for each of the work
- items to be addressed within the project, and showing how the estimated effort is changing from iteration to iteration.
- The project burndown report should be updated at the end of each iteration.
-</p>
-<p>
- The project burndown rate is usually communicated in graphical form.&nbsp;The project burndown chart consists of two
- perspectives, with the horizontal axis showing the iterations and the vertical axis indicating the remaining points
- from the work items list. Additionally, the average burndown rate from previous iterations is calculated, and a trend
- for the remainder of the project forecasted from that historical data.&nbsp;
-</p>
-<p>
- Project burndown management is an enabling technique that allows direct linkage of iteration goals to work items. The
- project manager will use the project burndown information for communicating progress and trends to senior management.
-</p>See <a class="elementLink" href="./../../../practice.mgmt.two_level_project_planning.base/guidances/examples/project_burndown_report_example_847643C1.html" guid="_Yiq2EDcGEdyTZ9G7ByfQTw">Project Burndown Report</a>&nbsp;for an example of project burndown report.<br /></mainDescription>
+ <mainDescription><p>
+ The project burndown report is&nbsp;the primary tool for understanding the status of a project. It shows the trend for
+ how much work is left to do within that project. This is done by adding the estimated effort left for each of the work
+ items to be addressed within the project, and showing how the estimated effort is changing from iteration to iteration.
+ The project burndown report should be updated at the end of each iteration.
+</p>
+<p>
+ The project burndown rate is usually communicated in graphical form.&nbsp;The project burndown chart consists of two
+ perspectives, with the horizontal axis showing the iterations and the vertical axis indicating the remaining points
+ from the work items list. Additionally, the average burndown rate from previous iterations is calculated, and a trend
+ for the remainder of the project forecasted from that historical data.&nbsp;
+</p>
+<p>
+ Project burndown management is an enabling technique that allows direct linkage of iteration goals to work items. The
+ project manager will use the project burndown information for communicating progress and trends to senior management.
+</p>See <a class="elementLink"
+href="./../../../practice.mgmt.release_planning.base/guidances/examples/project_burndown_report_example_847643C1.html"
+guid="_Yiq2EDcGEdyTZ9G7ByfQTw">Project Burndown Report</a>&nbsp;for an example of project burndown report.<br /></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.release_planning.base/guidances/roadmaps/how_to_adopt.xmi b/epf_prac_151/practice.mgmt.release_planning.base/guidances/roadmaps/how_to_adopt.xmi
index e809a0d..81057cd 100644
--- a/epf_prac_151/practice.mgmt.release_planning.base/guidances/roadmaps/how_to_adopt.xmi
+++ b/epf_prac_151/practice.mgmt.release_planning.base/guidances/roadmaps/how_to_adopt.xmi
@@ -1,47 +1,47 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-4a1QxeLdn2OKx5_Lft8tBA" name="how_to_adopt,_ERIDQOMPEdyM47cGD2jiaQ" guid="-4a1QxeLdn2OKx5_Lft8tBA" changeDate="2009-07-15T04:22:23.000-0700" version="7.2.0">
- <mainDescription><h3>
- Getting started&nbsp;
-</h3>
-<p>
- Release&nbsp;planning is concerned with creating a strategic project plan (where the internal and external releases of
- the project are identified), and tactical iteration plans for individual iterations within releases. It aims at
- creating the right level of granularity for each purpose, so that the investment in planning is held to a minimum.
-</p>
-<p>
- Begin by understanding the high-level features that the system is expected to possess. These are the system's main
- themes or services, and they are typically described or listed in a vision document. They serve to set goals and
- expectations, both internally and externally, and they guide and constrain the iteration planning.
-</p>
-<p>
- The project plan is coarser-grained than iteration plans. As <a class="elementLinkWithUserText"
- href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#LEF07"
- guid="_JlTPUM6aEdyuBO4ZIzcyig">[LEF07]</a> notes, a system can be described with a list of 25-50 features, calibrated
- to the relative complexity of that system. Iteration plans, on the other hand, are described in terms of individual
- user stories, use cases and scenarios, or other work items that will be&nbsp;developed in each iteration.
-</p>
-<p>
- As early in the project as possible, ideally as part of the kick-off of a new project, hold a planning session (with
- the whole team and the stakeholders of the system) during which the initial project plan is established.
-</p>
-<p>
- Update the project plan as often as necessary to reflect changing business priorities and needs.
-</p>
-<p>
- Iteration plans help to estimate and track individual iterations. For each iteration, its plan is created just-in-time,
- based on the currently highest prioritized work items in the product backlog.
-</p>
-<h3>
- Common pitfalls
-</h3>
-<p>
- One of the biggest challenges with agile planning is to resist pressure from upper management if they require to see
- complete plans up-front in the project. This is best avoided by involving them in the planning process, and by
- demonstrating the value of empirical planning by making the process transparent and open (to the organization and the
- project's stakeholders) so that they can easily follow the progress of the project.
-</p>
-<p>
- It can be difficult to find the right level of granularity for the features of a given system. With too many features,
- the planning process becomes tedious and error-prone, and will work counter to the intent.
+ <mainDescription><h3>
+ Getting started&nbsp;
+</h3>
+<p>
+ Release&nbsp;planning is concerned with creating a strategic project plan (where the internal and external releases of
+ the project are identified), and tactical iteration plans for individual iterations within releases. It aims at
+ creating the right level of granularity for each purpose, so that the investment in planning is held to a minimum.
+</p>
+<p>
+ Begin by understanding the high-level features that the system is expected to possess. These are the system's main
+ themes or services, and they are typically described or listed in a vision document. They serve to set goals and
+ expectations, both internally and externally, and they guide and constrain the iteration planning.
+</p>
+<p>
+ The project plan is coarser-grained than iteration plans. As <a class="elementLinkWithUserText"
+ href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#LEF07"
+ guid="_JlTPUM6aEdyuBO4ZIzcyig">[LEF07]</a> notes, a system can be described with a list of 25-50 features, calibrated
+ to the relative complexity of that system. Iteration plans, on the other hand, are described in terms of individual
+ user stories, use cases and scenarios, or other work items that will be&nbsp;developed in each iteration.
+</p>
+<p>
+ As early in the project as possible, ideally as part of the kick-off of a new project, hold a planning session (with
+ the whole team and the stakeholders of the system) during which the initial project plan is established.
+</p>
+<p>
+ Update the project plan as often as necessary to reflect changing business priorities and needs.
+</p>
+<p>
+ Iteration plans help to estimate and track individual iterations. For each iteration, its plan is created just-in-time,
+ based on the currently highest prioritized work items in the product backlog.
+</p>
+<h3>
+ Common pitfalls
+</h3>
+<p>
+ One of the biggest challenges with agile planning is to resist pressure from upper management if they require to see
+ complete plans up-front in the project. This is best avoided by involving them in the planning process, and by
+ demonstrating the value of empirical planning by making the process transparent and open (to the organization and the
+ project's stakeholders) so that they can easily follow the progress of the project.
+</p>
+<p>
+ It can be difficult to find the right level of granularity for the features of a given system. With too many features,
+ the planning process becomes tedious and error-prone, and will work counter to the intent.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.release_planning.base/guidances/termdefinitions/project_burndown.xmi b/epf_prac_151/practice.mgmt.release_planning.base/guidances/termdefinitions/project_burndown.xmi
index 0a45896..d9ea988 100644
--- a/epf_prac_151/practice.mgmt.release_planning.base/guidances/termdefinitions/project_burndown.xmi
+++ b/epf_prac_151/practice.mgmt.release_planning.base/guidances/termdefinitions/project_burndown.xmi
@@ -1,8 +1,8 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-NNByAM5YsjCu39flaOSZtQ" name=",_eX0YsEvvEdunZcj9T5hrMQ" guid="-NNByAM5YsjCu39flaOSZtQ" changeDate="2008-07-15T11:45:34.000-0700" version="7.2.0">
- <mainDescription><p>
- A&nbsp;primary report for understanding the status of&nbsp;a project. It typically consists of&nbsp;a
- chart&nbsp;showing&nbsp;the iterations in the horizontal axis and the remaining points from the work items list in the
- vertical axis.
+ <mainDescription><p>
+ A&nbsp;primary report for understanding the status of&nbsp;a project. It typically consists of&nbsp;a
+ chart&nbsp;showing&nbsp;the iterations in the horizontal axis and the remaining points from the work items list in the
+ vertical axis.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.release_planning.base/tasks/plan_the_project.xmi b/epf_prac_151/practice.mgmt.release_planning.base/tasks/plan_the_project.xmi
index e1db237..34fa25b 100644
--- a/epf_prac_151/practice.mgmt.release_planning.base/tasks/plan_the_project.xmi
+++ b/epf_prac_151/practice.mgmt.release_planning.base/tasks/plan_the_project.xmi
@@ -1,18 +1,18 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:TaskDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_fPbdIKe2Edmzde8VFK5bxg" name="plan_the_project,_0lC70MlgEdmt3adZL5Dmdw" guid="_fPbdIKe2Edmzde8VFK5bxg" changeDate="2008-07-14T01:50:23.000-0700" version="1.0.0">
- <mainDescription>Developing the project plan provides an opportunity for the team to agree on project scope, objectives, initial timeframe,
-and deliverables. It allows the team to begin demonstrating self-organization by defining success criteria and work
-practices to be used. Collaboration and consensus by all key project participants is the goal, but the role responsible for
+ <mainDescription>Developing the project plan provides an opportunity for the team to agree on project scope, objectives, initial timeframe,
+and deliverables. It allows the team to begin demonstrating self-organization by defining success criteria and work
+practices to be used. Collaboration and consensus by all key project participants is the goal, but the role responsible for
this task must ensure that everybody is committed to the plan.</mainDescription>
- <keyConsiderations><p>
- Gain agreement with stakeholders and the rest of the project team regarding the order of objectives and the duration of
- the project. Make adjustments as&nbsp;necessary.
+ <keyConsiderations><p>
+ Gain agreement with stakeholders and the rest of the project team regarding the order of objectives and the duration of
+ the project. Make adjustments as&nbsp;necessary.
</p></keyConsiderations>
<sections xmi:id="_gu-PgIyBEdyhZb-MhCJrlA" name="Identify a cohesive team" guid="_gu-PgIyBEdyhZb-MhCJrlA">
<sectionDescription>Revisit the resourcing for the project.&nbsp;Identify gaps and initiate hiring or re-allocation of resources as needed.
Discuss with the team who plays which roles, and have them agree on their responsibilities.</sectionDescription>
</sections>
- <sections xmi:id="_jknm8IyBEdyhZb-MhCJrlA" name="Estimate project size " guid="_jknm8IyBEdyhZb-MhCJrlA">
+ <sections xmi:id="_jknm8IyBEdyhZb-MhCJrlA" name="Estimate project size" guid="_jknm8IyBEdyhZb-MhCJrlA">
<sectionDescription><p>
The&nbsp;team produces rough size estimates for each work item&nbsp;found in the <a class="elementLink"
href="./../../core.mgmt.slot.base/workproducts/project_work_slot_F12BAC46.html" guid="_1QZI8EfUEdyiPI8btkmvmw">[Project
@@ -87,10 +87,10 @@
</p>
<p>
Capture the objectives for deployment and release dates in the <a class="elementLink"
- href="./../../practice.mgmt.two_level_project_planning.base/workproducts/project_plan_1CDBB7E4.html"
+ href="./../../practice.mgmt.release_planning.base/workproducts/project_plan_1CDBB7E4.html"
guid="_0a6vcMlgEdmt3adZL5Dmdw">Project Plan</a>.
</p></sectionDescription>
</sections>
- <purpose>Get stakeholder buy-in for starting the project and team commitment to move forward with it. This plan can be updated as
+ <purpose>Get stakeholder buy-in for starting the project and team commitment to move forward with it. This plan can be updated as
the project progresses based on feedback and changes in the environment.</purpose>
</org.eclipse.epf.uma:TaskDescription>
diff --git a/epf_prac_151/practice.mgmt.release_planning.base/workproducts/project_plan.xmi b/epf_prac_151/practice.mgmt.release_planning.base/workproducts/project_plan.xmi
index 28e3252..d2227cf 100644
--- a/epf_prac_151/practice.mgmt.release_planning.base/workproducts/project_plan.xmi
+++ b/epf_prac_151/practice.mgmt.release_planning.base/workproducts/project_plan.xmi
@@ -1,21 +1,21 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ArtifactDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_IbVp8KX4EdmvhNXG0Oc2uA" name="project_plan,_0a6vcMlgEdmt3adZL5Dmdw" guid="_IbVp8KX4EdmvhNXG0Oc2uA" changeDate="2009-11-23T06:59:45.000-0800" version="1.0.0">
- <mainDescription><p>
- This artifact describes how the project is organized, and identifies what practices will be followed. Additionally, it
- defines the parameters for tracking project progress, and specifies the high-level objectives of the iterations and
- their milestones.
-</p>
-<p>
- The project plan allows stakeholders and other team members to understand the big picture and, roughly, when to expect
- a certain level of functionality be available.&nbsp;Update the plan&nbsp;as often as necessary, usually at the end of
- each iteration, in order to reflect changing priorities and needs, as well as record the lessons learned from the
- project.
+ <mainDescription><p>
+ This artifact describes how the project is organized, and identifies what practices will be followed. Additionally, it
+ defines the parameters for tracking project progress, and specifies the high-level objectives of the iterations and
+ their milestones.
+</p>
+<p>
+ The project plan allows stakeholders and other team members to understand the big picture and, roughly, when to expect
+ a certain level of functionality be available.&nbsp;Update the plan&nbsp;as often as necessary, usually at the end of
+ each iteration, in order to reflect changing priorities and needs, as well as record the lessons learned from the
+ project.
</p></mainDescription>
- <keyConsiderations>Create and update the project plan in planning sessions that involve the whole team and appropriate project stakeholders in
+ <keyConsiderations>Create and update the project plan in planning sessions that involve the whole team and appropriate project stakeholders in
order to make sure that everybody agrees with it.</keyConsiderations>
- <purpose><p>
- The purpose of this artifact is&nbsp;to provide a central document where any project team member can find the
- information on how the project will be conducted.&nbsp;
+ <purpose><p>
+ The purpose of this artifact is&nbsp;to provide a central document where any project team member can find the
+ information on how the project will be conducted.&nbsp;
</p></purpose>
<impactOfNotHaving>Without this artifact, there can be a lack of clear boundaries of the project scope that can lead to: 
<ul>
diff --git a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/capabilitypatterns/risk_value_lifecycle_phases/content.xmi b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/capabilitypatterns/risk_value_lifecycle_phases/content.xmi
index c9c9c79..17a1372 100644
--- a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/capabilitypatterns/risk_value_lifecycle_phases/content.xmi
+++ b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/capabilitypatterns/risk_value_lifecycle_phases/content.xmi
@@ -1,47 +1,47 @@
<?xml version="1.0" encoding="UTF-8"?>
<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1">
<org.eclipse.epf.uma:ActivityDescription xmi:id="-Uq-ecMy01nzV6sLsXMJ1ow" name="Inception Phase,_-UFkUVThEd2ZeY-22kx0mw" guid="-Uq-ecMy01nzV6sLsXMJ1ow">
- <mainDescription>For more on this phase, see <a class="elementLink"
-href="./../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/inception_phase_C4456871.html"
+ <mainDescription>For more on this phase, see <a class="elementLink"
+href="./../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/inception_phase_C4456871.html"
guid="_0hmKgBOMEduCNqgZdt_OaA">Inception Phase</a>.</mainDescription>
</org.eclipse.epf.uma:ActivityDescription>
<org.eclipse.epf.uma:ActivityDescription xmi:id="-2OtVEeOzetzCgwp0Rgr4Yw" name="Elaboration Phase,_2_nRIVThEd2ZeY-22kx0mw" guid="-2OtVEeOzetzCgwp0Rgr4Yw">
- <mainDescription>For more on this phase, see <a class="elementLink"
-href="./../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/elaboration_phase_BE880435.html"
+ <mainDescription>For more on this phase, see <a class="elementLink"
+href="./../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/elaboration_phase_BE880435.html"
guid="_2plxwBOMEduCNqgZdt_OaA">Elaboration Phase</a>.</mainDescription>
</org.eclipse.epf.uma:ActivityDescription>
<org.eclipse.epf.uma:ActivityDescription xmi:id="-6PEqL-4C0ngDnSot7_JayA" name="Construction Phase,__r658VThEd2ZeY-22kx0mw" guid="-6PEqL-4C0ngDnSot7_JayA">
- <mainDescription>For more on this phase, see <a class="elementLink"
-href="./../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/construction_phase_873B6559.html"
+ <mainDescription>For more on this phase, see <a class="elementLink"
+href="./../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/construction_phase_873B6559.html"
guid="_48EKsBOMEduCNqgZdt_OaA">Construction Phase</a>.</mainDescription>
</org.eclipse.epf.uma:ActivityDescription>
<org.eclipse.epf.uma:ActivityDescription xmi:id="-qs6M0AwWCTfjqB3am3SE9A" name="Transition Phase,_BBN48VTiEd2ZeY-22kx0mw" guid="-qs6M0AwWCTfjqB3am3SE9A">
- <mainDescription>For more on this phase, see <a class="elementLink"
-href="./../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/transition_phase_DD5986E5.html"
+ <mainDescription>For more on this phase, see <a class="elementLink"
+href="./../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/transition_phase_DD5986E5.html"
guid="__ca5UBOMEduCNqgZdt_OaA">Transition Phase</a>.</mainDescription>
</org.eclipse.epf.uma:ActivityDescription>
<org.eclipse.epf.uma:ProcessDescription xmi:id="-1IlTGK1mPdoxAMwuAjqLYg" name="ris_value_lifecycle_phases,_FzchseL7EdyM47cGD2jiaQ" guid="-1IlTGK1mPdoxAMwuAjqLYg" version="7.2.0">
- <mainDescription><p>
- This capability pattern illustrates an iterative process with the organization of iterations distributed throughout
- four phases: <a class="elementLinkwithUserText"
- href="./../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/inception_phase_C4456871.html"
- guid="_0hmKgBOMEduCNqgZdt_OaA">Inception</a>, <a class="elementLinkwithUserText"
- href="./../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/elaboration_phase_BE880435.html"
- guid="_2plxwBOMEduCNqgZdt_OaA">Elaboration</a>, <a class="elementLinkwithUserText"
- href="./../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/construction_phase_873B6559.html"
- guid="_48EKsBOMEduCNqgZdt_OaA">Construction</a>, and <a class="elementLinkwithUserText"
- href="./../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/transition_phase_DD5986E5.html"
- guid="__ca5UBOMEduCNqgZdt_OaA">Transition</a>.
-</p>
-<p>
- Each phase contains one or more iterations.&nbsp;After the last iteration of a phase is performed, there is a milestone
- that provides the questions that check whether the objectives of that phase were met or not, thereby giving
- stakeholders and management the opportunity to make business decisions about whether the project should continue to the
- next phase or not.
+ <mainDescription><p>
+ This capability pattern illustrates an iterative process with the organization of iterations distributed throughout
+ four phases: <a class="elementLinkwithUserText"
+ href="./../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/inception_phase_C4456871.html"
+ guid="_0hmKgBOMEduCNqgZdt_OaA">Inception</a>, <a class="elementLinkwithUserText"
+ href="./../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/elaboration_phase_BE880435.html"
+ guid="_2plxwBOMEduCNqgZdt_OaA">Elaboration</a>, <a class="elementLinkwithUserText"
+ href="./../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/construction_phase_873B6559.html"
+ guid="_48EKsBOMEduCNqgZdt_OaA">Construction</a>, and <a class="elementLinkwithUserText"
+ href="./../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/transition_phase_DD5986E5.html"
+ guid="__ca5UBOMEduCNqgZdt_OaA">Transition</a>.
+</p>
+<p>
+ Each phase contains one or more iterations.&nbsp;After the last iteration of a phase is performed, there is a milestone
+ that provides the questions that check whether the objectives of that phase were met or not, thereby giving
+ stakeholders and management the opportunity to make business decisions about whether the project should continue to the
+ next phase or not.
</p></mainDescription>
- <usageNotes><p>
- This capability pattern is a template that can be used&nbsp;to assemble an end-to-end delivery process,&nbsp;which
- includes specific activities and tasks&nbsp;to be performed in each&nbsp;iteration.
+ <usageNotes><p>
+ This capability pattern is a template that can be used&nbsp;to assemble an end-to-end delivery process,&nbsp;which
+ includes specific activities and tasks&nbsp;to be performed in each&nbsp;iteration.
</p></usageNotes>
</org.eclipse.epf.uma:ProcessDescription>
</xmi:XMI>
diff --git a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/capabilitypatterns/risk_value_lifecycle_phases/model.xmi b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/capabilitypatterns/risk_value_lifecycle_phases/model.xmi
index 922eec0..5ae682a 100644
--- a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/capabilitypatterns/risk_value_lifecycle_phases/model.xmi
+++ b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/capabilitypatterns/risk_value_lifecycle_phases/model.xmi
@@ -1,5 +1,5 @@
<?xml version="1.0" encoding="UTF-8"?>
-<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1">
+<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1">
<org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="__CvCULekEd-D7YZN9NgldQ" guid="__CvCULekEd-D7YZN9NgldQ">
<resourceDescriptors xmi:id="__CvCUbekEd-D7YZN9NgldQ" id="-Uq-ecMy01nzV6sLsXMJ1ow" uri="content.xmi"/>
<resourceDescriptors xmi:id="__CvCUrekEd-D7YZN9NgldQ" id="-2OtVEeOzetzCgwp0Rgr4Yw" uri="content.xmi"/>
@@ -47,7 +47,7 @@
<processElements xsi:type="org.eclipse.epf.uma:Iteration" xmi:id="_SKnAxOL9EdyM47cGD2jiaQ" name="transition_iteration" guid="_SKnAxOL9EdyM47cGD2jiaQ" presentationName="Transition Iteration [1..n]" briefDescription="This is a placeholder for a typical Transition phase iteration. It provides a place to include the activities typically performed during a single iteration in the Transition phase." superActivities="_BBN48VTiEd2ZeY-22kx0mw" isRepeatable="true" linkToPredecessor="_ztFT8FTiEd2ZeY-22kx0mw"/>
<processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_ztFT8FTiEd2ZeY-22kx0mw" guid="_ztFT8FTiEd2ZeY-22kx0mw" pred="_ePfxAFTiEd2ZeY-22kx0mw"/>
</childPackages>
- <processElements xsi:type="org.eclipse.epf.uma:Phase" xmi:id="_BBN48VTiEd2ZeY-22kx0mw" name="transition_phase" guid="_BBN48VTiEd2ZeY-22kx0mw" presentationName="Transition Phase" briefDescription="The focus of the Transition Phase is to ensure that software is available for its end users. " superActivities="_SKnA1uL9EdyM47cGD2jiaQ" linkToPredecessor="_EUZEcVTjEd2ZeY-22kx0mw" breakdownElements="_SKnAxOL9EdyM47cGD2jiaQ _nm0swFTiEd2ZeY-22kx0mw">
+ <processElements xsi:type="org.eclipse.epf.uma:Phase" xmi:id="_BBN48VTiEd2ZeY-22kx0mw" name="transition_phase" guid="_BBN48VTiEd2ZeY-22kx0mw" presentationName="Transition Phase" briefDescription="The focus of the Transition Phase is to ensure that software is available for its end users." superActivities="_SKnA1uL9EdyM47cGD2jiaQ" linkToPredecessor="_EUZEcVTjEd2ZeY-22kx0mw" breakdownElements="_SKnAxOL9EdyM47cGD2jiaQ _nm0swFTiEd2ZeY-22kx0mw">
<presentation xmi:id="-qs6M0AwWCTfjqB3am3SE9A" href="uma://-Uq-ecMy01nzV6sLsXMJ1ow#-qs6M0AwWCTfjqB3am3SE9A"/>
</processElements>
<processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_EUZEcVTjEd2ZeY-22kx0mw" guid="_EUZEcVTjEd2ZeY-22kx0mw" pred="__r658VThEd2ZeY-22kx0mw"/>
diff --git a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/concepts/construction_phase.xmi b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/concepts/construction_phase.xmi
index 960bef8..db81f96 100644
--- a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/concepts/construction_phase.xmi
+++ b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/concepts/construction_phase.xmi
@@ -1,40 +1,44 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-bbpT_BdDRrv6waNI365Qhg" name=",_48EKsBOMEduCNqgZdt_OaA" guid="-bbpT_BdDRrv6waNI365Qhg" changeDate="2008-02-24T08:12:12.000-0800" version="1.0.0">
- <mainDescription><p>
- The purpose in this phase is to complete the development of the system based upon the baselined architecture.
-</p>
-<p> There are objectives for the Construction phase that help us to&nbsp;have
- cost-efficient development of a complete product -- an operational version of
- your system -- that can be deployed&nbsp;in the user community&nbsp;<a class="elementlinkwithusertext" href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#KRO03" guid="_JlTPUM6aEdyuBO4ZIzcyig">[KRO03]</a>:
-</p>
-<ol>
-
- <li> Iteratively develop a complete product that is ready to transition to its
- user community. Describe remaining requirements, fill in design details, complete
- the implementation, and test the software. Release the first operational version
- (beta) of the system and determine whether users are ready for the application
- to be deployed. </li>
-
- <li> Minimize development costs and achieve some degree of parallelism. Optimize
- resources and leverage development parallelism between developers or teams
- of developers by, for example, assigning components that can be developed
- independently of one another. </li>
-</ol>
-<h4>
- Key considerations
-</h4>
-<p>
- Typically, the Construction phase has more iterations (two to four) than the other phases, depending on the types of
- projects:
-</p>
-<ul>
-
- <li> <b>Simple project: </b>One iteration to build the product (to a beta release)
- </li>
-
- <li><b> More substantial project: </b>One iteration to expose a partial system
- and one to mature it to beta testing </li>
- <li><b> Large project: </b>Three or more iterations, depending upon the size
- of the project (number of requirements to implement for a beta release) </li>
+ <mainDescription><p>
+ The purpose in this phase is to complete the development of the system based upon the baselined architecture.
+</p>
+<p>
+ There are objectives for the Construction phase that help us to&nbsp;have cost-efficient development of a complete
+ product -- an operational version of your system -- that can be deployed&nbsp;in the user community&nbsp;<a
+ class="elementlinkwithusertext"
+ href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#KRO03"
+ guid="_JlTPUM6aEdyuBO4ZIzcyig">[KRO03]</a>:
+</p>
+<ol>
+ <li>
+ Iteratively develop a complete product that is ready to transition to its user community. Describe remaining
+ requirements, fill in design details, complete the implementation, and test the software. Release the first
+ operational version (beta) of the system and determine whether users are ready for the application to be deployed.
+ </li>
+ <li>
+ Minimize development costs and achieve some degree of parallelism. Optimize resources and leverage development
+ parallelism between developers or teams of developers by, for example, assigning components that can be developed
+ independently of one another.
+ </li>
+</ol>
+<h4>
+ Key considerations
+</h4>
+<p>
+ Typically, the Construction phase has more iterations (two to four) than the other phases, depending on the types of
+ projects:
+</p>
+<ul>
+ <li>
+ <b>Simple project:</b> One iteration to build the product (to a beta release)
+ </li>
+ <li>
+ <b>More substantial project:</b> One iteration to expose a partial system and one to mature it to beta testing
+ </li>
+ <li>
+ <b>Large project:</b> Three or more iterations, depending upon the size of the project (number of requirements to
+ implement for a beta release)
+ </li>
</ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/concepts/elaboration_phase.xmi b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/concepts/elaboration_phase.xmi
index f248010..02f3596 100644
--- a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/concepts/elaboration_phase.xmi
+++ b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/concepts/elaboration_phase.xmi
@@ -1,59 +1,63 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-F-eWIBzxEXE1jygbN3nrrQ" name=",_2plxwBOMEduCNqgZdt_OaA" guid="-F-eWIBzxEXE1jygbN3nrrQ" changeDate="2008-02-24T08:14:58.000-0800" version="1.0.0">
- <mainDescription><p>
- The purpose of this phase is to establish the baseline of the architecture of the system and provide a stable basis for
- the bulk of the&nbsp;development effort in the next phase.
-</p>
-<p>
- There are objectives for the Elaboration phase that help you address risks associated with requirements, architecture,
- costs, and schedule <a class="elementlinkwithusertext" href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#KRO03" guid="_JlTPUM6aEdyuBO4ZIzcyig">[KRO03]</a>:
-</p>
-<ul>
- <li>
-
- <p> <strong>Get a more detailed understanding of the requirements.</strong>
- Having a good understanding of the majority of requirements enables you
- to create a more detailed plan and to get buy-in from stakeholders. Be sure
- to gain an in-depth understanding of the most critical requirements to be
- validated by&nbsp;the architecture. </p>
- </li>
- <li>
-
- <p> <strong>Design, implement, validate, and establish the baseline for the
- architecture.</strong> Design, implement, and test a skeleton structure
- of the system. Although the functionality is not complete yet, most of the
- interfaces between the building blocks are implemented and tested. This
- is referred to<i> an</i><strong> </strong><i>executable architecture</i>.
- </p>
- </li>
- <li>
- <p>
- <strong>Mitigate essential risks, and produce accurate schedule and cost estimates.</strong> Many technical
- risks are addressed as a result of detailing the requirements and of designing, implementing, and testing the
- architecture. Refine and detail the high-level project plan.
- </p>
- </li>
-</ul>
-<h4>
- Key considerations
-</h4>
-<p> The number of iterations in the Elaboration phase is dependent on, but not
- limited to, factors such as green-field development compared to maintenance
- cycle, unprecedented system compared to well-known technology and architecture,
- and so on. </p>
-<p> Typically, on the first iteration, it is better to design, implement, and
- test a small number of critical scenarios to identify what type of architecture
- and architectural mechanisms you need, so you can mitigate the most crucial
- risks. You also detail high-risk requirements that have to be addressed early
- in the project. You test enough to validate that the architectural risks are
- mitigated. </p>
-<p> During the subsequent iterations, you fix whatever was not right from the
- previous iteration. You design, implement, and test the remaining architecturally
- significant scenarios, ensuring that you check all major areas of the system
- (architectural coverage), so that potential risks are identified as early as
- possible. <a class="elementlinkwithusertext" href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html" guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>
-</p>
-<p>
- <br />
+ <mainDescription><p>
+ The purpose of this phase is to establish the baseline of the architecture of the system and provide a stable basis for
+ the bulk of the&nbsp;development effort in the next phase.
+</p>
+<p>
+ There are objectives for the Elaboration phase that help you address risks associated with requirements, architecture,
+ costs, and schedule <a class="elementlinkwithusertext"
+ href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#KRO03"
+ guid="_JlTPUM6aEdyuBO4ZIzcyig">[KRO03]</a>:
+</p>
+<ul>
+ <li>
+ <p>
+ <strong>Get a more detailed understanding of the requirements.</strong> Having a good understanding of the
+ majority of requirements enables you to create a more detailed plan and to get buy-in from stakeholders. Be
+ sure to gain an in-depth understanding of the most critical requirements to be validated by&nbsp;the
+ architecture.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Design, implement, validate, and establish the baseline for the architecture.</strong> Design,
+ implement, and test a skeleton structure of the system. Although the functionality is not complete yet, most of
+ the interfaces between the building blocks are implemented and tested. This is referred to <i>an</i>
+ <i>executable architecture</i>.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Mitigate essential risks, and produce accurate schedule and cost estimates.</strong> Many technical
+ risks are addressed as a result of detailing the requirements and of designing, implementing, and testing the
+ architecture. Refine and detail the high-level project plan.
+ </p>
+ </li>
+</ul>
+<h4>
+ Key considerations
+</h4>
+<p>
+ The number of iterations in the Elaboration phase is dependent on, but not limited to, factors such as green-field
+ development compared to maintenance cycle, unprecedented system compared to well-known technology and architecture, and
+ so on.
+</p>
+<p>
+ Typically, on the first iteration, it is better to design, implement, and test a small number of critical scenarios to
+ identify what type of architecture and architectural mechanisms you need, so you can mitigate the most crucial risks.
+ You also detail high-risk requirements that have to be addressed early in the project. You test enough to validate that
+ the architectural risks are mitigated.
+</p>
+<p>
+ During the subsequent iterations, you fix whatever was not right from the previous iteration. You design, implement,
+ and test the remaining architecturally significant scenarios, ensuring that you check all major areas of the system
+ (architectural coverage), so that potential risks are identified as early as possible. <a
+ class="elementlinkwithusertext"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[KRO03]</a>
+</p>
+<p>
+ <br />
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/concepts/inception_phase.xmi b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/concepts/inception_phase.xmi
index ed2589b..754096e 100644
--- a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/concepts/inception_phase.xmi
+++ b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/concepts/inception_phase.xmi
@@ -1,58 +1,66 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-GRJW_KNOJoEQF3r6lmBrEw" name=",_0hmKgBOMEduCNqgZdt_OaA" guid="-GRJW_KNOJoEQF3r6lmBrEw" changeDate="2008-07-11T10:14:27.000-0700" version="1.0.0">
- <mainDescription><p>
- The purpose in this phase is to achieve concurrence among all stakeholders on the lifecycle objectives for the project.
-</p>
-<p>
- There are four objectives of the Inception phase that clarify the scope, project objectives, and feasibility of the
- intended solution <a class="elementlinkwithusertext" href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#KRO03" guid="_JlTPUM6aEdyuBO4ZIzcyig">[KRO03]</a>:
-</p>
-<ol>
- <li>
-
- <p> <strong>Understand what to build.</strong> Determine an overall vision,
- including the scope of the system and its boundaries. Identify the stakeholders:
- who is interested in this system and what are their success criteria?</p>
- </li>
- <li>
- <p>
- <strong>Identify key system functionality.</strong> Decide which requirements are most critical.
- </p>
- </li>
- <li>
-
- <p> <strong>Determine at least one possible solution.</strong> Assess whether
- the vision is technically feasible.&nbsp;This may involve identifying a
- candidate high-level architecture or doing technical prototypes, or both.</p>
- </li>
- <li>
- <p>
- <strong>Understand</strong> the high-level estimate for cost, schedule, and risks associated with the project.
- </p>
- </li>
-</ol>
-<h4>
- Key considerations
-</h4>
-<p> Projects may have one or more iterations in the Inception phase. These are
- among the reasons for multiple iterations: </p>
-<ul>
-
- <li> Project is large, and it is hard to define its scope</li>
-
- <li> Unprecedented system</li>
-
- <li> Too many stakeholders with competing needs and complex relationships</li>
-
- <li> Major technical risks demand the creation of a prototype or proof of concept</li>
-</ul>
-<p> There are some commonly observed&nbsp;counterproductive patterns during the
- Inception phase. Some teams postpone providing estimates until they analyze
- the entire domain and have written a large amount of requirements documentation.
- This behavior often leads to &quot;analysis paralysis.&quot; Another pattern
- is poor planning of Inception iterations. Avoid such patterns by planning iterations
- during Inception in a way that iterations are risk-driven, include early integration
- and testing, and produce a product increment that you can demonstrate to stakeholders.
- By default, have one (potentially short) iteration in Inception to avoid analysis
- paralysis. </p></mainDescription>
+ <mainDescription><p>
+ The purpose in this phase is to achieve concurrence among all stakeholders on the lifecycle objectives for the project.
+</p>
+<p>
+ There are four objectives of the Inception phase that clarify the scope, project objectives, and feasibility of the
+ intended solution <a class="elementlinkwithusertext"
+ href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#KRO03"
+ guid="_JlTPUM6aEdyuBO4ZIzcyig">[KRO03]</a>:
+</p>
+<ol>
+ <li>
+ <p>
+ <strong>Understand what to build.</strong> Determine an overall vision, including the scope of the system and
+ its boundaries. Identify the stakeholders: who is interested in this system and what are their success
+ criteria?
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Identify key system functionality.</strong> Decide which requirements are most critical.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Determine at least one possible solution.</strong> Assess whether the vision is technically
+ feasible.&nbsp;This may involve identifying a candidate high-level architecture or doing technical prototypes,
+ or both.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Understand</strong> the high-level estimate for cost, schedule, and risks associated with the project.
+ </p>
+ </li>
+</ol>
+<h4>
+ Key considerations
+</h4>
+<p>
+ Projects may have one or more iterations in the Inception phase. These are among the reasons for multiple iterations:
+</p>
+<ul>
+ <li>
+ Project is large, and it is hard to define its scope
+ </li>
+ <li>
+ Unprecedented system
+ </li>
+ <li>
+ Too many stakeholders with competing needs and complex relationships
+ </li>
+ <li>
+ Major technical risks demand the creation of a prototype or proof of concept
+ </li>
+</ul>
+<p>
+ There are some commonly observed&nbsp;counterproductive patterns during the Inception phase. Some teams postpone
+ providing estimates until they analyze the entire domain and have written a large amount of requirements documentation.
+ This behavior often leads to "analysis paralysis." Another pattern is poor planning of Inception iterations. Avoid such
+ patterns by planning iterations during Inception in a way that iterations are risk-driven, include early integration
+ and testing, and produce a product increment that you can demonstrate to stakeholders. By default, have one
+ (potentially short) iteration in Inception to avoid analysis paralysis.
+</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/concepts/phase_milestones.xmi b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/concepts/phase_milestones.xmi
index 7d497bd..fc6676e 100644
--- a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/concepts/phase_milestones.xmi
+++ b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/concepts/phase_milestones.xmi
@@ -1,42 +1,59 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-DG8mYMnTGosWIxjPQFUoTA" name="milestones,_HNxbwMBJEdqSgKaj2SZBmg" guid="-DG8mYMnTGosWIxjPQFUoTA" changeDate="2008-02-11T01:56:57.000-0800" version="7.2.0">
- <mainDescription><p>
- From a&nbsp;development perspective, each iteration provides an increment of functionality to the product. Thus, the
- end of each iteration corresponds to a checkpoint where the project team demonstrates to stakeholders that the
- objectives for that iteration have been met.
-</p>
-<p> From a management perspective, the software lifecycle&nbsp;is decomposed over
- time into four sequential phases, each concluded by a major milestone [<a class="elementLinkWithUserText" href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#BOE95" guid="_JlTPUM6aEdyuBO4ZIzcyig">BOE95</a>].
- There are four major milestones that provide evaluation criteria at the end
- of each phase:</p>
-<p><b>The phases and milestones of a projec</b>t <br />
- <img height="156" alt="Click on text for more information about phases and milestones" src="resources/co_phas1.gif" width="406" border="0" /></p>
-<p> Each phase is&nbsp;a span of time between two major milestones and has specific
- focus and objectives. At the end of each phase, an assessment is performed to
- determine whether the objectives of the phase have been met. A satisfactory
- assessment allows the project to move to the next phase. When a milestone is
- not met, more iterations in the current phase may be performed before the milestone
- can be considered complete. Achieving a milestone represents an objective criteria
- with which to measure progress. </p>
-<p> At the end of the <a class="elementLink" href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/inception_phase_C4456871.html" guid="_0hmKgBOMEduCNqgZdt_OaA">Inception Phase</a> is the first major project milestone, or <strong>Lifecycle Objectives
- Milestone</strong>. At this point, you examine the cost versus benefit of the
- project and decide either to proceed with the project or to cancel it. </p>
-<p>
- At the end of the <a class="elementLink" href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/elaboration_phase_BE880435.html" guid="_2plxwBOMEduCNqgZdt_OaA">Elaboration Phase</a>&nbsp;is the second important project milestone, the
- <strong>Lifecycle Architecture Milestone</strong>. At this point, a baseline of requirements is agreed to, you examine
- the detailed system objectives and scope, the choice of architecture, and the resolution of the major risks. The
- milestone is achieved when the architecture has been validated.
-</p>
-<p>
- At the end of the <a class="elementLink" href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/construction_phase_873B6559.html" guid="_48EKsBOMEduCNqgZdt_OaA">Construction Phase</a><strong>&nbsp;</strong>is the third important project milestone,
- the <strong>Initial Operational Capability Milestone</strong>. At this point, the product is ready to be handed over to
- the transition team. All functionality has been developed and all alpha testing (if any) has been completed. In
- addition to the software, a user manual has been developed, and there is a description of the current release. The
- product is ready for beta testing.
-</p>
-<p> At the end of the <a class="elementLink" href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/transition_phase_DD5986E5.html" guid="__ca5UBOMEduCNqgZdt_OaA">Transition Phase</a><strong>&nbsp;</strong>is the fourth important project milestone, the
- <strong>Product Release Milestone</strong>. At this point, you decide if the
- objectives were met and whether you should start another development cycle.
- The Product Release Milestone is the result of the customer reviewing and accepting
- the project deliverables. </p></mainDescription>
+ <mainDescription><p>
+ From a&nbsp;development perspective, each iteration provides an increment of functionality to the product. Thus, the
+ end of each iteration corresponds to a checkpoint where the project team demonstrates to stakeholders that the
+ objectives for that iteration have been met.
+</p>
+<p>
+ From a management perspective, the software lifecycle&nbsp;is decomposed over time into four sequential phases, each
+ concluded by a major milestone [<a class="elementLinkWithUserText"
+ href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#BOE95"
+ guid="_JlTPUM6aEdyuBO4ZIzcyig">BOE95</a>]. There are four major milestones that provide evaluation criteria at the end
+ of each phase:
+</p>
+<p>
+ <b>The phases and milestones of a projec</b>t<br />
+ <img height="156" alt="Click on text for more information about phases and milestones" src="resources/co_phas1.gif"
+ width="406" border="0" />
+</p>
+<p>
+ Each phase is&nbsp;a span of time between two major milestones and has specific focus and objectives. At the end of
+ each phase, an assessment is performed to determine whether the objectives of the phase have been met. A satisfactory
+ assessment allows the project to move to the next phase. When a milestone is not met, more iterations in the current
+ phase may be performed before the milestone can be considered complete. Achieving a milestone represents an objective
+ criteria with which to measure progress.
+</p>
+<p>
+ At the end of the <a class="elementLink"
+ href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/inception_phase_C4456871.html"
+ guid="_0hmKgBOMEduCNqgZdt_OaA">Inception Phase</a> is the first major project milestone, or <strong>Lifecycle
+ Objectives Milestone</strong>. At this point, you examine the cost versus benefit of the project and decide either to
+ proceed with the project or to cancel it.
+</p>
+<p>
+ At the end of the <a class="elementLink"
+ href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/elaboration_phase_BE880435.html"
+ guid="_2plxwBOMEduCNqgZdt_OaA">Elaboration Phase</a>&nbsp;is the second important project milestone, the
+ <strong>Lifecycle Architecture Milestone</strong>. At this point, a baseline of requirements is agreed to, you examine
+ the detailed system objectives and scope, the choice of architecture, and the resolution of the major risks. The
+ milestone is achieved when the architecture has been validated.
+</p>
+<p>
+ At the end of the <a class="elementLink"
+ href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/construction_phase_873B6559.html"
+ guid="_48EKsBOMEduCNqgZdt_OaA">Construction Phase</a><strong>&nbsp;</strong>is the third important project milestone,
+ the <strong>Initial Operational Capability Milestone</strong>. At this point, the product is ready to be handed over to
+ the transition team. All functionality has been developed and all alpha testing (if any) has been completed. In
+ addition to the software, a user manual has been developed, and there is a description of the current release. The
+ product is ready for beta testing.
+</p>
+<p>
+ At the end of the <a class="elementLink"
+ href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/transition_phase_DD5986E5.html"
+ guid="__ca5UBOMEduCNqgZdt_OaA">Transition Phase</a><strong>&nbsp;</strong>is the fourth important project milestone,
+ the <strong>Product Release Milestone</strong>. At this point, you decide if the objectives were met and whether you
+ should start another development cycle. The Product Release Milestone is the result of the customer reviewing and
+ accepting the project deliverables.
+</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/concepts/project_lifecycle.xmi b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/concepts/project_lifecycle.xmi
index 25b2d42..7a36266 100644
--- a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/concepts/project_lifecycle.xmi
+++ b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/concepts/project_lifecycle.xmi
@@ -1,88 +1,88 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-ebKPqn9bWfbh1K2spgOwWQ" name="project_lifecycle,_nSfVwCNYEdyCq8v2ZO4QcA" guid="-ebKPqn9bWfbh1K2spgOwWQ" changeDate="2010-05-10T09:11:56.000-0700" version="7.2.0">
- <mainDescription><h3>
- Overview
-</h3>
-<p>
- Although the entire purpose of a project is to produce a product, the specific goals of the team will vary
- substantially throughout the project. In the beginning, there usually is considerable latitude in the requirements for
- the product. It may not be clear whether the project is feasible or even if it is likely to be profitable. At that
- time, it is critical to bring an answer to these questions and of little to no value to start developing the product in
- earnest.&nbsp;Toward the end of the project, the product itself is usually complete, and issues of quality, delivery,
- and completeness then take center stage. At different points in time, tasks are undertaken in new ways and work
- products will have new content.
-</p>
-<p>
- To coordinate the team's efforts in a manner that takes these fundamental observations into account, the project
- lifecycle should be divided into a sequence of phases. Each phase has a defined set of goals, a particular iteration
- style, and customized&nbsp; <a class="elementLinkWithUserText"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html"
- guid="_x459ktnmEdmO6L4XMImrsA">tasks</a>&nbsp;and&nbsp;<a class="elementLinkWithUserText"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
- guid="_H4JXwB_SEdq6CKKKq4D7YA">work products</a> to address the unique needs of the project at that point. The project
- lifecycle provides <em>stakeholders</em> with oversight, transparency, and steering mechanisms to control project
- funding, scope, risk exposure, value provided, and other aspects of the process.
-</p>
-<p>
- It helps to organize iterations into phases. Each phase ends with a milestone aimed at providing oversight by raising
- and answering a set of questions that are typically critical to stakeholders:
-</p>
-<ul>
- <li>
- <a class="elementLinkWithUserText"
- href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/inception_phase_C4456871.html"
- guid="_0hmKgBOMEduCNqgZdt_OaA">Inception</a>. Do we agree on project scope and objectives and whether or not the
- project should proceed?
- </li>
- <li>
- <a class="elementLinkWithUserText"
- href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/elaboration_phase_BE880435.html"
- guid="_2plxwBOMEduCNqgZdt_OaA">Elaboration</a>. Do we agree on the executable architecture to be used for
- developing the application, and do we find that the value delivered so far and the remaining risk is acceptable?
- </li>
- <li>
- <a class="elementLinkWithUserText"
- href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/construction_phase_873B6559.html"
- guid="_48EKsBOMEduCNqgZdt_OaA">Construction</a>. Do we find that we have an application that is sufficiently close
- to being released that we should switch the primary focus of the team to tuning, polishing, and ensuring successful
- deployment?
- </li>
- <li>
- <a class="elementLinkWithUserText"
- href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/transition_phase_DD5986E5.html"
- guid="__ca5UBOMEduCNqgZdt_OaA">Transition</a>. Is the application ready to release?
- </li>
-</ul>
-<p>
- If the answer is Yes to those questions at the phase review, the project continues. If the answer is No, the phase is
- delayed (usually by adding an extra iteration) until a satisfactory answer is received, or the stakeholders may
- determine that the project should be cancelled.
-</p>
-<p>
- Within each phase, you might have one or several iterations, where the iterations aim at producing the results required
- to answer these questions. As an example, to answer the question for Elaboration, we typically need to implement and
- test key aspects of the system so that we understand what architecture we need, what commercial, off-the-shelf (COTS)
- components we may need, what key risks we face and how to address them, the effectiveness of the team, and so on. These
- needs will steer how we prioritize what is to be done in an Elaboration iteration.
-</p>
-<p>
- One of the objectives of the project lifecycle is to focus on two key stakeholder drivers: <b>risk reduction</b> and
- <b>value creation</b>. As figure 1 shows, the&nbsp;four phases here described focus the team on risk reduction related
- to the questions to be answered at the end of the phase, while tracking value creation.
-</p>
-<p>
- <img height="268" alt="Risk goes down and value goes up as project progresses." src="resources/project_lifecycle.jpg"
- width="500" />&nbsp;
-</p>
-<p>
- <strong>Figure 1 - Risk reduction (red curve) and value creation (green curve) during the project lifecycle</strong>
-</p>
-<p dir="ltr">
- <i>Risk</i> is a manifestation of the likelihood of unexpected things happening to the project, and risk stands in the
- way of value creation. Risk is directly proportional to uncertainty in estimates, and stakeholders typically want to
- know sooner rather than later what value the project can deliver in the stipulated time. In many cases, you reduce risk
- when you create value by implementing and testing the most critical capabilities. However, there are situations where
- risk reduction and immediate value creation are at odds with each other, requiring careful balancing of these competing
- priorities to maximize stakeholder value.
+ <mainDescription><h3>
+ Overview
+</h3>
+<p>
+ Although the entire purpose of a project is to produce a product, the specific goals of the team will vary
+ substantially throughout the project. In the beginning, there usually is considerable latitude in the requirements for
+ the product. It may not be clear whether the project is feasible or even if it is likely to be profitable. At that
+ time, it is critical to bring an answer to these questions and of little to no value to start developing the product in
+ earnest.&nbsp;Toward the end of the project, the product itself is usually complete, and issues of quality, delivery,
+ and completeness then take center stage. At different points in time, tasks are undertaken in new ways and work
+ products will have new content.
+</p>
+<p>
+ To coordinate the team's efforts in a manner that takes these fundamental observations into account, the project
+ lifecycle should be divided into a sequence of phases. Each phase has a defined set of goals, a particular iteration
+ style, and customized&nbsp; <a class="elementLinkWithUserText"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html"
+ guid="_x459ktnmEdmO6L4XMImrsA">tasks</a>&nbsp;and&nbsp;<a class="elementLinkWithUserText"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
+ guid="_H4JXwB_SEdq6CKKKq4D7YA">work products</a> to address the unique needs of the project at that point. The project
+ lifecycle provides <em>stakeholders</em> with oversight, transparency, and steering mechanisms to control project
+ funding, scope, risk exposure, value provided, and other aspects of the process.
+</p>
+<p>
+ It helps to organize iterations into phases. Each phase ends with a milestone aimed at providing oversight by raising
+ and answering a set of questions that are typically critical to stakeholders:
+</p>
+<ul>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/inception_phase_C4456871.html"
+ guid="_0hmKgBOMEduCNqgZdt_OaA">Inception</a>. Do we agree on project scope and objectives and whether or not the
+ project should proceed?
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/elaboration_phase_BE880435.html"
+ guid="_2plxwBOMEduCNqgZdt_OaA">Elaboration</a>. Do we agree on the executable architecture to be used for
+ developing the application, and do we find that the value delivered so far and the remaining risk is acceptable?
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/construction_phase_873B6559.html"
+ guid="_48EKsBOMEduCNqgZdt_OaA">Construction</a>. Do we find that we have an application that is sufficiently close
+ to being released that we should switch the primary focus of the team to tuning, polishing, and ensuring successful
+ deployment?
+ </li>
+ <li>
+ <a class="elementLinkWithUserText"
+ href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/transition_phase_DD5986E5.html"
+ guid="__ca5UBOMEduCNqgZdt_OaA">Transition</a>. Is the application ready to release?
+ </li>
+</ul>
+<p>
+ If the answer is Yes to those questions at the phase review, the project continues. If the answer is No, the phase is
+ delayed (usually by adding an extra iteration) until a satisfactory answer is received, or the stakeholders may
+ determine that the project should be cancelled.
+</p>
+<p>
+ Within each phase, you might have one or several iterations, where the iterations aim at producing the results required
+ to answer these questions. As an example, to answer the question for Elaboration, we typically need to implement and
+ test key aspects of the system so that we understand what architecture we need, what commercial, off-the-shelf (COTS)
+ components we may need, what key risks we face and how to address them, the effectiveness of the team, and so on. These
+ needs will steer how we prioritize what is to be done in an Elaboration iteration.
+</p>
+<p>
+ One of the objectives of the project lifecycle is to focus on two key stakeholder drivers: <b>risk reduction</b> and
+ <b>value creation</b>. As figure 1 shows, the&nbsp;four phases here described focus the team on risk reduction related
+ to the questions to be answered at the end of the phase, while tracking value creation.
+</p>
+<p>
+ <img height="268" alt="Risk goes down and value goes up as project progresses." src="resources/project_lifecycle.jpg"
+ width="500" />&nbsp;
+</p>
+<p>
+ <strong>Figure 1 - Risk reduction (red curve) and value creation (green curve) during the project lifecycle</strong>
+</p>
+<p dir="ltr">
+ <i>Risk</i> is a manifestation of the likelihood of unexpected things happening to the project, and risk stands in the
+ way of value creation. Risk is directly proportional to uncertainty in estimates, and stakeholders typically want to
+ know sooner rather than later what value the project can deliver in the stipulated time. In many cases, you reduce risk
+ when you create value by implementing and testing the most critical capabilities. However, there are situations where
+ risk reduction and immediate value creation are at odds with each other, requiring careful balancing of these competing
+ priorities to maximize stakeholder value.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/concepts/transition_phase.xmi b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/concepts/transition_phase.xmi
index cc33929..09db4dc 100644
--- a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/concepts/transition_phase.xmi
+++ b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/concepts/transition_phase.xmi
@@ -1,42 +1,49 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-FrUmsKsGW4bnNmb9uaNOkg" name=",__ca5UBOMEduCNqgZdt_OaA" guid="-FrUmsKsGW4bnNmb9uaNOkg" changeDate="2008-02-24T08:16:27.000-0800" version="1.0.0">
- <mainDescription><p>
- The purpose in this phase is to ensure that the software is ready for delivery to users.
-</p>
-<p>
- There are objectives for the Transition phase that help you to&nbsp;fine-tune functionality, performance, and overall
- quality of the beta product from the end of&nbsp;the previous phase <a class="elementlinkwithusertext" href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#KRO03" guid="_JlTPUM6aEdyuBO4ZIzcyig">[KRO03]</a>:
-</p>
-<ol>
- <li>
- <p>
- <strong>Beta test to validate that user expectations are met.</strong> This typically requires some fine-tuning
- activities, such as bug-fixing and making enhancements for performance and usability.
- </p>
- </li>
- <li>
- <p>
- <strong>Achieve stakeholder concurrence that deployment is complete.</strong> This may involve various levels
- of tests for product acceptance, including formal and informal tests and beta tests.
- </p>
- </li>
- <li>
- <p>
- <strong>Improve future project performance through lessons learned.</strong> Document lessons learned and
- improve the process and tool environment for the project.
- </p>
- </li>
-</ol>
-<h4> Key considerations</h4>
-<p> The Transition phase can include running old and new systems in parallel,
- migrating data, training users, and adjusting business processes. </p>
-<p>
- The number of iterations in the Transition phase varies from one iteration for a simple system requiring primarily
- minor bug fixing, to many iterations for a complex system, involving addition of features and performing activities to
- make the business transition from using the old system to using the new system.
-</p>
-<p> When the Transition phase objectives are met, the project can be closed.&nbsp;For
- some products, the end of the current project lifecycle may coincide with the
- beginning of the next lifecycle, leading to the next generation of the same
- product. </p></mainDescription>
+ <mainDescription><p>
+ The purpose in this phase is to ensure that the software is ready for delivery to users.
+</p>
+<p>
+ There are objectives for the Transition phase that help you to&nbsp;fine-tune functionality, performance, and overall
+ quality of the beta product from the end of&nbsp;the previous phase <a class="elementlinkwithusertext"
+ href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#KRO03"
+ guid="_JlTPUM6aEdyuBO4ZIzcyig">[KRO03]</a>:
+</p>
+<ol>
+ <li>
+ <p>
+ <strong>Beta test to validate that user expectations are met.</strong> This typically requires some fine-tuning
+ activities, such as bug-fixing and making enhancements for performance and usability.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Achieve stakeholder concurrence that deployment is complete.</strong> This may involve various levels
+ of tests for product acceptance, including formal and informal tests and beta tests.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Improve future project performance through lessons learned.</strong> Document lessons learned and
+ improve the process and tool environment for the project.
+ </p>
+ </li>
+</ol>
+<h4>
+ Key considerations
+</h4>
+<p>
+ The Transition phase can include running old and new systems in parallel, migrating data, training users, and adjusting
+ business processes.
+</p>
+<p>
+ The number of iterations in the Transition phase varies from one iteration for a simple system requiring primarily
+ minor bug fixing, to many iterations for a complex system, involving addition of features and performing activities to
+ make the business transition from using the old system to using the new system.
+</p>
+<p>
+ When the Transition phase objectives are met, the project can be closed.&nbsp;For some products, the end of the current
+ project lifecycle may coincide with the beginning of the next lifecycle, leading to the next generation of the same
+ product.
+</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/examples/project_plan.xmi b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/examples/project_plan.xmi
index aed5bf7..6c3bde3 100644
--- a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/examples/project_plan.xmi
+++ b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/examples/project_plan.xmi
@@ -1,414 +1,414 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:GuidanceDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-IdlCQXdDNYGrGJU4TBwvCA" name="new_example,_Nzv5kDoAEdusGsHODb-STA" guid="-IdlCQXdDNYGrGJU4TBwvCA" changeDate="2009-08-05T04:38:30.000-0700" version="1.0.0">
- <mainDescription><h3>
- 1 Introduction
-</h3>
-<p>
- This plan covers the content and enablement portions of the EPF 1.0 project. A separate plan covers the tooling
- component.
-</p>
-<h3>
- 2 Project Organization
-</h3>
-<p>
- See also: <a href="http://www.eclipse.org/epf/">http://www.eclipse.org/epf/</a><br />
- <br />
- The work is divided into a number of content areas. Each content area is lead by a committer that is the content lead,
- working closely with a number of committers and contributors. The content lead is responsible for making sure that bugs
- and enhancement requests are triaged and assigned, and responsible for updating the project burndown (status) on a
- weekly basis.<br />
- <br />
- We also have a content architect (Ricardo Balduino), who is responsible for the overall structure and integration of
- content from all content areas.
-</p>
-<p>
- The work is divided into the following content areas:
-</p>
-<ul>
- <li>
- Project management: Chris Armstrong (lead), Jochen Krebs, Per Kroll
- </li>
- <li>
- Requirements: Chris Sibbald (lead), Paul Bramble, Ana Paula Valente Pereira, Leonardo Medeiros, Kurt Sand, Bruce
- MacIsaac, Jim Ruehlin, Ricardo Balduino, and others.
- </li>
- <li>
- Change management: Chris Sibbald (lead), Kurt Sand, and others.
- </li>
- <li>
- Development: Brian Lyons (lead), Scott Ambler, Ricardo Balduino, and others.
- </li>
- <li>
- Architecture: Mark Dickson (lead), Jim Ruehlin, Ana Pereira, Chris Doyle, and others.
- </li>
- <li>
- Test: Brian Lyons (lead), Nate Oster, Jeff Smith, Dana Spears, and others.
- </li>
- <li>
- General: Steve Adolph (lead),
- </li>
- <li>
- Developer outreach: Per Kroll / Naveena Bereny (leads), Ricardo Balduino, Scott Ambler, Kurt Sand, and others.
- </li>
-</ul>
-<h3>
- 3 Project Practices and Measurements
-</h3>
-<p>
- The OpenUP component team will use OpenUP practices adapted to address the fact that we are doing content development
- rather than coding. Key artifacts include: Project Plan (Word), Work Item List (Bugzilla + Excel), Iteration Plan
- (Word), and Status Assessment (Word).
-</p>
-<p>
- Progress is tracked using two primary measurements using a point system. It is estimated that 1 point represents 2h of
- work:
-</p>
-<ul>
- <li>
- Project backlog: The project backlog shows progress relative to overall work to be done within the project.
- </li>
- <li>
- Iteration backlog: The iteration backlog shows progress relative to work intended for the current iteration.
- </li>
-</ul>
-<h3>
- 4&nbsp; Project Milestones and Objectives
-</h3>
-<p>
- This section covers objectives for the entire EPF 1.0 project.
-</p>
-<ul>
- <li>
- Governance process in place, including guidelines for how to work with CVS
- </li>
- <li>
- Tutorials available to help people adopt EPF composer
- </li>
- <li>
- Process tools matured and usable to produce a broad set of processes and method content.
- </li>
- <li>
- Basic set of interfaces / APIs defined, stabilized, and delivered.
- </li>
- <li>
- Deliver basic printing capability.
- </li>
- <li>
- Mature content. Deliver a mature OpenUP, and beta quality of one or more other processes, whereof one should be
- another agile process.
- </li>
- <li>
- Generate a high level of interest around EPF v1.0. Press releases, papers, tutorials, workshops, presentations,
- etc.
- </li>
- <li>
- Identify a broader set of process champions with an interest to contribute to EPF within a specific domain, such as
- MDA or project management, or a specific vertical such as telecom.<br />
- </li>
-</ul>
-<table title="" cellspacing="0" cellpadding="2" width="85%" border="1">
- <tbody>
- <tr>
- <td>
- <strong>Phase</strong>
- </td>
- <td>
- <strong>Iteration</strong>
- </td>
- <td>
- <strong>Primary Objective (risks and use cases scenarios)</strong>
- </td>
- <td>
- <strong>Scheduled start or milestone</strong>
- </td>
- <td>
- <strong>Duration Estimate (calendar days)</strong>
- </td>
- </tr>
- <tr>
- <td>
- Inception/ Warm-up
- </td>
- <td>
- M0
- </td>
- <td>
- <ul>
- <li>
- Project acceptance and provisioning.
- </li>
- <li>
- IBM donation. Project environment established.
- </li>
- <li>
- Committer meeting. Project organization and plan agreed to.
- </li>
- </ul>
- </td>
- <td>
- 12/23/2005<br />
- 1/15/2005
- </td>
- <td>
- 24 days
- </td>
- </tr>
- <tr>
- <td>
- Elaboration
- </td>
- <td>
- M1
- </td>
- <td>
- <ul>
- <li>
- Legal process to be completed by initial committers
- </li>
- <li>
- Train all committers.
- </li>
- <li>
- Provision project, set up website, mailing lists, etc.
- </li>
- <li>
- Agree on structure of OpenUP; agree on how to structure of OpenUP into work units, principles and
- resources to evolve each unit.
- </li>
- <li>
- Identify outreach activities
- </li>
- </ul>
- </td>
- <td>
- 1/16/2006<br />
- 2/28/2006<br />
- </td>
- <td>
- 43 days
- </td>
- </tr>
- <tr>
- <td>
- Elaboration
- </td>
- <td>
- M2
- </td>
- <td>
- <ul>
- <li>
- Naming convention agreed to
- </li>
- <li>
- Agree to key structural information for OpenUP (e.g. tasks, work products, etc. defined)
- </li>
- <li>
- Engage with additional contributors
- </li>
- <li>
- Agree on user experience and have a few examples for OpenUP
- </li>
- <li>
- Validate extensibility / composibility of OpenUP
- </li>
- </ul>
- </td>
- <td>
- 3/1/2006<br />
- 4/15/2006<br />
- </td>
- <td>
- 45 days
- </td>
- </tr>
- <tr>
- <td>
- Elaboration
- </td>
- <td>
- M3
- </td>
- <td>
- <ul>
- <li>
- Identify an initial set of key promoters presenting at conferences, writing blogs and articles,
- etc.
- </li>
- <li>
- Agree on general structure of OpenUP
- </li>
- </ul>
- </td>
- <td>
- 4/15/2006<br />
- 5/31/2006
- </td>
- <td>
- 45 days
- </td>
- </tr>
- <tr>
- <td>
- Construction
- </td>
- <td>
- M4
- </td>
- <td>
- <ul>
- <li>
- Produce realistic plans for M5
- </li>
- <li>
- Agree on a management process
- </li>
- <li>
- Have all structural content decisions taken
- </li>
- <li>
- Have 30% of content ready for review
- </li>
- <li>
- Plan Agile2006, SD Best Practices, and other outreach activities
- </li>
- </ul>
- </td>
- <td>
- 6/1/2006<br />
- 7/16/2006<br />
- </td>
- <td>
- 45 days
- </td>
- </tr>
- <tr>
- <td>
- Construction
- </td>
- <td>
- M5
- </td>
- <td>
- <ul>
- <li>
- Finalize structure
- </li>
- <li>
- Improve usability and first impression
- </li>
- <li>
- Review 30% of content
- </li>
- <li>
- Make additional 30% of content available for review
- </li>
- <li>
- Establish a functioning management process for the project
- </li>
- <li>
- Establish a review board
- </li>
- <li>
- Produce initial draft collateral for EPF 1.0 launch
- </li>
- <li>
- Make preview at Agile 2006 successful
- </li>
- <li>
- Start to build a user community. Identify 2 pilot projects.
- </li>
- </ul>
- </td>
- <td>
- 7/17/2006<br />
- 8/4/2006
- </td>
- <td>
- 21 days
- </td>
- </tr>
- <tr>
- <td>
- Construction
- </td>
- <td>
- M6
- </td>
- <td>
- <ul>
- <li>
- Improve usability and first impression
- </li>
- <li>
- Have 60% of content reviewed
- </li>
- <li>
- Make the final 40% of content available for review
- </li>
- <li>
- Produce more draft collateral for EPF 1.0 launch
- </li>
- <li>
- Continue building a user community
- </li>
- </ul>
- </td>
- <td>
- 8/7/2006<br />
- 9/1/2006
- </td>
- <td>
- 28 days
- </td>
- </tr>
- <tr>
- <td>
- Transition / End Game
- </td>
- <td>
- M7
- </td>
- <td>
- <ul>
- <li>
- End game
- </li>
- <li>
- Finalize content 0.9
- </li>
- <li>
- Finalize launch collateral
- </li>
- <li>
- Plan next release
- </li>
- </ul>
- </td>
- <td>
- 9/4/2006<br />
- 9/29/2006
- </td>
- <td>
- 28 days
- </td>
- </tr>
- </tbody>
-</table>
-<h3>
- <br />
- 5 Deployment
-</h3>
-<p>
- N/A.
-</p>
-<h3>
- 6 Lessons Learned
-</h3>
-<p>
- N/A.<br />
- <br />
- <br />
-</p><br />
+ <mainDescription><h3>
+ 1 Introduction
+</h3>
+<p>
+ This plan covers the content and enablement portions of the EPF 1.0 project. A separate plan covers the tooling
+ component.
+</p>
+<h3>
+ 2 Project Organization
+</h3>
+<p>
+ See also: <a href="http://www.eclipse.org/epf/">http://www.eclipse.org/epf/</a><br />
+ <br />
+ The work is divided into a number of content areas. Each content area is lead by a committer that is the content lead,
+ working closely with a number of committers and contributors. The content lead is responsible for making sure that bugs
+ and enhancement requests are triaged and assigned, and responsible for updating the project burndown (status) on a
+ weekly basis.<br />
+ <br />
+ We also have a content architect (Ricardo Balduino), who is responsible for the overall structure and integration of
+ content from all content areas.
+</p>
+<p>
+ The work is divided into the following content areas:
+</p>
+<ul>
+ <li>
+ Project management: Chris Armstrong (lead), Jochen Krebs, Per Kroll
+ </li>
+ <li>
+ Requirements: Chris Sibbald (lead), Paul Bramble, Ana Paula Valente Pereira, Leonardo Medeiros, Kurt Sand, Bruce
+ MacIsaac, Jim Ruehlin, Ricardo Balduino, and others.
+ </li>
+ <li>
+ Change management: Chris Sibbald (lead), Kurt Sand, and others.
+ </li>
+ <li>
+ Development: Brian Lyons (lead), Scott Ambler, Ricardo Balduino, and others.
+ </li>
+ <li>
+ Architecture: Mark Dickson (lead), Jim Ruehlin, Ana Pereira, Chris Doyle, and others.
+ </li>
+ <li>
+ Test: Brian Lyons (lead), Nate Oster, Jeff Smith, Dana Spears, and others.
+ </li>
+ <li>
+ General: Steve Adolph (lead),
+ </li>
+ <li>
+ Developer outreach: Per Kroll / Naveena Bereny (leads), Ricardo Balduino, Scott Ambler, Kurt Sand, and others.
+ </li>
+</ul>
+<h3>
+ 3 Project Practices and Measurements
+</h3>
+<p>
+ The OpenUP component team will use OpenUP practices adapted to address the fact that we are doing content development
+ rather than coding. Key artifacts include: Project Plan (Word), Work Item List (Bugzilla + Excel), Iteration Plan
+ (Word), and Status Assessment (Word).
+</p>
+<p>
+ Progress is tracked using two primary measurements using a point system. It is estimated that 1 point represents 2h of
+ work:
+</p>
+<ul>
+ <li>
+ Project backlog: The project backlog shows progress relative to overall work to be done within the project.
+ </li>
+ <li>
+ Iteration backlog: The iteration backlog shows progress relative to work intended for the current iteration.
+ </li>
+</ul>
+<h3>
+ 4&nbsp; Project Milestones and Objectives
+</h3>
+<p>
+ This section covers objectives for the entire EPF 1.0 project.
+</p>
+<ul>
+ <li>
+ Governance process in place, including guidelines for how to work with CVS
+ </li>
+ <li>
+ Tutorials available to help people adopt EPF composer
+ </li>
+ <li>
+ Process tools matured and usable to produce a broad set of processes and method content.
+ </li>
+ <li>
+ Basic set of interfaces / APIs defined, stabilized, and delivered.
+ </li>
+ <li>
+ Deliver basic printing capability.
+ </li>
+ <li>
+ Mature content. Deliver a mature OpenUP, and beta quality of one or more other processes, whereof one should be
+ another agile process.
+ </li>
+ <li>
+ Generate a high level of interest around EPF v1.0. Press releases, papers, tutorials, workshops, presentations,
+ etc.
+ </li>
+ <li>
+ Identify a broader set of process champions with an interest to contribute to EPF within a specific domain, such as
+ MDA or project management, or a specific vertical such as telecom.<br />
+ </li>
+</ul>
+<table title="" cellspacing="0" cellpadding="2" width="85%" border="1">
+ <tbody>
+ <tr>
+ <td>
+ <strong>Phase</strong>
+ </td>
+ <td>
+ <strong>Iteration</strong>
+ </td>
+ <td>
+ <strong>Primary Objective (risks and use cases scenarios)</strong>
+ </td>
+ <td>
+ <strong>Scheduled start or milestone</strong>
+ </td>
+ <td>
+ <strong>Duration Estimate (calendar days)</strong>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Inception/ Warm-up
+ </td>
+ <td>
+ M0
+ </td>
+ <td>
+ <ul>
+ <li>
+ Project acceptance and provisioning.
+ </li>
+ <li>
+ IBM donation. Project environment established.
+ </li>
+ <li>
+ Committer meeting. Project organization and plan agreed to.
+ </li>
+ </ul>
+ </td>
+ <td>
+ 12/23/2005<br />
+ 1/15/2005
+ </td>
+ <td>
+ 24 days
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Elaboration
+ </td>
+ <td>
+ M1
+ </td>
+ <td>
+ <ul>
+ <li>
+ Legal process to be completed by initial committers
+ </li>
+ <li>
+ Train all committers.
+ </li>
+ <li>
+ Provision project, set up website, mailing lists, etc.
+ </li>
+ <li>
+ Agree on structure of OpenUP; agree on how to structure of OpenUP into work units, principles and
+ resources to evolve each unit.
+ </li>
+ <li>
+ Identify outreach activities
+ </li>
+ </ul>
+ </td>
+ <td>
+ 1/16/2006<br />
+ 2/28/2006<br />
+ </td>
+ <td>
+ 43 days
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Elaboration
+ </td>
+ <td>
+ M2
+ </td>
+ <td>
+ <ul>
+ <li>
+ Agree on naming conventions
+ </li>
+ <li>
+ Agree to key structural information for OpenUP (e.g. tasks, work products, etc. defined)
+ </li>
+ <li>
+ Engage with additional contributors
+ </li>
+ <li>
+ Agree on user experience and have a few examples for OpenUP
+ </li>
+ <li>
+ Validate extensibility / composibility of OpenUP
+ </li>
+ </ul>
+ </td>
+ <td>
+ 3/1/2006<br />
+ 4/15/2006<br />
+ </td>
+ <td>
+ 45 days
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Elaboration
+ </td>
+ <td>
+ M3
+ </td>
+ <td>
+ <ul>
+ <li>
+ Identify an initial set of key promoters presenting at conferences, writing blogs and articles,
+ etc.
+ </li>
+ <li>
+ Agree on general structure of OpenUP
+ </li>
+ </ul>
+ </td>
+ <td>
+ 4/15/2006<br />
+ 5/31/2006
+ </td>
+ <td>
+ 45 days
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Construction
+ </td>
+ <td>
+ M4
+ </td>
+ <td>
+ <ul>
+ <li>
+ Produce realistic plans for M5
+ </li>
+ <li>
+ Agree on a management process
+ </li>
+ <li>
+ Have all structural content decisions taken
+ </li>
+ <li>
+ Have 30% of content ready for review
+ </li>
+ <li>
+ Plan Agile2006, SD Best Practices, and other outreach activities
+ </li>
+ </ul>
+ </td>
+ <td>
+ 6/1/2006<br />
+ 7/16/2006<br />
+ </td>
+ <td>
+ 45 days
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Construction
+ </td>
+ <td>
+ M5
+ </td>
+ <td>
+ <ul>
+ <li>
+ Finalize structure
+ </li>
+ <li>
+ Improve usability and first impression
+ </li>
+ <li>
+ Review 30% of content
+ </li>
+ <li>
+ Make additional 30% of content available for review
+ </li>
+ <li>
+ Establish a functioning management process for the project
+ </li>
+ <li>
+ Establish a review board
+ </li>
+ <li>
+ Produce initial draft collateral for EPF 1.0 launch
+ </li>
+ <li>
+ Make preview at Agile 2006 successful
+ </li>
+ <li>
+ Start to build a user community. Identify 2 pilot projects.
+ </li>
+ </ul>
+ </td>
+ <td>
+ 7/17/2006<br />
+ 8/4/2006
+ </td>
+ <td>
+ 21 days
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Construction
+ </td>
+ <td>
+ M6
+ </td>
+ <td>
+ <ul>
+ <li>
+ Improve usability and first impression
+ </li>
+ <li>
+ Have 60% of content reviewed
+ </li>
+ <li>
+ Make the final 40% of content available for review
+ </li>
+ <li>
+ Produce more draft collateral for EPF 1.0 launch
+ </li>
+ <li>
+ Continue building a user community
+ </li>
+ </ul>
+ </td>
+ <td>
+ 8/7/2006<br />
+ 9/1/2006
+ </td>
+ <td>
+ 28 days
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Transition / End Game
+ </td>
+ <td>
+ M7
+ </td>
+ <td>
+ <ul>
+ <li>
+ End game
+ </li>
+ <li>
+ Finalize content 0.9
+ </li>
+ <li>
+ Finalize launch collateral
+ </li>
+ <li>
+ Plan next release
+ </li>
+ </ul>
+ </td>
+ <td>
+ 9/4/2006<br />
+ 9/29/2006
+ </td>
+ <td>
+ 28 days
+ </td>
+ </tr>
+ </tbody>
+</table>
+<h3>
+ <br />
+ 5 Deployment
+</h3>
+<p>
+ N/A.
+</p>
+<h3>
+ 6 Lessons Learned
+</h3>
+<p>
+ N/A.<br />
+ <br />
+ <br />
+</p><br />
<br /></mainDescription>
</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/practices/risk_value_lifecycle.xmi b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/practices/risk_value_lifecycle.xmi
index 4ad0d47..4ffce57 100644
--- a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/practices/risk_value_lifecycle.xmi
+++ b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/practices/risk_value_lifecycle.xmi
@@ -1,34 +1,46 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:PracticeDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-O5h7zCsZNfBqp61tzgV95Q" name="new_practice,_9FqrQB4sEd2bS8fFOQ7WWA" guid="-O5h7zCsZNfBqp61tzgV95Q" changeDate="2008-10-13T10:52:16.000-0700" version="7.5.0">
- <additionalInfo><h3> Additional resources </h3>
+ <additionalInfo><h3>
+ Additional resources
+</h3>
<p>
For more information on the risk-value lifecycle approach, see the following:
</p>
<ul>
- <li> Kruchten, P. &quot;<a href="http://www.ibm.com/developerworks/rational/library/4626.html">Going 
- Over the Waterfall with the RUP</a>&quot; (IBM developerWorks article, 2004)</li>
+ <li>
+ Kruchten, P. "<a href="http://www.ibm.com/developerworks/rational/library/4626.html">Going Over the Waterfall with
+ the RUP</a>" (IBM developerWorks article, 2004)
+ </li>
</ul>
-
<ul>
- <li> Kroll, P. and&nbsp;Kruchten, P. <em>The Rational Unified Process Made Easy</em>, 
- Addison Wesley, 2003. Chapters 5 through 9. </li>
-</ul>
-<br /></additionalInfo>
- <problem><h3> Why adopt this practice? </h3>
-<p> Project stakeholders look for&nbsp;ways to understand and control project 
- funding, scope, risk exposure, value provided, and other aspects of the project. 
- While&nbsp;project iterations deliver&nbsp;product increments that show value 
- delivered and show progress at a fine-grained level (meaning that work items 
- are being addressed), they do not provide the necessary project oversight, transparency, 
- and steering mechanisms at a coarse-grained level that allow stakeholders to 
- make informed business decisions about the project. </p>
-<p> The organization of iterations into a set of&nbsp;phases -- with a well-defined 
- milestone at the end of each phase -- provides the&nbsp;structure that stakeholders 
- and managers need to assess whether the objectives of the phase have been met 
- and&nbsp;whether the project should move on to the next phase or not. See <a class="elementLink" href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/phase_milestones_5678231E.html" guid="_HNxbwMBJEdqSgKaj2SZBmg">Phase Milestones</a>&nbsp;for more&nbsp;details.&nbsp; </p>
-<p> By addressing the goals and risks of each phase, the team has the opportunity 
- to find the right balance between risk reduction and immediate value creation, 
- which are two major drivers for stakeholders. See <a class="elementLink" href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/project_lifecycle_203F87.html" guid="_nSfVwCNYEdyCq8v2ZO4QcA">Project Lifecycle</a> for more information. </p></problem>
+ <li>
+ Kroll, P. and&nbsp;Kruchten, P. <em>The Rational Unified Process Made Easy</em>, Addison Wesley, 2003. Chapters 5
+ through 9.
+ </li>
+</ul><br /></additionalInfo>
+ <problem><h3>
+ Why adopt this practice?
+</h3>
+<p>
+ Project stakeholders look for&nbsp;ways to understand and control project funding, scope, risk exposure, value
+ provided, and other aspects of the project. While&nbsp;project iterations deliver&nbsp;product increments that show
+ value delivered and show progress at a fine-grained level (meaning that work items are being addressed), they do not
+ provide the necessary project oversight, transparency, and steering mechanisms at a coarse-grained level that allow
+ stakeholders to make informed business decisions about the project.
+</p>
+<p>
+ The organization of iterations into a set of&nbsp;phases -- with a well-defined milestone at the end of each phase --
+ provides the&nbsp;structure that stakeholders and managers need to assess whether the objectives of the phase have been
+ met and&nbsp;whether the project should move on to the next phase or not. See <a class="elementLink"
+ href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/phase_milestones_5678231E.html"
+ guid="_HNxbwMBJEdqSgKaj2SZBmg">Phase Milestones</a>&nbsp;for more&nbsp;details.&nbsp;
+</p>
+<p>
+ By addressing the goals and risks of each phase, the team has the opportunity to find the right balance between risk
+ reduction and immediate value creation, which are two major drivers for stakeholders. See <a class="elementLink"
+ href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/project_lifecycle_203F87.html"
+ guid="_nSfVwCNYEdyCq8v2ZO4QcA">Project Lifecycle</a> for more information.
+</p></problem>
<application><p>
The best way to read this practice is to first familiarize yourself with its overall structure: what it is in it and
how it is organized.&nbsp;
diff --git a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/roadmaps/how_to_adopt.xmi b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/roadmaps/how_to_adopt.xmi
index d7b913a..e234831 100644
--- a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/roadmaps/how_to_adopt.xmi
+++ b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/roadmaps/how_to_adopt.xmi
@@ -1,103 +1,112 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-R1d0qAJDnmI5Fm9ChHCYQw" name="how_to_adopt,_ERIDQOMPEdyM47cGD2jiaQ" guid="-R1d0qAJDnmI5Fm9ChHCYQw" changeDate="2008-06-30T01:42:52.000-0700" version="7.2.0">
- <mainDescription><h3> Getting started&nbsp; </h3>
-Organize your project into a set of phases, each providing a milestone where business
-and management decisions can be made on whether the project should go to the next
-phase or not. A risk-value lifecycle&nbsp;provide stakeholders with visibility
-on two main drivers: risks need to be driven down and value&nbsp;needs&nbsp;to
-be&nbsp;driven up.&nbsp;At the end of each phase in the lifecycle, there is a
-milestone that will help answer the questions and find the balance between risks
-and value. See <a class="elementLink" href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/phase_milestones_5678231E.html" guid="_HNxbwMBJEdqSgKaj2SZBmg">Phase Milestones</a>&nbsp;for more information on milestones and <a class="elementLink" href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/project_lifecycle_203F87.html" guid="_nSfVwCNYEdyCq8v2ZO4QcA">Project Lifecycle</a>&nbsp;for more information on balancing risks and value.<br />
-<p> Divide phases into iterations that deliver an increment of software that you
- can&nbsp;demonstrate and, potentially, deliver.&nbsp;Each iteration in a phase
- will contain just enough of any activity required to meet the objectives of
- that phase by the time you meet the milestone that concludes it. If the milestone
- can't be satisfied, consider adding one more iteration to that phase until the
- expected risks&nbsp;for the phase are mitigated or the expected stakeholder
- value is provided. </p>
-<p> Plan the number of iterations in each phase according to the lifecycle pattern
- that is most appropriate to your project. For example, when the problem domain
- is familiar, the risks are well-understood, and the project team is experienced,
- you may need only one iteration in Inception and one in Elaboration phases,
- then&nbsp;you can have multiple iterations in Construction&nbsp;(to develop
- the requirements and architecture) and a few iterations in Transition to migrate
- the product to users.&nbsp;Another example is when the problem domain is new
- or unfamiliar or the team is inexperienced. In such a case, you might need several
- iterations in Elaboration to refine requirements and architecture as you implement
- them, then one iteration in&nbsp;Construction to deal with less critical requirements.
- For more information on lifecycle patterns see&nbsp;[<a class="elementLinkWithUserText" href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#DOD94" guid="_JlTPUM6aEdyuBO4ZIzcyig">DOD94</a>]
- and [<a class="elementLinkWithUserText" href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#GIL88" guid="_JlTPUM6aEdyuBO4ZIzcyig">GIL88</a>].&nbsp;
-</p>
-<p>
- Phases are not identical in terms of schedule and effort. For example,&nbsp;a typical distribution&nbsp;of resources
- and time spent for a medium-sized project is represented in the table below.
-</p>
-<table title="Typical distribution of schedule and effort on a mid-sized project" cellspacing="0" cellpadding="2" width="85%" border="1">
- <tbody>
- <tr>
- <th id="" scope="col" abbr="">
- </th>
- <th id="" scope="col" abbr="">
- Inception
- </th>
- <th id="" scope="col" abbr="">
- Elaboration
- </th>
- <th id="" scope="col" abbr="">
- Construction
- </th>
- <th id="" scope="col" abbr="">
- Transition
- </th>
- </tr>
- <tr>
- <th id="" scope="row" abbr="">
- Effort
- </th>
- <td>
- ~5%
- </td>
- <td>
- 20%
- </td>
- <td>
- 65%
- </td>
- <td>
- 10%
- </td>
- </tr>
- <tr>
- <th id="" scope="row" abbr="">
- Schedule
- </th>
- <td>
- 10%
- </td>
- <td>
- 30%
- </td>
- <td>
- 50%
- </td>
- <td>
- 10%
- </td>
- </tr>
- </tbody>
-</table>
-<p>
- For more information and examples of projects adopting the four-phase lifecycle, see [<a class="elementLinkWithUserText" href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#KRO03" guid="_JlTPUM6aEdyuBO4ZIzcyig">KRO03</a>].
-</p>
-<h3> Common pitfalls </h3>
-<p> A common misconception about the four unified process phases is to compare
- them to&nbsp;a waterfall approach, where one would expect to document all of
- the requirements in Inception, create the whole design and architecture in Elaboration,
- do all of the implementation in Construction, and test in Transition. Phases
- are&nbsp;time-allocated in the project schedule and&nbsp;provide a framework
- and milestones for making business and management decisions. Each iteration
- in each phase provides a complete pass through activities in the disciplines&nbsp;of
- software development (for example, requirements, design, implementation, integration,
- testing, and so on) and produces an executable&nbsp;increment of software&nbsp;that
- minimizes risks and grows in value. </p></mainDescription>
+ <mainDescription><h3>
+ Getting started&nbsp;
+</h3>Organize your project into a set of phases, each providing a milestone where business and management decisions can be
+made on whether the project should go to the next phase or not. A risk-value lifecycle&nbsp;provide stakeholders with
+visibility on two main drivers: risks need to be driven down and value&nbsp;needs&nbsp;to be&nbsp;driven up.&nbsp;At the
+end of each phase in the lifecycle, there is a milestone that will help answer the questions and find the balance between
+risks and value. See <a class="elementLink"
+href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/phase_milestones_5678231E.html"
+guid="_HNxbwMBJEdqSgKaj2SZBmg">Phase Milestones</a>&nbsp;for more information on milestones and <a class="elementLink"
+href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/project_lifecycle_203F87.html"
+guid="_nSfVwCNYEdyCq8v2ZO4QcA">Project Lifecycle</a>&nbsp;for more information on balancing risks and value.<br />
+<p>
+ Divide phases into iterations that deliver an increment of software that you can&nbsp;demonstrate and, potentially,
+ deliver.&nbsp;Each iteration in a phase will contain just enough of any activity required to meet the objectives of
+ that phase by the time you meet the milestone that concludes it. If the milestone can't be satisfied, consider adding
+ one more iteration to that phase until the expected risks&nbsp;for the phase are mitigated or the expected stakeholder
+ value is provided.
+</p>
+<p>
+ Plan the number of iterations in each phase according to the lifecycle pattern that is most appropriate to your
+ project. For example, when the problem domain is familiar, the risks are well-understood, and the project team is
+ experienced, you may need only one iteration in Inception and one in Elaboration phases, then&nbsp;you can have
+ multiple iterations in Construction&nbsp;(to develop the requirements and architecture) and a few iterations in
+ Transition to migrate the product to users.&nbsp;Another example is when the problem domain is new or unfamiliar or the
+ team is inexperienced. In such a case, you might need several iterations in Elaboration to refine requirements and
+ architecture as you implement them, then one iteration in&nbsp;Construction to deal with less critical requirements.
+ For more information on lifecycle patterns see&nbsp;[<a class="elementLinkWithUserText"
+ href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#DOD94"
+ guid="_JlTPUM6aEdyuBO4ZIzcyig">DOD94</a>] and [<a class="elementLinkWithUserText"
+ href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#GIL88"
+ guid="_JlTPUM6aEdyuBO4ZIzcyig">GIL88</a>].&nbsp;
+</p>
+<p>
+ Phases are not identical in terms of schedule and effort. For example,&nbsp;a typical distribution&nbsp;of resources
+ and time spent for a medium-sized project is represented in the table below.
+</p>
+<table title="Typical distribution of schedule and effort on a mid-sized project" cellspacing="0" cellpadding="2"
+width="85%" border="1">
+ <tbody>
+ <tr>
+ <th id="" scope="col" abbr="">
+ </th>
+ <th id="" scope="col" abbr="">
+ Inception
+ </th>
+ <th id="" scope="col" abbr="">
+ Elaboration
+ </th>
+ <th id="" scope="col" abbr="">
+ Construction
+ </th>
+ <th id="" scope="col" abbr="">
+ Transition
+ </th>
+ </tr>
+ <tr>
+ <th id="" scope="row" abbr="">
+ Effort
+ </th>
+ <td>
+ ~5%
+ </td>
+ <td>
+ 20%
+ </td>
+ <td>
+ 65%
+ </td>
+ <td>
+ 10%
+ </td>
+ </tr>
+ <tr>
+ <th id="" scope="row" abbr="">
+ Schedule
+ </th>
+ <td>
+ 10%
+ </td>
+ <td>
+ 30%
+ </td>
+ <td>
+ 50%
+ </td>
+ <td>
+ 10%
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>
+ For more information and examples of projects adopting the four-phase lifecycle, see [<a
+ class="elementLinkWithUserText"
+ href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#KRO03"
+ guid="_JlTPUM6aEdyuBO4ZIzcyig">KRO03</a>].
+</p>
+<h3>
+ Common pitfalls
+</h3>
+<p>
+ A common misconception about the four unified process phases is to compare them to&nbsp;a waterfall approach, where one
+ would expect to document all of the requirements in Inception, create the whole design and architecture in Elaboration,
+ do all of the implementation in Construction, and test in Transition. Phases are&nbsp;time-allocated in the project
+ schedule and&nbsp;provide a framework and milestones for making business and management decisions. Each iteration in
+ each phase provides a complete pass through activities in the disciplines&nbsp;of software development (for example,
+ requirements, design, implementation, integration, testing, and so on) and produces an executable&nbsp;increment of
+ software&nbsp;that minimizes risks and grows in value.
+</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/construction.xmi b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/construction.xmi
index c954047..e8f13e0 100644
--- a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/construction.xmi
+++ b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/construction.xmi
@@ -1,6 +1,5 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-5wJmUR0WqX7lCIxsyqFsdA" name=",_0sD60EvDEdunZcj9T5hrMQ" guid="-5wJmUR0WqX7lCIxsyqFsdA" changeDate="2008-02-21T10:56:13.000-0800" version="7.2.0">
- <mainDescription>The third phase of the project lifecycle in which the software is brought from
-an executable architectural baseline to the point at which it is ready to be transitioned
-to the user community.</mainDescription>
+ <mainDescription>The third phase of the project lifecycle in which the software is brought from an executable architectural baseline to the
+point at which it is ready to be transitioned to the user community.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/elaboration.xmi b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/elaboration.xmi
index 77f558a..4c4f333 100644
--- a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/elaboration.xmi
+++ b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/elaboration.xmi
@@ -1,5 +1,4 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-0g2jTHQla8lbP6xGB3iGlg" name=",_8DkT4EvDEdunZcj9T5hrMQ" guid="-0g2jTHQla8lbP6xGB3iGlg" changeDate="2008-07-08T03:29:57.000-0700" version="7.2.0">
- <mainDescription>Second of four phases in the project lifecycle, when architecturally significant
-risks are addressed.</mainDescription>
+ <mainDescription>Second of four phases in the project lifecycle, when architecturally significant risks are addressed.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/inception.xmi b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/inception.xmi
index e204009..8780081 100644
--- a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/inception.xmi
+++ b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/inception.xmi
@@ -1,6 +1,5 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-dhgOQQ4GsV0-dNJmTmF9GA" name=",_525A8EvDEdunZcj9T5hrMQ" guid="-dhgOQQ4GsV0-dNJmTmF9GA" changeDate="2008-07-08T03:30:15.000-0700" version="7.2.0">
- <mainDescription>First of the four phases in the project lifecycle.&nbsp;It is about understanding
-the project scope and objectives and getting enough information to confirm whether
-the project should proceed&nbsp;or not.</mainDescription>
+ <mainDescription>First of the four phases in the project lifecycle.&nbsp;It is about understanding the project scope and objectives and
+getting enough information to confirm whether the project should proceed&nbsp;or not.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/ioc_milestone.xmi b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/ioc_milestone.xmi
index f9c08aa..1ef75c3 100644
--- a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/ioc_milestone.xmi
+++ b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/ioc_milestone.xmi
@@ -1,9 +1,11 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-gEgZg2UkFLjGeXkJLpAP6A" name=",_O7JBYEvFEdunZcj9T5hrMQ" guid="-gEgZg2UkFLjGeXkJLpAP6A" changeDate="2008-07-08T03:25:16.000-0700" version="7.2.0">
- <mainDescription><p> Third major project milestone that occurs at the end of the <a class="elementLink" href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/construction_E36D1BB6.html" guid="_0sD60EvDEdunZcj9T5hrMQ">Construction</a>
- phase. At this point, the product is ready to be handed over to the Transition
- team. All functionality has been developed and all alpha testing (if any) has
- been completed. In addition to the software, a user manual has been developed,
- and there is a description of the current release. The product is ready for
- beta testing. </p></mainDescription>
+ <mainDescription><p>
+ Third major project milestone that occurs at the end of the <a class="elementLink"
+ href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/construction_E36D1BB6.html"
+ guid="_0sD60EvDEdunZcj9T5hrMQ">Construction</a> phase. At this point, the product is ready to be handed over to the
+ Transition team. All functionality has been developed and all alpha testing (if any) has been completed. In addition to
+ the software, a user manual has been developed, and there is a description of the current release. The product is ready
+ for beta testing.
+</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/lca_milestone.xmi b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/lca_milestone.xmi
index 267cff2..a5446cf 100644
--- a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/lca_milestone.xmi
+++ b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/lca_milestone.xmi
@@ -1,8 +1,10 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-MllWL01NL93RTB7VsY69fw" name=",_NL4DMEvFEdunZcj9T5hrMQ" guid="-MllWL01NL93RTB7VsY69fw" changeDate="2008-07-08T03:22:55.000-0700" version="7.2.0">
- <mainDescription><p>
- Second major project milestone that occurs at the end of <a class="elementLink" href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/elaboration_3D6C8392.html" guid="_8DkT4EvDEdunZcj9T5hrMQ">Elaboration</a> phase. At this point, a baseline of requirements is agreed
- to.&nbsp;Examine the detailed system objectives and scope, the choice of architecture, and the resolution of the major
- risks. The milestone is achieved when the architecture has been validated.
+ <mainDescription><p>
+ Second major project milestone that occurs at the end of <a class="elementLink"
+ href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/elaboration_3D6C8392.html"
+ guid="_8DkT4EvDEdunZcj9T5hrMQ">Elaboration</a> phase. At this point, a baseline of requirements is agreed
+ to.&nbsp;Examine the detailed system objectives and scope, the choice of architecture, and the resolution of the major
+ risks. The milestone is achieved when the architecture has been validated.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/lco_milestone.xmi b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/lco_milestone.xmi
index d0fdd85..7928e04 100644
--- a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/lco_milestone.xmi
+++ b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/lco_milestone.xmi
@@ -1,6 +1,9 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-Rl8kaRW9Bxqdvq32kVCi7w" name=",_LGRBkEvFEdunZcj9T5hrMQ" guid="-Rl8kaRW9Bxqdvq32kVCi7w" changeDate="2008-07-08T03:20:50.000-0700" version="7.2.0">
- <mainDescription><p> First major project milestone, which occurs at the end of the <a class="elementLink" href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/inception_B9991FC2.html" guid="_525A8EvDEdunZcj9T5hrMQ">Inception</a>&nbsp;phase.&nbsp;At
- this point, compare the cost to the benefits of the project, and decide whether
- to proceed with the project or to cancel it. </p></mainDescription>
+ <mainDescription><p>
+ First major project milestone, which occurs at the end of the <a class="elementLink"
+ href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/inception_B9991FC2.html"
+ guid="_525A8EvDEdunZcj9T5hrMQ">Inception</a>&nbsp;phase.&nbsp;At this point, compare the cost to the benefits of the
+ project, and decide whether to proceed with the project or to cancel it.
+</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/pr_milestone.xmi b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/pr_milestone.xmi
index 37e2a7b..ceaaeac 100644
--- a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/pr_milestone.xmi
+++ b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/pr_milestone.xmi
@@ -1,7 +1,10 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-JegYQHIteCRN0iV2EKMjSA" name=",_QuywUEvFEdunZcj9T5hrMQ" guid="-JegYQHIteCRN0iV2EKMjSA" changeDate="2008-07-08T03:26:32.000-0700" version="7.2.0">
- <mainDescription><p> Fourth major project milestone that occurs at the end of the <a class="elementLink" href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/transition_6F9C9F4B.html" guid="_-5ms4EvDEdunZcj9T5hrMQ">Transition</a>&nbsp;phase.
- At this point, decide whether the objectives were met and whether you should
- start another development cycle. This milestone&nbsp;is the result of the customer
- reviewing and accepting the project deliverables. </p></mainDescription>
+ <mainDescription><p>
+ Fourth major project milestone that occurs at the end of the <a class="elementLink"
+ href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/transition_6F9C9F4B.html"
+ guid="_-5ms4EvDEdunZcj9T5hrMQ">Transition</a>&nbsp;phase. At this point, decide whether the objectives were met and
+ whether you should start another development cycle. This milestone&nbsp;is the result of the customer reviewing and
+ accepting the project deliverables.
+</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/transition.xmi b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/transition.xmi
index b9a35e4..fee45f8 100644
--- a/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/transition.xmi
+++ b/epf_prac_151/practice.mgmt.risk_value_lifecycle.base/guidances/termdefinitions/transition.xmi
@@ -1,4 +1,5 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-yoFF90pq-_UV3fm-5oDenw" name=",_-5ms4EvDEdunZcj9T5hrMQ" guid="-yoFF90pq-_UV3fm-5oDenw" changeDate="2008-02-21T10:57:04.000-0800" version="7.2.0">
- <mainDescription>The fourth and last <span class="docEmphasis">phase</span> of the project lifecycle, which results in a final product <span class="docEmphasis">release</span>.</mainDescription>
+ <mainDescription>The fourth and last <span class="docEmphasis">phase</span> of the project lifecycle, which results in a final product <span
+class="docEmphasis">release</span>.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.team_change_mgmt.base/guidances/guidelines/submitting_change_requests.xmi b/epf_prac_151/practice.mgmt.team_change_mgmt.base/guidances/guidelines/submitting_change_requests.xmi
index 437b8ea..3ce82f1 100644
--- a/epf_prac_151/practice.mgmt.team_change_mgmt.base/guidances/guidelines/submitting_change_requests.xmi
+++ b/epf_prac_151/practice.mgmt.team_change_mgmt.base/guidances/guidelines/submitting_change_requests.xmi
@@ -1,62 +1,63 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-w7sImtXWkf4HDXdUWjRsUg" name="new_guideline,_fnZj0NVXEdqy9sbRhejO5Q" guid="-w7sImtXWkf4HDXdUWjRsUg" authors="Chris Sibbald" changeDate="2007-02-26T10:52:05.000-0800" changeDescription="Moved content from previous concept:change request to this guideline and updated in accordance with discussion from April 18, 2006 telecon." version="0.2">
- <mainDescription><h3>
- Background
-</h3>
-<p>
- Change requests typically have a lifecycle. They are raised, reviewed, accepted or rejected, implemented, verified,
- and closed. These states define the status of the change request at a particular point in time, and represent critical
- information for tracking progress. Other sets of states are possible.
-</p>
-<p>
- During review of a change request, the goal is to assess the technical, cost, and schedule impact
- of implementing the change. The technical impact assessment includes the determination of
- which work products are affected and an estimate of the level of effort required to change and verify all
- affected artifacts. This information becomes the basis of the cost and schedule impact assessments and, ultimately,
- whether the change request will be accepted or rejected.
-</p>
-<p>
- If accepted, the implementation and verification of the change request will be assigned to an iteration in the same
- manner as any other work item.
-</p>
-<p>
- The current process uses the <a class="elementLinkWithType" href="./../../../core.mgmt.common.extend_supp/workproducts/work_items_list_39D03CC8.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a> to capture, prioritize, and track the change requests
- using the attributes defined for that artifact.
-</p>
-<h3>
- Submitting change requests
-</h3>
-<p>
- When submitting a change request, provide as much information as possible to enable a speedy review and
- disposition. At a minimum, all change requests should include the following information:
-</p>
-<ul>
- <li>
- <strong>ID:</strong> A unique identifier for the change request to simplify tracking. If you are using some
- form of change tracking tool the tool will assign a unique ID.
- </li>
- <li>
- <strong>Brief Description:</strong> A name that summarizes the change request.
- </li>
- <li>
- <strong>Detailed Description:</strong> A detailed description of the change request. For a defect, if you
- can provide information that will help reproduce the defect please do so. For an enhancement request, provide
- a rationale for the request.
- </li>
- <li>
- <strong>Affected Item:</strong> The affected artifact and version.
- </li>
- <li>
- <strong>Severity:</strong> How severe is this issue (show stopper, nice to have, and so on)?
- </li>
- <li>
- <strong>Priority:</strong> How important this request is, in your opinion.
- </li>
-</ul>
-<p>
- Depending upon the system you are using, the names of these data elements may differ. However, this information
- is required, in one form or another, to permit speedy review and disposition of the change request.
-</p><br />
-<br />
+ <mainDescription><h3>
+ Background
+</h3>
+<p>
+ Change requests typically have a lifecycle. They are raised, reviewed, accepted or rejected, implemented, verified, and
+ closed. These states define the status of the change request at a particular point in time, and represent critical
+ information for tracking progress. Other sets of states are possible.
+</p>
+<p>
+ During review of a change request, the goal is to assess the technical, cost, and schedule impact of implementing the
+ change. The technical impact assessment includes the determination of which work products are affected and an estimate
+ of the level of effort required to change and verify all affected artifacts. This information becomes the basis of the
+ cost and schedule impact assessments and, ultimately, whether the change request will be accepted or rejected.
+</p>
+<p>
+ If accepted, the implementation and verification of the change request will be assigned to an iteration in the same
+ manner as any other work item.
+</p>
+<p>
+ The current process uses the <a class="elementLinkWithType"
+ href="./../../../core.mgmt.common.extend_supp/workproducts/work_items_list_39D03CC8.html"
+ guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a> to capture, prioritize, and track the change requests
+ using the attributes defined for that artifact.
+</p>
+<h3>
+ Submitting change requests
+</h3>
+<p>
+ When submitting a change request, provide as much information as possible to enable a speedy review and disposition. At
+ a minimum, all change requests should include the following information:
+</p>
+<ul>
+ <li>
+ <strong>ID:</strong> A unique identifier for the change request to simplify tracking. If you are using some form of
+ change tracking tool the tool will assign a unique ID.
+ </li>
+ <li>
+ <strong>Brief Description:</strong> A name that summarizes the change request.
+ </li>
+ <li>
+ <strong>Detailed Description:</strong> A detailed description of the change request. For a defect, if you can
+ provide information that will help reproduce the defect please do so. For an enhancement request, provide a
+ rationale for the request.
+ </li>
+ <li>
+ <strong>Affected Item:</strong> The affected artifact and version.
+ </li>
+ <li>
+ <strong>Severity:</strong> How severe is this issue (show stopper, nice to have, and so on)?
+ </li>
+ <li>
+ <strong>Priority:</strong> How important this request is, in your opinion.
+ </li>
+</ul>
+<p>
+ Depending upon the system you are using, the names of these data elements may differ. However, this information is
+ required, in one form or another, to permit speedy review and disposition of the change request.
+</p><br />
+<br />
<br /></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.team_change_mgmt.base/guidances/roadmaps/how_to_adopt.xmi b/epf_prac_151/practice.mgmt.team_change_mgmt.base/guidances/roadmaps/how_to_adopt.xmi
index 1608083..89b1616 100644
--- a/epf_prac_151/practice.mgmt.team_change_mgmt.base/guidances/roadmaps/how_to_adopt.xmi
+++ b/epf_prac_151/practice.mgmt.team_change_mgmt.base/guidances/roadmaps/how_to_adopt.xmi
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
-<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmi:id="-TuCzhSCW4ZtU_Z5h-cGwFQ" name="how_to_adopt,_ERIDQOMPEdyM47cGD2jiaQ" guid="-TuCzhSCW4ZtU_Z5h-cGwFQ" changeDate="2010-09-15T12:40:22.858-0700" version="7.2.0">
+<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-TuCzhSCW4ZtU_Z5h-cGwFQ" name="how_to_adopt,_ERIDQOMPEdyM47cGD2jiaQ" guid="-TuCzhSCW4ZtU_Z5h-cGwFQ" changeDate="2010-09-15T12:40:22.858-0700" version="7.2.0">
<mainDescription><h3>
- Getting started
+ Getting started&nbsp;
</h3>
<p>
Implementing an effective change management process requires agreement on the appropriate level of change control. Not
diff --git a/epf_prac_151/practice.mgmt.whole_team.assign/roles/analyst.assign_guidance.xmi b/epf_prac_151/practice.mgmt.whole_team.assign/roles/analyst.assign_guidance.xmi
index 8d426a4..4febe54 100644
--- a/epf_prac_151/practice.mgmt.whole_team.assign/roles/analyst.assign_guidance.xmi
+++ b/epf_prac_151/practice.mgmt.whole_team.assign/roles/analyst.assign_guidance.xmi
@@ -2,7 +2,9 @@
<org.eclipse.epf.uma:RoleDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-lviXbsQRcGsTcSjgLy1dvg" name="new_role,_z0iMcEIuEd2GCesTWQms8Q" guid="-lviXbsQRcGsTcSjgLy1dvg" changeDate="2008-06-24T01:49:00.000-0700" version="7.5.0">
<assignmentApproaches><ul>
<li>
- See <a class="elementLinkWithType" href="./../../practice.mgmt.whole_team.base/guidances/guidelines/self_organize_work_assignments_F47FC314.html" guid="_rmBEkJjsEduad8I_c-ogIA">Guideline: Self-Organize Work Assignments</a> to see how members of small agile
+ See <a class="elementLinkWithType"
+ href="./../../practice.mgmt.whole_team.base/guidances/guidelines/self_organize_work_assignments_F47FC314.html"
+ guid="_rmBEkJjsEduad8I_c-ogIA">Guideline: Self-Organize Work Assignments</a> to see how members of small agile
teams can share in this role.
</li>
</ul></assignmentApproaches>
diff --git a/epf_prac_151/practice.mgmt.whole_team.assign/roles/developer.assign_guidance.xmi b/epf_prac_151/practice.mgmt.whole_team.assign/roles/developer.assign_guidance.xmi
index ea7daa7..0c064ff 100644
--- a/epf_prac_151/practice.mgmt.whole_team.assign/roles/developer.assign_guidance.xmi
+++ b/epf_prac_151/practice.mgmt.whole_team.assign/roles/developer.assign_guidance.xmi
@@ -1,5 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:RoleDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-oM6mYVImOYC0xt47Ekbwmg" name=",_flg_MEihEd2O0_STOCj1Ow" guid="-oM6mYVImOYC0xt47Ekbwmg" changeDate="2008-07-02T06:44:25.000-0700" version="7.5.0">
- <assignmentApproaches>See <a class="elementLinkWithType" href="./../../practice.mgmt.whole_team.base/guidances/guidelines/self_organize_work_assignments_F47FC314.html" guid="_rmBEkJjsEduad8I_c-ogIA">Guideline: Self-Organize Work Assignments</a>&nbsp;for more information about how several
+ <assignmentApproaches>See <a class="elementLinkWithType"
+href="./../../practice.mgmt.whole_team.base/guidances/guidelines/self_organize_work_assignments_F47FC314.html"
+guid="_rmBEkJjsEduad8I_c-ogIA">Guideline: Self-Organize Work Assignments</a>&nbsp;for more information about how several
team members can fill this role.</assignmentApproaches>
</org.eclipse.epf.uma:RoleDescription>
diff --git a/epf_prac_151/practice.mgmt.whole_team.base/guidances/concepts/iteration_lifecycle.contribute.xmi b/epf_prac_151/practice.mgmt.whole_team.base/guidances/concepts/iteration_lifecycle.contribute.xmi
index 994d0dd..28f5f28 100644
--- a/epf_prac_151/practice.mgmt.whole_team.base/guidances/concepts/iteration_lifecycle.contribute.xmi
+++ b/epf_prac_151/practice.mgmt.whole_team.base/guidances/concepts/iteration_lifecycle.contribute.xmi
@@ -1,29 +1,30 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-3Poew8AinbZvOYouGiQx6A" name="new_concept,_SrioEE9wEd2FdckE7CIizQ" guid="-3Poew8AinbZvOYouGiQx6A" changeDate="2008-07-11T10:40:03.000-0700" version="7.5.0">
- <mainDescription><p> Team members work more effectively if they can influence what they do and
- how they do it, rather than operating in an environment where they are told
- what to do. Giving the team the ability and responsibility to organize their
- work and determine how to best meet their commitments motivates team members
- to do their best. This also helps them collaborate to ensure that the right
- skills are applied to the appropriate tasks. Self-organization impacts many
- areas, including how planning and commitments are made (by a team, not by individuals),
- how work is assigned (you sign up rather than get assigned), and how team members
- view their roles in the project (team member first, job function second). </p>
-<p> <a class="elementLinkWithUserText" href="./../../../practice.mgmt.whole_team.base/guidances/guidelines/self_organize_work_assignments_F47FC314.html" guid="_rmBEkJjsEduad8I_c-ogIA">Self-organization</a>&nbsp;requires
- a few things to work: </p>
-<ul>
-
- <li> Transparency and commitments are crucial to aid in team communication and
- to bring out the best in the team members. Open communication about the team's
- commitments related to the iteration lifecycle and personal commitments made
- relative to micro increments ensures that execution problems are vetted and
- the right people are focused on solving them. </li>
-
- <li> Coaching is required to help teams self-organize and to remove barriers
- for success. The assumption is that the project manager is the coach. This
- requires that the project manager avoid a command-and-control style of management
- in favor of a coaching style. This has been a key recommendation in management
- books for the last two decades, but some project managers may still not be
- able to make that transition. </li>
+ <mainDescription><p>
+ Team members work more effectively if they can influence what they do and how they do it, rather than operating in an
+ environment where they are told what to do. Giving the team the ability and responsibility to organize their work and
+ determine how to best meet their commitments motivates team members to do their best. This also helps them collaborate
+ to ensure that the right skills are applied to the appropriate tasks. Self-organization impacts many areas, including
+ how planning and commitments are made (by a team, not by individuals), how work is assigned (you sign up rather than
+ get assigned), and how team members view their roles in the project (team member first, job function second).
+</p>
+<p>
+ <a class="elementLinkWithUserText"
+ href="./../../../practice.mgmt.whole_team.base/guidances/guidelines/self_organize_work_assignments_F47FC314.html"
+ guid="_rmBEkJjsEduad8I_c-ogIA">Self-organization</a>&nbsp;requires a few things to work:
+</p>
+<ul>
+ <li>
+ Transparency and commitments are crucial to aid in team communication and to bring out the best in the team
+ members. Open communication about the team's commitments related to the iteration lifecycle and personal
+ commitments made relative to micro increments ensures that execution problems are vetted and the right people are
+ focused on solving them.
+ </li>
+ <li>
+ Coaching is required to help teams self-organize and to remove barriers for success. The assumption is that the
+ project manager is the coach. This requires that the project manager avoid a command-and-control style of
+ management in favor of a coaching style. This has been a key recommendation in management books for the last two
+ decades, but some project managers may still not be able to make that transition.
+ </li>
</ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.whole_team.base/guidances/concepts/whole_team.xmi b/epf_prac_151/practice.mgmt.whole_team.base/guidances/concepts/whole_team.xmi
index 8ad1efc..b4cbddc 100644
--- a/epf_prac_151/practice.mgmt.whole_team.base/guidances/concepts/whole_team.xmi
+++ b/epf_prac_151/practice.mgmt.whole_team.base/guidances/concepts/whole_team.xmi
@@ -1,97 +1,97 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-pXI3ZcdGOOyWtDdzIg2E7w" name="whole_team,_zLlDwEk5Ed2JToD8KCVSGA" guid="-pXI3ZcdGOOyWtDdzIg2E7w" changeDate="2008-10-13T03:20:19.000-0700" version="7.5.0">
- <mainDescription><h3>
- Introduction
-</h3>
-<p>
- <i>Whole Team</i> refers to the organization that delivers software for a project, and it includes any and all
- contributors (both direct and indirect participants) to the delivery. It creates a collaborative environment in which
- the "whole" team participates in setting direction, managing work efforts, and delivering the solution. Successful
- software delivery ultimately depends on people. This dependence means that the way people work together is a critical
- success factor.
-</p>
-<h4>
- Background
-</h4>
-<p>
- In some approaches to software development, customers and development managers tell developers what they want, when
- they want it, and how much it can cost. Assignments are handed out and deadlines set without discussion. This
- environment creates resentment among developers, managers, and customers. Developers also are asked or even expected to
- work whatever hours it takes to get the job done. In addition, barriers exist or are created between teams, causing
- team members to blame each other or pass the problem onto someone else.
-</p>
-<h4>
- Definition
-</h4>
-<p>
- Whole Team embraces the concept that to be successful in terms of quality, schedule, and scope, people must feel
- empowered to accomplish the project goals. This empowerment also means that the ultimate customer of the software must
- be an active and equal participant in the process. The Whole Team process focuses on the collaboration among all team
- members and the joint decision-making process. This approach creates an environment that ensures transparency and
- promotes collaboration on related work items. Additionally, the active involvement of end users, customers, and
- sponsors in the development process enhances the quality of the delivered product.
-</p>
-<h4>
- Misconceptions
-</h4>
-<p>
- Whole team does not mean that the entire team works on everything at once, as the name suggests. The real goal with the
- Whole Team approach is to ensure that the team works collectively to identify risks and to assign, deliver, test, and
- review work products.
-</p>
-<h4>
- Key aspects
-</h4>
-<p>
- The Whole Team approach encompasses the following key ideas:
-</p>
-<ul>
- <li>
- Collaboration across team members through:
- <ul>
- <li>
- Daily meetings
- </li>
- <li>
- Extended-team members
- </li>
- <li>
- Cross-functional teams organized around components
- </li>
- <li>
- Enabling technologies
- </li>
- </ul>
- </li>
- <li>
- Sustainable pace
- </li>
- <li>
- Work assignments are pulled instead of pushed
- </li>
- <li>
- Decision-making is made by people close to the decision
- </li>
- <li>
- Managers do not direct, but coach and lead
- </li>
- <li>
- Everyone participates and generates value
- </li>
- <li>
- Transparency of information and activities
- </li>
- <li>
- Open and honest communication
- </li>
-</ul>
-<h4>
- Business benefits
-</h4>
-<p>
- Whole Team practice enriches the software development environment, raising overall resource productivity and improving
- software quality. The Whole Team approach creates transparency, enabling all team members to be aware of all other work
- activities in the software development process. This transparency is of direct benefit to the end user for the software
- product being developed.
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ <i>Whole Team</i> refers to the organization that delivers software for a project, and it includes any and all
+ contributors (both direct and indirect participants) to the delivery. It creates a collaborative environment in which
+ the "whole" team participates in setting direction, managing work efforts, and delivering the solution. Successful
+ software delivery ultimately depends on people. This dependence means that the way people work together is a critical
+ success factor.
+</p>
+<h4>
+ Background
+</h4>
+<p>
+ In some approaches to software development, customers and development managers tell developers what they want, when
+ they want it, and how much it can cost. Assignments are handed out and deadlines set without discussion. This
+ environment creates resentment among developers, managers, and customers. Developers also are asked or even expected to
+ work whatever hours it takes to get the job done. In addition, barriers exist or are created between teams, causing
+ team members to blame each other or pass the problem onto someone else.
+</p>
+<h4>
+ Definition
+</h4>
+<p>
+ Whole Team embraces the concept that to be successful in terms of quality, schedule, and scope, people must feel
+ empowered to accomplish the project goals. This empowerment also means that the ultimate customer of the software must
+ be an active and equal participant in the process. The Whole Team process focuses on the collaboration among all team
+ members and the joint decision-making process. This approach creates an environment that ensures transparency and
+ promotes collaboration on related work items. Additionally, the active involvement of end users, customers, and
+ sponsors in the development process enhances the quality of the delivered product.
+</p>
+<h4>
+ Misconceptions
+</h4>
+<p>
+ Whole team does not mean that the entire team works on everything at once, as the name suggests. The real goal with the
+ Whole Team approach is to ensure that the team works collectively to identify risks and to assign, deliver, test, and
+ review work products.
+</p>
+<h4>
+ Key aspects
+</h4>
+<p>
+ The Whole Team approach encompasses the following key ideas:
+</p>
+<ul>
+ <li>
+ Collaboration across team members through: 
+ <ul>
+ <li>
+ Daily meetings
+ </li>
+ <li>
+ Extended-team members
+ </li>
+ <li>
+ Cross-functional teams organized around components
+ </li>
+ <li>
+ Enabling technologies
+ </li>
+ </ul>
+ </li>
+ <li>
+ Sustainable pace
+ </li>
+ <li>
+ Work assignments are pulled instead of pushed
+ </li>
+ <li>
+ Decision-making is made by people close to the decision
+ </li>
+ <li>
+ Managers do not direct, but coach and lead
+ </li>
+ <li>
+ Everyone participates and generates value
+ </li>
+ <li>
+ Transparency of information and activities
+ </li>
+ <li>
+ Open and honest communication
+ </li>
+</ul>
+<h4>
+ Business benefits
+</h4>
+<p>
+ Whole Team practice enriches the software development environment, raising overall resource productivity and improving
+ software quality. The Whole Team approach creates transparency, enabling all team members to be aware of all other work
+ activities in the software development process. This transparency is of direct benefit to the end user for the software
+ product being developed.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.whole_team.base/guidances/guidelines/daily_meetings.xmi b/epf_prac_151/practice.mgmt.whole_team.base/guidances/guidelines/daily_meetings.xmi
index b63af13..77f9531 100644
--- a/epf_prac_151/practice.mgmt.whole_team.base/guidances/guidelines/daily_meetings.xmi
+++ b/epf_prac_151/practice.mgmt.whole_team.base/guidances/guidelines/daily_meetings.xmi
@@ -1,69 +1,83 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-zqsjK1qfcSGuOsNO5K7UhA" name="new_guideline,_251UMCmREdyy6Oss2-0s1g" guid="-zqsjK1qfcSGuOsNO5K7UhA" changeDate="2008-07-11T09:35:04.000-0700" version="7.2.0">
- <mainDescription><h3>
- Practices
-</h3>
-<p> Daily meetings are also known as<i> scrum</i> meetings <a class="elementLinkWithUserText" href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#SCH04" guid="_JlTPUM6aEdyuBO4ZIzcyig">[SCH04]</a>.
- These meetings help check the&nbsp;heartbeat of the project. All team members
- are required to attend. The meetings are held in the same place at the same
- time every work day and should&nbsp;not last for more than 15 minutes. Usually,
- teams conduct the meetings with everyone standing up to keep them short (thus
- some call them &quot;standup&quot; meetings). Anyone who is directly involved&nbsp;can
- also attend the meeting as an observer, but care should be taken because too
- many people in the meeting may cause disruption or cause people to be uncomfortable
- in sharing information. Typical daily meetings should have 10 people at most.
-</p>
-During the daily meeting, each team member updates peers with answers to the following
-three questions <a class="elementLinkWithUserText" href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#SCH04" guid="_JlTPUM6aEdyuBO4ZIzcyig">[SCH04]</a>:
-<ol>
-
- <li> What did I do yesterday?</li>
- <li>
- What will I do today?
- </li>
- <li>
- What is impeding my work?
- </li>
-</ol>
-<p> These three questions have a specific purpose [<a class="elementLinkWithUserText" href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#SUT06" guid="_9ToeIB83Edqsvps02rpOOg">SUT06</a>]:
-</p>
-<ul>
-
- <li> The first question tests the focus of the team. Anything done that was
- not work planned for the iteration is questioned. </li>
-
- <li> Answering the second question revises project strategy daily by reorienting
- the team according to dependency changes that were revealed by the response
- to the previous question. </li>
-
- <li> The third question will create issues that may result in new tasks in the
- Work Items list. The most important effect of this question is to create a
- list of issues that are assigned to the team or to managers.&nbsp;The team
- should expect management to help eliminate bottlenecks.&nbsp; </li>
-</ul>
-<p> These are the minimum number of questions that satisfy the goals of daily
- meetings. Experienced practitioners tend to add an additional question for improving
- collaboration among team members: "What have I learned or decided that is of
- relevance to the team?" [<a class="elementLinkWithUserText" href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#LAR03" guid="_9ToeIB83Edqsvps02rpOOg">LAR03</a>].&nbsp;"What
- might help or hinder others in meeting their commitments?" [<a class="elementLinkWithUserText" href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#YIP" guid="_9ToeIB83Edqsvps02rpOOg">YIP</a>].
- Other topics of discussion (design discussions, chat, and such) should be deferred
- until after the meeting. </p>
-<h4>
- Value
-</h4>
-<p> For self-directed teams, the daily meeting is a mechanism to quickly inform
- the team about the state of the project and people. It supports openness and
- enables resolution of dependencies and conflicts in real time. It builds a team;
- effective teams are built by regularly communicating, sharing commitments, and
- helping each other. [<a class="elementLinkWithUserText" href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#LAR03" guid="_9ToeIB83Edqsvps02rpOOg">LAR03</a>]</p>
- <h3>
- What a daily meeting is not </h3>
-<p>
- The daily meeting is not a status update meeting in which the project manager is collecting information about who is
- behind schedule. Rather, it is a meeting in which team members make commitments to each other.<br />
- <br />
- Neither is it a problem-solving nor issue resolution meeting. Issues that are
- raised are registered and usually dealt with by the relevant team members immediately
- afterward. It is the project manager's responsibility to resolve them as quickly
- as possible or to make sure that someone on the team does. </p></mainDescription>
+ <mainDescription><h3>
+ Practices
+</h3>
+<p>
+ Daily meetings are also known as <i>scrum</i> meetings <a class="elementLinkWithUserText"
+ href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#SCH04"
+ guid="_JlTPUM6aEdyuBO4ZIzcyig">[SCH04]</a>. These meetings help check the&nbsp;heartbeat of the project. All team
+ members are required to attend. The meetings are held in the same place at the same time every work day and
+ should&nbsp;not last for more than 15 minutes. Usually, teams conduct the meetings with everyone standing up to keep
+ them short (thus some call them "standup" meetings). Anyone who is directly involved&nbsp;can also attend the meeting
+ as an observer, but care should be taken because too many people in the meeting may cause disruption or cause people to
+ be uncomfortable in sharing information. Typical daily meetings should have 10 people at most.
+</p>During the daily meeting, each team member updates peers with answers to the following three questions <a
+class="elementLinkWithUserText"
+href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#SCH04"
+guid="_JlTPUM6aEdyuBO4ZIzcyig">[SCH04]</a>: 
+<ol>
+ <li>
+ What did I do yesterday?
+ </li>
+ <li>
+ What will I do today?
+ </li>
+ <li>
+ What is impeding my work?
+ </li>
+</ol>
+<p>
+ These three questions have a specific purpose [<a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#SUT06"
+ guid="_9ToeIB83Edqsvps02rpOOg">SUT06</a>]:
+</p>
+<ul>
+ <li>
+ The first question tests the focus of the team. Anything done that was not work planned for the iteration is
+ questioned.
+ </li>
+ <li>
+ Answering the second question revises project strategy daily by reorienting the team according to dependency
+ changes that were revealed by the response to the previous question.
+ </li>
+ <li>
+ The third question will create issues that may result in new tasks in the Work Items list. The most important
+ effect of this question is to create a list of issues that are assigned to the team or to managers.&nbsp;The team
+ should expect management to help eliminate bottlenecks.&nbsp;
+ </li>
+</ul>
+<p>
+ These are the minimum number of questions that satisfy the goals of daily meetings. Experienced practitioners tend to
+ add an additional question for improving collaboration among team members: "What have I learned or decided that is of
+ relevance to the team?" [<a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#LAR03"
+ guid="_9ToeIB83Edqsvps02rpOOg">LAR03</a>].&nbsp;"What might help or hinder others in meeting their commitments?" [<a
+ class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#YIP"
+ guid="_9ToeIB83Edqsvps02rpOOg">YIP</a>]. Other topics of discussion (design discussions, chat, and such) should be
+ deferred until after the meeting.
+</p>
+<h4>
+ Value
+</h4>
+<p>
+ For self-directed teams, the daily meeting is a mechanism to quickly inform the team about the state of the project and
+ people. It supports openness and enables resolution of dependencies and conflicts in real time. It builds a team;
+ effective teams are built by regularly communicating, sharing commitments, and helping each other. [<a
+ class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#LAR03"
+ guid="_9ToeIB83Edqsvps02rpOOg">LAR03</a>]
+</p>
+<h3>
+ What a daily meeting is not
+</h3>
+<p>
+ The daily meeting is not a status update meeting in which the project manager is collecting information about who is
+ behind schedule. Rather, it is a meeting in which team members make commitments to each other.<br />
+ <br />
+ Neither is it a problem-solving nor issue resolution meeting. Issues that are raised are registered and usually dealt
+ with by the relevant team members immediately afterward. It is the project manager's responsibility to resolve them as
+ quickly as possible or to make sure that someone on the team does.
+</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.whole_team.base/guidances/guidelines/maintain_a_sustainable_pace.xmi b/epf_prac_151/practice.mgmt.whole_team.base/guidances/guidelines/maintain_a_sustainable_pace.xmi
index 9e1d7a7..485514e 100644
--- a/epf_prac_151/practice.mgmt.whole_team.base/guidances/guidelines/maintain_a_sustainable_pace.xmi
+++ b/epf_prac_151/practice.mgmt.whole_team.base/guidances/guidelines/maintain_a_sustainable_pace.xmi
@@ -1,44 +1,48 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-aoCtIwigi2NOLiclMAXvgQ" name="new_guideline,_KzYHYMLmEdysDsQChI42QQ" guid="-aoCtIwigi2NOLiclMAXvgQ" changeDate="2008-06-18T00:04:51.000-0700" version="7.2.0">
- <mainDescription><p> <i>Sustainable pace </i>is the rate of work that a team can consistently maintain
- without burning out team members. This concept was popularized by the Extreme
- Programming (XP) methodology with its 40-hour work week practice, which later
- evolved into the more generic "sustainable pace."&nbsp;The basic idea is that,
- although a team can have brief spurts of overtime (perhaps for a week or two&nbsp;at
- a time during critical periods during a project lifecycle), it cannot maintain
- that pace indefinitely.&nbsp;This is analogous to the concept that you cannot
- sprint throughout a marathon. </p>
-<p>
- Strategies to help maintain a sustainable pace:
-</p>
-<ul>
- <li><strong>Build activities into everyday work</strong>.&nbsp;This avoids the
- problem that the activity is scheduled into a specific period and, therefore,
- must&nbsp;be accomplished regardless of how much effort it requires. For example,
- instead of leaving testing to the end of a project, test all the way through
- the project.&nbsp;Instead of modeling only at the beginning of a project,
- model all the way through only when you need the relevant information and
- only to the extent that you currently need.&nbsp;&nbsp; </li>
- <li><strong>Organize the project into short iterations</strong>.&nbsp;Short
- iterations provide the opportunity for small "pebbles" (which show progress)
- rather than huge "milestones."&nbsp;Continuous feedback reduces the&nbsp;need&nbsp;to
- work long hours. Also,&nbsp;it helps focus on finding ways to consistently
- achieve the regular deliveries. </li>
- <li><strong>Adopt a continuous integration strategy</strong>.&nbsp;By frequently
- merging code, compiling it, testing it, and running appropriate code analysis
- against it, you increase the quality of your work through finding and then
- fixing defects quickly and easily.&nbsp;This reduces the chance of major problems
- in your work, thereby reducing a primary motivator of unexpected overtime.&nbsp;
- </li>
- <li><strong>Question long hours</strong>.&nbsp;Productivity does not increase
- with hours worked.&nbsp;Tired people are far&nbsp;less productive than well-rested
- ones. </li>
- <li><strong>Recognize sustained overtime as a failure</strong>.&nbsp;If a team
- needs to work overtime for more than&nbsp;two weeks in a row, that is a reflection
- of poor planning or&nbsp;inadequate resources allocation.&nbsp; </li>
- <li><strong>Recognize that you're still working hard at a sustainable pace</strong>.&nbsp;Just
- because you are working at a sustainable pace, it&nbsp;doesn't mean that the
- team is not working hard enough. Rather, it is&nbsp;typically an indication
- that&nbsp;the team is&nbsp;a "well-oiled machine.&quot;</li>
+ <mainDescription><p>
+ <i>Sustainable pace</i> is the rate of work that a team can consistently maintain without burning out team members.
+ This concept was popularized by the Extreme Programming (XP) methodology with its 40-hour work week practice, which
+ later evolved into the more generic "sustainable pace."&nbsp;The basic idea is that, although a team can have brief
+ spurts of overtime (perhaps for a week or two&nbsp;at a time during critical periods during a project lifecycle), it
+ cannot maintain that pace indefinitely.&nbsp;This is analogous to the concept that you cannot sprint throughout a
+ marathon.
+</p>
+<p>
+ Strategies to help maintain a sustainable pace:
+</p>
+<ul>
+ <li>
+ <strong>Build activities into everyday work</strong>.&nbsp;This avoids the problem that the activity is scheduled
+ into a specific period and, therefore, must&nbsp;be accomplished regardless of how much effort it requires. For
+ example, instead of leaving testing to the end of a project, test all the way through the project.&nbsp;Instead of
+ modeling only at the beginning of a project, model all the way through only when you need the relevant information
+ and only to the extent that you currently need.&nbsp;&nbsp;
+ </li>
+ <li>
+ <strong>Organize the project into short iterations</strong>.&nbsp;Short iterations provide the opportunity for
+ small "pebbles" (which show progress) rather than huge "milestones."&nbsp;Continuous feedback reduces
+ the&nbsp;need&nbsp;to work long hours. Also,&nbsp;it helps focus on finding ways to consistently achieve the
+ regular deliveries.
+ </li>
+ <li>
+ <strong>Adopt a continuous integration strategy</strong>.&nbsp;By frequently merging code, compiling it, testing
+ it, and running appropriate code analysis against it, you increase the quality of your work through finding and
+ then fixing defects quickly and easily.&nbsp;This reduces the chance of major problems in your work, thereby
+ reducing a primary motivator of unexpected overtime.&nbsp;
+ </li>
+ <li>
+ <strong>Question long hours</strong>.&nbsp;Productivity does not increase with hours worked.&nbsp;Tired people are
+ far&nbsp;less productive than well-rested ones.
+ </li>
+ <li>
+ <strong>Recognize sustained overtime as a failure</strong>.&nbsp;If a team needs to work overtime for more
+ than&nbsp;two weeks in a row, that is a reflection of poor planning or&nbsp;inadequate resources allocation.&nbsp;
+ </li>
+ <li>
+ <strong>Recognize that you're still working hard at a sustainable pace</strong>.&nbsp;Just because you are working
+ at a sustainable pace, it&nbsp;doesn't mean that the team is not working hard enough. Rather, it is&nbsp;typically
+ an indication that&nbsp;the team is&nbsp;a "well-oiled machine."
+ </li>
</ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.whole_team.base/guidances/guidelines/self_organize_work_assignments.xmi b/epf_prac_151/practice.mgmt.whole_team.base/guidances/guidelines/self_organize_work_assignments.xmi
index 65bc087..e79a38d 100644
--- a/epf_prac_151/practice.mgmt.whole_team.base/guidances/guidelines/self_organize_work_assignments.xmi
+++ b/epf_prac_151/practice.mgmt.whole_team.base/guidances/guidelines/self_organize_work_assignments.xmi
@@ -1,93 +1,93 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-e26WOHRbTVQrDssK5zijVA" name="self_organize_work_assignments,_rmBEkJjsEduad8I_c-ogIA" guid="-e26WOHRbTVQrDssK5zijVA" changeDate="2009-08-07T02:16:30.000-0700" version="1.0.0">
- <mainDescription><p>
- A "self-organizing team" has the authority to choose the work that it will perform and the responsibility to do that
- work in the way that it chooses.&nbsp; These are important aspects of a self-organizing team:
-</p>
-<ul>
- <li>
- <b>The team selects its own work.</b> At the beginning of a work cycle, the team collectively selects the work from
- the prioritized project work. Work selection is performed within given constraints, including the priorities set by
- stakeholders, time (such as the length of the current work cycle, iteration or project increment), the budget, and
- the skills of team members.
- </li>
- <li>
- <b>Individuals select their own work.</b> Someone will choose to do something because they are good at it and know
- that they can do the work effectively, because they want to gain more experience at something and hope to improve
- their skills by working with someone with such experience, or because they know that the work needs to be done and
- that it's their turn to do so. Although an individual fulfills one or more roles on a project team, that doesn't
- imply that the person is constrained to doing only specific types of work.
- </li>
- <li>
- <b>The team determines how to perform the work.</b> At the beginning of a work cycle, the team holds an "all hands"
- planning meeting where it determines the general strategy for doing the work and the tasks required for that. More
- detailed planning, if required, will be done on a just-in-time&nbsp;basis by the individuals doing the work. Notice
- that the team is still constrained by your organization's standards, technical infrastructure, regulations, and so
- on.
- </li>
- <li>
- <b>Everyone commits to the work.</b> The team commits to accomplishing the work that it has agreed to do by the end
- of the&nbsp;work cycle. Individuals also commit to doing the work that they say they will do in that cycle,
- although as the&nbsp;time progresses, various tasks may be renegotiated as required.
- </li>
- <li>
- <b>The team coordinates regularly.</b> To ensure that the work is accomplished, the team must coordinate its
- efforts effectively. This is typically done through daily standup (scrum) meetings of the team and impromptu
- discussions between individuals.
- </li>
-</ul>
-<p>
- This is a participatory approach to decision-making, where everyone has the opportunity to provide input and to listen
- to the decision-making process. The goals are to make decisions at the right place within the organizational structure
- and to empower teams by giving them both the responsibility and the authority to get the job done. Giving them control
- over their work improves motivation among team members and, thereby, their productivity.
-</p>
-<h3>
- Project manager responsibilities
-</h3>
-<p>
- There is still work for the project manager on self-organizing teams:
-</p>
-<ul>
- <li>
- <b>Provide leadership.</b> Team culture and project vision must be nurtured and must evolve throughout the project,
- and direction must be provided to the team.
- </li>
- <li>
- <b>Mediate disagreements.</b> The manager must be prepared to step in and make a decision when other team members
- are unable to reach a decision.
- </li>
- <li>
- <b>Ensure that team members increase their skill sets.</b> From time to time, the manager may need to motivate
- individuals to take on new tasks that are outside of their comfort zones or to work with others to help those
- people gain new skills.
- </li>
- <li>
- <b>Ensure that the team respects their limits.</b> Self-organizing teams have the authority to make decisions
- within the scope of their responsibility, but that doesn't mean that they get to rethink everything that they feel
- like changing. For example, the development team must still conform to the technical infrastructure and to the
- business strategy of your organization; they probably do not have the authority to change these things even though
- they may not fully agree with them. When an issue falls outside of their scope of responsibility, the team must
- either accept it or collaborate with the people with the appropriate authority.
- </li>
- <li>
- <b>Summarize the project plan.</b> External stakeholders, such as senior management or business representatives not
- actively involved with the team, will want to know the current status of the project and the team's current plans.
- The project manager may be required to summarize and communicate this information to those people.
- </li>
-</ul>
-<h3>
- What "self-organizing" does not mean
-</h3>
-<p>
- The concept of self-organizing teams often sounds like anarchy or non-management to traditional IT professionals, but
- this is not true. Although self-organization relies on team members being responsible and mature, it is tempered by the
- guiding hand of a good project manager. It is also tempered by organizational standards, infrastructure, and external
- regulations. "Self-organizing" doesn't mean that you have complete freedom to do what you want.
-</p>
-<p>
- Self-organization isn't necessarily a consensus-based approach either. Sometimes, individuals will disagree with a
- decision but will choose to go along with the will of the team. Consensus decision-making isn't ruled out by this
- approach. but it certainly isn't required.
+ <mainDescription><p>
+ A "self-organizing team" has the authority to choose the work that it will perform and the responsibility to do that
+ work in the way that it chooses.&nbsp; These are important aspects of a self-organizing team:
+</p>
+<ul>
+ <li>
+ <b>The team selects its own work.</b> At the beginning of a work cycle, the team collectively selects the work from
+ the prioritized project work. Work selection is performed within given constraints, including the priorities set by
+ stakeholders, time (such as the length of the current work cycle, iteration or project increment), the budget, and
+ the skills of team members.
+ </li>
+ <li>
+ <b>Individuals select their own work.</b> Someone will choose to do something because they are good at it and know
+ that they can do the work effectively, because they want to gain more experience at something and hope to improve
+ their skills by working with someone with such experience, or because they know that the work needs to be done and
+ that it's their turn to do so. Although an individual fulfills one or more roles on a project team, that doesn't
+ imply that the person is constrained to doing only specific types of work.
+ </li>
+ <li>
+ <b>The team determines how to perform the work.</b> At the beginning of a work cycle, the team holds an "all hands"
+ planning meeting where it determines the general strategy for doing the work and the tasks required for that. More
+ detailed planning, if required, will be done on a just-in-time&nbsp;basis by the individuals doing the work. Notice
+ that the team is still constrained by your organization's standards, technical infrastructure, regulations, and so
+ on.
+ </li>
+ <li>
+ <b>Everyone commits to the work.</b> The team commits to accomplishing the work that it has agreed to do by the end
+ of the&nbsp;work cycle. Individuals also commit to doing the work that they say they will do in that cycle,
+ although as the&nbsp;time progresses, various tasks may be renegotiated as required.
+ </li>
+ <li>
+ <b>The team coordinates regularly.</b> To ensure that the work is accomplished, the team must coordinate its
+ efforts effectively. This is typically done through daily standup (scrum) meetings of the team and impromptu
+ discussions between individuals.
+ </li>
+</ul>
+<p>
+ This is a participatory approach to decision-making, where everyone has the opportunity to provide input and to listen
+ to the decision-making process. The goals are to make decisions at the right place within the organizational structure
+ and to empower teams by giving them both the responsibility and the authority to get the job done. Giving them control
+ over their work improves motivation among team members and, thereby, their productivity.
+</p>
+<h3>
+ Project manager responsibilities
+</h3>
+<p>
+ There is still work for the project manager on self-organizing teams:
+</p>
+<ul>
+ <li>
+ <b>Provide leadership.</b> Team culture and project vision must be nurtured and must evolve throughout the project,
+ and direction must be provided to the team.
+ </li>
+ <li>
+ <b>Mediate disagreements.</b> The manager must be prepared to step in and make a decision when other team members
+ are unable to reach a decision.
+ </li>
+ <li>
+ <b>Ensure that team members increase their skill sets.</b> From time to time, the manager may need to motivate
+ individuals to take on new tasks that are outside of their comfort zones or to work with others to help those
+ people gain new skills.
+ </li>
+ <li>
+ <b>Ensure that the team respects their limits.</b> Self-organizing teams have the authority to make decisions
+ within the scope of their responsibility, but that doesn't mean that they get to rethink everything that they feel
+ like changing. For example, the development team must still conform to the technical infrastructure and to the
+ business strategy of your organization; they probably do not have the authority to change these things even though
+ they may not fully agree with them. When an issue falls outside of their scope of responsibility, the team must
+ either accept it or collaborate with the people with the appropriate authority.
+ </li>
+ <li>
+ <b>Summarize the project plan.</b> External stakeholders, such as senior management or business representatives not
+ actively involved with the team, will want to know the current status of the project and the team's current plans.
+ The project manager may be required to summarize and communicate this information to those people.
+ </li>
+</ul>
+<h3>
+ What "self-organizing" does not mean
+</h3>
+<p>
+ The concept of self-organizing teams often sounds like anarchy or non-management to traditional IT professionals, but
+ this is not true. Although self-organization relies on team members being responsible and mature, it is tempered by the
+ guiding hand of a good project manager. It is also tempered by organizational standards, infrastructure, and external
+ regulations. "Self-organizing" doesn't mean that you have complete freedom to do what you want.
+</p>
+<p>
+ Self-organization isn't necessarily a consensus-based approach either. Sometimes, individuals will disagree with a
+ decision but will choose to go along with the will of the team. Consensus decision-making isn't ruled out by this
+ approach. but it certainly isn't required.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.mgmt.whole_team.base/guidances/practices/whole_team.xmi b/epf_prac_151/practice.mgmt.whole_team.base/guidances/practices/whole_team.xmi
index 5e256be..6c388aa 100644
--- a/epf_prac_151/practice.mgmt.whole_team.base/guidances/practices/whole_team.xmi
+++ b/epf_prac_151/practice.mgmt.whole_team.base/guidances/practices/whole_team.xmi
@@ -1,74 +1,86 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:PracticeDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-UGMg9CCG8I3qxV2ew6EVLw" name="new_practice,_6C4sMB4rEd2bS8fFOQ7WWA" guid="-UGMg9CCG8I3qxV2ew6EVLw" changeDate="2008-10-13T02:58:02.000-0700" version="7.5.0">
- <mainDescription><p> Whole teams are self-organizing, cross-functional, fluid, and highly collaborative.&nbsp;</p>
-<p><i>Self-organization </i>means&nbsp;that&nbsp;everyone on the team works together
- to determine the best way to perform the&nbsp;work required fulfilling the goals
- of the team.&nbsp;</p>
-<p>A <i>whole team </i>is cross-functional, containing people with the combined
- expertise to perform the work.&nbsp;This includes people with modeling skills,
- testing skills, management skills, and programming skills. It also includes
- stakeholders with the required domain knowledge.&nbsp;</p>
-<p><i>Fluidity</i> refers to the idea that the team composition will vary over
- time.&nbsp;For example, at the beginning of the project, you may need someone
- with deep build experience to help organize the team's build strategy, but after
- this work is finished, this person leaves the team.&nbsp;Whole teams work in&nbsp;a
- highly collaborative manner, adopting the most effective communication techniques
- for their situations and striving to work together as closely as possible. It
- is through collaboration that people make each other better. </p>
-<p>
- The goal of the&nbsp;Whole Team&nbsp;practice is to ensure that:
-</p>
-<ul>
- <li> <strong>Everyone has a sense of belonging on the team, of being in it together.</strong>&nbsp;There
- should be no "outsiders," no "them" but only "us.&quot;&nbsp;When everyone
- is on the team,&nbsp;people&nbsp;avoid&nbsp;blaming others. Instead, there
- is&nbsp;a sense of&nbsp;collective ownership. </li>
- <li> <strong>The team includes everyone required to build the system.</strong>&nbsp;Ideally,
- you want a self-contained team that has the skills and knowledge to get the
- job done.&nbsp;Realistically, this is not&nbsp;always possible at all points,
- and sometimes you will need to bring in outside experts for brief periods
- of time for specific goals.&nbsp;For example, you might need someone with
- experience at setting up the database at the beginning of the project or,
- in the middle of the project, someone with specific expertise in a certain
- aspect of the domain. </li>
- <li> <strong>Everyone on the team contributes any way that they can.</strong>&nbsp;With
- a whole team approach there is a move&nbsp;away from specialists who focus
- on a specific category of work, such as&nbsp;analysis or&nbsp;database administration,&nbsp;towards
- generalizing specialists who may have that expertise&nbsp;but will also work
- outside of their specialty to help&nbsp;address the current need.&nbsp; &nbsp;
- </li>
- <li> <strong>The team is self-organizing.</strong>&nbsp;The people best-suited
- to plan and organize the work are the ones who do the work. This results in&nbsp;better
- estimates (particularly when people know that they'll be held to those estimates),
- more realistic schedules, and increased acceptance of the plan by the team.
- </li>
- <li> <strong><strong>The team maintains a sustainable pace.</strong></strong>&nbsp;
- Just as you don't sprint throughout a marathon, you can't go for weeks or
- months at a time working unrealistic levels of overtime.&nbsp;Tired people
- are not productive people. </li>
- <li> <strong>Everyone works together closely.&nbsp;</strong>Not only is it safer,
- it is better to ask others for help when you need it.&nbsp;Another&nbsp;strategy
- for improving collaboration within the team is to have daily standup (scrum)
- meetings where you share your current status and explain any problems that
- you might have.&nbsp;Non-solo development practices, such as pair programming
- and modeling with others, are also common in the Whole Team approach. </li>
-</ul></mainDescription>
- <additionalInfo><p> For more information on the Whole Team approach: </p>
+ <mainDescription><p>
+ Whole teams are self-organizing, cross-functional, fluid, and highly collaborative.&nbsp;
+</p>
+<p>
+ <i>Self-organization</i> means&nbsp;that&nbsp;everyone on the team works together to determine the best way to perform
+ the&nbsp;work required fulfilling the goals of the team.&nbsp;
+</p>
+<p>
+ A <i>whole team</i> is cross-functional, containing people with the combined expertise to perform the work.&nbsp;This
+ includes people with modeling skills, testing skills, management skills, and programming skills. It also includes
+ stakeholders with the required domain knowledge.&nbsp;
+</p>
+<p>
+ <i>Fluidity</i> refers to the idea that the team composition will vary over time.&nbsp;For example, at the beginning of
+ the project, you may need someone with deep build experience to help organize the team's build strategy, but after this
+ work is finished, this person leaves the team.&nbsp;Whole teams work in&nbsp;a highly collaborative manner, adopting
+ the most effective communication techniques for their situations and striving to work together as closely as possible.
+ It is through collaboration that people make each other better.
+</p>
+<p>
+ The goal of the&nbsp;Whole Team&nbsp;practice is to ensure that:
+</p>
<ul>
- <li> 
- <p class="parseasinTitle"> <span id="btAsinTitle"><i>Extreme Programming Explained: 
- Embrace Change</i> (2nd Edition)</span> by Kent Beck and Cynthia Andres 
- (Addison-Wesley Professional, 2004)</p>
- </li>
- <li> 
- <p class="parseasinTitle"> <a href="http://www.agilemodeling.com/essays/generalizingSpecialists.htm" target="_blank">Generalizing 
- Specialists</a> by Scott W. Ambler </p>
- </li>
+ <li>
+ <strong>Everyone has a sense of belonging on the team, of being in it together.</strong>&nbsp;There should be no
+ "outsiders," no "them" but only "us."&nbsp;When everyone is on the team,&nbsp;people&nbsp;avoid&nbsp;blaming
+ others. Instead, there is&nbsp;a sense of&nbsp;collective ownership.
+ </li>
+ <li>
+ <strong>The team includes everyone required to build the system.</strong>&nbsp;Ideally, you want a self-contained
+ team that has the skills and knowledge to get the job done.&nbsp;Realistically, this is not&nbsp;always possible at
+ all points, and sometimes you will need to bring in outside experts for brief periods of time for specific
+ goals.&nbsp;For example, you might need someone with experience at setting up the database at the beginning of the
+ project or, in the middle of the project, someone with specific expertise in a certain aspect of the domain.
+ </li>
+ <li>
+ <strong>Everyone on the team contributes any way that they can.</strong>&nbsp;With a whole team approach there is a
+ move&nbsp;away from specialists who focus on a specific category of work, such as&nbsp;analysis or&nbsp;database
+ administration,&nbsp;towards generalizing specialists who may have that expertise&nbsp;but will also work outside
+ of their specialty to help&nbsp;address the current need.&nbsp; &nbsp;
+ </li>
+ <li>
+ <strong>The team is self-organizing.</strong>&nbsp;The people best-suited to plan and organize the work are the
+ ones who do the work. This results in&nbsp;better estimates (particularly when people know that they'll be held to
+ those estimates), more realistic schedules, and increased acceptance of the plan by the team.
+ </li>
+ <li>
+ <strong><strong>The team maintains a sustainable pace.</strong></strong>&nbsp; Just as you don't sprint throughout
+ a marathon, you can't go for weeks or months at a time working unrealistic levels of overtime.&nbsp;Tired people
+ are not productive people.
+ </li>
+ <li>
+ <strong>Everyone works together closely.&nbsp;</strong>Not only is it safer, it is better to ask others for help
+ when you need it.&nbsp;Another&nbsp;strategy for improving collaboration within the team is to have daily standup
+ (scrum) meetings where you share your current status and explain any problems that you might have.&nbsp;Non-solo
+ development practices, such as pair programming and modeling with others, are also common in the Whole Team
+ approach.
+ </li>
+</ul></mainDescription>
+ <additionalInfo><p>
+ For more information on the Whole Team approach:
+</p>
+<ul>
+ <li>
+ <p class="parseasinTitle">
+ <span id="btAsinTitle"><i>Extreme Programming Explained: Embrace Change</i> (2nd Edition)</span> by Kent Beck
+ and Cynthia Andres (Addison-Wesley Professional, 2004)
+ </p>
+ </li>
+ <li>
+ <p class="parseasinTitle">
+ <a href="http://www.agilemodeling.com/essays/generalizingSpecialists.htm" target="_blank">Generalizing
+ Specialists</a> by Scott W. Ambler
+ </p>
+ </li>
</ul></additionalInfo>
- <problem><p> The single most important productivity factor is the people on the team and 
- the way that they interact.&nbsp;The Whole Team practice describes strategies 
- to increase overall productivity through streamlining the organization structure 
- of the team and through streamlining collaboration within the team. </p></problem>
+ <problem><p>
+ The single most important productivity factor is the people on the team and the way that they interact.&nbsp;The Whole
+ Team practice describes strategies to increase overall productivity through streamlining the organization structure of
+ the team and through streamlining collaboration within the team.
+</p></problem>
<application><p>
These are the three best ways to understand this practice:
</p>
diff --git a/epf_prac_151/practice.mgmt.whole_team.base/guidances/roadmaps/how_to_adopt.xmi b/epf_prac_151/practice.mgmt.whole_team.base/guidances/roadmaps/how_to_adopt.xmi
index 24531db..76a0b25 100644
--- a/epf_prac_151/practice.mgmt.whole_team.base/guidances/roadmaps/how_to_adopt.xmi
+++ b/epf_prac_151/practice.mgmt.whole_team.base/guidances/roadmaps/how_to_adopt.xmi
@@ -1,60 +1,72 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-kGPLyLlIylW-w3B0RlwbwQ" name="how_to_adopt,_ERIDQOMPEdyM47cGD2jiaQ" guid="-kGPLyLlIylW-w3B0RlwbwQ" changeDate="2008-07-21T08:29:01.000-0700" version="7.2.0">
- <mainDescription><h3> Getting started&nbsp; </h3>
-<p>
- There are several steps to get started with the Whole Team practice.
-</p>
-<p><b>Understand the underlying philosophies behind this practice.&nbsp;</b><br />
- These philosophies are captured in the&nbsp;<a class="elementLink" href="./../../../practice.mgmt.whole_team.base/guidances/guidelines/self_organize_work_assignments_F47FC314.html" guid="_rmBEkJjsEduad8I_c-ogIA">Self-Organize Work Assignments</a>,&nbsp;<a class="elementLink" href="./../../../practice.mgmt.whole_team.base/guidances/guidelines/maintain_a_sustainable_pace_A132240B.html" guid="_KzYHYMLmEdysDsQChI42QQ">Maintain a Sustainable Pace</a>, and&nbsp;<a class="elementLink" href="./../../../practice.mgmt.whole_team.base/guidances/guidelines/daily_meetings_3690A7AD.html" guid="_251UMCmREdyy6Oss2-0s1g">Daily Meetings</a>&nbsp;guidelines.&nbsp; </p>
-<p><b> Discuss the implications of this practice with management.&nbsp;</b><br />
- The Whole Team practice often requires changes to the way that projects are
- managed and&nbsp;governed, because "whole teams" are&nbsp;often more self-contained
- than traditional project teams.&nbsp;For example, with self-organization, detailed
- planning is typically&nbsp;performed at the beginning of each iteration in a
- just-in-time manner and not at the beginning of the project.&nbsp;The implication
- is that management will receive different and often better-quality artifacts
- at different points in time than from project teams that do not adopt this practice.
-</p>
-<p><b>Discuss this practice with your team.&nbsp;</b><br />
- The concept of maintaining a sustainable pace is often attractive to&nbsp;team
- members.&nbsp;But are they&nbsp;comfortable with self-organization?&nbsp;Are
- they comfortable with sharing their current status in daily meetings?&nbsp;Do
- they appreciate how a Whole Team approach can improve their overall productivity?
-</p>
-<p><b> Identify viable aspects of this practice for your situation.</b> <br />
- Your team may not be able to adopt all aspects of this practice.&nbsp;For example,
- if your project is a high-priority, "emergency" project, perhaps you will not
- be able to adopt a sustainable pace in the short term. </p>
-<p><b> Prioritize your adoption efforts. </b><br />
- Some project teams can adopt this practice all at once, while&nbsp;other teams
- find that they need to ease into self-organization or into daily meetings.&nbsp;Adopt
- the aspects that are easy for your team right away, and then adopt the other
- aspects one or two at a time, as appropriate, over a period of several weeks.
-</p>
-<h3> Common pitfalls </h3>
-<p>
- There are several common pitfalls that project teams run into when adopting this practice.
-</p>
-<p> <b>Traditional project management culture <br />
- </b> In many ways, the whole team practice is all about pushing many management
- activities into the hands of the people who do the actual work, a philosophy&nbsp;that
- goes against the grain in some organizations.&nbsp;For example, your&nbsp;organization
- may&nbsp;have a belief system where "managers do the planning; the rest of the
- staff does what they are told" or an "estimation should be left to estimators"
- mindset. You will need to overcome those kinds of&nbsp;beliefs when adopting
- this practice.&nbsp;&nbsp;&nbsp;&nbsp; </p>
-<p> <b>Insufficient time to change <br />
- </b>It can take weeks, if not months, for experienced professionals to get used
- to some of the aspects of this practice, in particular daily meetings and self-organization.&nbsp;You
- cannot expect people to change overnight.&nbsp; </p>
-<p> <strong>Individuals struggle at first to see the "whole team"</strong> <br />
- Many people, in particular specialists, are used to working on their own and
- not as part of an overall team.&nbsp;They often struggle to understand why it
- is&nbsp;important to do so.&nbsp;For example, you may hear people ask why they
- need to participate in&nbsp;a daily meeting when a weekly status report is easier
- to write.&nbsp;They do not&nbsp;realize that it is&nbsp;critical for everyone
- on the entire team to understand everyone's status, not just for the manager
- to know.&nbsp;Although the individual might be proceeding effectively on one
- task, they might not realize that several others are being blocked by their
- lack of progress on other tasks that they haven't started yet.&nbsp; </p></mainDescription>
+ <mainDescription><h3>
+ Getting started&nbsp;
+</h3>
+<p>
+ There are several steps to get started with the Whole Team practice.
+</p>
+<p>
+ <b>Understand the underlying philosophies behind this practice.&nbsp;</b><br />
+ These philosophies are captured in the&nbsp;<a class="elementLink"
+ href="./../../../practice.mgmt.whole_team.base/guidances/guidelines/self_organize_work_assignments_F47FC314.html"
+ guid="_rmBEkJjsEduad8I_c-ogIA">Self-Organize Work Assignments</a>,&nbsp;<a class="elementLink"
+ href="./../../../practice.mgmt.whole_team.base/guidances/guidelines/maintain_a_sustainable_pace_A132240B.html"
+ guid="_KzYHYMLmEdysDsQChI42QQ">Maintain a Sustainable Pace</a>, and&nbsp;<a class="elementLink"
+ href="./../../../practice.mgmt.whole_team.base/guidances/guidelines/daily_meetings_3690A7AD.html"
+ guid="_251UMCmREdyy6Oss2-0s1g">Daily Meetings</a>&nbsp;guidelines.&nbsp;
+</p>
+<p>
+ <b>Discuss the implications of this practice with management.&nbsp;</b><br />
+ The Whole Team practice often requires changes to the way that projects are managed and&nbsp;governed, because "whole
+ teams" are&nbsp;often more self-contained than traditional project teams.&nbsp;For example, with self-organization,
+ detailed planning is typically&nbsp;performed at the beginning of each iteration in a just-in-time manner and not at
+ the beginning of the project.&nbsp;The implication is that management will receive different and often better-quality
+ artifacts at different points in time than from project teams that do not adopt this practice.
+</p>
+<p>
+ <b>Discuss this practice with your team.&nbsp;</b><br />
+ The concept of maintaining a sustainable pace is often attractive to&nbsp;team members.&nbsp;But are
+ they&nbsp;comfortable with self-organization?&nbsp;Are they comfortable with sharing their current status in daily
+ meetings?&nbsp;Do they appreciate how a Whole Team approach can improve their overall productivity?
+</p>
+<p>
+ <b>Identify viable aspects of this practice for your situation.</b><br />
+ Your team may not be able to adopt all aspects of this practice.&nbsp;For example, if your project is a high-priority,
+ "emergency" project, perhaps you will not be able to adopt a sustainable pace in the short term.
+</p>
+<p>
+ <b>Prioritize your adoption efforts.</b><br />
+ Some project teams can adopt this practice all at once, while&nbsp;other teams find that they need to ease into
+ self-organization or into daily meetings.&nbsp;Adopt the aspects that are easy for your team right away, and then adopt
+ the other aspects one or two at a time, as appropriate, over a period of several weeks.
+</p>
+<h3>
+ Common pitfalls
+</h3>
+<p>
+ There are several common pitfalls that project teams run into when adopting this practice.
+</p>
+<p>
+ <b>Traditional project management culture<br />
+ </b> In many ways, the whole team practice is all about pushing many management activities into the hands of the people
+ who do the actual work, a philosophy&nbsp;that goes against the grain in some organizations.&nbsp;For example,
+ your&nbsp;organization may&nbsp;have a belief system where "managers do the planning; the rest of the staff does what
+ they are told" or an "estimation should be left to estimators" mindset. You will need to overcome those kinds
+ of&nbsp;beliefs when adopting this practice.&nbsp;&nbsp;&nbsp;&nbsp;
+</p>
+<p>
+ <b>Insufficient time to change<br />
+ </b> It can take weeks, if not months, for experienced professionals to get used to some of the aspects of this
+ practice, in particular daily meetings and self-organization.&nbsp;You cannot expect people to change overnight.&nbsp;
+</p>
+<p>
+ <strong>Individuals struggle at first to see the "whole team"</strong><br />
+ Many people, in particular specialists, are used to working on their own and not as part of an overall team.&nbsp;They
+ often struggle to understand why it is&nbsp;important to do so.&nbsp;For example, you may hear people ask why they need
+ to participate in&nbsp;a daily meeting when a weekly status report is easier to write.&nbsp;They do not&nbsp;realize
+ that it is&nbsp;critical for everyone on the entire team to understand everyone's status, not just for the manager to
+ know.&nbsp;Although the individual might be proceeding effectively on one task, they might not realize that several
+ others are being blocked by their lack of progress on other tasks that they haven't started yet.&nbsp;
+</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.concurrent_testing.base/guidances/practices/concurrent_testing.xmi b/epf_prac_151/practice.tech.concurrent_testing.base/guidances/practices/concurrent_testing.xmi
index 24fe650..8cb478f 100644
--- a/epf_prac_151/practice.tech.concurrent_testing.base/guidances/practices/concurrent_testing.xmi
+++ b/epf_prac_151/practice.tech.concurrent_testing.base/guidances/practices/concurrent_testing.xmi
@@ -1,50 +1,62 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:PracticeDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-MOoQ_OfD89D0nh4_1aSAuw" name="rapid_testing,_9z1PgJ6NEdyQN-zRFaRrCQ" guid="-MOoQ_OfD89D0nh4_1aSAuw" changeDate="2008-08-07T02:33:18.000-0700" version="7.5.0">
- <mainDescription><p> This practice requires a high degree of integration and high-bandwidth communication
- between developers and testers. Given these requirements, the following are
- the main conditions for applying this practice: </p>
-<ul>
-
- <li> <b>Coverage: </b>Component, feature, and subsystem (or system) testing
- </li>
- <li> <b>Team considerations: </b>Small team with embedded tester or testers</li>
+ <mainDescription><p>
+ This practice requires a high degree of integration and high-bandwidth communication between developers and testers.
+ Given these requirements, the following are the main conditions for applying this practice:
+</p>
+<ul>
+ <li>
+ <b>Coverage:</b> Component, feature, and subsystem (or system) testing
+ </li>
+ <li>
+ <b>Team considerations:</b> Small team with embedded tester or testers
+ </li>
</ul></mainDescription>
<problem>This practice adopts testing throughout an iteration, concurrent with development. This prevents teams from compressing
testing into a separate activity at the end of an iteration or release. Concurrent testing reinforces the concept of
feature teams working in parallel.</problem>
- <application><p> Use a multi-prong approach when you review this practice. You can start by 
- focusing on the work products that will be produced or used during testing and 
- then shift to the tasks involved in processing those artifacts. You might play 
- different roles within your team. If you are a tester, then you will need to 
- get a very good understanding of the artifacts, the tasks, and the guidelines 
- supporting them. For a developer, the main points of interest are the artifacts 
- used within this practice. </p>
-<p> Start with the Test artifacts, read their description, and understand when 
- they are used (produced or used), by whom, and which roles are mainly responsible: 
+ <application><p>
+ Use a multi-prong approach when you review this practice. You can start by focusing on the work products that will be
+ produced or used during testing and then shift to the tasks involved in processing those artifacts. You might play
+ different roles within your team. If you are a tester, then you will need to get a very good understanding of the
+ artifacts, the tasks, and the guidelines supporting them. For a developer, the main points of interest are the
+ artifacts used within this practice.
+</p>
+<p>
+ Start with the Test artifacts, read their description, and understand when they are used (produced or used), by whom,
+ and which roles are mainly responsible:
</p>
<ul>
<li>
- <a class="elementLink" href="./../../../core.tech.common.extend_supp/workproducts/test_case_335C5DEA.html" guid="_0ZS-0MlgEdmt3adZL5Dmdw">Test Case</a>
+ <a class="elementLink" href="./../../../core.tech.common.extend_supp/workproducts/test_case_335C5DEA.html"
+ guid="_0ZS-0MlgEdmt3adZL5Dmdw">Test Case</a>
</li>
<li>
- <a class="elementLink" href="./../../../core.tech.common.extend_supp/workproducts/test_script_39A30BA2.html" guid="_0ZfMEMlgEdmt3adZL5Dmdw">Test Script</a>
+ <a class="elementLink" href="./../../../core.tech.common.extend_supp/workproducts/test_script_39A30BA2.html"
+ guid="_0ZfMEMlgEdmt3adZL5Dmdw">Test Script</a>
</li>
<li>
- <a class="elementLink" href="./../../../core.tech.common.extend_supp/workproducts/test_log_CBA2FDF4.html" guid="_0ZlSsMlgEdmt3adZL5Dmdw">Test Log</a>
+ <a class="elementLink" href="./../../../core.tech.common.extend_supp/workproducts/test_log_CBA2FDF4.html"
+ guid="_0ZlSsMlgEdmt3adZL5Dmdw">Test Log</a>
</li>
</ul>
-<p> Switch the focus to tasks and, depending on your main role within the team, 
- review the associated guidelines, concepts and, if applicable, the tool-related 
- guidance: </p>
+<p>
+ Switch the focus to tasks and, depending on your main role within the team, review the associated guidelines, concepts
+ and, if applicable, the tool-related guidance:
+</p>
<ul>
<li>
- <a class="elementLink" href="./../../../practice.tech.concurrent_testing.base/tasks/create_test_cases_D39E98A1.html" guid="_0iwc0clgEdmt3adZL5Dmdw">Create Test Cases</a>
+ <a class="elementLink"
+ href="./../../../practice.tech.concurrent_testing.base/tasks/create_test_cases_D39E98A1.html"
+ guid="_0iwc0clgEdmt3adZL5Dmdw">Create Test Cases</a>
</li>
<li>
- <a class="elementLink" href="./../../../practice.tech.concurrent_testing.base/tasks/implement_tests_26F00282.html" guid="_0jO98MlgEdmt3adZL5Dmdw">Implement Tests</a>
+ <a class="elementLink" href="./../../../practice.tech.concurrent_testing.base/tasks/implement_tests_26F00282.html"
+ guid="_0jO98MlgEdmt3adZL5Dmdw">Implement Tests</a>
</li>
<li>
- <a class="elementLink" href="./../../../practice.tech.concurrent_testing.base/tasks/run_tests_49698054.html" guid="_0jVEkMlgEdmt3adZL5Dmdw">Run Tests</a>
+ <a class="elementLink" href="./../../../practice.tech.concurrent_testing.base/tasks/run_tests_49698054.html"
+ guid="_0jVEkMlgEdmt3adZL5Dmdw">Run Tests</a>
</li>
</ul></application>
</org.eclipse.epf.uma:PracticeDescription>
diff --git a/epf_prac_151/practice.tech.concurrent_testing.base/guidances/roadmaps/how_to_adopt_concurrent_testing.xmi b/epf_prac_151/practice.tech.concurrent_testing.base/guidances/roadmaps/how_to_adopt_concurrent_testing.xmi
index 7517304..156b08a 100644
--- a/epf_prac_151/practice.tech.concurrent_testing.base/guidances/roadmaps/how_to_adopt_concurrent_testing.xmi
+++ b/epf_prac_151/practice.tech.concurrent_testing.base/guidances/roadmaps/how_to_adopt_concurrent_testing.xmi
@@ -1,37 +1,62 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-gNCvPJgehxo6Gnb98n0AhA" name="new_roadmap,_rV_9MPndEdyLA5PXdgVJXw" guid="-gNCvPJgehxo6Gnb98n0AhA" changeDate="2008-08-07T03:25:25.000-0700" version="7.2.0">
- <mainDescription><h3>
- How to adopt this practice
-</h3>
-<p> The following is a list of points that you need to consider when you adopt
- this practice. </p>
-<p> Process scope: </p>
-<ul>
-
- <li> <b>Test coverage:</b> component, feature, and subsystem, or all three</li>
- <li><b> Focus on the main elements:</b> tasks, artifacts, guidelines</li>
-</ul>
-<p> Team impact: </p>
-<ul>
- <li><b>Team composition:</b> Testers are part of the team, not external resources
- that are involved only at specific points.</li>
- <li> <b>Roles: </b>This practice also needs to be adopted by developers to make
- sure that they provide tested components. </li>
- <li> <b>Skills: </b>Testers need to adopt a more technical skill set, and developers
- can also fill the Tester role.</li>
-</ul>
-<p>Development approach:</p>
-<ul>
- <li>Set a goal of stable builds that can be tested from end-to-end. </li>
- <li>Provide smaller increments of functionality. </li>
- <li>Institute &quot;walkthroughs&quot; to determine whether a micro-increment
- is correct. </li>
- <li>Build and test frequently throughout an iteration. </li>
- <li>Make passing automated tests the team's definition of "finished" for a requirement.</li>
-</ul>
-<p>Reach a pattern where the team continuously develops micro-increments, tests
- them, and then regression tests the product throughout the day. Obviously, this
- involves a high degree of regression test automation. Achieving this level of
- automation requires the concerted effort of the whole team, across all the levels
- of testing, with automated unit, integration, system, and acceptance tests.</p></mainDescription>
+ <mainDescription><h3>
+ How to adopt this practice
+</h3>
+<p>
+ The following is a list of points that you need to consider when you adopt this practice.
+</p>
+<p>
+ Process scope:
+</p>
+<ul>
+ <li>
+ <b>Test coverage:</b> component, feature, and subsystem, or all three
+ </li>
+ <li>
+ <b>Focus on the main elements:</b> tasks, artifacts, guidelines
+ </li>
+</ul>
+<p>
+ Team impact:
+</p>
+<ul>
+ <li>
+ <b>Team composition:</b> Testers are part of the team, not external resources that are involved only at specific
+ points.
+ </li>
+ <li>
+ <b>Roles:</b> This practice also needs to be adopted by developers to make sure that they provide tested
+ components.
+ </li>
+ <li>
+ <b>Skills:</b> Testers need to adopt a more technical skill set, and developers can also fill the Tester role.
+ </li>
+</ul>
+<p>
+ Development approach:
+</p>
+<ul>
+ <li>
+ Set a goal of stable builds that can be tested from end-to-end.
+ </li>
+ <li>
+ Provide smaller increments of functionality.
+ </li>
+ <li>
+ Institute "walkthroughs" to determine whether a micro-increment is correct.
+ </li>
+ <li>
+ Build and test frequently throughout an iteration.
+ </li>
+ <li>
+ Make passing automated tests the team's definition of "finished" for a requirement.
+ </li>
+</ul>
+<p>
+ Reach a pattern where the team continuously develops micro-increments, tests them, and then regression tests the
+ product throughout the day. Obviously, this involves a high degree of regression test automation. Achieving this level
+ of automation requires the concerted effort of the whole team, across all the levels of testing, with automated unit,
+ integration, system, and acceptance tests.
+</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.concurrent_testing.base/tasks/create_test_cases.xmi b/epf_prac_151/practice.tech.concurrent_testing.base/tasks/create_test_cases.xmi
index 5e01e56..6b999de 100644
--- a/epf_prac_151/practice.tech.concurrent_testing.base/tasks/create_test_cases.xmi
+++ b/epf_prac_151/practice.tech.concurrent_testing.base/tasks/create_test_cases.xmi
@@ -1,10 +1,10 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:TaskDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_NrVKsKeqEdmKDbQuyzCoqQ" name="create_test_cases,_0iwc0clgEdmt3adZL5Dmdw" guid="_NrVKsKeqEdmKDbQuyzCoqQ" changeDate="2007-02-07T03:38:57.000-0800" version="1.0.0">
- <keyConsiderations><p>
- Develop test cases in parallel with requirements so that Analysts and Stakeholders can agree with the specific
- conditions of satisfaction for each requirement. The test cases act as acceptance criteria by expanding on the intent
- of the system&nbsp;through actual scenarios of use.&nbsp;This allows team members to measure progress in terms of
- passing test cases.&nbsp;
+ <keyConsiderations><p>
+ Develop test cases in parallel with requirements so that Analysts and Stakeholders can agree with the specific
+ conditions of satisfaction for each requirement. The test cases act as acceptance criteria by expanding on the intent
+ of the system&nbsp;through actual scenarios of use.&nbsp;This allows team members to measure progress in terms of
+ passing test cases.&nbsp;
</p></keyConsiderations>
<sections xmi:id="_IJFSsKuSEdmhFZtkg1nakg" name="Review the requirements to be tested" guid="_IJFSsKuSEdmhFZtkg1nakg">
<sectionDescription><p>
@@ -32,7 +32,9 @@
each test case. Optionally, outline steps for the test case.
</p>
<p>
- Verify that test cases meet the <a class="elementLinkWithType" href="./../../core.tech.common.extend_supp/guidances/checklists/test_case_9D3F2E96.html" guid="_0Zxf8MlgEdmt3adZL5Dmdw">Checklist: Test Case</a>&nbsp;guidelines.
+ Verify that test cases meet the <a class="elementLinkWithType"
+ href="./../../core.tech.common.extend_supp/guidances/checklists/test_case_9D3F2E96.html"
+ guid="_0Zxf8MlgEdmt3adZL5Dmdw">Checklist: Test Case</a>&nbsp;guidelines.
</p></sectionDescription>
</sections>
<sections xmi:id="_NK18YKuSEdmhFZtkg1nakg" name="Identify test data needs" guid="_NK18YKuSEdmhFZtkg1nakg">
@@ -42,7 +44,9 @@
not on creating specific data.
</p>
<p>
- For more information on test data selection, see <a class="elementLinkWithType" href="./../../core.tech.common.extend_supp/guidances/checklists/test_data_48E804D.html" guid="_KZQJMBhBEduxCP6DVVLxsA">Checklist: Test Data</a>.
+ For more information on test data selection, see <a class="elementLinkWithType"
+ href="./../../core.tech.common.extend_supp/guidances/checklists/test_data_48E804D.html"
+ guid="_KZQJMBhBEduxCP6DVVLxsA">Checklist: Test Data</a>.
</p></sectionDescription>
</sections>
<sections xmi:id="_Ok_mMKuSEdmhFZtkg1nakg" name="Share and evaluate the Test Cases" guid="_Ok_mMKuSEdmhFZtkg1nakg">
@@ -71,10 +75,12 @@
</li>
</ul>
<p>
- Optionally, capture new patterns of test cases&nbsp;in&nbsp;the test ideas list (see <a class="elementLinkWithType" href="./../../core.tech.common.extend_supp/guidances/concepts/test_ideas_ED562B58.html" guid="_0jnYcMlgEdmt3adZL5Dmdw">Concept: Test Ideas</a>).
+ Optionally, capture new patterns of test cases&nbsp;in&nbsp;the test ideas list (see <a class="elementLinkWithType"
+ href="./../../core.tech.common.extend_supp/guidances/concepts/test_ideas_ED562B58.html"
+ guid="_0jnYcMlgEdmt3adZL5Dmdw">Concept: Test Ideas</a>).
</p></sectionDescription>
</sections>
- <purpose><p>
- To achieve a shared understanding of the specific conditions that the solution must meet.
+ <purpose><p>
+ To achieve a shared understanding of the specific conditions that the solution must meet.
</p></purpose>
</org.eclipse.epf.uma:TaskDescription>
diff --git a/epf_prac_151/practice.tech.concurrent_testing.base/tasks/implement_tests.xmi b/epf_prac_151/practice.tech.concurrent_testing.base/tasks/implement_tests.xmi
index f71344c..d9376db 100644
--- a/epf_prac_151/practice.tech.concurrent_testing.base/tasks/implement_tests.xmi
+++ b/epf_prac_151/practice.tech.concurrent_testing.base/tasks/implement_tests.xmi
@@ -23,7 +23,9 @@
</p>Select an implementation technique for this design. At a minimum, determine if the Test Script will be manual or
automated. If the Test Case is well understood, it's best to implement an automated Test Script without first writing a
manual procedure. However, if the Test Case is new or novel, writing a manual Test Script can help validate the design of
-the test and aid collaboration with other team members. See <a class="elementLinkWithType" href="./../../core.tech.common.extend_supp/guidances/guidelines/programming_automated_tests_7DA10019.html" guid="_0j5sUMlgEdmt3adZL5Dmdw">Guideline: Programming Automated Tests</a> for more details about this decision.</sectionDescription>
+the test and aid collaboration with other team members. See <a class="elementLinkWithType"
+href="./../../core.tech.common.extend_supp/guidances/guidelines/programming_automated_tests_7DA10019.html"
+guid="_0j5sUMlgEdmt3adZL5Dmdw">Guideline: Programming Automated Tests</a> for more details about this decision.</sectionDescription>
</sections>
<sections xmi:id="_VN5M0KuSEdmhFZtkg1nakg" name="Implement the executable Test Script" guid="_VN5M0KuSEdmhFZtkg1nakg">
<sectionDescription><p>
@@ -61,7 +63,9 @@
configuration identification.
</p>
<p>
- For help with test suite organization, see <a class="elementLinkWithType" href="./../../core.tech.common.extend_supp/guidances/guidelines/test_suite_D54EEBED.html" guid="_0aDz0MlgEdmt3adZL5Dmdw">Guideline: Test Suite</a>.
+ For help with test suite organization, see <a class="elementLinkWithType"
+ href="./../../core.tech.common.extend_supp/guidances/guidelines/test_suite_D54EEBED.html"
+ guid="_0aDz0MlgEdmt3adZL5Dmdw">Guideline: Test Suite</a>.
</p></sectionDescription>
</sections>
<sections xmi:id="_X0dmcKuSEdmhFZtkg1nakg" name="Verify Test implementation" guid="_X0dmcKuSEdmhFZtkg1nakg">
@@ -70,7 +74,9 @@
the Test Script. For automated tests, verify that the Test Script executes correctly and produces the expected result.
</p>
<p>
- Verify that the Test Script meets the criteria in <a class="elementLinkWithType" href="./../../core.tech.common.extend_supp/guidances/checklists/test_script_FBB4524E.html" guid="_0Z9tMMlgEdmt3adZL5Dmdw">Checklist: Test Script</a>.
+ Verify that the Test Script meets the criteria in <a class="elementLinkWithType"
+ href="./../../core.tech.common.extend_supp/guidances/checklists/test_script_FBB4524E.html"
+ guid="_0Z9tMMlgEdmt3adZL5Dmdw">Checklist: Test Script</a>.
</p>
<p>
Add or update the Test Script(s) in configuration management.
@@ -87,7 +93,7 @@
through a representative set of the Test Scripts using an implementation of the system.
</p></sectionDescription>
</sections>
- <purpose><p>
- To implement step-by-step Test Scripts that demonstrate the solution satisfies the requirements.
+ <purpose><p>
+ To implement step-by-step Test Scripts that demonstrate the solution satisfies the requirements.
</p></purpose>
</org.eclipse.epf.uma:TaskDescription>
diff --git a/epf_prac_151/practice.tech.concurrent_testing.base/tasks/run_tests.xmi b/epf_prac_151/practice.tech.concurrent_testing.base/tasks/run_tests.xmi
index 53595ad..b997bb6 100644
--- a/epf_prac_151/practice.tech.concurrent_testing.base/tasks/run_tests.xmi
+++ b/epf_prac_151/practice.tech.concurrent_testing.base/tasks/run_tests.xmi
@@ -1,15 +1,15 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:TaskDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_NrbRUqeqEdmKDbQuyzCoqQ" name="run_tests,_0jVEkMlgEdmt3adZL5Dmdw" guid="_NrbRUqeqEdmKDbQuyzCoqQ" changeDate="2007-12-06T02:34:58.000-0800" version="1.0.0">
- <keyConsiderations><ul>
- <li>
- Run all tests as frequently as possible. Ideally, run all test scripts against each build deployed to the test
- environment. If this is impractical, run regression tests for existing functionality, and&nbsp;focus the test cycle
- on work items completed in the new build.
- </li>
- <li>
- Even test scripts that are expected to fail provide valuable feedback. However, once a test script is passing, it
- should not fail&nbsp;against subsequent builds of the solution.
- </li>
+ <keyConsiderations><ul>
+ <li>
+ Run all tests as frequently as possible. Ideally, run all test scripts against each build deployed to the test
+ environment. If this is impractical, run regression tests for existing functionality, and&nbsp;focus the test cycle
+ on work items completed in the new build.
+ </li>
+ <li>
+ Even test scripts that are expected to fail provide valuable feedback. However, once a test script is passing, it
+ should not fail&nbsp;against subsequent builds of the solution.
+ </li>
</ul></keyConsiderations>
<sections xmi:id="_xVhnwKRLEdyLP-jEVj8Kyw" name="Review work items completed in the build" guid="_xVhnwKRLEdyLP-jEVj8Kyw">
<sectionDescription>Review work items that were integrated into the build since the last test cycle. Focus on identifying any previously
@@ -25,19 +25,25 @@
about the maturing solution based on the objectives of the iteration.
</p>
<p>
- Plan with test suites to&nbsp;simplify the process of selecting tests for each build (see <a class="elementLinkWithType" href="./../../core.tech.common.extend_supp/guidances/guidelines/test_suite_D54EEBED.html" guid="_0aDz0MlgEdmt3adZL5Dmdw">Guideline: Test Suite</a>).
+ Plan with test suites to&nbsp;simplify the process of selecting tests for each build (see <a
+ class="elementLinkWithType" href="./../../core.tech.common.extend_supp/guidances/guidelines/test_suite_D54EEBED.html"
+ guid="_0aDz0MlgEdmt3adZL5Dmdw">Guideline: Test Suite</a>).
</p></sectionDescription>
</sections>
<sections xmi:id="_gV408KuSEdmhFZtkg1nakg" name="Execute Test Scripts against the build" guid="_gV408KuSEdmhFZtkg1nakg">
<sectionDescription><p>
- Run the tests using the step-by-step procedure in the <a class="elementLink" href="./../../core.tech.common.extend_supp/workproducts/test_script_39A30BA2.html" guid="_0ZfMEMlgEdmt3adZL5Dmdw">Test Script</a>.
+ Run the tests using the step-by-step procedure in the <a class="elementLink"
+ href="./../../core.tech.common.extend_supp/workproducts/test_script_39A30BA2.html" guid="_0ZfMEMlgEdmt3adZL5Dmdw">Test
+ Script</a>.
</p>
<p>
For automated test scripts, initiate the test execution.&nbsp;Automated test scripts should run in suites in the
correct sequence, and collect results in the Test Log.
</p>
<p>
- To execute a manual test script, establish its preconditions, perform the steps while logging results in the <a class="elementLink" href="./../../core.tech.common.extend_supp/workproducts/test_log_CBA2FDF4.html" guid="_0ZlSsMlgEdmt3adZL5Dmdw">Test Log</a>, and perform any teardown steps.
+ To execute a manual test script, establish its preconditions, perform the steps while logging results in the <a
+ class="elementLink" href="./../../core.tech.common.extend_supp/workproducts/test_log_CBA2FDF4.html"
+ guid="_0ZlSsMlgEdmt3adZL5Dmdw">Test Log</a>, and perform any teardown steps.
</p></sectionDescription>
</sections>
<sections xmi:id="_sQaC4DO2EduqsLmIADMQ9g" name="Analyze and communicate test results" guid="_sQaC4DO2EduqsLmIADMQ9g">
diff --git a/epf_prac_151/practice.tech.continuous_integration.base/guidances/concepts/change_requests.xmi b/epf_prac_151/practice.tech.continuous_integration.base/guidances/concepts/change_requests.xmi
index ba67bbc..0b29e8a 100644
--- a/epf_prac_151/practice.tech.continuous_integration.base/guidances/concepts/change_requests.xmi
+++ b/epf_prac_151/practice.tech.continuous_integration.base/guidances/concepts/change_requests.xmi
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-BsXK3ZGMm-mUT0KnkdoYBg" name="change_requests,_6jdvECb3Edqh1LYUOGRh2A" guid="-BsXK3ZGMm-mUT0KnkdoYBg" changeDate="2009-08-07T02:45:49.000-0700" version="7.2.0">
- <mainDescription><p>
- A change request represents any request to change a work product. This includes items commonly called defect reports,
- enhancement requests, requirements change request, implementation requests, and stakeholder requests.
+ <mainDescription><p>
+ A change request represents any request to change a work product. This includes items commonly called defect reports,
+ enhancement requests, requirements change request, implementation requests, and stakeholder requests.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.continuous_integration.base/guidances/concepts/workspace.xmi b/epf_prac_151/practice.tech.continuous_integration.base/guidances/concepts/workspace.xmi
index c4d4974..f60df83 100644
--- a/epf_prac_151/practice.tech.continuous_integration.base/guidances/concepts/workspace.xmi
+++ b/epf_prac_151/practice.tech.continuous_integration.base/guidances/concepts/workspace.xmi
@@ -1,50 +1,52 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_Dfmk8MPiEdmbOvqy4O0adg" name="workspace,_0cEmAMlgEdmt3adZL5Dmdw" guid="_Dfmk8MPiEdmbOvqy4O0adg" changeDate="2006-09-21T00:22:51.000-0700" version="1.0.0">
- <mainDescription><p align="left">
- On small teams, shared workspaces may work fine, but you must coordinate activities between team members to avoid
- conflicts.
-</p>
-<p align="left">
- A better approach is for each developer to have a reasonably private area for the development and testing of their work
- products. This workspace should be insulated&nbsp;so that destabilizing or conflicting changes made by others do not
- interfere with&nbsp;progress. However, it should&nbsp;not be isolated to the extent that&nbsp;the developer's work is
- unavailable to the team.
-</p>
-<p align="left">
- In addition, insulated&nbsp;workspaces can be created for each test phase, such as integration testing and system
- testing. This approach to workspaces provides several benefits <a class="elementLinkWithUserText" href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html" guid="_9ToeIB83Edqsvps02rpOOg">[WIB04]</a>:
-</p>
-<ul>
- <li>
- <p>
- Developers can develop, test, and debug software changes without being affected by others team
- members'&nbsp;changes until they are ready. When ready, developers can update their insulated environments to
- test the latest changes from other developers.
- </p>
- </li>
- <li>
- <p>
- With separate workspaces for integration and system testing, a team could use a methodology that ensures
- changes have passed integration testing before other developers get them, thereby minimizing the time spent
- solving integration problems.&nbsp; For example, if two team members check in incompatible changes without
- realizing it, and both changes are immediately available to everyone on the team, all team members&nbsp;might
- waste time trying to resolve the broken build. Conversely, if both changes must pass integration testing before
- being distributed to others, the problem could be found and fixed by one person with minimal disruption to the
- team.
- </p>
- </li>
- <li>
- <p>
- By setting up an integration area to collect and build the latest changes, the team can integrate early and
- often. That is a well-known best practice for reducing overall cost and time to deliver software projects.
- </p>
- </li>
- <li>
- <p>
- The system test area, which is used for preparing releases, is insulated from developers' ongoing changes and
- contains only configurations that have passed integration testing. This lets you control the content of the
- release while still enabling developers to continue working.
- </p>
- </li>
+ <mainDescription><p align="left">
+ On small teams, shared workspaces may work fine, but you must coordinate activities between team members to avoid
+ conflicts.
+</p>
+<p align="left">
+ A better approach is for each developer to have a reasonably private area for the development and testing of their work
+ products. This workspace should be insulated&nbsp;so that destabilizing or conflicting changes made by others do not
+ interfere with&nbsp;progress. However, it should&nbsp;not be isolated to the extent that&nbsp;the developer's work is
+ unavailable to the team.
+</p>
+<p align="left">
+ In addition, insulated&nbsp;workspaces can be created for each test phase, such as integration testing and system
+ testing. This approach to workspaces provides several benefits <a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
+ guid="_9ToeIB83Edqsvps02rpOOg">[WIB04]</a>:
+</p>
+<ul>
+ <li>
+ <p>
+ Developers can develop, test, and debug software changes without being affected by others team
+ members'&nbsp;changes until they are ready. When ready, developers can update their insulated environments to
+ test the latest changes from other developers.
+ </p>
+ </li>
+ <li>
+ <p>
+ With separate workspaces for integration and system testing, a team could use a methodology that ensures
+ changes have passed integration testing before other developers get them, thereby minimizing the time spent
+ solving integration problems.&nbsp; For example, if two team members check in incompatible changes without
+ realizing it, and both changes are immediately available to everyone on the team, all team members&nbsp;might
+ waste time trying to resolve the broken build. Conversely, if both changes must pass integration testing before
+ being distributed to others, the problem could be found and fixed by one person with minimal disruption to the
+ team.
+ </p>
+ </li>
+ <li>
+ <p>
+ By setting up an integration area to collect and build the latest changes, the team can integrate early and
+ often. That is a well-known best practice for reducing overall cost and time to deliver software projects.
+ </p>
+ </li>
+ <li>
+ <p>
+ The system test area, which is used for preparing releases, is insulated from developers' ongoing changes and
+ contains only configurations that have passed integration testing. This lets you control the content of the
+ release while still enabling developers to continue working.
+ </p>
+ </li>
</ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.continuous_integration.base/guidances/guidelines/continuous_integration.xmi b/epf_prac_151/practice.tech.continuous_integration.base/guidances/guidelines/continuous_integration.xmi
index 5f37e5e..bfcd91a 100644
--- a/epf_prac_151/practice.tech.continuous_integration.base/guidances/guidelines/continuous_integration.xmi
+++ b/epf_prac_151/practice.tech.continuous_integration.base/guidances/guidelines/continuous_integration.xmi
@@ -1,72 +1,92 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-DlaqJu4sEqMPk84qhJ6IEA" name="continuous_integration,_i8bUEL6cEdqti4GwqTkbsQ" guid="-DlaqJu4sEqMPk84qhJ6IEA" changeDate="2008-05-28T07:33:07.000-0700" version="7.2.0">
- <mainDescription><p>
- Continuous integration is a software development practice that completely rebuilds and tests the application frequently
- -- ideally, every time a change is introduced. This approach provides many benefits as outlined in&nbsp;<a class="elementLink" href="./../../../practice.tech.continuous_integration.base/guidances/practices/continous_integration_58673D65.html" guid="_rJNiMB4rEd2bS8fFOQ7WWA">Continuous Integration</a> and in <a class="elementLinkWithUserText" href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#WIKP-CI" guid="_9ToeIB83Edqsvps02rpOOg">[WIKP-CI]</a>.
-</p>
-<h3>
- Basic steps
-</h3>
-<p>
- The detailed application of continuous integration depends on which tools you use (configuration management system,
- automated build tool, automated test tool, and so forth). However, these are the basic steps:
-</p>
-<ol>
- <li>
- A developer, let's call her Jane, selects a&nbsp;work item&nbsp;to work on.
- </li>
- <li>
- Jane updates her <a class="elementLink" href="./../../../practice.tech.continuous_integration.base/guidances/concepts/workspace_722BBA90.html" guid="_0cEmAMlgEdmt3adZL5Dmdw">Workspace</a> to include the most recent <a class="elementLink" href="./../../../core.tech.slot.base/workproducts/software_implementation_slot_E92F6A39.html" guid="_Vux8UEfUEdyiPI8btkmvmw">[Software Implementation]</a> from the integration workspace.
- </li>
- <li>
- Jane makes her changes in her workspace to both her developer tests and to the implementation, and then she tests
- the changes.
- </li>
- <li>
- Before committing the changes, Jane updates her workspace again (because other developers may have introduced
- conflicting changes) and reruns her developer tests.
- </li>
- <li>
- If these tests are successful, the changes are promoted (see <a class="elementLinkWithType" href="./../../../practice.tech.continuous_integration.base/guidances/guidelines/promoting_changes_9087B764.html" guid="_SM4YIL6dEdqti4GwqTkbsQ">Guideline: Promoting Changes</a>) to&nbsp;the&nbsp;integration workspace.
- </li>
- <li>
- A complete <a class="elementLink" href="./../../../practice.tech.continuous_integration.base/workproducts/build_95D7D8FD.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a> of the application is performed by using the implementation from the
- integration workspace, and the entire suite of developer tests is run on this build.
- </li>
- <li>
- If any of these tests fail, the team is notified, and the failed test should be addressed as soon as possible.
- </li>
- <li>
- This process repeats as the team develops and continuously integrates and tests functionality in small increments.
- </li>
-</ol>
-<h3>
- Constraints
-</h3>
-<p>
- Conceptually, continuous integration can be performed manually (see <a class="elementLinkWithUserText" href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#SHO06" guid="_9ToeIB83Edqsvps02rpOOg">[SHO06]</a> for example). However, in practice, there are several constraints that must
- be respected for it to be effective:
-</p>
-<ol>
- <li>
- All changes must be introduced into a tested configuration that you know to be good.
- </li>
- <li>
- The integrate-build-test cycle must be fast enough so that it can be completed quickly and the team notified of the
- results. Many published guidelines promote a 10-minute cycle.
- </li>
- <li>
- Keep the <a class="elementLink" href="./../../../core.mgmt.common.extend_supp/guidances/concepts/change_set_430bf233.html" guid="_1QU9MAIoEdyLh7vsrHZ4YA">Change Set</a>s&nbsp;small enough so that the work can be completed and integration
- performed several times per day. Many published guidelines promote a 2- to 4-hour cycle between integrations.
- </li>
-</ol>
-<p>
- These constraints imply the need for a configuration management (CM) repository to maintain configuration information
- (Item 1 listed previously), automated build and test tools to meet the turnaround constraints (Item 2), and proper
- planning and discipline by developers to ensure that their work items and change sets are small enough to complete
- quickly (Item 3).
-</p>
-<p>
- For a more detailed description of continuous integration, see <a class="elementLinkWithUserText" href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#FOW06" guid="_9ToeIB83Edqsvps02rpOOg">[FOW06]</a> or <a class="elementLinkWithUserText" href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#WIKP-CI" guid="_9ToeIB83Edqsvps02rpOOg">[WIKP-CI]</a>.
+ <mainDescription><p>
+ Continuous integration is a software development practice that completely rebuilds and tests the application frequently
+ -- ideally, every time a change is introduced. This approach provides many benefits as outlined in&nbsp;<a
+ class="elementLink"
+ href="./../../../practice.tech.continuous_integration.base/guidances/practices/continous_integration_58673D65.html"
+ guid="_rJNiMB4rEd2bS8fFOQ7WWA">Continuous Integration</a> and in <a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#WIKP-CI"
+ guid="_9ToeIB83Edqsvps02rpOOg">[WIKP-CI]</a>.
+</p>
+<h3>
+ Basic steps
+</h3>
+<p>
+ The detailed application of continuous integration depends on which tools you use (configuration management system,
+ automated build tool, automated test tool, and so forth). However, these are the basic steps:
+</p>
+<ol>
+ <li>
+ A developer, let's call her Jane, selects a&nbsp;work item&nbsp;to work on.
+ </li>
+ <li>
+ Jane updates her <a class="elementLink"
+ href="./../../../practice.tech.continuous_integration.base/guidances/concepts/workspace_722BBA90.html"
+ guid="_0cEmAMlgEdmt3adZL5Dmdw">Workspace</a> to include the most recent <a class="elementLink"
+ href="./../../../core.tech.slot.base/workproducts/technical_implementation_slot_E92F6A39.html"
+ guid="_Vux8UEfUEdyiPI8btkmvmw">[Technical Implementation]</a> from the integration workspace.
+ </li>
+ <li>
+ Jane makes her changes in her workspace to both her developer tests and to the implementation, and then she tests
+ the changes.
+ </li>
+ <li>
+ Before committing the changes, Jane updates her workspace again (because other developers may have introduced
+ conflicting changes) and reruns her developer tests.
+ </li>
+ <li>
+ If these tests are successful, the changes are promoted (see <a class="elementLinkWithType"
+ href="./../../../practice.tech.continuous_integration.base/guidances/guidelines/promoting_changes_9087B764.html"
+ guid="_SM4YIL6dEdqti4GwqTkbsQ">Guideline: Promoting Changes</a>) to&nbsp;the&nbsp;integration workspace.
+ </li>
+ <li>
+ A complete <a class="elementLink" href="./../../../core.tech.common.extend_supp/workproducts/build_95D7D8FD.html"
+ guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a> of the application is performed by using the implementation from the
+ integration workspace, and the entire suite of developer tests is run on this build.
+ </li>
+ <li>
+ If any of these tests fail, the team is notified, and the failed test should be addressed as soon as possible.
+ </li>
+ <li>
+ This process repeats as the team develops and continuously integrates and tests functionality in small increments.
+ </li>
+</ol>
+<h3>
+ Constraints
+</h3>
+<p>
+ Conceptually, continuous integration can be performed manually (see <a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#SHO06"
+ guid="_9ToeIB83Edqsvps02rpOOg">[SHO06]</a> for example). However, in practice, there are several constraints that must
+ be respected for it to be effective:
+</p>
+<ol>
+ <li>
+ All changes must be introduced into a tested configuration that you know to be good.
+ </li>
+ <li>
+ The integrate-build-test cycle must be fast enough so that it can be completed quickly and the team notified of the
+ results. Many published guidelines promote a 10-minute cycle.
+ </li>
+ <li>
+ Keep the <a class="elementLink"
+ href="./../../../core.mgmt.common.extend_supp/guidances/concepts/change_set_430BF233.html"
+ guid="_1QU9MAIoEdyLh7vsrHZ4YA">Change Set</a>s&nbsp;small enough so that the work can be completed and integration
+ performed several times per day. Many published guidelines promote a 2- to 4-hour cycle between integrations.
+ </li>
+</ol>
+<p>
+ These constraints imply the need for a configuration management (CM) repository to maintain configuration information
+ (Item 1 listed previously), automated build and test tools to meet the turnaround constraints (Item 2), and proper
+ planning and discipline by developers to ensure that their work items and change sets are small enough to complete
+ quickly (Item 3).
+</p>
+<p>
+ For a more detailed description of continuous integration, see <a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#FOW06"
+ guid="_9ToeIB83Edqsvps02rpOOg">[FOW06]</a> or <a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#WIKP-CI"
+ guid="_9ToeIB83Edqsvps02rpOOg">[WIKP-CI]</a>.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.continuous_integration.base/guidances/guidelines/promoting_changes.xmi b/epf_prac_151/practice.tech.continuous_integration.base/guidances/guidelines/promoting_changes.xmi
index 4321971..5aff3b7 100644
--- a/epf_prac_151/practice.tech.continuous_integration.base/guidances/guidelines/promoting_changes.xmi
+++ b/epf_prac_151/practice.tech.continuous_integration.base/guidances/guidelines/promoting_changes.xmi
@@ -1,88 +1,99 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-zCM2ucJJxc_bQr_LoHlSaQ" name="promoting_changes,_SM4YIL6dEdqti4GwqTkbsQ" guid="-zCM2ucJJxc_bQr_LoHlSaQ" changeDate="2007-08-04T04:54:07.000-0700" version="1.0.0">
- <mainDescription><p>
- During iterative software development, the team&nbsp;creates numerous <a class="elementLink" href="./../../../core.mgmt.common.extend_supp/guidances/concepts/change_set_430bf233.html" guid="_1QU9MAIoEdyLh7vsrHZ4YA">Change Set</a>s that are combined into a <a class="elementLink" href="./../../../practice.tech.continuous_integration.base/workproducts/build_95D7D8FD.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a>. A build is initiated by combining the work completed by one or more
- developers and resolving any conflicts between those changes. Ideally a build is then subjected to a battery of tests
- to determine if it is of sufficient quality to move into production.
-</p>
-<p>
- As the changes progress from development towards production, its beneficial to know two characteristics:
-</p>
-<p>
- <strong>Test Context</strong>&nbsp;– identifying the elements and their versions that are tested together
-</p>
-<ul>
- <li>
- What changes are in this build (completed work items)
- </li>
- <li>
- What&nbsp;changes are&nbsp;partially in this build (work items that are partially complete)
- </li>
- <li>
- What changes are&nbsp;not in this build (work items that are not reflected at all in this build)
- </li>
-</ul>
-<p>
- <strong>Verification Level</strong> – identifying what amount of testing is complete.&nbsp; For example,
-</p>
-<ul>
- <li>
- Unit Tested
- </li>
- <li>
- Integration Tested
- </li>
- <li>
- System Tested
- </li>
-</ul>
-<p>
- The promotion lifecycle coordinates and synchronizes the efforts of the development team. This lifecycle consists of
- the following steps:
-</p>
-<ul>
- <li>
- Changes are introduced into the system in the form of completed&nbsp;<a class="elementLink" href="./../../../core.mgmt.common.extend_supp/guidances/concepts/change_set_430bf233.html" guid="_1QU9MAIoEdyLh7vsrHZ4YA">Change Set</a>s
- </li>
- <li>
- A build is generated clearly identifying the&nbsp;changes included in the build
- </li>
- <li>
- Testing is conducted
- </li>
- <li>
- When testing is successful the changes are marked with the appropriate&nbsp;verification level through labeling,
- baselining or other related techniques.
- </li>
-</ul>
-<p>
- Ultimately all required testing is complete and a new system&nbsp;increment is ready.
-</p>
-<p>
- Separate&nbsp;<a class="elementLink" href="./../../../practice.tech.continuous_integration.base/guidances/concepts/workspace_722BBA90.html" guid="_0cEmAMlgEdmt3adZL5Dmdw">Workspace</a>s are often used as the context for each level of testing. As changes are
- added to the <a class="elementLink" href="./../../../practice.tech.continuous_integration.base/guidances/concepts/workspace_722BBA90.html" guid="_0cEmAMlgEdmt3adZL5Dmdw">Workspace</a>, it is verified for consistency and tested. This ensures that the effort
- of testing a build is applied to the correct&nbsp;set of changes, makes the context for the tests stable,&nbsp;and also
- allows developers to continue working on the next build while the tests are being conducted.
-</p>
-<p>
- A change promotion lifecycle such as this offers three key benefits
-</p>
-<ol>
- <li>
- Reduces effort because there is no reason to execute the tests in the next stages until the&nbsp;changes passes the
- previous stage. For example you would not commit the resources to&nbsp;system testing a build until it
- passes&nbsp;developer tests.
- </li>
- <li>
- Helps to ensure that a change&nbsp;which is moved into production has been subjected to the appropriate level of
- testing first.
- </li>
- <li>
- Simplifies debugging since developers can base their work on a proven&nbsp;set of changes&nbsp;in relative
- isolation from destabilizing changes from other developers
- </li>
-</ol>
-<p>
- For an example of this approach see <a href="http://www.agiledata.org/essays/sandboxes.html" target="_blank">Development Sandboxes: An Agile "Best" Practice.</a>
+ <mainDescription><p>
+ During iterative software development, the team&nbsp;creates numerous <a class="elementLink"
+ href="./../../../core.mgmt.common.extend_supp/guidances/concepts/change_set_430BF233.html"
+ guid="_1QU9MAIoEdyLh7vsrHZ4YA">Change Set</a>s that are combined into a <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/workproducts/build_95D7D8FD.html"
+ guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a>. A build is initiated by combining the work completed by one or more
+ developers and resolving any conflicts between those changes. Ideally a build is then subjected to a battery of tests
+ to determine if it is of sufficient quality to move into production.
+</p>
+<p>
+ As the changes progress from development towards production, its beneficial to know two characteristics:
+</p>
+<p>
+ <strong>Test Context</strong>&nbsp;– identifying the elements and their versions that are tested together
+</p>
+<ul>
+ <li>
+ What changes are in this build (completed work items)
+ </li>
+ <li>
+ What&nbsp;changes are&nbsp;partially in this build (work items that are partially complete)
+ </li>
+ <li>
+ What changes are&nbsp;not in this build (work items that are not reflected at all in this build)
+ </li>
+</ul>
+<p>
+ <strong>Verification Level</strong> – identifying what amount of testing is complete.&nbsp; For example,
+</p>
+<ul>
+ <li>
+ Unit Tested
+ </li>
+ <li>
+ Integration Tested
+ </li>
+ <li>
+ System Tested
+ </li>
+</ul>
+<p>
+ The promotion lifecycle coordinates and synchronizes the efforts of the development team. This lifecycle consists of
+ the following steps:
+</p>
+<ul>
+ <li>
+ Changes are introduced into the system in the form of completed&nbsp;<a class="elementLink"
+ href="./../../../core.mgmt.common.extend_supp/guidances/concepts/change_set_430BF233.html"
+ guid="_1QU9MAIoEdyLh7vsrHZ4YA">Change Set</a>s
+ </li>
+ <li>
+ A build is generated clearly identifying the&nbsp;changes included in the build
+ </li>
+ <li>
+ Testing is conducted
+ </li>
+ <li>
+ When testing is successful the changes are marked with the appropriate&nbsp;verification level through labeling,
+ baselining or other related techniques.
+ </li>
+</ul>
+<p>
+ Ultimately all required testing is complete and a new system&nbsp;increment is ready.
+</p>
+<p>
+ Separate&nbsp;<a class="elementLink"
+ href="./../../../practice.tech.continuous_integration.base/guidances/concepts/workspace_722BBA90.html"
+ guid="_0cEmAMlgEdmt3adZL5Dmdw">Workspace</a>s are often used as the context for each level of testing. As changes are
+ added to the <a class="elementLink"
+ href="./../../../practice.tech.continuous_integration.base/guidances/concepts/workspace_722BBA90.html"
+ guid="_0cEmAMlgEdmt3adZL5Dmdw">Workspace</a>, it is verified for consistency and tested. This ensures that the effort
+ of testing a build is applied to the correct&nbsp;set of changes, makes the context for the tests stable,&nbsp;and also
+ allows developers to continue working on the next build while the tests are being conducted.
+</p>
+<p>
+ A change promotion lifecycle such as this offers three key benefits
+</p>
+<ol>
+ <li>
+ Reduces effort because there is no reason to execute the tests in the next stages until the&nbsp;changes passes the
+ previous stage. For example you would not commit the resources to&nbsp;system testing a build until it
+ passes&nbsp;developer tests.
+ </li>
+ <li>
+ Helps to ensure that a change&nbsp;which is moved into production has been subjected to the appropriate level of
+ testing first.
+ </li>
+ <li>
+ Simplifies debugging since developers can base their work on a proven&nbsp;set of changes&nbsp;in relative
+ isolation from destabilizing changes from other developers
+ </li>
+</ol>
+<p>
+ For an example of this approach see <a href="http://www.agiledata.org/essays/sandboxes.html"
+ target="_blank">Development Sandboxes: An Agile "Best" Practice.</a>
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.continuous_integration.base/guidances/practices/continous_integration.xmi b/epf_prac_151/practice.tech.continuous_integration.base/guidances/practices/continous_integration.xmi
index 1a25bb8..fac19ab 100644
--- a/epf_prac_151/practice.tech.continuous_integration.base/guidances/practices/continous_integration.xmi
+++ b/epf_prac_151/practice.tech.continuous_integration.base/guidances/practices/continous_integration.xmi
@@ -1,27 +1,27 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:PracticeDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-CtyoBMfPzn2SCjU-fK3ehg" name="continous_integration,_rJNiMB4rEd2bS8fFOQ7WWA" guid="-CtyoBMfPzn2SCjU-fK3ehg" changeDate="2010-08-27T03:48:17.000-0700" version="7.5.0">
- <mainDescription><h3>
- The essence of continuous integration
-</h3>
-<p>
- The essence of continuous integration can be described by the following activities:
-</p>
-<ul>
- <li>
- Developers make small changes to the latest integration-tested implementation in their workspaces, and they unit
- test them before making the changes available to the team.
- </li>
-</ul>
-<ul>
- <li>
- Change sets from all developers are integrated in an integration workspace and tested frequently (at least daily--
- ideally any time a new change set is available).
- </li>
-</ul>
-<p>
- The first activity ensures that changes are made to a configuration that is known to be good and tested before making
- the changes available. The second activity identifies integration issues early so that they can be corrected while the
- change is still fresh in the developer's mind.
+ <mainDescription><h3>
+ The essence of continuous integration
+</h3>
+<p>
+ The essence of continuous integration can be described by the following activities:
+</p>
+<ul>
+ <li>
+ Developers make small changes to the latest integration-tested implementation in their workspaces, and they unit
+ test them before making the changes available to the team.
+ </li>
+</ul>
+<ul>
+ <li>
+ Change sets from all developers are integrated in an integration workspace and tested frequently (at least daily--
+ ideally any time a new change set is available).
+ </li>
+</ul>
+<p>
+ The first activity ensures that changes are made to a configuration that is known to be good and tested before making
+ the changes available. The second activity identifies integration issues early so that they can be corrected while the
+ change is still fresh in the developer's mind.
</p></mainDescription>
<additionalInfo><h3>
Books and articles<br />
@@ -31,7 +31,7 @@
<tbody>
<tr>
<td colspan="2">
- Martin Fowler. "Continuous Integration," <a
+ Martin Fowler. "Continuous Integration," <a
href="http://www.martinfowler.com/articles/continuousIntegration.html"
target="_blank">www.martinfowler.com/articles/continuousIntegration.html</a> (2006).
</td>
diff --git a/epf_prac_151/practice.tech.continuous_integration.base/guidances/roadmaps/how_to_adopt_continuous_integration.xmi b/epf_prac_151/practice.tech.continuous_integration.base/guidances/roadmaps/how_to_adopt_continuous_integration.xmi
index cf3d511..ddb1260 100644
--- a/epf_prac_151/practice.tech.continuous_integration.base/guidances/roadmaps/how_to_adopt_continuous_integration.xmi
+++ b/epf_prac_151/practice.tech.continuous_integration.base/guidances/roadmaps/how_to_adopt_continuous_integration.xmi
@@ -1,86 +1,107 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-b9r9AqTZkhRIh8JdHv5pDQ" name="new_roadmap,_4qbzQPnTEdyLA5PXdgVJXw" guid="-b9r9AqTZkhRIh8JdHv5pDQ" changeDate="2008-08-18T11:36:57.000-0700" version="7.2.0">
- <mainDescription><h3> Getting started </h3>
-<p> The ultimate goal of continuous integration (CI) is to integrate and test
- the system on every change to minimize the time between injecting a defect and
- correcting it. If the team is new to continuous integration, though, it is best
- to start small and then incrementally add subpractices, as identified in the
- subsection that follows. For example, start with a simple daily integration
- build and incrementally add tests and automated inspections (code coverage,
- and so forth) to the build process, over time. As the team begins to adopt the
- sub-practices increase the build frequency. The following subpractices provide
- guidance in adopting CI. </p>
-<h4> Developer practices </h4>
-<ul>
- <li><b> Make changes available frequently.</b> For CI to be effective, <a class="elementLink" href="./../../../core.mgmt.common.extend_supp/guidances/concepts/change_set_430bf233.html" guid="_1QU9MAIoEdyLh7vsrHZ4YA">Change Set</a>s need to be small, complete, cohesive, and <em>available</em> for
- integration. Keep change sets small so that they can be completed and tested
- in a relatively short time span.</li>
-</ul>
-<ul>
- <li><b> Don't break the build. </b>Test your changes by using a private build
- before making your changes available. </li>
-</ul>
-<ul>
- <li><b>Fix broken builds immediately. </b>When a problem is identified, fix
- it as soon as possible, while it is still fresh in your mind. If the problem
- cannot be quickly resolved, back out (do not complete) the changes. </li>
-</ul>
-<h4> Integration practices </h4>
-<p> A build is more than a compile (compilation). A build consists of compilation,
- testing, inspection, and deployment. </p>
-<ul>
- <li> <b>Provide feedback </b>as quickly as possible. </li>
-</ul>
-<ul>
- <li><b>Automate the build process</b> so that it is fast and repeatable and
- so that issues are identified and conveyed to the appropriate person for resolution
- as quickly as possible. </li>
-</ul>
-<h4>
- Automation
-</h4>
-<ul>
- <li> Commit your test scripts to the CM repository so they are controlled and
- available to the rest of the team. Automated testing is highly recommended,
- both for developer tests and integration tests. Tests need to be repeatable
- and fast. </li>
-</ul>
-<ul>
- <li> Commit your build scripts to the CM repository so they are controlled and
- available to the rest of the team. Automated builds are highly recommended,
- both for private builds and integration builds. Builds need to be repeatable
- and fast. </li>
-</ul>
-<ul>
- <li> Invest in a CI server.The goal of continuous integration is to integrate,
- build, and test the software in a clean environment any time that there is
- a change to the implementation. Although a dedicated CI server is not essential,
- it will greatly reduce the overhead required to integrate continuously and
- provide the required reporting. </li>
-</ul>
-<h3> Common pitfalls </h3>
-<ul>
- <li> <b>A build process that doesn't identify problems.</b> A build is more
- that a simple compilation (or its dynamic language variations). Sound testing
- and inspection practices, both developer testing and integration testing,
- must be adopted also to ensure the right amount of coverage. </li>
-</ul>
-<ul>
- <li> <b>Integration builds that take too long to complete. </b>The build process
- must balance coverage with speed. You don't have to run every system level
- acceptance test to meet the intent of CI. Staged builds will provide a useful
- means to organize testing to get the balance coverage and speed. </li>
-</ul>
-<ul>
- <li> <b>Change sets that are too large.</b> Developers must develop the discipline
- and skills to organize their work into small, cohesive change sets. This will
- simplify testing, debugging, and reporting. It will also ensure that changes
- are made available frequently enough to meet the intention of continuous integration.
- </li>
-</ul>
-
-<ul>
- <li> <b>Failure to commit defects to the CM repository. </b>Ensure adequate
- testing by developers before making change sets available. </li>
+ <mainDescription><h3>
+ Getting started&nbsp;
+</h3>
+<p>
+ The ultimate goal of continuous integration (CI) is to integrate and test the system on every change to minimize the
+ time between injecting a defect and correcting it. If the team is new to continuous integration, though, it is best to
+ start small and then incrementally add subpractices, as identified in the subsection that follows. For example, start
+ with a simple daily integration build and incrementally add tests and automated inspections (code coverage, and so
+ forth) to the build process, over time. As the team begins to adopt the sub-practices increase the build frequency. The
+ following subpractices provide guidance in adopting CI.
+</p>
+<h4>
+ Developer practices
+</h4>
+<ul>
+ <li>
+ <b>Make changes available frequently.</b> For CI to be effective, <a class="elementLink"
+ href="./../../../core.mgmt.common.extend_supp/guidances/concepts/change_set_430BF233.html"
+ guid="_1QU9MAIoEdyLh7vsrHZ4YA">Change Set</a>s need to be small, complete, cohesive, and <em>available</em> for
+ integration. Keep change sets small so that they can be completed and tested in a relatively short time span.
+ </li>
+</ul>
+<ul>
+ <li>
+ <b>Don't break the build.</b> Test your changes by using a private build before making your changes available.
+ </li>
+</ul>
+<ul>
+ <li>
+ <b>Fix broken builds immediately.</b> When a problem is identified, fix it as soon as possible, while it is still
+ fresh in your mind. If the problem cannot be quickly resolved, back out (do not complete) the changes.
+ </li>
+</ul>
+<h4>
+ Integration practices
+</h4>
+<p>
+ A build is more than a compile (compilation). A build consists of compilation, testing, inspection, and deployment.
+</p>
+<ul>
+ <li>
+ <b>Provide feedback</b> as quickly as possible.
+ </li>
+</ul>
+<ul>
+ <li>
+ <b>Automate the build process</b> so that it is fast and repeatable and so that issues are identified and conveyed
+ to the appropriate person for resolution as quickly as possible.
+ </li>
+</ul>
+<h4>
+ Automation
+</h4>
+<ul>
+ <li>
+ Commit your test scripts to the CM repository so they are controlled and available to the rest of the team.
+ Automated testing is highly recommended, both for developer tests and integration tests. Tests need to be
+ repeatable and fast.
+ </li>
+</ul>
+<ul>
+ <li>
+ Commit your build scripts to the CM repository so they are controlled and available to the rest of the team.
+ Automated builds are highly recommended, both for private builds and integration builds. Builds need to be
+ repeatable and fast.
+ </li>
+</ul>
+<ul>
+ <li>
+ Invest in a CI server.The goal of continuous integration is to integrate, build, and test the software in a clean
+ environment any time that there is a change to the implementation. Although a dedicated CI server is not essential,
+ it will greatly reduce the overhead required to integrate continuously and provide the required reporting.
+ </li>
+</ul>
+<h3>
+ Common pitfalls
+</h3>
+<ul>
+ <li>
+ <b>A build process that doesn't identify problems.</b> A build is more that a simple compilation (or its dynamic
+ language variations). Sound testing and inspection practices, both developer testing and integration testing, must
+ be adopted also to ensure the right amount of coverage.
+ </li>
+</ul>
+<ul>
+ <li>
+ <b>Integration builds that take too long to complete.</b> The build process must balance coverage with speed. You
+ don't have to run every system level acceptance test to meet the intent of CI. Staged builds will provide a useful
+ means to organize testing to get the balance coverage and speed.
+ </li>
+</ul>
+<ul>
+ <li>
+ <b>Change sets that are too large.</b> Developers must develop the discipline and skills to organize their work
+ into small, cohesive change sets. This will simplify testing, debugging, and reporting. It will also ensure that
+ changes are made available frequently enough to meet the intention of continuous integration.
+ </li>
+</ul>
+<ul>
+ <li>
+ <b>Failure to commit defects to the CM repository.</b> Ensure adequate testing by developers before making change
+ sets available.
+ </li>
</ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.continuous_integration.base/tasks/integrate_and_create_build.xmi b/epf_prac_151/practice.tech.continuous_integration.base/tasks/integrate_and_create_build.xmi
index 53b78c8..6a89267 100644
--- a/epf_prac_151/practice.tech.continuous_integration.base/tasks/integrate_and_create_build.xmi
+++ b/epf_prac_151/practice.tech.continuous_integration.base/tasks/integrate_and_create_build.xmi
@@ -1,16 +1,20 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:TaskDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-01L_eCnHjKmBPsGcdk8XTg" name=",_Dq0GQAIoEdyLh7vsrHZ4YA" guid="-01L_eCnHjKmBPsGcdk8XTg" changeDate="2008-09-08T06:12:53.000-0700" version="7.2.0">
- <keyConsiderations><p>
- In order to be effective at applying the practice of <a class="elementLink" href="./../../practice.tech.continuous_integration.base/guidances/guidelines/continuous_integration_13C1A8CA.html" guid="_i8bUEL6cEdqti4GwqTkbsQ">Continuous Integration</a>,&nbsp;the time to integrate, build, and test the increment
- must be short enough that it can be performed several times per day.&nbsp; Changes should be broken down into
- relatively small <a class="elementLink" href="./../../core.mgmt.common.extend_supp/guidances/concepts/change_set_430bf233.html" guid="_1QU9MAIoEdyLh7vsrHZ4YA">Change Set</a>s that can be implemented, integrated and tested quickly.
+ <keyConsiderations><p>
+ In order to be effective at applying the practice of <a class="elementLink"
+ href="./../../practice.tech.continuous_integration.base/guidances/guidelines/continuous_integration_13C1A8CA.html"
+ guid="_i8bUEL6cEdqti4GwqTkbsQ">Continuous Integration</a>,&nbsp;the time to integrate, build, and test the increment
+ must be short enough that it can be performed several times per day.&nbsp; Changes should be broken down into
+ relatively small <a class="elementLink"
+ href="./../../core.mgmt.common.extend_supp/guidances/concepts/change_set_430BF233.html"
+ guid="_1QU9MAIoEdyLh7vsrHZ4YA">Change Set</a>s that can be implemented, integrated and tested quickly.
</p></keyConsiderations>
<sections xmi:id="_kkZBhZOKEdyaRbFYa4AN4A" name="Integrate implemented elements" guid="_kkZBhZOKEdyaRbFYa4AN4A">
<sectionDescription><p>
In&nbsp;the relevant&nbsp;<a class="elementLink"
href="./../../practice.tech.continuous_integration.base/guidances/concepts/workspace_722BBA90.html"
guid="_0cEmAMlgEdmt3adZL5Dmdw">Workspace</a>, combine all completed&nbsp;<a class="elementLink"
- href="./../../core.mgmt.common.extend_supp/guidances/concepts/change_set_430bf233.html"
+ href="./../../core.mgmt.common.extend_supp/guidances/concepts/change_set_430BF233.html"
guid="_1QU9MAIoEdyLh7vsrHZ4YA">Change Set</a>s that are not in the latest baseline. Resolve any conflicting versions of
the artifacts by either removing one of the change sets that created the conflict&nbsp;or by creating a new change set
that includes merged versions of the conflicting artifacts.
@@ -71,7 +75,7 @@
guid="_i8bUEL6cEdqti4GwqTkbsQ">Continuous Integration</a>.
</p></sectionDescription>
</sections>
- <purpose>The purpose of this task is to integrate all changes made by all developers into the code base and perform the minimal
-testing on the system increment in order to validate the build.&nbsp; The goal is to identify integration issues as soon as
+ <purpose>The purpose of this task is to integrate all changes made by all developers into the code base and perform the minimal
+testing on the system increment in order to validate the build.&nbsp; The goal is to identify integration issues as soon as
possible, so they can be corrected easily by the right person, at the right time.</purpose>
</org.eclipse.epf.uma:TaskDescription>
diff --git a/epf_prac_151/practice.tech.evolutionary_arch.base/guidances/guidelines/modeling_the_arch.xmi b/epf_prac_151/practice.tech.evolutionary_arch.base/guidances/guidelines/modeling_the_arch.xmi
index d51da11..be6bc5b 100644
--- a/epf_prac_151/practice.tech.evolutionary_arch.base/guidances/guidelines/modeling_the_arch.xmi
+++ b/epf_prac_151/practice.tech.evolutionary_arch.base/guidances/guidelines/modeling_the_arch.xmi
@@ -1,29 +1,29 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-mEJbo_5lG227hXMdftmX_A" name="new_guideline_2,_HrgUQNcuEdy1nJEYZGzN4A" guid="-mEJbo_5lG227hXMdftmX_A" changeDate="2008-10-15T06:32:49.000-0700" version="7.2.0">
- <mainDescription><p>
- When architecting a system, developing visual models of the architecture can be quite helpful as such models provide an
- excellent high-level picture of the system, its <a class="elementLink"
- href="./../../../core.tech.common.extend_supp/guidances/concepts/component_CB167D48.html"
- guid="_0YP18MlgEdmt3adZL5Dmdw">Component</a>s and their relationships. Specifically, you may find it useful to develop
- these three Unified Modeling Language (UML) diagrams:
-</p>
-<ul>
- <li>
- <strong>Layer map</strong> (represented as a class diagram using packages) that describes the upper-level layers of
- the architecture
- </li>
- <li>
- <strong>Deployment diagram</strong> (represented by a deployment diagram) that outlines the&nbsp;expected network
- topology
- </li>
- <li>
- <strong>Key Abstractions diagram</strong> (represented by a class diagram) that shows the key
- abstractions/components&nbsp;and important relationships among them
- </li>
-</ul>
-<p>
- For more information on visual modeling, see <a class="elementLinkWithType"
- href="./../../../core.tech.common.extend_supp/guidances/guidelines/using_visual_modeling_DA1CA6E4.html"
- guid="_0SsecNr8EdyXE6np2_hUMA">Guideline: Using Visual Modeling</a>.
+ <mainDescription><p>
+ When architecting a system, developing visual models of the architecture can be quite helpful as such models provide an
+ excellent high-level picture of the system, its <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/component_CB167D48.html"
+ guid="_0YP18MlgEdmt3adZL5Dmdw">Component</a>s and their relationships. Specifically, you may find it useful to develop
+ these three Unified Modeling Language (UML) diagrams:
+</p>
+<ul>
+ <li>
+ <strong>Layer map</strong> (represented as a class diagram using packages) that describes the upper-level layers of
+ the architecture
+ </li>
+ <li>
+ <strong>Deployment diagram</strong> (represented by a deployment diagram) that outlines the&nbsp;expected network
+ topology
+ </li>
+ <li>
+ <strong>Key Abstractions diagram</strong> (represented by a class diagram) that shows the key
+ abstractions/components&nbsp;and important relationships among them
+ </li>
+</ul>
+<p>
+ For more information on visual modeling, see <a class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/guidelines/using_visual_modeling_DA1CA6E4.html"
+ guid="_0SsecNr8EdyXE6np2_hUMA">Guideline: Using Visual Modeling</a>.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.evolutionary_arch.base/guidances/practices/evolutionary_arch.xmi b/epf_prac_151/practice.tech.evolutionary_arch.base/guidances/practices/evolutionary_arch.xmi
index 5d7e3c2..53483e5 100644
--- a/epf_prac_151/practice.tech.evolutionary_arch.base/guidances/practices/evolutionary_arch.xmi
+++ b/epf_prac_151/practice.tech.evolutionary_arch.base/guidances/practices/evolutionary_arch.xmi
@@ -1,44 +1,47 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:PracticeDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-TleqHW_wvIYc0qLQgZUchA" name="new_practice,_uVnpQB4qEd2bS8fFOQ7WWA" guid="-TleqHW_wvIYc0qLQgZUchA" changeDate="2008-10-15T06:27:20.000-0700" version="7.5.0">
- <mainDescription><h3>
- The essence of evolutionary architecture
-</h3>
-<p>
- In the Evolutionary Architecture practice, you analyze the major technical concerns that affect the solution and
- document architectural decisions to ensure that you have assessed and communicated those decisions.
-</p>
-<h3>
- The key principles of the Evolutionary Architecture practice are:
-</h3>
-<ul type="disc">
- <li class="MsoNormal c3">
- <strong><span class="c1">Perform architecture work "just in time" for all other work.</span></strong> <span
- class="c1">When planning your project, identify and discuss architectural issues with your team, and then
- prioritize architectural work with any other work.</span> Base your priorities on mitigating technical risk rather
- than creating value. Deferring architectural issues to handle them "just in time" enables the architecture to
- <em><span class="c2">evolve over time</span></em>.
- </li>
-</ul>
-<ul type="disc">
- <li class="MsoNormal c3">
- <strong><span class="c1">Document key architectural decisions and outstanding issues</span></strong><span
- class="c1">. The <a class="elementLink"
- href="./../../../practice.tech.evolutionary_arch.base/workproducts/architecture_notebook_9BB92433.html"
- guid="_0XAf0MlgEdmt3adZL5Dmdw">Architecture Notebook</a> a list of the architectural issues to make it easy to
- understand which architectural decisions you've made and which you've not yet addressed.</span>
- </li>
-</ul>
-<ul type="disc">
- <li class="MsoNormal c3">
- <strong><span class="c1">Implement and test key capabilities as a way to address architectural
- issues</span></strong><span class="c1">. Resolving architectural issues typically requires not only architectural
- brainstorming, but also associated prototyping. In other words: implement enough code to validate the assumptions
- behind the architecture. The code becomes production code, except for anything thrown away because it proves the
- architecture invalid.</span>
- </li>
+ <mainDescription><h3>
+ The essence of evolutionary architecture
+</h3>
+<p>
+ In the Evolutionary Architecture practice, you analyze the major technical concerns that affect the solution and
+ document architectural decisions to ensure that you have assessed and communicated those decisions.
+</p>
+<h3>
+ The key principles of the Evolutionary Architecture practice are:
+</h3>
+<ul type="disc">
+ <li class="MsoNormal c3">
+ <strong><span class="c1">Perform architecture work "just in time" for all other work.</span></strong> <span
+ class="c1">When planning your project, identify and discuss architectural issues with your team, and then
+ prioritize architectural work with any other work.</span> Base your priorities on mitigating technical risk rather
+ than creating value. Deferring architectural issues to handle them "just in time" enables the architecture to
+ <em><span class="c2">evolve over time</span></em>.
+ </li>
+</ul>
+<ul type="disc">
+ <li class="MsoNormal c3">
+ <strong><span class="c1">Document key architectural decisions and outstanding issues</span></strong><span
+ class="c1">. The <a class="elementLink"
+ href="./../../../practice.tech.evolutionary_arch.base/workproducts/architecture_notebook_9BB92433.html"
+ guid="_0XAf0MlgEdmt3adZL5Dmdw">Architecture Notebook</a> a list of the architectural issues to make it easy to
+ understand which architectural decisions you've made and which you've not yet addressed.</span>
+ </li>
+</ul>
+<ul type="disc">
+ <li class="MsoNormal c3">
+ <strong><span class="c1">Implement and test key capabilities as a way to address architectural
+ issues</span></strong><span class="c1">. Resolving architectural issues typically requires not only architectural
+ brainstorming, but also associated prototyping. In other words: implement enough code to validate the assumptions
+ behind the architecture. The code becomes production code, except for anything thrown away because it proves the
+ architecture invalid.</span>
+ </li>
</ul></mainDescription>
- <additionalInfo><h3> Additional resources </h3>
-<p> See these sources for more information on the evolutionary architecture approach: 
+ <additionalInfo><h3>
+ Additional resources
+</h3>
+<p>
+ See these sources for more information on the evolutionary architecture approach:
</p>
<ul>
<li>
@@ -54,34 +57,36 @@
Architecture</a>
</li>
</ul><br /></additionalInfo>
- <problem><p> <span class="c1">The Evolutionary Architecture practice describes how to incrementally 
- build and improve the software architecture while uncovering and addressing 
- architectural issues during software development. This reduces technical risk 
- without requiring significant up-front architectural effort.</span> </p>
+ <problem><p>
+ <span class="c1">The Evolutionary Architecture practice describes how to incrementally build and improve the software
+ architecture while uncovering and addressing architectural issues during software development. This reduces technical
+ risk without requiring significant up-front architectural effort.</span>
+</p>
<p>
<span class="c1">This practice:</span>
</p>
<ul>
- <li>Improves quality and productivity by reducing the need to make time-consuming, 
- error-prone fixes to late-detected problems that result from architectural 
- flaws. This is possible because the architecture is validated early, and key 
- architectural problems are corrected before the majority of development is 
- done.<span class="c1"></span> </li>
+ <li>
+ Improves quality and productivity by reducing the need to make time-consuming, error-prone fixes to late-detected
+ problems that result from architectural flaws. This is possible because the architecture is validated early, and
+ key architectural problems are corrected before the majority of development is done.
+ </li>
</ul>
<ul>
- <li> Reduces time to market by focusing on reuse. It 
- improves the consistency and maintainability of the system by incorporating 
- lessons learned from development back into the architecture and applying those 
- lessons to the rest of development.<span class="c1"></span> </li>
+ <li>
+ Reduces time to market by focusing on reuse. It improves the consistency and maintainability of the system by
+ incorporating lessons learned from development back into the architecture and applying those lessons to the rest of
+ development.
+ </li>
</ul>
<ul>
- <li> 
- <div class="MsoNormal c2"> <span class="c1">Improves predictability by identifying 
- and implementing the highest-risk technical areas first.</span> It improves 
- the team's responsiveness to change by shortening the architectural cycle 
- and minimizing time wasted in architectural scrap and rework when changes 
- arise. </div>
- </li>
+ <li>
+ <div class="MsoNormal c2">
+ <span class="c1">Improves predictability by identifying and implementing the highest-risk technical areas
+ first.</span> It improves the team's responsiveness to change by shortening the architectural cycle and
+ minimizing time wasted in architectural scrap and rework when changes arise.
+ </div>
+ </li>
</ul></problem>
<application><p>
The best way to read this practice is to first familiarize yourself with its overall structure: what is in it and how
diff --git a/epf_prac_151/practice.tech.evolutionary_arch.base/guidances/roadmaps/how_to_adopt_evolutionary_arch_practice.xmi b/epf_prac_151/practice.tech.evolutionary_arch.base/guidances/roadmaps/how_to_adopt_evolutionary_arch_practice.xmi
index eb5015c..6d81964 100644
--- a/epf_prac_151/practice.tech.evolutionary_arch.base/guidances/roadmaps/how_to_adopt_evolutionary_arch_practice.xmi
+++ b/epf_prac_151/practice.tech.evolutionary_arch.base/guidances/roadmaps/how_to_adopt_evolutionary_arch_practice.xmi
@@ -1,45 +1,68 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-KXvzdy6aJTFPQRS-UK5dvA" name="new_roadmap,_Odpz8NciEdy1nJEYZGzN4A" guid="-KXvzdy6aJTFPQRS-UK5dvA" changeDate="2008-08-11T10:28:42.000-0700" version="7.2.0">
- <mainDescription><h3> Getting started</h3>
-<p> Begin by making sure that the team and key stakeholders understand what software
- architecture is and the value of capturing it in a separate artifact. See <a class="elementLinkWithType" href="./../../../core.tech.common.extend_supp/guidances/concepts/software_architecture_59A08DE0.html" guid="__O7tAMVvEduLYZUGfgZrkQ">Concept: Software Architecture</a>. </p>
-<p> After there is agreement that the architectural information should be captured,
- it is important to come to an agreement on what architectural information you
- want to capture and what format it should take. Review the <a class="elementLinkWithType" href="./../../../practice.tech.evolutionary_arch.base/workproducts/architecture_notebook_9BB92433.html" guid="_0XAf0MlgEdmt3adZL5Dmdw">Artifact: Architecture Notebook</a> and associated guidance. Agree on what you
- want to document. </p>
-<p> Next, review <a class="elementLinkWithType" href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_views_viewpoints_7A6CD31.html" guid="_kgtcoNc8Edyd7OybSySFxg">Concept: Architectural Views and Viewpoints</a> and <a class="elementLinkWithType" href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_mechanism_2932DFB6.html" guid="_mzxI0A4LEduibvKwrGxWxA">Concept: Architectural Mechanisms</a>. Both are crucial to understanding how to define
- and communicate the architecture. </p>
-<p> Now you can turn your attention to deciding, as a team, how and when
- the architectural tasks should be performed. </p>
-<ul>
- <li>
- If you are working on a new project and you are at the beginning of the lifecycle, review <a class="elementLinkWithType" href="./../../../practice.tech.evolutionary_arch.base/tasks/outline_the_arch_FF123A81.html" guid="_0f-1oMlgEdmt3adZL5Dmdw">Task: Outline the Architecture</a>.
- </li>
-
- <li> If you are working on a project that is already underway, take time to
- document the decisions that have already been made and continue to evolve
- the architecture as development proceeds. See <a class="elementLinkWithType" href="./../../../practice.tech.evolutionary_arch.base/tasks/refine_the_arch_7723A69E.html" guid="_0gRJgMlgEdmt3adZL5Dmdw">Task: Refine the Architecture</a>. </li>
-</ul>
-<h3> Common pitfalls </h3>
-<p> The architect should not work in isolation and just throw an architectural
- specification over the wall to the developers. This requires too much documentation
- and makes it difficult for team members to understand why the architecture needs
- to work the way it does. Building the architecture is an activity that requires
- collaboration to be successful. </p>
-<p> Avoid creating significant and detailed architectural documentation for
- agile projects. Don't get caught up in defining exactly what the structure
- of the Architecture Notebook should be. Focus on capturing the key decisions
- and the rationale for these decisions. Refer to more detailed documentation
- where necessary, and don't duplicate material. Keep the documentation clear
- and concise. Make sure that the people who use the architecture (the development
- team) are comfortable with the format and content of the architecture. Is there
- more or different information that they would like to see? Would they like to
- see less, instead? </p>
-<p> Document important decisions. Team members may be close by and you may be
- in constant contact with them, but teams change and software architects move
- on to other projects. Failure to document important decisions raises the risk
- of failure later because future team members won't have the benefit of being
- involved in today's collaborative decisions. Consider future team members as
- collaborators that you simply don't have the opportunity to speak to face-to-face.
+ <mainDescription><h3>
+ Getting started&nbsp;
+</h3>
+<p>
+ Begin by making sure that the team and key stakeholders understand what software architecture is and the value of
+ capturing it in a separate artifact. See <a class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/software_architecture_59A08DE0.html"
+ guid="__O7tAMVvEduLYZUGfgZrkQ">Concept: Software Architecture</a>.
+</p>
+<p>
+ After there is agreement that the architectural information should be captured, it is important to come to an agreement
+ on what architectural information you want to capture and what format it should take. Review the <a
+ class="elementLinkWithType"
+ href="./../../../practice.tech.evolutionary_arch.base/workproducts/architecture_notebook_9BB92433.html"
+ guid="_0XAf0MlgEdmt3adZL5Dmdw">Artifact: Architecture Notebook</a> and associated guidance. Agree on what you want to
+ document.
+</p>
+<p>
+ Next, review <a class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_views_viewpoints_7A6CD31.html"
+ guid="_kgtcoNc8Edyd7OybSySFxg">Concept: Architectural Views and Viewpoints</a> and <a class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_mechanism_2932DFB6.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Concept: Architectural Mechanism</a>. Both are crucial to understanding how to define
+ and communicate the architecture.
+</p>
+<p>
+ Now you can turn your attention to deciding, as a team, how and when the architectural tasks should be performed.
+</p>
+<ul>
+ <li>
+ If you are working on a new project and you are at the beginning of the lifecycle, review <a
+ class="elementLinkWithType"
+ href="./../../../practice.tech.evolutionary_arch.base/tasks/envision_the_arch_FF123A81.html"
+ guid="_0f-1oMlgEdmt3adZL5Dmdw">Task: Envision the Architecture</a>.
+ </li>
+ <li>
+ If you are working on a project that is already underway, take time to document the decisions that have already
+ been made and continue to evolve the architecture as development proceeds. See <a class="elementLinkWithType"
+ href="./../../../practice.tech.evolutionary_arch.base/tasks/refine_the_arch_7723A69E.html"
+ guid="_0gRJgMlgEdmt3adZL5Dmdw">Task: Refine the Architecture</a>.
+ </li>
+</ul>
+<h3>
+ Common pitfalls
+</h3>
+<p>
+ The architect should not work in isolation and just throw an architectural specification over the wall to the
+ developers. This requires too much documentation and makes it difficult for team members to understand why the
+ architecture needs to work the way it does. Building the architecture is an activity that requires collaboration to be
+ successful.
+</p>
+<p>
+ Avoid creating significant and detailed architectural documentation for agile projects. Don't get caught up in defining
+ exactly what the structure of the Architecture Notebook should be. Focus on capturing the key decisions and the
+ rationale for these decisions. Refer to more detailed documentation where necessary, and don't duplicate material. Keep
+ the documentation clear and concise. Make sure that the people who use the architecture (the development team) are
+ comfortable with the format and content of the architecture. Is there more or different information that they would
+ like to see? Would they like to see less, instead?
+</p>
+<p>
+ Document important decisions. Team members may be close by and you may be in constant contact with them, but teams
+ change and software architects move on to other projects. Failure to document important decisions raises the risk of
+ failure later because future team members won't have the benefit of being involved in today's collaborative decisions.
+ Consider future team members as collaborators that you simply don't have the opportunity to speak to face-to-face.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.evolutionary_arch.base/guidances/supportingmaterials/release_info_evolutionary_arch.xmi b/epf_prac_151/practice.tech.evolutionary_arch.base/guidances/supportingmaterials/release_info_evolutionary_arch.xmi
index 484b51e..97590fc 100644
--- a/epf_prac_151/practice.tech.evolutionary_arch.base/guidances/supportingmaterials/release_info_evolutionary_arch.xmi
+++ b/epf_prac_151/practice.tech.evolutionary_arch.base/guidances/supportingmaterials/release_info_evolutionary_arch.xmi
@@ -1,5 +1,5 @@
<?xml version="1.0" encoding="UTF-8"?>
-<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmi:id="-Iyj1LA3WbTQP_iQmRp7ibw" name="release_info_evolutionary_arch,_rA1NMc3lEdyjXslGsagg_w" guid="-Iyj1LA3WbTQP_iQmRp7ibw" changeDate="2010-09-20T09:17:03.407-0700" version="7.2.0">
+<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-Iyj1LA3WbTQP_iQmRp7ibw" name="release_info_evolutionary_arch,_rA1NMc3lEdyjXslGsagg_w" guid="-Iyj1LA3WbTQP_iQmRp7ibw" changeDate="2010-09-20T09:17:03.407-0700" version="7.2.0">
<mainDescription><h3>
EPF base
</h3>
@@ -123,11 +123,11 @@
Architecture and the Task: Refine the Architecture)
</li>
<li>
- Guideline: Using Visual Modeling (added to capture visual modeling techniques, because content was originally in an
- addendum to the Guideline: Abstract Away Complexity)
+ Guideline: Using Visual Modeling (visual modeling was originally in an addendum to the Guideline: Abstract Away
+ Complexity)
</li>
<li>
- Guideline: Modeling the Architecture (added to capture information on visual architectural models)
+ Guideline: Modeling the Architecture (information on visual architectural models)
</li>
<li>
Practice elements (elements common to all practices):
diff --git a/epf_prac_151/practice.tech.evolutionary_arch.base/guidances/templates/architecture_notebook.xmi b/epf_prac_151/practice.tech.evolutionary_arch.base/guidances/templates/architecture_notebook.xmi
index cd6a723..381bf01 100644
--- a/epf_prac_151/practice.tech.evolutionary_arch.base/guidances/templates/architecture_notebook.xmi
+++ b/epf_prac_151/practice.tech.evolutionary_arch.base/guidances/templates/architecture_notebook.xmi
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:GuidanceDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-h09djKXIOUJlez8h6UXrWw" name=",_me8WcAANEdyRS9uciXlZ6g" guid="-h09djKXIOUJlez8h6UXrWw" changeDate="2007-05-11T03:20:56.000-0700" version="7.2.0">
- <mainDescription><p>
- Attached is a template applicable for describing the architecture for a small, co-located project.
+ <mainDescription><p>
+ Attached is a template applicable for describing the architecture for a small, co-located project.
</p></mainDescription>
<attachments>resources/architecture_notebook_tpl.dot</attachments>
</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/epf_prac_151/practice.tech.evolutionary_arch.base/tasks/envision_the_arch.vm.xmi b/epf_prac_151/practice.tech.evolutionary_arch.base/tasks/envision_the_arch.vm.xmi
index af905d7..9341da1 100644
--- a/epf_prac_151/practice.tech.evolutionary_arch.base/tasks/envision_the_arch.vm.xmi
+++ b/epf_prac_151/practice.tech.evolutionary_arch.base/tasks/envision_the_arch.vm.xmi
@@ -1,7 +1,9 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:TaskDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-tmKVpMZoAoS-Wkvbe_iHpQ" name=",_s4ojQNqREdy88NBoQgfGyg" guid="-tmKVpMZoAoS-Wkvbe_iHpQ" version="7.2.0">
- <keyConsiderations><p>
- At this stage, you may find it useful to develop a draft version of your architectural models.&nbsp; For more
- information, see <a class="elementLinkWithType" href="./../../practice.tech.evolutionary_arch.base/guidances/guidelines/modeling_the_arch_8BE6E55B.html" guid="_HrgUQNcuEdy1nJEYZGzN4A">Guideline: Modeling the Architecture</a>.
+ <keyConsiderations><p>
+ At this stage, you may find it useful to develop a draft version of your architectural models.&nbsp; For more
+ information, see <a class="elementLinkWithType"
+ href="./../../practice.tech.evolutionary_arch.base/guidances/guidelines/modeling_the_arch_8BE6E55B.html"
+ guid="_HrgUQNcuEdy1nJEYZGzN4A">Guideline: Modeling the Architecture</a>.
</p></keyConsiderations>
</org.eclipse.epf.uma:TaskDescription>
diff --git a/epf_prac_151/practice.tech.evolutionary_arch.base/tasks/envision_the_arch.xmi b/epf_prac_151/practice.tech.evolutionary_arch.base/tasks/envision_the_arch.xmi
index 7681550..166a3db 100644
--- a/epf_prac_151/practice.tech.evolutionary_arch.base/tasks/envision_the_arch.xmi
+++ b/epf_prac_151/practice.tech.evolutionary_arch.base/tasks/envision_the_arch.xmi
@@ -1,39 +1,39 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:TaskDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_qDRSULBKEdm7Eph_l9Cn9w" name="envision_the_arch,_0f-1oMlgEdmt3adZL5Dmdw" guid="_qDRSULBKEdm7Eph_l9Cn9w" changeDate="2010-05-26T09:05:46.000-0700" version="1.0.0">
- <mainDescription><p>
- This task focuses on envisioning the initial architecture and outlining the&nbsp;architectural decisions that will
- guide development and testing. It relies on gathering experience gained in similar systems or problem domains to
- constrain and focus the architecture so that effort is not wasted in re-inventing architecture.
-</p>
-<p>
- The results are captured for future reference and are communicated across the team. It is important that the team has
- enough information to understand the technical approach being taken.
-</p>
-<p>
- The architecture evolves organically over time by outlining and refining portions of it. A few people get together in a
- room and sketch out what they think the architecture will be. This envisioning effort sets the foundation for
- prototyping. If the solution is similar to a previously produced solution (or is a well-known solution domain), then it
- will probably be good 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 work done here does not seek to produce a detailed and comprehensive technical specification for the system.
- Rather, the approach should be to decide the overall technical approach at a high level. The conclusion of this work
- should produce just enough information to communicate the architecture to the team, and to demonstrate its viability to
- the customer. This allows the project to move forward, enabling you to refine and baseline the architecture.
+ <mainDescription><p>
+ This task focuses on envisioning the initial architecture and outlining the&nbsp;architectural decisions that will
+ guide development and testing. It relies on gathering experience gained in similar systems or problem domains to
+ constrain and focus the architecture so that effort is not wasted in re-inventing architecture.
+</p>
+<p>
+ The results are captured for future reference and are communicated across the team. It is important that the team has
+ enough information to understand the technical approach being taken.
+</p>
+<p>
+ The architecture evolves organically over time by outlining and refining portions of it. A few people get together in a
+ room and sketch out what they think the architecture will be. This envisioning effort sets the foundation for
+ prototyping. If the solution is similar to a previously produced solution (or is a well-known solution domain), then it
+ will probably be good 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 work done here does not seek to produce a detailed and comprehensive technical specification for the system.
+ Rather, the approach should be to decide the overall technical approach at a high level. The conclusion of this work
+ should produce just enough information to communicate the architecture to the team, and to demonstrate its viability to
+ the customer. This allows the project to move forward, enabling you to refine and baseline the architecture.
</p></mainDescription>
- <keyConsiderations><p>
- It&nbsp;is important to reduce the complexity of the&nbsp;solution by raising the levels of abstraction.&nbsp;For more
- information, see <a class="elementLinkWithType"
- href="./../../core.tech.common.extend_supp/guidances/guidelines/abstract_away_complexity_DBF13AE6.html"
- guid="_we3F4ACpEdu8m4dIntu6jA">Guideline: Abstract Away Complexity</a>.
-</p>
-<p>
- It is critical that this task be performed collaboratively with active involvement of other team members and project
- stakeholders so that consensus and common understanding is reached. It is particularly vital to involve the
- developer(s) throughout this task. The architecture effort&nbsp;is about providing leadership and coordination of the
- technical work rather than putting in a solo performance.
+ <keyConsiderations><p>
+ It&nbsp;is important to reduce the complexity of the&nbsp;solution by raising the levels of abstraction.&nbsp;For more
+ information, see <a class="elementLinkWithType"
+ href="./../../core.tech.common.extend_supp/guidances/guidelines/abstract_away_complexity_DBF13AE6.html"
+ guid="_we3F4ACpEdu8m4dIntu6jA">Guideline: Abstract Away Complexity</a>.
+</p>
+<p>
+ It is critical that this task be performed collaboratively with active involvement of other team members and project
+ stakeholders so that consensus and common understanding is reached. It is particularly vital to involve the
+ developer(s) throughout this task. The architecture effort&nbsp;is about providing leadership and coordination of the
+ technical work rather than putting in a solo performance.
</p></keyConsiderations>
<sections xmi:id="_3nMQQA3rEduibvKwrGxWxA" name="Identify architectural goals" guid="_3nMQQA3rEduibvKwrGxWxA">
<sectionDescription><p>
@@ -175,21 +175,21 @@
<sectionDescription>Work with the team&nbsp;to verify that the architecture is consistent with the requirements and that the descriptions of
the architecture are complete, meaningful, and clear.</sectionDescription>
</sections>
- <sections xmi:id="_Xia1QFHSEd2zrOgIte8oWg" name="Capture and communicate architectural decisions " guid="_Xia1QFHSEd2zrOgIte8oWg">
+ <sections xmi:id="_Xia1QFHSEd2zrOgIte8oWg" name="Capture and communicate architectural decisions" guid="_Xia1QFHSEd2zrOgIte8oWg">
<sectionDescription>Capture important decisions about the architecture in the <a class="elementLink"
href="./../../practice.tech.evolutionary_arch.base/workproducts/architecture_notebook_9BB92433.html"
guid="_0XAf0MlgEdmt3adZL5Dmdw">Architecture Notebook</a>&nbsp;for future reference. Make sure that&nbsp;the team
understands the architecture&nbsp;and can deliver it.</sectionDescription>
</sections>
- <purpose><p>
- To&nbsp;envision a technical approach to the system that supports the project requirements, within the constraints
- placed on the system and the development team.
-</p>
-<p>
- To provide sufficient guidance and direction for the team to begin development.
+ <purpose><p>
+ To&nbsp;envision a technical approach to the system that supports the project requirements, within the constraints
+ placed on the system and the development team.
+</p>
+<p>
+ To provide sufficient guidance and direction for the team to begin development.
</p></purpose>
- <alternatives><p>
- This task&nbsp;is most&nbsp;needed when developing new and unprecedented systems. In systems where there is already a
- well-defined architecture, this task may be omitted and replaced with a&nbsp;review of the existing architecture.
+ <alternatives><p>
+ This task&nbsp;is most&nbsp;needed when developing new and unprecedented systems. In systems where there is already a
+ well-defined architecture, this task may be omitted and replaced with a&nbsp;review of the existing architecture.
</p></alternatives>
</org.eclipse.epf.uma:TaskDescription>
diff --git a/epf_prac_151/practice.tech.evolutionary_arch.base/tasks/refine_the_arch.vm.xmi b/epf_prac_151/practice.tech.evolutionary_arch.base/tasks/refine_the_arch.vm.xmi
index 7d1692e..f381541 100644
--- a/epf_prac_151/practice.tech.evolutionary_arch.base/tasks/refine_the_arch.vm.xmi
+++ b/epf_prac_151/practice.tech.evolutionary_arch.base/tasks/refine_the_arch.vm.xmi
@@ -1,6 +1,9 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:TaskDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-E459X-McFVuJGngiFPWf6w" name=",_1kmN0NqREdy88NBoQgfGyg" guid="-E459X-McFVuJGngiFPWf6w" changeDate="2008-02-13T04:15:20.000-0800" version="7.2.0">
- <keyConsiderations><p>
- As you evolve the architecture, you may wish to evolve your architectural models.&nbsp; For more information, see <a class="elementLinkWithType" href="./../../practice.tech.evolutionary_arch.base/guidances/guidelines/modeling_the_arch_8BE6E55B.html" guid="_HrgUQNcuEdy1nJEYZGzN4A">Guideline: Modeling the Architecture</a>.
+ <keyConsiderations><p>
+ As you evolve the architecture, you may wish to evolve your architectural models.&nbsp; For more information, see <a
+ class="elementLinkWithType"
+ href="./../../practice.tech.evolutionary_arch.base/guidances/guidelines/modeling_the_arch_8BE6E55B.html"
+ guid="_HrgUQNcuEdy1nJEYZGzN4A">Guideline: Modeling the Architecture</a>.
</p></keyConsiderations>
</org.eclipse.epf.uma:TaskDescription>
diff --git a/epf_prac_151/practice.tech.evolutionary_arch.base/tasks/refine_the_arch.xmi b/epf_prac_151/practice.tech.evolutionary_arch.base/tasks/refine_the_arch.xmi
index d5008e2..f038baa 100644
--- a/epf_prac_151/practice.tech.evolutionary_arch.base/tasks/refine_the_arch.xmi
+++ b/epf_prac_151/practice.tech.evolutionary_arch.base/tasks/refine_the_arch.xmi
@@ -1,56 +1,65 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:TaskDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_rUis8LBKEdm7Eph_l9Cn9w" name="refine_the_arch,_0gRJgMlgEdmt3adZL5Dmdw" guid="_rUis8LBKEdm7Eph_l9Cn9w" changeDate="2008-08-08T11:29:21.000-0700" version="1.0.0">
- <mainDescription><p>
- This task&nbsp;builds upon the outlined architecture and makes concrete and unambiguous architectural decisions to
- support development.&nbsp; It takes into&nbsp;account any design and implementation work products that have been
- developed so far.&nbsp; In other words, the architecture evolves as the solution is designed and implemented, and the
- architecture documentation is updated to reflect any changes made during development. This is&nbsp;a key,&nbsp;since
- the actual implementation is the only real "proof" that the software architecture is viable and provides the definitive
- basis for validating the suitability&nbsp;of the architecture.&nbsp; For more information, see <a class="elementLinkWithType" href="./../../core.tech.common.extend_supp/guidances/concepts/executable_arch_D4E68CBD.html" guid="_O1kAANvfEduv2KOT-Teh6w">Concept: Executable Architecture</a>.
-</p>
-<p>
- The results are captured for future reference and are communicated across the team.
+ <mainDescription><p>
+ This task&nbsp;builds upon the outlined architecture and makes concrete and unambiguous architectural decisions to
+ support development.&nbsp; It takes into&nbsp;account any design and implementation work products that have been
+ developed so far.&nbsp; In other words, the architecture evolves as the solution is designed and implemented, and the
+ architecture documentation is updated to reflect any changes made during development. This is&nbsp;a key,&nbsp;since
+ the actual implementation is the only real "proof" that the software architecture is viable and provides the definitive
+ basis for validating the suitability&nbsp;of the architecture.&nbsp; For more information, see <a
+ class="elementLinkWithType"
+ href="./../../core.tech.common.extend_supp/guidances/concepts/executable_arch_D4E68CBD.html"
+ guid="_O1kAANvfEduv2KOT-Teh6w">Concept: Executable Architecture</a>.
+</p>
+<p>
+ The results are captured for future reference and are communicated across the team.
</p></mainDescription>
- <keyConsiderations><p>
- It is important to continue to reduce the complexity of the&nbsp;solution by raising the levels of abstraction.&nbsp;
- For more information, see <a class="elementLinkWithType" href="./../../core.tech.common.extend_supp/guidances/guidelines/abstract_away_complexity_DBF13AE6.html" guid="_we3F4ACpEdu8m4dIntu6jA">Guideline: Abstract Away Complexity</a>.
-</p>
-<p>
- Continue the collaboration with the whole&nbsp;team on the refining of the architecture in order to promote consensus
- and a common understanding of the overall solution. The architect should be working to coordinate and guide the
- technical activities of the team rather than doing all the work alone.&nbsp;Place special emphasis&nbsp;on
- involving&nbsp;the developer(s) throughout this task since it's the developed solution that will prove out the
- architecture and may result in refinements to the architecture documentation.
-</p>
-<p>
- Ensure that those who need to act upon the architectural work&nbsp;understand&nbsp;it and are able to work with
- it.&nbsp;Make sure that the description of the architecture clearly conveys not only the solution but also the
- motivation and objectives related to the&nbsp;decisions that have been made in shaping the architecture. This will make
- it easier for others to understand the architecture and to adapt it over time.
-</p>
-<p>
- You can communicate your decisions as many ways as you wish.&nbsp; For example:
-</p>
-<ul>
- <li>
- Publication of&nbsp;reference source code
- </li>
- <li>
- Publication of&nbsp;reference models
- </li>
- <li>
- Publication of&nbsp;software architecture documentation
- </li>
- <li>
- Formal&nbsp;presentations of the material
- </li>
- <li>
- Informal walkthroughs of the architecture
- </li>
+ <keyConsiderations><p>
+ It is important to continue to reduce the complexity of the&nbsp;solution by raising the levels of abstraction.&nbsp;
+ For more information, see <a class="elementLinkWithType"
+ href="./../../core.tech.common.extend_supp/guidances/guidelines/abstract_away_complexity_DBF13AE6.html"
+ guid="_we3F4ACpEdu8m4dIntu6jA">Guideline: Abstract Away Complexity</a>.
+</p>
+<p>
+ Continue the collaboration with the whole&nbsp;team on the refining of the architecture in order to promote consensus
+ and a common understanding of the overall solution. The architect should be working to coordinate and guide the
+ technical activities of the team rather than doing all the work alone.&nbsp;Place special emphasis&nbsp;on
+ involving&nbsp;the developer(s) throughout this task since it's the developed solution that will prove out the
+ architecture and may result in refinements to the architecture documentation.
+</p>
+<p>
+ Ensure that those who need to act upon the architectural work&nbsp;understand&nbsp;it and are able to work with
+ it.&nbsp;Make sure that the description of the architecture clearly conveys not only the solution but also the
+ motivation and objectives related to the&nbsp;decisions that have been made in shaping the architecture. This will make
+ it easier for others to understand the architecture and to adapt it over time.
+</p>
+<p>
+ You can communicate your decisions as many ways as you wish.&nbsp; For example:
+</p>
+<ul>
+ <li>
+ Publication of&nbsp;reference source code
+ </li>
+ <li>
+ Publication of&nbsp;reference models
+ </li>
+ <li>
+ Publication of&nbsp;software architecture documentation
+ </li>
+ <li>
+ Formal&nbsp;presentations of the material
+ </li>
+ <li>
+ Informal walkthroughs of the architecture
+ </li>
</ul></keyConsiderations>
<sections xmi:id="_l92AYNpaEdyP58ppo1Ieaw" name="Refine the architectural goals and architecturally-significant requirements" guid="_l92AYNpaEdyP58ppo1Ieaw">
<sectionDescription><p>
- Work with the team, especially the stakeholders and the requirements team, to review the status of the <a class="elementLink" href="./../../core.tech.common.extend_supp/guidances/concepts/arch_goals_CB41D8AE.html" guid="_HlRqANpbEdyP58ppo1Ieaw">Architectural Goals</a>&nbsp;and <a class="elementLink" href="./../../core.tech.common.extend_supp/guidances/concepts/arch_significant_requirements_1EE5D757.html" guid="_HrZGIA4MEduibvKwrGxWxA">Architecturally Significant Requirements</a>&nbsp;and refine them as needed. It may be
+ Work with the team, especially the stakeholders and the requirements team, to review the status of the <a
+ class="elementLink" href="./../../core.tech.common.extend_supp/guidances/concepts/arch_goals_CB41D8AE.html"
+ guid="_HlRqANpbEdyP58ppo1Ieaw">Architectural Goals</a>&nbsp;and <a class="elementLink"
+ href="./../../core.tech.common.extend_supp/guidances/concepts/arch_significant_requirements_1EE5D757.html"
+ guid="_HrZGIA4MEduibvKwrGxWxA">Architecturally Significant Requirements</a>&nbsp;and refine them as needed. It may be
that some new architecturally-significant requirements have been introduced or your architectural goals and priorities
may have changed.
</p>
@@ -164,7 +173,9 @@
that could be built to be reused.
</p>
<p dir="ltr" style="MARGIN-RIGHT: 0px">
- For more information, see <a class="elementLinkWithType" href="./../../core.tech.common.extend_supp/guidances/guidelines/software_reuse_B6B04C26.html" guid="_vO2uoO0OEduUpsu85bVhiQ">Guideline: Software Reuse</a>.
+ For more information, see <a class="elementLinkWithType"
+ href="./../../core.tech.common.extend_supp/guidances/guidelines/software_reuse_B6B04C26.html"
+ guid="_vO2uoO0OEduUpsu85bVhiQ">Guideline: Software Reuse</a>.
</p></sectionDescription>
</sections>
<sections xmi:id="_GFLpsFHPEd2zrOgIte8oWg" name="Validate the architecture" guid="_GFLpsFHPEd2zrOgIte8oWg">
diff --git a/epf_prac_151/practice.tech.evolutionary_arch.base/workproducts/architecture_notebook.vm.xmi b/epf_prac_151/practice.tech.evolutionary_arch.base/workproducts/architecture_notebook.vm.xmi
index 9ff33e2..cc71f1a 100644
--- a/epf_prac_151/practice.tech.evolutionary_arch.base/workproducts/architecture_notebook.vm.xmi
+++ b/epf_prac_151/practice.tech.evolutionary_arch.base/workproducts/architecture_notebook.vm.xmi
@@ -1,5 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ArtifactDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-5_3zlnRYAOz-wT6GBaWoNg" name="new_artifact,_G0xGANfdEdy8T_PKWvNDBA" guid="-5_3zlnRYAOz-wT6GBaWoNg" changeDate="2008-02-15T08:35:13.000-0800" version="7.2.0">
- <representationOptions>A set of architectural models can be developed as part of the architectural documentation. For 
-more information, see <a class="elementLinkWithType" href="./../../practice.tech.evolutionary_arch.base/guidances/guidelines/modeling_the_arch_8BE6E55B.html" guid="_HrgUQNcuEdy1nJEYZGzN4A">Guideline: Modeling the Architecture</a>.</representationOptions>
+ <representationOptions>A set of architectural models can be developed as part of the architectural documentation. For more information, see <a
+class="elementLinkWithType"
+href="./../../practice.tech.evolutionary_arch.base/guidances/guidelines/modeling_the_arch_8BE6E55B.html"
+guid="_HrgUQNcuEdy1nJEYZGzN4A">Guideline: Modeling the Architecture</a>.</representationOptions>
</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/epf_prac_151/practice.tech.evolutionary_arch.base/workproducts/architecture_notebook.xmi b/epf_prac_151/practice.tech.evolutionary_arch.base/workproducts/architecture_notebook.xmi
index 95ed290..232618d 100644
--- a/epf_prac_151/practice.tech.evolutionary_arch.base/workproducts/architecture_notebook.xmi
+++ b/epf_prac_151/practice.tech.evolutionary_arch.base/workproducts/architecture_notebook.xmi
@@ -1,62 +1,62 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ArtifactDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_H4gOYKYTEdmvhNXG0Oc2uA" name="architecture_notebook,_0XAf0MlgEdmt3adZL5Dmdw" guid="_H4gOYKYTEdmvhNXG0Oc2uA" changeDate="2008-08-15T00:25:02.000-0700" version="1.0.0">
- <mainDescription><p>
- This artifact&nbsp;describes the <a class="elementLink" href="./../../core.tech.common.extend_supp/guidances/concepts/software_architecture_59A08DE0.html" guid="__O7tAMVvEduLYZUGfgZrkQ">Software Architecture</a>.
-</p>
-<p> It provides a place for maintaining the list of architectural issues, along
- with the associated architectural decisions, designs, patterns, code documented
- (or pointed to), and so forth -- all at appropriate levels to make it easy to
- understand what architectural decisions have been made and remain to be made.
-</p>
-<p> It is helpful for architects to use this artifact to collaborate with other
- team members in developing the architecture and to help team members understand
- the motivation behind architectural decisions so that those decisions can be
- robustly implemented. For example, the architect may put constraints on how
- data is packaged and communicated between different parts of the system. This
- may appear to be a burden, but the justification in the Architecture Notebook
- can explain that there is a significant performance bottleneck when communicating
- with a legacy system. The rest of the system must adapt to this bottleneck by
- following a specific data packaging scheme. </p>
-<p> This artifact should also inform the team members how the system is partitioned
- or organized so that the team can adapt to the needs of the system. It also
- gives a first glimpse of the system and its technical motivations to whoever
- must maintain and change the architecture later.<br />
+ <mainDescription><p>
+ This artifact&nbsp;describes the <a class="elementLink"
+ href="./../../core.tech.common.extend_supp/guidances/concepts/software_architecture_59A08DE0.html"
+ guid="__O7tAMVvEduLYZUGfgZrkQ">Software Architecture</a>.
+</p>
+<p>
+ It provides a place for maintaining the list of architectural issues, along with the associated architectural
+ decisions, designs, patterns, code documented (or pointed to), and so forth -- all at appropriate levels to make it
+ easy to understand what architectural decisions have been made and remain to be made.
+</p>
+<p>
+ It is helpful for architects to use this artifact to collaborate with other team members in developing the architecture
+ and to help team members understand the motivation behind architectural decisions so that those decisions can be
+ robustly implemented. For example, the architect may put constraints on how data is packaged and communicated between
+ different parts of the system. This may appear to be a burden, but the justification in the Architecture Notebook can
+ explain that there is a significant performance bottleneck when communicating with a legacy system. The rest of the
+ system must adapt to this bottleneck by following a specific data packaging scheme.
+</p>
+<p>
+ This artifact should also inform the team members how the system is partitioned or organized so that the team can adapt
+ to the needs of the system. It also gives a first glimpse of the system and its technical motivations to whoever must
+ maintain and change the architecture later.<br />
</p></mainDescription>
- <purpose>To capture and make architectural decisions and to explain those decisions to
-developers.&nbsp;</purpose>
- <impactOfNotHaving>Without this artifact, there will be no coordination of the individual design 
-efforts, and it will be difficult to establish and communicate an overall architectural 
-vision of the project.</impactOfNotHaving>
- <reasonsForNotNeeding><p> This artifact is not required if an existing reference architecture is being 
- used or another approach or set of artifacts are being used to document the 
- architecture. This artifact may not be needed if the design is relatively straight-forward 
- and does not have any architecturally significant risks. </p></reasonsForNotNeeding>
- <briefOutline><p dir="ltr" style="MARGIN-RIGHT: 0px"> At a minimum, this artifact should do 
- these three things:</p>
+ <purpose>To capture and make architectural decisions and to explain those decisions to developers.&nbsp;</purpose>
+ <impactOfNotHaving>Without this artifact, there will be no coordination of the individual design efforts, and it will be difficult to
+establish and communicate an overall architectural vision of the project.</impactOfNotHaving>
+ <reasonsForNotNeeding><p>
+ This artifact is not required if an existing reference architecture is being used or another approach or set of
+ artifacts are being used to document the architecture. This artifact may not be needed if the design is relatively
+ straight-forward and does not have any architecturally significant risks.
+</p></reasonsForNotNeeding>
+ <briefOutline><p dir="ltr" style="MARGIN-RIGHT: 0px">
+ At a minimum, this artifact should do these three things:
+</p>
<ul dir="ltr">
<li>
- 
- <div style="MARGIN-RIGHT: 0px"> List guidelines, decisions, and constraints 
- to be followed </div>
+ <div style="MARGIN-RIGHT: 0px">
+ List guidelines, decisions, and constraints to be followed
+ </div>
</li>
<li>
- 
- <div style="MARGIN-RIGHT: 0px"> Justify those guidelines, decisions, and constraints 
- </div>
+ <div style="MARGIN-RIGHT: 0px">
+ Justify those guidelines, decisions, and constraints
+ </div>
</li>
<li>
- 
- <div style="MARGIN-RIGHT: 0px"> Describe the Architectural Mechanisms and 
- where they should be applied</div>
+ <div style="MARGIN-RIGHT: 0px">
+ Describe the Architectural Mechanisms and where they should be applied
+ </div>
</li>
</ul>
-<p dir="ltr" style="MARGIN-RIGHT: 0px"> Team members who were not involved in 
- those architectural decisions need to understand the reasoning behind the context 
- of the architecture so that they can address the needs of the system. Consider 
- adding more information when appropriate. A small project shouldn't spend a 
- lot of time documenting the architecture, but all critical elements of the system 
- must be communicated to current and future team members. This is all useful 
- content: </p>
+<p dir="ltr" style="MARGIN-RIGHT: 0px">
+ Team members who were not involved in those architectural decisions need to understand the reasoning behind the context
+ of the architecture so that they can address the needs of the system. Consider adding more information when
+ appropriate. A small project shouldn't spend a lot of time documenting the architecture, but all critical elements of
+ the system must be communicated to current and future team members. This is all useful content:
+</p>
<ul dir="ltr">
<li>
<div style="MARGIN-RIGHT: 0px">
@@ -99,9 +99,9 @@
</div>
</li>
<li>
- 
- <div style="MARGIN-RIGHT: 0px"> Key scenarios that describe critical behavior 
- of the system </div>
+ <div style="MARGIN-RIGHT: 0px">
+ Key scenarios that describe critical behavior of the system
+ </div>
</li>
</ul></briefOutline>
</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/epf_prac_151/practice.tech.evolutionary_design.assign/roles/developer_vm.xmi b/epf_prac_151/practice.tech.evolutionary_design.assign/roles/developer_vm.xmi
index 48f826f..87cf071 100644
--- a/epf_prac_151/practice.tech.evolutionary_design.assign/roles/developer_vm.xmi
+++ b/epf_prac_151/practice.tech.evolutionary_design.assign/roles/developer_vm.xmi
@@ -1,6 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:RoleDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-xbAirPdH1IOKcnklk8hdqw" name="new_role,_sypCEPvjEdqf0-top1XJIg" guid="-xbAirPdH1IOKcnklk8hdqw" changeDate="2006-09-11T11:34:39.000-0700" version="7.2.0">
- <skills><p> In addition, to create a visual model of the system, the person in this role 
- needs the ability to&nbsp;render the design in the Unified Modeling Language 
- (UML). </p></skills>
+ <skills><p>
+ In addition, to create a visual model of the system, the person in this role needs the ability to&nbsp;render the
+ design in the Unified Modeling Language (UML).
+</p></skills>
</org.eclipse.epf.uma:RoleDescription>
diff --git a/epf_prac_151/practice.tech.evolutionary_design.base/guidances/concepts/design.xmi b/epf_prac_151/practice.tech.evolutionary_design.base/guidances/concepts/design.xmi
index ee3261e..8edb3d3 100644
--- a/epf_prac_151/practice.tech.evolutionary_design.base/guidances/concepts/design.xmi
+++ b/epf_prac_151/practice.tech.evolutionary_design.base/guidances/concepts/design.xmi
@@ -1,113 +1,113 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-c5Uh71vXTPN-VmrGYVRV7w" name=",_bFjlAPTYEduDKIuqTXQ8SA" guid="-c5Uh71vXTPN-VmrGYVRV7w" changeDate="2008-10-15T06:50:52.000-0700" version="7.2.0">
- <mainDescription><p>
- Designing a system is about creating the internal structure and behavior of a system that's robust, extensible, and
- high-quality. Good design improves quality and makes a system easier to maintain and extend, while a poor design can
- significantly raise the cost of producing and maintaining the software.
-</p>
-<p>
- Design is an abstraction of the code that presents the system from a perspective that makes it easier to address the
- structure and behavior of the software. This can be done through viewing the code, but it's more difficult and less
- effective to address structural and behavioral issues this way. Design can be visual models, simple sketches, text
- descriptions, etc. The critical element of design is that it describes how different elements of the system interact to
- fulfill the requirements.
-</p>
-<p>
- The amount of design that's formally documented and maintained will vary depending on the criticality of the design and
- how much of the design needs to be communicated to future team members. At a minimum, all architecturally significant
- design elements should be documented and kept up-to-date with the implementation. These are critical aspects of the
- system that are necessary for the understanding and maintenance of the software. Other important or complex structure
- and behavior may be maintained as well. And some contracts may require that the entire design is thoroughly documented.
-</p>
-<p>
- On many projects there will probably be aspects of the design that are only documented for the purpose of creating a
- solution or walking through how certain behavior will be realized. It may not be worth the overhead of maintaining this
- information as the design is transformed through refactoring and other influences. However, it may be useful to archive
- the initial decisions, whiteboard images, or files so they can be referenced in the future if necessary. These can be
- viewed as "old meeting minutes" that are stored for potential future reference. They may not reflect the current
- design, but they may still provide useful insight.
-</p>
-<h3>
- Multiple Passes
-</h3>
-<p>
- The design will be revisited many times throughout an iterative lifecycle and even within an iteration. Each time some
- design activity is being performed, it will be performed in the context of a specific goal. The goal might be to
- identify a notional set of participants in a collaboration that can be exercised to realize the behavior required (an
- analysis pass). The goal might be in the identification of some coarse-grained elements that are required to act out
- some scenario (an architectural pass). Then a pass might be done within one of those components to identify the
- elements within that will collaborate together to perform the behavior required (a more detailed design pass).<br />
- <br />
- Design might be performed in a particular context such as database context, user-interface context, or perhaps the
- context of how some existing library will be applied. In these cases the design steps will be performed just to make
- and communicate decisions regarding that context
-</p>
-<p>
- Avoid analysis paralysis. Avoid refining, extending, and improving the design beyond a minimal version that suffices to
- cover the needs of the requirements within the architecture. Design should be done in small chunks, proven via
- implementation, improved via refactoring, and integrated into the baseline to provide value to the stakeholders.
-</p>
-<h3>
- Design versus Architecture
-</h3>
-<p>
- Design is a real thing, the construction of the system's structure and behavior. Architecture defines principles,
- contexts, and constraints on the system's construction. Architecture is described in architecture artifacts, but it's
- realized as design (visual or otherwise) and implementation.<br />
- <br />
- One way to look at architecture is that it helps to make the entire design more cohesive with itself by balancing the
- needs of the entire system. Design tends to focus on one area at a time. Architecture helps assure the design is
- consistent and appropriate to the goals of the system. For instance, there may be constraints placed on most of the
- design to support the performance of one part of the system, such as improving access to a legacy system. Failure to
- conform to those constraints in the design may cause the system to fail to meet the performance requirements of the
- legacy system access. Conforming to the architecture assures that all the goals of the system are met by balancing
- competing technical issues.
-</p>
-<h3>
- Quality of Design
-</h3>
-<h4>
- You Aren't Going to Need It
-</h4>
-<p>
- The YAGNI principle is a good general approach to design. While designs should be robust enough to modify, re-use, and
- maintain, it should also be as simple as possible. One of the ways to keep it simple is to make few assumptions about
- what the design's going to need in the future. Don't assume you'll need something until you know you need it, then do a
- good job of adding it. Add what's needed for the current requirement or iteration. Refactor the design as necessary
- when more functionality needs to be added or the design must be made more complex to deal with new circumstances.
-</p>
-<h4>
- Coupling and Cohesion
-</h4>
-<p>
- Two of the most fundamental principles of design are coupling and cohesion. A good design contains elements that have
- high cohesion and low coupling. High cohesion means that a single element, such as a class or subsystem, is composed of
- parts that are closely related or work closely together to fulfill some purpose. Low coupling means that the elements
- of a system have a minimum of dependencies on each other. A single element such as a subsystem should be easily
- replaceable by another subsystem that provides similar behavior.<br />
- <br />
- For example, in a payroll system an Employee class would have high cohesion if it contained elements and functions such
- as Name, Tax ID Number, and Monthly Salary. At first, it may seem as if the Calculate Paycheck functional would also be
- cohesive. But when you consider that hourly employees must be paid overtime, sales people must have commission
- calculated for them, etc, the function is less related to Employee and should probably be its own class or
- subsystem.<br />
- <br />
- An example of low coupling would be if the Calculate Paycheck subsystem can be easily replaced by third party that may
- be more robust and offer more features.<br />
- <br />
- Coupling and cohesion are so important to be aware of because they arise in so many design principles and design
- strategies such as patterns.
-</p>
-<h4>
- Open-Closed Principle
-</h4>
-<p>
- Elements in the design should be "open" for extension but "closed" for modification. The goal of this principle is to
- create software than can be extended without changing code&nbsp;<a class="elementLinkWithUserText"
- href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#MEY97"
- guid="_9ToeIB83Edqsvps02rpOOg">[MEY97]</a>. This is because every change to software runs the risk of introducing bugs
- into code that's already correct. It also allows functionality to be re-used without having to know the details of the
- implementation, reducing the time it takes to create something new. Keeping this principle in mind helps make a design
- more maintainable.<br />
+ <mainDescription><p>
+ Designing a system is about creating the internal structure and behavior of a system that's robust, extensible, and
+ high-quality. Good design improves quality and makes a system easier to maintain and extend, while a poor design can
+ significantly raise the cost of producing and maintaining the software.
+</p>
+<p>
+ Design is an abstraction of the code that presents the system from a perspective that makes it easier to address the
+ structure and behavior of the software. This can be done through viewing the code, but it's more difficult and less
+ effective to address structural and behavioral issues this way. Design can be visual models, simple sketches, text
+ descriptions, etc. The critical element of design is that it describes how different elements of the system interact to
+ fulfill the requirements.
+</p>
+<p>
+ The amount of design that's formally documented and maintained will vary depending on the criticality of the design and
+ how much of the design needs to be communicated to future team members. At a minimum, all architecturally significant
+ design elements should be documented and kept up-to-date with the implementation. These are critical aspects of the
+ system that are necessary for the understanding and maintenance of the software. Other important or complex structure
+ and behavior may be maintained as well. And some contracts may require that the entire design is thoroughly documented.
+</p>
+<p>
+ On many projects there will probably be aspects of the design that are only documented for the purpose of creating a
+ solution or walking through how certain behavior will be realized. It may not be worth the overhead of maintaining this
+ information as the design is transformed through refactoring and other influences. However, it may be useful to archive
+ the initial decisions, whiteboard images, or files so they can be referenced in the future if necessary. These can be
+ viewed as "old meeting minutes" that are stored for potential future reference. They may not reflect the current
+ design, but they may still provide useful insight.
+</p>
+<h3>
+ Multiple Passes
+</h3>
+<p>
+ The design will be revisited many times throughout an iterative lifecycle and even within an iteration. Each time some
+ design activity is being performed, it will be performed in the context of a specific goal. The goal might be to
+ identify a notional set of participants in a collaboration that can be exercised to realize the behavior required (an
+ analysis pass). The goal might be in the identification of some coarse-grained elements that are required to act out
+ some scenario (an architectural pass). Then a pass might be done within one of those components to identify the
+ elements within that will collaborate together to perform the behavior required (a more detailed design pass).<br />
+ <br />
+ Design might be performed in a particular context such as database context, user-interface context, or perhaps the
+ context of how some existing library will be applied. In these cases the design steps will be performed just to make
+ and communicate decisions regarding that context
+</p>
+<p>
+ Avoid analysis paralysis. Avoid refining, extending, and improving the design beyond a minimal version that suffices to
+ cover the needs of the requirements within the architecture. Design should be done in small chunks, proven via
+ implementation, improved via refactoring, and integrated into the baseline to provide value to the stakeholders.
+</p>
+<h3>
+ Design versus Architecture
+</h3>
+<p>
+ Design is a real thing, the construction of the system's structure and behavior. Architecture defines principles,
+ contexts, and constraints on the system's construction. Architecture is described in architecture artifacts, but it's
+ realized as design (visual or otherwise) and implementation.<br />
+ <br />
+ One way to look at architecture is that it helps to make the entire design more cohesive with itself by balancing the
+ needs of the entire system. Design tends to focus on one area at a time. Architecture helps assure the design is
+ consistent and appropriate to the goals of the system. For instance, there may be constraints placed on most of the
+ design to support the performance of one part of the system, such as improving access to a legacy system. Failure to
+ conform to those constraints in the design may cause the system to fail to meet the performance requirements of the
+ legacy system access. Conforming to the architecture assures that all the goals of the system are met by balancing
+ competing technical issues.
+</p>
+<h3>
+ Quality of Design
+</h3>
+<h4>
+ You Aren't Going to Need It
+</h4>
+<p>
+ The YAGNI principle is a good general approach to design. While designs should be robust enough to modify, re-use, and
+ maintain, it should also be as simple as possible. One of the ways to keep it simple is to make few assumptions about
+ what the design's going to need in the future. Don't assume you'll need something until you know you need it, then do a
+ good job of adding it. Add what's needed for the current requirement or iteration. Refactor the design as necessary
+ when more functionality needs to be added or the design must be made more complex to deal with new circumstances.
+</p>
+<h4>
+ Coupling and Cohesion
+</h4>
+<p>
+ Two of the most fundamental principles of design are coupling and cohesion. A good design contains elements that have
+ high cohesion and low coupling. High cohesion means that a single element, such as a class or subsystem, is composed of
+ parts that are closely related or work closely together to fulfill some purpose. Low coupling means that the elements
+ of a system have a minimum of dependencies on each other. A single element such as a subsystem should be easily
+ replaceable by another subsystem that provides similar behavior.<br />
+ <br />
+ For example, in a payroll system an Employee class would have high cohesion if it contained elements and functions such
+ as Name, Tax ID Number, and Monthly Salary. At first, it may seem as if the Calculate Paycheck functional would also be
+ cohesive. But when you consider that hourly employees must be paid overtime, sales people must have commission
+ calculated for them, etc, the function is less related to Employee and should probably be its own class or
+ subsystem.<br />
+ <br />
+ An example of low coupling would be if the Calculate Paycheck subsystem can be easily replaced by third party that may
+ be more robust and offer more features.<br />
+ <br />
+ Coupling and cohesion are so important to be aware of because they arise in so many design principles and design
+ strategies such as patterns.
+</p>
+<h4>
+ Open-Closed Principle
+</h4>
+<p>
+ Elements in the design should be "open" for extension but "closed" for modification. The goal of this principle is to
+ create software than can be extended without changing code&nbsp;<a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#MEY97"
+ guid="_9ToeIB83Edqsvps02rpOOg">[MEY97]</a>. This is because every change to software runs the risk of introducing bugs
+ into code that's already correct. It also allows functionality to be re-used without having to know the details of the
+ implementation, reducing the time it takes to create something new. Keeping this principle in mind helps make a design
+ more maintainable.<br />
</p>&nbsp;</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.evolutionary_design.base/guidances/concepts/requirements_realization.xmi b/epf_prac_151/practice.tech.evolutionary_design.base/guidances/concepts/requirements_realization.xmi
index 0952d20..28e9f4d 100644
--- a/epf_prac_151/practice.tech.evolutionary_design.base/guidances/concepts/requirements_realization.xmi
+++ b/epf_prac_151/practice.tech.evolutionary_design.base/guidances/concepts/requirements_realization.xmi
@@ -1,20 +1,20 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-xsQ27TDaTcUQ1VKUQG_HIQ" name=",_T9FbYFRFEd2o7OqLaYh8nA" guid="-xsQ27TDaTcUQ1VKUQG_HIQ" changeDate="2008-08-19T07:20:27.000-0700" version="7.5.0">
- <mainDescription><p>
- Requirements&nbsp;realizations represent how one or more requirements are fulfilled in the design. This can take
- various forms. It may include, for example, a textual description (a document), class diagrams of participating classes
- and subsystems, and interaction diagrams (communication and sequence diagrams) that illustrate the flow of interactions
- between class and subsystem instances.
-</p>
-<p>
- In a model, requirements realization is typically represented as a UML collaboration that groups the diagrams and other
- information (such as textual descriptions) that form part of the realization.&nbsp;&nbsp; If using use cases, the
- collaboration may be further stereotyped as a use-case realization.
-</p>
-<p>
- Note that there can be more than one realization of the same set of requirements.&nbsp; This is particularly important
- for larger projects, or families of systems where the same requirements may be designed differently in different
- products within the product family. Consider the case of a family of telephone switches which have many requirements in
- common, but which design and implement them differently according to product positioning, performance and price.
+ <mainDescription><p>
+ Requirements&nbsp;realizations represent how one or more requirements are fulfilled in the design. This can take
+ various forms. It may include, for example, a textual description (a document), class diagrams of participating classes
+ and subsystems, and interaction diagrams (communication and sequence diagrams) that illustrate the flow of interactions
+ between class and subsystem instances.
+</p>
+<p>
+ In a model, requirements realization is typically represented as a UML collaboration that groups the diagrams and other
+ information (such as textual descriptions) that form part of the realization.&nbsp;&nbsp; If using use cases, the
+ collaboration may be further stereotyped as a use-case realization.
+</p>
+<p>
+ Note that there can be more than one realization of the same set of requirements.&nbsp; This is particularly important
+ for larger projects, or families of systems where the same requirements may be designed differently in different
+ products within the product family. Consider the case of a family of telephone switches which have many requirements in
+ common, but which design and implement them differently according to product positioning, performance and price.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.evolutionary_design.base/guidances/guidelines/analyze_the_design.xmi b/epf_prac_151/practice.tech.evolutionary_design.base/guidances/guidelines/analyze_the_design.xmi
index dda7aa4..af689e4 100644
--- a/epf_prac_151/practice.tech.evolutionary_design.base/guidances/guidelines/analyze_the_design.xmi
+++ b/epf_prac_151/practice.tech.evolutionary_design.base/guidances/guidelines/analyze_the_design.xmi
@@ -1,119 +1,127 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-1vS_ELnQxGQKwfCrRYrc7w" name="new_guideline,__MnggPTdEduDKIuqTXQ8SA" guid="-1vS_ELnQxGQKwfCrRYrc7w" changeDate="2008-02-15T04:35:47.000-0800" version="7.2.0">
- <mainDescription><h1>
- Identification of elements
-</h1>
-<p>
- Identify the elements, based on the needs of the requirements. The identification of elements can stem from a static
- perspective of walking through the requirements and identifying elements clearly called out, which is a form of domain
- modeling. This can pull in other elements identified as being in the application domain or deemed necessary from
- examining the requirements for the portion of the system being designed. This identification can also pull from key
- abstractions identified while defining the architecture.
-</p>
-<p>
- The identification of elements should also apply a dynamic perspective by walking through scenarios of use of the
- system (or subsystem) and identifying elements needed to support the behavior. That behavior might be a scenario of use
- from an external user perspective or, while designing a subsystem, a responsibility assigned to the subsystem that has
- complex algorithmic behavior. Consider applying the <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/guidelines/entity_control_boundary_pattern_C4047897.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a> to identify the elements necessary to support the
- scenario, or apply other patterns identified in the architecture that specify the elements that will be used to support
- specific aspects of the scenario.
-</p>
-<p>
- If you are designing a real-time system, include elements to represent events and signals that allow you to describe
- the asynchronous triggers of behavior to which the system must respond. <b>Events</b> are specifications of interesting
- occurrences in time and space that usually (if they are noteworthy) require some response from the system.
- <b>Signals</b> represent asynchronous mechanisms used to communicate certain types of events within the system.
-</p>
-<p>
- If there are existing elements from previous passes over the design or from selected frameworks or other reusable
- elements, reuse them whenever possible. See <a class="elementLinkWithType" href="./../../../core.tech.common.extend_supp/guidances/guidelines/software_reuse_B6B04C26.html" guid="_vO2uoO0OEduUpsu85bVhiQ">Guideline: Software Reuse</a>.
-</p>
-<p>
- After identifying the elements, give each one meaningful name. Each element should also have a description, so that the
- team members who work together to refine the design and implement from the design will understand the role that each
- element plays.
-</p>
-<p>
- Based on this information, the identification of elements could be applied several times in designing just one part of
- the system. Although there is no one correct strategy for multiple passes, they could be done at a coarse-grained level
- and then a fine-grained level, or at an analysis (abstract) level and then a design level.
-</p>
-<h1>
- Behavior of elements
-</h1>
-<p>
- To identify the behavior of the elements, go through scenarios and assign behavior to the appropriate collaborating
- participants. If a particular use of the system or subsystem can have multiple possible outcomes or variant sequences,
- cover enough scenarios to ensure that the design is robust enough to support the possibilities.
-</p>
-<p>
- When assigning behavior to elements, consider applying the <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/guidelines/entity_control_boundary_pattern_C4047897.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a>&nbsp;or other patterns identified in the
- architecture.
-</p>
-<p>
- Behavior can be represented as a simple statement of responsibility, or it can be a detailed operation specification.
- Use the appropriate level of detail to communicate important design decisions while giving the freedom to make
- appropriate implementation decisions as those tasks ensue.
-</p>
-<p>
- Avoid too much identification of behavior solely from the perspective of domain modeling. Include only behavior that is
- really needed -- behavior identified by going through required scenarios of system use.
-</p>
-<p>
- Behavior must be understood as a responsibility of an element, as well as an interaction between two elements in the
- context of some broader behavior of the system or subsystem. The latter part of this will lead the developer to
- identify relationships that are necessary between the elements.
-</p>
-<h1>
- Design element relationships
-</h1>
-<p>
- The relationships between the elements necessary for the behavior must be designed. This can simply be the
- identification of the ability to traverse from one element to another or else a need to manage an association between
- the elements. Relationships can be designed in more detail, as appropriate. This can include: optionality,
- multiplicity, whether the relationship is a simple dependency or managed association, and so on. These decisions that
- drive implementation details are best made at the design level, where it is easier to see how all of the pieces fit
- together.
-</p>
-<p>
- Avoid defining too many relationships based on relationships in the application domain. Include only relationships that
- are needed based on the requirements. On the other hand, a combination of requirements knowledge and domain knowledge
- can lead to some detailed decisions on the relationships, such as optionality and multiplicity.
-</p>
-<h1>
- Analysis classes and YAGNI
-</h1>
-<p>
- Analysis classes are used to identify initial buckets where system functionality should go. They're the first pass at
- understanding where system behavior will be realized in the design and implementation. For example, an entity class
- might initially represent all of the behavior for an employee, such as storing personal information and calculating the
- value of a paycheck. Few assumptions are made about how the final design will look at this point. Analysis classes are
- about making sure required behavior is represented somewhere in the system, rather than about creating a perfect
- design.
-</p>
-<p>
- Analysis classes allow you to begin designing from abstractions, so that the details of the system depend on those
- abstractions and not the other way around. In the Employee class, the notion of an employee should start with the idea
- of someone who works for the company, who has responsibilities and receives benefits. It's easier to create a design
- from this simple idea. The complexity of the design should emerge from the abstract ideas of what the design needs to
- do. This will also help keep coupling low and cohesion high.
-</p>
-<p>
- YAGNI (You Aren't Going to Need It) is an approach to design where the developer creates only enough implementation and
- design to address the required functionality. No assumptions are made about re-use or possible future uses of the
- software. Software is improved when the system requirements demand more functionality or robustness.
-</p>
-<p>
- The first classes created from a YAGNI perspective are much like analysis classes. You don't know how complex it may be
- to calculate a paycheck for your employee, so you assume that functionality is highly cohesive with the rest of what
- the Employee class must do. As you understanding of the requirement develops, the analysis class evolves into a set of
- collaborating classes and patterns that better support the behavior of the system. For example, payroll calculations
- could be moved into a pattern that handles all of the different types of paycheck calculations (overtime, commissions,
- and so forth), thereby increasing the internal cohesion of the class.
-</p>
-<p>
- Use analysis classes to define an initial place to put system behavior, and add only enough behavior to satisfy the
- YAGNI perspective. Analysis classes will evolve into concrete design classes as more behavior is added and as the
- design is refactored. See <a class="elementLinkWithType" href="./../../../practice.tech.evolutionary_design.base/guidances/guidelines/evolve_the_design_3C9D6965.html" guid="_C4U9QPTeEduDKIuqTXQ8SA">Guideline: Evolve the Design</a>.
+ <mainDescription><h3>
+ Identification of elements
+</h3>
+<p>
+ Identify the elements, based on the needs of the requirements. The identification of elements can stem from a static
+ perspective of walking through the requirements and identifying elements clearly called out, which is a form of domain
+ modeling. This can pull in other elements identified as being in the application domain or deemed necessary from
+ examining the requirements for the portion of the system being designed. This identification can also pull from key
+ abstractions identified while defining the architecture.
+</p>
+<p>
+ The identification of elements should also apply a dynamic perspective by walking through scenarios of use of the
+ system (or subsystem) and identifying elements needed to support the behavior. That behavior might be a scenario of use
+ from an external user perspective or, while designing a subsystem, a responsibility assigned to the subsystem that has
+ complex algorithmic behavior. Consider applying the <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/guidances/guidelines/entity_control_boundary_pattern_C4047897.html"
+ guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a> to identify the elements necessary to support the
+ scenario, or apply other patterns identified in the architecture that specify the elements that will be used to support
+ specific aspects of the scenario.
+</p>
+<p>
+ If you are designing a real-time system, include elements to represent events and signals that allow you to describe
+ the asynchronous triggers of behavior to which the system must respond. <b>Events</b> are specifications of interesting
+ occurrences in time and space that usually (if they are noteworthy) require some response from the system.
+ <b>Signals</b> represent asynchronous mechanisms used to communicate certain types of events within the system.
+</p>
+<p>
+ If there are existing elements from previous passes over the design or from selected frameworks or other reusable
+ elements, reuse them whenever possible. See <a class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/guidelines/software_reuse_B6B04C26.html"
+ guid="_vO2uoO0OEduUpsu85bVhiQ">Guideline: Software Reuse</a>.
+</p>
+<p>
+ After identifying the elements, give each one meaningful name. Each element should also have a description, so that the
+ team members who work together to refine the design and implement from the design will understand the role that each
+ element plays.
+</p>
+<p>
+ Based on this information, the identification of elements could be applied several times in designing just one part of
+ the system. Although there is no one correct strategy for multiple passes, they could be done at a coarse-grained level
+ and then a fine-grained level, or at an analysis (abstract) level and then a design level.
+</p>
+<h3>
+ Behavior of elements
+</h3>
+<p>
+ To identify the behavior of the elements, go through scenarios and assign behavior to the appropriate collaborating
+ participants. If a particular use of the system or subsystem can have multiple possible outcomes or variant sequences,
+ cover enough scenarios to ensure that the design is robust enough to support the possibilities.
+</p>
+<p>
+ When assigning behavior to elements, consider applying the <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/guidances/guidelines/entity_control_boundary_pattern_C4047897.html"
+ guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a>&nbsp;or other patterns identified in the
+ architecture.
+</p>
+<p>
+ Behavior can be represented as a simple statement of responsibility, or it can be a detailed operation specification.
+ Use the appropriate level of detail to communicate important design decisions while giving the freedom to make
+ appropriate implementation decisions as those tasks ensue.
+</p>
+<p>
+ Avoid too much identification of behavior solely from the perspective of domain modeling. Include only behavior that is
+ really needed -- behavior identified by going through required scenarios of system use.
+</p>
+<p>
+ Behavior must be understood as a responsibility of an element, as well as an interaction between two elements in the
+ context of some broader behavior of the system or subsystem. The latter part of this will lead the developer to
+ identify relationships that are necessary between the elements.
+</p>
+<h3>
+ Design element relationships
+</h3>
+<p>
+ The relationships between the elements necessary for the behavior must be designed. This can simply be the
+ identification of the ability to traverse from one element to another or else a need to manage an association between
+ the elements. Relationships can be designed in more detail, as appropriate. This can include: optionality,
+ multiplicity, whether the relationship is a simple dependency or managed association, and so on. These decisions that
+ drive implementation details are best made at the design level, where it is easier to see how all of the pieces fit
+ together.
+</p>
+<p>
+ Avoid defining too many relationships based on relationships in the application domain. Include only relationships that
+ are needed based on the requirements. On the other hand, a combination of requirements knowledge and domain knowledge
+ can lead to some detailed decisions on the relationships, such as optionality and multiplicity.
+</p>
+<h3>
+ Analysis classes and YAGNI
+</h3>
+<p>
+ Analysis classes are used to identify initial buckets where system functionality should go. They're the first pass at
+ understanding where system behavior will be realized in the design and implementation. For example, an entity class
+ might initially represent all of the behavior for an employee, such as storing personal information and calculating the
+ value of a paycheck. Few assumptions are made about how the final design will look at this point. Analysis classes are
+ about making sure required behavior is represented somewhere in the system, rather than about creating a perfect
+ design.
+</p>
+<p>
+ Analysis classes allow you to begin designing from abstractions, so that the details of the system depend on those
+ abstractions and not the other way around. In the Employee class, the notion of an employee should start with the idea
+ of someone who works for the company, who has responsibilities and receives benefits. It's easier to create a design
+ from this simple idea. The complexity of the design should emerge from the abstract ideas of what the design needs to
+ do. This will also help keep coupling low and cohesion high.
+</p>
+<p>
+ YAGNI (You Aren't Going to Need It) is an approach to design where the developer creates only enough implementation and
+ design to address the required functionality. No assumptions are made about re-use or possible future uses of the
+ software. Software is improved when the system requirements demand more functionality or robustness.
+</p>
+<p>
+ The first classes created from a YAGNI perspective are much like analysis classes. You don't know how complex it may be
+ to calculate a paycheck for your employee, so you assume that functionality is highly cohesive with the rest of what
+ the Employee class must do. As you understanding of the requirement develops, the analysis class evolves into a set of
+ collaborating classes and patterns that better support the behavior of the system. For example, payroll calculations
+ could be moved into a pattern that handles all of the different types of paycheck calculations (overtime, commissions,
+ and so forth), thereby increasing the internal cohesion of the class.
+</p>
+<p>
+ Use analysis classes to define an initial place to put system behavior, and add only enough behavior to satisfy the
+ YAGNI perspective. Analysis classes will evolve into concrete design classes as more behavior is added and as the
+ design is refactored. See <a class="elementLinkWithType"
+ href="./../../../practice.tech.evolutionary_design.base/guidances/guidelines/evolve_the_design_3C9D6965.html"
+ guid="_C4U9QPTeEduDKIuqTXQ8SA">Guideline: Evolve the Design</a>.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.evolutionary_design.base/guidances/guidelines/designing_visually.xmi b/epf_prac_151/practice.tech.evolutionary_design.base/guidances/guidelines/designing_visually.xmi
index b0746b8..396b5ab 100644
--- a/epf_prac_151/practice.tech.evolutionary_design.base/guidances/guidelines/designing_visually.xmi
+++ b/epf_prac_151/practice.tech.evolutionary_design.base/guidances/guidelines/designing_visually.xmi
@@ -1,189 +1,193 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-1xE2ZW3MjNAJ7jkaZNbkww" name="visual_modeling,_1fM3AC9_EduW5uTjiIcspQ" guid="-1xE2ZW3MjNAJ7jkaZNbkww" changeDate="2006-11-21T11:21:26.000-0800" version="1.0.0">
- <mainDescription><h3>
- Introduction
-</h3>
-<p>
- Using visual modeling techniques to design software can help break down complex problems into a series of smaller,
- easier to manage tasks. Sharing pictures rather than written documents or source code also helps the understanding and
- communication of difficult concepts. Adopting standard modeling notations such as the UML increases this capability by
- helping to make diagrams precise and unambiguous.
-</p>
-<p>
- The degree of formality used when producing and disseminating models should vary according to your needs. Small,
- collaborative teams modeling around whiteboards and capturing the results on a sheet of paper or with digital cameras
- can yield good results. This can also help the team focus on producing software with the help of models; rather than
- becoming sidetracked into over-engineering both the models and the solution. Modeling tools provide additional value to
- projects, especially for more complex systems. Their specifics of use are outside the scope of this guideline, however.
-</p>
-<p>
- This guideline does not describe a formal sequential progression through prescriptive design steps. Whether some or all
- of these techniques are needed, or how long is spent on them will vary depending on real-world issues such as the
- complexity of the requirements; the experience of the designer; and the way the team works.
-</p>
-<p>
- This guideline uses a simplified scenario (Login) to help keep the focus on understanding the techniques rather than
- the specific requirements. In the real-world, it is doubtful that much time would be spent modeling a simple problem.
- Here is the use case diagram, for reference;
-</p>
-<p>
- <img height="142" alt="User Login Use Case Model" src="resources/user_login_ucm.jpg" width="472" />
-</p>
-<h3>
- Identify elements
-</h3>
-<p>
- Render the identified design elements as classes in a UML diagram.&nbsp; Apply appropriate stereotypes and optionally
- render the class using an icon specific to the stereotype to characterize the intent of the class in the design.&nbsp;
- Name and briefly describe the classes in a few sentences. Do not spend too much time working on associations, as these
- will be developed through working on collaborations in the next step.
-</p>
-<p>
- Classes can be drawn as a basic UML rectangle or with a specific symbol associated with a particular stereotype.
-</p>
-<p>
- The resulting class diagram should be conceptually similar to this one:
-</p>
-<p>
- <img height="228" alt="Identify Elements - Initial Class Model" src="resources/identify_elements_bce.jpg" width="290" />
-</p>
-<p>
- For this example, the <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/guidelines/entity_control_boundary_pattern_C4047897.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a> has been used to derive two classes (LoginUI and
- LoginController). In addition, two design elements already identified in the architecture (SecuritySystemInterface and
- User) have also been incorporated.
-</p>
-<h3>
- Determine how elements collaborate to realize the scenario
-</h3>
-<p>
- When determining collaboration, two kinds of diagrams are useful.
-</p>
-<ul>
- <li>
- A dynamic object diagram, showing how the design elements collaborate to realize the requirements.
- </li>
- <li>
- A static class diagram, showing the classes involved in realizing the requirements.
- </li>
-</ul>
-<p>
- Remember to also update any other impacted diagrams as appropriate, based on modifications or additions to the design.
-</p>
-<p>
- Create a number of dynamic object diagrams that walk through how a set of objects collaborate to perform the behavior
- of the scenarios.&nbsp; Even if just one scenario is being designed, this might take multiple diagrams to render it in
- smaller, understandable chunks or from multiple contexts.
-</p>
-<p>
- <img style="WIDTH: 776px; HEIGHT: 355px" height="355" alt="User Login Sequence Diagram" src="resources/user_login_seq.jpg" width="776" />
-</p>
-<p>
- The above sequence diagram shows the user credentials being passed through to the security system for authentication.
- Steps in the use case scenario are transformed into messages between the participating objects. The messages in this
- example are not yet fully formed (there are no parameters or return values), so they are prefixed with "//" to show
- that more work is needed.&nbsp; A sequence diagram was used in this example, but a communication diagram could have
- been used.
-</p>
-<p>
- It&nbsp;can be&nbsp;useful to create one or more static class diagrams that show the classes in the design that support
- the realization.&nbsp; These class diagrams are often called View of Participating Classes diagrams, they provide a
- focused view on the overall design by only showing the classes, relationships, operations, and attributes relevant to
- the collaboration.
-</p>
-<p>
- <img height="469" alt="Login VOPC" src="resources/login_vopc.jpg" width="448" />
-</p>
-<p>
- This diagram shows the operations and relationships that were identified by drawing the sequence diagram. The
- relationships in this example&nbsp;have not been refined yet, so they are just shown as simple associations. Remember
- to examine the diagram to verify that the design can support the behavior in the sequence diagram.
-</p>
-<p>
- Working at this level of detail in the model during the early stages of design can be helpful. It keeps the diagrams
- relatively simple and easy to understand. It makes them easier to draw in a workshop and easier to change during
- discussion. It is often easier to add the detail once there is agreement on the fundamentals.
-</p>
-<h3>
- Refine design decisions
-</h3>
-<p>
- Once the fundamentals of the design are relatively stable, you can begin to add detail to the design. Some of this can
- be performed in code or in the model. If modeling is chosen, then refine attributes, responsibilities and
- relationships.
-</p>
-<h4>
- Describe responsibilities
-</h4>
-<p>
- Class responsibilities are either actions to be performed by an object or knowledge maintained and provided to other
- objects. Each class will typically have several responsibilities; each responsibility will evolve into one or more
- operations during design.
-</p>
-<p>
- Responsibilities are derived from messages on interaction diagrams or from non-functional requirements that a class has
- to support. Document a responsibility by giving it a name, and optionally a brief description (what it does).
-</p>
-<p>
- These operations can be left as self-evident from their context, they can be given textual descriptions of the
- algorithm required to perform the behavior, or they could spawn off another whole pass of this technique where a set of
- classes that collaborate together to perform the internals of the operation are identified, etc.
-</p>
-<h4>
- Describe attributes and associations
-</h4>
-<p>
- A class may have to store simple data information, like: string, integer, and the like. For such simple type of
- information, attributes are defined for classes. For a more complex or "behavioral" attribute, consider creating an
- extra class and establish an association to it.
-</p>
-<p>
- To perform their responsibilities, classes may depend on other classes to supply needed behavior. These other classes
- might be ones already identified in this design session, they might be existing classes pulled from the architecture,
- or the need for new classes might be conceived. Associations in a class diagram can be used to represent inter-class
- relationships.
-</p>
-<p>
- <img height="439" alt="Login VOPC (Refined)" src="resources/login_vopc_refined.jpg" width="557" />
-</p>
-<p>
- This diagram shows a number of refinements. The LoginUI class has been replaced by LoginForm. The User class has been
- renamed UserCredentials and is created by the LoginForm class rather than LoginController. It is then used as a
- parameter for subsequent messages rather than passing the individual attributes. The SecuritySystemInterface class has
- been refined into two elements, ISystemSecurity, which provides a simple façade for interaction with the rests of the
- design; and SecuritySystemProxy, which handles interaction with the external security system.
-</p>
-<h3>
- Design internals
-</h3>
-<p>
- The classes in the design are likely to need to be distributed amongst different packages and subsystems or components.
-</p>
-<p>
- <img height="304" alt="User Login - Design Packages" src="resources/dv_packaging.jpg" width="571" />
-</p>
-<p>
- In this example, the LoginForm, LoginController and UserCredentials elements have been placed in a package called
- LocalSecurity. The SecuritySystemProxy is a part of a subsystem called SecuritySystemAdapter which realizes the
- ISecuritySystem interface. The SecuritySystemAdapter wraps the legacy SecuritySystem, expressed here as a component
- offering a validateUser interface.
-</p>
-<p>
- Each of these packaged elements can be distributed amongst the team for further development work.
-</p>
-<h3>
- Conclusion
-</h3>
-<p>
- This guideline walked through the techniques in a concrete manner started with a scenario of a use case through to
- distributing the classes identified into a set of packages. This example demonstrates a technique for designing
- visually, but it should be considered as just one conceptual pass of design.&nbsp; One could as easily apply this
- technique when defining the internals of how the SecuritySystemProxy class will collaborate with a set of classes to
- validate the credentials.
-</p>
-<p>
- When applying this guideline, work in small chunks and keep in mind the goal of delivering software to the users that
- provides value. To deliver high-quality software requires consideration of how the pieces will work together to deliver
- that value. But as soon as key decisions have been made and the decisions have been communicated to the appropriate
- team members, the team should move on to implementing the source code to verify the design and deliver the value.
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ Using visual modeling techniques to design software can help break down complex problems into a series of smaller,
+ easier to manage tasks. Sharing pictures rather than written documents or source code also helps the understanding and
+ communication of difficult concepts. Adopting standard modeling notations such as the UML increases this capability by
+ helping to make diagrams precise and unambiguous.
+</p>
+<p>
+ The degree of formality used when producing and disseminating models should vary according to your needs. Small,
+ collaborative teams modeling around whiteboards and capturing the results on a sheet of paper or with digital cameras
+ can yield good results. This can also help the team focus on producing software with the help of models; rather than
+ becoming sidetracked into over-engineering both the models and the solution. Modeling tools provide additional value to
+ projects, especially for more complex systems. Their specifics of use are outside the scope of this guideline, however.
+</p>
+<p>
+ This guideline does not describe a formal sequential progression through prescriptive design steps. Whether some or all
+ of these techniques are needed, or how long is spent on them will vary depending on real-world issues such as the
+ complexity of the requirements; the experience of the designer; and the way the team works.
+</p>
+<p>
+ This guideline uses a simplified scenario (Login) to help keep the focus on understanding the techniques rather than
+ the specific requirements. In the real-world, it is doubtful that much time would be spent modeling a simple problem.
+ Here is the use case diagram, for reference;
+</p>
+<p>
+ <img height="142" alt="User Login Use Case Model" src="resources/user_login_ucm.jpg" width="472" />
+</p>
+<h3>
+ Identify elements
+</h3>
+<p>
+ Render the identified design elements as classes in a UML diagram.&nbsp; Apply appropriate stereotypes and optionally
+ render the class using an icon specific to the stereotype to characterize the intent of the class in the design.&nbsp;
+ Name and briefly describe the classes in a few sentences. Do not spend too much time working on associations, as these
+ will be developed through working on collaborations in the next step.
+</p>
+<p>
+ Classes can be drawn as a basic UML rectangle or with a specific symbol associated with a particular stereotype.
+</p>
+<p>
+ The resulting class diagram should be conceptually similar to this one:
+</p>
+<p>
+ <img height="228" alt="Identify Elements - Initial Class Model" src="resources/identify_elements_bce.jpg"
+ width="290" />
+</p>
+<p>
+ For this example, the <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/guidances/guidelines/entity_control_boundary_pattern_C4047897.html"
+ guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a> has been used to derive two classes (LoginUI and
+ LoginController). In addition, two design elements already identified in the architecture (SecuritySystemInterface and
+ User) have also been incorporated.
+</p>
+<h3>
+ Determine how elements collaborate to realize the scenario
+</h3>
+<p>
+ When determining collaboration, two kinds of diagrams are useful.
+</p>
+<ul>
+ <li>
+ A dynamic object diagram, showing how the design elements collaborate to realize the requirements.
+ </li>
+ <li>
+ A static class diagram, showing the classes involved in realizing the requirements.
+ </li>
+</ul>
+<p>
+ Remember to also update any other impacted diagrams as appropriate, based on modifications or additions to the design.
+</p>
+<p>
+ Create a number of dynamic object diagrams that walk through how a set of objects collaborate to perform the behavior
+ of the scenarios.&nbsp; Even if just one scenario is being designed, this might take multiple diagrams to render it in
+ smaller, understandable chunks or from multiple contexts.
+</p>
+<p>
+ <img style="WIDTH: 776px; HEIGHT: 355px" height="355" alt="User Login Sequence Diagram"
+ src="resources/user_login_seq.jpg" width="776" />
+</p>
+<p>
+ The above sequence diagram shows the user credentials being passed through to the security system for authentication.
+ Steps in the use case scenario are transformed into messages between the participating objects. The messages in this
+ example are not yet fully formed (there are no parameters or return values), so they are prefixed with "//" to show
+ that more work is needed.&nbsp; A sequence diagram was used in this example, but a communication diagram could have
+ been used.
+</p>
+<p>
+ It&nbsp;can be&nbsp;useful to create one or more static class diagrams that show the classes in the design that support
+ the realization.&nbsp; These class diagrams are often called View of Participating Classes diagrams, they provide a
+ focused view on the overall design by only showing the classes, relationships, operations, and attributes relevant to
+ the collaboration.
+</p>
+<p>
+ <img height="469" alt="Login VOPC" src="resources/login_vopc.jpg" width="448" />
+</p>
+<p>
+ This diagram shows the operations and relationships that were identified by drawing the sequence diagram. The
+ relationships in this example&nbsp;have not been refined yet, so they are just shown as simple associations. Remember
+ to examine the diagram to verify that the design can support the behavior in the sequence diagram.
+</p>
+<p>
+ Working at this level of detail in the model during the early stages of design can be helpful. It keeps the diagrams
+ relatively simple and easy to understand. It makes them easier to draw in a workshop and easier to change during
+ discussion. It is often easier to add the detail once there is agreement on the fundamentals.
+</p>
+<h3>
+ Refine design decisions
+</h3>
+<p>
+ Once the fundamentals of the design are relatively stable, you can begin to add detail to the design. Some of this can
+ be performed in code or in the model. If modeling is chosen, then refine attributes, responsibilities and
+ relationships.
+</p>
+<h4>
+ Describe responsibilities
+</h4>
+<p>
+ Class responsibilities are either actions to be performed by an object or knowledge maintained and provided to other
+ objects. Each class will typically have several responsibilities; each responsibility will evolve into one or more
+ operations during design.
+</p>
+<p>
+ Responsibilities are derived from messages on interaction diagrams or from non-functional requirements that a class has
+ to support. Document a responsibility by giving it a name, and optionally a brief description (what it does).
+</p>
+<p>
+ These operations can be left as self-evident from their context, they can be given textual descriptions of the
+ algorithm required to perform the behavior, or they could spawn off another whole pass of this technique where a set of
+ classes that collaborate together to perform the internals of the operation are identified, etc.
+</p>
+<h4>
+ Describe attributes and associations
+</h4>
+<p>
+ A class may have to store simple data information, like: string, integer, and the like. For such simple type of
+ information, attributes are defined for classes. For a more complex or "behavioral" attribute, consider creating an
+ extra class and establish an association to it.
+</p>
+<p>
+ To perform their responsibilities, classes may depend on other classes to supply needed behavior. These other classes
+ might be ones already identified in this design session, they might be existing classes pulled from the architecture,
+ or the need for new classes might be conceived. Associations in a class diagram can be used to represent inter-class
+ relationships.
+</p>
+<p>
+ <img height="439" alt="Login VOPC (Refined)" src="resources/login_vopc_refined.jpg" width="557" />
+</p>
+<p>
+ This diagram shows a number of refinements. The LoginUI class has been replaced by LoginForm. The User class has been
+ renamed UserCredentials and is created by the LoginForm class rather than LoginController. It is then used as a
+ parameter for subsequent messages rather than passing the individual attributes. The SecuritySystemInterface class has
+ been refined into two elements, ISystemSecurity, which provides a simple façade for interaction with the rests of the
+ design; and SecuritySystemProxy, which handles interaction with the external security system.
+</p>
+<h3>
+ Design internals
+</h3>
+<p>
+ The classes in the design are likely to need to be distributed amongst different packages and subsystems or components.
+</p>
+<p>
+ <img height="304" alt="User Login - Design Packages" src="resources/dv_packaging.jpg" width="571" />
+</p>
+<p>
+ In this example, the LoginForm, LoginController and UserCredentials elements have been placed in a package called
+ LocalSecurity. The SecuritySystemProxy is a part of a subsystem called SecuritySystemAdapter which realizes the
+ ISecuritySystem interface. The SecuritySystemAdapter wraps the legacy SecuritySystem, expressed here as a component
+ offering a validateUser interface.
+</p>
+<p>
+ Each of these packaged elements can be distributed amongst the team for further development work.
+</p>
+<h3>
+ Conclusion
+</h3>
+<p>
+ This guideline walked through the techniques in a concrete manner started with a scenario of a use case through to
+ distributing the classes identified into a set of packages. This example demonstrates a technique for designing
+ visually, but it should be considered as just one conceptual pass of design.&nbsp; One could as easily apply this
+ technique when defining the internals of how the SecuritySystemProxy class will collaborate with a set of classes to
+ validate the credentials.
+</p>
+<p>
+ When applying this guideline, work in small chunks and keep in mind the goal of delivering software to the users that
+ provides value. To deliver high-quality software requires consideration of how the pieces will work together to deliver
+ that value. But as soon as key decisions have been made and the decisions have been communicated to the appropriate
+ team members, the team should move on to implementing the source code to verify the design and deliver the value.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.evolutionary_design.base/guidances/guidelines/evolve_the_design.xmi b/epf_prac_151/practice.tech.evolutionary_design.base/guidances/guidelines/evolve_the_design.xmi
index fc207c5..aa8d161 100644
--- a/epf_prac_151/practice.tech.evolutionary_design.base/guidances/guidelines/evolve_the_design.xmi
+++ b/epf_prac_151/practice.tech.evolutionary_design.base/guidances/guidelines/evolve_the_design.xmi
@@ -1,191 +1,191 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-8V5osHpRNG6Z7KPy8RGW1w" name=",_C4U9QPTeEduDKIuqTXQ8SA" guid="-8V5osHpRNG6Z7KPy8RGW1w" changeDate="2008-10-15T08:19:00.000-0700" version="7.5.0">
- <mainDescription><h1>
- Review the design
-</h1>
-<p>
- Design is best accomplished collaboratively, because it is a problem-solving activity with a range of&nbsp;parts and
- perspectives. There should be a constant level of review to ensure that the decisions make sense within the area being
- designed and in the design of the system overall. There also might be occasions where some area of design is reviewed
- by a set of interested or knowledgeable parties, such as the architect who will verify that the design conforms to an
- architectural decision or a developer who will be expected to implement the design.
-</p>
-<p>
- The design should be examined to ensure that it follows heuristics of quality design, such as loose coupling and high
- cohesion. Responsibilities should be appropriately distributed to elements in ways that there are no elements with too
- much responsibility and no elements that are left without any responsibilities. The design should be able to clearly
- communicate the design decisions, yet not delve into concerns best dealt with during implementation of code.
-</p>
-<p>
- Ensure that the design follows any project-specific guidelines and conforms to the architecture. Modifications to the
- design to improve it (based on issues identified in reviewing it) should apply <a class="elementLink"
- href="./../../../core.tech.common.extend_supp/guidances/guidelines/refactoring_F3D63EBD.html"
- guid="_YNx2sJ05EdyQ3oTO93enUw">Refactoring</a>&nbsp;to ensure that the design and any existing implementation of the
- design continues to fulfill its responsibilities.
-</p>Revisit the relationships between elements to improve the coupling in the design. Remove redundant relationships, try
-to make relationships unidirectional, and so forth. See <a class="elementLinkWithType"
-href="./../../../practice.tech.evolutionary_design.base/guidances/guidelines/analyze_the_design_4C4750C0.html"
-guid="__MnggPTdEduDKIuqTXQ8SA">Guideline: Analyze the Design</a> for more information.
-<h1>
- Refine the design
-</h1>
-<p>
- After creating an implementation that includes a set of collaborating elements, with the behavior and relationships
- robust enough to pass developer tests, the design can be improved and transformed into a more robust and maintainable
- system.
-</p>
-<p>
- The visibility of each operation should be selected to be as restrictive as possible. Based on walking through the
- scenario, it should be clear which operations must be available to other elements in the design and which can be
- considered behavior inside of the element that has the operation. Minimizing the number of public operations creates a
- more maintainable and understandable design.
-</p>
-<p>
- With respect to parameters, the return value, and a description of how it perform the behavior, operations can be
- detailed at a lower level that drives the actual implementation, or that detail might be left to be handled when
- writing the code.
-</p>
-<p>
- Data attributes can be identified based on information needed to support behavior or based on additional requirements,
- such as information to be presented to the user or transmitted to another system. Avoid indiscriminate domain analysis,
- because there might be a great deal of data in the domain that is not needed to support the requirements. Data
- attributes can simply be identified or they can be designed in detail, with attribute types, initial values, and
- constraints. Decide on the visibility of the data attribute; operations to access and update the data can be added or
- deferred until implementation.
-</p>
-<p>
- Generalization and interfaces can be applied to simplify or otherwise improve the design. Ensure that the use of these
- techniques actually improves the design, rather than bogging it down with complexity. For example, common behavior can
- be factored into a parent class through generalization or out to a helper class through delegation. The latter solution
- can be more understandable and maintainable, because generalization is an inflexible relationship (see the section that
- follows on inheritance).
-</p>
-<p>
- The refinement of any portion of the design could include another pass through the design process. You might find that
- what was initially identified as a single behavior of an element warrants a detailed walkthrough of the collaborating
- elements to realize that behavior.
-</p>
-<p>
- When updating an existing design -- especially one that has had portions already implemented -- apply refactoring to
- ensure that the improved design continues to perform as expected.
-</p>
-<h2>
- Organize elements
-</h2>
-<p>
- In a design of any notable size, the elements must be organized into packages. Assign the elements to existing or new
- packages, and ensure that the visibility relationships between the packages support the navigation required between the
- elements. Decide whether each element should be visible to elements outside of the package.
-</p>
-<p>
- When structuring the design into packages, consider <a class="elementLink"
- href="./../../../core.tech.common.extend_supp/guidances/guidelines/layering_F169CF07.html"
- guid="_0gpkAMlgEdmt3adZL5Dmdw">Layering</a> and other patterns. Although all design work must conform to existing
- architectural decisions, the allocation of elements to packages and possible updates to package visibility are of
- significant architectural concern. The developer should collaborate with the architect to ensure that package-level
- decisions are in accordance with the rest of the architecture.
-</p>
-<p>
- This guideline first talks about the identification and design of the elements and then about organizing the elements
- into packages. However, this is not a strict order of events. There is nothing wrong with identifying a package
- structure for the system and then populating that structure with identified elements, as long as the actual elements
- identified are allowed to influence the resulting package structure. See the sections on identification and behavior of
- elements in <a class="elementLinkWithType"
- href="./../../../practice.tech.evolutionary_design.base/guidances/guidelines/analyze_the_design_4C4750C0.html"
- guid="__MnggPTdEduDKIuqTXQ8SA">Guideline: Analyze the Design</a>.
-</p>
-<h2>
- Identify patterns
-</h2>
-<p>
- Identifying <a class="elementLink"
- href="./../../../core.tech.common.extend_supp/guidances/concepts/pattern_10BE6D96.html"
- guid="_0YJvUMlgEdmt3adZL5Dmdw">Pattern</a>s and seeking opportunities to leverage patterns are useful techniques. The
- value of patterns here is that they provide a shortcut to a robust design. For instance, when there's an interface
- realized by multiple classes, it's possible that an Abstract Factory pattern will be useful, because the pattern
- encapsulates the logic of what class should be instantiated. The more experienced a developer is, the better the
- developer is at identifying opportunities to take advantage of, or leverage, patterns.
-</p>
-<p>
- The longer you use patterns, the easier it will be to identify opportunities to leverage them. At first, look for
- places where you can clearly specify the need for some behavior. Perhaps there's a place where some function or
- algorithm must be shared between many different classes. How can this behavior be shared over and over among
- heterogeneous classes? Or perhaps a third-party library is replacing a block of custom code. Is there a way to make
- this transition easier by creating an interface that can use either implementation? These are opportunities for finding
- or possibly creating a pattern.
-</p>
-<p>
- See also <a class="elementLinkWithUserText"
- href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#GAM95"
- guid="_9ToeIB83Edqsvps02rpOOg">[GAM95]</a>&nbsp;and <a class="elementLinkWithUserText"
- href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#SHA05"
- guid="_9ToeIB83Edqsvps02rpOOg">[SHA05]</a>
-</p>
-<h1>
- Inheriting behavior versus inheriting interfaces
-</h1>
-<p>
- Inheritance (or generalization) is often used as a shortcut during implementation to quickly re-use behavior (code).
-</p>
-<p>
- <b>Caution:</b><br />
- Work hard to remove behavior inheritance in design. It will almost always cost more effort than it saves.
-</p>
-<p>
- Inheritance is a very rigid structure with strict rules. A class that inherits from another class is establishing an
- <b>is-a</b> relationship. The inheriting class is a type of the parent class-- the child has the same relationships and
- behaviors as the parent. In most hierarchies, it will be impossible to maintain this type of relationship. Exceptions
- quickly creep in, and it's common to find child classes that remove or override behavior in the parent classes. This
- increases maintenance costs and makes it difficult to understand what each class does.
-</p>
-<p>
- It's also too tempting to instantiate parent classes, which makes the parent class both abstract and concrete. If a
- class has children, it must be abstract enough to support the generalized behavior of the children. But if it's
- instantiated, it must be concrete enough to provide specific behavior. It's rarely possible to fulfill both of these
- competing imperatives at the same time, and the design suffers.
-</p>
-<p>
- Use association and aggregation relationships instead of inheriting behavior. Patterns are a good tool to leverage in
- breaking up inheritance hierarchies.
-</p>
-<p>
- Inheriting interfaces is safe, because only the description and not the implementation of what needs to be done is
- reused.
-</p>
-<p>
- Avoiding inheriting behavior is an application of the Open-Closed Principle. See <a class="elementLinkWithType"
- href="./../../../practice.tech.evolutionary_design.base/guidances/concepts/design_E36137FA.html"
- guid="_bFjlAPTYEduDKIuqTXQ8SA">Concept: Design</a> for more information.
-</p>
-<h1>
- <strong>Revisit the analysis</strong>
-</h1>
-<p>
- The <a class="elementLinkWithType"
- href="./../../../practice.tech.evolutionary_design.base/guidances/guidelines/analyze_the_design_4C4750C0.html"
- guid="__MnggPTdEduDKIuqTXQ8SA">Guideline: Analyze the Design</a>&nbsp;describes techniques that are also useful when
- evolving a more robust design.<br />
-</p>
-<h2>
- <strong>Consider the architecture</strong>
-</h2>
-<p>
- The architecture must be considered in all design changes. The "best" design for a particular part of the solution may
- not be appropriate because of architectural constraints that must support the entire system. The architecture may also
- help to make design decisions, because it can be part of the selection criteria between two potential solutions.
- Developers should always be up-to-date with the architecture and review it often, particularly in early iterations.
-</p>
-<p>
- This guideline remarks on conforming to the architecture in various ways; it is written as though it is about designing
- within a pre-existing architecture. Although projects will often have pre-existing architectures available, a
- particular architecture is the result of design activities. Therefore, in addition to discussing conformance to some
- existing architecture, you must also consider the creation of the architecture, as well as updates and improvements
- based on the work of design.
-</p>
-<p>
- Also, see&nbsp;<a class="elementLinkWithUserText"
- href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#SHA05"
- guid="_9ToeIB83Edqsvps02rpOOg">[SHA05]</a> for a&nbsp;useful introduction to object-oriented techniques that should be
- applied when evolving a good design.
+ <mainDescription><h3>
+ Review the design
+</h3>
+<p>
+ Design is best accomplished collaboratively, because it is a problem-solving activity with a range of&nbsp;parts and
+ perspectives. There should be a constant level of review to ensure that the decisions make sense within the area being
+ designed and in the design of the system overall. There also might be occasions where some area of design is reviewed
+ by a set of interested or knowledgeable parties, such as the architect who will verify that the design conforms to an
+ architectural decision or a developer who will be expected to implement the design.
+</p>
+<p>
+ The design should be examined to ensure that it follows heuristics of quality design, such as loose coupling and high
+ cohesion. Responsibilities should be appropriately distributed to elements in ways that there are no elements with too
+ much responsibility and no elements that are left without any responsibilities. The design should be able to clearly
+ communicate the design decisions, yet not delve into concerns best dealt with during implementation of code.
+</p>
+<p>
+ Ensure that the design follows any project-specific guidelines and conforms to the architecture. Modifications to the
+ design to improve it (based on issues identified in reviewing it) should apply <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/guidances/guidelines/refactoring_F3D63EBD.html"
+ guid="_YNx2sJ05EdyQ3oTO93enUw">Refactoring</a>&nbsp;to ensure that the design and any existing implementation of the
+ design continues to fulfill its responsibilities.
+</p>Revisit the relationships between elements to improve the coupling in the design. Remove redundant relationships, try
+to make relationships unidirectional, and so forth. See <a class="elementLinkWithType"
+href="./../../../practice.tech.evolutionary_design.base/guidances/guidelines/analyze_the_design_4C4750C0.html"
+guid="__MnggPTdEduDKIuqTXQ8SA">Guideline: Analyze the Design</a> for more information. 
+<h3>
+ Refine the design
+</h3>
+<p>
+ After creating an implementation that includes a set of collaborating elements, with the behavior and relationships
+ robust enough to pass developer tests, the design can be improved and transformed into a more robust and maintainable
+ system.
+</p>
+<p>
+ The visibility of each operation should be selected to be as restrictive as possible. Based on walking through the
+ scenario, it should be clear which operations must be available to other elements in the design and which can be
+ considered behavior inside of the element that has the operation. Minimizing the number of public operations creates a
+ more maintainable and understandable design.
+</p>
+<p>
+ With respect to parameters, the return value, and a description of how it perform the behavior, operations can be
+ detailed at a lower level that drives the actual implementation, or that detail might be left to be handled when
+ writing the code.
+</p>
+<p>
+ Data attributes can be identified based on information needed to support behavior or based on additional requirements,
+ such as information to be presented to the user or transmitted to another system. Avoid indiscriminate domain analysis,
+ because there might be a great deal of data in the domain that is not needed to support the requirements. Data
+ attributes can simply be identified or they can be designed in detail, with attribute types, initial values, and
+ constraints. Decide on the visibility of the data attribute; operations to access and update the data can be added or
+ deferred until implementation.
+</p>
+<p>
+ Generalization and interfaces can be applied to simplify or otherwise improve the design. Ensure that the use of these
+ techniques actually improves the design, rather than bogging it down with complexity. For example, common behavior can
+ be factored into a parent class through generalization or out to a helper class through delegation. The latter solution
+ can be more understandable and maintainable, because generalization is an inflexible relationship (see the section that
+ follows on inheritance).
+</p>
+<p>
+ The refinement of any portion of the design could include another pass through the design process. You might find that
+ what was initially identified as a single behavior of an element warrants a detailed walkthrough of the collaborating
+ elements to realize that behavior.
+</p>
+<p>
+ When updating an existing design -- especially one that has had portions already implemented -- apply refactoring to
+ ensure that the improved design continues to perform as expected.
+</p>
+<h4>
+ Organize elements
+</h4>
+<p>
+ In a design of any notable size, the elements must be organized into packages. Assign the elements to existing or new
+ packages, and ensure that the visibility relationships between the packages support the navigation required between the
+ elements. Decide whether each element should be visible to elements outside of the package.
+</p>
+<p>
+ When structuring the design into packages, consider <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/guidances/guidelines/layering_F169CF07.html"
+ guid="_0gpkAMlgEdmt3adZL5Dmdw">Layering</a> and other patterns. Although all design work must conform to existing
+ architectural decisions, the allocation of elements to packages and possible updates to package visibility are of
+ significant architectural concern. The developer should collaborate with the architect to ensure that package-level
+ decisions are in accordance with the rest of the architecture.
+</p>
+<p>
+ This guideline first talks about the identification and design of the elements and then about organizing the elements
+ into packages. However, this is not a strict order of events. There is nothing wrong with identifying a package
+ structure for the system and then populating that structure with identified elements, as long as the actual elements
+ identified are allowed to influence the resulting package structure. See the sections on identification and behavior of
+ elements in <a class="elementLinkWithType"
+ href="./../../../practice.tech.evolutionary_design.base/guidances/guidelines/analyze_the_design_4C4750C0.html"
+ guid="__MnggPTdEduDKIuqTXQ8SA">Guideline: Analyze the Design</a>.
+</p>
+<h4>
+ Identify patterns
+</h4>
+<p>
+ Identifying <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/pattern_10BE6D96.html"
+ guid="_0YJvUMlgEdmt3adZL5Dmdw">Pattern</a>s and seeking opportunities to leverage patterns are useful techniques. The
+ value of patterns here is that they provide a shortcut to a robust design. For instance, when there's an interface
+ realized by multiple classes, it's possible that an Abstract Factory pattern will be useful, because the pattern
+ encapsulates the logic of what class should be instantiated. The more experienced a developer is, the better the
+ developer is at identifying opportunities to take advantage of, or leverage, patterns.
+</p>
+<p>
+ The longer you use patterns, the easier it will be to identify opportunities to leverage them. At first, look for
+ places where you can clearly specify the need for some behavior. Perhaps there's a place where some function or
+ algorithm must be shared between many different classes. How can this behavior be shared over and over among
+ heterogeneous classes? Or perhaps a third-party library is replacing a block of custom code. Is there a way to make
+ this transition easier by creating an interface that can use either implementation? These are opportunities for finding
+ or possibly creating a pattern.
+</p>
+<p>
+ See also <a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#GAM95"
+ guid="_9ToeIB83Edqsvps02rpOOg">[GAM95]</a>&nbsp;and <a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#SHA05"
+ guid="_9ToeIB83Edqsvps02rpOOg">[SHA05]</a>
+</p>
+<h3>
+ Inheriting behavior versus inheriting interfaces
+</h3>
+<p>
+ Inheritance (or generalization) is often used as a shortcut during implementation to quickly re-use behavior (code).
+</p>
+<p>
+ <b>Caution:</b><br />
+ Work hard to remove behavior inheritance in design. It will almost always cost more effort than it saves.
+</p>
+<p>
+ Inheritance is a very rigid structure with strict rules. A class that inherits from another class is establishing an
+ <b>is-a</b> relationship. The inheriting class is a type of the parent class-- the child has the same relationships and
+ behaviors as the parent. In most hierarchies, it will be impossible to maintain this type of relationship. Exceptions
+ quickly creep in, and it's common to find child classes that remove or override behavior in the parent classes. This
+ increases maintenance costs and makes it difficult to understand what each class does.
+</p>
+<p>
+ It's also too tempting to instantiate parent classes, which makes the parent class both abstract and concrete. If a
+ class has children, it must be abstract enough to support the generalized behavior of the children. But if it's
+ instantiated, it must be concrete enough to provide specific behavior. It's rarely possible to fulfill both of these
+ competing imperatives at the same time, and the design suffers.
+</p>
+<p>
+ Use association and aggregation relationships instead of inheriting behavior. Patterns are a good tool to leverage in
+ breaking up inheritance hierarchies.
+</p>
+<p>
+ Inheriting interfaces is safe, because only the description and not the implementation of what needs to be done is
+ reused.
+</p>
+<p>
+ Avoiding inheriting behavior is an application of the Open-Closed Principle. See <a class="elementLinkWithType"
+ href="./../../../practice.tech.evolutionary_design.base/guidances/concepts/design_E36137FA.html"
+ guid="_bFjlAPTYEduDKIuqTXQ8SA">Concept: Design</a> for more information.
+</p>
+<h3>
+ <strong>Revisit the analysis</strong>
+</h3>
+<p>
+ The <a class="elementLinkWithType"
+ href="./../../../practice.tech.evolutionary_design.base/guidances/guidelines/analyze_the_design_4C4750C0.html"
+ guid="__MnggPTdEduDKIuqTXQ8SA">Guideline: Analyze the Design</a>&nbsp;describes techniques that are also useful when
+ evolving a more robust design.<br />
+</p>
+<h4>
+ <strong>Consider the architecture</strong>
+</h4>
+<p>
+ The architecture must be considered in all design changes. The "best" design for a particular part of the solution may
+ not be appropriate because of architectural constraints that must support the entire system. The architecture may also
+ help to make design decisions, because it can be part of the selection criteria between two potential solutions.
+ Developers should always be up-to-date with the architecture and review it often, particularly in early iterations.
+</p>
+<p>
+ This guideline remarks on conforming to the architecture in various ways; it is written as though it is about designing
+ within a pre-existing architecture. Although projects will often have pre-existing architectures available, a
+ particular architecture is the result of design activities. Therefore, in addition to discussing conformance to some
+ existing architecture, you must also consider the creation of the architecture, as well as updates and improvements
+ based on the work of design.
+</p>
+<p>
+ Also, see&nbsp;<a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#SHA05"
+ guid="_9ToeIB83Edqsvps02rpOOg">[SHA05]</a> for a&nbsp;useful introduction to object-oriented techniques that should be
+ applied when evolving a good design.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.evolutionary_design.base/guidances/practices/evolutionary_design.xmi b/epf_prac_151/practice.tech.evolutionary_design.base/guidances/practices/evolutionary_design.xmi
index 5ebb711..d51b3fd 100644
--- a/epf_prac_151/practice.tech.evolutionary_design.base/guidances/practices/evolutionary_design.xmi
+++ b/epf_prac_151/practice.tech.evolutionary_design.base/guidances/practices/evolutionary_design.xmi
@@ -1,37 +1,37 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:PracticeDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-6c0bIr5yRMTjbRKw9kIHrA" name="evolutionary_design,_aSVhIB4qEd2bS8fFOQ7WWA" guid="-6c0bIr5yRMTjbRKw9kIHrA" changeDate="2008-08-14T03:22:00.000-0700" version="7.5.0">
- <mainDescription><h4>
- The Essence of Evolutionary Design
-</h4>
-<p>
- During each pass of the design, you will add, refine, and refactor your solution. The following steps summarize the
- evolutionary design practice:
-</p>
-<ul>
- <li>
- Understand new requirement details
- </li>
- <li>
- Identify design elements
- </li>
- <li>
- Determine how elements collaborate to realize the scenario
- </li>
- <li>
- Refine design decisions
- </li>
- <li>
- Design internals
- </li>
- <li>
- Communicate the design
- </li>
- <li>
- Understand the architecture
- </li>
- <li>
- Evaluate the design<br />
- </li>
+ <mainDescription><h4>
+ The Essence of Evolutionary Design
+</h4>
+<p>
+ During each pass of the design, you will add, refine, and refactor your solution. The following steps summarize the
+ evolutionary design practice:
+</p>
+<ul>
+ <li>
+ Understand new requirement details
+ </li>
+ <li>
+ Identify design elements
+ </li>
+ <li>
+ Determine how elements collaborate to realize the scenario
+ </li>
+ <li>
+ Refine design decisions
+ </li>
+ <li>
+ Design internals
+ </li>
+ <li>
+ Communicate the design
+ </li>
+ <li>
+ Understand the architecture
+ </li>
+ <li>
+ Evaluate the design<br />
+ </li>
</ul></mainDescription>
<additionalInfo><p>
Meyer, B., <em>Object-Oriented Software Construction</em>, Prentice Hall, 1997
@@ -60,13 +60,15 @@
</p>
</blockquote>
<p dir="ltr">
- Richard E. Fairley, Mary Jane Willshire, "<a href="http://doi.ieeecomputersociety.org/10.1109/MC.2005.303" target="_blank">Iterative Rework: The Good, the Bad, and the Ugly</a>," Computer, vol. 38, no. 9, pp. 34-41, Sept.,
+ Richard E. Fairley, Mary Jane Willshire, "<a href="http://doi.ieeecomputersociety.org/10.1109/MC.2005.303"
+ target="_blank">Iterative Rework: The Good, the Bad, and the Ugly</a>," Computer, vol. 38, no. 9, pp. 34-41, Sept.,
2005.<br />
<br />
Martin Fowler, <a href="http://martinfowler.com/articles/designDead.html" target="_blank">"Is Design Dead?"</a>
Retrieved 8 August 2008<br />
<br />
- Craig Larman, Victor R. Basili, "<a href="http://doi.ieeecomputersociety.org/10.1109/MC.2003.1204375" target="_blank">Iterative and Incremental Development: A Brief History</a>" Computer, vol. 36, no. 6, pp. 47-56, Jun.,
+ Craig Larman, Victor R. Basili, "<a href="http://doi.ieeecomputersociety.org/10.1109/MC.2003.1204375"
+ target="_blank">Iterative and Incremental Development: A Brief History</a>" Computer, vol. 36, no. 6, pp. 47-56, Jun.,
2003.
</p>
<p dir="ltr">
diff --git a/epf_prac_151/practice.tech.evolutionary_design.base/guidances/roadmaps/how_to_adopt_evolutionary_design.xmi b/epf_prac_151/practice.tech.evolutionary_design.base/guidances/roadmaps/how_to_adopt_evolutionary_design.xmi
index 6d92b94..797e1bd 100644
--- a/epf_prac_151/practice.tech.evolutionary_design.base/guidances/roadmaps/how_to_adopt_evolutionary_design.xmi
+++ b/epf_prac_151/practice.tech.evolutionary_design.base/guidances/roadmaps/how_to_adopt_evolutionary_design.xmi
@@ -1,52 +1,52 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-QmIvs-rs3Fiyg7PVRx2IvQ" name="new_roadmap,_irQiEOCsEdynptYdmll41Q" guid="-QmIvs-rs3Fiyg7PVRx2IvQ" changeDate="2008-10-15T09:15:06.000-0700" version="7.2.0">
- <mainDescription><p>
- <strong>Getting Started</strong>
-</p>
-<p>
- Begin by gaining an understanding of&nbsp;<a class="elementLinkWithUserText"
- href="./../../../core.tech.common.extend_supp/guidances/concepts/pattern_10BE6D96.html"
- guid="_0YJvUMlgEdmt3adZL5Dmdw">design patterns</a>. There are good references in the Additional&nbsp;Information
- section of the&nbsp;<a class="elementLink"
- href="./../../../practice.tech.evolutionary_design.base/guidances/practices/evolutionary_design_DE27D8D9.html"
- guid="_aSVhIB4qEd2bS8fFOQ7WWA">Evolutionary Design</a>&nbsp;page. Patterns are essential to creating, managing, and
- evolving designs. As the name implies, evolutionary design involves returning to the existing design over and over
- again to refine, change, and improve previous thinking. It can be performed at the beginning of a development cycle
- (before implementation), during a development cycle (while implementing code), after the cycle (when the developer
- tests have&nbsp;successfully executed), or any combination of these. The team should determine where in the development
- cycle the design will be performed. See <a class="elementLinkWithType"
- href="./../../../practice.tech.evolutionary_design.base/tasks/design_solution_A97CE9EA.html"
- guid="_0fshwMlgEdmt3adZL5Dmdw">Task: Design the Solution</a>.
-</p>
-<p>
- Understand <a class="elementLinkWithUserText"
- href="./../../../core.tech.common.extend_supp/guidances/concepts/refactoring_1B63BA3B.html"
- guid="_Poc7IPDzEdqYgerqi84oCA">refactoring</a> and the difference between code refactoring and design refactoring.
- There is no exact boundary separating the two, but there are some clear areas where the developer will wear the "design
- hat" when reworking the design into a better structure. These areas will usually involve identifying where design
- patterns can replace or enhance the existing design, or areas of the design where patterns can be identified and
- harvested for reuse.
-</p>
-<p>
- <strong>Common pitfalls</strong>
-</p>
-<p>
- Evolutionary design emerges from refactoring existing design. This improves the design without changing the behavior of
- the system. Failing to perform developer or unit testing is a high risk activity, as you can not guarantee that:
-</p>
-<ul>
- <li>
- The original design works correctly
- </li>
- <li>
- The refactored design works correctly
- </li>
-</ul>
-<p>
- Therefore, you must perform rigorous <a class="elementLinkWithUserText"
- href="./../../../core.tech.common.extend_supp/guidances/concepts/developer_testing_FEBDAED6.html"
- guid="_ADwlAJRtEdyrdaw_xGakyw">developer testing</a> in order to verify the robustness of the design. Otherwise, you
- may waste a lot of time refactoring something that does not work, or refactoring the correct behavior out of the
- system.
+ <mainDescription><p>
+ <strong>Getting Started</strong>
+</p>
+<p>
+ Begin by gaining an understanding of&nbsp;<a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/pattern_10BE6D96.html"
+ guid="_0YJvUMlgEdmt3adZL5Dmdw">design patterns</a>. There are good references in the Additional&nbsp;Information
+ section of the&nbsp;<a class="elementLink"
+ href="./../../../practice.tech.evolutionary_design.base/guidances/practices/evolutionary_design_DE27D8D9.html"
+ guid="_aSVhIB4qEd2bS8fFOQ7WWA">Evolutionary Design</a>&nbsp;page. Patterns are essential to creating, managing, and
+ evolving designs. As the name implies, evolutionary design involves returning to the existing design over and over
+ again to refine, change, and improve previous thinking. It can be performed at the beginning of a development cycle
+ (before implementation), during a development cycle (while implementing code), after the cycle (when the developer
+ tests have&nbsp;successfully executed), or any combination of these. The team should determine where in the development
+ cycle the design will be performed. See <a class="elementLinkWithType"
+ href="./../../../practice.tech.evolutionary_design.base/tasks/design_solution_A97CE9EA.html"
+ guid="_0fshwMlgEdmt3adZL5Dmdw">Task: Design the Solution</a>.
+</p>
+<p>
+ Understand <a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/refactoring_1B63BA3B.html"
+ guid="_Poc7IPDzEdqYgerqi84oCA">refactoring</a> and the difference between code refactoring and design refactoring.
+ There is no exact boundary separating the two, but there are some clear areas where the developer will wear the "design
+ hat" when reworking the design into a better structure. These areas will usually involve identifying where design
+ patterns can replace or enhance the existing design, or areas of the design where patterns can be identified and
+ harvested for reuse.
+</p>
+<p>
+ <strong>Common pitfalls</strong>
+</p>
+<p>
+ Evolutionary design emerges from refactoring existing design. This improves the design without changing the behavior of
+ the system. Failing to perform developer or unit testing is a high risk activity, as you can not guarantee that:
+</p>
+<ul>
+ <li>
+ The original design works correctly
+ </li>
+ <li>
+ The refactored design works correctly
+ </li>
+</ul>
+<p>
+ Therefore, you must perform rigorous <a class="elementLinkWithUserText"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/developer_testing_FEBDAED6.html"
+ guid="_ADwlAJRtEdyrdaw_xGakyw">developer testing</a> in order to verify the robustness of the design. Otherwise, you
+ may waste a lot of time refactoring something that does not work, or refactoring the correct behavior out of the
+ system.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.evolutionary_design.base/guidances/supportingmaterials/using_ed_in_context.xmi b/epf_prac_151/practice.tech.evolutionary_design.base/guidances/supportingmaterials/using_ed_in_context.xmi
index 8cc7d96..76164ab 100644
--- a/epf_prac_151/practice.tech.evolutionary_design.base/guidances/supportingmaterials/using_ed_in_context.xmi
+++ b/epf_prac_151/practice.tech.evolutionary_design.base/guidances/supportingmaterials/using_ed_in_context.xmi
@@ -1,19 +1,19 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-5Eyl-J5cLkiBJKpxgcxBRA" name="new_supporting_material,_atpj0GjLEd2PJ-nlV-86WA" guid="-5Eyl-J5cLkiBJKpxgcxBRA" changeDate="2008-08-14T08:40:06.000-0700" version="7.5.0">
- <mainDescription><p>
- The Evolutionary Design practice describes how to create a high quality design by evolving the design in small
- increments and refactoring often. It should be used in conjunction with other practices or process elements to deliver
- high quality software. This example illustrates one possible way of utilizing the ED practice in conjunction with other
- practices.
-</p>
-<p>
- This diagram describes an evolutionary approach to developing software by incrementally considering a small part of the
- system. A brief amount of time is spent considering the possible design, the code is implemented using a test-first
- approach, and&nbsp;the design is reviewed and refactored until high quality software is achieved. The new part of the
- system is then integrated with the rest of the system, and another small part of the system is selected for
- development.&nbsp;
-</p>
-<p>
- <img height="587" alt="" src="resources/ed_in_context.jpg" width="598" />
+ <mainDescription><p>
+ The Evolutionary Design practice describes how to create a high quality design by evolving the design in small
+ increments and refactoring often. It should be used in conjunction with other practices or process elements to deliver
+ high quality software. This example illustrates one possible way of utilizing the ED practice in conjunction with other
+ practices.
+</p>
+<p>
+ This diagram describes an evolutionary approach to developing software by incrementally considering a small part of the
+ system. A brief amount of time is spent considering the possible design, the code is implemented using a test-first
+ approach, and&nbsp;the design is reviewed and refactored until high quality software is achieved. The new part of the
+ system is then integrated with the rest of the system, and another small part of the system is selected for
+ development.&nbsp;
+</p>
+<p>
+ <img height="587" alt="" src="resources/ed_in_context.jpg" width="598" />
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.evolutionary_design.base/guidances/templates/design.xmi b/epf_prac_151/practice.tech.evolutionary_design.base/guidances/templates/design.xmi
index dde3b47..8a6de9b 100644
--- a/epf_prac_151/practice.tech.evolutionary_design.base/guidances/templates/design.xmi
+++ b/epf_prac_151/practice.tech.evolutionary_design.base/guidances/templates/design.xmi
@@ -1,106 +1,106 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:GuidanceDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-giTBOvJczHXweRzBQEo-7A" name="new_template,_EOPcMAMUEdylNddAObilIA" guid="-giTBOvJczHXweRzBQEo-7A" changeDate="2008-08-14T08:20:04.000-0700" version="7.5.0">
- <mainDescription><p>
- This template describes how the design can be organized to be understood from multiple perspectives. It also provides
- suggestions for how patterns and descriptions of small, reusable interactions can be used to minimize redundancy.
-</p>
-<p>
- It is important not to think of design as "a document." Design information that is worth keeping for some duration must
- have a long-lived form. But that form might be as a repository in a visual modeling tool, or as subdirectories of
- whiteboard diagrams captured with a digital camera, or as an actual document that provides structure for images taken
- from a myriad of sources.
-</p>
-<p>
- Designs are often organized into requirement realizations. A requirements realization is a part of the design that
- shows how one or more requirements is implemented.
-</p>
-<p>
- This template describes the information that should be conveyed. Typically, it works best to convey the information
- graphically (either with UML or another unambiguous notation), or at least in words, at an abstract level. You can
- enhance this with code examples, but best not to render the design solely at the code level.
-</p>
-<p>
- The structure of the design is suggested in this template.
-</p>
-<h1>
- Design structure
-</h1>
-<p style="COLOR: #0000ff">
- [Describe the design from the highest level. This is commonly done with a diagram that shows a layered architecture.]
-</p>
-<h1>
- Subsystems
-</h1>
-<h2>
- [Sub-system1]
-</h2>
-<p style="COLOR: #0000ff">
- [Describe the design of a portion of the system (a package or component, for instance). The design should capture both
- static and dynamic perspectives.
-</p>
-<p style="COLOR: #0000ff">
- When capturing dynamic descriptions of behavior, look for reusable chunks of behavior that you can reference to
- simplify the design of the requirement realizations.
-</p>
-<p style="COLOR: #0000ff">
- You can break this section down into lower-level subsections to describe lower-level, encapsulated subsystems.]
-</p>
-<h1>
- Patterns
-</h1>
-<h2>
- [Pattern1]
-</h2>
-<h3>
- Overview
-</h3>
-<p style="COLOR: #0000ff">
- [Provide an overview of the pattern in words in some consistent form. The overview of a pattern can include the intent,
- motivation, and applicability.]
-</p>
-<h3>
- Structure
-</h3>
-<p style="COLOR: #0000ff">
- [Describe the pattern from a static perspective. Include all of the participants and how they relate to one another,
- and call out the&nbsp;relevant data and behavior.]
-</p>
-<h3>
- Behavior
-</h3>
-<p style="COLOR: #0000ff">
- [Describe the pattern from a dynamic perspective. Walk the reader through how the participants collaborate to support
- various scenarios.]
-</p>Example
-<p style="COLOR: #0000ff">
- [Often, you can convey the nature of the pattern better with an additional concrete example.]
-</p>
-<h1>
- Requirement&nbsp;realizations
-</h1>
-<h2>
- [Realization1]
-</h2>
-<h3>
- View of participants
-</h3>
-<p style="COLOR: #0000ff">
- [Describe the participating design elements from a static perspective, giving details such as behavior, relationships,
- and attributes relevant to this realization.]
-</p>
-<h3>
- Basic scenario
-</h3>
-<p style="COLOR: #0000ff">
- [For the main flow, describe how instances of the design elements collaborate to realize the requirements. When using
- UML, this can be done with collaboration diagrams (sequence or communication).]
-</p>
-<h3>
- Additional scenarios
-</h3>
-<p style="COLOR: #0000ff">
- [For other scenarios that must be described to convey an appropriate amount of information about how the requirement
- behavior will be realized, describe how instances of the design elements collaborate to realize the requirement. When
- using UML, you can do this with collaboration diagrams (sequence or communication).]
+ <mainDescription><p>
+ This template describes how the design can be organized to be understood from multiple perspectives. It also provides
+ suggestions for how patterns and descriptions of small, reusable interactions can be used to minimize redundancy.
+</p>
+<p>
+ It is important not to think of design as "a document." Design information that is worth keeping for some duration must
+ have a long-lived form. But that form might be as a repository in a visual modeling tool, or as subdirectories of
+ whiteboard diagrams captured with a digital camera, or as an actual document that provides structure for images taken
+ from a myriad of sources.
+</p>
+<p>
+ Designs are often organized into requirement realizations. A requirements realization is a part of the design that
+ shows how one or more requirements is implemented.
+</p>
+<p>
+ This template describes the information that should be conveyed. Typically, it works best to convey the information
+ graphically (either with UML or another unambiguous notation), or at least in words, at an abstract level. You can
+ enhance this with code examples, but best not to render the design solely at the code level.
+</p>
+<p>
+ The structure of the design is suggested in this template.
+</p>
+<h2>
+ Design structure
+</h2>
+<p style="COLOR: #0000ff">
+ [Describe the design from the highest level. This is commonly done with a diagram that shows a layered architecture.]
+</p>
+<h2>
+ Subsystems
+</h2>
+<h3>
+ [Sub-system1]
+</h3>
+<p style="COLOR: #0000ff">
+ [Describe the design of a portion of the system (a package or component, for instance). The design should capture both
+ static and dynamic perspectives.
+</p>
+<p style="COLOR: #0000ff">
+ When capturing dynamic descriptions of behavior, look for reusable chunks of behavior that you can reference to
+ simplify the design of the requirement realizations.
+</p>
+<p style="COLOR: #0000ff">
+ You can break this section down into lower-level subsections to describe lower-level, encapsulated subsystems.]
+</p>
+<h2>
+ Patterns
+</h2>
+<h3>
+ [Pattern1]
+</h3>
+<h4>
+ Overview
+</h4>
+<p style="COLOR: #0000ff">
+ [Provide an overview of the pattern in words in some consistent form. The overview of a pattern can include the intent,
+ motivation, and applicability.]
+</p>
+<h4>
+ Structure
+</h4>
+<p style="COLOR: #0000ff">
+ [Describe the pattern from a static perspective. Include all of the participants and how they relate to one another,
+ and call out the&nbsp;relevant data and behavior.]
+</p>
+<h4>
+ Behavior
+</h4>
+<p style="COLOR: #0000ff">
+ [Describe the pattern from a dynamic perspective. Walk the reader through how the participants collaborate to support
+ various scenarios.]
+</p>Example 
+<p style="COLOR: #0000ff">
+ [Often, you can convey the nature of the pattern better with an additional concrete example.]
+</p>
+<h2>
+ Requirement&nbsp;realizations
+</h2>
+<h3>
+ [Realization1]
+</h3>
+<h4>
+ View of participants
+</h4>
+<p style="COLOR: #0000ff">
+ [Describe the participating design elements from a static perspective, giving details such as behavior, relationships,
+ and attributes relevant to this realization.]
+</p>
+<h4>
+ Basic scenario
+</h4>
+<p style="COLOR: #0000ff">
+ [For the main flow, describe how instances of the design elements collaborate to realize the requirements. When using
+ UML, this can be done with collaboration diagrams (sequence or communication).]
+</p>
+<h4>
+ Additional scenarios
+</h4>
+<p style="COLOR: #0000ff">
+ [For other scenarios that must be described to convey an appropriate amount of information about how the requirement
+ behavior will be realized, describe how instances of the design elements collaborate to realize the requirement. When
+ using UML, you can do this with collaboration diagrams (sequence or communication).]
</p></mainDescription>
</org.eclipse.epf.uma:GuidanceDescription>
diff --git a/epf_prac_151/practice.tech.evolutionary_design.base/tasks/design_solution.xmi b/epf_prac_151/practice.tech.evolutionary_design.base/tasks/design_solution.xmi
index 0da991a..980e419 100644
--- a/epf_prac_151/practice.tech.evolutionary_design.base/tasks/design_solution.xmi
+++ b/epf_prac_151/practice.tech.evolutionary_design.base/tasks/design_solution.xmi
@@ -1,57 +1,63 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:TaskDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_NrC20qeqEdmKDbQuyzCoqQ" name="design_solution,_0fshwMlgEdmt3adZL5Dmdw" guid="_NrC20qeqEdmKDbQuyzCoqQ" changeDate="2008-01-25T09:58:59.000-0800" version="1.0.0">
- <mainDescription><p>
- This task is about designing part of the system, not the whole system.&nbsp; It should be applied based upon some small
- subset of requirements.&nbsp; The requirements driving the design could be scenario-based functional requirements,
- non-functional requirements, or a combination.
-</p>
-<p>
- This task can be applied in some specific context such as the database access elements required for some
- scenario.&nbsp; In this case the task might be applied&nbsp;again later&nbsp;to deal with a different context on the
- same requirements.&nbsp; Keep in mind that to actually build some functionality of value&nbsp;to the users, all
- contexts will typically need to be designed and implemented. For example, to actually utilize some system capability it
- will have to have been designed and implemented all its context such as user interface, business rules, database
- access, etc.
-</p>
-<p>
- For cohesion and completeness, this task is described as an end-to-end pass of designing a scenario of system usage. In
- practice, this task will be revisited many times as the design is first considered, portions are implemented, more
- design is performed based on what was learned, etc. The healthiest application of this task is in very close proximity
- to the implementation.
-</p>
-<p>
- If this task is being performed on an architecturally significant element the results of this design should be
- referenced by the <a class="elementLink" href="./../../core.tech.slot.base/workproducts/technical_architecture_slot_FF074CDD.html" guid="_8OD-cLPTEduocbW-TPTq7A">[Technical Architecture]</a>.
+ <mainDescription><p>
+ This task is about designing part of the system, not the whole system.&nbsp; It should be applied based upon some small
+ subset of requirements.&nbsp; The requirements driving the design could be scenario-based functional requirements,
+ non-functional requirements, or a combination.
+</p>
+<p>
+ This task can be applied in some specific context such as the database access elements required for some
+ scenario.&nbsp; In this case the task might be applied&nbsp;again later&nbsp;to deal with a different context on the
+ same requirements.&nbsp; Keep in mind that to actually build some functionality of value&nbsp;to the users, all
+ contexts will typically need to be designed and implemented. For example, to actually utilize some system capability it
+ will have to have been designed and implemented all its context such as user interface, business rules, database
+ access, etc.
+</p>
+<p>
+ For cohesion and completeness, this task is described as an end-to-end pass of designing a scenario of system usage. In
+ practice, this task will be revisited many times as the design is first considered, portions are implemented, more
+ design is performed based on what was learned, etc. The healthiest application of this task is in very close proximity
+ to the implementation.
+</p>
+<p>
+ If this task is being performed on an architecturally significant element the results of this design should be
+ referenced by the <a class="elementLink"
+ href="./../../core.tech.slot.base/workproducts/technical_architecture_slot_FF074CDD.html"
+ guid="_8OD-cLPTEduocbW-TPTq7A">[Technical Architecture]</a>.
</p></mainDescription>
- <keyConsiderations><p>
- Each step in this task can cause all previous steps to be revisited in light of new information and decisions.&nbsp;
- For example, while determining how elements collaborate&nbsp;you might find a gap in the requirements that causes you
- to go back to the beginning after collaborating with the analyst, or when evaluating the design a reviewer
- could&nbsp;note that a reusable element being used doesn't work as expected and that could cause you to identify new
- elements to take its place.
-</p>
-<p>
- Consider the architecture while performing this task.&nbsp; All design work must be done while regarding the
- architecture within which the design exists.&nbsp; Furthermore, certain design elements will be deemed architecturally
- significant; those elements will require updates to the architecture.
-</p>
-<p>
- This task will be applied numerous times.&nbsp; Design is best performed in small chunks.
-</p>
-<p>
- Even when starting the design for a particular project it&nbsp;is expected that there will be existing frameworks and
- reusable elements.&nbsp; Every step of this task must give attention to the existing design and existing
- implementation, utilizing existing elements when possible and emulating or improving existing elements as appropriate
- while designing this portion of the solution.
-</p>
-<p>
- Apply patterns throughout this task.&nbsp; Patterns represent proven designs and their usage promotes quality and
- consistency across the design.
+ <keyConsiderations><p>
+ Each step in this task can cause all previous steps to be revisited in light of new information and decisions.&nbsp;
+ For example, while determining how elements collaborate&nbsp;you might find a gap in the requirements that causes you
+ to go back to the beginning after collaborating with the analyst, or when evaluating the design a reviewer
+ could&nbsp;note that a reusable element being used doesn't work as expected and that could cause you to identify new
+ elements to take its place.
+</p>
+<p>
+ Consider the architecture while performing this task.&nbsp; All design work must be done while regarding the
+ architecture within which the design exists.&nbsp; Furthermore, certain design elements will be deemed architecturally
+ significant; those elements will require updates to the architecture.
+</p>
+<p>
+ This task will be applied numerous times.&nbsp; Design is best performed in small chunks.
+</p>
+<p>
+ Even when starting the design for a particular project it&nbsp;is expected that there will be existing frameworks and
+ reusable elements.&nbsp; Every step of this task must give attention to the existing design and existing
+ implementation, utilizing existing elements when possible and emulating or improving existing elements as appropriate
+ while designing this portion of the solution.
+</p>
+<p>
+ Apply patterns throughout this task.&nbsp; Patterns represent proven designs and their usage promotes quality and
+ consistency across the design.
</p></keyConsiderations>
<sections xmi:id="_4Z7WYKuKEdmhFZtkg1nakg" name="Understand requirement details" guid="_4Z7WYKuKEdmhFZtkg1nakg">
<sectionDescription><p>
- Examine the relevant&nbsp;<a class="elementLink" href="./../../core.tech.slot.base/workproducts/technical_specification_slot_2812F7EF.html" guid="_i3vkoLS-EduDY8LNbMCDBA">[Technical Specification]</a>&nbsp;to understand the scope of the design task and the
- expectations on the <a class="elementLink" href="./../../practice.tech.evolutionary_design.base/workproducts/design_D677D182.html" guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a>. Work with the Stakeholder and Analyst to clarify ambiguous or missing
+ Examine the relevant&nbsp;<a class="elementLink"
+ href="./../../core.tech.slot.base/workproducts/technical_specification_slot_2812F7EF.html"
+ guid="_i3vkoLS-EduDY8LNbMCDBA">[Technical Specification]</a>&nbsp;to understand the scope of the design task and the
+ expectations on the <a class="elementLink"
+ href="./../../practice.tech.evolutionary_design.base/workproducts/design_D677D182.html"
+ guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a>. Work with the Stakeholder and Analyst to clarify ambiguous or missing
information.
</p>
<p>
@@ -66,7 +72,10 @@
</sections>
<sections xmi:id="_Ci7aYFixEdusJoWkvSRO9Q" name="Understand the architecture" guid="_Ci7aYFixEdusJoWkvSRO9Q">
<sectionDescription><p>
- Review the Architecture Notebook to identify changes and additions to the architecture. See&nbsp;<a class="elementLinkWithType" href="./../../practice.tech.evolutionary_design.base/guidances/guidelines/evolve_the_design_3C9D6965.html" guid="_C4U9QPTeEduDKIuqTXQ8SA">Guideline: Evolve the Design</a>&nbsp;for more information. Work with the architect if
+ Review the Architecture Notebook to identify changes and additions to the architecture. See&nbsp;<a
+ class="elementLinkWithType"
+ href="./../../practice.tech.evolutionary_design.base/guidances/guidelines/evolve_the_design_3C9D6965.html"
+ guid="_C4U9QPTeEduDKIuqTXQ8SA">Guideline: Evolve the Design</a>&nbsp;for more information. Work with the architect if
there is any uncertainty on the understanding of relevant parts of the architecture or of the conformance of the design
strategy.
</p>
@@ -78,8 +87,12 @@
<sectionDescription><p>
Identify the elements that collaborate together to provide the required behavior. This can start with the key
abstractions identified in the Architecture Notebook, design, domain analysis, and classical analysis of the
- requirements (noun filtering) to derive the elements that would be required to fulfill them. The <a class="elementLink" href="./../../core.tech.common.extend_supp/guidances/guidelines/entity_control_boundary_pattern_C4047897.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a> provides a good start for identifying elements. Also
- see <a class="elementLinkWithType" href="./../../practice.tech.evolutionary_design.base/guidances/guidelines/analyze_the_design_4C4750C0.html" guid="__MnggPTdEduDKIuqTXQ8SA">Guideline: Analyze the Design</a>.
+ requirements (noun filtering) to derive the elements that would be required to fulfill them. The <a class="elementLink"
+ href="./../../core.tech.common.extend_supp/guidances/guidelines/entity_control_boundary_pattern_C4047897.html"
+ guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a> provides a good start for identifying elements. Also
+ see <a class="elementLinkWithType"
+ href="./../../practice.tech.evolutionary_design.base/guidances/guidelines/analyze_the_design_4C4750C0.html"
+ guid="__MnggPTdEduDKIuqTXQ8SA">Guideline: Analyze the Design</a>.
</p>
<p>
Existing elements of the design should be examined to see if they should participate in the collaboration. It is a
@@ -119,11 +132,16 @@
</p>
<p>
Evolve the design by examining recent changes in the larger context of the design and determine if refactoring and
- redesigning techniques will improve the robustness, flexibility, and understandability of the design. See&nbsp;<a class="elementLinkWithType" href="./../../practice.tech.evolutionary_design.base/guidances/guidelines/evolve_the_design_3C9D6965.html" guid="_C4U9QPTeEduDKIuqTXQ8SA">Guideline: Evolve the Design</a> for guidance specific design decisions and on making
+ redesigning techniques will improve the robustness, flexibility, and understandability of the design. See&nbsp;<a
+ class="elementLinkWithType"
+ href="./../../practice.tech.evolutionary_design.base/guidances/guidelines/evolve_the_design_3C9D6965.html"
+ guid="_C4U9QPTeEduDKIuqTXQ8SA">Guideline: Evolve the Design</a> for guidance specific design decisions and on making
design improvements just when they're needed.
</p>
<p>
- Incorporate <a class="elementLink" href="./../../core.tech.common.extend_supp/guidances/concepts/arch_mechanism_2932DFB6.html" guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanisms</a>s from the architecture. Apply consistent structure of the
+ Incorporate <a class="elementLink"
+ href="./../../core.tech.common.extend_supp/guidances/concepts/arch_mechanism_2932DFB6.html"
+ guid="_mzxI0A4LEduibvKwrGxWxA">Architectural Mechanism</a>s from the architecture. Apply consistent structure of the
elements and organization of the behavior as in other areas of the design and use patterns identified in the
architecture.
</p></sectionDescription>
@@ -200,11 +218,17 @@
actively participating in the design effort itself. If design flaws are identified, improve the design.
</p>
<p>
- See <a class="elementLinkWithType" href="./../../practice.tech.evolutionary_design.base/guidances/concepts/design_E36137FA.html" guid="_bFjlAPTYEduDKIuqTXQ8SA">Concept: Design</a>, <a class="elementLinkWithType" href="./../../practice.tech.evolutionary_design.base/guidances/guidelines/analyze_the_design_4C4750C0.html" guid="__MnggPTdEduDKIuqTXQ8SA">Guideline: Analyze the Design</a>, and <a class="elementLinkWithType" href="./../../practice.tech.evolutionary_design.base/guidances/guidelines/evolve_the_design_3C9D6965.html" guid="_C4U9QPTeEduDKIuqTXQ8SA">Guideline: Evolve the Design</a>&nbsp;for more information.
+ See <a class="elementLinkWithType"
+ href="./../../practice.tech.evolutionary_design.base/guidances/concepts/design_E36137FA.html"
+ guid="_bFjlAPTYEduDKIuqTXQ8SA">Concept: Design</a>, <a class="elementLinkWithType"
+ href="./../../practice.tech.evolutionary_design.base/guidances/guidelines/analyze_the_design_4C4750C0.html"
+ guid="__MnggPTdEduDKIuqTXQ8SA">Guideline: Analyze the Design</a>, and <a class="elementLinkWithType"
+ href="./../../practice.tech.evolutionary_design.base/guidances/guidelines/evolve_the_design_3C9D6965.html"
+ guid="_C4U9QPTeEduDKIuqTXQ8SA">Guideline: Evolve the Design</a>&nbsp;for more information.
</p></sectionDescription>
</sections>
- <purpose><p>
- The purpose of&nbsp;this&nbsp;task&nbsp;is to describe the&nbsp;elements of the system so that they support the
- required behavior, are of high quality, and fit within the architecture.
+ <purpose><p>
+ The purpose of&nbsp;this&nbsp;task&nbsp;is to describe the&nbsp;elements of the system so that they support the
+ required behavior, are of high quality, and fit within the architecture.
</p></purpose>
</org.eclipse.epf.uma:TaskDescription>
diff --git a/epf_prac_151/practice.tech.evolutionary_design.base/workproducts/design.xmi b/epf_prac_151/practice.tech.evolutionary_design.base/workproducts/design.xmi
index cc85d37..aeb823f 100644
--- a/epf_prac_151/practice.tech.evolutionary_design.base/workproducts/design.xmi
+++ b/epf_prac_151/practice.tech.evolutionary_design.base/workproducts/design.xmi
@@ -1,19 +1,19 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ArtifactDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_zxB-QKYcEdmvhNXG0Oc2uA" name="design,_0WuL8slgEdmt3adZL5Dmdw" guid="_zxB-QKYcEdmvhNXG0Oc2uA" changeDate="2008-08-15T00:29:20.000-0700" version="1.0.0">
- <mainDescription><p>
- This product can describe multiple static and dynamic views of the system for examination. Although various views may
- focus on divergent, seemingly independent issues of how the system will be put together and work, they should fit
- together without contradiction.
-</p>
-<p>
- It describes the elements that will make up the implemented system. It communicates abstractions of particular portions
- of the implementation and can describe an&nbsp;encapsulated subsystem, a high-level analysis of the system, a view of
- the system in only one context, or other perspectives that explain a solution to a specific problem that needs to be
- communicated.
+ <mainDescription><p>
+ This product can describe multiple static and dynamic views of the system for examination. Although various views may
+ focus on divergent, seemingly independent issues of how the system will be put together and work, they should fit
+ together without contradiction.
+</p>
+<p>
+ It describes the elements that will make up the implemented system. It communicates abstractions of particular portions
+ of the implementation and can describe an&nbsp;encapsulated subsystem, a high-level analysis of the system, a view of
+ the system in only one context, or other perspectives that explain a solution to a specific problem that needs to be
+ communicated.
</p></mainDescription>
- <purpose><p>
- &nbsp;Describe the&nbsp;elements of the system&nbsp;so&nbsp;they can be examined and understood in ways
- not&nbsp;possible by reading the source code.
+ <purpose><p>
+ &nbsp;Describe the&nbsp;elements of the system&nbsp;so&nbsp;they can be examined and understood in ways
+ not&nbsp;possible by reading the source code.
</p></purpose>
<impactOfNotHaving><p>
Implementation will proceed with fine-grained, inconsistent tactical decisions that lead to poor-quality software.
diff --git a/epf_prac_151/practice.tech.shared_vision.base/guidances/roadmaps/how_to_adopt.xmi b/epf_prac_151/practice.tech.shared_vision.base/guidances/roadmaps/how_to_adopt.xmi
index a2e701f..87e8b91 100644
--- a/epf_prac_151/practice.tech.shared_vision.base/guidances/roadmaps/how_to_adopt.xmi
+++ b/epf_prac_151/practice.tech.shared_vision.base/guidances/roadmaps/how_to_adopt.xmi
@@ -1,63 +1,63 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-G9wByhMaPQHqKvp12aZFEA" name="how_to_adopt,_TcmHIDzQEd2XwI9llpWEBA" guid="-G9wByhMaPQHqKvp12aZFEA" changeDate="2009-07-20T05:21:44.000-0700" version="7.5.0">
- <mainDescription><h3>
- Getting started
-</h3>
-<p>
- Creating a shared vision involves understanding and agreeing on the fundamental "what" and "why" of the product under
- development. This ensures that stakeholders and the development team have a common understanding of the problem to be
- solved, and understand the stakeholders' needs.
-</p>
-<p>
- Begin by reviewing the reference material associated with this practice to better understand the intent of the
- practice. Review the template for the <a class="elementLink"
- href="./../../../core.tech.common.extend_supp/workproducts/vision_2E71B03C.html"
- guid="_0WVxcMlgEdmt3adZL5Dmdw">Vision</a> to understand the information that it captures. Tailor the template for the
- specific needs of the project. Review the <a class="elementLink"
- href="./../../../practice.tech.shared_vision.base/tasks/develop_technical_vision_9D36CF2F.html"
- guid="_0fOAoMlgEdmt3adZL5Dmdw">Develop Technical Vision</a> task to understand what needs to be performed to capture
- and communicate the vision. Review the guidelines on requirements gathering techniques and requirements reviews
- associated with the Develop Technical Vision task, and select the appropriate technique(s) for the project. Educate the
- development team and relevant stakeholders on the purpose of this practice, and get buy-in on the techniques that will
- be used to establish and maintain a shared vision.
-</p>
-<p>
- This practice is related to many other useful practices. For example:
-</p>
-<ul>
- <li>
- Requirements practices: the vision is one of the outcomes of stakeholder requests elicitation. It is also the
- primary input for developing more fine-grained technical requirements. Stakeholders and the development team use
- the vision to provide the context and high-level objectives for the detailed technical requirements.
- </li>
- <li>
- Architecture practices: the vision outlines the high-level objectives and constraints for the system that inform
- architectural design decisions.
- </li>
- <li>
- Project management practices: the vision defines the scope and constraints of the project that are the basis for
- work prioritization and initial estimates of effort. The value delivered by the team at each milestone must align
- with stakeholders' expectations, expressed by the project vision.
- </li>
-</ul>
-<h3>
- Common pitfalls
-</h3>
-<p>
- <b>Rushing into a solution before the problem is understood.</b> The result is typically a system that fails to solve
- stakeholder problems and satisfy stakeholder needs. Avoid design while capturing the vision. Focus on the "what" and
- "why" of the product, rather than detailing the solution. Detailed technical requirements will be developed later, in
- conjunction with architectural design and trade-off analysis.
-</p>
-<p>
- <b>Failure to gain agreement on the problem to be solved.</b> Make sure that you have identified all stakeholders,
- captured their needs and wishes, and obtained agreement on the problem to be solved and associated constraints. Missing
- a critical stakeholder can result in significant re-work later.
-</p>
-<p>
- <b>Failure to manage scope.</b> Rome was not built in a day (or in a single project). Make sure that you capture
- stakeholder needs and features, and prioritize them to deliver as much value as early as possible. If the estimated
- effort is too great to commit to for a single external release, divide and conquer. The product vision may span more
- than one release of the product, providing a roadmap for future work, as well as work planned for the current project.
+ <mainDescription><h3>
+ Getting started&nbsp;
+</h3>
+<p>
+ Creating a shared vision involves understanding and agreeing on the fundamental "what" and "why" of the product under
+ development. This ensures that stakeholders and the development team have a common understanding of the problem to be
+ solved, and understand the stakeholders' needs.
+</p>
+<p>
+ Begin by reviewing the reference material associated with this practice to better understand the intent of the
+ practice. Review the template for the <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/workproducts/vision_2E71B03C.html"
+ guid="_0WVxcMlgEdmt3adZL5Dmdw">Vision</a> to understand the information that it captures. Tailor the template for the
+ specific needs of the project. Review the <a class="elementLink"
+ href="./../../../practice.tech.shared_vision.base/tasks/develop_technical_vision_9D36CF2F.html"
+ guid="_0fOAoMlgEdmt3adZL5Dmdw">Develop Technical Vision</a> task to understand what needs to be performed to capture
+ and communicate the vision. Review the guidelines on requirements gathering techniques and requirements reviews
+ associated with the Develop Technical Vision task, and select the appropriate technique(s) for the project. Educate the
+ development team and relevant stakeholders on the purpose of this practice, and get buy-in on the techniques that will
+ be used to establish and maintain a shared vision.
+</p>
+<p>
+ This practice is related to many other useful practices. For example:
+</p>
+<ul>
+ <li>
+ Requirements practices: the vision is one of the outcomes of stakeholder requests elicitation. It is also the
+ primary input for developing more fine-grained technical requirements. Stakeholders and the development team use
+ the vision to provide the context and high-level objectives for the detailed technical requirements.
+ </li>
+ <li>
+ Architecture practices: the vision outlines the high-level objectives and constraints for the system that inform
+ architectural design decisions.
+ </li>
+ <li>
+ Project management practices: the vision defines the scope and constraints of the project that are the basis for
+ work prioritization and initial estimates of effort. The value delivered by the team at each milestone must align
+ with stakeholders' expectations, expressed by the project vision.
+ </li>
+</ul>
+<h3>
+ Common pitfalls
+</h3>
+<p>
+ <b>Rushing into a solution before the problem is understood.</b> The result is typically a system that fails to solve
+ stakeholder problems and satisfy stakeholder needs. Avoid design while capturing the vision. Focus on the "what" and
+ "why" of the product, rather than detailing the solution. Detailed technical requirements will be developed later, in
+ conjunction with architectural design and trade-off analysis.
+</p>
+<p>
+ <b>Failure to gain agreement on the problem to be solved.</b> Make sure that you have identified all stakeholders,
+ captured their needs and wishes, and obtained agreement on the problem to be solved and associated constraints. Missing
+ a critical stakeholder can result in significant re-work later.
+</p>
+<p>
+ <b>Failure to manage scope.</b> Rome was not built in a day (or in a single project). Make sure that you capture
+ stakeholder needs and features, and prioritize them to deliver as much value as early as possible. If the estimated
+ effort is too great to commit to for a single external release, divide and conquer. The product vision may span more
+ than one release of the product, providing a roadmap for future work, as well as work planned for the current project.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.shared_vision.base/guidances/termdefinitions/feature.xmi b/epf_prac_151/practice.tech.shared_vision.base/guidances/termdefinitions/feature.xmi
index 5ad6bb5..4aa4f40 100644
--- a/epf_prac_151/practice.tech.shared_vision.base/guidances/termdefinitions/feature.xmi
+++ b/epf_prac_151/practice.tech.shared_vision.base/guidances/termdefinitions/feature.xmi
@@ -1,4 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-qpBnpWqiD7gjT08LjTMbsQ" name="new_term_definition,_PgYREAeYEduWycDgioo5rg" guid="-qpBnpWqiD7gjT08LjTMbsQ" changeDate="2007-11-09T09:51:42.000-0800" version="7.1.0">
- <mainDescription>An externally observable service provided by the system that directly fulfills a <a class="elementLink" href="./../../../practice.tech.shared_vision.base/guidances/termdefinitions/stakeholder_need_F8F672BB.html" guid="_WUiFcAeYEduWycDgioo5rg">stakeholder need</a>.</mainDescription>
+ <mainDescription>An externally observable service provided by the system that directly fulfills a <a class="elementLink"
+href="./../../../practice.tech.shared_vision.base/guidances/termdefinitions/stakeholder_need_F8F672BB.html"
+guid="_WUiFcAeYEduWycDgioo5rg">stakeholder need</a>.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.shared_vision.base/tasks/develop_technical_vision.xmi b/epf_prac_151/practice.tech.shared_vision.base/tasks/develop_technical_vision.xmi
index 0760e61..0f3d188 100644
--- a/epf_prac_151/practice.tech.shared_vision.base/tasks/develop_technical_vision.xmi
+++ b/epf_prac_151/practice.tech.shared_vision.base/tasks/develop_technical_vision.xmi
@@ -1,14 +1,14 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:TaskDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_5rJ78Lj3Edmy88CC3LfB_w" name="develop_vision,_0fOAoMlgEdmt3adZL5Dmdw" guid="_5rJ78Lj3Edmy88CC3LfB_w" changeDate="2007-12-18T01:14:14.000-0800" changeDescription="Review comments:|1. Conflicts with other GBS practices and work products|-. Removed "Define the system boundaries" - need to figure out how to get it |back in.|Removed from step 1:|Develop profiles of potential (or actual) users of the system that map to the |roles of human actors of the system that you are developing.|-. Removed "Identify constraints on the system"||Need to determine how to make this work with GS method's practices for these removed steps.|Some options:|- OpenUP could be doing something simpler than the GS Method approach that is ok to do as well (need to convince GBS)|- OpenUP could have a practice for doing these additional things that isn't part of the "basic vision", but can be added in by contributing steps|- OpenUP could go with a more basic practice for defining a vision, and not do these aspects|- The steps could be written as "optional things to do if you don't have a separate practice".||I like the first option best.||2. Removed "Update the vision" which occurs throughout the task.||3. Removed all the links to work items - we shoudn't assume it is there.||4. Removed hyperlinks to attached guidance. We need to make sure this convention is followed elsewhere.||5. Removed links to OpenUP-only guidance, such as "principles for collaborative development". Makes sense, but we need to make sure this convention is followed elsewhere." version="1.0.0">
- <keyConsiderations><p>
- Use-case modeling&nbsp;is one technique that can prove useful in defining the system boundaries and system behavior.
+ <keyConsiderations><p>
+ Use-case modeling&nbsp;is one technique that can prove useful in defining the system boundaries and system behavior.
</p></keyConsiderations>
- <sections xmi:id="_ceK-UED2EdyoefaQkqWN_Q" name="Identify Stakeholders " guid="_ceK-UED2EdyoefaQkqWN_Q">
+ <sections xmi:id="_ceK-UED2EdyoefaQkqWN_Q" name="Identify Stakeholders" guid="_ceK-UED2EdyoefaQkqWN_Q">
<sectionDescription>Identify the stakeholders: decision-makers, customers, potential users, partners, domain experts, industry analysts and
other interested parties. Briefly describe what stakeholders do and what their responsibilities are with regard to the
system being developed.</sectionDescription>
</sections>
- <sections xmi:id="_h7AacED2EdyoefaQkqWN_Q" name="Gain agreement on the problem to be solved " guid="_h7AacED2EdyoefaQkqWN_Q">
+ <sections xmi:id="_h7AacED2EdyoefaQkqWN_Q" name="Gain agreement on the problem to be solved" guid="_h7AacED2EdyoefaQkqWN_Q">
<sectionDescription><p>
Avoid rushing into defining the solution. First, gain agreement on the definition of the problem by asking the
stakeholders what they see as the problem. Then search for root causes, or the "problem behind the problem".
@@ -16,7 +16,7 @@
you distinguish solutions and answers from problems and questions.
</p></sectionDescription>
</sections>
- <sections xmi:id="_vbkccED2EdyoefaQkqWN_Q" name="Gather stakeholder requests " guid="_vbkccED2EdyoefaQkqWN_Q">
+ <sections xmi:id="_vbkccED2EdyoefaQkqWN_Q" name="Gather stakeholder requests" guid="_vbkccED2EdyoefaQkqWN_Q">
<sectionDescription><p>
Use the most appropriate technique to help you on requirements gathering.&nbsp;Each technique is applicable in a
particular situation or to a certain type of stakeholder.
@@ -36,12 +36,17 @@
Analyze the scope in terms of processes, organizations, and systems.
</p></sectionDescription>
</sections>
- <sections xmi:id="_6uIV0ED2EdyoefaQkqWN_Q" name="Define features of the system " guid="_6uIV0ED2EdyoefaQkqWN_Q">
+ <sections xmi:id="_6uIV0ED2EdyoefaQkqWN_Q" name="Define features of the system" guid="_6uIV0ED2EdyoefaQkqWN_Q">
<sectionDescription><p>
- Work with stakeholders to capture&nbsp;a list&nbsp;of&nbsp;<a class="elementlinkwithusertext" href="./../../practice.tech.shared_vision.base/guidances/termdefinitions/feature_4ED64AEE.html" guid="_PgYREAeYEduWycDgioo5rg">features</a> that stakeholders want in the system, briefly describing them and giving <a class="elementLinkWithUserText" href="./../../core.tech.common.extend_supp/guidances/concepts/requirement_attributes_4AC73153.html" guid="_VQ268O0KEdqHTdbLTmC5IQ">attributes</a> to help define their general status and priority in the project.
+ Work with stakeholders to capture&nbsp;a list&nbsp;of&nbsp;<a class="elementlinkwithusertext"
+ href="./../../practice.tech.shared_vision.base/guidances/termdefinitions/feature_4ED64AEE.html"
+ guid="_PgYREAeYEduWycDgioo5rg">features</a> that stakeholders want in the system, briefly describing them and giving <a
+ class="elementLinkWithUserText"
+ href="./../../core.tech.common.extend_supp/guidances/concepts/requirement_attributes_4AC73153.html"
+ guid="_VQ268O0KEdqHTdbLTmC5IQ">attributes</a> to help define their general status and priority in the project.
</p></sectionDescription>
</sections>
- <sections xmi:id="__nDMkED2EdyoefaQkqWN_Q" name="Achieve concurrence " guid="__nDMkED2EdyoefaQkqWN_Q">
+ <sections xmi:id="__nDMkED2EdyoefaQkqWN_Q" name="Achieve concurrence" guid="__nDMkED2EdyoefaQkqWN_Q">
<sectionDescription>Conduct an effective requirements&nbsp;review&nbsp;with stakeholders and the development team&nbsp;to ensure agreement on
the project vision, assess quality, and identify required changes.</sectionDescription>
</sections>
@@ -51,7 +56,7 @@
business and technical terms.&nbsp; Work with stakeholders to continually expand and refine the glossary throughout the
project lifecycle.</sectionDescription>
</sections>
- <purpose>The solution is proposed for a problem that everybody agrees on. Stakeholders collaborate with the development team to
-express and document their problems, needs, and potential features for the system to be, so the project team can better
+ <purpose>The solution is proposed for a problem that everybody agrees on. Stakeholders collaborate with the development team to
+express and document their problems, needs, and potential features for the system to be, so the project team can better
understand what has to be done.</purpose>
</org.eclipse.epf.uma:TaskDescription>
diff --git a/epf_prac_151/practice.tech.test_driven_development.base/guidances/concepts/collective_code_ownership.xmi b/epf_prac_151/practice.tech.test_driven_development.base/guidances/concepts/collective_code_ownership.xmi
index faacdc8..3621cb4 100644
--- a/epf_prac_151/practice.tech.test_driven_development.base/guidances/concepts/collective_code_ownership.xmi
+++ b/epf_prac_151/practice.tech.test_driven_development.base/guidances/concepts/collective_code_ownership.xmi
@@ -1,20 +1,22 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-ykYi7xrRdC5O9qFXhU3doA" name=",_xYMPoCZnEdyUaK463Ozu5g" guid="-ykYi7xrRdC5O9qFXhU3doA" changeDate="2008-08-06T03:25:38.000-0700" version="7.2.0">
- <mainDescription><p>
- With collective code ownership, any member of the team can change any piece of code in the system at any time. There
- should not be a policy or norm that one person is responsible for one part of the code base so that others are not
- allowed to modify it.
-</p>
-<p>
- Fostering an environment where any developer might be expected to modify any piece of code to implement some
- functionality, fix a bug, or improve the solution leads to a more collaborative team experience. Developers will become
- familiar with more of the code and benefit from the experience of others. It drives a high-performance team and removes
- hurdles so that changes can be made by those who need them when they need them. No one person can become the gatekeeper
- or bottleneck for changes to some subsystem within the code base.
-</p>
-<p>
- Collective code ownership works best if there are coding standards to prevent one developer's style from being
- significantly different than another's (see <a class="elementLinkWithType" href="./../../../core.tech.common.extend_supp/guidances/concepts/coding_standard_1FF691E0.html" guid="_aGqAsJ01EdyQ3oTO93enUw">Concept: Coding Standard</a>). It is also critical that there are developer tests in
- place to ensure that work on a unit of code does not break it.
+ <mainDescription><p>
+ With collective code ownership, any member of the team can change any piece of code in the system at any time. There
+ should not be a policy or norm that one person is responsible for one part of the code base so that others are not
+ allowed to modify it.
+</p>
+<p>
+ Fostering an environment where any developer might be expected to modify any piece of code to implement some
+ functionality, fix a bug, or improve the solution leads to a more collaborative team experience. Developers will become
+ familiar with more of the code and benefit from the experience of others. It drives a high-performance team and removes
+ hurdles so that changes can be made by those who need them when they need them. No one person can become the gatekeeper
+ or bottleneck for changes to some subsystem within the code base.
+</p>
+<p>
+ Collective code ownership works best if there are coding standards to prevent one developer's style from being
+ significantly different than another's (see <a class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/coding_standard_1FF691E0.html"
+ guid="_aGqAsJ01EdyQ3oTO93enUw">Concept: Coding Standard</a>). It is also critical that there are developer tests in
+ place to ensure that work on a unit of code does not break it.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.test_driven_development.base/guidances/guidelines/developer_testing.tdd.xmi b/epf_prac_151/practice.tech.test_driven_development.base/guidances/guidelines/developer_testing.tdd.xmi
index db99145..023d278 100644
--- a/epf_prac_151/practice.tech.test_driven_development.base/guidances/guidelines/developer_testing.tdd.xmi
+++ b/epf_prac_151/practice.tech.test_driven_development.base/guidances/guidelines/developer_testing.tdd.xmi
@@ -1,12 +1,14 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-7ketKzGlDB1TVwsYHvVLfg" name="new_guideline,_T_ylcCnlEd2W590fuUWNqw" guid="-7ketKzGlDB1TVwsYHvVLfg" changeDate="2008-05-24T04:02:36.000-0700" version="7.5.0">
- <mainDescription><h3>
- Write the tests first
-</h3>
-<p>
- Writing the tests after the code is a chore. The urge is to rush through it, to finish up and move on. Writing tests
- before the code makes testing part of a positive feedback loop. As you implement more code, you see more tests passing
- until finally all the tests pass and you're done. People who write tests first seem to be more successful, and it takes
- no more time. For more on putting tests first, see <a class="elementLinkWithType" href="./../../../practice.tech.test_driven_development.base/guidances/guidelines/test_driven_development_F581182D.html" guid="_5s_DUJ03EdyQ3oTO93enUw">Guideline: Test Driven Development</a>.
+ <mainDescription><h3>
+ Write the tests first
+</h3>
+<p>
+ Writing the tests after the code is a chore. The urge is to rush through it, to finish up and move on. Writing tests
+ before the code makes testing part of a positive feedback loop. As you implement more code, you see more tests passing
+ until finally all the tests pass and you're done. People who write tests first seem to be more successful, and it takes
+ no more time. For more on putting tests first, see <a class="elementLinkWithType"
+ href="./../../../practice.tech.test_driven_development.base/guidances/guidelines/test_driven_development_F581182D.html"
+ guid="_5s_DUJ03EdyQ3oTO93enUw">Guideline: Test Driven Development</a>.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.test_driven_development.base/guidances/guidelines/test_driven_development.xmi b/epf_prac_151/practice.tech.test_driven_development.base/guidances/guidelines/test_driven_development.xmi
index 151374e..049918d 100644
--- a/epf_prac_151/practice.tech.test_driven_development.base/guidances/guidelines/test_driven_development.xmi
+++ b/epf_prac_151/practice.tech.test_driven_development.base/guidances/guidelines/test_driven_development.xmi
@@ -1,65 +1,65 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-mItcFA1WMTAyJvkqMrXuMQ" name="new_guideline,_5s_DUJ03EdyQ3oTO93enUw" guid="-mItcFA1WMTAyJvkqMrXuMQ" changeDate="2008-10-14T10:03:34.000-0700" version="7.2.0">
- <mainDescription><h3>
- Introduction
-</h3>
-<p>
- With Test Driven Development (TDD) you do detailed design in a just-in-time (JIT) manner via writing a single test
- before writing just enough production code to fulfill that test. When you have new functionality to add to your system,
- perform the following steps:
-</p>
-<ol>
- <li>
- <strong>Quickly add a developer test</strong>. You need just enough implementation code to fail.&nbsp; For example,
- a new method about to be added to a class could be created that just throws a fatal exception.
- </li>
- <li>
- <strong>Run your tests</strong>. You will typically run the complete test suite, although for sake of speed you may
- decide to run only a subset. The goal is to ensure that the new test does in fact fail.
- </li>
- <li>
- <strong>Update your production code</strong>. The goal is to add just enough functionality so that&nbsp;the code
- passes the new test.&nbsp;
- </li>
- <li>
- <strong>Run your test suite again</strong>. If the tests fail you need to update your functional code and retest.
- Once the tests pass, start over.
- </li>
-</ol><br />
-<p>
- <img height="600" alt="Test First Design Flow" src="resources/test_first_design.jpg" width="294" />
-</p>
-<h4>
- Why TDD?
-</h4>
-<p>
- A significant advantage of TDD is that it enables you to take small steps when writing software, which is not only
- safer it is also far more productive than writing code in large steps. For example, assume you add some new functional
- code, compile, and test it. Chances are pretty good that your tests will be broken by defects that exist in the new
- code. It is much easier to find, and then fix, those defects if you've written five new lines of code than fifty lines.
- The implication is that the faster your compiler and regression test suite, the more attractive it is to proceed in
- smaller and smaller steps.
-</p>
-<p>
- There are other common testing strategies (listed here in order of effectiveness).
-</p>
-<ol>
- <li>
- <strong>Write several tests first</strong>. This is a variant of TDD where you write more than one test before
- writing just enough production code to fulfill those tests. The advantage is that you don't need to build your
- system as often, potentially saving time. It has the disadvantage that you will write more production code at once,
- increasing the difficulty of finding the cause of new bugs.
- </li>
- <li>
- <strong>Test after the fact</strong>. With this approach you write some production code then you write enough
- testing code to validate it. This has the advantage that you're at least still validating the code but has the
- disadvantage that you lose the design benefit inherent in writing the testing code first.
- </li>
-</ol>
-<p>
- An underlying assumption of TFD is that a unit-testing framework is available. Agile software developers often use the
- xUnit family of open source tools, such as <a href="http://www.junit.org/"><strong><u><font
- color="#0000ff">JUnit</font></u></strong></a> or <a href="http://www.vbunit.org/"><strong><u><font
- color="#0000ff">VBUnit</font></u></strong></a>, although commercial tools are also viable options.
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ With Test Driven Development (TDD) you do detailed design in a just-in-time (JIT) manner via writing a single test
+ before writing just enough production code to fulfill that test. When you have new functionality to add to your system,
+ perform the following steps:
+</p>
+<ol>
+ <li>
+ <strong>Quickly add a developer test</strong>. You need just enough implementation code to fail.&nbsp; For example,
+ a new method about to be added to a class could be created that just throws a fatal exception.
+ </li>
+ <li>
+ <strong>Run your tests</strong>. You will typically run the complete test suite, although for sake of speed you may
+ decide to run only a subset. The goal is to ensure that the new test does in fact fail.
+ </li>
+ <li>
+ <strong>Update your production code</strong>. The goal is to add just enough functionality so that&nbsp;the code
+ passes the new test.&nbsp;
+ </li>
+ <li>
+ <strong>Run your test suite again</strong>. If the tests fail you need to update your functional code and retest.
+ Once the tests pass, start over.
+ </li>
+</ol><br />
+<p>
+ <img height="600" alt="Test First Design Flow" src="resources/test_first_design.jpg" width="294" />
+</p>
+<h4>
+ Why TDD?
+</h4>
+<p>
+ A significant advantage of TDD is that it enables you to take small steps when writing software, which is not only
+ safer it is also far more productive than writing code in large steps. For example, assume you add some new functional
+ code, compile, and test it. Chances are pretty good that your tests will be broken by defects that exist in the new
+ code. It is much easier to find, and then fix, those defects if you've written five new lines of code than fifty lines.
+ The implication is that the faster your compiler and regression test suite, the more attractive it is to proceed in
+ smaller and smaller steps.
+</p>
+<p>
+ There are other common testing strategies (listed here in order of effectiveness).
+</p>
+<ol>
+ <li>
+ <strong>Write several tests first</strong>. This is a variant of TDD where you write more than one test before
+ writing just enough production code to fulfill those tests. The advantage is that you don't need to build your
+ system as often, potentially saving time. It has the disadvantage that you will write more production code at once,
+ increasing the difficulty of finding the cause of new bugs.
+ </li>
+ <li>
+ <strong>Test after the fact</strong>. With this approach you write some production code then you write enough
+ testing code to validate it. This has the advantage that you're at least still validating the code but has the
+ disadvantage that you lose the design benefit inherent in writing the testing code first.
+ </li>
+</ol>
+<p>
+ An underlying assumption of TFD is that a unit-testing framework is available. Agile software developers often use the
+ xUnit family of open source tools, such as <a href="http://www.junit.org/"><strong><u><font
+ color="#0000ff">JUnit</font></u></strong></a> or <a href="http://www.vbunit.org/"><strong><u><font
+ color="#0000ff">VBUnit</font></u></strong></a>, although commercial tools are also viable options.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.test_driven_development.base/guidances/practices/test_driven_dev.xmi b/epf_prac_151/practice.tech.test_driven_development.base/guidances/practices/test_driven_dev.xmi
index 17503fb..f040c37 100644
--- a/epf_prac_151/practice.tech.test_driven_development.base/guidances/practices/test_driven_dev.xmi
+++ b/epf_prac_151/practice.tech.test_driven_development.base/guidances/practices/test_driven_dev.xmi
@@ -1,67 +1,70 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:PracticeDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-nV4dgKPmOiwZnl6nUoKqQw" name="new_practice,_FUDtMB4mEd2bS8fFOQ7WWA" guid="-nV4dgKPmOiwZnl6nUoKqQw" changeDate="2008-08-14T03:23:09.000-0700" version="7.5.0">
- <mainDescription><p>
- Test driven development (TDD) is the practice of writing developer tests and implementation code concurrently
- and at a very fine level of granularity.
-</p>
-<p>
- In test driven design, the developer first writes a small test to validate a small change, runs the test to
- ensure that it fails (a sanity check), and then writes just enough implementation code to make that developer test
- run successfully. This cycle is short and it rarely goes beyond 10 minutes. In each cycle, the tests come first. Once a
- test is done, the developer goes on to the next test until there are no more tests to be written for the
- implementation of the work item currently under development.
-</p>
-<p>
- <img alt="file:///C:/Documents%20and%20Settings/Administrator/Desktop/tdd_flow.jpg" src="resources/tdd_flow.jpg" />
-</p>
-<p>
- The practice of test driven development changes how the developer thinks. Tests are not written as an
- afterthought. Instead, developer tests are written as part of the everyday, every minute way of building software.
-</p>
-<p>
- What are the advantages of test driven design?
-</p>
-<ol>
- <li>
- Assumptions in the design are analyzed before the implementation code is written. To write developer tests, an
- examination must be made of the behavior of each piece of code to be written. Correct and incorrect behaviors must
- be defined. In a way, writing the tests before the code can be considered a version of detailed design.
- </li>
- <li>
- Code units designed for testability up front are cleaner and more loosely coupled.
- </li>
- <li>
- Errors are found earlier. Errors or gaps in the requirements and design are identified before coding begins,
- when it could be tempting to move ahead based on assumptions.
- </li>
- <li>
- A clearer collaboration strategy between the developer and others that might be responsible for the
- requirements, architecture, and design is put in place. During the creation of the tests, there must be a
- meeting of the minds as to what has been specified. After that, the implementation can carry on with
- confidence that there is a shared vision of what the code should do.
- </li>
- <li>
- There are unambiguous criteria for completion of the code. When the tests conclude successfully, the code is working as specified.
- Non-functional quality dimensions can be dealt with separately, but there is a clear moment when the code behaves
- correctly.
- </li>
- <li>
- The technique drives the developer to work in smaller increments with faster quality feedback. At any time, the
- developer is just one test away from having error-free code.
- </li>
- <li>
- There is a separation of concerns and effort between getting code working and improving the quality of the code
- that already runs correctly. Separating out these two areas of concern provides focus and time management support
- to a developer. In one pass over the implementation, the developer makes it pass the tests as simply as possible, and then in a
- subsequent pass, looks for areas to improve.
- </li>
-</ol>
-<p>
- See <a class="elementLink" href="./../../../practice.tech.test_driven_development.base/guidances/supportingmaterials/using_tdd_in_context_2ADBB50B.html" guid="_vLvAUGjFEd2PJ-nlV-86WA">Using TDD in context</a> for more information.
+ <mainDescription><p>
+ Test driven development (TDD) is the practice of writing developer tests and implementation code concurrently and at a
+ very fine level of granularity.
+</p>
+<p>
+ In test driven design, the developer first writes a small test to validate a small change, runs the test to ensure that
+ it fails (a sanity check), and then writes just enough implementation code to make that developer test run
+ successfully. This cycle is short and it rarely goes beyond 10 minutes. In each cycle, the tests come first. Once a
+ test is done, the developer goes on to the next test until there are no more tests to be written for the implementation
+ of the work item currently under development.
+</p>
+<p>
+ <img alt="file:///C:/Documents%20and%20Settings/Administrator/Desktop/tdd_flow.jpg" src="resources/tdd_flow.jpg" />
+</p>
+<p>
+ The practice of test driven development changes how the developer thinks. Tests are not written as an afterthought.
+ Instead, developer tests are written as part of the everyday, every minute way of building software.
+</p>
+<p>
+ What are the advantages of test driven design?
+</p>
+<ol>
+ <li>
+ Assumptions in the design are analyzed before the implementation code is written. To write developer tests, an
+ examination must be made of the behavior of each piece of code to be written. Correct and incorrect behaviors must
+ be defined. In a way, writing the tests before the code can be considered a version of detailed design.
+ </li>
+ <li>
+ Code units designed for testability up front are cleaner and more loosely coupled.
+ </li>
+ <li>
+ Errors are found earlier. Errors or gaps in the requirements and design are identified before coding begins, when
+ it could be tempting to move ahead based on assumptions.
+ </li>
+ <li>
+ A clearer collaboration strategy between the developer and others that might be responsible for the requirements,
+ architecture, and design is put in place. During the creation of the tests, there must be a meeting of the minds as
+ to what has been specified. After that, the implementation can carry on with confidence that there is a shared
+ vision of what the code should do.
+ </li>
+ <li>
+ There are unambiguous criteria for completion of the code. When the tests conclude successfully, the code is
+ working as specified. Non-functional quality dimensions can be dealt with separately, but there is a clear moment
+ when the code behaves correctly.
+ </li>
+ <li>
+ The technique drives the developer to work in smaller increments with faster quality feedback. At any time, the
+ developer is just one test away from having error-free code.
+ </li>
+ <li>
+ There is a separation of concerns and effort between getting code working and improving the quality of the code
+ that already runs correctly. Separating out these two areas of concern provides focus and time management support
+ to a developer. In one pass over the implementation, the developer makes it pass the tests as simply as possible,
+ and then in a subsequent pass, looks for areas to improve.
+ </li>
+</ol>
+<p>
+ See <a class="elementLink"
+ href="./../../../practice.tech.test_driven_development.base/guidances/supportingmaterials/using_tdd_in_context_2ADBB50B.html"
+ guid="_vLvAUGjFEd2PJ-nlV-86WA">Using TDD in context</a> for more information.
</p></mainDescription>
<additionalInfo><p>
- If you are just getting started with TDD or developer testing in general, you will need to know why developer testing is a
- good idea, and the basics of what makes good developer tests. A good starting place is this <a href="http://itc.conversationsnetwork.org/shows/detail301.html" target="_blank">Kent Beck presentation</a>. Kent Beck
+ If you are just getting started with TDD or developer testing in general, you will need to know why developer testing
+ is a good idea, and the basics of what makes good developer tests. A good starting place is this <a
+ href="http://itc.conversationsnetwork.org/shows/detail301.html" target="_blank">Kent Beck presentation</a>. Kent Beck
is the creator of Extreme Programming, which is where TDD was originally defined.
</p>
<p>
@@ -90,23 +93,32 @@
</li>
</ul>
<p>
- Once you are familiar with the basics of TDD, select various tasks to view more detail about what needs to be
- done to perform the task. If you will be creating a capability pattern or delivery process that includes TDD, see <a class="elementLink" href="./../../../practice.tech.test_driven_development.base/guidances/supportingmaterials/using_tdd_in_context_2ADBB50B.html" guid="_vLvAUGjFEd2PJ-nlV-86WA">Using TDD in context</a>. This shows one example of how TDD can be used in conjunction
+ Once you are familiar with the basics of TDD, select various tasks to view more detail about what needs to be done to
+ perform the task. If you will be creating a capability pattern or delivery process that includes TDD, see <a
+ class="elementLink"
+ href="./../../../practice.tech.test_driven_development.base/guidances/supportingmaterials/using_tdd_in_context_2ADBB50B.html"
+ guid="_vLvAUGjFEd2PJ-nlV-86WA">Using TDD in context</a>. This shows one example of how TDD can be used in conjunction
with other activities and capability patterns to create a pattern for developing software. This is only one possible
example: there are many was to use TDD with other development practices.
</p></additionalInfo>
<problem><p>
The test driven development practice reduces time to market by reducing the amount of time needed to integrate and
- stabilize builds. It improves productivity by finding and fixing errors close to the time that they are introduced. And it
- increases the overall quality of the software by guaranteeing that all new code has been tested, and all existing code has
- been regression tested, prior to check-in.
+ stabilize builds. It improves productivity by finding and fixing errors close to the time that they are introduced. And
+ it increases the overall quality of the software by guaranteeing that all new code has been tested, and all existing
+ code has been regression tested, prior to check-in.
</p>
<p>
- Developers use TDD to create the <a class="elementLink" href="./../../../core.tech.common.extend_supp/workproducts/implementation_AFFEFC46.html" guid="_JqYbgJ01EdyQ3oTO93enUw">Implementation</a> and the <a class="elementLink" href="./../../../core.tech.common.extend_supp/workproducts/developer_test_6A91CE05.html" guid="_kh9FcJ02EdyQ3oTO93enUw">Developer Test</a>s.
+ Developers use TDD to create the <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/workproducts/implementation_AFFEFC46.html"
+ guid="_JqYbgJ01EdyQ3oTO93enUw">Implementation</a> and the <a class="elementLink"
+ href="./../../../core.tech.common.extend_supp/workproducts/developer_test_6A91CE05.html"
+ guid="_kh9FcJ02EdyQ3oTO93enUw">Developer Test</a>s.
</p>
<p>
- See the <a class="elementLink" href="./../../../practice.tech.test_driven_development.base/guidances/roadmaps/adopt_tdd_practice_7D642D12.html" guid="_8yG48JRqEdyrdaw_xGakyw">How to Adopt the Test Driven Development Practice</a> for information on navigating
- the TDD Practice.
+ See the <a class="elementLink"
+ href="./../../../practice.tech.test_driven_development.base/guidances/roadmaps/adopt_tdd_practice_7D642D12.html"
+ guid="_8yG48JRqEdyrdaw_xGakyw">How to Adopt the Test Driven Development Practice</a> for information on navigating the
+ TDD Practice.
</p></problem>
<background><p>
TDD was originally part of Kent Beck's Extreme Programming process. It's now also used in many other Agile and
diff --git a/epf_prac_151/practice.tech.test_driven_development.base/guidances/roadmaps/adopt_tdd_practice.xmi b/epf_prac_151/practice.tech.test_driven_development.base/guidances/roadmaps/adopt_tdd_practice.xmi
index d13cbaf..aff0b95 100644
--- a/epf_prac_151/practice.tech.test_driven_development.base/guidances/roadmaps/adopt_tdd_practice.xmi
+++ b/epf_prac_151/practice.tech.test_driven_development.base/guidances/roadmaps/adopt_tdd_practice.xmi
@@ -1,130 +1,130 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-CGSI-WD83sE5swSmSDjAYA" name="adopt_tdd_practice,_8yG48JRqEdyrdaw_xGakyw" guid="-CGSI-WD83sE5swSmSDjAYA" authors="Jim Ruehlin" changeDate="2008-10-14T09:58:19.000-0700" version="7.2.0">
- <mainDescription><h3>
- Getting Started
-</h3>
-<p>
- If you have just installed the test driven development (TDD) practice, start by reviewing the <a
- class="elementLinkWithType"
- href="./../../../core.tech.common.extend_supp/guidances/concepts/developer_testing_FEBDAED6.html"
- guid="_ADwlAJRtEdyrdaw_xGakyw">Concept: Developer Testing</a>. These will introduce you to the basics of what you need
- to know about developer testing in the context of TDD. For more introductory information, read this <a
- href="http://www.agiledata.org/essays/tdd.html" target="_blank">Introduction to TDD</a>.
-</p>
-<p>
- If your organization has never done developer testing before, start your adoption by educating the members of the team.
- Use the resources below for educational and reference materials. Begin to track your performance immediately, because
- that will give you quick feedback on how rapidly the team is adopting TDD, even if it is a very low form of adoption at
- first.
-</p>
-<p>
- Tools are critical for creating and managing unit tests. Educate the team on using new tools, and discover which
- practices and features of the tools will work best in your environment.
-</p>
-<p>
- Specify modest, attainable goals when adopting TDD. For instance, instead of insisting that every code change must have
- a developer test starting now, it may be better to limit TDD practices to a single important implementation element.
- This will allow the team to come up to speed on tools and learn new development habits while minimizing the impact on
- the overall schedule. After the team has gained some comfort with the new way of doing things (usually a couple of
- weeks or a single iteration), your refined method for TDD can be applied to all new or changed code. Continue
- increasing the team's capabilities with TDD by introducing new tools, constraints, monitoring, or methods in modest,
- attainable increments. This also allows the team to experience success with new techniques, which usually leads to a
- team that embraces rather than resists change.
-</p>
-<p>
- Like all process changes, adopting TDD requires that team members change behaviors and develop new habits, such as
- writing code only when a test already exists to validate it. Developers will need the education provided by the links
- on this page, and the methods described in this practice, to develop these new behaviors. They will also need to have
- their new behaviors enforced by the team as a whole, and by management, until constantly writing tests while writing
- code is a habit. TDD is no different from other areas of process adoption. The managing body (bosses or the team) need
- to put as much effort into creating new behaviors as the individual developers do.
-</p>
-<p>
- <strong>TDD Adoption scenario</strong>
-</p>
-<p>
- Here is one possible scenario for adopting the TDD practice. You will want to add, change, or remove steps to design an
- adoption roadmap more suitable to your environment. Hiring a consultant experienced in TDD will also speed your
- adoption of the practice and help avoid common pitfalls.
-</p>
-<ol>
- <li>
- Educate the team on TDD. Use the presentations and articles referenced in this practice as a starting place. It
- would also be helpful for developers to attend a class on developer testing and TDD.
- </li>
- <li>
- Have the team review the material in this practice.
- </li>
- <li>
- Extend this practice to reflect any important constraints or requirements in your organization. For instance,
- indicate any extra information that may need to be described when checking in system or test code, link to any
- materials that describe internal tools that your team is required to use, or create a guideline describing how each
- test must be documented or structured to conform to corporate standards.
- </li>
- <li>
- Identify and prepare to collect the information or metrics that will tell you how well you are adopting this
- practice. Make sure that the metrics are easy to collect. Highly accurate metrics that are difficult to collect are
- often abandoned, so provide no value. Coarser measurements that are easy to collect usually provide sufficient
- information, and it is more likely that they will continue to be collected.
- </li>
- <li>
- Identify the initial, modest goals for your TDD adoption, such as "An average of 2 tests per method for
- implementation element X". The goal is to be successful at some incremental amount of adoption, not to adopt
- everything in a single event. Make success a regular habit.
- </li>
- <li>
- Select a critical system implementation element to start applying TDD on. Begin using new TDD tools and techniques
- to develop and test the code.
- </li>
- <li>
- Select a time frame to evaluate the adoption of new TDD techniques. It should be long enough to allow new habits to
- start to develop, but short enough that changes can be made relatively quickly. This will generally be sometime
- between a couple of weeks and a couple of months.
- </li>
- <li>
- Begin to use TDD as described in the practice. Write tests before writing system code.
- </li>
- <li>
- Evaluate your TDD adoption based on the objectives and metrics that you defined.
- </li>
- <li>
- Make adjustments based on your evaluation. Eliminate tools or tool features that do not prove effective, and
- increase practices that are efficient and improve quality.
- </li>
- <li>
- Determine the next step in adoption. Early on, this will be to write tests for more and more implementation
- elements until TDD is performed on all software for the system. Often, you will be able to achieve this after just
- a few evaluation cycles.
- </li>
- <li>
- Continue to examine how your developer testing can be improved. Address problem areas in regular project review
- meetings. Monitor testing sites (such as the ones referenced on this page), and have individual team members read
- new articles and books about developer testing. They can report back to the group to generate insight and
- discussion about more improvements that can be incrementally applied to your TDD practice.
- </li>
- <li>
- Continue to extend or modify this practice to reflect how your team is performing TDD, and what the next increment
- of adoption should be for your team.
- </li>
-</ol>
-<h4>
- <br />
- Common pitfalls
-</h4>
-<p>
- TDD is a new way of thinking about testing. Failing to plan and manage how the team's behavior needs to change over
- time increases the chance of failing at TDD. Keep the team focused on TDD, and watch for the team falling back into old
- habits.
-</p>
-<p>
- Individuals may opt for expedience and skip "small" or "insignificant" tests in an effort to meet deadlines. TDD's
- payoff is later in the development cycle, when the team is working with a high-quality baseline rather than fixing a
- mountain of bugs that have piled up. No change is too small to be tested.
-</p>
-<p>
- Individuals may ignore implementation refactoring once the code runs successfully. Implementation refactoring keeps the
- code maintainable and reduces code decay, a phenomenon where the average number of errors created by a code fix
- increases over time. The team must refactor after the code runs successfully in order to maintain stable code that can
- be maintained and improved over the long term.
+ <mainDescription><h3>
+ Getting Started&nbsp;
+</h3>
+<p>
+ If you have just installed the test driven development (TDD) practice, start by reviewing the <a
+ class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/developer_testing_FEBDAED6.html"
+ guid="_ADwlAJRtEdyrdaw_xGakyw">Concept: Developer Testing</a>. These will introduce you to the basics of what you need
+ to know about developer testing in the context of TDD. For more introductory information, read this <a
+ href="http://www.agiledata.org/essays/tdd.html" target="_blank">Introduction to TDD</a>.
+</p>
+<p>
+ If your organization has never done developer testing before, start your adoption by educating the members of the team.
+ Use the resources below for educational and reference materials. Begin to track your performance immediately, because
+ that will give you quick feedback on how rapidly the team is adopting TDD, even if it is a very low form of adoption at
+ first.
+</p>
+<p>
+ Tools are critical for creating and managing unit tests. Educate the team on using new tools, and discover which
+ practices and features of the tools will work best in your environment.
+</p>
+<p>
+ Specify modest, attainable goals when adopting TDD. For instance, instead of insisting that every code change must have
+ a developer test starting now, it may be better to limit TDD practices to a single important implementation element.
+ This will allow the team to come up to speed on tools and learn new development habits while minimizing the impact on
+ the overall schedule. After the team has gained some comfort with the new way of doing things (usually a couple of
+ weeks or a single iteration), your refined method for TDD can be applied to all new or changed code. Continue
+ increasing the team's capabilities with TDD by introducing new tools, constraints, monitoring, or methods in modest,
+ attainable increments. This also allows the team to experience success with new techniques, which usually leads to a
+ team that embraces rather than resists change.
+</p>
+<p>
+ Like all process changes, adopting TDD requires that team members change behaviors and develop new habits, such as
+ writing code only when a test already exists to validate it. Developers will need the education provided by the links
+ on this page, and the methods described in this practice, to develop these new behaviors. They will also need to have
+ their new behaviors enforced by the team as a whole, and by management, until constantly writing tests while writing
+ code is a habit. TDD is no different from other areas of process adoption. The managing body (bosses or the team) need
+ to put as much effort into creating new behaviors as the individual developers do.
+</p>
+<p>
+ <strong>TDD Adoption scenario</strong>
+</p>
+<p>
+ Here is one possible scenario for adopting the TDD practice. You will want to add, change, or remove steps to design an
+ adoption roadmap more suitable to your environment. Hiring a consultant experienced in TDD will also speed your
+ adoption of the practice and help avoid common pitfalls.
+</p>
+<ol>
+ <li>
+ Educate the team on TDD. Use the presentations and articles referenced in this practice as a starting place. It
+ would also be helpful for developers to attend a class on developer testing and TDD.
+ </li>
+ <li>
+ Have the team review the material in this practice.
+ </li>
+ <li>
+ Extend this practice to reflect any important constraints or requirements in your organization. For instance,
+ indicate any extra information that may need to be described when checking in system or test code, link to any
+ materials that describe internal tools that your team is required to use, or create a guideline describing how each
+ test must be documented or structured to conform to corporate standards.
+ </li>
+ <li>
+ Identify and prepare to collect the information or metrics that will tell you how well you are adopting this
+ practice. Make sure that the metrics are easy to collect. Highly accurate metrics that are difficult to collect are
+ often abandoned, so provide no value. Coarser measurements that are easy to collect usually provide sufficient
+ information, and it is more likely that they will continue to be collected.
+ </li>
+ <li>
+ Identify the initial, modest goals for your TDD adoption, such as "An average of 2 tests per method for
+ implementation element X". The goal is to be successful at some incremental amount of adoption, not to adopt
+ everything in a single event. Make success a regular habit.
+ </li>
+ <li>
+ Select a critical system implementation element to start applying TDD on. Begin using new TDD tools and techniques
+ to develop and test the code.
+ </li>
+ <li>
+ Select a time frame to evaluate the adoption of new TDD techniques. It should be long enough to allow new habits to
+ start to develop, but short enough that changes can be made relatively quickly. This will generally be sometime
+ between a couple of weeks and a couple of months.
+ </li>
+ <li>
+ Begin to use TDD as described in the practice. Write tests before writing system code.
+ </li>
+ <li>
+ Evaluate your TDD adoption based on the objectives and metrics that you defined.
+ </li>
+ <li>
+ Make adjustments based on your evaluation. Eliminate tools or tool features that do not prove effective, and
+ increase practices that are efficient and improve quality.
+ </li>
+ <li>
+ Determine the next step in adoption. Early on, this will be to write tests for more and more implementation
+ elements until TDD is performed on all software for the system. Often, you will be able to achieve this after just
+ a few evaluation cycles.
+ </li>
+ <li>
+ Continue to examine how your developer testing can be improved. Address problem areas in regular project review
+ meetings. Monitor testing sites (such as the ones referenced on this page), and have individual team members read
+ new articles and books about developer testing. They can report back to the group to generate insight and
+ discussion about more improvements that can be incrementally applied to your TDD practice.
+ </li>
+ <li>
+ Continue to extend or modify this practice to reflect how your team is performing TDD, and what the next increment
+ of adoption should be for your team.
+ </li>
+</ol>
+<h4>
+ <br />
+ Common pitfalls
+</h4>
+<p>
+ TDD is a new way of thinking about testing. Failing to plan and manage how the team's behavior needs to change over
+ time increases the chance of failing at TDD. Keep the team focused on TDD, and watch for the team falling back into old
+ habits.
+</p>
+<p>
+ Individuals may opt for expedience and skip "small" or "insignificant" tests in an effort to meet deadlines. TDD's
+ payoff is later in the development cycle, when the team is working with a high-quality baseline rather than fixing a
+ mountain of bugs that have piled up. No change is too small to be tested.
+</p>
+<p>
+ Individuals may ignore implementation refactoring once the code runs successfully. Implementation refactoring keeps the
+ code maintainable and reduces code decay, a phenomenon where the average number of errors created by a code fix
+ increases over time. The team must refactor after the code runs successfully in order to maintain stable code that can
+ be maintained and improved over the long term.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.test_driven_development.base/guidances/supportingmaterials/using_tdd_in_context.xmi b/epf_prac_151/practice.tech.test_driven_development.base/guidances/supportingmaterials/using_tdd_in_context.xmi
index c51d7e3..d1fb2dc 100644
--- a/epf_prac_151/practice.tech.test_driven_development.base/guidances/supportingmaterials/using_tdd_in_context.xmi
+++ b/epf_prac_151/practice.tech.test_driven_development.base/guidances/supportingmaterials/using_tdd_in_context.xmi
@@ -1,17 +1,17 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-DAk3ahn7Yqi4DY4VKX5b7A" name="new_supporting_material,_vLvAUGjFEd2PJ-nlV-86WA" guid="-DAk3ahn7Yqi4DY4VKX5b7A" changeDate="2008-08-12T04:24:47.000-0700" version="7.5.0">
- <mainDescription><p>
- The Test Driven Development practice describes how to use TDD to create a high quality version of the implementation.
- It should be used in conjunction with other practices or process elements to deliver high quality software. This
- example illustrates one possible way of utilizing the TDD practice in conjunction with other practices.
-</p>
-<p>
- This diagram describes an evolutionary approach to developing the software by considering just a small part of the
- system. A brief amount of time is spent considering the possible design, the code is implemented via the TDD practice,
- and&nbsp;the design is reviewed and refactored until high quality software is achieved. The new part of the system is
- then integrated with the rest of the system, and another small part of the system is selected for development.&nbsp;
-</p>
-<p>
- <img height="587" alt="" src="resources/tdd_in_context.jpg" width="598" />
+ <mainDescription><p>
+ The Test Driven Development practice describes how to use TDD to create a high quality version of the implementation.
+ It should be used in conjunction with other practices or process elements to deliver high quality software. This
+ example illustrates one possible way of utilizing the TDD practice in conjunction with other practices.
+</p>
+<p>
+ This diagram describes an evolutionary approach to developing the software by considering just a small part of the
+ system. A brief amount of time is spent considering the possible design, the code is implemented via the TDD practice,
+ and&nbsp;the design is reviewed and refactored until high quality software is achieved. The new part of the system is
+ then integrated with the rest of the system, and another small part of the system is selected for development.&nbsp;
+</p>
+<p>
+ <img height="587" alt="" src="resources/tdd_in_context.jpg" width="598" />
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.test_driven_development.base/tasks/implement_developer_tests.xmi b/epf_prac_151/practice.tech.test_driven_development.base/tasks/implement_developer_tests.xmi
index 545e3bb..c5df988 100644
--- a/epf_prac_151/practice.tech.test_driven_development.base/tasks/implement_developer_tests.xmi
+++ b/epf_prac_151/practice.tech.test_driven_development.base/tasks/implement_developer_tests.xmi
@@ -1,14 +1,14 @@
<?xml version="1.0" encoding="UTF-8"?>
-<org.eclipse.epf.uma:TaskDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmi:id="-UW-yTFk3AppqcGGU-Px63A" name=",_znlIcJR9EdyVKbgqUOtqQA" guid="-UW-yTFk3AppqcGGU-Px63A" changeDate="2010-09-15T12:44:18.858-0700" version="7.2.0">
- <mainDescription><p>
- Developer testing is different from other forms of testing in that it is based on the expected behavior of code units
- rather than being directly based on the system requirements.
-</p>
-<p>
- It is best to do this at a small scale, much smaller than the complete code base to be authored by a developer over the
- course of an iteration. This can be done for one operation, one field added to a user interface, one stored procedure,
- etc. As the code base is incrementally built, new tests will be authored and existing tests might be revisited to test
- additional behavior.
+<org.eclipse.epf.uma:TaskDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-UW-yTFk3AppqcGGU-Px63A" name=",_znlIcJR9EdyVKbgqUOtqQA" guid="-UW-yTFk3AppqcGGU-Px63A" changeDate="2010-09-15T12:44:18.858-0700" version="7.2.0">
+ <mainDescription><p>
+ Developer testing is different from other forms of testing in that it is based on the expected behavior of code units
+ rather than being directly based on the system requirements.
+</p>
+<p>
+ It is best to do this at a small scale, much smaller than the complete code base to be authored by a developer over the
+ course of an iteration. This can be done for one operation, one field added to a user interface, one stored procedure,
+ etc. As the code base is incrementally built, new tests will be authored and existing tests might be revisited to test
+ additional behavior.
</p></mainDescription>
<keyConsiderations><ol>
<li>
@@ -82,8 +82,8 @@
</li>
</ul></sectionDescription>
</sections>
- <purpose>Prepare to validate an implementation element (e.g. an operation, a class, a stored procedure) through unit testing. The
+ <purpose>Prepare to validate an implementation element (e.g. an operation, a class, a stored procedure) through unit testing. The
result is one or more new developer tests.</purpose>
- <alternatives>Rely on acceptance tests to validate your software. This will likely be time consuming, late, and not as effective as
+ <alternatives>Rely on acceptance tests to validate your software. This will likely be time consuming, late, and not as effective as
developer testing in identifying bugs and finding their location in the code.</alternatives>
</org.eclipse.epf.uma:TaskDescription>
diff --git a/epf_prac_151/practice.tech.test_driven_development.base/tasks/implement_solution.xmi b/epf_prac_151/practice.tech.test_driven_development.base/tasks/implement_solution.xmi
index 3b07010..daba6a6 100644
--- a/epf_prac_151/practice.tech.test_driven_development.base/tasks/implement_solution.xmi
+++ b/epf_prac_151/practice.tech.test_driven_development.base/tasks/implement_solution.xmi
@@ -1,13 +1,13 @@
<?xml version="1.0" encoding="UTF-8"?>
-<org.eclipse.epf.uma:TaskDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmi:id="-UaDGd7K2rQIFMwCrDuqQKQ" name=",_Ht-z8JfJEdyZkIR-s-Y8wQ" guid="-UaDGd7K2rQIFMwCrDuqQKQ" changeDate="2010-09-15T12:46:02.202-0700" version="7.2.0">
- <mainDescription><p>
- Usually, this task is focused on a specific implementation&nbsp;element, such as a class or component, but it does not
- need to be.
-</p>
-<p>
- A portion of the design is implemented by performing this task. This task can be performed any number of times during
- an iteration. In fact it is best to do this task in as small a scope as possible to tighten the loop between it and
- related tasks involving developer testing and consideration of the design.
+<org.eclipse.epf.uma:TaskDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-UaDGd7K2rQIFMwCrDuqQKQ" name=",_Ht-z8JfJEdyZkIR-s-Y8wQ" guid="-UaDGd7K2rQIFMwCrDuqQKQ" changeDate="2010-09-15T12:46:02.202-0700" version="7.2.0">
+ <mainDescription><p>
+ Usually, this task is focused on a specific implementation&nbsp;element, such as a class or component, but it does not
+ need to be.
+</p>
+<p>
+ A portion of the design is implemented by performing this task. This task can be performed any number of times during
+ an iteration. In fact it is best to do this task in as small a scope as possible to tighten the loop between it and
+ related tasks involving developer testing and consideration of the design.
</p></mainDescription>
<keyConsiderations><p>
It is best when developer tests already exist so there is an unambiguous definition of what behavior is considered
@@ -147,9 +147,9 @@
impact, it may be necessary to communicate that change to the other team members through a change request.
</p></sectionDescription>
</sections>
- <purpose><p>
- The purpose of this task is to produce an implementation for part of the solution (such as a class or component), or to
- fix one or more defects. The result is typically new or modified source code, which is&nbsp;referred to the
- implementation.
+ <purpose><p>
+ The purpose of this task is to produce an implementation for part of the solution (such as a class or component), or to
+ fix one or more defects. The result is typically new or modified source code, which is&nbsp;referred to the
+ implementation.
</p></purpose>
</org.eclipse.epf.uma:TaskDescription>
diff --git a/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/concepts/use_case.ucdd.xmi b/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/concepts/use_case.ucdd.xmi
index f65dcb1..d213959 100644
--- a/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/concepts/use_case.ucdd.xmi
+++ b/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/concepts/use_case.ucdd.xmi
@@ -1,54 +1,54 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-wv4JAmTQ0R_KjP76LgDITg" name="new_concept,_ryuL0LsbEdyfAY9BXNFkDg" guid="-wv4JAmTQ0R_KjP76LgDITg" changeDate="2008-10-13T09:31:33.000-0700" version="7.2.0">
- <mainDescription><h3>
- Specifying Use Cases
-</h3>
-<h4>
- <a id="How to Find Use Cases" name="How to Find Use Cases">How to Find Use Cases</a>
-</h4>
-<p>
- See the&nbsp;<a class="elementLinkWithType"
- href="./../../../practice.tech.use_case_driven_dev.base/guidances/guidelines/identify_and_outline_actors_and_ucs_BB5516A9.html"
- guid="_eyL0wCu-EdqSxKAVa9kmvA">Guideline: Identify and Outline Actors and Use Cases</a>&nbsp;for guidance on finding
- Actors and Use Cases.
-</p>
-<h4>
- <a id="How a Use Case Evolves" name="How a Use Case Evolves">How a Use Case Evolves</a>
-</h4>
-<p>
- See the <a class="elementLinkWithType"
- href="./../../../practice.tech.use_case_driven_dev.base/guidances/guidelines/detail_ucs_and_scenarios_6BC56BB7.html"
- guid="_4BJ_YCxSEdqjsdw1QLH_6Q">Guideline: Detail Use Cases and Scenarios</a>&nbsp;for guidance on evolving use cases.
-</p>
-<h4>
- Level of detail necessary in use cases&nbsp;
-</h4>
-<p>
- There will often be use cases in your model that are so simple that they do not need a detailed description of the flow
- of events, a step-by-step outline is quite enough. The criteria for making this decision is that you don't see
- disagreement among user kind of readers on what the use case means, and that designers and testers are comfortable with
- the level of detail provided by the step-by-step format. Examples are use cases that describe simple entry or retrieval
- of some data from the system.
-</p>
-<h4>
- <a id="The Scope of a Use Case" name="The Scope of a Use Case">The Scope of a Use Case</a>
-</h4>
-<p>
- It is often hard to decide if a set of user-system interactions, or dialog, is one or several use cases. Consider the
- use of a recycling machine. The customer inserts deposit items, such as cans, bottles, and crates, into the recycling
- machine. When she has inserted all her deposit items, she presses a button, and a receipt is printed. She can then
- exchange this receipt for money.
-</p>
-<p>
- Is it one use case to insert a deposit item, and another use case to require the receipt? Or is it all one use case?
- There are two actions, but one without the other is of little value to the customer. Rather, it is the complete dialog
- with all the insertions, and getting the receipt, that is of value for the customer (and makes sense to her). Thus, the
- complete dialog, from inserting the first deposit item, to pressing the button and getting the receipt, is a complete
- case of use, a use case.
-</p>
-<p>
- Additionally, you want to keep the two actions together, to be able to review them at the same time, modify them
- together, test them together, write manuals for them and in general manage them as a unit. This becomes very obvious in
- larger systems.
+ <mainDescription><h3>
+ Specifying Use Cases
+</h3>
+<h4>
+ <a id="How to Find Use Cases" name="How to Find Use Cases">How to Find Use Cases</a>
+</h4>
+<p>
+ See the&nbsp;<a class="elementLinkWithType"
+ href="./../../../practice.tech.use_case_driven_dev.base/guidances/guidelines/identify_and_outline_actors_and_ucs_BB5516A9.html"
+ guid="_eyL0wCu-EdqSxKAVa9kmvA">Guideline: Identify and Outline Actors and Use Cases</a>&nbsp;for guidance on finding
+ Actors and Use Cases.
+</p>
+<h4>
+ <a id="How a Use Case Evolves" name="How a Use Case Evolves">How a Use Case Evolves</a>
+</h4>
+<p>
+ See the <a class="elementLinkWithType"
+ href="./../../../practice.tech.use_case_driven_dev.base/guidances/guidelines/detail_ucs_and_scenarios_6BC56BB7.html"
+ guid="_4BJ_YCxSEdqjsdw1QLH_6Q">Guideline: Detail Use Cases and Scenarios</a>&nbsp;for guidance on evolving use cases.
+</p>
+<h4>
+ Level of detail necessary in use cases&nbsp;
+</h4>
+<p>
+ There will often be use cases in your model that are so simple that they do not need a detailed description of the flow
+ of events, a step-by-step outline is quite enough. The criteria for making this decision is that you don't see
+ disagreement among user kind of readers on what the use case means, and that designers and testers are comfortable with
+ the level of detail provided by the step-by-step format. Examples are use cases that describe simple entry or retrieval
+ of some data from the system.
+</p>
+<h4>
+ <a id="The Scope of a Use Case" name="The Scope of a Use Case">The Scope of a Use Case</a>
+</h4>
+<p>
+ It is often hard to decide if a set of user-system interactions, or dialog, is one or several use cases. Consider the
+ use of a recycling machine. The customer inserts deposit items, such as cans, bottles, and crates, into the recycling
+ machine. When she has inserted all her deposit items, she presses a button, and a receipt is printed. She can then
+ exchange this receipt for money.
+</p>
+<p>
+ Is it one use case to insert a deposit item, and another use case to require the receipt? Or is it all one use case?
+ There are two actions, but one without the other is of little value to the customer. Rather, it is the complete dialog
+ with all the insertions, and getting the receipt, that is of value for the customer (and makes sense to her). Thus, the
+ complete dialog, from inserting the first deposit item, to pressing the button and getting the receipt, is a complete
+ case of use, a use case.
+</p>
+<p>
+ Additionally, you want to keep the two actions together, to be able to review them at the same time, modify them
+ together, test them together, write manuals for them and in general manage them as a unit. This becomes very obvious in
+ larger systems.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/concepts/use_case.ucm.xmi b/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/concepts/use_case.ucm.xmi
index 2e5f58e..3aca4d8 100644
--- a/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/concepts/use_case.ucm.xmi
+++ b/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/concepts/use_case.ucm.xmi
@@ -1,13 +1,15 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-3kVaHsAKwWzKBx12XV-xTg" name="new_concept,_jivyULseEdyfAY9BXNFkDg" guid="-3kVaHsAKwWzKBx12XV-xTg" changeDate="2008-01-04T03:42:07.000-0800" version="7.2.0">
- <mainDescription><h3>
- <a id="Use-Case Diagrams" name="Use-Case Diagrams">Use-Case Diagrams</a>
-</h3>
-<p>
- You may choose to illustrate how a use case relates to actors and other use cases in a use-case diagram (in unusual
- cases, more than one diagram). This is useful if the use case is involved with many actors, or has relationships to
- many other use cases. A diagram of this kind is of "local" character, since it shows the use-case model from the
- perspective of one use case only and is not intended to explain any general facts about the whole use-case model. Refer
- to&nbsp;<a class="elementLinkWithType" href="./../../../practice.tech.use_case_driven_dev.base/guidances/guidelines/use_case_model_4C64E97D.html" guid="_0VAUsMlgEdmt3adZL5Dmdw">Guideline: Use-Case Model</a> for more information.<br />
+ <mainDescription><h3>
+ <a id="Use-Case Diagrams" name="Use-Case Diagrams">Use-Case Diagrams</a>
+</h3>
+<p>
+ You may choose to illustrate how a use case relates to actors and other use cases in a use-case diagram (in unusual
+ cases, more than one diagram). This is useful if the use case is involved with many actors, or has relationships to
+ many other use cases. A diagram of this kind is of "local" character, since it shows the use-case model from the
+ perspective of one use case only and is not intended to explain any general facts about the whole use-case model. Refer
+ to&nbsp;<a class="elementLinkWithType"
+ href="./../../../practice.tech.use_case_driven_dev.base/guidances/guidelines/use_case_model_4C64E97D.html"
+ guid="_0VAUsMlgEdmt3adZL5Dmdw">Guideline: Use-Case Model</a> for more information.<br />
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/guidelines/detail_ucs_and_scenarios.xmi b/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/guidelines/detail_ucs_and_scenarios.xmi
index c2dfcf6..f48a68a 100644
--- a/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/guidelines/detail_ucs_and_scenarios.xmi
+++ b/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/guidelines/detail_ucs_and_scenarios.xmi
@@ -1,160 +1,160 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-78ko4CuOJERKJF9ZvwMUBQ" name="detail_ucs_and_scenarios,_4BJ_YCxSEdqjsdw1QLH_6Q" guid="-78ko4CuOJERKJF9ZvwMUBQ" changeDate="2009-03-27T04:04:37.000-0700" version="1.0.0">
- <mainDescription><h4>
- Most efficient way to write use cases
-</h4>
-<p>
- Because use cases model requirements, they are highly dynamic by nature. The more we examine a requirement, the more we
- learn, and the more things change. To further complicate the issue, changes to one use case can lead to changes in
- others. Therefore, we want a flexible, highly efficient method for writing use cases that eliminates unnecessary work
- and rewriting.
-</p>
-<p>
- An iterative, breadth-first approach, in which the use case is continuously evaluated before adding detail, is an
- effective way to write use cases. This breadth-first approach involves two aspects: writing the set of use cases and
- writing individual use cases.
-</p>
-<p>
- <strong>Writing sets of use cases:</strong> Use cases exist in sets, and the relationships between the various use
- cases and Actors&nbsp;are important. As you learn more about the Actors, you also learn more about the system's
- boundaries and transactions. Likewise, as you learn more about the system's transactions, you learn more about its
- Actors. Therefore, it is more efficient to write several use cases simultaneously than to write them sequentially. This
- way, you can identify and understand the effects of the various use cases upon each other as you write them, rather
- than as afterthoughts that require rewriting or elimination of previous work.
-</p>
-<p>
- <strong>Writing individual use cases.</strong> Similarly, it makes sense to write each individual use case iteratively.
- Starting with the main scenario, you can then identify various alternative and error flows that the use case might
- follow, then evaluate, rearrange or eliminate them, and then add the details of the surviving scenarios.
-</p>
-<p>
- Consider factors that can influence the format and level of detail for your use case description.
-</p>
-<h4>
- Detail the flow of events of the main scenario
-</h4>
-<p>
- As a starting point, use the step-by-step description of the use-case main scenario. Then, gradually add details to
- this scenario, describing <strong>what</strong> the use case does, <strong>not how</strong> to solve problems internal
- to the system.
-</p>
-<p>
- A flow of events description explores:
-</p>
-<ul>
- <li>
- How and when the use case starts
- </li>
- <li>
- When the use case interacts with the Actors, and what data they exchange
- </li>
- <li>
- When the use case uses data stored in the system or stores data in the system
- </li>
- <li>
- How and when the use case ends
- </li>
-</ul>
-<p>
- It does not describe:
-</p>
-<ul>
- <li>
- The GUI
- </li>
- <li>
- Technical details of hardware or software
- </li>
- <li>
- Design issues
- </li>
-</ul>
-<h4>
- Identify alternate flows
-</h4>
-<p>
- A use case consists of a number of scenarios, each representing specific instances of the use case that correspond to
- specific inputs from the Actor or to specific conditions in the environment. Each scenario describes alternate ways
- that the system provides a behavior, or it can describe failure or exception cases.
-</p>
-<p>
- As you detail the main scenario, identify alternate flows by asking these questions:
-</p>
-<ul>
- <li>
- Are there different options available, depending on input from the Actor? (for example, if the Actor enters an
- invalid PIN number while accessing an ATM)
- </li>
- <li>
- What business rules can come into play? (for instance, the Actor requests more money from the ATM than is available
- in her account)
- </li>
- <li>
- What could go wrong? (such as no network connection available when required to perform a transaction)
- </li>
-</ul>
-<p>
- It is best to develop these scenarios iteratively, as well. Begin by identifying them. Examine each possible scenario
- to determine whether it is relevant, that it can actually happen, and that it is distinct from other scenarios.
- Eliminate redundant or unnecessary scenarios, and then start elaborating on the more important ones.
-</p>
-<h4>
- Structure the use case
-</h4>
-<p>
- It is useful to structure the use case according to scenarios. This helps both to simplify communication and
- maintenance and to permit the use cases to be implemented iteratively.
-</p>
-<p>
- In addition to structuring the use cases according to scenarios, it is often useful to structure the scenarios
- themselves into sub-flows. This provides an additional level of granularity for planning work and tracking progress.
- Unless a sub-flow involves only a minor part of the complete flow of events (which can be described in the body of the
- text), it is recommended that you describe each sub-flow in a separate section to the Flow of Events section. Sub-flows
- that need to be in a separate section include these examples:
-</p>
-<ul>
- <li>
- Sub-flows that occupy a large segment of a given flow of events.
- </li>
- <li>
- Exceptional and alternate flows of events. This helps the use case's basic flow of events to stand out more
- clearly.
- </li>
- <li>
- Any sub-flow that can be executed at several intervals in the same flow of events.
- </li>
-</ul>
-<h4>
- Describe special requirements
-</h4>
-<p>
- You must also capture any requirements that are related to the use case, but are not taken into consideration in the
- flow of events of the use case. Such requirements are likely to be nonfunctional.
-</p>
-<p>
- Typically, nonfunctional requirements that refer to a specific use case are captured in the special requirements
- section of the use case.&nbsp;If there are nonfunctional requirements that apply to more than one use case, capture
- these in the system-wide requirements specification.
-</p>
-<h4>
- Describe preconditions and postconditions
-</h4>
-<p>
- A <strong>precondition</strong> on a use case explains the state that the system must be in for the use case to be able
- to start. Be careful in describing the system state. Avoid describing the detail of other, incidental activities that
- might already have taken place.
-</p>
-<p>
- A <strong>postcondition</strong> on a use case lists possible states that the system can be in at the end of the use
- case execution. The system must be in one of those states. A postcondition also states actions that the system performs
- at the end of the use case, regardless of what occurred in the use case. Post-Conditions can be categorized as Minimal
- Guarantees&nbsp;or Success Guarantees.&nbsp; A Minimal Guarantee represents a condition that will be true when the use
- case ends, regardless of how it terminates.&nbsp; A Success Guarantee represents a condition that will be true when the
- use case ends successfully, regardless of which path it took.
-</p>
-<p>
- Neither preconditions nor postconditions need to be used to create a sequence of use cases. As a general rule, there
- must never be a case where you have to first perform one use case and then another to have a meaningful flow of events.
- If that is the case, correct the problem by reviewing the use cases.
+ <mainDescription><h4>
+ Most efficient way to write use cases
+</h4>
+<p>
+ Because use cases model requirements, they are highly dynamic by nature. The more we examine a requirement, the more we
+ learn, and the more things change. To further complicate the issue, changes to one use case can lead to changes in
+ others. Therefore, we want a flexible, highly efficient method for writing use cases that eliminates unnecessary work
+ and rewriting.
+</p>
+<p>
+ An iterative, breadth-first approach, in which the use case is continuously evaluated before adding detail, is an
+ effective way to write use cases. This breadth-first approach involves two aspects: writing the set of use cases and
+ writing individual use cases.
+</p>
+<p>
+ <strong>Writing sets of use cases:</strong> Use cases exist in sets, and the relationships between the various use
+ cases and Actors&nbsp;are important. As you learn more about the Actors, you also learn more about the system's
+ boundaries and transactions. Likewise, as you learn more about the system's transactions, you learn more about its
+ Actors. Therefore, it is more efficient to write several use cases simultaneously than to write them sequentially. This
+ way, you can identify and understand the effects of the various use cases upon each other as you write them, rather
+ than as afterthoughts that require rewriting or elimination of previous work.
+</p>
+<p>
+ <strong>Writing individual use cases.</strong> Similarly, it makes sense to write each individual use case iteratively.
+ Starting with the main scenario, you can then identify various alternative and error flows that the use case might
+ follow, then evaluate, rearrange or eliminate them, and then add the details of the surviving scenarios.
+</p>
+<p>
+ Consider factors that can influence the format and level of detail for your use case description.
+</p>
+<h4>
+ Detail the flow of events of the main scenario
+</h4>
+<p>
+ As a starting point, use the step-by-step description of the use-case main scenario. Then, gradually add details to
+ this scenario, describing <strong>what</strong> the use case does, <strong>not how</strong> to solve problems internal
+ to the system.
+</p>
+<p>
+ A flow of events description explores:
+</p>
+<ul>
+ <li>
+ How and when the use case starts
+ </li>
+ <li>
+ When the use case interacts with the Actors, and what data they exchange
+ </li>
+ <li>
+ When the use case uses data stored in the system or stores data in the system
+ </li>
+ <li>
+ How and when the use case ends
+ </li>
+</ul>
+<p>
+ It does not describe:
+</p>
+<ul>
+ <li>
+ The GUI
+ </li>
+ <li>
+ Technical details of hardware or software
+ </li>
+ <li>
+ Design issues
+ </li>
+</ul>
+<h4>
+ Identify alternate flows
+</h4>
+<p>
+ A use case consists of a number of scenarios, each representing specific instances of the use case that correspond to
+ specific inputs from the Actor or to specific conditions in the environment. Each scenario describes alternate ways
+ that the system provides a behavior, or it can describe failure or exception cases.
+</p>
+<p>
+ As you detail the main scenario, identify alternate flows by asking these questions:
+</p>
+<ul>
+ <li>
+ Are there different options available, depending on input from the Actor? (for example, if the Actor enters an
+ invalid PIN number while accessing an ATM)
+ </li>
+ <li>
+ What business rules can come into play? (For instance, the Actor requests more money from the ATM than is available
+ in her account)
+ </li>
+ <li>
+ What could go wrong? (Such as no network connection available when required to perform a transaction)
+ </li>
+</ul>
+<p>
+ It is best to develop these scenarios iteratively, as well. Begin by identifying them. Examine each possible scenario
+ to determine whether it is relevant, that it can actually happen, and that it is distinct from other scenarios.
+ Eliminate redundant or unnecessary scenarios, and then start elaborating on the more important ones.
+</p>
+<h4>
+ Structure the use case
+</h4>
+<p>
+ It is useful to structure the use case according to scenarios. This helps both to simplify communication and
+ maintenance and to permit the use cases to be implemented iteratively.
+</p>
+<p>
+ In addition to structuring the use cases according to scenarios, it is often useful to structure the scenarios
+ themselves into sub-flows. This provides an additional level of granularity for planning work and tracking progress.
+ Unless a sub-flow involves only a minor part of the complete flow of events (which can be described in the body of the
+ text), it is recommended that you describe each sub-flow in a separate section to the Flow of Events section. Sub-flows
+ that need to be in a separate section include these examples:
+</p>
+<ul>
+ <li>
+ Sub-flows that occupy a large segment of a given flow of events.
+ </li>
+ <li>
+ Exceptional and alternate flows of events. This helps the use case's basic flow of events to stand out more
+ clearly.
+ </li>
+ <li>
+ Any sub-flow that can be executed at several intervals in the same flow of events.
+ </li>
+</ul>
+<h4>
+ Describe special requirements
+</h4>
+<p>
+ You must also capture any requirements that are related to the use case, but are not taken into consideration in the
+ flow of events of the use case. Such requirements are likely to be nonfunctional.
+</p>
+<p>
+ Typically, nonfunctional requirements that refer to a specific use case are captured in the special requirements
+ section of the use case.&nbsp;If there are nonfunctional requirements that apply to more than one use case, capture
+ these in the system-wide requirements specification.
+</p>
+<h4>
+ Describe preconditions and postconditions
+</h4>
+<p>
+ A <strong>precondition</strong> on a use case explains the state that the system must be in for the use case to be able
+ to start. Be careful in describing the system state. Avoid describing the detail of other, incidental activities that
+ might already have taken place.
+</p>
+<p>
+ A <strong>postcondition</strong> on a use case lists possible states that the system can be in at the end of the use
+ case execution. The system must be in one of those states. A postcondition also states actions that the system performs
+ at the end of the use case, regardless of what occurred in the use case. Post-Conditions can be categorized as Minimal
+ Guarantees&nbsp;or Success Guarantees.&nbsp; A Minimal Guarantee represents a condition that will be true when the use
+ case ends, regardless of how it terminates.&nbsp; A Success Guarantee represents a condition that will be true when the
+ use case ends successfully, regardless of which path it took.
+</p>
+<p>
+ Neither preconditions nor postconditions need to be used to create a sequence of use cases. As a general rule, there
+ must never be a case where you have to first perform one use case and then another to have a meaningful flow of events.
+ If that is the case, correct the problem by reviewing the use cases.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/guidelines/identify_and_outline_actors_and_ucs.xmi b/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/guidelines/identify_and_outline_actors_and_ucs.xmi
index 586b556..f9101f7 100644
--- a/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/guidelines/identify_and_outline_actors_and_ucs.xmi
+++ b/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/guidelines/identify_and_outline_actors_and_ucs.xmi
@@ -1,146 +1,146 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-Rcm_MlViENAvFFyIe9V3dQ" name="identify_and_outline_actors_and_ucs,_eyL0wCu-EdqSxKAVa9kmvA" guid="-Rcm_MlViENAvFFyIe9V3dQ" changeDate="2009-03-27T04:07:00.000-0700" version="1.0.0">
- <mainDescription><h4>
- Identifying actors
-</h4>
-<p>
- Find the external entities with which the system under development must interact. Candidates include groups of users
- who will require help from the system to perform their tasks and run the system's primary or secondary functions, as
- well as external hardware, software, and other systems.
-</p>
-<p>
- Define each candidate actor by naming it and writing a brief description. Includes the actor's area of responsibility
- and the goals that the actor will attempt to accomplish when using the system. Eliminate actor candidates who do not
- have any goals.
-</p>
-<p>
- These questions are useful in identifying actors:
-</p>
-<ul>
- <li>
- Who will supply, use, or remove information from the system?
- </li>
- <li>
- Who will use the system?
- </li>
- <li>
- Who is interested in a certain feature or service provided by the system?
- </li>
- <li>
- Who will support and maintain the system?
- </li>
- <li>
- What are the system's external resources?
- </li>
- <li>
- What other systems will need to interact with the system under development?
- </li>
-</ul>
-<p>
- Review the list of stakeholders that you captured in the Vision statement. Not all stakeholders will be actors
- (meaning, they will not all interact directly with the system under development), but this list of stakeholders is
- useful for identifying candidates for actors.
-</p>
-<h4>
- Identifying&nbsp;use cases
-</h4>
-<p>
- The best way to find use cases is to consider what each actor requires of the system. For each actor, human or not,
- ask:
-</p>
-<ul>
- <li>
- What are the goals that the actor will attempt to accomplish with the system?
- </li>
- <li>
- What are the primary tasks that the actor wants the system to perform?
- </li>
- <li>
- Will the actor create, store, change, remove, or read data in the system?
- </li>
- <li>
- Will the actor need to inform the system about sudden external changes?
- </li>
- <li>
- Does the actor need to be informed about certain occurrences, such as unavailability of a network resource,&nbsp;in
- the system?
- </li>
- <li>
- Will the actor perform a system startup or shutdown?
- </li>
-</ul>
-<p>
- Understanding how&nbsp;the target&nbsp;organization works and how this information system might be incorporated into
- existing operations gives an idea of system's surroundings. That information can reveal other use case candidates.
-</p>
-<p>
- Give a unique name and brief description that clearly describes the goals for each use case. If the candidate use case
- does not have goals, ask yourself why it exists, and then either identify a goal or eliminate the use case.
-</p>
-<h4>
- Outlining Use Cases
-</h4>
-<p>
- Without going into details, write a first draft of the flow of events of the use cases identified as being of high
- priority. Initially, write a simple step-by-step description of the basic flow of the use case. The step-by-step
- description is a simple ordered list of interactions between the actor and the system. For example, the description of
- the basic flow of the Withdraw Cash use case of an automated teller machine (ATM) would be something like this:
-</p>
-<ol>
- <li>
- The&nbsp;customer inserts a bank card.
- </li>
- <li>
- The system validates the card and prompts the person to enter a personal identification number (PIN).
- </li>
- <li>
- The customer&nbsp;enters a PIN.
- </li>
- <li>
- The system validates the PIN and prompts the customer to select an action.
- </li>
- <li>
- The customer selects Withdraw Cash.
- </li>
- <li>
- The system prompts the customer to choose which account.
- </li>
- <li>
- The customer selects the checking account.
- </li>
- <li>
- The system prompts for an amount.
- </li>
- <li>
- The customer enters the amount to withdraw.
- </li>
- <li>
- The system validates the amount (assuming sufficient funds), and then issues cash and receipt.
- </li>
- <li>
- The customer takes the cash and receipt, and then retrieves the bank card.
- </li>
- <li>
- The use case ends.
- </li>
-</ol>
-<p>
- As you create this step-by-step description of the basic flow of events, you can discover alternative and exceptional
- flows. For example, what happens if the customer enters an invalid PIN? Record the name and a brief description of each
- alternate flow that you identified.
-</p>
-<h4>
- Representing relationships between actors and use cases
-</h4>
-<p>
- The relationship between actors and use cases&nbsp;can be captured, or documented.&nbsp; There are several ways to do
- this. If you are using a use-case model on the project, you can create use-case diagrams to show how&nbsp;actors and
- use cases&nbsp;relate to each other.&nbsp; Refer to&nbsp;<a
- href="./../../../practice.tech.use_case_driven_dev.base/guidances/guidelines/use_case_model_4C64E97D.html"
- guid="_0VAUsMlgEdmt3adZL5Dmdw">Guideline: Use-Case Model</a>&nbsp;for more information.
-</p>
-<p>
- If you are not using a use-case model for the project, make sure that each use case identifies the associated primary
- and secondary actors.
+ <mainDescription><h4>
+ Identifying actors
+</h4>
+<p>
+ Find the external entities with which the system under development must interact. Candidates include groups of users
+ who will require help from the system to perform their tasks and run the system's primary or secondary functions, as
+ well as external hardware, software, and other systems.
+</p>
+<p>
+ Define each candidate actor by naming it and writing a brief description. Includes the actor's area of responsibility
+ and the goals that the actor will attempt to accomplish when using the system. Eliminate actor candidates who do not
+ have any goals.
+</p>
+<p>
+ These questions are useful in identifying actors:
+</p>
+<ul>
+ <li>
+ Who will supply, use, or remove information from the system?
+ </li>
+ <li>
+ Who will use the system?
+ </li>
+ <li>
+ Who is interested in a certain feature or service provided by the system?
+ </li>
+ <li>
+ Who will support and maintain the system?
+ </li>
+ <li>
+ What are the system's external resources?
+ </li>
+ <li>
+ What other systems will need to interact with the system under development?
+ </li>
+</ul>
+<p>
+ Review the list of stakeholders that you captured in the Vision statement. Not all stakeholders will be actors
+ (meaning, they will not all interact directly with the system under development), but this list of stakeholders is
+ useful for identifying candidates for actors.
+</p>
+<h4>
+ Identifying&nbsp;use cases
+</h4>
+<p>
+ The best way to find use cases is to consider what each actor requires of the system. For each actor, human or not,
+ ask:
+</p>
+<ul>
+ <li>
+ What are the goals that the actor will attempt to accomplish with the system?
+ </li>
+ <li>
+ What are the primary tasks that the actor wants the system to perform?
+ </li>
+ <li>
+ Will the actor create, store, change, remove, or read data in the system?
+ </li>
+ <li>
+ Will the actor need to inform the system about sudden external changes?
+ </li>
+ <li>
+ Does the actor need to be informed about certain occurrences, such as unavailability of a network resource,&nbsp;in
+ the system?
+ </li>
+ <li>
+ Will the actor perform a system startup or shutdown?
+ </li>
+</ul>
+<p>
+ Understanding how&nbsp;the target&nbsp;organization works and how this information system might be incorporated into
+ existing operations gives an idea of system's surroundings. That information can reveal other use case candidates.
+</p>
+<p>
+ Give a unique name and brief description that clearly describes the goals for each use case. If the candidate use case
+ does not have goals, ask yourself why it exists, and then either identify a goal or eliminate the use case.
+</p>
+<h4>
+ Outlining Use Cases
+</h4>
+<p>
+ Without going into details, write a first draft of the flow of events of the use cases identified as being of high
+ priority. Initially, write a simple step-by-step description of the basic flow of the use case. The step-by-step
+ description is a simple ordered list of interactions between the actor and the system. For example, the description of
+ the basic flow of the Withdraw Cash use case of an automated teller machine (ATM) would be something like this:
+</p>
+<ol>
+ <li>
+ The&nbsp;customer inserts a bank card.
+ </li>
+ <li>
+ The system validates the card and prompts the person to enter a personal identification number (PIN).
+ </li>
+ <li>
+ The customer&nbsp;enters a PIN.
+ </li>
+ <li>
+ The system validates the PIN and prompts the customer to select an action.
+ </li>
+ <li>
+ The customer selects Withdraw Cash.
+ </li>
+ <li>
+ The system prompts the customer to choose which account.
+ </li>
+ <li>
+ The customer selects the checking account.
+ </li>
+ <li>
+ The system prompts for an amount.
+ </li>
+ <li>
+ The customer enters the amount to withdraw.
+ </li>
+ <li>
+ The system validates the amount (assuming sufficient funds), and then issues cash and receipt.
+ </li>
+ <li>
+ The customer takes the cash and receipt, and then retrieves the bank card.
+ </li>
+ <li>
+ The use case ends.
+ </li>
+</ol>
+<p>
+ As you create this step-by-step description of the basic flow of events, you can discover alternative and exceptional
+ flows. For example, what happens if the customer enters an invalid PIN? Record the name and a brief description of each
+ alternate flow that you identified.
+</p>
+<h4>
+ Representing relationships between actors and use cases
+</h4>
+<p>
+ The relationship between actors and use cases&nbsp;can be captured, or documented.&nbsp; There are several ways to do
+ this. If you are using a use-case model on the project, you can create use-case diagrams to show how&nbsp;actors and
+ use cases&nbsp;relate to each other.&nbsp; Refer to&nbsp;<a
+ href="./../../../practice.tech.use_case_driven_dev.base/guidances/guidelines/use_case_model_4C64E97D.html"
+ guid="_0VAUsMlgEdmt3adZL5Dmdw">Guideline: Use-Case Model</a>&nbsp;for more information.
+</p>
+<p>
+ If you are not using a use-case model for the project, make sure that each use case identifies the associated primary
+ and secondary actors.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/guidelines/system_wide_requirements.xmi b/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/guidelines/system_wide_requirements.xmi
index 289eef3..cdc2884 100644
--- a/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/guidelines/system_wide_requirements.xmi
+++ b/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/guidelines/system_wide_requirements.xmi
@@ -1,417 +1,417 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-BdYFG4-dbPBGFzF9z6KGPA" name="supporting_requirements,_wr24gNcGEdqz_d2XWoVt6Q" guid="-BdYFG4-dbPBGFzF9z6KGPA" changeDate="2009-03-28T10:35:12.000-0700" version="1.0.0">
- <mainDescription><p>
- There is a finite set of requirements to consider when it comes to gathering system-wide requirements, qualities, or
- constraints. Many of them are unfamiliar to stakeholders; therefore, they&nbsp;might find it difficult to answer
- questions related to topics such as availability, performance, scalability, or localization. You can use this guideline
- and the associated checklist <a class="elementLinkWithType"
- href="./../../../core.tech.common.extend_supp/guidances/checklists/system_wide_rqmts_furps_3158BF2F.html"
- guid="_Vael8CGMEdu3VKXZx45D3A">Checklist: System-Wide Requirements (FURPS+)</a>&nbsp;when speaking to stakeholders to
- ensure that all topics are discussed. Make sure that stakeholders understand the costs of their selections and do not
- end up wanting everything that is on the list.
-</p>
-<h3>
- Functional
-</h3>
-<ul>
- <li>
- <p>
- <strong>Auditing:</strong> Is there a need to track who used the system and when they used it? State
- requirements for providing audit trails when running the system.
- </p>
- </li>
- <li>
- <p>
- <strong>Authentication:</strong> Will access to the system be controlled? State requirements for
- authentication.
- </p>
- </li>
- <li>
- <p>
- <strong>Licensing:</strong> Will the system or parts of the system be licensed? If open-source software has
- been used in the system, have all open-source agreements been respected? State requirements for acquiring,
- installing, tracking, and monitoring licenses.
- </p>
- </li>
- <li>
- <p>
- <strong>Printing:</strong> Will printing capability be required? State requirements for printing.
- </p>
- </li>
- <li>
- <p>
- <strong>Reporting:</strong> Is reporting capability required? State requirements for reporting.
- </p>
- </li>
- <li>
- <p>
- <strong>Scheduling:</strong> Will certain system actions need to be scheduled? State requirements for
- scheduling capability.
- </p>
- </li>
- <li>
- <p>
- <strong>Security:</strong> Will elements of the system or system data need to be secure? State requirements to
- protect access to certain resources or information.
- </p>
- </li>
-</ul>
-<h3>
- Usability
-</h3>
-<p>
- Usability requirements are critical to the success of any system. Unfortunately, usability requirements are often the
- most poorly specified requirements. Consider this common requirement: The system shall be easy to use. This doesn't
- help much, because it cannot be verified.
-</p>
-<p>
- While capturing usability requirements, it is a good idea to identify issues and concerns first, and then refine these
- into verifiable requirements later (see <a class="elementLinkWithType"
- href="./../../../core.tech.common.extend_supp/guidances/guidelines/writing_good_requirements_48248536.html"
- guid="_6jXzYNcKEdqz_d2XWoVt6Q">Guideline: Writing Requirements Statements</a>). According to a traditional definition,
- usability consists of five factors:
-</p>
-<ul>
- <li>
- <p>
- <strong>Ease of learning:</strong> A user with a specified level of experience must be able to learn how to use
- the system in a specified amount of time.
- </p>
- </li>
- <li>
- <p>
- <strong>Task efficiency:</strong> A user must be able to complete a specified task in a specified time (or
- number of mouse clicks).
- </p>
- </li>
- <li>
- <p>
- <strong>Ease of remembering:</strong> A user must be able to remember how to accomplish specified tasks after
- not using the system for a specified period of time.
- </p>
- </li>
- <li>
- <p>
- <strong>Understandability:</strong> A user must be able to understand system prompts and messages and what the
- system does.
- </p>
- </li>
- <li>
- <p>
- <strong>Subjective satisfaction:</strong> A specified percentage of the user community must express
- satisfaction with using the system.
- </p>
- </li>
-</ul>
-<p>
- You might want to use the following method to identify and specify usability requirements:
-</p>
-<div style="MARGIN-LEFT: 2em">
- <ol>
- <li>
- Identify the key usability issues by looking at critical tasks, user profiles, system goals, and previous
- usability problems.
- </li>
- <li>
- Choose the appropriate style to express the requirements:
- <ul>
- <li>
- <strong>Performance style:</strong> Specify how fast users can learn various tasks and how fast they
- can perform the tasks after training.
- </li>
- <li>
- <strong>Defect style:</strong> Rather than measuring task times, identify usability defects and
- specifies how frequently they can occur.
- </li>
- <li>
- <strong>Guideline style:</strong> Specify the general appearance and response time of the user
- interface by reference to an accepted and well-defined standard
- </li>
- </ul>
- </li>
- <li>
- Write the actual requirements, including performance criteria (see <a class="elementLinkWithType"
- href="./../../../core.tech.common.extend_supp/guidances/guidelines/writing_good_requirements_48248536.html"
- guid="_6jXzYNcKEdqz_d2XWoVt6Q">Guideline: Writing Requirements Statements</a>&nbsp;for more information).
- </li>
- </ol>
-</div>
-<h3>
- Reliability
-</h3>
-<p>
- Reliability includes the system's ability to continue running under stress and adverse conditions. In the case of an
- application, reliability relates to the amount of time that the software is available and running as opposed to time
- unavailable. Specify reliability acceptance levels, as well as how they will be measured and evaluated. Describe
- reliability criteria in measurable terms. This is usually expressed as the allowable time between failures or the total
- allowable failure rate. Other important reliability considerations include:
-</p>
-<ul>
- <li>
- <p>
- <strong>Accuracy:</strong> Specify requirements for the precision (resolution) and the accuracy (by some known
- standard) that is required in any calculation performed or in system output.
- </p>
- </li>
- <li>
- <p>
- <strong>Availability:</strong> Specify requirements for the percentage of time the system is available for use,
- hours of use, maintenance access, and degraded-mode operations. Availability is typically specified in terms of
- the Mean Time Between Failures (MTBF).
- </p>
- </li>
- <li>
- <p>
- <strong>Recoverability:</strong> Specify requirements for recovery from failure. This is typically specified in
- terms of the Mean Time to Repair (MTTR).
- </p>
- </li>
- <li>
- <p>
- <strong>Frequency and severity of failures:</strong> Specify the maximum defect rate (typically expressed as
- defects/KSLOC or defects/function-point) and severity of failures. Severity&nbsp;can be categorized in terms of
- <strong>minor</strong>, <strong>significant</strong>, and <strong>critical</strong> defects. The requirements
- must define each of these terms unambiguously. For example, a <strong>critical</strong> defect could be defined
- as one that results in loss of data or complete inability to use certain functionality of the system.
- </p>
- </li>
-</ul>
-<h3>
- Performance
-</h3>
-<ul>
- <li>
- <p>
- <strong>Response times:</strong> Specify the amount of time available for the system to complete specified
- tasks and transactions (average, maximum). Use units of measurement. <em>Examples:</em>
- </p>
- <ul>
- <li>
- Any interface between a user and the system shall have a maximum response time of 2 seconds.
- </li>
- <li>
- The product shall download the new status parameters within 5 minutes of a change.<br />
- </li>
- </ul>
- </li>
- <li>
- <strong>Throughput:</strong> Specify the capacity of the system to support a given flow of information (for
- example, transactions per second).<br />
- </li>
- <li>
- <strong>Capacity:</strong> Specify on the volumes that the product must be able to deal with and the numbers of
- data stored by the product. Make sure that the requirement description is quantified, and thus can be tested. Use
- unit of measurement such as: the number of customers or transactions the system can accommodate, resource usage
- (memory, disk, . . . ) or degradation modes (what is the acceptable mode of operation when the system has been
- degraded in some manner) <em>Examples:</em>
- <ul>
- <li>
- The product shall cater for 300 simultaneous users within the period from 9:00 AM to 11 AM.
- </li>
- <li>
- Maximum loading at other periods will be 150.<br />
- </li>
- </ul>
- </li>
- <li>
- <strong>Start-up:</strong> The time for the system to start up.<br />
- </li>
- <li>
- <strong>Shut-down:</strong> The time for the system to shut down.
- </li>
-</ul>
-<h3>
- Supportability
-</h3>
-<ul>
- <li>
- <p>
- <strong>Adaptability:</strong> Are there any special requirements regarding adaptation of the software
- (including upgrading)? List requirements for the ease with which the system is adapted to new environments.
- </p>
- </li>
- <li>
- <p>
- <strong>Compatibility:</strong> Are there any requirements regarding this system and its compatibility with
- previous versions of this system or legacy systems that provide the same capability?
- </p>
- </li>
- <li>
- <p>
- <strong>Configurability:</strong> Will the product be configured after it has been deployed? In what way will
- the system be configured?
- </p>
- </li>
- <li>
- <p>
- <strong>Installation:</strong> State any special requirements regarding system installation
- </p>
- </li>
- <li>
- <strong>Level of Support:</strong> What is the level of support that the product requires? This is often performed
- using a Help desk. If there are to be people who provide support for the product, is that support considered part
- of what you are providing to the customer? Are there any requirements for that support? You might also build
- support into the product itself, in which case this is the place to write those requirements. Consider the level of
- support that you anticipate providing and what forms it might take.<br />
- </li>
- <li>
- <strong>Maintainability:</strong> Are there any special requirements regarding system maintenance? What are the
- requirements for the intended release cycle for the product and the form that the release will take? Quantify the
- time necessary to make specified changes to the product. There can also be special requirements for
- maintainability, such as&nbsp;a requirement that&nbsp;the product must be able to be maintained by its end-users or
- developers who are not your development team. This has an effect on the way that the product is developed, and
- there can be additional requirements for documentation or training. Describe the type of maintenance and the amount
- of effort required. <em>Examples:</em><br />
- </li>
- <li style="LIST-STYLE-TYPE: none">
- <ul>
- <li>
- A new weather station must be able to be added to the system overnight.
- </li>
- <li>
- The maintenance releases will be offered to end-users once a year.<br />
- </li>
- </ul>
- </li>
- <li>
- <strong>Scalability:</strong> What volumes of users and data will the system support? This specifies the expected
- increases in size that the product must be able to handle As businesses grow (or are expected to grow), the
- software products must increase their capacities to cope with the new volumes. This can be expressed as a profile
- over time.<br />
- </li>
- <li>
- <strong>Testability:</strong> Are there any special requirements regarding the testability of the system?
- </li>
-</ul>
-<h3>
- Constraints (+)
-</h3>
-<ul>
- <li>
- <p>
- <strong>Design constraints:</strong> Are there any design decisions that have been mandated that the product
- must adhered to?
- </p>
- </li>
- <li>
- <p>
- <strong>Third-party components:</strong> Specify any mandated legacy, COTS, or open-source components to be
- used with the system.
- </p>
- </li>
- <li>
- <p>
- <strong>Implementation languages:</strong> Specify requirements on the implementation languages to be used
- </p>
- </li>
- <li>
- <p>
- <strong>Platform support:</strong> Specify requirements on the platforms that the system will support
- </p>
- </li>
- <li>
- <p>
- <strong>Resource limits:</strong> Specify requirements on the use of system resources, such as memory and hard
- disk space
- </p>
- </li>
- <li>
- <p>
- <strong>Physical Constraints:</strong> Specify requirements on the shape, size, and weight of the resulting
- hardware to house the system
- </p>
- </li>
-</ul>
-<h3>
- Interface Requirements (+)
-</h3>
-<p>
- Describe both the user interface and interfaces with external systems.
-</p>
-<h4>
- User interface
-</h4>
-<p>
- Describe requirements related to user interfaces that are to be implemented by the software. The intention of this
- section is to state the requirements, but not to describe the user interface itself, because interface design can
- overlap the requirements-gathering process. This is particularly true if you are using prototyping as part of your
- requirements gathering process. As you develop prototypes, it is important to capture the requirements that relate to
- the look and feel of the user interface. In other words, be sure that you understand your client's intentions for the
- product's look and feel. Record these as requirements, rather than merely using a prototype for approval.
-</p>
-<ul>
- <li>
- <p>
- <strong>Look and feel:</strong> A description of the aesthetic appearance and layout of the interface. Your
- client might have given you particular demands, such as style, colors, degree of interaction, and so on. This
- section captures the requirements for the interface, rather than the design for the interface. The motivation
- is to capture the expectations, the constraints, and the client's demands for the interface before designing
- it. <em>Examples:</em>
- </p>
- <ul>
- <li>
- The product shall have the same layout as the district maps from the engineering department.
- </li>
- <li>
- The product shall use the company color.<br />
- </li>
- </ul>
- </li>
- <li>
- <strong>Layout and navigation requirements:</strong> Specify requirements on major screen areas and how they must
- be grouped together.<br />
- </li>
- <li>
- <strong>Consistency:</strong> Consistency in the user interface enables users to predict what will happen. This
- section states requirements on the use of mechanisms to be employed in the user interface. This applies both within
- the system, and with other systems and can be applied at different levels: navigation controls, screen areas sizes
- and shapes, placements for entering / presenting data, terminology<br />
- </li>
- <li>
- <strong>User personalization and customization requirements:</strong> Requirements on content that must
- automatically displayed to users or available based on user attributes. Sometimes users allowed to customize the
- content displayed or to personalize displayed content.
- </li>
-</ul>
-<h4>
- Interfaces to external systems or devices
-</h4>
-<ul>
- <li>
- <p>
- <strong>Software interfaces:</strong> Are there any external systems with which this system must interface? Are
- there any constraints on the nature of the interface between this system and any external system, such as the
- format of data passed between these systems? Do they use any particular protocol? Describe software interfaces
- with other components. These can be purchased components, components reused from another application, or
- components being developed for subsystems outside of the scope of the system under consideration, but with
- which this it must interact. For each system, consider both provided and required interfaces.
- </p>
- </li>
- <li>
- <p>
- <strong>Hardware interfaces:</strong> Define any hardware interfaces that are to be supported by the software,
- including logical structure, physical addresses, expected behavior, and so on.
- </p>
- </li>
- <li>
- <p>
- <strong>Communications interfaces:</strong> Describe any communications interfaces to other systems or devices,
- such as local area networks (LANs), remote serial devices, and so on.
- </p>
- </li>
-</ul>
-<h3>
- Business Rules (+)
-</h3>
-<p>
- Besides technical requirements, also consider the particular business domain in which the system needs to fit.
-</p>
-<p>
- Business rules or policies that the system must conform to can constrain system functionality. Business rules are
- referred to by system use cases and can be in the form of decision tables, computation rules, decision trees,
- algorithms, and so forth. Describing the rules in the flows of the use cases usually clutters the use-case
- specifications. Therefore, they are normally captured in separate artifacts or as annexes related to the use-case
- specifications. In many cases, a business rule applies to more then one use case. Shared business rules must be stored
- in a single repository or&nbsp;document.
+ <mainDescription><p>
+ There is a finite set of requirements to consider when it comes to gathering system-wide requirements, qualities, or
+ constraints. Many of them are unfamiliar to stakeholders; therefore, they&nbsp;might find it difficult to answer
+ questions related to topics such as availability, performance, scalability, or localization. You can use this guideline
+ and the associated checklist <a class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/checklists/system_wide_rqmts_furps_3158BF2F.html"
+ guid="_Vael8CGMEdu3VKXZx45D3A">Checklist: System-Wide Requirements (FURPS+)</a>&nbsp;when speaking to stakeholders to
+ ensure that all topics are discussed. Make sure that stakeholders understand the costs of their selections and do not
+ end up wanting everything that is on the list.
+</p>
+<h3>
+ Functional
+</h3>
+<ul>
+ <li>
+ <p>
+ <strong>Auditing:</strong> Is there a need to track who used the system and when they used it? State
+ requirements for providing audit trails when running the system.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Authentication:</strong> Will access to the system be controlled? State requirements for
+ authentication.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Licensing:</strong> Will the system or parts of the system be licensed? If open-source software has
+ been used in the system, have all open-source agreements been respected? State requirements for acquiring,
+ installing, tracking, and monitoring licenses.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Printing:</strong> Will printing capability be required? State requirements for printing.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Reporting:</strong> Is reporting capability required? State requirements for reporting.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Scheduling:</strong> Will certain system actions need to be scheduled? State requirements for
+ scheduling capability.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Security:</strong> Will elements of the system or system data need to be secure? State requirements to
+ protect access to certain resources or information.
+ </p>
+ </li>
+</ul>
+<h3>
+ Usability
+</h3>
+<p>
+ Usability requirements are critical to the success of any system. Unfortunately, usability requirements are often the
+ most poorly specified requirements. Consider this common requirement: The system shall be easy to use. This doesn't
+ help much, because it cannot be verified.
+</p>
+<p>
+ While capturing usability requirements, it is a good idea to identify issues and concerns first, and then refine these
+ into verifiable requirements later (see <a class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/guidelines/writing_good_requirements_48248536.html"
+ guid="_6jXzYNcKEdqz_d2XWoVt6Q">Guideline: Writing Requirements Statements</a>). According to a traditional definition,
+ usability consists of five factors:
+</p>
+<ul>
+ <li>
+ <p>
+ <strong>Ease of learning:</strong> A user with a specified level of experience must be able to learn how to use
+ the system in a specified amount of time.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Task efficiency:</strong> A user must be able to complete a specified task in a specified time (or
+ number of mouse clicks).
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Ease of remembering:</strong> A user must be able to remember how to accomplish specified tasks after
+ not using the system for a specified period of time.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Understandability:</strong> A user must be able to understand system prompts and messages and what the
+ system does.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Subjective satisfaction:</strong> A specified percentage of the user community must express
+ satisfaction with using the system.
+ </p>
+ </li>
+</ul>
+<p>
+ You might want to use the following method to identify and specify usability requirements:
+</p>
+<div style="MARGIN-LEFT: 2em">
+ <ol>
+ <li>
+ Identify the key usability issues by looking at critical tasks, user profiles, system goals, and previous
+ usability problems.
+ </li>
+ <li>
+ Choose the appropriate style to express the requirements: 
+ <ul>
+ <li>
+ <strong>Performance style:</strong> Specify how fast users can learn various tasks and how fast they
+ can perform the tasks after training.
+ </li>
+ <li>
+ <strong>Defect style:</strong> Rather than measuring task times, identify usability defects and
+ specifies how frequently they can occur.
+ </li>
+ <li>
+ <strong>Guideline style:</strong> Specify the general appearance and response time of the user
+ interface by reference to an accepted and well-defined standard
+ </li>
+ </ul>
+ </li>
+ <li>
+ Write the actual requirements, including performance criteria (see <a class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/guidelines/writing_good_requirements_48248536.html"
+ guid="_6jXzYNcKEdqz_d2XWoVt6Q">Guideline: Writing Requirements Statements</a>&nbsp;for more information).
+ </li>
+ </ol>
+</div>
+<h3>
+ Reliability
+</h3>
+<p>
+ Reliability includes the system's ability to continue running under stress and adverse conditions. In the case of an
+ application, reliability relates to the amount of time that the software is available and running as opposed to time
+ unavailable. Specify reliability acceptance levels, as well as how they will be measured and evaluated. Describe
+ reliability criteria in measurable terms. This is usually expressed as the allowable time between failures or the total
+ allowable failure rate. Other important reliability considerations include:
+</p>
+<ul>
+ <li>
+ <p>
+ <strong>Accuracy:</strong> Specify requirements for the precision (resolution) and the accuracy (by some known
+ standard) that is required in any calculation performed or in system output.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Availability:</strong> Specify requirements for the percentage of time the system is available for use,
+ hours of use, maintenance access, and degraded-mode operations. Availability is typically specified in terms of
+ the Mean Time Between Failures (MTBF).
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Recoverability:</strong> Specify requirements for recovery from failure. This is typically specified in
+ terms of the Mean Time to Repair (MTTR).
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Frequency and severity of failures:</strong> Specify the maximum defect rate (typically expressed as
+ defects/KSLOC or defects/function-point) and severity of failures. Severity&nbsp;can be categorized in terms of
+ <strong>minor</strong>, <strong>significant</strong>, and <strong>critical</strong> defects. The requirements
+ must define each of these terms unambiguously. For example, a <strong>critical</strong> defect could be defined
+ as one that results in loss of data or complete inability to use certain functionality of the system.
+ </p>
+ </li>
+</ul>
+<h3>
+ Performance
+</h3>
+<ul>
+ <li>
+ <p>
+ <strong>Response times:</strong> Specify the amount of time available for the system to complete specified
+ tasks and transactions (average, maximum). Use units of measurement. <em>Examples:</em>
+ </p>
+ <ul>
+ <li>
+ Any interface between a user and the system shall have a maximum response time of 2 seconds.
+ </li>
+ <li>
+ The product shall download the new status parameters within 5 minutes of a change.<br />
+ </li>
+ </ul>
+ </li>
+ <li>
+ <strong>Throughput:</strong> Specify the capacity of the system to support a given flow of information (for
+ example, transactions per second).<br />
+ </li>
+ <li>
+ <strong>Capacity:</strong> Specify on the volumes that the product must be able to deal with and the numbers of
+ data stored by the product. Make sure that the requirement description is quantified, and thus can be tested. Use
+ unit of measurement such as: the number of customers or transactions the system can accommodate, resource usage
+ (memory, disk, . . . ), or degradation modes (what is the acceptable mode of operation when the system has been
+ degraded in some manner) <em>Examples:</em> 
+ <ul>
+ <li>
+ The product shall cater for 300 simultaneous users within the period from 9:00 AM to 11 AM.
+ </li>
+ <li>
+ Maximum loading at other periods will be 150.<br />
+ </li>
+ </ul>
+ </li>
+ <li>
+ <strong>Start-up:</strong> The time for the system to start up.<br />
+ </li>
+ <li>
+ <strong>Shut-down:</strong> The time for the system to shut down.
+ </li>
+</ul>
+<h3>
+ Supportability
+</h3>
+<ul>
+ <li>
+ <p>
+ <strong>Adaptability:</strong> Are there any special requirements regarding adaptation of the software
+ (including upgrading)? List requirements for the ease with which the system is adapted to new environments.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Compatibility:</strong> Are there any requirements regarding this system and its compatibility with
+ previous versions of this system or legacy systems that provide the same capability?
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Configurability:</strong> Will the product be configured after it has been deployed? In what way will
+ the system be configured?
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Installation:</strong> State any special requirements regarding system installation
+ </p>
+ </li>
+ <li>
+ <strong>Level of Support:</strong> What is the level of support that the product requires? This is often performed
+ using a Help desk. If there are to be people who provide support for the product, is that support considered part
+ of what you are providing to the customer? Are there any requirements for that support? You might also build
+ support into the product itself, in which case this is the place to write those requirements. Consider the level of
+ support that you anticipate providing and what forms it might take.<br />
+ </li>
+ <li>
+ <strong>Maintainability:</strong> Are there any special requirements regarding system maintenance? What are the
+ requirements for the intended release cycle for the product and the form that the release will take? Quantify the
+ time necessary to make specified changes to the product. There can also be special requirements for
+ maintainability, such as&nbsp;a requirement that&nbsp;the product must be able to be maintained by its end-users or
+ developers who are not your development team. This has an effect on the way that the product is developed, and
+ there can be additional requirements for documentation or training. Describe the type of maintenance and the amount
+ of effort required. <em>Examples:</em><br />
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <ul>
+ <li>
+ A new weather station must be able to be added to the system overnight.
+ </li>
+ <li>
+ The maintenance releases will be offered to end-users once a year.<br />
+ </li>
+ </ul>
+ </li>
+ <li>
+ <strong>Scalability:</strong> What volumes of users and data will the system support? This specifies the expected
+ increases in size that the product must be able to handle As businesses grow (or are expected to grow), the
+ software products must increase their capacities to cope with the new volumes. This can be expressed as a profile
+ over time.<br />
+ </li>
+ <li>
+ <strong>Testability:</strong> Are there any special requirements regarding the testability of the system?
+ </li>
+</ul>
+<h3>
+ Constraints (+)
+</h3>
+<ul>
+ <li>
+ <p>
+ <strong>Design constraints:</strong> Are there any design decisions that have been mandated that the product
+ must adhered to?
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Third-party components:</strong> Specify any mandated legacy, COTS, or open-source components to be
+ used with the system.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Implementation languages:</strong> Specify requirements on the implementation languages to be used
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Platform support:</strong> Specify requirements on the platforms that the system will support
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Resource limits:</strong> Specify requirements on the use of system resources, such as memory and hard
+ disk space
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Physical Constraints:</strong> Specify requirements on the shape, size, and weight of the resulting
+ hardware to house the system
+ </p>
+ </li>
+</ul>
+<h3>
+ Interface Requirements (+)
+</h3>
+<p>
+ Describe both the user interface and interfaces with external systems.
+</p>
+<h4>
+ User interface
+</h4>
+<p>
+ Describe requirements related to user interfaces that are to be implemented by the software. The intention of this
+ section is to state the requirements, but not to describe the user interface itself, because interface design can
+ overlap the requirements-gathering process. This is particularly true if you are using prototyping as part of your
+ requirements gathering process. As you develop prototypes, it is important to capture the requirements that relate to
+ the look and feel of the user interface. In other words, be sure that you understand your client's intentions for the
+ product's look and feel. Record these as requirements, rather than merely using a prototype for approval.
+</p>
+<ul>
+ <li>
+ <p>
+ <strong>Look and feel:</strong> A description of the aesthetic appearance and layout of the interface. Your
+ client might have given you particular demands, such as style, colors, degree of interaction, and so on. This
+ section captures the requirements for the interface, rather than the design for the interface. The motivation
+ is to capture the expectations, the constraints, and the client's demands for the interface before designing
+ it. <em>Examples:</em>
+ </p>
+ <ul>
+ <li>
+ The product shall have the same layout as the district maps from the engineering department.
+ </li>
+ <li>
+ The product shall use the company color.<br />
+ </li>
+ </ul>
+ </li>
+ <li>
+ <strong>Layout and navigation requirements:</strong> Specify requirements on major screen areas and how they must
+ be grouped together.<br />
+ </li>
+ <li>
+ <strong>Consistency:</strong> Consistency in the user interface enables users to predict what will happen. This
+ section states requirements on the use of mechanisms to be employed in the user interface. This applies both within
+ the system, and with other systems and can be applied at different levels: navigation controls, screen areas sizes
+ and shapes, placements for entering / presenting data, terminology<br />
+ </li>
+ <li>
+ <strong>User personalization and customization requirements:</strong> Requirements on content that must
+ automatically displayed to users or available based on user attributes. Sometimes users allowed to customize the
+ content displayed or to personalize displayed content.
+ </li>
+</ul>
+<h4>
+ Interfaces to external systems or devices
+</h4>
+<ul>
+ <li>
+ <p>
+ <strong>Software interfaces:</strong> Are there any external systems with which this system must interface? Are
+ there any constraints on the nature of the interface between this system and any external system, such as the
+ format of data passed between these systems? Do they use any particular protocol? Describe software interfaces
+ with other components. These can be purchased components, components reused from another application, or
+ components being developed for subsystems outside of the scope of the system under consideration, but with
+ which this it must interact. For each system, consider both provided and required interfaces.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Hardware interfaces:</strong> Define any hardware interfaces that are to be supported by the software,
+ including logical structure, physical addresses, expected behavior, and so on.
+ </p>
+ </li>
+ <li>
+ <p>
+ <strong>Communications interfaces:</strong> Describe any communications interfaces to other systems or devices,
+ such as local area networks (LANs), remote serial devices, and so on.
+ </p>
+ </li>
+</ul>
+<h3>
+ Business Rules (+)
+</h3>
+<p>
+ Besides technical requirements, also consider the particular business domain in which the system needs to fit.
+</p>
+<p>
+ Business rules or policies that the system must conform to can constrain system functionality. Business rules are
+ referred to by system use cases and can be in the form of decision tables, computation rules, decision trees,
+ algorithms, and so forth. Describing the rules in the flows of the use cases usually clutters the use-case
+ specifications. Therefore, they are normally captured in separate artifacts or as annexes related to the use-case
+ specifications. In many cases, a business rule applies to more then one use case. Shared business rules must be stored
+ in a single repository or&nbsp;document.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/guidelines/uc_realizations.xmi b/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/guidelines/uc_realizations.xmi
index 4c753a5..832c458 100644
--- a/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/guidelines/uc_realizations.xmi
+++ b/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/guidelines/uc_realizations.xmi
@@ -1,89 +1,89 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-CFYVionNDLkMw6SG6runQA" name="uc_realizations,_2uan8NbyEdqu5o2S60g5LA" guid="-CFYVionNDLkMw6SG6runQA" changeDate="2009-03-28T10:38:35.000-0700" version="7.2.0">
- <mainDescription><p>
- A use-case realization represents how a use case will be implemented in terms of collaborating objects. This artifact
- can take various forms. It can include, for example, a textual description (a document), class diagrams of
- participating classes and subsystems, and interaction diagrams (communication and sequence diagrams) that illustrate
- the flow of interactions between class and subsystem instances.
-</p>
-<p>
- The reason for separating the use-case realization from its use case is that doing so allows the use cases to be
- managed separately from their realizations. This is particularly important for larger projects, or families of systems
- where the same use cases can be designed differently in different products within the product family. Consider the case
- of a family of telephone switches which have many use cases in common, but which design and implement them differently
- according to product positioning, performance and price.
-</p>
-<p>
- For larger projects, separating the use case and its realization allows changes to the design of the use case without
- affecting the baselined use case itself.
-</p>
-<p>
- In a model, a use-case realization is represented as a UML collaboration that groups the diagrams and other information
- (such as textual descriptions) that form part of the use-case realization.
-</p>
-<p>
- UML diagrams that&nbsp;support use-case realizations can be produced in an analysis context, a&nbsp;design context, or
- both, depending on the needs of the project. For each use case in the use-case model, there&nbsp;can be&nbsp;a use-case
- realization in the analysis/design model with a realization relationship to the use case. In UML this is shown as a
- dashed arrow, with an arrowhead like a generalization relationship, indicating that a realization is a kind of
- inheritance, as well as a dependency.<br />
-</p>
-<p align="center">
- <img alt="Use Case Realizations" src="resources/ucrea1.gif" width="277" height="109" />
-</p>
-<p>
- A use-case realization in the&nbsp;design can be traced to a use case in the use-case model.
-</p>
-<h4>
- Class Diagrams Owned by a Use-Case Realization
-</h4>
-<p>
- For each use-case realization there can be one or more class diagrams depicting its participating classes. A class and
- its objects often participate in several use-case realizations. It is important&nbsp;while designing to coordinate all
- the requirements on a class and its objects that different use-case realizations can have. The figure below shows an
- analysis&nbsp;class diagram for the realization of the Receive Deposit Item use case. Note the use of
- boundary-control-entity stereotypes to represent analysis classes (see <a class="elementLinkWithType"
- href="./../../../core.tech.common.extend_supp/guidances/guidelines/entity_control_boundary_pattern_C4047897.html"
- guid="_uF-QYEAhEdq_UJTvM1DM2Q">Guideline: Entity-Control-Boundary Pattern</a>).
-</p>
-<p align="center">
- <img alt="Class diagram for the realization of Receive Deposit Item" src="resources/md_ucre3.gif" width="328"
- height="213" />
-</p>
-<p align="center">
- <strong>The use case Receive Deposit Item and its analysis-level class diagram</strong>.
-</p>
-<h4>
- Communication and Sequence Diagrams Owned by a Use-Case Realization
-</h4>
-<p>
- For each use-case realization there&nbsp;can be&nbsp;one or more interaction diagrams depicting its participating
- objects and their interactions. There are two types of interaction diagrams: sequence diagrams and communication
- diagrams. They express similar information, but show it in different ways. Sequence diagrams show the explicit sequence
- of messages and are better when it is important to visualize the time ordering of messages, whereas communication
- diagrams show the communication links between objects and are better for understanding all of the effects on a given
- object and for algorithm design.
-</p>
-<p>
- Realizing use cases through interaction diagrams helps to keep the design simple and cohesive. Assigning
- responsibilities to classes on the basis of what the use-case scenario explicitly requires encourages the design to
- contain the following:
-</p>
-<ul>
- <li>
- Only the functionality actually used in support of a use case scenario
- </li>
- <li>
- Functionality that can be tested through an associated test case
- </li>
- <li>
- Functionality that is more easily traceable to requirements and changes
- </li>
- <li>
- Explicitly declared class dependencies that are easier to manage
- </li>
-</ul>
-<p>
- These factors help improve the overall quality of the system.
+ <mainDescription><p>
+ A use-case realization represents how a use case will be implemented in terms of collaborating objects. This artifact
+ can take various forms. It can include, for example, a textual description (a document), class diagrams of
+ participating classes and subsystems, and interaction diagrams (communication and sequence diagrams) that illustrate
+ the flow of interactions between class and subsystem instances.
+</p>
+<p>
+ The reason for separating the use-case realization from its use case is that doing so allows the use cases to be
+ managed separately from their realizations. This is particularly important for larger projects, or families of systems
+ where the same use cases can be designed differently in different products within the product family. Consider the case
+ of a family of telephone switches which have many use cases in common, but which design and implement them differently
+ according to product positioning, performance and price.
+</p>
+<p>
+ For larger projects, separating the use case and its realization allows changes to the design of the use case without
+ affecting the baselined use case itself.
+</p>
+<p>
+ In a model, a use-case realization is represented as a UML collaboration that groups the diagrams and other information
+ (such as textual descriptions) that form part of the use-case realization.
+</p>
+<p>
+ UML diagrams that&nbsp;support use-case realizations can be produced in an analysis context, a&nbsp;design context, or
+ both, depending on the needs of the project. For each use case in the use-case model, there&nbsp;can be&nbsp;a use-case
+ realization in the analysis/design model with a realization relationship to the use case. In UML this is shown as a
+ dashed arrow, with an arrowhead like a generalization relationship, indicating that a realization is a kind of
+ inheritance, as well as a dependency.<br />
+</p>
+<p align="center">
+ <img alt="Use Case Realizations" src="resources/ucrea1.gif" width="277" height="109" />
+</p>
+<p>
+ A use-case realization in the&nbsp;design can be traced to a use case in the use-case model.
+</p>
+<h4>
+ Class Diagrams Owned by a Use-Case Realization
+</h4>
+<p>
+ For each use-case realization there can be one or more class diagrams depicting its participating classes. A class and
+ its objects often participate in several use-case realizations. It is important&nbsp;while designing to coordinate all
+ the requirements on a class and its objects that different use-case realizations can have. The figure below shows an
+ analysis&nbsp;class diagram for the realization of the Receive Deposit Item use case. Note the use of
+ boundary-control-entity stereotypes to represent analysis classes (see <a class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/guidelines/entity_control_boundary_pattern_C4047897.html"
+ guid="_uF-QYEAhEdq_UJTvM1DM2Q">Guideline: Entity-Control-Boundary Pattern</a>).
+</p>
+<p align="center">
+ <img alt="Class diagram for the realization of Receive Deposit Item" src="resources/md_ucre3.gif" width="328"
+ height="213" />
+</p>
+<p align="center">
+ <strong>The use case Receive Deposit Item and its analysis-level class diagram</strong>.
+</p>
+<h4>
+ Communication and Sequence Diagrams Owned by a Use-Case Realization
+</h4>
+<p>
+ For each use-case realization there&nbsp;can be&nbsp;one or more interaction diagrams depicting its participating
+ objects and their interactions. There are two types of interaction diagrams: sequence diagrams and communication
+ diagrams. They express similar information, but show it in different ways. Sequence diagrams show the explicit sequence
+ of messages and are better when it is important to visualize the time ordering of messages, whereas communication
+ diagrams show the communication links between objects and are better for understanding all of the effects on a given
+ object and for algorithm design.
+</p>
+<p>
+ Realizing use cases through interaction diagrams helps to keep the design simple and cohesive. Assigning
+ responsibilities to classes on the basis of what the use-case scenario explicitly requires encourages the design to
+ contain the following:
+</p>
+<ul>
+ <li>
+ Only the functionality actually used in support of a use case scenario,
+ </li>
+ <li>
+ Functionality that can be tested through an associated test case,
+ </li>
+ <li>
+ Functionality that is more easily traceable to requirements and changes,
+ </li>
+ <li>
+ Explicitly declared class dependencies that are easier to manage.
+ </li>
+</ul>
+<p>
+ These factors help improve the overall quality of the system.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/guidelines/use_case_model.xmi b/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/guidelines/use_case_model.xmi
index 76400cd..1da4cf7 100644
--- a/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/guidelines/use_case_model.xmi
+++ b/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/guidelines/use_case_model.xmi
@@ -1,290 +1,290 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_AGvpcMM3EdmSIPI87WLu3g" name="uc_model,_0VAUsMlgEdmt3adZL5Dmdw" guid="_AGvpcMM3EdmSIPI87WLu3g" changeDate="2009-03-28T10:40:44.000-0700" version="1.0.0">
- <mainDescription><h3>
- Introduction
-</h3>
-<p>
- The key to successful iterative development is ensuring that the development team maximizes stakeholder value and
- minimizes risk early in the lifecycle, while minimizing re-work later.&nbsp; This imposes some constraints on how we
- develop the use-case model.
-</p>
-<p>
- At one extreme is the classical waterfall approach, which attempts to&nbsp;detail all of the requirements prior to
- design and implementation.&nbsp; This approach delays delivery of stakeholder value and risk reduction unnecessarily.
-</p>
-<p>
- At the other extreme is&nbsp;beginning development prior to understanding what the system must do.&nbsp; This approach
- results in significant, and costly, re-work later in the lifecycle.
-</p>
-<p>
- A better approach is to detail only those requirements which will be the focus of development in the next iteration (or
- two).&nbsp; Selection of these requirements is driven by value and risk, and thus requires as a minimum an abstract
- understanding of the "big-picture".
-</p>
-<p>
- The following discussion will outline the approach used to evolve the use-case model to achieve these goals.
-</p>
-<h3>
- <a id="How the Use-Case Model Evolves" name="How the Use-Case Model Evolves">How the Use-Case Model Evolves</a>
-</h3>
-<p>
- The recommended approach to evolving the use-case model takes a "breadth before depth" approach.&nbsp; In this
- approach, one identifies the actors and use cases and outlines them quickly.&nbsp; Based on this knowledge, one can
- then perform an initial assessment of risk and priorities and thus focus the effort of&nbsp;detailing&nbsp;the use
- cases on the right areas.
-</p>
-<h4>
- Inception
-</h4>
-<p>
- The purpose of inception is to understand the scope of the system.&nbsp; We need to understand the main purpose of the
- system, what is within the scope of the system, and what is external to the system.&nbsp; We must strive to list all
- the primary actors and use cases, however we don't have the luxury of being able to detail all of these requirements at
- this time.&nbsp; Strive to&nbsp;identify by name&nbsp;~80% of the primary actors and use cases and provide a brief
- description (one - three sentences) for each.
-</p>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <h5>
- Identify Stakeholders
- </h5>
- <p>
- Begin by listing all the external stakeholders for the system.&nbsp; These individuals will be the source of the
- requirements.
- </p>
- <h5>
- Identify Actors
- </h5>
- <p>
- Name and describe the primary actors.&nbsp; See <a class="elementLinkWithType"
- href="./../../../practice.tech.use_case_driven_dev.base/guidances/guidelines/identify_and_outline_actors_and_ucs_BB5516A9.html"
- guid="_eyL0wCu-EdqSxKAVa9kmvA">Guideline: Identify and Outline Actors and Use Cases</a>.
- </p>
- <h5>
- Identify Use Cases
- </h5>
- <p>
- For each actor, ask "what does this actor want to accomplish with the system"?&nbsp; This will reveal the primary
- use cases for the system.&nbsp; Name and describe each of these as you discover them.
- </p>
- <h5>
- Update the Use-Case Model
- </h5>
- <p>
- Update the use case model to capture the actor and use case names and brief description.&nbsp; Capture the
- relationship between the actors and use cases.
- </p>
- <h5>
- Outline the Basic Flows
- </h5>
- <p>
- For those use cases that are considered high priority by the stakeholders, or high risk by the development team,
- capture a step-by-step description of the Basic Flow.&nbsp; Don't worry about structuring the flow at this
- point.&nbsp; Focus on capturing the dialogue between the actor and the system and the key requirements for the
- system.
- </p>
- <h5>
- Identify Alternate Flows
- </h5>
- <p>
- As you work through the Basic Flows, ask: "What can go wrong?"; "What options are available at this point?";
- etc.&nbsp; These types of questions will reveal alternate flows.&nbsp; Capture these, giving each a name and brief
- description.&nbsp; Fight the urge to detail these alternate flows at this time.
- </p>
- <h5>
- Refactor the Use Case Model
- </h5>
- <p>
- Based on the Basic Flows you have identified, determine if there is common behavior that could be factored out into
- &lt;&lt;include&gt;&gt; use cases.&nbsp; Refactor the Use Case model accordingly.
- </p>
- <h5>
- Prioritize Use Cases
- </h5>
- <p>
- Given the abstract description you now have of the requirements, work with stakeholders to prioritize the use
- cases.&nbsp; This will be the primary input to iteration planning.
- </p>
-</blockquote>
-<h4>
- Elaboration
-</h4>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <p>
- The purpose of elaboration is to demonstrate the feasibility of&nbsp;the solution prior to committing additional
- resources.&nbsp; To be successful, one must demonstrate that stakeholder value can be delivered and that the risk
- of continuing is acceptable.&nbsp; We must strive to detail and implement ~20% of the scenarios.&nbsp; These
- scenarios must be selected to achieve good coverage of the architecture (for example, a vertical slice through the
- architecture, touching as many&nbsp;components and interfaces as possible, is preferred to elaborating the GUI
- only).
- </p>
- <h5>
- Detail Basic Flow
- </h5>
- <p>
- For those UC selected for the next iteration, spend the time to detail the basic flow now.&nbsp; See <a
- class="elementLinkWithType"
- href="./../../../practice.tech.use_case_driven_dev.base/guidances/guidelines/detail_ucs_and_scenarios_6BC56BB7.html"
- guid="_4BJ_YCxSEdqjsdw1QLH_6Q">Guideline: Detail Use Cases and Scenarios</a>.
- </p>
- <h5>
- Detail Alternate Flow
- </h5>
- <p>
- For those alternate flows selected for the next iteration, spend the time to detail the flows now.
- </p>
- <h5>
- Update the Use-Case Model
- </h5>
- <p>
- Update the Use-Case Model to capture any refinements made as a result of your work.&nbsp; Depending upon the
- complexity of the system, you might want to introduce packages to group the use cases in a logical manner to
- simplify communications, iteration planning, and parallel development.
- </p>
-</blockquote>
-<h4>
- Construction
-</h4>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <p>
- The purpose of construction is to incrementally deliver functionality (and value).&nbsp; Working from the iteration
- plan, continue detailing the remaining requirements.&nbsp; Shoot for completion of ~90 - ~95% of use cases by the
- end of construction.
- </p>
- <h5>
- Detail Basic Flows
- </h5>
- <p>
- For those UC selected for the next iteration, spend the time to detail the basic flow now.&nbsp; See <a
- class="elementLinkWithType"
- href="./../../../practice.tech.use_case_driven_dev.base/guidances/guidelines/detail_ucs_and_scenarios_6BC56BB7.html"
- guid="_4BJ_YCxSEdqjsdw1QLH_6Q">Guideline: Detail Use Cases and Scenarios</a>.
- </p>
- <h5>
- Detail Alternate Flows
- </h5>
- <p>
- For those alternate flows selected for the next iteration, spend the time to detail the flows now.
- </p>
- <h5>
- Update the Use-Case Model
- </h5>
- <p>
- Update the Use-Case Model to capture any refinements made as a result of your work.
- </p>
-</blockquote>
-<h4>
- Transition
-</h4>
-<p>
- The purpose of transition is to make the system operational in its intended environment.&nbsp; Some requirements will
- not be covered at this point.&nbsp; But the requirements must clearly not stress the design.&nbsp; The remaining ~5% to
- ~10% of use cases must be detailed and implemented in this phase.
-</p>
-<h3>
- <a id="Avoiding Functional Decomposition" name="Avoiding Functional Decomposition">Avoiding Functional
- Decomposition</a>
-</h3>
-<p>
- A common pitfall for those new to use-case models is to perform a&nbsp;functional decomposition of the system. This
- results in many small "use cases", that on their own do not deliver the "observable result of value" to the
- actor.&nbsp; To avoid this, watch for the following symptoms:
-</p>
-<ul>
- <li>
- <strong>Small</strong> use cases, meaning that the description of the flow of events is only one or a few
- sentences.
- </li>
- <li>
- <strong>Many</strong> use cases, meaning that the number of use cases is some multiple of a hundred, rather than a
- multiple of ten.
- </li>
- <li>
- Use-case names that are constructions such as "do this operation on this particular data" or "do this function with
- this particular data". For example, "Enter Personal Identification Number in an ATM machine" must not be modeled as
- a separate use case for the ATM machine, because no one would use the system to do just this. A use case is a
- complete flow of events that results in something of value to an actor.
- </li>
-</ul>
-<p>
- To avoid functional decomposition, make sure that the use-case model helps answer these kinds of questions:
-</p>
-<ul>
- <li>
- What is the context of the system?
- </li>
- <li>
- Why are you building this system?
- </li>
- <li>
- What does the user want the system to do?
- </li>
- <li>
- How&nbsp;do the users benefit from the system?
- </li>
-</ul>
-<h3>
- <a id="Structuring the Use-Case Model" name="Structuring the Use-Case Model">Structuring the Use-Case Model</a>
-</h3>
-<p>
- There are three main reasons for structuring the use-case model:
-</p>
-<ul>
- <li>
- To make the use cases easier to understand.
- </li>
- <li>
- To partition common behavior described within many use cases
- </li>
- <li>
- To make the use-case model easier to maintain.
- </li>
-</ul>
-<p>
- Structuring is not the first thing you do, however. There is no point in structuring the use cases until you know a bit
- more about their behavior than a one-sentence description. Establishing a step-by-step outline of the flow of events
- can assure your decisions are based on an accurate understanding of the behavior
-</p>
-<p>
- There are several advanced modeling concepts available in the literature for&nbsp;structuring the use-case model,
- however, following the principle of "keep-it-simple" only the most useful of these, namely the &lt;&lt;include&gt;&gt;
- relationship is discussed in this process.&nbsp; This relationship permits one to factor out common behavior into a
- separate use case that is "include" in other use cases.&nbsp; See <a class="elementLinkWithType"
- href="./../../../core.tech.common.extend_supp/guidances/concepts/use_case_model_CD178AF9.html"
- guid="_2jyfUAhVEduRe8TeoBmuGg">Concept: Use-Case Model</a>&nbsp;for more&nbsp;details.
-</p>
-<p>
- Another aspect of&nbsp;structuring the use-case model for easier understanding is grouping the use cases into packages.
- The use-case model can be organized as a hierarchy of use-case packages. For more information on use-case packages, see
- <a class="elementLinkWithType"
- href="./../../../core.tech.common.extend_supp/guidances/concepts/use_case_model_CD178AF9.html"
- guid="_2jyfUAhVEduRe8TeoBmuGg">Concept: Use-Case Model</a>.
-</p>
-<h3>
- <a id="Use Cases Are Always Related to Actors" name="Use Cases Are Always Related to Actors">Relationship Between Use
- Cases and Actors</a>
-</h3>
-<p>
- Running each use case includes communication with one or more actors. A use-case instance is always started by an actor
- asking the system to do something. This implies that every use case must have communicates-associations with actors.
- The reason for this rule is to enforce that the system provides only the functionality that users need and nothing
- else. Having use cases that no one requests is an indication that something is wrong in the use-case model or in the
- requirements.
-</p>
-<p>
- However, there are some exceptions to this rule:
-</p>
-<ul>
- <li>
- An&nbsp;"included" use case might not interact with an actor if the base use case does.
- </li>
- <li>
- A use case can be initiated according to a schedule (for example, once a week or once a day), which means that the
- system clock is the initiator. The system clock is internal to the system; therefore, the use case is not initiated
- by an actor but by an internal system event. If no other actor interaction occurs in the use case, it will not have
- any associations to actors. However, for clarity, you can use "time" as an actor to show how the use case is
- initiated in your use-case diagrams. <strong>CAUTION:</strong> if you have a lot of "time" actors in your model,
- challenge them.&nbsp; Perhaps you missed a real actor, such as an administrator responsible for scheduling reports,
- etc.
- </li>
+ <mainDescription><h3>
+ Introduction
+</h3>
+<p>
+ The key to successful iterative development is ensuring that the development team maximizes stakeholder value and
+ minimizes risk early in the lifecycle, while minimizing re-work later.&nbsp; This imposes some constraints on how we
+ develop the use-case model.
+</p>
+<p>
+ At one extreme is the classical waterfall approach, which attempts to&nbsp;detail all of the requirements prior to
+ design and implementation.&nbsp; This approach delays delivery of stakeholder value and risk reduction unnecessarily.
+</p>
+<p>
+ At the other extreme is&nbsp;beginning development prior to understanding what the system must do.&nbsp; This approach
+ results in significant, and costly, re-work later in the lifecycle.
+</p>
+<p>
+ A better approach is to detail only those requirements which will be the focus of development in the next iteration (or
+ two).&nbsp; Selection of these requirements is driven by value and risk, and thus requires as a minimum an abstract
+ understanding of the "big-picture".
+</p>
+<p>
+ The following discussion will outline the approach used to evolve the use-case model to achieve these goals.
+</p>
+<h3>
+ <a id="How the Use-Case Model Evolves" name="How the Use-Case Model Evolves">How the Use-Case Model Evolves</a>
+</h3>
+<p>
+ The recommended approach to evolving the use-case model takes a "breadth before depth" approach.&nbsp; In this
+ approach, one identifies the actors and use cases and outlines them quickly.&nbsp; Based on this knowledge, one can
+ then perform an initial assessment of risk and priorities and thus focus the effort of&nbsp;detailing&nbsp;the use
+ cases on the right areas.
+</p>
+<h4>
+ Inception
+</h4>
+<p>
+ The purpose of inception is to understand the scope of the system.&nbsp; We need to understand the main purpose of the
+ system, what is within the scope of the system, and what is external to the system.&nbsp; We must strive to list all
+ the primary actors and use cases, however we don't have the luxury of being able to detail all of these requirements at
+ this time.&nbsp; Strive to&nbsp;identify by name&nbsp;~80% of the primary actors and use cases and provide a brief
+ description (one - three sentences) for each.
+</p>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <h5>
+ Identify Stakeholders
+ </h5>
+ <p>
+ Begin by listing all the external stakeholders for the system.&nbsp; These individuals will be the source of the
+ requirements.
+ </p>
+ <h5>
+ Identify Actors
+ </h5>
+ <p>
+ Name and describe the primary actors.&nbsp; See <a class="elementLinkWithType"
+ href="./../../../practice.tech.use_case_driven_dev.base/guidances/guidelines/identify_and_outline_actors_and_ucs_BB5516A9.html"
+ guid="_eyL0wCu-EdqSxKAVa9kmvA">Guideline: Identify and Outline Actors and Use Cases</a>.
+ </p>
+ <h5>
+ Identify Use Cases
+ </h5>
+ <p>
+ For each actor, ask "what does this actor want to accomplish with the system"?&nbsp; This will reveal the primary
+ use cases for the system.&nbsp; Name and describe each of these as you discover them.
+ </p>
+ <h5>
+ Update the Use-Case Model
+ </h5>
+ <p>
+ Update the use case model to capture the actor and use case names and brief description.&nbsp; Capture the
+ relationship between the actors and use cases.
+ </p>
+ <h5>
+ Outline the Basic Flows
+ </h5>
+ <p>
+ For those use cases that are considered high priority by the stakeholders, or high risk by the development team,
+ capture a step-by-step description of the Basic Flow.&nbsp; Don't worry about structuring the flow at this
+ point.&nbsp; Focus on capturing the dialogue between the actor and the system and the key requirements for the
+ system.
+ </p>
+ <h5>
+ Identify Alternate Flows
+ </h5>
+ <p>
+ As you work through the Basic Flows, ask: "What can go wrong?"; "What options are available at this point?";
+ etc.&nbsp; These types of questions will reveal alternate flows.&nbsp; Capture these, giving each a name and brief
+ description.&nbsp; Fight the urge to detail these alternate flows at this time.
+ </p>
+ <h5>
+ Refactor the Use Case Model
+ </h5>
+ <p>
+ Based on the Basic Flows you have identified, determine if there is common behavior that could be factored out into
+ &lt;&lt;include&gt;&gt; use cases.&nbsp; Refactor the Use Case model accordingly.
+ </p>
+ <h5>
+ Prioritize Use Cases
+ </h5>
+ <p>
+ Given the abstract description you now have of the requirements, work with stakeholders to prioritize the use
+ cases.&nbsp; This will be the primary input to iteration planning.
+ </p>
+</blockquote>
+<h4>
+ Elaboration
+</h4>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ The purpose of elaboration is to demonstrate the feasibility of&nbsp;the solution prior to committing additional
+ resources.&nbsp; To be successful, one must demonstrate that stakeholder value can be delivered and that the risk
+ of continuing is acceptable.&nbsp; We must strive to detail and implement ~20% of the scenarios.&nbsp; These
+ scenarios must be selected to achieve good coverage of the architecture (for example, a vertical slice through the
+ architecture, touching as many&nbsp;components and interfaces as possible, is preferred to elaborating the GUI
+ only).
+ </p>
+ <h5>
+ Detail Basic Flow
+ </h5>
+ <p>
+ For those UC selected for the next iteration, spend the time to detail the basic flow now.&nbsp; See <a
+ class="elementLinkWithType"
+ href="./../../../practice.tech.use_case_driven_dev.base/guidances/guidelines/detail_ucs_and_scenarios_6BC56BB7.html"
+ guid="_4BJ_YCxSEdqjsdw1QLH_6Q">Guideline: Detail Use Cases and Scenarios</a>.
+ </p>
+ <h5>
+ Detail Alternate Flow
+ </h5>
+ <p>
+ For those alternate flows selected for the next iteration, spend the time to detail the flows now.
+ </p>
+ <h5>
+ Update the Use-Case Model
+ </h5>
+ <p>
+ Update the Use-Case Model to capture any refinements made as a result of your work.&nbsp; Depending upon the
+ complexity of the system, you might want to introduce packages to group the use cases in a logical manner to
+ simplify communications, iteration planning, and parallel development.
+ </p>
+</blockquote>
+<h4>
+ Construction
+</h4>
+<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+ <p>
+ The purpose of construction is to incrementally deliver functionality (and value).&nbsp; Working from the iteration
+ plan, continue detailing the remaining requirements.&nbsp; Shoot for completion of ~90 - ~95% of use cases by the
+ end of construction.
+ </p>
+ <h5>
+ Detail Basic Flows
+ </h5>
+ <p>
+ For those UC selected for the next iteration, spend the time to detail the basic flow now.&nbsp; See <a
+ class="elementLinkWithType"
+ href="./../../../practice.tech.use_case_driven_dev.base/guidances/guidelines/detail_ucs_and_scenarios_6BC56BB7.html"
+ guid="_4BJ_YCxSEdqjsdw1QLH_6Q">Guideline: Detail Use Cases and Scenarios</a>.
+ </p>
+ <h5>
+ Detail Alternate Flows
+ </h5>
+ <p>
+ For those alternate flows selected for the next iteration, spend the time to detail the flows now.
+ </p>
+ <h5>
+ Update the Use-Case Model
+ </h5>
+ <p>
+ Update the Use-Case Model to capture any refinements made as a result of your work.
+ </p>
+</blockquote>
+<h4>
+ Transition
+</h4>
+<p>
+ The purpose of transition is to make the system operational in its intended environment.&nbsp; Some requirements will
+ not be covered at this point.&nbsp; But the requirements must clearly not stress the design.&nbsp; The remaining ~5% to
+ ~10% of use cases must be detailed and implemented in this phase.
+</p>
+<h3>
+ <a id="Avoiding Functional Decomposition" name="Avoiding Functional Decomposition">Avoiding Functional
+ Decomposition</a>
+</h3>
+<p>
+ A common pitfall for those new to use-case models is to perform a&nbsp;functional decomposition of the system. This
+ results in many small "use cases", that on their own do not deliver the "observable result of value" to the
+ actor.&nbsp; To avoid this, watch for the following symptoms:
+</p>
+<ul>
+ <li>
+ <strong>Small</strong> use cases, meaning that the description of the flow of events is only one or a few
+ sentences.
+ </li>
+ <li>
+ <strong>Many</strong> use cases, meaning that the number of use cases is some multiple of a hundred, rather than a
+ multiple of ten.
+ </li>
+ <li>
+ Use-case names that are constructions such as "do this operation on this particular data" or "do this function with
+ this particular data". For example, "Enter Personal Identification Number in an ATM machine" must not be modeled as
+ a separate use case for the ATM machine, because no one would use the system to do just this. A use case is a
+ complete flow of events that results in something of value to an actor.
+ </li>
+</ul>
+<p>
+ To avoid functional decomposition, make sure that the use-case model helps answer these kinds of questions:
+</p>
+<ul>
+ <li>
+ What is the context of the system?
+ </li>
+ <li>
+ Why are you building this system?
+ </li>
+ <li>
+ What does the user want the system to do?
+ </li>
+ <li>
+ How&nbsp;do the users benefit from the system?
+ </li>
+</ul>
+<h3>
+ <a id="Structuring the Use-Case Model" name="Structuring the Use-Case Model">Structuring the Use-Case Model</a>
+</h3>
+<p>
+ There are three main reasons for structuring the use-case model:
+</p>
+<ul>
+ <li>
+ To make the use cases easier to understand.
+ </li>
+ <li>
+ To partition common behavior described within many use cases.
+ </li>
+ <li>
+ To make the use-case model easier to maintain.
+ </li>
+</ul>
+<p>
+ Structuring is not the first thing you do, however. There is no point in structuring the use cases until you know a bit
+ more about their behavior than a one-sentence description. Establishing a step-by-step outline of the flow of events
+ can assure your decisions are based on an accurate understanding of the behavior
+</p>
+<p>
+ There are several advanced modeling concepts available in the literature for&nbsp;structuring the use-case model,
+ however, following the principle of "keep-it-simple" only the most useful of these, namely the &lt;&lt;include&gt;&gt;
+ relationship is discussed in this process.&nbsp; This relationship permits one to factor out common behavior into a
+ separate use case that is "include" in other use cases.&nbsp; See <a class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/use_case_model_CD178AF9.html"
+ guid="_2jyfUAhVEduRe8TeoBmuGg">Concept: Use-Case Model</a>&nbsp;for more&nbsp;details.
+</p>
+<p>
+ Another aspect of&nbsp;structuring the use-case model for easier understanding is grouping the use cases into packages.
+ The use-case model can be organized as a hierarchy of use-case packages. For more information on use-case packages, see
+ <a class="elementLinkWithType"
+ href="./../../../core.tech.common.extend_supp/guidances/concepts/use_case_model_CD178AF9.html"
+ guid="_2jyfUAhVEduRe8TeoBmuGg">Concept: Use-Case Model</a>.
+</p>
+<h3>
+ <a id="Use Cases Are Always Related to Actors" name="Use Cases Are Always Related to Actors">Relationship Between Use
+ Cases and Actors</a>
+</h3>
+<p>
+ Running each use case includes communication with one or more actors. A use-case instance is always started by an actor
+ asking the system to do something. This implies that every use case must have communicates-associations with actors.
+ The reason for this rule is to enforce that the system provides only the functionality that users need and nothing
+ else. Having use cases that no one requests is an indication that something is wrong in the use-case model or in the
+ requirements.
+</p>
+<p>
+ However, there are some exceptions to this rule:
+</p>
+<ul>
+ <li>
+ An&nbsp;"included" use case might not interact with an actor if the base use case does.
+ </li>
+ <li>
+ A use case can be initiated according to a schedule (for example, once a week or once a day), which means that the
+ system clock is the initiator. The system clock is internal to the system; therefore, the use case is not initiated
+ by an actor but by an internal system event. If no other actor interaction occurs in the use case, it will not have
+ any associations to actors. However, for clarity, you can use "time" as an actor to show how the use case is
+ initiated in your use-case diagrams. <strong>CAUTION:</strong> if you have a lot of "time" actors in your model,
+ challenge them.&nbsp; Perhaps you missed a real actor, such as an administrator responsible for scheduling reports,
+ etc.
+ </li>
</ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/roadmaps/how_to_adopt.xmi b/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/roadmaps/how_to_adopt.xmi
index 758cf36..bc6428d 100644
--- a/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/roadmaps/how_to_adopt.xmi
+++ b/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/roadmaps/how_to_adopt.xmi
@@ -1,36 +1,36 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-3WNAtOgFvwsJtFvhDugsVA" name="new_roadmap,_PJKZkMRfEdyBt8f9agIerg" guid="-3WNAtOgFvwsJtFvhDugsVA" changeDate="2009-03-28T11:00:54.000-0700" version="7.2.0">
- <mainDescription><h3>
- Getting Started
-</h3>
-<p>
- After getting some basic familiarity with the concept of use cases, consider identifying use cases in a workshop
- environment, led by someone experienced in writing use cases. Detail one or a few example scenarios to serve as an
- example for other use case authors, to set a standard for format, style, and level of detail.
-</p>
-<p>
- Some teams prefer to identify all of the use cases and actors first, capturing those in a UML use-case diagram, or
- other sort of visual notation. Then they iteratively detail the use cases assigned to the current or next iteration, by
- outlining the steps in the use case main flow and alternative flows. When these steps and flows are detailed in the
- amount needed for development to start, it is useful to group flows in what is called use-case scenarios. Some teams
- prefer to identify scenarios first and then write the use cases in a more structured way later, by grouping related
- scenarios together. Scenarios can be used as a unit of work assignment and progress measurement on how use cases are
- analyzed, designed, implemented, and tested throughout the project.
-</p>
-<p>
- As you get more comfortable with this practice, consider supplementing your use cases with storyboards, activity
- diagrams, and additional requirements techniques. Modeling use cases in UML diagrams or in modeling tools can be
- helpful when there are lots of use cases, but start with a focus on the text and some key scenarios.
-</p>
-<h4>
- Common pitfalls
-</h4>
-<p>
- Try to avoid applying functional decomposition approach to use cases. That can lead you to find too many use cases, and
- use-case descriptions that are a half-page or less in length. On the other hand, finding too few use cases can result
- in overloaded use cases. It can lead to long and complex use-case descriptions. Try to find a balance that makes sense
- for your team, stakeholders, and the type of system that you are developing. There are different opinions about what is
- the appropriate number of use cases for a system. The suggestion is that even large, complex systems will have no more
- than a couple dozen use cases on average.
+ <mainDescription><h3>
+ Getting Started
+</h3>
+<p>
+ After getting some basic familiarity with the concept of use cases, consider identifying use cases in a workshop
+ environment, led by someone experienced in writing use cases. Detail one or a few example scenarios to serve as an
+ example for other use case authors, to set a standard for format, style, and level of detail.
+</p>
+<p>
+ Some teams prefer to identify all of the use cases and actors first, capturing those in a UML use-case diagram, or
+ other sort of visual notation. Then they iteratively detail the use cases assigned to the current or next iteration, by
+ outlining the steps in the use case main flow and alternative flows. When these steps and flows are detailed in the
+ amount needed for development to start, it is useful to group flows in what is called use-case scenarios. Some teams
+ prefer to identify scenarios first and then write the use cases in a more structured way later, by grouping related
+ scenarios together. Scenarios can be used as a unit of work assignment and progress measurement on how use cases are
+ analyzed, designed, implemented, and tested throughout the project.
+</p>
+<p>
+ As you get more comfortable with this practice, consider supplementing your use cases with storyboards, activity
+ diagrams, and additional requirements techniques. Modeling use cases in UML diagrams or in modeling tools can be
+ helpful when there are lots of use cases, but start with a focus on the text and some key scenarios.
+</p>
+<h4>
+ Common pitfalls
+</h4>
+<p>
+ Try to avoid applying functional decomposition approach to use cases. That can lead you to find too many use cases, and
+ use-case descriptions that are a half-page or less in length. On the other hand, finding too few use cases can result
+ in overloaded use cases. It can lead to long and complex use-case descriptions. Try to find a balance that makes sense
+ for your team, stakeholders, and the type of system that you are developing. There are different opinions about what is
+ the appropriate number of use cases for a system. The suggestion is that even large, complex systems will have no more
+ than a couple dozen use cases on average.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/termdefinitions/system_wide_requirement.xmi b/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/termdefinitions/system_wide_requirement.xmi
index f77de18..8f1d5b1 100644
--- a/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/termdefinitions/system_wide_requirement.xmi
+++ b/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/termdefinitions/system_wide_requirement.xmi
@@ -1,6 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-ketzwgDgY82DMyfuHqu3Cw" name=",_U_olUEvDEdunZcj9T5hrMQ" guid="-ketzwgDgY82DMyfuHqu3Cw" changeDate="2006-12-21T09:32:14.000-0800" version="1.0.0">
- <mainDescription>System-wide requirements are requirements that&nbsp;define necessary system quality attributes&nbsp;such as performance,
-usability and reliability, as well as global functional requirements&nbsp;that are not captured in behavioral requirements
+ <mainDescription>System-wide requirements are requirements that&nbsp;define necessary system quality attributes&nbsp;such as performance,
+usability and reliability, as well as global functional requirements&nbsp;that are not captured in behavioral requirements
artifacts such as use-cases.</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/termdefinitions/use_case_scenario.xmi b/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/termdefinitions/use_case_scenario.xmi
index eb495d8..ebb5476 100644
--- a/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/termdefinitions/use_case_scenario.xmi
+++ b/epf_prac_151/practice.tech.use_case_driven_dev.base/guidances/termdefinitions/use_case_scenario.xmi
@@ -1,6 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-t3jNM5ZWkYtzB8A4Chz2Vw" name=",_oXmYMEvGEdunZcj9T5hrMQ" guid="-t3jNM5ZWkYtzB8A4Chz2Vw" version="7.2.0">
- <mainDescription>Represents specific instances of the use case that correspond to specific inputs from the Actor or to specific conditions
-in the environment. Each scenario describes alternate ways that the system provides a behavior, or it may describe failure
+ <mainDescription>Represents specific instances of the use case that correspond to specific inputs from the Actor or to specific conditions
+in the environment. Each scenario describes alternate ways that the system provides a behavior, or it may describe failure
or exception cases</mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.tech.use_case_driven_dev.base/tasks/detail_system_wide_requirements.xmi b/epf_prac_151/practice.tech.use_case_driven_dev.base/tasks/detail_system_wide_requirements.xmi
index 2d815cc..10b71aa 100644
--- a/epf_prac_151/practice.tech.use_case_driven_dev.base/tasks/detail_system_wide_requirements.xmi
+++ b/epf_prac_151/practice.tech.use_case_driven_dev.base/tasks/detail_system_wide_requirements.xmi
@@ -1,8 +1,8 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:TaskDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-9sNgONA1WJCxf12B40uDgw" name="detail_system_wide_requirements,_4z8Z0EbEEdyx8quJU3Grxg" guid="-9sNgONA1WJCxf12B40uDgw" changeDate="2007-11-14T10:42:54.000-0800" version="1.0.0">
- <keyConsiderations>To avoid unnecessary rework, only those requirements that are scheduled for implementation in the near term (in the next
+ <keyConsiderations>To avoid unnecessary rework, only those requirements that are scheduled for implementation in the near term (in the next
iteration or two)&nbsp;must be detailed.</keyConsiderations>
- <sections xmi:id="_4z8Z1EbEEdyx8quJU3Grxg" name="Detail system-wide requirements " guid="_4z8Z1EbEEdyx8quJU3Grxg">
+ <sections xmi:id="_4z8Z1EbEEdyx8quJU3Grxg" name="Detail system-wide requirements" guid="_4z8Z1EbEEdyx8quJU3Grxg">
<sectionDescription><p>
Some&nbsp;system-wide requirements&nbsp;might need to be clarified or described in more detail.&nbsp;New
requirements&nbsp;may&nbsp;be discovered&nbsp;while the use cases and scenarios are detailed, and new requirements may
@@ -21,6 +21,6 @@
consistency with the&nbsp;agreed vision.&nbsp;Assess quality and identify any required changes.
</p></sectionDescription>
</sections>
- <purpose>The purpose of this task is to describe one or more system-wide requirements in sufficient detail to validate understanding
+ <purpose>The purpose of this task is to describe one or more system-wide requirements in sufficient detail to validate understanding
of the requirements, to ensure concurrence with stakeholder expectations, and to permit software development to begin.</purpose>
</org.eclipse.epf.uma:TaskDescription>
diff --git a/epf_prac_151/practice.tech.use_case_driven_dev.base/tasks/detail_use_case_scenarios.ucm.xmi b/epf_prac_151/practice.tech.use_case_driven_dev.base/tasks/detail_use_case_scenarios.ucm.xmi
index d49e6b7..c726bd3 100644
--- a/epf_prac_151/practice.tech.use_case_driven_dev.base/tasks/detail_use_case_scenarios.ucm.xmi
+++ b/epf_prac_151/practice.tech.use_case_driven_dev.base/tasks/detail_use_case_scenarios.ucm.xmi
@@ -2,10 +2,19 @@
<org.eclipse.epf.uma:TaskDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-locCQOxOUM8zej2tBD6M6Q" name="detail_use_case_scenarios.ucm,_-pOLIEbEEdyx8quJU3Grxg" guid="-locCQOxOUM8zej2tBD6M6Q" version="1.0.0">
<sections xmi:id="_-pOLIUbEEdyx8quJU3Grxg" name="Update Use-Case Model" guid="_-pOLIUbEEdyx8quJU3Grxg">
<sectionDescription><p>
- Based on your work detailing use cases and scenarios, update the <a class="elementLink" href="./../../core.tech.common.extend_supp/workproducts/use_case_model_85965D1B.html" guid="_W2SgEDR5EdutE_HNDTJk5Q">Use-Case Model</a>.&nbsp;Add, remove or update&nbsp;<a class="elementLinkWithUserText" href="./../../core.tech.common.extend_supp/guidances/concepts/actor_411726C.html" guid="_zGqO0MDpEduTGJ8i4u8TMw">Actors</a>
- and <a class="elementLink" href="./../../core.tech.common.extend_supp/workproducts/use_case_22BE66E2.html" guid="_0VGbUMlgEdmt3adZL5Dmdw">Use Case</a>s as required.&nbsp;<br />
- For more information on creating and structuring your use case model see <a class="elementLinkWithType" href="./../../practice.tech.use_case_driven_dev.base/guidances/guidelines/use_case_model_4C64E97D.html" guid="_0VAUsMlgEdmt3adZL5Dmdw">Guideline: Use-Case Model</a>.&nbsp;For assistance in assessing the quality of your
- use-case model see <a class="elementLinkWithType" href="./../../core.tech.common.extend_supp/guidances/checklists/use_case_model_27A2D1CF.html" guid="_0U6OEMlgEdmt3adZL5Dmdw">Checklist: Use-Case Model</a>.
+ Based on your work detailing use cases and scenarios, update the <a class="elementLink"
+ href="./../../core.tech.common.extend_supp/workproducts/use_case_model_85965D1B.html"
+ guid="_W2SgEDR5EdutE_HNDTJk5Q">Use-Case Model</a>.&nbsp;Add, remove or update&nbsp;<a class="elementLinkWithUserText"
+ href="./../../core.tech.common.extend_supp/guidances/concepts/actor_411726C.html"
+ guid="_zGqO0MDpEduTGJ8i4u8TMw">Actors</a> and <a class="elementLink"
+ href="./../../core.tech.common.extend_supp/workproducts/use_case_22BE66E2.html" guid="_0VGbUMlgEdmt3adZL5Dmdw">Use
+ Case</a>s as required.&nbsp;<br />
+ For more information on creating and structuring your use case model see <a class="elementLinkWithType"
+ href="./../../practice.tech.use_case_driven_dev.base/guidances/guidelines/use_case_model_4C64E97D.html"
+ guid="_0VAUsMlgEdmt3adZL5Dmdw">Guideline: Use-Case Model</a>.&nbsp;For assistance in assessing the quality of your
+ use-case model see <a class="elementLinkWithType"
+ href="./../../core.tech.common.extend_supp/guidances/checklists/use_case_model_27A2D1CF.html"
+ guid="_0U6OEMlgEdmt3adZL5Dmdw">Checklist: Use-Case Model</a>.
</p></sectionDescription>
</sections>
</org.eclipse.epf.uma:TaskDescription>
diff --git a/epf_prac_151/practice.tech.use_case_driven_dev.base/tasks/detail_use_case_scenarios.xmi b/epf_prac_151/practice.tech.use_case_driven_dev.base/tasks/detail_use_case_scenarios.xmi
index 62cb984..c8c7e77 100644
--- a/epf_prac_151/practice.tech.use_case_driven_dev.base/tasks/detail_use_case_scenarios.xmi
+++ b/epf_prac_151/practice.tech.use_case_driven_dev.base/tasks/detail_use_case_scenarios.xmi
@@ -1,11 +1,11 @@
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:TaskDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-oFAa8Uu6tr_GkE_E0iycdQ" name="detail_use_case_scenarios,_SL7N0LPdEduocbW-TPTq7A" guid="-oFAa8Uu6tr_GkE_E0iycdQ" changeDate="2007-12-18T02:40:22.000-0800" changeDescription="Review comments:||1. Step 2 was a copy of step 1.|2. Step 1 - excessive linking - remove 2nd paragraph|" version="7.1.0">
- <keyConsiderations><p>
- To avoid unnecessary rework, only those use-case scenarios that are scheduled for implementation in the near term (in
- the next iteration or two)&nbsp;must be detailed.&nbsp;
-</p>
-<p>
- Not all use-case scenarios require detailing.
+ <keyConsiderations><p>
+ To avoid unnecessary rework, only those use-case scenarios that are scheduled for implementation in the near term (in
+ the next iteration or two)&nbsp;must be detailed.&nbsp;
+</p>
+<p>
+ Not all use-case scenarios require detailing.
</p></keyConsiderations>
<sections xmi:id="_fAWPkJLZEdyk6dG0ehkW5Q" name="Detail use cases and scenarios" guid="_fAWPkJLZEdyk6dG0ehkW5Q">
<sectionDescription><p>
@@ -29,6 +29,6 @@
consistency with the agreed vision.&nbsp;Assess quality and identify any required changes.
</p></sectionDescription>
</sections>
- <purpose>The purpose of this task is to describe&nbsp;use-case scenarios in sufficient detail to validate understanding of the
+ <purpose>The purpose of this task is to describe&nbsp;use-case scenarios in sufficient detail to validate understanding of the
requirements, to ensure concurrence with stakeholder expectations, and to permit software development to begin.</purpose>
</org.eclipse.epf.uma:TaskDescription>
diff --git a/epf_prac_151/practice.tech.use_case_driven_dev.base/tasks/identify_and_outline_requirements.xmi b/epf_prac_151/practice.tech.use_case_driven_dev.base/tasks/identify_and_outline_requirements.xmi
index 8915d27..c99777d 100644
--- a/epf_prac_151/practice.tech.use_case_driven_dev.base/tasks/identify_and_outline_requirements.xmi
+++ b/epf_prac_151/practice.tech.use_case_driven_dev.base/tasks/identify_and_outline_requirements.xmi
@@ -1,5 +1,5 @@
<?xml version="1.0" encoding="UTF-8"?>
-<org.eclipse.epf.uma:TaskDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmi:id="_P9iS8PV_EdmdHa9MmVPgqQ" name="identify_and_outline_requirements,_P9cMUPV_EdmdHa9MmVPgqQ" guid="_P9iS8PV_EdmdHa9MmVPgqQ" changeDate="2008-02-11T02:20:35.000-0800" changeDescription="We need to solve the relationship to work items list" version="1.0.0">
+<org.eclipse.epf.uma:TaskDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_P9iS8PV_EdmdHa9MmVPgqQ" name="identify_and_outline_requirements,_P9cMUPV_EdmdHa9MmVPgqQ" guid="_P9iS8PV_EdmdHa9MmVPgqQ" changeDate="2008-02-11T02:20:35.000-0800" changeDescription="We need to solve the relationship to work items list" version="1.0.0">
<sections xmi:id="_ckG-cCY-EdqNHcQ-rAojXw" name="Gather information" guid="_ckG-cCY-EdqNHcQ-rAojXw">
<sectionDescription><p>
Use various techniques to make gathering requirements easier. Face-to-face meetings with stakeholders is the most
@@ -16,7 +16,7 @@
<sectionDescription>If there are ambiguous or domain-specific terms that need to be clearly defined, make sure you work closely with
stakeholders&nbsp;to capture these&nbsp;terms in the glossary and that you use these terms consistently.</sectionDescription>
</sections>
- <sections xmi:id="_fDbgkCY-EdqNHcQ-rAojXw" name="Identify the types of requirements relevant to your system " guid="_fDbgkCY-EdqNHcQ-rAojXw">
+ <sections xmi:id="_fDbgkCY-EdqNHcQ-rAojXw" name="Identify the types of requirements relevant to your system" guid="_fDbgkCY-EdqNHcQ-rAojXw">
<sectionDescription><p>
Requirements can be broadly classified as either functional or non-functional requirements. The former specify what the
system must do. The latter specify constraints on the solution such as usability, reliability, performance,
@@ -39,7 +39,7 @@
guid="_eyL0wCu-EdqSxKAVa9kmvA">Identify and Outline Actors and Use Cases</a> for more information.
</p></sectionDescription>
</sections>
- <sections xmi:id="_Ql45gEI6Edyrh7YaMjqrlA" name="Identify and capture system-wide requirements " guid="_Ql45gEI6Edyrh7YaMjqrlA">
+ <sections xmi:id="_Ql45gEI6Edyrh7YaMjqrlA" name="Identify and capture system-wide requirements" guid="_Ql45gEI6Edyrh7YaMjqrlA">
<sectionDescription><p>
Collaborate with stakeholders to identify and capture&nbsp;the system-wide requirements relevant&nbsp;to your system.
Capture references to these requirements with other project to-do items so that you can prioritize the work.
@@ -54,9 +54,9 @@
<sectionDescription>Conduct a review&nbsp;of the&nbsp;requirements with relevant stakeholders and the development team to ensure consistency
with the agreed vision, assess quality, and identify any required changes.</sectionDescription>
</sections>
- <purpose>The purpose of this task is to identify and capture functional and non-functional requirements for the system. These
-requirements form the basis of communication and agreement between the stakeholders and the development team on what the
-system must do to satisfy stakeholder needs. The goal is to understand the requirements at a high-level so that the initial
-scope of work can be determined.&nbsp;Further analysis will be performed to detail these requirements prior to
+ <purpose>The purpose of this task is to identify and capture functional and non-functional requirements for the system. These
+requirements form the basis of communication and agreement between the stakeholders and the development team on what the
+system must do to satisfy stakeholder needs. The goal is to understand the requirements at a high-level so that the initial
+scope of work can be determined.&nbsp;Further analysis will be performed to detail these requirements prior to
implementation.</purpose>
</org.eclipse.epf.uma:TaskDescription>
