Creating a lifecycle project template

In addition to using the predefined lifecycle project templates, you can create templates.

1. Create an XML file for the new template and open it in an XML editor.
2. Specify the XML declaration and namespace.
   In the following example, the dc namespace abbreviation refers to the Dublin Core Metadata Initiative (DCMI) properties namespace URI. The second namespace entry identifies the Lifecycle Project Administration namespace URI.

   <?xml version="1.0" encoding="UTF-8"?
   <template 
      xmlns:dc="http://purl.org/dc/terms/"
      xmlns="http://jazz.net/xmlns/foundation/lpa/1.0/"
   >

3. Specify the template description section. Use the description element and its child properties to specify meta information.
   1. Specify a unique identifier for the template by using the dc:identifier element. The Lifecycle Project Administration (LPA) user interface uses the identifier when you delete or update a template.
   2. Specify a name for the template by using the dc:title element.
   3. Provide a description of the template by using the dc:description element. A useful description identifies the project areas and the associations between those project areas that the template creates.
   4. Specify the creator of the template by using the dc:creator element.. You could specify yourself, your company, or your organization.
   5. Specify the locales that the template supports by using the locales element.
   The following example describes the Quality Professional, Analyst, and Developer template.

   <description>
     <dc:identifier>rational.alm.integrated.template</dc:identifier> 
     <dc:title>Quality Professional, Analyst, Developer</dc:title> 
     <dc:description>This template sets up associated project areas for quality management, requirements management, and change and configuration management. The testers (in quality management) and analysts (in requirements management) work integrated with development (in change and configuration management) and quality management tasks and requirements change requests are tracked in the change and configuration management project. The change and configuration management project area can be configured to use the Scrum or Formal Project Management process template. The requirements management project area can be configured to use the Base, Use Case, Agile Requirements or Traditional Requirements project template.</dc:description> 
     <dc:creator>IBM Corp.</dc:creator> 
   <locales>
     <locale>en_US</locale> 
     <locale>fr</locale> 
     <locale>de</locale> 
     <locale>ja</locale> 
     </locales>
   </description>

4. Specify the project areas that the lifecycle project template creates. For each project area, specify the following elements:
   • projectArea id. The ID is necessary if other element properties will reference this project area. The ID must be unique. For example: mycorp.mytemplate.ewm.project
   • processTemplates. Use the processTemplates element to list the process templates that can be used to create the project area. The process templates must be available on the application where the project area is to be created. For each process template, specify the following elements:
     • dc:identifier: unique identifier of the process template.
     • dc:title: name of the process template.
   • projectTemplates. For requirements management project areas only, you can also specify project templates. As with process templates, specify the following elements:
     • dc:identifier: unique identifier of the project template.
     • dc:title: name of the project template.
   • dc:subject. Use the subject to further describe the project area. When users create the lifecycle project, the subject is appended to the default project area name.
   • domain ref. The domain is the Open Services for Lifecycle Collaboration (OSLC) domain of the project area:
     • For change and configuration management project areas, specify http://open-services.net/ns/cm#
     • For design management project areas, specify http://open-services.net/ns/am#
     • For quality management project areas, specify http://open-services.net/ns/qm#
     • For requirements management project areas, specify http://open-services.net/ns/rm#

   The following example specifies a change and configuration management project area. Users have the choice of creating the project area based on the Scrum or Formal Project Management process templates.

   <projectArea id="rtc.project">
            <processTemplates>
               <processTemplate>
                  <dc:identifier> scrum2.process.ibm.com</dc:identifier>
                  <dc:title>Scrum</dc:title>
               </processTemplate>
               <processTemplate>
                  <dc:identifier>formalpm.process.ibm.com</dc:identifier>
                  <dc:title>Formal</dc:title>
               </processTemplate>
            </processTemplates>
            <dc:subject>Change Management</dc:subject>
            <domain ref="http://open-services.net/ns/cm#" />
         </projectArea>

5. Specify the associations to establish between the project areas. Within each projectAreaAssociation element, use the sourceDomain and targetDomain elements to identify two project areas, and use the linkType element to indicate the relationship between the artifacts being linked to each other.
   The following example specifies that artifacts created in the requirements management project area can be linked to artifacts created in the change and configuration management project area. The linkType elements indicate that the requirements management artifacts (requirements) are implemented by the change and configuration management artifacts (work items). For the full list of supported link types, see Supported link types.

   <projectAreaAssociations>
      
         <!-- RRC implemented-by RTC -->
         <projectAreaAssociation>
            <sourceDomain ref="#rrc.project" />
            <linkType>implemented-by</linkType>
            <targetDomain ref="#rtc.project" />
         </projectAreaAssociation>
      
         <!-- RTC implements RRC -->
         <projectAreaAssociation>
            <sourceDomain ref="#rtc.project" />
            <linkType> implements</linkType>
            <targetDomain ref="#rrc.project" />
         </projectAreaAssociation>
   .
   .
   .
   </projectAreaAssociations>

6. Define the lifecycle project that the lifecycle project template creates. Within the LifeCycleProject element, specify the following elements:
   • id: unique identifier of the lifecycle project template.
   • dc:title: value that will be used as the name of the lifecycle projects to be created. To use the name that users enter in the Name field of the LPA editor, specify ${request.param.projectName}.
   • dc:description: value that will be used as the description of the lifecycle projects to be created. To use the description that users enter in the Description field of the LPA editor, specify${request.param.projectDescription}.
   • lifeCylceProjectContext: specifies that the project area identified by the ref attribute is added to the lifecycle project. Specify a lifeCylceProjectContext element for each project area to be created.
   • configuration. Optional. Use the configuration element to configure process role relationship rules. In a cross-application environment, each project area has its own roles and permissions. For a user to work on linked artifacts in each project area, the user must have sufficient roles and permissions in each project area. After you configure rules that specify the correct combination of process roles across project areas, the LPA user interface flags users who do not have those process roles. In this way, the Lifecycle Project Administration user interface helps you to avoid problems where members do not have the permissions needed to do their work.

     For each rule that you want to specify, enter a roleRule tag.

     Within the roleRule tag, enter one sourceRole tag, for one project area, and targetRole tags for the other project area or areas. Use the id attribute to identify the role. Use the context attribute to identify the project area. The sourceRole tag identifies the role assignment that triggers the rule. The targetRole tags identify the role assignments that the user should have in the other project areas.

   The following configuration rule file specifies two rules. In the first rule, if a user has the ScrumMaster role in the change and configuration management project area, that user must have the Test Team Member role and the Administrator role in the quality management and requirements management project areas, respectively. In the second rule, if a user has the Product Owner role in the change and configuration management project area, that user must have the Test Team Contributor role and the Author role in the quality management and requirements management project areas, respectively.

   <lifeCycleProjects>
         <lifeCycleProject id="lpa.project">
            <dc:title>${request.param.projectName}</dc:title>
            <dc:description>${request.param.lpaProjectDescription}</dc:description>
            <lifeCycleProjectContext ref="#rrc.project"/>
            <lifeCycleProjectContext ref="#rtc.project"/>
            <lifeCycleProjectContext ref="#rqm.project"/>
            <configuration>
               <roleRule>
                  <sourceRole id="ScrumMaster" context="#rtc.project"/>
                  <targetRole id="Test Team Member" context="#rqm.project"/>
                  <targetRole id="Administrator" context="#rrc.project"/>
               </roleRule>
               <roleRule>
                  <sourceRole id="Product Owner" context="#rtc.project"/>
                  <targetRole id="Test Team Contributor" context="#rqm.project"/>
                  <targetRole id="Author" context="#rrc.project"/>
               </roleRule>
            </configuration> 
         </lifeCycleProject>
      </lifeCycleProjects>

7. Save the lifecycle project template XML file.
8. Import the lifecycle project template XML file into the LPA user interface.