This commit was manufactured by cvs2svn to create tag
'before_importing_dsdm_plugin'.
diff --git a/Scrum French/.cvsignore b/Scrum French/.cvsignore
deleted file mode 100644
index b30de62..0000000
--- a/Scrum French/.cvsignore
+++ /dev/null
@@ -1,2 +0,0 @@
-.lock
-.project
diff --git a/Scrum French/Scrum/about.html b/Scrum French/Scrum/about.html
deleted file mode 100644
index 6040025..0000000
--- a/Scrum French/Scrum/about.html
+++ /dev/null
@@ -1,9 +0,0 @@
-
-<span style="font-weight: bold; font-family: Arial Narrow;">Claude Aubry</span><br/>
-<span style="font-weight: bold; color: rgb(255, 102, 0); font-family: Arial Narrow;">Consultant Méthodes Agiles</span><span style="font-family: Arial Narrow;">
-</span>
-<br/><small style="font-family: Arial Narrow;">
-<span style="color: rgb(102, 102, 102);">Mobile : 06 60 646 946</span>
-<br/>
-<a href="http://scrum.aubryconseil.com">Blog</a> -
-<a href="http://www.aubryconseil.com/">Web</a>
\ No newline at end of file
diff --git a/Scrum French/Scrum/customcategories/Intro.xmi b/Scrum French/Scrum/customcategories/Intro.xmi
deleted file mode 100644
index aa49ac4..0000000
--- a/Scrum French/Scrum/customcategories/Intro.xmi
+++ /dev/null
@@ -1,4 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-juIDa_fXi2K1BE5NTblPow" name="new_custom_category,_s8y1UABREdu3o4yroaI-tA" guid="-juIDa_fXi2K1BE5NTblPow" changeDate="2006-12-04T21:46:12.515+0100">
- <mainDescription>Ce site décrit l'utilisation de Scrum</mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum French/Scrum/customcategories/Scrum Elements.xmi b/Scrum French/Scrum/customcategories/Scrum Elements.xmi
deleted file mode 100644
index 35e8dc5..0000000
--- a/Scrum French/Scrum/customcategories/Scrum Elements.xmi
+++ /dev/null
@@ -1,2 +0,0 @@
-<?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.3/uma.ecore" xmi:id="-zS9h38tmK4L-U9kbgkpGKQ" name="Eléments de Scrum,_nF6fgALYEduFv7wnrO7SvQ" guid="-zS9h38tmK4L-U9kbgkpGKQ" changeDate="2006-07-16T15:44:25.338+0200"/>
diff --git a/Scrum French/Scrum/deliveryprocesses/Scrum/content.xmi b/Scrum French/Scrum/deliveryprocesses/Scrum/content.xmi
deleted file mode 100644
index c97db24..0000000
--- a/Scrum French/Scrum/deliveryprocesses/Scrum/content.xmi
+++ /dev/null
@@ -1,83 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0">
- <org.eclipse.epf.uma:DeliveryProcessDescription xmi:id="-16dzhVoCex78V2iCDZVx0w" name="Scrum,_9llsAQAvEdubGMceRDupFQ" guid="-16dzhVoCex78V2iCDZVx0w">
- <mainDescription>La production d’une version du logiciel (<a class="elementLink"
-href="./../../Scrum/guidances/termdefinitions/Release,_AIB9gIHrEduFs9jH8xc4xw.html"
-guid="_AIB9gIHrEduFs9jH8xc4xw">Release</a>) se fait en général en quelques mois. Les fonctionnalités demandées pour la
-release sont collectées dans le backlog de produit et classées par priorité. Le directeur de produit est responsable de
-l’insertion des changements dans ce backlog.&nbsp; <br />
-La release est produite par une série d’itérations de 2 à 4 semaines appelées des <a class="elementLink"
-href="./../../Scrum/guidances/termdefinitions/Sprint,_kftWoIHqEduFs9jH8xc4xw.html"
-guid="_kftWoIHqEduFs9jH8xc4xw">Sprint</a>s. Le contenu d’un Sprint est défini par l’équipe avec le propriétaire de produit,
-en tenant compte des priorités et de la capacité de l’équipe. L’équipe définit les tâches nécessaires pour réaliser les
-fonctionnalités sélectionnées pour le Sprint.&nbsp; <br />
-Pendant un sprint, des points de contrôle sur l’avancement sont effectués lors des mêlées quotidiennes. Cela permet au
-ScrumMaster de déterminer l’avancement par rapport aux engagements du Sprint et de conseiller des ajustements pour assurer
-le succès du Sprint.&nbsp; <br />
-A la fin de chaque Sprint, l’équipe produit un <a class="elementLink"
-href="./../../Scrum/workproducts/Product increment,_tCmYEP-xEdqLnajTSLeAsA.html" guid="_tCmYEP-xEdqLnajTSLeAsA">Incrément
-de produit</a>&nbsp;potentiellement utilisable, dont l’évaluation permet d’ajuster le backlog pour le Sprint suivant.</mainDescription>
- <keyConsiderations><p>
- Scrum contribue à renforcer l’esprit d’équipe dans les projets,&nbsp; avec une collection de pratiques proches de
- celles que l’on trouve dans des sports collectifs en particulier le rugby.
-</p>
-<br />
-<br /></keyConsiderations>
- <purpose>.</purpose>
- <howtoStaff>Une équipe Scrum est composée de 3 à 10 personnes.</howtoStaff>
- <scope>Scrum ne décrit pas toutes les disciplines du développement de logiciel (analyse, conception, codage, test) et doit être
-considéré, plutôt qu’un processus complet, comme un pattern de processus qui est à utiliser pour la gestion de projet et la
-gestion des exigences. <br />
-Scrum ne fournit pas d’aide pour la réalisation des activités techniques du développement.</scope>
- <estimatingTechnique><p>
- Il est conseillé de pratiquer une estimation basée sur les points (story points), associés aux éléments du backlog.
-</p></estimatingTechnique>
- </org.eclipse.epf.uma:DeliveryProcessDescription>
- <org.eclipse.epf.uma:ActivityDescription xmi:id="-WiMYK8iwLeOO-sSBRBjbNQ" name="Phase de préparation,_37TdkAL_EduOAKqB9I73uw" guid="-WiMYK8iwLeOO-sSBRBjbNQ">
- <mainDescription><p>
- Scrum ne prend pas en compte tous les aspects de préparation d'un projet. Seules sont présentées les taches spécifiques
- de Scrum plus une qui regroupe tous les travaux pouvant etre réalisés
-</p></mainDescription>
- </org.eclipse.epf.uma:ActivityDescription>
- <org.eclipse.epf.uma:DescriptorDescription xmi:id="-EpBaHVCIYCqqGX_wv7dlYA" name="Travaux quotidiens,_nXmKUANlEduYd-55D-Aiqg" guid="-EpBaHVCIYCqqGX_wv7dlYA">
- <refinedDescription>Scrum ne propose rien pour la réalisation de ces tâches techniques de conception, codage et test mais se conjugue bien avec
-l’utilisation des techniques XP (binômage, développement dirigé par les tests…). <br />
-Les tâches ne sont pas assignées par le ScrumMaster mais choisies par les membres de l’équipe au fur et à mesure. <br />
-L’équipe met à jour, chaque fois que c’est nécessaire, l’estimation du reste à faire sur les tâches du <br />
-backlog du sprint.</refinedDescription>
- </org.eclipse.epf.uma:DescriptorDescription>
- <org.eclipse.epf.uma:DescriptorDescription xmi:id="-EOwIzNPjfNIjzJ3TRAgeWQ" name="Sprint de release,_zbM2QIGBEduKE9hnyImx1Q" guid="-EOwIzNPjfNIjzJ3TRAgeWQ">
- <keyConsiderations>Essayer de ne pas modifier de code lors du dernier sprint, c'est trop tard et risqué.</keyConsiderations>
- <usageGuidance>Il est optionnel. Cela dépend de la façon dont le produit est mis à disposition de ses utilisateurs finals. On en devrait
-dérouler ce sprint optionnel que des travaux qu'il est impossible de faire avant, dans les sprints "normaux".</usageGuidance>
- <refinedDescription><p>
- Les tâches effectuées pendant ce sprint dépendent fortement du type de déploiement du logiciel.
-</p>
-<p>
- On peut y trouver des travaux portant sur :
-</p>
-<ul>
- <li>
- mise en production à chaud,
- </li>
- <li>
- packaging du produit,
- </li>
- <li>
- mise à disposition par téléchargement en ligne,
- </li>
- <li>
- documentation technique,
- </li>
- <li>
- formation des utilisateurs,
- </li>
- <li>
- marketing du produit.
- </li>
-</ul></refinedDescription>
- </org.eclipse.epf.uma:DescriptorDescription>
- <org.eclipse.epf.uma:DescriptorDescription xmi:id="-MupkaQeHNEmiF7Lnl3VirQ" name="Sprint backlog,_glbG2wMAEduOAKqB9I73uw" guid="-MupkaQeHNEmiF7Lnl3VirQ">
- <usageGuidance>Un par sprint</usageGuidance>
- </org.eclipse.epf.uma:DescriptorDescription>
-</xmi:XMI>
diff --git a/Scrum French/Scrum/deliveryprocesses/Scrum/model.xmi b/Scrum French/Scrum/deliveryprocesses/Scrum/model.xmi
deleted file mode 100644
index eafcf7c..0000000
--- a/Scrum French/Scrum/deliveryprocesses/Scrum/model.xmi
+++ /dev/null
@@ -1,982 +0,0 @@
-<?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.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
- <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_9m1CIAAvEdubGMceRDupFQ" guid="_9m1CIAAvEdubGMceRDupFQ">
- <resourceDescriptors xmi:id="_9m1CIQAvEdubGMceRDupFQ" id="-16dzhVoCex78V2iCDZVx0w" uri="content.xmi"/>
- <resourceDescriptors xmi:id="_-d2LQQMEEduOAKqB9I73uw" id="-WiMYK8iwLeOO-sSBRBjbNQ" uri="content.xmi"/>
- <resourceDescriptors xmi:id="_8N5DwANlEduYd-55D-Aiqg" id="-EpBaHVCIYCqqGX_wv7dlYA" uri="content.xmi"/>
- <resourceDescriptors xmi:id="_iCOP4IGPEduKE9hnyImx1Q" id="-EOwIzNPjfNIjzJ3TRAgeWQ" uri="content.xmi"/>
- <resourceDescriptors xmi:id="_tObbkLPBEduk5O8SjA21Fg" id="-MupkaQeHNEmiF7Lnl3VirQ" uri="content.xmi"/>
- </org.eclipse.epf.uma.resourcemanager:ResourceManager>
- <org.eclipse.epf.uma:ProcessComponent xmi:id="_9llsAAAvEdubGMceRDupFQ" name="Scrum" guid="_9llsAAAvEdubGMceRDupFQ">
- <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_37NW8AL_EduOAKqB9I73uw" name="Preparation Phase" guid="_37NW8AL_EduOAKqB9I73uw">
- <processElements xsi:type="org.eclipse.epf.uma:Phase" xmi:id="_37TdkAL_EduOAKqB9I73uw" name="Preparation Phase" guid="_37TdkAL_EduOAKqB9I73uw" briefDescription="Cette phase initiale permet de préparer tout ce qui est nécessaire avant de commencer la série des sprints" presentationName="Phase de préparation" isOptional="true" superActivities="_9llsAQAvEdubGMceRDupFQ" breakdownElements="_zYT-EQMAEduOAKqB9I73uw _zYaEsAMAEduOAKqB9I73uw _zYaEsgMAEduOAKqB9I73uw _zYaEswMAEduOAKqB9I73uw _zYaEtAMAEduOAKqB9I73uw _7FGsMANkEduYd-55D-Aiqg _7FGsMQNkEduYd-55D-Aiqg _O6XmcANlEduYd-55D-Aiqg">
- <presentation xmi:id="-WiMYK8iwLeOO-sSBRBjbNQ" href="uma://-16dzhVoCex78V2iCDZVx0w#-WiMYK8iwLeOO-sSBRBjbNQ"/>
- </processElements>
- <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_zYT-EQMAEduOAKqB9I73uw" name="Plan release" guid="_zYT-EQMAEduOAKqB9I73uw" presentationName="Planifier la release" superActivities="_37TdkAL_EduOAKqB9I73uw" linkToPredecessor="_2vOSsAMEEduOAKqB9I73uw _MEJPgAPOEdubhrgDuRb4fA _MEPWIAPOEdubhrgDuRb4fA" additionallyPerformedBy="_zYaEswMAEduOAKqB9I73uw _zYaEsgMAEduOAKqB9I73uw" mandatoryInput="_zYaEtAMAEduOAKqB9I73uw" output="_zYaEtAMAEduOAKqB9I73uw" performedPrimarilyBy="_zYaEsAMAEduOAKqB9I73uw">
- <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_ho-aIP_BEdqtbrr0B1TG-A"/>
- <selectedSteps href="uma://-3f4axrWBKHGv74oKN2x-gQ#_8qN08APJEdubhrgDuRb4fA"/>
- <selectedSteps href="uma://-3f4axrWBKHGv74oKN2x-gQ#_BuXEQAPKEdubhrgDuRb4fA"/>
- <selectedSteps href="uma://-3f4axrWBKHGv74oKN2x-gQ#_EaLKQAPKEdubhrgDuRb4fA"/>
- <selectedSteps href="uma://-3f4axrWBKHGv74oKN2x-gQ#_HDZ2UAPKEdubhrgDuRb4fA"/>
- <selectedSteps href="uma://-3f4axrWBKHGv74oKN2x-gQ#_I71XkAPKEdubhrgDuRb4fA"/>
- </processElements>
- <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_zYaEsAMAEduOAKqB9I73uw" name="Product Owner" guid="_zYaEsAMAEduOAKqB9I73uw" presentationName="Directeur Produit" superActivities="_37TdkAL_EduOAKqB9I73uw" responsibleFor="_zYaEtAMAEduOAKqB9I73uw">
- <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_ICJyYPpaEdqsc-f87sBK8A"/>
- </processElements>
- <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_zYaEsgMAEduOAKqB9I73uw" name="Team" guid="_zYaEsgMAEduOAKqB9I73uw" presentationName="Equipe Scrum" hasMultipleOccurrences="true" superActivities="_37TdkAL_EduOAKqB9I73uw">
- <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_9apLsPpaEdqsc-f87sBK8A"/>
- </processElements>
- <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_zYaEswMAEduOAKqB9I73uw" name="ScrumMaster" guid="_zYaEswMAEduOAKqB9I73uw" presentationName="ScrumMaster" superActivities="_37TdkAL_EduOAKqB9I73uw">
- <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_t1K9kPpYEdqsc-f87sBK8A"/>
- </processElements>
- <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_zYaEtAMAEduOAKqB9I73uw" name="Product Backlog" guid="_zYaEtAMAEduOAKqB9I73uw" presentationName="Backlog de produit" superActivities="_37TdkAL_EduOAKqB9I73uw">
- <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_5ABscPpYEdqsc-f87sBK8A"/>
- </processElements>
- <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_2vOSsAMEEduOAKqB9I73uw" guid="_2vOSsAMEEduOAKqB9I73uw" linkType="finishToFinish"/>
- <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_7FGsMANkEduYd-55D-Aiqg" name="Initiate Product Backlog" guid="_7FGsMANkEduYd-55D-Aiqg" presentationName="Produire le backlog de produit initial" superActivities="_37TdkAL_EduOAKqB9I73uw" additionallyPerformedBy="_7FGsMQNkEduYd-55D-Aiqg _zYaEsgMAEduOAKqB9I73uw" output="_zYaEtAMAEduOAKqB9I73uw" performedPrimarilyBy="_zYaEsAMAEduOAKqB9I73uw">
- <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_BGFMoANkEduYd-55D-Aiqg"/>
- <selectedSteps href="uma://-mi1O4H7RRm0YqlUNyp8TJg#_pWL_gAPJEdubhrgDuRb4fA"/>
- <selectedSteps href="uma://-mi1O4H7RRm0YqlUNyp8TJg#_u0Z7sAPJEdubhrgDuRb4fA"/>
- </processElements>
- <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_7FGsMQNkEduYd-55D-Aiqg" name="StakeHolder" guid="_7FGsMQNkEduYd-55D-Aiqg" presentationName="Intervenant" isPlanned="false" hasMultipleOccurrences="true" superActivities="_37TdkAL_EduOAKqB9I73uw">
- <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_Qqmp8P_AEdqtbrr0B1TG-A"/>
- </processElements>
- <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_O6XmcANlEduYd-55D-Aiqg" name="Preparation work" guid="_O6XmcANlEduYd-55D-Aiqg" presentationName="Travaux de préparation" isPlanned="true" hasMultipleOccurrences="true" superActivities="_37TdkAL_EduOAKqB9I73uw" performedPrimarilyBy="_zYaEsgMAEduOAKqB9I73uw"/>
- <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_MEJPgAPOEdubhrgDuRb4fA" guid="_MEJPgAPOEdubhrgDuRb4fA" linkType="finishToFinish" pred="_7FGsMANkEduYd-55D-Aiqg"/>
- <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_MEPWIAPOEdubhrgDuRb4fA" guid="_MEPWIAPOEdubhrgDuRb4fA" linkType="finishToFinish" pred="_O6XmcANlEduYd-55D-Aiqg"/>
- <diagrams xmi:id="_y9sh0AMEEduOAKqB9I73uw" guid="_y9sh0AMEEduOAKqB9I73uw">
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y9yocAMEEduOAKqB9I73uw" guid="_y9yocAMEEduOAKqB9I73uw">
- <position xmi:id="_y9yocQMEEduOAKqB9I73uw" x="84.0" y="34.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_2vIMEQMEEduOAKqB9I73uw" guid="_2vIMEQMEEduOAKqB9I73uw" anchor="_2vIMEAMEEduOAKqB9I73uw _2vIMEgMEEduOAKqB9I73uw">
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vOSsQMEEduOAKqB9I73uw" guid="_2vOSsQMEEduOAKqB9I73uw"/>
- </contained>
- <anchorage xmi:id="_2QAAEgMEEduOAKqB9I73uw" guid="_2QAAEgMEEduOAKqB9I73uw" graphEdge="_2QAAEQMEEduOAKqB9I73uw"/>
- <anchorage xmi:id="_2vIMEAMEEduOAKqB9I73uw" guid="_2vIMEAMEEduOAKqB9I73uw" graphEdge="_2vIMEQMEEduOAKqB9I73uw">
- <position xmi:id="_2vIMEwMEEduOAKqB9I73uw" x="155.0" y="50.0"/>
- </anchorage>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y9yocgMEEduOAKqB9I73uw" guid="_y9yocgMEEduOAKqB9I73uw"/>
- <size xmi:id="_y9yocwMEEduOAKqB9I73uw" width="130.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_y9yodAMEEduOAKqB9I73uw" guid="_y9yodAMEEduOAKqB9I73uw">
- <position xmi:id="_y9yodQMEEduOAKqB9I73uw" x="158.0" y="214.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_nqi5YYGGEduKE9hnyImx1Q" guid="_nqi5YYGGEduKE9hnyImx1Q" anchor="_nqi5YIGGEduKE9hnyImx1Q _nqi5YoGGEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_2vIMEgMEEduOAKqB9I73uw" guid="_2vIMEgMEEduOAKqB9I73uw" graphEdge="_2vIMEQMEEduOAKqB9I73uw"/>
- <anchorage xmi:id="_MEDI4gPOEdubhrgDuRb4fA" guid="_MEDI4gPOEdubhrgDuRb4fA" graphEdge="_MEDI4QPOEdubhrgDuRb4fA"/>
- <anchorage xmi:id="_nqi5YIGGEduKE9hnyImx1Q" guid="_nqi5YIGGEduKE9hnyImx1Q" graphEdge="_nqi5YYGGEduKE9hnyImx1Q">
- <position xmi:id="_nqi5Y4GGEduKE9hnyImx1Q" x="171.0" y="228.0"/>
- </anchorage>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y9yodgMEEduOAKqB9I73uw" guid="_y9yodgMEEduOAKqB9I73uw" element="_zYT-EQMAEduOAKqB9I73uw"/>
- <size xmi:id="_y9yodwMEEduOAKqB9I73uw" width="88.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_03XZMAMEEduOAKqB9I73uw" guid="_03XZMAMEEduOAKqB9I73uw">
- <position xmi:id="_03XZMQMEEduOAKqB9I73uw" x="187.0" y="-6.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_2QAAEQMEEduOAKqB9I73uw" guid="_2QAAEQMEEduOAKqB9I73uw" anchor="_2QAAEAMEEduOAKqB9I73uw _2QAAEgMEEduOAKqB9I73uw"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_-h0qsQNkEduYd-55D-Aiqg" guid="_-h0qsQNkEduYd-55D-Aiqg" anchor="_-h0qsANkEduYd-55D-Aiqg _-h0qsgNkEduYd-55D-Aiqg"/>
- <anchorage xmi:id="_2QAAEAMEEduOAKqB9I73uw" guid="_2QAAEAMEEduOAKqB9I73uw" graphEdge="_2QAAEQMEEduOAKqB9I73uw">
- <position xmi:id="_2QAAEwMEEduOAKqB9I73uw" x="58.0" y="51.0"/>
- </anchorage>
- <anchorage xmi:id="_-h0qsANkEduYd-55D-Aiqg" guid="_-h0qsANkEduYd-55D-Aiqg" graphEdge="_-h0qsQNkEduYd-55D-Aiqg">
- <position xmi:id="_-h6xUANkEduYd-55D-Aiqg" x="62.0" y="51.0"/>
- </anchorage>
- <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_03XZMgMEEduOAKqB9I73uw" guid="_03XZMgMEEduOAKqB9I73uw" typeInfo="start node"/>
- <size xmi:id="_03XZMwMEEduOAKqB9I73uw" width="20.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_8cZ2UANkEduYd-55D-Aiqg" guid="_8cZ2UANkEduYd-55D-Aiqg">
- <position xmi:id="_8cZ2UQNkEduYd-55D-Aiqg" x="14.0" y="94.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_LDfDwQPOEdubhrgDuRb4fA" guid="_LDfDwQPOEdubhrgDuRb4fA" anchor="_LDfDwAPOEdubhrgDuRb4fA _LDfDwgPOEdubhrgDuRb4fA"/>
- <anchorage xmi:id="_4JEBIgPNEdubhrgDuRb4fA" guid="_4JEBIgPNEdubhrgDuRb4fA" graphEdge="_4JEBIQPNEdubhrgDuRb4fA"/>
- <anchorage xmi:id="_LDfDwAPOEdubhrgDuRb4fA" guid="_LDfDwAPOEdubhrgDuRb4fA" graphEdge="_LDfDwQPOEdubhrgDuRb4fA">
- <position xmi:id="_LDfDwwPOEdubhrgDuRb4fA" x="114.0" y="145.0"/>
- </anchorage>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_8cZ2UgNkEduYd-55D-Aiqg" guid="_8cZ2UgNkEduYd-55D-Aiqg" element="_7FGsMANkEduYd-55D-Aiqg"/>
- <size xmi:id="_8cZ2UwNkEduYd-55D-Aiqg" width="168.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_n_DhAANnEduYd-55D-Aiqg" guid="_n_DhAANnEduYd-55D-Aiqg">
- <position xmi:id="_n_DhAQNnEduYd-55D-Aiqg" x="255.0" y="90.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_LgIjgQPOEdubhrgDuRb4fA" guid="_LgIjgQPOEdubhrgDuRb4fA" anchor="_LgIjgAPOEdubhrgDuRb4fA _LgIjggPOEdubhrgDuRb4fA"/>
- <anchorage xmi:id="_114dkgPNEdubhrgDuRb4fA" guid="_114dkgPNEdubhrgDuRb4fA" graphEdge="_114dkQPNEdubhrgDuRb4fA"/>
- <anchorage xmi:id="_LgIjgAPOEdubhrgDuRb4fA" guid="_LgIjgAPOEdubhrgDuRb4fA" graphEdge="_LgIjgQPOEdubhrgDuRb4fA">
- <position xmi:id="_LgIjgwPOEdubhrgDuRb4fA" x="282.0" y="140.0"/>
- </anchorage>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_n_DhAgNnEduYd-55D-Aiqg" guid="_n_DhAgNnEduYd-55D-Aiqg" element="_O6XmcANlEduYd-55D-Aiqg"/>
- <size xmi:id="_n_DhAwNnEduYd-55D-Aiqg" width="113.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_nITO0APNEdubhrgDuRb4fA" guid="_nITO0APNEdubhrgDuRb4fA">
- <position xmi:id="_nITO0QPNEdubhrgDuRb4fA" x="162.0" y="55.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_114dkQPNEdubhrgDuRb4fA" guid="_114dkQPNEdubhrgDuRb4fA" anchor="_114dkAPNEdubhrgDuRb4fA _114dkgPNEdubhrgDuRb4fA"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_4JEBIQPNEdubhrgDuRb4fA" guid="_4JEBIQPNEdubhrgDuRb4fA" anchor="_4JEBIAPNEdubhrgDuRb4fA _4JEBIgPNEdubhrgDuRb4fA"/>
- <anchorage xmi:id="_-h0qsgNkEduYd-55D-Aiqg" guid="_-h0qsgNkEduYd-55D-Aiqg" graphEdge="_-h0qsQNkEduYd-55D-Aiqg">
- <position xmi:id="_Ip2OIFGGEduRlKB2-_Ejlg" x="36.0" y="5.0"/>
- </anchorage>
- <anchorage xmi:id="_114dkAPNEdubhrgDuRb4fA" guid="_114dkAPNEdubhrgDuRb4fA" graphEdge="_114dkQPNEdubhrgDuRb4fA">
- <position xmi:id="_114dkwPNEdubhrgDuRb4fA" x="67.0" y="0.0"/>
- </anchorage>
- <anchorage xmi:id="_4JEBIAPNEdubhrgDuRb4fA" guid="_4JEBIAPNEdubhrgDuRb4fA" graphEdge="_4JEBIQPNEdubhrgDuRb4fA">
- <position xmi:id="_HPd_kAPOEdubhrgDuRb4fA" x="17.0" y="0.0"/>
- </anchorage>
- <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_nITO0gPNEdubhrgDuRb4fA" guid="_nITO0gPNEdubhrgDuRb4fA" typeInfo="synchnonization bar"/>
- <size xmi:id="_nITO0wPNEdubhrgDuRb4fA" width="81.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_J5FtMAPOEdubhrgDuRb4fA" guid="_J5FtMAPOEdubhrgDuRb4fA">
- <position xmi:id="_J5FtMQPOEdubhrgDuRb4fA" x="152.0" y="171.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_MEDI4QPOEdubhrgDuRb4fA" guid="_MEDI4QPOEdubhrgDuRb4fA" anchor="_MEDI4APOEdubhrgDuRb4fA _MEDI4gPOEdubhrgDuRb4fA"/>
- <anchorage xmi:id="_LDfDwgPOEdubhrgDuRb4fA" guid="_LDfDwgPOEdubhrgDuRb4fA" graphEdge="_LDfDwQPOEdubhrgDuRb4fA">
- <position xmi:id="_LDfDxAPOEdubhrgDuRb4fA" x="42.0" y="0.0"/>
- </anchorage>
- <anchorage xmi:id="_LgIjggPOEdubhrgDuRb4fA" guid="_LgIjggPOEdubhrgDuRb4fA" graphEdge="_LgIjgQPOEdubhrgDuRb4fA">
- <position xmi:id="_LgIjhAPOEdubhrgDuRb4fA" x="54.0" y="0.0"/>
- </anchorage>
- <anchorage xmi:id="_MEDI4APOEdubhrgDuRb4fA" guid="_MEDI4APOEdubhrgDuRb4fA" graphEdge="_MEDI4QPOEdubhrgDuRb4fA">
- <position xmi:id="_MJgy8FGGEduRlKB2-_Ejlg" x="49.0" y="0.0"/>
- </anchorage>
- <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_J5FtMgPOEdubhrgDuRb4fA" guid="_J5FtMgPOEdubhrgDuRb4fA" typeInfo="synchnonization bar"/>
- <size xmi:id="_J5FtMwPOEdubhrgDuRb4fA" width="100.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_mMXrMIGGEduKE9hnyImx1Q" guid="_mMXrMIGGEduKE9hnyImx1Q">
- <position xmi:id="_mMXrMYGGEduKE9hnyImx1Q" x="190.0" y="282.0"/>
- <anchorage xmi:id="_nqi5YoGGEduKE9hnyImx1Q" guid="_nqi5YoGGEduKE9hnyImx1Q" graphEdge="_nqi5YYGGEduKE9hnyImx1Q"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_mMXrMoGGEduKE9hnyImx1Q" guid="_mMXrMoGGEduKE9hnyImx1Q" typeInfo="end node"/>
- <size xmi:id="_mMXrM4GGEduKE9hnyImx1Q" width="24.0" height="-1.0"/>
- </contained>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_y9sh0QMEEduOAKqB9I73uw" guid="_y9sh0QMEEduOAKqB9I73uw" presentation="Workflow" element="_37TdkAL_EduOAKqB9I73uw"/>
- </diagrams>
- <diagrams xmi:id="_jcymYAPNEdubhrgDuRb4fA" guid="_jcymYAPNEdubhrgDuRb4fA">
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymYQPNEdubhrgDuRb4fA" guid="_jcymYQPNEdubhrgDuRb4fA">
- <position xmi:id="_jcymYgPNEdubhrgDuRb4fA" x="-1.0" y="-1.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5oznBIGMEduKE9hnyImx1Q" guid="_5oznBIGMEduKE9hnyImx1Q" anchor="_5oznA4GMEduKE9hnyImx1Q _5oznBYGMEduKE9hnyImx1Q"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5uBeNIGMEduKE9hnyImx1Q" guid="_5uBeNIGMEduKE9hnyImx1Q" anchor="_5uBeM4GMEduKE9hnyImx1Q _5uBeNYGMEduKE9hnyImx1Q"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_03qQxLKjEdudsfcMCYa15A" guid="_03qQxLKjEdudsfcMCYa15A" anchor="_03qQw7KjEdudsfcMCYa15A _03qQxbKjEdudsfcMCYa15A"/>
- <anchorage xmi:id="_5oznAoGMEduKE9hnyImx1Q" guid="_5oznAoGMEduKE9hnyImx1Q" graphEdge="_5oznAYGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_5oznA4GMEduKE9hnyImx1Q" guid="_5oznA4GMEduKE9hnyImx1Q" graphEdge="_5oznBIGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_5uBeMoGMEduKE9hnyImx1Q" guid="_5uBeMoGMEduKE9hnyImx1Q" graphEdge="_5uBeMYGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_5uBeM4GMEduKE9hnyImx1Q" guid="_5uBeM4GMEduKE9hnyImx1Q" graphEdge="_5uBeNIGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_03qQwrKjEdudsfcMCYa15A" guid="_03qQwrKjEdudsfcMCYa15A" graphEdge="_03qQwbKjEdudsfcMCYa15A"/>
- <anchorage xmi:id="_03qQw7KjEdudsfcMCYa15A" guid="_03qQw7KjEdudsfcMCYa15A" graphEdge="_03qQxLKjEdudsfcMCYa15A"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymYwPNEdubhrgDuRb4fA" guid="_jcymYwPNEdubhrgDuRb4fA" element="_zYT-EQMAEduOAKqB9I73uw"/>
- <size xmi:id="_jcymZAPNEdubhrgDuRb4fA" width="-1.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymZQPNEdubhrgDuRb4fA" guid="_jcymZQPNEdubhrgDuRb4fA">
- <position xmi:id="_jcymZgPNEdubhrgDuRb4fA" x="30.0" y="88.0"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymZwPNEdubhrgDuRb4fA" guid="_jcymZwPNEdubhrgDuRb4fA" element="_zYaEsAMAEduOAKqB9I73uw"/>
- <size xmi:id="_jcymaAPNEdubhrgDuRb4fA" width="316.0" height="67.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymaQPNEdubhrgDuRb4fA" guid="_jcymaQPNEdubhrgDuRb4fA">
- <position xmi:id="_jcymagPNEdubhrgDuRb4fA" x="30.0" y="283.0"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymawPNEdubhrgDuRb4fA" guid="_jcymawPNEdubhrgDuRb4fA" element="_zYaEsgMAEduOAKqB9I73uw"/>
- <size xmi:id="_jcymbAPNEdubhrgDuRb4fA" width="239.0" height="53.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymbQPNEdubhrgDuRb4fA" guid="_jcymbQPNEdubhrgDuRb4fA">
- <position xmi:id="_jcymbgPNEdubhrgDuRb4fA" x="-1.0" y="-1.0"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymbwPNEdubhrgDuRb4fA" guid="_jcymbwPNEdubhrgDuRb4fA" element="_zYaEswMAEduOAKqB9I73uw"/>
- <size xmi:id="_jcymcAPNEdubhrgDuRb4fA" width="-1.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymcQPNEdubhrgDuRb4fA" guid="_jcymcQPNEdubhrgDuRb4fA">
- <position xmi:id="_jcymcgPNEdubhrgDuRb4fA" x="-1.0" y="-1.0"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymcwPNEdubhrgDuRb4fA" guid="_jcymcwPNEdubhrgDuRb4fA" element="_zYaEtAMAEduOAKqB9I73uw"/>
- <size xmi:id="_jcymdAPNEdubhrgDuRb4fA" width="-1.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymdQPNEdubhrgDuRb4fA" guid="_jcymdQPNEdubhrgDuRb4fA">
- <position xmi:id="_jcymdgPNEdubhrgDuRb4fA" x="-1.0" y="-1.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5oznB4GMEduKE9hnyImx1Q" guid="_5oznB4GMEduKE9hnyImx1Q" anchor="_5oznBoGMEduKE9hnyImx1Q _5oznCIGMEduKE9hnyImx1Q"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5uBeN4GMEduKE9hnyImx1Q" guid="_5uBeN4GMEduKE9hnyImx1Q" anchor="_5uBeNoGMEduKE9hnyImx1Q _5uBeOIGMEduKE9hnyImx1Q"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_03qQx7KjEdudsfcMCYa15A" guid="_03qQx7KjEdudsfcMCYa15A" anchor="_03qQxrKjEdudsfcMCYa15A _03qQyLKjEdudsfcMCYa15A"/>
- <anchorage xmi:id="_5oznBoGMEduKE9hnyImx1Q" guid="_5oznBoGMEduKE9hnyImx1Q" graphEdge="_5oznB4GMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_5uBeNoGMEduKE9hnyImx1Q" guid="_5uBeNoGMEduKE9hnyImx1Q" graphEdge="_5uBeN4GMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_03qQxrKjEdudsfcMCYa15A" guid="_03qQxrKjEdudsfcMCYa15A" graphEdge="_03qQx7KjEdudsfcMCYa15A"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymdwPNEdubhrgDuRb4fA" guid="_jcymdwPNEdubhrgDuRb4fA" element="_7FGsMANkEduYd-55D-Aiqg"/>
- <size xmi:id="_jcymeAPNEdubhrgDuRb4fA" width="-1.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymeQPNEdubhrgDuRb4fA" guid="_jcymeQPNEdubhrgDuRb4fA">
- <position xmi:id="_jcymegPNEdubhrgDuRb4fA" x="-1.0" y="-1.0"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymewPNEdubhrgDuRb4fA" guid="_jcymewPNEdubhrgDuRb4fA" element="_7FGsMQNkEduYd-55D-Aiqg"/>
- <size xmi:id="_jcymfAPNEdubhrgDuRb4fA" width="-1.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jcymfQPNEdubhrgDuRb4fA" guid="_jcymfQPNEdubhrgDuRb4fA">
- <position xmi:id="_jcymfgPNEdubhrgDuRb4fA" x="-1.0" y="-1.0"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymfwPNEdubhrgDuRb4fA" guid="_jcymfwPNEdubhrgDuRb4fA" element="_O6XmcANlEduYd-55D-Aiqg"/>
- <size xmi:id="_jcymgAPNEdubhrgDuRb4fA" width="-1.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jdE6QAPNEdubhrgDuRb4fA" guid="_jdE6QAPNEdubhrgDuRb4fA">
- <property xmi:id="_jdE6QQPNEdubhrgDuRb4fA" guid="_jdE6QQPNEdubhrgDuRb4fA" key="wpCompositeType" value="1"/>
- <position xmi:id="_jdE6QgPNEdubhrgDuRb4fA" x="127.0" y="1.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_jdRHgQPNEdubhrgDuRb4fA" guid="_jdRHgQPNEdubhrgDuRb4fA" anchor="_jdRHgAPNEdubhrgDuRb4fA"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8P1cgRTUEduFIr9xNbwGyQ" guid="_8P1cgRTUEduFIr9xNbwGyQ" anchor="_8P1cgBTUEduFIr9xNbwGyQ"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5oznAYGMEduKE9hnyImx1Q" guid="_5oznAYGMEduKE9hnyImx1Q" anchor="_5oznAIGMEduKE9hnyImx1Q _5oznAoGMEduKE9hnyImx1Q"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5uBeMYGMEduKE9hnyImx1Q" guid="_5uBeMYGMEduKE9hnyImx1Q" anchor="_5uBeMIGMEduKE9hnyImx1Q _5uBeMoGMEduKE9hnyImx1Q"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_03qQwbKjEdudsfcMCYa15A" guid="_03qQwbKjEdudsfcMCYa15A" anchor="_03qQwLKjEdudsfcMCYa15A _03qQwrKjEdudsfcMCYa15A"/>
- <anchorage xmi:id="_jdRHgAPNEdubhrgDuRb4fA" guid="_jdRHgAPNEdubhrgDuRb4fA" graphEdge="_jdRHgQPNEdubhrgDuRb4fA"/>
- <anchorage xmi:id="_8P1cgBTUEduFIr9xNbwGyQ" guid="_8P1cgBTUEduFIr9xNbwGyQ" graphEdge="_8P1cgRTUEduFIr9xNbwGyQ"/>
- <anchorage xmi:id="_5oznAIGMEduKE9hnyImx1Q" guid="_5oznAIGMEduKE9hnyImx1Q" graphEdge="_5oznAYGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_5uBeMIGMEduKE9hnyImx1Q" guid="_5uBeMIGMEduKE9hnyImx1Q" graphEdge="_5uBeMYGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_03qQwLKjEdudsfcMCYa15A" guid="_03qQwLKjEdudsfcMCYa15A" graphEdge="_03qQwbKjEdudsfcMCYa15A"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jdE6QwPNEdubhrgDuRb4fA" guid="_jdE6QwPNEdubhrgDuRb4fA" element="_zYT-EQMAEduOAKqB9I73uw"/>
- <size xmi:id="_jdE6RAPNEdubhrgDuRb4fA" width="78.0" height="67.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jdE6RQPNEdubhrgDuRb4fA" guid="_jdE6RQPNEdubhrgDuRb4fA">
- <property xmi:id="_jdE6RgPNEdubhrgDuRb4fA" guid="_jdE6RgPNEdubhrgDuRb4fA" key="wpCompositeType" value="2"/>
- <position xmi:id="_jdE6RwPNEdubhrgDuRb4fA" x="127.0" y="175.0"/>
- <anchorage xmi:id="_jdRHggPNEdubhrgDuRb4fA" guid="_jdRHggPNEdubhrgDuRb4fA"/>
- <anchorage xmi:id="_8P1cghTUEduFIr9xNbwGyQ" guid="_8P1cghTUEduFIr9xNbwGyQ"/>
- <anchorage xmi:id="_5oznBYGMEduKE9hnyImx1Q" guid="_5oznBYGMEduKE9hnyImx1Q" graphEdge="_5oznBIGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_5uBeNYGMEduKE9hnyImx1Q" guid="_5uBeNYGMEduKE9hnyImx1Q" graphEdge="_5uBeNIGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_03qQxbKjEdudsfcMCYa15A" guid="_03qQxbKjEdudsfcMCYa15A" graphEdge="_03qQxLKjEdudsfcMCYa15A"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jdE6SAPNEdubhrgDuRb4fA" guid="_jdE6SAPNEdubhrgDuRb4fA" element="_zYT-EQMAEduOAKqB9I73uw"/>
- <size xmi:id="_jdE6SQPNEdubhrgDuRb4fA" width="78.0" height="67.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_jdLA4APNEdubhrgDuRb4fA" guid="_jdLA4APNEdubhrgDuRb4fA">
- <property xmi:id="_jdLA4QPNEdubhrgDuRb4fA" guid="_jdLA4QPNEdubhrgDuRb4fA" key="wpCompositeType" value="2"/>
- <position xmi:id="_jdLA4gPNEdubhrgDuRb4fA" x="220.0" y="175.0"/>
- <anchorage xmi:id="_jdRHgwPNEdubhrgDuRb4fA" guid="_jdRHgwPNEdubhrgDuRb4fA"/>
- <anchorage xmi:id="_8P1cgxTUEduFIr9xNbwGyQ" guid="_8P1cgxTUEduFIr9xNbwGyQ"/>
- <anchorage xmi:id="_5oznCIGMEduKE9hnyImx1Q" guid="_5oznCIGMEduKE9hnyImx1Q" graphEdge="_5oznB4GMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_5uBeOIGMEduKE9hnyImx1Q" guid="_5uBeOIGMEduKE9hnyImx1Q" graphEdge="_5uBeN4GMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_03qQyLKjEdudsfcMCYa15A" guid="_03qQyLKjEdudsfcMCYa15A" graphEdge="_03qQx7KjEdudsfcMCYa15A"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jdLA4wPNEdubhrgDuRb4fA" guid="_jdLA4wPNEdubhrgDuRb4fA" element="_7FGsMANkEduYd-55D-Aiqg"/>
- <size xmi:id="_jdLA5APNEdubhrgDuRb4fA" width="78.0" height="67.0"/>
- </contained>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_jcymgQPNEdubhrgDuRb4fA" guid="_jcymgQPNEdubhrgDuRb4fA" presentation="Activity Detail" element="_37TdkAL_EduOAKqB9I73uw"/>
- </diagrams>
- </childPackages>
- <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_NSW6sAMAEduOAKqB9I73uw" name="Sprint Phase" guid="_NSW6sAMAEduOAKqB9I73uw">
- <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_SoXWEAMAEduOAKqB9I73uw" name="Sprint (n)" guid="_SoXWEAMAEduOAKqB9I73uw">
- <processElements xsi:type="org.eclipse.epf.uma:Iteration" xmi:id="_SoXWEQMAEduOAKqB9I73uw" name="Sprint (n)" guid="_SoXWEQMAEduOAKqB9I73uw" briefDescription="Déroulement d'un sprint (itération)" presentationName="Sprint" isPlanned="false" superActivities="_NSW6sQMAEduOAKqB9I73uw" isRepeatable="true" breakdownElements="_glbG0AMAEduOAKqB9I73uw _glbG0QMAEduOAKqB9I73uw _glbG0wMAEduOAKqB9I73uw _glbG1AMAEduOAKqB9I73uw _glbG1QMAEduOAKqB9I73uw _glbG1gMAEduOAKqB9I73uw _glbG1wMAEduOAKqB9I73uw _glbG2AMAEduOAKqB9I73uw _glbG2QMAEduOAKqB9I73uw _glbG2gMAEduOAKqB9I73uw _glbG2wMAEduOAKqB9I73uw _glbG3AMAEduOAKqB9I73uw _glbG3QMAEduOAKqB9I73uw _nXmKUANlEduYd-55D-Aiqg"/>
- <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_glbG0AMAEduOAKqB9I73uw" name="Manage problems" guid="_glbG0AMAEduOAKqB9I73uw" presentationName="Gérer les problèmes" superActivities="_SoXWEQMAEduOAKqB9I73uw" isOngoing="true" optionalInput="_glbG2wMAEduOAKqB9I73uw" output="_glbG2wMAEduOAKqB9I73uw" performedPrimarilyBy="_glbG1wMAEduOAKqB9I73uw">
- <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_Xpd5gP_AEdqtbrr0B1TG-A"/>
- <selectedSteps href="uma://-mZfAV7RcWJlp5idlHzeEcA#_LCxqQAB6EduSVaTQTBfIHA"/>
- <selectedSteps href="uma://-mZfAV7RcWJlp5idlHzeEcA#_PIKyUAB6EduSVaTQTBfIHA"/>
- </processElements>
- <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_glbG0QMAEduOAKqB9I73uw" name="Update product backlog" guid="_glbG0QMAEduOAKqB9I73uw" presentationName="Mettre à jour le backlog de produit" superActivities="_SoXWEQMAEduOAKqB9I73uw" isOngoing="true" additionallyPerformedBy="_glbG2QMAEduOAKqB9I73uw _glbG2gMAEduOAKqB9I73uw" mandatoryInput="_glbG3AMAEduOAKqB9I73uw" output="_glbG3AMAEduOAKqB9I73uw" performedPrimarilyBy="_glbG2AMAEduOAKqB9I73uw">
- <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_STkWYP_BEdqtbrr0B1TG-A"/>
- <selectedSteps href="uma://-XdgedeazfFRGDxMY3Fnh5g#_c3HaQAPKEdubhrgDuRb4fA"/>
- <selectedSteps href="uma://-XdgedeazfFRGDxMY3Fnh5g#_fkXDoAPKEdubhrgDuRb4fA"/>
- <selectedSteps href="uma://-XdgedeazfFRGDxMY3Fnh5g#_k-kCgAPKEdubhrgDuRb4fA"/>
- </processElements>
- <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_glbG0wMAEduOAKqB9I73uw" name="Plan sprint" guid="_glbG0wMAEduOAKqB9I73uw" presentationName="Planifier le sprint" superActivities="_SoXWEQMAEduOAKqB9I73uw" additionallyPerformedBy="_glbG2AMAEduOAKqB9I73uw" mandatoryInput="_glbG3AMAEduOAKqB9I73uw" output="_glbG2wMAEduOAKqB9I73uw" performedPrimarilyBy="_glbG2gMAEduOAKqB9I73uw">
- <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_4LOggPpaEdqsc-f87sBK8A"/>
- <selectedSteps href="uma://-NRwwk6YGAtu25V3Lc04G6w#_TJNsUP--Edqtbrr0B1TG-A"/>
- <selectedSteps href="uma://-NRwwk6YGAtu25V3Lc04G6w#_p4C0sP--Edqtbrr0B1TG-A"/>
- <selectedSteps href="uma://-NRwwk6YGAtu25V3Lc04G6w#_worbAP--Edqtbrr0B1TG-A"/>
- <selectedSteps href="uma://-NRwwk6YGAtu25V3Lc04G6w#_xvy5UAPKEdubhrgDuRb4fA"/>
- <selectedSteps href="uma://-NRwwk6YGAtu25V3Lc04G6w#_DxNQUAPLEdubhrgDuRb4fA"/>
- <selectedSteps href="uma://-NRwwk6YGAtu25V3Lc04G6w#_Iq14wAPLEdubhrgDuRb4fA"/>
- </processElements>
- <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_glbG1AMAEduOAKqB9I73uw" name="Retrospective" guid="_glbG1AMAEduOAKqB9I73uw" presentationName="Rétrospective" superActivities="_SoXWEQMAEduOAKqB9I73uw" linkToPredecessor="_O0710AMCEduOAKqB9I73uw" additionallyPerformedBy="_glbG2AMAEduOAKqB9I73uw _glbG1wMAEduOAKqB9I73uw _glbG2QMAEduOAKqB9I73uw" output="_glbG3AMAEduOAKqB9I73uw" performedPrimarilyBy="_glbG2gMAEduOAKqB9I73uw">
- <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_J_sRIP_AEdqtbrr0B1TG-A"/>
- <selectedSteps href="uma://-S4qXwp40l_8eCcyyI7o-3A#_lwzeABGPEduHloEV5-Zv-w"/>
- <selectedSteps href="uma://-S4qXwp40l_8eCcyyI7o-3A#_noL2YBGPEduHloEV5-Zv-w"/>
- </processElements>
- <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_glbG1QMAEduOAKqB9I73uw" name="Review sprint" guid="_glbG1QMAEduOAKqB9I73uw" presentationName="Faire la revue du sprint" superActivities="_SoXWEQMAEduOAKqB9I73uw" isEventDriven="true" additionallyPerformedBy="_glbG2AMAEduOAKqB9I73uw _glbG1wMAEduOAKqB9I73uw _glbG2QMAEduOAKqB9I73uw" mandatoryInput="_glbG3QMAEduOAKqB9I73uw" output="_glbG3AMAEduOAKqB9I73uw" performedPrimarilyBy="_glbG2gMAEduOAKqB9I73uw">
- <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_MRrRYPpbEdqsc-f87sBK8A"/>
- <selectedSteps href="uma://-zoJryMCuHfxWP7Q5Er195Q#_XL6VgAPLEdubhrgDuRb4fA"/>
- <selectedSteps href="uma://-zoJryMCuHfxWP7Q5Er195Q#_ZgJB8APLEdubhrgDuRb4fA"/>
- <selectedSteps href="uma://-zoJryMCuHfxWP7Q5Er195Q#_cBouUAPLEdubhrgDuRb4fA"/>
- <selectedSteps href="uma://-zoJryMCuHfxWP7Q5Er195Q#_hrswoHoYEduJVrY6eKG_mw"/>
- <selectedSteps href="uma://-zoJryMCuHfxWP7Q5Er195Q#_d776UHoYEduJVrY6eKG_mw"/>
- </processElements>
- <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_glbG1gMAEduOAKqB9I73uw" name="Scrum daily meeting" guid="_glbG1gMAEduOAKqB9I73uw" presentationName="Mêlée quotidienne" superActivities="_SoXWEQMAEduOAKqB9I73uw" isRepeatable="true" isEventDriven="true" linkToPredecessor="_34UPdAzNEduDObTFE5q79g _34UPdQzNEduDObTFE5q79g _34UPdgzNEduDObTFE5q79g" additionallyPerformedBy="_glbG2gMAEduOAKqB9I73uw _glbG2AMAEduOAKqB9I73uw" mandatoryInput="_glbG2wMAEduOAKqB9I73uw" output="_glbG2wMAEduOAKqB9I73uw" performedPrimarilyBy="_glbG1wMAEduOAKqB9I73uw">
- <Task href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_d09LYP_AEdqtbrr0B1TG-A"/>
- <selectedSteps href="uma://-vDOuVl_xPKipKd90HQNZng#_oUrlcBGOEduHloEV5-Zv-w"/>
- <selectedSteps href="uma://-vDOuVl_xPKipKd90HQNZng#_r0KkEBGOEduHloEV5-Zv-w"/>
- <selectedSteps href="uma://-vDOuVl_xPKipKd90HQNZng#_vZkkgBGOEduHloEV5-Zv-w"/>
- </processElements>
- <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_glbG1wMAEduOAKqB9I73uw" name="ScrumMaster" guid="_glbG1wMAEduOAKqB9I73uw" presentationName="ScrumMaster" superActivities="_SoXWEQMAEduOAKqB9I73uw" responsibleFor="_glbG2wMAEduOAKqB9I73uw">
- <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_t1K9kPpYEdqsc-f87sBK8A"/>
- </processElements>
- <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_glbG2AMAEduOAKqB9I73uw" name="Product Owner" guid="_glbG2AMAEduOAKqB9I73uw" presentationName="Directeur Produit" superActivities="_SoXWEQMAEduOAKqB9I73uw" responsibleFor="_glbG3AMAEduOAKqB9I73uw">
- <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_ICJyYPpaEdqsc-f87sBK8A"/>
- </processElements>
- <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_glbG2QMAEduOAKqB9I73uw" name="StakeHolder" guid="_glbG2QMAEduOAKqB9I73uw" presentationName="Intervenant" isPlanned="false" hasMultipleOccurrences="true" superActivities="_SoXWEQMAEduOAKqB9I73uw">
- <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_Qqmp8P_AEdqtbrr0B1TG-A"/>
- </processElements>
- <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_glbG2gMAEduOAKqB9I73uw" name="Team" guid="_glbG2gMAEduOAKqB9I73uw" presentationName="Equipe Scrum" hasMultipleOccurrences="true" superActivities="_SoXWEQMAEduOAKqB9I73uw">
- <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_9apLsPpaEdqsc-f87sBK8A"/>
- </processElements>
- <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_glbG2wMAEduOAKqB9I73uw" name="Sprint backlog" guid="_glbG2wMAEduOAKqB9I73uw" presentationName="Backlog du sprint" superActivities="_SoXWEQMAEduOAKqB9I73uw">
- <presentation xmi:id="-MupkaQeHNEmiF7Lnl3VirQ" href="uma://-16dzhVoCex78V2iCDZVx0w#-MupkaQeHNEmiF7Lnl3VirQ"/>
- <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_Dzw70PpZEdqsc-f87sBK8A"/>
- </processElements>
- <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_glbG3AMAEduOAKqB9I73uw" name="Product Backlog" guid="_glbG3AMAEduOAKqB9I73uw" presentationName="Backlog de produit" superActivities="_SoXWEQMAEduOAKqB9I73uw" activityEntryState="courant" activityExitState="mis à jour">
- <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_5ABscPpYEdqsc-f87sBK8A"/>
- </processElements>
- <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_glbG3QMAEduOAKqB9I73uw" name="Product" guid="_glbG3QMAEduOAKqB9I73uw" presentationName="Incrément de produit" superActivities="_SoXWEQMAEduOAKqB9I73uw">
- <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_tCmYEP-xEdqLnajTSLeAsA"/>
- </processElements>
- <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_O0710AMCEduOAKqB9I73uw" guid="_O0710AMCEduOAKqB9I73uw" linkType="finishToFinish" pred="_glbG1QMAEduOAKqB9I73uw"/>
- <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_nXmKUANlEduYd-55D-Aiqg" name="Daily work" guid="_nXmKUANlEduYd-55D-Aiqg" briefDescription="L'équipe réalise les taches du backlog pour arriver au but du sprint" presentationName="Travaux quotidiens" isPlanned="true" hasMultipleOccurrences="true" superActivities="_SoXWEQMAEduOAKqB9I73uw" mandatoryInput="_glbG2wMAEduOAKqB9I73uw" output="_glbG3QMAEduOAKqB9I73uw">
- <presentation xmi:id="-EpBaHVCIYCqqGX_wv7dlYA" href="uma://-16dzhVoCex78V2iCDZVx0w#-EpBaHVCIYCqqGX_wv7dlYA"/>
- </processElements>
- <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_34UPdAzNEduDObTFE5q79g" guid="_34UPdAzNEduDObTFE5q79g" linkType="finishToFinish" pred="_glbG0QMAEduOAKqB9I73uw"/>
- <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_34UPdQzNEduDObTFE5q79g" guid="_34UPdQzNEduDObTFE5q79g" linkType="finishToFinish" pred="_nXmKUANlEduYd-55D-Aiqg"/>
- <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_34UPdgzNEduDObTFE5q79g" guid="_34UPdgzNEduDObTFE5q79g" linkType="finishToFinish" pred="_glbG0AMAEduOAKqB9I73uw"/>
- <diagrams xmi:id="_2vZZMAMBEduOAKqB9I73uw" guid="_2vZZMAMBEduOAKqB9I73uw">
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vZZMQMBEduOAKqB9I73uw" guid="_2vZZMQMBEduOAKqB9I73uw">
- <position xmi:id="_2vZZMgMBEduOAKqB9I73uw" x="199.0" y="174.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_LnUDQQMCEduOAKqB9I73uw" guid="_LnUDQQMCEduOAKqB9I73uw" anchor="_LnUDQAMCEduOAKqB9I73uw"/>
- <anchorage xmi:id="_LSlwcgMCEduOAKqB9I73uw" guid="_LSlwcgMCEduOAKqB9I73uw" graphEdge="_LSlwcQMCEduOAKqB9I73uw"/>
- <anchorage xmi:id="_LnUDQAMCEduOAKqB9I73uw" guid="_LnUDQAMCEduOAKqB9I73uw" graphEdge="_LnUDQQMCEduOAKqB9I73uw">
- <position xmi:id="_LnUDQwMCEduOAKqB9I73uw" x="316.0" y="187.0"/>
- </anchorage>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vZZMwMBEduOAKqB9I73uw" guid="_2vZZMwMBEduOAKqB9I73uw"/>
- <size xmi:id="_2vZZNAMBEduOAKqB9I73uw" width="143.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vff0AMBEduOAKqB9I73uw" guid="_2vff0AMBEduOAKqB9I73uw">
- <position xmi:id="_2vff0QMBEduOAKqB9I73uw" x="322.0" y="134.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_swPHwQzNEduDObTFE5q79g" guid="_swPHwQzNEduDObTFE5q79g" anchor="_swPHwAzNEduDObTFE5q79g _swPHwgzNEduDObTFE5q79g"/>
- <anchorage xmi:id="_L-ChMgMCEduOAKqB9I73uw" guid="_L-ChMgMCEduOAKqB9I73uw" graphEdge="_L-ChMQMCEduOAKqB9I73uw"/>
- <anchorage xmi:id="_swPHwAzNEduDObTFE5q79g" guid="_swPHwAzNEduDObTFE5q79g" graphEdge="_swPHwQzNEduDObTFE5q79g">
- <position xmi:id="_swPHwwzNEduDObTFE5q79g" x="394.0" y="241.0"/>
- </anchorage>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vff0gMBEduOAKqB9I73uw" guid="_2vff0gMBEduOAKqB9I73uw" element="_glbG0AMAEduOAKqB9I73uw"/>
- <size xmi:id="_2vff0wMBEduOAKqB9I73uw" width="98.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vff1AMBEduOAKqB9I73uw" guid="_2vff1AMBEduOAKqB9I73uw">
- <position xmi:id="_2vff1QMBEduOAKqB9I73uw" x="19.0" y="127.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_r27hMQzNEduDObTFE5q79g" guid="_r27hMQzNEduDObTFE5q79g" anchor="_r27hMAzNEduDObTFE5q79g _r27hMgzNEduDObTFE5q79g"/>
- <anchorage xmi:id="_KNcGQgMCEduOAKqB9I73uw" guid="_KNcGQgMCEduOAKqB9I73uw" graphEdge="_KNcGQQMCEduOAKqB9I73uw"/>
- <anchorage xmi:id="_r27hMAzNEduDObTFE5q79g" guid="_r27hMAzNEduDObTFE5q79g" graphEdge="_r27hMQzNEduDObTFE5q79g">
- <position xmi:id="_r27hMwzNEduDObTFE5q79g" x="123.0" y="239.0"/>
- </anchorage>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vff1gMBEduOAKqB9I73uw" guid="_2vff1gMBEduOAKqB9I73uw" element="_glbG0QMAEduOAKqB9I73uw"/>
- <size xmi:id="_2vff1wMBEduOAKqB9I73uw" width="130.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vff2AMBEduOAKqB9I73uw" guid="_2vff2AMBEduOAKqB9I73uw">
- <position xmi:id="_2vff2QMBEduOAKqB9I73uw" x="76.0" y="269.0"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vff2gMBEduOAKqB9I73uw" guid="_2vff2gMBEduOAKqB9I73uw"/>
- <size xmi:id="_2vff2wMBEduOAKqB9I73uw" width="88.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vff3AMBEduOAKqB9I73uw" guid="_2vff3AMBEduOAKqB9I73uw">
- <position xmi:id="_2vff3QMBEduOAKqB9I73uw" x="190.0" y="3.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_-mYC4QzNEduDObTFE5q79g" guid="_-mYC4QzNEduDObTFE5q79g" anchor="_-mYC4AzNEduDObTFE5q79g _-mYC4gzNEduDObTFE5q79g"/>
- <anchorage xmi:id="_I2DckgMCEduOAKqB9I73uw" guid="_I2DckgMCEduOAKqB9I73uw" graphEdge="_I2DckQMCEduOAKqB9I73uw"/>
- <anchorage xmi:id="_-mYC4AzNEduDObTFE5q79g" guid="_-mYC4AzNEduDObTFE5q79g" graphEdge="_-mYC4QzNEduDObTFE5q79g">
- <position xmi:id="_-mYC4wzNEduDObTFE5q79g" x="264.0" y="88.0"/>
- </anchorage>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vff3gMBEduOAKqB9I73uw" guid="_2vff3gMBEduOAKqB9I73uw" element="_glbG0wMAEduOAKqB9I73uw"/>
- <size xmi:id="_2vff3wMBEduOAKqB9I73uw" width="79.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vff4AMBEduOAKqB9I73uw" guid="_2vff4AMBEduOAKqB9I73uw">
- <position xmi:id="_2vff4QMBEduOAKqB9I73uw" x="346.0" y="332.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_PENn8QMCEduOAKqB9I73uw" guid="_PENn8QMCEduOAKqB9I73uw" anchor="_PENn8AMCEduOAKqB9I73uw _PENn8gMCEduOAKqB9I73uw"/>
- <anchorage xmi:id="_O0vokgMCEduOAKqB9I73uw" guid="_O0vokgMCEduOAKqB9I73uw" graphEdge="_O0vokQMCEduOAKqB9I73uw"/>
- <anchorage xmi:id="_PENn8AMCEduOAKqB9I73uw" guid="_PENn8AMCEduOAKqB9I73uw" graphEdge="_PENn8QMCEduOAKqB9I73uw">
- <position xmi:id="_PENn8wMCEduOAKqB9I73uw" x="327.0" y="377.0"/>
- </anchorage>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vff4gMBEduOAKqB9I73uw" guid="_2vff4gMBEduOAKqB9I73uw" element="_glbG1AMAEduOAKqB9I73uw"/>
- <size xmi:id="_2vff4wMBEduOAKqB9I73uw" width="67.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vff5AMBEduOAKqB9I73uw" guid="_2vff5AMBEduOAKqB9I73uw">
- <position xmi:id="_2vff5QMBEduOAKqB9I73uw" x="175.0" y="332.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_O0vokQMCEduOAKqB9I73uw" guid="_O0vokQMCEduOAKqB9I73uw" anchor="_O0vokAMCEduOAKqB9I73uw _O0vokgMCEduOAKqB9I73uw">
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O0710QMCEduOAKqB9I73uw" guid="_O0710QMCEduOAKqB9I73uw"/>
- </contained>
- <anchorage xmi:id="_Ok5OsgMCEduOAKqB9I73uw" guid="_Ok5OsgMCEduOAKqB9I73uw" graphEdge="_Ok5OsQMCEduOAKqB9I73uw"/>
- <anchorage xmi:id="_O0vokAMCEduOAKqB9I73uw" guid="_O0vokAMCEduOAKqB9I73uw" graphEdge="_O0vokQMCEduOAKqB9I73uw">
- <position xmi:id="_O0vokwMCEduOAKqB9I73uw" x="324.0" y="328.0"/>
- </anchorage>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vff5gMBEduOAKqB9I73uw" guid="_2vff5gMBEduOAKqB9I73uw" element="_glbG1QMAEduOAKqB9I73uw"/>
- <size xmi:id="_2vff5wMBEduOAKqB9I73uw" width="111.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_2vff6AMBEduOAKqB9I73uw" guid="_2vff6AMBEduOAKqB9I73uw">
- <position xmi:id="_2vff6QMBEduOAKqB9I73uw" x="187.0" y="217.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_63CqYQzNEduDObTFE5q79g" guid="_63CqYQzNEduDObTFE5q79g" anchor="_63CqYAzNEduDObTFE5q79g _63CqYgzNEduDObTFE5q79g"/>
- <anchorage xmi:id="_34UPcgzNEduDObTFE5q79g" guid="_34UPcgzNEduDObTFE5q79g" graphEdge="_34UPcQzNEduDObTFE5q79g"/>
- <anchorage xmi:id="_63CqYAzNEduDObTFE5q79g" guid="_63CqYAzNEduDObTFE5q79g" graphEdge="_63CqYQzNEduDObTFE5q79g">
- <position xmi:id="_63CqYwzNEduDObTFE5q79g" x="268.0" y="326.0"/>
- </anchorage>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vff6gMBEduOAKqB9I73uw" guid="_2vff6gMBEduOAKqB9I73uw" element="_glbG1gMAEduOAKqB9I73uw"/>
- <size xmi:id="_2vff6wMBEduOAKqB9I73uw" width="86.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_DtnjIAMCEduOAKqB9I73uw" guid="_DtnjIAMCEduOAKqB9I73uw">
- <position xmi:id="_DtnjIQMCEduOAKqB9I73uw" x="9.0" y="15.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_I2DckQMCEduOAKqB9I73uw" guid="_I2DckQMCEduOAKqB9I73uw" anchor="_I2DckAMCEduOAKqB9I73uw _I2DckgMCEduOAKqB9I73uw"/>
- <anchorage xmi:id="_I2DckAMCEduOAKqB9I73uw" guid="_I2DckAMCEduOAKqB9I73uw" graphEdge="_I2DckQMCEduOAKqB9I73uw">
- <position xmi:id="_I2DckwMCEduOAKqB9I73uw" x="318.0" y="32.0"/>
- </anchorage>
- <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_DtnjIgMCEduOAKqB9I73uw" guid="_DtnjIgMCEduOAKqB9I73uw" typeInfo="start node"/>
- <size xmi:id="_DtnjIwMCEduOAKqB9I73uw" width="20.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_EQ85sAMCEduOAKqB9I73uw" guid="_EQ85sAMCEduOAKqB9I73uw">
- <position xmi:id="_EQ85sQMCEduOAKqB9I73uw" x="531.0" y="342.0"/>
- <anchorage xmi:id="_PENn8gMCEduOAKqB9I73uw" guid="_PENn8gMCEduOAKqB9I73uw" graphEdge="_PENn8QMCEduOAKqB9I73uw"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_EQ85sgMCEduOAKqB9I73uw" guid="_EQ85sgMCEduOAKqB9I73uw" typeInfo="end node"/>
- <size xmi:id="_EQ85swMCEduOAKqB9I73uw" width="24.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_FLsDoAMCEduOAKqB9I73uw" guid="_FLsDoAMCEduOAKqB9I73uw">
- <position xmi:id="_FLsDoQMCEduOAKqB9I73uw" x="206.0" y="274.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_Ok5OsQMCEduOAKqB9I73uw" guid="_Ok5OsQMCEduOAKqB9I73uw" anchor="_Ok5OsAMCEduOAKqB9I73uw _Ok5OsgMCEduOAKqB9I73uw"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_ADBAAQzOEduDObTFE5q79g" guid="_ADBAAQzOEduDObTFE5q79g" anchor="_ADBAAAzOEduDObTFE5q79g _ADBAAgzOEduDObTFE5q79g">
- <waypoints xmi:id="_0PYkcAzOEduDObTFE5q79g" x="491.0" y="285.0"/>
- <waypoints xmi:id="_0PYkcQzOEduDObTFE5q79g" x="492.0" y="76.0"/>
- </contained>
- <anchorage xmi:id="_Ok5OsAMCEduOAKqB9I73uw" guid="_Ok5OsAMCEduOAKqB9I73uw" graphEdge="_Ok5OsQMCEduOAKqB9I73uw">
- <position xmi:id="_cyxCoAMCEduOAKqB9I73uw" x="23.0" y="23.0"/>
- </anchorage>
- <anchorage xmi:id="_63CqYgzNEduDObTFE5q79g" guid="_63CqYgzNEduDObTFE5q79g" graphEdge="_63CqYQzNEduDObTFE5q79g">
- <position xmi:id="_63CqZAzNEduDObTFE5q79g" x="23.0" y="0.0"/>
- </anchorage>
- <anchorage xmi:id="_ADBAAAzOEduDObTFE5q79g" guid="_ADBAAAzOEduDObTFE5q79g" graphEdge="_ADBAAQzOEduDObTFE5q79g">
- <position xmi:id="_ADBAAwzOEduDObTFE5q79g" x="47.0" y="11.0"/>
- </anchorage>
- <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_FLsDogMCEduOAKqB9I73uw" guid="_FLsDogMCEduOAKqB9I73uw" typeInfo="decision node"/>
- <size xmi:id="_FLsDowMCEduOAKqB9I73uw" width="48.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_HEmGAAMCEduOAKqB9I73uw" guid="_HEmGAAMCEduOAKqB9I73uw">
- <position xmi:id="_HEmGAQMCEduOAKqB9I73uw" x="180.0" y="106.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_KNcGQQMCEduOAKqB9I73uw" guid="_KNcGQQMCEduOAKqB9I73uw" anchor="_KNcGQAMCEduOAKqB9I73uw _KNcGQgMCEduOAKqB9I73uw"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_LSlwcQMCEduOAKqB9I73uw" guid="_LSlwcQMCEduOAKqB9I73uw" anchor="_LSlwcAMCEduOAKqB9I73uw _LSlwcgMCEduOAKqB9I73uw"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_L-ChMQMCEduOAKqB9I73uw" guid="_L-ChMQMCEduOAKqB9I73uw" anchor="_L-ChMAMCEduOAKqB9I73uw _L-ChMgMCEduOAKqB9I73uw"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_haut0QNmEduYd-55D-Aiqg" guid="_haut0QNmEduYd-55D-Aiqg" anchor="_haut0ANmEduYd-55D-Aiqg _haut0gNmEduYd-55D-Aiqg"/>
- <anchorage xmi:id="_KNcGQAMCEduOAKqB9I73uw" guid="_KNcGQAMCEduOAKqB9I73uw" graphEdge="_KNcGQQMCEduOAKqB9I73uw">
- <position xmi:id="_KNcGQwMCEduOAKqB9I73uw" x="47.0" y="5.0"/>
- </anchorage>
- <anchorage xmi:id="_LSlwcAMCEduOAKqB9I73uw" guid="_LSlwcAMCEduOAKqB9I73uw" graphEdge="_LSlwcQMCEduOAKqB9I73uw">
- <position xmi:id="_LSlwcwMCEduOAKqB9I73uw" x="49.0" y="0.0"/>
- </anchorage>
- <anchorage xmi:id="_L-ChMAMCEduOAKqB9I73uw" guid="_L-ChMAMCEduOAKqB9I73uw" graphEdge="_L-ChMQMCEduOAKqB9I73uw">
- <position xmi:id="_L-In0AMCEduOAKqB9I73uw" x="50.0" y="5.0"/>
- </anchorage>
- <anchorage xmi:id="_haut0ANmEduYd-55D-Aiqg" guid="_haut0ANmEduYd-55D-Aiqg" graphEdge="_haut0QNmEduYd-55D-Aiqg">
- <position xmi:id="_8NQZYIGPEduKE9hnyImx1Q" x="50.0" y="5.0"/>
- </anchorage>
- <anchorage xmi:id="__S4jkgzNEduDObTFE5q79g" guid="__S4jkgzNEduDObTFE5q79g" graphEdge="__S4jkQzNEduDObTFE5q79g">
- <position xmi:id="__S4jlAzNEduDObTFE5q79g" x="46.0" y="0.0"/>
- </anchorage>
- <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_HEmGAgMCEduOAKqB9I73uw" guid="_HEmGAgMCEduOAKqB9I73uw" typeInfo="synchnonization bar"/>
- <size xmi:id="_HEmGAwMCEduOAKqB9I73uw" width="100.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_XP3cUANmEduYd-55D-Aiqg" guid="_XP3cUANmEduYd-55D-Aiqg">
- <position xmi:id="_XP3cUQNmEduYd-55D-Aiqg" x="184.0" y="134.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_sOOm4QzNEduDObTFE5q79g" guid="_sOOm4QzNEduDObTFE5q79g" anchor="_sOOm4AzNEduDObTFE5q79g _sOOm4gzNEduDObTFE5q79g"/>
- <anchorage xmi:id="_haut0gNmEduYd-55D-Aiqg" guid="_haut0gNmEduYd-55D-Aiqg" graphEdge="_haut0QNmEduYd-55D-Aiqg"/>
- <anchorage xmi:id="_sOOm4AzNEduDObTFE5q79g" guid="_sOOm4AzNEduDObTFE5q79g" graphEdge="_sOOm4QzNEduDObTFE5q79g">
- <position xmi:id="_sOOm4wzNEduDObTFE5q79g" x="263.0" y="237.0"/>
- </anchorage>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_XP3cUgNmEduYd-55D-Aiqg" guid="_XP3cUgNmEduYd-55D-Aiqg" element="_nXmKUANlEduYd-55D-Aiqg"/>
- <size xmi:id="_XP3cUwNmEduYd-55D-Aiqg" width="92.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_4Fi44ANmEduYd-55D-Aiqg" name="Add Free Text" guid="_4Fi44ANmEduYd-55D-Aiqg">
- <property xmi:id="_4Fi44QNmEduYd-55D-Aiqg" guid="_4Fi44QNmEduYd-55D-Aiqg" key="free text" value="date de fin de sprint atteinte"/>
- <position xmi:id="_4Fi44gNmEduYd-55D-Aiqg" x="154.0" y="297.0"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_4Fi44wNmEduYd-55D-Aiqg" guid="_4Fi44wNmEduYd-55D-Aiqg" typeInfo="free text"/>
- <size xmi:id="_4Fi45ANmEduYd-55D-Aiqg" width="69.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_S90SkAzNEduDObTFE5q79g" guid="_S90SkAzNEduDObTFE5q79g">
- <position xmi:id="_S90SkQzNEduDObTFE5q79g" x="206.0" y="66.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="__S4jkQzNEduDObTFE5q79g" guid="__S4jkQzNEduDObTFE5q79g" anchor="__S4jkAzNEduDObTFE5q79g __S4jkgzNEduDObTFE5q79g"/>
- <anchorage xmi:id="_-mYC4gzNEduDObTFE5q79g" guid="_-mYC4gzNEduDObTFE5q79g" graphEdge="_-mYC4QzNEduDObTFE5q79g">
- <position xmi:id="_-mYC5AzNEduDObTFE5q79g" x="23.0" y="0.0"/>
- </anchorage>
- <anchorage xmi:id="__S4jkAzNEduDObTFE5q79g" guid="__S4jkAzNEduDObTFE5q79g" graphEdge="__S4jkQzNEduDObTFE5q79g">
- <position xmi:id="__S4jkwzNEduDObTFE5q79g" x="23.0" y="23.0"/>
- </anchorage>
- <anchorage xmi:id="_ADBAAgzOEduDObTFE5q79g" guid="_ADBAAgzOEduDObTFE5q79g" graphEdge="_ADBAAQzOEduDObTFE5q79g">
- <position xmi:id="_ADBABAzOEduDObTFE5q79g" x="47.0" y="11.0"/>
- </anchorage>
- <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_S90SkgzNEduDObTFE5q79g" guid="_S90SkgzNEduDObTFE5q79g" typeInfo="decision node"/>
- <size xmi:id="_S90SkwzNEduDObTFE5q79g" width="48.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_qmzWEAzNEduDObTFE5q79g" guid="_qmzWEAzNEduDObTFE5q79g">
- <position xmi:id="_qmzWEQzNEduDObTFE5q79g" x="180.0" y="198.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_34UPcQzNEduDObTFE5q79g" guid="_34UPcQzNEduDObTFE5q79g" anchor="_34UPcAzNEduDObTFE5q79g _34UPcgzNEduDObTFE5q79g"/>
- <anchorage xmi:id="_r27hMgzNEduDObTFE5q79g" guid="_r27hMgzNEduDObTFE5q79g" graphEdge="_r27hMQzNEduDObTFE5q79g">
- <position xmi:id="_r27hNAzNEduDObTFE5q79g" x="38.0" y="0.0"/>
- </anchorage>
- <anchorage xmi:id="_sOOm4gzNEduDObTFE5q79g" guid="_sOOm4gzNEduDObTFE5q79g" graphEdge="_sOOm4QzNEduDObTFE5q79g">
- <position xmi:id="_8NQZYYGPEduKE9hnyImx1Q" x="50.0" y="0.0"/>
- </anchorage>
- <anchorage xmi:id="_swPHwgzNEduDObTFE5q79g" guid="_swPHwgzNEduDObTFE5q79g" graphEdge="_swPHwQzNEduDObTFE5q79g">
- <position xmi:id="_swPHxAzNEduDObTFE5q79g" x="48.0" y="0.0"/>
- </anchorage>
- <anchorage xmi:id="_34UPcAzNEduDObTFE5q79g" guid="_34UPcAzNEduDObTFE5q79g" graphEdge="_34UPcQzNEduDObTFE5q79g">
- <position xmi:id="_34UPcwzNEduDObTFE5q79g" x="44.0" y="0.0"/>
- </anchorage>
- <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_qmzWEgzNEduDObTFE5q79g" guid="_qmzWEgzNEduDObTFE5q79g" typeInfo="synchnonization bar"/>
- <size xmi:id="_qmzWEwzNEduDObTFE5q79g" width="100.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_f5j60AzOEduDObTFE5q79g" name="Add Free Text" guid="_f5j60AzOEduDObTFE5q79g">
- <property xmi:id="_f5j60QzOEduDObTFE5q79g" guid="_f5j60QzOEduDObTFE5q79g" key="free text" value="encore des jours dans le sprint"/>
- <position xmi:id="_f5j60gzOEduDObTFE5q79g" x="289.0" y="266.0"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_f5j60wzOEduDObTFE5q79g" guid="_f5j60wzOEduDObTFE5q79g" typeInfo="free text"/>
- <size xmi:id="_f5j61AzOEduDObTFE5q79g" width="165.0" height="-1.0"/>
- </contained>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_2vZZNQMBEduOAKqB9I73uw" guid="_2vZZNQMBEduOAKqB9I73uw" presentation="Workflow" element="_SoXWEQMAEduOAKqB9I73uw"/>
- </diagrams>
- <diagrams xmi:id="_O8kwcANmEduYd-55D-Aiqg" guid="_O8kwcANmEduYd-55D-Aiqg">
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8kwcQNmEduYd-55D-Aiqg" guid="_O8kwcQNmEduYd-55D-Aiqg">
- <position xmi:id="_O8kwcgNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RsYGMEduKE9hnyImx1Q" guid="_5q5RsYGMEduKE9hnyImx1Q" anchor="_5q5RsIGMEduKE9hnyImx1Q _5q5RsoGMEduKE9hnyImx1Q"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeEYGMEduKE9hnyImx1Q" guid="_51BeEYGMEduKE9hnyImx1Q" anchor="_51BeEIGMEduKE9hnyImx1Q _51BeEoGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_5q5RsIGMEduKE9hnyImx1Q" guid="_5q5RsIGMEduKE9hnyImx1Q" graphEdge="_5q5RsYGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_51BeEIGMEduKE9hnyImx1Q" guid="_51BeEIGMEduKE9hnyImx1Q" graphEdge="_51BeEYGMEduKE9hnyImx1Q"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8kwcwNmEduYd-55D-Aiqg" guid="_O8kwcwNmEduYd-55D-Aiqg" element="_glbG0AMAEduOAKqB9I73uw"/>
- <size xmi:id="_O8kwdANmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8kwdQNmEduYd-55D-Aiqg" guid="_O8kwdQNmEduYd-55D-Aiqg">
- <position xmi:id="_O8kwdgNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5Rt4GMEduKE9hnyImx1Q" guid="_5q5Rt4GMEduKE9hnyImx1Q" anchor="_5q5RtoGMEduKE9hnyImx1Q _5q5RuIGMEduKE9hnyImx1Q"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeF4GMEduKE9hnyImx1Q" guid="_51BeF4GMEduKE9hnyImx1Q" anchor="_51BeFoGMEduKE9hnyImx1Q _51BeGIGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_5q5RtYGMEduKE9hnyImx1Q" guid="_5q5RtYGMEduKE9hnyImx1Q" graphEdge="_5q5RtIGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_5q5RtoGMEduKE9hnyImx1Q" guid="_5q5RtoGMEduKE9hnyImx1Q" graphEdge="_5q5Rt4GMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_51BeFYGMEduKE9hnyImx1Q" guid="_51BeFYGMEduKE9hnyImx1Q" graphEdge="_51BeFIGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_51BeFoGMEduKE9hnyImx1Q" guid="_51BeFoGMEduKE9hnyImx1Q" graphEdge="_51BeF4GMEduKE9hnyImx1Q"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8kwdwNmEduYd-55D-Aiqg" guid="_O8kwdwNmEduYd-55D-Aiqg" element="_glbG0QMAEduOAKqB9I73uw"/>
- <size xmi:id="_O8kweANmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8kweQNmEduYd-55D-Aiqg" guid="_O8kweQNmEduYd-55D-Aiqg">
- <position xmi:id="_O8kwegNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RvYGMEduKE9hnyImx1Q" guid="_5q5RvYGMEduKE9hnyImx1Q" anchor="_5q5RvIGMEduKE9hnyImx1Q _5q5RvoGMEduKE9hnyImx1Q"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeHYGMEduKE9hnyImx1Q" guid="_51BeHYGMEduKE9hnyImx1Q" anchor="_51BeHIGMEduKE9hnyImx1Q _51BeHoGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_5q5Ru4GMEduKE9hnyImx1Q" guid="_5q5Ru4GMEduKE9hnyImx1Q" graphEdge="_5q5RuoGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_5q5RvIGMEduKE9hnyImx1Q" guid="_5q5RvIGMEduKE9hnyImx1Q" graphEdge="_5q5RvYGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_51BeG4GMEduKE9hnyImx1Q" guid="_51BeG4GMEduKE9hnyImx1Q" graphEdge="_51BeGoGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_51BeHIGMEduKE9hnyImx1Q" guid="_51BeHIGMEduKE9hnyImx1Q" graphEdge="_51BeHYGMEduKE9hnyImx1Q"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8kwewNmEduYd-55D-Aiqg" guid="_O8kwewNmEduYd-55D-Aiqg" element="_glbG0wMAEduOAKqB9I73uw"/>
- <size xmi:id="_O8kwfANmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8kwfQNmEduYd-55D-Aiqg" guid="_O8kwfQNmEduYd-55D-Aiqg">
- <position xmi:id="_O8kwfgNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RwIGMEduKE9hnyImx1Q" guid="_5q5RwIGMEduKE9hnyImx1Q" anchor="_5q5Rv4GMEduKE9hnyImx1Q _5q5RwYGMEduKE9hnyImx1Q"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeIIGMEduKE9hnyImx1Q" guid="_51BeIIGMEduKE9hnyImx1Q" anchor="_51BeH4GMEduKE9hnyImx1Q _51BeIYGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_5q5Rv4GMEduKE9hnyImx1Q" guid="_5q5Rv4GMEduKE9hnyImx1Q" graphEdge="_5q5RwIGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_51BeH4GMEduKE9hnyImx1Q" guid="_51BeH4GMEduKE9hnyImx1Q" graphEdge="_51BeIIGMEduKE9hnyImx1Q"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3EANmEduYd-55D-Aiqg" guid="_O8q3EANmEduYd-55D-Aiqg" element="_glbG1AMAEduOAKqB9I73uw"/>
- <size xmi:id="_O8q3EQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3EgNmEduYd-55D-Aiqg" guid="_O8q3EgNmEduYd-55D-Aiqg">
- <position xmi:id="_O8q3EwNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RxoGMEduKE9hnyImx1Q" guid="_5q5RxoGMEduKE9hnyImx1Q" anchor="_5q5RxYGMEduKE9hnyImx1Q _5q5Rx4GMEduKE9hnyImx1Q"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeJoGMEduKE9hnyImx1Q" guid="_51BeJoGMEduKE9hnyImx1Q" anchor="_51BeJYGMEduKE9hnyImx1Q _51BeJ4GMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_5q5RxIGMEduKE9hnyImx1Q" guid="_5q5RxIGMEduKE9hnyImx1Q" graphEdge="_5q5Rw4GMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_5q5RxYGMEduKE9hnyImx1Q" guid="_5q5RxYGMEduKE9hnyImx1Q" graphEdge="_5q5RxoGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_51BeJIGMEduKE9hnyImx1Q" guid="_51BeJIGMEduKE9hnyImx1Q" graphEdge="_51BeI4GMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_51BeJYGMEduKE9hnyImx1Q" guid="_51BeJYGMEduKE9hnyImx1Q" graphEdge="_51BeJoGMEduKE9hnyImx1Q"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3FANmEduYd-55D-Aiqg" guid="_O8q3FANmEduYd-55D-Aiqg" element="_glbG1QMAEduOAKqB9I73uw"/>
- <size xmi:id="_O8q3FQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3FgNmEduYd-55D-Aiqg" guid="_O8q3FgNmEduYd-55D-Aiqg">
- <position xmi:id="_O8q3FwNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RzIGMEduKE9hnyImx1Q" guid="_5q5RzIGMEduKE9hnyImx1Q" anchor="_5q5Ry4GMEduKE9hnyImx1Q _5q5RzYGMEduKE9hnyImx1Q"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeLIGMEduKE9hnyImx1Q" guid="_51BeLIGMEduKE9hnyImx1Q" anchor="_51BeK4GMEduKE9hnyImx1Q _51BeLYGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_5q5RyoGMEduKE9hnyImx1Q" guid="_5q5RyoGMEduKE9hnyImx1Q" graphEdge="_5q5RyYGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_5q5Ry4GMEduKE9hnyImx1Q" guid="_5q5Ry4GMEduKE9hnyImx1Q" graphEdge="_5q5RzIGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_51BeKoGMEduKE9hnyImx1Q" guid="_51BeKoGMEduKE9hnyImx1Q" graphEdge="_51BeKYGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_51BeK4GMEduKE9hnyImx1Q" guid="_51BeK4GMEduKE9hnyImx1Q" graphEdge="_51BeLIGMEduKE9hnyImx1Q"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3GANmEduYd-55D-Aiqg" guid="_O8q3GANmEduYd-55D-Aiqg" element="_glbG1gMAEduOAKqB9I73uw"/>
- <size xmi:id="_O8q3GQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3GgNmEduYd-55D-Aiqg" guid="_O8q3GgNmEduYd-55D-Aiqg">
- <position xmi:id="_O8q3GwNmEduYd-55D-Aiqg" x="30.0" y="88.0"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3HANmEduYd-55D-Aiqg" guid="_O8q3HANmEduYd-55D-Aiqg" element="_glbG1wMAEduOAKqB9I73uw"/>
- <size xmi:id="_O8q3HQNmEduYd-55D-Aiqg" width="338.0" height="53.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3HgNmEduYd-55D-Aiqg" guid="_O8q3HgNmEduYd-55D-Aiqg">
- <position xmi:id="_O8q3HwNmEduYd-55D-Aiqg" x="30.0" y="356.0"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3IANmEduYd-55D-Aiqg" guid="_O8q3IANmEduYd-55D-Aiqg" element="_glbG2AMAEduOAKqB9I73uw"/>
- <size xmi:id="_O8q3IQNmEduYd-55D-Aiqg" width="222.0" height="67.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3IgNmEduYd-55D-Aiqg" guid="_O8q3IgNmEduYd-55D-Aiqg">
- <position xmi:id="_O8q3IwNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3JANmEduYd-55D-Aiqg" guid="_O8q3JANmEduYd-55D-Aiqg" element="_glbG2QMAEduOAKqB9I73uw"/>
- <size xmi:id="_O8q3JQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3JgNmEduYd-55D-Aiqg" guid="_O8q3JgNmEduYd-55D-Aiqg">
- <position xmi:id="_O8q3JwNmEduYd-55D-Aiqg" x="30.0" y="638.0"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3KANmEduYd-55D-Aiqg" guid="_O8q3KANmEduYd-55D-Aiqg" element="_glbG2gMAEduOAKqB9I73uw"/>
- <size xmi:id="_O8q3KQNmEduYd-55D-Aiqg" width="374.0" height="67.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3KgNmEduYd-55D-Aiqg" guid="_O8q3KgNmEduYd-55D-Aiqg">
- <position xmi:id="_O8q3KwNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3LANmEduYd-55D-Aiqg" guid="_O8q3LANmEduYd-55D-Aiqg" element="_glbG2wMAEduOAKqB9I73uw"/>
- <size xmi:id="_O8q3LQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3LgNmEduYd-55D-Aiqg" guid="_O8q3LgNmEduYd-55D-Aiqg">
- <position xmi:id="_O8q3LwNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3MANmEduYd-55D-Aiqg" guid="_O8q3MANmEduYd-55D-Aiqg" element="_glbG3AMAEduOAKqB9I73uw"/>
- <size xmi:id="_O8q3MQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3MgNmEduYd-55D-Aiqg" guid="_O8q3MgNmEduYd-55D-Aiqg">
- <position xmi:id="_O8q3MwNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3NANmEduYd-55D-Aiqg" guid="_O8q3NANmEduYd-55D-Aiqg" element="_glbG3QMAEduOAKqB9I73uw"/>
- <size xmi:id="_O8q3NQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O8q3NgNmEduYd-55D-Aiqg" guid="_O8q3NgNmEduYd-55D-Aiqg">
- <position xmi:id="_O8q3NwNmEduYd-55D-Aiqg" x="-1.0" y="-1.0"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3OANmEduYd-55D-Aiqg" guid="_O8q3OANmEduYd-55D-Aiqg" element="_nXmKUANlEduYd-55D-Aiqg"/>
- <size xmi:id="_O8q3OQNmEduYd-55D-Aiqg" width="-1.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O9bsEANmEduYd-55D-Aiqg" guid="_O9bsEANmEduYd-55D-Aiqg">
- <property xmi:id="_O9bsEQNmEduYd-55D-Aiqg" guid="_O9bsEQNmEduYd-55D-Aiqg" key="wpCompositeType" value="2"/>
- <position xmi:id="_O9bsEgNmEduYd-55D-Aiqg" x="137.0" y="161.0"/>
- <anchorage xmi:id="_O-9WFQNmEduYd-55D-Aiqg" guid="_O-9WFQNmEduYd-55D-Aiqg"/>
- <anchorage xmi:id="_oHjVsANnEduYd-55D-Aiqg" guid="_oHjVsANnEduYd-55D-Aiqg"/>
- <anchorage xmi:id="_D6EPMAO8EdubhrgDuRb4fA" guid="_D6EPMAO8EdubhrgDuRb4fA"/>
- <anchorage xmi:id="_-EfTMAPMEdubhrgDuRb4fA" guid="_-EfTMAPMEdubhrgDuRb4fA"/>
- <anchorage xmi:id="_8ZSTcBTUEduFIr9xNbwGyQ" guid="_8ZSTcBTUEduFIr9xNbwGyQ"/>
- <anchorage xmi:id="_5q5RsoGMEduKE9hnyImx1Q" guid="_5q5RsoGMEduKE9hnyImx1Q" graphEdge="_5q5RsYGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_51BeEoGMEduKE9hnyImx1Q" guid="_51BeEoGMEduKE9hnyImx1Q" graphEdge="_51BeEYGMEduKE9hnyImx1Q"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O9bsEwNmEduYd-55D-Aiqg" guid="_O9bsEwNmEduYd-55D-Aiqg" element="_glbG0AMAEduOAKqB9I73uw"/>
- <size xmi:id="_O9bsFANmEduYd-55D-Aiqg" width="72.0" height="67.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O9t_8ANmEduYd-55D-Aiqg" guid="_O9t_8ANmEduYd-55D-Aiqg">
- <property xmi:id="_O9t_8QNmEduYd-55D-Aiqg" guid="_O9t_8QNmEduYd-55D-Aiqg" key="wpCompositeType" value="1"/>
- <position xmi:id="_O9t_8gNmEduYd-55D-Aiqg" x="142.0" y="269.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_O-9WFwNmEduYd-55D-Aiqg" guid="_O-9WFwNmEduYd-55D-Aiqg" anchor="_O-9WFgNmEduYd-55D-Aiqg"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_oHjVsgNnEduYd-55D-Aiqg" guid="_oHjVsgNnEduYd-55D-Aiqg" anchor="_oHjVsQNnEduYd-55D-Aiqg"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_D6EPMgO8EdubhrgDuRb4fA" guid="_D6EPMgO8EdubhrgDuRb4fA" anchor="_D6EPMQO8EdubhrgDuRb4fA"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_-EfTMgPMEdubhrgDuRb4fA" guid="_-EfTMgPMEdubhrgDuRb4fA" anchor="_-EfTMQPMEdubhrgDuRb4fA"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8ZSTchTUEduFIr9xNbwGyQ" guid="_8ZSTchTUEduFIr9xNbwGyQ" anchor="_8ZSTcRTUEduFIr9xNbwGyQ"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RtIGMEduKE9hnyImx1Q" guid="_5q5RtIGMEduKE9hnyImx1Q" anchor="_5q5Rs4GMEduKE9hnyImx1Q _5q5RtYGMEduKE9hnyImx1Q"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeFIGMEduKE9hnyImx1Q" guid="_51BeFIGMEduKE9hnyImx1Q" anchor="_51BeE4GMEduKE9hnyImx1Q _51BeFYGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_O-9WFgNmEduYd-55D-Aiqg" guid="_O-9WFgNmEduYd-55D-Aiqg" graphEdge="_O-9WFwNmEduYd-55D-Aiqg"/>
- <anchorage xmi:id="_oHjVsQNnEduYd-55D-Aiqg" guid="_oHjVsQNnEduYd-55D-Aiqg" graphEdge="_oHjVsgNnEduYd-55D-Aiqg"/>
- <anchorage xmi:id="_D6EPMQO8EdubhrgDuRb4fA" guid="_D6EPMQO8EdubhrgDuRb4fA" graphEdge="_D6EPMgO8EdubhrgDuRb4fA"/>
- <anchorage xmi:id="_-EfTMQPMEdubhrgDuRb4fA" guid="_-EfTMQPMEdubhrgDuRb4fA" graphEdge="_-EfTMgPMEdubhrgDuRb4fA"/>
- <anchorage xmi:id="_8ZSTcRTUEduFIr9xNbwGyQ" guid="_8ZSTcRTUEduFIr9xNbwGyQ" graphEdge="_8ZSTchTUEduFIr9xNbwGyQ"/>
- <anchorage xmi:id="_5q5Rs4GMEduKE9hnyImx1Q" guid="_5q5Rs4GMEduKE9hnyImx1Q" graphEdge="_5q5RtIGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_51BeE4GMEduKE9hnyImx1Q" guid="_51BeE4GMEduKE9hnyImx1Q" graphEdge="_51BeFIGMEduKE9hnyImx1Q"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O9t_8wNmEduYd-55D-Aiqg" guid="_O9t_8wNmEduYd-55D-Aiqg" element="_glbG0QMAEduOAKqB9I73uw"/>
- <size xmi:id="_O9t_9ANmEduYd-55D-Aiqg" width="78.0" height="67.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O96NMANmEduYd-55D-Aiqg" guid="_O96NMANmEduYd-55D-Aiqg">
- <property xmi:id="_O96NMQNmEduYd-55D-Aiqg" guid="_O96NMQNmEduYd-55D-Aiqg" key="wpCompositeType" value="2"/>
- <position xmi:id="_O96NMgNmEduYd-55D-Aiqg" x="142.0" y="443.0"/>
- <anchorage xmi:id="_O-9WGANmEduYd-55D-Aiqg" guid="_O-9WGANmEduYd-55D-Aiqg"/>
- <anchorage xmi:id="_oHjVswNnEduYd-55D-Aiqg" guid="_oHjVswNnEduYd-55D-Aiqg"/>
- <anchorage xmi:id="_D6EPMwO8EdubhrgDuRb4fA" guid="_D6EPMwO8EdubhrgDuRb4fA"/>
- <anchorage xmi:id="_-EfTMwPMEdubhrgDuRb4fA" guid="_-EfTMwPMEdubhrgDuRb4fA"/>
- <anchorage xmi:id="_8ZSTcxTUEduFIr9xNbwGyQ" guid="_8ZSTcxTUEduFIr9xNbwGyQ"/>
- <anchorage xmi:id="_5q5RuIGMEduKE9hnyImx1Q" guid="_5q5RuIGMEduKE9hnyImx1Q" graphEdge="_5q5Rt4GMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_51BeGIGMEduKE9hnyImx1Q" guid="_51BeGIGMEduKE9hnyImx1Q" graphEdge="_51BeF4GMEduKE9hnyImx1Q"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O96NMwNmEduYd-55D-Aiqg" guid="_O96NMwNmEduYd-55D-Aiqg" element="_glbG0QMAEduOAKqB9I73uw"/>
- <size xmi:id="_O96NNANmEduYd-55D-Aiqg" width="78.0" height="67.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O-GacANmEduYd-55D-Aiqg" guid="_O-GacANmEduYd-55D-Aiqg">
- <property xmi:id="_O-GacQNmEduYd-55D-Aiqg" guid="_O-GacQNmEduYd-55D-Aiqg" key="wpCompositeType" value="1"/>
- <position xmi:id="_O-GacgNmEduYd-55D-Aiqg" x="289.0" y="551.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_O-9WGgNmEduYd-55D-Aiqg" guid="_O-9WGgNmEduYd-55D-Aiqg" anchor="_O-9WGQNmEduYd-55D-Aiqg"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_oHjVtQNnEduYd-55D-Aiqg" guid="_oHjVtQNnEduYd-55D-Aiqg" anchor="_oHjVtANnEduYd-55D-Aiqg"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_D6EPNQO8EdubhrgDuRb4fA" guid="_D6EPNQO8EdubhrgDuRb4fA" anchor="_D6EPNAO8EdubhrgDuRb4fA"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_-EfTNQPMEdubhrgDuRb4fA" guid="_-EfTNQPMEdubhrgDuRb4fA" anchor="_-EfTNAPMEdubhrgDuRb4fA"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8ZSTdRTUEduFIr9xNbwGyQ" guid="_8ZSTdRTUEduFIr9xNbwGyQ" anchor="_8ZSTdBTUEduFIr9xNbwGyQ"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RuoGMEduKE9hnyImx1Q" guid="_5q5RuoGMEduKE9hnyImx1Q" anchor="_5q5RuYGMEduKE9hnyImx1Q _5q5Ru4GMEduKE9hnyImx1Q"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeGoGMEduKE9hnyImx1Q" guid="_51BeGoGMEduKE9hnyImx1Q" anchor="_51BeGYGMEduKE9hnyImx1Q _51BeG4GMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_O-9WGQNmEduYd-55D-Aiqg" guid="_O-9WGQNmEduYd-55D-Aiqg" graphEdge="_O-9WGgNmEduYd-55D-Aiqg"/>
- <anchorage xmi:id="_oHjVtANnEduYd-55D-Aiqg" guid="_oHjVtANnEduYd-55D-Aiqg" graphEdge="_oHjVtQNnEduYd-55D-Aiqg"/>
- <anchorage xmi:id="_D6EPNAO8EdubhrgDuRb4fA" guid="_D6EPNAO8EdubhrgDuRb4fA" graphEdge="_D6EPNQO8EdubhrgDuRb4fA"/>
- <anchorage xmi:id="_-EfTNAPMEdubhrgDuRb4fA" guid="_-EfTNAPMEdubhrgDuRb4fA" graphEdge="_-EfTNQPMEdubhrgDuRb4fA"/>
- <anchorage xmi:id="_8ZSTdBTUEduFIr9xNbwGyQ" guid="_8ZSTdBTUEduFIr9xNbwGyQ" graphEdge="_8ZSTdRTUEduFIr9xNbwGyQ"/>
- <anchorage xmi:id="_5q5RuYGMEduKE9hnyImx1Q" guid="_5q5RuYGMEduKE9hnyImx1Q" graphEdge="_5q5RuoGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_51BeGYGMEduKE9hnyImx1Q" guid="_51BeGYGMEduKE9hnyImx1Q" graphEdge="_51BeGoGMEduKE9hnyImx1Q"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O-GacwNmEduYd-55D-Aiqg" guid="_O-GacwNmEduYd-55D-Aiqg" element="_glbG0wMAEduOAKqB9I73uw"/>
- <size xmi:id="_O-GadANmEduYd-55D-Aiqg" width="78.0" height="67.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O-MhEANmEduYd-55D-Aiqg" guid="_O-MhEANmEduYd-55D-Aiqg">
- <property xmi:id="_O-MhEQNmEduYd-55D-Aiqg" guid="_O-MhEQNmEduYd-55D-Aiqg" key="wpCompositeType" value="2"/>
- <position xmi:id="_O-MhEgNmEduYd-55D-Aiqg" x="292.0" y="725.0"/>
- <anchorage xmi:id="_O-9WGwNmEduYd-55D-Aiqg" guid="_O-9WGwNmEduYd-55D-Aiqg"/>
- <anchorage xmi:id="_oHjVtgNnEduYd-55D-Aiqg" guid="_oHjVtgNnEduYd-55D-Aiqg"/>
- <anchorage xmi:id="_D6EPNgO8EdubhrgDuRb4fA" guid="_D6EPNgO8EdubhrgDuRb4fA"/>
- <anchorage xmi:id="_-EfTNgPMEdubhrgDuRb4fA" guid="_-EfTNgPMEdubhrgDuRb4fA"/>
- <anchorage xmi:id="_8ZSTdhTUEduFIr9xNbwGyQ" guid="_8ZSTdhTUEduFIr9xNbwGyQ"/>
- <anchorage xmi:id="_5q5RvoGMEduKE9hnyImx1Q" guid="_5q5RvoGMEduKE9hnyImx1Q" graphEdge="_5q5RvYGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_51BeHoGMEduKE9hnyImx1Q" guid="_51BeHoGMEduKE9hnyImx1Q" graphEdge="_51BeHYGMEduKE9hnyImx1Q"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O-MhEwNmEduYd-55D-Aiqg" guid="_O-MhEwNmEduYd-55D-Aiqg" element="_glbG0wMAEduOAKqB9I73uw"/>
- <size xmi:id="_O-MhFANmEduYd-55D-Aiqg" width="72.0" height="67.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O-YuUANmEduYd-55D-Aiqg" guid="_O-YuUANmEduYd-55D-Aiqg">
- <property xmi:id="_O-YuUQNmEduYd-55D-Aiqg" guid="_O-YuUQNmEduYd-55D-Aiqg" key="wpCompositeType" value="2"/>
- <position xmi:id="_O-YuUgNmEduYd-55D-Aiqg" x="121.0" y="725.0"/>
- <anchorage xmi:id="_O-9WHANmEduYd-55D-Aiqg" guid="_O-9WHANmEduYd-55D-Aiqg"/>
- <anchorage xmi:id="_oHjVtwNnEduYd-55D-Aiqg" guid="_oHjVtwNnEduYd-55D-Aiqg"/>
- <anchorage xmi:id="_D6EPNwO8EdubhrgDuRb4fA" guid="_D6EPNwO8EdubhrgDuRb4fA"/>
- <anchorage xmi:id="_-EfTNwPMEdubhrgDuRb4fA" guid="_-EfTNwPMEdubhrgDuRb4fA"/>
- <anchorage xmi:id="_8ZSTdxTUEduFIr9xNbwGyQ" guid="_8ZSTdxTUEduFIr9xNbwGyQ"/>
- <anchorage xmi:id="_5q5RwYGMEduKE9hnyImx1Q" guid="_5q5RwYGMEduKE9hnyImx1Q" graphEdge="_5q5RwIGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_51BeIYGMEduKE9hnyImx1Q" guid="_51BeIYGMEduKE9hnyImx1Q" graphEdge="_51BeIIGMEduKE9hnyImx1Q"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O-YuUwNmEduYd-55D-Aiqg" guid="_O-YuUwNmEduYd-55D-Aiqg" element="_glbG1AMAEduOAKqB9I73uw"/>
- <size xmi:id="_O-YuVANmEduYd-55D-Aiqg" width="78.0" height="67.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O-k7kANmEduYd-55D-Aiqg" guid="_O-k7kANmEduYd-55D-Aiqg">
- <property xmi:id="_O-k7kQNmEduYd-55D-Aiqg" guid="_O-k7kQNmEduYd-55D-Aiqg" key="wpCompositeType" value="1"/>
- <position xmi:id="_O-k7kgNmEduYd-55D-Aiqg" x="216.0" y="565.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_O-9WHgNmEduYd-55D-Aiqg" guid="_O-9WHgNmEduYd-55D-Aiqg" anchor="_O-9WHQNmEduYd-55D-Aiqg"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_oHjVuQNnEduYd-55D-Aiqg" guid="_oHjVuQNnEduYd-55D-Aiqg" anchor="_oHjVuANnEduYd-55D-Aiqg"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_D6EPOQO8EdubhrgDuRb4fA" guid="_D6EPOQO8EdubhrgDuRb4fA" anchor="_D6EPOAO8EdubhrgDuRb4fA"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_-EfTOQPMEdubhrgDuRb4fA" guid="_-EfTOQPMEdubhrgDuRb4fA" anchor="_-EfTOAPMEdubhrgDuRb4fA"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8ZSTeRTUEduFIr9xNbwGyQ" guid="_8ZSTeRTUEduFIr9xNbwGyQ" anchor="_8ZSTeBTUEduFIr9xNbwGyQ"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5Rw4GMEduKE9hnyImx1Q" guid="_5q5Rw4GMEduKE9hnyImx1Q" anchor="_5q5RwoGMEduKE9hnyImx1Q _5q5RxIGMEduKE9hnyImx1Q"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeI4GMEduKE9hnyImx1Q" guid="_51BeI4GMEduKE9hnyImx1Q" anchor="_51BeIoGMEduKE9hnyImx1Q _51BeJIGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_O-9WHQNmEduYd-55D-Aiqg" guid="_O-9WHQNmEduYd-55D-Aiqg" graphEdge="_O-9WHgNmEduYd-55D-Aiqg"/>
- <anchorage xmi:id="_oHjVuANnEduYd-55D-Aiqg" guid="_oHjVuANnEduYd-55D-Aiqg" graphEdge="_oHjVuQNnEduYd-55D-Aiqg"/>
- <anchorage xmi:id="_D6EPOAO8EdubhrgDuRb4fA" guid="_D6EPOAO8EdubhrgDuRb4fA" graphEdge="_D6EPOQO8EdubhrgDuRb4fA"/>
- <anchorage xmi:id="_-EfTOAPMEdubhrgDuRb4fA" guid="_-EfTOAPMEdubhrgDuRb4fA" graphEdge="_-EfTOQPMEdubhrgDuRb4fA"/>
- <anchorage xmi:id="_8ZSTeBTUEduFIr9xNbwGyQ" guid="_8ZSTeBTUEduFIr9xNbwGyQ" graphEdge="_8ZSTeRTUEduFIr9xNbwGyQ"/>
- <anchorage xmi:id="_5q5RwoGMEduKE9hnyImx1Q" guid="_5q5RwoGMEduKE9hnyImx1Q" graphEdge="_5q5Rw4GMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_51BeIoGMEduKE9hnyImx1Q" guid="_51BeIoGMEduKE9hnyImx1Q" graphEdge="_51BeI4GMEduKE9hnyImx1Q"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O-k7kwNmEduYd-55D-Aiqg" guid="_O-k7kwNmEduYd-55D-Aiqg" element="_glbG1QMAEduOAKqB9I73uw"/>
- <size xmi:id="_O-k7lANmEduYd-55D-Aiqg" width="63.0" height="53.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O-rCMANmEduYd-55D-Aiqg" guid="_O-rCMANmEduYd-55D-Aiqg">
- <property xmi:id="_O-rCMQNmEduYd-55D-Aiqg" guid="_O-rCMQNmEduYd-55D-Aiqg" key="wpCompositeType" value="2"/>
- <position xmi:id="_O-rCMgNmEduYd-55D-Aiqg" x="209.0" y="725.0"/>
- <anchorage xmi:id="_O-9WHwNmEduYd-55D-Aiqg" guid="_O-9WHwNmEduYd-55D-Aiqg"/>
- <anchorage xmi:id="_oHjVugNnEduYd-55D-Aiqg" guid="_oHjVugNnEduYd-55D-Aiqg"/>
- <anchorage xmi:id="_D6EPOgO8EdubhrgDuRb4fA" guid="_D6EPOgO8EdubhrgDuRb4fA"/>
- <anchorage xmi:id="_-EfTOgPMEdubhrgDuRb4fA" guid="_-EfTOgPMEdubhrgDuRb4fA"/>
- <anchorage xmi:id="_8ZSTehTUEduFIr9xNbwGyQ" guid="_8ZSTehTUEduFIr9xNbwGyQ"/>
- <anchorage xmi:id="_5q5Rx4GMEduKE9hnyImx1Q" guid="_5q5Rx4GMEduKE9hnyImx1Q" graphEdge="_5q5RxoGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_51BeJ4GMEduKE9hnyImx1Q" guid="_51BeJ4GMEduKE9hnyImx1Q" graphEdge="_51BeJoGMEduKE9hnyImx1Q"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O-rCMwNmEduYd-55D-Aiqg" guid="_O-rCMwNmEduYd-55D-Aiqg" element="_glbG1QMAEduOAKqB9I73uw"/>
- <size xmi:id="_O-rCNANmEduYd-55D-Aiqg" width="78.0" height="67.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O-xI0ANmEduYd-55D-Aiqg" guid="_O-xI0ANmEduYd-55D-Aiqg">
- <property xmi:id="_O-xI0QNmEduYd-55D-Aiqg" guid="_O-xI0QNmEduYd-55D-Aiqg" key="wpCompositeType" value="1"/>
- <position xmi:id="_O-xI0gNmEduYd-55D-Aiqg" x="249.0" y="1.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_O-9WIQNmEduYd-55D-Aiqg" guid="_O-9WIQNmEduYd-55D-Aiqg" anchor="_O-9WIANmEduYd-55D-Aiqg"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_oHjVvANnEduYd-55D-Aiqg" guid="_oHjVvANnEduYd-55D-Aiqg" anchor="_oHjVuwNnEduYd-55D-Aiqg"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_D6EPPAO8EdubhrgDuRb4fA" guid="_D6EPPAO8EdubhrgDuRb4fA" anchor="_D6EPOwO8EdubhrgDuRb4fA"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_-EfTPAPMEdubhrgDuRb4fA" guid="_-EfTPAPMEdubhrgDuRb4fA" anchor="_-EfTOwPMEdubhrgDuRb4fA"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_8ZSTfBTUEduFIr9xNbwGyQ" guid="_8ZSTfBTUEduFIr9xNbwGyQ" anchor="_8ZSTexTUEduFIr9xNbwGyQ"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_5q5RyYGMEduKE9hnyImx1Q" guid="_5q5RyYGMEduKE9hnyImx1Q" anchor="_5q5RyIGMEduKE9hnyImx1Q _5q5RyoGMEduKE9hnyImx1Q"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_51BeKYGMEduKE9hnyImx1Q" guid="_51BeKYGMEduKE9hnyImx1Q" anchor="_51BeKIGMEduKE9hnyImx1Q _51BeKoGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_O-9WIANmEduYd-55D-Aiqg" guid="_O-9WIANmEduYd-55D-Aiqg" graphEdge="_O-9WIQNmEduYd-55D-Aiqg"/>
- <anchorage xmi:id="_oHjVuwNnEduYd-55D-Aiqg" guid="_oHjVuwNnEduYd-55D-Aiqg" graphEdge="_oHjVvANnEduYd-55D-Aiqg"/>
- <anchorage xmi:id="_D6EPOwO8EdubhrgDuRb4fA" guid="_D6EPOwO8EdubhrgDuRb4fA" graphEdge="_D6EPPAO8EdubhrgDuRb4fA"/>
- <anchorage xmi:id="_-EfTOwPMEdubhrgDuRb4fA" guid="_-EfTOwPMEdubhrgDuRb4fA" graphEdge="_-EfTPAPMEdubhrgDuRb4fA"/>
- <anchorage xmi:id="_8ZSTexTUEduFIr9xNbwGyQ" guid="_8ZSTexTUEduFIr9xNbwGyQ" graphEdge="_8ZSTfBTUEduFIr9xNbwGyQ"/>
- <anchorage xmi:id="_5q5RyIGMEduKE9hnyImx1Q" guid="_5q5RyIGMEduKE9hnyImx1Q" graphEdge="_5q5RyYGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_51BeKIGMEduKE9hnyImx1Q" guid="_51BeKIGMEduKE9hnyImx1Q" graphEdge="_51BeKYGMEduKE9hnyImx1Q"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O-xI0wNmEduYd-55D-Aiqg" guid="_O-xI0wNmEduYd-55D-Aiqg" element="_glbG1gMAEduOAKqB9I73uw"/>
- <size xmi:id="_O-xI1ANmEduYd-55D-Aiqg" width="72.0" height="67.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O-9WEANmEduYd-55D-Aiqg" guid="_O-9WEANmEduYd-55D-Aiqg">
- <property xmi:id="_O-9WEQNmEduYd-55D-Aiqg" guid="_O-9WEQNmEduYd-55D-Aiqg" key="wpCompositeType" value="2"/>
- <position xmi:id="_O-9WEgNmEduYd-55D-Aiqg" x="249.0" y="161.0"/>
- <anchorage xmi:id="_O-9WIgNmEduYd-55D-Aiqg" guid="_O-9WIgNmEduYd-55D-Aiqg"/>
- <anchorage xmi:id="_oHjVvQNnEduYd-55D-Aiqg" guid="_oHjVvQNnEduYd-55D-Aiqg"/>
- <anchorage xmi:id="_D6EPPQO8EdubhrgDuRb4fA" guid="_D6EPPQO8EdubhrgDuRb4fA"/>
- <anchorage xmi:id="_-EfTPQPMEdubhrgDuRb4fA" guid="_-EfTPQPMEdubhrgDuRb4fA"/>
- <anchorage xmi:id="_8ZSTfRTUEduFIr9xNbwGyQ" guid="_8ZSTfRTUEduFIr9xNbwGyQ"/>
- <anchorage xmi:id="_5q5RzYGMEduKE9hnyImx1Q" guid="_5q5RzYGMEduKE9hnyImx1Q" graphEdge="_5q5RzIGMEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_51BeLYGMEduKE9hnyImx1Q" guid="_51BeLYGMEduKE9hnyImx1Q" graphEdge="_51BeLIGMEduKE9hnyImx1Q"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O-9WEwNmEduYd-55D-Aiqg" guid="_O-9WEwNmEduYd-55D-Aiqg" element="_glbG1gMAEduOAKqB9I73uw"/>
- <size xmi:id="_O-9WFANmEduYd-55D-Aiqg" width="72.0" height="67.0"/>
- </contained>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_O8q3OgNmEduYd-55D-Aiqg" guid="_O8q3OgNmEduYd-55D-Aiqg" presentation="Activity Detail" element="_SoXWEQMAEduOAKqB9I73uw"/>
- </diagrams>
- </childPackages>
- <processElements xsi:type="org.eclipse.epf.uma:Phase" xmi:id="_NSW6sQMAEduOAKqB9I73uw" name="Sprint Phase" guid="_NSW6sQMAEduOAKqB9I73uw" briefDescription="Cette phase consiste à dérouler les sprints les uns après les autres " presentationName="Phase des sprints" isPlanned="false" superActivities="_9llsAQAvEdubGMceRDupFQ" linkToPredecessor="_9MP9UAMAEduOAKqB9I73uw" breakdownElements="_SoXWEQMAEduOAKqB9I73uw _zbM2QIGBEduKE9hnyImx1Q _MpXRYIGOEduKE9hnyImx1Q _RHd0YIGOEduKE9hnyImx1Q"/>
- <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_9MP9UAMAEduOAKqB9I73uw" guid="_9MP9UAMAEduOAKqB9I73uw" linkType="finishToFinish" pred="_37TdkAL_EduOAKqB9I73uw"/>
- <processElements xsi:type="org.eclipse.epf.uma:TaskDescriptor" xmi:id="_zbM2QIGBEduKE9hnyImx1Q" name="Sprint de release" guid="_zbM2QIGBEduKE9hnyImx1Q" briefDescription="Ce dernier sprint permet de préparer la livraison du produit." presentationName="Travaux de livraison" isPlanned="true" isOptional="true" superActivities="_NSW6sQMAEduOAKqB9I73uw" isRepeatable="true" mandatoryInput="_RHd0YIGOEduKE9hnyImx1Q" output="_RHd0YIGOEduKE9hnyImx1Q" performedPrimarilyBy="_MpXRYIGOEduKE9hnyImx1Q">
- <presentation xmi:id="-EOwIzNPjfNIjzJ3TRAgeWQ" href="uma://-16dzhVoCex78V2iCDZVx0w#-EOwIzNPjfNIjzJ3TRAgeWQ"/>
- </processElements>
- <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_MpXRYIGOEduKE9hnyImx1Q" name="Team" guid="_MpXRYIGOEduKE9hnyImx1Q" presentationName="Equipe Scrum" hasMultipleOccurrences="true" superActivities="_NSW6sQMAEduOAKqB9I73uw">
- <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_9apLsPpaEdqsc-f87sBK8A"/>
- </processElements>
- <processElements xsi:type="org.eclipse.epf.uma:WorkProductDescriptor" xmi:id="_RHd0YIGOEduKE9hnyImx1Q" name="Product increment" guid="_RHd0YIGOEduKE9hnyImx1Q" presentationName="Incrément de produit" superActivities="_NSW6sQMAEduOAKqB9I73uw">
- <WorkProduct xsi:type="org.eclipse.epf.uma:Artifact" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_tCmYEP-xEdqLnajTSLeAsA"/>
- </processElements>
- <diagrams xmi:id="_N15QIAMBEduOAKqB9I73uw" guid="_N15QIAMBEduOAKqB9I73uw">
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_N15QIQMBEduOAKqB9I73uw" guid="_N15QIQMBEduOAKqB9I73uw">
- <position xmi:id="_N15QIgMBEduOAKqB9I73uw" x="204.0" y="49.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_APACQWaOEduYmqfjmBwflA" guid="_APACQWaOEduYmqfjmBwflA" anchor="_APACQGaOEduYmqfjmBwflA _APACQmaOEduYmqfjmBwflA"/>
- <anchorage xmi:id="__iwAQmaNEduYmqfjmBwflA" guid="__iwAQmaNEduYmqfjmBwflA" graphEdge="__iwAQWaNEduYmqfjmBwflA"/>
- <anchorage xmi:id="_APACQGaOEduYmqfjmBwflA" guid="_APACQGaOEduYmqfjmBwflA" graphEdge="_APACQWaOEduYmqfjmBwflA">
- <position xmi:id="_APACQ2aOEduYmqfjmBwflA" x="212.0" y="44.0"/>
- </anchorage>
- <anchorage xmi:id="_K_vA8maOEduYmqfjmBwflA" guid="_K_vA8maOEduYmqfjmBwflA" graphEdge="_K_vA8WaOEduYmqfjmBwflA"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_N15QIwMBEduOAKqB9I73uw" guid="_N15QIwMBEduOAKqB9I73uw" element="_SoXWEQMAEduOAKqB9I73uw"/>
- <size xmi:id="_N15QJAMBEduOAKqB9I73uw" width="40.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_8BvXoGaNEduYmqfjmBwflA" guid="_8BvXoGaNEduYmqfjmBwflA">
- <position xmi:id="_8BvXoWaNEduYmqfjmBwflA" x="94.0" y="62.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="__iwAQWaNEduYmqfjmBwflA" guid="__iwAQWaNEduYmqfjmBwflA" anchor="__iwAQGaNEduYmqfjmBwflA __iwAQmaNEduYmqfjmBwflA"/>
- <anchorage xmi:id="__iwAQGaNEduYmqfjmBwflA" guid="__iwAQGaNEduYmqfjmBwflA" graphEdge="__iwAQWaNEduYmqfjmBwflA">
- <position xmi:id="__iwAQ2aNEduYmqfjmBwflA" x="94.0" y="51.0"/>
- </anchorage>
- <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_8BvXomaNEduYmqfjmBwflA" guid="_8BvXomaNEduYmqfjmBwflA" typeInfo="start node"/>
- <size xmi:id="_8BvXo2aNEduYmqfjmBwflA" width="19.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_8oyJgGaNEduYmqfjmBwflA" guid="_8oyJgGaNEduYmqfjmBwflA">
- <position xmi:id="_8oyJgWaNEduYmqfjmBwflA" x="613.0" y="60.0"/>
- <anchorage xmi:id="_7lIDYoGEEduKE9hnyImx1Q" guid="_7lIDYoGEEduKE9hnyImx1Q" graphEdge="_7lIDYYGEEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_hKUjEoGFEduKE9hnyImx1Q" guid="_hKUjEoGFEduKE9hnyImx1Q" graphEdge="_hKUjEYGFEduKE9hnyImx1Q"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_8oyJgmaNEduYmqfjmBwflA" guid="_8oyJgmaNEduYmqfjmBwflA" typeInfo="end node"/>
- <size xmi:id="_8oyJg2aNEduYmqfjmBwflA" width="26.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_9kPFIGaNEduYmqfjmBwflA" guid="_9kPFIGaNEduYmqfjmBwflA">
- <position xmi:id="_9kPFIWaNEduYmqfjmBwflA" x="343.0" y="60.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_K_vA8WaOEduYmqfjmBwflA" guid="_K_vA8WaOEduYmqfjmBwflA" anchor="_K_vA8GaOEduYmqfjmBwflA _K_vA8maOEduYmqfjmBwflA">
- <waypoints xmi:id="_R-7AoGaOEduYmqfjmBwflA" x="363.0" y="17.0"/>
- <waypoints xmi:id="_QXWl4GaOEduYmqfjmBwflA" x="222.0" y="17.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_a2plkYGFEduKE9hnyImx1Q" guid="_a2plkYGFEduKE9hnyImx1Q" anchor="_a2plkIGFEduKE9hnyImx1Q _a2plkoGFEduKE9hnyImx1Q">
- <waypoints xmi:id="_DyIEkIGGEduKE9hnyImx1Q" x="363.0" y="133.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_hKUjEYGFEduKE9hnyImx1Q" guid="_hKUjEYGFEduKE9hnyImx1Q" anchor="_hKUjEIGFEduKE9hnyImx1Q _hKUjEoGFEduKE9hnyImx1Q">
- <waypoints xmi:id="_9g1ssIGFEduKE9hnyImx1Q" x="575.0" y="71.0"/>
- </contained>
- <anchorage xmi:id="_APACQmaOEduYmqfjmBwflA" guid="_APACQmaOEduYmqfjmBwflA" graphEdge="_APACQWaOEduYmqfjmBwflA">
- <position xmi:id="_APACRGaOEduYmqfjmBwflA" x="0.0" y="11.0"/>
- </anchorage>
- <anchorage xmi:id="_K_vA8GaOEduYmqfjmBwflA" guid="_K_vA8GaOEduYmqfjmBwflA" graphEdge="_K_vA8WaOEduYmqfjmBwflA">
- <position xmi:id="_K_vA82aOEduYmqfjmBwflA" x="21.0" y="0.0"/>
- </anchorage>
- <anchorage xmi:id="_a2plkIGFEduKE9hnyImx1Q" guid="_a2plkIGFEduKE9hnyImx1Q" graphEdge="_a2plkYGFEduKE9hnyImx1Q">
- <position xmi:id="_Ais7MIGGEduKE9hnyImx1Q" x="21.0" y="23.0"/>
- </anchorage>
- <anchorage xmi:id="_hKUjEIGFEduKE9hnyImx1Q" guid="_hKUjEIGFEduKE9hnyImx1Q" graphEdge="_hKUjEYGFEduKE9hnyImx1Q">
- <position xmi:id="_9C4lYIGFEduKE9hnyImx1Q" x="42.0" y="11.0"/>
- </anchorage>
- <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_9kPFImaNEduYmqfjmBwflA" guid="_9kPFImaNEduYmqfjmBwflA" typeInfo="decision node"/>
- <size xmi:id="_9kPFI2aNEduYmqfjmBwflA" width="43.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_-UpVwHoSEduJVrY6eKG_mw" name="Add Free Text" guid="_-UpVwHoSEduJVrY6eKG_mw">
- <property xmi:id="_-UpVwXoSEduJVrY6eKG_mw" guid="_-UpVwXoSEduJVrY6eKG_mw" key="free text" value="livraison à préparer"/>
- <position xmi:id="_-UpVwnoSEduJVrY6eKG_mw" x="377.0" y="102.0"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_-UpVw3oSEduJVrY6eKG_mw" guid="_-UpVw3oSEduJVrY6eKG_mw" typeInfo="free text"/>
- <size xmi:id="_-UpVxHoSEduJVrY6eKG_mw" width="69.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_O1l_kHoTEduJVrY6eKG_mw" name="Add Free Text" guid="_O1l_kHoTEduJVrY6eKG_mw">
- <property xmi:id="_O1l_kXoTEduJVrY6eKG_mw" guid="_O1l_kXoTEduJVrY6eKG_mw" key="free text" value="encore un sprint"/>
- <position xmi:id="_O1l_knoTEduJVrY6eKG_mw" x="237.0" y="0.0"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_O1l_k3oTEduJVrY6eKG_mw" guid="_O1l_k3oTEduJVrY6eKG_mw" typeInfo="free text"/>
- <size xmi:id="_O1l_lHoTEduJVrY6eKG_mw" width="79.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_4SofQIGBEduKE9hnyImx1Q" guid="_4SofQIGBEduKE9hnyImx1Q">
- <position xmi:id="_4SofQYGBEduKE9hnyImx1Q" x="457.0" y="104.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_7lIDYYGEEduKE9hnyImx1Q" guid="_7lIDYYGEEduKE9hnyImx1Q" anchor="_7lIDYIGEEduKE9hnyImx1Q _7lIDYoGEEduKE9hnyImx1Q">
- <waypoints xmi:id="_FGeBUIGGEduKE9hnyImx1Q" x="626.0" y="133.0"/>
- </contained>
- <anchorage xmi:id="_7lIDYIGEEduKE9hnyImx1Q" guid="_7lIDYIGEEduKE9hnyImx1Q" graphEdge="_7lIDYYGEEduKE9hnyImx1Q">
- <position xmi:id="_7lIDY4GEEduKE9hnyImx1Q" x="509.0" y="67.0"/>
- </anchorage>
- <anchorage xmi:id="_a2plkoGFEduKE9hnyImx1Q" guid="_a2plkoGFEduKE9hnyImx1Q" graphEdge="_a2plkYGFEduKE9hnyImx1Q"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_4SofQoGBEduKE9hnyImx1Q" guid="_4SofQoGBEduKE9hnyImx1Q" element="_zbM2QIGBEduKE9hnyImx1Q"/>
- <size xmi:id="_4SofQ4GBEduKE9hnyImx1Q" width="82.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_JYpoMIGGEduKE9hnyImx1Q" name="Add Free Text" guid="_JYpoMIGGEduKE9hnyImx1Q">
- <property xmi:id="_JYpoMYGGEduKE9hnyImx1Q" guid="_JYpoMYGGEduKE9hnyImx1Q" key="free text" value="fin de release"/>
- <position xmi:id="_JYpoMoGGEduKE9hnyImx1Q" x="457.0" y="54.0"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_JYpoM4GGEduKE9hnyImx1Q" guid="_JYpoM4GGEduKE9hnyImx1Q" typeInfo="free text"/>
- <size xmi:id="_JYpoNIGGEduKE9hnyImx1Q" width="66.0" height="-1.0"/>
- </contained>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_N15QJQMBEduOAKqB9I73uw" guid="_N15QJQMBEduOAKqB9I73uw" presentation="Workflow" element="_NSW6sQMAEduOAKqB9I73uw"/>
- </diagrams>
- </childPackages>
- <processElements xsi:type="org.eclipse.epf.uma:WorkOrder" xmi:id="_E1ptMIF9EduKE9hnyImx1Q" guid="_E1ptMIF9EduKE9hnyImx1Q" linkType="finishToFinish" pred="_NSW6sQMAEduOAKqB9I73uw"/>
- <processElements xsi:type="org.eclipse.epf.uma:RoleDescriptor" xmi:id="_XJr8krPCEduk5O8SjA21Fg" name="Product Owner" guid="_XJr8krPCEduk5O8SjA21Fg" suppressed="true" presentationName="Directeur Produit" superActivities="_9llsAQAvEdubGMceRDupFQ">
- <Role href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_ICJyYPpaEdqsc-f87sBK8A"/>
- </processElements>
- <diagrams xmi:id="_kZvAwAChEduhO59Otqg2rw" guid="_kZvAwAChEduhO59Otqg2rw">
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_kZvAwQChEduhO59Otqg2rw" guid="_kZvAwQChEduhO59Otqg2rw">
- <position xmi:id="_kZvAwgChEduhO59Otqg2rw" x="124.0" y="57.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_mj1g0QChEduhO59Otqg2rw" guid="_mj1g0QChEduhO59Otqg2rw" anchor="_mj1g0AChEduhO59Otqg2rw _mj1g0gChEduhO59Otqg2rw">
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_mkBuEQChEduhO59Otqg2rw" guid="_mkBuEQChEduhO59Otqg2rw"/>
- </contained>
- <anchorage xmi:id="_mj1g0AChEduhO59Otqg2rw" guid="_mj1g0AChEduhO59Otqg2rw" graphEdge="_mj1g0QChEduhO59Otqg2rw">
- <position xmi:id="_mj1g0wChEduhO59Otqg2rw" x="158.0" y="73.0"/>
- </anchorage>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_kZvAwwChEduhO59Otqg2rw" guid="_kZvAwwChEduhO59Otqg2rw"/>
- <size xmi:id="_kZvAxAChEduhO59Otqg2rw" width="55.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_kZvAxQChEduhO59Otqg2rw" guid="_kZvAxQChEduhO59Otqg2rw">
- <position xmi:id="_kZvAxgChEduhO59Otqg2rw" x="340.0" y="57.0"/>
- <anchorage xmi:id="_mj1g0gChEduhO59Otqg2rw" guid="_mj1g0gChEduhO59Otqg2rw" graphEdge="_mj1g0QChEduhO59Otqg2rw"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_kZvAxwChEduhO59Otqg2rw" guid="_kZvAxwChEduhO59Otqg2rw"/>
- <size xmi:id="_kZvAyAChEduhO59Otqg2rw" width="62.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_Ew8_sACiEduhO59Otqg2rw" name="Add Free Text" guid="_Ew8_sACiEduhO59Otqg2rw">
- <property xmi:id="_Ew8_sQCiEduhO59Otqg2rw" guid="_Ew8_sQCiEduhO59Otqg2rw" key="free text" value="les sprints successifs qui constituent la release"/>
- <position xmi:id="_Ew8_sgCiEduhO59Otqg2rw" x="299.0" y="87.0"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_Ew8_swCiEduhO59Otqg2rw" guid="_Ew8_swCiEduhO59Otqg2rw" typeInfo="free text"/>
- <size xmi:id="_Ew8_tACiEduhO59Otqg2rw" width="86.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_Nk0CAACiEduhO59Otqg2rw" name="Add Free Text" guid="_Nk0CAACiEduhO59Otqg2rw">
- <property xmi:id="_Nk6IoACiEduhO59Otqg2rw" guid="_Nk6IoACiEduhO59Otqg2rw" key="free text" value="Phase initiale avant le premier sprint"/>
- <position xmi:id="_Nk6IoQCiEduhO59Otqg2rw" x="134.0" y="89.0"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_Nk6IogCiEduhO59Otqg2rw" guid="_Nk6IogCiEduhO59Otqg2rw" typeInfo="free text"/>
- <size xmi:id="_Nk6IowCiEduhO59Otqg2rw" width="72.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_G5YwkAEKEduzRosbOajx7w" guid="_G5YwkAEKEduzRosbOajx7w">
- <position xmi:id="_G5e3MAEKEduzRosbOajx7w" x="109.0" y="43.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_Ivhy0QEKEduzRosbOajx7w" guid="_Ivhy0QEKEduzRosbOajx7w" anchor="_Ivhy0AEKEduzRosbOajx7w _Ivhy0gEKEduzRosbOajx7w">
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_Iv0GsQEKEduzRosbOajx7w" guid="_Iv0GsQEKEduzRosbOajx7w"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_ZSAOMQEsEduzRosbOajx7w" guid="_ZSAOMQEsEduzRosbOajx7w" anchor="_ZSAOMAEsEduzRosbOajx7w _ZSAOMgEsEduzRosbOajx7w">
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_ZSSiEQEsEduzRosbOajx7w" guid="_ZSSiEQEsEduzRosbOajx7w"/>
- </contained>
- <anchorage xmi:id="_Ivhy0AEKEduzRosbOajx7w" guid="_Ivhy0AEKEduzRosbOajx7w" graphEdge="_Ivhy0QEKEduzRosbOajx7w">
- <position xmi:id="_Ivhy0wEKEduzRosbOajx7w" x="152.0" y="58.0"/>
- </anchorage>
- <anchorage xmi:id="_ZSAOMAEsEduzRosbOajx7w" guid="_ZSAOMAEsEduzRosbOajx7w" graphEdge="_ZSAOMQEsEduzRosbOajx7w">
- <position xmi:id="_ZSAOMwEsEduzRosbOajx7w" x="135.0" y="60.0"/>
- </anchorage>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_G5e3MQEKEduzRosbOajx7w" guid="_G5e3MQEKEduzRosbOajx7w"/>
- <size xmi:id="_G5e3MgEKEduzRosbOajx7w" width="55.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_G5e3MwEKEduzRosbOajx7w" guid="_G5e3MwEKEduzRosbOajx7w">
- <position xmi:id="_G5e3NAEKEduzRosbOajx7w" x="337.0" y="41.0"/>
- <anchorage xmi:id="_Ivhy0gEKEduzRosbOajx7w" guid="_Ivhy0gEKEduzRosbOajx7w" graphEdge="_Ivhy0QEKEduzRosbOajx7w"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_G5e3NQEKEduzRosbOajx7w" guid="_G5e3NQEKEduzRosbOajx7w"/>
- <size xmi:id="_G5e3NgEKEduzRosbOajx7w" width="83.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_GOyb8AEsEduzRosbOajx7w" guid="_GOyb8AEsEduzRosbOajx7w">
- <position xmi:id="_GOyb8QEsEduzRosbOajx7w" x="359.0" y="43.0"/>
- <anchorage xmi:id="_ZSAOMgEsEduzRosbOajx7w" guid="_ZSAOMgEsEduzRosbOajx7w" graphEdge="_ZSAOMQEsEduzRosbOajx7w"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_GOyb8gEsEduzRosbOajx7w" guid="_GOyb8gEsEduzRosbOajx7w"/>
- <size xmi:id="_GOyb8wEsEduzRosbOajx7w" width="32.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6wY-4AMAEduOAKqB9I73uw" guid="_6wY-4AMAEduOAKqB9I73uw">
- <position xmi:id="_6wY-4QMAEduOAKqB9I73uw" x="112.0" y="25.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_9LxcMQMAEduOAKqB9I73uw" guid="_9LxcMQMAEduOAKqB9I73uw" anchor="_9LxcMAMAEduOAKqB9I73uw _9LxcMgMAEduOAKqB9I73uw">
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_9MP9UQMAEduOAKqB9I73uw" guid="_9MP9UQMAEduOAKqB9I73uw"/>
- </contained>
- <anchorage xmi:id="_9LxcMAMAEduOAKqB9I73uw" guid="_9LxcMAMAEduOAKqB9I73uw" graphEdge="_9LxcMQMAEduOAKqB9I73uw">
- <position xmi:id="_9LxcMwMAEduOAKqB9I73uw" x="151.0" y="42.0"/>
- </anchorage>
- <anchorage xmi:id="_D3KWIgMBEduOAKqB9I73uw" guid="_D3KWIgMBEduOAKqB9I73uw" graphEdge="_D3KWIQMBEduOAKqB9I73uw"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6wY-4gMAEduOAKqB9I73uw" guid="_6wY-4gMAEduOAKqB9I73uw" element="_37TdkAL_EduOAKqB9I73uw"/>
- <size xmi:id="_6wY-4wMAEduOAKqB9I73uw" width="103.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_6wY-5AMAEduOAKqB9I73uw" guid="_6wY-5AMAEduOAKqB9I73uw">
- <position xmi:id="_6wY-5QMAEduOAKqB9I73uw" x="295.0" y="25.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_EPaeEQMBEduOAKqB9I73uw" guid="_EPaeEQMBEduOAKqB9I73uw" anchor="_EPaeEAMBEduOAKqB9I73uw">
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_E1ptMYF9EduKE9hnyImx1Q" guid="_E1ptMYF9EduKE9hnyImx1Q"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_DVQF4YGHEduKE9hnyImx1Q" guid="_DVQF4YGHEduKE9hnyImx1Q" anchor="_DVQF4IGHEduKE9hnyImx1Q _DVQF4oGHEduKE9hnyImx1Q"/>
- <anchorage xmi:id="_9LxcMgMAEduOAKqB9I73uw" guid="_9LxcMgMAEduOAKqB9I73uw" graphEdge="_9LxcMQMAEduOAKqB9I73uw"/>
- <anchorage xmi:id="_EPaeEAMBEduOAKqB9I73uw" guid="_EPaeEAMBEduOAKqB9I73uw" graphEdge="_EPaeEQMBEduOAKqB9I73uw">
- <position xmi:id="_EPaeEwMBEduOAKqB9I73uw" x="340.0" y="44.0"/>
- </anchorage>
- <anchorage xmi:id="_DVQF4IGHEduKE9hnyImx1Q" guid="_DVQF4IGHEduKE9hnyImx1Q" graphEdge="_DVQF4YGHEduKE9hnyImx1Q">
- <position xmi:id="_ENbrEIGHEduKE9hnyImx1Q" x="343.0" y="41.0"/>
- </anchorage>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_6wY-5gMAEduOAKqB9I73uw" guid="_6wY-5gMAEduOAKqB9I73uw" element="_NSW6sQMAEduOAKqB9I73uw"/>
- <size xmi:id="_6wY-5wMAEduOAKqB9I73uw" width="87.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_CL_00AMBEduOAKqB9I73uw" guid="_CL_00AMBEduOAKqB9I73uw">
- <position xmi:id="_CL_00QMBEduOAKqB9I73uw" x="39.0" y="38.0"/>
- <contained xsi:type="org.eclipse.epf.uma:GraphEdge" xmi:id="_D3KWIQMBEduOAKqB9I73uw" guid="_D3KWIQMBEduOAKqB9I73uw" anchor="_D3KWIAMBEduOAKqB9I73uw _D3KWIgMBEduOAKqB9I73uw"/>
- <anchorage xmi:id="_D3KWIAMBEduOAKqB9I73uw" guid="_D3KWIAMBEduOAKqB9I73uw" graphEdge="_D3KWIQMBEduOAKqB9I73uw">
- <position xmi:id="_D3KWIwMBEduOAKqB9I73uw" x="46.0" y="44.0"/>
- </anchorage>
- <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_CL_00gMBEduOAKqB9I73uw" guid="_CL_00gMBEduOAKqB9I73uw" typeInfo="start node"/>
- <size xmi:id="_CL_00wMBEduOAKqB9I73uw" width="20.0" height="-1.0"/>
- </contained>
- <contained xsi:type="org.eclipse.epf.uma:GraphNode" xmi:id="_DDxxYAMBEduOAKqB9I73uw" guid="_DDxxYAMBEduOAKqB9I73uw">
- <position xmi:id="_DD34AAMBEduOAKqB9I73uw" x="456.0" y="36.0"/>
- <anchorage xmi:id="_DVQF4oGHEduKE9hnyImx1Q" guid="_DVQF4oGHEduKE9hnyImx1Q" graphEdge="_DVQF4YGHEduKE9hnyImx1Q"/>
- <semanticModel xsi:type="org.eclipse.epf.uma:SimpleSemanticModelElement" xmi:id="_DD34AQMBEduOAKqB9I73uw" guid="_DD34AQMBEduOAKqB9I73uw" typeInfo="end node"/>
- <size xmi:id="_DD34AgMBEduOAKqB9I73uw" width="24.0" height="-1.0"/>
- </contained>
- <semanticModel xsi:type="org.eclipse.epf.uma:UMASemanticModelBridge" xmi:id="_kZvAyQChEduhO59Otqg2rw" guid="_kZvAyQChEduhO59Otqg2rw" presentation="Workflow" element="_9llsAQAvEdubGMceRDupFQ"/>
- </diagrams>
- <process xsi:type="org.eclipse.epf.uma:DeliveryProcess" xmi:id="_9llsAQAvEdubGMceRDupFQ" name="Scrum" guid="_9llsAQAvEdubGMceRDupFQ" briefDescription="Les phases, les sprints et les tâches à dérouler lors de la production d'une release." presentationName="Release" isRepeatable="true" breakdownElements="_37TdkAL_EduOAKqB9I73uw _NSW6sQMAEduOAKqB9I73uw _XJr8krPCEduk5O8SjA21Fg">
- <presentation xmi:id="-16dzhVoCex78V2iCDZVx0w" href="uma://-16dzhVoCex78V2iCDZVx0w#-16dzhVoCex78V2iCDZVx0w"/>
- <concepts href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_XtRuYP-zEdqLnajTSLeAsA"/>
- <defaultContext href="uma://_hDRYYPpYEdqsc-f87sBK8A#_IqDLgP_OEdqtbrr0B1TG-A"/>
- <validContext href="uma://_hDRYYPpYEdqsc-f87sBK8A#_IqDLgP_OEdqtbrr0B1TG-A"/>
- </process>
- </org.eclipse.epf.uma:ProcessComponent>
-</xmi:XMI>
diff --git a/Scrum French/Scrum/deliveryprocesses/resources/csm.jpg b/Scrum French/Scrum/deliveryprocesses/resources/csm.jpg
deleted file mode 100644
index 18cd417..0000000
--- a/Scrum French/Scrum/deliveryprocesses/resources/csm.jpg
+++ /dev/null
Binary files differ
diff --git a/Scrum French/Scrum/deliveryprocesses/resources/icescrum_simple.gif b/Scrum French/Scrum/deliveryprocesses/resources/icescrum_simple.gif
deleted file mode 100644
index e7d73b3..0000000
--- a/Scrum French/Scrum/deliveryprocesses/resources/icescrum_simple.gif
+++ /dev/null
Binary files differ
diff --git a/Scrum French/Scrum/deliveryprocesses/resources/icescrum_simple.jpg b/Scrum French/Scrum/deliveryprocesses/resources/icescrum_simple.jpg
deleted file mode 100644
index bc69128..0000000
--- a/Scrum French/Scrum/deliveryprocesses/resources/icescrum_simple.jpg
+++ /dev/null
Binary files differ
diff --git a/Scrum French/Scrum/deliveryprocesses/resources/icescrum_simple.png b/Scrum French/Scrum/deliveryprocesses/resources/icescrum_simple.png
deleted file mode 100644
index a91525c..0000000
--- a/Scrum French/Scrum/deliveryprocesses/resources/icescrum_simple.png
+++ /dev/null
Binary files differ
diff --git a/Scrum French/Scrum/disciplines/Scrum activities.xmi b/Scrum French/Scrum/disciplines/Scrum activities.xmi
deleted file mode 100644
index 48a8e24..0000000
--- a/Scrum French/Scrum/disciplines/Scrum activities.xmi
+++ /dev/null
@@ -1,8 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-4wqJQ0qXLYZ8kCnpDu--tA" name="Scrum activities,_6sdMAAL-EduOAKqB9I73uw" guid="-4wqJQ0qXLYZ8kCnpDu--tA" changeDate="2006-12-03T10:43:16.000+0100" version="1.0.0">
- <mainDescription><p>
- L'application de Scrum concerne essentiellement&nbsp;les disciplines habituelles de gestion de projet et de gestion des
- exigences.
-</p></mainDescription>
- <keyConsiderations>Une bonne partie de ces activités est effectuée collectivement,&nbsp;en équipe.</keyConsiderations>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum French/Scrum/guidances/concepts/Presentation Scrum.xmi b/Scrum French/Scrum/guidances/concepts/Presentation Scrum.xmi
deleted file mode 100644
index b707be0..0000000
--- a/Scrum French/Scrum/guidances/concepts/Presentation Scrum.xmi
+++ /dev/null
@@ -1,81 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-MSO8KF-0IlKZJGnSwwTNZA" name="new_concept,_3WivIBTQEduFIr9xNbwGyQ" guid="-MSO8KF-0IlKZJGnSwwTNZA" changeDate="2006-12-03T08:21:54.843+0100" version="1.0.0">
- <mainDescription><p>
- Scrum est un processus léger et itératif de gestion de projets, qui fait partie de la famille des <a
- title="Méthode agile" href="http://fr.wikipedia.org/wiki/Méthode_agile">méthodes agiles</a>, qui partage les valeurs
- définies dans le Manifeste Agile et qui en reprend les principes fondamentaux.
-</p>
-<h5>
- Résumé
-</h5>
-<p>
- Scrum peut se résumer ainsi :
-</p>
-<p class="quote">
- Scrum conduit à montrer souvent et régulièrement (toutes les 2 à 4 semaines, selon la durée du <a class="elementLink"
- href="./../../../Scrum/guidances/termdefinitions/Sprint,_kftWoIHqEduFs9jH8xc4xw.html"
- guid="_kftWoIHqEduFs9jH8xc4xw">Sprint</a>) un produit (partiel) qui fonctionne. Le métier identifie les exigences et
- définit leur priorité. L'équipe s'organise elle-même pour déterminer la meilleure façon de produire les exigences les
- plus prioritaires. A chaque fin de sprint, tout le monde peut voir fonctionner le produit actuel et contribuer à
- prendre une décision sur ce qu'on fait&nbsp;: soit le livrer dans l'état, soit continuer à l'améliorer pendant&nbsp;un
- sprint&nbsp;supplémentaire avant de se reposer la question.
-</p>
-<h5>
- Origine
-</h5>
-<p>
- Le terme Scrum est emprunté au rugby et signifie mêlée. Ce processus s'articule en effet autour d'une équipe soudée,
- qui cherche à atteindre un but, comme c'est le cas au rugby quand le pack déploie sa force collective pour avancer avec
- le ballon pendant une mêlée.
-</p>
-<p>
- Scrum insiste particulièrement sur l’aspect social et collectif du développement. Le but de Scrum est d'améliorer la
- qualité et la productivité, avec une approche empirique, en s'appuyant sur l'autonomie de l'équipe.
-</p>
-<h5>
- Empirisme
-</h5>
-<p>
- Un processus empirique, donc basé sur l'expérience, nécessite une bonne visibilité, des inspections fréquentes et des
- adaptations aux plans. Cela se décline dans Scrum par les 2 cycles de régulation&nbsp;:
-</p>
-<ul>
- <li>
- lors de mêlées quotidiennes, on tient compte de l'expérience du jour passé pour adapter le planning des jours
- restant dans le sprint.
- </li>
- <li>
- lors des revues de sprint, on tient compte de l'expérience du sprint passé pour adapter le planning de la release,
- portant sur les sprints à venir.
- </li>
-</ul>
-<p>
- Les tâches d'un sprint ne sont pas définies de façon très précise : pas de date de début, pas de date de fin, pas de
- dépendance. Scrum considère que ce n'est pas prévisible. L'empirisme de Scrum consiste à s'appuyer continuellement sur
- l'analyse de l'état courant du projet pour contrôler le processus et réduire les risques.
-</p>
-<h5>
- Portée
-</h5>
-<p>
- Scrum ne décrit pas toutes les disciplines du développement (analyse, conception, codage, test) et doit être considéré,
- plutôt qu’un processus complet, comme un pattern de processus qui est&nbsp;concerne la gestion de projet et la gestion
- des exigences. Scrum ne fournit pas d’aide pour la réalisation des activités techniques du développement. C'est à
- l'équipe de définir elle-même ce qu'elle à faire.
-</p>
-<h5>
- Diffusion
-</h5>
-<p>
- Scrum existe depuis les années 90 et connaît une popularité croissante depuis quelques années. Il a été utilisé sur des
- centaines de projets dans le monde, mais est pour l’instant peu introduit en France. Depuis 3 ans, un processus de
- certification a été mis en place. En novembre 2006, plus de 7000 personnes avaient obtenu la certification ScrumMaster.
-</p>
-<p>
- &nbsp;<img height="56" alt="ScrumMaster" src="./resources/csm.jpg" width="179" />
-</p>
-<p>
- Pour plus d'informations sur Scrum, voir <a href="http://fr.wikipedia.org/wiki/Scrum"
- target="_blank">http://fr.wikipedia.org/wiki/Scrum</a>
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum French/Scrum/guidances/concepts/Produit, release et sprint.xmi b/Scrum French/Scrum/guidances/concepts/Produit, release et sprint.xmi
deleted file mode 100644
index 6d73875..0000000
--- a/Scrum French/Scrum/guidances/concepts/Produit, release et sprint.xmi
+++ /dev/null
@@ -1,37 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-BPz1k8sC6CCyJ2yZCc1p2Q" name="Produit, release et sprint,_XtRuYP-zEdqLnajTSLeAsA" guid="-BPz1k8sC6CCyJ2yZCc1p2Q" changeDate="2006-12-02T00:54:40.221+0100" version="1.0.0">
- <mainDescription><p>
- Une <a class="elementLink" href="./../../../Scrum/guidances/termdefinitions/Release,_AIB9gIHrEduFs9jH8xc4xw.html"
- guid="_AIB9gIHrEduFs9jH8xc4xw">Release</a>&nbsp;est constituée d'une série de <a class="elementLink"
- href="./../../../Scrum/guidances/termdefinitions/Sprint,_kftWoIHqEduFs9jH8xc4xw.html"
- guid="_kftWoIHqEduFs9jH8xc4xw">Sprint</a>s et dure en général quelques mois. Pendant la vie d'un produit, on déroule
- plusieurs releases.
-</p>
-<p>
- <img height="115" alt="release et sprints" src="./resources/release.jpg" width="600" />
-</p>
-<p>
- Une release a les attributs suivants :
-</p>
-<ul class="noindent">
- <li>
- le but
- </li>
- <li>
- le type, à choisir entre "à date fixée" et "sans date fixée"(par défaut). Dans le cas où on choisit à date fixée,
- la date est fournie.
- </li>
- <li>
- la durée, en nombre de jours, définie pour les sprints
- </li>
- <li>
- le nombre de sprints&nbsp;prévus
- </li>
-</ul>
-<p>
- Le <a class="elementLink" href="./../../../Scrum/guidances/reports/Release Planning,_Z2NzkIGWEduKE9hnyImx1Q.html"
- guid="_Z2NzkIGWEduKE9hnyImx1Q">Planning de la release</a>&nbsp;constitue un niveau de planification du projet : il
- montre de façon "grosses mailles" les items qu'il est prévu de réaliser au cours des sprints de cette release.<br />
- <br />
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum French/Scrum/guidances/concepts/Travail collaboratif.xmi b/Scrum French/Scrum/guidances/concepts/Travail collaboratif.xmi
deleted file mode 100644
index 55eac7a..0000000
--- a/Scrum French/Scrum/guidances/concepts/Travail collaboratif.xmi
+++ /dev/null
@@ -1,134 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-dU_t9olFRQIyOBZQvMndKg" name="new_concept,_OUjj0AEZEduzRosbOajx7w" guid="-dU_t9olFRQIyOBZQvMndKg" changeDate="2006-12-04T21:17:26.750+0100">
- <mainDescription><p>
- Le collectif prend forme à travers des réunions. Scrum impose 5 types de réunions :&nbsp;
-</p>
-<ol>
- <li>
- Réunion pour <a class="elementLink" href="./../../../Scrum/tasks/Plan sprint,_4LOggPpaEdqsc-f87sBK8A.html"
- guid="_4LOggPpaEdqsc-f87sBK8A">Planifier le sprint</a>&nbsp;(1ème partie, sélection du sous-ensemble du backlog))
- </li>
- <li>
- Réunion pour <a class="elementLink" href="./../../../Scrum/tasks/Plan sprint,_4LOggPpaEdqsc-f87sBK8A.html"
- guid="_4LOggPpaEdqsc-f87sBK8A">Planifier le sprint</a>nt (2ème&nbsp;partie, planification du sprint)
- </li>
- <li>
- <a class="elementLink" href="./../../../Scrum/tasks/Scrum daily meeting,_d09LYP_AEdqtbrr0B1TG-A.html"
- guid="_d09LYP_AEdqtbrr0B1TG-A">Mêlée quotidienne</a>
- </li>
- <li>
- Réunion pour <a class="elementLink" href="./../../../Scrum/tasks/Review sprint,_MRrRYPpbEdqsc-f87sBK8A.html"
- guid="_MRrRYPpbEdqsc-f87sBK8A">Faire la revue du sprint</a>
- </li>
- <li>
- <a class="elementLink" href="./../../../Scrum/tasks/Retrospective,_J_sRIP_AEdqtbrr0B1TG-A.html"
- guid="_J_sRIP_AEdqtbrr0B1TG-A">Rétrospective</a><br />
- </li>
-</ol>
-<p>
- Le tableau ci-dessous montre la participation des rôles Scrum à ces réunions :<br />
-</p>
-<table cellspacing="2" cellpadding="2" width="180" border="1">
- <tbody>
- <tr>
- <th scope="col">
- </th>
- <th scope="col">
- 1
- </th>
- <th scope="col">
- 2
- </th>
- <th scope="col">
- 3
- </th>
- <th scope="col">
- 4
- </th>
- <th scope="col">
- 5
- </th>
- </tr>
- <tr>
- <th scope="row">
- <a class="elementLink" href="./../../../Scrum/roles/ScrumMaster,_t1K9kPpYEdqsc-f87sBK8A.html"
- guid="_t1K9kPpYEdqsc-f87sBK8A">ScrumMaster</a>
- </th>
- <td>
- Obligatoire
- </td>
- <td>
- Animation
- </td>
- <td>
- Animation
- </td>
- <td>
- Obligatoire
- </td>
- <td>
- Animation
- </td>
- </tr>
- <tr>
- <th scope="row">
- <a class="elementLink" href="./../../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html"
- guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur Produit</a>
- </th>
- <td>
- Animation
- </td>
- <td>
- Souhaitée
- </td>
- <td>
- Souhaitée
- </td>
- <td>
- Obligatoire
- </td>
- <td>
- Souhaitée
- </td>
- </tr>
- <tr>
- <th scope="row">
- Equipe
- </th>
- <td>
- Obligatoire
- </td>
- <td>
- Obligatoire
- </td>
- <td>
- Obligatoire
- </td>
- <td>
- Animation
- </td>
- <td>
- Obligatoire
- </td>
- </tr>
- <tr>
- <th scope="row">
- Intervenant
- </th>
- <td>
- </td>
- <td>
- </td>
- <td>
- Possible
- </td>
- <td>
- Souhaitée
- </td>
- <td>
- </td>
- </tr>
- </tbody>
-</table>
-<br /></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum French/Scrum/guidances/concepts/resources/clip_image001.png b/Scrum French/Scrum/guidances/concepts/resources/clip_image001.png
deleted file mode 100644
index 32678ac..0000000
--- a/Scrum French/Scrum/guidances/concepts/resources/clip_image001.png
+++ /dev/null
Binary files differ
diff --git a/Scrum French/Scrum/guidances/concepts/resources/clip_image002.gif b/Scrum French/Scrum/guidances/concepts/resources/clip_image002.gif
deleted file mode 100644
index aa6b057..0000000
--- a/Scrum French/Scrum/guidances/concepts/resources/clip_image002.gif
+++ /dev/null
Binary files differ
diff --git a/Scrum French/Scrum/guidances/concepts/resources/csm.jpg b/Scrum French/Scrum/guidances/concepts/resources/csm.jpg
deleted file mode 100644
index 18cd417..0000000
--- a/Scrum French/Scrum/guidances/concepts/resources/csm.jpg
+++ /dev/null
Binary files differ
diff --git a/Scrum French/Scrum/guidances/concepts/resources/release.jpg b/Scrum French/Scrum/guidances/concepts/resources/release.jpg
deleted file mode 100644
index a270cd4..0000000
--- a/Scrum French/Scrum/guidances/concepts/resources/release.jpg
+++ /dev/null
Binary files differ
diff --git a/Scrum French/Scrum/guidances/examples/resources/demo_banque_2.JPG b/Scrum French/Scrum/guidances/examples/resources/demo_banque_2.JPG
deleted file mode 100644
index 046308b..0000000
--- a/Scrum French/Scrum/guidances/examples/resources/demo_banque_2.JPG
+++ /dev/null
Binary files differ
diff --git a/Scrum French/Scrum/guidances/reports/Release Burndown Chart.xmi b/Scrum French/Scrum/guidances/reports/Release Burndown Chart.xmi
deleted file mode 100644
index 434f1c4..0000000
--- a/Scrum French/Scrum/guidances/reports/Release Burndown Chart.xmi
+++ /dev/null
@@ -1,9 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-pJuF9iKbSQx7TIwHNBVTgg" name="Release Burndown Chart,_vKqe8PpaEdqsc-f87sBK8A" guid="-pJuF9iKbSQx7TIwHNBVTgg" changeDate="2006-12-03T15:16:09.515+0100">
- <mainDescription><p>
- C'est un <a class="elementLink"
- href="./../../../Scrum/guidances/termdefinitions/Burndown Chart,_X5rREILYEduLd8CaF_IcMA.html"
- guid="_X5rREILYEduLd8CaF_IcMA">Graphe de tendance</a>&nbsp;pour une release :&nbsp;il montre la tendance dans
- l'avancement de la release par une présentation graphique du reste à faire à la fin de chaque sprint passé.
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum French/Scrum/guidances/reports/Release Planning.xmi b/Scrum French/Scrum/guidances/reports/Release Planning.xmi
deleted file mode 100644
index 9360ab0..0000000
--- a/Scrum French/Scrum/guidances/reports/Release Planning.xmi
+++ /dev/null
@@ -1,7 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-EmLqiNX2WnmsfEtxNiuyTQ" name="new_report,_Z2NzkIGWEduKE9hnyImx1Q" guid="-EmLqiNX2WnmsfEtxNiuyTQ" changeDate="2006-12-02T00:51:59.549+0100">
- <mainDescription><p>
- Il est dérivé du backlog de produit : c'est un sous-ensemble contenant uniquement les éléments prévus dans la release
- et associés aux sprints prévus dans la release.
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum French/Scrum/guidances/reports/Sprint Burndown Chart.xmi b/Scrum French/Scrum/guidances/reports/Sprint Burndown Chart.xmi
deleted file mode 100644
index 10e80bb..0000000
--- a/Scrum French/Scrum/guidances/reports/Sprint Burndown Chart.xmi
+++ /dev/null
@@ -1,9 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-qVeT6_sAspmZjCYQLOrhbg" name="Sprint Burndown Chart,_jC4NwPpaEdqsc-f87sBK8A" guid="-qVeT6_sAspmZjCYQLOrhbg" changeDate="2006-12-03T15:17:51.046+0100">
- <mainDescription><p>
- C'est un <a class="elementLink"
- href="./../../../Scrum/guidances/termdefinitions/Burndown Chart,_X5rREILYEduLd8CaF_IcMA.html"
- guid="_X5rREILYEduLd8CaF_IcMA">Graphe de tendance</a>&nbsp;pour un sprint :&nbsp;il montre la tendance dans
- l'avancement du sprint par une présentation graphique du reste à faire à la fin de chaque jour passé.
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum French/Scrum/guidances/roadmaps/Application.xmi b/Scrum French/Scrum/guidances/roadmaps/Application.xmi
deleted file mode 100644
index 5ade8ce..0000000
--- a/Scrum French/Scrum/guidances/roadmaps/Application.xmi
+++ /dev/null
@@ -1,33 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-IPxNSDzXKWa-H_kJ2PMtYA" name="new_roadmap,_6Jox0IRuEduo75chJsIcXg" guid="-IPxNSDzXKWa-H_kJ2PMtYA" changeDate="2006-12-05T16:29:34.781+0100">
- <mainDescription><p>
- Le&nbsp;Manifeste Agile proclame que "les outils et les processus sont utiles, mais que&nbsp;les personnes et les
- interactions qu'elles ont entre elles sont plus importantes" pour la réussite du projet. Il faut garder ce principe à
- l'esprit lors de l'application de Scrum. Il convient également de respecter les&nbsp;caractéristiques de Scrum comme :
-</p>
-<ul>
- <li>
- l'approche empirique basée sur la régulation,
- </li>
- <li>
- la planification adaptative plutôt que prédictive,
- </li>
- <li>
- l'auto-gestion de l'équipe pour faire ce qu'elle a à faire.
- </li>
-</ul>
-<p>
- De plus, Scrum ne décrit pas les activités d'ingénierie nécessaires à la réalisation du produit.
-</p>
-<p>
- L'application de Scrum décrite ci-dessous&nbsp;doit être lue et utilisée&nbsp;à l'aune de ces principes agiles. Elle
- montre comment les éléments de Scrum sont utilisés lors du déroulement d'une période de temps,&nbsp;ou cycle de vie.
-</p>
-<p>
- Ce cycle de vie ne représente pas toute la vie d'un produit, mais porte uniquement sur la production d'une <a
- class="elementLink" href="./../../../Scrum/guidances/termdefinitions/Release,_AIB9gIHrEduFs9jH8xc4xw.html"
- guid="_AIB9gIHrEduFs9jH8xc4xw">Release</a>. Le guide <a class="elementLink"
- href="./../../../Scrum/guidances/concepts/Produit, release et sprint,_XtRuYP-zEdqLnajTSLeAsA.html"
- guid="_XtRuYP-zEdqLnajTSLeAsA">Produit, release et sprint</a>&nbsp;replace cette période dans un contexte plus large.
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum French/Scrum/guidances/supportingmaterials/Copyright.xmi b/Scrum French/Scrum/guidances/supportingmaterials/Copyright.xmi
deleted file mode 100644
index 09ba739..0000000
--- a/Scrum French/Scrum/guidances/supportingmaterials/Copyright.xmi
+++ /dev/null
@@ -1,6 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-03XtfjRMEs23qIdCSSQiNQ" name="new_supporting_material,_N8zs0AEGEduzRosbOajx7w" guid="-03XtfjRMEs23qIdCSSQiNQ" changeDate="2007-02-03T11:40:46.906-0800" version="1.0.0">
- <mainDescription>Ce programme et le matériel qui l'accompagne sont mis à disposition selon les termes de la licence "<a
-href="http://www.eclipse.org/org/documents/epl-v10.php" target="_blank">Eclipse Public License v1.0</a>" qui régit cette
-distribution.</mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum French/Scrum/guidances/supportingmaterials/Introduction.xmi b/Scrum French/Scrum/guidances/supportingmaterials/Introduction.xmi
deleted file mode 100644
index 8254917..0000000
--- a/Scrum French/Scrum/guidances/supportingmaterials/Introduction.xmi
+++ /dev/null
@@ -1,24 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-WfzsSn3X35gSHQZ2kqtoVw" name="Introduction,_wz30kABREdu3o4yroaI-tA" guid="-WfzsSn3X35gSHQZ2kqtoVw" changeDate="2006-12-04T21:23:34.453+0100">
- <mainDescription><p>
- Ce plugin, réalisé&nbsp;avec&nbsp;<a href="http://www.eclipse.org/epf/" target="_blank">EPF</a> (Eclipse&nbsp;Process
- Framework)&nbsp;présente :
-</p>
-<ul>
- <li>
- une introduction à <a class="elementLink"
- href="./../../../Scrum/guidances/concepts/Presentation Scrum,_3WivIBTQEduFIr9xNbwGyQ.html"
- guid="_3WivIBTQEduFIr9xNbwGyQ">Scrum</a>
- </li>
- <li>
- les notions principales de Scrum (<a class="elementLink"
- href="./../../../Scrum/customcategories/Scrum Elements,_nF6fgALYEduFv7wnrO7SvQ.html"
- guid="_nF6fgALYEduFv7wnrO7SvQ">Eléments Scrum</a>),
- </li>
- <li>
- une façon de les appliquer (<a class="elementLink"
- href="./../../../Scrum/customcategories/Cycle de vie Scrum,_7BSBkABCEduYUKPFgCzFuA.html"
- guid="_7BSBkABCEduYUKPFgCzFuA">Cycle de vie</a>) qui est à adapter à chaque projet.
- </li>
-</ul></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum French/Scrum/guidances/supportingmaterials/Scrum references.xmi b/Scrum French/Scrum/guidances/supportingmaterials/Scrum references.xmi
deleted file mode 100644
index a1f2561..0000000
--- a/Scrum French/Scrum/guidances/supportingmaterials/Scrum references.xmi
+++ /dev/null
@@ -1,14 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-cfa6bdUgQuboNpJRKaCLAw" name="Scrum referencesl,_PTGe4IRvEduo75chJsIcXg" guid="-cfa6bdUgQuboNpJRKaCLAw" changeDate="2006-12-05T15:45:31.406+0100">
- <mainDescription><ul>
- <li>
- Ken Schwaber&nbsp;: <a href="http://softpro.stores.yahoo.net/0-7356-1993-x.html" target="_blank">Agile Project
- Management with Scrum.</a>&nbsp;
- </li>
- <li>
- Mike Cohn&nbsp;: <a
- href="http://www.amazon.fr/exec/obidos/ASIN/0131479415/sr=8-1/qid=1152998855/ref=sr_1_1/402-4433368-7461703?_encoding=UTF8&amp;s=gateway&amp;v=glance"
- target="_blank">Agile Estimating and Planning</a>
- </li>
-</ul></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum French/Scrum/guidances/termdefinitions/Burndown Chart.xmi b/Scrum French/Scrum/guidances/termdefinitions/Burndown Chart.xmi
deleted file mode 100644
index 63ce6f7..0000000
--- a/Scrum French/Scrum/guidances/termdefinitions/Burndown Chart.xmi
+++ /dev/null
@@ -1,4 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-KQ4Jzjy6YgAr_2NXa4J67g" name="new_term_definition,_X5rREILYEduLd8CaF_IcMA" guid="-KQ4Jzjy6YgAr_2NXa4J67g">
- <mainDescription>Représentation graphique du reste à faire dans une période, actualisée aussi souvent que possible.</mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum French/Scrum/guidances/termdefinitions/Release.xmi b/Scrum French/Scrum/guidances/termdefinitions/Release.xmi
deleted file mode 100644
index 46444c0..0000000
--- a/Scrum French/Scrum/guidances/termdefinitions/Release.xmi
+++ /dev/null
@@ -1,5 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-XPyPmZTAVbnvJVuOLvYpXw" name="Release,_AIB9gIHrEduFs9jH8xc4xw" guid="-XPyPmZTAVbnvJVuOLvYpXw" changeDate="2006-12-02T10:53:51.187+0100" version="1.0.0">
- <mainDescription>Une release correspond à la livraison d'une version. Par habitude, on parle de release pour considérer la période de temps
-qui va du début du travail sur cette version jusqu'à sa livraison et qui passe par une série de sprints successifs.</mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum French/Scrum/guidances/termdefinitions/Sprint.xmi b/Scrum French/Scrum/guidances/termdefinitions/Sprint.xmi
deleted file mode 100644
index 0af2272..0000000
--- a/Scrum French/Scrum/guidances/termdefinitions/Sprint.xmi
+++ /dev/null
@@ -1,5 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-fcoz1Nm_QnX6xtLg5YWdVg" name="new_term_definition,_kftWoIHqEduFs9jH8xc4xw" guid="-fcoz1Nm_QnX6xtLg5YWdVg" changeDate="2006-12-02T10:51:49.500+0100">
- <mainDescription>Un sprint est un bloc de temps aboutissant à créer un incrément du produit. C'est le terme utilisé dans Scrum pour
-itération.</mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum French/Scrum/guidances/termdefinitions/Theme.xmi b/Scrum French/Scrum/guidances/termdefinitions/Theme.xmi
deleted file mode 100644
index 2814df0..0000000
--- a/Scrum French/Scrum/guidances/termdefinitions/Theme.xmi
+++ /dev/null
@@ -1,4 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-GKfSarwQLoaHhoT71FQI8Q" name="new_term_definition,_aeYKoIKlEduQgtHqedKdMA" guid="-GKfSarwQLoaHhoT71FQI8Q" changeDate="2006-12-03T09:09:30.312+0100">
- <mainDescription>Un thème constitue un regroupement fonctionnel d'exigences.</mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum French/Scrum/guidances/termdefinitions/Timebox.xmi b/Scrum French/Scrum/guidances/termdefinitions/Timebox.xmi
deleted file mode 100644
index 0d19473..0000000
--- a/Scrum French/Scrum/guidances/termdefinitions/Timebox.xmi
+++ /dev/null
@@ -1,4 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-tHVOELWOQDI7i0M2rlMufQ" name="new_term_definition,_3qdXkILXEduLd8CaF_IcMA" guid="-tHVOELWOQDI7i0M2rlMufQ" changeDate="2006-12-03T15:11:12.609+0100">
- <mainDescription>Une période de temps à échéance fixée et intangible même si tous les objectifs ne sont pas atteints.</mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum French/Scrum/guidances/termdefinitions/Velocity.xmi b/Scrum French/Scrum/guidances/termdefinitions/Velocity.xmi
deleted file mode 100644
index ac28bb4..0000000
--- a/Scrum French/Scrum/guidances/termdefinitions/Velocity.xmi
+++ /dev/null
@@ -1,4 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-PeP4fADValHXs2Z2Z8zJ1w" name="new_term_definition,_HQEP8ILXEduLd8CaF_IcMA" guid="-PeP4fADValHXs2Z2Z8zJ1w" changeDate="2007-01-29T09:14:31.140+0100" version="1.0.0">
- <mainDescription>La vélocité est la mesure de la capacité de l'équipe pendant un sprint.</mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum French/Scrum/plugin.xmi b/Scrum French/Scrum/plugin.xmi
deleted file mode 100644
index 1789c5d..0000000
--- a/Scrum French/Scrum/plugin.xmi
+++ /dev/null
@@ -1,197 +0,0 @@
-<?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.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
- <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_5AUAUPpYEdqsc-f87sBK8A" guid="_5AUAUPpYEdqsc-f87sBK8A">
- <subManagers xmi:id="_9m1CIAAvEdubGMceRDupFQ" href="uma://_9llsAAAvEdubGMceRDupFQ#_9m1CIAAvEdubGMceRDupFQ"/>
- <resourceDescriptors xmi:id="_5AUAUfpYEdqsc-f87sBK8A" id="-Y3SFEe-A-lRF8TaEn9vKNQ" uri="roles/ScrumMaster.xmi"/>
- <resourceDescriptors xmi:id="_N_XCIf-0EdqLnajTSLeAsA" id="-CgLjZ6Bwc0EyYyQCjzlw7g" uri="rolesets/Scrum%20Roles.xmi"/>
- <resourceDescriptors xmi:id="_aziTsP--Edqtbrr0B1TG-A" id="-NRwwk6YGAtu25V3Lc04G6w" uri="tasks/Plan%20sprint%202.xmi"/>
- <resourceDescriptors xmi:id="_9lx5QAAvEdubGMceRDupFQ" id="_9llsAAAvEdubGMceRDupFQ" uri="deliveryprocesses/Scrum/model.xmi"/>
- <resourceDescriptors xmi:id="_qJ7PoABSEdu3o4yroaI-tA" id="-juIDa_fXi2K1BE5NTblPow" uri="customcategories/Intro.xmi"/>
- <resourceDescriptors xmi:id="_OY10sABaEdu3o4yroaI-tA" id="-WfzsSn3X35gSHQZ2kqtoVw" uri="guidances/supportingmaterials/Introduction.xmi"/>
- <resourceDescriptors xmi:id="_hhv8QAB7EduSVaTQTBfIHA" id="-35iKPqDM2F2PjKWQLCW4tA" uri="roles/Product%20Owner.xmi"/>
- <resourceDescriptors xmi:id="_hh2C4AB7EduSVaTQTBfIHA" id="-mZfAV7RcWJlp5idlHzeEcA" uri="tasks/Manage%20problems.xmi"/>
- <resourceDescriptors xmi:id="_rosG4AEGEduzRosbOajx7w" id="-03XtfjRMEs23qIdCSSQiNQ" uri="guidances/supportingmaterials/Copyright.xmi"/>
- <resourceDescriptors xmi:id="_kTIcUAELEduzRosbOajx7w" id="-eSc2tcV1h17HBw_s8ROEVw" uri="workproducttypes/Backlogs.xmi"/>
- <resourceDescriptors xmi:id="_K5MbwAEPEduzRosbOajx7w" id="-Of1SdnAQ9nmsL5DFvD2Uug" uri="workproducts/Product%20Backlog.xmi"/>
- <resourceDescriptors xmi:id="_K5MbwQEPEduzRosbOajx7w" id="-LVZG5zK2YjEGXO3SwDmqug" uri="roles/Team.xmi"/>
- <resourceDescriptors xmi:id="_K5YpAAEPEduzRosbOajx7w" id="-u0-b4PNo9XzOh1-dv_aaKA" uri="roles/StakeHolder.xmi"/>
- <resourceDescriptors xmi:id="_AaX3AAEQEduzRosbOajx7w" id="-8V2DOvzUhvtqwWvTOHMB5g" uri="workproducts/Sprint%20backlog.xmi"/>
- <resourceDescriptors xmi:id="_A0kNwQESEduzRosbOajx7w" id="-zoJryMCuHfxWP7Q5Er195Q" uri="tasks/Review%20sprint.xmi"/>
- <resourceDescriptors xmi:id="_A0qUYAESEduzRosbOajx7w" id="-vDOuVl_xPKipKd90HQNZng" uri="tasks/Scrum%20daily%20meeting.xmi"/>
- <resourceDescriptors xmi:id="_A0qUYQESEduzRosbOajx7w" id="-XdgedeazfFRGDxMY3Fnh5g" uri="tasks/Update%20product%20backlog.xmi"/>
- <resourceDescriptors xmi:id="_wj_I8AEWEduzRosbOajx7w" id="-S4qXwp40l_8eCcyyI7o-3A" uri="tasks/Retrospective.xmi"/>
- <resourceDescriptors xmi:id="_WYwq0QEZEduzRosbOajx7w" id="-dU_t9olFRQIyOBZQvMndKg" uri="guidances/concepts/Travail%20collaboratif.xmi"/>
- <resourceDescriptors xmi:id="_pWgXYAL_EduOAKqB9I73uw" id="-4wqJQ0qXLYZ8kCnpDu--tA" uri="disciplines/Scrum%20activities.xmi"/>
- <resourceDescriptors xmi:id="_PitjwQOwEduJnc8byNAQ9Q" id="-zS9h38tmK4L-U9kbgkpGKQ" uri="customcategories/Scrum%20Elements.xmi"/>
- <resourceDescriptors xmi:id="_XQS7sAPKEdubhrgDuRb4fA" id="-3f4axrWBKHGv74oKN2x-gQ" uri="tasks/Plan%20release.xmi"/>
- <resourceDescriptors xmi:id="_XQZCUAPKEdubhrgDuRb4fA" id="-mi1O4H7RRm0YqlUNyp8TJg" uri="tasks/Initiate%20Product%20Backlog.xmi"/>
- <resourceDescriptors xmi:id="_E6ZVsBTREduFIr9xNbwGyQ" id="-MSO8KF-0IlKZJGnSwwTNZA" uri="guidances/concepts/Presentation%20Scrum.xmi"/>
- <resourceDescriptors xmi:id="_ZllqMDwUEdun48PxFCzHCw" id="-BPz1k8sC6CCyJ2yZCc1p2Q" uri="guidances/concepts/Produit,%20release%20et%20sprint.xmi"/>
- <resourceDescriptors xmi:id="_tO6jEHpCEdug1NkGFo_hTg" id="-6aCUL_kawJFNBtfH_sRXkw" uri="workproducts/Product%20increment.xmi"/>
- <resourceDescriptors xmi:id="_5nqe4IGJEduKE9hnyImx1Q" id="-KC1R73i9f6P7ZT4pgBOLzA" uri="workproducts/Product%20Backlog%20Item.xmi"/>
- <resourceDescriptors xmi:id="_74nh8YGWEduKE9hnyImx1Q" id="-EmLqiNX2WnmsfEtxNiuyTQ" uri="guidances/reports/Release%20Planning.xmi"/>
- <resourceDescriptors xmi:id="_U_2y4IHpEdu3SZQ-Dp1OAA" id="-6UJtuFO3WFBFpJOFeV1QMQ" uri="workproducts/Sprint%20Backlog%20Item.xmi"/>
- <resourceDescriptors xmi:id="_1MHpkIHqEduFs9jH8xc4xw" id="-fcoz1Nm_QnX6xtLg5YWdVg" uri="guidances/termdefinitions/Sprint.xmi"/>
- <resourceDescriptors xmi:id="_DD7t8IHrEduFs9jH8xc4xw" id="-XPyPmZTAVbnvJVuOLvYpXw" uri="guidances/termdefinitions/Release.xmi"/>
- <resourceDescriptors xmi:id="_mmlSkIKlEduQgtHqedKdMA" id="-GKfSarwQLoaHhoT71FQI8Q" uri="guidances/termdefinitions/Theme.xmi"/>
- <resourceDescriptors xmi:id="_P8d_YILXEduLd8CaF_IcMA" id="-PeP4fADValHXs2Z2Z8zJ1w" uri="guidances/termdefinitions/Velocity.xmi"/>
- <resourceDescriptors xmi:id="_IbymwILYEduLd8CaF_IcMA" id="-tHVOELWOQDI7i0M2rlMufQ" uri="guidances/termdefinitions/Timebox.xmi"/>
- <resourceDescriptors xmi:id="_tOn1YILYEduLd8CaF_IcMA" id="-KQ4Jzjy6YgAr_2NXa4J67g" uri="guidances/termdefinitions/Burndown%20Chart.xmi"/>
- <resourceDescriptors xmi:id="_-wFhAILYEduLd8CaF_IcMA" id="-pJuF9iKbSQx7TIwHNBVTgg" uri="guidances/reports/Release%20Burndown%20Chart.xmi"/>
- <resourceDescriptors xmi:id="_LCa1UILZEduLd8CaF_IcMA" id="-qVeT6_sAspmZjCYQLOrhbg" uri="guidances/reports/Sprint%20Burndown%20Chart.xmi"/>
- <resourceDescriptors xmi:id="_egmj0IRvEduo75chJsIcXg" id="-cfa6bdUgQuboNpJRKaCLAw" uri="guidances/supportingmaterials/Scrum%20references.xmi"/>
- <resourceDescriptors xmi:id="_cpeaYYSAEduo75chJsIcXg" id="-IPxNSDzXKWa-H_kJ2PMtYA" uri="guidances/roadmaps/Application.xmi"/>
- </org.eclipse.epf.uma.resourcemanager:ResourceManager>
- <org.eclipse.epf.uma:MethodPlugin xmi:id="_mQ3eoPpYEdqsc-f87sBK8A" name="Scrum" guid="_mQ3eoPpYEdqsc-f87sBK8A" briefDescription="Ce plugin porte sur l'utilisation de Scrum." authors="Claude Aubry" changeDate="2006-12-05T18:52:42.109+0100" version="1.0" copyrightStatement="_N8zs0AEGEduzRosbOajx7w">
- <methodPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3eofpYEdqsc-f87sBK8A" name="Content" guid="_mQ3eofpYEdqsc-f87sBK8A">
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3eovpYEdqsc-f87sBK8A" name="Categories" guid="_mQ3eovpYEdqsc-f87sBK8A">
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3eo_pYEdqsc-f87sBK8A" name="Domains" guid="_mQ3eo_pYEdqsc-f87sBK8A">
- <contentElements xsi:type="org.eclipse.epf.uma:Domain" xmi:id="_AcwmAANoEduYd-55D-Aiqg" name="Scrum Artefacts" guid="_AcwmAANoEduYd-55D-Aiqg" presentationName="Produits Scrum" workProducts="_tCmYEP-xEdqLnajTSLeAsA _5ABscPpYEdqsc-f87sBK8A _Dzw70PpZEdqsc-f87sBK8A"/>
- </childPackages>
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3epPpYEdqsc-f87sBK8A" name="Disciplines" guid="_mQ3epPpYEdqsc-f87sBK8A">
- <contentElements xsi:type="org.eclipse.epf.uma:Discipline" xmi:id="_6sdMAAL-EduOAKqB9I73uw" name="Scrum activities" guid="_6sdMAAL-EduOAKqB9I73uw" briefDescription="Les activités spécifiques induites par l'application de Scrum." presentationName="Activités Scrum" conceptsAndPapers="_OUjj0AEZEduzRosbOajx7w" tasks="_Xpd5gP_AEdqtbrr0B1TG-A _STkWYP_BEdqtbrr0B1TG-A _ho-aIP_BEdqtbrr0B1TG-A _4LOggPpaEdqsc-f87sBK8A _J_sRIP_AEdqtbrr0B1TG-A _MRrRYPpbEdqsc-f87sBK8A _d09LYP_AEdqtbrr0B1TG-A _BGFMoANkEduYd-55D-Aiqg">
- <presentation xmi:id="-4wqJQ0qXLYZ8kCnpDu--tA" href="uma://-4wqJQ0qXLYZ8kCnpDu--tA#-4wqJQ0qXLYZ8kCnpDu--tA"/>
- </contentElements>
- </childPackages>
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3epfpYEdqsc-f87sBK8A" name="RoleSets" guid="_mQ3epfpYEdqsc-f87sBK8A">
- <contentElements xsi:type="org.eclipse.epf.uma:RoleSet" xmi:id="_3qmmoP-zEdqLnajTSLeAsA" name="Scrum Roles" guid="_3qmmoP-zEdqLnajTSLeAsA" briefDescription="Les rôles dans un projet qui applique Scrum." presentationName="Rôles Scrum" conceptsAndPapers="_OUjj0AEZEduzRosbOajx7w" roles="_ICJyYPpaEdqsc-f87sBK8A _t1K9kPpYEdqsc-f87sBK8A _9apLsPpaEdqsc-f87sBK8A _Qqmp8P_AEdqtbrr0B1TG-A">
- <presentation xmi:id="-CgLjZ6Bwc0EyYyQCjzlw7g" href="uma://-CgLjZ6Bwc0EyYyQCjzlw7g#-CgLjZ6Bwc0EyYyQCjzlw7g"/>
- </contentElements>
- </childPackages>
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3epvpYEdqsc-f87sBK8A" name="WP Types" guid="_mQ3epvpYEdqsc-f87sBK8A">
- <contentElements xsi:type="org.eclipse.epf.uma:WorkProductType" xmi:id="_d-yk8ABREdu3o4yroaI-tA" name="Backlogs" guid="_d-yk8ABREdu3o4yroaI-tA" briefDescription="Scrum utilise un nombre très restreint de produits de travail, essentiellement 2 listes appelées backlogs." presentationName="Backlogs" workProducts="_5ABscPpYEdqsc-f87sBK8A _Dzw70PpZEdqsc-f87sBK8A">
- <presentation xmi:id="-eSc2tcV1h17HBw_s8ROEVw" href="uma://-eSc2tcV1h17HBw_s8ROEVw#-eSc2tcV1h17HBw_s8ROEVw"/>
- </contentElements>
- </childPackages>
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3ep_pYEdqsc-f87sBK8A" name="Tools" guid="_mQ3ep_pYEdqsc-f87sBK8A"/>
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3eqPpYEdqsc-f87sBK8A" name="StandardCategories" guid="_mQ3eqPpYEdqsc-f87sBK8A"/>
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3eqfpYEdqsc-f87sBK8A" name="CustomCategories" guid="_mQ3eqfpYEdqsc-f87sBK8A">
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3eqvpYEdqsc-f87sBK8A" name="Hidden" guid="_mQ3eqvpYEdqsc-f87sBK8A">
- <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_mQ3eq_pYEdqsc-f87sBK8A" name="Catégories personnalisées" guid="_mQ3eq_pYEdqsc-f87sBK8A" categorizedElements="_7BSBkABCEduYUKPFgCzFuA _s8y1UABREdu3o4yroaI-tA _nF6fgALYEduFv7wnrO7SvQ"/>
- </childPackages>
- <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_7BSBkABCEduYUKPFgCzFuA" name="Cycle de vie Scrum" guid="_7BSBkABCEduYUKPFgCzFuA" presentationName="Cycle de vie">
- <categorizedElements xsi:type="org.eclipse.epf.uma:Roadmap" href="#_6Jox0IRuEduo75chJsIcXg"/>
- <categorizedElements xsi:type="org.eclipse.epf.uma:DeliveryProcess" href="uma://_9llsAAAvEdubGMceRDupFQ#_9llsAQAvEdubGMceRDupFQ"/>
- <categorizedElements xsi:type="org.eclipse.epf.uma:Concept" href="#_XtRuYP-zEdqLnajTSLeAsA"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_s8y1UABREdu3o4yroaI-tA" name="Intro" guid="_s8y1UABREdu3o4yroaI-tA" presentationName="Intro" categorizedElements="_wz30kABREdu3o4yroaI-tA _3WivIBTQEduFIr9xNbwGyQ _PTGe4IRvEduo75chJsIcXg">
- <presentation xmi:id="-juIDa_fXi2K1BE5NTblPow" href="uma://-juIDa_fXi2K1BE5NTblPow#-juIDa_fXi2K1BE5NTblPow"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_nF6fgALYEduFv7wnrO7SvQ" name="Scrum Elements" guid="_nF6fgALYEduFv7wnrO7SvQ" briefDescription="Description des éléments de Scrum : rôles, réunions et backlogs, ainsi que des guides dans leur utilisation." presentationName="Eléments" categorizedElements="_3qmmoP-zEdqLnajTSLeAsA _d-yk8ABREdu3o4yroaI-tA _6sdMAAL-EduOAKqB9I73uw">
- <presentation xmi:id="-zS9h38tmK4L-U9kbgkpGKQ" href="uma://-zS9h38tmK4L-U9kbgkpGKQ#-zS9h38tmK4L-U9kbgkpGKQ"/>
- </contentElements>
- </childPackages>
- </childPackages>
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mQ3erPpYEdqsc-f87sBK8A" name="CoreContent" guid="_mQ3erPpYEdqsc-f87sBK8A">
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_rkSgEPpYEdqsc-f87sBK8A" name="Eléments de Scrum" guid="_rkSgEPpYEdqsc-f87sBK8A" briefDescription="Scrum signifie mêlée au rugby. Scrum utilise les valeurs et l'esprit du rugby et les adapte aux projets de développement. Comme le pack lors d'un ballon porté au rugby, l'équipe chargée du développement travaille de façon collective, soudée vers un objectif précis. Comme un demi de mêlée, le ScrumMaster aiguillonne les membres de l'équipe, les repositionne dans la bonne direction et donne le tempo pour assurer la réussite du projet. Au delà de cet accent mis sur la puissance du collectif, Scrum est un processus agile qui attaque la complexité par une approche empirique. Scrum est facile à apprendre, Scrum est indépendant des méthodes et technologies utilisées : son adoption présente peu de risques. ">
- <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_t1K9kPpYEdqsc-f87sBK8A" name="ScrumMaster" guid="_t1K9kPpYEdqsc-f87sBK8A" briefDescription="C' est l'animateur d'une équipe Scrum." presentationName="ScrumMaster" responsibleFor="_Dzw70PpZEdqsc-f87sBK8A">
- <presentation xmi:id="-Y3SFEe-A-lRF8TaEn9vKNQ" href="uma://-Y3SFEe-A-lRF8TaEn9vKNQ#-Y3SFEe-A-lRF8TaEn9vKNQ"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_5ABscPpYEdqsc-f87sBK8A" name="Product Backlog" guid="_5ABscPpYEdqsc-f87sBK8A" briefDescription="Contient les exigences d'un produit" presentationName="Backlog de produit" conceptsAndPapers="_XtRuYP-zEdqLnajTSLeAsA" reports="_vKqe8PpaEdqsc-f87sBK8A _Z2NzkIGWEduKE9hnyImx1Q">
- <presentation xmi:id="-Of1SdnAQ9nmsL5DFvD2Uug" href="uma://-Of1SdnAQ9nmsL5DFvD2Uug#-Of1SdnAQ9nmsL5DFvD2Uug"/>
- <containedArtifacts xmi:id="_-D85cIGIEduKE9hnyImx1Q" name="Product Backlog Item" guid="_-D85cIGIEduKE9hnyImx1Q" briefDescription="Chose à faire qui apporte de la valeur. Appelé PBI (Product Backlog Item)" presentationName="Elément de backlog de produit">
- <presentation xmi:id="-KC1R73i9f6P7ZT4pgBOLzA" href="uma://-KC1R73i9f6P7ZT4pgBOLzA#-KC1R73i9f6P7ZT4pgBOLzA"/>
- </containedArtifacts>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_Dzw70PpZEdqsc-f87sBK8A" name="Sprint backlog" guid="_Dzw70PpZEdqsc-f87sBK8A" briefDescription="Liste des choses à faire du point de vue de l'équipe de développement." presentationName="Backlog du sprint" reports="_jC4NwPpaEdqsc-f87sBK8A">
- <presentation xmi:id="-8V2DOvzUhvtqwWvTOHMB5g" href="uma://-8V2DOvzUhvtqwWvTOHMB5g#-8V2DOvzUhvtqwWvTOHMB5g"/>
- <containedArtifacts xmi:id="_9C78MIHnEdu3SZQ-Dp1OAA" name="Sprint Backlog Item" guid="_9C78MIHnEdu3SZQ-Dp1OAA" briefDescription="C'est une tâche, un travail élémentaire à réaliser pendant le sprint." presentationName="Elément de Backlog de Sprint">
- <presentation xmi:id="-6UJtuFO3WFBFpJOFeV1QMQ" href="uma://-6UJtuFO3WFBFpJOFeV1QMQ#-6UJtuFO3WFBFpJOFeV1QMQ"/>
- </containedArtifacts>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_ICJyYPpaEdqsc-f87sBK8A" name="Product Owner" guid="_ICJyYPpaEdqsc-f87sBK8A" briefDescription="C’est le représentant du "métier" dans le projet. " presentationName="Directeur Produit" responsibleFor="_5ABscPpYEdqsc-f87sBK8A">
- <presentation xmi:id="-35iKPqDM2F2PjKWQLCW4tA" href="uma://-35iKPqDM2F2PjKWQLCW4tA#-35iKPqDM2F2PjKWQLCW4tA"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Report" xmi:id="_jC4NwPpaEdqsc-f87sBK8A" name="Sprint Burndown Chart" guid="_jC4NwPpaEdqsc-f87sBK8A" briefDescription="Présentation de l'avancement du sprint courant." presentationName="Sprint Burndown Chart" conceptsAndPapers="_XtRuYP-zEdqLnajTSLeAsA">
- <presentation xmi:id="-qVeT6_sAspmZjCYQLOrhbg" href="uma://-qVeT6_sAspmZjCYQLOrhbg#-qVeT6_sAspmZjCYQLOrhbg"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Report" xmi:id="_vKqe8PpaEdqsc-f87sBK8A" name="Release Burndown Chart" guid="_vKqe8PpaEdqsc-f87sBK8A" briefDescription="Présentation de l'avancement de la release." presentationName="Release Burndown Chart" conceptsAndPapers="_XtRuYP-zEdqLnajTSLeAsA">
- <presentation xmi:id="-pJuF9iKbSQx7TIwHNBVTgg" href="uma://-pJuF9iKbSQx7TIwHNBVTgg#-pJuF9iKbSQx7TIwHNBVTgg"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_4LOggPpaEdqsc-f87sBK8A" name="Plan sprint" guid="_4LOggPpaEdqsc-f87sBK8A" briefDescription="Planification du court terme" presentationName="Planifier le sprint" performedBy="_9apLsPpaEdqsc-f87sBK8A" mandatoryInput="_5ABscPpYEdqsc-f87sBK8A" output="_Dzw70PpZEdqsc-f87sBK8A" additionallyPerformedBy="_ICJyYPpaEdqsc-f87sBK8A">
- <presentation xmi:id="-NRwwk6YGAtu25V3Lc04G6w" href="uma://-NRwwk6YGAtu25V3Lc04G6w#-NRwwk6YGAtu25V3Lc04G6w"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_9apLsPpaEdqsc-f87sBK8A" name="Team" guid="_9apLsPpaEdqsc-f87sBK8A" briefDescription="Il s'agit d'un rôle collectif. Tous les membres de l'équipe participent au travail, sans qu'on disitingue des fonctions particulières pour chacun." presentationName="Equipe Scrum" responsibleFor="_tCmYEP-xEdqLnajTSLeAsA">
- <presentation xmi:id="-LVZG5zK2YjEGXO3SwDmqug" href="uma://-LVZG5zK2YjEGXO3SwDmqug#-LVZG5zK2YjEGXO3SwDmqug"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_MRrRYPpbEdqsc-f87sBK8A" name="Review sprint" guid="_MRrRYPpbEdqsc-f87sBK8A" briefDescription="Montrer ce qui a été réalisé et fonctionne. En tirer les conséquences." presentationName="Faire la revue du sprint" performedBy="_9apLsPpaEdqsc-f87sBK8A" mandatoryInput="_tCmYEP-xEdqLnajTSLeAsA" output="_5ABscPpYEdqsc-f87sBK8A" additionallyPerformedBy="_ICJyYPpaEdqsc-f87sBK8A _t1K9kPpYEdqsc-f87sBK8A _Qqmp8P_AEdqtbrr0B1TG-A">
- <presentation xmi:id="-zoJryMCuHfxWP7Q5Er195Q" href="uma://-zoJryMCuHfxWP7Q5Er195Q#-zoJryMCuHfxWP7Q5Er195Q"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="_tCmYEP-xEdqLnajTSLeAsA" name="Product increment" guid="_tCmYEP-xEdqLnajTSLeAsA" briefDescription="Le produit partiel obtenu à la fin de chaque sprint." presentationName="Incrément de produit">
- <presentation xmi:id="-6aCUL_kawJFNBtfH_sRXkw" href="uma://-6aCUL_kawJFNBtfH_sRXkw#-6aCUL_kawJFNBtfH_sRXkw"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_J_sRIP_AEdqtbrr0B1TG-A" name="Retrospective" guid="_J_sRIP_AEdqtbrr0B1TG-A" briefDescription="Faire un bilan du sprint qui se termine" presentationName="Rétrospective" performedBy="_9apLsPpaEdqsc-f87sBK8A" output="_5ABscPpYEdqsc-f87sBK8A" additionallyPerformedBy="_ICJyYPpaEdqsc-f87sBK8A _t1K9kPpYEdqsc-f87sBK8A _Qqmp8P_AEdqtbrr0B1TG-A">
- <presentation xmi:id="-S4qXwp40l_8eCcyyI7o-3A" href="uma://-S4qXwp40l_8eCcyyI7o-3A#-S4qXwp40l_8eCcyyI7o-3A"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="_Qqmp8P_AEdqtbrr0B1TG-A" name="StakeHolder" guid="_Qqmp8P_AEdqtbrr0B1TG-A" briefDescription="Personne ne participant pas directement au projet mais ayant une influence sur celui-ci." presentationName="Intervenant">
- <presentation xmi:id="-u0-b4PNo9XzOh1-dv_aaKA" href="uma://-u0-b4PNo9XzOh1-dv_aaKA#-u0-b4PNo9XzOh1-dv_aaKA"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_Xpd5gP_AEdqtbrr0B1TG-A" name="Manage problems" guid="_Xpd5gP_AEdqtbrr0B1TG-A" briefDescription="Prendre en compte les événements qui surviennent à tout moment sur un projet et tenter de les régler." presentationName="Gérer les problèmes" performedBy="_t1K9kPpYEdqsc-f87sBK8A" output="_Dzw70PpZEdqsc-f87sBK8A" optionalInput="_Dzw70PpZEdqsc-f87sBK8A">
- <presentation xmi:id="-mZfAV7RcWJlp5idlHzeEcA" href="uma://-mZfAV7RcWJlp5idlHzeEcA#-mZfAV7RcWJlp5idlHzeEcA"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_d09LYP_AEdqtbrr0B1TG-A" name="Scrum daily meeting" guid="_d09LYP_AEdqtbrr0B1TG-A" briefDescription="La régulation des activités de développement et de test se fait à travers les mêlées quotidiennes." presentationName="Mêlée quotidienne" performedBy="_t1K9kPpYEdqsc-f87sBK8A" mandatoryInput="_Dzw70PpZEdqsc-f87sBK8A" output="_Dzw70PpZEdqsc-f87sBK8A" additionallyPerformedBy="_9apLsPpaEdqsc-f87sBK8A _ICJyYPpaEdqsc-f87sBK8A">
- <presentation xmi:id="-vDOuVl_xPKipKd90HQNZng" href="uma://-vDOuVl_xPKipKd90HQNZng#-vDOuVl_xPKipKd90HQNZng"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_STkWYP_BEdqtbrr0B1TG-A" name="Update product backlog" guid="_STkWYP_BEdqtbrr0B1TG-A" briefDescription="Prise en compte des changements de périmètre en vue de préparer les sprints suivants." presentationName="Mettre à jour le backlog de produit" performedBy="_ICJyYPpaEdqsc-f87sBK8A" mandatoryInput="_5ABscPpYEdqsc-f87sBK8A" output="_5ABscPpYEdqsc-f87sBK8A" additionallyPerformedBy="_Qqmp8P_AEdqtbrr0B1TG-A _9apLsPpaEdqsc-f87sBK8A">
- <presentation xmi:id="-XdgedeazfFRGDxMY3Fnh5g" href="uma://-XdgedeazfFRGDxMY3Fnh5g#-XdgedeazfFRGDxMY3Fnh5g"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_ho-aIP_BEdqtbrr0B1TG-A" name="Plan release" guid="_ho-aIP_BEdqtbrr0B1TG-A" briefDescription="Planification à moyen terme" presentationName="Planifier la release" performedBy="_ICJyYPpaEdqsc-f87sBK8A" mandatoryInput="_5ABscPpYEdqsc-f87sBK8A" output="_5ABscPpYEdqsc-f87sBK8A" additionallyPerformedBy="_t1K9kPpYEdqsc-f87sBK8A _9apLsPpaEdqsc-f87sBK8A">
- <presentation xmi:id="-3f4axrWBKHGv74oKN2x-gQ" href="uma://-3f4axrWBKHGv74oKN2x-gQ#-3f4axrWBKHGv74oKN2x-gQ"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_OUjj0AEZEduzRosbOajx7w" name="Travail collaboratif" guid="_OUjj0AEZEduzRosbOajx7w" presentationName="Travail collaboratif">
- <presentation xmi:id="-dU_t9olFRQIyOBZQvMndKg" href="uma://-dU_t9olFRQIyOBZQvMndKg#-dU_t9olFRQIyOBZQvMndKg"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_XtRuYP-zEdqLnajTSLeAsA" name="Produit, release et sprint" guid="_XtRuYP-zEdqLnajTSLeAsA" presentationName="Produit, release et sprint">
- <presentation xmi:id="-BPz1k8sC6CCyJ2yZCc1p2Q" href="uma://-BPz1k8sC6CCyJ2yZCc1p2Q#-BPz1k8sC6CCyJ2yZCc1p2Q"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="_BGFMoANkEduYd-55D-Aiqg" name="Initiate Product Backlog" guid="_BGFMoANkEduYd-55D-Aiqg" briefDescription="Identifier une liste d'items, les inclure dans le backlog et les classer par priorité." presentationName="Elaborer le backlog de produit initial" performedBy="_ICJyYPpaEdqsc-f87sBK8A" output="_5ABscPpYEdqsc-f87sBK8A" additionallyPerformedBy="_Qqmp8P_AEdqtbrr0B1TG-A _9apLsPpaEdqsc-f87sBK8A">
- <presentation xmi:id="-mi1O4H7RRm0YqlUNyp8TJg" href="uma://-mi1O4H7RRm0YqlUNyp8TJg#-mi1O4H7RRm0YqlUNyp8TJg"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="_3WivIBTQEduFIr9xNbwGyQ" name="Presentation Scrum" guid="_3WivIBTQEduFIr9xNbwGyQ" briefDescription="Scrum repose sur une technique de gestion de projets qui conduit à obtenir un produit avec la plus grande valeur "métier" possible dans la durée la plus réduite." presentationName="Scrum">
- <presentation xmi:id="-MSO8KF-0IlKZJGnSwwTNZA" href="uma://-MSO8KF-0IlKZJGnSwwTNZA#-MSO8KF-0IlKZJGnSwwTNZA"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Report" xmi:id="_Z2NzkIGWEduKE9hnyImx1Q" name="Release Planning" guid="_Z2NzkIGWEduKE9hnyImx1Q" briefDescription="Plan montrant les sprints et les éléments du backlog associés à ces sprints" presentationName="Planning de la release" conceptsAndPapers="_XtRuYP-zEdqLnajTSLeAsA">
- <presentation xmi:id="-EmLqiNX2WnmsfEtxNiuyTQ" href="uma://-EmLqiNX2WnmsfEtxNiuyTQ#-EmLqiNX2WnmsfEtxNiuyTQ"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_kftWoIHqEduFs9jH8xc4xw" name="Sprint" guid="_kftWoIHqEduFs9jH8xc4xw" presentationName="Sprint">
- <presentation xmi:id="-fcoz1Nm_QnX6xtLg5YWdVg" href="uma://-fcoz1Nm_QnX6xtLg5YWdVg#-fcoz1Nm_QnX6xtLg5YWdVg"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_AIB9gIHrEduFs9jH8xc4xw" name="Release" guid="_AIB9gIHrEduFs9jH8xc4xw" presentationName="Release">
- <presentation xmi:id="-XPyPmZTAVbnvJVuOLvYpXw" href="uma://-XPyPmZTAVbnvJVuOLvYpXw#-XPyPmZTAVbnvJVuOLvYpXw"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_aeYKoIKlEduQgtHqedKdMA" name="Theme" guid="_aeYKoIKlEduQgtHqedKdMA" presentationName="Thème">
- <presentation xmi:id="-GKfSarwQLoaHhoT71FQI8Q" href="uma://-GKfSarwQLoaHhoT71FQI8Q#-GKfSarwQLoaHhoT71FQI8Q"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_HQEP8ILXEduLd8CaF_IcMA" name="Velocity" guid="_HQEP8ILXEduLd8CaF_IcMA" presentationName="Vélocité">
- <presentation xmi:id="-PeP4fADValHXs2Z2Z8zJ1w" href="uma://-PeP4fADValHXs2Z2Z8zJ1w#-PeP4fADValHXs2Z2Z8zJ1w"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_3qdXkILXEduLd8CaF_IcMA" name="Timebox" guid="_3qdXkILXEduLd8CaF_IcMA" presentationName="Bloc de temps">
- <presentation xmi:id="-tHVOELWOQDI7i0M2rlMufQ" href="uma://-tHVOELWOQDI7i0M2rlMufQ#-tHVOELWOQDI7i0M2rlMufQ"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:TermDefinition" xmi:id="_X5rREILYEduLd8CaF_IcMA" name="Burndown Chart" guid="_X5rREILYEduLd8CaF_IcMA" presentationName="Graphe de tendance">
- <presentation xmi:id="-KQ4Jzjy6YgAr_2NXa4J67g" href="uma://-KQ4Jzjy6YgAr_2NXa4J67g#-KQ4Jzjy6YgAr_2NXa4J67g"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Roadmap" xmi:id="_6Jox0IRuEduo75chJsIcXg" name="Application" guid="_6Jox0IRuEduo75chJsIcXg" briefDescription="Appliquer Scrum sans oublier les principes" presentationName="Appliquer Scrum">
- <presentation xmi:id="-IPxNSDzXKWa-H_kJ2PMtYA" href="uma://-IPxNSDzXKWa-H_kJ2PMtYA#-IPxNSDzXKWa-H_kJ2PMtYA"/>
- </contentElements>
- </childPackages>
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_SqGkoABREdu3o4yroaI-tA" name="Général" guid="_SqGkoABREdu3o4yroaI-tA">
- <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_wz30kABREdu3o4yroaI-tA" name="Introduction" guid="_wz30kABREdu3o4yroaI-tA" briefDescription="Bienvenue dans Scrum !" presentationName="Introduction">
- <presentation xmi:id="-WfzsSn3X35gSHQZ2kqtoVw" href="uma://-WfzsSn3X35gSHQZ2kqtoVw#-WfzsSn3X35gSHQZ2kqtoVw"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_N8zs0AEGEduzRosbOajx7w" name="Copyright" guid="_N8zs0AEGEduzRosbOajx7w" presentationName="Copyright">
- <presentation xmi:id="-03XtfjRMEs23qIdCSSQiNQ" href="uma://-03XtfjRMEs23qIdCSSQiNQ#-03XtfjRMEs23qIdCSSQiNQ"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_PTGe4IRvEduo75chJsIcXg" name="Scrum references" guid="_PTGe4IRvEduo75chJsIcXg" presentationName="Références">
- <presentation xmi:id="-cfa6bdUgQuboNpJRKaCLAw" href="uma://-cfa6bdUgQuboNpJRKaCLAw#-cfa6bdUgQuboNpJRKaCLAw"/>
- </contentElements>
- </childPackages>
- </childPackages>
- <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_mQ3erfpYEdqsc-f87sBK8A" name="CapabilityPatterns" guid="_mQ3erfpYEdqsc-f87sBK8A"/>
- </methodPackages>
- <methodPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_mQ3ervpYEdqsc-f87sBK8A" name="DeliveryProcesses" guid="_mQ3ervpYEdqsc-f87sBK8A">
- <childPackages xsi:type="org.eclipse.epf.uma:ProcessComponent" xmi:id="_9llsAAAvEdubGMceRDupFQ" href="uma://_9llsAAAvEdubGMceRDupFQ#_9llsAAAvEdubGMceRDupFQ"/>
- </methodPackages>
- <methodPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_mQ3er_pYEdqsc-f87sBK8A" name="ProcessContributions" guid="_mQ3er_pYEdqsc-f87sBK8A"/>
- </org.eclipse.epf.uma:MethodPlugin>
-</xmi:XMI>
diff --git a/Scrum French/Scrum/roles/Product Owner.xmi b/Scrum French/Scrum/roles/Product Owner.xmi
deleted file mode 100644
index 8a24545..0000000
--- a/Scrum French/Scrum/roles/Product Owner.xmi
+++ /dev/null
@@ -1,70 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-35iKPqDM2F2PjKWQLCW4tA" name="Product Owner,_ICJyYPpaEdqsc-f87sBK8A" guid="-35iKPqDM2F2PjKWQLCW4tA" authors="Claude Aubry" changeDate="2006-12-06T09:55:24.078+0100" version="1.0.0">
- <mainDescription><p>
- Le Directeur de produit (<i>Product Owner</i>) est le représentant des clients et utilisateurs dans l'équipe.
-</p>
-<p>
- A ce titre, il est responsable de définir les caractéristiques du produit développé par l'équipe en termes de :
-</p>
-<ul>
- <li>
- <strong>fonctionnalités</strong> offertes. Plus précisément il identifie chaque exigence que doit&nbsp;satisfaire
- le produit comme un&nbsp;<a class="elementLink"
- href="./../../Scrum/workproducts/Product Backlog Item,_-D85cIGIEduKE9hnyImx1Q.html"
- guid="_-D85cIGIEduKE9hnyImx1Q">Elément de backlog de produit</a>&nbsp;(ou item). Il fournit les détails sur ces
- exigences quand c'est nécessaire pour l'équipe. Il est souhaitable qu'il spécifie&nbsp;les tests d'acceptation
- (acceptance tests) de chaque exigence.
- </li>
- <li>
- <strong>priorité</strong>. C'est lui qui définit l'ordre dans lequel ces éléments seront développés en fonction de
- la valeur qu'ils apportent aux clients et utilisateurs. Cela permet d'alimenter l'équipe avec un <a
- class="elementLink" href="./../../Scrum/workproducts/Product Backlog,_5ABscPpYEdqsc-f87sBK8A.html"
- guid="_5ABscPpYEdqsc-f87sBK8A">Backlog de produit</a>&nbsp;prêt pour la planification des sprints,
- </li>
- <li>
- <strong>but</strong>. C'est lui définit l'objectif d'une release et qui prend les décisions concernant le <a
- class="elementLink" href="./../../Scrum/guidances/reports/Release Planning,_Z2NzkIGWEduKE9hnyImx1Q.html"
- guid="_Z2NzkIGWEduKE9hnyImx1Q">Planning de la release</a>.
- </li>
-</ul>
-<br /></mainDescription>
- <keyConsiderations><p>
- Son implication est capitale pour assurer le succès du projet. En définissant sa vision sur le produit, il&nbsp;donne
- l'impulsion à l'équipe. En promouvant à l'extérieur le résultat de chaque sprint, il fournit à l'équipe une
- reconnaissance qui la motive.
-</p></keyConsiderations>
- <skills><p>
- Une personne qui joue ce rôle devrait posséder les compétences suivantes :
-</p>
-<ul>
- <li>
- bonne connaissance du domaine métier,
- </li>
- <li>
- capacité à avoir une position respectée par tous les intervenants extérieurs (clients et utilisateurs),
- </li>
- <li>
- capacité à prendre une décision au bon moment (pas trop tôt ni trop tard),
- </li>
- <li>
- esprit ouvert au changement,
- </li>
- <li>
- facilité à communiquer avec l'équipe.
- </li>
-</ul>
-<p>
- Quelqu'un qui a été Analyste Métier (Business Analyst) est un bon candidat pour ce rôle.
-</p></skills>
- <assignmentApproaches><p>
- Il n'y a qu'une seule personne qui joue ce rôle. Cette personne doit être affectée au projet (le Directeur de produit
- fait partie de l'équipe étendue et participe aux réunions). Le travail nécessite une affectation à plein temps ou
- presque.
-</p>
-<p>
- Il est&nbsp;important qu'il soit très disponible pour répondre aux questions de l'équipe, pour définir les tests
- fonctionnels et&nbsp;donner son avis sur divers aspects du produit (l'interface homme machine d'un logiciel, par
- exemple).
-</p></assignmentApproaches>
- <synonyms>Propriétaire de produit (product owner en anglais),&nbsp;Client (dans XP)</synonyms>
-</org.eclipse.epf.uma:RoleDescription>
diff --git a/Scrum French/Scrum/roles/ScrumMaster.xmi b/Scrum French/Scrum/roles/ScrumMaster.xmi
deleted file mode 100644
index 84b2974..0000000
--- a/Scrum French/Scrum/roles/ScrumMaster.xmi
+++ /dev/null
@@ -1,122 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-Y3SFEe-A-lRF8TaEn9vKNQ" name="new_role,_t1K9kPpYEdqsc-f87sBK8A" guid="-Y3SFEe-A-lRF8TaEn9vKNQ" authors="Claude Aubry" changeDate="2007-01-08T17:37:05.421+0100" version="1.0.0">
- <mainDescription><p>
- Il a pour responsabilité, dans le cadre du développement d'un produit, d'aider l'équipe à travailler de façon autonome
- et à s'améliorer constamment.
-</p>
-<p>
- Pour cela, il effectue les travaux suivants :&nbsp;
-</p>
-<ul>
- <li>
- tâches périodiques,&nbsp;dont l'objectif est de mettre en application Scrum en organisant et animant le&nbsp;<a
- class="elementLink" href="./../../Scrum/guidances/concepts/Travail collaboratif,_OUjj0AEZEduzRosbOajx7w.html"
- guid="_OUjj0AEZEduzRosbOajx7w">Travail collaboratif</a>&nbsp;(réunions)&nbsp;:
- <ul>
- <li>
- Mêlée quotidienne.
- </li>
- <li>
- Planification du sprint
- </li>
- <li>
- Revue du sprint
- </li>
- <li>
- Rétrospective
- </li>
- </ul>
- </li>
- <li>
- tâches sur évènement
- <ul>
- <li>
- éliminer les obstacles&nbsp;: prendre en compte les évènements qui surviennent à tout moment sur un projet
- pour les régler au plus vite, tout en protégeant l’équipe des interférences extérieures
- </li>
- </ul>
- </li>
- <li>
- tâche de fond
- <ul>
- <li>
- faire en sorte que l’équipe reste concentrée sur le véritable objectif du projet, qui est de réaliser les
- éléments du Backlog en collaboration étroite avec le Directeur Produit, et soit productive .
- </li>
- </ul>
- </li>
-</ul>
-<p>
- Analogies
-</p>
-<ul>
- <li>
- Le terme Scrum vient du rugby. Le poste de demi de mêlée est celui qui se rapproche le plus de l'idée de
- ScrumMaster.
- </li>
- <li>
- Ken Schwaber compare le ScrumMaster à un chien de berger.
- </li>
-</ul>
-<br /></mainDescription>
- <keyConsiderations><ul>
- <li>
- Ce n'est pas un chef de projet&nbsp;: il ne dirige pas, il n'impose pas, il ne contraint pas.
- </li>
- <li>
- Il fait partie de l'équipe&nbsp;: il s'engage avec les autres.
- </li>
- <li>
- Il doit régulièrement rencontrer physiquement les autres membres de l'équipe.
- </li>
-</ul></keyConsiderations>
- <skills><p>
- Les compétences et l'expérience souhaitées dépendent de la taille, de la complexité technique et de management. Il est
- préférable de posséder les compétences suivantes pour jouer&nbsp;ce rôle :
-</p>
-<ul>
- <li>
- bien connaître Scrum,
- </li>
- <li>
- avoir des facilités de présentation, de communication et de négociation,
- </li>
- <li>
- guider sans imposer,
- </li>
- <li>
- faire preuve de qualité de meneur d'hommes et savoir motiver une équipe,
- </li>
- <li>
- savoir résoudre les conflits et les problèmes,
- </li>
- <li>
- communiquer honnêtement sur le degré d'avancement,
- </li>
- <li>
- garder le respect de l'objectif essentiel, qui est de livrer un produit qui remplit&nbsp;ses exigences.
- </li>
-</ul>
-<p>
- En revanche il n'est pas nécessaire de :
-</p>
-<ul>
- <li>
- avoir de l'expérience du domaine de l'application (pas indispensable, mais ça peut aider),
- </li>
- <li>
- avoir des compétences techniques sur le développement.
- </li>
-</ul></skills>
- <assignmentApproaches><p>
- Pour une équipe Scrum typique (de 6 à 10 personnes) , une seule personne joue ce rôle sur un projet.
-</p>
-<p>
- Celui qui le joue peut, éventuellement, participer aux travaux du sprint avec les autres membres de l'équipe, mais cela
- doit rester limité.
-</p></assignmentApproaches>
- <synonyms><p>
- Facilitateur de processus. On désigne parfois le ScrumMaster comme une déclinaison agile du chef de projet, mais cela
- ne favorise pas la compréhension du rôle.
-</p></synonyms>
-</org.eclipse.epf.uma:RoleDescription>
diff --git a/Scrum French/Scrum/roles/StakeHolder.xmi b/Scrum French/Scrum/roles/StakeHolder.xmi
deleted file mode 100644
index a1ded05..0000000
--- a/Scrum French/Scrum/roles/StakeHolder.xmi
+++ /dev/null
@@ -1,18 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-u0-b4PNo9XzOh1-dv_aaKA" name="StakeHolder,_Qqmp8P_AEdqtbrr0B1TG-A" guid="-u0-b4PNo9XzOh1-dv_aaKA" authors="Claude Aubry" changeDate="2006-12-03T09:39:26.078+0100" version="1.0.0">
- <mainDescription><p>
- Un intervenant ne fait pas partie de l'équipe, mais il est intéressé par le produit réalisé. Il peut avoir une
- influence sur le déroulement du projet. Il participe à des réunions Scrum : voir sa contribution au <a
- class="elementLink" href="./../../Scrum/guidances/concepts/Travail collaboratif,_OUjj0AEZEduzRosbOajx7w.html"
- guid="_OUjj0AEZEduzRosbOajx7w">Travail collaboratif</a>.
-</p>
-<p>
- Dans son jargon, Scrum appelle&nbsp;les personnes jouant ce rôle&nbsp;des poules (chicken) et conseille de protéger
- l’équipe, constituée des cochons (pigs), de leur influence directe sur le projet pendant un sprint. Cela signifie que
- les intervenants ont des fenêtres d'intervention qui sont strictement définies afin de ne pas perturber le travail de
- l'équipe.
-</p></mainDescription>
- <synonyms><p>
- Partie-prenante (Stakeholder en anglais)
-</p></synonyms>
-</org.eclipse.epf.uma:RoleDescription>
diff --git a/Scrum French/Scrum/roles/Team.xmi b/Scrum French/Scrum/roles/Team.xmi
deleted file mode 100644
index 91e38f6..0000000
--- a/Scrum French/Scrum/roles/Team.xmi
+++ /dev/null
@@ -1,16 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-LVZG5zK2YjEGXO3SwDmqug" name="Team,_9apLsPpaEdqsc-f87sBK8A" guid="-LVZG5zK2YjEGXO3SwDmqug" authors="Claude Aubry" changeDate="2006-12-03T09:36:21.984+0100" version="1.0.0">
- <mainDescription><p>
- Une équipe regroupe des membres qui forment un tout soudé capable de réaliser les différentes tâches sur
- lesquelles&nbsp;elle s’engage collectivement lors de chaque sprint.
-</p>
-<p>
- Elle possède la latitude voulue pour déterminer ce qui doit être fait afin d’atteindre le but fixé du sprint. Elle
- s’organise de façon autonome et planifie ses propres travaux, sans se les faire imposer.
-</p></mainDescription>
- <keyConsiderations>Par son approche centrée sur le collectif,&nbsp;l'agilité contribue à améliorer la camaraderie dans l’équipe.</keyConsiderations>
- <skills>L’équipe doit être capable de réaliser les différentes tâches sur lesquelles elle s'engage lors de la planification du
-sprint. Cela signifie qu'elle doit être multi-fonctionnelle (cross-functional) pour couvrir les travaux d'analyse, de
-conception, de codage, de test et autres.</skills>
- <assignmentApproaches>Une équipe Scrum comprend généralement de&nbsp;3 à 10 personnes.</assignmentApproaches>
-</org.eclipse.epf.uma:RoleDescription>
diff --git a/Scrum French/Scrum/roles/resources/148-le-role-de-scrummaster.html b/Scrum French/Scrum/roles/resources/148-le-role-de-scrummaster.html
deleted file mode 100644
index 83644c8..0000000
--- a/Scrum French/Scrum/roles/resources/148-le-role-de-scrummaster.html
+++ /dev/null
@@ -1,296 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html lang="fr" xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
-<head>
-
-
-<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
-
-
-
-
-
- <meta name="MSSmartTagsPreventParsing" content="TRUE">
- <link rel="previous" href="http://www.aubryconseil.com/dotclear/index.php/2007/01/05/146-inscription-technorati" title="Inscription Technorati">
-<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/Mes-projets" title="Mes projets">
-<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/Evenements" title="Mes événements">
-<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/Mes-conseils" title="Mes conseils">
-<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/Mes-cours" title="Mes cours">
-<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/L-agilite-en-france" title="L'agilité en France">
-<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/L-agilite-dans-le-monde" title="L'agilité dans le monde">
-<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/L-agilite-en-dehors-du-logiciel" title="L'agilité en dehors du logiciel">
-<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/Mon-butinage" title="Mon butinage">
-<link rel="section" href="http://www.aubryconseil.com/dotclear/index.php/Mon-blog" title="Mon blog">
-<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2007/01" title="janvier 2007">
-<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/12" title="décembre 2006">
-<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/11" title="novembre 2006">
-<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/10" title="octobre 2006">
-<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/09" title="septembre 2006">
-<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/08" title="août 2006">
-<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/07" title="juillet 2006">
-<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/06" title="juin 2006">
-<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/05" title="mai 2006">
-<link rel="archive" href="http://www.aubryconseil.com/dotclear/index.php/2006/04" title="avril 2006">
- <link rel="alternate" type="application/rss+xml" title="RSS" href="http://www.aubryconseil.com/dotclear/rss.php">
- <link rel="alternate" type="application/xml" title="Atom" href="http://www.aubryconseil.com/dotclear/atom.php">
- <meta name="DC.title" content="Scrum - Méthodes agiles"><title>Le rôle de ScrumMaster - Scrum - Méthodes agiles</title><!--
-<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
- xmlns:dc="http://purl.org/dc/elements/1.1/"
- xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/">
-<rdf:Description
- rdf:about="http://www.aubryconseil.com/dotclear/index.php/2007/01/07/148-le-role-de-scrummaster"
- dc:identifier="http://www.aubryconseil.com/dotclear/index.php/2007/01/07/148-le-role-de-scrummaster"
- dc:title="Le rôle de ScrumMaster"
- trackback:ping="http://www.aubryconseil.com/dotclear/tb.php?id=148" />
-</rdf:RDF>
--->
-
-
-
-<link rel="stylesheet" type="text/css" href="148-le-role-de-scrummaster.css" media="all"></head><body>
-
-<div id="page">
-
-<div id="top">
- <h1><a indepth="true" href="index.html">Scrum - Méthodes agiles</a></h1>
-</div>
-
-<p id="prelude"><a href="#main">Aller au contenu</a> |
-<a href="#sidebar">Aller au menu</a> |
-<a href="#search">Aller à la recherche</a></p>
-
-<div id="main">
- <div id="content">
-
-<div class="post">
- <h2 class="post-title">Le rôle de ScrumMaster</h2>
- <p class="post-info">
-<!--
-claude aubry,
--->
- dimanche 7 janvier 2007 à 16:08 <span>::</span> <a indepth="true" href="mes-conseils.html">Mes conseils</a>
- <span>::</span> <a indepth="true" href="148-le-role-de-scrummaster.html" title="Lien permanent vers : Le rôle de ScrumMaster">#148</a>
- <span>::</span> <a href="http://www.aubryconseil.com/dotclear/rss.php?type=co&post=148" title="fil RSS des commentaires de : Le rôle de ScrumMaster">rss</a>
- </p>
-
- <div class="post-chapo"><p>Un résumé du rôle de ScrumMaster, l'animateur d'une équipe qui applique Scrum.</p></div> <div class="post-content"><h5>Synonymes</h5>
-<ul>
-<li>Facilitateur de processus.</li>
-<li>On désigne parfois le ScrumMaster comme une déclinaison agile du chef de projet, mais cela ne favorise pas la compréhension du rôle <sup>[<a href="#pnote-148-1" id="rev-pnote-148-1">1</a>]</sup>.</li>
-</ul>
-<h5>Analogies</h5>
-<ul>
-<li>Le terme Scrum vient du rugby. Le poste de demi de mêlée est celui qui se rapproche le plus de l'idée de ScrumMaster.</li>
-<li>Ken Schwaber compare le ScrumMaster à un chien de berger.</li>
-</ul>
-<h5>Responsabilité</h5>
-
-<p>Il a pour responsabilité, dans le cadre du développement d'un produit, d'aider l'équipe à travailler de façon autonome et à s'améliorer constamment.</p>
-
-
-<h5>Tâches</h5>
-<ul>
-<li>tâches périodiques : mettre en application Scrum en organisant et animant les réunions :
-<ul>
-<li>Mêlée quotidienne.</li>
-<li>Planification du sprint</li>
-<li>Revue du sprint</li>
-<li>Rétrospective</li>
-</ul></li>
-<li>tâches sur évènement
-<ul>
-<li>éliminer les obstacles : prendre en compte les évènements qui surviennent à tout moment sur un projet pour les régler au plus vite, tout en protégeant l’équipe des interférences extérieures</li>
-</ul></li>
-<li>tâche de fond
-<ul>
-<li>faire en sorte que l’équipe reste concentrée sur le véritable objectif du projet, qui est de réaliser les éléments du Backlog en collaboration étroite avec le Directeur Produit, et soit productive .</li>
-</ul></li>
-</ul>
-
-<h5>Compétences</h5>
-
-<p>Les compétences et l'expérience souhaitées dépendent de la taille, de la complexité technique et de management. Il est préférable de posséder les compétences suivantes pour jouer ce rôle :</p>
-<ul>
-<li>bien connaitre Scrum,</li>
-<li>avoir des facilités de présentation, de communication et de négociation,</li>
-<li>guider sans imposer,</li>
-<li>faire preuve de qualité de meneur d'hommes et savoir motiver une équipe,</li>
-<li>savoir résoudre les conflits et les problèmes,</li>
-<li>communiquer honnêtement sur le degré d'avancement,</li>
-<li>garder le respect de l'objectif essentiel, qui est de livrer un produit qui apporte de la valeur avec une utilisation optimale des ressources.</li>
-</ul>
-
-<p>En revanche il n'est pas nécessaire de :</p>
-<ul>
-<li>avoir de l'expérience du domaine de l'application <sup>[<a href="#pnote-148-2" id="rev-pnote-148-2">2</a>]</sup>,</li>
-<li>avoir des compétences techniques sur le développement logiciel.</li>
-</ul>
-
-<h5>Affectation</h5>
-
-
-<p>Pour une équipe Scrum typique <sup>[<a href="#pnote-148-3" id="rev-pnote-148-3">3</a>]</sup>, une seule personne joue ce rôle sur un projet.</p>
-
-
-<p>Celui qui le joue peut, éventuellement, participer aux travaux du sprint avec les autres membres de l'équipe, mais cela doit rester limité.</p>
-
-<h5>Points clés</h5>
-<ul>
-<li>Ce n'est pas un chef de projet : il ne dirige pas, il n'impose pas, il ne contraint pas.</li>
-<li>Il fait partie de l'équipe : il s'engage avec les autres.</li>
-<li>Il doit régulièrement rencontrer physiquement les autres membres de l'équipe.</li>
-</ul>
-<div class="footnotes"><h4>Notes</h4>
-<p>[<a href="#rev-pnote-148-1" id="pnote-148-1">1</a>] voir sur ce sujet <a href="http://agilitateur.azeau.com/index.php?itemid=61" hreflang="fr">le billet de l'Agilitateur</a></p>
-<p>[<a href="#rev-pnote-148-2" id="pnote-148-2">2</a>] ce n'est pas indispensable, mais ça peut aider</p>
-<p>[<a href="#rev-pnote-148-3" id="pnote-148-3">3</a>] de 6 à 10 personnes</p></div></div>
-
-
-</div>
-
-<div id="trackbacks">
- <h3 id="tb">Rétroliens</h3>
- <p>Aucun rétrolien.</p>
-
-
-
- <p>Pour faire un rétrolien sur ce billet :
- http://www.aubryconseil.com/dotclear/tb.php?id=148</p>
- </div>
-
-<div id="comments">
- <h3 id="co">Commentaires</h3>
- <p>Aucun commentaire pour le moment.</p>
-
-
-
- <h3>Ajouter un commentaire</h3>
- <form action="http://www.aubryconseil.com/dotclear/index.php/2007/01/07/148-le-role-de-scrummaster" method="post" id="comment-form">
-<fieldset>
- <p class="field"><label for="c_nom">Nom ou pseudo :</label>
- <input name="c_nom" id="c_nom" size="30" maxlength="255" value="" type="text">
- </p>
-
- <p class="field"><label for="c_mail">Email (facultatif) :</label>
- <input name="c_mail" id="c_mail" size="30" maxlength="255" value="" type="text">
- </p>
-
- <p class="field"><label for="c_site">Site Web (facultatif) :</label>
- <input name="c_site" id="c_site" size="30" maxlength="255" value="http://" type="text">
- </p>
-
- <p class="field"><label for="c_content">Commentaire :</label>
- <textarea name="c_content" id="c_content" cols="35" rows="7"></textarea>
- </p>
-</fieldset>
-
-<p class="form-help">Le code HTML dans le commentaire sera affiché comme du texte,
-les adresses internet seront converties automatiquement.</p>
-
-<fieldset>
- <p><input id="c_remember" name="c_remember" type="checkbox">
- <label for="c_remember">Se souvenir de mes informations</label>
- </p>
- <p><input class="preview" name="preview" value="prévisualiser" type="submit">
- <input class="submit" value="envoyer" type="submit">
- <input name="redir" value="http://www.aubryconseil.com/dotclear/index.php/2007/01/07/148-le-role-de-scrummaster" type="hidden"></p>
-</fieldset>
-
-</form>
- </div>
- </div>
-</div>
-
- <div id="sidebar">
-
-
- <div id="presentation"><h2></h2><p>Dans ce blog ma contribution à la diffusion de Scrum à travers mes expériences en tant que <a href="http://www.aubryconseil.com/">consultant</a> et comme enseignant à l'<a href="http://www.iup-ups.ups-tlse.fr/isi/" hreflang="fr">IUP ISI</a> <br>
-Claude Aubry</p>
- <a indepth="true" href="contact.html">Page contact</a>
- </div>
-
- <div id="connexes">
- <h2>Scrum</h2>
-
- <ul><li><a indepth="true" href="scrum_001.html">Introduction à Scrum</a>
-</li><li><a indepth="true" href="mon-offre-scrum.html">Essayer Scrum</a>
-</li><li><a indepth="true" href="icescrum.html">IceScrum</a>
-</li><li><a indepth="true" href="liens-scrum.html">Plus d'infos sur Scrum</a>
-</li></ul> </div>
-
-
-
- <div id="tags">
- <h2>Tags</h2>
-
- <ul id="tagcloud"><li class="level-2"><a indepth="true" href="agilite.html">agilité</a> </li><li class="level-1"><a indepth="true" href="backlog.html">backlog</a> </li><li class="level-1"><a indepth="true" href="blog.html">blog</a> </li><li class="level-1"><a indepth="true" href="conference.html">conférence</a> </li><li class="level-1"><a indepth="true" href="contrat.html">contrat</a> </li><li class="level-1"><a indepth="true" href="dotclear.html">dotclear</a> </li><li class="level-1"><a indepth="true" href="epf.html">EPF</a> </li><li class="level-1"><a indepth="true" href="equipe.html">equipe</a> </li><li class="level-2"><a indepth="true" href="estimation.html">estimation</a> </li><li class="level-1"><a indepth="true" href="fac.html">fac</a> </li><li class="level-1"><a indepth="true" href="formation.html">formation</a> </li><li class="level-1"><a indepth="true" href="humour.html">humour</a> </li><li class="level-2"><a indepth="true" href="icescrum_001.html">icescrum</a> </li><li class="level-1"><a indepth="true" href="mesures.html">mesures</a> </li><li class="level-1"><a indepth="true" href="moi.html">moi</a> </li><li class="level-1"><a indepth="true" href="musique.html">musique</a> </li><li class="level-1"><a indepth="true" href="openup.html">OpenUP</a> </li><li class="level-1"><a indepth="true" href="outils.html">outils</a> </li><li class="level-2"><a indepth="true" href="planification.html">planification</a> </li><li class="level-2"><a indepth="true" href="processus.html">processus</a> </li><li class="level-1"><a indepth="true" href="presentation.html">présentation</a> </li><li class="level-1"><a indepth="true" href="release.html">release</a> </li><li class="level-1"><a indepth="true" href="rugby.html">rugby</a> </li><li class="level-1"><a indepth="true" href="retrospective.html">rétrospective</a> </li><li class="level-1"><a indepth="true" href="roles.html">rôles</a> </li><li class="level-5"><a indepth="true" href="scrum.html">scrum</a> </li><li class="level-1"><a indepth="true" href="sigmat.html">sigmat</a> </li><li class="level-1"><a indepth="true" href="tdd.html">tdd</a> </li><li class="level-1"><a indepth="true" href="techno.html">techno</a> </li><li class="level-2"><a indepth="true" href="tendances.html">tendances</a> </li><li class="level-1"><a indepth="true" href="traduction.html">traduction</a> </li><li class="level-1"><a indepth="true" href="uml.html">UML</a> </li><li class="level-2"><a indepth="true" href="user-stories.html">user stories</a> </li><li class="level-1"><a indepth="true" href="vision.html">vision</a> </li><li class="level-1"><a indepth="true" href="xp.html">xp</a> </li></ul> </div>
-
- <div id="syndicate">
- <h2>Syndication</h2>
- <a href="http://www.netvibes.com/subscribe.php?url=http%3A%2F%2Fwww.aubryconseil.com%2Fdotclear"><img src="add2netvibes.gif" alt="Add to Netvibes" height="17" width="91"></a>
- <ul>
- <li><a href="http://www.aubryconseil.com/dotclear/rss.php">fil rss</a></li>
- <li><a href="http://www.aubryconseil.com/dotclear/rss.php?type=co">fil rss commentaires</a></li>
- <li><a href="http://www.aubryconseil.com/dotclear/atom.php">fil atom</a></li>
- <li><a href="http://www.aubryconseil.com/dotclear/atom.php?type=co">fil atom commentaires</a></li>
- </ul>
- </div>
-
- <div id="calendar">
- <h2>Calendrier</h2>
- <table summary="Calendrier">
-<caption><a indepth="true" href="12.html" title="décembre 2006">«</a> janvier 2007</caption><thead><tr><th scope="col"><abbr title="lundi">lun</abbr></th><th scope="col"><abbr title="mardi">mar</abbr></th><th scope="col"><abbr title="mercredi">mer</abbr></th><th scope="col"><abbr title="jeudi">jeu</abbr></th><th scope="col"><abbr title="vendredi">ven</abbr></th><th scope="col"><abbr title="samedi">sam</abbr></th><th scope="col"><abbr title="dimanche">dim</abbr></th></tr></thead>
-<tbody><tr><td><a indepth="true" href="01.html">1</a></td><td><a indepth="true" href="02.html">2</a></td><td>3</td><td><a indepth="true" href="04.html">4</a></td><td><a indepth="true" href="05.html">5</a></td><td>6</td><td class="active"><a indepth="true" href="07.html">7</a></td></tr>
-<tr><td>8</td><td>9</td><td>10</td><td>11</td><td>12</td><td>13</td><td>14</td></tr>
-<tr><td>15</td><td>16</td><td>17</td><td>18</td><td>19</td><td>20</td><td>21</td></tr>
-<tr><td>22</td><td>23</td><td>24</td><td>25</td><td>26</td><td>27</td><td>28</td></tr>
-<tr><td>29</td><td>30</td><td>31</td><td> </td><td> </td><td> </td><td> </td></tr>
-</tbody>
-</table> </div>
-
- <div id="search">
- <form action="http://www.aubryconseil.com/dotclear/index.php/" method="get">
-
- <h2><label for="q">Rechercher</label></h2>
- <p class="field"><input name="q" id="q" size="10" value="" accesskey="4" type="text">
- <input class="submit" value="ok" type="submit"></p>
-
- </form>
- </div>
-
- <div id="selection"><h2>À retenir</h2><ul><li><a indepth="true" href="148-le-role-de-scrummaster.html">Le rôle de ScrumMaster</a></li><li><a indepth="true" href="132-le-role-de-directeur-de-produit.html">Le rôle de directeur de produit</a></li><li><a indepth="true" href="125-scrum-en-bref.html">Scrum en bref</a></li><li><a indepth="true" href="115-backlog-priorise.html">Backlog : critères pour établir les priorités</a></li><li><a indepth="true" href="99-discipline-et-agilite.html">Discipline et agilité</a></li><li><a indepth="true" href="87-duree-fixe-des-iterations.html">Durée fixe des itérations</a></li><li><a indepth="true" href="67-la-minute-ideale-du-randonneur.html">La minute idéale du randonneur</a></li><li><a indepth="true" href="58-agilite-pour-un-contrat-au-forfait.html">Agilité pour un contrat au forfait</a></li><li><a indepth="true" href="36-avant-la-premiere-iteration.html">Avant la première itération</a></li><li><a indepth="true" href="29-duree-d-une-iteration.html">Durée d'une itération</a></li></ul></div>
-
- <div id="toclink">
-<h2><a indepth="true" href="toc.html">Table des matières</a></h2>
-</div>
-
-
-
- <div id="archives">
- <h2>Archives</h2>
- <ul><li><strong><a indepth="true" href="01_001.html">janvier 2007</a></strong></li><li><a indepth="true" href="12.html">décembre 2006</a></li><li><a indepth="true" href="11.html">novembre 2006</a></li><li><a indepth="true" href="10.html">octobre 2006</a></li><li><a indepth="true" href="09.html">septembre 2006</a></li><li><a indepth="true" href="08.html">août 2006</a></li><li><a indepth="true" href="07_001.html">juillet 2006</a></li><li><a indepth="true" href="06.html">juin 2006</a></li><li><a indepth="true" href="05_001.html">mai 2006</a></li><li><a indepth="true" href="04_001.html">avril 2006</a></li></ul> </div>
-
- <div id="links">
- <h2>Blogs lus régulièrement</h2>
- <h3>Agile</h3><ul><li><a href="http://agilitateur.azeau.com/" hreflang="fr">L'Agilitateur</a></li><li><a href="http://kanemar.wordpress.com/" hreflang="EN">Kane Mar</a></li><li><a href="http://silkandspinach.net/" hreflang="EN">Silk and Spinach</a></li><li><a href="http://www.testing.com/cgi-bin/blog" hreflang="en">Exploration Through Example</a></li><li><a href="http://www.agileadvice.com/" hreflang="EN">Agile Advice</a></li><li><a href="http://theagileblog.net/" hreflang="en">On Be(come)ing Agile</a></li><li><a href="http://bossavit.com/thoughts/" hreflang="EN" rel="co-worker">Laurent Bossavit</a></li><li><a href="http://prog13.free.fr/" hreflang="fr">Avangel</a></li><li><a href="http://tcros.blogspot.com/" hreflang="fr">Thierry Cros</a></li></ul><h3>Techno</h3><ul><li><a href="http://www.dotnetguru2.org/proques/" hreflang="fr" title="Le blog de Pascal Roques">UML Guru</a></li><li><a href="http://www.inherence.fr/dotclear/" hreflang="fr">Parlons ISO 20000</a></li><li><a href="http://nauges.typepad.com/my_weblog/" hreflang="fr">Louis Naugès</a></li><li><a href="http://standblog.org/blog/" hreflang="fr">StandBlog</a></li></ul> </div>
-
- <div id="categories">
- <h2>Catégories</h2>
- <ul><li><a indepth="true" href="mes-projets.html">Mes projets</a></li><li><a indepth="true" href="evenements.html">Mes événements</a></li><li><a indepth="true" href="mes-conseils.html">Mes conseils</a></li><li><a indepth="true" href="mes-cours.html">Mes cours</a></li><li><a indepth="true" href="l-agilite-en-france.html">L'agilité en France</a></li><li><a indepth="true" href="l-agilite-dans-le-monde.html">L'agilité dans le monde</a></li><li><a indepth="true" href="l-agilite-en-dehors-du-logiciel.html">L'agilité en dehors du logiciel</a></li><li><a indepth="true" href="mon-butinage.html">Mon butinage</a></li><li><a indepth="true" href="mon-blog.html">Mon blog</a></li></ul> </div>
-
-
-
-
-</div><p id="footer">Le blog de Claude Aubry est <a href="http://www.dotclear.net/">
-propulsé par DotClear</a></p>
-
-</div>
-<!-- end #page -->
-
-<!-- Blocs en plus pour ajouter des images en tout genre si besoin -->
-<div id="block1"><span></span></div><div id="block2"><span></span></div>
-<div id="block3"><span></span></div><div id="block4"><span></span></div>
-<div id="block5"><span></span></div><div id="block6"><span></span></div>
-
-
-
-</body></html>
diff --git a/Scrum French/Scrum/rolesets/Scrum Roles.xmi b/Scrum French/Scrum/rolesets/Scrum Roles.xmi
deleted file mode 100644
index 8542e8b..0000000
--- a/Scrum French/Scrum/rolesets/Scrum Roles.xmi
+++ /dev/null
@@ -1,13 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-CgLjZ6Bwc0EyYyQCjzlw7g" name="new_role_set,_3qmmoP-zEdqLnajTSLeAsA" guid="-CgLjZ6Bwc0EyYyQCjzlw7g" changeDate="2006-12-03T08:51:09.000+0100">
- <mainDescription><p>
- Scrum définit uniquement 3 rôles pour les personnes qui participent aux travaux de développement. A la différence
- d’autres processus, il n’existe pas d’architecte, de programmeur, de testeur, d’analyste, de rédacteur. L’équipe
- regroupe les compétences sans distinction du rôle de chacun a priori.
-</p>
-<p>
- Toutes les personnes ayant une influence sur&nbsp;le projet sans y participer directement sont représentées par le rôle
- <a class="elementLink" href="./../../Scrum/roles/StakeHolder,_Qqmp8P_AEdqtbrr0B1TG-A.html"
- guid="_Qqmp8P_AEdqtbrr0B1TG-A">Intervenant</a>.
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum French/Scrum/scrum.jpg b/Scrum French/Scrum/scrum.jpg
deleted file mode 100644
index 5fe67e3..0000000
--- a/Scrum French/Scrum/scrum.jpg
+++ /dev/null
Binary files differ
diff --git a/Scrum French/Scrum/tasks/Initiate Product Backlog.xmi b/Scrum French/Scrum/tasks/Initiate Product Backlog.xmi
deleted file mode 100644
index 3563196..0000000
--- a/Scrum French/Scrum/tasks/Initiate Product Backlog.xmi
+++ /dev/null
@@ -1,45 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-mi1O4H7RRm0YqlUNyp8TJg" name="Initiate Product Backlog,_BGFMoANkEduYd-55D-Aiqg" guid="-mi1O4H7RRm0YqlUNyp8TJg" authors="Claude Aubry" changeDate="2006-12-03T09:00:53.343+0100" version="1.0.0">
- <keyConsiderations><p>
- Le backlog initial doit permettre de planifier au moins les 2 ou 3 premiers sprints.
-</p></keyConsiderations>
- <sections xmi:id="_pWL_gAPJEdubhrgDuRb4fA" name="Collecter les éléments du backlog" guid="_pWL_gAPJEdubhrgDuRb4fA">
- <sectionDescription><p>
- Le <a class="elementLink" href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html"
- guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur Produit</a>&nbsp;établit une première liste des exigences (une
- exigence&nbsp;devient un&nbsp;<a class="elementLink"
- href="./../../Scrum/workproducts/Product Backlog Item,_-D85cIGIEduKE9hnyImx1Q.html"
- guid="_-D85cIGIEduKE9hnyImx1Q">Elément de backlog de produit</a>)&nbsp;qu'il souhaite voir réalisées pour la fin de la
- release.
-</p>
-<p>
- Pour compléter cette liste et obtenir un backlog suffisant, il est conseillé d'organiser un workshop réunissant toute
- l'équipe plus des intervenants. Au cours de ce workshop, le <a class="elementLink"
- href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html" guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur
- Produit</a>&nbsp;présente son ébauche de backlog et chacun intervient pour proposer de nouveaux items.
-</p>
-<p>
- Il est fréquent qu'un élément du backlog soit identifié&nbsp;comme une histoire d'utilisateur (User story), technique
- utilisée à l'origine dans EXtreme Programming (XP) et qui s'adapte très bien&nbsp;à Scrum.
-</p>
-<br /></sectionDescription>
- </sections>
- <sections xmi:id="_u0Z7sAPJEdubhrgDuRb4fA" name="Ordonner le backlog" guid="_u0Z7sAPJEdubhrgDuRb4fA">
- <sectionDescription><p>
- Le <a class="elementLink" href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html"
- guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur Produit</a>&nbsp;ordonne les éléments du backlog selon une priorité
- décroissante. Pour lui, A plus prioritaire que B signifie qu'il souhaite disposer, dans un produit partiel, de l'item A
- avant l'item B.
-</p>
-<p>
- Lorsque le backlog contient beaucoup d'éléments, le classement par priorité de chacun est fastidieux et délicat. C'est
- pourquoi il est utile de définir des <a class="elementLink"
- href="./../../Scrum/guidances/termdefinitions/Theme,_aeYKoIKlEduQgtHqedKdMA.html"
- guid="_aeYKoIKlEduQgtHqedKdMA">Thème</a>s, d'associer à&nbsp;chaque élément un thème et de définir les&nbsp;priorités
- sur les thèmes avant de passer aux éléments. Cela peut être fait lors d'une réunion à laquelle participent les <a
- class="elementLink" href="./../../Scrum/roles/StakeHolder,_Qqmp8P_AEdqtbrr0B1TG-A.html"
- guid="_Qqmp8P_AEdqtbrr0B1TG-A">Intervenant</a>s, ainsi que des membres de l'équipe.
-</p></sectionDescription>
- </sections>
- <purpose>Le but est de produire un backlog au moins suffisant pour permettre le démarrage de la série des sprints.</purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum French/Scrum/tasks/Manage problems.xmi b/Scrum French/Scrum/tasks/Manage problems.xmi
deleted file mode 100644
index 3cbc0ce..0000000
--- a/Scrum French/Scrum/tasks/Manage problems.xmi
+++ /dev/null
@@ -1,40 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-mZfAV7RcWJlp5idlHzeEcA" name="Manage problems,_Xpd5gP_AEdqtbrr0B1TG-A" guid="-mZfAV7RcWJlp5idlHzeEcA" changeDate="2006-12-03T10:05:51.734+0100" version="1.0.0">
- <keyConsiderations><p>
- Cette tâche est centrée sur la résolution de ces problèmes.
-</p></keyConsiderations>
- <sections xmi:id="_LCxqQAB6EduSVaTQTBfIHA" name="Prendre connaissance du problème" guid="_LCxqQAB6EduSVaTQTBfIHA">
- <sectionDescription><p>
- La réunion quotidienne est l'endroit idéal pour déceler les problèmes qu'une équipe rencontre. Elle peut même permettre
- de les résoudre immédiatement grâce à la collaboration de l'équipe. Cependant :
-</p>
-<ul>
- <li>
- il arrive que des problèmes urgents soient soulevés entre 2 réunions quotidiennes
- </li>
- <li>
- et surtout la résolution des problèmes n'est pas faite en réunion (sauf si elle évidente)
- </li>
-</ul>
-<p>
- Suite à la mise en évidence d'un problème, par exemple lors de la réunion quotidienne,&nbsp;identifier la cause du
- problème et les impacts sur le projet. Pour cela une communication orale, à l'initiative&nbsp;du&nbsp;<a
- class="elementLink" href="./../../Scrum/roles/ScrumMaster,_t1K9kPpYEdqsc-f87sBK8A.html"
- guid="_t1K9kPpYEdqsc-f87sBK8A">ScrumMaster</a>,&nbsp;avec la personne qui a soulevé le problème est souhaitable.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_PIKyUAB6EduSVaTQTBfIHA" name="Décider d'un plan d'action" guid="_PIKyUAB6EduSVaTQTBfIHA">
- <sectionDescription><p>
- Identifier les solutions possibles.<br />
- Une réunion avec le responsable hiérarchique est organisée si des problèmes survenant sur le projet ne peuvent pas
- être réglés simplement ou sont à un niveau au-dessus de son autorité.
-</p>
-<p>
- Le <a class="elementLink" href="./../../Scrum/roles/ScrumMaster,_t1K9kPpYEdqsc-f87sBK8A.html"
- guid="_t1K9kPpYEdqsc-f87sBK8A">ScrumMaster</a>&nbsp;doit s'efforcer de résoudre le problème au plus tôt, pour ne pas
- perturber l'avancement de l'équipe.
-</p></sectionDescription>
- </sections>
- <purpose>Le but est de d'éliminer les problèmes rencontrés par l'équipe pour qu'elle puisse se concentrer sur ses véritables
-objectifs.</purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum French/Scrum/tasks/Plan release.xmi b/Scrum French/Scrum/tasks/Plan release.xmi
deleted file mode 100644
index 6c78f3b..0000000
--- a/Scrum French/Scrum/tasks/Plan release.xmi
+++ /dev/null
@@ -1,90 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-3f4axrWBKHGv74oKN2x-gQ" name="Plan release,_ho-aIP_BEdqtbrr0B1TG-A" guid="-3f4axrWBKHGv74oKN2x-gQ" changeDate="2006-12-03T09:23:18.328+0100" version="1.0.0">
- <keyConsiderations>Il s'agit d'un travail collectif à l'initiative du directeur de produit.</keyConsiderations>
- <sections xmi:id="_8qN08APJEdubhrgDuRb4fA" name="Définir les conditions de succès de la release" guid="_8qN08APJEdubhrgDuRb4fA">
- <sectionDescription><p>
- Il existe 2 types de releases&nbsp; :
-</p>
-<ul>
- <li>
- une release dirigée par la date de fin. L'objectif est de mettre en production ou à disposition des utilisateurs à
- une date fixée.
- </li>
- <li>
- une release dirigée par les fonctionnalités. La liste des exigences est connue et la release prendra fin lorsque
- toutes les exigences seront réalisées.
- </li>
-</ul>
-<p>
- Les conditions de succès sont définies en fonction de ce type de release.
-</p>
-<br /></sectionDescription>
- </sections>
- <sections xmi:id="_BuXEQAPKEdubhrgDuRb4fA" name="Estimer les éléments du backlog" guid="_BuXEQAPKEdubhrgDuRb4fA">
- <sectionDescription><p>
- L'estimation est faite pour chaque éléments. Il est préférable de travailler en premier sur les plus prioritaires.
-</p>
-<p>
- L'estimation est réalisée en équipe.
-</p>
-<p>
- La grandeur utilisée pour les estimations est de préférence le point, sans unités. Pour les valeurs utilisées pour les
- estimations, on utilise souvent la suite de Fibonacci (1, 2, 3, 5, 8 et 13).
-</p>
-<p>
- Les techniques d'estimation sont, de préférence, basées sur une approche collective de l'estimation. Il est conseillé
- de pratiquer le "planning poker" et de travailler par analogie en comparant les éléments estimés.&nbsp;
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_EaLKQAPKEdubhrgDuRb4fA" name="Définir la durée des sprints" guid="_EaLKQAPKEdubhrgDuRb4fA">
- <sectionDescription><p>
- Historiquement dans Scrum, la durée d'un sprint est de 30 jours. Cependant il est possible et même recommandé de faire
- des sprints plus courts. La durée dépend du projet et des contraintes qui s'y appliquent.<br />
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_HDZ2UAPKEdubhrgDuRb4fA" name="Estimer la vélocité" guid="_HDZ2UAPKEdubhrgDuRb4fA">
- <sectionDescription><p>
- L'idéal est que l'équipe ait déjà travaillé ensemble sur un projet afin qu'on ait pu mesurer sa <a class="elementLink"
- href="./../../Scrum/guidances/termdefinitions/Velocity,_HQEP8ILXEduLd8CaF_IcMA.html"
- guid="_HQEP8ILXEduLd8CaF_IcMA">Vélocité</a>&nbsp;réelle. Elle sera alors utilisée pour cette release, éventuellement
- ajustée compte tenu de la nature du projet. Attention cependant un point n'a pas forcément la même valeur dans des
- projets différents.
-</p>
-<p>
- Si ce n'est pas le cas, il faut faire une estimation de la vélocité. Le mieux est de travailler sur le contenu du
- premier sprint de la release et de voir ce que l'équipe pense pouvoir réaliser pendant ce premier sprint. Cela donne
- une vélocité estimée qui peut être utilisée pour la planification de la release. Ensuite la planification sera basée
- sur la vélocité mesurée dans les sprints précédents.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_I71XkAPKEdubhrgDuRb4fA" name="Associer les éléments du backlog aux sprints" guid="_I71XkAPKEdubhrgDuRb4fA">
- <sectionDescription><p>
- En fonction des paramètres suivants :
-</p>
-<ul>
- <li>
- les estimations de chaque item,
- </li>
- <li>
- l'ordre dans lesquels les items sont classés (la priorité),
- </li>
- <li>
- la vélocité estimée pour la release,
- </li>
-</ul>
-<p>
- on affecte les items aux sprints de la release.
-</p>
-<p>
- Il est normal d'ajuster, c'est à dire de changer légèrement l'ordre des items, ne serait-ce que pour se rapprocher le
- plus possible de la vélocité (en effet on ne tombe pas toujours "rond").
-</p>
-<p>
- Il faut associer des items aux premiers sprints (les 2 ou 3 premiers), mais il n'est pas indispensable de le faire pour
- tous les sprints de la release.
-</p></sectionDescription>
- </sections>
- <purpose><p>
- Elaborer la planification initiale de la release permettant de lancer la série de sprints.
-</p></purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum French/Scrum/tasks/Plan sprint 2.xmi b/Scrum French/Scrum/tasks/Plan sprint 2.xmi
deleted file mode 100644
index f745cf2..0000000
--- a/Scrum French/Scrum/tasks/Plan sprint 2.xmi
+++ /dev/null
@@ -1,105 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-NRwwk6YGAtu25V3Lc04G6w" name="Plan sprint,_4LOggPpaEdqsc-f87sBK8A" guid="-NRwwk6YGAtu25V3Lc04G6w" authors="Claude Aubry" changeDate="2006-12-03T09:57:11.890+0100" version="1.0.0">
- <keyConsiderations><p>
- La réunion de planification de sprint est un travail réalisé en groupe.
-</p>
-<p>
- Elle est limitée dans le temps :
-</p>
-<ul>
- <li>
- durée max : limitée à 4 heures
- </li>
- <li>
- durée moyenne : 2 heures
- </li>
-</ul></keyConsiderations>
- <sections xmi:id="_TJNsUP--Edqtbrr0B1TG-A" name="Définir le but du sprint" guid="_TJNsUP--Edqtbrr0B1TG-A">
- <sectionDescription><p>
- Au début lors des premiers sprints de la première release d'un produit, le but est bien souvent de montrer la
- faisabilité de l'architecture envisagée.
-</p>
-<p>
- Ensuite, une fois que l'architecture est stabilisée, le but d'un sprint est proposé par le <a class="elementLink"
- href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html" guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur
- Produit</a> et discuté avec l'équipe. Il porte souvent sur un thème fonctionnel.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_xvy5UAPKEdubhrgDuRb4fA" name="Sélectionner les items" guid="_xvy5UAPKEdubhrgDuRb4fA">
- <sectionDescription><p>
- Il s'agit de définir le périmètre de ce sprint. Cela est fait en associant un <a class="elementLink"
- href="./../../Scrum/workproducts/Product Backlog Item,_-D85cIGIEduKE9hnyImx1Q.html"
- guid="_-D85cIGIEduKE9hnyImx1Q">Elément de backlog de produit</a>&nbsp;au sprint puis un autre en tenant compte de la
- vélocité de l'équipe.
-</p>
-<p>
- Si un <a class="elementLink" href="./../../Scrum/guidances/reports/Release Planning,_Z2NzkIGWEduKE9hnyImx1Q.html"
- guid="_Z2NzkIGWEduKE9hnyImx1Q">Planning de la release</a>&nbsp;a été effectué, cette étape consiste seulement à valider
- collectivement le sous-ensemble du backlog prévu pour ce sprint.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_p4C0sP--Edqtbrr0B1TG-A" name="Identifier les tâches à partir des items" guid="_p4C0sP--Edqtbrr0B1TG-A">
- <sectionDescription><p>
- La 2ème partie de la réunion a pour objectif de définir comment l’équipe va s’arranger pour réaliser le résultat
- attendu du sprint.<br />
- Pour cela, chaque <a class="elementLink"
- href="./../../Scrum/workproducts/Product Backlog Item,_-D85cIGIEduKE9hnyImx1Q.html"
- guid="_-D85cIGIEduKE9hnyImx1Q">Elément de backlog de produit</a>&nbsp;sélectionné est décomposé en tâches. Cela permet
- à toute l’équipe de discuter et d’éclaircir des points de solution par rapport à cet item, en demandant si nécessaire
- au propriétaire de produit des précisions sur le comportement du produit.<br />
-</p>
-<p>
- Normalement l'ensemble des activités du cycle de vie sont déroulées lors d'un sprint :<br />
-</p>
-<ul>
- <li>
- Les exigences sélectionnées sont spécifiées
- </li>
- <li>
- L'architecture est remaniée si nécessaire
- </li>
- <li>
- Les classes et sous-systèmes sont conçus, implémentés et testés
- </li>
- <li>
- Les différents composants sont intégrés et testés
- </li>
- <li>
- Le produit est packagé&nbsp;
- </li>
- <li>
- Les tests d'acceptation sont passés.<br />
- </li>
-</ul>
-<p>
- L'importance donnée à ces activités dépend de la place du sprint dans la release.<br />
- <br />
- Le travail prévu dans un sprint précédent mais qui n'a pu être réalisé à cause de la réduction des objectifs devient
- prioritaire pour le sprint suivant.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_DxNQUAPLEdubhrgDuRb4fA" name="Estimer les tâches" guid="_DxNQUAPLEdubhrgDuRb4fA">
- <sectionDescription><p>
- Les taches sont estimées en heures. Il est conseillé d'avoir des tâches suffisamment fines pour qu'une estimation reste
- inférieure à 16 heures.
-</p>
-<p>
- L'estimation est faite collectivement, par l'équipe. Au cours de la discussion pour arriver à une estimation, les
- aspects techniques sont abordés.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_worbAP--Edqtbrr0B1TG-A" name="Attribuer les tâches" guid="_worbAP--Edqtbrr0B1TG-A">
- <sectionDescription>Une fois que les activités du sprint ont été définies, elles seront affectées aux membres de l'équipe. Les activités
-peuvent être réalisées par une ou plusieurs personnes. Toutes les activités doivent être prises en compte, y compris les
-réunions de travail (hors réunions Scrum), les lectures de documents ou de code.<br />
-Il est préférable de différer l'affectation de certaines activités, qui seront prises pendant le sprint en fonction des
-disponibilités des membres de l'équipe.</sectionDescription>
- </sections>
- <sections xmi:id="_Iq14wAPLEdubhrgDuRb4fA" name="Obtenir l'engagement de l'équipe" guid="_Iq14wAPLEdubhrgDuRb4fA">
- <sectionDescription><p>
- Il est souhaitable que l'équipe s'engage collectivement sur le backlog du sprint, c'est à dire sur les éléments du
- backlog qu'elle estime pouvoir réaliser dans le sprint.
-</p></sectionDescription>
- </sections>
- <purpose>Le but est de planifier&nbsp;le sprint&nbsp;qui commence.</purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum French/Scrum/tasks/Retrospective.xmi b/Scrum French/Scrum/tasks/Retrospective.xmi
deleted file mode 100644
index 243a584..0000000
--- a/Scrum French/Scrum/tasks/Retrospective.xmi
+++ /dev/null
@@ -1,28 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-S4qXwp40l_8eCcyyI7o-3A" name="Retrospective,_J_sRIP_AEdqtbrr0B1TG-A" guid="-S4qXwp40l_8eCcyyI7o-3A" changeDate="2006-12-03T10:01:12.593+0100" version="1.0.0">
- <keyConsiderations><p>
- Chaque membre de l’équipe est invité à s’exprimer sur ce qui s’est bien et mal passé.
-</p>
-<ul>
- <li>
- durée max : 2 heures
- </li>
- <li>
- durée moyenne : 1 heure
- </li>
-</ul></keyConsiderations>
- <sections xmi:id="_lwzeABGPEduHloEV5-Zv-w" name="Discussion" guid="_lwzeABGPEduHloEV5-Zv-w">
- <sectionDescription>Chaque membre de l’équipe est invité à s’exprimer sur ce qui s’est bien et mal passé dans l'application de Scrum sur le
-projet.</sectionDescription>
- </sections>
- <sections xmi:id="_noL2YBGPEduHloEV5-Zv-w" name="Définir le plan d'actions" guid="_noL2YBGPEduHloEV5-Zv-w">
- <sectionDescription><p>
- L’équipe discute des améliorations possibles et leur donne une priorité.
-</p>
-<p>
- Le&nbsp;<a class="elementLink" href="./../../Scrum/roles/ScrumMaster,_t1K9kPpYEdqsc-f87sBK8A.html"
- guid="_t1K9kPpYEdqsc-f87sBK8A">ScrumMaster</a> ajoute les actions d’amélioration dans le backlog.
-</p></sectionDescription>
- </sections>
- <purpose>L’objectif est d'améliorer continuellement le processus.</purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum French/Scrum/tasks/Review sprint.xmi b/Scrum French/Scrum/tasks/Review sprint.xmi
deleted file mode 100644
index a63b191..0000000
--- a/Scrum French/Scrum/tasks/Review sprint.xmi
+++ /dev/null
@@ -1,66 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-zoJryMCuHfxWP7Q5Er195Q" name="Review sprint,_MRrRYPpbEdqsc-f87sBK8A" guid="-zoJryMCuHfxWP7Q5Er195Q" changeDate="2006-12-03T09:52:13.953+0100" version="1.0.0">
- <keyConsiderations><p>
- Travail en groupe (lors de la réunion dite de revue de sprint)
-</p>
-<p>
- Pour la réunion :
-</p>
-<ul class="noindent">
- <li>
- durée max : &nbsp;2 heures
- </li>
- <li>
- durée moyenne : 1 heure
- </li>
-</ul></keyConsiderations>
- <sections xmi:id="_XL6VgAPLEdubhrgDuRb4fA" name="Préparer la démonstration" guid="_XL6VgAPLEdubhrgDuRb4fA">
- <sectionDescription>La préparation de la réunion ne doit pas excéder une heure.<br /></sectionDescription>
- </sections>
- <sections xmi:id="_ZgJB8APLEdubhrgDuRb4fA" name="Effectuer la démonstration" guid="_ZgJB8APLEdubhrgDuRb4fA">
- <sectionDescription>L’équipe présente le produit partiel résultat de ses travaux, sous forme de démonstration des exigences (histoires
-d'utilisateur) réalisées. Seules les exigences complètement finies (et testées) sont présentées. Cela permet d’avoir une
-mesure objective de l’avancement. <br /></sectionDescription>
- </sections>
- <sections xmi:id="_cBouUAPLEdubhrgDuRb4fA" name="Evaluer les résultats du sprint" guid="_cBouUAPLEdubhrgDuRb4fA">
- <sectionDescription><p>
- Le&nbsp;<a class="elementLink" href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html"
- guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur Produit</a> et les intervenants présents (clients, utilisateurs) posent des
- questions à l’équipe, donnent leur impression, font des propositions et des demandes de changement. Le <a
- class="elementLink" href="./../../Scrum/workproducts/Product Backlog,_5ABscPpYEdqsc-f87sBK8A.html"
- guid="_5ABscPpYEdqsc-f87sBK8A">Backlog de produit</a>&nbsp;est enrichi avec les bugs découverts et les demandes
- d’évolution.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_hrswoHoYEduJVrY6eKG_mw" name="Calculer la vélocité réelle" guid="_hrswoHoYEduJVrY6eKG_mw">
- <sectionDescription><p>
- La <a class="elementLink" href="./../../Scrum/guidances/termdefinitions/Velocity,_HQEP8ILXEduLd8CaF_IcMA.html"
- guid="_HQEP8ILXEduLd8CaF_IcMA">Vélocité</a>&nbsp;du sprint&nbsp;est obtenue en faisant la somme de tous les points
- associés aux exigences considérées comme effectivement finies. Elle est comparée à celle des sprints précédents, le
- plus souvent à travers un <a class="elementLink"
- href="./../../Scrum/guidances/reports/Release Burndown Chart,_vKqe8PpaEdqsc-f87sBK8A.html"
- guid="_vKqe8PpaEdqsc-f87sBK8A">Release Burndown Chart</a>.&nbsp;&nbsp;
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_d776UHoYEduJVrY6eKG_mw" name="Ajuster le plan de la release" guid="_d776UHoYEduJVrY6eKG_mw">
- <sectionDescription><p>
- Les conditions ont pu changer depuis la dernière planification de la release :
-</p>
-<ul>
- <li>
- des items ont pu être ajoutés ou suppirmés, les estimations modifiées,&nbsp;
- </li>
- <li>
- l'ordre dans lesquels les items sont classés (la priorité) a pu être modifié,
- </li>
-</ul>
-<p>
- De plus la vélocité&nbsp;moyenne a pu évoluer avec la prise de la vélocité calculée du sprint.&nbsp;
-</p>
-<p>
- Le <a class="elementLink" href="./../../Scrum/guidances/reports/Release Planning,_Z2NzkIGWEduKE9hnyImx1Q.html"
- guid="_Z2NzkIGWEduKE9hnyImx1Q">Planning de la release</a> est ajusté en tenant compte de ces nouveaux paramètres.
-</p></sectionDescription>
- </sections>
- <purpose>&nbsp;Le but est de montrer les exigences réalisées pendant le sprint par une démonstration du produit partiel</purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum French/Scrum/tasks/Scrum daily meeting.xmi b/Scrum French/Scrum/tasks/Scrum daily meeting.xmi
deleted file mode 100644
index f9cd5b0..0000000
--- a/Scrum French/Scrum/tasks/Scrum daily meeting.xmi
+++ /dev/null
@@ -1,56 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-vDOuVl_xPKipKd90HQNZng" name="Scrum daily meeting,_d09LYP_AEdqtbrr0B1TG-A" guid="-vDOuVl_xPKipKd90HQNZng" changeDate="2006-12-03T10:07:26.890+0100" version="1.0.0">
- <keyConsiderations><p>
- Se déroule tous les jours, avec toute l'équipe, de préférence le matin en arrivant : il est souhaitable que la réunion
- ait lieu tous les jours au même endroit et à la même heure.
-</p>
-<p>
- La réunion est limitée à 15 minutes.&nbsp;<br />
- L’objectif est d’examiner l’avancement des travaux et d'identifier les problèmes potentiels, mais pas de résoudre les
- problèmes
-</p></keyConsiderations>
- <sections xmi:id="_oUrlcBGOEduHloEV5-Zv-w" name="Préparer" guid="_oUrlcBGOEduHloEV5-Zv-w">
- <sectionDescription>Chacun met à jour le planning ( le backlog se sprint) en actualisant le reste à faire sur ses tâches, ce qui permet de
-produire un <a class="elementLink"
-href="./../../Scrum/guidances/reports/Sprint Burndown Chart,_jC4NwPpaEdqsc-f87sBK8A.html"
-guid="_jC4NwPpaEdqsc-f87sBK8A">Sprint Burndown Chart</a>.</sectionDescription>
- </sections>
- <sections xmi:id="_r0KkEBGOEduHloEV5-Zv-w" name="Se réunir" guid="_r0KkEBGOEduHloEV5-Zv-w">
- <sectionDescription><p>
- Chaque membre de l’équipe s’exprime tour à tour, en répondant à 3 questions sur :
-</p>
-<ol>
- <li>
- Ce qui a été fait depuis la mêlée précédente (en principe la veille)
- </li>
- <li>
- Ce qui va être fait aujourd’hui
- </li>
- <li>
- Les problèmes rencontrés&nbsp;
- </li>
-</ol>
-<p>
- Il est souhaitable que la réunion s'effectue avec tous les personnes de l'équipe debout en cercle et en ayant sous les
- yeux le <a class="elementLink" href="./../../Scrum/workproducts/Sprint backlog,_Dzw70PpZEdqsc-f87sBK8A.html"
- guid="_Dzw70PpZEdqsc-f87sBK8A">Backlog du sprint</a>&nbsp;et le <a class="elementLink"
- href="./../../Scrum/guidances/reports/Sprint Burndown Chart,_jC4NwPpaEdqsc-f87sBK8A.html"
- guid="_jC4NwPpaEdqsc-f87sBK8A">Sprint Burndown Chart</a>&nbsp;actualisés.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_vZkkgBGOEduHloEV5-Zv-w" name="Consolider" guid="_vZkkgBGOEduHloEV5-Zv-w">
- <sectionDescription>Le&nbsp;<a class="elementLink" href="./../../Scrum/workproducts/Sprint backlog,_Dzw70PpZEdqsc-f87sBK8A.html"
-guid="_Dzw70PpZEdqsc-f87sBK8A">Backlog du sprint</a>&nbsp;remis à jour sert à prendre une décision sur l'ajustement du but
-du sprint. Il faut avoir à l'esprit qu'un sprint est limité dans le temps (bloc de temps) et qu'il est préférable de
-supprimer du contenu prévu initialement plutôt que d'avoir du retard. <br />
-Les problèmes soulevés sont résolus&nbsp;lors de&nbsp;<a class="elementLink"
-href="./../../Scrum/tasks/Manage problems,_Xpd5gP_AEdqtbrr0B1TG-A.html" guid="_Xpd5gP_AEdqtbrr0B1TG-A">Gérer les
-problèmes</a>&nbsp;à l'initiative du <a class="elementLink"
-href="./../../Scrum/roles/ScrumMaster,_t1K9kPpYEdqsc-f87sBK8A.html" guid="_t1K9kPpYEdqsc-f87sBK8A">ScrumMaster</a>.</sectionDescription>
- </sections>
- <purpose>Le but est de faire le point sur l'avancement de l'équipe et d'identifier les problèmes. L’objectif est uniquement
-d’examiner l’avancement des travaux, pas de résoudre les problèmes.</purpose>
- <alternatives><p>
- Appelé aussi Stand-Up Meeting (XP)
-</p></alternatives>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum French/Scrum/tasks/Update product backlog.xmi b/Scrum French/Scrum/tasks/Update product backlog.xmi
deleted file mode 100644
index af19cc7..0000000
--- a/Scrum French/Scrum/tasks/Update product backlog.xmi
+++ /dev/null
@@ -1,38 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-XdgedeazfFRGDxMY3Fnh5g" name="Manage product backlog,_STkWYP_BEdqtbrr0B1TG-A" guid="-XdgedeazfFRGDxMY3Fnh5g" changeDate="2006-12-03T09:12:31.968+0100" version="1.0.0">
- <keyConsiderations><p>
- Pendant le sprint, personne ne peut modifier la sélection des items du backlog effectuée au début du sprint : le
- périmètre du sprint reste inchangé.
-</p>
-<p>
- En revanche, n’importe qui, même un intervenant extérieur, peut proposer de nouveaux items pour plus tard. Ces items
- sont étudiés et ordonnés par le propriétaire du produit en vue de la planification du prochain sprint.<br />
- Les bugs et les demandes d’évolution issus des essais du produit partiel obtenu à la fin du sprint précédent viennent
- également enrichir le backlog.
-</p></keyConsiderations>
- <sections xmi:id="_c3HaQAPKEdubhrgDuRb4fA" name="Collecter les changements" guid="_c3HaQAPKEdubhrgDuRb4fA">
- <sectionDescription><p>
- N’importe qui, même un intervenant extérieur, peut proposer des changements à ajouter au backlog.<br />
- Les bugs et les demandes d’évolution issus des essais du produit partiel obtenu à la fin du sprint précédent viennent
- également enrichir le backlog.
-</p>
-<p>
- Ces éléments sont analysés par le propriétaire du produit en vue de la planification du prochain sprint.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_fkXDoAPKEdubhrgDuRb4fA" name="Réordonner les items" guid="_fkXDoAPKEdubhrgDuRb4fA">
- <sectionDescription>Les éléments ajoutés depuis le sprint précédent sont ordonnés dans le backlog par le&nbsp;<a class="elementLink"
-href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html" guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur Produit</a>
-en vue de la planification à venir.</sectionDescription>
- </sections>
- <sections xmi:id="_k-kCgAPKEdubhrgDuRb4fA" name="Réestimer les items" guid="_k-kCgAPKEdubhrgDuRb4fA">
- <sectionDescription><p>
- L'estimation en points des nouveaux éléments introduits dans le backlog est faite par l'équipe, de préférence lors d'un
- travail de groupe avec le Directeur de prouit, un ou 2 jours avant la revue de fin de sprint.
-</p>
-<p>
- Des items déjà présents peuvent également être réestimés.
-</p></sectionDescription>
- </sections>
- <purpose>Actualiser le backlog et ajuster la planification en tenant compte des changements apparus depuis le dernier sprint.</purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/Scrum French/Scrum/workproducts/Product Backlog Item.xmi b/Scrum French/Scrum/workproducts/Product Backlog Item.xmi
deleted file mode 100644
index adf4810..0000000
--- a/Scrum French/Scrum/workproducts/Product Backlog Item.xmi
+++ /dev/null
@@ -1,56 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-KC1R73i9f6P7ZT4pgBOLzA" name="new_artifact,_-D85cIGIEduKE9hnyImx1Q" guid="-KC1R73i9f6P7ZT4pgBOLzA" changeDate="2006-12-01T23:15:03.002+0100">
- <mainDescription>C'est une exigence fonctionnelle ou non fonctionnelle (technique), une demande d'évolution, un bug ou tout autre
-chose&nbsp;dont la réalisation apporte de la valeur au <a class="elementLink"
-href="./../../Scrum/roles/Product Owner,_ICJyYPpaEdqsc-f87sBK8A.html" guid="_ICJyYPpaEdqsc-f87sBK8A">Directeur
-Produit</a>.&nbsp;
-<p>
- Il possède des attributs qui sont généralement :
-</p>
-<ul>
- <li>
- une estimation de sa valeur qui est le plus souvent montrée de façon relative aux autres éléments par la notion de
- priorité,
- </li>
- <li>
- une estimation de son coût de développement,
- </li>
- <li>
- éventuellement le thème (domaine fonctionnel) dont il fait partie,
- </li>
- <li>
- éventuellement son type (défini en fonction du projet, par exemple histoire d'utilisateur, bug, exigence non
- fonctionnelle),
- </li>
-</ul>
-<p>
- Si on utilise la technique des histoires d'utilisateur (user stories) et le développement dirigé par les tests (TDD),
- on associe les critères servant aux tests d'acceptation de cet élément.
-</p>
-<p>
- La vie d'un PBI passe par les états suivants :
-</p>
-<ul class="noindent">
- <li>
- créé
- </li>
- <li>
- estimé
- </li>
- <li>
- planifié (associé à un&nbsp;sprint futur
- </li>
- <li>
- associé au sprint courant (on le réalise)
- </li>
- <li>
- réalisé
- </li>
- <li style="list-style: none">
- <br />
- </li>
-</ul></mainDescription>
- <keyConsiderations>Le principe de Scrum est de finir complètement un PBI dans un sprint.</keyConsiderations>
- <externalId>PBI</externalId>
- <purpose>Sert à la gestion de projet : il sera placé dans un sprint</purpose>
-</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/Scrum French/Scrum/workproducts/Product Backlog.xmi b/Scrum French/Scrum/workproducts/Product Backlog.xmi
deleted file mode 100644
index 4d8cb72..0000000
--- a/Scrum French/Scrum/workproducts/Product Backlog.xmi
+++ /dev/null
@@ -1,28 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-Of1SdnAQ9nmsL5DFvD2Uug" name="Product Backlog,_5ABscPpYEdqsc-f87sBK8A" guid="-Of1SdnAQ9nmsL5DFvD2Uug" authors="Claude AUbry" changeDate="2006-12-03T09:31:43.140+0100" version="1.0.0">
- <mainDescription><p>
- Le backlog du produit est le référentiel des exigences. Il contient des éléments du backlog (appelés aussi des items de
- backlog de produit).
-</p>
-<p>
- Sa vie est liée à celle du produit.
-</p></mainDescription>
- <purpose>Lister toutes les choses à faire&nbsp;du point de vue du client (le quoi)</purpose>
- <impactOfNotHaving>Obligatoire</impactOfNotHaving>
- <briefOutline>Visible par tous, il est mis à jour régulièrement. Il est présenté à la revue de planification du sprint et, une fois
-accepté, la partie contenant les exigences allouées au sprint courant est gelée.</briefOutline>
- <representationOptions><ul>
- <li>
- Cartes (story cards)
- </li>
- <li>
- Feuille d'un tableur
- </li>
- <li>
- Outil IceScrum&nbsp;
- </li>
- <li>
- Base de données
- </li>
-</ul></representationOptions>
-</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/Scrum French/Scrum/workproducts/Product increment.xmi b/Scrum French/Scrum/workproducts/Product increment.xmi
deleted file mode 100644
index bc47bed..0000000
--- a/Scrum French/Scrum/workproducts/Product increment.xmi
+++ /dev/null
@@ -1,38 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-6aCUL_kawJFNBtfH_sRXkw" name="Product increment,_tCmYEP-xEdqLnajTSLeAsA" guid="-6aCUL_kawJFNBtfH_sRXkw" changeDate="2006-12-03T10:04:18.218+0100" version="1.0.0">
- <mainDescription><p>
- Le résultat principal d'un sprint est le produit partiel qui réalise, en plus de ce qui existait au début du
- sprint,&nbsp;les exigences supplémentaires réalisées pendant ce sprint.
-</p>
-<p>
- On peut&nbsp;trouver 3 utilisations -après la démonstration lors de la revue de sprintes- du produit partiel obtenu en
- fin d'itération&nbsp;:
-</p>
-<ul>
- <li>
- il n'est pas utilisé en dehors de l'équipe. Il a été produit pour chercher à minimiser les risques liés à la
- technologie et à la capacité de l'équipe à intégrer pour produire un <q>build</q>. Cela arrive surtout au début
- d'un nouveau produit.
- </li>
- <li>
- il est utilisé par des clients privilégiés, en plus du directeur produit. Cela leur donne la possibilité de jouer
- avec, ce qui permet de réduire les risques portant sur l'IHM liées à la facilité d'utilisation des fonctionnalités.
- Les retours faits iront alimenter le backlog pour prise en compte ultérieure.
- </li>
- <li>
- il est mis en production ou en exploitation et utilisé par ses utilisateurs finals. C'est évidemment ce qu'il faut
- viser puisque chaque nouvelle version apporte de la valeur. Autant l'apporter le plus tôt possible, dès qu'elle est
- disponible. Mais ce n'est généralement pas possible de mettre en production à la fin de chaque sprint : trop de
- temps serait pris pour passer les tests de recette sur tout le système, déployer sur l'environnement de production,
- écrire les manuels utilisateurs, préparer et donner la formation aux utilisateurs... C'est pourquoi ce travail
- particulier nécessite souvent une activité de préparation à la mise en production. Mais si on réussit à limiter le
- temps pour faire tout ça, on peut alors mettre en production plus souvent qu'à la fin des releases.
- </li>
-</ul>
-<br /></mainDescription>
- <keyConsiderations><p>
- Le produit évolue pendant toute sa vie jusqu'à son retrait.
-</p></keyConsiderations>
- <briefOutline>Le produit partiel peut être déployé dans l'environnement de production&nbsp;ou simplement mis à disposition des
-utilisateurs.</briefOutline>
-</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/Scrum French/Scrum/workproducts/Sprint Backlog Item.xmi b/Scrum French/Scrum/workproducts/Sprint Backlog Item.xmi
deleted file mode 100644
index 1f7bd5b..0000000
--- a/Scrum French/Scrum/workproducts/Sprint Backlog Item.xmi
+++ /dev/null
@@ -1,20 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-6UJtuFO3WFBFpJOFeV1QMQ" name="new_artifact,_9C78MIHnEdu3SZQ-Dp1OAA" guid="-6UJtuFO3WFBFpJOFeV1QMQ" changeDate="2006-12-02T10:38:33.140+0100">
- <mainDescription><p>
- Chaque tâche possède les attributs suivants :
-</p>
-<ul>
- <li>
- l'estimation du temps à passer pour finir la tâche. Les efforts sont estimés, par l’équipe, en heures sur une
- échelle qui varie habituellement de 1à 16 heures. Les tâches plus grandes devraient être décomposées. L’estimation
- du reste à faire est réactualisée tous les jours.
- </li>
- <li>
- l'<a class="elementLink" href="./../../Scrum/workproducts/Product Backlog Item,_-D85cIGIEduKE9hnyImx1Q.html"
- guid="_-D85cIGIEduKE9hnyImx1Q">Elément de backlog de produit</a>&nbsp;à l'origine de cette tâche
- </li>
- <li>
- la personne qui prend en compte cette tâche<br />
- </li>
-</ul></mainDescription>
-</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/Scrum French/Scrum/workproducts/Sprint backlog.xmi b/Scrum French/Scrum/workproducts/Sprint backlog.xmi
deleted file mode 100644
index da5b496..0000000
--- a/Scrum French/Scrum/workproducts/Sprint backlog.xmi
+++ /dev/null
@@ -1,16 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-8V2DOvzUhvtqwWvTOHMB5g" name="Sprint backlog,_Dzw70PpZEdqsc-f87sBK8A" guid="-8V2DOvzUhvtqwWvTOHMB5g" changeDate="2006-12-03T10:17:45.781+0100" version="1.0.0">
- <mainDescription><p>
- Il&nbsp;contient la liste des tâches que l’équipe s’engage à faire afin de compléter les éléments de backlog de produit
- sélectionnés pour ce sprint.<br />
- L’équipe peut modifier une tâche, la supprimer ou en ajouter de nouvelles : il est courant que des tâches apparaissent
- lors du sprint.
-</p></mainDescription>
- <purpose>Il&nbsp;décrit l'ensemble des&nbsp;tâches d'un sprint, avec les ressources qui y sont affectées et le travail qui reste à
-faire. C'est un plan qui porte sur des tâches détaillées, il est dit à "mailles fines".</purpose>
- <impactOfNotHaving>Obligatoire</impactOfNotHaving>
- <briefOutline><p>
- C'est un outil de communication essentiel qui aide à gérer le sprint. Il doit être facilement mis à jour et rester
- visible à toute l'équipe.
-</p></briefOutline>
-</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/Scrum French/Scrum/workproducts/resources/EtatsPBI.jpg b/Scrum French/Scrum/workproducts/resources/EtatsPBI.jpg
deleted file mode 100644
index 4e1e28f..0000000
--- a/Scrum French/Scrum/workproducts/resources/EtatsPBI.jpg
+++ /dev/null
Binary files differ
diff --git a/Scrum French/Scrum/workproducttypes/Backlogs.xmi b/Scrum French/Scrum/workproducttypes/Backlogs.xmi
deleted file mode 100644
index 67ae2e4..0000000
--- a/Scrum French/Scrum/workproducttypes/Backlogs.xmi
+++ /dev/null
@@ -1,15 +0,0 @@
-<?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.3/uma.ecore" xmi:id="-eSc2tcV1h17HBw_s8ROEVw" name="Backlogs,_d-yk8ABREdu3o4yroaI-tA" guid="-eSc2tcV1h17HBw_s8ROEVw" changeDate="2006-06-22T22:06:50.327+0200">
- <mainDescription><p>
- Les backlogs de Produit et de Sprint sont des éléments de gestion majeurs dans l'utilisation de Scrum.
-</p>
-<p>
- A partir des backlogs, on produit des rapports comme le <a class="elementLink"
- href="./../../Scrum/guidances/reports/Release Burndown Chart,_vKqe8PpaEdqsc-f87sBK8A.html"
- guid="_vKqe8PpaEdqsc-f87sBK8A">Release Burndown Chart</a>&nbsp;ou le <a class="elementLink"
- href="./../../Scrum/guidances/reports/Sprint Burndown Chart,_jC4NwPpaEdqsc-f87sBK8A.html"
- guid="_jC4NwPpaEdqsc-f87sBK8A">Sprint Burndown Chart</a>
-</p></mainDescription>
- <keyConsiderations>Un backlog est une liste d'items. Le terme n'est pas traduit en français car il est couramment utilisé dans la communauté
-des développeurs.</keyConsiderations>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/Scrum French/configurations/Scrum.xmi b/Scrum French/configurations/Scrum.xmi
deleted file mode 100644
index 4575445..0000000
--- a/Scrum French/configurations/Scrum.xmi
+++ /dev/null
@@ -1,27 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<org.eclipse.epf.uma:MethodConfiguration 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.3/uma.ecore" epf:version="1.0.0" xmi:id="_IqDLgP_OEdqtbrr0B1TG-A" name="Scrum" guid="_IqDLgP_OEdqtbrr0B1TG-A" briefDescription="Le processus Scrum" version="1.0.0">
- <methodPluginSelection href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eoPpYEdqsc-f87sBK8A"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3erPpYEdqsc-f87sBK8A"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eofpYEdqsc-f87sBK8A"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3epfpYEdqsc-f87sBK8A"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eovpYEdqsc-f87sBK8A"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3epPpYEdqsc-f87sBK8A"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eo_pYEdqsc-f87sBK8A"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3ep_pYEdqsc-f87sBK8A"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3erfpYEdqsc-f87sBK8A"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3ervpYEdqsc-f87sBK8A"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3epvpYEdqsc-f87sBK8A"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3er_pYEdqsc-f87sBK8A"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eqfpYEdqsc-f87sBK8A"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eqPpYEdqsc-f87sBK8A"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eqvpYEdqsc-f87sBK8A"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_rkSgEPpYEdqsc-f87sBK8A"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_SqGkoABREdu3o4yroaI-tA"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessComponent" href="uma://_9llsAAAvEdubGMceRDupFQ#_9llsAAAvEdubGMceRDupFQ"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_9llsAAAvEdubGMceRDupFQ#_37NW8AL_EduOAKqB9I73uw"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_9llsAAAvEdubGMceRDupFQ#_NSW6sAMAEduOAKqB9I73uw"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://_9llsAAAvEdubGMceRDupFQ#_SoXWEAMAEduOAKqB9I73uw"/>
- <processViews xsi:type="org.eclipse.epf.uma:CustomCategory" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_s8y1UABREdu3o4yroaI-tA"/>
- <processViews xsi:type="org.eclipse.epf.uma:CustomCategory" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_nF6fgALYEduFv7wnrO7SvQ"/>
- <processViews xsi:type="org.eclipse.epf.uma:CustomCategory" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_7BSBkABCEduYUKPFgCzFuA"/>
-</org.eclipse.epf.uma:MethodConfiguration>
diff --git a/Scrum French/library.xmi b/Scrum French/library.xmi
deleted file mode 100644
index 16d6058..0000000
--- a/Scrum French/library.xmi
+++ /dev/null
@@ -1,12 +0,0 @@
-<?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.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
- <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_hDRYYfpYEdqsc-f87sBK8A" guid="_hDRYYfpYEdqsc-f87sBK8A">
- <subManagers xmi:id="_5AUAUPpYEdqsc-f87sBK8A" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_5AUAUPpYEdqsc-f87sBK8A"/>
- <resourceDescriptors xmi:id="_hDRYYvpYEdqsc-f87sBK8A" id="_hDRYYPpYEdqsc-f87sBK8A" uri=""/>
- <resourceDescriptors xmi:id="_mRDr4PpYEdqsc-f87sBK8A" id="_mQ3eoPpYEdqsc-f87sBK8A" uri="Scrum/plugin.xmi"/>
- <resourceDescriptors xmi:id="_VRheAYPTEdu0eqo2Hxw7OA" id="_VRheAIPTEdu0eqo2Hxw7OA" uri="IceScrum/plugin.xmi"/>
- </org.eclipse.epf.uma.resourcemanager:ResourceManager>
- <org.eclipse.epf.uma:MethodLibrary xmi:id="_hDRYYPpYEdqsc-f87sBK8A" name="scrum" guid="_hDRYYPpYEdqsc-f87sBK8A">
- <methodPlugins xmi:id="_mQ3eoPpYEdqsc-f87sBK8A" href="uma://_mQ3eoPpYEdqsc-f87sBK8A#_mQ3eoPpYEdqsc-f87sBK8A"/>
- </org.eclipse.epf.uma:MethodLibrary>
-</xmi:XMI>
diff --git a/XP/.cvsignore b/XP/.cvsignore
deleted file mode 100644
index 6fe43c5..0000000
--- a/XP/.cvsignore
+++ /dev/null
@@ -1 +0,0 @@
-.lock
diff --git a/XP/.project b/XP/.project
deleted file mode 100644
index 7773d54..0000000
--- a/XP/.project
+++ /dev/null
@@ -1,12 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<projectDescription>
- <name>XP</name>
- <comment></comment>
- <projects>
- </projects>
- <buildSpec>
- </buildSpec>
- <natures>
- <nature>org.eclipse.epf.library.project.MethodLibraryProjectNature</nature>
- </natures>
-</projectDescription>
diff --git a/XP/configurations/config_for_xp.xmi b/XP/configurations/config_for_xp.xmi
deleted file mode 100644
index 52715dd..0000000
--- a/XP/configurations/config_for_xp.xmi
+++ /dev/null
@@ -1,29 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<org.eclipse.epf.uma:MethodConfiguration 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.3/uma.ecore" epf:version="1.0.0" xmi:id="_mohucGE-EdqnIZeW8YpHcA" name="config_for_xp" guid="_mohucGE-EdqnIZeW8YpHcA" version="1.0.0">
- <methodPluginSelection href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#{35DCB3E1-2766-423E-A849-57ECD4F41A40}"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_mhU6S2E-EdqnIZeW8YpHcA"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_mhU6QGE-EdqnIZeW8YpHcA"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_mhU6RGE-EdqnIZeW8YpHcA"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_mhU6QWE-EdqnIZeW8YpHcA"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_mhU6Q2E-EdqnIZeW8YpHcA"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_mhU6QmE-EdqnIZeW8YpHcA"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_mhU6RmE-EdqnIZeW8YpHcA"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_mhU6TGE-EdqnIZeW8YpHcA"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_mhU6TWE-EdqnIZeW8YpHcA"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_mhU6RWE-EdqnIZeW8YpHcA"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ProcessPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_mhU6TmE-EdqnIZeW8YpHcA"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_mhU6SGE-EdqnIZeW8YpHcA"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_mhU6R2E-EdqnIZeW8YpHcA"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_mhU6SWE-EdqnIZeW8YpHcA"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_ms9igWE-EdqnIZeW8YpHcA"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#{90FB58E1-B403-4358-85D0-BD902528D810}"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#{796EA4CB-0038-43B8-A568-792DCC3B9F22}"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#{DBE91BD5-0065-4049-AA61-058C77F1D2A3}"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#{45A887AB-A968-48AF-8213-4D470DA9DBCC}"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#{01E73AC7-B8D8-4B2F-8B29-A28D9813DB6C}"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#{BC57C7CE-BFA8-464F-9925-D27A7968B63C}"/>
- <methodPackageSelection xsi:type="org.eclipse.epf.uma:ContentPackage" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#{8367713C-3AEA-489D-B136-DB87D6340A3F}"/>
- <processViews xsi:type="org.eclipse.epf.uma:CustomCategory" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_um0n8GdjEdqlnYmIxoiUEQ"/>
- <processViews xsi:type="org.eclipse.epf.uma:CustomCategory" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_8NSdoGdjEdqlnYmIxoiUEQ"/>
- <defaultView xsi:type="org.eclipse.epf.uma:CustomCategory" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_um0n8GdjEdqlnYmIxoiUEQ"/>
-</org.eclipse.epf.uma:MethodConfiguration>
diff --git a/XP/library.xmi b/XP/library.xmi
deleted file mode 100644
index 02ce1ab..0000000
--- a/XP/library.xmi
+++ /dev/null
@@ -1,11 +0,0 @@
-<?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.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
- <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_hmtlAW96EdupM6itjmYdSQ" guid="_hmtlAW96EdupM6itjmYdSQ">
- <subManagers xmi:id="_TOlmEGMyEdqsrK7eslBiiA" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#_TOlmEGMyEdqsrK7eslBiiA"/>
- <resourceDescriptors xmi:id="_hmtlAm96EdupM6itjmYdSQ" id="_hmtlAG96EdupM6itjmYdSQ" uri=""/>
- <resourceDescriptors xmi:id="_1wUXkG96EdupM6itjmYdSQ" id="{35DCB3E1-2766-423E-A849-57ECD4F41A40}" uri="xp/plugin.xmi"/>
- </org.eclipse.epf.uma.resourcemanager:ResourceManager>
- <org.eclipse.epf.uma:MethodLibrary xmi:id="_hmtlAG96EdupM6itjmYdSQ" name="XP" guid="_hmtlAG96EdupM6itjmYdSQ">
- <methodPlugins xmi:id="{35DCB3E1-2766-423E-A849-57ECD4F41A40}" href="uma://{35DCB3E1-2766-423E-A849-57ECD4F41A40}#{35DCB3E1-2766-423E-A849-57ECD4F41A40}"/>
- </org.eclipse.epf.uma:MethodLibrary>
-</xmi:XMI>
diff --git a/XP/xp/customcategories/conceptual_road_maps.xmi b/XP/xp/customcategories/conceptual_road_maps.xmi
deleted file mode 100644
index 08649a0..0000000
--- a/XP/xp/customcategories/conceptual_road_maps.xmi
+++ /dev/null
@@ -1,9 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-QcM1bn-XJLcMSggRp54YlQ" name="conceptual_road_maps,_mtDpJGE-EdqnIZeW8YpHcA" guid="-QcM1bn-XJLcMSggRp54YlQ" changeDate="2005-12-06T05:01:41.292-0800">
- <mainDescription><p class="node">
- &nbsp;
-</p>
-<br />
-<br />
-<br /></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/customcategories/getting_started.xmi b/XP/xp/customcategories/getting_started.xmi
deleted file mode 100644
index ac36596..0000000
--- a/XP/xp/customcategories/getting_started.xmi
+++ /dev/null
@@ -1,92 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-MqIvi7DInwjz8kX7QEyU3g" name="getting_started,_ms9ig2E-EdqnIZeW8YpHcA" guid="-MqIvi7DInwjz8kX7QEyU3g" changeDate="2006-03-02T14:18:20.615-0800">
- <mainDescription><h3>
- <a id="WhatisXP" name="WhatisXP">What is XP?</a>
-</h3>
-<p>
- Extreme Programming or XP is a development process that can be used by small to medium sized teams to develop high
- quality software within a predictable schedule and budget and with a minimum of overhead. XP is currently one of the
- most widely used agile processes in the industry.
-</p>
-<p>
- <img height="540" alt="" src="resources/circleOfLife.jpg" width="720" usemap="#xp_practices_image_map" border="0" />
- <map id="xp_practices_image_map" name="xp_practices_image_map">
- <area shape="RECT" coords="298,19,390,88"
- href="./../../xp/guidances/concepts/whole_team,7.89591827591278E-306.html" />
- <area shape="RECT" coords="176,135,282,200"
- href="./../../xp/guidances/concepts/collective_ownership,9.300699588493279E-306.html" />
- <area shape="RECT" coords="297,168,434,231"
- href="./../../xp/guidances/concepts/test_driven_development,1.620567348185129E-306.html" />
- <area shape="RECT" coords="447,135,547,198"
- href="./../../xp/guidances/concepts/coding_standard,8.8116853923311E-307.html" />
- <area shape="RECT" coords="15,236,122,305"
- href="./../../xp/guidances/concepts/customer_tests,2.297945473205673E-305.html" />
- <area shape="RECT" coords="218,238,362,307"
- href="./../../xp/guidances/concepts/pair_programming,3.876855509996079E-307.html" />
- <area shape="RECT" coords="392,241,512,305"
- href="./../../xp/guidances/concepts/refactoring_xp_programming,1.4410217108363206E-306.html" />
- <area shape="RECT" coords="614,236,714,302"
- href="./../../xp/guidances/concepts/planning_game,2.7371805612676613E-305.html" />
- <area shape="RECT" coords="143,325,270,393"
- href="./../../xp/guidances/concepts/continuous_integration,3.193414568279561E-305.html" />
- <area shape="RECT" coords="310,321,412,379"
- href="./../../xp/guidances/concepts/simple_design,1.6109092258980447E-306.html" />
- <area shape="RECT" coords="468,323,597,393"
- href="./../../xp/guidances/concepts/xp_sustainable_pace,3.133529870649493E-306.html" />
- <area shape="RECT" coords="307,386,413,436"
- href="./../../xp/guidances/concepts/metaphor_system_of_names,4.884861766532753E-306.html" />
- <area shape="RECT" coords="312,475,419,539"
- href="./../../xp/guidances/concepts/small_releases,5.762953011420275E-306.html" />
- <area shape="RECT" target="_blank" coords="561,494,708,538" href="http://www.xprogramming.com" />
- </map>
-</p>
-<p>
- This diagram arranges the core practices of Extreme Programming in a way that makes them easy to remember and that
- exemplifies the steering and control cycles of the process. For more details, see <a class="elementLinkWithType"
- href="./../../xp/guidances/concepts/xp_practices,2.2937799026801584E-305.html" guid="2.2937799026801584E-305">Concept:
- XP Practices</a>.
-</p>
-<h2>
- <a id="Start" name="Start">Where do I start?</a>
-</h2>
-<p>
- If you are unfamiliar with XP and want to learn more about it, we suggest you take the following steps:
-</p>
-<ul>
- <li>
- Get a quick <a class="elementLinkWithUserText"
- href="./../../xp/guidances/concepts/what_is_xp,9.251272550276345E-306.html" guid="9.251272550276345E-306">overview
- of XP</a>.
- </li>
- <li>
- Learn what the <a class="elementLinkWithUserText"
- href="./../../xp/guidances/concepts/motivation,1.6390805262958034E-306.html"
- guid="1.6390805262958034E-306">motivation behind XP</a> is.
- </li>
- <li>
- Understand what <a class="elementLink"
- href="./../../xp/guidances/concepts/agile_software_development,1.041091673844025E-305.html"
- guid="1.041091673844025E-305">Agile Software Development</a> means.
- </li>
- <li>
- Take a tour of the <a class="elementLink"
- href="./../../xp/guidances/concepts/xp_values,1.076140803519123E-306.html" guid="1.076140803519123E-306">XP
- Values</a> and <a class="elementLink"
- href="./../../xp/guidances/concepts/xp_practices,2.2937799026801584E-305.html" guid="2.2937799026801584E-305">XP
- Practices</a>.
- </li>
-</ul>
-<p>
- If you are familiar with XP and are interested in trying XP on your RUP project, we simply suggest you start by reading
- the <a class="elementLinkWithUserText"
- href="./../../xp/guidances/concepts/extreme_programming,5.2637267673584526E-306.html"
- guid="5.2637267673584526E-306">Extreme Programming Roadmap</a>.<br />
-</p>
-<h3>
- <a id="Who" name="Who">Who is behind the plug-in?</a>
-</h3>
-<p>
- This plug-in is a collaboration between <a href="http://www.objectmentor.com/" target="_blank">Object Mentor Inc.</a>
- and&nbsp;<a href="http://www.ibm.com/" target="_blank">IBM Corporation</a>.
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/customcategories/guidelines_overview.xmi b/XP/xp/customcategories/guidelines_overview.xmi
deleted file mode 100644
index 1bd6357..0000000
--- a/XP/xp/customcategories/guidelines_overview.xmi
+++ /dev/null
@@ -1,6 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-8FSBtYSGN9EGWRr1N6fbPQ" name="guidelines_overview,2.0279775416255596E-305" guid="-8FSBtYSGN9EGWRr1N6fbPQ" changeDate="2005-12-06T04:35:18.106-0800">
- <mainDescription><p>
- <b>Guidelines</b> provide practical information about the implementation of specific activities in the process.
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/customcategories/key_xp_concepts.xmi b/XP/xp/customcategories/key_xp_concepts.xmi
deleted file mode 100644
index b4d2e70..0000000
--- a/XP/xp/customcategories/key_xp_concepts.xmi
+++ /dev/null
@@ -1,2 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-hZ1cvRhigpDb6WbQckPWcA" name="key_xp_concepts,1.9093436569802954E-305" guid="-hZ1cvRhigpDb6WbQckPWcA" changeDate="2006-11-29T17:04:06.831-0800" version="1.0.0"/>
diff --git a/XP/xp/customcategories/references.xmi b/XP/xp/customcategories/references.xmi
deleted file mode 100644
index 2ebe0c8..0000000
--- a/XP/xp/customcategories/references.xmi
+++ /dev/null
@@ -1,3457 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-a8huB5Sn0Qjfe-SkZubH1w" name="references,_mtcqtmE-EdqnIZeW8YpHcA" guid="-a8huB5Sn0Qjfe-SkZubH1w" changeDate="2005-12-06T05:10:54.327-0800">
- <mainDescription><a id="XE_references__bibliography_of" name="XE_references__bibliography_of"></a><a id="XE_bibliography__references_for"
-name="XE_bibliography__references_for"></a>
-<h5>
- Topics
-</h5>
-<ul>
- <li>
- <a href="#Business Modeling references">Business Modeling</a>
- </li>
- <li>
- <a href="#Configuration Management references">Configuration Management</a>
- </li>
- <li>
- <a href="#Miscellaneous references">Miscellaneous</a>
- </li>
- <li>
- <a href="#Modeling and Unified Modeling Language references">Modeling and Unified Modeling Language</a>
- </li>
- <li>
- <a href="#Object-Oriented Technology references">Object-Oriented Technology</a>
- </li>
- <li>
- <a href="#Project Management references">Project Management</a>
- </li>
- <li>
- <a href="#Requirement Management references">Requirements Management</a>
- </li>
- <li>
- <a href="#Software Architecture references">Software Architecture</a>
- </li>
- <li>
- <a href="#Software Development Process references">Software Development Process</a>
- </li>
- <li>
- <a href="#Testing and Quality references">Testing and Quality</a>
- </li>
-</ul>
-<h2 align="left">
- <a id="Business Modeling references" name="Business Modeling references">Business Modeling</a>
-</h2>
-<div align="center">
- <table width="100%" summary="layout table" border="0">
- <tbody>
- <tr>
- <td valign="top" width="12%">
- <a id="BRO95" name="BRO95">BRO95</a>
- </td>
- <td colspan="2">
- Frederick P. Brooks, Jr. 1995. <i>The Mythical Man-Month-Essays on Software Engineering</i> 2nd ed.
- Reading, MA, Addison Wesley Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- &nbsp;
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- A classic that should be read and re-read by everyone involved in software development. We recommend
- this 20-year anniversary edition rather than the original 1975 edition.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="CLA97" name="CLA97">CLA97</a>
- </td>
- <td colspan="2">
- Carl von Clausewitz 1997. <i>On War.</i> Wordsworth Editions.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- One of the greatest books ever written on the subject of war, and applicable to the field of
- management.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="CHM95" name="CHM95">CHM95</a>
- </td>
- <td colspan="2">
- James Champy 1995. <i>Reengineering Management: The Mandate for New Leadership.</i> New York, NY:
- HarperCollins.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Gives some insight into the precarious art of managing a business (re-)engineering effort.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="DVP93" name="DVP93">DVP93</a>
- </td>
- <td colspan="2">
- Thomas H. Davenport 1993. <i>Process Innovation-Reengineering Work through&nbsp;Information
- Technology.</i> Boston, MA: Harvard Business School Press.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Solid and comprehensive introduction about how information technology enables business improvement and
- (re-)engineering.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="GAO97" name="GAO97">GAO97</a>
- </td>
- <td colspan="2">
- United States General Accounting Office 1997. <i>Business Process Reengineering Assessment Guide</i>.
- <a href="http://www.gao.gov" target="_blank">http://www.gao.gov</a>
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="1%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="150%">
- Describes a framework for assessing a business (re-)engineering effort.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="ERI00" name="ERI00">ERI00</a>
- </td>
- <td colspan="2">
- Hans-Erik Eriksson and Magnus Penker 2000. <i>Business Modeling With UML: Business Patterns at
- Work.&nbsp;</i>New York, NY: John Wiley &amp; Sons, Inc.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Presents a set of valuable patterns for business modeling.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="HAM93" name="HAM93">HAM93</a>
- </td>
- <td colspan="2">
- Michael Hammer and James Champy 1993.&nbsp; <i>Reengineering the Corporation-A Manifesto for Business
- Revolution.</i>&nbsp;<br />
- New York, NY: HarperBusiness.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- The book that popularized the movement of business (re-)engineering. An excellent complement to <i>The
- Object Advantage-Business Process Reengineering with Object Technology</i> cited above<i>.&nbsp;</i>
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="HAR91" name="HAR91">HAR91</a>
- </td>
- <td colspan="2">
- H. James Harrington 1991. <i>Business Process Improvement: The Breakthrough Strategy for Total Quality,
- Productivity, and Competitiveness</i>. New York, NY: McGraw-Hill.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Another contributor to the topic of business (re-)engineering.<i>&nbsp;</i>
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="JAC94" name="JAC94">JAC94</a>
- </td>
- <td colspan="2">
- Ivar Jacobson, Maria Ericsson, and Agneta Jacobson 1994. <i>The Object Advantage-Business Process
- Reengineering with Object Technology</i>. Addison Wesley Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- The basis of the Business Modeling discipline, this is the very first book that applied object
- technology to the field of business modeling.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="KAP96" name="KAP96">KAP96</a>
- </td>
- <td colspan="2">
- Robert Kaplan and David Norton 1996. <i>The Balanced Scorecard</i>. Boston, MA: Harvard Business School
- Press.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="1%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="150%">
- Best practices for successfully implementing the Balanced Scorecard.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="KOT96" name="KOT96">KOT96</a>
- </td>
- <td colspan="2">
- John P. Kotter 1996. <i>Leading Change</i>. Boston, MA: Harvard Business School Press.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="1%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="150%">
- A practical, proven model for planning and managing organizational change.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="MARS00" name="MARS00">MARS00</a>
- </td>
- <td colspan="2">
- Chris Marshall 2000. <i>Enterprise Modeling with UML</i>. Addison Wesley Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="1%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="150%">
- Describes how to create business models that facilitate the development software systems.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="NDL97" name="NDL97">NDL97</a>
- </td>
- <td colspan="2">
- David A. Nadler and Michael L. Tushman 1999.&nbsp; <i>Competing by Design-the Power of Organizational
- Architecture.</i> Oxford University Press.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Defines organizational architecture and capabilities as a source of competitive advantage.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="OHM91" name="OHM91">OHM91</a>
- </td>
- <td colspan="2">
- Kenichi Ohmae 1991.&nbsp; <i>The Mind of the Strategist: The Art of Japanese Business.</i> McGraw-Hill.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="1%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="150%">
- A crisp and practical guide to strategic management.
- </td>
- </tr>
- <tr>
- <td>
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="ODL98" name="ODL98">ODL98</a>
- </td>
- <td colspan="2">
- James J. Odell 1998.&nbsp; <i>Advanced Object-Oriented Analysis &amp; Design Using UML.</i> Cambridge
- University Press.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Provides a good overview, among other things, on the topic of business rules.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="PFE99" name="PFE99">PFE99</a>
- </td>
- <td colspan="2">
- Jeffrey Pfeffer and Robert Sutton 1999.&nbsp; <i>The Knowing-Doing Gap.</i> Boston, MA: Harvard
- Business School Press.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="1%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="150%">
- Discusses the reasons why some organizations do not apply their own lessons learned and provides
- pointers for how to overcome this challenge.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="PLR99" name="PLR99">PLR99</a>
- </td>
- <td colspan="2">
- R. Steven Player (Editor) and David Keys (Editor) 1999.&nbsp; <i>Activity-Based Management: Arthur
- Andersen's Lessons from the ABM Battlefield.</i> Wiley Cost Management Series.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- An introduction to understanding the management of costs, and how to implement activity-based costing
- (ABC) and activity-based management (ABM) systems.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="POR98" name="POR98">POR98</a>
- </td>
- <td colspan="2">
- Michael Porter 1998.&nbsp; <i>Competitive Strategy: Techniques for Analyzing Industries and
- Competitors.</i> Simon &amp; Schuster, Inc.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="1%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="150%">
- A practical guide for the strategic planner.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="ROS97" name="ROS97">ROS97</a>
- </td>
- <td colspan="2">
- Ron Ross 1997.&nbsp; <i>The Business Rule Book: Classifying, Defining and Modeling Rules.</i> Boston,
- MA: Database Research Group.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="1%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="150%">
- A complete handbook for the business rules analyst.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="SEY98" name="SEY98">SEY98</a>
- </td>
- <td colspan="2">
- Patricia Seybold 1998.&nbsp; <i>Customers.com.</i> Random House Publishing.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="1%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="150%">
- An excellent collection of practical guidelines and case studies on the benefits of e-business and
- (re-)engineering.
- </td>
- </tr>
- </tbody>
- </table>
-</div>
-<br />
-<h2 align="left">
- <a id="Configuration Management references" name="Configuration Management references">Configuration Management</a>
-</h2>
-<div align="center">
- <table width="100%" summary="layout table" border="0">
- <tbody>
- <tr>
- <td valign="top" width="12%">
- <a id="BER92" name="BER92">BER92</a>
- </td>
- <td colspan="2">
- H. Berlack 1992. <i>Software Configuration Management.</i> New York, NY: John Wiley &amp; Sons, Inc.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="BUC93" name="BUC93">BUC93</a>
- </td>
- <td colspan="2">
- J. Buckley 1993. <i>Implementing Configuration Management, Hardware, Software and Firmware.</i>&nbsp;
- Los Alamitos, CA: IEEE Computer Science Press.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="WHI00" name="WHI00">WHI00</a>
- </td>
- <td colspan="2">
- Brian White and Geoff Glemm 2000. <i>Software Configuration Management Strategies and Rational
- ClearCase: A Practical Introduction.</i> Addison-Wesley Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="WHI91" name="WHI91">WHI91</a>
- </td>
- <td colspan="2">
- David Whitgift 1991. <i>Methods and Tools for Software Configuration Management.</i>&nbsp; New York,
- NY: John Wiley &amp; Sons, Inc.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- </tbody>
- </table>
-</div>
-<br />
-<h2>
- <a id="Miscellaneous references" name="Miscellaneous references">Miscellaneous</a>
-</h2>
-<div align="center">
- <table width="100%" summary="layout table" border="0">
- <tbody>
- <tr>
- <td valign="top" width="12%">
- <a id="BOU94" name="BOU94">BOU94</a>
- </td>
- <td colspan="2">
- Serge Bouchy 1994.&nbsp; <i>L'ingénierie des systèmes informatiques évolutifs,</i> Paris, France:
- Eyrolles, 330p.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="BRO95" name="BRO95">BRO95</a>
- </td>
- <td colspan="2">
- Frederick P. Brooks, Jr. 1995. <i>The Mythical Man-Month-Essays on Software Engineering</i> 2nd ed.
- Reading, MA, Addison Wesley Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- A classic that should be read and re-read by everyone involved in software development. We recommend
- this 20-year anniversary edition rather than the original 1975 edition.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="con92" name="con92">CON92</a>
- </td>
- <td colspan="2">
- D. Conner 1992. <i>Managing at the Speed of Change.</i> New York, NY: Random House, Inc.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="DAT99" name="DAT99">DAT99</a>
- </td>
- <td colspan="2">
- C.J. Date 1999. <i>An Introduction to Database Systems.</i>&nbsp; 7th ed.&nbsp; New York, NY:
- Addison-Wesley Publishing Company, Inc.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Excellent introduction, reference, and source of background information on Database Systems.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="DAV95" name="DAV95">DAV95</a>
- </td>
- <td colspan="2">
- Alan Davis 1995. <i>201 Principles of Software Development.</i>&nbsp; New York, NY: McGraw-Hill.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Full of good advice for every team member on a project.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="DEG90" name="DEG90">DEG90</a>
- </td>
- <td colspan="2">
- Peter DeGrace and Leslie Stahl 1990. <i>Wicked Problems, Righteous Solutions: A Catalog of Modern
- Software Engineering Practices.</i> Englewood Cliffs, NJ: Yourdon Press.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- An insightful book on various process lifecycles and their origins, flaws, and strengths; useful for
- understanding the importance of process.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="DEI84" name="DEI84">DEI84</a>
- </td>
- <td colspan="2">
- Harvey M. Deitel 1984. <i>An Introduction to Operating Systems.</i> Addison Wesley Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="FIS96" name="FIS96">FIS96</a>
- </td>
- <td colspan="2">
- Charles Fishman 1996. <i>Johnson Space Center Shuttle Software Group, "They Write the Right
- Stuff"</i><i>.</i> Fastcompany, Issue 6, p. 95, December, 1996.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="GRA97" name="GRA97">GRA97</a>
- </td>
- <td colspan="2">
- Ian Graham, et al. 1997. <i>The OPEN Process Specification</i>. 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%">
- Another process model, coming from down under that shares some principles with the Rational Unified
- Process (RUP).
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="hac97" name="hac97">HAC97</a>
- </td>
- <td colspan="2">
- JoAnn T. Hackos and Dawn M. Stevens 1997. <i>Standards for Online Communication.</i> John Wiley and
- Sons, Inc.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- For the modern technical writer, this book has become the defacto standard. It defines a process for
- developing user manuals, specifically focusing on how you produce online help systems.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="HER99" name="HER99">HER99</a>
- </td>
- <td colspan="2">
- Peter Herzum and Oliver Sims 1999. <i>Business Component Factory: A Comprehensive Overview of
- Component-Based Development for the Enterprise.</i> John Wiley &amp; Sons.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Defines and describes component-based development-from creating small components to creating
- federations of large component-based systems.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- IBM2000
- </td>
- <td colspan="2">
- <i>IBM System Integrated Method.</i> International Business Machines Corporation 1998, 1999, 2000.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- IBM99a
- </td>
- <td colspan="2">
- <i>An Approach to Designing e-business Solutions.</i> International Business Machines Corporation 1999.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- <a href="http://www.redbooks.ibm.com/abstracts/sg245949.html"
- target="_blank">http://www.redbooks.ibm.com/abstracts/sg245949.html</a>
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- IBM99b
- </td>
- <td colspan="2">
- <i>Design Considerations: From Client Server Applications to e-business Applications.</i> International
- Business Machines Corporation 1999.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- <a href="http://www.redbooks.ibm.com/abstracts/sg245503.html"
- target="_blank">http://www.redbooks.ibm.com/abstracts/sg245503.html</a>
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- IBM99c
- </td>
- <td colspan="2">
- <i>The Front of IBM WebSphere-Building e-business User Interfaces.</i> International Business Machines
- Corporation 1999.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- <a href="http://www.redbooks.ibm.com/abstracts/sg245488.html"
- target="_blank">http://www.redbooks.ibm.com/abstracts/sg245488.html</a>
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- IBM98a
- </td>
- <td colspan="2">
- <i>Architecture Description Standard: Overview.</i>&nbsp; International Business Machines Corporation
- 1998.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- IBM98b
- </td>
- <td colspan="2">
- <i>Architecture Description Standard: Semantic Specification.</i>&nbsp; International Business Machines
- Corporation 1998.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Other relevant Web sites for the preceding IBM references are:<br />
- <a href="http://www.redbooks.ibm.com" target="_blank">http://www.redbooks.ibm.com<br />
- </a> <a href="http://www.ibm.com/e-business/" target="_blank">http://www.ibm.com/e-business/<br />
- </a> <a href="http://www.ibm.com/software" target="_blank">http://www.ibm.com/software<br />
- </a> <a href="http://www.ibm.com/developer/" target="_blank">http://www.ibm.com/developer/<br />
- </a> <a href="http://www.ibm.com/services/" target="_blank">http://www.ibm.com/services/</a>
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="IBM97" name="IBM97">IBM97</a>
- </td>
- <td colspan="2">
- IBM 1997. <i>Developing Object-Oriented Software</i><i>-</i><i>An Experienced- based Approach.</i>
- Upper Saddle River, NJ: Prentice-Hall.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Like the RUP, an iterative, incremental, object-oriented, scenario-driven, risk-aware process developed
- by the IBM Object Technology Center.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="IE610.12" name="IE610.12">IE610.12</a>
- </td>
- <td colspan="2">
- IEEE Std 610.12-1990. <i>IEEE Standard Glossary of Software Engineering Terminology.</i> The Institute
- of Electrical and Electronics Engineers, Inc.: New York, NY, 10017-2394, USA. 1990.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" height="23">
- <a id="JAV03" name="JAV03">JAV03</a>
- </td>
- <td colspan="2">
- JavaTM 2 Platform, Standard Edition, v 1.4.2 API Specification -
- http://java.sun.com/j2se/1.4.2/docs/api/index.html
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="jel93" name="jel93">JEL93</a>
- </td>
- <td colspan="2">
- J. Jellison 1993. <i>Overcoming Resistance: A Practical Guide to Producing Change in the
- Workplace.</i>&nbsp; New York, NY: Simon &amp; Schuster, Inc.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="KAT93" name="KAT93">KAT93</a>
- </td>
- <td colspan="2">
- Jon R. Katzenbach and Douglas K. Smith 1993. <i>The Wisdom of Teams.</i> New York, NY: Harper Business.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- The secret of effective teams.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="KET98" name="KET98">KET98</a>
- </td>
- <td colspan="2">
- Nasser Kettani, et al. 1998. <i>De Merise à UML.</i> Paris, France: Editions Eyrolles.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Merise is a very popular software development methodology in France, which has been upgraded to use
- UML. It has some similitude with the RUP.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="LEA97" name="LEA97">LEA97</a>
- </td>
- <td colspan="2">
- Doug Lea 1999.&nbsp; <i>Concurrent Programming in Java.</i> Addison Wesley Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="MCA95" name="MCA95">MCA95</a>
- </td>
- <td colspan="2">
- Jim McCarthy 1995.&nbsp; <i>Dynamics of Software Development.</i> Redmond, WA: Microsoft Press.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Fifty-three rules of thumb by a Microsoft development manager.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="MCO97" name="MCO97">MCO97</a>
- </td>
- <td colspan="2">
- Steve McConnell 1997.&nbsp; <i>Software Project Survival Guide.</i> Redmond, WA: Microsoft Press.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- A collection of practical experience on how to deliver successful software projects.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="MCO93" name="MCO93">MCO93</a>
- </td>
- <td colspan="2">
- Steve McConnell 1993. <i>Code Complete</i><i>-</i><i>A Practical Handbook of Software Construction.</i>
- Redmond, WA: Microsoft Press.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- A great book for the implementers and for testers looking at the implementation, integration, and test
- aspects of the development process.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="mos98" name="mos98">MOS98</a>
- </td>
- <td colspan="2">
- Microsoft 1998. The <i>Microsoft Manual of Style for Technical Publications.</i>&nbsp; Redmond, WA:
- Microsoft Press.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="STA97" name="STA97">STA97</a>
- </td>
- <td colspan="2">
- Jennifer Stapleton 1997.&nbsp; <i>The Dynamic System Development Method.</i> Addison Wesley Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- At 15,000 feet, the DSDM approach could be seen as an introduction to the RUP. Although they use a
- different terminology, the two processes are very close to each other, and you can see the RUP as an
- instance or an implementation of&nbsp; DSDM.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="TAN86" name="TAN86">TAN86</a>
- </td>
- <td colspan="2">
- Andrew S. Tannenbaum 1986. <i>Operating Systems: Design and Implementation.&nbsp;</i> Upper Saddle
- River, NJ: Prentice Hall.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="WID00" name="WID00">WID00</a>
- </td>
- <td colspan="2">
- R. Max Wideman and PMForum, February, 1999 and January, 2000. <i>Wideman Comparative Glossary of
- Project Management Terms v2.0.</i> www.pmforum.org
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- This great collection of various software engineering terms and their many definitions is available
- online at <a href="http://www.pmforum.org/library/glossary/"
- target="_blank">http://www.pmforum.org/library/glossary/</a>.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="YOU97" name="YOU97">YOU97</a>
- </td>
- <td colspan="2">
- Edward Yourdon 1997. <i>Death March: Managing "Mission Impossible" Projects.</i> Upper Saddle River,
- NJ: Prentice Hall.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- An interesting view on project troubles.
- </td>
- </tr>
- </tbody>
- </table>
-</div>
-<br />
-<h2 align="left">
- <a id="Modeling and Unified Modeling Language references"
- name="Modeling and Unified Modeling Language references">Modeling and Unified Modeling Language</a>
-</h2>
-<div align="center">
- <table width="100%" summary="layout table" border="0">
- <tbody>
- <tr>
- <td valign="top" width="11%">
- <a id="BOO98" name="BOO98">BOO98</a>
- </td>
- <td colspan="2">
- G. Booch, J. Rumbaugh, and I. Jacobson, 1998. <i>UML User Guide</i>. Addison-Wesley Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%">
- </td>
- <td width="11%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Published at the same time as Rational Unified Process 5.1, this book is an excellent user's guide on
- UML by its main authors.
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%">
- <a id="CHE01" name="CHE01">CHE01</a>
- </td>
- <td colspan="2">
- John Cheesman and John Daniels, 2001. <i>UML Components: A Simple Process for Specifying
- Component-Based Software</i>. Addison-Wesley Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%">
- </td>
- <td width="11%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- This book provides a lot of in-depth practical guidance for specifying component-based systems, at the
- same time remaining compact and readable.
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%">
- <a id="CONA99" name="CONA99">CONA99</a>
- </td>
- <td colspan="2">
- Jim Conallen, 1999. <i>Building Web Applications with UML.</i> Addison-Wesley Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%">
- </td>
- <td width="11%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- A good introduction to the basics of web application development in the context of the RUP. This book
- also shows how to use the UML to model web applications and introduces a Web Application Extension to
- the UML.
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%">
- <a id="DOUG98" name="DOUG98">DOUG98</a>
- </td>
- <td colspan="2">
- Bruce Powel Douglass 1998. <i>Real-Time UML.</i> Addison Wesley Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%">
- </td>
- <td width="11%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Using UML as the notation, this book offers good advice on the application of object-oriented
- technology for real-time systems.
- </td>
- </tr>
- <tr>
- <td valign="top">
- <a id="ERI04" name="ERI04">ERI04</a>
- </td>
- <td colspan="2">
- Hans-Erik Eriksson, Magnus Penker, Brian Lyons and David Fado 2004. <i>UML 2 Toolkit</i>. Indianopolis:
- Wiley Publishing, Inc.
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%">
- <a id="ERI97" name="ERI97">ERI97</a>
- </td>
- <td colspan="2">
- Hans-Erik Eriksson and Magnus Penker 1997. <i>UML Toolkit</i>. New York: John Wiley &amp; Sons.
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%">
- </td>
- <td width="11%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- A more comprehensive book on UML as seen from Sweden by another pair of Rational friends.
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%">
- <a id="FOW97" name="FOW97">FOW97</a>
- </td>
- <td colspan="2">
- Martin Fowler 1997. <i>UML Distilled-Applying the standard object modeling language</i>. Addison-Wesley
- Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%">
- </td>
- <td width="11%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- A very nice little introduction to UML if you're in a hurry.
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%">
- <a id="FRA03" name="FRA03">FRA03</a>
- </td>
- <td colspan="2">
- David S. Frankel 2003. <i>Model Driven Architecture: Applying MDA to Enterprise Computing.</i> John
- Wiley &amp; Sons.
- </td>
- </tr>
- <tr>
- <td valign="top">
- &nbsp;
- </td>
- <td>
- &nbsp;
- </td>
- <td>
- A foundational work on the OMG's Model Driven Architecture initiative, written by one of its principal
- developers.
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%">
- <a id="KLE03" name="KLE03">KLE03</a>
- </td>
- <td colspan="2">
- Anneke Kleppe, Jos Warmer and Wim Bast 2003. <i>MDA Explained-The Model Driven
- Architecture(TM):Practice and Promise.</i> Addison-Wesley.
- </td>
- </tr>
- <tr>
- <td valign="top">
- &nbsp;
- </td>
- <td>
- &nbsp;
- </td>
- <td>
- More useful insights into MDA from a practitioner's viewpoint, written by contributors to the creation
- of MDA.
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%">
- <a id="LAR02" name="LAR02">LAR02</a>
- </td>
- <td colspan="2">
- Craig Larman 2002.&nbsp; <i>Applying UML and Patterns: An Introduction to Object-Oriented Analysis and
- Design and the Unified Process,</i> 2nd ed. Prentice-Hall, Inc.
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%">
- </td>
- <td width="11%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- This book is a great illustration of what happens in the Analysis &amp; Design discipline. It teaches
- analysis and design, the use of UML, and the application of the concept of pattern in the context of
- the Unified Process. By presenting the case study in an iterative, risk-driven, architecture-centric
- process, Mr. Larman's advice has a realistic context. He exposes the dynamics of what really happens in
- software development and shows the external forces at play. The design activities are connected to
- other tasks, and they no longer appear as a purely cerebral activity of systematic transformations or
- creative intuition.
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%">
- <a id="MEL04" name="MEL04">MEL04</a>
- </td>
- <td colspan="2">
- Stephen J. Mellor, Kendall Scott, Axel Uhl, Dirk Weise 2004. <i>MDA Distilled-Principles of
- Model-Driven Architecture.</i> Addison-Wesley.
- </td>
- </tr>
- <tr>
- <td valign="top">
- &nbsp;
- </td>
- <td>
- &nbsp;
- </td>
- <td>
- Extracts and presents the essence of MDA, with an emphasis on the technology for executable models.
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%">
- <a id="MUL98" name="MUL98">MUL98</a>
- </td>
- <td colspan="2">
- Pierre-Alain Muller 1998.&nbsp; <i>Instant UML.</i> Wrox Inc.
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%">
- </td>
- <td width="11%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Another short introduction to UML by a former colleague.
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%">
- <a id="NBG01" name="NBG01">NBG01</a>
- </td>
- <td colspan="2">
- Eric J. Naiburg and Robert A. Maksimchuk 2001. <i>UML For Database Design</i>. New York, NY:
- Addison-Wesley Publishing Company, Inc.
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%">
- &nbsp;
- </td>
- <td width="11%">
- &nbsp;
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Application of UML to database modeling and design.&nbsp; Supported throughout by a case study.
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%">
- <a id="OMG03" name="OMG03">OMG03</a>
- </td>
- <td colspan="2">
- <i>MDA Guide Version 1.0.1.</i> Object Management Group. Document omg/2003-06-01, June 2003
- </td>
- </tr>
- <tr>
- <td valign="top">
- &nbsp;
- </td>
- <td>
- &nbsp;
- </td>
- <td>
- <p>
- A specification of the concepts and terminology of Model Driven Architecture from the OMG.
- </p>
- <p>
- <a href="http://www.omg.org/mda/specs.htm" target="_blank">http://www.omg.org/mda/specs.htm</a>
- </p>
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%">
- <a id="QUA98" name="QUA98">QUA98</a>
- </td>
- <td colspan="2">
- Terry Quatrani 1998. <i>Visual Modeling with Rational Rose and UML.</i> Addison Wesley Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%">
- &nbsp;
- </td>
- <td width="11%">
- &nbsp;
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Provides step-by-step guidance on how to build UML models. At the same time, it follows the RUP, in
- effect providing a small scale example.
- </td>
- </tr>
- <tr>
- <td valign="top">
- <a id="RUM05" name="RUM05">RUM05</a>
- </td>
- <td colspan="2">
- James Rumbaugh, Ivar Jacobson, Grady Booch, 2005. <i>The Unified Modeling Language Reference Manual,
- second edition.</i> Addison-Wesley, Boston.
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%">
- <a id="RUM98" name="RUM98">RUM98</a>
- </td>
- <td colspan="2">
- J. Rumbaugh, I. Jacobson, and G. Booch, 1998. <i>UML Reference Manual.</i> Addison Wesley Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%">
- </td>
- <td width="11%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Certainly more digestible than the OMG standard; UML fully exposed by its main authors.
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%">
- <a id="UML01" name="UML01">UML01</a>
- </td>
- <td colspan="2">
- <i>OMG Unified Modeling Language Specification, Version 1.4.&nbsp;</i> Rational Software Corporation,
- 18880 Homestead Road, Cupertino, CA 95014, and Object Management Group, Inc., 492 Old Connecticut Path,
- Framingham, MA 01701.
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%">
- </td>
- <td width="11%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- The latest specification of the UML. Available online at <a href="http://www.rational.com/uml"
- target="_blank">http://www.rational.com/uml</a>.
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%" height="21">
- <a id="UML04" name="UML04">UML04</a>
- </td>
- <td colspan="2">
- <i>OMG Unified Modeling Language Specification, Version 2.0.&nbsp;</i> Object Management Group, Inc.,
- Needham, MA 02494
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%">
- </td>
- <td width="11%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Final Adopted Specification (2003-08-02)
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%">
- <a id="UML96" name="UML96">UML96</a>
- </td>
- <td colspan="2">
- G. Booch, J. Rumbaugh, and I. Jacobson 1996. <i>The Unified Modeling Language for Object-Oriented
- Development.</i> Documentation set, version 0.9 Addendum, Rational Software Corporation.
- </td>
- </tr>
- <tr>
- <td valign="top" width="11%">
- <a id="UML95" name="UML95">UML95</a>
- </td>
- <td colspan="2">
- G. Booch and J. Rumbaugh 1995. <i>Unified Method for Object-Oriented Development.</i> Documentation
- set, version 0.8, Rational Software Corporation.
- </td>
- </tr>
- </tbody>
- </table>
-</div>
-<br />
-<h2 align="left">
- <a id="Object-Oriented Technology references" name="Object-Oriented Technology references">Object-Oriented
- Technology</a>
-</h2>
-<div align="center">
- <table width="100%" summary="layout table" border="0">
- <tbody>
- <tr>
- <td valign="top" width="12%">
- <a id="BOO93" name="BOO93">BOO93</a>
- </td>
- <td colspan="2">
- Grady Booch 1993. <i>Object-Oriented Analysis and Design with Applications,</i> 2nd edition. Redwood
- City, CA: The Benjamin/Cummings Publishing Company.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="BUH96" name="BUH96">BUH96</a>
- </td>
- <td colspan="2">
- R. J. A. Buhr and R. S. Casselman 1996. <i>Use Case Maps for Object-Oriented Systems.</i> Upper Saddle
- River, NJ: Prentice-Hall.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- This book develops some other views on use cases.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="JAC92" name="JAC92">JAC92</a>
- </td>
- <td colspan="2">
- Ivar Jacobson, et al. 1992. <i>Object-Oriented Software Engineering-A Use Case-Driven Approach</i>,
- Wokingham, England: Addison Wesley Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="RUM91" name="RUM91">RUM91</a>
- </td>
- <td colspan="2">
- James Rumbaugh, et al. 1991. <i>Object-Oriented Modeling and Design.</i> Upper Saddle River, NJ:
- Prentice-Hall.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- The three books above are the original roots to the object-oriented analysis and design discipline from
- "the three amigos", just before the advent of the UML and the RUP. Despite the use of their original
- notations, they are still the key references for OO designers.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="RUM96" name="RUM96">RUM96</a>
- </td>
- <td colspan="2">
- James Rumbaugh 1996. <i>OMT Insights.</i> New York: SIGS Books.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- A complement to the original&nbsp; OMT book, diving into special topics: inheritance, use cases, and so
- on.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="SEL94" name="SEL94">SEL94</a>
- </td>
- <td colspan="2">
- Bran Selic, Garth Gullekson, and Paul Ward 1994. <i>Real-time Object-Oriented Modeling.</i> New York,
- NY: John Wiley &amp; Sons, Inc.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- The reference work on using object technology for the design of reactive systems by the people who have
- brought us <i>ObjecTime Developer</i>.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="WIR90" name="WIR90">WIR90</a>
- </td>
- <td colspan="2">
- Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener 1990. <i>Designing Object-Oriented
- Software.</i> Upper Saddle River, NJ: Prentice-Hall.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- This book describes the Class, Responsibility, Collaboration (CRC) approach to object-oriented software
- development.
- </td>
- </tr>
- </tbody>
- </table>
-</div>
-<br />
-<h2 align="left">
- <a id="Project Management references" name="Project Management references">Project Management</a>
-</h2>
-<div align="center">
- <table width="100%" summary="layout table" border="0">
- <tbody>
- <tr>
- <td valign="top" width="12%">
- <a id="AMI95" name="AMI95">AMI95</a>
- </td>
- <td colspan="2">
- K. Pulford, A. Kuntzmann-Combelles, and S. Shirlaw 1995. <i>A Quantitative Approach to Software
- Management-The AMI Handbook.</i> Addison Wesley Longman.&nbsp;
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="BOE00" name="BOE00">BOE00</a>
- </td>
- <td colspan="2">
- Barry W. Boehm et al, 2000. Software Cost Estimation with COCOMO II. Upper Saddle River, NJ:
- Prentice-Hall.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- The successor to the original classic work.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="BOE81" name="BOE81">BOE81</a>
- </td>
- <td colspan="2">
- Barry W. Boehm 1981. <i>Software Engineering Economics.</i> Upper Saddle River, NJ: Prentice-Hall.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- A classic work on software effort estimation that describes the original COCOMO estimation model.
- </td>
- </tr>
- <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>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Still the best little introduction to risk management.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="BOO95" name="BOO95">BOO95</a>
- </td>
- <td colspan="2">
- Grady Booch 1995. <i>Object Solutions-Managing the Object-Oriented Project.</i> Addison Wesley Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- A pragmatic book for managers of object-oriented projects; one of the sources on the underlying
- philosophy of the RUP.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="CAN01" name="CAN01">CAN01</a>
- </td>
- <td colspan="2">
- Murray Cantor 2001. <i>Software Leadership.</i> Addison-Wesley Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="CAR93" name="CAR93">CAR93</a>
- </td>
- <td colspan="2">
- Marvin J. Carr, et al. 1993. <i>Taxonomy-Based Risk Identification,</i> Technical Report
- CMU/SEI-93-TR-6, Pittsburgh, PA, SEI, June 1993, 24p.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Provides a source of inspiration to get started on your own list of risks.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="CHA89" name="CHA89">CHA89</a>
- </td>
- <td colspan="2">
- Robert Charette 1989. <i>Software Engineering Risk Analysis and Management.</i> New York, NY:
- McGraw-Hill.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Practical perspective on risk management.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="CHID94" name="CHID94">CHID94</a>
- </td>
- <td colspan="2">
- Chidamber and Kemerer 1994. <i>A metrics suite for object-oriented design,</i> IEEE Transactions on
- Software Engineering, 20(6), 1994.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- One of the original contributions to the field of OO software metrics.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="CLE96" name="CLE96">CLE96</a>
- </td>
- <td colspan="2">
- Robert T. Clemen 1996. <i>Making Hard Decisions: An Introduction to Decision Analysis.</i> Duxbury
- Press.&nbsp;
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Thorough yet accessible treatment of the fundamentals of decision analysis.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="DEV95" name="DEV95">DEV95</a>
- </td>
- <td colspan="2">
- Michael T. Devlin and Walker E. Royce.&nbsp; <i>Improving Software Economics in the Aerospace and
- Defense Industry,</i> Technical Paper TP-46, Santa Clara, CA, Rational Software Corporation, 1995.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="EVA98" name="EVA98">EVA98</a>
- </td>
- <td colspan="2">
- James R. Evans and David L. Olson 1998. <i>Introduction to Simulation and Risk Analysis.</i>&nbsp;
- Upper Saddle River, NJ: Prentice-Hall.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Good introduction to the use of simulation for business modeling.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="FAI94" name="FAI94">FAI94</a>
- </td>
- <td colspan="2">
- Richard Fairley 1994. "Risk Management for Software Project," <i>IEEE Software,</i> 11 (3), May 1994,
- pp.57-67
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Straightforward strategy for risk management if you have never done this before.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="GIL88" name="GIL88">GIL88</a>
- </td>
- <td colspan="2">
- Tom Gilb 1988. <i>Principles of Software Engineering Management.</i> 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>
- <tr>
- <td valign="top" width="12%">
- <a id="HEND96" name="HEND96">HEND96</a>
- </td>
- <td colspan="2">
- Brian Henderson-Sellers 1996. <i>Object-Oriented Metrics, Measures of Complexity.</i> Prentice Hall
- PTR.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Good, detailed coverage of OO-specific metrics.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="JON94" name="JON94">JON94</a>
- </td>
- <td colspan="2">
- Capers Jones 1994. <i>Assessment and Control of Software Risks.</i> Yourdon Press.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- An indispensable source of risks to check your list against to make sure it's is complete.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="KAR96" name="KAR96">KAR96</a>
- </td>
- <td colspan="2">
- Dale Karolak 1996. <i>Software Engineering Risk Management.</i> Los Alamitos, CA: IEEE Computer Society
- Press.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Offers more sophisticated advice and techniques for risk management.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="MCO96" name="MCO96">MCO96</a>
- </td>
- <td colspan="2">
- Steve McConnell 1996. <i>Rapid Development.</i> Redmond, WA: Microsoft Press.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Excellent coverage of good practice for rapid software development
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="MSP97" name="MSP97">MSP97</a>
- </td>
- <td colspan="2">
- User's Guide for Microsoft Project 98, Microsoft Corporation, 1997.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="OCO94" name="OCO94">OCO94</a>
- </td>
- <td colspan="2">
- Fergus O'Connell 1994. <i>How to Run Successful Projects.</i> New York, NY: Prentice-Hall
- International.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- A real gem! Everything you really need to know to manage your first project, in 170 pages.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="PMI96" name="PMI96">PMI96</a>
- </td>
- <td colspan="2">
- <i>A Guide to the Project Management Body of Knowledge.</i> The Project Management Institute: Newton
- Square, PA, 19073-3299, USA. 1996.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="PUT92" name="PUT92">PUT92</a>
- </td>
- <td colspan="2">
- Lawrence Putnam &amp; Ware Myers 1992. <i>Measures for Excellence: Reliable Software On Time, Within
- Budget.</i> Yourdon Press.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="ROY98" name="ROY98">ROY98</a>
- </td>
- <td colspan="2">
- Walker Royce 1998. <i>Software Project Management: A Unified Framework.</i> Addison Wesley Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- An indispensable companion to the RUP, this book describes the spirit of the Rational Process and its
- underlying software economics. Full of great advice for the project manager.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="VOS96" name="VOS96">VOS96</a>
- </td>
- <td colspan="2">
- David Vose 1996. <i>Quantitative Risk Analysis: A Guide to Monte Carlo Simulation Modeling.</i> John
- Wiley &amp; Sons.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- A good guide to the modeling of uncertainty using Monte Carlo techniques.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="WHIT97" name="WHIT97">WHIT97</a>
- </td>
- <td colspan="2">
- Scott Whitmire 1997. <i>Object-Oriented Design Measurement.</i> John Wiley &amp; Sons, Inc.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- A good, if mathematically challenging, treatment of the theoretical basis of software measurement.
- </td>
- </tr>
- </tbody>
- </table>
-</div>
-<br />
-<h2 align="left">
- <a id="Requirement Management references" name="Requirement Management references">Requirements Management</a>
-</h2>
-<div align="center">
- <table width="100%" summary="layout table" border="0">
- <tbody>
- <tr>
- <td valign="top" width="12%">
- <a id="AND96" name="AND96">AND96</a>
- </td>
- <td colspan="2">
- Stephen J. Andriole 1996. <i>Managing Systems Requirements: Methods, Tools, and Cases.</i> McGraw Hill.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="BEY98" name="BEY98">BEY98</a>
- </td>
- <td colspan="2">
- Hugh Beyer and Karen Holtzblatt 1998. <i>Contextual Design.</i> San Francisco, CA: Morgan Kaufmann
- Publishers.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="BIT03" name="BIT03">BIT03</a>
- </td>
- <td colspan="2">
- Kurt Bittner and Ian Spence 2003. <i>Use Case Modeling.</i> Addison Wesley Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Comprehensive coverage of use case techniques and practices, including useful examples showing how
- use-case specifications evolve over time.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="COC01a" name="COC01a">COC01a</a>
- </td>
- <td colspan="2">
- Alistair Cockburn 2001. <i>Writing Effective Use Cases.</i> Addison Wesley Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Excellent guidance for those who need to write use cases. Multiple styles and techniques contrasted
- with insight in an unbiased way. Many helpful tips to improve your use cases.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="CON99" name="CON99">CON99</a>
- </td>
- <td colspan="2">
- Larry Constantine and Lucy A.D. Lockwood 1999. <i>Software for Use.</i> Reading, MA: Addison Wesley
- Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- An excellent book on user-centric design, focusing on techniques and practical guidelines for
- developing software that is usable.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="COO99" name="COO99">COO99</a>
- </td>
- <td colspan="2">
- Alan Cooper1999. <i>The Inmates are Running the Asylum.</i> Indianapolis, IN: SAMS.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="DAV93" name="DAV93">DAV93</a>
- </td>
- <td colspan="2">
- Alan Davis 1993. <i>Software Requirements-Objects, Functions and States.</i> Englewood Cliffs, NJ:
- Prentice Hall.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="FIS91" name="FIS91">FIS91</a>
- </td>
- <td colspan="2">
- Roger Fisher and William Ury 1991. <i>Getting to Yes-Negotiating Agreement Without Giving In, 2nd
- Edition.</i> Penguin Books USA.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="GAU89" name="GAU89">GAU89</a>
- </td>
- <td colspan="2">
- Donald Gause and Gerald Weinberg 1989. <i>Exploring Requirements-Quality Before Design.</i> New York,
- NY: Dorset House.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="GOU88" name="GOU88">GOU88</a>
- </td>
- <td colspan="2">
- John D. Gould 1988. "How to Design Usable Systems", in Helander, Martin, ed. <i>Handbook of Computer
- Interaction</i>, pp. 757-789, North-Holland, Amsterdam, The Netherlands.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="GOU87" name="GOU87">GOU87</a>
- </td>
- <td colspan="2">
- John D. Gould, Stephen J. Boies, Stephen Levy, John T. Richards and Jim Schoonard 1987. "The 1984
- Olympic Message System: a test of behavioral principles of system design", in <i>Communications of the
- ACM</i>, Vol. 30, No. 9, pp. 758-769.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="GRA92" name="GRA92">GRA92</a>
- </td>
- <td colspan="2">
- Robert Grady 1992. <i>Practical Software Metrics for Project Management and Process Improvement</i>.
- Prentice-Hall.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%" height="28">
- <a id="HOL96" name="HOL96">HOL96</a>
- </td>
- <td width="88%" colspan="2" height="28">
- Holtzblatt, K., and H. Beyer 1996. "Contextual Design: Principles and Practice," <i>Field Methods for
- Software and Systems Design</i>. D. Wixon and J. Ramey (Eds.), NY, NY: John Wiley &amp; Sons, Inc.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="IE830" name="IE830">IE830</a>
- </td>
- <td colspan="2">
- IEEE Std 830-1993. <i>Recommended Practice for Software Requirements Specifications.</i> Software
- Engineering Standards Committee of the IEEE Computer Society: New York, NY, 1993.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="ISO13407" name="ISO13407">ISO13407</a>
- </td>
- <td colspan="2">
- ISO/TC159 1999. <i>Human-centred design processes for interactive systems.</i> Report ISO 13407:1999,
- International Organization for Standardization, Geneva, Switzerland.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="KOV99" name="KOV99">KOV99</a>
- </td>
- <td colspan="2">
- Benjamin L. Kovitz 1999. <i>Practical Software Requirements-A Manual of Content &amp; Style.</i>
- Manning Publications.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="LEF99" name="LEF99">LEF99</a>
- </td>
- <td colspan="2">
- Dean Leffingwell and Don Widrig 1999. <i>Effective Requirements Management.</i> Addison Wesley Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%" height="21">
- <a id="MAY99" name="MAY99">MAY99</a>
- </td>
- <td width="88%" colspan="2" height="21">
- Deborah J. Mayhew1999. <i>The Usability Engineering Lifecycle.</i> Morgan Kaufmann Publishers.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="SCH98" name="SCH98">SCH98</a>
- </td>
- <td colspan="2">
- Geri Schneider and Jason P. Winters 1998. <i>Applying Use Cases-A Practical Guide.</i> Addison Wesley
- Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="SOM97" name="SOM97">SOM97</a>
- </td>
- <td colspan="2">
- Ian Sommerville and Pete Sawyer 1997. <i>Requirements Engineering-A Good Practice Guide.</i> New York,
- NY: John Wiley &amp; Sons, Inc.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="THA97" name="THA97">THA97</a>
- </td>
- <td colspan="2">
- Richard H. Thayer and Merlin Dorfman 1997. <i>Software Requirements Engineering, 2nd Edition.</i> IEEE
- Computer Society Press.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="WEI95" name="WEI95">WEI95</a>
- </td>
- <td colspan="2">
- Gerald Weinberg, 1995. "Just Say No! Improving the Requirements Process", <i>American Programmer</i>,
- October 1995.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- </tbody>
- </table>
-</div>
-<br />
-<h2 align="left">
- <a id="Software Architecture references" name="Software Architecture references">Software Architecture</a>
-</h2>
-<div align="center">
- <table width="100%" summary="layout table" border="0" valign="top">
- <tbody>
- <tr>
- <td valign="top" width="12%">
- <a id="BAS98" name="BAS98">BAS98</a>
- </td>
- <td colspan="2">
- Len Bass, Paul Clements, and Rick Kazman 1998. <i>Software Architecture in Practice.</i> Addison Wesley
- Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- A handbook of software architecture, with numerous case studies.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="BOS00" name="BOS00">BOS00</a>
- </td>
- <td colspan="2">
- Jan Bosch 2000. <i>Design and Use of Software Architecture.</i> Addison Wesley Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="BUS96" name="BUS96">BUS96</a>
- </td>
- <td colspan="2">
- Frank Buschmann, Régine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stahl 1996.
- <i>Pattern-Oriented Software Architecture-A System of Patterns</i>, New York, NY: John Wiley and Sons,
- Inc.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Following the model of the "gang of four" book (Gamma, et al, see above) this book makes an inventory
- of a wide range of design patterns at the level of the architecture.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="CKK02" name="CKK02">CKK02</a>
- </td>
- <td colspan="2">
- Paul Clements, Rick Kazman, and Mark Klein 2002. <i>Evaluating Software Architecture</i>, Addison
- Wesley Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="CLE02" name="CLE02">CLE02</a>
- </td>
- <td colspan="2">
- Paul Clements et al. 2002. <i>Documenting Software Architectures: Views and Beyond</i>, Addison Wesley
- Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="CLN02" name="CLN02">CLN02</a>
- </td>
- <td colspan="2">
- Paul Clements and Linda Northrop 2002. <i>Software Product Lines: Practice and Patterns</i>, Addison
- Wesley Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- The preceding three books are from the Software Engineering Institute's architecture study group.
- <i>Evaluating Software Architecture</i> provides useful input for architectural reviews. <i>Documenting
- Software Architectures: Views and Beyond</i> fully embraces the concept of views and helps with
- developing a Software Architecture document.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="DIK01" name="DIK01">DIK01</a>
- </td>
- <td colspan="2">
- David M. Dikel, David Kane, and James R. Wilson 2001. <i>Software Architecture - Organizational
- Principles and Patterns</i>, Prentice-Hall.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Describes the VRAPS model of architecting: Vision, Rhythm, Anticipation, Partnering, and
- Simplification. This is a good reference for the budding architect to put his or her role in context.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="FOW97a" name="FOW97a">FOW97a</a>
- </td>
- <td colspan="2">
- Martin Fowler 1997. <i>Analysis Patterns: Reusable Object Models.</i> Addison Wesley Longman.&nbsp;
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="GAM94" name="GAM94">GAM94</a>
- </td>
- <td colspan="2">
- Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides 1994. <i>Design Patterns-Elements of
- Reusable Object-Oriented Software.</i> Addison Wesley Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- One of the earlier works on patterns, this book deals with patterns "in the small".
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="GAR93" name="GAR93">GAR93</a>
- </td>
- <td colspan="2">
- David Garlan and Mary Shaw. <i>An Introduction to Software Architecture.&nbsp;</i> SEI Technical Report
- CMU/SEI-94-TR-21.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="HOF99" name="HOF99">HOF99</a>
- </td>
- <td colspan="2">
- Christine Hofmeister, Robert Nord, and Dilip Soni 1999. <i>Applied Software Architecture.</i> Addison
- Wesley Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Proposes an alternate set of architectural views and describes the corresponding process. As the views
- are not too far from the RUP views, this book is an excellent complement to the guidance found in RUP.
- Contains several examples of architecture from the biomedical field.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="IEP1471" name="IEP1471">IEP1471</a>
- </td>
- <td colspan="2">
- <i>IEEE Recommended Practice for Architectural Description</i>, IEEE Std P1471, 2000.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- This standard recommends architectural description based on the concept of multiple views, of which the
- RUP 4+1 view is an example.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="JAC97" name="JAC97">JAC97</a>
- </td>
- <td colspan="2">
- Ivar Jacobson, Martin Griss and Patrik Jonsson, 1997. <i>Software Reuse-Architecture, Process and
- Organization for Business Success</i>. 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 companion book to the RUP, this book offers insights on the design of components and systems of
- interconnected system, and lays out a strategy for institutionalizing a practice of systematic reuse at
- the corporate level.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="KRU95" name="KRU95">KRU95</a>
- </td>
- <td colspan="2">
- Philippe Kruchten 1995, "The 4+1 view model of architecture," <i>IEEE Software.</i> 12(6), November
- 1995.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- The origin of the 4+1 views used for architectural description in the RUP.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="LMFS96" name="LMFS96">LMFS96</a>
- </td>
- <td colspan="2">
- Lockheed Martin Federal STARS (Software Technology for Adaptable, Reliable Systems) Program. Domain
- Engineering Guidebook.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- This Guidebook provides a high-level description of the Domain Engineering&nbsp; process in the context
- of a real organization-the U.S. Air Force's Space and Warning Systems Center.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="PW92" name="PW92">PW92</a>
- </td>
- <td colspan="2">
- Dewayne E. Perry and Alexander L. Wolf. <i>Foundations for the Study of Software Architecture.</i> ACM
- SIGSOFT Software Engineering Notes, 17(4):40-52, October 1992.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="REC97" name="REC97">REC97</a>
- </td>
- <td colspan="2">
- Eberhardt Rechtin and Mark Maier 1997. <i>The Art of System Architecting.</i> Boca Ration, FL: CRC
- Press.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Although not specifically directed to software engineers, these two books are extremely valuable for
- software architects: in particular, they introduce an invaluable set of heuristics and many examples of
- architecture.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="REC91" name="REC91">REC91</a>
- </td>
- <td colspan="2">
- Eberhardt Rechtin 1991. <i>Systems Architecting: creating and building complex systems</i>. Englewood
- Cliffs NJ: Prentice-Hall.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="ROY91" name="ROY91">ROY91</a>
- </td>
- <td colspan="2">
- Walker E. Royce and Winston Royce, "Software Architecture: Integrating Process and Technology,"
- <i>Quest,</i> 14 (1), 1991, Redondo Beach, CA: TRW, pp.2-15.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="SHA96" name="SHA96">SHA96</a>
- </td>
- <td colspan="2">
- Mary Shaw and David Garlan 1996. <i>Software Architecture-Perspectives on an Emerging Discipline.</i>
- Upper Saddle River, NJ: Prentice-Hall.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- A good introduction to the concepts and problems of software architecture.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="WIT94" name="WIT94">WIT94</a>
- </td>
- <td colspan="2">
- Bernard I. Witt, F. Terry Baker, and Everett W. Merritt 1994. <i>Software Architecture and
- Design-Principles, Models, and Methods.</i> New York, NY: Van Nostrand Reinhold.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- One of the first comprehensive book written on software architecture.
- </td>
- </tr>
- </tbody>
- </table>
-</div>
-<br />
-<h2>
- <a id="Software Development Process references" name="Software Development Process references">Software Development
- Process</a>
-</h2>
-<div align="center">
- <table width="100%" summary="layout table" border="0">
- <tbody>
- <tr>
- <td valign="top" width="12%">
- <a id="AMB99" name="AMB99">AMB99</a>
- </td>
- <td colspan="2">
- Scott W. Ambler 1999. <i>More Process Patterns: Delivering Large-Scale Systems Using Object
- Technology</i>. New York, NY: SIGS Books/Cambridge University Press.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- The companion to [AMB98].
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="AMB98" name="AMB98">AMB98</a>
- </td>
- <td colspan="2">
- Scott W. Ambler 1998. <i>Process Patterns: Building Large-Scale Systems Using Object Technology</i>.
- New York, NY: SIGS Books/Cambridge University Press.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- A good resource on process tailoring and applying object-oriented techniques to software engineering
- projects.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="BOE96" name="BOE96">BOE96</a>
- </td>
- <td colspan="2">
- Barry W. Boehm 1996, "Anchoring the Software Process," <i>IEEE Software,</i> July 1996, pp.73-82.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- This article defines the four phases and the corresponding milestones.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="BOE88" name="BOE88">BOE88</a>
- </td>
- <td colspan="2">
- Barry W. Boehm 1988, "A Spiral Model of Software Development and Enhancement," <i>Computer,</i> May
- 1988, IEEE, pp.61-72.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- This seminal article defines the principles and motivations of iterative development.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="COC01" name="COC01">COC01</a>
- </td>
- <td colspan="2">
- Alistair Cockburn 2001. <i>Agile Software Development</i> Addison-Wesley Publishing Co.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Peers into the team dynamics, the cultures, the communications aspects of software development.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="DOD94" name="DOD94">DOD94</a>
- </td>
- <td colspan="2">
- <i>Software Development and Documentation,</i> MIL-STD-498, U.S. Department of Defense, December 1994.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="FER01" name="FER01">FER01</a>
- </td>
- <td colspan="2">
- Xavier Ferre et al. 2001, "Usability Basics for Software Developers," <i>IEEE Software,</i> January
- 2001, pp. 22-29.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="HIG00" name="HIG00">HIG00</a>
- </td>
- <td colspan="2">
- James A. Highsmith 2000. <i>Adaptive Software Development: A Collaborative Approach to Managing Complex
- Systems</i>. Dorset House.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- This book is a great companion book to the RUP-a fantastic and convincing plea for iterative
- development. Very practical advice for the project manager.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="HUM89" name="HUM89">HUM89</a>
- </td>
- <td colspan="2">
- Watts S. Humphrey 1989. <i>Managing the Software Process</i>. Reading, MA: Addison Wesley Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- A classic book on software process and the capability maturity model developed at the Software
- Engineering Institute.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="ISO95" name="ISO95">ISO95</a>
- </td>
- <td colspan="2">
- ISO/IEC 12207 <i>Information Technology-Software Life-cycle Processes.</i> ISO, Geneva, 1995, 57p.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="ISO91" name="ISO91">ISO91</a>
- </td>
- <td colspan="2">
- ISO 9000-3 <i>Guidelines for the Application of ISO 9001 to the Development, Supply, and Maintenance of
- Software.</i> ISO, Geneva 1991.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Two key standards for software process definition and assessment.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="JAC98" name="JAC98">JAC98</a>
- </td>
- <td colspan="2">
- Ivar Jacobson, Grady Booch, and James Rumbaugh 1998. <i>The Unified Software Development Process.</i>
- Addison Wesley Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- This recent textbook is a more thorough description of the Unified Process and is a useful companion to
- the RUP. Also provides examples of UML modeling.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="JAC97" name="JAC97">JAC97</a>
- </td>
- <td colspan="2">
- Ivar Jacobson, Martin Griss, and Patrik Jonsson 1997. <i>Software Reuse-Architecture, Process and
- Organization for Business Success.</i> Addison Wesley Longman.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- This textbook on software reuse is great complement to the RUP. It features also some great chapters on
- architecture.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="JEF01" name="JEF01">JEF01</a>
- </td>
- <td colspan="2">
- Ron Jeffries, Ann Anderson, and Chet Hendrickson 2001. <i>Extreme Programming Installed.</i>
- Addison-Wesley.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- This book describes practical Extreme Programming techniques.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="KRU96" name="KRU96">KRU96</a>
- </td>
- <td colspan="2">
- Philippe Kruchten 1996. "A Rational Development Process"<i>,</i> <i>CrossTalk</i>, 9 (7), July 1996,
- p.11-16.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Developed with Walker Royce, Sue Mickel, and a score of Rational consultants, this article describes
- the iterative lifecycle of the Rational Process.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="KRU91" name="KRU91">KRU91</a>
- </td>
- <td colspan="2">
- Philippe Kruchten 1991. "Un processus de dévelopment de logiciel itératif et centré sur
- l´architecture", <i>Proceedings of the 4th International Conference on Software Engineering, December
- 1991</i>, Toulouse, France, EC2.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- The Rational iterative process in French.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="KRU00" name="KRU00">KRU00</a>
- </td>
- <td colspan="2">
- Philippe Kruchten 2000. <i>The Rational Unified Process, An Introduction, Second Edition.</i> Addison
- Wesley Longman.&nbsp;
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Indespensible as an introductory text, this "mile wide, inch deep" overview quickly introduces you to
- the concepts, structure, content, and motivation of the RUP.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="KRO03" name="KRO03">KRO03</a>
- </td>
- <td colspan="2">
- Per Kroll and Philippe Kruchten 2003. <i>The Rational Unified Process Made Easy, A Practitioners Guide
- to the RUP.</i> Addison Wesley Longman.&nbsp;
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- A practical guide to adopting the spirit, principles and practices of the RUP. An invaluable resource
- in helping you decide how to apply the RUP in your organization or project.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="MCF96" name="MCF96">MCF96</a>
- </td>
- <td colspan="2">
- Robert McFeeley 1996. <i>IDEAL: A User's Guide for Software Process Improvement.</i> Software
- Engineering Institute, Pittsburgh, PA, CMU/SEI-96-HB-001.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Describes a software process improvement program model called IDEAL, a generic description of a
- sequence of recommended steps for initiating and managing a process implementation project.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="PAR86" name="PAR86">PAR86</a>
- </td>
- <td colspan="2">
- David L. Parnas and Paul C. Clements, "A Rational Design Process: How and Why to Fake It", <i>IEEE
- Trans. Software Eng.,</i> Feb. 1986, pp.251-257.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="PAU93" name="PAU93">PAU93</a>
- </td>
- <td colspan="2">
- Mark Paulk, et al. 1993. <i>Capability Maturity Model for Software, Version 1.1.</i> Software
- Engineering Institute, Pittsburgh, PA SEI-93-TR-024.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- The original reference for the capability maturity model.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="ROY90" name="ROY90">ROY90</a>
- </td>
- <td colspan="2">
- Walker E. Royce, "TRW's Ada Process Model for Incremental Development of Large Software Systems",
- <i>Proceedings ICSE 12, March 26-30, 1990,</i> Nice, France, IEEE, pp.2-11.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="ROY70" name="ROY70">ROY70</a>
- </td>
- <td colspan="2">
- Winston W. Royce, "Managing the Development of Large Software Systems: Concepts and Techniques",
- <i>Proceedings, WESCON</i>, August 1970.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- </tbody>
- </table>
-</div>
-<br />
-<h2 align="left">
- <a id="Testing and Quality references" name="Testing and Quality references">Testing and Quality</a>
-</h2>
-<div align="center">
- <table width="100%" summary="layout table" border="0">
- <tbody>
- <tr>
- <td valign="top" width="12%">
- <a id="BAC01a" name="BAC01a">BAC01a</a>
- </td>
- <td colspan="2">
- James Bach 2001. <i>What Is Exploratory Testing? (And How It Differs from Scripted Testing).</i>
- Software Testing and Quality Engineering Magazine, Jan 29, 2001.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- This article is available online at <a
- href="http://www.stickyminds.com/sitewide.asp?sid=582697&amp;sqry=%2AJ%28MIXED%29%2AR%28createdate%29%2AK%28simplesite%29%2AF%28what+is+exploratory+testing%29%2A&amp;sidx=0&amp;sopp=10&amp;ObjectId=2255&amp;Function=DETAILBROWSE&amp;ObjectType=COL"
- target="_blank">http://www.stickyminds.com</a>.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="BAS87" name="BAS87">BAS87</a>
- </td>
- <td colspan="2">
- BAS87 Victor R. Basili and H. Dieter Rombach 1987. <i>Tailoring the Software Process to Project Goals
- and Environments.</i> Proceedings of the 9th International Conference on Software Engineering Software,
- IEEE Press.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="BEI95" name="BEI95">BEI95</a>
- </td>
- <td colspan="2">
- Boris Beizer 1995. <i>Black Box Testing.</i> New York, NY: John Wiley &amp; Sons, Inc.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Various strategies to develop test cases for the functional testing of software. Dr. Beizer's writing
- style and wit make this book easy and fun to read, with excellent, understandable examples.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="BLA99" name="BLA99">BLA99</a>
- </td>
- <td colspan="2">
- Rex Black 1999. <i>Managing the Testing Process.</i> Microsoft Press.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- This book is a good source of information about managing system testing teams.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="GLA81" name="GLA81">GLA81</a>
- </td>
- <td colspan="2">
- Robert L. Glass 1981. <i>Persistent Software Errors.</i> IEEE Transactions on Software Engineering,
- March 1981.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="IE829" name="IE829">IE829</a>
- </td>
- <td colspan="2">
- IEEE 829-1983 <i>Standard for Software Test Documentation.</i> Software Engineering Standards Committee
- of the IEEE Computer Society, New York.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="KAN01" name="KAN01"></a>KAN01
- </td>
- <td colspan="2">
- Cem Kaner, James Bach, and Bret Pettichord 2001. <i>Lessons Learned in Software Testing.</i> John Wiley
- &amp; Sons, Inc.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- A wealth of tips and tricks that help to address a wide variety of issues faced in the testing of
- computer software. Broad coverage of management, psychological as well as the technical aspects of
- software testing. Valuable guidance for the novice and the expert alike.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="KAN99" name="KAN99"></a>KAN99
- </td>
- <td colspan="2">
- Cem Kaner, Jack Falk, and Hung Quoc Nguyen 1999. <i>Testing Computer Software, 2nd Edition.</i> John
- Wiley &amp; Sons, Inc.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="12%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Billed as "The best-selling software testing book of all time", this book offers a broad coverage of
- various aspects of software testing.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="MAR00" name="MAR00">MAR00</a>
- </td>
- <td colspan="2">
- Brian Marick 2000. <i>Faults of Omission.</i> Software Testing and Quality Engineering Magazine,
- March-April 2000.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="12%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- This article is available online at: <a href="http://www.testing.com/writings/omissions.pdf"
- target="_blank">http://www.testing.com/writings/omissions.pdf</a>.<br />
- (<a href="http://www.adobe.com/products/acrobat/alternate.html" target="_blank">Get Adobe Reader</a>)
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="MYE79" name="MYE79">MYE79</a>
- </td>
- <td colspan="2">
- Glenford J. Myers 1979. <i>The Art of Software Testing</i>, John Wiley &amp; Sons, Inc., New York.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- This is one of the classic works of software testing literature. Even today this timelesss text offers
- useful, practical, and relevent guidance.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="OST84" name="OST84">OST84</a>
- </td>
- <td colspan="2">
- Thomas J. Ostrand and Elaine J. Weyuker 1984. <i>Collecting and Categorizing Software Error Data in an
- Industrial Environment.</i> Journal of Systems and Software, Vol. 4, 1984.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- </tbody>
- </table>
-</div>
-<br />
-<br />
-<br />
-<br />
-<br />
-<br />
-<br />
-<br />
-<br />
-<br />
-<br />
-<br />
-<br />
-<br />
-<br />
-<br />
-<br />
-<br />
-<br />
-<br />
-<br />
-<br />
-<br />
-<br />
-<br />
-<br /></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/customcategories/resources/circleOfLife.jpg b/XP/xp/customcategories/resources/circleOfLife.jpg
deleted file mode 100644
index 3772826..0000000
--- a/XP/xp/customcategories/resources/circleOfLife.jpg
+++ /dev/null
Binary files differ
diff --git a/XP/xp/customcategories/resources/extreme_programming,5.2637267673584526E-306.html b/XP/xp/customcategories/resources/extreme_programming,5.2637267673584526E-306.html
deleted file mode 100644
index 3eb88af..0000000
--- a/XP/xp/customcategories/resources/extreme_programming,5.2637267673584526E-306.html
+++ /dev/null
@@ -1,273 +0,0 @@
-<html xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
-<head>
-<META http-equiv="Content-Type" content="text/html; charset=UTF-8">
-<title>Concept: Extreme Programming</title>
-<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
-<meta name="element_type" content="concept">
-<meta content="description" name="filetype">
-<meta name="role" content="">
-<link type="text/css" href="./../../../css/default.css" rel="StyleSheet">
-<script src="./../../../scripts/contentpage.js" type="text/javascript" language="JavaScript"></script><script type="text/javascript" language="JavaScript">
- backPath = './../../../';
- </script>
-</head>
-<body onload="createSectionLinks('div', 'sectionHeading', './../../../images/');">
-<table width="100%" cellspacing="0" cellpadding="0" border="0">
-<tr>
-<td valign="top"><a name="Top"></a>
-<table cellpadding="0" cellspacing="0" border="0">
-<tr>
-<td class="pageTitle">Concept: Extreme Programming</td>
-</tr>
-</table>
-<table cellspacing="0" cellpadding="0" border="0" width="100%">
-<tr>
-<td class="pageTitleSeparator"><img height="1" alt="" src="./../../../images/shim.gif"></td>
-</tr>
-</table>
-<div class="overview">
-<table cellpadding="0" cellspacing="0" border="0" width="97%">
-<tr>
-<td>
-<table cellpadding="0" cellspacing="0" border="0" class="overviewTable">
-<tr>
-<td valign="top"></td>
-</tr>
-</table>
-</td>
-</tr>
-</table>
-</div>
-<div class="sectionHeading">Main Description</div>
-<div class="sectionContent">
-<table cellpadding="0" cellspacing="0" border="0" class="sectionTable">
-<tr valign="top">
-<td class="sectionTableCell"><a id="XE_xp__conceptual_process_roadmap" name="XE_xp__conceptual_process_roadmap"></a><a id="XE_roadmap__for_xp_practices" name="XE_roadmap__for_xp_practices"></a>
-<h3>
- Topics
-</h3>
-<div align="left">
- <table width="70%" border="1">
- <tbody valign="top">
- <tr>
- <td width="315" height="178">
- <ul>
- <li>
- <a href="#Introduction">Introduction</a>
- </li>
- <li style="LIST-STYLE-TYPE: none">
- <ul>
- <li>
- <a href="#About">About XP</a>
- </li>
- </ul>
- </li>
- </ul>
- <p>
- <br />
- <br />
- </p>
- <ul>
- <li>
- <a href="#Characteristics">Characteristics of an XP Project</a>
- </li>
- <li>
- <a href="#GettingStarted">How to Get Started</a>
- </li>
- <li>
- <a href="#Phases">Phases and Iterations</a>
- </li>
- </ul>
- </td>
- <td width="315" height="178">
- <b>Additional Guidance:</b>
- <ul>
- <li>
- Guidelines
- <ul>
- <li>
- <a class="elementLink" href="./../../../xp/guidances/guidelines/refactoring,8.137126904637637E-306.html" guid="8.137126904637637E-306">Refactoring</a>
- </li>
- <li>
- <a class="elementLinkWithUserText" href="./../../../xp/guidances/guidelines/test_driven_development_tdd,3.9254165491375454E-306.html" guid="3.9254165491375454E-306">Test First Development</a>
- </li>
- <li>
- <a class="elementLinkWithUserText" href="./../../../xp/guidances/guidelines/pair_programming,3.85153041801319E-307.html" guid="3.85153041801319E-307">Pair Programming</a>
- </li>
- <li>
- <a class="elementLinkWithUserText" href="./../../../xp/guidances/guidelines/planning_game,6.7335956461328426E-307.html" guid="6.7335956461328426E-307">Planning Game</a>
- </li>
- <li style="LIST-STYLE-TYPE: none">
- <br />
- <br />
- </li>
- </ul>
- </li>
- <li>
- <a class="elementLinkWithUserText" href="./../../../xp/guidances/supportingmaterials/bup_xp_plug-in_resource_center,2.315717433735515E-305.html" guid="2.315717433735515E-305">Additional XP Resources</a>
- </li>
- </ul>
- <b>Additional Concepts:</b>
- <ul>
- <li>
- <a class="elementLink" href="./../../../xp/guidances/concepts/agile_software_development,1.041091673844025E-305.html" guid="1.041091673844025E-305">Agile Software Development</a>
- </li>
- </ul>
- </td>
- </tr>
- </tbody>
- </table>
-</div>
-<br />
-<br />
-<h1>
- <a id="Introduction" name="Introduction">Introduction</a>
-</h1>
-<p>
- This roadmap provides information for getting started and applying the practices of eXtreme Programming (XP) to a
- software development project. The roadmap can be used as a guide to the content delivered in the BUP XP Plug-In.
-</p>
-<h3>
- <a id="About" name="About">About XP</a>
-</h3>
-<p>
- Extreme Programming is an instance of an <a class="elementLink" href="./../../../xp/guidances/concepts/agile_software_development,1.041091673844025E-305.html" guid="1.041091673844025E-305">Agile Software Development</a> method. XP is a method that is optimized for small to
- medium-sized project teams that fit a certain profile. It promotes rapid feedback and response to continual change. It
- is based upon the four <a class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/xp_values,1.076140803519123E-306.html" guid="1.076140803519123E-306">values</a> of simplicity, communication, feedback, and courage and is consistent with the
- values of agile software development.
-</p>
-<br />
-<p>
- Extreme Programming is an instance of an agile method for developing software. It is based upon the core principle of
- agility and consists of twelve practices that, when applied to an appropriate software development project, can produce
- high-quality software. If you are unfamiliar with the concepts surrounding XP, you should start by reading <a class="elementLink" href="./../../../xp/guidances/concepts/agile_software_development,1.041091673844025E-305.html" guid="1.041091673844025E-305">Agile Software Development</a>.
-</p>
-<h3>
- <a id="Characteristics" name="Characteristics">Characteristics of an XP Project</a>
-</h3>
-<p>
- Extreme Programming or XP is a development process that can be used by small to medium-sized teams to develop high
- quality software within a predictable schedule and budget and with a minimum of overhead. Since XP relies heavily on
- direct and frequent communication between the team members, the team should be co-located. An ideal project for using
- XP would be one that has most of the following characteristics:
-</p>
-<ul>
- <li>
- A small to medium-sized team (fewer than 20 people on the complete team)
- </li>
- <li>
- Co-located, preferably in a single area with a large common space
- </li>
- <li>
- A committed, full-time, on-site customer or customer representative
- </li>
- <li style="LIST-STYLE-TYPE: none">
- <br />
- </li>
-</ul>
-<h3>
- <a id="Phases" name="Phases">Phases and Iterations</a>
-</h3>
-<p>
- An XP project is one that is based on rapid feedback through short iterations and frequent releases. BUP and XP share a
- fundamental belief that iterative development is the best way to deliver valuable software to your customers. The
- concept of phases, as usually described in a BUP configuration, is somewhat different. Decisions described in the BUP
- phases that define milestones occur, but they are not called specifically as defining phases. For a discussion of how
- the phases are related to an XP project, see the discussion of <a class="elementLinkWithUserText" href="./../../../xp/deliveryprocesses/bup_phases_and_xp,{63BD15C5-40EF-469A-A22A-3291734B60F4}.html" guid="{63BD15C5-40EF-469A-A22A-3291734B60F4}">Phases</a>.
-</p>
-<h3>
- <a id="GettingStarted" name="GettingStarted">How to Get Started</a>
-</h3>
-<p>
- This section provides a recommended way to approach XP for your project. You don't have to follow the steps as
- specified, but if you have little experience with XP, we recommend following them as closely as possible the first
- time.
-</p>
-<table cellspacing="2" cellpadding="1" width="91%" border="1">
- <tbody>
- <tr>
- <th width="10%">
- Step
- </th>
- <th align="left" width="47%">
- Do this ...
- </th>
- <th align="left" width="43%">
- in order to...
- </th>
- </tr>
- <tr>
- <td align="middle" width="10%">
- 1
- </td>
- <td width="47%">
- Familiarize yourself with the <a class="elementLink" href="./../../../xp/guidances/concepts/motivation,1.6390805262958034E-306.html" guid="1.6390805262958034E-306">motivation</a> for using XP, the <a class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/what_is_xp,9.251272550276345E-306.html" guid="9.251272550276345E-306">short description</a> of XP, and the <a class="elementLink" href="./../../../xp/guidances/concepts/xp_practices,2.2937799026801584E-305.html" guid="2.2937799026801584E-305">XP Practices</a>
- </td>
- <td width="43%">
- understand the fundamental principles of XP and how the practices support each other.
- </td>
- </tr>
- <tr>
- <td align="middle" width="10%">
- 2
- </td>
- <td width="47%">
- Read the key concepts of <a class="elementLink" href="./../../../xp/guidances/concepts/agile_software_development,1.041091673844025E-305.html" guid="1.041091673844025E-305">Agile Software Development</a>
- </td>
- <td width="43%">
- understand the collaborative and social aspects of XP.
- </td>
- </tr>
- <tr>
- <td align="middle" width="10%">
- 3
- </td>
- <td width="47%">
- Determine if XP is appropriate for your project by reviewing <a href="#Characteristics">The Characteristics
- of an XP Project</a>
- </td>
- <td width="43%">
- decide if XP may be appropriate for your project.
- </td>
- </tr>
- <tr>
- <td align="middle" width="10%">
- 4
- </td>
- <td width="47%">
- Read about the <a class="elementLinkWithUserText" href="./../../../xp/guidances/guidelines/xp_environment,3.754748120034442E-307.html" guid="3.754748120034442E-307">XP Environment</a>.
- </td>
- <td width="43%">
- prepare the physical and tool environment for your team.
- </td>
- </tr>
- <tr>
- <td align="middle" width="10%">
- 5
- </td>
- <td width="47%">
- Read the <a class="elementLink" href="./../../../xp/guidances/supportingmaterials/getting_started_with_xp,1.2284921351651456E-304.html" guid="1.2284921351651456E-304">Getting Started with XP</a> guidelines.
- </td>
- <td width="43%">
- get suggestions on how to start an XP project.
- </td>
- </tr>
- </tbody>
-</table>
-<br />
-<br />
-<br />
-<br /></td>
-</tr>
-</table>
-</div>
-<table cellpadding="0" cellspacing="0" border="0" class="copyright">
-<tr>
-<td class="copyright"></td>
-</tr>
-</table>
-</td>
-</tr>
-</table>
-</body>
-</html>
diff --git a/XP/xp/customcategories/resources/xp_getting_started_guidelines.htm b/XP/xp/customcategories/resources/xp_getting_started_guidelines.htm
deleted file mode 100644
index 983817c..0000000
--- a/XP/xp/customcategories/resources/xp_getting_started_guidelines.htm
+++ /dev/null
@@ -1,79 +0,0 @@
-<!-- RPW META DATA START --
-<rpw name="MetaData" meta_value="anonymous" meta_name="element_type"></rpw>
-<rpw name="MetaData" meta_value="guideline" meta_name="filetype"></rpw>
--- RPW META DATA END -->
-
-<html>
-
-<head>
-<link rel="stylesheet" href="../../../rop.css" type="text/css">
-<title>Guidelines: <rpw name="InsertPresentationName"></rpw></title>
-<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
-</head>
-
-
-<body>
-
-<rpw name="Warning"><b>!RPW INCLUDE! DO NOT MOVE/MODIFY !RPW INCLUDE!</b><br></rpw>
-<rpw name="Include">rpw/startBorder.rpw</rpw>
-<rpw name="Warning"><br><b>!RPW INCLUDE! DO NOT MOVE/MODIFY !RPW INCLUDE!</b></rpw>
-
-
-<h1 class="banner"><a name="Top"></a>Guidelines: <rpw name="PresentationName">Adopting
- XP Practices</rpw> <a name="XE_xp__adopting_practices"></a><a name="XE_adopting_practices__in_xp"></a></h1>
-<p>XP is a set of synergistic practices. Because the practices depend upon each
- other, people often wonder where they should start. In general, we recommend
- that you stop and consciously decide to adopt as many of the XP practices as
- possible.</p>
-<p>However, if that induces too much stress, consider adopting the practices in
- this order.</p>
-<p><b><a href="../../../components/pc_xp_essentials/pc_xp_integration/co_continuous_integration.htm">Establish
- a solid build process</a></b>. If you are not able to reliably build the software
- you are working on, you can&8217;t really go further. Once you have a reliable
- build process, make sure that you run whatever <a href="../../../components/pc_xp_essentials/pc_xp_testing/co_customer_tests.htm">tests</a>
- you have prior to each checking.</p>
-<p><b><a href="../../../components/pc_xp_essentials/pc_xp_programming/co_pair_program.htm">Pair
- programming</a></b> is often a significantly different way of working for most
- developers. It takes a little bit of time to get used to it, but as a team does,
- they recognize that they are a much more powerful team because everyone’s
- knowledge of the system grows rapidly. In addition, quality goes up because
- there are two sets of eyes on all work as it is being done. When you adopt pair
- programming, ideally you should have an <a href="../../../components/pc_xp_essentials/pc_xp_management/xp_open_workspace_guidelines.htm">open
- workspace</a>.</p>
-<p>As your team gets started with pair programming, you should adopt the <b><a href="../../../components/pc_xp_essentials/co_planning_game.htm">Planning
- Game</a></b>. The Planning Game will help you identify good goals for your next
- release, iteration, and day of work. At the end of your first iteration, you
- will have a velocity that you can use to get a sense of how long it takes you
- do do your work. As you do your planning, talk to your customer about producing
- acceptance tests and being available to the team.</p>
-<p>As you work together on your first iteration, try doing <a href="../../../components/pc_xp_essentials/co_test_driven_development.htm"><b>test-driven
- development</b></a>. It will feel strange at first. If it doesn’t, you
- are probably doing it wrong. Over time, it will feel like a more natural way
- to develop software. Recognize that, at first, your velocity will be rather
- low. This is a side effect of the learning process. Over the next few iterations
- your speed will increase.</p>
-<p>As you move forward, learn how to <a href="../../../components/pc_xp_essentials/pc_xp_programming/co_refactoring.htm"><b>refactor</b></a>
- and start to practice <a href="../../../components/pc_xp_essentials/co_collective_code_ownership.htm"><b>collective
- code ownership</b></a>. Often collective code ownership is a little scary at
- first, but as you pair, you will notice that everyone is learning what it takes
- to work with the system. When people volunteer for tasks, they either volunteer
- only for what they know how to do or for things that they can get help on from
- a partner.</p>
-<p>Once you have a few iterations under your belt, you will be able to understand
- how the process works and how the different practices interact and support each
- other. Finally, listen to the feedback coming from your team. That feedback
- is critical and can be used to improve and adapt the process to your team’s
- particular needs and problems.</p>
-
-
-<p><br/><br/></p>
-
-<rpw name="Warning"><b>!RPW INCLUDE! DO NOT MOVE/MODIFY !RPW INCLUDE!</b><br></rpw>
-<rpw name="Include">rpw/endBorderOmRat.rpw</rpw>
-<rpw name="Include">rpw/endBorder.rpw</rpw>
-<rpw name="Warning"><br><b>!RPW INCLUDE! DO NOT MOVE/MODIFY !RPW INCLUDE!</b></rpw>
-
-</body>
-
-</html>
-
diff --git a/XP/xp/customcategories/resources/xp_practices,2.2937799026801584E-305.html b/XP/xp/customcategories/resources/xp_practices,2.2937799026801584E-305.html
deleted file mode 100644
index f77493f..0000000
--- a/XP/xp/customcategories/resources/xp_practices,2.2937799026801584E-305.html
+++ /dev/null
@@ -1,115 +0,0 @@
-<html xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
-<head>
-<META http-equiv="Content-Type" content="text/html; charset=UTF-8">
-<title>Concept: XP Practices</title>
-<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
-<meta name="element_type" content="concept">
-<meta content="description" name="filetype">
-<meta name="role" content="">
-<link type="text/css" href="./../../../css/default.css" rel="StyleSheet">
-<script src="./../../../scripts/contentpage.js" type="text/javascript" language="JavaScript"></script><script type="text/javascript" language="JavaScript">
- backPath = './../../../';
- </script>
-</head>
-<body onload="createSectionLinks('div', 'sectionHeading', './../../../images/');">
-<table width="100%" cellspacing="0" cellpadding="0" border="0">
-<tr>
-<td valign="top"><a name="Top"></a>
-<table cellpadding="0" cellspacing="0" border="0">
-<tr>
-<td class="pageTitle">Concept: XP Practices</td>
-</tr>
-</table>
-<table cellspacing="0" cellpadding="0" border="0" width="100%">
-<tr>
-<td class="pageTitleSeparator"><img height="1" alt="" src="./../../../images/shim.gif"></td>
-</tr>
-</table>
-<div class="overview">
-<table cellpadding="0" cellspacing="0" border="0" width="97%">
-<tr>
-<td>
-<table cellpadding="0" cellspacing="0" border="0" class="overviewTable">
-<tr>
-<td valign="top"></td>
-</tr>
-</table>
-</td>
-</tr>
-</table>
-</div>
-<div class="sectionHeading">Main Description</div>
-<div class="sectionContent">
-<table cellpadding="0" cellspacing="0" border="0" class="sectionTable">
-<tr valign="top">
-<td class="sectionTableCell"><a id="XE_xp__practices_of" name="XE_xp__practices_of"></a><a id="XE_practices_in__xp" name="XE_practices_in__xp"></a>
-<p>
- XP is a collection of guiding values and best practices. Most of these practices have been used in the industry in some
- shape or form for a number of years. XP has simply identified them and tried to push the envelope of these practices in
- order to get the most benefit from them. Taken individually, these practices are all fairly simple. But it is the sum
- of all of them that provides the most benefit as they reinforce each other to address the most difficult problems teams
- encounter when developing software.
-</p>
-<br />
-<br />
-<p>
- <img height="540" alt="" src="./../../../xp/resources/circleOfLife.jpg" width="720" usemap="#xp_practices_image_map" border="0" /> <map id="xp_practices_image_map" name="xp_practices_image_map">
- <area shape="RECT" coords="298,19,390,88" href="./../../../xp/guidances/concepts/whole_team,7.89591827591278E-306.html" />
- <area shape="RECT" coords="176,135,282,200" href="./../../../xp/guidances/concepts/collective_ownership,9.300699588493279E-306.html" />
- <area shape="RECT" coords="297,168,434,231" href="./../../../xp/guidances/concepts/test_driven_development,1.620567348185129E-306.html" />
- <area shape="RECT" coords="447,135,547,198" href="./../../../xp/guidances/concepts/coding_standard,8.8116853923311E-307.html" />
- <area shape="RECT" coords="15,236,122,305" href="./../../../xp/guidances/concepts/customer_tests,2.297945473205673E-305.html" />
- <area shape="RECT" coords="218,238,362,307" href="./../../../xp/guidances/concepts/pair_programming,3.876855509996079E-307.html" />
- <area shape="RECT" coords="392,241,512,305" href="./../../../xp/guidances/concepts/refactoring_xp_programming,1.4410217108363206E-306.html" />
- <area shape="RECT" coords="614,236,714,302" href="./../../../xp/guidances/concepts/planning_game,2.7371805612676613E-305.html" />
- <area shape="RECT" coords="143,325,270,393" href="./../../../xp/guidances/concepts/continuous_integration,3.193414568279561E-305.html" />
- <area shape="RECT" coords="310,321,412,379" href="./../../../xp/guidances/concepts/simple_design,1.6109092258980447E-306.html" />
- <area shape="RECT" coords="468,323,597,393" href="./../../../xp/guidances/concepts/xp_sustainable_pace,3.133529870649493E-306.html" />
- <area shape="RECT" coords="307,386,413,436" href="./../../../xp/guidances/concepts/metaphor_system_of_names,4.884861766532753E-306.html" />
- <area shape="RECT" coords="312,475,419,539" href="./../../../xp/guidances/concepts/small_releases,5.762953011420275E-306.html" />
- <area shape="RECT" target="_blank" coords="561,494,708,538" href="http://www.xprogramming.com" />
- </map>
-</p>
-<p>
- This diagram arranges the core practices of Extreme Programming in a way that makes them easy to remember and that
- exemplifies the steering and control cycles of the process.
-</p>
-<p>
- The outer red circle is called the "Circle of Life". It's what keeps an XP project going, producing tested working
- software. The <a class="elementLink" href="./../../../xp/guidances/concepts/whole_team,7.89591827591278E-306.html" guid="7.89591827591278E-306">Whole Team</a>, customer members and development members, work together--preferably
- physically together--to build the project. Using the <a class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/planning_game,2.7371805612676613E-305.html" guid="2.7371805612676613E-305">Planning Game</a> elements of Release Planning and Iteration Planning, they plan a
- series of <a class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/small_releases,5.762953011420275E-306.html" guid="5.762953011420275E-306">Small
- Releases</a> of software that demonstrably pass all the <a class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/customer_tests,2.297945473205673E-305.html" guid="2.297945473205673E-305">Customer Tests</a>.
-</p>
-<p>
- The innermost blue circle describes the day to day, moment to moment, work of the XP developers. Each feature is
- addressed with <a class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/simple_design,1.6109092258980447E-306.html" guid="1.6109092258980447E-306">Simple Design</a>, ensuring that the design of the system is just right for the features
- supported. The programmers work in <a class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/pair_programming,3.876855509996079E-307.html" guid="3.876855509996079E-307">pairs</a> for all production code development, providing continuous code review and
- valuable, team-wide understanding of the system. They build the software using <a class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/test_driven_development,1.620567348185129E-306.html" guid="1.620567348185129E-306">Test-Driven Development,</a> a technique that produces well-crafted and well-tested
- software with a minimum of wasted effort, and the design is kept clean by the continuous improvement process of <a class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/refactoring_xp_programming,1.4410217108363206E-306.html" guid="1.4410217108363206E-306">Refactoring</a>.
-</p>
-<p>
- The middle green circle contains the important supporting practices of XP. The software is designed according to a
- common, shared, evolving <a class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/metaphor_system_of_names,4.884861766532753E-306.html" guid="4.884861766532753E-306">Metaphor</a> that helps it all hang together. It is kept <a class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/continuous_integration,3.193414568279561E-305.html" guid="3.193414568279561E-305">continuously integrated</a> with many system builds every day, each one fully tested. The
- team shares ownership of of all the code so that needed changes can be made by any qualified pair, not just by one
- individual. Since everyone works on everything, the team evolves a <a class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/coding_standard,8.8116853923311E-307.html" guid="8.8116853923311E-307">standard
- way of coding</a>. Finally, XP teams work at a <a class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/xp_sustainable_pace,3.133529870649493E-306.html" guid="3.133529870649493E-306">sustainable pace</a> that enables them to deliver tested software on a predictable basis
- from the first day of the project until the last.
-</p>
-<p>
- <br />
-
-</p></td>
-</tr>
-</table>
-</div>
-<table cellpadding="0" cellspacing="0" border="0" class="copyright">
-<tr>
-<td class="copyright"></td>
-</tr>
-</table>
-</td>
-</tr>
-</table>
-</body>
-</html>
diff --git a/XP/xp/customcategories/xp_best_practices.xmi b/XP/xp/customcategories/xp_best_practices.xmi
deleted file mode 100644
index b1d62db..0000000
--- a/XP/xp/customcategories/xp_best_practices.xmi
+++ /dev/null
@@ -1,83 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-LVHbtWMGC3pAL9abD018MA" name="xp_best_practices,4.315031901943112E-306" guid="-LVHbtWMGC3pAL9abD018MA" changeDate="2006-12-01T15:22:33.700-0800" version="1.0.0">
- <mainDescription><p>
- Extreme Programming is based on core values of <a class="elementLinkWithUserText"
- href="./../../xp/guidances/concepts/xp_values,1.076140803519123E-306.html" guid="1.076140803519123E-306">communication,
- simplicity, feedback, and courage</a>. These are not just buzzwords: they pervade the behavior of XP practitioners and
- the choice of XP practices.
-</p>
-<p>
- More than anything else, XP is about people, people coming together and working together to build software. The
- practices of XP are there to enable people to work together; the practices try never to get in the way of the human
- enterprise of building software that meets business needs. Thus, the practices of XP, while quite disciplined, are
- there to enable interactions among individuals, never to replace or interfere with those interactions.
-</p>
-<h3>
- XP Practices
-</h3>
-<p>
- <b><a class="elementLinkWithUserText" href="./../../xp/guidances/concepts/xp_practices,2.2937799026801584E-305.html"
- guid="2.2937799026801584E-305">Overview</a></b>
-</p>
-<ul>
- <li>
- <a class="elementLink" href="./../../xp/guidances/concepts/whole_team,7.89591827591278E-306.html"
- guid="7.89591827591278E-306">Whole Team</a>
- </li>
- <li>
- <a class="elementLinkWithUserText" href="./../../xp/guidances/concepts/planning_game,2.7371805612676613E-305.html"
- guid="2.7371805612676613E-305">Planning Game</a>
- </li>
- <li>
- <a class="elementLinkWithUserText" href="./../../xp/guidances/concepts/small_releases,5.762953011420275E-306.html"
- guid="5.762953011420275E-306">Small Releases</a>
- </li>
- <li>
- <a class="elementLinkWithUserText" href="./../../xp/guidances/concepts/customer_tests,2.297945473205673E-305.html"
- guid="2.297945473205673E-305">Customer Tests</a>
- </li>
- <li>
- <a class="elementLinkWithUserText" href="./../../xp/guidances/concepts/simple_design,1.6109092258980447E-306.html"
- guid="1.6109092258980447E-306">Simple Design</a>
- </li>
- <li>
- <a class="elementLinkWithUserText"
- href="./../../xp/guidances/concepts/pair_programming,3.876855509996079E-307.html"
- guid="3.876855509996079E-307">Pair Programming</a>
- </li>
- <li>
- <a class="elementLinkWithUserText"
- href="./../../xp/guidances/concepts/test_driven_development,1.620567348185129E-306.html"
- guid="1.620567348185129E-306">Test Driven Development</a>
- </li>
- <li>
- <a class="elementLinkWithUserText"
- href="./../../xp/guidances/concepts/refactoring_xp_programming,1.4410217108363206E-306.html"
- guid="1.4410217108363206E-306">Refactoring</a>
- </li>
- <li>
- <a class="elementLinkWithUserText"
- href="./../../xp/guidances/concepts/metaphor_system_of_names,4.884861766532753E-306.html"
- guid="4.884861766532753E-306">Metaphor</a>
- </li>
- <li>
- <a class="elementLinkWithUserText"
- href="./../../xp/guidances/concepts/continuous_integration,3.193414568279561E-305.html"
- guid="3.193414568279561E-305">Continuous Integration</a>
- </li>
- <li>
- <a class="elementLinkWithUserText"
- href="./../../xp/guidances/concepts/collective_ownership,9.300699588493279E-306.html"
- guid="9.300699588493279E-306">Collective Ownership</a>
- </li>
- <li>
- <a class="elementLinkWithUserText" href="./../../xp/guidances/concepts/coding_standard,8.8116853923311E-307.html"
- guid="8.8116853923311E-307">Coding Standard</a>
- </li>
- <li>
- <a class="elementLinkWithUserText"
- href="./../../xp/guidances/concepts/xp_sustainable_pace,3.133529870649493E-306.html"
- guid="3.133529870649493E-306">Sustainable Pace</a>
- </li>
-</ul></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/customcategories/xp_roles_and_tasks.xmi b/XP/xp/customcategories/xp_roles_and_tasks.xmi
deleted file mode 100644
index fc6b18a..0000000
--- a/XP/xp/customcategories/xp_roles_and_tasks.xmi
+++ /dev/null
@@ -1,94 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-c5D4uYtVcDvab8GzkO0HiQ" name="xp_roles_and_activities,3.967980776087095E-306" guid="-c5D4uYtVcDvab8GzkO0HiQ" changeDate="2006-11-29T16:43:23.824-0800" version="1.0.0">
- <mainDescription><a id="XE_activities__overview_of_xp_and_rup_activities" name="XE_activities__overview_of_xp_and_rup_activities"></a>
-<div align="left">
- <table width="75%" border="1">
- <tbody>
- <tr>
- <td width="6%" rowspan="2">
- &nbsp;
- </td>
- <td align="middle" colspan="5">
- <a class="elementLink" href="./../../xp/guidances/concepts/whole_team,7.89591827591278E-306.html"
- guid="7.89591827591278E-306">Whole Team</a>
- </td>
- </tr>
- <tr>
- <td align="middle" colspan="2">
- <a class="elementLink"
- href="./../../xp/guidances/supportingmaterials/xp_customer_team,2.9889538140050517E-306.html"
- guid="2.9889538140050517E-306">XP Customer Team</a>
- </td>
- <td align="middle">
- <a class="elementLink"
- href="./../../xp/guidances/supportingmaterials/xp_developer_team,8.608243854485154E-306.html"
- guid="8.608243854485154E-306">XP Developer Team</a>
- </td>
- <td align="middle" colspan="2">
- <a class="elementLink"
- href="./../../xp/guidances/supportingmaterials/xp_organization,5.613949040902463E-308.html"
- guid="5.613949040902463E-308">XP Organization</a>
- </td>
- </tr>
- <tr>
- <td align="middle">
- <b>XP Roles</b>
- </td>
- <td align="middle" width="17%">
- <a class="elementLinkWithUserText"
- href="./../../xp/roles/xp_customer,{3C90DD4F-CFDB-4111-922D-3B840B8942DE}.html"
- guid="{3C90DD4F-CFDB-4111-922D-3B840B8942DE}">Customer</a>
- </td>
- <td align="middle">
- <a class="elementLinkWithUserText"
- href="./../../xp/roles/xp_tester,{FB65D00B-8304-4CF7-9969-52CE82F503DC}.html"
- guid="{FB65D00B-8304-4CF7-9969-52CE82F503DC}">Tester</a>
- </td>
- <td align="middle">
- <a class="elementLinkWithUserText"
- href="./../../xp/roles/xp_programmer,{08A6AF28-69B1-42DC-A957-2E6CDCB436C1}.html"
- guid="{08A6AF28-69B1-42DC-A957-2E6CDCB436C1}">Programmer</a>
- </td>
- <td align="middle" width="13%">
- <a class="elementLinkWithUserText"
- href="./../../xp/roles/xp_tracker,{D8FE277E-4F9A-47EB-855F-C451D601BBAF}.html"
- guid="{D8FE277E-4F9A-47EB-855F-C451D601BBAF}">Tracker</a>
- </td>
- <td align="middle" width="12%">
- <a class="elementLinkWithUserText"
- href="./../../xp/roles/xp_coach,{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}.html"
- guid="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">Coach</a>
- </td>
- </tr>
- </tbody>
- </table>
- <br />
-</div>
-<br />
-<h3>
- XP Roles and Tasks
-</h3>
-<p>
- XP defines a more limited set of roles and tasks than Unified Process. The XP roles usually have much broader scope
- than Unified Process roles. There is a definite push in XP to move away from specialization where only one person on a
- team has knowledge of specific and critical parts of the system or technology. The consequence is that the XP roles
- usually map to more than one Unified Process role. Some Unified Process roles/tasks/artifacts do not map to anything in
- XP as XP has a somewhat smaller scope than Unified Process.
-</p>
-<h4>
- Definition of Roles and Tasks in Unified Process
-</h4>
-<p>
- <b>Roles</b> are typically realized by an individual or a set of individuals working together as a team. A project team
- member typically fulfills many different roles. <b>Roles</b> are not individuals; instead, they describe how
- individuals behave in the business and what responsibilities these individuals have. While most roles are realized by
- people within the organization, people outside of the development organization play an important role. A <b>role</b> is
- an abstract definition of a set of <b>tasks</b> performed and <b>artifacts</b> generated.
-</p>
-<p>
- <b>Roles</b> have a set of cohesive&nbsp;<b>tasks</b> to be performed. These&nbsp;<b>tasks</b> are closely related and
- functionally coupled and are often best performed by the same individual.&nbsp;Tasks are closely related to
- <b>artifacts</b>. Artifacts provide the input and output for the&nbsp;tasks and the mechanism by which information is
- communicated between tasks.
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/customcategories/xp_white_papers.xmi b/XP/xp/customcategories/xp_white_papers.xmi
deleted file mode 100644
index af9d616..0000000
--- a/XP/xp/customcategories/xp_white_papers.xmi
+++ /dev/null
@@ -1,20 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-_GqtAEsGnq12qQmyqWdHHQ" name="xp_white_papers,6.505229665845286E-306" guid="-_GqtAEsGnq12qQmyqWdHHQ" changeDate="2005-12-06T04:42:48.153-0800">
- <mainDescription><p>
- Additional white papers related to XP can be found at:
-</p>
-<p>
- White papers relate to the <a href="http://www.objectmentor.com/processImprovement/xpRupResourceCenter/index%20">BUP XP
- Plug-In Resource Center</a>.
-</p>
-<p>
- White papers related to Agile methods and Object Oriented Programming at <a
- href="http://www.objectmentor.com/resources" target="_blank">http://www.objectmentor.com/resources</a><a
- href="http://www.objectmentor.com"></a>
-</p>
-<br />
-<br />
-<br />
-<br />
-<br /></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/concepts/agile_software_development.xmi b/XP/xp/guidances/concepts/agile_software_development.xmi
deleted file mode 100644
index 934aba0..0000000
--- a/XP/xp/guidances/concepts/agile_software_development.xmi
+++ /dev/null
@@ -1,76 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-EHSlFv7Gla5oCPGBiaZKow" name="agile_software_development,1.041091673844025E-305" guid="-EHSlFv7Gla5oCPGBiaZKow" changeDate="2006-11-29T15:32:13.357-0800" version="1.0.0">
- <mainDescription><a id="XE_agile_software_development__process_differentiators"
-name="XE_agile_software_development__process_differentiators"></a>
-<h2>
- <a id="Intro" name="Intro">Introduction</a>
-</h2>
-<p>
- Extreme Programming is probably the best known and very likely the most used of what have come to be known as agile
- software development methods. There are many software professionals working on agile methods today. There have been
- several international conferences on agile methods, numerous papers, many websites, and quite a few books. We'll key
- our discussion from the Agile Manifesto at <a href="http://www.agilemanifesto.org"
- target="_blank">www.agilemanifesto.org</a>.
-</p>
-<p>
- We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have
- come to value:
-</p>
-<h2>
- <a id="Individuals" name="Individuals">Individuals and Interactions Over Processes and Tools</a>
-</h2>
-<p>
- Processes and tools are very important. We wouldn't be writing this and you wouldn't be reading it were that not true.
- The best processes and tools, we believe, are those that enable the individuals who are part of a software project to
- do their job most effectively. To do that, the processes and tools need to facilitate the human interactions that bring
- about understanding and cooperation. The agile methods use the smallest amount of process that's safe and the simplest
- tools that are effective in aid of those individuals and interactions.
-</p>
-<h2>
- <a id="Working" name="Working">Working Software Over Comprehensive Documentation</a>
-</h2>
-<p>
- Documentation can be very important to a software project. Sometimes it's the only way to communicate ideas across
- space and time. For an ongoing software project, however, there is a much better way to know what's going on and to
- steer the project.
-</p>
-<p>
- Observe the software. The software can be tested, used, and inspected, and all the answers you get are unambiguous. The
- agile methods focus on keeping the software visible, beginning as early as possible. The best XP projects begin
- producing tested visible software in the first couple of weeks of the project and never stop.
-</p>
-<h2>
- <a id="Customer" name="Customer">Customer Collaboration Over Contract Negotiation</a>
-</h2>
-<p>
- Many software projects require a contract, and all benefit from a clear understanding of what will be done. Attempts to
- over-constrain the initial understanding, however, almost always backfire. Too often, the result can be a "letter of
- the law" product that pleases neither the developers nor the users. Agile methods recognize that all stakeholders will
- be learning over the course of the project. Agile projects are thus set up to facilitate learning and to take advantage
- of it.
-</p>
-<h2>
- <a id="Responding" name="Responding">Responding to Change Over Following a Plan</a>
-</h2>
-<p>
- Too many changes of direction can cause a project to go out of control, costing too much or never finishing. Initial
- plans, however, cannot know which potential changes should be accommodated and which ignored. Agile methods address
- this issue in two ways:
-</p>
-<p>
- First, they respond to change by planning publicly and often. Small changes are dealt with in frequent in-team small
- planning sessions, while the big picture is published and processed by all stakeholders, again very frequently.
-</p>
-<p>
- Second, the development techniques in the agile methods generally allow stakeholders to substitute new and better ideas
- for earlier notions without exorbitant increases in costs.
-</p>
-<h2>
- <a id="Summary" name="Summary">Summary</a>
-</h2>
-<p>
- As you study Extreme Programming and as you use it, it's important to keep these agile values in mind. As you tune and
- adjust the process to your situation, working with the values will enable you to get the best results from the least
- effort.
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/concepts/coding_standard.xmi b/XP/xp/guidances/concepts/coding_standard.xmi
deleted file mode 100644
index d5f0a6b..0000000
--- a/XP/xp/guidances/concepts/coding_standard.xmi
+++ /dev/null
@@ -1,33 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="--qg2qc3dqmgeB63Nx7Zndg" name="coding_standard,8.8116853923311E-307" guid="--qg2qc3dqmgeB63Nx7Zndg" changeDate="2006-11-09T16:13:06.585-0800" version="1.0.0">
- <mainDescription><a id="XE_xp__coding_standard" name="XE_xp__coding_standard"></a><a id="XE_coding_standard__practice_of"
-name="XE_coding_standard__practice_of"></a><a id="XE_engineering_practices__coding_standard"
-name="XE_engineering_practices__coding_standard"></a>
-<h3>
- Description
-</h3>
-<p>
- Using a coding standard is a software development practice that has been widely accepted in the industry. The need for
- this practice takes on added importance in XP because of the increased level of communication required by collective
- ownership, pair programming and the constant refactoring of the code. 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.
-</p>
-<p>
- Ideally, the coding standard should be the result of team consensus. In some cases, decisions will be arbitrary
- (placement of braces). 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. Pair
- programming and collective code ownership is sufficient to reinforce the use of the standard within the team. With
- time, the team will use and modify the standard to develop a style that is well adapted to their environment.
-</p>
-<h3>
- Benefits
-</h3>
-<ul>
- <li>
- <b>Improved communication</b>: increases the ability to read each other's code.
- </li>
- <li>
- <b>Refactoring support</b>: provides consistently shaped code.
- </li>
-</ul></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/concepts/collective_ownership.xmi b/XP/xp/guidances/concepts/collective_ownership.xmi
deleted file mode 100644
index 23cdb73..0000000
--- a/XP/xp/guidances/concepts/collective_ownership.xmi
+++ /dev/null
@@ -1,36 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-YP0i7TC6QNgemddcj1iE7g" name="collective_ownership,9.300699588493279E-306" guid="-YP0i7TC6QNgemddcj1iE7g" changeDate="2006-11-13T14:36:27.348-0800" version="1.0.0">
- <mainDescription><a id="XE_xp__collective_ownership" name="XE_xp__collective_ownership"></a><a id="XE_collective_ownership__practice_of"
-name="XE_collective_ownership__practice_of"></a><a id="XE_engineering_practices__collective_ownership"
-name="XE_engineering_practices__collective_ownership"></a>
-<h3>
- Description
-</h3>
-<p>
- The practice of collective ownership states that any member of the team can change any piece of code in the system at
- any time.
-</p>
-<p>
- Having a good suite of tests and being able to integrate continuously is critical to ensuring that this practice works
- well. Without the tests, it would be impossible to know that a critical piece of the system was modified improperly
- because of inappropriate understanding. Integrating frequently and testing ensures that such problems are caught and
- fixed quickly. Used with pair programming, collective code ownership is an effective way to spread the knowledge of the
- system across the entire team.
-</p>
-<h3>
- Benefits
-</h3>
-<ul>
- <li>
- <b>Shared knowledge of the code</b>: allows programmers to become familiar with more of the code and benefit from
- the experience of others.
- </li>
- <li>
- <b>Simpler code</b>: causes complex code to be found and refactored more quickly as many pairs of eyes read the
- same code.
- </li>
- <li>
- <b>Get things done quickly</b>: removes hurdles so changes can be made by those that need them when they need them.
- </li>
-</ul></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/concepts/continuous_integration.xmi b/XP/xp/guidances/concepts/continuous_integration.xmi
deleted file mode 100644
index ed5830f..0000000
--- a/XP/xp/guidances/concepts/continuous_integration.xmi
+++ /dev/null
@@ -1,43 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-35rZhRLEVuTVI4280ncN0A" name="continuous_integration,3.193414568279561E-305" guid="-35rZhRLEVuTVI4280ncN0A" changeDate="2006-11-08T16:55:42.002-0800" version="1.0.0">
- <mainDescription><a id="XE_xp__continuous_integration" name="XE_xp__continuous_integration"></a><a
-id="XE_continuous_integration__practice_of" name="XE_continuous_integration__practice_of"></a><a
-id="XE_engineering_practices__continuous_integration" name="XE_engineering_practices__continuous_integration"></a>
-<h3>
- Description
-</h3>
-<p>
- One of the goals of XP is to ensure that the customer can feel and touch actual progress that reflects the investment
- to date. As the team builds the software incrementally according to the customer's priority, the new functionality is
- continuously integrated and demonstrated to the customer.
-</p>
-<p>
- Integration in XP can happen several times a day. As developers finish some work, they integrate what they have done.
- Typically, integration is done on an integration machine in order to serialize the process. Integration is supported by
- unit tests and acceptance tests. When a pair of programmers first sits at the integration machine, the current code
- base passes all tests. They start by integrating their changes into the code and checking for conflicts. Then, they run
- all tests. Should any test fail, the pair is responsible for fixing the code and making it pass. Since the tests were
- all passed before, the failures are in some way related to the modifications that have made to the code. Once all the
- tests have passed, the integration can be considered a success and another pair can now integrate its changes. The
- integrated build can then be handed over to the customer, who can see the new functionality on a running system.
-</p>
-<p>
- This practice obviously requires the use of tools and an environment that supports fast integration/build/test cycles.
-</p>
-<h3>
- Benefits
-</h3>
-<ul>
- <li>
- <b>Simplified and faster integrations</b>: reduces important conflicts associated with big bang integration and
- insures that people are working with the latest version of the code.
- </li>
- <li>
- <b>Improved feedback</b>: shows constant and demonstrable progress (it takes a running system to pass the
- customer's acceptance tests).
- </li>
- <li>
- <b>System always shippable</b>: the latest version of the system passing all tests is always available.
- </li>
-</ul></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/concepts/customer_tests.xmi b/XP/xp/guidances/concepts/customer_tests.xmi
deleted file mode 100644
index 1d9ff82..0000000
--- a/XP/xp/guidances/concepts/customer_tests.xmi
+++ /dev/null
@@ -1,31 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-oW2j2l-rXqHeWPIgjPpbng" name="customer_tests,2.297945473205673E-305" guid="-oW2j2l-rXqHeWPIgjPpbng" changeDate="2006-11-10T09:32:51.048-0800" version="1.0.0">
- <mainDescription><a id="XE_xp__customer_tests" name="XE_xp__customer_tests"></a><a id="XE_customer_tests__practice_of"
-name="XE_customer_tests__practice_of"></a><a id="XE_engineering_practices__customer_tests"
-name="XE_engineering_practices__customer_tests"></a>
-<h3>
- Description
-</h3>
-<p>
- One of the rights in the customer bill of rights tells the customer he will be able to see progress in the form of a
- working system that passes repeatable tests that he specifies. These tests are what we call the Customer Tests. The
- customer specifies one or more Customer Tests for each user story in the system, describing in detail how each story is
- expected to work. Because the tests are put into executable form and are fully automated, they tell programmers what
- needs to be done in a unambiguous way (tests pass or fail) and allow the customer to feel confident that the system is
- meeting his needs.
-</p>
-<h3>
- Benefits
-</h3>
-<ul>
- <li>
- Ability to see <b>tangible and verifiable progress</b>.
- </li>
- <li>
- <b>Ultimate traceability</b>: the Customer Tests are executable system requirements.
- </li>
- <li>
- <b>Repeatability</b>: because they are automated, the tests can be run at any time.
- </li>
-</ul></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/concepts/developer_testing.xmi b/XP/xp/guidances/concepts/developer_testing.xmi
deleted file mode 100644
index eda0627..0000000
--- a/XP/xp/guidances/concepts/developer_testing.xmi
+++ /dev/null
@@ -1,515 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-aJBLg1aguP1bIWvQbJSd6w" name="developer_testing,4.085829182735815E-305" guid="-aJBLg1aguP1bIWvQbJSd6w" changeDate="2006-11-13T14:42:19.105-0800" version="1.0.0">
- <mainDescription><a id="XE_test__developer_testing__concept_of" name="XE_test__developer_testing__concept_of"></a><a
-id="XE_design__developer_testing__concept_of" name="XE_design__developer_testing__concept_of"></a>
-<h3>
- <a id="Introduction" name="Introduction"></a>Introduction
-</h3>
-<p>
- The phrase "Developer Testing" is used to categorize the testing activities most appropriately performed by software
- developers. It also includes the artifacts created by those activities. Developer Testing encompasses the work
- traditionally thought of under the following categories: Unit Testing, much of Integration Testing, and some aspects of
- what is most often referred to as System Testing. While Developer Testing is traditionally associated with activities
- in the Implementation discipline, it also has a relationship to activities in the Analysis and Design discipline.
-</p>
-<p>
- By thinking of Developer Testing in this "holistic" way, you help to mitigate some of the risk associated with the more
- "atomistic" approach traditionally taken. In the traditional approach to Developer Testing, the effort is initially
- focused on evaluating that all units are working independently. Late in the development life-cycle, as the development
- work nears completion, the integrated units are assembled into a working subsystem or system and tested in this setting
- for the first time.
-</p>
-<p>
- This approach has a number of failings. Firstly, because it encourages a staged approach to the testing of the
- integrated units and later subsystems, any errors identified during these tests are often found too late. This late
- discovery typically results in the decision to take no corrective action, or it requires major rework to correct. This
- rework is both expensive and detracts from making forward progress in other areas. This increases the risk of the
- project being derailed or abandoned.
-</p>
-<p>
- Secondly, creating rigid boundaries between Unit, Integration and System Test increases the probability that errors
- spanning the boundaries will be discovered by no one. The risk is compounded when responsibility for these types of
- tests is assigned to separate teams.
-</p>
-<p>
- The style of developer testing recommended by&nbsp;iterative processes&nbsp;encourages the developer to focus on the
- most valuable and appropriate tests to conduct at the given point in time. Even within the scope of a single iteration,
- it is usually more efficient for the developer to find and correct as many of the defects in her own code as possible,
- without the additional overhead in hand-off to a separate test group. The desired result is the early discovery of the
- most significant software errors&nbsp;- regardless of whether those errors are in the independent unit, the integration
- of the units or the working of the integrated units within a meaningful end-user scenario.
-</p>
-<h3>
- <a id="DeveloperTestingPitfalls" name="DeveloperTestingPitfalls"></a>Pitfalls Getting Started with Developer Testing
-</h3>
-<p>
- Many developers who begin trying to do a substantially more thorough job of testing give up the effort shortly
- thereafter. They find that it does not seem to be yielding value. Further, some developers who begin well with
- developer testing find that they've created an unmaintainable test suite that is eventually abandoned.
-</p>
-<p>
- This page gives some guidelines for getting over the first hurdles and for creating a test suite that avoids the
- maintainability trap. For more information, see <a href="../../workguid/wg_mnttstste.htm">Guidelines: Maintaining
- Automated Test Suites</a>.
-</p>
-<h4>
- Establish expectations
-</h4>
-<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 component 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>
-<h4>
- Automate your tests
-</h4>
-<p>
- Running tests often is not practical if tests are manual. For some components, 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 component 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 component 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 component 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 component that does just enough to support the tests.
-</p>
-<p>
- Stubs are also useful when a component that your component talks to isn't ready yet. You don't want your testing to
- wait on someone else's code.
-</p>
-<p>
- For more information, see <a href="../implemen/co_stubs.htm">Concepts: Stubs</a>.
-</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>
- Write the tests first
-</h4>
-<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="./../../../xp/guidances/concepts/test-first_design,6.556259235358794E-306.html"
- guid="6.556259235358794E-306">Concept: Test-first Design</a>
-</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 component's behavior. As a simple example, suppose the component 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>
- You can't maintain a test's bug-finding power unless it's clear what <a class="elementLinkWithUserText"
- href="./../../../xp/guidances/concepts/test-ideas_list,8.834380241450745E-306.html#TestIdeas"
- guid="8.834380241450745E-306">Test Ideas</a> a test implements. Test code tends to be under-commented, even though it's
- often harder to understand the "why" behind it than product code.
-</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 component. 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 component 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 align="center">
- <img height="46" alt="" src="resources/dvltst-img1.gif" width="195" />
-</p>
-<p class="picturetext">
- Fig1: Double-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 align="center">
- <img height="46" alt="" src="resources/dvltst-img2.gif" width="318" />
-</p>
-<p class="picturetext">
- Fig2: Double-linked list - item inserted
-</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 align="center">
- <img height="73" alt="" src="resources/dvltst-img3.gif" width="318" />
-</p>
-<p class="picturetext">
- Fig3: Double-linked list - fault in implementation
-</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>
-<h3>
- <a id="TestDesignMistakes" name="TestDesignMistakes"></a>Characteristic Test Design Mistakes
-</h3>
-<p>
- Each test exercises a component 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 a component 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 component 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 gotten for the wrong
- reason. While it's often impossible to know, sometimes it's not.
-</p>
-<br />
-<br /></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/concepts/extreme_programming.xmi b/XP/xp/guidances/concepts/extreme_programming.xmi
deleted file mode 100644
index 6e210bb..0000000
--- a/XP/xp/guidances/concepts/extreme_programming.xmi
+++ /dev/null
@@ -1,229 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-27sE-swoOUGtar9a0f3RPw" name="extreme_programming,5.2637267673584526E-306" guid="-27sE-swoOUGtar9a0f3RPw" changeDate="2006-12-01T15:11:05.063-0800" version="1.0.0">
- <mainDescription><a id="XE_xp__conceptual_process_roadmap" name="XE_xp__conceptual_process_roadmap"></a><a id="XE_roadmap__for_xp_practices"
-name="XE_roadmap__for_xp_practices"></a>
-<h3>
- Topics
-</h3>
-<div align="left">
- <table width="70%" border="1">
- <tbody valign="top">
- <tr>
- <td width="315" height="178">
- <ul>
- <li>
- <a href="#Introduction">Introduction</a>
- </li>
- <li style="LIST-STYLE-TYPE: none">
- <ul>
- <li>
- <a href="#About">About XP</a>
- </li>
- </ul>
- </li>
- <li>
- <a href="#Characteristics">Characteristics of an XP Project</a>
- </li>
- <li>
- <a href="#Phases">Phases and Iterations</a>
- </li>
- <li>
- <a href="#GettingStarted">How to Get Started</a>
- </li>
- </ul>
- </td>
- <td width="315" height="178">
- <b>Additional Guidance:</b>
- <ul>
- <li>
- Guidelines
- </li>
- <li style="LIST-STYLE-TYPE: none">
- <ul>
- <li>
- <a class="elementLink"
- href="./../../../xp/guidances/guidelines/refactoring,8.137126904637637E-306.html"
- guid="8.137126904637637E-306">Refactoring</a>
- </li>
- <li>
- <a class="elementLinkWithUserText"
- href="./../../../xp/guidances/guidelines/test_driven_development_tdd,3.9254165491375454E-306.html"
- guid="3.9254165491375454E-306">Test First Development</a>
- </li>
- <li>
- <a class="elementLinkWithUserText"
- href="./../../../xp/guidances/guidelines/pair_programming,3.85153041801319E-307.html"
- guid="3.85153041801319E-307">Pair Programming</a>
- </li>
- <li>
- <a class="elementLinkWithUserText"
- href="./../../../xp/guidances/guidelines/planning_game,6.7335956461328426E-307.html"
- guid="6.7335956461328426E-307">Planning Game</a>
- </li>
- </ul>
- </li>
- </ul>
- <br />
- <b>Additional Concepts:</b>
- <ul>
- <li>
- <a class="elementLink"
- href="./../../../xp/guidances/concepts/agile_software_development,1.041091673844025E-305.html"
- guid="1.041091673844025E-305">Agile Software Development</a>
- </li>
- </ul>
- </td>
- </tr>
- </tbody>
- </table>
-</div>
-<br />
-<br />
-<h1>
- <a id="Introduction" name="Introduction">Introduction</a>
-</h1>
-<p>
- This roadmap provides information for getting started and applying the practices of eXtreme Programming (XP) to a
- software development project.
-</p>
-<h3>
- <a id="About" name="About">About XP</a>&nbsp;
-</h3>
-<p>
- Extreme Programming is an instance of an <a class="elementLink"
- href="./../../../xp/guidances/concepts/agile_software_development,1.041091673844025E-305.html"
- guid="1.041091673844025E-305">Agile Software Development</a> method. XP is a method that is optimized for small to
- medium-sized project teams that fit a certain profile. It promotes rapid feedback and response to continual change. It
- is based upon the four <a class="elementLinkWithUserText"
- href="./../../../xp/guidances/concepts/xp_values,1.076140803519123E-306.html" guid="1.076140803519123E-306">values</a>
- of simplicity, communication, feedback, and courage and is consistent with the values of agile software development.
-</p>
-<p>
- Extreme Programming is an instance of an agile method for developing software. It is based upon the core principle of
- agility and consists of twelve practices that, when applied to an appropriate software development project, can produce
- high-quality software. If you are unfamiliar with the concepts surrounding XP, you should start by reading <a
- class="elementLink" href="./../../../xp/guidances/concepts/agile_software_development,1.041091673844025E-305.html"
- guid="1.041091673844025E-305">Agile Software Development</a>.
-</p>
-<h3>
- <a id="Characteristics" name="Characteristics">Characteristics of an XP Project</a>
-</h3>
-<p>
- Extreme Programming or XP is a development process that can be used by small to medium-sized teams to develop high
- quality software within a predictable schedule and budget and with a minimum of overhead. Since XP relies heavily on
- direct and frequent communication between the team members, the team should be co-located. An ideal project for using
- XP would be one that has most of the following characteristics:
-</p>
-<ul>
- <li>
- A small to medium-sized team (fewer than 20 people on the complete team)
- </li>
- <li>
- Co-located, preferably in a single area with a large common space
- </li>
- <li>
- A committed, full-time, on-site customer or customer representative
- </li>
-</ul>
-<h3>
- <a id="Phases" name="Phases">Phases and Iterations</a>
-</h3>
-<p>
- An XP project is one that is based on rapid feedback through short iterations and frequent releases.&nbsp;Unified
- Process&nbsp;and XP share a fundamental belief that iterative development is the best way to deliver valuable software
- to your customers. The concept of phases, as usually described in the Unified Process, is somewhat different. Decisions
- described in the Unified Process phases that define milestones occur, but they are not called specifically as defining
- phases.
-</p>
-<h3>
- <a id="GettingStarted" name="GettingStarted">How to Get Started</a>
-</h3>
-<p>
- This section provides a recommended way to approach XP for your project. You don't have to follow the steps as
- specified, but if you have little experience with XP, we recommend following them as closely as possible the first
- time.
-</p>
-<table cellspacing="2" cellpadding="1" width="91%" border="1">
- <tbody>
- <tr>
- <th width="10%">
- Step
- </th>
- <th align="left" width="47%">
- Do this ...
- </th>
- <th align="left" width="43%">
- in order to...
- </th>
- </tr>
- <tr>
- <td align="middle" width="10%">
- 1
- </td>
- <td width="47%">
- Familiarize yourself with the&nbsp;<a class="elementLink"
- href="./../../../xp/guidances/concepts/motivation,1.6390805262958034E-306.html"
- guid="1.6390805262958034E-306">motivation</a> for using XP, the <a class="elementLinkWithUserText"
- href="./../../../xp/guidances/concepts/what_is_xp,9.251272550276345E-306.html"
- guid="9.251272550276345E-306">short description</a> of XP, and the <a class="elementLink"
- href="./../../../xp/guidances/concepts/xp_practices,2.2937799026801584E-305.html"
- guid="2.2937799026801584E-305">XP Practices</a>
- </td>
- <td width="43%">
- understand the fundamental principles of XP and how the practices support each other.
- </td>
- </tr>
- <tr>
- <td align="middle" width="10%">
- 2
- </td>
- <td width="47%">
- Read the key concepts of <a class="elementLink"
- href="./../../../xp/guidances/concepts/agile_software_development,1.041091673844025E-305.html"
- guid="1.041091673844025E-305">Agile Software Development</a>
- </td>
- <td width="43%">
- understand the collaborative and social aspects of XP.
- </td>
- </tr>
- <tr>
- <td align="middle" width="10%">
- 3
- </td>
- <td width="47%">
- Determine if XP is appropriate for your project by reviewing <a href="#Characteristics">The Characteristics
- of an XP Project</a>
- </td>
- <td width="43%">
- decide if XP may be appropriate for your project.
- </td>
- </tr>
- <tr>
- <td align="middle" width="10%">
- 4
- </td>
- <td width="47%">
- Read about the <a class="elementLinkWithUserText"
- href="./../../../xp/guidances/guidelines/xp_environment,3.754748120034442E-307.html"
- guid="3.754748120034442E-307">XP Environment</a>.
- </td>
- <td width="43%">
- prepare the physical and tool environment for your team.
- </td>
- </tr>
- <tr>
- <td align="middle" width="10%">
- 5
- </td>
- <td width="47%">
- Read the <a class="elementLink"
- href="./../../../xp/guidances/supportingmaterials/getting_started_with_xp,1.2284921351651456E-304.html"
- guid="1.2284921351651456E-304">Getting Started with XP</a> guidelines.
- </td>
- <td width="43%">
- get suggestions on how to start an XP project.
- </td>
- </tr>
- </tbody>
-</table></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/concepts/metaphor_system_of_names.xmi b/XP/xp/guidances/concepts/metaphor_system_of_names.xmi
deleted file mode 100644
index ebb542b..0000000
--- a/XP/xp/guidances/concepts/metaphor_system_of_names.xmi
+++ /dev/null
@@ -1,40 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-2OU2wQP_WNWX5zzWzx4ANw" name="metaphor_system_of_names,4.884861766532753E-306" guid="-2OU2wQP_WNWX5zzWzx4ANw" changeDate="2006-11-08T16:24:49.021-0800" version="1.0.0">
- <mainDescription><a id="XE_xp__metaphor_(system_of_names)" name="XE_xp__metaphor_(system_of_names)"></a><a
-id="XE_metaphor_(system_of_names)__practice_of" name="XE_metaphor_(system_of_names)__practice_of"></a><a
-id="XE_engineering_practices__metaphor_(system_of_names)" name="XE_engineering_practices__metaphor_(system_of_names)"></a>
-<h3>
- Description
-</h3>
-<p>
- This metaphor is a design overview. It is a way of defining the system using a commonly understandable vocabulary with
- its associated relationships. It allows the whole team to talk about the structure of the software in a convenient and
- memorable way. A good metaphor is one that all team members can understand easily, remember, and always keep in the
- back of their minds. It provides a unifying direction that developers can follow as they build the system a small piece
- at a time.
-</p>
-<p>
- Metaphors are not always easy to find at the start of a project. In that case, teams can simply identify the key
- objects and their interactions in the system (System of Names). The real metaphor might emerge later on. When everybody
- on the team can explain quickly the system through its major objects and their interactions, the goal has been reached.
-</p>
-<p>
- The iterative nature of XP causes the architecture of our system to evolve over time. The metaphor is not static; it
- will change and hopefully improve over time as our understanding of the system improves.
-</p>
-<p>
- An example of a metaphor would be something like: "It's like a subway system with passengers and stations, tickets and
- turnstiles, etc.".
-</p>
-<h3>
- Benefits
-</h3>
-<ul>
- <li>
- <b>Communication</b>: customer and developer define a common language they can use to talk about the system.
- </li>
- <li>
- <b>Direction</b>: the metaphor helps guide the developers towards the solution.
- </li>
-</ul></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/concepts/motivation.xmi b/XP/xp/guidances/concepts/motivation.xmi
deleted file mode 100644
index 4a39f82..0000000
--- a/XP/xp/guidances/concepts/motivation.xmi
+++ /dev/null
@@ -1,55 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-nIpFvBhY9WogqrEQv4NknQ" name="why_xp,1.6390805262958034E-306" guid="-nIpFvBhY9WogqrEQv4NknQ" changeDate="2006-11-08T15:24:24.660-0800" version="1.0.0">
- <mainDescription><p>
- The goal of a software process is to guide the software development organization to:
-</p>
-<ol>
- <li>
- Get the right software done.
- </li>
- <li>
- Get the software done right.
- </li>
- <li>
- Get the software done quickly.
- </li>
- <li>
- Get the software done frugally.
- </li>
-</ol>
-<p>
- There are many approaches to this problem. Some software processes are high in ceremony. They guide the developers to
- create many artifacts. They punctuate the project with phases and sign-offs. They release infrequently, sometimes
- solely upon project completion. There is a time and place for such processes.
-</p>
-<p>
- On the other hand, the most important and scarce resource in any project is the time of the developers. High ceremony
- processes fill that time with work activities that center around artifacts and reviews instead of around the core
- artifacts of code and tests. For many projects this is an exorbitant expense.
-</p>
-<p>
- To manage this expense, many projects need a process that uses a minimum of ceremony and concentrates on the core
- artifacts. They need a feedback-driven process that delivers working software rapidly in quick releases.
-</p>
-<p>
- XP is just such a low ceremony process. It is used by those teams and for those projects where ceremony is of little
- value, but rapid feedback is of high value. Such projects tend to be small to medium sized - fewer than one or two
- million lines of code - and involve fewer than one or two dozen developers. They tend to exist in environments of
- intense business and or technical change. They are, of course, exceedingly common.
-</p>
-<p>
- A lack of ceremony does not imply a lack of management. XP places a lot of emphasis on techniques for planning,
- estimation, and schedule management. Creating, maintaining, and managing a project plan is a very big part of XP.
-</p>
-<p>
- A lack of ceremony also does not imply a lack of discipline. XP espouses discipline for every facet of the project.
- There is discipline for testing, integration, planning, reviewing, and for producing software with a high quality
- internal structure. The goal is to keep the project moving and the software easy to modify, easy to extend, and easy to
- develop.
-</p>
-<p>
- In short, XP puts the emphasis on ensuring that the team is working on the minimum set of activities and artifacts that
- will produce the right software, built right, built quickly and built frugally.<br />
- <br />
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/concepts/pair_programming.xmi b/XP/xp/guidances/concepts/pair_programming.xmi
deleted file mode 100644
index 61a1f07..0000000
--- a/XP/xp/guidances/concepts/pair_programming.xmi
+++ /dev/null
@@ -1,42 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-n52TyFa7Reb3LOJV1JMpvg" name="pair_programming,3.876855509996079E-307" guid="-n52TyFa7Reb3LOJV1JMpvg" changeDate="2006-11-09T16:16:04.083-0800" version="1.0.0">
- <mainDescription><a id="XE_xp__pair_programming" name="XE_xp__pair_programming"></a><a id="XE_pair_programming__practice_of"
-name="XE_pair_programming__practice_of"></a><a id="XE_engineering_practices__pair_programming"
-name="XE_engineering_practices__pair_programming"></a>
-<h3>
- Description
-</h3>
-<p>
- All production software in XP is produced by two programmers, sitting side by side, at the same machine. This practice
- ensures that all production code is reviewed by at least one other programmer and results in better design, better
- testing, and better code.
-</p>
-<p>
- Research into pair programming shows that pairing produces better code in about the same time as programmers working
- singly.
-</p>
-<p>
- Pairing also serves to communicate knowledge throughout the team. As pairs switch, everyone gets the benefits of
- everyone's specialized knowledge. Programmers learn, their skills improve, and they become more valuable to the team
- and to the company.
-</p>
-<h3>
- Benefits
-</h3>
-<ul>
- <li>
- Better design, code and tests.
- </li>
- <li>
- Application and skill knowledge sharing across team.
- </li>
-</ul>
-<h3>
- Related Information
-</h3>
-<p>
- See the <a class="elementLinkWithUserText"
- href="./../../../xp/guidances/guidelines/pair_programming,3.85153041801319E-307.html" guid="3.85153041801319E-307">Pair
- Programming Guidelines</a>.
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/concepts/planning_game.xmi b/XP/xp/guidances/concepts/planning_game.xmi
deleted file mode 100644
index b4d0953..0000000
--- a/XP/xp/guidances/concepts/planning_game.xmi
+++ /dev/null
@@ -1,99 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-CPHs6R59_druVDY6nRjHEw" name="planning_game,2.7371805612676613E-305" guid="-CPHs6R59_druVDY6nRjHEw" changeDate="2006-11-13T15:39:25.183-0800" version="1.0.0">
- <mainDescription><a id="XE_xp__planning_game" name="XE_xp__planning_game"></a><a id="XE_planning_game__practice_of"
-name="XE_planning_game__practice_of"></a><a id="XE_engineering_practices__planning_game"
-name="XE_engineering_practices__planning_game"></a>
-<h3>
- Description
-</h3>
-<p>
- The purpose of planning is to ensure that we are working on the most valuable things at all times. As much as we would
- like to, planning is not about predicting the future. Even the best, most thought out plans need to be continually
- refined. They require continuous and constant feedback to be useful.
-</p>
-<p>
- XP proposes the following planning hierarchy:
-</p>
-<ul>
- <li>
- Projects are split into releases that typically last two to three months.
- </li>
- <li>
- Releases are split into iterations that typically last two to three weeks.
- </li>
- <li>
- Iterations are planned into tasks that typically last one to two days.
- </li>
-</ul>
-<p>
- The XP planning game has two main activities:
-</p>
-<h4>
- Release Planning
-</h4>
-<ul>
- <li>
- Customer presents user stories to the team.
- </li>
- <li>
- Programmers estimate the user stories.
- </li>
- <li>
- Customers selects a set of user stories for the next release. The total of the estimates of the selected stories
- cannot exceed the team's previous release velocity (how much they did the previous release).
- </li>
-</ul>
-<h4>
- Iteration Planning
-</h4>
-<ul>
- <li>
- Customer presents the user stories that will be worked on for the iteration. These stories usually come from the
- release. Stories not in the release can be selected for the iteration, but the customer will have to push out an
- existing story of the same size out of the iteration and the release. This is done so the team does not commit to
- do more work than they have shown they can do in the past.
- </li>
- <li>
- Programmers break down the stories into engineering tasks.
- </li>
- <li>
- Programmers sign up and estimate engineering tasks.
- </li>
- <li>
- Programmers do a sanity check to make sure all these tasks can be done by comparing against what was done the
- previous iteration.
- </li>
- <li>
- If there is too much to do, the customer will drop one or more user story from the iteration.
- </li>
- <li>
- If there is not enough work, the customer can add one or more story to fill the iteration.
- </li>
-</ul>
-<h3>
- Benefits
-</h3>
-<ul class="noindent">
- <li>
- Provides <b>quick and meaningful feedback</b>.
- </li>
- <li>
- Provides <b>lots of opportunities</b> to use that feedback <b>to steer the team to success</b>.
- </li>
- <li>
- Provides <b>clear</b>, long-term <b>strategic</b> (release plan) <b>and</b> short-term <b>tactical goals</b>
- (iteration plan).
- </li>
- <li>
- <b>Allows the team to manage themselves</b> (task list).
- </li>
-</ul>
-<h3>
- Related Information
-</h3>
-<p>
- See the <a class="elementLinkWithUserText"
- href="./../../../xp/guidances/guidelines/planning_game,6.7335956461328426E-307.html"
- guid="6.7335956461328426E-307">Planning Game Guidelines</a>.
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/concepts/product_quality.xmi b/XP/xp/guidances/concepts/product_quality.xmi
deleted file mode 100644
index 694c958..0000000
--- a/XP/xp/guidances/concepts/product_quality.xmi
+++ /dev/null
@@ -1,169 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-nGaswirSOYturOoUWwGdRw" name="product_quality,3.712584012051524E-306" guid="-nGaswirSOYturOoUWwGdRw" changeDate="2006-11-10T10:10:29.938-0800" version="1.0.0">
- <mainDescription><h3>
- <a id="Introduction" name="Introduction">Introduction</a>
-</h3>
-<p>
- If you're serious about producing an excellent product, you face two problems:
-</p>
-<ul>
- <li>
- How do you know when the product is good enough?
- </li>
- <li>
- If the product is not yet good enough, how do you assure that the stakeholders involved know that?
- </li>
-</ul>
-<p>
- The answer to the first question lets you release the product. The answer to the second question helps you avoid
- releasing a bad product.
-</p>
-<p>
- You might think: "I don't want to ship a merely good enough product; I want to ship a <i>great</i> product!" Let's
- explore that. What happens when you tell your coworkers, managers, or investors that you have high quality standards
- and intend to ship a great product? If it's early in the project cycle, they probably nod and smile. Everyone likes
- quality. However, if it's late in the project cycle, you're under a lot of pressure to complete the project. Creating a
- great product might require that you perform extensive testing, fix many problems (even small ones), add features, or
- even scrap and rewrite a large part of the code. You will also have to resolve disputes over different visions of good
- quality. Greatness is hard work. Perfection is even harder! Eventually, the people who control the project will come to
- you and say something like: "Perfection would be nice, but we have to be practical. We're running a business. Quality
- is good, but not quality <i>at any cost</i>. As you know, all software has bugs."
-</p>
-<p>
- Greatness can be a motivating goal. It appeals to the pride you have in your work. But there are problems with using
- what amounts to "if quality is good, more quality must be better" to justify the pursuit of excellence. For one thing,
- making such an argument can portray you as a quality fanatic, rather than a balanced thinker. For another thing, it
- ignores the cost factor. A BMW is a nice car, but it costs a lot more than a Saturn. A Saturn may not be the ultimate
- driving experience, but it's nice for the money. In leaving out cost, the <i><b>more is better</b></i> argument also
- ignores diminishing returns. The better your product, the harder it gets to justify further improvement. While you
- labor to gold-plate one aspect of a product, out of necessity you must ignore other aspects of the product or even the
- potential opportunities presented by another project. The business has to make choices every day about the best use of
- its resources. There are factors other than quality that must be considered.
-</p>
-<p>
- The <i><b>good enough quality</b></i> concept (GEQ) is, paradoxically, a more effective argument than <i><b>more is
- better</b></i>, because it provides a target that is either achievable or not achievable, in which case it becomes a de
- facto argument for canceling or rechartering the project.
-</p>
-<h3>
- <a id="GEQParadigms" name="GEQParadigms">Paradigms of Good Enough</a>
-</h3>
-<p>
- Most businesses practice some form of good enough reasoning about their products. The only ones that don't are those
- who believe they have achieved perfection, because they lack the imagination and skill to see how their products might
- be improved.
-</p>
-<p>
- Here are some models of <i><b>good enough</b></i> that have been tried. Some of them are more effective than others,
- depending on the situation:
-</p>
-<ul>
- <li>
- <b>Not too Bad</b> <i>("we're not dead yet") -</i> Our quality only has to be good enough so we can continue to
- stay in business. Make it good enough so that we aren't successfully sued.<br />
- <br />
- </li>
- <li>
- <b>Positive Infallibility</b> <i>("anything we do is good") -</i> Our organization is the best in the world.
- Because we're so good, anything we do is automatically good. Think about success. Don't think about failure because
- "negative" thinking makes for poor quality.<br />
- <br />
- </li>
- <li>
- <b>Righteous Exhaustion</b> <i>("perfection or bust") -</i> No product is good enough; it's effort that counts. And
- only our complete exhaustion will be a good enough level of effort. Business issues are not our concern. We will do
- everything we possibly can to make it perfect. Since we'll never be finished improving, someone will have to come
- in and pry it from our fingers if they want it. Then they will bear the blame for any quality problems, not
- us.<br />
- <br />
- </li>
- <li>
- <b>Customer is Always Right</b> <i>("customers seem to like it") -</i> If customers like it, it must be good
- enough. Of course, you can't please everybody all the time. And if a current or potential customer doesn't like the
- product, it's up to them to let us know. We can't read their minds.<br />
- <br />
- </li>
- <li>
- <b>Defined Process</b> <i>("we follow a Good Process") -</i> Quality is the result of the process we use to build
- the product. We have defined our process and we think it's a good process. Therefore, as long as we follow the
- process, a good enough product will inevitably result.<br />
- <br />
- </li>
- <li>
- <b>Static Requirements</b> <i>("we satisfy the Requirements") -</i> We have defined quality in terms of objective,
- quantifiable, noncontroversial goals. If we meet those goals, we have a good enough product, no matter what other
- subjective, non-quantifiable, controversial goals might be suggested.<br />
- <br />
- </li>
- <li>
- <b>Accountability</b> <i>("we fulfill our promises") -</i> Quality is defined by contract. We promise to do certain
- things and achieve certain goals. If we fulfill our contract, that's good enough.<br />
- <br />
- </li>
- <li>
- <b>Advocacy</b> <i>("we make every reasonable effort") -</i> We advocate excellence. Throughout the project, we
- look for ways to prevent problems, and to find and fix the ones we couldn't prevent. If we work faithfully toward
- excellence, that will be good enough.<br />
- <br />
- </li>
- <li>
- <b>Dynamic Tradeoff</b> <i>("we weigh many factors") -</i> With respect to our mission and the situation at hand, a
- product is good enough when it has sufficient benefits, no critical problems, its benefits sufficiently outweigh
- its non-critical problems, and it would cause more harm than good to continue improving it.<br />
- <br />
- </li>
-</ul>
-<h3>
- <a id="IsHighQualityExpensive" name="IsHighQualityExpensive">Is High Quality Necessarily More Expensive?</a>
-</h3>
-<p>
- Depending on a lot of factors, such as process, skill, technology, tools, environment, and culture, you may be able to
- produce a much higher quality product for the same cost. A more testable and maintainable product will cost less to
- improve and other costs are specifically associated with poor quality, such as support costs and costs to the customer.
-</p>
-<p>
- The cost of quality is a complex issue and it's difficult to make broad generalizations. However, you can say with
- certainty that you can always spend more time on much better tests, much more error handling, and more fixing or
- rewriting of every part of the product. No matter how good you are, that costs something. And if you can't think of
- more improvements to make, it's more likely that you've reached the upper limit of your imagination, not of quality.
-</p>
-<p>
- In the software industry GEQ is inspired more as a response to one particular cost than any other: the cost of not
- releasing the product <i>soon enough</i>. The specter of the market window, or the external deadline, imposes penalties
- upon us if we can't meet the challenge. That's why the ends of projects are so often characterized by frenzied triage.
- If you want to know what an organization really believes is good enough, and how well prepared they are for it, witness
- the last three days of any six-month software project. See what happens when a new problem is reported on the last day.
-</p>
-<h3>
- <a id="Quantification" name="Quantification">Wouldn't Quantification Help?</a>
-</h3>
-<p>
- It can be tempting to reduce quality to a number, then set a numerical threshold that represents good enough quality.
- This is a problem, because you can only measure factors that <i>relate</i> to quality. You can't measure quality
- itself. This is partly because the word "quality" is just a label for a relationship between a person and a thing.
- "This product is high in quality" is just another way of saying "Somebody values this product". It's a statement about
- the product, but also a statement about people and the surrounding context. Even if the product stays the same, people
- and situations change, so there can be no single, static, <i>true</i> measure of quality.
-</p>
-<p>
- There are many measures you might use to get a sense of quality, even if you can't measure it completely and
- objectively. Even so, the question of what quality is good enough requires sophisticated judgment. You can't escape
- from the fact that, in the end, people have to think it through and make a judgment. For a simple product, that
- judgment might be easy. For a complex, high-stakes product, it's very difficult.
-</p>
-<h3>
- <a id="FurtherInfo" name="FurtherInfo">Further Information</a>
-</h3>
-<p>
- To assist you with evaluating product quality, the following types of information are available for most of the
- artifacts included in the Unified Process:
-</p>
-<ul>
- <li>
- Artifact Guidelines and Checkpoints: information on how to develop, evaluate, and use the artifact.
- </li>
- <li>
- Templates: "models" or prototypes of the artifact, providing structure and guidance for content.<br />
- </li>
-</ul></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/concepts/refactoring_xp_programming.xmi b/XP/xp/guidances/concepts/refactoring_xp_programming.xmi
deleted file mode 100644
index 34d0dbb..0000000
--- a/XP/xp/guidances/concepts/refactoring_xp_programming.xmi
+++ /dev/null
@@ -1,75 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-U8NScY6mORb4XPcNZ_mrEA" name="refactoring_xp_programming,1.4410217108363206E-306" guid="-U8NScY6mORb4XPcNZ_mrEA" changeDate="2006-11-09T16:20:46.023-0800" version="1.0.0">
- <mainDescription><a id="XE_xp__refactoring" name="XE_xp__refactoring"></a><a id="XE_refactoring__practice_of"
-name="XE_refactoring__practice_of"></a><a id="XE_engineering_practices__refactoring"
-name="XE_engineering_practices__refactoring"></a>
-<h3>
- Description
-</h3>
-<p>
- Refactoring is the practice of improving the design of a system without changing its behavior. Refactoring is a
- critical practice and skill in iterative development. The programmer is either adding a new feature or refactoring. XP
- programmers consciously choose between refactoring and adding new functionality on a minute-by-minute basis. Some
- refactorings are trivial, such as renaming or moving things. Other refactorings allow you to exchange procedural logic
- with polymorphism, and still larger refactorings exist to introduce design patterns.
-</p>
-<p>
- While processes like Extreme Programming rely on refactoring to let the design emerge, the usefulness of refactoring
- extends beyond the Agile Methodologies. As feature requests and bug fixes require changes to a system, refactoring
- techniques allow the programmers to maintain a good design. Refactoring can also be used to improve the design of an
- existing system.
-</p>
-<p>
- Refactoring is not new. Developers have been refactoring for years, though only recently have people started to catalog
- refactorings. Refactoring has become such an important part of development that professional-level Integrated
- Development Environments (IDEs) either include built-in tools or have plug-ins to provide refactoring support.
-</p>
-<p>
- If your system isn't being refactored as it is modified, your design deteriorates; methods become longer, classes take
- on more responsibility, more code gets cut and pasted around your system, previously cut-and-pasted code has to be
- modified in several places.
-</p>
-<p>
- If your system becomes brittle and inflexible, your developers will have to spend more time and money to add features
- or fix bugs. As the design continues to deteriorate, fixing one bug creates two more, or the cost of adding a new
- feature out weighs the benefit of having it because so much of the system has to be modified. There are many analogies
- to describe this battle against entropy; from cleaning as you go to design debt.
-</p>
-<p>
- Knowing the refactorings isn't enough. Developers must be able to identify problem areas of the program design (often
- referred to as "smells"). These are the places where refactoring can be used to improve the design of the code. Design
- skill and experience are needed to recognize bad code smells.
-</p>
-<p>
- Automated tests provide a safety net when making changes. The automated tests report when the functionality of the
- system changes. Make a structural change to the software; see that the tests still pass. You can confidently refactor.
-</p>
-<p>
- Where do all these tests come from? In XP, they are developed using <a class="elementLinkWithUserText"
- href="./../../../xp/guidances/concepts/test_driven_development,1.620567348185129E-306.html"
- guid="1.620567348185129E-306">Test-Driven Development</a>. It is possible to refactor without tests, but you run the
- risk of unknowingly introducing bugs or breaking existing functionality.
-</p>
-<h3>
- Benefits
-</h3>
-<ul>
- <li>
- Allows the design to emerge over time.
- </li>
- <li>
- Keeps the design from rotting.
- </li>
- <li>
- Reduces cost of change.
- </li>
-</ul>
-<h3>
- Related Information
-</h3>
-<p>
- &nbsp;See the <a class="elementLinkWithUserText"
- href="./../../../xp/guidances/guidelines/refactoring,8.137126904637637E-306.html"
- guid="8.137126904637637E-306">Refactoring Guidelines</a>.
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/concepts/resources/dvltst-img1.gif b/XP/xp/guidances/concepts/resources/dvltst-img1.gif
deleted file mode 100644
index 8082009..0000000
--- a/XP/xp/guidances/concepts/resources/dvltst-img1.gif
+++ /dev/null
Binary files differ
diff --git a/XP/xp/guidances/concepts/resources/dvltst-img2.gif b/XP/xp/guidances/concepts/resources/dvltst-img2.gif
deleted file mode 100644
index 381f405..0000000
--- a/XP/xp/guidances/concepts/resources/dvltst-img2.gif
+++ /dev/null
Binary files differ
diff --git a/XP/xp/guidances/concepts/resources/dvltst-img3.gif b/XP/xp/guidances/concepts/resources/dvltst-img3.gif
deleted file mode 100644
index e7f17aa..0000000
--- a/XP/xp/guidances/concepts/resources/dvltst-img3.gif
+++ /dev/null
Binary files differ
diff --git a/XP/xp/guidances/concepts/resources/tstfrsdsg-img1.gif b/XP/xp/guidances/concepts/resources/tstfrsdsg-img1.gif
deleted file mode 100644
index 8b22b05..0000000
--- a/XP/xp/guidances/concepts/resources/tstfrsdsg-img1.gif
+++ /dev/null
Binary files differ
diff --git a/XP/xp/guidances/concepts/resources/tstfrsdsg-img2.gif b/XP/xp/guidances/concepts/resources/tstfrsdsg-img2.gif
deleted file mode 100644
index d17d10e..0000000
--- a/XP/xp/guidances/concepts/resources/tstfrsdsg-img2.gif
+++ /dev/null
Binary files differ
diff --git a/XP/xp/guidances/concepts/resources/tstfrsdsg-img3.gif b/XP/xp/guidances/concepts/resources/tstfrsdsg-img3.gif
deleted file mode 100644
index 182076e..0000000
--- a/XP/xp/guidances/concepts/resources/tstfrsdsg-img3.gif
+++ /dev/null
Binary files differ
diff --git a/XP/xp/guidances/concepts/resources/tstfrsdsg-img4.gif b/XP/xp/guidances/concepts/resources/tstfrsdsg-img4.gif
deleted file mode 100644
index d06ff22..0000000
--- a/XP/xp/guidances/concepts/resources/tstfrsdsg-img4.gif
+++ /dev/null
Binary files differ
diff --git a/XP/xp/guidances/concepts/resources/tstfrsdsg-img5.gif b/XP/xp/guidances/concepts/resources/tstfrsdsg-img5.gif
deleted file mode 100644
index f7fc9cd..0000000
--- a/XP/xp/guidances/concepts/resources/tstfrsdsg-img5.gif
+++ /dev/null
Binary files differ
diff --git a/XP/xp/guidances/concepts/resources/tstids_short-catalog.pdf b/XP/xp/guidances/concepts/resources/tstids_short-catalog.pdf
deleted file mode 100644
index d88327c..0000000
--- a/XP/xp/guidances/concepts/resources/tstids_short-catalog.pdf
+++ /dev/null
Binary files differ
diff --git a/XP/xp/guidances/concepts/resources/tstidsctl-img1.gif b/XP/xp/guidances/concepts/resources/tstidsctl-img1.gif
deleted file mode 100644
index b61b1c9..0000000
--- a/XP/xp/guidances/concepts/resources/tstidsctl-img1.gif
+++ /dev/null
Binary files differ
diff --git a/XP/xp/guidances/concepts/resources/tstidsctl-img2.gif b/XP/xp/guidances/concepts/resources/tstidsctl-img2.gif
deleted file mode 100644
index 9951dc2..0000000
--- a/XP/xp/guidances/concepts/resources/tstidsctl-img2.gif
+++ /dev/null
Binary files differ
diff --git a/XP/xp/guidances/concepts/resources/tstidslst-img1.gif b/XP/xp/guidances/concepts/resources/tstidslst-img1.gif
deleted file mode 100644
index ac8fd5f..0000000
--- a/XP/xp/guidances/concepts/resources/tstidslst-img1.gif
+++ /dev/null
Binary files differ
diff --git a/XP/xp/guidances/concepts/simple_design.xmi b/XP/xp/guidances/concepts/simple_design.xmi
deleted file mode 100644
index c8b3b3a..0000000
--- a/XP/xp/guidances/concepts/simple_design.xmi
+++ /dev/null
@@ -1,112 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-0rSxLFlmQfyKrgnqi1NKrg" name="simple_design,1.6109092258980447E-306" guid="-0rSxLFlmQfyKrgnqi1NKrg" changeDate="2006-11-08T16:39:05.846-0800" version="1.0.0">
- <mainDescription><a id="XE_xp__simple_design" name="XE_xp__simple_design"></a><a id="XE_simple_design__practice_of"
-name="XE_simple_design__practice_of"></a><a id="XE_engineering_practices__simple_design"
-name="XE_engineering_practices__simple_design"></a>
-<h3>
- Description
-</h3>
-<p>
- The design strategy in XP is to create the simplest design that meets your current requirements, as reflected in the
- current test cases. In many domains, "simplest design" is ambiguous, but it is a well-defined term in XP. A simple
- design has these four characteristics, listed in priority order:
-</p>
-<ul>
- <li>
- The system runs all the tests.
- </li>
- <li>
- It contains no duplicate code.
- </li>
- <li>
- The code states the programmers's intent very clearly.
- </li>
- <li>
- It contains the fewest possible number of classes and methods.
- </li>
-</ul>
-<p>
- Design in Extreme Programming is much more incremental than in any other methodology. The practice of Test-Driven
- Development describes how the system is created in many small steps, driven by tests that programmers write. Each of
- these tests is a probe into the design of the system, allowing the developers to explore the system as it is being
- created. This is quite a contrast to other methodologies where design is a separate phase of either the project or the
- iteration. In XP, design quite literally happens all the time.
-</p>
-<p>
- It takes a tremendous amount of courage to stop designing and start coding. Almost all developers are taught that they
- should understand everything about the system before committing that knowledge to code. The reason, they've always been
- told, is that code is hard to change. Once it is laid on its virtual paper, changing it involves understanding the
- hidden assumptions of the original developer, unseen couplings, months-long validation and verification procedures,
- etc. But if code could be changed with impunity, developers could afford to defer design decisions until later,
- understand the system incrementally, and implement in pieces.
-</p>
-<p>
- The strategy of building software in this manner is based on the following reasoning:
-</p>
-<ul>
- <li>
- Given that all requirements aren't known on the first day of the project, the development style must be adjusted to
- accommodate new understanding from customers and changes in the business climate.
- </li>
- <li>
- If a design decision does not have to be made now, avoid guessing by deferring the decision until it is needed. By
- that time, there is a better chance that enough understanding will exist to support a better decision.
- </li>
- <li>
- Change happens during the lifetime of a project. Decisions made once will be changed. The software must be designed
- and implemented in such a way that changes can be accommodated easily.
- </li>
- <li>
- Designs seldom survive their first skirmish with code. The act of coding provides feedback to the developer about
- the system. This learning must be reflected in the design. If the design is already cast before coding begins, this
- feedback is more difficult and costly to put back into the design.
- </li>
-</ul>
-<p>
- Here are some guidelines to help in arriving at a simple design:
-</p>
-<ul>
- <li>
- Look for a simple way to solve a problem. Software is hard, so there will be plenty of time for complexity later.
- For now, keep it simple. Simple, however, does not mean stupid. Pay attention to good design principles when
- forming a system incrementally.
- </li>
- <li>
- Resist the temptation to add infrastructure or other features that might be needed later. Chances are they won't be
- (YAGNI: You Aren't Going to Need It). Let the user stories force you to change the design.
- </li>
- <li>
- Don't generalize a solution until it is needed in at least two places. Follow the first rule above and keep
- implementation simple. Let the second user pay for the generality.
- </li>
- <li>
- Seek out and destroy duplication. The practice of <a class="elementLink"
- href="./../../../xp/guidances/concepts/refactoring_xp_programming,1.4410217108363206E-306.html"
- guid="1.4410217108363206E-306">Refactoring</a> is the most powerful tool in the arsenal. It is through removing
- duplication that new classes, methods, and larger scale systems are born.
- </li>
- <li>
- Remember that it is just code. If it is getting overly complex and painful, delete it. It can always be recreated
- again in less time and better than the first time by leveraging what was learned the first time.
- </li>
-</ul>
-<h3>
- Benefits
-</h3>
-<ul>
- <li>
- <b>Small initial investment</b>: There is no need to invest in frameworks or generality that might be or might not
- be required in the future.
- </li>
- <li>
- <b>Maintainability</b>: Simple design will keep the design from rotting and dying prematurely. The more complex the
- design is, the harder it is to understand and preserve and the more rapidly it will decay.
- </li>
- <li>
- <b>Flexibility</b>: Simple systems are always easier to change than more complex systems.
- </li>
- <li>
- <b>Agility</b>: Simple systems are faster to change than more complex systems.
- </li>
-</ul></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/concepts/small_releases.xmi b/XP/xp/guidances/concepts/small_releases.xmi
deleted file mode 100644
index 88f0990..0000000
--- a/XP/xp/guidances/concepts/small_releases.xmi
+++ /dev/null
@@ -1,33 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-vcCn_ksJo5Jw27aNZb1Cvw" name="small_releases,5.762953011420275E-306" guid="-vcCn_ksJo5Jw27aNZb1Cvw" changeDate="2006-11-09T15:03:57.390-0800" version="1.0.0">
- <mainDescription><a id="XE_xp__small_releases" name="XE_xp__small_releases"></a><a id="XE_small_releases__practice_of"
-name="XE_small_releases__practice_of"></a><a id="XE_engineering_practices__small_releases"
-name="XE_engineering_practices__small_releases"></a>
-<h3>
- Description
-</h3>
-<p>
- There are many developers who have spent years developing software and yet never had any of it released into use.
- Fortunately, this situation is becoming rarer, but it still happens. There are many reasons why some software never
- gets put into production, but often a key factor is the size of releases. Releasing software is much like integrating
- source code changes in a project: the longer you delay it, the tougher it becomes. Releasing software into production
- frequently is a good way of getting feedback. Users will often think of issues that they would not have without actual
- experience using the software. Getting that feedback early enhances the overall quality of the product.
-</p>
-<p>
- In XP, we recommend release cycles of three to four months at most.
-</p>
-<h3>
- Benefits
-</h3>
-<ul>
- <li>
- <b>Small releases increase feedback</b>. Discrepancies between the system that is needed and the system being
- developed are found early.
- </li>
- <li>
- Putting pieces of a system into production frequently raises the quality consciousness of the project. The
- <b>system must consistently be good enough to ship</b>.
- </li>
-</ul></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/concepts/test-first_design.xmi b/XP/xp/guidances/concepts/test-first_design.xmi
deleted file mode 100644
index 7e2335b..0000000
--- a/XP/xp/guidances/concepts/test-first_design.xmi
+++ /dev/null
@@ -1,312 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-3AbfvnHrCOIQS63sEjrOew" name="test-first_design,6.556259235358794E-306" guid="-3AbfvnHrCOIQS63sEjrOew" changeDate="2006-11-13T15:58:35.617-0800" version="1.0.0">
- <mainDescription><a id="XE_test__developer_testing__test-first_design" name="XE_test__developer_testing__test-first_design"></a><a
-id="XE_design__test-first_design" name="XE_design__test-first_design"></a>
-<h3>
- <a id="Introduction" name="Introduction">Introduction</a>
-</h3>
-<p>
- Test designs are created using information from a variety of artifacts, including design artifacts such as use case
- realizations, design models, or classifier interfaces. Tests are executed after components are created. It's typical to
- create the test designs just before the tests are to be executed - well after the software design artifacts are
- created. Figure 1, following, shows an example. Here, test design begins sometime toward the end of implementation. It
- draws on the results of component design. The arrow from Implementation to Test Execution indicates that the tests
- can't be executed until the implementation is complete.
-</p>
-<p align="center">
- <img height="159" alt="" src="resources/tstfrsdsg-img1.gif" width="614" />
-</p>
-<p class="picturetext">
- Fig1: Traditionally, Test Design is performed later in the life-cycle
-</p>
-<p>
- However, it doesn't have to be this way. Although test execution has to wait until the component has been implemented,
- test design can be done earlier. It could be done just after the design artifact is completed. It could even be done in
- parallel with component design, as shown here:
-</p>
-<p align="center">
- <img height="158" alt="" src="resources/tstfrsdsg-img2.gif" width="610" />
-</p>
-<p class="picturetext">
- Fig2: Test-first Design brings test design chronologically in-line with software design
-</p>
-<p>
- Moving the test effort "upstream" in this way is commonly called "test-first design". What are its advantages?
-</p>
-<ol>
- <li>
- No matter how carefully you design software, you'll make mistakes. You might be missing a relevant fact. Or you
- might have particular habits of thought that make it hard for you to see certain alternatives. Or you might just be
- tired and overlook something. Having other people review your design artifacts helps. They might have the facts you
- miss, or they might see what you overlooked. It's best if these people have a different perspective than you do; by
- looking at the design differently, they'll see things you missed.<br />
- <br />
- Experience has shown that the testing perspective is an effective one. It's relentlessly concrete. During software
- design, it's easy to think of a particular field as "displaying the title of the current customer" and move on
- without really thinking about it. During test design, you must decide <i>specifically</i> what that field will show
- when a customer who retired from the Navy and then obtained a law degree insists on referring to himself as
- "Lieutenant Morton H. Throckbottle (Ret.), Esq." Is his title "Lieutenant" or "Esquire"?<br />
- <br />
- If test design is deferred until just before test execution, as in Figure 1, you'll probably waste money. A
- mistake in your software design will remain uncaught until test design, when some tester says, "You know, I knew
- this guy from the Navy...", creates the "Morton" test, and discovers the problem. Now a partially or fully complete
- implementation has to be rewritten and a design artifact has to be updated. It would be cheaper to catch the
- problem before implementation begins.<br />
- </li>
- <li>
- Some mistakes might be caught before test design. Instead, they'll be caught by the Implementer. That's still bad.
- Implementation must grind to a halt while the focus switches from how to implement the design to what that design
- should be. That's disruptive even when the Implementer and Designer roles are filled by the same person; it's much
- more disruptive when they're different people. Preventing this disruption is another way in which test-first design
- helps improve efficiency.<br />
- </li>
- <li>
- Test designs help Implementers in another way-by clarifying design. If there's a question in the Implementer's mind
- about what the design meant, the test design might serve as a specific example of the desired behavior. That will
- lead to fewer bugs due to Implementer misunderstanding.<br />
- </li>
- <li>
- There are fewer bugs even if the question <i>wasn't</i> in the Implementer's mind - but should have been. For
- example, there might have been an ambiguity that the Designer unconsciously interpreted one way and the Implementer
- another. If the Implementer is working from both the design and also from specific instructions about what the
- component is supposed to do - from test cases - the component is more likely to actually do what is required.
- </li>
-</ol>
-<h3>
- <a id="Examples" name="Examples">Examples</a>
-</h3>
-<p>
- Here are some examples to give you the flavor of test-first design.
-</p>
-<p>
- Suppose you're creating a system to replace the old "ask the secretary" method of assigning meeting rooms. One of the
- methods of the <font size="+0">MeetingDatabase</font> class is called <font size="+0">getMeeting</font>, which has this
- signature:
-</p>
-<blockquote>
-<pre>
-Meeting getMeeting(Person, Time);
-</pre>
-</blockquote>
-<p>
- Given a person and a time, <font size="+0">getMeeting</font> returns the meeting that person is scheduled to be in at
- that time. If the person isn't scheduled for anything, it returns the special <font size="+0">Meeting</font> object
- <font size="+0">unscheduled</font>. There are some straightforward test cases:
-</p>
-<ul>
- <li>
- The person isn't in any meeting at the given time. Is the <font size="+0">unscheduled</font> meeting returned?
- </li>
- <li>
- The person is in a meeting at that time. Does the method return the correct meeting?
- </li>
-</ul>
-<p>
- These test cases are unexciting, but they need to be tried eventually. They might as well be created now, by writing
- the actual test code that will someday be run. Java code for the first test might look like this:
-</p>
-<pre>
- // if not in a meeting at given time,
- // expect to be unscheduled.
- public void testWhenAvailable() {
-Person fred = new Person("fred");
-Time now = Time.now();
-MeetingDatabase db = new MeetingDatabase();
-expect(db.getMeeting(fred, now) == Meeting.unscheduled);
- }
-</pre>
-<p>
- But there are more interesting test ideas. For example, this method searches for a match. Whenever a method searches,
- it's a good idea to ask what should happen if the search finds more than one match. In this case, that means asking
- "Can a person be in two meetings at once?" Seems impossible, but asking the secretary about that case might reveal
- something surprising. It turns out that some executives are quite often scheduled into two meetings at once. Their role
- is to pop into a meeting, "rally the troops" for some short amount of time, and then move on. A system that didn't
- accommodate that behavior would go at least partially unused.
-</p>
-<p>
- This is an example of test-first design done at the implementation level catching an analysis problem. There are a few
- things to note about that:
-</p>
-<ol>
- <li>
- You would hope that good use-case specification and analysis would have already discovered this requirement. In
- that case, the problem would have been avoided "upstream" and <font size="+0">getMeeting</font> would have been
- designed differently. (It couldn't return a meeting; it would have to return a set of meetings.) But analysis
- always misses some problems, and it's better for them to be discovered during implementation than after
- deployment.<br />
- </li>
- <li>
- In many cases, Designers and Implementers won't have the domain knowledge to catch such problems - they won't have
- the opportunity or time to quiz the secretary. In that case, the person designing tests for <font
- size="+0">getMeeting</font> would ask, "is there a case in which two meetings should be returned?", think for a
- while, and conclude that there wasn't. So test-first design doesn't catch every problem, but the mere fact of
- asking the right kinds of questions increases the chance a problem will be found.<br />
- </li>
- <li>
- Some of the same testing techniques that apply during implementation also apply to analysis. Test-first design can
- be done by analysts as well, but that's not the topic of this page.
- </li>
-</ol>
-<p>
- The second of the three examples is a statechart model for a heating system.
-</p>
-<p align="center">
- <img height="253" alt="" src="resources/tstfrsdsg-img3.gif" width="567" />
-</p>
-<p class="picturetext">
- Fig3: HVAC Statechart
-</p>
-<p>
- A set of tests would traverse all the arcs in the statechart. One test might begin with an idle system, inject a Too
- Hot event, fail the system during the Cooling/Running state, clear the failure, inject another Too Hot event, then run
- the system back to the Idle state. Since that does not exercise all the arcs, more tests are needed. These kinds of
- tests look for various kinds of implementation problems. For example, by traversing every arc, they check whether the
- implementation has left one out. By using sequences of events that have failure paths followed by paths that should
- successfully complete, they check whether error-handling code fails to clean up partial results that might affect later
- computation. (For more about testing statecharts, see <a class="elementLinkWithUserText"
- href="./../../../xp/guidances/guidelines/test_ideas_for_statechart_and_flow_diagrams,1.0347051690476123E-305.html"
- guid="1.0347051690476123E-305">Guideline: Test Ideas for Statechart and Activity Diagrams</a>.)
-</p>
-<p>
- The final example uses part of a design model. There's an association between a creditor and an invoice, where any
- given creditor can have more than one invoice outstanding.
-</p>
-<p align="center">
- <img height="45" alt="" src="resources/tstfrsdsg-img4.gif" width="186" />
-</p>
-<p class="picturetext">
- Fig4: Association between Creditor and Invoice Classes
-</p>
-<p>
- Tests based on this model would exercise the system when a creditor has no invoices, one invoice, and a large number of
- invoices. A tester would also ask whether there are situations in which an invoice might need to be associated with
- more than one creditor, or where an invoice has no creditor. (Perhaps the people who currently run the paper-based
- system the computer system is to replace use creditor-less invoices as a way to keep track of pending work). If so,
- that would be another problem that should have been caught in Analysis.
-</p>
-<h3>
- <a id="WhoDoesTest-FirstDesign" name="WhoDoesTest-FirstDesign">Who does test-first design?</a>
-</h3>
-<p>
- Test-first design can be done by either the author of the design or by someone else. It's common for the author to do
- it. The advantage is that it reduces communication overhead. The Designer and Test Designer don't have to explain
- things to each other. Further, a separate Test Designer would have to spend time learning the design well, whereas the
- original Designer already knows it. Finally, many of these questions - like "what happens if the compressor fails in
- state X?" - are natural questions to ask during both software artifact design and test design, so you might as well
- have the same person ask them exactly once and write the answers down in the form of tests.
-</p>
-<p>
- There are disadvantages, though. The first is that the Designer is, to some extent, blind to his or her own mistakes.
- The test design process will reveal some of that blindness, but probably not as much as a different person would find.
- How much of a problem this is seems to vary widely from person to person and is often related to the amount of
- experience the Designer has.
-</p>
-<p>
- Another disadvantage of having the same person do both software design and test design is that there's no parallelism.
- Whereas allocating the roles to separate people will take more total effort, it will probably result in less elapsed
- calendar time. If people are itching to move out of design and into implementation, taking time for test design can be
- frustrating. More importantly, there's a tendency to skimp on the work in order to move on.
-</p>
-<h3>
- <a id="CanAllTestDesignBeDoneAtComponentDesignTime" name="CanAllTestDesignBeDoneAtComponentDesignTime">Can all test
- design be done at component design time?</a>
-</h3>
-<p>
- No. The reason is that not all decisions are made at design time. Decisions made during implementation won't be
- well-tested by tests created from the design. The classic example of this is a routine to sort arrays. There are many
- different sorting algorithms with different tradeoffs. Quicksort is usually faster than an insertion sort on large
- arrays, but often slower on small arrays. So a sorting algorithm might be implemented to use Quicksort for arrays with
- more than 15 elements, but insertion sort otherwise. That division of labor might be invisible from design artifacts.
- You <i>could</i> represent it in a design artifact, but the Designer might have decided that the benefit of making such
- explicit decisions wasn't worthwhile. Since the size of the array plays no role in the design, the test design might
- inadvertently use only small arrays, meaning that none of the Quicksort code would be tested at all.
-</p>
-<p>
- As another example, consider this fraction of a sequence diagram. It shows a <font size="+0">SecurityManager</font>
- calling the <font size="+0">log()</font> method of <font size="+0">StableStore</font>. In this case, though, the <font
- size="+0">log()</font> returns a failure, which causes <font size="+0">SecurityManager</font> to call <font
- size="+0">Connection.close()</font>.
-</p>
-<p align="center">
- <img height="161" alt="" src="resources/tstfrsdsg-img5.gif" width="303" />
-</p>
-<p class="picturetext">
- Fig5: SecurityManager sequence diagram instance
-</p>
-<p>
- This is a good reminder to the Implementer. Whenever <font size="+0">log()</font> fails, the connection must be closed.
- The question for testing to answer is whether the Implementer really did it-and did it correctly-in <i>all</i> cases or
- just in <i>some</i>. To answer the question, the Test Designer must find all the calls to <font
- size="+0">StableStore.log()</font> and make sure each of those call points is given a failure to handle.
-</p>
-<p>
- It might seem odd to run such a test, given that you've just looked at all the code that calls <font
- size="+0">StableStore.log()</font>. Can't you just check to see if it handles failure correctly?
-</p>
-<p>
- Perhaps inspection might be enough. But error-handling code is notoriously error-prone because it often implicitly
- depends on assumptions that the existence of the error has violated. The classic example of this is code that handles
- allocation failures. Here's an example:
-</p>
-<blockquote>
-<pre>
-while (true) { // top level event loop
- try {
-XEvent xe = getEvent();
-... // main body of program
- } catch (OutOfMemoryError e) {
-emergencyRestart();
- }
-}
-</pre>
-</blockquote>
-<p>
- This code attempts to recover from out of memory errors by cleaning up (thus making memory available) and then
- continuing to process events. Let's suppose that's an acceptable design. <font size="+0">emergencyRestart</font> takes
- great care not to allocate memory. The problem is that <font size="+0">emergencyRestart</font> calls some utility
- routine, which calls some other utility routine, which calls some other utility routine-which allocates a new object.
- Except that there's no memory, so the whole program fails. These kinds of problems are hard to find through inspection.
-</p>
-<h3>
- <a id="Test-FirstDesignAndRUPPhases" name="Test-FirstDesignAndRUPPhases">Test-first design and the phases
- of&nbsp;Unified</a> Process
-</h3>
-<p>
- Up to this point, we've implicitly assumed that you'd do as much test design as possible as early as possible. That is,
- you'd derive all the tests you could from the design artifact, later adding only tests based on implementation
- internals. That may not be appropriate in the Elaboration phase, because such complete testing may not be aligned with
- an iteration's objectives.
-</p>
-<p>
- Suppose an architectural prototype is being built to demonstrate product feasibility to investors. It might be based on
- a few key use-case instances. Code should be tested to see that it supports them. But is there any harm if further
- tests are created? For example, it might be obvious that the prototype ignores important error cases. Why not document
- the need for that error handling by writing test cases that will exercise it?
-</p>
-<p>
- But what if the prototype does its job and reveals that the architectural approach won't work? Then the architecture
- will be thrown away - along with all those tests for error-handling. In that case, the effort of designing the tests
- will have yielded no value. It would have been better to have waited, and only designed those tests needed to check
- whether this proof-of-concept prototype really proves the concept.
-</p>
-<p>
- This may seem a minor point, but there are strong psychological effects in play. The Elaboration phase is about
- addressing major risks. The whole project team should be focused on those risks. Having people concentrating on minor
- issues drains focus and energy from the team.
-</p>
-<p>
- So where might test-first design be used successfully in the Elaboration phase? It can play an important role in
- adequately exploring architectural risks. Considering how, precisely, the team will know if a risk has been realized or
- avoided will add clarity to the design process and may well result in a better architecture being built the first time.
-</p>
-<p>
- During the Construction phase, design artifacts are put into their final form. All the required use-case realizations
- are implemented, as are the interfaces for all classes. Because the phase objective is completeness, complete
- test-first design is appropriate. Later events should invalidate few, if any, tests.
-</p>
-<p>
- The Inception and Transition phases typically have less focus on design activities for which testing is appropriate.
- When it is, test-first design is applicable. For example, it could be used with candidate proof-of-concept work in
- Inception. As with Construction and Elaboration phase testing, it should be aligned with iteration objectives.
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/concepts/test-ideas_catalog.xmi b/XP/xp/guidances/concepts/test-ideas_catalog.xmi
deleted file mode 100644
index 157b36b..0000000
--- a/XP/xp/guidances/concepts/test-ideas_catalog.xmi
+++ /dev/null
@@ -1,458 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-OrjIrRLW6v_XnqLUQ9GYaQ" name="test-ideas_catalog,1.2384224477983028E-305" guid="-OrjIrRLW6v_XnqLUQ9GYaQ" changeDate="2006-12-01T16:08:47.336-0800" version="1.0.0">
- <mainDescription><a id="XE_test-ideas_catalog__concept_of" name="XE_test-ideas_catalog__concept_of"></a>
-<h3>
- <a id="Introduction" name="Introduction">Introduction</a>
-</h3>
-<p>
- Much of programming involves taking things you've used over and over before, and then using them yet again in a
- different context. Those things are typically of certain classes-data structures (such as linked lists, hash tables, or
- relational databases) or <a href="./../../../glossary/glossary.htm#operation" target="_blank"><i>operations</i></a>
- (such as searching, sorting, creating temporary files, or popping up a browser window). For example, two customer
- relational databases will have many clichéd characteristics.
-</p>
-<p>
- The interesting thing about these clichés is that they have clichéd <a href="./../../../glossary/glossary.htm#fault"
- target="_blank"><i>faults</i></a>. People do not invent imaginative new ways to insert something incorrectly into a
- doubly-linked list. They tend to make the same mistakes that they and others have made before. A programmer who pops up
- a browser window might make one of these clichéd mistakes:
-</p>
-<ul>
- <li>
- creates a new window when one that's already open should be reused
- </li>
- <li>
- fails to make an obscured or minimized browser window visible
- </li>
- <li>
- uses Internet Explorer when the user has chosen a different default browser
- </li>
- <li>
- fails to check whether JavaScript is enabled
- </li>
-</ul>
-<p>
- Since faults are clichéd, so are the <a href="./../../../glossary/glossary.htm#test_idea" target="_blank"><i>test
- ideas</i></a> that can find them. Put these test ideas in your test-idea catalog so you can reuse them.
-</p>
-<h3>
- <a id="HowCatalogsFindFaults" name="HowCatalogsFindFaults">How a Test-Ideas Catalog Finds Faults</a>
-</h3>
-<p>
- One of the virtues of a catalog is that a single test idea can be useful for finding more than one underlying fault.
- Here's an example of one idea that finds two faults.
-</p>
-<p>
- The first fault was in a C compiler. This compiler took command-line options like "-table" or "-trace" or "-nolink".
- The options could be abbreviated to their smallest unique form. For example, "-ta" was as good as "-table". However,
- "-t" was not allowed, because it was ambiguous: it could mean either "-table" or "-trace".
-</p>
-<p>
- Internally, the command-line options were stored in a table like this:
-</p>
-<div align="left">
- <table cellspacing="0" cellpadding="2" width="25%" border="1">
- <tbody>
- <tr>
- <td width="100%">
- -table
- </td>
- </tr>
- <tr>
- <td width="100%">
- -trace
- </td>
- </tr>
- <tr>
- <td width="100%">
- -nolink
- </td>
- </tr>
- </tbody>
- </table>
- <br />
-</div>
-<p>
- When an option was encountered on the command line, it was looked up in the table. It matched if it was the prefix of
- any table entry; that is, "-t" matched "-table". After one match was found, the rest of the table was searched for
- another match. Another match would be an error, because it would indicate ambiguity.
-</p>
-<p>
- The code that did the searching looked like this:
-</p>
-<blockquote>
-<pre>
-for (first=0; first &lt; size; first++) {
- if (matches(entry[first], thing_sought)) {
-/* at least one match */
-for(dup=first+1; dup &lt; size; dup++)
- /* search for another */
- if (matches(entry[dup], thing_sought))
- /* extra match */
- break; /* error out */
-return first;
- }
-}
-return -1; /* Not found or ambiguity */
-</pre>
-</blockquote>
-<p>
- Do you see the problem? It's fairly subtle.
-</p>
-<p>
- The problem is the break statement. It's intended to break out of the outermost enclosing loop when a duplicate match
- is found, but it really breaks out of the inner one. That has the same effect as not finding a second match: the index
- of the first match is returned.
-</p>
-<p>
- Notice that this fault can only be found if the option being sought for matches twice in the table, as "-t" would.
-</p>
-<p>
- Now let's look at a second, completely different fault.
-</p>
-<p>
- The code takes a string. It is supposed to replace the last '=' in the string with a '+'. If there is no '=', nothing
- is done. The code uses the standard C library routine <font size="+0">strchr</font> to find the location of '='. Here's
- the code:
-</p>
-<blockquote>
-<pre>
-ptr = strchr(string, '='); /* Find last = */
-if (ptr != NULL_CHAR)
- *ptr = '+';
-</pre>
-</blockquote>
-<p>
- This problem here is also somewhat subtle.
-</p>
-<p>
- The function <font size="+0">strchr</font> returns the <i>first</i> match in the string, not the last. The correct
- function is <font size="+0">str<b><u>r</u></b>chr</font>. The problem was most likely a typographical error. (Actually,
- the deep underlying problem is that it's definitely unwise to put two functions that differ only by a typo into a
- standard library.)
-</p>
-<p>
- This fault can only be found when there are two or more equal signs in the input. That is:
-</p>
-<ul>
- <li>
- "a=b" would return the correct result, "a+b".
- </li>
- <li>
- "noequals" would return the correct result, "noequals".
- </li>
- <li>
- "a=b=c" would incorrectly return "a+b=c", not the correct "a=b+c"
- </li>
-</ul>
-<p>
- What's interesting and useful here is that we have two faults with completely different root causes (typographical
- error, misunderstanding of a C construct) and different manifestations in the code (wrong function called, misuse of
- break statement) that can be found by the <i>same</i> test idea (search for something that occurs twice).
-</p>
-<h3>
- <a id="GoodCatalogs" name="GoodCatalogs">A Good Test-Ideas Catalog</a>
-</h3>
-<p>
- What makes a good catalog?
-</p>
-<ul>
- <li>
- It contains a small set of test ideas that can find a much larger set of underlying faults.
- </li>
- <li>
- It's easy to read quickly (skim). You should be able to skip test ideas that are not relevant to your situation.
- </li>
- <li>
- It contains only test ideas that you will use. For example, someone who doesn't ever deal with Web browsers
- shouldn't have to keep skipping over test ideas for programs that use Web browsers. Someone working on game
- software will want a shorter catalog than someone working on safety-critical software. The game person can afford
- to concentrate only on the test ideas with the highest chance of finding faults.
- </li>
-</ul>
-<p>
- Given these rules, it seems best to have more than one catalog. Some data and operations are common to all programming,
- so their test ideas can be put into a catalog that all programmers can use. Others are specific to a particular domain,
- so test ideas for them can be put into a catalog of domain-specific test ideas.
-</p>
-<p>
- A sample catalog (<a href="./resources/tstids_short-catalog.pdf" target="_blank">tstids_short-catalog.pdf</a>) (<a
- href="http://www.adobe.com/products/acrobat/alternate.html">Get Adobe Reader</a>), used in the following example, is a
- good one from which to begin. <a href="../../../examples/extrnlcntrbtns/test/tstatmtch.htm">Test Ideas for Mixtures of
- ANDs and ORs</a> provides another example.
-</p>
-<h3>
- <a id="UsingACatalogExample" name="UsingACatalogExample">An Example of Using a Test-Ideas Catalog</a>
-</h3>
-<p>
- Here's how you might use the sample catalog (<a href="./resources/tstids_short-catalog.pdf"
- target="_blank">tstids_short-catalog.pdf</a>) (<a href="http://www.adobe.com/products/acrobat/alternate.html">Get
- Acrobat Reader</a>). Suppose you're implementing this method:
-</p>
-<blockquote>
-<pre>
-void applyToCommonFiles(Directory d1,
- Directory d2,
- Operation op);
-</pre>
-</blockquote>
-<p>
- <font size="+0">applyToCommonFiles</font> takes two directories as arguments. When a file in the first directory has
- the same name as a file in the second, <font size="+0">applyToCommonFiles</font> performs some operation on that pair
- of files. It descends subdirectories.
-</p>
-<p>
- The method for using the catalog is to scan through it looking for major headings that match your situation. Consider
- the test ideas under each heading to see if they are relevant, and then write those that are relevant into a <a
- class="elementLink" href="./../../../xp/guidances/concepts/test-ideas_list,8.834380241450745E-306.html"
- guid="8.834380241450745E-306">Test-Ideas List</a>.
-</p>
-<p>
- <b>Note:</b> This step-by-step description might make using the catalog seem laborious. It takes longer to read about
- creating the checklist than it does to actually create one.
-</p>
-<p>
- So, in the case of <font size="+0">applyToCommonFiles</font>, you might apply the catalog in the manner described
- throughout the rest of this section.
-</p>
-<p>
- The first entry is for <b>Any Object</b>. Could any of the arguments be null pointers? This is a matter of the contract
- between <font size="+0">applyToCommonFiles</font> and its callers. The contract could be that the callers will not pass
- in a null pointer. If they do, you can't rely on th expected behavior: <font size="+0">applyToCommonFiles</font> could
- perform any action. In such a case, no test is appropriate, since nothing <font size="+0">applyToCommonFiles</font>
- does can be wrong. If, however, <font size="+0">applyToCommonFiles</font> is required to check for null pointers, the
- test idea would be useful. Let's assume the latter, which gives us this starting Test-Ideas List:
-</p>
-<ul>
- <li>
- d1 is null (error case)
- </li>
- <li>
- d2 is null (error case)
- </li>
- <li>
- op is null (error case)
- </li>
-</ul>
-<p>
- The next catalog entry is <b>Strings</b>. The names of the files are strings, and they're compared to see if they
- match. The idea of testing with the empty string ("") doesn't seem useful. Presumably some standard string comparison
- routines will be used, and they will handle empty strings correctly.
-</p>
-<p>
- But wait... If there are strings being compared, what about case? Suppose <font size="+0">d1</font> contains a file
- named "File" and <font size="+0">d2</font> contains a file named "file". Should those files match? On UNIX, clearly
- not. On Microsoft&reg; Windows&reg;, they almost certainly should. That's another test idea:
-</p>
-<ul>
- <li>
- Files match in the two directories, but the case of the names is different.
- </li>
-</ul>
-<p>
- Notice that this test idea didn't come directly from the catalog. However, the catalog drew our attention to a
- particular aspect of the program (file names as strings), and our creativity gave us an additional idea. It's important
- not to use the catalog too narrowly-use it as a brainstorming technique, a way of inspiring new ideas.
-</p>
-<p>
- The next entry is <b>Collections</b>. A directory is a collection of files. Many programs that handle collections fail
- on the empty collection. A few that handle the empty collection, or collections with many elements, fail on collections
- with exactly one element. So these ideas are useful:
-</p>
-<ul>
- <li>
- d1 is empty
- </li>
- <li>
- d2 is empty
- </li>
- <li>
- d1 has exactly one file
- </li>
- <li>
- d2 has exactly one file
- </li>
-</ul>
-<p>
- The next idea is to use a collection of the maximum possible size. This is useful because programs like <font
- size="+0">applyToCommonFiles</font> are often tested with trivial little directories. Then some user comes along and
- applies them to two huge directory trees with thousands of files in them, only to discover that the program is
- grotesquely memory inefficient and can't handle that realistic case.
-</p>
-<p>
- Now, testing the absolute maximum size for a directory is not important; it only needs to be as large as a user might
- try. However, at the very least, there should be <i>some</i> test with more than three files in a directory:
-</p>
-<ul>
- <li>
- d1 contains very many files
- </li>
- <li>
- d2 contains very many files
- </li>
-</ul>
-<p>
- The final test idea (duplicate elements) doesn't apply to directories of files. That is, if you have a directory with
- two files that have the same name, you have a problem independent of <font size="+0">applyToCommonFiles</font>-your
- file system is corrupt.
-</p>
-<p>
- The next catalog entry is <b>Searching</b>. Those ideas can be translated into <font
- size="+0">applyToCommonFiles</font> terms like this:
-</p>
-<ul>
- <li>
- d1 and d2 have no files in common (all the names are different)
- </li>
- <li>
- d1 and d2 have exactly one file in common (it's alphabetically the last element in the directory)
- </li>
- <li>
- d1 and d2 have more than one file in common
- </li>
-</ul>
-<p>
- The final test idea checks whether <font size="+0">applyToCommonFiles</font> terminates too soon. Does it return as
- soon as it finds the first match? The parenthetical remark in the test idea before that assumes that the program will
- fetch the list of files in a directory using some library routine that returns them, sorted alphabetically. If not, it
- might be better to find out what the last one really is (the most recently created?) and make that be the match. Before
- you devote a lot of time to finding out how files are ordered, though, ask yourself how likely it is that putting the
- matching element last will make finding defects easier. Putting an element last in a collection is more useful if the
- code explicitly steps through the collection using an index. If it's using an iterator, it's extremely unlikely that
- the order matters.
-</p>
-<p>
- Let's look at one more entry in the sample catalog. The <b>Linked structures</b> entry reminds us that we're comparing
- directory <i>trees</i>, not just flat collections of files. It would be sad if <font
- size="+0">applyToCommonFiles</font> worked only in the top-level directories, but not in the lower-level ones. Deciding
- how to test whether <font size="+0">applyToCommonFiles</font> works in lower-level directories forces us to confront
- the incompleteness of its description.
-</p>
-<p>
- First, when does <font size="+0">applyToCommonFiles</font> descend into subdirectories? If the directory structure
- looks like this
-</p>
-<p align="center">
- <img height="162" alt="" src="resources/tstidsctl-img1.gif" width="334" />
-</p>
-<p class="picturetext">
- Figure 1: A directory structure
-</p>
-<p>
- does <font size="+0">applyToCommonFiles</font> descend into <font size="+0">Cdir</font>? That doesn't seem to make
- sense. There can be no match with anything in the other directory tree. In fact, it seems as if files in subdirectories
- can only match if the subdirectory names match. That is, suppose we have this directory structure:
-</p>
-<p align="center">
- <img height="165" alt="" src="resources/tstidsctl-img2.gif" width="334" />
-</p>
-<p class="picturetext">
- Figure 2: A second directory structure
-</p>
-<p>
- The files named "File" don't match because they're in different subdirectories The subdirectories should be descended
- only if they have the same name in both <font size="+0">d1</font> and <font size="+0">d2</font>. That leads to these
- test ideas:
-</p>
-<ul>
- <li>
- some subdirectory in d1 is not found in d2 (no descent)
- </li>
- <li>
- some subdirectory in d2 is not found in d1 (no descent)
- </li>
- <li>
- some subdirectory appears in both d1 and d2 (descend)
- </li>
-</ul>
-<p>
- But that raises other questions. Should the operation (<font size="+0">op</font>) be applied to matching subdirectories
- or just to matching files? If it's applied to the subdirectories, should it be applied before the descent or afterward?
- That makes a difference if, for example, the operation deletes the matching file or directory. For that matter,
- <i>should</i> the operation be allowed to modify the directory structure? And more specifically: what's the correct
- behavior of <font size="+0">applyToCommonFiles</font> if it does? (This is the same issue that comes up with
- iterators.)
-</p>
-<p>
- These sorts of questions typically arise when you carefully read a method's description of creating test ideas. But
- let's leave them aside for now. Whatever the answers are, there will have to be test ideas for them-test ideas that
- check whether the code correctly implements the answers.
-</p>
-<p>
- Let's return to the catalog. We still haven't considered all of its test ideas. The first one-empty (nothing in
- structure)-asks for an empty directory. We've already got that from the <b>Collections</b> entry. We've also got the
- <b>minimal non-empty</b> structure, which is a directory with a single element. This sort of redundancy is not
- uncommon, but it's easy to ignore.
-</p>
-<p>
- What about <b>a circular structure</b>? Directory structures can't be circular-a directory can't be within one of its
- descendants or within itself... or can it? What about shortcuts (on Windows) or symbolic links (on UNIX)? If there's a
- shortcut in <font size="+0">d1</font>'s directory tree that points back to <font size="+0">d1</font>, should <font
- size="+0">applyToCommonFiles</font> keep descending forever? The answer could lead to one or more new test ideas:
-</p>
-<ul>
- <li>
- d1 is circular because of shortcuts or symbolic links
- </li>
- <li>
- d2 is circular because of shortcuts or symbolic links
- </li>
-</ul>
-<p>
- Depending on the correct behavior, there may be more test ideas than that.
-</p>
-<p>
- Finally, what about <b>depth greater than one</b>? Earlier test ideas will ensure that we test descending into one
- level of subdirectory, but we should check that <font size="+0">applyToCommonFiles</font> keeps descending:
-</p>
-<ul>
- <li>
- descends through several levels (&gt;1) of d1's subdirectories
- </li>
- <li>
- descends through several levels (&gt;1) of d2's subdirectories
- </li>
-</ul>
-<h3>
- <a id="CreatingYourOwnCatalogs" name="CreatingYourOwnCatalogs">Creating and Maintaining Your Own Test-Ideas Catalog</a>
-</h3>
-<p>
- As mentioned previously, the generic catalog won't contain all of the test ideas you need. But <a
- href="./../../../glossary/glossary.htm#domain" target="_blank"><i>domain</i></a>-specific catalogs haven't been
- published outside of the companies that created them. If you want them, you'll need to build them. Here's some advice.
-</p>
-<ul>
- <li>
- Do not fill a catalog with your speculations about what ideas would be good for finding faults. Remember that each
- test idea you put in the catalog costs time and money:
- <ul>
- <li>
- your time to maintain the catalog
- </li>
- <li>
- other programmers' time to think about the test idea
- </li>
- <li>
- possibly other programmers' time to implement a test
- </li>
- </ul>
- <br />
- Add only ideas that have a demonstrated track record. You should be able to point to at least one actual fault
- that the test idea would have caught. Ideally, the fault should be one that was missed by other testing; that is,
- one that was reported from the field. One good way to build catalogs is to browse through your company's bug
- database and ask questions about how each fault could have been detected earlier.
- </li>
- <li style="LIST-STYLE-TYPE: none">
- <br />
- <br />
- </li>
- <li>
- It's unlikely to work if creating and maintaining a Test-Ideas Catalog is something you do in your spare time.
- You'll need time specifically allocated to this task, just like for any other important one. We recommend you
- create and maintain your Test-Ideas Catalog during <a href="wfs_imptstast.htm">Workflow Detail: Improve Test
- Assets</a>.
- </li>
-</ul>
-<br />
-<br /></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/concepts/test-ideas_list.xmi b/XP/xp/guidances/concepts/test-ideas_list.xmi
deleted file mode 100644
index ebda44f..0000000
--- a/XP/xp/guidances/concepts/test-ideas_list.xmi
+++ /dev/null
@@ -1,292 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-3i1jvKMUGGmAYPw4dHFbEg" name="test-ideas_list,8.834380241450745E-306" guid="-3i1jvKMUGGmAYPw4dHFbEg" changeDate="2006-12-01T15:44:08.749-0800" version="1.0.0">
- <mainDescription><h3>
- <a id="Introduction" name="Introduction">Introduction</a>
-</h3>
-<p>
- Information used in designing tests is gathered from many places: design models, classifier interfaces, statecharts,
- and code itself. At some point, this source document information must be transformed into executable tests:
-</p>
-<ul>
- <li>
- specific inputs given to the software under test
- </li>
- <li>
- in a particular hardware and software configuration
- </li>
- <li>
- initialized to a known state
- </li>
- <li>
- with specific results expected
- </li>
-</ul>
-<p>
- It's possible to go directly from source document information to executable tests, but it's often useful to add an
- intermediate step. In this step, test ideas are written into a <i>Test-Ideas List</i>, which is used to create
- executable tests.
-</p>
-<h3>
- <a id="TestIdeas" name="TestIdeas">What are Test Ideas?</a>
-</h3>
-<p>
- A test idea (sometimes referred to as a test requirement) is a brief statement about a test that could be performed. As
- a simple example, let's consider a function that calculates a square root and come up with some test ideas:
-</p>
-<ul>
- <li>
- give a number that's barely less than zero as input
- </li>
- <li>
- give zero as the input
- </li>
- <li>
- test a number that's a perfect square, like 4 or 16 (is the result exactly 2 or 4?)
- </li>
-</ul>
-<p>
- Each of these ideas could readily be converted into an executable test with exact descriptions of inputs and expected
- results.
-</p>
-<p>
- There are two advantages to this less-specific intermediate form:
-</p>
-<ul>
- <li>
- test ideas are more reviewable and understandable than complete tests - it's easier to understand the reasoning
- behind them
- </li>
- <li>
- test ideas support more powerful tests, as described later under the heading <a href="#TestDesignUsingTheList">Test
- Design Using the List</a>
- </li>
-</ul>
-<p>
- The square root examples all describe inputs, but test ideas can describe any of the elements of an executable test.
- For example, "print to a LaserJet IIIp" describes an aspect of the test environment to be used for a test, as does
- "test with database full", however, these latter test ideas are very incomplete in themselves: Print <b>what</b> to the
- printer? Do <b>what</b> with that full database? They do, however, ensure that important ideas aren't forgotten; ideas
- that will be described in more detail later in test design.
-</p>
-<p>
- Test ideas are often based on fault&nbsp;models; notions of which faults are plausible in software and how those faults
- can best be uncovered. For example, consider boundaries. It's safe to assume the square root function can be
- implemented something like this:
-</p>
-<blockquote>
-<pre>
- double sqrt(double x) { if (x &lt; 0) // signal error ...
-</pre>
-</blockquote>
-<p>
- It's also plausible that the <font size="+0">&lt;</font> will be incorrectly typed as <font size="+0">&lt;=</font>.
- People often make that kind of mistake, so it's worth checking. The fault cannot be detected with <font
- size="+0">X</font> having the value <font size="+0">2</font>, because both the incorrect expression (<font
- size="+0">x&lt;=0</font>) and the correct expression (<font size="+0">x&lt;0</font>) will take the same branch of the
- <font size="+0">if</font> statement. Similarly, giving <font size="+0">X</font> the value -<font size="+0">5</font>
- cannot find the fault. The only way to find it is to give <font size="+0">X</font> the value <font size="+0">0</font>,
- which justifies the second test idea.
-</p>
-<p>
- In this case, the fault model is explicit. In other cases, it's implicit. For example, whenever a program manipulates a
- linked structure, it's good to test it against a circular one. It's possible that many faults could lead to a
- mishandled circular structure. For the purposes of testing, they needn't be enumerated - it suffices to know that some
- fault is likely enough that the test is worth running.
-</p>
-<p>
- The following links provide information about getting test ideas from different kinds of fault models. The first two
- are explicit fault models; the last uses implicit ones.
-</p>
-<ul>
- <li>
- <a class="elementLinkWithType"
- href="./../../../xp/guidances/guidelines/test_ideas_for_booleans_and_boundaries,1.7150344523489172E-305.html"
- guid="1.7150344523489172E-305">Guideline: Test Ideas for Booleans and Boundaries</a>
- </li>
- <li>
- <a class="elementLinkWithType"
- href="./../../../xp/guidances/guidelines/test_ideas_for_method_calls,8.5657170364036E-306.html"
- guid="8.5657170364036E-306">Guideline: Test Ideas for Method Calls</a>
- </li>
- <li>
- <a class="elementLinkWithType"
- href="./../../../xp/guidances/concepts/test-ideas_catalog,1.2384224477983028E-305.html"
- guid="1.2384224477983028E-305">Concept: Test-Ideas Catalog</a>
- </li>
-</ul>
-<p>
- These fault models can be applied to many different artifacts. For example, the first one describes what to do with
- Boolean expressions. Such expressions can be found in code, in guard conditions, in statecharts and sequence diagrams,
- and in natural-language descriptions of method behaviors (such as you might find in a published API).
-</p>
-<p>
- Occasionally it's also helpful to have guidelines for specific artifacts. See <a class="elementLinkWithType"
- href="./../../../xp/guidances/guidelines/test_ideas_for_statechart_and_flow_diagrams,1.0347051690476123E-305.html"
- guid="1.0347051690476123E-305">Guideline: Test Ideas for Statechart and Flow Diagrams</a>.
-</p>
-<p>
- A particular Test-Ideas List might contain test ideas from many fault models, and those fault models could be derived
- from more than one artifact.
-</p>
-<h3>
- <a id="TestDesignUsingTheList" name="TestDesignUsingTheList">Test Design Using the List</a>
-</h3>
-<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.
-</p>
-<blockquote>
-<pre>
- int Collection.find(String string, Boolean ignoreCase);
-</pre>
-</blockquote>
-<p>
- Here are some test ideas for this method:
-</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>
- It would be simple to implement these seven tests, one for each test idea. However, different test ideas can be
- combined into a single test. For example, the following test <i>satisfies</i> test ideas 2, 6, and 7:
-</p>
-<blockquote>
- <p>
- Setup: collection initialized to ["dawn", "Dawn"]<br />
- Invocation: collection.find("Dawn", false)<br />
- Expected result: return value is 1 (it would be 0 if "dawn" were not skipped)
- </p>
-</blockquote>
-<p>
- Making test ideas nonspecific makes them easier to combine.
-</p>
-<p>
- It's possible to satisfy all of the test ideas in three tests. Why would three tests that satisfy seven test ideas be
- better than seven separate tests?
-</p>
-<ul>
- <li>
- When you're creating a large number of simple tests, it's common to create test N+1 by copying test N and tweaking
- it just enough to satisfy the new test idea. The result, especially in more complex software, is that test N+1
- probably exercises the program in almost the same way as test N. It takes almost exactly the same path through the
- code.<br />
- <br />
- A smaller number of tests, each satisfying several test ideas, doesn't allow a "copy and tweak" approach. Each
- test will be somewhat different from the last, exercising the code in different ways and taking different
- paths.<br />
- <br />
- Why would that be better? 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. By
- having each test do very different things from the last one - by adding seemingly unneeded variety - you increase
- the chance that one of the tests will stumble over a bug by sheer dumb luck. In effect, smaller, more complex tests
- increase the chance the test will satisfy a test idea that you didn't know you needed.<br />
- </li>
- <li>
- Sometimes when you're creating more complex tests, new test ideas come to mind. That happens less often with simple
- tests, because so much of what you're doing is exactly like the last test, which dulls your mind.
- </li>
-</ul>
-<p>
- However, there are reasons for not creating complex tests.
-</p>
-<ul>
- <li>
- If each test satisfies a single test idea and the test for idea 2 fails, you immediately know the most likely
- cause: the program doesn't handle a match in the last position. If a test satisfies ideas 2, 6, and 7, then
- isolating the failure is harder.<br />
- </li>
- <li>
- Complex tests are more difficult to understand and maintain. The intent of the test is less obvious.<br />
- </li>
- <li>
- Complex tests are more difficult to create. Constructing a test that satisfies five test ideas often takes more
- time than constructing five tests that each satisfy one. Moreover, it's easier to make mistakes - to think you're
- satisfying all five when you're only satisfying four.
- </li>
-</ul>
-<p>
- In practice, you must find a reasonable balance between complexity and simplicity. For example, the first tests you
- subject the software to (typically the smoke tests) should be simple, easy to understand and maintain, and intended to
- catch the most obvious problems. Later tests should be more complex, but not so complex they are not maintainable.
-</p>
-<p>
- After you've finished a set of tests, it's good to check them against the characteristic test design mistakes discussed
- in <a class="elementLinkWithType"
- href="./../../../xp/guidances/concepts/developer_testing,4.085829182735815E-305.html#TestDesignMistakes"
- guid="4.085829182735815E-305">Concept: Developer Testing</a>.
-</p>
-<h3>
- <a id="UsingTestIdeasBeforeTest" name="UsingTestIdeasBeforeTest">Using Test Ideas Before Testing</a>
-</h3>
-<p>
- A Test-Ideas List is useful for reviews and inspections of design artifacts. For example, consider this part of a
- design model showing the association between Department and Employee classes.
-</p>
-<p align="center">
- <img height="45" alt="" src="resources/tstidslst-img1.gif" width="223" />
-</p>
-<p class="picturetext">
- Figure 1: Association between Department and Employee Classes
-</p>
-<p>
- The rules for creating test ideas from such a model would ask you to consider the case where a department has many
- employees. By walking through a design and asking "what if, at this point, the department has many employees?", you
- might discover design or analysis errors. For example, you might realize that only one employee at a time can be
- transferred between departments. That might be a problem if the corporation is prone to sweeping reorganizations where
- many employees need to be transferred.
-</p>
-<p>
- Such faults, cases where a possibility was overlooked, are called <i>faults of omission</i>. Just like the faults
- themselves, you have probably omitted tests that detect these faults from your testing effort. For example, see <a
- class="elementLinkWithUserText"
- href="./../../../xp/guidances/supportingmaterials/xp_and_agile_process_references,6.191633934532389E-306.html"
- guid="6.191633934532389E-306">[GLA81]</a>, &nbsp;<a href="../../referenc.htm#OST84">[OST84]</a>, <a
- href="../../referenc.htm#BAS87">[BAS87]</a>, <a href="../../referenc.htm#MAR00">[MAR00]</a>, and other studies that
- show how often faults of omission escape into deployment.
-</p>
-<p>
- The role of testing in design activities is discussed further in <a class="elementLinkWithType"
- href="./../../../xp/guidances/concepts/test-first_design,6.556259235358794E-306.html"
- guid="6.556259235358794E-306">Concept: Test-first Design</a>.
-</p>
-<h3>
- <a id="TestIdeasTraceability" name="TestIdeasTraceability">Test Ideas and Traceability</a>
-</h3>
-<p>
- Traceability is a matter of tradeoffs. Is its value worth the cost of maintaining it? This question needs to be
- considered during <a href="../../activity/ac_tst_dfnasstrcnds.htm">Activity: Define Assessment and Traceability
- Needs</a>.
-</p>
-<p>
- When traceability is worthwhile, it's conventional to trace tests back to the artifacts that inspired them. For
- example, you might have traceability between an API and its tests. If the API changes, you know which tests to change.
- If the code (that implements the API) changes, you know which tests to run. If a test puzzles you, you can find the API
- it's intended to test.
-</p>
-<p>
- The Test-Ideas List adds another level of traceability. You can trace from a test to the test ideas it satisfies, and
- then from the test ideas to the original artifact.
-</p>
-<br />
-<br /></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/concepts/test_driven_development.xmi b/XP/xp/guidances/concepts/test_driven_development.xmi
deleted file mode 100644
index f33515e..0000000
--- a/XP/xp/guidances/concepts/test_driven_development.xmi
+++ /dev/null
@@ -1,100 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-yaD6WKGdrZ0n0yBSpwPr4g" name="test_driven_development,1.620567348185129E-306" guid="-yaD6WKGdrZ0n0yBSpwPr4g" changeDate="2006-11-21T15:06:48.997-0800" version="1.0.0">
- <mainDescription><a id="XE_xp__test_driven_development" name="XE_xp__test_driven_development"></a><a
-id="XE_test_driven_development__practice_of" name="XE_test_driven_development__practice_of"></a><a
-id="XE_engineering_practices__test_driven_development" name="XE_engineering_practices__test_driven_development"></a>
-<h3>
- Description
-</h3>
-<p>
- Test-Driven Development is one of the core programming practices of XP. Many of us have learned over the years the
- value of writing automated tests for our code. Many of us have also learned the difficulty of writing tests after code
- is already in place. Test-Driven Development takes a different, extreme approach to ensure that we test all code, all
- the time.
-</p>
-<p>
- The practice of Test-Driven Development requires a change in how you program and in how you think. You won't write
- tests as an afterthought. You won't be trying to see if the code you have written works. Instead, you will write tests
- as part of the everyday, every minute way of building software. Instead of writing detailed design specifications on
- paper, write the spec in code. Instead of first striving to perfectly design a system on paper, use tests to guide your
- design. Instead of coding for hours at a stretch only to find that the planning went awry, use Test-Driven Development
- to pace yourself, always assuring forward progress with the firm foundation of an ever-growing suite of running tests.
-</p>
-<p>
- The steps:
-</p>
-<ul>
- <li>
- Have an idea where you are going.
- </li>
- <li>
- Write a test that specifies a tiny bit of functionality.
- </li>
- <li>
- Ensure that the test fails (you haven't built the functionality yet!).
- </li>
- <li>
- Write only the code necessary to make the test pass.
- </li>
- <li>
- Refactor the code, ensuring that it has the clear and simple design for the functionality built to date.
- </li>
- <li>
- Repeat until you have the desired functionality.
- </li>
-</ul>
-<p>
- The rules:
-</p>
-<ul>
- <li>
- Test everything that can possibly break.
- </li>
- <li>
- Tests come first.
- </li>
- <li>
- All tests run at 100% all the time.
- </li>
-</ul>
-<p>
- Test-Driven Development is infectious! Developers swear by it. Developers do not seem to abandon it after giving it an
- honest trial.
-</p>
-<h3>
- Benefits
-</h3>
-<ul>
- <li>
- Testable modules are decoupled from other complex classes, resulting in <b>loosely coupled modules</b>. Loosely
- coupled modules are a sign of good design.
- </li>
- <li>
- Code is written so that <b>modules are testable in isolation</b>. Code written without tests in mind is often
- highly coupled, a big hint that you have a poor object-oriented design. If you have to write tests first, you'll
- devise ways of minimizing dependencies in your system in order to write your tests.
- </li>
- <li>
- The <b>tests act as documentation,</b> providing concrete examples of how to use the module being tested.
- </li>
- <li>
- The tests are the first client of your classes; they <b>show how the developer intended the class to be used</b>.
- </li>
- <li>
- The <b>tests act as a safety net</b>. Notifying the programmer immediately when a side-effect defect is introduced
- into the system.
- </li>
- <li>
- <b>Development is paced</b>. You can stop at anytime with the tests describing the progress so far. Each
- programming session gives a sense of satisfaction with getting some of the code working.
- </li>
-</ul>
-<h3>
- Related Information
-</h3>
-<p>
- For more information, see <a class="elementLinkWithUserText"
- href="./../../../xp/guidances/guidelines/test_driven_development_tdd,3.9254165491375454E-306.html"
- guid="3.9254165491375454E-306">Test Driven Development Guidelines</a>.
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/concepts/what_is_xp.xmi b/XP/xp/guidances/concepts/what_is_xp.xmi
deleted file mode 100644
index 9147ccc..0000000
--- a/XP/xp/guidances/concepts/what_is_xp.xmi
+++ /dev/null
@@ -1,49 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-nO38_JQ9G3FQvNlAT5Agqg" name="what_is_xp,9.251272550276345E-306" guid="-nO38_JQ9G3FQvNlAT5Agqg" changeDate="2006-11-08T15:33:57.947-0800" version="1.0.0">
- <mainDescription><a id="XE_xp__what_is_it" name="XE_xp__what_is_it"></a><a id="XE_what_is__xp" name="XE_what_is__xp"></a>
-<p>
- Kent Beck, author of <i>Extreme Programming Explained</i> [<a class="elementLinkWithUserText"
- href="./../../../xp/guidances/supportingmaterials/xp_and_agile_process_references,6.191633934532389E-306.html#BEC00"
- guid="6.191633934532389E-306">BEC00</a>], says, "XP is a light-weight methodology for small-to-medium-sized teams
- developing software in the face of vague or rapidly changing requirements." Simply stated, XP is a set of <a
- class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/xp_values,1.076140803519123E-306.html"
- guid="1.076140803519123E-306">values</a>, <a class="elementLinkWithUserText"
- href="./../../../xp/guidances/concepts/xp_rights,3.036332011267074E-306.html" guid="3.036332011267074E-306">rights,</a>
- and best <a class="elementLinkWithUserText"
- href="./../../../xp/customcategories/xp_best_practices,4.315031901943112E-306.html"
- guid="4.315031901943112E-306">practices</a> that support each other in incrementally developing software.
-</p>
-<p>
- When a team is developing software with XP, the customer creates stories that describe the functionality of the
- software. These stories are very lightweight use-cases. They are small units of functionality that require less than
- one or two weeks to implement. Programmers estimate the stories, and, based upon those estimates, the customer decides
- which stories to do first.
-</p>
-<p>
- Development is done iteratively and incrementally. Every two weeks, the programming team delivers working stories to
- the customer. Then the customer chooses another two weeks worth of work. The system grows in functionality, piece by
- piece, steered by the customer. Progress is measured and tracked based on the observable behavior of the team.
-</p>
-<p>
- XP relies on evolutionary design and testing techniques that maintain a high quality design while new functionality is
- being added. These techniques avoid the mess of unmaintainable code through continuous review, an emphasis on
- simplicity, and the backstop of nearly universal test coverage.
-</p>
-<p>
- Programmers work on their programming tasks in pairs. The pair share a single workstation and work together to write a
- single piece of code. Both partners are equally engaged in the writing. The keyboard moves back and forth between them
- frequently.
-</p>
-<p>
- XP programmers practice Test-Driven Development. In short, they write unit tests prior to writing production code.
- However, this is done in very tiny increments. Tiny portions of a test are written first, and then just enough
- production code is written to make those portions pass. This continues iteratively until everything that can be
- practically tested has been tested.
-</p>
-<p>
- XP focuses on continuous delivery of tested, running software from the first day of the project to the last. Delivery
- of real software, combined with simple but frequent planning, provides stakeholders with a clear view of what is done
- and what will be done. This enables the business to steer the project to an on-time shipment of the best possible
- software that can be completed in the time available.
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/concepts/whole_team.xmi b/XP/xp/guidances/concepts/whole_team.xmi
deleted file mode 100644
index 31b9037..0000000
--- a/XP/xp/guidances/concepts/whole_team.xmi
+++ /dev/null
@@ -1,102 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-uqrgrFY-74R1FijPLvcXoQ" name="whole_team,7.89591827591278E-306" guid="-uqrgrFY-74R1FijPLvcXoQ" changeDate="2006-11-08T15:36:31.999-0800" version="1.0.0">
- <mainDescription><h3>
- Description
-</h3>
-<p>
- All the contributors to an XP project sit together, members of a whole team. The team shares the project goals and the
- responsibility for achieving them. This team must include a business representative, the "Customer" who provides the
- requirements, sets the priorities, and steers the project. It's best if the Customer or one of her aides is a real end
- user who knows the domain and what is needed. The team will of course have programmers. The team may include testers,
- who help the Customer define the customer acceptance tests. Analysts may serve as helpers to the Customer, helping to
- define the requirements. There is commonly a coach, who helps the team keep on track and facilitates the process. There
- may be a manager, providing resources, handling external communication and coordinating activities. None of these roles
- is necessarily the exclusive property of just one individual. Everybody on an XP team contributes in any way that they
- can. The best teams have no specialists, only general contributors with special skills.
-</p>
-<p>
- Subservient in organization to the Whole Team are the teams that focus on the business decisions (<a
- class="elementLink" href="./../../../xp/guidances/supportingmaterials/xp_customer_team,2.9889538140050517E-306.html"
- guid="2.9889538140050517E-306">XP Customer Team</a>), the technical decisions (<a class="elementLink"
- href="./../../../xp/guidances/supportingmaterials/xp_developer_team,8.608243854485154E-306.html"
- guid="8.608243854485154E-306">XP Developer Team</a>), and the organization that supports those teams (<a
- class="elementLink" href="./../../../xp/guidances/supportingmaterials/xp_organization,5.613949040902463E-308.html"
- guid="5.613949040902463E-308">XP Organization</a>). To create a context for clear communication, XP provides a set of
- guidelines defining the rights of the customer and developer. These guidelines are referred to as the <a
- class="elementLinkWithUserText" href="./../../../xp/guidances/concepts/xp_rights,3.036332011267074E-306.html"
- guid="3.036332011267074E-306">customer and a developer bill of rights</a>.
-</p>
-<div align="left">
- <table width="75%" border="1">
- <tbody>
- <tr>
- <th width="30%">
- <a class="elementLink"
- href="./../../../xp/guidances/supportingmaterials/xp_customer_team,2.9889538140050517E-306.html"
- guid="2.9889538140050517E-306">XP Customer Team</a>
- </th>
- <th width="34%">
- <a class="elementLink"
- href="./../../../xp/guidances/supportingmaterials/xp_developer_team,8.608243854485154E-306.html"
- guid="8.608243854485154E-306">XP Developer Team</a>
- </th>
- <th width="36%">
- <a class="elementLink"
- href="./../../../xp/guidances/supportingmaterials/xp_organization,5.613949040902463E-308.html"
- guid="5.613949040902463E-308">XP Organization</a>
- </th>
- </tr>
- <tr>
- <td align="middle">
- <a class="elementLinkWithUserText"
- href="./../../../xp/roles/xp_customer,{3C90DD4F-CFDB-4111-922D-3B840B8942DE}.html"
- guid="{3C90DD4F-CFDB-4111-922D-3B840B8942DE}">Customer</a>
- </td>
- <td align="middle">
- <a class="elementLinkWithUserText"
- href="./../../../xp/roles/xp_programmer,{08A6AF28-69B1-42DC-A957-2E6CDCB436C1}.html"
- guid="{08A6AF28-69B1-42DC-A957-2E6CDCB436C1}">Programmer</a>
- </td>
- <td align="middle">
- <a class="elementLinkWithUserText"
- href="./../../../xp/roles/xp_tracker,{D8FE277E-4F9A-47EB-855F-C451D601BBAF}.html"
- guid="{D8FE277E-4F9A-47EB-855F-C451D601BBAF}">Tracker</a>
- </td>
- </tr>
- <tr>
- <td align="middle">
- <a class="elementLinkWithUserText"
- href="./../../../xp/roles/xp_tester,{FB65D00B-8304-4CF7-9969-52CE82F503DC}.html"
- guid="{FB65D00B-8304-4CF7-9969-52CE82F503DC}">Tester</a>
- </td>
- <td align="middle">
- &nbsp;
- </td>
- <td align="middle">
- <a class="elementLinkWithUserText"
- href="./../../../xp/roles/xp_coach,{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}.html"
- guid="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">Coach</a>
- </td>
- </tr>
- </tbody>
- </table>
- <br />
-</div>
-<h3>
- Benefits
-</h3>
-<ul>
- <li>
- <b>Progress visibility</b>: customer gets real feedback on a daily basis.
- </li>
- <li>
- <b>Agility</b>: customer can steer team on a daily basis.
- </li>
- <li>
- <b>Reduces miscommunication</b>: contact is direct and face to face, single point of contact.
- </li>
- <li>
- <b>Speeds up communication</b>: customer is always available to answer questions.
- </li>
-</ul></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/concepts/xp_practices.xmi b/XP/xp/guidances/concepts/xp_practices.xmi
deleted file mode 100644
index 9f35b80..0000000
--- a/XP/xp/guidances/concepts/xp_practices.xmi
+++ /dev/null
@@ -1,98 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-24MPC2FhJbx7Fr0F6QEq8A" name="xp_practices,2.2937799026801584E-305" guid="-24MPC2FhJbx7Fr0F6QEq8A" changeDate="2006-11-08T15:39:14.245-0800" version="1.0.0">
- <mainDescription><a id="XE_xp__practices_of" name="XE_xp__practices_of"></a><a id="XE_practices_in__xp" name="XE_practices_in__xp"></a>
-<p>
- XP is a collection of guiding values and best practices. Most of these practices have been used in the industry in some
- shape or form for a number of years. XP has simply identified them and tried to push the envelope of these practices in
- order to get the most benefit from them. Taken individually, these practices are all fairly simple. But it is the sum
- of all of them that provides the most benefit as they reinforce each other to address the most difficult problems teams
- encounter when developing software.
-</p>
-<br />
-<br />
-<p>
- <img height="540" alt="" src="./../../../xp/resources/circleOfLife.jpg" width="720" usemap="#xp_practices_image_map"
- border="0" /> <map id="xp_practices_image_map" name="xp_practices_image_map">
- <area shape="RECT" coords="298,19,390,88"
- href="./../../../xp/guidances/concepts/whole_team,7.89591827591278E-306.html" />
- <area shape="RECT" coords="176,135,282,200"
- href="./../../../xp/guidances/concepts/collective_ownership,9.300699588493279E-306.html" />
- <area shape="RECT" coords="297,168,434,231"
- href="./../../../xp/guidances/concepts/test_driven_development,1.620567348185129E-306.html" />
- <area shape="RECT" coords="447,135,547,198"
- href="./../../../xp/guidances/concepts/coding_standard,8.8116853923311E-307.html" />
- <area shape="RECT" coords="15,236,122,305"
- href="./../../../xp/guidances/concepts/customer_tests,2.297945473205673E-305.html" />
- <area shape="RECT" coords="218,238,362,307"
- href="./../../../xp/guidances/concepts/pair_programming,3.876855509996079E-307.html" />
- <area shape="RECT" coords="392,241,512,305"
- href="./../../../xp/guidances/concepts/refactoring_xp_programming,1.4410217108363206E-306.html" />
- <area shape="RECT" coords="614,236,714,302"
- href="./../../../xp/guidances/concepts/planning_game,2.7371805612676613E-305.html" />
- <area shape="RECT" coords="143,325,270,393"
- href="./../../../xp/guidances/concepts/continuous_integration,3.193414568279561E-305.html" />
- <area shape="RECT" coords="310,321,412,379"
- href="./../../../xp/guidances/concepts/simple_design,1.6109092258980447E-306.html" />
- <area shape="RECT" coords="468,323,597,393"
- href="./../../../xp/guidances/concepts/xp_sustainable_pace,3.133529870649493E-306.html" />
- <area shape="RECT" coords="307,386,413,436"
- href="./../../../xp/guidances/concepts/metaphor_system_of_names,4.884861766532753E-306.html" />
- <area shape="RECT" coords="312,475,419,539"
- href="./../../../xp/guidances/concepts/small_releases,5.762953011420275E-306.html" />
- <area shape="RECT" target="_blank" coords="561,494,708,538" href="http://www.xprogramming.com" />
- </map>
-</p>
-<p>
- This diagram arranges the core practices of Extreme Programming in a way that makes them easy to remember and that
- exemplifies the steering and control cycles of the process.
-</p>
-<p>
- The outer red circle is called the "Circle of Life". It's what keeps an XP project going, producing tested working
- software. The <a class="elementLink" href="./../../../xp/guidances/concepts/whole_team,7.89591827591278E-306.html"
- guid="7.89591827591278E-306">Whole Team</a>, customer members and development members, work together - preferably
- physically together - to build the project. Using the <a class="elementLinkWithUserText"
- href="./../../../xp/guidances/concepts/planning_game,2.7371805612676613E-305.html"
- guid="2.7371805612676613E-305">Planning Game</a> elements of Release Planning and Iteration Planning, they plan a
- series of <a class="elementLinkWithUserText"
- href="./../../../xp/guidances/concepts/small_releases,5.762953011420275E-306.html" guid="5.762953011420275E-306">Small
- Releases</a> of software that demonstrably pass all the <a class="elementLinkWithUserText"
- href="./../../../xp/guidances/concepts/customer_tests,2.297945473205673E-305.html"
- guid="2.297945473205673E-305">Customer Tests</a>.
-</p>
-<p>
- The innermost blue circle describes the day to day, moment to moment, work of the XP developers. Each feature is
- addressed with <a class="elementLinkWithUserText"
- href="./../../../xp/guidances/concepts/simple_design,1.6109092258980447E-306.html"
- guid="1.6109092258980447E-306">Simple Design</a>, ensuring that the design of the system is just right for the features
- supported. The programmers work in <a class="elementLinkWithUserText"
- href="./../../../xp/guidances/concepts/pair_programming,3.876855509996079E-307.html"
- guid="3.876855509996079E-307">pairs</a> for all production code development, providing continuous code review and
- valuable, team-wide understanding of the system. They build the software using <a class="elementLinkWithUserText"
- href="./../../../xp/guidances/concepts/test_driven_development,1.620567348185129E-306.html"
- guid="1.620567348185129E-306">Test-Driven Development,</a> a technique that produces well-crafted and well-tested
- software with a minimum of wasted effort, and the design is kept clean by the continuous improvement process of <a
- class="elementLinkWithUserText"
- href="./../../../xp/guidances/concepts/refactoring_xp_programming,1.4410217108363206E-306.html"
- guid="1.4410217108363206E-306">Refactoring</a>.
-</p>
-<p>
- The middle green circle contains the important supporting practices of XP. The software is designed according to a
- common, shared, evolving <a class="elementLinkWithUserText"
- href="./../../../xp/guidances/concepts/metaphor_system_of_names,4.884861766532753E-306.html"
- guid="4.884861766532753E-306">Metaphor</a> that helps it all hang together. It is kept <a
- class="elementLinkWithUserText"
- href="./../../../xp/guidances/concepts/continuous_integration,3.193414568279561E-305.html"
- guid="3.193414568279561E-305">continuously integrated</a> with many system builds every day, each one fully tested. The
- team shares ownership of of all the code so that needed changes can be made by any qualified pair, not just by one
- individual. Since everyone works on everything, the team evolves a <a class="elementLinkWithUserText"
- href="./../../../xp/guidances/concepts/coding_standard,8.8116853923311E-307.html" guid="8.8116853923311E-307">standard
- way of coding</a>. Finally, XP teams work at a <a class="elementLinkWithUserText"
- href="./../../../xp/guidances/concepts/xp_sustainable_pace,3.133529870649493E-306.html"
- guid="3.133529870649493E-306">sustainable pace</a> that enables them to deliver tested software on a predictable basis
- from the first day of the project until the last.
-</p>
-<p>
- <br />
- &nbsp;
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/concepts/xp_rights.xmi b/XP/xp/guidances/concepts/xp_rights.xmi
deleted file mode 100644
index fc81ae3..0000000
--- a/XP/xp/guidances/concepts/xp_rights.xmi
+++ /dev/null
@@ -1,48 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-vEvfeoyYAPDr-jfyX2QLww" name="xp_rights,3.036332011267074E-306" guid="-vEvfeoyYAPDr-jfyX2QLww" changeDate="2006-11-08T15:44:06.238-0800" version="1.0.0">
- <mainDescription><a id="XE_xp__bill_of_rights" name="XE_xp__bill_of_rights"></a><a id="XE_bill_of_rights__in_xp"
-name="XE_bill_of_rights__in_xp"></a>
-<h2>
- Developer Bill of Rights
-</h2>
-<ul>
- <li>
- You have the right to know what is needed with clear declarations of priority.
- </li>
- <li>
- You have the right to produce quality work at all times.
- </li>
- <li>
- You have the right to ask for and receive help from peers, superiors, and customers.
- </li>
- <li>
- You have the right to make and update your own estimates.
- </li>
- <li>
- You have the right to accept responsibilities instead of having them assigned to you.
- </li>
-</ul>
-<h2>
- Customer Bill of Rights
-</h2>
-<ul>
- <li>
- You have the right to an overall plan, to know what can be accomplished when and at what cost.
- </li>
- <li>
- You have the right to get the greatest possible value out of every programming week.
- </li>
- <li>
- You have the right to see progress in a running system proven to work by passing repeatable tests that you specify.
- </li>
- <li>
- You have the right to change your mind, to substitute functionality, and to change priorities without paying
- exorbitant costs.
- </li>
- <li>
- You have the right to be informed of schedule changes in time to choose how to reduce the scope to restore the
- original date. You can cancel the project at any time and be left with a useful working system reflecting the
- investment to date.
- </li>
-</ul></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/concepts/xp_sustainable_pace.xmi b/XP/xp/guidances/concepts/xp_sustainable_pace.xmi
deleted file mode 100644
index d782e29..0000000
--- a/XP/xp/guidances/concepts/xp_sustainable_pace.xmi
+++ /dev/null
@@ -1,44 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-DoLoZOTPa_LacQ3jUG_lsg" name="xp_sustainable_pace,3.133529870649493E-306" guid="-DoLoZOTPa_LacQ3jUG_lsg" changeDate="2006-11-09T15:07:23.389-0800" version="1.0.0">
- <mainDescription><a id="XE_xp__sustainable_pace" name="XE_xp__sustainable_pace"></a><a id="XE_sustainable_pace__practice_of"
-name="XE_sustainable_pace__practice_of"></a><a id="XE_engineering_practices__sustainable_pace"
-name="XE_engineering_practices__sustainable_pace"></a>
-<h3>
- Description
-</h3>
-<p>
- The assumption in XP is that software development is not a sprint but a marathon. While a sprinter will easily beat a
- marathon runner over a very short distance, the marathon runner will always win in the long run. Consistently working
- overtime will destroy the team, the design, and eventually the product. It creates an environment that makes it
- impossible to do high quality work. People make more mistakes because they are tired (not to mention their low morale),
- causing bugs that require a lot of time to fix down the line. The end result is that it slows everything and everyone
- down.
-</p>
-<p>
- Continuous overtime can be a symptom of a deeper problem that is not being addressed. Perhaps the process is too broken
- to be fixed by working more. The rule in XP is that, if the team has to do more than one consecutive week of overtime,
- it should reassess the situation and start rethinking the plan. Overtime is OK if you need to get to the end of an
- iteration or a release, but it should always be an exception rather than the rule.
-</p>
-<p>
- Sustainable pace is about fostering a team that can produce a consistent amount of work over a long period of time.
-</p>
-<h3>
- Benefits
-</h3>
-<ul>
- <li>
- <b>Improved predictability</b>: plans become more accurate.
- </li>
- <li>
- <b>Improved product quality</b>: programmers have the time to do the right thing.
- </li>
- <li>
- <b>Improved job satisfaction</b>: programmers can enjoy their work with as little stress as possible.
- </li>
- <li>
- <b>Reduced time to market</b>: less time required to fix bad code and rotting design.<br />
- <br />
- </li>
-</ul></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/concepts/xp_values.xmi b/XP/xp/guidances/concepts/xp_values.xmi
deleted file mode 100644
index e5cb99e..0000000
--- a/XP/xp/guidances/concepts/xp_values.xmi
+++ /dev/null
@@ -1,173 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-pA6XLJKgRiwDTEp_qMlQ9g" name="xp_values,1.076140803519123E-306" guid="-pA6XLJKgRiwDTEp_qMlQ9g" changeDate="2005-12-06T02:48:47.737-0800">
- <mainDescription><a id="XE_xp__core_values" name="XE_xp__core_values"></a>
-<h2>
- <a id="Communication" name="Communication">Communication</a>
-</h2>
-<p>
- XP emphasizes face-to-face communication over other types of communication, such as documents. XP values documents but
- values personal communication even more. In order to facilitate communication, XP teams:
-</p>
-<ul>
- <li>
- Use a common system metaphor or vocabulary.
- </li>
- <li>
- Work closely with one another in an open workspace.
- </li>
- <li>
- Continuously integrate the code.
- </li>
- <li>
- Work closely with the business people, preferably having them in the same room.
- </li>
- <li>
- Program in pairs.
- </li>
- <li>
- Collectively own the code.
- </li>
- <li>
- Frequently plan and report status to the customer.
- </li>
-</ul>
-<h2>
- <a id="Simplicity" name="Simplicity">Simplicity</a>
-</h2>
-<p>
- XP presumes that it is better to do the simple thing today and pay a little more tomorrow if more is really needed than
- to do a more complicated thing today that may never be used. This is a fundamental philosophy that permeates everything
- in an XP project. If something isn't needed today, we don't do it today.
-</p>
-<p>
- For example:
-</p>
-<ul>
- <li>
- We will write no document unless there is an immediate and significant need.
- </li>
- <li>
- We will adopt no tool unless there is a tangible and verifiable benefit.
- </li>
- <li>
- We will avoid writing infrastructure until it is needed by existing code.
- </li>
-</ul>
-<p>
- In order to maintain the simplicity of their software and their team structure, XP teams:
-</p>
-<ul>
- <li>
- Ask themselves: What is the simplest thing that can possibly work?
- </li>
- <li>
- Continuously simplify and improve the design through refactoring.
- </li>
-</ul>
-<p>
- Some time ago, Kent Beck offered the following rules for simple design. In priority order, the code must:
-</p>
-<ol>
- <li>
- Run all the tests.
- </li>
- <li>
- Contain no duplicate code.
- </li>
- <li>
- Express all the ideas the author wants to express.
- </li>
- <li>
- Minimize classes and methods.
- </li>
-</ol>
-<h2>
- <a id="Feedback" name="Feedback">Feedback</a>
-</h2>
-<p>
- Feedback works at different scales in XP.
-</p>
-<p>
- At the highest level, the customer can see the progress of the team through the working software delivered every two
- weeks. This continuous feedback allows the customer to steer the project to success. We get concrete feedback on the
- state of the system in the form of executable pieces of functionality that pass repeatable, automated acceptance tests.
- These tests prevent the system from backsliding. No new release of the system can fail acceptance tests that used to
- work.
-</p>
-<p>
- At the programming level, programmers write unit tests for all the logic in the system to get immediate and concrete
- feedback telling them if the code they just wrote is doing what they expected.
-</p>
-<p>
- XP teams:
-</p>
-<ul>
- <li>
- Develop in small releases.
- </li>
- <li>
- Develop in smaller iterations.
- </li>
- <li>
- Break features and requirements into stories that fit in an iteration.
- </li>
- <li>
- Break stories into even smaller tasks.
- </li>
- <li>
- Write small unit tests to ensure that tasks work properly.
- </li>
- <li>
- Write acceptance tests to ensure that stories work properly.
- </li>
- <li>
- Track progress and communicate it to the customer frequently.
- </li>
-</ul>
-<h2>
- <a id="Courage" name="Courage">Courage</a>
-</h2>
-<p>
- Perhaps a better name for this value is trust. In order to function, the members of an XP team have to have the courage
- to trust each other, trust their customer, trust their practices, and trust themselves.
-</p>
-<p>
- XP team members trust that they can:
-</p>
-<ul>
- <li>
- Stop when they are tired.
- </li>
- <li>
- Let every business decision be made by the customer.
- </li>
- <li>
- Ask customers to reduce the scope of a release.
- </li>
- <li>
- Ask their peers or customers for help.
- </li>
- <li>
- Design and implement only what is needed for today and add tomorrow what will be needed tomorrow.
- </li>
- <li>
- Make changes that improve the functions or structure of the code.
- </li>
- <li>
- Fix the design and retrofit existing code when the design is shown to be inadequate.
- </li>
- <li>
- Throw away code.
- </li>
- <li>
- Change code they did not write.
- </li>
- <li>
- Change the process when it is not working.
- </li>
-</ul>
-<p>
- <br />
- <br />
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/examples/test-ideas_catalog_examples.xmi b/XP/xp/guidances/examples/test-ideas_catalog_examples.xmi
deleted file mode 100644
index 2c3a002..0000000
--- a/XP/xp/guidances/examples/test-ideas_catalog_examples.xmi
+++ /dev/null
@@ -1,6 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-HkQclhewSbkFSomo1l_LBg" name="test-ideas_catalog_examples,6.216049252606417E-306" guid="-HkQclhewSbkFSomo1l_LBg" changeDate="2005-12-06T02:48:05.726-0800">
- <mainDescription><a id="XE_test_idea__example_catalogs_of" name="XE_test_idea__example_catalogs_of"></a><a
-id="XE_test_ideas_catalog__examples_of" name="XE_test_ideas_catalog__examples_of"></a>HTML:&nbsp;<a
-href="resources/tstidactl.htm" target="_blank">tstidactl.htm</a></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/guidelines/equivalence_class_analysis.xmi b/XP/xp/guidances/guidelines/equivalence_class_analysis.xmi
deleted file mode 100644
index 85b2197..0000000
--- a/XP/xp/guidances/guidelines/equivalence_class_analysis.xmi
+++ /dev/null
@@ -1,301 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-c7t_eJuo1g5hpWTYTCItig" name="equivalence_class_analysis,1.8491691792142673E-308" guid="-c7t_eJuo1g5hpWTYTCItig">
- <mainDescription><a id="XE_runtime_observation_&amp;_analysis__concept" name="XE_runtime_observation_&amp;_analysis__concept"></a>
-<h3>
- <a id="Introduction" name="Introduction">Introduction</a>
-</h3>
-<p>
- Except for the most trivial of software applications, it is generally considered impossible to test all the input
- combinations logically feasible for a software system. Therefore, selecting a good subset that has the highest
- probability of finding the most errors, is a worthwhile and important task for testers to undertake.
-</p>
-<p>
- Testing based on equivalence class analysis (synonyms: <i>equivalence partitioning</i>, <i>domain analysis</i>) is a
- form of black-box test analysis that attempts to reduce the total number of potential tests to a minimal set of tests
- that will uncover as many errors as possible [<a href="../../process/referenc.htm#MYE79">MYE79</a>]. It is a method
- that partitions the set of inputs and outputs into a finite number of <i><a
- href="./../../../glossary/glossary.htm#equivalence_class">equivalence classes</a></i> that enable the selection of a
- representative test value for each class. The test that results from the representative value for a class is said to be
- "equivalent" to the other values in the same class. If no errors were found in the test of the representative value, it
- is reasoned that all the other "equivalent" values wouldn't identify any errors either.
-</p>
-<p>
- The power of Equivalence Classes lies in their ability to guide the tester using a sampling strategy to reduce the
- combinatorial explosion of potentially necessary tests. The technique provides a logical bases by which a subset of the
- total conceivable number of tests can be selected. Here are some categories of problem areas for large numbers of tests
- that can be benefit from the consideration of equivalence classes:
-</p>
-<ol>
- <li>
- Combinations of independent variables
- </li>
- <li>
- Dependent variables based on hierarchical relationship
- </li>
- <li>
- Dependent variables based on temporal relationship
- </li>
- <li>
- Clustered relationships based on market exemplars
- </li>
- <li>
- Complex relationships that can be modeled
- </li>
-</ol>
-<h3>
- <a id="Strategies" name="Strategies">Strategies</a>
-</h3>
-<p>
- There are different strategies and techniques that can be used in equivalence partition testing. Here are some
- examples:
-</p>
-<h4>
- <a id="EquivalenceClassPartition" name="EquivalenceClassPartition">Equivalence Class Partition</a>
-</h4>
-<p>
- Equivalence partition theory as proposed by Glenford Myers [<a href="../../process/referenc.htm#MYE79">MYE79</a>].
- attempts to reduce the total number of test cases necessary by partitioning the input conditions into a finite number
- of equivalence classes. Two types of equivalence classes are classified: the set of valid inputs to the program is
- regarded as the <i>valid equivalence class</i>, and all other inputs are included in the <i>invalid equivalence
- class</i>.
-</p>
-<p>
- Here are a set of guidelines to identify equivalence classes:
-</p>
-<ol>
- <li>
- If an input condition specifies a range of values (such as, program "accepts values from 10 to 100"), then one
- valid equivalence class (from 10 to 100) and two invalid equivalence classes are identified (less than 10 and
- greater than 100).
- </li>
- <li>
- If an input condition specifies a set of values (such as, "cloth can be many colors: RED, WHITE, BLACK, GREEN,
- BROWN "), then one valid equivalence class (the valid values) and one invalid equivalence class (all the other
- invalid values) are identified. Each value of the valid equivalence class should be handled distinctly.
- </li>
- <li>
- If the input condition is specified as a "must be" situation (such as, "the input string must be upper case"), then
- one valid equivalence class (uppercase characters) and one invalid equivalence (all the other input except
- uppercase characters) class are identified.
- </li>
- <li>
- Everything finished "long" before the task is done is an equivalence class. Everything done within some short time
- interval before the program is finished is another class. Everything done just before program starts another
- operation is another class.
- </li>
- <li>
- If a program is specified to work with memory size from 64M to 256M. Then this size range is an equivalence class.
- Any other memory size, which is greater than 256M or less than 64M, can be accepted.
- </li>
- <li>
- The partition of output event lies in the inputs of the program. Even though different input equivalence classes
- could have same type of output event, you should still treat the input equivalence classes distinctly.
- </li>
-</ol>
-<h4>
- <a id="BoundaryValueAnalysis" name="BoundaryValueAnalysis">Boundary Value Analysis</a>
-</h4>
-<p>
- In each of the equivalence classes, the boundary conditions are considered to have a higher rate of success identifying
- resulting failures than non-boundary conditions. Boundary conditions are the values at, immediately above or below the
- boundary or "edges" of each equivalence classes.
-</p>
-<p>
- Tests that result from boundary conditions make use of values at the minimum (min), just above minimum (min+), just
- below the maximum (max-), and the maximum (max) of the range that needs be tested. When testing boundary values,
- testers choose a few test cases for each equivalence class. For the relatively small sample of tests the likelihood of
- failure discovery is high. The Tester is given some relief from the burden of testing a huge population of cases in an
- equivalent class of values that are unlikely to produce large differences in testing results.
-</p>
-<p>
- Some recommendations when choosing boundary values:
-</p>
-<ol>
- <li>
- For a floating variable, if the valid condition of it is from <code>-1.0</code> to <code>1.0</code>, test
- <code>-1.0</code>, <code>1.0</code>, <code>-1.001</code> and <code>1.001</code>.
- </li>
- <li>
- For an integer, if the valid range of input is <code>10</code> to <code>100</code>, test <code>9</code>,
- <code>10</code>, <code>100</code>, <code>101</code>.
- </li>
- <li>
- If a program expects an uppercase letter, test the boundary A and Z. Test <code>@</code> and <code>[</code> too,
- because in ASCII code, <code>@</code> is just below A and <code>[</code> is just beyond the Z.
- </li>
- <li>
- If the input or output of a program is an ordered set, pay attention on the first and the last element of the set.
- </li>
- <li>
- If the sum of the inputs must be a specific number (<code>n</code>), test the program where the sum is
- <code>n-1</code>, <code>n</code>, or <code>n+1</code>.
- </li>
- <li>
- If the program accepts a list, test values in the list. All the other values are invalid.
- </li>
- <li>
- When reading from or writing to a file, check the first and last characters in the file.
- </li>
- <li>
- The smallest denomination of money is one cent or equivalent. If the program accepts a specific range, from a to b,
- test a <code>-0.01</code> and b <code>+0.01</code>.
- </li>
- <li>
- For a variable with multiple ranges, each range is an equivalence class. If the sub-ranges are not overlapped, test
- the values on the boundaries, beyond the upper boundary, and below the lower boundary.
- </li>
-</ol>
-<h4>
- <a id="SpecialValues" name="SpecialValues">Special Values</a>
-</h4>
-<p>
- After attempting the two previous boundary analysis strategies, an experienced tester will observe the program inputs
- to discovery any "special value" cases, which are again potentially rich sources for uncovering software failures. Here
- are some examples:
-</p>
-<ol>
- <li>
- For an integer type, zero should always be tested if it is in the valid equivalence class.
- </li>
- <li>
- When testing time (hour, minute and second), 59 and 0 should always be tested as the upper and lower bound for each
- field, no matter what constraint the input variable has. Thus, except the boundary values of the input, -1, 0, 59
- and 60 should always be test cases.
- </li>
- <li>
- When testing date (year, month and day), several test cases, such as number of days in a specific month, the number
- of days in February in leap year, the number of days in the non-leap year, should be involved.
- </li>
-</ol>
-<h4>
- <a id="CategoryPartition" name="CategoryPartition">"Category-Partition" Method</a>
-</h4>
-<p>
- <a href="#OstrandBalcer">Ostrand and Balcer</a> [16] developed a partition method that helps testers to analyze the
- system specification, write test scripts, and manage them. Different from common strategies that mostly focuses on the
- code, their method is based on the specification and design information too.
-</p>
-<p>
- The main benefit of this method is its ability to expose errors before the code has been written because the input
- source is the specification and the tests result from the analysis of that specification. Faults in the specifications
- will be discovered early, often well before they are implemented in code.
-</p>
-<p>
- The strategy for the "category-partition" method follows:
-</p>
-<ol>
- <li>
- Analyze the specification: decompose the system functionality into functional units, which can be tested
- independently both by specification and implementation.<br />
- From there;<br />
- <br />
-
- <ol>
- <li>
- Identify the parameters and the environment conditions that will influence the function's execution.
- Parameters are the inputs of the function unit. Environment conditions are the system states, which will
- effect the execution of the function unit.
- </li>
- <li>
- Identify the characteristics of the parameters and the environment conditions.
- </li>
- <li>
- Classify the characteristics into categories, which effect the behavior of the system.<br />
- <br />
- </li>
- </ol>
- Ambiguous, contradictory, and missing descriptions of behavior will be discovered in this stage.<br />
- <br />
- </li>
- <li>
- Partition the categories into choices: Choices are the different possible situations that might occur and not be
- expected. They represent the same type of information in a category.<br />
- <br />
- </li>
- <li>
- Determine the relations and the constraints among choices. The choices in different categories influence with each
- other, which also have an influence of building the test suite. Constraints are added to eliminate the
- contradiction of between choices of different parameters and environments.<br />
- <br />
- </li>
- <li>
- Design test cases according to the categories, choices and constraint information. If a choice causes an error,
- don't combine it with other choices to create the test case. If a choice can be "adequately" tested by one single
- test, it is either the representative of the choice or a special value.
- </li>
-</ol>
-<h3>
- <a id="FurtherReading" name="FurtherReading">Further Reading and References</a>
-</h3>
-<ol>
- <li>
- Glenford J. Myers, The Art of Software Testing, John Wiley &amp; Sons, Inc., New York, 1979.
- </li>
- <li>
- White L. J. and Cohen E. I., A domain strategy for computer program testing, IEEE Transaction on Software
- Engineering, Vol. SE-6, No. 3, 1980.
- </li>
- <li>
- Lori A. Clarke, Johnhette Hassell, and Debra J Richardson, A Close Look at Domain Testing, IEEE Transaction on
- Software Engineering, 8-4, 1992.
- </li>
- <li>
- Steven J. Zeil, Faten H. Afifi and Lee J. White, Detection of Linear Detection via Domain Testing, ACM Transaction
- on Software Engineering and Methodology, 1-4, 1992.
- </li>
- <li>
- BingHiang Jeng, Elaine J. Weyuker, A Simplified Domain-Testing Strategy, ACM Transaction on Software Engineering
- and Methodology, 3-3, 1994.
- </li>
- <li>
- Paul C. Jorgensen, Software Testing - A Craftsman's Approach, CRC Press LLC, 1995.
- </li>
- <li>
- Martin R. Woodward and Zuhoor A. Al-khanjari, Testability, fault, and the domain-to-range ratio: An eternal
- triangle, ACM Press New York, NY, 2000.
- </li>
- <li>
- Dick Hamlet, On subdomains: Testing, profiles, and components, SIGSOFT: ACM Special Interest Group on Software
- Engineering, 71-16, 2000.
- </li>
- <li>
- Cem Kaner, James Bach, and Bret Pettichord, Lessons learned in Software Testing, John Wiley &amp; Sons, Inc., New
- York, 2002.
- </li>
- <li>
- Andy Podgurski and Charles Yang, Partition Testing, Stratified Sampling, and Cluster Analysis, SIGSOFT: ACM Special
- Interest Group on Software Engineering, 18-5, 1993.
- </li>
- <li>
- Debra J. Richardson and Lori A. Clarke, A partition analysis method to increase program reliability, SIGSOFT: ACM
- Special Interest Group on Software Engineering, 1981.
- </li>
- <li>
- Lori A. Clarke, Johnette Hassell, and Debra J Richardson, A system to generate test data and symbolically execute
- programs, IEEE Transaction on Software Engineering, SE-2, 1976.
- </li>
- <li>
- Boris Beizer, Black-Box Testing - Techniques for Functional testing of Software and System, John Wiley &amp; Sons,
- Inc., 1995.
- </li>
- <li>
- Steven J. Zeil, Faten H. Afifi and Lee J. White, Testing for Liner Errors in Nonlinear computer programs, ACM
- Transaction on Software Engineering and Methodology, 1-4, 1992.
- </li>
- <li>
- William E. Howden, Functional Program Testing, IEEE Transactions on Software Engineering, Vol. SE-6, No. 2, 1980.
- </li>
- <li>
- <a id="OstrandBalcer" name="OstrandBalcer">Thomas J. Ostrand and Marc J. Balcer</a>, The Category-Partition method
- for specifying and generating functional tests, Communications of ACM 31, 1988.
- </li>
- <li>
- Cem Kaner, Jack Falk and Hung Quoc Nguyen, Testing Computer Software, John Wiley &amp; Sons, Inc., 1999.
- </li>
-</ol>
-<p>
- &nbsp;
-</p>
-<br />
-<br /></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/guidelines/open_workspace.xmi b/XP/xp/guidances/guidelines/open_workspace.xmi
deleted file mode 100644
index a5a5328..0000000
--- a/XP/xp/guidances/guidelines/open_workspace.xmi
+++ /dev/null
@@ -1,35 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-mq7aEjHjqWoRd6aWFK_Dwg" name="open_workspace,3.269440809144354E-305" guid="-mq7aEjHjqWoRd6aWFK_Dwg" changeDate="2005-12-06T04:26:31.188-0800">
- <mainDescription><a id="XE_xp__open_workspace" name="XE_xp__open_workspace"></a><a id="XE_workspace__in_xp" name="XE_workspace__in_xp"></a>
-<p>
- XP's open workspace borrows from the concept of the war room. Studies have shown that teams working tightly together in
- close proximity achieve much greater productivity than when they are apart in their own separate offices or cubicles.
- In XP, all members of the team, including the customer, sit in the open workspace.
-</p>
-<p>
- The ideal XP programming environment is an open workspace filled with tables and room for pairs of people to work
- together and maintain contact with their peers.
-</p>
-<p>
- The open workspace should foster an environment in which programmers can focus on their problems but still hear enough
- to jump in other conversations if they can help. It is an environment that emphasizes teamwork.
-</p>
-<p>
- In many places in the world, businesses have "cubicle cultures." In the interests of privacy and enhanced
- concentration, programmers often spend most of their time in their own workspace that is separated from their peers. It
- acts as a little capsule of solitude that lets them work in "peace." While everyone needs quiet time and some privacy,
- the bulk of software development work is best done collaboratively.
-</p>
-<p>
- When people go into their small workspaces, they are out of the flow and exchange of information that keeps a project
- vigorous.
-</p>
-<p>
- In XP, team members should have some private space. They need a place where they can use a phone privately or browse
- email, but software development should be done in an open workspace.
-</p>
-<p>
- <br />
- &nbsp;
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/guidelines/pair_programming.xmi b/XP/xp/guidances/guidelines/pair_programming.xmi
deleted file mode 100644
index 927fdbc..0000000
--- a/XP/xp/guidances/guidelines/pair_programming.xmi
+++ /dev/null
@@ -1,343 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-nfbUMyTTqEbCp3HDn-NjOA" name="pair_programming,3.85153041801319E-307" guid="-nfbUMyTTqEbCp3HDn-NjOA" changeDate="2006-11-09T16:44:32.495-0800" version="1.0.0">
- <mainDescription><a id="XE_xp__pair_programming" name="XE_xp__pair_programming"></a><a id="XE_pair_programming__in_xp"
-name="XE_pair_programming__in_xp"></a>
-<h3>
- Topics
-</h3>
-<ul>
- <li>
- <a href="#WhatIsPair">What is pair programming?</a>
- </li>
- <li>
- <a href="#WhyPair">Why Pair Program?</a>
- </li>
- <li>
- <a href="#FormingPairs">How Pairs Form</a>
- </li>
- <li>
- <a href="#ChangingPairs">When to Change Partners</a>
- </li>
- <li>
- <a href="#WorkingAlone">Can't I work alone?</a>
- </li>
- <li>
- <a href="#Productivity">Doesn't this cut my productivity in half?</a>
- </li>
- <li>
- <a href="#Hygiene">Hygiene and Etiquette Issues</a>
- </li>
- <li>
- <a href="#Disabilities">Disabilities and Physical Incompatibilities</a>
- </li>
- <li>
- <a href="#Distributed">Our Team is Geographically Distributed</a>
- </li>
- <li>
- <a href="#BossHog">My Pair Partner Hogs the Keyboard and Ignores Me</a>
- </li>
- <li>
- <a href="#NoSolution">My Pair Partner and I Cannot Agree on a Solution</a>
- </li>
- <li>
- <a href="#Language">My Partner and I have different First Languages</a>
- </li>
- <li>
- <a href="#Schedule">How do we deal with different personal schedules?</a>
- </li>
- <li>
- <a href="#OddNumber">What if we have an odd number of programmers?</a>
- </li>
- <li>
- <a href="#Pathologies">Pairing Pathologies</a>
- </li>
-</ul>
-<h3>
- <a id="WhatIsPair" name="WhatIsPair">What is pair programming?</a>
-</h3>
-<p>
- Pair programming is a programming discipline in which all production code is written by pairs of programmers. Each pair
- works together at a single workstation. They share the keyboard, mouse, and monitor.
-</p>
-<p>
- The two programmers work closely together. The keyboard moves back and forth between them frequently. Both eyes are
- locked on the screen. Both minds are immersed in the code. The code is the product of both brains, not just one. Both
- programmers are equally engaged in writing the code, and neither can claim authorship.
-</p>
-<p>
- Pairs are short lived. A good pairing time is four hours. Sometimes a pair may last for a day. Very rarely they might
- last for a week. Instead, the pairs form for a few hours and then break up and reform with different partners.
-</p>
-<p>
- During the iteration-planning meeting, each programmer signed up for tasks to complete by the end of the iteration. The
- programmer remains responsible for those tasks. Half of the pairs he works in will be working on his tasks, and half
- will be working on other's tasks.
-</p>
-<h3>
- <a id="WhyPair" name="WhyPair">Why Pair Program?</a>
-</h3>
-<p>
- Pair programming is a form of continuous code review and usually replaces the practice of code reviews and code
- walkthroughs. The idea is that if code reviews are a good thing, then continuously reviewing the code is better.
-</p>
-<p>
- Even though every task is the responsibility of an individual programmer, many other programmers will have worked on
- that task with the responsible programmer. Thus, knowledge of the system spreads through the team, and no single
- programmer can claim ownership of any part of the code. It is likely that any programmer on the team will be able to
- work in any module in the system.
-</p>
-<p>
- Sometimes you get stuck on ideas and can't see past them. Your pair partner can often provide the necessary nudge to
- get you to see a different point of view.
-</p>
-<p>
- When new people join the team, they learn by pairing. Over the course of one iteration, they will pair with everybody
- on the team and see every part of the system currently being worked upon. This is an excellent way to train a new team
- member.
-</p>
-<h3>
- <a id="FormingPairs" name="FormingPairs">How Pairs Form</a>
-</h3>
-<p>
- You come to work in the morning and attend the stand-up meeting. Then you walk up to someone and ask him if he'll help
- you. Or perhaps someone will walk up to you and ask you to help him. The rule is: when asked, you must say yes.
- However, you can negotiate schedule.
-</p>
-<p>
- Pairs form naturally. Managers do not get involved with selecting pairs. Pairing is not scheduled or controlled in any
- formal manner. The coach or another team member or the team as a whole may notice that certain team members have
- adopted pathological pairing activities and may intervene.
-</p>
-<h3>
- <a id="ChangingPairs" name="ChangingPairs">When to Change Partners</a>
-</h3>
-<ul>
- <li>
- When you get tired of your current partner.
- </li>
- <li>
- When you think your current partner is too tired or distracted to help.
- </li>
- <li>
- When the two of you get stuck on a concept.
- </li>
- <li>
- Lunchtime.
- </li>
- <li>
- Quitting time.
- </li>
- <li>
- Or generally whenever you feel like it.
- </li>
-</ul>
-<h3>
- <a id="WorkingAlone" name="WorkingAlone">Can't I work alone?</a>
-</h3>
-<p>
- Yes, of course. You just can't check in production code that you've written on your own.
-</p>
-<p>
- Often we need to hide away somewhere and think some issue through without someone else breathing down our neck or
- distracting us with news of his sister-in-law's hypoglycemia. It is perfectly OK to hide away, and every programmer
- should have a private place to go.
-</p>
-<p>
- When alone, it is perfectly OK to write some code to help you think through a program. However, in an XP team, you are
- not allowed to check that code into the production environment. Instead, you can bring that code to your next pairing
- session and walk through it with your partner. Your partner must be given every right to modify, delete, or otherwise
- refactor it. You should help your partner become comfortable with the code and keep an open mind to every refactoring.
-</p>
-<p>
- Often the best approach is for the two of you to review the code you wrote and then rewrite it as a pair. Remember, the
- value of a piece of code is not actually in that code. Rather, it is in the neurons and synapses of the programmers. It
- is always much easier to write a module the second time, and the result is always better. So, if you program alone,
- think of the code as a rough draft that you will throw away and rewrite with your pair partner.
-</p>
-<h3>
- <a id="Productivity" name="Productivity">Doesn't this cut my productivity in half?</a>
-</h3>
-<p>
- Apparently not. Teams that work in pairs do not report significant loss of productivity. Indeed, they tend to report
- that they are more productive than when they worked alone.
-</p>
-<p>
- This anecdotal evidence is backed up by some research studies. Some of those studies can be found at <a
- href="http://www.pairprogramming.com" target="_blank">www.pairprogramming.com</a>.
-</p>
-<p>
- One might explain these results by viewing the programmers as two runners pacing each other. When one gets tired or
- defocused, the other provides the motivation and inspiration to keep going. Also, the pair spends less time going down
- dead ends and being blocked on ideas.
-</p>
-<p>
- One thing seems clear. Typing is not the critical element. If it were, then pairing would certainly cut productivity in
- half. It may be that pairing allows the two to think twice as quickly.
-</p>
-<h3>
- <a id="Hygiene" name="Hygiene">Hygiene and Etiquette Issues</a>
-</h3>
-<p>
- Hygiene and etiquette issues are bad breath, body odor, post-nasal drip, colds, rude noises, gas, motor mouths,
- telephone-jockeys, day-traders, hypochondriacs, etc. Humans are a dirty species. Amazingly, we are usually able to get
- along with each other's nasty little idiosyncrasies, but there are times when one person has certain habits that are
- over the top. How do you pair with such a person?
-</p>
-<ul>
- <li>
- Grin and bear it, it'll only last for a couple of hours.
- </li>
- <li>
- Bring breath mints.
- </li>
- <li>
- Leave deodorant or gelucel on his desk.
- </li>
- <li>
- Write anonymous letters to the offender.
- </li>
- <li>
- Disconnect the phone.
- </li>
- <li>
- Complain to your boss.
- </li>
- <li>
- But, by far, the best advice is to tell your pair partner outright what bothers you.
- </li>
-</ul>
-<h3>
- <a id="Disabilities" name="Disabilities">Disabilities and Physical Incompatibilities</a>
-</h3>
-<ul>
- <li>
- Left handed vs. right handed mouse users.
- </li>
- <li>
- Some people need special keyboards to control RSI or OOS.
- </li>
- <li>
- Some people use Dvorak keyboards.
- </li>
- <li>
- Some people need to special screens to be able to see.
- </li>
- <li>
- Some people prefer a trackball to a mouse.
- </li>
-</ul>
-<p>
- Problems like these are pretty easy to overcome. Equip certain workstations with two keyboards, two mice, two monitors,
- etc. Pairs don't have to work at the exact same keyboard, mouse, or monitor.
-</p>
-<p>
- In fact, pairs don't really have to use the same workstation. They could use two completely independent workstations
- sitting next to each other, connected with NetMeeting or some other kind of collaboration software.
-</p>
-<h3>
- <a id="Distributed" name="Distributed">Our Team is Geographically Distributed</a>
-</h3>
-<p>
- At best, pairing over geographical boundaries is difficult. The best approach is to split the project up into
- sub-projects that can be done separately at each geographic location. That way the programmers at each location can
- pair with each other and won't have to interact as much with the remote programmers.
-</p>
-<p>
- Sometimes the project cannot be easily split amongst all the geographic sites. In that case, you can use NetMeeting or
- other collaborative software to facilitate remote pairing. Remote pairing is possible but not as effective as local
- pairing. When you pair locally, you have the advantage of body language, eye contact, and all the other nuances of
- person-to-person communication to help you. When you pair remotely, you are forced to use a sub-optimal communication
- channel.
-</p>
-<h3>
- <a id="BossHog" name="BossHog">My Pair Partner Hogs the Keyboard and Ignores Me</a>
-</h3>
-<ul>
- <li>
- Perhaps you are outrunning him. Try to go a little slower and get him engaged.
- </li>
- <li>
- Perhaps he's got personal problems that are distracting him. Suggest that this might not be a good time to pair.
- </li>
- <li>
- Perhaps he thinks you aren't listening to his ideas. Make sure you talk though all ideas with him, and make sure he
- has a chance to try as many of his ideas as you get to try of yours.
- </li>
- <li>
- Perhaps he thinks you've been hogging the keyboard. Push the keyboard in his direction and ask him to drive.
- </li>
- <li>
- Perhaps he is just not ever going to want to pair program, no matter what. For the moment, the best you can do is
- dissolve the pair and choose another partner. If the behavior continues, the team will have to decide what to do
- about it. Perhaps the team will ask him to write configuration scripts or something.
- </li>
-</ul>
-<h3>
- <a id="NoSolution" name="NoSolution">My Pair Partner and I Cannot Agree on a Solution</a>
-</h3>
-<ul>
- <li>
- Gently ask him if you can drive for a while.
- </li>
- <li>
- Gently ask him to describe what he is doing.
- </li>
- <li>
- Perhaps he needs time to think alone. Suggest this to him and dissolve the pair.
- </li>
- <li>
- Perhaps he just can't pair program. Dissolve the pair and choose another partner. If the behavior continues, the
- team will have to figure out what to do.
- </li>
-</ul>
-<h3>
- <a id="Language" name="Language">My Partner and I have different First Languages</a>
-</h3>
-<p>
- Your only choice is to slow down and work hard to communicate. You might understand him better by writing strategic
- notes than by talking. Work hard on helping him with pronunciation and grammar. Work hard at understanding his accent
- and usage. It will take time, but the situation will improve. Do not give up!
-</p>
-<h3>
- <a id="Schedule" name="Schedule">How do we deal with different personal schedules?</a>
-</h3>
-<p>
- Some people come in early; some people stay late. How can you find pair partners if everybody has a different working
- schedule?
-</p>
-<p>
- Pairs only last for a few hours. All you need is enough overlap time for pairs to form and work effectively. Most
- personal schedules allow this.
-</p>
-<p>
- Team members may have to get creative with their scheduling to accommodate each other. Some folks may have to change
- their schedules to make sure that others have sufficient pairing opportunity. For example, if Bill can only work in the
- evenings, the team may decide to adopt a rotating schedule for others who can come in late one day and pair with Bill.
-</p>
-<h3>
- <a id="OddNumber" name="OddNumber">What if we have an odd number of programmers?</a>
-</h3>
-<p>
- Remember that pairs break up and reform frequently. The odd man out will not have to wait long before someone becomes
- available to pair with. In the meantime, he can read his email or a trade journal or just read through some code that
- he is unfamiliar with.
-</p>
-<h3>
- <a id="Pathologies" name="Pathologies">Pairing Pathologies</a>
-</h3>
-<ul>
- <li>
- Joined at the hip. Sometimes two people decide to pair exclusively. This is not a good idea. They are missing the
- opportunity to get the whole team's input and are isolating themselves into one part of the system. The team should
- break them up by suggesting that they pair with others.
- </li>
- <li>
- The blind leading the blind. It's not a good idea for new members of the team to pair too often with other new
- members of the team. Newbies should pair most often with team members with more seniority.
- </li>
-</ul>
-<p>
- <br />
- <br />
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/guidelines/planning_game.xmi b/XP/xp/guidances/guidelines/planning_game.xmi
deleted file mode 100644
index 118f700..0000000
--- a/XP/xp/guidances/guidelines/planning_game.xmi
+++ /dev/null
@@ -1,273 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-85F1Tegv16godTFTKyPdww" name="planning_game,6.7335956461328426E-307" guid="-85F1Tegv16godTFTKyPdww" changeDate="2006-11-09T15:30:46.086-0800" version="1.0.0">
- <mainDescription><a id="XE_xp__planning_game" name="XE_xp__planning_game"></a><a id="XE_planning__in_xp" name="XE_planning__in_xp"></a>
-<h3>
- Topics
-</h3>
-<ul>
- <li>
- <a href="#Overview">XP Planning Overview</a>
- </li>
- <li>
- <a href="#Iterations">Iterations</a>
- </li>
- <li>
- <a href="#Stories">User Stories</a>
- </li>
- <li>
- <a href="#ReleasePlanning">Release Planning</a>
- </li>
- <li>
- <a href="#IterationPlanning">Iteration Planning</a>
- </li>
- <li>
- <a href="#TaskPlanning">Task Planning</a>
- </li>
- <li>
- <a href="#Recovery">Recovery</a>
- </li>
- <li>
- <a href="#Feedback">Feedback</a>
- </li>
- <li>
- <a href="#AcceptanceTests">Acceptance Tests</a>
- </li>
- <li>
- <a href="#First">How do we create budgets for the first iteration and release?</a>
- </li>
- <li>
- <a href="#Velocity">How do changes in the team affect velocity?</a>
- </li>
-</ul>
-<h3>
- <a id="Overview" name="Overview">XP Planning Overview</a>
-</h3>
-<p>
- An XP project is broken down into a set of two-week iterations. Each iteration follows the next in a linear sequence.
- Executable code that passes unit tests and acceptance tests is the core deliverable beginning with the first iteration.
-</p>
-<p>
- Planning an XP project is a continuous activity. There is no master plan that is decided upon at the start of the
- project and that is followed until the end. An XP project is planned in detail, one iteration at a time. The plan for
- an iteration is created at the beginning of that iteration. The plan is then checked and adjusted continuously
- throughout the iteration.
-</p>
-<p>
- Iterations are grouped into larger milestones called releases. A typical release spans two to three months. At the
- beginning, the release plan is created. This is a very rough plan that tentatively describes the features that the
- project team believes can and should be implemented during that time. The release plan is continuously updated as each
- iteration within the release provides more data.
-</p>
-<p>
- The overriding principle of XP planning is feedback. Every iteration provides data about the velocity of the team. That
- data is used to continuously calibrate the plan. Measuring the results of each iteration generates a continuous stream
- of data. The team and its managers use that data to make decisions and take actions that will improve the project
- outcome.
-</p>
-<h3>
- <a id="Iterations" name="Iterations">Iterations</a>
-</h3>
-<p>
- An iteration is simply a span of time in which the team implements a set of features. In an XP project, this time is
- typically two weeks and should never be longer than four. The team should decide how long its iterations should be and
- then stick to that time. It is not wise to continuously change the duration of the iterations because that makes
- determination of a team's velocity more complicated.
-</p>
-<p>
- When an iteration is over, it is over, irrespective of how much the iteration accomplished. It is never wise to extend
- an iteration in order to provide more time to finish the planned deliverables. The ability to plan an XP project
- depends strongly on fixed-length iterations of consistent duration and ruthless termination of each iteration
- irrespective of whether the planned tasks are complete to allow the velocity to be measured.
-</p>
-<h3>
- <a id="Stories" name="Stories">User Stories</a>
-</h3>
-<p>
- The content or scope of an XP project is described in user stories. User stories are very simple descriptions of the
- features to be developed. Each story is typically written on a single index card and contains virtually no detail. The
- card contains little more than the name of the feature.
-</p>
-<p>
- Stories are the tokens of planning. When we create a release plan or an iteration plan, we select the stories we want
- in that release or iteration and schedule them. Once a story is scheduled for an iteration, two things must happen in
- that iteration. First, the details of the story must be fleshed out, resulting in the creation of appropriate
- acceptance tests. Second, the story must be implemented so that it passes those acceptance tests.
-</p>
-<p>
- In order to choose which stories to schedule for an iteration, we need to know two things: how important is the story
- and how long will the story take to implement. The first comes from the judgment of the customers/stakeholders, and the
- second comes from the judgment of the developers.
-</p>
-<p>
- Developers estimate the stories. The estimate for a user story should neither be too big nor too small. Those that are
- too big should be split into multiple stories, and those that are too small should be merged. A good guideline is to
- keep the size of a user story between two days and a week of team effort. The customer/stakeholders and the developers
- will negotiate over the stories, splitting and merging as necessary, until they are appropriately sized.
-</p>
-<p>
- Estimates are written on the story cards as numbers. We refer to these numbers as story points. It doesn't matter what
- units were originally used to create the estimates. It might have been man-days or man weeks or something else. Once
- the estimates are made, we forget the units and simply refer to them as story points.
-</p>
-<h3>
- <a id="ReleasePlanning" name="ReleasePlanning">Release Planning</a>
-</h3>
-<p>
- The customer/stakeholders know what features they want completed for the next release. The developers know how much
- they can get done in the next release. The developers give the customer/stakeholders a budget for the release based
- upon how much the developers got done in the previous release. If the developers finished 720 story points in the last
- release, then it is safe to say that they'll finish about 720 in this release.
-</p>
-<p>
- The customer/stakeholders choose stories that add up to this number. They choose the stories that are most critical and
- have the most business value. They lay them out in roughly the order in which they'd like to see them implemented. This
- selection and ordering of the stories becomes the release plan.
-</p>
-<p>
- Any stakeholder can look at the release plan and see about when a particular feature will be implemented. They know
- that, if the feature is listed early, then it is likely to be completed. If a story is listed late in the plan, then
- the risk is higher. The release plan is not static. Any time priorities change, the customer/stakeholders can change
- the plan by reordering stories, adding new stories, removing existing stories, and so on. Thus, the release plan is
- always changing in response to the changing business.
-</p>
-<h3>
- <a id="IterationPlanning" name="IterationPlanning">Iteration Planning</a>
-</h3>
-<p>
- At the beginning of each iteration, we take a half day to plan that iteration. The developers supply the
- customer/stakeholders with a budget for the iteration based upon what they finished in the last iteration. If they got
- 68 story points done in the last iteration, then it is safe to plan for 68 in this iteration.
-</p>
-<p>
- The customer/stakeholders select the stories from the release plan that they feel are most important for this
- iteration. The sum of the selected story points cannot exceed the budget given by the developers.
-</p>
-<p>
- Though the customer/stakeholders can suggest an ordering for the stories in an iteration, the developers are not bound
- to that ordering. The developers are free to rearrange the stories within the iteration in any manner that makes sense.
-</p>
-<p>
- Once the iteration has begun, the customer/stakeholders cannot make arbitrary changes to the stories in that iteration.
- Any change has to be carefully negotiated with the developers. If the customer/stakeholders want to remove a story and
- replace it with another, they must check with the developers to see if that will fit in the iteration. If the
- developers agree, then the change can be made. If the developers do not agree then the customer/stakeholder may decide
- to wait until the next iteration or may decide to completely abort the current iteration and plan a new iteration.
-</p>
-<h3>
- <a id="TaskPlanning" name="TaskPlanning">Task Planning</a>
-</h3>
-<p>
- Once the stories have been selected for the iteration, then the developers break the stories down into programming
- tasks. The tasks are recorded on a whiteboard or a flip chart.
-</p>
-<p>
- Tasks are simple units of work that accomplish a particular goal within a story. One task might be to set up the
- database schema for a story. Another might be to create the HTML pages for a story. Still another task might be to
- write a servlet that checks passwords. A task should be on the order of a man-day of effort.
-</p>
-<p>
- The breakdown of stories into tasks is a design activity. The developers consider how the stories will be developed and
- whether or not there are any design options that allow the stories to share tasks.
-</p>
-<p>
- Once the list of tasks is complete, the developers take turns signing up for the tasks. Each developer puts his or her
- initials next to a task and then estimates that task. The estimate is typically in hours.
-</p>
-<p>
- Each developer has a budget of hours that he keeps in the back of his head. This budget represents the number of hours
- he believes he will have for the development of his tasks in this iteration. Each time a developer signs up for a task,
- he deducts his estimate from that budget. When a developer's budget goes to zero, he stops signing up for tasks.
-</p>
-<p>
- Ideally, at the end of sign up, all the tasks would have initials, and every developer's budget would be at zero. But
- this is seldom the case. There are two much more likely scenarios:
-</p>
-<ul>
- <li>
- Everybody's budget is at zero, and there are tasks left. In this case, the developers need to work together to find
- a better division of tasks. If a GUI guy signed up for a database task just to get some new experience, then
- perhaps he should swap with someone who could do that task more quickly. If after such trading there are still
- tasks left over, then the team has to ask the customer/stakeholder to remove some stories or tasks.
- </li>
- <li>
- The tasks are all signed up, but some people still have budget left. In this case, the team needs to ask the
- customer/stakeholders to give them a few more stories.
- </li>
-</ul>
-<h3>
- <a id="Recovery" name="Recovery">Recovery</a>
-</h3>
-<p>
- On the day that marks the halfway point of the iteration, the team has another short meeting. Half the tasks should be
- complete. More importantly, half the stories should be complete. More precisely, a set of stories whose points add up
- to half the iteration budget should be complete. The nightmare we are trying to avoid is that the iteration ends with
- all the stories 95% complete. We'd rather that 95% of the stories be complete.
-</p>
-<p>
- If half the stories are not complete, then the team asks the customer to remove some stories from the iteration. This
- same kind of check is made towards the end of the iteration. The team assesses how much they have working and how much
- is left. If it appears that they may not complete all the promised stories, then they ask the customer/stakeholders to
- remove some.
-</p>
-<p>
- By the same token, if more than half the stories are complete by the midpoint, the developers ask the
- customer/stakeholder for more work. Likewise, as the iteration gets close to the end, any idle developers should help
- others complete their tasks. If it appears that all tasks will be completed early, the developers should ask the
- customer/stakeholders for more stories.
-</p>
-<h3>
- <a id="Feedback" name="Feedback">Feedback</a>
-</h3>
-<p>
- The number of story points completed in the previous iteration is the team's current velocity. This velocity is used as
- the budget for the next iteration. Thus we only commit to doing what we know we did in the last iteration.
-</p>
-<p>
- The same is true for releases. When we plan the next release, we use the number of story points we finished in the
- previous release.
-</p>
-<p>
- Individual developers use the same technique for their task budgets. If they got 22 hours worth of tasks finished in
- the last iteration, they should only sign up for 22 hours of tasks this time.
-</p>
-<h3>
- <a id="AcceptanceTests" name="AcceptanceTests">Acceptance Tests</a>
-</h3>
-<p>
- After the iteration-planning meeting is over, the customer/stakeholders must provide the developers with acceptance
- tests for the stories that were selected for the iteration. Typically, these tests will be created with the help of the
- Q/A or testing groups. These tests specify exactly to the developers what the stories being implemented must do, so
- they must be given to the developers as early as possible.
-</p>
-<p>
- Some XP teams manage to write their acceptance tests an iteration early. The Q/A or testing group works with the
- customer/stakeholders during the current iteration to determine which stories are most likely to be selected for the
- next iteration. Together, they define the set of acceptance tests that will be given to the developers during the next
- iteration planning meeting. By planning ahead like this, the developers can have the acceptance tests for an
- iteration's stories immediately.
-</p>
-<h3>
- <a id="First" name="First">How do we create budgets for the first iteration and release?</a>
-</h3>
-<p>
- If you have history from other projects, then make use of that. Otherwise, you have to guess. A good way to guess is to
- spend a day or two trying to implement one or two stories. This should give you an inkling of your velocity.
-</p>
-<h3>
- <a id="Velocity" name="Velocity">How do changes in the team affect velocity?</a>
-</h3>
-<p>
- If the change is small, then it's probably best to allow the velocity to change by itself. If you got 52 story points
- done last iteration, but this iteration you have a new team member, it's probably best to keep your velocity at 52 and
- commit do doing just 52 story points in the next iteration. At the end of that iteration, you may find that you've done
- a little more than 52, and you can adjust your velocity accordingly.
-</p>
-<p>
- On the other hand, if 30% of the team is going on vacation for the next iteration, then it's probably wise to reduce
- your velocity accordingly.
-</p>
-<p>
- <br />
- &nbsp;
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/guidelines/refactoring.xmi b/XP/xp/guidances/guidelines/refactoring.xmi
deleted file mode 100644
index f82d991..0000000
--- a/XP/xp/guidances/guidelines/refactoring.xmi
+++ /dev/null
@@ -1,616 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-dbA7zKOJY5WPZyLXErA9vw" name="refactoring,8.137126904637637E-306" guid="-dbA7zKOJY5WPZyLXErA9vw" changeDate="2006-11-09T16:45:22.634-0800" version="1.0.0">
- <mainDescription><h3>
- Topics
-</h3>
-<ul>
- <li>
- <a href="#WhatIs">What is refactoring?</a>
- </li>
- <li>
- <a href="#Why">Why should I refactor?</a>
- </li>
- <li>
- <a href="#When">When should I refactor?</a>
- </li>
- <li>
- <a href="#Example">An example of refactoring</a>
- </li>
-</ul>
-<h3>
- <a id="WhatIs" name="WhatIs">What is refactoring?</a>
-</h3>
-<p>
- Refactoring is the act of improving the structure of a program without changing its behavior. Refactoring is done in
- tiny little steps, each barely worth doing. In between each step, we run the relevant unit tests to make sure that the
- changes we made have not broken anything. The edit/compile/test cycle is usually between 30 seconds and five minutes.
-</p>
-<h3>
- <a id="Why" name="Why">Why should I refactor?</a>
-</h3>
-<p>
- The purpose of refactoring is to improve the design and readability of the code. There are several specific goals:
-</p>
-<ul>
- <li>
- The code should pass all its tests.
- </li>
- <li>
- It should be as expressive as it is possible for you to make it.
- </li>
- <li>
- It should be as simple as it is possible for you to make it.
- </li>
- <li>
- It should have no redundancy.
- </li>
-</ul>
-<h3>
- <a id="When" name="When">When should I refactor?</a>
-</h3>
-<p>
- Refactoring is not something that we schedule. There is no line item in the schedule for it. There is no particular
- time when we do it. Refactoring is done all the time. As you and your pair partner work on a task, such as writing
- tests and code, you will notice that the code and tests are not as clean and simple as they could be. That is the time
- to stop and refactor that code.
-</p>
-<p>
- The rule is: <b>Don't let the sun set on bad code.</b>
-</p>
-<h3>
- <a id="Example" name="Example">An Example of Refactoring</a>
-</h3>
-<p>
- Consider the two unit tests and the <font size="3"><tt>Formatter</tt></font> class shown below. The <font
- size="3"><tt>Formatter</tt></font> class works but is not as expressive as I'd like it to be. So I'll refactor it in
- stages.
-</p>
-<table width="100%" border="1">
- <tbody>
- <tr>
- <td>
-<pre>
- public void testCenterLine()
-</pre>
-<pre>
- {
-</pre>
-<pre>
- Formatter f = new Formatter();
-</pre>
-<pre>
- f.setLineWidth(10);
-</pre>
-<pre>
- assertEquals(" word ", f.center("word"));
-</pre>
-<pre>
- }
-</pre>
-<pre>
- public void testOddCenterLine() throws Exception
-</pre>
-<pre>
- {
-</pre>
-<pre>
- Formatter f = new Formatter();
-</pre>
-<pre>
- f.setLineWidth(10);
-</pre>
-<pre>
- assertEquals(" hello ", f.center("hello"));
-</pre>
-<pre>
- }
-</pre>
- </td>
- </tr>
- </tbody>
-</table>
-<br />
-<br />
-<table width="100%" border="1">
- <tbody>
- <tr>
- <td>
-<pre>
- import java.util.Arrays;
-</pre>
-<pre>
- public class Formatter
-</pre>
-<pre>
- {
-</pre>
-<pre>
- private int width;
-</pre>
-<pre>
- private char spaces[];
-</pre>
-<pre>
- public void setLineWidth(int width)
-</pre>
-<pre>
- {
-</pre>
-<pre>
- this.width = width;
-</pre>
-<pre>
- spaces = new char[width];
-</pre>
-<pre>
- Arrays.fill(spaces, ' ');
-</pre>
-<pre>
- }
-</pre>
-<pre>
- public String center(String line)
-</pre>
-<pre>
- {
-</pre>
-<pre>
- int remainder = 0;
-</pre>
-<pre>
- StringBuffer b = new StringBuffer();
-</pre>
-<pre>
- int padding = (width - line.length()) / 2;
-</pre>
-<pre>
- remainder = line.length() % 2;
-</pre>
-<pre>
- b.append(spaces, 0, padding);
-</pre>
-<pre>
- b.append(line);
-</pre>
-<pre>
- b.append(spaces, 0, padding + remainder);
-</pre>
-<pre>
- return b.toString();
-</pre>
-<pre>
- }
-</pre>
-<pre>
- }
-</pre>
- </td>
- </tr>
- </tbody>
-</table>
-<p>
- The <font size="3"><tt>setLineWidth</tt></font> function is a little mysterious. What is this <font
- size="3"><tt>spaces</tt></font> array and why is it being filled with blanks? By looking ahead into the <font
- size="3"><tt>center</tt></font> function, we see that the <font size="3"><tt>spaces</tt></font> array is just a
- convenience to allow us to move a number of blanks into a <font size="3"><tt>StringBuffer</tt></font>. I wonder if we
- really need this convenience array.
-</p>
-<p>
- For the moment, I'm going to pull the initialization of the array out into its own function named <font
- size="3"><tt>buildArrayOfSpaces</tt></font>. That way, it's all in one place, and I can think about it a little more
- clearly.
-</p>
-<table width="100%" border="1">
- <tbody>
- <tr>
- <td>
-<pre>
-public void setLineWidth(int width)
-</pre>
-<pre>
-{
-</pre>
-<pre>
- this.width = width;
-</pre>
-<pre>
-<b>buildArrayOfSpaces(width);</b>
-</pre>
-<pre>
-}
-</pre>
-<pre>
-private void <b>buildArrayOfSpaces(int width)</b>
-</pre>
-<pre>
-{
-</pre>
-<pre>
- spaces = new char[width];
-</pre>
-<pre>
- Arrays.fill(spaces, ' ');
-</pre>
-<pre>
-}
-</pre>
-<pre>
-<font size="3"><b><i>Run the tests: the tests pass</i></b></font>
-</pre>
- </td>
- </tr>
- </tbody>
-</table>
-<p>
- I don't like the way <font size="3"><tt>center</tt></font> function is constructed. There is math scattered all through
- it. I think we can rearrange the math to make things clearer.
-</p>
-<table width="100%" border="1">
- <tbody>
- <tr>
- <td>
-<pre>
-public String center(String line)
-</pre>
-<pre>
-{
-</pre>
-<pre>
-<b>int remainder = line.length() % 2;</b>
-</pre>
-<pre>
-<b>int numberOfBlanksInFront = (width - line.length()) / 2;</b>
-</pre>
-<pre>
- <b>int numberOfBlanksAtEnd = (width - line.length()) / 2 + remainder;</b>
-</pre>
-<pre>
- StringBuffer b = new StringBuffer();
-</pre>
-<pre>
- b.append(spaces, 0, <b>numberOfBlanksInFront</b>);
-</pre>
-<pre>
- b.append(line);
-</pre>
-<pre>
- b.append(spaces, 0, <b>numberOfBlanksAtEnd</b>);
-</pre>
-<pre>
- return b.toString();
-</pre>
-<pre>
-}
-<font size="3"><b><i>Run the tests: the tests pass</i></b></font><br />
-</pre>
- </td>
- </tr>
- </tbody>
-</table>
-<p>
- This looks good, but we can reduce the clutter by changing some of the variables into functions.
-</p>
-<table width="100%" border="1">
- <tbody>
- <tr>
- <td>
-<pre>
-public String center(String line)
-</pre>
-<pre>
-{
-</pre>
-<pre>
- StringBuffer b = new StringBuffer();
-</pre>
-<pre>
- b.append(spaces, 0, <b>numberOfBlanksInFront(line)</b>);
-</pre>
-<pre>
- b.append(line);
-</pre>
-<pre>
- b.append(spaces, 0, <b>numberOfBlanksBehind(line)</b>);
-</pre>
-<pre>
- return b.toString();
-}
-</pre>
-<pre>
-<b>private int numberOfBlanksBehind(String line)</b>
-</pre>
-<pre>
-<b>{</b>
-</pre>
-<pre>
- <b>int extraBlankIfOdd = line.length() % 2;</b>
-</pre>
-<pre>
- <b>return (width - line.length()) / 2 + extraBlankIfOdd;</b>
-</pre>
-<pre>
-<b>}</b>
-</pre>
-<pre>
-<b>private int numberOfBlanksInFront(String line)</b>
-</pre>
-<pre>
-<b>{</b>
- <b>return (width - line.length()) / 2;</b>
-</pre>
-<pre>
-<b>}</b>
-<font size="3"><b><i>Run the tests: the tests pass</i></b></font>
-</pre>
- </td>
- </tr>
- </tbody>
-</table>
-<p>
- This makes the <font size="3"><tt>center</tt></font> function read a little better. However, the use of the <font
- size="3"><tt>StringBuffer.append</tt></font> function is a little confusing. We might be able to improve it a little by
- creating a more explicit function.
-</p>
-<table width="100%" border="1">
- <tbody>
- <tr>
- <td>
-<pre>
-public String center(String line)
-</pre>
-<pre>
-{
-</pre>
-<pre>
- StringBuffer b = new StringBuffer();
-</pre>
-<pre>
-<b>appendBlanks(b, numberOfBlanksInFront(line));</b>
-</pre>
-<pre>
- b.append(line);
-</pre>
-<pre>
-<b>appendBlanks(b, numberOfBlanksBehind(line));</b>
-</pre>
-<pre>
- return b.toString();
-</pre>
-<pre>
-}
-</pre>
-<pre>
-<strong>private void appendBlanks(StringBuffer b, int numberOfBlanks)</strong>
-</pre>
-<pre>
-<strong>{</strong>
-</pre>
-<pre>
- <strong>b.append(spaces, 0, numberOfBlanks);</strong>
-</pre>
-<pre>
-<strong>}</strong>
-<font size="3"><b><i>Run the tests: the tests pass</i></b></font>
-</pre>
- </td>
- </tr>
- </tbody>
-</table>
-<p>
- Now we can rewrite <font size="3"><tt>appendBlanks</tt></font> to avoid using the <font size="3"><tt>spaces</tt></font>
- array.
-</p>
-<table width="100%" border="1">
- <tbody>
- <tr>
- <td>
-<pre>
-import java.util.Arrays;
-</pre>
-<pre>
-public class Formatter
-</pre>
-<pre>
-{
-</pre>
-<pre>
- private int width;
-</pre>
-<pre>
- public void setLineWidth(int width)
-</pre>
-<pre>
- {
-</pre>
-<pre>
- this.width = width;
-</pre>
-<pre>
- }
-</pre>
-<pre>
- public String center(String line)
-</pre>
-<pre>
- {
-</pre>
-<pre>
- StringBuffer b = new StringBuffer();
-</pre>
-<pre>
- appendBlanks(b, numberOfBlanksInFront(line));
-</pre>
-<pre>
- b.append(line);
-</pre>
-<pre>
- appendBlanks(b, numberOfBlanksBehind(line));
-</pre>
-<pre>
- return b.toString();
-</pre>
-<pre>
- }
-</pre>
-<pre>
- private void appendBlanks(StringBuffer b, int numberOfBlanks)
-</pre>
-<pre>
- {
-</pre>
-<pre>
-<b> while(numberOfBlanks-- &gt; 0)</b>
-</pre>
-<pre>
-<b> b.append(' ');</b>
-</pre>
-<pre>
- }
-</pre>
-<pre>
- private int numberOfBlanksBehind(String line)
-</pre>
-<pre>
- {
-</pre>
-<pre>
- int extraBlankIfOdd = line.length() % 2;
-</pre>
-<pre>
- return (width - line.length()) / 2 + extraBlankIfOdd;
-</pre>
-<pre>
- }
-</pre>
-<pre>
- private int numberOfBlanksInFront(String line)
-</pre>
-<pre>
- {
-</pre>
-<pre>
- return (width - line.length()) / 2; }
-</pre>
-<pre>
- }
-</pre>
-<pre>
-}<font size="3"><b><i>Run the tests: the tests pass</i></b></font><br />
-</pre>
- </td>
- </tr>
- </tbody>
-</table>
-<p>
- The names of functions like <font size="3"><tt>numberOfBlanksBehind</tt></font> imply that the reader knows that these
- will be called from the <font size="3"><tt>center</tt></font> function. We should eliminate this implication by
- renaming those functions.
-</p>
-<table width="100%" border="1">
- <tbody>
- <tr>
- <td>
-<pre>
-import java.util.Arrays;
-</pre>
-<pre>
-public class Formatter
-</pre>
-<pre>
-{
-</pre>
-<pre>
- private int width;
-</pre>
-<pre>
- public void setLineWidth(int width)
-</pre>
-<pre>
- {
-</pre>
-<pre>
- this.width = width;
-</pre>
-<pre>
- }
-</pre>
-<pre>
- public String center(String line)
-</pre>
-<pre>
- {
-</pre>
-<pre>
- StringBuffer b = new StringBuffer();
-</pre>
-<pre>
- appendBlanks(b, <b>numberOfBlanksToLeftOfCenter</b>(line));
-</pre>
-<pre>
- b.append(line);
-</pre>
-<pre>
- appendBlanks(b, <b>numberOfBlanksToRightOfCenter</b>(line));
-</pre>
-<pre>
- return b.toString();
-</pre>
-<pre>
- }
-</pre>
-<pre>
- private void appendBlanks(StringBuffer b, int numberOfBlanks)
-</pre>
-<pre>
- {
-</pre>
-<pre>
- while(numberOfBlanks-- &gt; 0)
-</pre>
-<pre>
- b.append(' ');
-</pre>
-<pre>
- }
-</pre>
-<pre>
- private int <b>numberOfBlanksToRightOfCenter</b>(String line)
-</pre>
-<pre>
- {
-</pre>
-<pre>
- int extraBlankIfOdd = line.length() % 2;
-</pre>
-<pre>
- return (width - line.length()) / 2 + extraBlankIfOdd;
-</pre>
-<pre>
- }
-
- private int <b>numberOfBlanksToLeftOfCenter</b>(String line)
-</pre>
-<pre>
- {
-</pre>
-<pre>
- return (width - line.length()) / 2;
-</pre>
-<pre>
- }
-</pre>
-<pre>
-}
-<font size="3"><b><i>Run the tests: the tests pass</i></b></font>
-</pre>
- </td>
- </tr>
- </tbody>
-</table>
-<p>
- And I think we are done. You might find other refactorings to do, or you might not agree with all of the refactorings
- I've done. That's to be expected. The point is, however, that I have put a lot of effort into the readability and
- simplicity of this class. That effort will help others understand this class and make it easier for them to change the
- class when the time comes.
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/guidelines/resources/Thumbs.db b/XP/xp/guidances/guidelines/resources/Thumbs.db
deleted file mode 100644
index f4a7efc..0000000
--- a/XP/xp/guidances/guidelines/resources/Thumbs.db
+++ /dev/null
Binary files differ
diff --git a/XP/xp/guidances/guidelines/resources/md_state3.gif b/XP/xp/guidances/guidelines/resources/md_state3.gif
deleted file mode 100644
index ee64962..0000000
--- a/XP/xp/guidances/guidelines/resources/md_state3.gif
+++ /dev/null
Binary files differ
diff --git a/XP/xp/guidances/guidelines/resources/tstfrsdsg-img3.gif b/XP/xp/guidances/guidelines/resources/tstfrsdsg-img3.gif
deleted file mode 100644
index 182076e..0000000
--- a/XP/xp/guidances/guidelines/resources/tstfrsdsg-img3.gif
+++ /dev/null
Binary files differ
diff --git a/XP/xp/guidances/guidelines/resources/xp_tdd_guid_database.jpg b/XP/xp/guidances/guidelines/resources/xp_tdd_guid_database.jpg
deleted file mode 100644
index 08b590c..0000000
--- a/XP/xp/guidances/guidelines/resources/xp_tdd_guid_database.jpg
+++ /dev/null
Binary files differ
diff --git a/XP/xp/guidances/guidelines/test_driven_development_tdd.xmi b/XP/xp/guidances/guidelines/test_driven_development_tdd.xmi
deleted file mode 100644
index b4a5ead..0000000
--- a/XP/xp/guidances/guidelines/test_driven_development_tdd.xmi
+++ /dev/null
@@ -1,625 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-jc10ie6UDWUJzSDfsQExjw" name="test_driven_development_tdd,3.9254165491375454E-306" guid="-jc10ie6UDWUJzSDfsQExjw" changeDate="2006-11-21T15:17:42.164-0800" version="1.0.0">
- <mainDescription><a id="XE_xp__test_driven_development" name="XE_xp__test_driven_development"></a><a id="XE_test_driven_development__in_xp"
-name="XE_test_driven_development__in_xp"></a>
-<h3>
- Topics
-</h3>
-<ul>
- <li>
- <a href="#WhatIs">What is TDD?</a>
- </li>
- <li>
- <a href="#Java">A TDD Example in Java</a>
- </li>
- <li>
- <a href="#Benefits">What are the benefits of TDD?</a>
- </li>
- <li>
- <a href="#Costs">What are the costs of TDD?</a>
- </li>
- <li>
- <a href="#Principles">What testing principles should I employ?</a>
- </li>
- <li>
- <a href="#GUIS">How do I test GUIs?</a>
- </li>
- <li>
- <a href="#Embedded">How do I test embedded systems?</a>
- </li>
- <li>
- <a href="#Concurrency">How do I test concurrency?</a>
- </li>
- <li>
- <a href="#Database">How do I test database transactions?</a>
- </li>
- <li>
- <a href="#Servlets">How do I test servlets?</a>
- </li>
- <li>
- <a href="#WebPages">How do I test web pages?</a>
- </li>
-</ul>
-<h3>
- <a id="WhatIs" name="WhatIs">What is TDD?</a>
-</h3>
-<p>
- TDD is the practice of writing unit tests and production code concurrently and at a very fine level of granularity. A
- pair of programmers first write a small portion of a unit test, and then they write just enough production code to make
- that unit test compile and execute. Then they write a little bit more of the test and then add enough production code
- to make that new bit compile and pass. This cycle lasts somewhere between 30 seconds and five minutes. Rarely does it
- grow to ten minutes. In each cycle, the tests come first. Once a unit test is done, the pair goes on to the next test
- until they run out of tests for the task they are currently working on.
-</p>
-<h3>
- <a id="Java" name="Java">A TDD Example in Java</a>
-</h3>
-<p>
- What follows is a simple example of test-driven development. The program we are writing is a text formatter that can
- take arbitrary strings and can horizontally center them in a page. The first column shows the tests, and the second
- column shows the production code. The test is always written first and compiled. If the compile fails, then production
- code is added to make the compile succeed. Then the test is run to see if it passes. If the test fails, then production
- code is added to make the test pass. If the test passes, then a new test is added.
-</p>
-<table width="100%" border="1">
- <tbody>
- <tr>
- <td>
- <div align="center">
- <font size="-1"><i><b>First we write the test</b></i></font>
- </div>
- </td>
- <td>
- <div align="center">
- <font size="-1"><i><b>Then we write the production code</b></i></font>
- </div>
- </td>
- </tr>
- </tbody>
- <tbody>
- <tr>
- <td>
-<pre>
-<font size="2">public void testCenterLine(){
- Formatter f = new Formatter();
-}</font>
-</pre>
- <div align="center">
-<pre>
-<font color="#ff0000" size="2">does not compile</font>
-</pre>
- </div>
- </td>
- <td>
-<pre>
-<font size="2">class Formatter{
-}
-
-</font>
-</pre>
- <div align="center">
-<pre>
-<font color="#008000" size="2">compiles and passes</font>
-</pre>
- </div>
- </td>
- </tr>
- <tr>
- <td>
-<pre>
-<font size="2">public void testCenterLine(){
- Formatter f = new Formatter();
- f.setLineWidth(10);
- assertEquals(" word ", f.center("word"));
-}
-
-
-</font>
-</pre>
- <div align="center">
-<pre>
-<font color="#ff0000" size="2">does not compile</font>
-</pre>
- </div>
- </td>
- <td>
-<pre>
-<font size="2">class Formatter{
- public void setLineWidth(int width) {
- }
-
-
- public String center(String line) {<br />
- return "";
- }
-}</font>
-</pre>
- <div align="center">
-<pre>
-<font color="#ff0000" size="2">compiles and fails</font>
-</pre>
- </div>
- </td>
- </tr>
- <tr>
- <td>
- <font size="2">&nbsp;</font>
- </td>
- <td>
-<pre>
-<font size="2">import java.util.Arrays;
-
-
-public class Formatter {
- private int width;
- private char spaces[];
-
- public void setLineWidth(int width) {
- this.width = width;
- spaces = new char[width];
- Arrays.fill(spaces, ' ');
- }
-
-
- public String center(String line) {
- StringBuffer b = new StringBuffer();
- int padding = width/2 - line.length();
- b.append(spaces, 0, padding);
- b.append(line);
- b.append(spaces, 0, padding);
- return b.toString();
- }
-}
-</font>
-</pre>
- <div align="center">
-<pre>
-<font color="#ff0000" size="2">compiles and unexpectedly fails</font>
-</pre>
- </div>
- </td>
- </tr>
- <tr>
- <td>
- <font size="2">&nbsp;</font>
- </td>
- <td>
-<pre>
-<font size="2">public String center(String line) {
- StringBuffer b = new StringBuffer();
- <b>int padding = (width - line.length()) / 2;</b>
- b.append(spaces, 0, padding);
- b.append(line);
- b.append(spaces, 0, padding);
- return b.toString();
-}
-
-</font>
-</pre>
- <div align="center">
-<pre>
-<font color="#008000" size="2">compiles and passes</font>
-</pre>
- </div>
- </td>
- </tr>
- <tr>
- <td>
-<pre>
-<font size="2">public void testCenterLine() {
- Formatter f = new Formatter();
- f.setLineWidth(10);
- assertEquals(" word ", f.center("word"));
-}
-
-<b>public void testOddCenterLine() {
- Formatter f = new Formatter();
- f.setLineWidth(10);
- assertEquals( " hello ", f.center("hello"));
-}</b>
-</font>
-</pre>
- <div align="center">
-<pre>
-<font color="#ff0000" size="2">compiles and fails</font>
-</pre>
- </div>
- </td>
- <td>
-<pre>
-<font size="2">public String center(String line) {
- <b>int remainder = 0;</b>
- StringBuffer b = new StringBuffer();
- int padding = (width - line.length()) / 2;
- <b>remainder = line.length() % 2;</b>
- b.append(spaces, 0, padding);
- b.append(line);
- b.append(spaces, 0, padding + <b>remainder</b>);
- return b.toString();
-}
-
-</font>
-</pre>
- <div align="center">
-<pre>
-<font color="#008000" size="2">compiles and passes</font>
-</pre>
- </div>
- </td>
- </tr>
- </tbody>
-</table>
-<h3>
- <a id="Benefits" name="Benefits">What are the benefits of TDD?</a>
-</h3>
-<ul>
- <li>
- <b>Test Coverage</b>. If you follow the rules of TDD, then virtually 100% of the lines of code in your production
- program will be covered by unit tests. This does not cover 100% of the paths through the code, but it does make
- sure that virtually every line is executed and tested.<br />
- </li>
- <li>
- <b>Test Repeatability</b>. The tests can be run any time you like. This is especially useful after you've made a
- change to the production code. You can run the tests to make sure you haven't broken anything. Having the tests to
- back you up can give you the courage to make changes that would otherwise be too risky to make.<br />
- </li>
- <li>
- <b>Documentation</b>. The tests describe your understanding of how the code should behave. They also describe the
- API. Therefore, the tests are a form of documentation. Unit tests are typically pretty simple, so they are easy to
- read. Moreover, they are unambiguous and executable. Finally, if the tests are run every time any change is made to
- the code, they will never get out of date.<br />
- </li>
- <li>
- <b>API Design</b>. When you write tests first, you put yourself in the position of a user of your program's API.
- This can only help you design that API better. Your first concern, as you write the tests, is to make it easy and
- convenient to use that API.<br />
- </li>
- <li>
- <b>System Design</b>. A module that is independently testable is a module that is decoupled from the rest of the
- system. When you write tests first, you automatically decouple the modules you are testing. This has a profoundly
- positive effect on the overall design quality of the system.<br />
- </li>
- <li>
- <b>Reduced Debugging</b>. When you move in the tiny little steps recommended by TDD, it is hardly ever necessary to
- use the debugger. Debugging time is reduced enormously.<br />
- </li>
- <li>
- <b>Your code worked a minute ago!</b> If you observe a team of developers who are practicing TDD, you will notice
- that every pair of developer had their code working a minute ago. It doesn't matter when you make the observation!
- A minute or so ago, each pair ran their code, and it passed all its tests. Thus, you are never very far away from
- making the system work.<br />
- </li>
-</ul>
-<h3>
- <a id="Costs" name="Costs">What are the costs of TDD?</a>
-</h3>
-<ul>
- <li>
- Programming in tiny cycles can seem inefficient. Programmers often find it frustrating to work in increments that
- are so small that they know the outcome of the test. It sometimes seems that such a tiny step is not worth
- taking.<br />
- </li>
- <li>
- A lot of test code is produced. It is not uncommon for the bulk of test code to exceed the bulk of production code
- by a large amount. This code has to be maintained at a significant cost.<br />
- </li>
- <li>
- A lot of time is spent keeping the tests in sync with the production code. Programmers sometimes feel that time
- spent on keeping the tests working and well structured is time that is not being spent on the customer's
- needs.<br />
- </li>
-</ul>
-<h3>
- <a id="Principles" name="Principles">What testing principles should I employ?</a>
-</h3>
-<ul>
- <li>
- <b>Isolation</b>. When writing a unit test for a module, consider whether you want that module to invoke other
- modules. If not, then isolate the module with interfaces. For example, suppose you are testing a module that
- interacts with the database. The test has nothing to do with the database; it simply tests the way that the module
- manipulates the database. So you isolate the module from the database by creating an interface that represents the
- database and that the module uses. Then, for the purposes of the test, you implement that interface with a test
- stub. This kind of isolation greatly decreases the amount of coupling in the overall system.
- </li>
-</ul>
-<p>
- <img height="166" alt="" src="resources/xp_tdd_guid_database.jpg" width="403" />
-</p>
-<ul>
- <li>
- <b>Simplicity</b>. Keep your edit/compile/test cycles extremely short: less than five minutes on average. Write
- only enough production code to make the current tests pass. Try not to write code that will make future tests pass.
- At every edit/compile/test cycle, keep the code as simple as it can be.<br />
- </li>
- <li>
- <b>Increase Generality</b>. As you add test cases, the production code should become more and more general. Always
- try to increase generality. For example, consider the following test case:<br />
-
- <blockquote>
- <blockquote>
-<pre>
- public testThreeSquared() { assertEquals(9, MyClass.square(3)); }
-</pre>
- </blockquote>
- </blockquote>
- <p>
- We might make this test pass by writing:
- </p>
- </li>
-</ul>
-<blockquote>
- <blockquote>
-<pre>
- public class MyClass { public static int square(int n) { return 9; } }
-</pre>
- </blockquote>
- <p>
- This conforms to the simplicity principle. If <font size="3"><tt>testThreeSquared</tt></font> were the only test
- case that mattered, then this implementation would be correct. Of course, we know that it is incorrect, but in its
- current form it verifies that the test case actually passes when it is supposed to. Now suppose that we add a new
- test case:
- </p>
- <blockquote>
- <blockquote>
-<pre>
- public testFourSquared() { assertEquals(16, MyClass.square(4)); }
-</pre>
- </blockquote>
- </blockquote>
- <p>
- We could make this pass by changing the square function as follows:
- </p>
- <blockquote>
- <blockquote>
-<pre>
- public static int square(int n) { if (n == 3) return 9; else return 16; }
-</pre>
- </blockquote>
- </blockquote>
- <p>
- While this would pass the test, it violates the rule to make the code more general. To make the code more general,
- we have to return the square of the argument.
- </p>
- <blockquote>
- <blockquote>
-<pre>
- public static int square(int n) { return n*n; }
-</pre>
- </blockquote>
- </blockquote>
- <p>
- This solution passes all the tests, is simple, and increases the generality of the solution.
- </p>
-</blockquote>
-<ul>
- <li>
- <b>Corner Cases and Boundary Conditions</b>. Corner cases and boundary conditions are implemented in the production
- code with if statements or other similar decision structures. Don't write these statements unless you have a unit
- test that is failing because they don't exist. For example, let's say you are calculating weekly pay for an hourly
- employee.
- <blockquote>
- <blockquote>
-<pre>
- public void testHourlyPay() { double hourlyRate = 10.00; double hoursWorked = 8; Employee e = new Employee(hourlyRate); assertEquals(80.00, e.calculatePay(hoursWorked)); }
-</pre>
- </blockquote>
- </blockquote>
- <p>
- The code that makes this pass looks like this:
- </p>
- </li>
-</ul>
-<blockquote>
- <blockquote>
- <blockquote>
-<pre>
- public class Employee { private double hourlyRate; public Employee(double hourlyRate) { this.hourlyRate = hourlyRate; } public double calculatePay(double hoursWorked) { return hourlyRate * hoursWorked; } }
-</pre>
- </blockquote>
- </blockquote>
- <p>
- Now let's say we want to calculate overtime pay. Any hours over eight are charged at time-and-a-half. The first
- thing we do is add the new failing test case:
- </p>
- <blockquote>
- <blockquote>
-<pre>
- public void testOvertime() { double hourlyRate = 10.00; double hoursWorked = 10; Employee e = new Employee(hourlyRate); assertEquals(110.00, e.calculatePay(hoursWorked); }
-</pre>
- </blockquote>
- </blockquote>
- <p>
- <i>Then</i> we make the test case pass by changing the production code.
- </p>
- <blockquote>
- <blockquote>
-<pre>
- public double calculatePay(double hoursWorked) { double overtimeRate = hourlyRate * 1.5; double normalHours = Math.min(hoursWorked, 8.0); double overtimeHours = hoursWorked ̵; normalHours; return (normalHours * hourlyRate) + (overtimeHours * overtimeRate); }
-</pre>
- </blockquote>
- </blockquote>
- <p>
- Avoid adding any <font size="3"><tt>if, while, for, do,</tt></font> or any other type of conditional without a
- failing test case. Remember to add test cases for each such boundary condition.
- </p>
-</blockquote>
-<ul>
- <li>
- <b>Test Anything That Could Possibly Break</b>. By the same token, don't bother to test things that cannot possibly
- break. For example, it is usually fruitless to test simple accessors and mutators.
- <blockquote>
- <blockquote>
-<pre>
- public void testAccessorAndMutator() { X x = new X(); x.setField(3); assertEquals(3, x.getField()); }
-</pre>
- </blockquote>
- </blockquote>
- <p>
- Accessors and mutators cannot reasonably break. So there's no point in testing them. Judgment clearly has to be
- applied to use this rule. You will be tempted to avoid a necessary unit test by claiming that the code cannot
- possibly break. You'll know you've fallen into this habit when you start finding bugs in methods you thought
- couldn't break.
- </p>
- </li>
- <li>
- <b>Keep Test Data in the Code</b>. It is sometimes tempting to put test data into a file, especially when the input
- to a module is a file. However, the best place for test data is in the unit test code itself. For example, assume
- we have a function that counts the number of characters in a file. The signature for this function is:
- <blockquote>
- <blockquote>
-<pre>
- public int count(String fileName).
-</pre>
- </blockquote>
- </blockquote>
- <p>
- In order to keep the test data in the unit test code, the test should be written this way:
- </p>
- </li>
- <li style="LIST-STYLE-TYPE: none">
- <blockquote>
- <blockquote>
-<pre>
- public testCount() { File testFile = new File("testFile"); FileOutputStream fos = new FileOutputStream(testFile); PrintStream ps = new PrintStream(fos); ps.print("Oh, you Idiots!"); ps.close(); assertEquals(15, FileUtil.count("testFile")); testFile.delete(); }
-</pre>
- </blockquote>
- </blockquote>
- </li>
-</ul>
-<blockquote>
- <p>
- This keeps all the data relevant to the test in one place.
- </p>
-</blockquote>
-<ul>
- <li>
- <b>Test Pruning</b>. Sometimes you'll write tests that are useful for a time but become redundant as other tests
- take over their role. Don't be afraid to remove old redundant tests. Keep the test suite as small as possible
- without compromising coverage.
- </li>
-</ul>
-<ul>
- <li>
- <b>Keep Test Time Short</b>. The effectiveness of the tests depends upon convenience. The more convenient it is to
- run the tests, the more often they will be run. Thus, it is very important to keep the test run time very short. In
- a large system, this means partitioning the tests.<br />
- <br />
- When working on a particular module, you'll want to choose the tests that are relevant to that module and the
- surrounding modules. Keep the test time well under a minute. Ten seconds is often too long.<br />
- <br />
- When checking in a module, run a test suite that tests the whole system but takes no more than 10 minutes to run.
- This may mean you'll have to pull out some of the longer running tests.<br />
- <br />
- Every night, run all the tests in the system. Keep the running time small enough so that they can be run more than
- once before morning just in case there is a problem that forces a rerun.
- </li>
-</ul>
-<h3>
- <a id="GUIS" name="GUIS">How do I test GUIs?</a>
-</h3>
-<p>
- The trick to writing unit tests for GUIs is separation and decoupling. Separate the GUI code into three layers,
- typically called <b>Model</b>, <b>View</b>, and <b>Presenter</b>:
-</p>
-<ul>
- <li>
- The <b>Model</b> understands the business rules of the items that are to be displayed on the screen. All relevant,
- business-related policies are implemented in this module. Therefore, this module is easy to test based solely on
- its inputs and outputs.<br />
- </li>
- <li>
- The <b>Presenter</b> understands how the data is to be presented and how the user will interact with that data. It
- knows that there are buttons, check boxes, text fields, etc. It knows that sometimes the buttons need to be
- disabled (grayed), and it knows sometimes text fields are not editable. It knows, at a mechanical level, how the
- data are displayed and how the interactions take place. However, it does not know anything about the actual GUI
- API. For example, if you are writing a Java Swing GUI, the Presenter does not use any of the swing classes. Rather,
- it sends messages to the View to take care of the actual display and interaction. Thus, the Presenter can be
- tested, again, based solely on its inputs from the Model and its outputs to the View.<br />
- </li>
- <li>
- The <b>View</b> understands the GUI API. It makes no policy, selection, or validation decisions. It has virtually
- zero intelligence. It is simply a shim that ties the interface used by the Presenter to the GUI API. It can be
- tested by writing tests that check the wiring. The tests walk through the GUI data structures, making sure that the
- appropriate button, text fields, and check boxes have been created. The tests send events to the GUI widgets and
- make sure the appropriate callbacks are invoked.
- </li>
-</ul>
-<h3>
- <a id="Embedded" name="Embedded">How do I test embedded systems?</a>
-</h3>
-<p>
- Some software is written to control hardware. You can test this software by writing a hardware simulator. The tests set
- the hardware simulator up into various states and then drive the system to manipulate that hardware. Finally, the tests
- query the simulation to ensure that the hardware was driven to the correct final state.
-</p>
-<h3>
- <a id="Concurrency" name="Concurrency">How do I test concurrency?</a>
-</h3>
-<p>
- Some software is reentrant or concurrent. Race conditions can make the software behavior non-deterministic. There are
- failure modes that can be both severe and strongly dependent upon timing and order of events. Software that works
- 99.999% of the time can fail that last .001% of the time due to concurrency problems. Finding these problems is a
- challenge.
-</p>
-<p>
- Usually exhaustive Monte Carlo testing is used to attempt to drive the system through as many states as possible.
-</p>
-<p>
- Once concurrency problems are discovered, tests can be written that drive the system to the failure state and then
- prove the failure. Thereafter, the problem can be repaired, and the test remains in the test suite as a regression
- test.
-</p>
-<h3>
- <a id="Database" name="Database">How do I test database transactions?</a>
-</h3>
-<p>
- Almost always the best way to do this is to create an interface that represents the database. Each test case can
- implement that interface and pretend to be the database, supplying its own data and interpreting the calls made by the
- module under test. This prevents test data from actually being written and read from the database. It also allows the
- test code to force failure conditions that are otherwise hard to simulate.
-</p>
-<p>
- See: <a href="http://c2.com/cgi/wiki?MockObject%20" target="_blank">http://c2.com/cgi/wiki?MockObject</a>
-</p>
-<h3>
- <a id="Servlets" name="Servlets">How do I test Servlets?</a>
-</h3>
-<p>
- Servlets are simply pipes through which form data passes into a program and HTML passes out. The trick to testing a
- servlet is to separate the program from the pipe. Keep the servlet code as thin as possible. Put your program in plain
- old classes that don't derive from Servlet. Then you can test those plain old classes as usual. If the servlet itself
- is thin enough, it may be too simple to bother testing.
-</p>
-<p>
- Of course, you can also set up your own little servlet invoker or use one of the open source versions. These programs
- act like a web server and fire servlets for you. You pass the form data to them, and they pass the HTML back to you.
-</p>
-<p>
- See:
-</p>
-<blockquote>
- <a href="http://c2.com/cgi/wiki?JunitServlet" target="_blank">http://c2.com/cgi/wiki?JunitServlet</a><br />
- <a href="http://c2.com/cgi/wiki?ServletTesting" target="_blank">http://c2.com/cgi/wiki?ServletTesting</a><br />
- <a href="http://strutstestcase.sourceforge.net/" target="_blank">http://strutstestcase.sourceforge.net/</a>
-</blockquote>
-<h3>
- <a id="WebPages" name="WebPages">How do I test web pages?</a>
-</h3>
-<p>
- An HTML document is almost an XML document. There is a tool that allows you to query an HTML document as though it were
- an XML document. That tool is called HTTPUnit. Using this tool, you can write tests that inspect the innards of an HTML
- document without worrying about white space or formatting issues. Another tool called HTMLUnit also does something
- similar. HTMLUnit includes support for testing HTML pages with embedded JavaScript.
-</p>
-<p>
- See:
-</p>
-<blockquote>
- <a href="http://httpunit.sourceforge.net/" target="_blank">http://httpunit.sourceforge.net/</a><br />
- <a href="http://htmlunit.sourceforge.net/" target="_blank">http://htmlunit.sourceforge.net/</a><br />
-</blockquote>
-<p>
- <br />
- &nbsp;
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/guidelines/test_ideas_for_booleans_and_boundaries.xmi b/XP/xp/guidances/guidelines/test_ideas_for_booleans_and_boundaries.xmi
deleted file mode 100644
index f506c50..0000000
--- a/XP/xp/guidances/guidelines/test_ideas_for_booleans_and_boundaries.xmi
+++ /dev/null
@@ -1,1751 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-FX8hDYUKOXsrQulFe9lwtw" name="test_ideas_for_booleans_and_boundaries,1.7150344523489172E-305" guid="-FX8hDYUKOXsrQulFe9lwtw" changeDate="2006-11-21T15:55:18.633-0800" version="1.0.0">
- <mainDescription><a id="XE_test__developer_testing__test_ideas__for_booleans_and_boundaries"
-name="XE_test__developer_testing__test_ideas__for_booleans_and_boundaries"></a><a
-id="XE_test-ideas__for_booleans_and_boundaries" name="XE_test-ideas__for_booleans_and_boundaries"></a><a
-id="XE_design__developer_testing__test_ideas__for_booleans_and_boundaries"
-name="XE_design__developer_testing__test_ideas__for_booleans_and_boundaries"></a>
-<h3>
- <a id="Introduction" name="Introduction"></a>Introduction
-</h3>
-<p>
- Test ideas are based on <a href="./../../../glossary/glossary.htm#fault_model" target="_blank">fault models</a>,
- notions of which faults are plausible in software and how those faults can best be uncovered. This guideline shows how
- to create test ideas from boolean and relational expressions. It first motivates the techniques by looking at code,
- then describes how to apply them if the code hasn't been written yet or is otherwise unavailable.
-</p>
-<h3>
- <a id="BooleanExpressions" name="BooleanExpressions"></a><b>Boolean Expressions</b>
-</h3>
-<p>
- Consider the following code snippet, taken from an (imaginary) system for managing bomb detonation. It's part of the
- safety system and controls whether the "detonate bomb" button push is obeyed.
-</p>
-<blockquote>
-<pre>
-if (publicIsClear || technicianClear) {
- bomb.detonate();
-}
-</pre>
-</blockquote>
-<p>
- The code is wrong. The <font size="+0">||</font> should be an <font size="+0">&amp;&amp;</font>. That mistake will have
- bad effects. Instead of detonating the bomb when both the bomb technician and public are clear, the system will
- detonate when <i>either</i> is clear.
-</p>
-<p>
- What test would find this bug?
-</p>
-<p>
- Consider a test in which the button is pushed when both the technician and public are clear. The code will allow the
- bomb to be detonated. But-and this is important-the <i>correct</i> code (the one that uses an <font
- size="+0">&amp;&amp;</font>) would do the same. So the test is useless at finding this fault.
-</p>
-<p>
- Similarly, this incorrect code behaves correctly when both the technician and public are next to the bomb: the bomb is
- not detonated.
-</p>
-<p>
- To find the bug, you have to have a case in which the code as written evaluates differently than the code that should
- have been written. For example, the public must be clear, but the bomb technician is still next to the bomb. Here are
- all the tests in table form:
-</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="100%" bordercolorlight="#808080" border="1">
- <tbody>
- <tr>
- <th scope="col" width="20%">
- <p align="center">
- publicIsClear
- </p>
- </th>
- <th scope="col" width="20%">
- <p align="center">
- technicianClear
- </p>
- </th>
- <th scope="col" width="20%">
- <p align="center">
- Code as written...
- </p>
- </th>
- <th scope="col" width="20%">
- <p align="center">
- Correct code would have...
- </p>
- </th>
- <th width="20%">
- &nbsp;
- </th>
- </tr>
- <tr>
- <td width="20%">
- <p align="center">
- true
- </p>
- </td>
- <td width="20%">
- <p align="center">
- true
- </p>
- </td>
- <td width="20%">
- <p align="center">
- <font color="#008000">detonates</font>
- </p>
- </td>
- <td width="20%">
- <p align="center">
- <font color="#008000">detonated</font>
- </p>
- </td>
- <td width="20%">
- <p align="center">
- test is useless (for this fault)
- </p>
- </td>
- </tr>
- <tr>
- <td width="20%">
- <p align="center">
- true
- </p>
- </td>
- <td width="20%">
- <p align="center">
- false
- </p>
- </td>
- <td width="20%">
- <p align="center">
- <font color="#ff0000">detonates</font>
- </p>
- </td>
- <td width="20%">
- <p align="center">
- <font color="#ff0000">not detonated</font>
- </p>
- </td>
- <td width="20%">
- <p align="center">
- useful test
- </p>
- </td>
- </tr>
- <tr>
- <td width="20%">
- <p align="center">
- false
- </p>
- </td>
- <td width="20%">
- <p align="center">
- true
- </p>
- </td>
- <td width="20%">
- <p align="center">
- <font color="#ff0000">detonates</font>
- </p>
- </td>
- <td width="20%">
- <p align="center">
- <font color="#ff0000">not detonated</font>
- </p>
- </td>
- <td width="20%">
- <p align="center">
- useful test
- </p>
- </td>
- </tr>
- <tr>
- <td width="20%">
- <p align="center">
- false
- </p>
- </td>
- <td width="20%">
- <p align="center">
- false
- </p>
- </td>
- <td width="20%">
- <p align="center">
- <font color="#008000">does not detonate</font>
- </p>
- </td>
- <td width="20%">
- <p align="center">
- <font color="#008000">not detonated</font>
- </p>
- </td>
- <td width="20%">
- <p align="center">
- test is useless (for this fault)
- </p>
- </td>
- </tr>
- </tbody>
- </table>
- <br />
-</div>
-<p>
- The two middle tests are both useful for finding this particular fault. Note, however, that they're redundant: since
- either will find the fault, you needn't run both.
-</p>
-<p>
- There are other ways in which the expression might be wrong. Here are two lists of common mistakes in boolean
- expressions. The faults on the left are all caught by the technique discussed here. The faults on the right might not
- be. So this technique doesn't catch all the faults we might like, but it's still useful.
-</p>
-<div align="right">
- <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="100%" bordercolorlight="#808080" border="1">
- <tbody>
- <tr>
- <th scope="col" width="50%">
- <p align="center">
- <b>Faults detected</b>
- </p>
- </th>
- <th scope="col" width="50%">
- <p align="center">
- <b>Faults possibly not detected</b>
- </p>
- </th>
- </tr>
- <tr>
- <td width="50%">
- Using wrong operator: a <font color="#ff0000"><b>||</b></font> b should be a<font
- color="#ff0000"><b>&amp;&amp;</b></font>b
- </td>
- <td width="50%">
- Wrong variable used: a&amp;&amp;<font color="#ff0000"><b>b</b></font>&amp;&amp;c should be a&amp;&amp;
- <font color="#ff0000"><b>x</b></font>&amp;&amp;d
- </td>
- </tr>
- <tr>
- <td width="50%">
- Negation is omitted or incorrect: a||b should be <font color="#ff0000"><b>!</b></font>a||b, or <font
- color="#ff0000"><b>!</b></font> a||b should be a||b
- </td>
- <td width="50%">
- Expression is too simple: a&amp;&amp;b should be a&amp;&amp;b<font
- color="#ff0000"><b>&amp;&amp;c</b></font>
- </td>
- </tr>
- <tr>
- <td width="50%">
- The expression is misparenthesized: a&amp;&amp;b||c should be a&amp;&amp;<font
- color="#ff0000"><b>(</b></font>b||c<font color="#ff0000"><b>)</b></font>
- </td>
- <td width="50%">
- Expressions with more than one of the faults in the left column
- </td>
- </tr>
- <tr>
- <td width="50%">
- The expression is overly complex: a&amp;&amp;b<b>&amp;&amp;c</b> should be <font
- size="+0">a&amp;&amp;b<br />
- </font> (This fault is not so likely, but is easy to find with tests useful for other reasons.)
- </td>
- <td width="50%">
- &nbsp;
- </td>
- </tr>
- </tbody>
- </table>
- <br />
-</div>
-<p>
- How are these ideas used? Suppose you're given a boolean expression like <font size="+0">a&amp;&amp;!b</font>. You
- could construct a truth table like this one:
-</p>
-<div align="right">
- <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="100%" bordercolorlight="#808080" border="1">
- <tbody>
- <tr>
- <th scope="col" width="14%">
- <p align="center">
- a
- </p>
- </th>
- <th scope="col" width="14%">
- <p align="center">
- b
- </p>
- </th>
- <th scope="col" width="14%">
- <p align="center">
- a&amp;&amp;!b<br />
- (code as written)
- </p>
- </th>
- <th scope="col" width="14%">
- <p align="center">
- maybe it should be<br />
- a<font color="#ff0000"><b>||</b></font>!b
- </p>
- </th>
- <th scope="col" width="14%">
- <p align="center">
- maybe it should be<br />
- <font color="#ff0000"><b>!</b></font>a&amp;&amp;!b
- </p>
- </th>
- <th scope="col" width="15%">
- <p align="center">
- maybe it should be<br />
- a&amp;&amp;b
- </p>
- </th>
- <th scope="col" width="15%">
- <p align="center">
- ...
- </p>
- </th>
- </tr>
- <tr>
- <td width="14%">
- <p align="center">
- true
- </p>
- </td>
- <td width="14%">
- <p align="center">
- true
- </p>
- </td>
- <td width="14%">
- <p align="center">
- false
- </p>
- </td>
- <td width="14%">
- <p align="center">
- <font color="#ff0000">true</font>
- </p>
- </td>
- <td width="14%">
- <p align="center">
- false
- </p>
- </td>
- <td width="15%">
- <p align="center">
- <font color="#ff0000">true</font>
- </p>
- </td>
- <td width="15%">
- <p align="center">
- ...
- </p>
- </td>
- </tr>
- <tr>
- <td width="14%">
- <p align="center">
- true
- </p>
- </td>
- <td width="14%">
- <p align="center">
- false
- </p>
- </td>
- <td width="14%">
- <p align="center">
- true
- </p>
- </td>
- <td width="14%">
- <p align="center">
- true
- </p>
- </td>
- <td width="14%">
- <p align="center">
- <font color="#ff0000">false</font>
- </p>
- </td>
- <td width="15%">
- <p align="center">
- false
- </p>
- </td>
- <td width="15%">
- <p align="center">
- ...
- </p>
- </td>
- </tr>
- <tr>
- <td width="14%">
- <p align="center">
- false
- </p>
- </td>
- <td width="14%">
- <p align="center">
- true
- </p>
- </td>
- <td width="14%">
- <p align="center">
- false
- </p>
- </td>
- <td width="14%">
- <p align="center">
- false
- </p>
- </td>
- <td width="14%">
- <p align="center">
- false
- </p>
- </td>
- <td width="15%">
- <p align="center">
- false
- </p>
- </td>
- <td width="15%">
- <p align="center">
- ...
- </p>
- </td>
- </tr>
- <tr>
- <td width="14%">
- <p align="center">
- false
- </p>
- </td>
- <td width="14%">
- <p align="center">
- false
- </p>
- </td>
- <td width="14%">
- <p align="center">
- false
- </p>
- </td>
- <td width="14%">
- <p align="center">
- <font color="#ff0000">true</font>
- </p>
- </td>
- <td width="14%">
- <p align="center">
- <font color="#ff0000">true</font>
- </p>
- </td>
- <td width="15%">
- <p align="center">
- false
- </p>
- </td>
- <td width="15%">
- <p align="center">
- ...
- </p>
- </td>
- </tr>
- </tbody>
- </table>
- <br />
-</div>
-<p>
- If you crunched through all the possibilities, you'd find that the first, second, and fourth possibilities are all
- that's needed. The third expression will find no faults that won't be found by one of the others, so you needn't try
- it. (As the expressions grow more complicated, the savings due to unneeded cases grow quickly.)
-</p>
-<p>
- Of course, no one sane would build such a table. Fortunately, you don't have to. It's easy to memorize the required
- cases for simple expressions. (See the next section.) For more complex expressions, such as <font
- size="+0">A&amp;&amp;B||C</font>, see <a href="../../examples/extrnlcntrbtns/test/tstatmtch.htm" target="_blank">Test
- Ideas for Mixtures of ANDs and ORs</a>, which lists test ideas for expressions with two or three operators. For even
- more complex expressions, a <a href="http://www.testing.com/tools/multi/README.html" target="_blank">program</a> can be
- used to generate test ideas.
-</p>
-<h3>
- <a id="SimpleExpressionTables" name="SimpleExpressionTables"></a><b>Tables for Simple Boolean Expressions</b>
-</h3>
-<p>
- If the expression is <font size="+0">A&amp;&amp;B</font>, test with:
-</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 scope="col" width="50%">
- <p align="center">
- A
- </p>
- </th>
- <th scope="col" width="50%">
- <p align="center">
- B
- </p>
- </th>
- </tr>
- <tr>
- <td width="50%">
- <p align="center">
- true
- </p>
- </td>
- <td width="50%">
- <p align="center">
- true
- </p>
- </td>
- </tr>
- <tr>
- <td>
- <p align="center">
- true
- </p>
- </td>
- <td>
- <p align="center">
- false
- </p>
- </td>
- </tr>
- <tr>
- <td width="50%">
- <p align="center">
- false
- </p>
- </td>
- <td width="50%">
- <p align="center">
- true
- </p>
- </td>
- </tr>
- </tbody>
- </table>
- <br />
-</div>
-<p>
- If the expression is <font size="+0">A||B</font>, test with:
-</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 scope="col" width="50%">
- <p align="center">
- A
- </p>
- </th>
- <th scope="col" width="50%">
- <p align="center">
- B
- </p>
- </th>
- </tr>
- <tr>
- <td width="50%">
- <p align="center">
- true
- </p>
- </td>
- <td width="50%">
- <p align="center">
- false
- </p>
- </td>
- </tr>
- <tr>
- <td>
- <p align="center">
- false
- </p>
- </td>
- <td>
- <p align="center">
- true
- </p>
- </td>
- </tr>
- <tr>
- <td width="50%">
- <p align="center">
- false
- </p>
- </td>
- <td width="50%">
- <p align="center">
- false
- </p>
- </td>
- </tr>
- </tbody>
- </table>
- <br />
-</div>
-<p>
- If the expression is <font size="+0">A<sub>1</sub> &amp;&amp; A<sub>2</sub> &amp;&amp; ... &amp;&amp;
- A<sub>n</sub></font>, test with:
-</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>
- <td width="100%">
- <p align="center">
- A<sub>1,</sub> A<sub>2</sub>, ..., and A<sub>n</sub> are all true
- </p>
- </td>
- </tr>
- <tr>
- <td width="100%">
- <p align="center">
- A<sub>1</sub> is false, all the rest are true
- </p>
- </td>
- </tr>
- <tr>
- <td width="100%">
- <p align="center">
- A<sub>2</sub> is false, all the rest are true
- </p>
- </td>
- </tr>
- <tr>
- <td width="100%">
- <p align="center">
- ...
- </p>
- </td>
- </tr>
- <tr>
- <td width="100%">
- <p align="center">
- A<sub>n</sub> is false, all the rest are true
- </p>
- </td>
- </tr>
- </tbody>
- </table>
- <br />
-</div>
-<p align="left">
- If the expression is <font size="+0">A<sub>1</sub> || A<sub>2</sub> || ... || A<sub>n</sub></font>, test with:
-</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>
- <td width="100%">
- <p align="center">
- A<sub>1,</sub> A<sub>2</sub>, ..., and A<sub>n</sub> are all false
- </p>
- </td>
- </tr>
- <tr>
- <td width="100%">
- <p align="center">
- A<sub>1</sub> is true, all the rest are false
- </p>
- </td>
- </tr>
- <tr>
- <td width="100%">
- <p align="center">
- A<sub>2</sub> is true, all the rest are false
- </p>
- </td>
- </tr>
- <tr>
- <td width="100%">
- <p align="center">
- ...
- </p>
- </td>
- </tr>
- <tr>
- <td width="100%">
- <p align="center">
- A<sub>n</sub> is true, all the rest are false
- </p>
- </td>
- </tr>
- </tbody>
- </table>
- <br />
-</div>
-<p>
- If the expression is <font size="+0">A</font>, test with:
-</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>
- <td width="100%">
- <p align="center">
- A
- </p>
- </td>
- </tr>
- <tr>
- <td width="100%">
- <p align="center">
- true
- </p>
- </td>
- </tr>
- <tr>
- <td width="100%">
- <p align="center">
- false
- </p>
- </td>
- </tr>
- </tbody>
- </table>
- <br />
-</div>
-<p>
- So, when you need to test <font size="+0">a&amp;&amp;!b</font>, you can apply the first table above, invert the sense
- of b (because it's negated), and get this list of <a class="elementLinkWithUserText"
- href="./../../../xp/guidances/concepts/test-ideas_list,8.834380241450745E-306.html" guid="8.834380241450745E-306">Test
- Ideas</a>:
-</p>
-<ul>
- <li>
- A true, B false
- </li>
- <li>
- A true, B true
- </li>
- <li>
- A false, B false
- </li>
-</ul>
-<h3>
- <a id="RelationalExpressions" name="RelationalExpressions"></a><b>Relational Expressions</b>
-</h3>
-<p align="left">
- Here's another example of code with a fault:
-</p>
-<blockquote>
-<pre>
-if (finished &lt; required) {
- siren.sound();
-}
-</pre>
-</blockquote>
-<p align="left">
- The <font size="+0">&lt;</font> should be a <font size="+0">&lt;=</font>. Such mistakes are fairly common. As with
- boolean expressions, you can construct a table of test values and see which ones detect the fault:
-</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 scope="col" width="25%">
- <p align="center">
- finished
- </p>
- </th>
- <th scope="col" width="25%">
- <p align="center">
- required
- </p>
- </th>
- <th scope="col" width="25%">
- <p align="center">
- code as written...
- </p>
- </th>
- <th scope="col" width="25%">
- <p align="center">
- the correct code would have...
- </p>
- </th>
- </tr>
- <tr>
- <td width="25%">
- <p align="center">
- 1
- </p>
- </td>
- <td width="25%">
- <p align="center">
- 5
- </p>
- </td>
- <td width="25%">
- <p align="center">
- sounds the siren
- </p>
- </td>
- <td width="25%">
- <p align="center">
- sounded the siren
- </p>
- </td>
- </tr>
- <tr>
- <td width="25%">
- <p align="center">
- 5
- </p>
- </td>
- <td width="25%">
- <p align="center">
- 5
- </p>
- </td>
- <td width="25%">
- <p align="center">
- <font color="#ff0000">does not sound the siren</font>
- </p>
- </td>
- <td width="25%">
- <p align="center">
- <font color="#ff0000">sounded the siren</font>
- </p>
- </td>
- </tr>
- <tr>
- <td width="25%">
- <p align="center">
- 5
- </p>
- </td>
- <td width="25%">
- <p align="center">
- 1
- </p>
- </td>
- <td width="25%">
- <p align="center">
- does not sound the siren
- </p>
- </td>
- <td width="25%">
- <p align="center">
- not sounded the siren
- </p>
- </td>
- </tr>
- </tbody>
- </table>
- <br />
-</div>
-<p>
- More generally, the fault can be detected whenever <font size="+0">finished=required</font>. From analyses of plausible
- faults, we can get these rules for test ideas:
-</p>
-<p>
- If the expression is A&lt;B or A&gt;=B, test with
-</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>
- <td width="100%">
- <p align="center">
- A=B
- </p>
- </td>
- </tr>
- <tr>
- <td width="100%">
- <p align="center">
- A slightly less than B
- </p>
- </td>
- </tr>
- </tbody>
- </table>
- <br />
-</div>
-<p>
- If the expression is A&gt;B or A&lt;=B, test with
-</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>
- <td width="100%">
- <p align="center">
- A=B
- </p>
- </td>
- </tr>
- <tr>
- <td width="100%">
- <p align="center">
- A slightly larger than B
- </p>
- </td>
- </tr>
- </tbody>
- </table>
- <br />
-</div>
-<p>
- What does "slightly" mean? If A and B are integers, A should be one less than or larger than B. If they are floating
- point numbers, A should be a number quite close to B. (It's probably not necessary that it be the the closest floating
- point number to B.)
-</p>
-<h3>
- <a id="CombinedExpressions" name="CombinedExpressions"></a><b>Rules for Combined Boolean and Relational Expressions</b>
-</h3>
-<p>
- Most relational operators occur within boolean expressions, as in this example:
-</p>
-<blockquote>
-<pre>
-if (finished &lt; required) {
- siren.sound();
-}
-</pre>
-</blockquote>
-<p>
- The rules for relational expressions would lead to these test ideas:
-</p>
-<ol>
- <li>
- <font size="+0">finished</font> is equal to required
- </li>
- <li>
- <font size="+0">finished</font> is slightly less than <font size="+0">required</font>
- </li>
-</ol>
-<p>
- The rules for boolean expressions would lead to these:
-</p>
-<ol>
- <li>
- <font size="+0">finished &lt; required</font> should be true
- </li>
- <li>
- <font size="+0">finished &lt; required</font> should be false
- </li>
-</ol>
-<p>
- But if <font size="+0">finished</font> is slightly less than <font size="+0">required</font>, <font size="+0">finished
- &lt; required</font> is true, so there's no point in writing down the latter.
-</p>
-<p>
- And if <font size="+0">finished</font> equals <font size="+0">required</font>, <font size="+0">finished &lt;
- required</font> is false, so there's no point in writing down that latter one either.
-</p>
-<p>
- So, <b>if a relational expression contains no boolean operators (<font size="+0">&amp;&amp;</font> and <font
- size="+0">||</font>), ignore the fact that it's also a boolean expression.</b>
-</p>
-<p>
- Things are a bit more complicated with combinations of boolean and relational operators, like this one:
-</p>
-<blockquote>
-<pre>
-if (count&lt;5 || always) {
- siren.sound();
-}
-</pre>
-</blockquote>
-<p>
- From the relational expression, you get:
-</p>
-<ul>
- <li>
- <font size="+0">count</font> slightly less than 5
- </li>
- <li>
- <font size="+0">count</font> equal to 5
- </li>
-</ul>
-<p>
- From the boolean expression, you get:
-</p>
-<ul>
- <li>
- <font size="+0">count&lt;5</font> true, always false
- </li>
- <li>
- <font size="+0">count&lt;5</font> false, always true
- </li>
- <li>
- <font size="+0">count&lt;5</font> false, always false
- </li>
-</ul>
-<p>
- These can be combined into three more specific test ideas. (Here, note that <font size="+0">count</font> is an
- integer.)
-</p>
-<ol>
- <li>
- <font size="+0">count=4</font>, always false
- </li>
- <li>
- <font size="+0">count=5</font>, always true
- </li>
- <li>
- <font size="+0">count=5</font>, always false
- </li>
-</ol>
-<p>
- Notice that <font size="+0">count=5</font> is used twice. It might seem better to use it only once, to allow the use of
- some other value-after all, why test <font size="+0">count</font> with 5 twice? Wouldn't it be better to try it once
- with 5 and another time with some other value such that <font size="+0">count&lt;5</font> is false? It would be, but
- it's dangerous to try. That's because it's easy to make a mistake. Suppose you tried the following:
-</p>
-<ol>
- <li>
- <font size="+0">count=4</font>, always false
- </li>
- <li>
- <font size="+0">count=5</font>, always true
- </li>
- <li>
- <font size="+0"><b>count&lt;5</b></font> <b>false</b>, <font size="+0">always</font> false
- </li>
-</ol>
-<p>
- Suppose that there's a fault that can <i>only</i> be caught with <font size="+0">count=5</font>. What that means is
- that the value 5 will cause <font size="+0">count&lt;5</font> to produce false in the second test, when the correct
- code would have produced true. However, that false value is immediately or'd with the value of always, which is true.
- That means the value of the whole expression is correct, even though the value of the relational subexpression was
- wrong. The fault will go undiscovered.
-</p>
-<p>
- The fault doesn't go undiscovered if it's the <i>other</i> count=5 that is left less specific.
-</p>
-<p>
- Similar problems happen when the relational expression is on the right-hand side of the boolean operator.
-</p>
-<p>
- Because it's hard to know which subexpressions have to be exact and which can be general, it's best to make them all
- exact. The alternative is to use the <a href="http://www.testing.com/tools/multi/README.html" target="_blank">boolean
- expression program</a> mentioned above. It produces correct test ideas for arbitrary mixed boolean-and-relational
- expressions.
-</p>
-<h3>
- <a id="TestIdeasWithoutCode" name="TestIdeasWithoutCode"></a><b>Test ideas without Code</b>
-</h3>
-<p>
- As explained in <a class="elementLinkWithType"
- href="./../../../xp/guidances/concepts/test-first_design,6.556259235358794E-306.html"
- guid="6.556259235358794E-306">Concept: Test-first Design</a>, it's usually preferable to design tests before
- implementing code. So, although the techniques are motivated by code examples, they'll usually be applied without code.
- How?
-</p>
-<p>
- Certain design artifacts, such as statecharts and sequence diagrams, use boolean expressions as guards. Those cases are
- straightforward-simply add the test ideas from the boolean expressions to the artifact's test idea checklist. See <a
- class="elementLinkWithUserText"
- href="./../../../xp/guidances/guidelines/test_ideas_for_statechart_and_flow_diagrams,1.0347051690476123E-305.html"
- guid="1.0347051690476123E-305">Guideline: Test Ideas for Statechart and Activity Diagrams</a>.
-</p>
-<p>
- The trickier case is when boolean expressions are implicit rather than explicit. That's often the case in descriptions
- of APIs. Here's an example. Consider this method:
-</p>
-<blockquote>
-<pre>
-List matchList(Directory d1, Directory d1,
- FilenameFilter excluder);
-</pre>
-</blockquote>
-<p>
- The description of this method's behavior might read like this:
-</p>
-<blockquote>
- <p>
- Returns a List of the absolute pathnames of all files that appear in both Directories. Subdirectories are
- descended. [...] Filenames that match the <font size="+0">excluder</font> are excluded from the returned list. The
- excluder only applies to the top-level directories, not to filenames in subdirectories.
- </p>
-</blockquote>
-<p>
- The words "and" and "or" do not appear. But when is a filename included in the return list? When it appears in the
- first directory <b>and</b> it appears in the second directory <b>and</b> it's either in a lower level directory
- <b>or</b> it's not specifically excluded. In code:
-</p>
-<blockquote>
-<pre>
-if (appearsInFirst &amp;&amp; appearsInSecond &amp;&amp;
- (inLowerLevel || !excluded)) {
- add to list
-}
-</pre>
-</blockquote>
-<p>
- Here are the test ideas for that expression, given in tabular form:
-</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 scope="col" width="25%">
- <p align="center">
- appearsInFirst
- </p>
- </th>
- <th scope="col" width="25%">
- <p align="center">
- appearsInSecond
- </p>
- </th>
- <th scope="col" width="25%">
- <p align="center">
- inLower
- </p>
- </th>
- <th scope="col" width="25%">
- <p align="center">
- excluded
- </p>
- </th>
- </tr>
- <tr>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- false
- </p>
- </td>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- </tr>
- <tr>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- false
- </p>
- </td>
- <td width="25%">
- <p align="center">
- false
- </p>
- </td>
- </tr>
- <tr>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- </tr>
- <tr>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- false
- </p>
- </td>
- <td width="25%">
- <p align="center">
- false
- </p>
- </td>
- <td width="25%">
- <p align="center">
- false
- </p>
- </td>
- </tr>
- <tr>
- <td width="25%">
- <p align="center">
- false
- </p>
- </td>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- false
- </p>
- </td>
- <td width="25%">
- <p align="center">
- false
- </p>
- </td>
- </tr>
- </tbody>
- </table>
-</div>
-<p>
- <br />
- The general approach for discovering implicit boolean expressions from text is to first list the actions described
- (such as "returns a matching name"). Then write a boolean expression that describes the cases in which an action is
- taken. Derive test ideas from all the expressions.
-</p>
-<p>
- There's room for disagreement in that process. For example, one person might write down the boolean expression used
- above. Another might say that there are really two distinct actions: first, the program discovers matching names, then
- it filters them out. So, instead of one expression, there are two:
-</p>
-<dl>
- <dt>
- discover a match:
- </dt>
- <dd>
- happens when a file is in the first directory <b>and</b> a file with the same name is in the second directory
- </dd>
- <dt>
- filter a match:
- </dt>
- <dd>
- happens when the matching files are in the top level <b>and</b> the name matches the <font
- size="+0">excluder</font>
- </dd>
-</dl>
-<p>
- These different approaches can lead to different test ideas and thus different tests. But the differences are most
- likely not particularly important. That is, the time spent worrying about which expression is right, and trying
- alternatives, would be better spent on other techniques and producing more tests. If you're curious about what the
- sorts of differences might be, read on.
-</p>
-<p>
- The second person would get two sets of test ideas.
-</p>
-<blockquote>
- <p>
- test ideas about discovering a match:
- </p>
- <ul>
- <li>
- file in first directory, file in second directory (true, true)
- </li>
- <li>
- file in first directory, file not in second directory (true, false)
- </li>
- <li>
- file not in first directory, file in second directory (false, true)
- </li>
- </ul>
- <p>
- test ideas about filtering a match (once one has been discovered):
- </p>
- <ul>
- <li>
- matching files are in the top level, the name matches the <font size="+0">excluder</font> (true, true)
- </li>
- <li>
- matching files are in the top level, the name doesn't match the <font size="+0">excluder</font> (true, false)
- </li>
- <li>
- matching files are in some lower level, the name matches the <font size="+0">excluder</font> (false, true)
- </li>
- </ul>
-</blockquote>
-<p>
- Suppose those two sets of test ideas are combined. The ones in the second set only matter when the file is in both
- directories, so they can only be combined with the first idea in the first set. That gives us the following:
-</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 scope="col" width="25%">
- <p align="center">
- file in first directory
- </p>
- </th>
- <th scope="col" width="25%">
- <p align="center">
- file in second directory
- </p>
- </th>
- <th scope="col" width="25%">
- <p align="center">
- in top level
- </p>
- </th>
- <th scope="col" width="25%">
- <p align="center">
- matches excluder
- </p>
- </th>
- </tr>
- <tr>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- </tr>
- <tr>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- false
- </p>
- </td>
- </tr>
- <tr>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- false
- </p>
- </td>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- </tr>
- </tbody>
- </table>
- <br />
-</div>
-<p>
- Two of the test ideas about discovering a match do not appear in that table. We can add them like this:
-</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 scope="col" width="25%">
- <p align="center">
- file in first directory
- </p>
- </th>
- <th scope="col" width="25%">
- <p align="center">
- file in second directory
- </p>
- </th>
- <th scope="col" width="25%">
- <p align="center">
- in top level
- </p>
- </th>
- <th scope="col" width="25%">
- <p align="center">
- matches excluder
- </p>
- </th>
- </tr>
- <tr>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- </tr>
- <tr>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- false
- </p>
- </td>
- </tr>
- <tr>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- false
- </p>
- </td>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- </tr>
- <tr>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- false
- </p>
- </td>
- <td width="25%">
- <p align="center">
- -
- </p>
- </td>
- <td width="25%">
- <p align="center">
- -
- </p>
- </td>
- </tr>
- <tr>
- <td width="25%">
- <p align="center">
- false
- </p>
- </td>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- -
- </p>
- </td>
- <td width="25%">
- <p align="center">
- -
- </p>
- </td>
- </tr>
- </tbody>
- </table>
- <br />
-</div>
-<p>
- The blank cells indicate that the columns are irrelevant.
-</p>
-<p>
- This table now looks rather similar to the first person's table. The similarity can be emphasized by using the same
- terminology. The first person's table has a column called "inLower", and the second person's has one called "in top
- level". They can be converted by flipping the sense of the values. Doing that, we get this version of the second table:
-</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 width="25%">
- <p align="center">
- appearsInFirst
- </p>
- </th>
- <th width="25%">
- <p align="center">
- appearsInSecond
- </p>
- </th>
- <th width="25%">
- <p align="center">
- inLower
- </p>
- </th>
- <th width="25%">
- <p align="center">
- excluded
- </p>
- </th>
- </tr>
- <tr>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- false
- </p>
- </td>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- </tr>
- <tr>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- false
- </p>
- </td>
- <td width="25%">
- <p align="center">
- false
- </p>
- </td>
- </tr>
- <tr>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- <td width="25%">
- <p align="center">
- true
- </p>
- </td>
- </tr>
- <tr>
- <td>
- <p align="center">
- true
- </p>
- </td>
- <td>
- <p align="center">
- false
- </p>
- </td>
- <td>
- <p align="center">
- -
- </p>
- </td>
- <td>
- <p align="center">
- -
- </p>
- </td>
- </tr>
- <tr>
- <td>
- <p align="center">
- false
- </p>
- </td>
- <td>
- <p align="center">
- true
- </p>
- </td>
- <td>
- <p align="center">
- -
- </p>
- </td>
- <td>
- <p align="center">
- -
- </p>
- </td>
- </tr>
- </tbody>
- </table>
- <br />
-</div>
-<p>
- The first three rows are identical to the first person's table. The last two differ only in that this version doesn't
- specify values that the first does. This amounts to an assumption about the way the code was written. The first assumed
- a complicated boolean expression:
-</p>
-<blockquote>
-<pre>
-if (appearsInFirst &amp;&amp; appearsInSecond &amp;&amp;
- (inLowerLevel || !excluded)) {
- add to list
-}
-</pre>
-</blockquote>
-<p>
- The second assumes nested boolean expressions:
-</p>
-<blockquote>
-<pre>
-if (appearsInFirst &amp;&amp; appearsInSecond) {
- // found match.
- if (inTopLevel &amp;&amp; excluded) {
-// filter it
- }
-}
-</pre>
-</blockquote>
-<p>
- The difference between the two is that the test ideas for the first detect two faults that the ideas for the second do
- not, because those faults don't apply.
-</p>
-<ol>
- <li>
- In the first implementation, there can be a misparenthesization fault. Are the parentheses around the <font
- size="+0">||</font> correct or incorrect? Since the second implementation has no <font size="+0">||</font> and no
- parentheses, the fault cannot exist.
- </li>
- <li>
- The test requirements for the first implementation check whether the second <font size="+0">&amp;&amp;</font>
- should be an <font size="+0">||</font>. In the second implementation, that explicit <font
- size="+0">&amp;&amp;</font> is replaced by the implicit <font size="+0">&amp;&amp;</font> of the nested <font
- size="+0">if</font> statements. There's no <font size="+0">||</font>-for-<font size="+0">&amp;&amp;</font> fault,
- per se. (It might be the case that the nesting is incorrect, but this technique does not address that.)<br />
- </li>
-</ol></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/guidelines/test_ideas_for_method_calls.xmi b/XP/xp/guidances/guidelines/test_ideas_for_method_calls.xmi
deleted file mode 100644
index a02f9fd..0000000
--- a/XP/xp/guidances/guidelines/test_ideas_for_method_calls.xmi
+++ /dev/null
@@ -1,582 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-nwZMQTZtIwI5weh9c_HoYA" name="test_ideas_for_method_calls,8.5657170364036E-306" guid="-nwZMQTZtIwI5weh9c_HoYA" changeDate="2006-11-21T15:58:59.045-0800" version="1.0.0">
- <mainDescription><a id="XE_test__developer_testing__test_ideas__for_method_calls"
-name="XE_test__developer_testing__test_ideas__for_method_calls"></a><a
-id="XE_design__developer_testing__test_ideas__for_method_calls"
-name="XE_design__developer_testing__test_ideas__for_method_calls"></a><a id="XE_test-ideas__for_method_calls"
-name="XE_test-ideas__for_method_calls"></a>
-<h3>
- <a id="Introduction" name="Introduction">Introduction</a>
-</h3>
-<p>
- Here's an example of defective code:
-</p>
-<blockquote>
-<pre>
-File file = new File(stringName);
-file.delete();
-</pre>
-</blockquote>
-<p>
- The defect is that <font size="+0">File.delete</font> can fail, but the code doesn't check for that. Fixing it requires
- the addition of the italicized code shown here:
-</p>
-<blockquote>
-<pre>
-File file = new File(stringName);
-<font color="#ff0000"><i><b>if (</b></i></font>file.delete()<font color="#ff0000"><i><b>== false) {...}</b></i></font>
-</pre>
-</blockquote>
-<p>
- This guideline describes a method for detecting cases where your code does not handle the result of calling a method.
- (Note that it assumes that the method called produces the correct result for whatever inputs you give it. That's
- something that should be tested, but creating test ideas for the called method is a separate activity. That is, it's
- not your job to test <font size="+0">File.delete</font>.)
-</p>
-<p>
- The key notion is that you should create a test idea for each <i>distinct unhandled relevant result</i> of a method
- call. To define that term, let's first look at <i>result</i>. When a method executes, it changes the state of the
- world. Here are some examples:
-</p>
-<ul>
- <li>
- It might push return values on the runtime stack.
- </li>
- <li>
- It might throw an exception.
- </li>
- <li>
- It might change a global variable.
- </li>
- <li>
- It might update a record in a database.
- </li>
- <li>
- It might send data over the network.
- </li>
- <li>
- It might print a message to standard output.
- </li>
-</ul>
-<p>
- Now let's look at <i>relevant</i>, again using some examples.
-</p>
-<ul>
- <li>
- Suppose the method being called prints a message to standard output. That "changes the state of the world", but it
- cannot affect the further processing of this program. No matter what gets printed, even nothing at all, it can't
- affect the execution of your code.
- </li>
- <li>
- If the method returns true for success and false for failure, your program very likely should branch based on the
- result. So that return value is relevant.
- </li>
- <li>
- If the called method updates a database record that your code later reads and uses, the result (updating the
- record) is relevant.
- </li>
-</ul>
-<p>
- (There's no absolute line between relevant and irrelevant. By calling <font size="+0">print</font>, your method might
- cause buffers to be allocated, and that allocation might be relevant after <font size="+0">print</font> returns. It's
- conceivable that a defect might depend on whether and what buffers were allocated. It's conceivable, but is it at all
- plausible?)
-</p>
-<p>
- A method might often have a very large number of results, but only some of them will be <i>distinct</i>. For example,
- consider a method that writes bytes to disk. It might return a number less than zero to indicate failure; otherwise, it
- returns the number of bytes written (which might be fewer than the number requested). The large number of possibilities
- can be grouped into three distinct results:
-</p>
-<ul>
- <li>
- a number less than zero.
- </li>
- <li>
- the number written equals the number requested
- </li>
- <li>
- some bytes were written, but less than the number requested.
- </li>
-</ul>
-<p>
- All the values less than zero are grouped into one result because no reasonable program will make a distinction among
- them. All of them (if, indeed, more than one is possible) should be treated as an error. Similarly, if the code
- requested that 500 bytes be written, it doesn't matter if 34 were actually written or 340: the same thing will probably
- be done with the unwritten bytes. (If something different should be done for some value, such as 0, that will form a
- new distinct result.)
-</p>
-<p>
- There's one last word in the defining term to explain. This particular testing technique is not concerned with distinct
- results that are already <i>handled</i>. Consider, again, this code:
-</p>
-<blockquote>
-<pre>
-File file = new File(stringName);
-if (file.delete() == false) {...}
-</pre>
-</blockquote>
-<p>
- There are two distinct results (true and false). The code handles them. It might handle them incorrectly, but test
- ideas from <a class="elementLinkWithType"
- href="./../../../xp/guidances/guidelines/test_ideas_for_booleans_and_boundaries,1.7150344523489172E-305.html"
- guid="1.7150344523489172E-305">Guideline: Test Ideas for Booleans and Boundaries</a> will check that. This test
- technique is concerned with distinct results that are not specifically handled by distinct code. That might happen for
- two reasons: you thought the distinction was irrelevant, or you simply overlooked it. Here's an example of the first
- case:
-</p>
-<blockquote>
-<pre>
-result = m.method();
-switch (result) {
- case FAIL:
- case CRASH:
- ...
- break;
- case DEFER:
- ...
- break;
- default:
- ...
- break;
-}
-</pre>
-</blockquote>
-<p>
- <font size="+0">FAIL</font> and <font size="+0">CRASH</font> are handled by the same code. It might be wise to check
- that that's really appropriate. Here's an example of an overlooked distinction:
-</p>
-<blockquote>
-<pre>
-result = s.shutdown();
-if (result == PANIC) {
- ...
-} else {
- // success! Shut down the reactor.
- ...
-}
-</pre>
-</blockquote>
-<p>
- It turns out that shutdown can return an additional distinct result: <font size="+0">RETRY</font>. The code as written
- treats that case the same as the success case, which is almost certainly wrong.
-</p>
-<h3>
- <a id="FindingTestIdeas" name="FindingTestIdeas">Finding test ideas</a>
-</h3>
-<p>
- So your goal is to think of those distinct relevant results you previously overlooked. That seems impossible: why would
- you realize they're relevant now if you didn't earlier?
-</p>
-<p>
- The answer is that a systematic re-examination of your code, when in a testing frame of mind and not a programming
- frame of mind, can sometimes cause you to think new thoughts. You <i>can</i> question your own assumptions by
- methodically stepping through your code, looking at the methods you call, rechecking their documentation, and thinking.
- Here are some cases to watch for.
-</p>
-<h4>
- "Impossible" cases
-</h4>
-<p>
- Often, it will appear that error returns are impossible. Doublecheck your assumptions.
-</p>
-<p>
- This example shows a Java implementation of a common Unix idiom for handling temporary files.
-</p>
-<blockquote>
-<pre>
-File file = new File("tempfile");
-FileOutputStream s;
-try {
- // open the temp file.
- s = new FileOutputStream(file);
-} catch (IOException e) {...}
-// Make sure temp file will be deleted
-file.delete();
-</pre>
-</blockquote>
-<p>
- The goal is to make sure that a temporary file is always deleted, no matter how the program exits. You do this by
- creating the temporary file, then immediately deleting it. On Unix, you can continue to work with the deleted file, and
- the operating system takes care of cleaning up when the process exits. A not-painstaking Unix programmer might not
- write the code to check for a failed deletion. Since she just successfully created the file, she must be able to delete
- it.
-</p>
-<p>
- This trick doesn't work on Windows. The deletion will fail because the file is open. Discovering that fact is hard: as
- of August 2000, the Java documentation did not enumerate the situations in which <font size="+0">delete</font> could
- fail; it merely says that it can. But-perhaps-when in "testing mode", the programmer might question her assumption.
- Since her code is supposed to be "write once, run everywhere", she might ask a Windows programmer when <font
- size="+0">File.delete</font> fails on Windows and so discover the awful truth.
-</p>
-<h4>
- "Irrelevant" cases
-</h4>
-<p>
- Another force against noticing a distinct relevant value is being already convinced that it doesn't matter. A Java
- <font size="+0">Comparator</font>'s <font size="+0">compare</font> method returns either a number &lt;0, 0, or a number
- &gt;0. Those are three distinct cases that might be tried. This code lumps two of them together:
-</p>
-<blockquote>
-<pre>
-void allCheck(Comparator c) {
- ...
- if (c.compare(o1, o2) &lt;= 0) {
- ...
- } else {
- ...
- }
-</pre>
-</blockquote>
-<p>
- But that might be wrong. The way to discover whether it is or not is to try the two cases separately, even if you
- really believe it will make no difference. (Your beliefs are really what you're testing.) Note that you might be
- executing the <font size="+0">then</font> case of the <font size="+0">if</font> statement more than once for other
- reasons. Why not try one of them with the result less than 0 and one with the result exactly equal to zero?
-</p>
-<h4>
- Uncaught exceptions
-</h4>
-<p>
- Exceptions are a kind of distinct result. By way of background, consider this code:
-</p>
-<blockquote>
-<pre>
-void process(Reader r) {
- ...
- try {
- ...
- int c = r.read();
- ...
- } catch (IOException e) {
- ...
- }
-}
-</pre>
-</blockquote>
-<p>
- You'd expect to check whether the handler code really does the right thing with a read failure. But suppose an
- exception is explicitly unhandled. Instead, it's allowed to propagate upward through the code under test. In Java, that
- might look like this:
-</p>
-<blockquote>
-<pre>
-void process(Reader r) <font color="#ff0000"><i><b>throws IOException</b></i></font> {
- ...
- int c = r.read();
- ...
-}
-</pre>
-</blockquote>
-<p>
- This technique asks you to test that case <i>even though</i> the code explicitly doesn't handle it. Why? Because of
- this kind of fault:
-</p>
-<blockquote>
-<pre>
-void process(Reader r) throws IOException {
- ...
- <font color="#ff0000"><i><b>Tracker.hold(this);</b></i></font>
- ...
- int c = r.read();
- ...
- <font color="#ff0000"><i><b>Tracker.release(this);</b></i></font>
- ...
-}
-</pre>
-</blockquote>
-<p>
- Here, the code affects global state (through <font size="+0">Tracker.hold</font>). If the exception is thrown, <font
- size="+0">Tracker.release</font> will never be called.
-</p>
-<p>
- (Notice that the failure to release will probably have no obvious immediate consequences. The problem will most likely
- not be visible until <font size="+0">process</font> is called again, whereupon the attempt to <font
- size="+0">hold</font> the object for a second time will fail. A good article about such defects is Keith Stobie's <a
- href="http://www.testingcraft.com/stobie-exceptions.pdf" target="_blank">"Testing for Exceptions"</a>. &nbsp; (<a
- href="http://www.adobe.com/products/acrobat/alternate.html" target="_blank">Get Adobe Reader</a>))
-</p>
-<h3>
- <a id="UndiscoveredFaults" name="UndiscoveredFaults">Undiscovered faults</a>
-</h3>
-<p>
- This particular technique does not address all defects associated with method calls. Here are two kinds that it's
- unlikely to catch.
-</p>
-<h4>
- Incorrect arguments
-</h4>
-<p>
- Consider these two lines of C code, where the first line is wrong and the second line is correct.
-</p>
-<blockquote>
-<pre>
-... strncmp(s1, s2, strlen(s1)) ...
-... strncmp(s1, s2, strlen(<font color="#ff0000"><i><b>s2</b></i></font>)) ...
-</pre>
-</blockquote>
-<p>
- <font size="+0">strncmp</font> compares two strings and returns a number less than 0 if the first one is
- lexicographically less than the second (would come earlier in a dictionary), 0 if they're equal, and a number greater
- than 0 if the first one is lexicographically larger. However, it only compares the number of characters given by the
- third argument. The problem is that the length of the first string is used to limit the comparison, whereas it should
- be the length of the second.
-</p>
-<p>
- This technique would require three tests, one for each distinct return value. Here are three you could use:
-</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 scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
- s1
- </th>
- <th scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
- s2
- </th>
- <th scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
- expected result
- </th>
- <th scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
- actual result
- </th>
- </tr>
- <tr>
- <td align="middle" width="25%">
- "a"
- </td>
- <td align="middle" width="25%">
- "bbb"
- </td>
- <td align="middle" width="25%">
- &lt;0
- </td>
- <td align="middle" width="25%">
- &lt;0
- </td>
- </tr>
- <tr>
- <td align="middle" width="25%">
- "bbb"
- </td>
- <td align="middle" width="25%">
- "a"
- </td>
- <td align="middle" width="25%">
- &gt;0
- </td>
- <td align="middle" width="25%">
- &gt;0
- </td>
- </tr>
- <tr>
- <td align="middle" width="25%">
- "foo"
- </td>
- <td align="middle" width="25%">
- "foo"
- </td>
- <td align="middle" width="25%">
- =0
- </td>
- <td align="middle" width="25%">
- =0
- </td>
- </tr>
- </tbody>
- </table>
- <br />
-</div>
-<p>
- The defect is not discovered because nothing in this technique <i>forces</i> the third argument to have any particular
- value. What's needed is a test case like this:
-</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 scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
- <b>s1</b>
- </th>
- <th scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
- <b>s2</b>
- </th>
- <th scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
- <b>expected result</b>
- </th>
- <th scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
- <b>actual result</b>
- </th>
- </tr>
- <tr>
- <td align="middle" width="25%">
- "foo"
- </td>
- <td align="middle" width="25%">
- "foo<font color="#ff0000"><i><b>d</b></i></font>"
- </td>
- <td align="middle" width="25%">
- <font color="#ff0000"><i><b>&lt;0</b></i></font>
- </td>
- <td align="middle" width="25%">
- =0
- </td>
- </tr>
- </tbody>
- </table>
- <br />
-</div>
-<p>
- While there are techniques suitable for catching such defects, they are seldom used in practice. Your testing effort is
- probably better spent on a rich set of tests that targets many types of defects (and that you hope catches this type as
- a side effect).
-</p>
-<h4>
- Indistinct results
-</h4>
-<p>
- There's a danger that comes when you're coding - and testing - method-by-method. Here's an example. There are two
- methods. The first, <font size="+0">connect</font>, wants to establish a network connection:
-</p>
-<blockquote>
-<pre>
-void connect() {
- ...
- Integer portNumber = serverPortFromUser();
- if (portNumber == null) {
- // pop up message about invalid port number
- return;
- }
-</pre>
-</blockquote>
-<p>
- It calls <font size="+0">serverPortFromUser</font> to get a port number. That method returns two distinct values. It
- returns a port number chosen by the user if the number chosen is valid (1000 or greater). Otherwise, it returns null.
- If null is returned, the code under test pops up an error message and quits.
-</p>
-<p>
- When <font size="+0">connect</font> was tested, it worked as intended: a valid port number caused a connection to be
- established, and an invalid one led to a popup.
-</p>
-<p>
- The code to <font size="+0">serverPortFromUser</font> is a bit more complicated. It first pops up a window that asks
- for a string and has the standard OK and CANCEL buttons. Based on what the user does, there are four cases:
-</p>
-<ol>
- <li>
- If the user types a valid number, that number is returned.
- </li>
- <li>
- If the number is too small (less than 1000), null is returned (so the message about invalid port number will be
- displayed).
- </li>
- <li>
- If the number is misformatted, null is again returned (and the same message is appropriate).
- </li>
- <li>
- If the user clicks CANCEL, null is returned.
- </li>
-</ol>
-<p>
- This code also works as intended.
-</p>
-<p>
- The combination of the two chunks of code, though, has a bad consequence: the user presses CANCEL and gets a message
- about an invalid port number. All the code works as intended, but the overall effect is still wrong. It was tested in a
- reasonable way, but a defect was missed.
-</p>
-<p>
- The problem here is that <font size="+0">null</font> is one result that represents two distinct <i>meanings</i> ("bad
- value" and "user cancelled"). Nothing in this technique forces you to notice that problem with the design of <font
- size="+0">serverPortFromUser</font>.
-</p>
-<p>
- Testing can help, though. When <font size="+0">serverPortFromUser</font> is tested in isolation - just to see if it
- returns the intended value in each of those four cases - the context of use is lost. Instead, suppose it were tested
- via <font size="+0">connect</font>. There would be four tests that would exercise both of the methods simultaneously:
-</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 scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
- input
- </th>
- <th scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
- expected result
- </th>
- <th scope="col" align="middle" width="25%" bgcolor="#c0c0c0">
- thought process
- </th>
- </tr>
- <tr>
- <td align="middle" width="25%">
- user types "1000"
- </td>
- <td align="middle" width="25%">
- connection to port 1000 is opened
- </td>
- <td align="middle" width="25%">
- <font size="+0">serverPortFromUser</font> returns a number, which is used.
- </td>
- </tr>
- <tr>
- <td>
- <p align="center">
- user types "999"
- </p>
- </td>
- <td>
- <p align="center">
- popup about invalid port number
- </p>
- </td>
- <td>
- <p align="center">
- <font size="+0">serverPortFromUser</font> returns null, which leads to popup
- </p>
- </td>
- </tr>
- <tr>
- <td align="middle" width="25%">
- <p align="center">
- user types "i99"
- </p>
- </td>
- <td align="middle" width="25%">
- popup about invalid port number
- </td>
- <td align="middle" width="25%">
- <font size="+0">serverPortFromUser</font> returns null, which leads to popup
- </td>
- </tr>
- <tr>
- <td align="middle" width="25%">
- users clicks CANCEL
- </td>
- <td align="middle" width="25%">
- whole connection process should be cancelled
- </td>
- <td align="middle" width="25%">
- <font size="+0"><i>serverPortFromUser</i></font> <i>returns null, hey wait a minute that doesn't make
- sense...</i>
- </td>
- </tr>
- </tbody>
- </table>
- <br />
-</div>
-<p>
- As is often the case, testing in a larger context reveals integration problems that escape small-scale testing. And, as
- is also often the case, careful thought during test design reveals the problem before the test is run. (But if the
- defect isn't caught then, it will be caught when the test is run.)<br />
- <br />
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/guidelines/test_ideas_for_statechart_and_flow_diagrams.xmi b/XP/xp/guidances/guidelines/test_ideas_for_statechart_and_flow_diagrams.xmi
deleted file mode 100644
index 68d4dbf..0000000
--- a/XP/xp/guidances/guidelines/test_ideas_for_statechart_and_flow_diagrams.xmi
+++ /dev/null
@@ -1,250 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-60dp5lxFJEpUarhchGCnHw" name="test_ideas_for_statechart_and_flow_diagrams,1.0347051690476123E-305" guid="-60dp5lxFJEpUarhchGCnHw" version="1.0.0">
- <mainDescription><a id="XE_state_machine__test_ideas_for" name="XE_state_machine__test_ideas_for"></a><a
-id="XE_test_idea__for_state_machine" name="XE_test_idea__for_state_machine"></a>
-<h3>
- <a id="Introduction" name="Introduction">Introduction</a>
-</h3>
-<p>
- This guideline shows how to identify <a class="elementLinkWithUserText"
- href="./../../../xp/guidances/concepts/test-ideas_list,8.834380241450745E-306.html#TestIdeas"
- guid="8.834380241450745E-306">test ideas</a> from statecharts and other design structures that consist mainly of nodes
- connected by arcs and that show something of the possible control flows of a program. The main goal of this testing is
- to traverse every arc in some test. If you've never exercised an arc, why do you think it will work when a customer
- does?
-</p>
-<h3>
- <a id="Implementation" name="Implementation">Testing the Implementation</a>
-</h3>
-<p>
- Consider this statechart:
-</p>
-<p align="center">
- <img height="253" alt="" src="resources/tstfrsdsg-img3.gif" width="567" />
-</p>
-<p class="picturetext">
- Fig1: HVAC Statechart
-</p>
-<p>
- Here's a first list of test ideas:
-</p>
-<ul>
- <li>
- Idle state receives Too Hot event
- </li>
- <li>
- Idle state receives Too Cool event
- </li>
- <li>
- Cooling/Startup state receives Compressor Running event
- </li>
- <li>
- Cooling/Ready state receives Fan Running event
- </li>
- <li>
- Cooling/Running state receives OK event
- </li>
- <li>
- Cooling/Running state receives Failure event
- </li>
- <li>
- Failure state receives Failure Cleared event
- </li>
- <li>
- Heating state receives OK event
- </li>
- <li>
- Heating state receives Failure event
- </li>
-</ul>
-<p>
- These test ideas could all be exercised in a single test, or you could create several tests that each exercise a few.
- As with all test design, strive for a balance between the ease of implementation of many simple tests and the
- additional defect-finding power of complex tests. (See <a class="elementLinkWithUserText"
- href="./../../../xp/guidances/concepts/test-ideas_list,8.834380241450745E-306.html#TestDesignUsingTheList"
- guid="8.834380241450745E-306">"test design using the list"</a> in the <a class="elementLinkWithUserText"
- href="./../../../xp/guidances/concepts/test-ideas_list,8.834380241450745E-306.html"
- guid="8.834380241450745E-306">Concept: Test Ideas List</a> page.) If you have use case scenarios that describe certain
- paths through the statechart, you should favor tests that take those paths.
-</p>
-<p>
- In any case, the tests should check that all actions required by the statechart actually take place. For example, is
- the alarm started on entry to the Failure state, then stopped upon exit?
-</p>
-<p>
- The test should also check that the transition leads to the correct next state. That can be a difficult problem when
- the states are invisible from the outside. The only way to detect an incorrect state is to inject some sequence of
- events that leads to incorrect output. More precisely, you would need to construct a follow-on sequence of events whose
- externally-visible results for the <i>correct</i> state differ from those that the same sequence would provoke from
- each possible <i>incorrect</i> state.
-</p>
-<p>
- In the example above, how would you know that the Failure Cleared event in the Failure state correctly led to the Idle
- state, instead of staying in the Failure state? You might trust that the stopping of the Alarm meant that transition
- had been made, but it might be better to check by lowering the temperature enough to make the heater start or raising
- it enough to turn on cooling. If something happens, you're more confident that the transition was correct. If nothing
- happens, it's likely the device stayed in the Failure state.
-</p>
-<p>
- At the very least, determining whether the resulting state is correct complicates test design. It is often better to
- make the state machine explicit and make its states visible to the tests.
-</p>
-<h4>
- Other statechart constructs
-</h4>
-<p>
- Statecharts consist of more than arcs and arrows. Here is a list of statechart constructs and the effect they have on
- the test idea list.
-</p>
-<h5>
- Event actions, entry actions, and exit actions
-</h5>
-<p>
- These do not generate test ideas per se. Rather, the tests should check that the actions behave as specified. If the
- actions represent substantial programs, those programs must be tested. The test ideas for the programs might be
- combined with test ideas from the statechart, but it's probably more manageable to separate them. Make the decision
- based on the effort involved and on your suspicion that there might be interactions between events. That is, if a
- particular action on one arc cannot possibly share data with an action on another arc, there is no reason to exercise
- the two actions in the same test (as you would if they were part of the same path through a statechart test).
-</p>
-<h5>
- Guard conditions
-</h5>
-<p>
- Guard conditions are boolean expressions. The test ideas for guard conditions are derived as described in <a
- class="elementLinkWithType"
- href="./../../../xp/guidances/guidelines/test_ideas_for_booleans_and_boundaries,1.7150344523489172E-305.html"
- guid="1.7150344523489172E-305">Guideline: Test Ideas for Booleans and Boundaries</a>.
-</p>
-<p>
- In the example above, the Too Cool transition from the Idle state is guarded with [restart time &gt;= 5 mins]. That
- leads to two separate test ideas:
-</p>
-<ul>
- <li>
- Idle state receives Too Cool event when restart time is five minutes (transition taken)
- </li>
- <li>
- Idle state receives Too Cool event when restart time is just less than five minutes (transition blocked)
- </li>
-</ul>
-<p>
- In both cases, any test that uses the test idea should check that the correct state is reached.
-</p>
-<h5>
- Internal transitions
-</h5>
-<p>
- An internal transition adds the same sort of ideas to a test idea list as an external transition does. It's merely that
- the next state is the same as the original state. It would be prudent to set up the test such that the state's entry
- and exit actions would cause an observable effect if they were incorrectly triggered.
-</p>
-<h5>
- Nested states
-</h5>
-<p>
- When constructing tests, set them up such that entry and exit events of the composite state have observable effects.
- You want to notice if they're skipped.
-</p>
-<h5>
- Concurrent substates
-</h5>
-<p>
- Testing of concurrency falls outside of the scope of developer testing.
-</p>
-<h5>
- Deferred events
-</h5>
-<p>
- If you suspect an event might be handled differently depending on whether it was deferred and queued rather than
- generated while the program was actually in the receiving state, you might test those two cases.
-</p>
-<p>
- If the event in the receiving state has a guard condition, consider the ramifications of changes to the condition's
- variables between the time the event is generated and the time it is received.
-</p>
-<p>
- If more than one state can handle a deferred event, consider testing deferral to each of the possible receiving states.
- Perhaps the implementation assumes that the "obvious" state will handle the event.
-</p>
-<h5>
- History states
-</h5>
-<p>
- Here is an example of a history state:
-</p>
-<p align="center">
- <img height="211" alt="" src="resources/md_state3.gif" width="412" />
-</p>
-<p class="picturetext">
- Fig2: History State Example
-</p>
-<p>
- The transition into the history state represents three real transitions, and thus three test ideas:
-</p>
-<ul>
- <li>
- BackupUp event in Command state leads to Collecting state
- </li>
- <li>
- BackupUp event in Command state leads to Copying state
- </li>
- <li>
- BackupUp event in Command state leads to CleaningUp state
- </li>
-</ul>
-<h5>
- Chain states
-</h5>
-<p>
- Chain states do not seem to have any implications for test design, except that they introduce more actions that need to
- be checked.
-</p>
-<h3>
- <a id="Design" name="Design">Testing the Design</a>
-</h3>
-<p>
- The preceding discussion focuses on checking whether the implementation matches the design. But the design might also
- be wrong. While examining the design to find test ideas, also check for two types of problems:
-</p>
-<p>
- <b>Missing events.</b> The statechart shows a state's response to events <i>that the designer anticipated could arrive
- in that state</i>. It's not unknown for designers to overlook events. For example, in this statechart (repeated from
- the top of the page), perhaps the designer forgot that a failure can occur in the Ready substate of Cooling, not just
- when the fan is Running.
-</p>
-<p align="center">
- <img height="253" alt="" src="resources/tstfrsdsg-img3.gif" width="567" />
-</p>
-<p class="picturetext">
- Fig3: HVAC Statechart
-</p>
-<p>
- For this reason, it's wise to ask, for each state, whether any of the events that apply to other states might apply to
- this one. If you discover that one does, correct your design.
-</p>
-<p>
- <b>Incomplete or missing guard conditions.</b> Similarly, perhaps guard conditions on one transition will suggest guard
- conditions on others. For example, the above statechart takes care not to restart the heater too often, but there is no
- such restriction on the cooling system. Should there be?
-</p>
-<p>
- It is also possible that variables used on one guard condition will suggest that other guard conditions are too simple.
-</p>
-<h3>
- <a id="Interactions" name="Interactions">Testing Interactions</a>
-</h3>
-<p>
- Testing each arc in a graph is by no means complete testing. For example, suppose the start state initializes a
- variable to 0, state Setter sets it to 5, and state Divider divides it into 100 (100/variable). If there's a path from
- the start state to Divider that does not pass through Setter, you have a divide-by-zero exception. If the statechart
- has many states, simply exercising each arc might miss that path.
-</p>
-<p>
- Except for very simple statecharts, testing every path is infeasible. In practice, tests that are complex and
- correspond to use case scenarios are often sufficient. If you desire stronger tests, consider requiring a path from
- each state where a datum is given a value to each state that uses it.
-</p>
-<br />
-<br /></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/guidelines/xp_environment.xmi b/XP/xp/guidances/guidelines/xp_environment.xmi
deleted file mode 100644
index f7d9236..0000000
--- a/XP/xp/guidances/guidelines/xp_environment.xmi
+++ /dev/null
@@ -1,114 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-OuWRQbxXBGWox8SgcCr6sQ" name="xp_environment,3.754748120034442E-307" guid="-OuWRQbxXBGWox8SgcCr6sQ" changeDate="2005-12-06T04:25:25.664-0800">
- <mainDescription><a id="XE_xp__environment" name="XE_xp__environment"></a><a id="XE_environment__in_xp" name="XE_environment__in_xp"></a>
-<p>
- No process is an island. In other words, you can't expect to just take a process or process elements off a shelf and
- use them without regard to their context.
-</p>
-<p>
- XP has certain key requirements of the "environment"; the physical, organizational, and business setting where it will
- be applied.
-</p>
-<h3>
- Topics
-</h3>
-<ul>
- <li>
- <a href="#Physical">Physical Requirements</a>
- <ul>
- <li>
- <a href="#OpenWorkspace">Open Workspace</a>
- </li>
- <li>
- <a href="#Toolset">Uniform Toolset</a>
- </li>
- <li>
- <a href="#BuildMachine">Dedicated Build Machine</a>
- </li>
- <li>
- <a href="#VersionControl">Version Control Tool</a>
- </li>
- </ul>
- </li>
- <li>
- <a href="#Org">Organizational Requirements</a>
- </li>
- <li>
- <a href="#Business">Business Requirements</a>
- </li>
-</ul>
-<h3>
- <a id="Physical" name="Physical">Physical Requirements</a>
-</h3>
-<h4>
- <a id="OpenWorkspace" name="OpenWorkspace">Open Workspace</a>
-</h4>
-<p>
- One key aspect of XP is a strong focus on communication. To communicate effectively, a team should have as few physical
- barriers to each other as possible. The ideal XP programming environment is an open workspace filled with tables and
- room for pairs of people to work together and maintain contact with their peers. For more details, see the <a
- class="elementLinkWithUserText" href="./../../../myxp/guidances/guidelines/open_workspace,3.269440809144354E-305.html"
- guid="3.269440809144354E-305">open workspace guideline</a>.
-</p>
-<h4>
- <a id="Toolset" name="Toolset">Uniform Toolset</a>
-</h4>
-<p>
- XP works best when there are no artificial impediments to getting and giving help. If you have an open workspace with
- five computers for production coding and each of them has a wildly different set of tools, some people will gravitate
- to the machines that have the tools they like and feel uncomfortable moving to the machines that have unfamiliar tools.
- Think about your own experiences. Do you feel hindered working in an unfamiliar IDE? How much does that impede you when
- someone asks for your help. If, as a team, you adopt a uniform set of tools and keep your development machines
- homogenous, you are making it far easier for people to give and receive help.
-</p>
-<h4>
- <a id="BuildMachine" name="BuildMachine">Dedicated Build Machine</a>
-</h4>
-<p>
- In XP, there are many different ways to do builds. However, the primary constraint is that all unit tests are run prior
- to checking in any production code. In most situations, the easiest way to accomplish this is to have a dedicated build
- machine. You can check in your code and trigger a build across the network or walk to the build machine and run the
- build. Either way, having a dedicated machine gives you the advantage of having a common, pristine environment for your
- builds.
-</p>
-<h4>
- <a id="VersionControl" name="VersionControl">Version Control Tool</a>
-</h4>
-<p>
- All software projects need version control tools; however, in XP we place a premium upon their usability. The ability
- to be able to check out code without locking it is also valued. When a team writes pervasive unit tests and practices
- collective code ownership, locking code for revision is often too pessimistic. It creates unncessary bottlenecks.
-</p>
-<h3>
- <a id="Org" name="Org">Organizational Requirements</a>
-</h3>
-<p>
- Organizations adopting XP should be able to dedicate someone to act as the customer for each XP team. The customer role
- in XP is critical. If the person who is acting as the customer has other responsibilities, it is best if those
- responsibilities are subordinate to being available to the rest of the team.
-</p>
-<p>
- In addition to having an available customer, organizations practicing XP should allow teams to be self-sufficient. In
- organizations where many functions are supported by different groups (configuration management group, deployment group,
- QA), the different functions can impede development if there are not mechanisms to allow each team to do what it takes
- to finalize its iterations without waiting for other teams.
-</p>
-<h3>
- <a id="Business" name="Business">Business Requirements</a>
-</h3>
-<p>
- XP works best in situations where organizations can take advantage of variable scope. If a business creates a fixed
- scope contract with a fixed end date, it can be hard to discern how long it really takes for a team to sustainably
- develop good software.
-</p>
-<p>
- People in the organizations look at the schedule rather than the velocity data that XP produces. The result is all too
- predictable. Software may be delivered on time, but it may also be buggy and a poor platform for future development. In
- XP, we recognize that each team has a particular speed at which they can reliably develop software. That speed varies
- from team to team. If a team is pushed faster than that speed, the results are often disasterous.
-</p>
-<p>
- <br />
- <br />
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/practices/sustainable_pace.xmi b/XP/xp/guidances/practices/sustainable_pace.xmi
deleted file mode 100644
index d1d5b93..0000000
--- a/XP/xp/guidances/practices/sustainable_pace.xmi
+++ /dev/null
@@ -1,40 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-AS84xtg2NOXfrqA6eVRzMQ" name="new_practice,_ycm9gGZBEdqvwYzpSSc2Nw" guid="-AS84xtg2NOXfrqA6eVRzMQ" changeDate="2005-12-06T02:20:39.800-0800">
- <mainDescription><h3>
- Description
-</h3>
-<p>
- The assumption in XP is that software development is not a sprint but a marathon. While a sprinter will easily beat a
- marathon runner over a very short distance, the marathon runner will always win in the long run. Consistently working
- overtime will destroy the team, the design, and eventually the product. It creates an environment that makes it
- impossible to do high quality work. People make more mistakes because they are tired (not to mention their low morale),
- causing bugs that require a lot of time to fix down the line. The end result is that it slows everything and everyone
- down.
-</p>
-<p>
- Continuous overtime can be a symptom of a deeper problem that is not being addressed. Perhaps the process is too broken
- to be fixed by working more. The rule in XP is that, if the team has to do more than one consecutive week of overtime,
- it should reassess the situation and start rethinking the plan. Overtime is OK if you need to get to the end of an
- iteration or a release, but it should always be an exception rather than the rule.
-</p>
-<p>
- Sustainable pace is about fostering a team that can produce a consistent amount of work over a long period of time.
-</p>
-<h3>
- Benefits
-</h3>
-<ul>
- <li>
- <b>Improved predictability</b>: plans become more accurate.
- </li>
- <li>
- <b>Improved product quality</b>: programmers have the time to do the right thing.
- </li>
- <li>
- <b>Improved job satisfaction</b>: programmers can enjoy their work with as little stress as possible.
- </li>
- <li>
- <b>Reduced time to market</b>: less time required to fix bad code and rotting design.
- </li>
-</ul></mainDescription>
-</org.eclipse.epf.uma:PracticeDescription>
diff --git a/XP/xp/guidances/supportingmaterials/getting_started_with_xp.xmi b/XP/xp/guidances/supportingmaterials/getting_started_with_xp.xmi
deleted file mode 100644
index 0b79c1e..0000000
--- a/XP/xp/guidances/supportingmaterials/getting_started_with_xp.xmi
+++ /dev/null
@@ -1,65 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-PCk5_o83KYiPZaKUzt021A" name="getting_started_with_xp,1.2284921351651456E-304" guid="-PCk5_o83KYiPZaKUzt021A" changeDate="2006-11-08T15:14:04.387-0800" version="1.0.0">
- <mainDescription><a id="XE_xp__getting started_with" name="XE_xp__getting started_with"></a><a id="XE_getting started__with_xp"
-name="XE_getting started__with_xp"></a>
-<h3>
- Topics
-</h3>
-<ul>
- <li>
- <a href="#WhatisXP">What is XP?</a>
- </li>
- <li>
- <a href="#Start">Where do I start?</a>
- </li>
- <li>
- <a href="#Providing">Providing Feedback</a>
- </li>
-</ul>
-<h3>
- <a id="WhatisXP" name="WhatisXP">What is XP?</a>
-</h3>
-<p>
- Extreme Programming or XP is a development process that can be used by small to medium sized teams to develop high
- quality software within a predictable schedule and budget and with a minimum of overhead. XP is currently one of the
- most widely used agile processes in the industry.
-</p>
-<h3>
- <a id="Start" name="Start">Where do I start?</a>
-</h3>
-<p>
- If you are unfamiliar with XP and want to learn more about it, we suggest you take the following steps:
-</p>
-<ul>
- <li>
- Get a quick <a class="elementLinkWithUserText"
- href="./../../../xp/guidances/concepts/what_is_xp,9.251272550276345E-306.html"
- guid="9.251272550276345E-306">overview of XP</a>.
- </li>
- <li>
- Learn what the <a class="elementLinkWithUserText"
- href="./../../../xp/guidances/concepts/motivation,1.6390805262958034E-306.html"
- guid="1.6390805262958034E-306">motivation behind XP</a> is.
- </li>
- <li>
- Understand what <a class="elementLink"
- href="./../../../xp/guidances/concepts/agile_software_development,1.041091673844025E-305.html"
- guid="1.041091673844025E-305">Agile Software Development</a> means.
- </li>
- <li>
- Take a tour of the <a class="elementLink"
- href="./../../../xp/guidances/concepts/xp_values,1.076140803519123E-306.html" guid="1.076140803519123E-306">XP
- Values</a> and <a class="elementLink"
- href="./../../../xp/guidances/concepts/xp_practices,2.2937799026801584E-305.html" guid="2.2937799026801584E-305">XP
- Practices</a>.
- </li>
-</ul>
-<h3>
- <a id="Providing" name="Providing">Providing Feedback</a>
-</h3>
-<p>
- As this is the first version of the XP plug-in, we are looking to the community for advice on how to make&nbsp;it
- better. You can help us do this by sending us your suggestions, comments, or questions to the discussions lists (see <a
- href="http://www.eclipse.org/epf">www.eclipse.org/epf</a> for more information).
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/supportingmaterials/resources/.cvsignore b/XP/xp/guidances/supportingmaterials/resources/.cvsignore
deleted file mode 100644
index 085e8ba..0000000
--- a/XP/xp/guidances/supportingmaterials/resources/.cvsignore
+++ /dev/null
@@ -1 +0,0 @@
-Thumbs.db
diff --git a/XP/xp/guidances/supportingmaterials/resources/CRsym_obj.gif b/XP/xp/guidances/supportingmaterials/resources/CRsym_obj.gif
deleted file mode 100644
index d1f6a31..0000000
--- a/XP/xp/guidances/supportingmaterials/resources/CRsym_obj.gif
+++ /dev/null
Binary files differ
diff --git a/XP/xp/guidances/supportingmaterials/xp_and_agile_process_references.xmi b/XP/xp/guidances/supportingmaterials/xp_and_agile_process_references.xmi
deleted file mode 100644
index ead1c07..0000000
--- a/XP/xp/guidances/supportingmaterials/xp_and_agile_process_references.xmi
+++ /dev/null
@@ -1,227 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-8UKMv929ysWDBF1IOAAgsg" name="xp_and_agile_process_references,6.191633934532389E-306" guid="-8UKMv929ysWDBF1IOAAgsg" changeDate="2006-11-29T16:47:27.124-0800" version="1.0.0">
- <mainDescription><a id="XE_references__xp_bibliography_of" name="XE_references__xp_bibliography_of"></a>
-<div align="center">
- <br />
-
- <table width="100%" border="0">
- <tbody>
- <tr>
- <td valign="top" width="12%">
- <a id="AUE01" name="AUE01">AUE01</a>
- </td>
- <td colspan="2">
- Ken Auer et al. 2001. <i>Extreme Programming Applied: Playing to Win.</i> Addison-Wesley Publishing
- Co.&nbsp;
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Experiences from pioneers in applying XP.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="BEC00" name="BEC00">BEC00</a>
- </td>
- <td colspan="2">
- Kent Beck 2000. <i>Extreme Programming Explained</i> Addison-Wesley Publishing Co.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Good introduction to the fundamental ideas of XP.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="BEC01" name="BEC01">BEC01</a>
- </td>
- <td colspan="2">
- Kent Beck, Martin Fowler 2001. <i>Planning Extreme Programming</i> Addison-Wesley Publishing Co.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Explains how to plan and manage an XP project.
- </td>
- </tr>
- </tbody>
- <tbody>
- <tr>
- <td valign="top" width="12%">
- <a id="COC01" name="COC01">COC01</a>
- </td>
- <td colspan="2">
- Alistair Cockburn 2001. <i>Agile Software Development</i> Addison-Wesley Publishing Co.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Peers into the team dynamics, the cultures, the communications aspects of software development.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="FOW99" name="FOW99">FOW99</a>
- </td>
- <td colspan="2">
- Martin Fowler et al. 1999. <i>Refactoring: Improving the Design of Existing Code</i> Addison-Wesley
- Publishing Co.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="JEF01" name="JEF01">JEF01</a>
- </td>
- <td colspan="2">
- Ron Jeffries, Ann Anderson, and Chet Hendrickson 2001. <i>Extreme Programming Installed.</i>
- Addison-Wesley.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- This book describes practical Extreme Programming techniques.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="KER01" name="KER01">KER01</a>
- </td>
- <td colspan="2">
- Norman L. Kerth, April 2001. <i>Project Retrospectives: A Handbook for Team Reviews.</i> Dorset
- House.&nbsp;
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- "Presents a convincing argument for the value of taking the time to study past projects and learn from
- them [...] Kerth's sensitivity to the complex interpersonal issues surrounding project retrospectives
- will help any facilitator, participant, or manager get the most out of these important learning
- activities." Karl E. Wiegers, February 8, 2003.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="KRO03" name="KRO03">KRO03</a>
- </td>
- <td colspan="2">
- Per Kroll and Philippe Kruchten 2003. <i>The Rational Unified Process Made Easy, A Practitioners Guide
- to the RUP.</i> Addison Wesley Longman.&nbsp;
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- A practical guide to adopting the spirit, principles and practices of the RUP. An invaluable resource
- in helping you decide how to apply the RUP in your organization or project.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="NEW01" name="NEW01">NEW01</a>
- </td>
- <td colspan="2">
- James Newkirk and Robert Martin 2001. <i>Extreme Programming in Practice.</i> Addison-Wesley Publishing
- Co.&nbsp;
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- A report of experience using XP on a web project.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="SUC01" name="SUC01">SUC01</a>
- </td>
- <td colspan="2">
- Giancarlo Succi, Michele Marchesi 2001. <i>Extreme Programming Examined.</i> Addison-Wesley Publishing
- Co.&nbsp;
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- A collection of papers covering a wide variety of topics related to XP.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- <a id="WAK01" name="WAK01">WAK01</a>
- </td>
- <td colspan="2">
- William Wake 2001. <i>Extreme Programming Explored.</i> Addison-Wesley Publishing Co.&nbsp;
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- Based on the popular XPlorations website. Specific subjects are explored in detail.
- </td>
- </tr>
- <tr>
- <td valign="top" width="12%">
- </td>
- <td width="10%">
- </td>
- <td style="PADDING-BOTTOM: 10px" width="78%">
- </td>
- </tr>
- </tbody>
- </table>
-</div></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/supportingmaterials/xp_artifacts.xmi b/XP/xp/guidances/supportingmaterials/xp_artifacts.xmi
deleted file mode 100644
index f7bff54..0000000
--- a/XP/xp/guidances/supportingmaterials/xp_artifacts.xmi
+++ /dev/null
@@ -1,69 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-O3LVBobhzFRt-5bytDkqqQ" name="xp_artifacts,1.545655831828372E-305" guid="-O3LVBobhzFRt-5bytDkqqQ" changeDate="2006-11-29T16:45:12.644-0800" version="1.0.0">
- <mainDescription><a id="XE_artifact__overview_of_all_xp_artifacts" name="XE_artifact__overview_of_all_xp_artifacts"></a>
-<p>
- In the spirit of simplicity, one of the basic <a class="elementLink"
- href="./../../../xp/guidances/concepts/xp_values,1.076140803519123E-306.html" guid="1.076140803519123E-306">XP
- Values</a>, the number of artifacts in XP is fairly small. Actually, in XP we don't really talk about artifacts as
- such. Except for the production code, all other artifacts generated by the process imply work that is tangential to
- getting to the end goal, a running product. In theory, everything else should be considered as optional. The set of
- artifacts presented&nbsp;here is commonly used by XP teams to deliver software in an efficient manner. As a rule, try
- to limit the amount of effort put on any tangential work unless it can be proved to improve the process in some
- demonstrable way.
-</p>
-<p>
- The XP artifacts are:
-</p>
-<ul>
- <li>
- <a class="elementLinkWithUserText"
- href="./../../../xp/workproducts/xp_vision,{2300FB25-7249-4481-A1BD-978240906832}.html"
- guid="{2300FB25-7249-4481-A1BD-978240906832}">Vision</a>
- </li>
- <li>
- <a class="elementLinkWithUserText"
- href="./../../../xp/workproducts/xp_user_story,{21946731-4F5C-4862-8B4D-868629952B92}.html"
- guid="{21946731-4F5C-4862-8B4D-868629952B92}">User Story</a>
- </li>
- <li>
- <a class="elementLinkWithUserText"
- href="./../../../xp/workproducts/xp_customer_test,{DF0EDBC7-4AAD-438D-89AA-64ECFE2416F5}.html"
- guid="{DF0EDBC7-4AAD-438D-89AA-64ECFE2416F5}">Customer Test</a>
- </li>
- <li>
- <a class="elementLinkWithUserText"
- href="./../../../xp/workproducts/xp_release_plan,{CA77FBD2-04DD-4010-B2AA-03E1E7C66B0B}.html"
- guid="{CA77FBD2-04DD-4010-B2AA-03E1E7C66B0B}">Release Plan</a>
- </li>
- <li>
- <a class="elementLinkWithUserText"
- href="./../../../xp/workproducts/xp_metaphor,{7C34EE96-C3EA-49FD-A53C-7C113B86AE01}.html"
- guid="{7C34EE96-C3EA-49FD-A53C-7C113B86AE01}">Metaphor (System of Names)</a>
- </li>
- <li>
- <a class="elementLinkWithUserText"
- href="./../../../xp/workproducts/xp_iteration_plan,{DC18E34B-70C1-403D-84CC-1BF117A7473D}.html"
- guid="{DC18E34B-70C1-403D-84CC-1BF117A7473D}">Iteration Plan</a>
- </li>
- <li>
- <a class="elementLinkWithUserText"
- href="./../../../xp/workproducts/xp_coding_standard,{1D7E042C-B29E-4169-8DF3-37DE0A5F64ED}.html"
- guid="{1D7E042C-B29E-4169-8DF3-37DE0A5F64ED}">Coding Standard</a>
- </li>
- <li>
- <a class="elementLinkWithUserText"
- href="./../../../xp/workproducts/xp_unit_test,{D156652E-7C52-4EBD-8F23-F38169877A57}.html"
- guid="{D156652E-7C52-4EBD-8F23-F38169877A57}">Unit Test</a>
- </li>
- <li>
- <a class="elementLinkWithUserText"
- href="./../../../xp/workproducts/xp_production_code,{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1}.html"
- guid="{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1}">Production Code</a>
- </li>
- <li>
- <a class="elementLinkWithUserText"
- href="./../../../xp/workproducts/xp_build,{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222}.html"
- guid="{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222}">Build</a>
- </li>
-</ul></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/supportingmaterials/xp_copyright.xmi b/XP/xp/guidances/supportingmaterials/xp_copyright.xmi
deleted file mode 100644
index c9c9c7e..0000000
--- a/XP/xp/guidances/supportingmaterials/xp_copyright.xmi
+++ /dev/null
@@ -1,8 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-31JQsY6FjFegmq-JJZdndg" name=",_XI5PQHEPEdug-a-RuUM3Hg" guid="-31JQsY6FjFegmq-JJZdndg" changeDate="2006-11-10T15:05:13.550-0800">
- <mainDescription>Copyright (c) 2002, 2006 IBM Corporation and Object Mentor. All rights reserved. <br />
-This program and the accompanying materials are made available under the terms of the Eclipse Public License v1.0 which
-accompanies this distribution, and is available at <a href="http://www.eclipse.org/legal/epl-v10.html"
-target="_blank">http://www.eclipse.org/legal/epl-v10.html</a>. <br />
-Contributors: IBM Corporation and Object Mentor - initial implementation<br /></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/supportingmaterials/xp_customer_team.xmi b/XP/xp/guidances/supportingmaterials/xp_customer_team.xmi
deleted file mode 100644
index 01bcd67..0000000
--- a/XP/xp/guidances/supportingmaterials/xp_customer_team.xmi
+++ /dev/null
@@ -1,16 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-mZMamrTcnR6xoZgvw9XU-A" name="xp_customer_team,2.9889538140050517E-306" guid="-mZMamrTcnR6xoZgvw9XU-A" changeDate="2005-12-06T02:43:10.832-0800">
- <mainDescription><p>
- The customer team provides the requirements, sets the priorities and steers the project. The customer team can be made
- up of one or more business representatives from different parts of the organization. If there is more than one
- representative, it is important that the customer team speak to the developers in one voice ("The Customer") in order
- to keep communication focused. It is best if the customer team includes a real end user who knows the domain and what
- is needed. There may be a manager, providing resources, handling external communication and coordinating activities.
- The team may include testers, who help the customer define the customer acceptance tests. Analysts may also help to
- define the requirements.
-</p>
-<p>
- <br />
- <br />
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/supportingmaterials/xp_developer_team.xmi b/XP/xp/guidances/supportingmaterials/xp_developer_team.xmi
deleted file mode 100644
index dc97e3c..0000000
--- a/XP/xp/guidances/supportingmaterials/xp_developer_team.xmi
+++ /dev/null
@@ -1,11 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-_11Y5NHJcC5lkqB4CeSpbg" name="xp_developer_team,8.608243854485154E-306" guid="-_11Y5NHJcC5lkqB4CeSpbg" changeDate="2005-12-06T02:43:06.686-0800">
- <mainDescription><p>
- The developer team writes the software that will meet the customer's needs. The team consists of programmers, and
- commonly a coach, who helps the team stay on track and facilitates the process.
-</p>
-<p>
- <br />
- <br />
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/supportingmaterials/xp_organization.xmi b/XP/xp/guidances/supportingmaterials/xp_organization.xmi
deleted file mode 100644
index a8a5898..0000000
--- a/XP/xp/guidances/supportingmaterials/xp_organization.xmi
+++ /dev/null
@@ -1,26 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-2nINowSo0VedqZTd4LIZIg" name="xp_organization,5.613949040902463E-308" guid="-2nINowSo0VedqZTd4LIZIg" changeDate="2005-12-06T03:12:10.223-0800">
- <mainDescription><p>
- On all but the smallest of projects, the people involved in a software project will be part of one or more entities
- (businesses, functional groups, governments, communities, etc.). The <a class="elementLink"
- href="./../../../myxp/guidances/concepts/xp_practices,2.2937799026801584E-305.html" guid="2.2937799026801584E-305">XP
- Practices</a> focus on the roles directly involved in identifying what the software needs to do (<a class="elementLink"
- href="./../../../myxp/guidances/supportingmaterials/xp_customer_team,2.9889538140050517E-306.html"
- guid="2.9889538140050517E-306">XP Customer Team</a>) and developing that software (<a class="elementLink"
- href="./../../../myxp/guidances/supportingmaterials/xp_developer_team,8.608243854485154E-306.html"
- guid="8.608243854485154E-306">XP Developer Team</a>). To support those teams, the <a class="elementLink"
- href="./../../../myxp/guidances/concepts/whole_team,7.89591827591278E-306.html" guid="7.89591827591278E-306">Whole
- Team</a> includes a third important group, the XP Organization.
-</p>
-<p>
- The specific roles that XP identifies as part of the XP Organization are the XP Tracker and the XP Coach. The XP
- Organization also includes all of the people who make up the infrastructure that allows the project to exist. This
- includes management, accounting, support, facilities, etc. Because these are supporting roles, XP attempts to minimize
- the dependence of the XP Customer Team and the XP Developer Team on the XP Organization. In XP, the goal is for the
- whole team to be self-managing and largely self-supporting. XP does not give specific practice guidance to these other
- roles, but does suggest that these roles also guide their practices with the <a class="elementLink"
- href="./../../../myxp/guidances/concepts/xp_values,1.076140803519123E-306.html" guid="1.076140803519123E-306">XP
- Values</a> of communication, simplicity, feedback, and courage.
-</p>
-<br /></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/whitepapers/refactoring.xmi b/XP/xp/guidances/whitepapers/refactoring.xmi
deleted file mode 100644
index c3268ae..0000000
--- a/XP/xp/guidances/whitepapers/refactoring.xmi
+++ /dev/null
@@ -1,25 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-ql_2w28A9SIIZQca3Wg-kQ" name="refactoring,1.0713784560673905E-305" guid="-ql_2w28A9SIIZQca3Wg-kQ" changeDate="2006-11-10T15:40:03.134-0800" version="1.0.0">
- <mainDescription><address>
- By&nbsp;Michael Feathers.
-</address>
-<address>
- All Rights Reserved.
-</address>
-<p>
- A&nbsp;<a href="resources/refactoring.pdf" target="_blank">PDFversion</a> of this article is available; however, you
- must have <a href="http://www.adobe.com/products/acrobat/alternate.html" target="_blank">Adobe Acrobat</a> installed to
- view it.
-</p>
-<h3>
- Abstract
-</h3>
-<p>
- This paper addresses refactoring from the context of starting with legacy code, as opposed to so called "green field"
- development. Topics covered include: Test Coverings; Inflection Points; Breaking External and Internal Dependencies.
-</p>
-<p>
- <br />
- &nbsp;
-</p></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/whitepapers/resources/refactoring.pdf b/XP/xp/guidances/whitepapers/resources/refactoring.pdf
deleted file mode 100644
index a627aed..0000000
--- a/XP/xp/guidances/whitepapers/resources/refactoring.pdf
+++ /dev/null
Binary files differ
diff --git a/XP/xp/guidances/whitepapers/resources/xppair.pdf b/XP/xp/guidances/whitepapers/resources/xppair.pdf
deleted file mode 100644
index fe0eb9f..0000000
--- a/XP/xp/guidances/whitepapers/resources/xppair.pdf
+++ /dev/null
Binary files differ
diff --git a/XP/xp/guidances/whitepapers/resources/xprefact.pdf b/XP/xp/guidances/whitepapers/resources/xprefact.pdf
deleted file mode 100644
index 187c9b1..0000000
--- a/XP/xp/guidances/whitepapers/resources/xprefact.pdf
+++ /dev/null
Binary files differ
diff --git a/XP/xp/guidances/whitepapers/xp_guidelines_pair_programming.xmi b/XP/xp/guidances/whitepapers/xp_guidelines_pair_programming.xmi
deleted file mode 100644
index 94ce18c..0000000
--- a/XP/xp/guidances/whitepapers/xp_guidelines_pair_programming.xmi
+++ /dev/null
@@ -1,24 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-Ymu8T1hQ_QoxCaNAQhD9AA" name="rup_xp_guidelines_pair_programming,7.290386721197834E-306" guid="-Ymu8T1hQ_QoxCaNAQhD9AA" changeDate="2006-11-29T15:10:56.067-0800" version="1.0.0">
- <mainDescription><a id="XE_XP__Pair_Programming" name="XE_XP__Pair_Programming"></a>
-<address>
- By Robert C. Martin<br />
- Object Mentor, Inc.<br />
- <a href="http://www.objectmentor.com" target="_blank">www.objectmentor.com</a>
-</address>
-All Rights Reserved.&nbsp;
-<p>
- A <a href="resources/xppair.pdf" target="_blank">PDF version</a> of this article is available, however, you must have
- <a href="http://www.adobe.com/products/acrobat/alternate.html" target="_blank">Adobe Acrobat</a> installed to view it.
-</p>
-<h3>
- Abstract
-</h3>
-<p>
- Pair programming is a well-tested, well accepted alternative to code reviews. More than that, it's a fundamentally
- different way to write software. The benefits go far beyond productivity and quality, and affect such things as the
- robustness and morale of the team.
-</p>
-<br />
-<br /></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/guidances/whitepapers/xp_guidelines_test-first_design_and_refactoring.xmi b/XP/xp/guidances/whitepapers/xp_guidelines_test-first_design_and_refactoring.xmi
deleted file mode 100644
index 866b1c2..0000000
--- a/XP/xp/guidances/whitepapers/xp_guidelines_test-first_design_and_refactoring.xmi
+++ /dev/null
@@ -1,26 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-_AgYWcSlbVBZOVcQfJuBnQ" name="xp_guidelines_test-first_design_and_refactoring,6.334658646686929E-306" guid="-_AgYWcSlbVBZOVcQfJuBnQ" changeDate="2006-11-29T15:11:30.669-0800" version="1.0.0">
- <mainDescription><a id="XE_XP__Test-first_Design_and_Refactoring" name="XE_XP__Test-first_Design_and_Refactoring"></a>
-<address>
- By Robert C. Martin<br />
- Object Mentor, Inc.<br />
- <a href="http://www.objectmentor.com" target="_blank">www.objectmentor.com</a>
-</address>
-<p>
- All Rights Reserved.
-</p>
-<p>
- A <a href="resources/xprefact.pdf" target="_blank">PDF version</a> of this article is available, however, you must have
- <a href="http://www.adobe.com/products/acrobat/alternate.html" target="_blank">Adobe Acrobat</a> installed to view it.
-</p>
-<h3>
- Abstract&nbsp;
-</h3>
-<p>
- This paper demonstrates the techniques of refactoring in the presence of test-first design and conveys a programming
- attitude. A program is not done when it works; a program is done when it works <i>and</i> when it's as simple and clean
- as possible.
-</p>
-<br />
-<br /></mainDescription>
-</org.eclipse.epf.uma:ContentDescription>
diff --git a/XP/xp/plugin.xmi b/XP/xp/plugin.xmi
deleted file mode 100644
index afc849c..0000000
--- a/XP/xp/plugin.xmi
+++ /dev/null
@@ -1,451 +0,0 @@
-<?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.3/uma.ecore" xmlns:org.eclipse.epf.uma.resourcemanager="http:///org/eclipse/epf/uma/resourcemanager.ecore" epf:version="1.0.0">
- <org.eclipse.epf.uma.resourcemanager:ResourceManager xmi:id="_TOlmEGMyEdqsrK7eslBiiA" guid="_TOlmEGMyEdqsrK7eslBiiA">
- <resourceDescriptors xmi:id="_TOlmEWMyEdqsrK7eslBiiA" id="-MqIvi7DInwjz8kX7QEyU3g" uri="customcategories/getting_started.xmi"/>
- <resourceDescriptors xmi:id="_TPioUGMyEdqsrK7eslBiiA" id="-hZ1cvRhigpDb6WbQckPWcA" uri="customcategories/key_xp_concepts.xmi"/>
- <resourceDescriptors xmi:id="_TPou8GMyEdqsrK7eslBiiA" id="-LVHbtWMGC3pAL9abD018MA" uri="customcategories/xp_best_practices.xmi"/>
- <resourceDescriptors xmi:id="_TQBJcGMyEdqsrK7eslBiiA" id="-QcM1bn-XJLcMSggRp54YlQ" uri="customcategories/conceptual_road_maps.xmi"/>
- <resourceDescriptors xmi:id="_TQHQEGMyEdqsrK7eslBiiA" id="-8FSBtYSGN9EGWRr1N6fbPQ" uri="customcategories/guidelines_overview.xmi"/>
- <resourceDescriptors xmi:id="_TQNWsGMyEdqsrK7eslBiiA" id="-_GqtAEsGnq12qQmyqWdHHQ" uri="customcategories/xp_white_papers.xmi"/>
- <resourceDescriptors xmi:id="_TQNWsWMyEdqsrK7eslBiiA" id="-a8huB5Sn0Qjfe-SkZubH1w" uri="customcategories/references.xmi"/>
- <resourceDescriptors xmi:id="_Teo0QGMyEdqsrK7eslBiiA" id="-c5D4uYtVcDvab8GzkO0HiQ" uri="customcategories/xp_roles_and_tasks.xmi"/>
- <resourceDescriptors xmi:id="_TgcyIGMyEdqsrK7eslBiiA" id="-W67fNE0rT1c2PM-20yXbrw" uri="tasks/develop_xp_vision.xmi"/>
- <resourceDescriptors xmi:id="_Tgo_YGMyEdqsrK7eslBiiA" id="-ZUxMgSWqLlaO5p1r1-ug6Q" uri="workproducts/xp_vision.xmi"/>
- <resourceDescriptors xmi:id="_TgvGAGMyEdqsrK7eslBiiA" id="-U8NScY6mORb4XPcNZ_mrEA" uri="guidances/concepts/refactoring_xp_programming.xmi"/>
- <resourceDescriptors xmi:id="_Tg1MoGMyEdqsrK7eslBiiA" id="--qg2qc3dqmgeB63Nx7Zndg" uri="guidances/concepts/coding_standard.xmi"/>
- <resourceDescriptors xmi:id="_Tg7TQGMyEdqsrK7eslBiiA" id="-n52TyFa7Reb3LOJV1JMpvg" uri="guidances/concepts/pair_programming.xmi"/>
- <resourceDescriptors xmi:id="_ThBZ4GMyEdqsrK7eslBiiA" id="-ql_2w28A9SIIZQca3Wg-kQ" uri="guidances/whitepapers/refactoring.xmi"/>
- <resourceDescriptors xmi:id="_Th-cIGMyEdqsrK7eslBiiA" id="-qIbMRqe8wqKN2-HLtNUcLw" uri="tasks/define_coding_standard.xmi"/>
- <resourceDescriptors xmi:id="_Th-cIWMyEdqsrK7eslBiiA" id="-9EbmL3qGJ_TemB83cJublQ" uri="tasks/estimate_task.xmi"/>
- <resourceDescriptors xmi:id="_TiEiwGMyEdqsrK7eslBiiA" id="-DbsgXRUjLhsnnpioGI2b3g" uri="tasks/implement_spike.xmi"/>
- <resourceDescriptors xmi:id="_TiQwAGMyEdqsrK7eslBiiA" id="-IoT5LZUu3vnNFp-pwPUMHA" uri="tasks/refactor_code.xmi"/>
- <resourceDescriptors xmi:id="_TiW2oGMyEdqsrK7eslBiiA" id="-dbA7zKOJY5WPZyLXErA9vw" uri="guidances/guidelines/refactoring.xmi"/>
- <resourceDescriptors xmi:id="_Ti1XwGMyEdqsrK7eslBiiA" id="-nfbUMyTTqEbCp3HDn-NjOA" uri="guidances/guidelines/pair_programming.xmi"/>
- <resourceDescriptors xmi:id="_TjHroGMyEdqsrK7eslBiiA" id="-NznKylxa2Y_MG8lACUV9Bw" uri="workproducts/xp_coding_standard.xmi"/>
- <resourceDescriptors xmi:id="_TjNyQGMyEdqsrK7eslBiiA" id="-HkQclhewSbkFSomo1l_LBg" uri="guidances/examples/test-ideas_catalog_examples.xmi"/>
- <resourceDescriptors xmi:id="_TjT44GMyEdqsrK7eslBiiA" id="-0rSxLFlmQfyKrgnqi1NKrg" uri="guidances/concepts/simple_design.xmi"/>
- <resourceDescriptors xmi:id="_TjZ_gGMyEdqsrK7eslBiiA" id="-2OU2wQP_WNWX5zzWzx4ANw" uri="guidances/concepts/metaphor_system_of_names.xmi"/>
- <resourceDescriptors xmi:id="_TjgGIGMyEdqsrK7eslBiiA" id="-umDp1nFYrMetgnJ-kUMhHw" uri="tasks/breakdown_story.xmi"/>
- <resourceDescriptors xmi:id="_Tj-nQGMyEdqsrK7eslBiiA" id="-Z9xFd9JTnJuNN5S27p06UQ" uri="tasks/estimate_user_story.xmi"/>
- <resourceDescriptors xmi:id="_TkEt4GMyEdqsrK7eslBiiA" id="-sQUFozEqR3Gpa5PnCjFh9Q" uri="workproducts/xp_metaphor.xmi"/>
- <resourceDescriptors xmi:id="_TkK0gGMyEdqsrK7eslBiiA" id="-35rZhRLEVuTVI4280ncN0A" uri="guidances/concepts/continuous_integration.xmi"/>
- <resourceDescriptors xmi:id="_TkQ7IGMyEdqsrK7eslBiiA" id="--tP2hgRfEkZPGYvy1y0GZQ" uri="tasks/integrate_system.xmi"/>
- <resourceDescriptors xmi:id="_TkXBwGMyEdqsrK7eslBiiA" id="-rphHqeONv59sqZq_6FzE6Q" uri="workproducts/xp_build.xmi"/>
- <resourceDescriptors xmi:id="_TkdIYGMyEdqsrK7eslBiiA" id="-oW2j2l-rXqHeWPIgjPpbng" uri="guidances/concepts/customer_tests.xmi"/>
- <resourceDescriptors xmi:id="_TkjPAGMyEdqsrK7eslBiiA" id="-nGaswirSOYturOoUWwGdRw" uri="guidances/concepts/product_quality.xmi"/>
- <resourceDescriptors xmi:id="_TkpVoGMyEdqsrK7eslBiiA" id="-3i1jvKMUGGmAYPw4dHFbEg" uri="guidances/concepts/test-ideas_list.xmi"/>
- <resourceDescriptors xmi:id="_Tk7pgGMyEdqsrK7eslBiiA" id="-WgE0oiE2yddCOMnfzL25Gw" uri="tasks/define_customer_test.xmi"/>
- <resourceDescriptors xmi:id="_TlCXMGMyEdqsrK7eslBiiA" id="-c7t_eJuo1g5hpWTYTCItig" uri="guidances/guidelines/equivalence_class_analysis.xmi"/>
- <resourceDescriptors xmi:id="_TlOkcGMyEdqsrK7eslBiiA" id="-p0GGwGNG5O8Dn6O6ZzivIw" uri="tasks/report_acceptance_test_result.xmi"/>
- <resourceDescriptors xmi:id="_TlUrEGMyEdqsrK7eslBiiA" id="-KfsuH9i0hVMlGV7PVIa3FQ" uri="roles/xp_tester.xmi"/>
- <resourceDescriptors xmi:id="_TokMUGMyEdqsrK7eslBiiA" id="-fm-gBePbdl_WMsE5NxEreQ" uri="tasks/automate_acceptance_test.xmi"/>
- <resourceDescriptors xmi:id="_ToqS8GMyEdqsrK7eslBiiA" id="-6RyabSc-ZUEtoEKb90BCbg" uri="tasks/run_acceptance_test.xmi"/>
- <resourceDescriptors xmi:id="_TowZkGMyEdqsrK7eslBiiA" id="-OPKuXnenD910fJyGKA99aw" uri="tasks/setup_tester_environment.xmi"/>
- <resourceDescriptors xmi:id="_To2gMGMyEdqsrK7eslBiiA" id="-YYMUwBepQ28JU78LtraO3w" uri="workproducts/xp_customer_test.xmi"/>
- <resourceDescriptors xmi:id="_To8m0GMyEdqsrK7eslBiiA" id="-gAMIwaLmqX7bf6GLCqwB-g" uri="roles/xp_coach.xmi"/>
- <resourceDescriptors xmi:id="_TpCtcGMyEdqsrK7eslBiiA" id="-DoLoZOTPa_LacQ3jUG_lsg" uri="guidances/concepts/xp_sustainable_pace.xmi"/>
- <resourceDescriptors xmi:id="_TpI0EGMyEdqsrK7eslBiiA" id="-u-Svthjtn1xLK2IwVUpk5Q" uri="tasks/adapt_and_improve_process.xmi"/>
- <resourceDescriptors xmi:id="_TpO6sGMyEdqsrK7eslBiiA" id="-I3yOxhkbTu3OCbzQ0sUsyA" uri="tasks/explain_process.xmi"/>
- <resourceDescriptors xmi:id="_TpVBUGMyEdqsrK7eslBiiA" id="-32JWpciwfc2e7HgQavJDkw" uri="tasks/improve_team_skills.xmi"/>
- <resourceDescriptors xmi:id="_TpbH8GMyEdqsrK7eslBiiA" id="-SH3UFVsPViLT3hOalbaxgA" uri="tasks/keep_process_on_track.xmi"/>
- <resourceDescriptors xmi:id="_TphOkGMyEdqsrK7eslBiiA" id="-L85wOCiwe2O8D8CISEGGGg" uri="tasks/resolve_conflicts.xmi"/>
- <resourceDescriptors xmi:id="_TpnVMGMyEdqsrK7eslBiiA" id="-FIhk4OEzZl2IAVMXurpBLA" uri="roles/xp_tracker.xmi"/>
- <resourceDescriptors xmi:id="_Tptb0GMyEdqsrK7eslBiiA" id="-FxF90KOknQ5km30pP0038w" uri="tasks/track_story_completion.xmi"/>
- <resourceDescriptors xmi:id="_TpzicGMyEdqsrK7eslBiiA" id="-0iRnQW0M9QDTNqWNijBB5A" uri="tasks/track_task_completion.xmi"/>
- <resourceDescriptors xmi:id="_Tp5pEGMyEdqsrK7eslBiiA" id="-vcCn_ksJo5Jw27aNZb1Cvw" uri="guidances/concepts/small_releases.xmi"/>
- <resourceDescriptors xmi:id="_Tp_vsGMyEdqsrK7eslBiiA" id="-7gEOFFavlkSqwIoTNrvfJA" uri="tasks/define_release_plan.xmi"/>
- <resourceDescriptors xmi:id="_TqF2UGMyEdqsrK7eslBiiA" id="-85F1Tegv16godTFTKyPdww" uri="guidances/guidelines/planning_game.xmi"/>
- <resourceDescriptors xmi:id="_TqSDkGMyEdqsrK7eslBiiA" id="-WOPGmKUuYbvVeVHp0sgEgw" uri="tasks/report_project_status.xmi"/>
- <resourceDescriptors xmi:id="_TqYKMGMyEdqsrK7eslBiiA" id="-cU3MzukpGPAtw0wSS23R-g" uri="tasks/update_iteration_plan.xmi"/>
- <resourceDescriptors xmi:id="_TqeQ0GMyEdqsrK7eslBiiA" id="-YO16TebjP7U0gkcYg7OY_A" uri="tasks/update_release_plan.xmi"/>
- <resourceDescriptors xmi:id="_TqkXcGMyEdqsrK7eslBiiA" id="-mMZ9KUhiFwBbzSFjq_tO4A" uri="workproducts/xp_release_plan.xmi"/>
- <resourceDescriptors xmi:id="_TqqeEGMyEdqsrK7eslBiiA" id="-23MZj6vLVbgbkXaptH4riQ" uri="roles/xp_system_administrator.xmi"/>
- <resourceDescriptors xmi:id="_TqwksGMyEdqsrK7eslBiiA" id="-1rVEQRCvrcicCdhpuuIZ8w" uri="tasks/setup_programmer_environment.xmi"/>
- <resourceDescriptors xmi:id="_Tq8x8GMyEdqsrK7eslBiiA" id="-OuWRQbxXBGWox8SgcCr6sQ" uri="guidances/guidelines/xp_environment.xmi"/>
- <resourceDescriptors xmi:id="_TrC4kGMyEdqsrK7eslBiiA" id="-92rjXjWhll5LOtPc58YERg" uri="roles/xp_customer.xmi"/>
- <resourceDescriptors xmi:id="_TsAh4GMyEdqsrK7eslBiiA" id="-CPHs6R59_druVDY6nRjHEw" uri="guidances/concepts/planning_game.xmi"/>
- <resourceDescriptors xmi:id="_TsGogGMyEdqsrK7eslBiiA" id="-BWG5zUGb8c25kuLJ3ck8ng" uri="tasks/define_iteration_plan.xmi"/>
- <resourceDescriptors xmi:id="_TsMvIGMyEdqsrK7eslBiiA" id="-cqTu_uwmZrF3sFspx465XQ" uri="tasks/write_user_story.xmi"/>
- <resourceDescriptors xmi:id="_TsS1wGMyEdqsrK7eslBiiA" id="-45BLJONIjGn7h4z87VXqHQ" uri="workproducts/xp_iteration_plan.xmi"/>
- <resourceDescriptors xmi:id="_TslJoGMyEdqsrK7eslBiiA" id="-f1cDEBpC5wbDTQ9ru9UbLw" uri="workproducts/xp_production_code.xmi"/>
- <resourceDescriptors xmi:id="_TsrQQGMyEdqsrK7eslBiiA" id="-YP0i7TC6QNgemddcj1iE7g" uri="guidances/concepts/collective_ownership.xmi"/>
- <resourceDescriptors xmi:id="_TsxW4GMyEdqsrK7eslBiiA" id="-yaD6WKGdrZ0n0yBSpwPr4g" uri="guidances/concepts/test_driven_development.xmi"/>
- <resourceDescriptors xmi:id="_Ts3dgGMyEdqsrK7eslBiiA" id="-RoFHDUeLz4UFKDuFirQp3g" uri="roles/xp_programmer.xmi"/>
- <resourceDescriptors xmi:id="_Ts9kIGMyEdqsrK7eslBiiA" id="-aJBLg1aguP1bIWvQbJSd6w" uri="guidances/concepts/developer_testing.xmi"/>
- <resourceDescriptors xmi:id="_TtV-oGMyEdqsrK7eslBiiA" id="-3AbfvnHrCOIQS63sEjrOew" uri="guidances/concepts/test-first_design.xmi"/>
- <resourceDescriptors xmi:id="_TtiL4GMyEdqsrK7eslBiiA" id="-OrjIrRLW6v_XnqLUQ9GYaQ" uri="guidances/concepts/test-ideas_catalog.xmi"/>
- <resourceDescriptors xmi:id="_Tt6mYGMyEdqsrK7eslBiiA" id="-Ymu8T1hQ_QoxCaNAQhD9AA" uri="guidances/whitepapers/xp_guidelines_pair_programming.xmi"/>
- <resourceDescriptors xmi:id="_TuAtAGMyEdqsrK7eslBiiA" id="-_AgYWcSlbVBZOVcQfJuBnQ" uri="guidances/whitepapers/xp_guidelines_test-first_design_and_refactoring.xmi"/>
- <resourceDescriptors xmi:id="_TuGzoGMyEdqsrK7eslBiiA" id="-kNZQ2Mr_nyfmCboprjMNTg" uri="tasks/write_code.xmi"/>
- <resourceDescriptors xmi:id="_TuM6QGMyEdqsrK7eslBiiA" id="-jc10ie6UDWUJzSDfsQExjw" uri="guidances/guidelines/test_driven_development_tdd.xmi"/>
- <resourceDescriptors xmi:id="_TurbYGMyEdqsrK7eslBiiA" id="-nwZMQTZtIwI5weh9c_HoYA" uri="guidances/guidelines/test_ideas_for_method_calls.xmi"/>
- <resourceDescriptors xmi:id="_TvD14GMyEdqsrK7eslBiiA" id="-60dp5lxFJEpUarhchGCnHw" uri="guidances/guidelines/test_ideas_for_statechart_and_flow_diagrams.xmi"/>
- <resourceDescriptors xmi:id="_TvQDIGMyEdqsrK7eslBiiA" id="-FX8hDYUKOXsrQulFe9lwtw" uri="guidances/guidelines/test_ideas_for_booleans_and_boundaries.xmi"/>
- <resourceDescriptors xmi:id="_TxcbgGMyEdqsrK7eslBiiA" id="-rtY57MTVQrEcfTKwD3-Wvw" uri="workproducts/xp_user_story.xmi"/>
- <resourceDescriptors xmi:id="_TxiiIGMyEdqsrK7eslBiiA" id="-dwfXb2dWJOQkTuLo-BTFeQ" uri="workproducts/xp_unit_test.xmi"/>
- <resourceDescriptors xmi:id="_Tx68oGMyEdqsrK7eslBiiA" id="-PCk5_o83KYiPZaKUzt021A" uri="guidances/supportingmaterials/getting_started_with_xp.xmi"/>
- <resourceDescriptors xmi:id="_TyBDQGMyEdqsrK7eslBiiA" id="-nO38_JQ9G3FQvNlAT5Agqg" uri="guidances/concepts/what_is_xp.xmi"/>
- <resourceDescriptors xmi:id="_TyNQgGMyEdqsrK7eslBiiA" id="-nIpFvBhY9WogqrEQv4NknQ" uri="guidances/concepts/motivation.xmi"/>
- <resourceDescriptors xmi:id="_TyT-MGMyEdqsrK7eslBiiA" id="-EHSlFv7Gla5oCPGBiaZKow" uri="guidances/concepts/agile_software_development.xmi"/>
- <resourceDescriptors xmi:id="_TygLcGMyEdqsrK7eslBiiA" id="-pA6XLJKgRiwDTEp_qMlQ9g" uri="guidances/concepts/xp_values.xmi"/>
- <resourceDescriptors xmi:id="_TymSEGMyEdqsrK7eslBiiA" id="-24MPC2FhJbx7Fr0F6QEq8A" uri="guidances/concepts/xp_practices.xmi"/>
- <resourceDescriptors xmi:id="_TysYsGMyEdqsrK7eslBiiA" id="-vEvfeoyYAPDr-jfyX2QLww" uri="guidances/concepts/xp_rights.xmi"/>
- <resourceDescriptors xmi:id="_TzK50GMyEdqsrK7eslBiiA" id="-27sE-swoOUGtar9a0f3RPw" uri="guidances/concepts/extreme_programming.xmi"/>
- <resourceDescriptors xmi:id="_TzXHEGMyEdqsrK7eslBiiA" id="-mq7aEjHjqWoRd6aWFK_Dwg" uri="guidances/guidelines/open_workspace.xmi"/>
- <resourceDescriptors xmi:id="_TzdNsGMyEdqsrK7eslBiiA" id="-8UKMv929ysWDBF1IOAAgsg" uri="guidances/supportingmaterials/xp_and_agile_process_references.xmi"/>
- <resourceDescriptors xmi:id="_T0mdMGMyEdqsrK7eslBiiA" id="-_11Y5NHJcC5lkqB4CeSpbg" uri="guidances/supportingmaterials/xp_developer_team.xmi"/>
- <resourceDescriptors xmi:id="_T0sj0GMyEdqsrK7eslBiiA" id="-mZMamrTcnR6xoZgvw9XU-A" uri="guidances/supportingmaterials/xp_customer_team.xmi"/>
- <resourceDescriptors xmi:id="_T0yqcGMyEdqsrK7eslBiiA" id="-O3LVBobhzFRt-5bytDkqqQ" uri="guidances/supportingmaterials/xp_artifacts.xmi"/>
- <resourceDescriptors xmi:id="_GkS58GZBEdqvwYzpSSc2Nw" id="-uqrgrFY-74R1FijPLvcXoQ" uri="guidances/concepts/whole_team.xmi"/>
- <resourceDescriptors xmi:id="_MhXf4GZCEdqvwYzpSSc2Nw" id="-AS84xtg2NOXfrqA6eVRzMQ" uri="guidances/practices/sustainable_pace.xmi"/>
- <resourceDescriptors xmi:id="_7IA_sGZHEdqvwYzpSSc2Nw" id="-2nINowSo0VedqZTd4LIZIg" uri="guidances/supportingmaterials/xp_organization.xmi"/>
- <resourceDescriptors xmi:id="_-s6MEHEPEdug-a-RuUM3Hg" id="-31JQsY6FjFegmq-JJZdndg" uri="guidances/supportingmaterials/xp_copyright.xmi"/>
- </org.eclipse.epf.uma.resourcemanager:ResourceManager>
- <org.eclipse.epf.uma:MethodPlugin xmi:id="{35DCB3E1-2766-423E-A849-57ECD4F41A40}" name="xp" guid="{35DCB3E1-2766-423E-A849-57ECD4F41A40}" changeDate="2006-11-08T14:45:47.271-0800" copyrightStatement="_XI5PQHEPEdug-a-RuUM3Hg">
- <methodPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mhU6QGE-EdqnIZeW8YpHcA" name="Content" guid="_mhU6QGE-EdqnIZeW8YpHcA">
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mhU6QWE-EdqnIZeW8YpHcA" name="Categories" guid="_mhU6QWE-EdqnIZeW8YpHcA">
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mhU6QmE-EdqnIZeW8YpHcA" name="Domains" guid="_mhU6QmE-EdqnIZeW8YpHcA"/>
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mhU6Q2E-EdqnIZeW8YpHcA" name="Disciplines" guid="_mhU6Q2E-EdqnIZeW8YpHcA"/>
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mhU6RGE-EdqnIZeW8YpHcA" name="RoleSets" guid="_mhU6RGE-EdqnIZeW8YpHcA">
- <contentElements xsi:type="org.eclipse.epf.uma:RoleSet" xmi:id="_13azwGNdEdqsrK7eslBiiA" name="xp_roles" guid="_13azwGNdEdqsrK7eslBiiA" presentationName="XP Roles" roles="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6} {3C90DD4F-CFDB-4111-922D-3B840B8942DE} {08A6AF28-69B1-42DC-A957-2E6CDCB436C1} {0CB3C507-AFEE-4DA8-982B-9B93C8729910} {D8FE277E-4F9A-47EB-855F-C451D601BBAF} {FB65D00B-8304-4CF7-9969-52CE82F503DC}"/>
- </childPackages>
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mhU6RWE-EdqnIZeW8YpHcA" name="WP Types" guid="_mhU6RWE-EdqnIZeW8YpHcA"/>
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mhU6RmE-EdqnIZeW8YpHcA" name="Tools" guid="_mhU6RmE-EdqnIZeW8YpHcA"/>
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mhU6R2E-EdqnIZeW8YpHcA" name="StandardCategories" guid="_mhU6R2E-EdqnIZeW8YpHcA"/>
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mhU6SGE-EdqnIZeW8YpHcA" name="CustomCategories" guid="_mhU6SGE-EdqnIZeW8YpHcA" reusedPackages="_ms9igWE-EdqnIZeW8YpHcA _mhU6SGE-EdqnIZeW8YpHcA {45A887AB-A968-48AF-8213-4D470DA9DBCC} {90FB58E1-B403-4358-85D0-BD902528D810} {01E73AC7-B8D8-4B2F-8B29-A28D9813DB6C} {8367713C-3AEA-489D-B136-DB87D6340A3F} {DBE91BD5-0065-4049-AA61-058C77F1D2A3} {796EA4CB-0038-43B8-A568-792DCC3B9F22}">
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mhU6SWE-EdqnIZeW8YpHcA" name="Hidden" guid="_mhU6SWE-EdqnIZeW8YpHcA" reusedPackages="_mhU6SGE-EdqnIZeW8YpHcA">
- <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_mhU6SmE-EdqnIZeW8YpHcA" name="Custom Categories" guid="_mhU6SmE-EdqnIZeW8YpHcA" categorizedElements="_ms9ig2E-EdqnIZeW8YpHcA _mtDpJGE-EdqnIZeW8YpHcA _mtcqtmE-EdqnIZeW8YpHcA _mtcquWE-EdqnIZeW8YpHcA _um0n8GdjEdqlnYmIxoiUEQ _8NSdoGdjEdqlnYmIxoiUEQ"/>
- </childPackages>
- <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_ms9ig2E-EdqnIZeW8YpHcA" name="getting_started" guid="_ms9ig2E-EdqnIZeW8YpHcA" presentationName="Getting Started" variabilityType="replaces" categorizedElements="1.2284921351651456E-304 1.9093436569802954E-305 4.315031901943112E-306 2.0279775416255596E-305 6.505229665845286E-306 _8NSdoGdjEdqlnYmIxoiUEQ">
- <presentation xmi:id="-MqIvi7DInwjz8kX7QEyU3g" href="uma://-MqIvi7DInwjz8kX7QEyU3g#-MqIvi7DInwjz8kX7QEyU3g"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="1.9093436569802954E-305" name="key_xp_concepts" guid="1.9093436569802954E-305" briefDescription="The following concepts are a good starting point to introduce the "spirit" of XP." presentationName="Key XP Concepts" categorizedElements="9.251272550276345E-306 1.6390805262958034E-306 1.041091673844025E-305 1.076140803519123E-306 2.2937799026801584E-305 3.036332011267074E-306">
- <presentation xmi:id="-hZ1cvRhigpDb6WbQckPWcA" href="uma://-hZ1cvRhigpDb6WbQckPWcA#-hZ1cvRhigpDb6WbQckPWcA"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="4.315031901943112E-306" name="xp_best_practices" guid="4.315031901943112E-306" presentationName="XP Best Practices" categorizedElements="3.133529870649493E-306 5.762953011420275E-306 9.300699588493279E-306 2.7371805612676613E-305 3.876855509996079E-307 1.4410217108363206E-306 1.620567348185129E-306 2.297945473205673E-305 3.193414568279561E-305 1.6109092258980447E-306 4.884861766532753E-306 8.8116853923311E-307 7.89591827591278E-306">
- <presentation xmi:id="-LVHbtWMGC3pAL9abD018MA" href="uma://-LVHbtWMGC3pAL9abD018MA#-LVHbtWMGC3pAL9abD018MA"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_mtDpJGE-EdqnIZeW8YpHcA" name="conceptual_road_maps" guid="_mtDpJGE-EdqnIZeW8YpHcA" presentationName="Conceptual Roadmap" variabilityType="replaces" categorizedElements="5.2637267673584526E-306">
- <presentation xmi:id="-QcM1bn-XJLcMSggRp54YlQ" href="uma://-QcM1bn-XJLcMSggRp54YlQ#-QcM1bn-XJLcMSggRp54YlQ"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="2.0279775416255596E-305" name="guidelines_overview" guid="2.0279775416255596E-305" presentationName="Guidelines Overview" categorizedElements="3.754748120034442E-307 3.269440809144354E-305 3.85153041801319E-307 8.137126904637637E-306 3.9254165491375454E-306 6.7335956461328426E-307">
- <presentation xmi:id="-8FSBtYSGN9EGWRr1N6fbPQ" href="uma://-8FSBtYSGN9EGWRr1N6fbPQ#-8FSBtYSGN9EGWRr1N6fbPQ"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="6.505229665845286E-306" name="xp_white_papers" guid="6.505229665845286E-306" presentationName="XP White Papers" categorizedElements="7.290386721197834E-306 6.334658646686929E-306 1.0713784560673905E-305">
- <presentation xmi:id="-_GqtAEsGnq12qQmyqWdHHQ" href="uma://-_GqtAEsGnq12qQmyqWdHHQ#-_GqtAEsGnq12qQmyqWdHHQ"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_mtcqtmE-EdqnIZeW8YpHcA" name="references" guid="_mtcqtmE-EdqnIZeW8YpHcA" presentationName="References" variabilityType="replaces" categorizedElements="6.191633934532389E-306">
- <presentation xmi:id="-a8huB5Sn0Qjfe-SkZubH1w" href="uma://-a8huB5Sn0Qjfe-SkZubH1w#-a8huB5Sn0Qjfe-SkZubH1w"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_mtcquWE-EdqnIZeW8YpHcA" name="xp_basic_roles_artifacts" guid="_mtcquWE-EdqnIZeW8YpHcA" presentationName="XP Roles and Artifacts" categorizedElements="3.967980776087095E-306 1.545655831828372E-305"/>
- <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="3.967980776087095E-306" name="xp_roles_and_tasks" guid="3.967980776087095E-306" presentationName="XP Roles and Tasks" categorizedElements="5.613949040902463E-308">
- <presentation xmi:id="-c5D4uYtVcDvab8GzkO0HiQ" href="uma://-c5D4uYtVcDvab8GzkO0HiQ#-c5D4uYtVcDvab8GzkO0HiQ"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_um0n8GdjEdqlnYmIxoiUEQ" name="overview" guid="_um0n8GdjEdqlnYmIxoiUEQ" presentationName="Overview" categorizedElements="_ms9ig2E-EdqnIZeW8YpHcA _mtDpJGE-EdqnIZeW8YpHcA _mtcqtmE-EdqnIZeW8YpHcA"/>
- <contentElements xsi:type="org.eclipse.epf.uma:CustomCategory" xmi:id="_8NSdoGdjEdqlnYmIxoiUEQ" name="xp_team" guid="_8NSdoGdjEdqlnYmIxoiUEQ" presentationName="XP Team" categorizedElements="_13azwGNdEdqsrK7eslBiiA _mtcquWE-EdqnIZeW8YpHcA"/>
- </childPackages>
- </childPackages>
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_mhU6S2E-EdqnIZeW8YpHcA" name="CoreContent" guid="_mhU6S2E-EdqnIZeW8YpHcA">
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="{90FB58E1-B403-4358-85D0-BD902528D810}" name="xp_essentials" guid="{90FB58E1-B403-4358-85D0-BD902528D810}" briefDescription=" This component provides the essential concepts required to understand XP. " reusedPackages="{90FB58E1-B403-4358-85D0-BD902528D810} {45A887AB-A968-48AF-8213-4D470DA9DBCC} {BC57C7CE-BFA8-464F-9925-D27A7968B63C} {8367713C-3AEA-489D-B136-DB87D6340A3F} {01E73AC7-B8D8-4B2F-8B29-A28D9813DB6C} {796EA4CB-0038-43B8-A568-792DCC3B9F22}">
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="{BC57C7CE-BFA8-464F-9925-D27A7968B63C}" name="xp_requirements" guid="{BC57C7CE-BFA8-464F-9925-D27A7968B63C}" briefDescription=" This component provides guidance for defining requirements on an XP project. " reusedPackages="{90FB58E1-B403-4358-85D0-BD902528D810} {BC57C7CE-BFA8-464F-9925-D27A7968B63C}">
- <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="{A179D686-1E79-4CB0-97B5-103B4FBBBDEF}" name="xp_customer_req" guid="{A179D686-1E79-4CB0-97B5-103B4FBBBDEF}" presentationName="XP Customer (Requirements)" variabilityType="contributes" variabilityBasedOnElement="{3C90DD4F-CFDB-4111-922D-3B840B8942DE}" responsibleFor="{2300FB25-7249-4481-A1BD-978240906832}"/>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{A8708FFB-BB20-40AF-BEF2-7A8A814FF74D}" name="develop_xp_vision" guid="{A8708FFB-BB20-40AF-BEF2-7A8A814FF74D}" presentationName="Define Vision" performedBy="{A179D686-1E79-4CB0-97B5-103B4FBBBDEF}" output="{2300FB25-7249-4481-A1BD-978240906832}">
- <presentation xmi:id="-W67fNE0rT1c2PM-20yXbrw" href="uma://-W67fNE0rT1c2PM-20yXbrw#-W67fNE0rT1c2PM-20yXbrw"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="{2300FB25-7249-4481-A1BD-978240906832}" name="xp_vision" guid="{2300FB25-7249-4481-A1BD-978240906832}" briefDescription="Defines the stakeholder's view of the product to be developed, specified in terms of the stakeholder's key needs and features." presentationName="XP Vision" variabilityType="extends">
- <presentation xmi:id="-ZUxMgSWqLlaO5p1r1-ug6Q" href="uma://-ZUxMgSWqLlaO5p1r1-ug6Q#-ZUxMgSWqLlaO5p1r1-ug6Q"/>
- </contentElements>
- </childPackages>
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="{01E73AC7-B8D8-4B2F-8B29-A28D9813DB6C}" name="xp_programming" guid="{01E73AC7-B8D8-4B2F-8B29-A28D9813DB6C}" briefDescription=" This component provides guidance for programming on XP projects. " reusedPackages="{90FB58E1-B403-4358-85D0-BD902528D810} {01E73AC7-B8D8-4B2F-8B29-A28D9813DB6C} {796EA4CB-0038-43B8-A568-792DCC3B9F22}">
- <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="{C587F94C-90FD-4943-A4DE-68E9B6875071}" name="xp_implementer" guid="{C587F94C-90FD-4943-A4DE-68E9B6875071}" presentationName="XP Programmer (Implementer)" variabilityType="contributes" variabilityBasedOnElement="{08A6AF28-69B1-42DC-A957-2E6CDCB436C1}" conceptsAndPapers="1.4410217108363206E-306 8.8116853923311E-307 3.876855509996079E-307 1.0713784560673905E-305" responsibleFor="{1D7E042C-B29E-4169-8DF3-37DE0A5F64ED}"/>
- <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="1.4410217108363206E-306" name="refactoring_xp_programming" guid="1.4410217108363206E-306" presentationName="Refactoring">
- <presentation xmi:id="-U8NScY6mORb4XPcNZ_mrEA" href="uma://-U8NScY6mORb4XPcNZ_mrEA#-U8NScY6mORb4XPcNZ_mrEA"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="8.8116853923311E-307" name="coding_standard" guid="8.8116853923311E-307" presentationName="Coding Standard">
- <presentation xmi:id="--qg2qc3dqmgeB63Nx7Zndg" href="uma://--qg2qc3dqmgeB63Nx7Zndg#--qg2qc3dqmgeB63Nx7Zndg"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="3.876855509996079E-307" name="pair_programming" guid="3.876855509996079E-307" presentationName="Pair Programming">
- <presentation xmi:id="-n52TyFa7Reb3LOJV1JMpvg" href="uma://-n52TyFa7Reb3LOJV1JMpvg#-n52TyFa7Reb3LOJV1JMpvg"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Whitepaper" xmi:id="1.0713784560673905E-305" name="refactoring" guid="1.0713784560673905E-305" presentationName="Refactoring">
- <presentation xmi:id="-ql_2w28A9SIIZQca3Wg-kQ" href="uma://-ql_2w28A9SIIZQca3Wg-kQ#-ql_2w28A9SIIZQca3Wg-kQ"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{C88D5B0A-1A59-4575-ADDF-8ECBBAB83410}" name="define_coding_standard" guid="{C88D5B0A-1A59-4575-ADDF-8ECBBAB83410}" presentationName="Define Coding Standard" performedBy="{C587F94C-90FD-4943-A4DE-68E9B6875071}" output="{1D7E042C-B29E-4169-8DF3-37DE0A5F64ED}" optionalInput="{1D7E042C-B29E-4169-8DF3-37DE0A5F64ED}">
- <presentation xmi:id="-qIbMRqe8wqKN2-HLtNUcLw" href="uma://-qIbMRqe8wqKN2-HLtNUcLw#-qIbMRqe8wqKN2-HLtNUcLw"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{EC483990-8129-4AE3-893C-0F7406C128DA}" name="estimate_task" guid="{EC483990-8129-4AE3-893C-0F7406C128DA}" presentationName="Estimate Task" performedBy="{C587F94C-90FD-4943-A4DE-68E9B6875071}">
- <presentation xmi:id="-9EbmL3qGJ_TemB83cJublQ" href="uma://-9EbmL3qGJ_TemB83cJublQ#-9EbmL3qGJ_TemB83cJublQ"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{85BE1C0E-F389-4246-BB22-9A52988018B7}" name="implement_spike" guid="{85BE1C0E-F389-4246-BB22-9A52988018B7}" presentationName="Implement Spike" performedBy="{C587F94C-90FD-4943-A4DE-68E9B6875071}" output="{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1} {D156652E-7C52-4EBD-8F23-F38169877A57}" optionalInput="{7C34EE96-C3EA-49FD-A53C-7C113B86AE01} {21946731-4F5C-4862-8B4D-868629952B92}">
- <presentation xmi:id="-DbsgXRUjLhsnnpioGI2b3g" href="uma://-DbsgXRUjLhsnnpioGI2b3g#-DbsgXRUjLhsnnpioGI2b3g"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{3DD335BB-45F6-49C7-B17A-90652C73A485}" name="refactor_code" guid="{3DD335BB-45F6-49C7-B17A-90652C73A485}" presentationName="Refactor Code" guidelines="8.137126904637637E-306 3.85153041801319E-307" performedBy="{C587F94C-90FD-4943-A4DE-68E9B6875071}" mandatoryInput="{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1}" output="{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1} {D156652E-7C52-4EBD-8F23-F38169877A57}" optionalInput="{7C34EE96-C3EA-49FD-A53C-7C113B86AE01} {D156652E-7C52-4EBD-8F23-F38169877A57}">
- <presentation xmi:id="-IoT5LZUu3vnNFp-pwPUMHA" href="uma://-IoT5LZUu3vnNFp-pwPUMHA#-IoT5LZUu3vnNFp-pwPUMHA"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="8.137126904637637E-306" name="refactoring" guid="8.137126904637637E-306" presentationName="Refactoring">
- <presentation xmi:id="-dbA7zKOJY5WPZyLXErA9vw" href="uma://-dbA7zKOJY5WPZyLXErA9vw#-dbA7zKOJY5WPZyLXErA9vw"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="3.85153041801319E-307" name="pair_programming" guid="3.85153041801319E-307" presentationName="Pair Programming">
- <presentation xmi:id="-nfbUMyTTqEbCp3HDn-NjOA" href="uma://-nfbUMyTTqEbCp3HDn-NjOA#-nfbUMyTTqEbCp3HDn-NjOA"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="{1D7E042C-B29E-4169-8DF3-37DE0A5F64ED}" name="xp_coding_standard" guid="{1D7E042C-B29E-4169-8DF3-37DE0A5F64ED}" briefDescription="Describes the conventions to be used when working with the programming language." presentationName="Coding Standard" examples="6.216049252606417E-306">
- <presentation xmi:id="-NznKylxa2Y_MG8lACUV9Bw" href="uma://-NznKylxa2Y_MG8lACUV9Bw#-NznKylxa2Y_MG8lACUV9Bw"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Example" xmi:id="6.216049252606417E-306" name="test-ideas_catalog_examples" guid="6.216049252606417E-306" briefDescription="The example is attached below." presentationName="Test-Ideas Catalog Examples">
- <presentation xmi:id="-HkQclhewSbkFSomo1l_LBg" href="uma://-HkQclhewSbkFSomo1l_LBg#-HkQclhewSbkFSomo1l_LBg"/>
- </contentElements>
- </childPackages>
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="{796EA4CB-0038-43B8-A568-792DCC3B9F22}" name="xp_design" guid="{796EA4CB-0038-43B8-A568-792DCC3B9F22}" briefDescription=" This component provides guidance for how to design on an XP project. " reusedPackages="{90FB58E1-B403-4358-85D0-BD902528D810} {796EA4CB-0038-43B8-A568-792DCC3B9F22}">
- <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="{AB49377E-B734-45D9-A8AE-906AE216CBC7}" name="xp_designer" guid="{AB49377E-B734-45D9-A8AE-906AE216CBC7}" presentationName="XP Programmer (Designer)" variabilityType="contributes" variabilityBasedOnElement="{08A6AF28-69B1-42DC-A957-2E6CDCB436C1}" conceptsAndPapers="1.6109092258980447E-306 4.884861766532753E-306" responsibleFor="{7C34EE96-C3EA-49FD-A53C-7C113B86AE01}"/>
- <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="1.6109092258980447E-306" name="simple_design" guid="1.6109092258980447E-306" presentationName="Simple Design">
- <presentation xmi:id="-0rSxLFlmQfyKrgnqi1NKrg" href="uma://-0rSxLFlmQfyKrgnqi1NKrg#-0rSxLFlmQfyKrgnqi1NKrg"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="4.884861766532753E-306" name="metaphor_system_of_names" guid="4.884861766532753E-306" presentationName="Metaphor (System of Names)">
- <presentation xmi:id="-2OU2wQP_WNWX5zzWzx4ANw" href="uma://-2OU2wQP_WNWX5zzWzx4ANw#-2OU2wQP_WNWX5zzWzx4ANw"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{90DBD758-58B8-4383-94DD-312D349512BC}" name="breakdown_story" guid="{90DBD758-58B8-4383-94DD-312D349512BC}" presentationName="Break down Story" performedBy="{AB49377E-B734-45D9-A8AE-906AE216CBC7}" optionalInput="{21946731-4F5C-4862-8B4D-868629952B92}">
- <presentation xmi:id="-umDp1nFYrMetgnJ-kUMhHw" href="uma://-umDp1nFYrMetgnJ-kUMhHw#-umDp1nFYrMetgnJ-kUMhHw"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{23A924D3-5989-40DD-86A9-9D8FCFB8AE52}" name="estimate_user_story" guid="{23A924D3-5989-40DD-86A9-9D8FCFB8AE52}" presentationName="Estimate User Story" performedBy="{AB49377E-B734-45D9-A8AE-906AE216CBC7}" optionalInput="{21946731-4F5C-4862-8B4D-868629952B92}">
- <presentation xmi:id="-Z9xFd9JTnJuNN5S27p06UQ" href="uma://-Z9xFd9JTnJuNN5S27p06UQ#-Z9xFd9JTnJuNN5S27p06UQ"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="{7C34EE96-C3EA-49FD-A53C-7C113B86AE01}" name="xp_metaphor" guid="{7C34EE96-C3EA-49FD-A53C-7C113B86AE01}" briefDescription="A commonly understood vocabulary describing the significant pieces of the system and their associated relationships." presentationName="Metaphor (System of Names)">
- <presentation xmi:id="-sQUFozEqR3Gpa5PnCjFh9Q" href="uma://-sQUFozEqR3Gpa5PnCjFh9Q#-sQUFozEqR3Gpa5PnCjFh9Q"/>
- </contentElements>
- </childPackages>
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="{DBE91BD5-0065-4049-AA61-058C77F1D2A3}" name="xp_integration" guid="{DBE91BD5-0065-4049-AA61-058C77F1D2A3}" briefDescription=" This component provides guidance for integrating and building executables on XP projects. " reusedPackages="{90FB58E1-B403-4358-85D0-BD902528D810} {DBE91BD5-0065-4049-AA61-058C77F1D2A3}">
- <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="{2F4BC5DA-F706-4C38-9D38-6911C7856B10}" name="xp_integrator" guid="{2F4BC5DA-F706-4C38-9D38-6911C7856B10}" presentationName="XP Programmer (Integrator)" variabilityType="contributes" variabilityBasedOnElement="{08A6AF28-69B1-42DC-A957-2E6CDCB436C1}" conceptsAndPapers="3.193414568279561E-305" responsibleFor="{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222}"/>
- <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="3.193414568279561E-305" name="continuous_integration" guid="3.193414568279561E-305" presentationName="Continuous Integration">
- <presentation xmi:id="-35rZhRLEVuTVI4280ncN0A" href="uma://-35rZhRLEVuTVI4280ncN0A#-35rZhRLEVuTVI4280ncN0A"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{70FEC254-8555-4844-AD82-68367E25F082}" name="integrate_system" guid="{70FEC254-8555-4844-AD82-68367E25F082}" presentationName="Integrate and Build" performedBy="{2F4BC5DA-F706-4C38-9D38-6911C7856B10}" output="{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222}" optionalInput="{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1}">
- <presentation xmi:id="--tP2hgRfEkZPGYvy1y0GZQ" href="uma://--tP2hgRfEkZPGYvy1y0GZQ#--tP2hgRfEkZPGYvy1y0GZQ"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222}" name="xp_build" guid="{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222}" briefDescription="The result of the code integration and building process." presentationName="XP Build" variabilityType="extends">
- <presentation xmi:id="-rphHqeONv59sqZq_6FzE6Q" href="uma://-rphHqeONv59sqZq_6FzE6Q#-rphHqeONv59sqZq_6FzE6Q"/>
- </contentElements>
- </childPackages>
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="{8367713C-3AEA-489D-B136-DB87D6340A3F}" name="xp_testing" guid="{8367713C-3AEA-489D-B136-DB87D6340A3F}" briefDescription=" This component provides guidance for testing on XP projects. " reusedPackages="{90FB58E1-B403-4358-85D0-BD902528D810} {8367713C-3AEA-489D-B136-DB87D6340A3F}">
- <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="{9EE5F015-C409-4DD9-91AC-1A87DB833E92}" name="xp_customer_tst" guid="{9EE5F015-C409-4DD9-91AC-1A87DB833E92}" presentationName="XP Customer Test" variabilityType="contributes" variabilityBasedOnElement="{3C90DD4F-CFDB-4111-922D-3B840B8942DE}" conceptsAndPapers="2.297945473205673E-305 3.712584012051524E-306 8.834380241450745E-306" responsibleFor="{DF0EDBC7-4AAD-438D-89AA-64ECFE2416F5}"/>
- <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="2.297945473205673E-305" name="customer_tests" guid="2.297945473205673E-305" presentationName="Customer Tests">
- <presentation xmi:id="-oW2j2l-rXqHeWPIgjPpbng" href="uma://-oW2j2l-rXqHeWPIgjPpbng#-oW2j2l-rXqHeWPIgjPpbng"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="3.712584012051524E-306" name="product_quality" guid="3.712584012051524E-306" presentationName="Product Quality">
- <presentation xmi:id="-nGaswirSOYturOoUWwGdRw" href="uma://-nGaswirSOYturOoUWwGdRw#-nGaswirSOYturOoUWwGdRw"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="8.834380241450745E-306" name="test-ideas_list" guid="8.834380241450745E-306" presentationName="Test-Ideas List">
- <presentation xmi:id="-3i1jvKMUGGmAYPw4dHFbEg" href="uma://-3i1jvKMUGGmAYPw4dHFbEg#-3i1jvKMUGGmAYPw4dHFbEg"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{DCDB57BE-4233-4CF8-90CE-70D6808F92B0}" name="define_customer_test" guid="{DCDB57BE-4233-4CF8-90CE-70D6808F92B0}" presentationName="Define Customer Test" guidelines="1.8491691792142673E-308" performedBy="{9EE5F015-C409-4DD9-91AC-1A87DB833E92}" optionalInput="{21946731-4F5C-4862-8B4D-868629952B92}">
- <presentation xmi:id="-WgE0oiE2yddCOMnfzL25Gw" href="uma://-WgE0oiE2yddCOMnfzL25Gw#-WgE0oiE2yddCOMnfzL25Gw"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="1.8491691792142673E-308" name="equivalence_class_analysis" guid="1.8491691792142673E-308" presentationName="Equivalence Class Analysis">
- <presentation xmi:id="-c7t_eJuo1g5hpWTYTCItig" href="uma://-c7t_eJuo1g5hpWTYTCItig#-c7t_eJuo1g5hpWTYTCItig"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="{567EE050-7E62-4B63-8761-4883FF2FFF23}" name="xp_test_analyst" guid="{567EE050-7E62-4B63-8761-4883FF2FFF23}" presentationName="XP Test Analyst" variabilityType="contributes" variabilityBasedOnElement="{3C90DD4F-CFDB-4111-922D-3B840B8942DE}"/>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{52D6E875-C46B-454B-A39C-CEC21603AF5C}" name="report_acceptance_test_result" guid="{52D6E875-C46B-454B-A39C-CEC21603AF5C}" presentationName="Report Customer Test Result" performedBy="{3C90DD4F-CFDB-4111-922D-3B840B8942DE}" optionalInput="{DF0EDBC7-4AAD-438D-89AA-64ECFE2416F5}">
- <presentation xmi:id="-p0GGwGNG5O8Dn6O6ZzivIw" href="uma://-p0GGwGNG5O8Dn6O6ZzivIw#-p0GGwGNG5O8Dn6O6ZzivIw"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="{FB65D00B-8304-4CF7-9969-52CE82F503DC}" name="xp_tester" guid="{FB65D00B-8304-4CF7-9969-52CE82F503DC}" briefDescription="The XP Tester role helps the customer define and write acceptance tests for user stories." presentationName="XP Tester">
- <presentation xmi:id="-KfsuH9i0hVMlGV7PVIa3FQ" href="uma://-KfsuH9i0hVMlGV7PVIa3FQ#-KfsuH9i0hVMlGV7PVIa3FQ"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{E614ED93-AE72-4FD1-B459-C508CE1C536F}" name="automate_acceptance_test" guid="{E614ED93-AE72-4FD1-B459-C508CE1C536F}" presentationName="Automate Customer Test" performedBy="{FB65D00B-8304-4CF7-9969-52CE82F503DC}" output="{DF0EDBC7-4AAD-438D-89AA-64ECFE2416F5}">
- <presentation xmi:id="-fm-gBePbdl_WMsE5NxEreQ" href="uma://-fm-gBePbdl_WMsE5NxEreQ#-fm-gBePbdl_WMsE5NxEreQ"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{D4E30732-30D3-4C75-8C69-D2F15313F1A9}" name="run_acceptance_test" guid="{D4E30732-30D3-4C75-8C69-D2F15313F1A9}" presentationName="Run Customer Test" performedBy="{FB65D00B-8304-4CF7-9969-52CE82F503DC}" optionalInput="{DF0EDBC7-4AAD-438D-89AA-64ECFE2416F5}">
- <presentation xmi:id="-6RyabSc-ZUEtoEKb90BCbg" href="uma://-6RyabSc-ZUEtoEKb90BCbg#-6RyabSc-ZUEtoEKb90BCbg"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{B4F9BDCC-629E-485B-9EFA-318F8D5A37BC}" name="setup_tester_environment" guid="{B4F9BDCC-629E-485B-9EFA-318F8D5A37BC}" presentationName="Setup Tester Environment" performedBy="{FB65D00B-8304-4CF7-9969-52CE82F503DC}">
- <presentation xmi:id="-OPKuXnenD910fJyGKA99aw" href="uma://-OPKuXnenD910fJyGKA99aw#-OPKuXnenD910fJyGKA99aw"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="{DF0EDBC7-4AAD-438D-89AA-64ECFE2416F5}" name="xp_customer_test" guid="{DF0EDBC7-4AAD-438D-89AA-64ECFE2416F5}" briefDescription="Run against the system to verify that a feature has been implemented properly." presentationName="XP Customer Test" variabilityType="extends">
- <presentation xmi:id="-YYMUwBepQ28JU78LtraO3w" href="uma://-YYMUwBepQ28JU78LtraO3w#-YYMUwBepQ28JU78LtraO3w"/>
- </contentElements>
- </childPackages>
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="{45A887AB-A968-48AF-8213-4D470DA9DBCC}" name="xp_management" guid="{45A887AB-A968-48AF-8213-4D470DA9DBCC}" briefDescription=" This component provides guidance for managing XP projects. " reusedPackages="{45A887AB-A968-48AF-8213-4D470DA9DBCC} {90FB58E1-B403-4358-85D0-BD902528D810} {BC57C7CE-BFA8-464F-9925-D27A7968B63C}">
- <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}" name="xp_coach" guid="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}" briefDescription="The XP Coach is a supporting role which helps a team stay on process and help the team learn." presentationName="XP Coach" variabilityType="extends" conceptsAndPapers="3.133529870649493E-306">
- <presentation xmi:id="-gAMIwaLmqX7bf6GLCqwB-g" href="uma://-gAMIwaLmqX7bf6GLCqwB-g#-gAMIwaLmqX7bf6GLCqwB-g"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="3.133529870649493E-306" name="xp_sustainable_pace" guid="3.133529870649493E-306" presentationName="Sustainable Pace">
- <presentation xmi:id="-DoLoZOTPa_LacQ3jUG_lsg" href="uma://-DoLoZOTPa_LacQ3jUG_lsg#-DoLoZOTPa_LacQ3jUG_lsg"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{F0D4C205-4A38-42AF-BE87-9A6C0C173E65}" name="adapt_and_improve_process" guid="{F0D4C205-4A38-42AF-BE87-9A6C0C173E65}" presentationName="Adapt and Improve Process" performedBy="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">
- <presentation xmi:id="-u-Svthjtn1xLK2IwVUpk5Q" href="uma://-u-Svthjtn1xLK2IwVUpk5Q#-u-Svthjtn1xLK2IwVUpk5Q"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{1FA31F30-1F90-4BD3-9F0D-57DF66FC6727}" name="explain_process" guid="{1FA31F30-1F90-4BD3-9F0D-57DF66FC6727}" presentationName="Explain Process" performedBy="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">
- <presentation xmi:id="-I3yOxhkbTu3OCbzQ0sUsyA" href="uma://-I3yOxhkbTu3OCbzQ0sUsyA#-I3yOxhkbTu3OCbzQ0sUsyA"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{1C4325AC-17DE-4CD0-8AA0-4B210570579F}" name="improve_team_skills" guid="{1C4325AC-17DE-4CD0-8AA0-4B210570579F}" presentationName="Improve Team Skills" performedBy="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">
- <presentation xmi:id="-32JWpciwfc2e7HgQavJDkw" href="uma://-32JWpciwfc2e7HgQavJDkw#-32JWpciwfc2e7HgQavJDkw"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{80725BC3-E2BA-4860-8F07-4A34B96FBB2A}" name="keep_process_on_track" guid="{80725BC3-E2BA-4860-8F07-4A34B96FBB2A}" presentationName="Keep Process On Track" performedBy="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">
- <presentation xmi:id="-SH3UFVsPViLT3hOalbaxgA" href="uma://-SH3UFVsPViLT3hOalbaxgA#-SH3UFVsPViLT3hOalbaxgA"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{1B23700D-02B0-476F-A3DE-6F63A5407151}" name="resolve_conflicts" guid="{1B23700D-02B0-476F-A3DE-6F63A5407151}" presentationName="Resolve Conflicts" performedBy="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">
- <presentation xmi:id="-L85wOCiwe2O8D8CISEGGGg" href="uma://-L85wOCiwe2O8D8CISEGGGg#-L85wOCiwe2O8D8CISEGGGg"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="{D8FE277E-4F9A-47EB-855F-C451D601BBAF}" name="xp_tracker" guid="{D8FE277E-4F9A-47EB-855F-C451D601BBAF}" briefDescription="The XP Tracker role measures and communicates the team's progress." presentationName="XP Tracker" variabilityType="extends">
- <presentation xmi:id="-FIhk4OEzZl2IAVMXurpBLA" href="uma://-FIhk4OEzZl2IAVMXurpBLA#-FIhk4OEzZl2IAVMXurpBLA"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{C333BA32-CF6B-4577-9212-302893043EFF}" name="track_story_completion" guid="{C333BA32-CF6B-4577-9212-302893043EFF}" presentationName="Track Release Progress" performedBy="{D8FE277E-4F9A-47EB-855F-C451D601BBAF}" optionalInput="{21946731-4F5C-4862-8B4D-868629952B92}">
- <presentation xmi:id="-FxF90KOknQ5km30pP0038w" href="uma://-FxF90KOknQ5km30pP0038w#-FxF90KOknQ5km30pP0038w"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{3D22CC4B-ABC4-4CFE-9ACF-C9615E01382C}" name="track_task_completion" guid="{3D22CC4B-ABC4-4CFE-9ACF-C9615E01382C}" presentationName="Track Iteration Progress" performedBy="{D8FE277E-4F9A-47EB-855F-C451D601BBAF}">
- <presentation xmi:id="-0iRnQW0M9QDTNqWNijBB5A" href="uma://-0iRnQW0M9QDTNqWNijBB5A#-0iRnQW0M9QDTNqWNijBB5A"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="{9FAAB16A-C7FC-470A-BF2C-7F0951919E3B}" name="xp_customer_man" guid="{9FAAB16A-C7FC-470A-BF2C-7F0951919E3B}" presentationName="XP Customer (Manager)" variabilityType="contributes" variabilityBasedOnElement="{3C90DD4F-CFDB-4111-922D-3B840B8942DE}" conceptsAndPapers="5.762953011420275E-306" responsibleFor="{CA77FBD2-04DD-4010-B2AA-03E1E7C66B0B}"/>
- <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="5.762953011420275E-306" name="small_releases" guid="5.762953011420275E-306" presentationName="Small Releases">
- <presentation xmi:id="-vcCn_ksJo5Jw27aNZb1Cvw" href="uma://-vcCn_ksJo5Jw27aNZb1Cvw#-vcCn_ksJo5Jw27aNZb1Cvw"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{D755C076-8E63-4A24-89AA-A7D64E368B90}" name="define_release_plan" guid="{D755C076-8E63-4A24-89AA-A7D64E368B90}" presentationName="Define Release" guidelines="6.7335956461328426E-307" performedBy="{9FAAB16A-C7FC-470A-BF2C-7F0951919E3B}" output="{CA77FBD2-04DD-4010-B2AA-03E1E7C66B0B}" optionalInput="{2300FB25-7249-4481-A1BD-978240906832}">
- <presentation xmi:id="-7gEOFFavlkSqwIoTNrvfJA" href="uma://-7gEOFFavlkSqwIoTNrvfJA#-7gEOFFavlkSqwIoTNrvfJA"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="6.7335956461328426E-307" name="planning_game" guid="6.7335956461328426E-307" presentationName="Planning Game">
- <presentation xmi:id="-85F1Tegv16godTFTKyPdww" href="uma://-85F1Tegv16godTFTKyPdww#-85F1Tegv16godTFTKyPdww"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{ED94150E-EE14-47BF-97F5-F1EC7130EEEC}" name="report_project_status" guid="{ED94150E-EE14-47BF-97F5-F1EC7130EEEC}" presentationName="Report Project Status" performedBy="{9FAAB16A-C7FC-470A-BF2C-7F0951919E3B}">
- <presentation xmi:id="-WOPGmKUuYbvVeVHp0sgEgw" href="uma://-WOPGmKUuYbvVeVHp0sgEgw#-WOPGmKUuYbvVeVHp0sgEgw"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{653F1EF4-2BE5-4CCB-80E7-17CE02B081DC}" name="update_iteration_plan" guid="{653F1EF4-2BE5-4CCB-80E7-17CE02B081DC}" presentationName="Adjust Iteration Scope" guidelines="6.7335956461328426E-307" performedBy="{9FAAB16A-C7FC-470A-BF2C-7F0951919E3B}" output="{DC18E34B-70C1-403D-84CC-1BF117A7473D}" optionalInput="{DC18E34B-70C1-403D-84CC-1BF117A7473D}">
- <presentation xmi:id="-cU3MzukpGPAtw0wSS23R-g" href="uma://-cU3MzukpGPAtw0wSS23R-g#-cU3MzukpGPAtw0wSS23R-g"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{18BF87E6-5849-4091-AFE2-FC4F0C3887B1}" name="update_release_plan" guid="{18BF87E6-5849-4091-AFE2-FC4F0C3887B1}" presentationName="Revise Release Plan" guidelines="6.7335956461328426E-307" performedBy="{9FAAB16A-C7FC-470A-BF2C-7F0951919E3B}" output="{CA77FBD2-04DD-4010-B2AA-03E1E7C66B0B}" optionalInput="{CA77FBD2-04DD-4010-B2AA-03E1E7C66B0B}">
- <presentation xmi:id="-YO16TebjP7U0gkcYg7OY_A" href="uma://-YO16TebjP7U0gkcYg7OY_A#-YO16TebjP7U0gkcYg7OY_A"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="{CA77FBD2-04DD-4010-B2AA-03E1E7C66B0B}" name="xp_release_plan" guid="{CA77FBD2-04DD-4010-B2AA-03E1E7C66B0B}" briefDescription="A list of prioritized user stories that will be implemented in the coming release(s)." presentationName="XP Release Plan" variabilityType="extends">
- <presentation xmi:id="-mMZ9KUhiFwBbzSFjq_tO4A" href="uma://-mMZ9KUhiFwBbzSFjq_tO4A#-mMZ9KUhiFwBbzSFjq_tO4A"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="{0CB3C507-AFEE-4DA8-982B-9B93C8729910}" name="xp_system_administrator" guid="{0CB3C507-AFEE-4DA8-982B-9B93C8729910}" briefDescription="The XP Programmer (Administrator) is responsible for managing the programmer environment." presentationName="XP Programmer (Administrator)" variabilityType="extends">
- <presentation xmi:id="-23MZj6vLVbgbkXaptH4riQ" href="uma://-23MZj6vLVbgbkXaptH4riQ#-23MZj6vLVbgbkXaptH4riQ"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{D3AA9FEE-AAD9-4884-BF71-425E122110A7}" name="setup_programmer_environment" guid="{D3AA9FEE-AAD9-4884-BF71-425E122110A7}" presentationName="Setup Programmer Environment" guidelines="3.754748120034442E-307" performedBy="{0CB3C507-AFEE-4DA8-982B-9B93C8729910}">
- <presentation xmi:id="-1rVEQRCvrcicCdhpuuIZ8w" href="uma://-1rVEQRCvrcicCdhpuuIZ8w#-1rVEQRCvrcicCdhpuuIZ8w"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="3.754748120034442E-307" name="xp_environment" guid="3.754748120034442E-307" presentationName="XP Environment">
- <presentation xmi:id="-OuWRQbxXBGWox8SgcCr6sQ" href="uma://-OuWRQbxXBGWox8SgcCr6sQ#-OuWRQbxXBGWox8SgcCr6sQ"/>
- </contentElements>
- </childPackages>
- <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="{3C90DD4F-CFDB-4111-922D-3B840B8942DE}" name="xp_customer" guid="{3C90DD4F-CFDB-4111-922D-3B840B8942DE}" briefDescription="The XP Customer role has the responsibility of defining what is the right product to build, determining the order in which features will be built, and making sure the product actually works." presentationName="XP Customer" conceptsAndPapers="2.7371805612676613E-305" responsibleFor="{DC18E34B-70C1-403D-84CC-1BF117A7473D} {21946731-4F5C-4862-8B4D-868629952B92}">
- <presentation xmi:id="-92rjXjWhll5LOtPc58YERg" href="uma://-92rjXjWhll5LOtPc58YERg#-92rjXjWhll5LOtPc58YERg"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="2.7371805612676613E-305" name="planning_game" guid="2.7371805612676613E-305" presentationName="Planning Game">
- <presentation xmi:id="-CPHs6R59_druVDY6nRjHEw" href="uma://-CPHs6R59_druVDY6nRjHEw#-CPHs6R59_druVDY6nRjHEw"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{849E3635-6FCD-4FAD-A007-CA34B9998622}" name="define_iteration_plan" guid="{849E3635-6FCD-4FAD-A007-CA34B9998622}" presentationName="Define Iteration" guidelines="6.7335956461328426E-307" performedBy="{3C90DD4F-CFDB-4111-922D-3B840B8942DE}" output="{DC18E34B-70C1-403D-84CC-1BF117A7473D}" optionalInput="{CA77FBD2-04DD-4010-B2AA-03E1E7C66B0B}">
- <presentation xmi:id="-BWG5zUGb8c25kuLJ3ck8ng" href="uma://-BWG5zUGb8c25kuLJ3ck8ng#-BWG5zUGb8c25kuLJ3ck8ng"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{62CFC55C-3151-46CB-8886-F3DBD552ABC4}" name="write_user_story" guid="{62CFC55C-3151-46CB-8886-F3DBD552ABC4}" presentationName="Write User Story" performedBy="{3C90DD4F-CFDB-4111-922D-3B840B8942DE}" output="{21946731-4F5C-4862-8B4D-868629952B92}" optionalInput="{2300FB25-7249-4481-A1BD-978240906832}">
- <presentation xmi:id="-cqTu_uwmZrF3sFspx465XQ" href="uma://-cqTu_uwmZrF3sFspx465XQ#-cqTu_uwmZrF3sFspx465XQ"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="{DC18E34B-70C1-403D-84CC-1BF117A7473D}" name="xp_iteration_plan" guid="{DC18E34B-70C1-403D-84CC-1BF117A7473D}" briefDescription="Essentially a list of user stories and engineering tasks that will be worked on in the current iteration." presentationName="XP Iteration Plan" variabilityType="extends">
- <presentation xmi:id="-45BLJONIjGn7h4z87VXqHQ" href="uma://-45BLJONIjGn7h4z87VXqHQ#-45BLJONIjGn7h4z87VXqHQ"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1}" name="xp_production_code" guid="{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1}" briefDescription="The executable specification of the system being built." presentationName="Production Code" variabilityType="extends" conceptsAndPapers="9.300699588493279E-306 1.620567348185129E-306">
- <presentation xmi:id="-f1cDEBpC5wbDTQ9ru9UbLw" href="uma://-f1cDEBpC5wbDTQ9ru9UbLw#-f1cDEBpC5wbDTQ9ru9UbLw"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="9.300699588493279E-306" name="collective_ownership" guid="9.300699588493279E-306" presentationName="Collective Ownership">
- <presentation xmi:id="-YP0i7TC6QNgemddcj1iE7g" href="uma://-YP0i7TC6QNgemddcj1iE7g#-YP0i7TC6QNgemddcj1iE7g"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="1.620567348185129E-306" name="test_driven_development" guid="1.620567348185129E-306" presentationName="Test Driven Development">
- <presentation xmi:id="-yaD6WKGdrZ0n0yBSpwPr4g" href="uma://-yaD6WKGdrZ0n0yBSpwPr4g#-yaD6WKGdrZ0n0yBSpwPr4g"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Role" xmi:id="{08A6AF28-69B1-42DC-A957-2E6CDCB436C1}" name="xp_programmer" guid="{08A6AF28-69B1-42DC-A957-2E6CDCB436C1}" briefDescription="The XP Programmer is responsible for implementing the code to support the user stories." presentationName="XP Programmer" conceptsAndPapers="1.620567348185129E-306 9.300699588493279E-306 4.085829182735815E-305 6.556259235358794E-306 8.834380241450745E-306 1.2384224477983028E-305 7.290386721197834E-306 6.334658646686929E-306" responsibleFor="{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1} {D156652E-7C52-4EBD-8F23-F38169877A57}">
- <presentation xmi:id="-RoFHDUeLz4UFKDuFirQp3g" href="uma://-RoFHDUeLz4UFKDuFirQp3g#-RoFHDUeLz4UFKDuFirQp3g"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="4.085829182735815E-305" name="developer_testing" guid="4.085829182735815E-305" presentationName="Developer Testing">
- <presentation xmi:id="-aJBLg1aguP1bIWvQbJSd6w" href="uma://-aJBLg1aguP1bIWvQbJSd6w#-aJBLg1aguP1bIWvQbJSd6w"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="6.556259235358794E-306" name="test-first_design" guid="6.556259235358794E-306" presentationName="Test-first Design">
- <presentation xmi:id="-3AbfvnHrCOIQS63sEjrOew" href="uma://-3AbfvnHrCOIQS63sEjrOew#-3AbfvnHrCOIQS63sEjrOew"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="1.2384224477983028E-305" name="test-ideas_catalog" guid="1.2384224477983028E-305" presentationName="Test-Ideas Catalog">
- <presentation xmi:id="-OrjIrRLW6v_XnqLUQ9GYaQ" href="uma://-OrjIrRLW6v_XnqLUQ9GYaQ#-OrjIrRLW6v_XnqLUQ9GYaQ"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Whitepaper" xmi:id="7.290386721197834E-306" name="xp_guidelines_pair_programming" guid="7.290386721197834E-306" presentationName="XP Guidelines: Pair Programming">
- <presentation xmi:id="-Ymu8T1hQ_QoxCaNAQhD9AA" href="uma://-Ymu8T1hQ_QoxCaNAQhD9AA#-Ymu8T1hQ_QoxCaNAQhD9AA"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Whitepaper" xmi:id="6.334658646686929E-306" name="xp_guidelines_test-first_design_and_refactoring" guid="6.334658646686929E-306" presentationName="XP Guidelines: Test-first Design and Refactoring">
- <presentation xmi:id="-_AgYWcSlbVBZOVcQfJuBnQ" href="uma://-_AgYWcSlbVBZOVcQfJuBnQ#-_AgYWcSlbVBZOVcQfJuBnQ"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Task" xmi:id="{8F6CB99A-D2EA-44BB-8CE5-F97220D44088}" name="write_code" guid="{8F6CB99A-D2EA-44BB-8CE5-F97220D44088}" presentationName="Write Code" guidelines="3.9254165491375454E-306 3.85153041801319E-307 8.5657170364036E-306 1.0347051690476123E-305 1.7150344523489172E-305" examples="6.216049252606417E-306" performedBy="{08A6AF28-69B1-42DC-A957-2E6CDCB436C1}" output="{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1}" optionalInput="{1D7E042C-B29E-4169-8DF3-37DE0A5F64ED} {DC18E34B-70C1-403D-84CC-1BF117A7473D} {7C34EE96-C3EA-49FD-A53C-7C113B86AE01}">
- <presentation xmi:id="-kNZQ2Mr_nyfmCboprjMNTg" href="uma://-kNZQ2Mr_nyfmCboprjMNTg#-kNZQ2Mr_nyfmCboprjMNTg"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="3.9254165491375454E-306" name="test_driven_development_tdd" guid="3.9254165491375454E-306" presentationName="Test Driven Development (TDD)">
- <presentation xmi:id="-jc10ie6UDWUJzSDfsQExjw" href="uma://-jc10ie6UDWUJzSDfsQExjw#-jc10ie6UDWUJzSDfsQExjw"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="8.5657170364036E-306" name="test_ideas_for_method_calls" guid="8.5657170364036E-306" presentationName="Test Ideas for Method Calls">
- <presentation xmi:id="-nwZMQTZtIwI5weh9c_HoYA" href="uma://-nwZMQTZtIwI5weh9c_HoYA#-nwZMQTZtIwI5weh9c_HoYA"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="1.0347051690476123E-305" name="test_ideas_for_statechart_and_flow_diagrams" guid="1.0347051690476123E-305" presentationName="Test Ideas for Statechart and Flow Diagrams">
- <presentation xmi:id="-60dp5lxFJEpUarhchGCnHw" href="uma://-60dp5lxFJEpUarhchGCnHw#-60dp5lxFJEpUarhchGCnHw"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="1.7150344523489172E-305" name="test_ideas_for_booleans_and_boundaries" guid="1.7150344523489172E-305" presentationName="Test Ideas for Booleans and Boundaries">
- <presentation xmi:id="-FX8hDYUKOXsrQulFe9lwtw" href="uma://-FX8hDYUKOXsrQulFe9lwtw#-FX8hDYUKOXsrQulFe9lwtw"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="{21946731-4F5C-4862-8B4D-868629952B92}" name="xp_user_story" guid="{21946731-4F5C-4862-8B4D-868629952B92}" briefDescription="A brief description of some functionality provided by the system from the point of view of a user of that system." presentationName="User Story" variabilityType="extends">
- <presentation xmi:id="-rtY57MTVQrEcfTKwD3-Wvw" href="uma://-rtY57MTVQrEcfTKwD3-Wvw#-rtY57MTVQrEcfTKwD3-Wvw"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Artifact" xmi:id="{D156652E-7C52-4EBD-8F23-F38169877A57}" name="xp_unit_test" guid="{D156652E-7C52-4EBD-8F23-F38169877A57}" briefDescription="Used to ensure that a specific functionality of a component of the system is working properly." presentationName="XP Unit Test" conceptsAndPapers="1.620567348185129E-306 4.085829182735815E-305 6.556259235358794E-306" guidelines="8.5657170364036E-306 1.0347051690476123E-305 1.7150344523489172E-305 1.8491691792142673E-308" examples="6.216049252606417E-306">
- <presentation xmi:id="-dwfXb2dWJOQkTuLo-BTFeQ" href="uma://-dwfXb2dWJOQkTuLo-BTFeQ#-dwfXb2dWJOQkTuLo-BTFeQ"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Practice" xmi:id="_ycm9gGZBEdqvwYzpSSc2Nw" name="sustainable_pace" guid="_ycm9gGZBEdqvwYzpSSc2Nw" presentationName="Sustainable Pace" contentReferences="3.133529870649493E-306">
- <presentation xmi:id="-AS84xtg2NOXfrqA6eVRzMQ" href="uma://-AS84xtg2NOXfrqA6eVRzMQ#-AS84xtg2NOXfrqA6eVRzMQ"/>
- </contentElements>
- </childPackages>
- <childPackages xsi:type="org.eclipse.epf.uma:ContentPackage" xmi:id="_ms9igWE-EdqnIZeW8YpHcA" name="xp_basic_concepts" guid="_ms9igWE-EdqnIZeW8YpHcA" reusedPackages="{90FB58E1-B403-4358-85D0-BD902528D810} {01E73AC7-B8D8-4B2F-8B29-A28D9813DB6C} _ms9igWE-EdqnIZeW8YpHcA {45A887AB-A968-48AF-8213-4D470DA9DBCC}">
- <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="9.251272550276345E-306" name="what_is_xp" guid="9.251272550276345E-306" presentationName="What is XP?">
- <presentation xmi:id="-nO38_JQ9G3FQvNlAT5Agqg" href="uma://-nO38_JQ9G3FQvNlAT5Agqg#-nO38_JQ9G3FQvNlAT5Agqg"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="1.6390805262958034E-306" name="motivation" guid="1.6390805262958034E-306" presentationName="motivation">
- <presentation xmi:id="-nIpFvBhY9WogqrEQv4NknQ" href="uma://-nIpFvBhY9WogqrEQv4NknQ#-nIpFvBhY9WogqrEQv4NknQ"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="1.041091673844025E-305" name="agile_software_development" guid="1.041091673844025E-305" presentationName="Agile Software Development">
- <presentation xmi:id="-EHSlFv7Gla5oCPGBiaZKow" href="uma://-EHSlFv7Gla5oCPGBiaZKow#-EHSlFv7Gla5oCPGBiaZKow"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="1.076140803519123E-306" name="xp_values" guid="1.076140803519123E-306" presentationName="XP Values">
- <presentation xmi:id="-pA6XLJKgRiwDTEp_qMlQ9g" href="uma://-pA6XLJKgRiwDTEp_qMlQ9g#-pA6XLJKgRiwDTEp_qMlQ9g"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="2.2937799026801584E-305" name="xp_practices" guid="2.2937799026801584E-305" presentationName="XP Practices">
- <presentation xmi:id="-24MPC2FhJbx7Fr0F6QEq8A" href="uma://-24MPC2FhJbx7Fr0F6QEq8A#-24MPC2FhJbx7Fr0F6QEq8A"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="3.036332011267074E-306" name="xp_rights" guid="3.036332011267074E-306" presentationName="XP Rights">
- <presentation xmi:id="-vEvfeoyYAPDr-jfyX2QLww" href="uma://-vEvfeoyYAPDr-jfyX2QLww#-vEvfeoyYAPDr-jfyX2QLww"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="5.2637267673584526E-306" name="extreme_programming" guid="5.2637267673584526E-306" presentationName="Extreme Programming">
- <presentation xmi:id="-27sE-swoOUGtar9a0f3RPw" href="uma://-27sE-swoOUGtar9a0f3RPw#-27sE-swoOUGtar9a0f3RPw"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Guideline" xmi:id="3.269440809144354E-305" name="open_workspace" guid="3.269440809144354E-305" presentationName="Open Workspace">
- <presentation xmi:id="-mq7aEjHjqWoRd6aWFK_Dwg" href="uma://-mq7aEjHjqWoRd6aWFK_Dwg#-mq7aEjHjqWoRd6aWFK_Dwg"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="6.191633934532389E-306" name="xp_and_agile_process_references" guid="6.191633934532389E-306" presentationName="XP and Agile Process References">
- <presentation xmi:id="-8UKMv929ysWDBF1IOAAgsg" href="uma://-8UKMv929ysWDBF1IOAAgsg#-8UKMv929ysWDBF1IOAAgsg"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="8.608243854485154E-306" name="xp_developer_team" guid="8.608243854485154E-306" presentationName="XP Developer Team">
- <presentation xmi:id="-_11Y5NHJcC5lkqB4CeSpbg" href="uma://-_11Y5NHJcC5lkqB4CeSpbg#-_11Y5NHJcC5lkqB4CeSpbg"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="2.9889538140050517E-306" name="xp_customer_team" guid="2.9889538140050517E-306" presentationName="XP Customer Team">
- <presentation xmi:id="-mZMamrTcnR6xoZgvw9XU-A" href="uma://-mZMamrTcnR6xoZgvw9XU-A#-mZMamrTcnR6xoZgvw9XU-A"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="1.545655831828372E-305" name="xp_artifacts" guid="1.545655831828372E-305" presentationName="XP Artifacts">
- <presentation xmi:id="-O3LVBobhzFRt-5bytDkqqQ" href="uma://-O3LVBobhzFRt-5bytDkqqQ#-O3LVBobhzFRt-5bytDkqqQ"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:Concept" xmi:id="7.89591827591278E-306" name="whole_team" guid="7.89591827591278E-306" presentationName="Whole Team">
- <presentation xmi:id="-uqrgrFY-74R1FijPLvcXoQ" href="uma://-uqrgrFY-74R1FijPLvcXoQ#-uqrgrFY-74R1FijPLvcXoQ"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="5.613949040902463E-308" name="xp_organization" guid="5.613949040902463E-308" presentationName="XP Organization">
- <presentation xmi:id="-2nINowSo0VedqZTd4LIZIg" href="uma://-2nINowSo0VedqZTd4LIZIg#-2nINowSo0VedqZTd4LIZIg"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="1.2284921351651456E-304" name="getting_started_with_xp" guid="1.2284921351651456E-304" presentationName="Getting Started with XP">
- <presentation xmi:id="-PCk5_o83KYiPZaKUzt021A" href="uma://-PCk5_o83KYiPZaKUzt021A#-PCk5_o83KYiPZaKUzt021A"/>
- </contentElements>
- <contentElements xsi:type="org.eclipse.epf.uma:SupportingMaterial" xmi:id="_XI5PQHEPEdug-a-RuUM3Hg" name="xp_copyright" guid="_XI5PQHEPEdug-a-RuUM3Hg" presentationName="XP Plug-in Copyright" shapeicon="xp/guidances/supportingmaterials/resources/CRsym_obj.gif" nodeicon="xp/guidances/supportingmaterials/resources/CRsym_obj.gif">
- <presentation xmi:id="-31JQsY6FjFegmq-JJZdndg" href="uma://-31JQsY6FjFegmq-JJZdndg#-31JQsY6FjFegmq-JJZdndg"/>
- </contentElements>
- </childPackages>
- </childPackages>
- <childPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_mhU6TGE-EdqnIZeW8YpHcA" name="CapabilityPatterns" guid="_mhU6TGE-EdqnIZeW8YpHcA"/>
- </methodPackages>
- <methodPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_mhU6TWE-EdqnIZeW8YpHcA" name="DeliveryProcesses" guid="_mhU6TWE-EdqnIZeW8YpHcA"/>
- <methodPackages xsi:type="org.eclipse.epf.uma:ProcessPackage" xmi:id="_mhU6TmE-EdqnIZeW8YpHcA" name="ProcessContributions" guid="_mhU6TmE-EdqnIZeW8YpHcA"/>
- </org.eclipse.epf.uma:MethodPlugin>
-</xmi:XMI>
diff --git a/XP/xp/resources/.cvsignore b/XP/xp/resources/.cvsignore
deleted file mode 100644
index 085e8ba..0000000
--- a/XP/xp/resources/.cvsignore
+++ /dev/null
@@ -1 +0,0 @@
-Thumbs.db
diff --git a/XP/xp/resources/about.htm b/XP/xp/resources/about.htm
deleted file mode 100644
index a867e55..0000000
--- a/XP/xp/resources/about.htm
+++ /dev/null
@@ -1,76 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-
-<html>
-<!--
- Copyright (c) 2002, 2006 IBM Corporation and Object Mentor.
- All rights reserved. This program and the accompanying materials
- are made available under the terms of the Eclipse Public License v1.0
- which accompanies this distribution, and is available at
- http://www.eclipse.org/legal/epl-v10.html
- Contributors:
- IBM Corporation and Object Mentor - initial implementation
--->
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
- <title>About</title>
-<script src="scripts/common.js" type="text/javascript" language="JavaScript"></script>
- <style type="text/css">
- body {
- margin: 8px;
- }
- </style>
-</head>
-
-<body>
-<img src="epf.ico" width="16" height="16" alt="about icon" border="0"/><br />
-<br />
-<span class="pop">XP Plug-in for EPF Composer<br />
-Version 0.1<br />
-<br />
-Copyright (c) 2002, 2006 IBM Corporation and Object Mentor. All rights reserved. <br>
-This program and the accompanying materials are made available under the terms
-of the Eclipse Public License v1.0 which accompanies this distribution, and is
-available at <a href="http://www.eclipse.org/legal/epl-v10.html">http://www.eclipse.org/legal/epl-v10.html</a>.
-<br>
-Contributors: IBM Corporation and Object Mentor - initial implementation</span><br />
-<br />
- <table summary="" border="0" cellspacing="0" cellpadding="0">
- <tr>
- <td><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
- <td class="buttonbody" colspan="2"><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
- <td colspan="2"><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
- </tr>
- <tr>
- <td class="buttonbody" colspan="4" rowspan="2"><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
- <td><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
- </tr>
- <tr>
- <td class="buttonshadow"><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
- </tr>
- <tr>
- <td class="buttonbody" colspan="2" rowspan="2"><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
- <td class="buttonbody"><a class="button" href="javascript:self.close();"><span class="buttontxt"> Close </span></a></td>
- <td class="buttonbody" rowspan="2"><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
- <td class="buttonshadow" rowspan="2"><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
- </tr>
- <tr>
- <td class="buttonbody"><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
- </tr>
- <tr>
- <td><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
- <td class="buttonbody"><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
- <td class="buttonbody"><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
- <td class="buttonshadow"><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
- <td><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
- </tr>
- <tr>
- <td colspan="2"><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
- <td class="buttonshadow"><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
- <td colspan="2"><img src="./images/shim.gif" alt="" width="1" height="1" /></td>
- </tr>
- </table>
-
-</body>
-</html>
diff --git a/XP/xp/resources/banner.gif b/XP/xp/resources/banner.gif
deleted file mode 100644
index 308266d..0000000
--- a/XP/xp/resources/banner.gif
+++ /dev/null
Binary files differ
diff --git a/XP/xp/resources/circleOfLife.jpg b/XP/xp/resources/circleOfLife.jpg
deleted file mode 100644
index 3772826..0000000
--- a/XP/xp/resources/circleOfLife.jpg
+++ /dev/null
Binary files differ
diff --git a/XP/xp/resources/process.gif b/XP/xp/resources/process.gif
deleted file mode 100644
index 8f9a085..0000000
--- a/XP/xp/resources/process.gif
+++ /dev/null
Binary files differ
diff --git a/XP/xp/resources/spscreen.htm b/XP/xp/resources/spscreen.htm
deleted file mode 100644
index b233aa4..0000000
--- a/XP/xp/resources/spscreen.htm
+++ /dev/null
@@ -1,34 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-
-<!-- RPW META DATA START --
-
-
--- RPW META DATA END -->
-
-<html>
-
-<head>
-<link rel="StyleSheet" href="rop.css" type="text/css"/>
-<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
-<title>Splash Screen</title>
-</head>
-
-<body>
-
-
-
-<p align="center"> </p>
-<h2 align="center">Please wait while the tree browser is being loaded...<br/></h2>
-<!--
-<p align="center"> </p>
-<p align="center"><img src="images/splash.gif" alt="Welcome to the Eclipse Process Framework"/></p>
-<br/>
--->
-<br/>
-
-
-</body>
-
-</html>
diff --git a/XP/xp/roles/xp_coach.xmi b/XP/xp/roles/xp_coach.xmi
deleted file mode 100644
index ea49307..0000000
--- a/XP/xp/roles/xp_coach.xmi
+++ /dev/null
@@ -1,22 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-gAMIwaLmqX7bf6GLCqwB-g" name="xp_coach,{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}" guid="-gAMIwaLmqX7bf6GLCqwB-g" changeDate="2006-11-09T13:28:38.381-0800" version="1.0.0">
- <mainDescription><a id="XE_xp_coach__role_definition" name="XE_xp_coach__role_definition"></a><a id="Description" name="Description"></a>
-<p>
- The <a class="PresentationName" guid="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">XP Coach</a> role helps a team stay on
- process and helps the team to learn. A coach brings an outside perspective to help a team see themselves more clearly.
- The coach will help balance the needs of delivering the project while improving the use of the practices. A coach or
- team of coaches supports the Customer Team, the Developer Team, and the Organization.
-</p>
-<p>
- The decisions that coaches make should always stem from the XP values (communication, simplicity, feedback, and
- courage) and usually move toward the XP practices. As such, familiarity with the values and practices is a
- prerequisite. The coach must command the respect required to lead the respective teams. The coach must possess people
- skills and be effective in influencing the actions of the teams.
-</p></mainDescription>
- <skills><a id="Skills" name="Skills"></a>
-<p>
- The <a class="PresentationName" href="./../../xp/roles/xp_coach,{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}.html" guid="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">XP Coach</a> uses many different techniques. The coach is a mentor,
- working side by side with team members on their tasks. The coach is a facilitator, helping achieve more effective team
- performance. The coach is a conduit, reinforcing communication within the team and across teams.
-</p></skills>
-</org.eclipse.epf.uma:RoleDescription>
diff --git a/XP/xp/roles/xp_customer.xmi b/XP/xp/roles/xp_customer.xmi
deleted file mode 100644
index c45f444..0000000
--- a/XP/xp/roles/xp_customer.xmi
+++ /dev/null
@@ -1,16 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-92rjXjWhll5LOtPc58YERg" name="xp_customer,{3C90DD4F-CFDB-4111-922D-3B840B8942DE}" guid="-92rjXjWhll5LOtPc58YERg" changeDate="2006-11-13T11:52:45.927-0800" version="1.0.0">
- <mainDescription><a id="XE_xp_customer__role_definition" name="XE_xp_customer__role_definition"></a><a id="Description"
-name="Description"></a>
-<p>
- The <a class="PresentationName" guid="{3C90DD4F-CFDB-4111-922D-3B840B8942DE}">XP Customer</a> role has the
- responsibility of defining what is the right product to build, determining the order in which features will be built
- and making sure the product actually works.
-</p>
-<p>
- The <a class="PresentationName" guid="{3C90DD4F-CFDB-4111-922D-3B840B8942DE}">XP Customer</a> writes system features in
- the form of user stories that have business value. Using the planning game, he chooses the order in which the stories
- will be done by the development team. He also defines acceptance tests that will be run against the system to prove
- that the system is reliable and does what is required.
-</p></mainDescription>
-</org.eclipse.epf.uma:RoleDescription>
diff --git a/XP/xp/roles/xp_programmer.xmi b/XP/xp/roles/xp_programmer.xmi
deleted file mode 100644
index d72f7c1..0000000
--- a/XP/xp/roles/xp_programmer.xmi
+++ /dev/null
@@ -1,4 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-RoFHDUeLz4UFKDuFirQp3g" name="xp_programmer,{08A6AF28-69B1-42DC-A957-2E6CDCB436C1}" guid="-RoFHDUeLz4UFKDuFirQp3g">
- <mainDescription><a id="XE_xp_programmer__role_definition" name="XE_xp_programmer__role_definition"></a></mainDescription>
-</org.eclipse.epf.uma:RoleDescription>
diff --git a/XP/xp/roles/xp_system_administrator.xmi b/XP/xp/roles/xp_system_administrator.xmi
deleted file mode 100644
index 939d820..0000000
--- a/XP/xp/roles/xp_system_administrator.xmi
+++ /dev/null
@@ -1,19 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-23MZj6vLVbgbkXaptH4riQ" name="xp_system_administrator,{0CB3C507-AFEE-4DA8-982B-9B93C8729910}" guid="-23MZj6vLVbgbkXaptH4riQ" version="1.0.0">
- <mainDescription><a id="XE_xp_programmer_(administrator)__role_definition" name="XE_xp_programmer_(administrator)__role_definition"></a><a
-id="Description" name="Description"></a>
-<p>
- The <a class="PresentationName" guid="{0CB3C507-AFEE-4DA8-982B-9B93C8729910}">XP Programmer (Administrator)</a> role
- includes most of the traditional software development technical roles, such as designer, implementer, integrator, and
- administrator.
-</p>
-<p>
- In the administrator role, the programmer deals with establishing the physical working environment.
-</p></mainDescription>
- <skills><a id="Skills" name="Skills"></a>
-<p>
- The <a class="PresentationName" guid="{0CB3C507-AFEE-4DA8-982B-9B93C8729910}">XP Programmer (Administrator)</a> role is
- responsible for establishing the workspace for pair programming, including removing cubicle walls, establishing line of
- sight with the customer, and standardizing on the development tools.
-</p></skills>
-</org.eclipse.epf.uma:RoleDescription>
diff --git a/XP/xp/roles/xp_tester.xmi b/XP/xp/roles/xp_tester.xmi
deleted file mode 100644
index 5f83389..0000000
--- a/XP/xp/roles/xp_tester.xmi
+++ /dev/null
@@ -1,23 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-KfsuH9i0hVMlGV7PVIa3FQ" name="xp_tester,{FB65D00B-8304-4CF7-9969-52CE82F503DC}" guid="-KfsuH9i0hVMlGV7PVIa3FQ" version="1.0.0">
- <mainDescription><p>
- The primary responsibility of the XP Tester is to help the customer define and implement acceptance tests for user
- stories. The XP Tester is also responsible for running the tests frequently and posting the results for the whole team
- to see. As the number of tests grow, the XP Tester will likely need to create and maintain some kind of tool to make it
- easier to define them, run them, and gather the results quickly.
-</p></mainDescription>
- <skills><p>
- Whereas knowledge of the applications target domain is provided by the customer, the XP Tester needs to support the
- customer by providing:
-</p>
-<ul>
- <li>
- Knowledge of typical software failure conditions and the test techniques that can be employed to uncover those
- errors.
- </li>
- <li>
- Knowledge of different techniques to implement and run tests, including understanding of and experience with test
- automation.
- </li>
-</ul></skills>
-</org.eclipse.epf.uma:RoleDescription>
diff --git a/XP/xp/roles/xp_tracker.xmi b/XP/xp/roles/xp_tracker.xmi
deleted file mode 100644
index 095f36e..0000000
--- a/XP/xp/roles/xp_tracker.xmi
+++ /dev/null
@@ -1,12 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-FIhk4OEzZl2IAVMXurpBLA" name="xp_tracker,{D8FE277E-4F9A-47EB-855F-C451D601BBAF}" guid="-FIhk4OEzZl2IAVMXurpBLA" version="1.0.0">
- <mainDescription><a id="XE_xp_tracker__role_definition" name="XE_xp_tracker__role_definition"></a><a id="Description"
-name="Description"></a>
-<p>
- The three basic things the <a class="PresentationName" guid="{D8FE277E-4F9A-47EB-855F-C451D601BBAF}">XP Tracker</a>
- will track are the release plan (user stories), the iteration plan (tasks) and the acceptance tests. The tracker can
- also keep track of other metrics, which may help in solving problems the team is having. A good <a
- class="PresentationName" guid="{D8FE277E-4F9A-47EB-855F-C451D601BBAF}">XP Tracker</a> has the ability to collect the
- information without disturbing the process significantly.
-</p></mainDescription>
-</org.eclipse.epf.uma:RoleDescription>
diff --git a/XP/xp/tasks/adapt_and_improve_process.xmi b/XP/xp/tasks/adapt_and_improve_process.xmi
deleted file mode 100644
index 370063c..0000000
--- a/XP/xp/tasks/adapt_and_improve_process.xmi
+++ /dev/null
@@ -1,60 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-u-Svthjtn1xLK2IwVUpk5Q" name="adapt_and_improve_process,{F0D4C205-4A38-42AF-BE87-9A6C0C173E65}" guid="-u-Svthjtn1xLK2IwVUpk5Q" version="1.0.0">
- <sections xmi:id="_oNoEAGE-EdqnIZeW8YpHcA" name=" General " guid="_oNoEAGE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Prep" name="Prep"></a>
-<p>
- Teams using XP are guided by the <a class="elementLink"
- href="./../../xp/guidances/concepts/xp_values,1.076140803519123E-306.html" guid="1.076140803519123E-306">XP Values</a>
- through their use of the <a class="elementLink"
- href="./../../xp/guidances/concepts/xp_practices,2.2937799026801584E-305.html" guid="2.2937799026801584E-305">XP
- Practices</a>. The XP Practices are each best practices, but the practices also leverage the benefits of the other
- practices to form an efficient, minimal set of practices required to deliver high quality software aligned to customer
- needs.
-</p>
-<p>
- In general, teams will be most effective in their use of XP if each of the practices is used as much as possible on the
- project. In practice, this can be difficult to achieve for a number of reasons, including:
-</p>
-<ul>
- <li>
- Technical obstacles, such as non-OO languages and legacy code
- </li>
- <li>
- Lack of skills, including basic programming skills, practice skills, domain expertise, teamwork skills
- </li>
- <li>
- A complex customer environment, where a single source of prioritized stories is difficult to develop
- </li>
- <li>
- Organizational obstacles, such as distributed teams, large teams, and command/control oriented cultures
- </li>
-</ul>
-<p>
- As the team uses XP, these obstacles affect their ability to effectively use the practices. The <a
- class="PresentationName" href="./../../xp/roles/xp_coach,{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}.html"
- guid="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">XP Coach</a> helps the team address how these challenges will affect
- their use of the practices. This starts with helping the team maintain the <a class="elementLinkWithUserText"
- href="./../../xp/guidances/concepts/xp_values,1.076140803519123E-306.html#Courage"
- guid="1.076140803519123E-306">Courage</a> to confront and remove these obstacles, clearing the way for the practices to
- be used. In cases where the obstacles cannot be removed, the coach and the team use the <a class="elementLink"
- href="./../../xp/guidances/concepts/xp_values,1.076140803519123E-306.html" guid="1.076140803519123E-306">XP Values</a>
- to guide adaptation of the practices.
-</p>
-<p>
- The <a class="PresentationName" href="./../../xp/roles/xp_coach,{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}.html"
- guid="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">XP Coach</a> needs to participate in communities that share best
- practices in software development and XP. These communities will exist within large companies, in local users groups,
- and in Internet communities.
-</p>
-<p>
- <br />
- <br />
-</p></sectionDescription>
- </sections>
- <purpose><a id="XE_adapt_and_improve_process__activity_definition" name="XE_adapt_and_improve_process__activity_definition"></a>
-<ul>
- <li>
- Improve the productivity of the team.
- </li>
-</ul></purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/xp/tasks/automate_acceptance_test.xmi b/XP/xp/tasks/automate_acceptance_test.xmi
deleted file mode 100644
index 8266bcc..0000000
--- a/XP/xp/tasks/automate_acceptance_test.xmi
+++ /dev/null
@@ -1,44 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-fm-gBePbdl_WMsE5NxEreQ" name="automate_acceptance_test,{E614ED93-AE72-4FD1-B459-C508CE1C536F}" guid="-fm-gBePbdl_WMsE5NxEreQ" version="1.0.0">
- <sections xmi:id="_oNCOIGE-EdqnIZeW8YpHcA" name=" General " guid="_oNCOIGE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Prep" name="Prep"></a>
-<p>
- XP teams represent detailed requirements as automated customer tests. Automating the tests insures they are detailed,
- unambiguous, and executable. Typically, each acceptance criteria is translated into at least one automated test.
-</p>
-<p>
- There are lots of ways to do this:
-</p>
-<ul>
- <li>
- For a batch program reading inputs and producing outputs: create test input files, capture actual output, and
- compare it against expected output.
- </li>
- <li>
- Write functional tests as programs. You can use a unit testing framework as a base or create a little scripting
- language the programmers can use.
- </li>
- <li>
- Allow the customer to easily specify tests (spreadsheets, flat text files) and create a small tool to read the
- input and expected output. The tool runs the input against the system and checks that the actual output matches the
- expected output.
- </li>
- <li>
- Build an input recorder to allow customers to define the tests.
- </li>
- <li>
- Use simple file-based tools to check the results.
- </li>
-</ul>
-<p>
- It is important to build the automation simply and incrementally as you need it. It is too easy to lose control and
- invest too much time in test automation instead of business value. Don't overdo it.
-</p></sectionDescription>
- </sections>
- <purpose><a id="XE_automate_customer_test__activity_definition" name="XE_automate_customer_test__activity_definition"></a>
-<ul>
- <li>
- Transform the acceptance criteria of a user story into executable form.
- </li>
-</ul></purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/xp/tasks/breakdown_story.xmi b/XP/xp/tasks/breakdown_story.xmi
deleted file mode 100644
index 783732e..0000000
--- a/XP/xp/tasks/breakdown_story.xmi
+++ /dev/null
@@ -1,36 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-umDp1nFYrMetgnJ-kUMhHw" name="breakdown_story,{90DBD758-58B8-4383-94DD-312D349512BC}" guid="-umDp1nFYrMetgnJ-kUMhHw" version="1.0.0">
- <sections xmi:id="_oEkOoGE-EdqnIZeW8YpHcA" name=" Understand the User Story " guid="_oEkOoGE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step1" name="Step1"></a>
-<p>
- Breaking down user stories occurs at iteration planning. The first step in iteration planning is for the customer to go
- over the story with the developers to ensure they understand the story. The developers can ask questions until they are
- satisfied that they understand all aspects of the system. The details of the user stories are defined in the acceptance
- test criteria.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_oEkOoWE-EdqnIZeW8YpHcA" name=" Discuss Possible Implementations " guid="_oEkOoWE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step2" name="Step2"></a>
-<p>
- Coming up with engineering tasks for a story requires a good understanding of how the story will be implemented. The
- team uses this time to discuss possible design alternatives or approaches.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_oEkOomE-EdqnIZeW8YpHcA" name=" Identify Engineering Tasks " guid="_oEkOomE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step3" name="Step3"></a>
-<p>
- Once an approach has been selected by the team, the team focuses on identifying the steps that allow the team to fully
- implement it during the following iteration.
-</p>
-<p>
- <br />
- <br />
-</p></sectionDescription>
- </sections>
- <purpose><a id="XE_break_down_story__activity_definition" name="XE_break_down_story__activity_definition"></a>
-<ul>
- <li>
- Split user stories into engineering tasks.
- </li>
-</ul></purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/xp/tasks/define_coding_standard.xmi b/XP/xp/tasks/define_coding_standard.xmi
deleted file mode 100644
index 437ff72..0000000
--- a/XP/xp/tasks/define_coding_standard.xmi
+++ /dev/null
@@ -1,29 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-qIbMRqe8wqKN2-HLtNUcLw" name="define_coding_standard,{C88D5B0A-1A59-4575-ADDF-8ECBBAB83410}" guid="-qIbMRqe8wqKN2-HLtNUcLw" version="1.0.0">
- <sections xmi:id="_oCfyEGE-EdqnIZeW8YpHcA" name=" Write Prototypical Classes " guid="_oCfyEGE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step1" name="Step1"></a>
-<p>
- When deciding on a coding standard, take the time to write a few classes which use a particular style. Should the curly
- braces be flush with the indentation of the line above? Do we use tabs or spaces? Are abbreviations permitted? If so,
- do we have a short list?
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_oCfyEWE-EdqnIZeW8YpHcA" name=" Discuss Standard " guid="_oCfyEWE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step2" name="Step2"></a>
-<p>
- The coding standard for a project should be as simple as possible. The goal is not to forbid error prone constructs,
- but rather to make the code as communicative and uniform as possible so it can be understood and worked on readily. If
- the team cannot reach consensus, use majority rule. Having a standard is more important than the specific details.
-</p>
-<p>
- <br />
- &nbsp;
-</p></sectionDescription>
- </sections>
- <purpose><a id="XE_define_coding_standard__activity_definition" name="XE_define_coding_standard__activity_definition"></a>
-<ul>
- <li>
- To aid clarity by making the style of code as familiar as possible.
- </li>
-</ul></purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/xp/tasks/define_customer_test.xmi b/XP/xp/tasks/define_customer_test.xmi
deleted file mode 100644
index 33b87e1..0000000
--- a/XP/xp/tasks/define_customer_test.xmi
+++ /dev/null
@@ -1,26 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-WgE0oiE2yddCOMnfzL25Gw" name="define_customer_test,{DCDB57BE-4233-4CF8-90CE-70D6808F92B0}" guid="-WgE0oiE2yddCOMnfzL25Gw" version="1.0.0">
- <sections xmi:id="_oGorMGE-EdqnIZeW8YpHcA" name="Understand the Story " guid="_oGorMGE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step1" name="Step1"></a>
-<p>
- Since the customer tests are automated, the customer has to be very specific about what the test will do. It is
- impossible to do this if the customer does not understand the story in intimate detail from a user perspective. Writing
- the customer tests will force the customer to go into all the details of the story. Stories must be testable.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_oGorMWE-EdqnIZeW8YpHcA" name="Define Test Criteria " guid="_oGorMWE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step2" name="Step2"></a>
-<p>
- Once the story is well understood and selected for the iteration, the automated customer tests are written. If the
- customer team includes testers, the customer could communicate the test criteria to the tester. This can be verbal or
- written. The criterion describes the tests for the normal and exceptional behavior of the system.<br />
- &nbsp;
-</p></sectionDescription>
- </sections>
- <purpose><a id="XE_define_customer_test__activity_definition" name="XE_define_customer_test__activity_definition"></a>
-<ul>
- <li>
- Define the criteria under which the customer will deem a story complete.
- </li>
-</ul></purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/xp/tasks/define_iteration_plan.xmi b/XP/xp/tasks/define_iteration_plan.xmi
deleted file mode 100644
index 7d63cdd..0000000
--- a/XP/xp/tasks/define_iteration_plan.xmi
+++ /dev/null
@@ -1,61 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-BWG5zUGb8c25kuLJ3ck8ng" name="define_iteration_plan,{849E3635-6FCD-4FAD-A007-CA34B9998622}" guid="-BWG5zUGb8c25kuLJ3ck8ng" version="1.0.0">
- <sections xmi:id="_oQSWcGE-EdqnIZeW8YpHcA" name="Preconditions " guid="_oQSWcGE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="PreCond" name="PreCond"></a>
-<p>
- The steps for this activity are part of XP iteration planning. In order for this activity to be successful, the
- following preconditions should be met:
-</p>
-<ul>
- <li>
- <div align="left">
- The customer understands the user stories very well.
- </div>
- </li>
- <li>
- The customer has defined acceptance criteria for the stories.
- </li>
- <li>
- All team members that will be involved in developing the stories should be present.
- </li>
-</ul></sectionDescription>
- </sections>
- <sections xmi:id="_oQSWcWE-EdqnIZeW8YpHcA" name="Customer Presents the User Stories " guid="_oQSWcWE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step1" name="Step1"></a>
-<p>
- The customer selects a list of user stories that he would like included in the next iteration. The stories typically
- come from the release plan but may also include new stories that were not originally planned. The customer explains the
- stories and the acceptance test criteria to the developers.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_oQSWcmE-EdqnIZeW8YpHcA" name="Developers Break Down Stories " guid="_oQSWcmE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step2" name="Step2"></a>
-<p>
- The developers discuss how to implement the story and break it down into engineering tasks. Tasks should include
- everything necessary to get the story to pass the customer's acceptance test.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_oQSWc2E-EdqnIZeW8YpHcA" name="Developers Sign Up and Estimate " guid="_oQSWc2E-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step3" name="Step3"></a>
-<p>
- The developers sign up for all the tasks. The developers put estimates only for the tasks they have personally signed
- up for.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_oQSWdGE-EdqnIZeW8YpHcA" name="Customer Adjusts Iteration Plan " guid="_oQSWdGE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step4" name="Step4"></a>
-<p>
- If the sum of all the task estimates is greater than the sum of all the tasks done by the team during the last
- iteration, the customer must remove some work in order to&nbsp;respect the team's iteration velocity.
-</p></sectionDescription>
- </sections>
- <purpose><a id="XE_define_iteration__activity_definition" name="XE_define_iteration__activity_definition"></a>
-<ul>
- <li>
- Establish what can be built during the iteration, given the team's constraints.
- </li>
- <li>
- Allow the team to manage itself at the task level.
- </li>
-</ul></purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/xp/tasks/define_release_plan.xmi b/XP/xp/tasks/define_release_plan.xmi
deleted file mode 100644
index 39fc546..0000000
--- a/XP/xp/tasks/define_release_plan.xmi
+++ /dev/null
@@ -1,78 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-7gEOFFavlkSqwIoTNrvfJA" name="define_release_plan,{D755C076-8E63-4A24-89AA-A7D64E368B90}" guid="-7gEOFFavlkSqwIoTNrvfJA" version="1.0.0">
- <sections xmi:id="_oOauMGE-EdqnIZeW8YpHcA" name="Preparation " guid="_oOauMGE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Prep" name="Prep"></a>
-<p>
- The steps for this activity are part of XP release planning. In order for this activity to be successful, the following
- preconditions should be met:
-</p>
-<ul>
- <li>
- The customer has enough user stories at present to fill at least one release.
- </li>
- <li>
- The customer understands the user stories very well.
- </li>
- <li>
- The customer has defined acceptance criteria for the stories.
- </li>
- <li>
- All team members that will be involved in developing the stories should be present.
- </li>
-</ul></sectionDescription>
- </sections>
- <sections xmi:id="_oOauMWE-EdqnIZeW8YpHcA" name="Customer Presents the User Stories " guid="_oOauMWE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step1" name="Step1"></a>
-<p>
- The customer describes each story to the team and explains the conditions under which the story is going to be
- considered complete.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_oOauMmE-EdqnIZeW8YpHcA" name="Developers Estimate the User Stories " guid="_oOauMmE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step2" name="Step2"></a>
-<p>
- The developers discuss each story and come up with an estimate based on their experience. High-level design discussions
- take place as developers try to understand the story and discuss different ways of implementing it. In some cases, the
- team will not be able to provide a reasonable estimate:
-</p>
-<ul>
- <li>
- They do not understand the story: the team should be asking more questions&nbsp;to the customer.
- </li>
- <li>
- The story is too big: the developers don't have a good grasp of the scope. It should be broken down into smaller
- stories.
- </li>
- <li>
- They don't know how to do it: they will need to do some research first.
- </li>
-</ul>
-<p>
- Be careful to avoid analysis paralysis. The first few times the team estimates stories, it may take as long as an hour
- to estimate a story. The second story should take less time. Your goal should be to be able to estimate a story in only
- a few minutes.
-</p>
-<p>
- As a rule of thumb, story estimates should not exceed the iteration length based on a pair of people dedicated to the
- story. When stories exceed the iteration length, the customer splits the story.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_oOg00GE-EdqnIZeW8YpHcA" name="Customer Prioritizes Stories " guid="_oOg00GE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step3" name="Step3"></a>
-<p>
- Once all the stories have an estimated cost, the customer can prioritize the stories into the release plan.The customer
- organizes stories into iterations and sequences of iterations into releases. The sum of all story points in each
- iteration cannot exceed the team's velocity. At the beginning of the project, you will have to guess the team's
- velocity. Try one third of the ideal programmer time available in an iteration. After a few iterations, revisit the
- plan and use the team's measured velocity. See more on release planning in the <a class="elementLinkWithUserText"
- href="./../../xp/guidances/guidelines/planning_game,6.7335956461328426E-307.html"
- guid="6.7335956461328426E-307">planning game guideline</a>.
-</p></sectionDescription>
- </sections>
- <purpose><a id="XE_define_release__activity_definition" name="XE_define_release__activity_definition"></a>
-<ul>
- <li>
- To estimate the content and delivery date for a release of the product.
- </li>
-</ul></purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/xp/tasks/develop_xp_vision.xmi b/XP/xp/tasks/develop_xp_vision.xmi
deleted file mode 100644
index 64a3858..0000000
--- a/XP/xp/tasks/develop_xp_vision.xmi
+++ /dev/null
@@ -1,80 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-W67fNE0rT1c2PM-20yXbrw" name="develop_xp_vision,{A8708FFB-BB20-40AF-BEF2-7A8A814FF74D}" guid="-W67fNE0rT1c2PM-20yXbrw" changeDate="2005-12-02T08:56:23.177-0800" version="1.0.0">
- <sections xmi:id="_oB58MGE-EdqnIZeW8YpHcA" name="Gain Agreement on the Problem Being Solved " guid="_oB58MGE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Gain" name="Step1"></a>
-<p>
- One of the simplest ways to gain agreement on the definition of the problem is to write it down and see if everyone
- agrees.
-</p>
-<p>
- Ask the group: What is the problem?
-</p>
-<p>
- It is very common to rush headlong into defining the solution rather than taking time to first understand the problem.
- Write down the problem and see if you can get everyone to agree on the definition.
-</p>
-<p>
- Then ask the group again: What is the problem, really?
-</p>
-<p>
- Search for root causes or the "problem behind the problem". The real problem is often hiding behind what is perceived
- as a problem. Don't accept the first statement of a problem. Continue to ask "why?" to find out what the problem
- "really" is. Sometimes the group can be so focused on an envisioned solution that it is hard to get them to formulate
- the underlying problem. In such cases, it can be beneficial to explore the benefits of the solution and then try to
- find the problems being solved by those benefits. You can then explore whether or not those problems are "real"
- problems in the organization.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_oB58MWE-EdqnIZeW8YpHcA" name="Identify Stakeholders " guid="_oB58MWE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Identify" name="Step2"></a>
-<ul>
- <li>
- Who are the users of the system?
- </li>
- <li>
- Who is the economic buyer for the system?
- </li>
- <li>
- Who else will be affected by the output that the system produces?
- </li>
- <li>
- Who will evaluate and bless the system when it is delivered and deployed?
- </li>
- <li>
- Are there any other internal or external users of the system whose needs must be addressed?
- </li>
- <li>
- Who will maintain the new system?
- </li>
- <li>
- Is there anyone else?
- </li>
- <li>
- Okay, is there anyone else?
- </li>
-</ul></sectionDescription>
- </sections>
- <sections xmi:id="_oB58MmE-EdqnIZeW8YpHcA" name="Define the Primary Features of the System " guid="_oB58MmE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Define" name="Step3"></a>
-<p>
- What primary features of the system allow the stakeholders to solve their problems? This should be a list of very
- high-level features.<br />
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_oB58M2E-EdqnIZeW8YpHcA" name="Communicate the Vision " guid="_oB58M2E-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Com" name="Step4"></a>
-<p>
- Once agreed upon by the stakeholders, the vision is communicated clearly to all project team members. When the project
- starts, XP teams often write up the vision on one of the whiteboards in the team's open workspace so it can easily be
- seen by all team members. After a short time, the team usually internalizes the vision and no longer needs the
- reminder.
-</p></sectionDescription>
- </sections>
- <purpose><a id="XE_define_vision__activity_definition" name="XE_define_vision__activity_definition"></a>
-<ul>
- <li>
- The Vision defines the stakeholder's view of the product being developed specified in terms of the stakeholder's
- key needs and features.
- </li>
-</ul></purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/xp/tasks/estimate_task.xmi b/XP/xp/tasks/estimate_task.xmi
deleted file mode 100644
index 132fb8c..0000000
--- a/XP/xp/tasks/estimate_task.xmi
+++ /dev/null
@@ -1,25 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-9EbmL3qGJ_TemB83cJublQ" name="estimate_task,{EC483990-8129-4AE3-893C-0F7406C128DA}" guid="-9EbmL3qGJ_TemB83cJublQ" version="1.0.0">
- <sections xmi:id="_oCfyEmE-EdqnIZeW8YpHcA" name="Understand the Task " guid="_oCfyEmE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step1" name="Step1"></a>
-<p>
- Task breakdown of a user story is done at iteration planning by the whole team. Since all team members are present,
- they should have a fairly good understanding of the tasks. If not, the team is there to help them.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_oCfyE2E-EdqnIZeW8YpHcA" name="Give an Estimate Based on Experience " guid="_oCfyE2E-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step3" name="Step2"></a>
-<p>
- The person giving the estimate can use his personal experience to give an estimate based on a similar task he has done
- before. If the experience is not there, other team members can help by providing their input based on their own
- experience. Very often, pairs will form for specific tasks at this stage. The most important aspect to keep in mind is
- that the person responsible for the task is the one giving the estimate.
-</p></sectionDescription>
- </sections>
- <purpose><a id="XE_estimate_task__activity_definition" name="XE_estimate_task__activity_definition"></a>
-<ul>
- <li>
- Provide a fine-grain estimate that will be used in iteration planning.
- </li>
-</ul></purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/xp/tasks/estimate_user_story.xmi b/XP/xp/tasks/estimate_user_story.xmi
deleted file mode 100644
index 6134cb5..0000000
--- a/XP/xp/tasks/estimate_user_story.xmi
+++ /dev/null
@@ -1,49 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-Z9xFd9JTnJuNN5S27p06UQ" name="estimate_user_story,{23A924D3-5989-40DD-86A9-9D8FCFB8AE52}" guid="-Z9xFd9JTnJuNN5S27p06UQ" version="1.0.0">
- <sections xmi:id="_oEqVQGE-EdqnIZeW8YpHcA" name=" Understand the User Story " guid="_oEqVQGE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step1" name="Step1"></a>
-<p>
- To provide an estimate that is fairly accurate, the developers need to have a good grasp of the story. During release
- planning, the customer describes each user story and presents acceptance test criteria. The developers can ask
- questions until they are satisfied that they understand the most important aspects of what the customer is asking for.
- Avoid analysis paralysis; there are many stories.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_oEqVQWE-EdqnIZeW8YpHcA" name=" Discuss Possible Implementations " guid="_oEqVQWE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step2" name="Step2"></a>
-<p>
- Sometimes the team can just estimate the story from their gut. Other times the story may not quite fit prior
- experiences, and the team may have to explore potential design alternatives. Do not settle on a specific design. If
- competing ideas take about the same amount of time, pick an estimate and move on to the next story. Avoid analysis
- paralysis; there are many stories.
-</p>
-<p>
- When there is deep uncertainty, the team can request the time to do some research (spike) in order to give a more
- realistic estimate.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_oEqVQmE-EdqnIZeW8YpHcA" name=" Give an Estimate Based on Experience " guid="_oEqVQmE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step3" name="Step3"></a>
-<p>
- If the team has done similar work before, they simply extrapolate from previous work. For work the team is unfamiliar
- with, a spike can provide just enough information to know what is possible and how long the effort is likely to last.
- An experienced XP team can estimate most stories in a few minutes or less. Avoid analysis paralysis; there are many
- stories.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_oEqVQ2E-EdqnIZeW8YpHcA" name=" Ask the Customer to Split the Story " guid="_oEqVQ2E-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Ask" name="Ask"></a>
-<p>
- Story estimates should not exceed the iteration duration for a pair of programmers. If the estimate is too big, have
- the customer split the story. People are better at estimating smaller pieces of work. Long estimates tend to go over
- budget. It would not be uncommon to take a four-week story and break it down only to discover it is four two-week
- stories.
-</p></sectionDescription>
- </sections>
- <purpose><a id="XE_estimate_user_story__activity_definition" name="XE_estimate_user_story__activity_definition"></a>
-<ul>
- <li>
- Provide a high-level estimate that will be used in release planning.
- </li>
-</ul></purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/xp/tasks/explain_process.xmi b/XP/xp/tasks/explain_process.xmi
deleted file mode 100644
index c2e560c..0000000
--- a/XP/xp/tasks/explain_process.xmi
+++ /dev/null
@@ -1,46 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-I3yOxhkbTu3OCbzQ0sUsyA" name="explain_process,{1FA31F30-1F90-4BD3-9F0D-57DF66FC6727}" guid="-I3yOxhkbTu3OCbzQ0sUsyA" version="1.0.0">
- <sections xmi:id="_oNuxsGE-EdqnIZeW8YpHcA" name=" General " guid="_oNuxsGE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Prep" name="Prep"></a>
-<p>
- As a team begins to use the <a class="elementLink"
- href="./../../xp/guidances/concepts/xp_practices,2.2937799026801584E-305.html" guid="2.2937799026801584E-305">XP
- Practices</a>, the coach must prepare the team to use the practices effectively.
-</p>
-<p>
- This includes the following:
-</p>
-<ul>
- <li>
- Teach the team about XP and ensure that the team has a common understanding of the practices.
- </li>
- <li>
- Facilitate the team's decision as to how aggressively the transition to the new practices will be.
- </li>
- <li>
- Facilitate a team activity to identify what obstacles they will face in using the practices effectively. Ensure
- that the team has a plan to overcome those obstacles.
- </li>
- <li>
- Facilitate a team activity to identify what constraints will require adaptation of the practices. Ensure that these
- adaptations are understood by the <a class="elementLink"
- href="./../../xp/guidances/concepts/whole_team,7.89591827591278E-306.html" guid="7.89591827591278E-306">Whole
- Team</a>.
- </li>
-</ul>
-<p>
- Because there are many roles in the team, a coach needs to have a good understanding of the all different activities in
- the process. In some cases, there might be more than one coach on a team to address needs. There might be a coach for
- the developer team and one for the customer team, for example.
-</p>
-<p>
- Use external expertise as necessary to ensure the team starts with a strong base of knowledge on which to succeed.
-</p></sectionDescription>
- </sections>
- <purpose><a id="XE_explain_process__activity_definition" name="XE_explain_process__activity_definition"></a>
-<ul>
- <li>
- Make sure the team has a common understanding of the fundamentals.
- </li>
-</ul></purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/xp/tasks/implement_spike.xmi b/XP/xp/tasks/implement_spike.xmi
deleted file mode 100644
index 3e8478e..0000000
--- a/XP/xp/tasks/implement_spike.xmi
+++ /dev/null
@@ -1,27 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-DbsgXRUjLhsnnpioGI2b3g" name="implement_spike,{85BE1C0E-F389-4246-BB22-9A52988018B7}" guid="-DbsgXRUjLhsnnpioGI2b3g" version="1.0.0">
- <sections xmi:id="_oCl4sGE-EdqnIZeW8YpHcA" name=" General " guid="_oCl4sGE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Prep" name="Prep"></a>
-<p>
- A spike is an experiment. It helps the team find some bit of information it is missing in order to go forward. As such,
- spikes are an important tool to minimize project risks.
-</p>
-<p>
- Spikes are very often called for during the planning process when the team is unsure about how long particular stories
- will take. In this case, the spike consists of trying out different ways of implementing the story. The team will do
- the bare minimum to gain an understanding of how to do the story so that they can provide a reasonable estimate. Very
- often, the code generated by spikes is literally thrown away. The value of the spike is in the information that was
- missing, namely a good estimate in this case.
-</p>
-<p>
- <br />
- &nbsp;
-</p></sectionDescription>
- </sections>
- <purpose><a id="XE_implement_spike__activity_definition" name="XE_implement_spike__activity_definition"></a>
-<ul>
- <li>
- Research a missing piece of information.
- </li>
-</ul></purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/xp/tasks/improve_team_skills.xmi b/XP/xp/tasks/improve_team_skills.xmi
deleted file mode 100644
index dc4de2a..0000000
--- a/XP/xp/tasks/improve_team_skills.xmi
+++ /dev/null
@@ -1,40 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-32JWpciwfc2e7HgQavJDkw" name="improve_team_skills,{1C4325AC-17DE-4CD0-8AA0-4B210570579F}" guid="-32JWpciwfc2e7HgQavJDkw" version="1.0.0">
- <sections xmi:id="_oNuxsWE-EdqnIZeW8YpHcA" name="General " guid="_oNuxsWE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Prep" name="Prep"></a>
-<p>
- Teams are made up of individuals with an imperfect balance of technical expertise, domain or customer awareness, and
- people skills. The team must continually identify and improve those skill areas that are lacking. The XP Coach helps
- ensure that this happens.
-</p>
-<p>
- The coach must always be aware of what difficulties the team is having in succeeding on their project. Some of these
- will be evident, often communicated directly by the team. Some will be subtle with little awareness on the team that
- there is a problem. To maintain this awareness, the coach must balance time spent in the trenches with the team,
- observing specific use of the practices, with time spent reflecting on the team's capabilities, unencumbered by the
- direct pressures of the project.
-</p>
-<p>
- With an awareness of where the team needs improvement, the coach must help the team integrate improvement activities
- into their work. Improvement activities need to be prioritized just as User Stories do. Different options will exist to
- address skill improvement needs. The coach should be familiar with a wide variety of activities, courses, and games to
- help people further their skills in a given practice. The coach acts as a conduit that connects the team with the
- expertise required to improve a skill whether that other resource is in the organization or is an external resource.
-</p>
-<p>
- One of the most effective tools to help the team identify areas for improvement is the Retrospective, a form of project
- review. Techniques for this are described in Norm Kerth's book, <i>Project Retrospectives</i> [<a
- class="elementLinkWithUserText"
- href="./../../xp/guidances/supportingmaterials/xp_and_agile_process_references,6.191633934532389E-306.html#KER01"
- guid="6.191633934532389E-306">KER01</a>]. Many teams have adapted the tools from the book to perform abbreviated
- retrospectives after each iteration in addition to the more comprehensive session held at the completion of a full
- project.
-</p></sectionDescription>
- </sections>
- <purpose><a id="XE_improve_team_skills__activity_definition" name="XE_improve_team_skills__activity_definition"></a>
-<ul>
- <li>
- Help the team members identify skills that need improvement and implement activities to improve those skills.
- </li>
-</ul></purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/xp/tasks/integrate_system.xmi b/XP/xp/tasks/integrate_system.xmi
deleted file mode 100644
index 6a05e47..0000000
--- a/XP/xp/tasks/integrate_system.xmi
+++ /dev/null
@@ -1,26 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="--tP2hgRfEkZPGYvy1y0GZQ" name="integrate_system,{70FEC254-8555-4844-AD82-68367E25F082}" guid="--tP2hgRfEkZPGYvy1y0GZQ" version="1.0.0">
- <sections xmi:id="_oE9QMGE-EdqnIZeW8YpHcA" name=" Run All Unit Tests for the System " guid="_oE9QMGE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step1" name="Step1"></a>
-<p>
- While you and your pair partner are working on a task, you run unit tests to make sure you are not introducing side
- effect defects. As a system evolves, it may become impractical to run all the unit tests for the system for every
- change made. In this case, you may choose a subset of the unit tests to run after every code change. When a task is
- completed or you feel that you have a piece you can integrate or you are uncertain for any reason, run all of the unit
- tests for the system.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_oE9QMWE-EdqnIZeW8YpHcA" name=" Check in Code " guid="_oE9QMWE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step2" name="Step2"></a>
-<p>
- If all of the unit test in the system passed, check in your code and produce a system build.
-</p></sectionDescription>
- </sections>
- <purpose><a id="XE_integrate_and_build__activity_definition" name="XE_integrate_and_build__activity_definition"></a>
-<ul>
- <li>
- To produce a runnable executable of the application under development that can be used to evaluate progress and
- provide feedback
- </li>
-</ul></purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/xp/tasks/keep_process_on_track.xmi b/XP/xp/tasks/keep_process_on_track.xmi
deleted file mode 100644
index 8f17756..0000000
--- a/XP/xp/tasks/keep_process_on_track.xmi
+++ /dev/null
@@ -1,29 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-SH3UFVsPViLT3hOalbaxgA" name="keep_process_on_track,{80725BC3-E2BA-4860-8F07-4A34B96FBB2A}" guid="-SH3UFVsPViLT3hOalbaxgA" version="1.0.0">
- <sections xmi:id="_oN04UGE-EdqnIZeW8YpHcA" name="General " guid="_oN04UGE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Prep" name="Prep"></a>
-<p>
- The <a class="elementLink" href="./../../xp/guidances/concepts/whole_team,7.89591827591278E-306.html"
- guid="7.89591827591278E-306">Whole Team</a> needs to be very focused on the goals of the project. The development
- practices enable the project goals to be achieved. The challenge of focusing on the project goals and focusing the
- disciplined and effective use of the practices is a constant challenge for the team.
-</p>
-<p>
- The <a class="elementLink" href="./../../xp/roles/xp_tracker,{D8FE277E-4F9A-47EB-855F-C451D601BBAF}.html"
- guid="{D8FE277E-4F9A-47EB-855F-C451D601BBAF}">XP Tracker</a> collects data and reports it to the team. This data
- provides guidance as to whether the project is on a trajectory to meet the project goals. The data also monitors the
- team's use of the practices.
-</p>
-<p>
- The <a class="PresentationName" href="./../../xp/roles/xp_coach,{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}.html"
- guid="{9C440605-FF0E-4D37-A774-BBF8B5F47AB6}">XP Coach</a> ensures that the team is collecting and using the data to
- ensure that the project and process goals are achieved.
-</p></sectionDescription>
- </sections>
- <purpose><a id="XE_keep_process_on_track__activity_definition" name="XE_keep_process_on_track__activity_definition"></a>
-<ul>
- <li>
- Ensure the process is being used effectively towards the project goals.
- </li>
-</ul></purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/xp/tasks/refactor_code.xmi b/XP/xp/tasks/refactor_code.xmi
deleted file mode 100644
index 639937b..0000000
--- a/XP/xp/tasks/refactor_code.xmi
+++ /dev/null
@@ -1,60 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-IoT5LZUu3vnNFp-pwPUMHA" name="refactor_code,{3DD335BB-45F6-49C7-B17A-90652C73A485}" guid="-IoT5LZUu3vnNFp-pwPUMHA" version="1.0.0">
- <sections xmi:id="_oCr_UGE-EdqnIZeW8YpHcA" name="Identify Poor Design " guid="_oCr_UGE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step1" name="Step1"></a>
-<p>
- While developing, requirements change and previous design decisions can be invalidated. A new feature is added, you get
- it to work, but the structure and clarity of the code can degrade. You could leave it, and the design will slowly rot,
- or you could improve the design on the spot. Refactoring is about improving the design.
-</p>
-<p>
- A simple design has these four characteristics, listed in priority order:
-</p>
-<ul>
- <li>
- The system runs all the tests.
- </li>
- <li>
- It contains no duplicate code.
- </li>
- <li>
- The code states the programmers' intent very clearly.
- </li>
- <li>
- It contains the fewest possible number of classes and methods.
- </li>
-</ul>
-<p>
- A good resource for gaining refactoring knowledge is Martin Fowler's book: <i>Refactoring - Improving the Design of
- Existing Code</i> [<a class="elementLinkWithUserText"
- href="./../../xp/guidances/supportingmaterials/xp_and_agile_process_references,6.191633934532389E-306.html#FOW99"
- guid="6.191633934532389E-306">FOW99</a>]. Martin discusses the idea of bad code smells, how to detect them, what harm
- they will do to your software, and how to fix them.
-</p>
-<p>
- During development, you should look at the code refactoring with an open mind and find its weaknesses. Clarify the
- code; fix what needs to be fixed. As you discover these smells, you should work to eliminate them before proceeding to
- the next test case. Save some time before you check-in your code to step back and look it over. Identify duplicate code
- sections and places where the design intent is not clear.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_oCr_UWE-EdqnIZeW8YpHcA" name="Refactor " guid="_oCr_UWE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step2" name="Step2"></a>
-<p>
- Refactoring involves making changes to your code which improve its structure without modifying its behavior. Martin
- Fowler's Refactoring book lists over sixty refactorings to handle particular code situations. The goal of each of them
- is to reduce duplication in the code base and increase clarity. Leave your code clean, simple, and free from
- duplication.
-</p>
-<p>
- As the structure of your code base evolves, you choose names which aid your understanding of the functionality
- specified by the code. This system of names becomes the vocabulary for your team's discussion of design.
-</p></sectionDescription>
- </sections>
- <purpose><a id="XE_refactor_code__activity_definition" name="XE_refactor_code__activity_definition"></a>
-<ul>
- <li>
- To keep the design of the system clear and ready for change.
- </li>
-</ul></purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/xp/tasks/report_acceptance_test_result.xmi b/XP/xp/tasks/report_acceptance_test_result.xmi
deleted file mode 100644
index 6063b10..0000000
--- a/XP/xp/tasks/report_acceptance_test_result.xmi
+++ /dev/null
@@ -1,21 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-p0GGwGNG5O8Dn6O6ZzivIw" name="report_acceptance_test_result,{52D6E875-C46B-454B-A39C-CEC21603AF5C}" guid="-p0GGwGNG5O8Dn6O6ZzivIw" version="1.0.0">
- <sections xmi:id="_oH6dkGE-EdqnIZeW8YpHcA" name=" General " guid="_oH6dkGE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Prep" name="Prep"></a>
-<p>
- This activity communicates to the whole team the progress they have made. As this is a major factor in motivation, XP
- teams very often use big, visible charts to show their progress. These charts are very often placed in the open
- workspace and visible to anyone who enters the team area.
-</p>
-<p>
- A suitable chart would track the number of customer tests defined and running by iteration. The vertical axis is the
- number of tests; the horizontal axis is the iteration number.
-</p></sectionDescription>
- </sections>
- <purpose><a id="XE_report_customer_test_result__activity_definition" name="XE_report_customer_test_result__activity_definition"></a>
-<ul>
- <li>
- Provide the team with a clear understanding of progress.
- </li>
-</ul></purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/xp/tasks/report_project_status.xmi b/XP/xp/tasks/report_project_status.xmi
deleted file mode 100644
index 5fa5970..0000000
--- a/XP/xp/tasks/report_project_status.xmi
+++ /dev/null
@@ -1,53 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-WOPGmKUuYbvVeVHp0sgEgw" name="report_project_status,{ED94150E-EE14-47BF-97F5-F1EC7130EEEC}" guid="-WOPGmKUuYbvVeVHp0sgEgw" version="1.0.0">
- <sections xmi:id="_oOzvwGE-EdqnIZeW8YpHcA" name="Gather the Information " guid="_oOzvwGE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step1" name="Step1"></a>
-<p>
- The most important information about the status of the project is the updated release plan. The release plan defines
- the current view of the release content and availability. Metrics, such as the team's velocity, can also be provided.
- Typically, metrics are tracked for the purpose of helping the team improve some aspects of development they are having
- problems with. These metrics can be presented as part of project status.
-</p>
-<p>
- The velocity metric can be abused. Keep in mind that there is no valid comparison of velocities between teams. The most
- important thing about a team's velocity is the stability of the velocity. This allows the team to predict what it can
- accomplish.
-</p>
-<p>
- Other meaningful metrics:
-</p>
-<ul>
- <li>
- Defined stories over time, overlaid with completed stories
- </li>
- <li>
- Defined customer tests overlaid with running customer tests
- </li>
- <li>
- Number of unit tests tracked over time
- </li>
- <li>
- Unit test coverage
- </li>
-</ul>
-<p>
- The team's significant metrics are recorded on flip chart paper and hung in the team's open workspace.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_oOzvwWE-EdqnIZeW8YpHcA" name=" Communicate the Status " guid="_oOzvwWE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step2" name="Step2"></a>
-<p>
- Since 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. It lowers significantly the risk of disconnect between
- the development team and the stakeholders. It also provides the team with data they can use to improve their
- development process. Stakeholders should come to the open workspace and view the project status that is recorded on the
- walls of the open workspace. They can experience the progress being made by the team first hand.
-</p></sectionDescription>
- </sections>
- <purpose><a id="XE_report_project_status__activity_definition" name="XE_report_project_status__activity_definition"></a>
-<ul>
- <li>
- Communicate to stakeholders the status of the project.
- </li>
-</ul></purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/xp/tasks/resolve_conflicts.xmi b/XP/xp/tasks/resolve_conflicts.xmi
deleted file mode 100644
index 08602f7..0000000
--- a/XP/xp/tasks/resolve_conflicts.xmi
+++ /dev/null
@@ -1,27 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-L85wOCiwe2O8D8CISEGGGg" name="resolve_conflicts,{1B23700D-02B0-476F-A3DE-6F63A5407151}" guid="-L85wOCiwe2O8D8CISEGGGg" changeDate="2006-11-09T14:20:06.801-0800" version="1.0.0">
- <mainDescription><p>
- Software projects require the coordinated efforts of many people. The <a class="elementLink"
- href="./../../xp/guidances/concepts/xp_practices,2.2937799026801584E-305.html" guid="2.2937799026801584E-305">XP
- Practices</a> leverage the ability of teams to collaborate and communicate about decisions and activities on the
- project. Because team members are working together in an <a class="elementLink"
- href="./../../xp/guidances/guidelines/open_workspace,3.269440809144354E-305.html" guid="3.269440809144354E-305">Open
- Workspace</a>, interpersonal conflicts are visible, not hidden by the separation of the cubicles. One byproduct of
- increased collaboration, communication, and feedback will be increased conflict. Unmanaged, this conflict may increase
- the risk to the project. XP, as a process, does not try to solve all of the problems that occur on a software project,
- it just enables the people to solve them.
-</p>
-<p>
- The XP Coach must make sure these conflicts are managed. The coach must help the team develop an environment of
- openness, where conflicts can be discussed and resolved. Conflicts left unresolved, like defects left undetected, are
- usually more disruptive and ultimately costly to fix. At times, the coach will take ownership to resolve a conflict on
- the team or across teams, but over time, the coach must ensure that the team is capable of resolving most conflicts on
- their own.
-</p></mainDescription>
- <purpose><a id="XE_resolve_conflicts__activity_definition" name="XE_resolve_conflicts__activity_definition"></a>
-<ul>
- <li>
- Prevent disagreements from reducing the team's productivity.
- </li>
-</ul></purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/xp/tasks/run_acceptance_test.xmi b/XP/xp/tasks/run_acceptance_test.xmi
deleted file mode 100644
index d965c78..0000000
--- a/XP/xp/tasks/run_acceptance_test.xmi
+++ /dev/null
@@ -1,17 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-6RyabSc-ZUEtoEKb90BCbg" name="run_acceptance_test,{D4E30732-30D3-4C75-8C69-D2F15313F1A9}" guid="-6RyabSc-ZUEtoEKb90BCbg" version="1.0.0">
- <sections xmi:id="_oNI70GE-EdqnIZeW8YpHcA" name=" General " guid="_oNI70GE-EdqnIZeW8YpHcA">
- <sectionDescription><p>
- This task consists of running all the customer or acceptance tests to ensure that all previously completed user stories
- are still working. A lot of XP teams run those tests on a daily basis as part of their automated daily build. Other
- teams run those tests every time a new story is added to the pool of completed stories to ensure that a new story has
- not caused previous ones to fail.
-</p></sectionDescription>
- </sections>
- <purpose><a id="XE_run_customer_test__activity_definition" name="XE_run_customer_test__activity_definition"></a>
-<ul>
- <li>
- Execute the automated acceptance test and gather results.
- </li>
-</ul></purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/xp/tasks/setup_programmer_environment.xmi b/XP/xp/tasks/setup_programmer_environment.xmi
deleted file mode 100644
index cba62e8..0000000
--- a/XP/xp/tasks/setup_programmer_environment.xmi
+++ /dev/null
@@ -1,50 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-1rVEQRCvrcicCdhpuuIZ8w" name="setup_programmer_environment,{D3AA9FEE-AAD9-4884-BF71-425E122110A7}" guid="-1rVEQRCvrcicCdhpuuIZ8w" version="1.0.0">
- <sections xmi:id="_oPGqsGE-EdqnIZeW8YpHcA" name="Remove Cubicle Walls and Other Impediments " guid="_oPGqsGE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step1" name="Step1"></a>
-<p>
- In XP, we attempt to maximize communication within the team. Programmers should be able to ask quick questions&nbsp;to
- other developers and overhear conversations which raise their understanding of the system. When team members are
- segregated into offices or cubicles, there is more of a chance that islands of knowledge will grow in isolation. This
- leads to redundant work and often work that is less integrated than if it had been done in an open space subject to the
- contributions of overhearing team members.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_oPNYYGE-EdqnIZeW8YpHcA" name="Place Computers in Positions Comfortable for Pairing " guid="_oPNYYGE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step2" name="Step2"></a>
-<p>
- Standard office furniture is not designed for pair programming. In particular, desks with leg wells seem to make
- pairing impossible. Ideally, computers should be placed on tables which have enough room for two people to sit side by
- side and trade turns working at the keyboard. Comfort should be your guide. If you are not comfortable, you will get
- fatigued easily and you certainly won't be doing the work you are capable of.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_oPNYYWE-EdqnIZeW8YpHcA" name="Standardize on Tools and Development Setup " guid="_oPNYYWE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step3" name="Step3"></a>
-<p>
- In XP, we find that work goes better when everyone is able to help everyone else. One simple thing that can get in the
- way is computer setup. If you use an editor with one set of key bindings and another team member uses another, it will
- be difficult for either of you to go to each other's computers and feel comfortable enough to drive. While this seems
- like a minor point, it makes a sizable difference on how effectively a team can collaborate. In many XP teams, machines
- are unassigned. You simply go to a free machine in the morning and check out the code that you need to start working
- on.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_oPNYYmE-EdqnIZeW8YpHcA" name="Establish Clear Line of Sight to Customer " guid="_oPNYYmE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step4" name="Step4"></a>
-<p>
- To work effectively with XP, you must be able to ask questions&nbsp;to your customer. If you are not able to ask
- questions and get timely answers, you are either bottlenecked on a task or tempted to guess and hope that you don't
- have to roll back your work later. When setting up your environment, establish a clear line of sight to the customer.
- The customer should be working in the same room as the team. If this is not possible, the customer should be no more
- than a phone call away.
-</p></sectionDescription>
- </sections>
- <purpose><a id="XE_setup_programmer_environment__activity_definition"
-name="XE_setup_programmer_environment__activity_definition"></a>
-<ul>
- <li>
- To make it easy to work collaboratively and raise the communication level of the team
- </li>
-</ul></purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/xp/tasks/setup_tester_environment.xmi b/XP/xp/tasks/setup_tester_environment.xmi
deleted file mode 100644
index 4379353..0000000
--- a/XP/xp/tasks/setup_tester_environment.xmi
+++ /dev/null
@@ -1,23 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-OPKuXnenD910fJyGKA99aw" name="setup_tester_environment,{B4F9BDCC-629E-485B-9EFA-318F8D5A37BC}" guid="-OPKuXnenD910fJyGKA99aw" version="1.0.0">
- <sections xmi:id="_oNI70WE-EdqnIZeW8YpHcA" name=" General " guid="_oNI70WE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Prep" name="Prep"></a>
-<p>
- Testers will need to setup some kind of hardware/software environment in order to run the customer acceptance tests.
- The environment might require the installation of specific software test tools or the OS might require specific
- environment settings. Try to replicate as much as possible a typical end-user environment when running the tests. Tests
- may require setting up multiple environments (when different operating systems are used, for example).
-</p>
-<p>
- Test environments are not only for testers; it is critical that they are made available to the programmers. Running the
- acceptance tests is their only way to know whether or not they are through with a story and whether they have broken
- previous stories or not.
-</p></sectionDescription>
- </sections>
- <purpose><a id="XE_setup_tester_environment__activity_definition" name="XE_setup_tester_environment__activity_definition"></a>
-<ul>
- <li>
- Create a stable environment for running the customer tests.
- </li>
-</ul></purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/xp/tasks/track_story_completion.xmi b/XP/xp/tasks/track_story_completion.xmi
deleted file mode 100644
index 4264a58..0000000
--- a/XP/xp/tasks/track_story_completion.xmi
+++ /dev/null
@@ -1,24 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-FxF90KOknQ5km30pP0038w" name="track_story_completion,{C333BA32-CF6B-4577-9212-302893043EFF}" guid="-FxF90KOknQ5km30pP0038w" version="1.0.0">
- <sections xmi:id="_oOHzQGE-EdqnIZeW8YpHcA" name=" General " guid="_oOHzQGE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Prep" name="Prep"></a>
-<p>
- Progress in XP is measured in user stories that are passing acceptance tests. A user story is deemed completed when and
- only when it passes all its acceptance tests. Because customer tests are all automated, this task is actually very
- simple since it only consists of running the automated acceptance test suite and comparing the results against the
- plan. If 50% (weighted according to cost) of the stories pass acceptance tests, you are 50% done. Hopefully, less than
- 50% or less of the release has elapsed. If not, it is an indication that the release plan should be revisited.
-</p>
-<p>
- On a regular basis, the tracker presents the progress the team is making in the release. This information can be
- presented in the form of a big, visible chart hanging in the team's open workspace. Progress is often presented as the
- number of stories done vs. planned for the release.
-</p></sectionDescription>
- </sections>
- <purpose><a id="XE_track_release_progress__activity_definition" name="XE_track_release_progress__activity_definition"></a>
-<ul>
- <li>
- Track the progress of the release.
- </li>
-</ul></purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/xp/tasks/track_task_completion.xmi b/XP/xp/tasks/track_task_completion.xmi
deleted file mode 100644
index 6a70108..0000000
--- a/XP/xp/tasks/track_task_completion.xmi
+++ /dev/null
@@ -1,30 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-0iRnQW0M9QDTNqWNijBB5A" name="track_task_completion,{3D22CC4B-ABC4-4CFE-9ACF-C9615E01382C}" guid="-0iRnQW0M9QDTNqWNijBB5A" version="1.0.0">
- <sections xmi:id="_oON54GE-EdqnIZeW8YpHcA" name=" General " guid="_oON54GE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Prep" name="Prep"></a>
-<p>
- Ideally tracking stories is much better than tracking tasks even at the iteration level since the stories can be proved
- to work through the acceptance tests and tasks can't. However, when there are few stories in the iteration, some teams
- also use tasks to help them gain a sense of progress.
-</p>
-<p>
- The tracker simply tracks how many tasks have been done during the iteration and how many are left. This information is
- readily available during the stand-up meetings. Half way through the iteration, the team should have done about half
- the tasks (in terms of the task cost estimates). If not, it is a sign that the iteration plan needs some tweaking. If
- the team is not going as fast as planned, the tweaking may consist of removing one of the stories from the iteration.
- If they are going faster than planned, then the team can ask the customer to bring a new story into the iteration. This
- is how the team iteration velocity will fluctuate over time.
-</p>
-<p>
- On a regular basis, the tracker presents the progress the team is making in the iteration. This information can be
- presented in the form of a big, visible chart hanging in the team's open workspace. Progress is often presented as the
- number of tasks or stories done vs. planned for the iteration.
-</p></sectionDescription>
- </sections>
- <purpose><a id="XE_track_iteration_progress__activity_definition" name="XE_track_iteration_progress__activity_definition"></a>
-<ul>
- <li>
- Track the progress during the iteration.
- </li>
-</ul></purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/xp/tasks/update_iteration_plan.xmi b/XP/xp/tasks/update_iteration_plan.xmi
deleted file mode 100644
index 8b5b49b..0000000
--- a/XP/xp/tasks/update_iteration_plan.xmi
+++ /dev/null
@@ -1,38 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-cU3MzukpGPAtw0wSS23R-g" name="update_iteration_plan,{653F1EF4-2BE5-4CCB-80E7-17CE02B081DC}" guid="-cU3MzukpGPAtw0wSS23R-g" version="1.0.0">
- <sections xmi:id="_oOzvwmE-EdqnIZeW8YpHcA" name="Gather the Information " guid="_oOzvwmE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step1" name="Step1"></a>
-<p>
- The team is responsible for keeping track of its project. Tasks that are completed are marked on the iteration plan. If
- anyone on the team realizes that the team is behind schedule, at any time, the customer is informed as soon as
- possible. The customer can then decide how to change the plan. The tracker may be the first to notice that the
- iteration is in jeopardy. An XP team is considered behind schedule if half the work is not finished halfway through the
- iteration. Ideally, this could be measured by observing that half the customer tests pass halfway through the
- iteration.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_oOzvw2E-EdqnIZeW8YpHcA" name="Update the Plan " guid="_oOzvw2E-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step2" name="Step2"></a>
-<p>
- When it is likely that not all the stories in the release will be finished, the customer must reduce scope. Extending
- the iteration is not an option. The customer either removes whole stories or splits stories and removes scope.
-</p>
-<p>
- When the team has excess capacity in the iteration, the customer is informed. The customer adds additional stories to
- fill the iteration . Customers like it when this happens.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_oOzvxGE-EdqnIZeW8YpHcA" name="Communicate the Plan " guid="_oOzvxGE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step3" name="Step3"></a>
-<p>
- The whole team should be made aware of any changes in the iteration plan so they can focus on the right tasks.
-</p></sectionDescription>
- </sections>
- <purpose><a id="XE_adjust_iteration_scope__activity_definition" name="XE_adjust_iteration_scope__activity_definition"></a>
-<ul>
- <li>
- To allow the customer to react to the team underestimating or over estimating the amount of work that can be
- accomplished in the current iteration.
- </li>
-</ul></purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/xp/tasks/update_release_plan.xmi b/XP/xp/tasks/update_release_plan.xmi
deleted file mode 100644
index 1d2b2c4..0000000
--- a/XP/xp/tasks/update_release_plan.xmi
+++ /dev/null
@@ -1,39 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-YO16TebjP7U0gkcYg7OY_A" name="update_release_plan,{18BF87E6-5849-4091-AFE2-FC4F0C3887B1}" guid="-YO16TebjP7U0gkcYg7OY_A" version="1.0.0">
- <sections xmi:id="_oO6dcGE-EdqnIZeW8YpHcA" name="Gather the Information " guid="_oO6dcGE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step1" name="Step1"></a>
-<p>
- The most recent count of completed story points in an iteration is the team's velocity. The number of story points
- completed in an iteration will change over time. Consequently, the team's velocity also changes. If the team's velocity
- increases, more work can be done in each iteration. If the team's velocity decreases, less work can be done in each
- iteration.
-</p>
-<p>
- As the team progresses through the project, the team's understanding of the problem is improved. Customers will add new
- stories and remove others. Programmers may need to change story estimates. Consequently, the release plan should be
- revisited periodically (every few iterations or as needed).
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_oO6dcWE-EdqnIZeW8YpHcA" name="Update the Plan " guid="_oO6dcWE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step2" name="Step2"></a>
-<p>
- Using the most recent velocity, the latest story estimates, and the customer's most recent view of priority, a new
- release plan is established.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_oO6dcmE-EdqnIZeW8YpHcA" name="Communicate the Plan " guid="_oO6dcmE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step3" name="Step3"></a>
-<p>
- Once the plan is updated, it is critical that the whole team be aware of it. This is usually really easy as the whole
- team was involved in the revision of the release plan. The plan will show the team the progress they are making
- (morale), and they will have a clear understanding of the new target they are shooting for (team cohesion).The plan
- must be realistic and alive.
-</p></sectionDescription>
- </sections>
- <purpose><a id="XE_revise_release_plan__activity_definition" name="XE_revise_release_plan__activity_definition"></a>
-<ul>
- <li>
- Ensure the release plan reflects our improved understanding of the coming releases.
- </li>
-</ul></purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/xp/tasks/write_code.xmi b/XP/xp/tasks/write_code.xmi
deleted file mode 100644
index 08b902a..0000000
--- a/XP/xp/tasks/write_code.xmi
+++ /dev/null
@@ -1,55 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-kNZQ2Mr_nyfmCboprjMNTg" name="write_code,{8F6CB99A-D2EA-44BB-8CE5-F97220D44088}" guid="-kNZQ2Mr_nyfmCboprjMNTg" version="1.0.0">
- <sections xmi:id="_oUbPkGE-EdqnIZeW8YpHcA" name=" Get a Pair Programming Partner " guid="_oUbPkGE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step1" name="Step1"></a>
-<p>
- Pair Programming is an Extreme Programming best practice. The basic rule regarding pair programming in XP is that all
- production code is developed in pairs. One programmer has the responsibility to complete a task. That programmer asks
- other programmers to pair with him to complete the task. The pairings are short term, usually less than half a day.
- Find a partner who has experience or skill you need to complete your task. Your task may include modifying a database
- table. Ask the person on the team most knowledgeable to help you effectively use the database API. Later, you might
- need to display the data in a GUI window, but you have not seen that part of the GUI. Get someone who knows about it to
- help.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_oUbPkWE-EdqnIZeW8YpHcA" name=" Write Failing Test Case " guid="_oUbPkWE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step2" name="Step2"></a>
-<p>
- When looking at an Engineering Task, you should consider how to add the capability to the system. Does the system
- require new classes? Are there classes that would be useful? Regardless of how these decisions come out, the addition
- of functionality requires the creation of a test case. You write the test case to demonstrate that a portion of the
- functionality you need isn't in the system. This test case should fail.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_oUbPkmE-EdqnIZeW8YpHcA" name=" Write Code to Make Tests Pass " guid="_oUbPkmE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step3" name="Step3"></a>
-<p>
- When you have a failing test case, you then write only the code that is necessary to satisfy the test case. Test cases
- should have a very narrow focus. A failing test case may trigger the creation of a new class or method named in the
- test case, or it may simply require you to add more code to existing classes and methods.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_oUbPk2E-EdqnIZeW8YpHcA" name=" Refactor Immediately " guid="_oUbPk2E-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step4" name="Step4"></a>
-<p>
- After the test case passes, go back and make the code as clean as possible. Have you added code to a method and caused
- the method to have more than one primary job? If so, extract a method. Has a class grown too large? Consider extracting
- a class. Have you noticed duplication? Refactor to remove it.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_oUbPlGE-EdqnIZeW8YpHcA" name=" Repeat Until Engineering Task is Done " guid="_oUbPlGE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step5" name="Step5"></a>
-<p>
- The preceding three steps should be done in sequence over and over until you and your pair partner are done with the
- engineering task. It is important to refactor as you go because refactoring, even on a micro-scale, makes additional
- work easier.
-</p></sectionDescription>
- </sections>
- <purpose><a id="XE_write_code__activity_definition" name="XE_write_code__activity_definition"></a>
-<ul>
- <li>
- To specify the design of the system in a way which is precise enough to allow computers to generate efficient
- processes automatically and clear enough for people to understand during ongoing work and maintenance.
- </li>
-</ul></purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/xp/tasks/write_user_story.xmi b/XP/xp/tasks/write_user_story.xmi
deleted file mode 100644
index 687e662..0000000
--- a/XP/xp/tasks/write_user_story.xmi
+++ /dev/null
@@ -1,39 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-cqTu_uwmZrF3sFspx465XQ" name="write_user_story,{62CFC55C-3151-46CB-8886-F3DBD552ABC4}" guid="-cqTu_uwmZrF3sFspx465XQ" version="1.0.0">
- <sections xmi:id="_oQZEIGE-EdqnIZeW8YpHcA" name=" Define System Behavior " guid="_oQZEIGE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step1" name="Step1"></a>
-<p>
- A user story is a brief description of a feature of the system. Stories are small, taking only a week or two to
- develop. The best stories provide direct business value. When stories are too big, they must be split. Consequently, it
- may take multiple stories to provide business value. In this case, the individual stories need to demonstrate to the
- customer that the team is making progress toward the desired business value.
-</p>
-<p>
- There is no need for a lot of detail in the description. The details will be flushed out when the acceptance tests for
- this story are defined. Typically, XP user stories are written on small index cards, one story per card.
-</p></sectionDescription>
- </sections>
- <sections xmi:id="_oQZEIWE-EdqnIZeW8YpHcA" name=" Define Customer Test " guid="_oQZEIWE-EdqnIZeW8YpHcA">
- <sectionDescription><a id="Step2" name="Step2"></a>
-<p>
- Each user story will have a set of conditions or acceptance criteria to fulfill before it is considered done.
- Basically, an acceptance criterion defines an interaction scenario between the user and the system. There is usually
- more than one possible scenario or acceptance test criterion for a typical story. The acceptance test criteria are
- converted into <a class="elementLinkWithUserText"
- href="./../../xp/tasks/automate_acceptance_test,{E614ED93-AE72-4FD1-B459-C508CE1C536F}.html"
- guid="{E614ED93-AE72-4FD1-B459-C508CE1C536F}">automated customer tests</a> when the story is being implemented.
-</p>
-<p>
- For simplicity, the test criteria are often written natural language. However, this makes them prone to
- misinterpretation. To address this issue, some teams provide simple tools that allow the customer to write the
- acceptance tests criteria in a form that can be executed directly by application-specific acceptance test framework.
- Ultimately, it is the responsibility of the customer to provide the customer tests
-</p></sectionDescription>
- </sections>
- <purpose><a id="XE_write_user_story__activity_definition" name="XE_write_user_story__activity_definition"></a>
-<ul>
- <li>
- To specify a specific behavior of the system from a user perspective.
- </li>
-</ul></purpose>
-</org.eclipse.epf.uma:TaskDescription>
diff --git a/XP/xp/workproducts/xp_build.xmi b/XP/xp/workproducts/xp_build.xmi
deleted file mode 100644
index 94f0f81..0000000
--- a/XP/xp/workproducts/xp_build.xmi
+++ /dev/null
@@ -1,13 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-rphHqeONv59sqZq_6FzE6Q" name="xp_build,{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222}" guid="-rphHqeONv59sqZq_6FzE6Q" changeDate="2006-11-08T16:52:31.958-0800" version="1.0.0">
- <purpose><a id="XE_xp_build__artifact_definition" name="XE_xp_build__artifact_definition"></a><a id="Purpose" name="Purpose"></a><a
-id="XE_xp_build__purpose_of" name="XE_xp_build__purpose_of"></a>
-<p>
- The purpose of the <a class="PresentationName"
- href="./../../xp/workproducts/xp_build,{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222}.html"
- guid="{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222}">XP Build</a> is to show demonstrable progress in a running system. Each
- <a class="PresentationName" href="./../../xp/workproducts/xp_build,{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222}.html"
- guid="{FE89AB1C-E0FE-4E7F-92B4-3FA2A0ED6222}">XP Build</a> incrementally shows new functionality while insuring that
- previous functionality has not been broken.
-</p></purpose>
-</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/XP/xp/workproducts/xp_coding_standard.xmi b/XP/xp/workproducts/xp_coding_standard.xmi
deleted file mode 100644
index 56152aa..0000000
--- a/XP/xp/workproducts/xp_coding_standard.xmi
+++ /dev/null
@@ -1,11 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-NznKylxa2Y_MG8lACUV9Bw" name="xp_coding_standard,{1D7E042C-B29E-4169-8DF3-37DE0A5F64ED}" guid="-NznKylxa2Y_MG8lACUV9Bw" changeDate="2006-11-09T16:10:06.935-0800" version="1.0.0">
- <purpose><a id="XE_coding_standard__artifact_definition" name="XE_coding_standard__artifact_definition"></a><a id="Purpose"
-name="Purpose"></a><a id="XE_coding_standard__purpose_of" name="XE_coding_standard__purpose_of"></a>
-<p>
- The purpose of the <a class="PresentationName" guid="{1D7E042C-B29E-4169-8DF3-37DE0A5F64ED}">Coding Standard</a> is to
- facilitate communication among programmers working on the same code base. The coding standard takes on added importance
- in XP because of the pair programming and collective code ownership practices. The objective is to have all parts of
- the code appear to have been written by the same programmer.
-</p></purpose>
-</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/XP/xp/workproducts/xp_customer_test.xmi b/XP/xp/workproducts/xp_customer_test.xmi
deleted file mode 100644
index a8c9449..0000000
--- a/XP/xp/workproducts/xp_customer_test.xmi
+++ /dev/null
@@ -1,14 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-YYMUwBepQ28JU78LtraO3w" name="xp_customer_test,{DF0EDBC7-4AAD-438D-89AA-64ECFE2416F5}" guid="-YYMUwBepQ28JU78LtraO3w" changeDate="2006-11-10T09:27:13.845-0800" version="1.0.0">
- <keyConsiderations>As more and more customer tests are added to the system, there will be a need to organize them in some way. Typically, the
-testers and programmers will build and maintain some kind of customer test framework. As is the case for the production
-code, it is important to let the framework evolve with the needs of the application. It is very easy to go overboard when
-building a test framework.</keyConsiderations>
- <purpose><a id="XE_xp_customer_test__artifact_definition" name="XE_xp_customer_test__artifact_definition"></a><a id="Purpose"
-name="Purpose"></a><a id="XE_xp_customer_test__purpose_of" name="XE_xp_customer_test__purpose_of"></a>
-<p>
- The <a class="PresentationName" guid="{DF0EDBC7-4AAD-438D-89AA-64ECFE2416F5}">XP Customer Test</a> demonstrates the
- presence of the system features as defined by the customer. They are the unambiguous and detailed requirements of the
- system.
-</p></purpose>
-</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/XP/xp/workproducts/xp_iteration_plan.xmi b/XP/xp/workproducts/xp_iteration_plan.xmi
deleted file mode 100644
index bfe636c..0000000
--- a/XP/xp/workproducts/xp_iteration_plan.xmi
+++ /dev/null
@@ -1,40 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-45BLJONIjGn7h4z87VXqHQ" name="xp_iteration_plan,{DC18E34B-70C1-403D-84CC-1BF117A7473D}" guid="-45BLJONIjGn7h4z87VXqHQ" changeDate="2006-11-13T13:17:43.002-0800" version="1.0.0">
- <mainDescription><p>
- The <a class="PresentationName" guid="{DC18E34B-70C1-403D-84CC-1BF117A7473D}">XP Iteration Plan</a> contains a list of
- stories selected to be implemented in the iteration. Each story is broken down into one or more engineering tasks.
- These tasks are sufficiently small that an individual can grasp its scope and provide a reasonable estimate. Tasks
- usually range from less than a day to one or two days for a single individual.
-</p>
-<p>
- The <a class="PresentationName" guid="{DC18E34B-70C1-403D-84CC-1BF117A7473D}">XP Iteration Plan</a> is recorded on flip
- chart paper and hung on the walls of the team's open workspace. Each story for the iteration is written on a piece of
- flip chart paper and hung on the open workspace wall. The team brainstorms the tasks needed to complete a story. They
- discuss the story with the customer as needed. The team will sometimes do a quick design session to help them figure
- out the tasks for a given story. This is repeated for each story in the iteration. Once all stories have been broken
- down, individuals sign up for tasks, recording their initials and estimate next to the task.
-</p>
-<p>
- What makes a good <a class="PresentationName" guid="{DC18E34B-70C1-403D-84CC-1BF117A7473D}">XP Iteration Plan</a>:
-</p>
-<ul>
- <li>
- The stories have been broken down into tasks.
- </li>
- <li>
- The tasks have been signed up for and given estimates.
- </li>
- <li>
- Stories are removed from the plan if there is too much to do.
- </li>
- <li>
- Stories are added to the plan if there is not enough to do.
- </li>
-</ul></mainDescription>
- <purpose><a id="XE_xp_iteration_plan__artifact_definition" name="XE_xp_iteration_plan__artifact_definition"></a><a id="Purpose"
-name="Purpose"></a><a id="XE_xp_iteration_plan__purpose_of" name="XE_xp_iteration_plan__purpose_of"></a>
-<p>
- The <a class="PresentationName" guid="{DC18E34B-70C1-403D-84CC-1BF117A7473D}">XP Iteration Plan</a> steers the efforts
- of the team during the iteration.<br />
-</p></purpose>
-</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/XP/xp/workproducts/xp_metaphor.xmi b/XP/xp/workproducts/xp_metaphor.xmi
deleted file mode 100644
index cfa7c32..0000000
--- a/XP/xp/workproducts/xp_metaphor.xmi
+++ /dev/null
@@ -1,10 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-sQUFozEqR3Gpa5PnCjFh9Q" name="xp_metaphor,{7C34EE96-C3EA-49FD-A53C-7C113B86AE01}" guid="-sQUFozEqR3Gpa5PnCjFh9Q" changeDate="2006-11-08T16:23:13.847-0800" version="1.0.0">
- <purpose><a id="XE_metaphor_(system_of_names)__artifact_definition" name="XE_metaphor_(system_of_names)__artifact_definition"></a><a
-id="Purpose" name="Purpose"></a><a id="XE_metaphor_(system_of_names)__purpose_of"
-name="XE_metaphor_(system_of_names)__purpose_of"></a>
-<p>
- The <a class="PresentationName" guid="{7C34EE96-C3EA-49FD-A53C-7C113B86AE01}">Metaphor (System of Names)</a> or System
- of Names allows the team to talk about the structure of the software in a convenient and memorable way.
-</p></purpose>
-</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/XP/xp/workproducts/xp_production_code.xmi b/XP/xp/workproducts/xp_production_code.xmi
deleted file mode 100644
index 473ee39..0000000
--- a/XP/xp/workproducts/xp_production_code.xmi
+++ /dev/null
@@ -1,19 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-f1cDEBpC5wbDTQ9ru9UbLw" name="xp_production_code,{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1}" guid="-f1cDEBpC5wbDTQ9ru9UbLw" changeDate="2006-11-13T13:21:51.018-0800" version="1.0.0">
- <mainDescription><p>
- This definition of <a class="PresentationName" guid="{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1}">Production Code</a>
- encompasses hand-coded software as well as executable models. The <a class="PresentationName"
- guid="{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1}">Production Code</a> must be kept clean and simple, as it is the main
- vehicle for communicating design intent to the programming team. The code has comprehensive customer and unit tests.
- The XP practices of simple design, pair programming, refactoring, collective code ownership, test driven development,
- and coding standard support the creation of the code.
-</p></mainDescription>
- <purpose><a id="XE_production_code__artifact_definition" name="XE_production_code__artifact_definition"></a><a id="Purpose"
-name="Purpose"></a><a id="XE_production_code__purpose_of" name="XE_production_code__purpose_of"></a>
-<p>
- In XP, we consider <a class="PresentationName" guid="{3EDA30A8-932C-4EC2-B9AB-A840304C5BC1}">Production Code</a> to be
- the most important artifact. It is the one design artifact that cannot be replaced because it is the only complete and
- unambiguous expression of design intent. Source code is a specification. It, along with a compiler or interpreter,
- encompasses all of the semantics necessary to produce a running process on a computer.
-</p></purpose>
-</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/XP/xp/workproducts/xp_release_plan.xmi b/XP/xp/workproducts/xp_release_plan.xmi
deleted file mode 100644
index c627fa1..0000000
--- a/XP/xp/workproducts/xp_release_plan.xmi
+++ /dev/null
@@ -1,11 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-mMZ9KUhiFwBbzSFjq_tO4A" name="xp_release_plan,{CA77FBD2-04DD-4010-B2AA-03E1E7C66B0B}" guid="-mMZ9KUhiFwBbzSFjq_tO4A" changeDate="2005-12-02T07:44:11.027-0800" version="1.0.0">
- <purpose><a id="XE_xp_release_plan__artifact_definition" name="XE_xp_release_plan__artifact_definition"></a><a id="Purpose"
-name="Purpose"></a><a id="XE_xp_release_plan__purpose_of" name="XE_xp_release_plan__purpose_of"></a>
-<p>
- The <a class="PresentationName" guid="{CA77FBD2-04DD-4010-B2AA-03E1E7C66B0B}">XP Release Plan</a> is the longer term
- project view. It organizes estimated stories into iterations and groups iterations into releases. The releases defined
- by the customer contain enough value to deliver the software to the end users of the product. The bias in ordering
- stories and defining releases is to deliver the most business value possible by the release date.
-</p></purpose>
-</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/XP/xp/workproducts/xp_unit_test.xmi b/XP/xp/workproducts/xp_unit_test.xmi
deleted file mode 100644
index 1db0e19..0000000
--- a/XP/xp/workproducts/xp_unit_test.xmi
+++ /dev/null
@@ -1,18 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-dwfXb2dWJOQkTuLo-BTFeQ" name="xp_unit_test,{D156652E-7C52-4EBD-8F23-F38169877A57}" guid="-dwfXb2dWJOQkTuLo-BTFeQ" changeDate="2006-11-13T13:57:02.728-0800" version="1.0.0">
- <mainDescription><p>
- <a class="PresentationName" guid="{D156652E-7C52-4EBD-8F23-F38169877A57}">XP Unit Test</a>s are usually implemented at
- the class level (in OO languages) and test the public interface. For every class in the system, a test class exists.
- Popular test frameworks are available usually for free (such as JUnit, CppUnit, CppUnitLite, NUnit). These are simple
- tools that help the developer to organize and run unit tests. These tests drive the programmer development and tell the
- programmer that the code works as the programmer expects.
-</p></mainDescription>
- <purpose><a id="XE_xp_unit_test__artifact_definition" name="XE_xp_unit_test__artifact_definition"></a><a id="Purpose"
-name="Purpose"></a><a id="XE_xp_unit_test__purpose_of" name="XE_xp_unit_test__purpose_of"></a>
-<p>
- An <a class="PresentationName" guid="{D156652E-7C52-4EBD-8F23-F38169877A57}">XP Unit Test</a> is written by developers
- to ensure that all system components work as expected. <a class="PresentationName"
- guid="{D156652E-7C52-4EBD-8F23-F38169877A57}">XP Unit Test</a> give the developers the confidence to modify the system
- and feel confident that everything still works.
-</p></purpose>
-</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/XP/xp/workproducts/xp_user_story.xmi b/XP/xp/workproducts/xp_user_story.xmi
deleted file mode 100644
index e5afb80..0000000
--- a/XP/xp/workproducts/xp_user_story.xmi
+++ /dev/null
@@ -1,66 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-rtY57MTVQrEcfTKwD3-Wvw" name="xp_user_story,{21946731-4F5C-4862-8B4D-868629952B92}" guid="-rtY57MTVQrEcfTKwD3-Wvw" changeDate="2006-11-13T14:28:55.298-0800" version="1.0.0">
- <mainDescription><p>
- A <a class="PresentationName" guid="{21946731-4F5C-4862-8B4D-868629952B92}">User Story</a> is only a token of past and
- future conversation between the customer and the programmers. XP's on-site customer practice minimizes the need to
- document extensively each story as the programmers can simply walk over and ask their questions to the customer as
- needed. <a class="PresentationName" guid="{21946731-4F5C-4862-8B4D-868629952B92}">User Story</a> details are captured
- in automated acceptance tests that are then used to validate the implementation of the story.
-</p>
-<p>
- It may not be necessary to write a description for all stories as the name of some of the stories might already offer
- enough information.
-</p>
-<p>
- What makes a good <a class="PresentationName" guid="{21946731-4F5C-4862-8B4D-868629952B92}">User Story</a>?
-</p>
-<ul>
- <li>
- The customer should care about it. The story should have business value in the customer's eyes so it can be
- prioritized. Sometimes a story needs to be broken down into smaller pieces to fit into an iteration. If by itself
- the story does not provide business value, it should at least provide demonstrable progress toward a feature with
- business value.
- </li>
- <li>
- Stories vertically slice through the product's architecture. They are not usually focused on a specific subsystem.
- </li>
- <li>
- Test cases can be written to verify that the programmers have implemented it correctly.
- </li>
- <li>
- It can be reasonably estimated by the developers. Stories that can't be estimated are rewritten.
- </li>
- <li>
- It can be completed within one iteration. A story that does not fit in an iteration is broken down into two or more
- smaller stories.
- </li>
-</ul></mainDescription>
- <purpose><a id="XE_user_story__artifact_definition" name="XE_user_story__artifact_definition"></a><a id="Purpose"
-name="Purpose"></a><a id="XE_user_story__purpose_of" name="XE_user_story__purpose_of"></a>
-<p>
- A <a class="PresentationName" guid="{21946731-4F5C-4862-8B4D-868629952B92}">User Story</a> represents a small piece of
- functionality of the system being built. It is not a complete specification of a feature. It is a promise to discuss a
- feature or a reminder of the discussion that has already taken place.
-</p></purpose>
- <representationOptions><p>
- Here are some sample stories for a typical on-line store application:
-</p>
-<p>
- --------------------------------------------------------------------------------<br />
- If the customer has entered a valid Tax Exemption ID, do not charge sales tax.
-</p>
-<p>
- --------------------------------------------------------------------------------<br />
- If the Customer ID is on the Preferred Customer list, do not charge for shipping, except for Next Day service.
-</p>
-<p>
- --------------------------------------------------------------------------------<br />
- On the System Status Page, show the number of orders in the past 24 hours, the total revenue, and list the top ten
- items in order of quantity ordered.
-</p>
-<p>
- --------------------------------------------------------------------------------<br />
- If the delivery address of a purchase is in any of the states in the attached table, calculate, display, and charge
- sales tax using the corresponding percentage.
-</p></representationOptions>
-</org.eclipse.epf.uma:ArtifactDescription>
diff --git a/XP/xp/workproducts/xp_vision.xmi b/XP/xp/workproducts/xp_vision.xmi
deleted file mode 100644
index 892bb7d..0000000
--- a/XP/xp/workproducts/xp_vision.xmi
+++ /dev/null
@@ -1,10 +0,0 @@
-<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-ZUxMgSWqLlaO5p1r1-ug6Q" name="xp_vision,{2300FB25-7249-4481-A1BD-978240906832}" guid="-ZUxMgSWqLlaO5p1r1-ug6Q" changeDate="2006-11-10T08:46:22.508-0800" version="1.0.0">
- <purpose><a id="XE_xp_vision__artifact_definition" name="XE_xp_vision__artifact_definition"></a><a id="Purpose"
-name="Purpose"></a><a id="XE_xp_vision__purpose_of" name="XE_xp_vision__purpose_of"></a>
-<p>
- The <a class="PresentationName" guid="{2300FB25-7249-4481-A1BD-978240906832}">XP Vision</a> consists of very high-level
- requirements. It communicates to the team a common understanding of the project and is a gauge against which all future
- decisions should be validated. It will guide the team during the development cycle.
-</p></purpose>
-</org.eclipse.epf.uma:ArtifactDescription>
