About project templates

Application lifecycle management consists of methods and tools that enable software development teams to follow a process. The benefits of using a process include:

• Providing a framework for managing software development projects.
• Establishing guidelines and a methodology for how individuals perform various tasks.
• Providing a consistent and repeatable way of working.
• Establishing clear milestones and methods to achieve them.
• Improving overall efficiency and productivity.

If a domain administrator has enabled the ability to use project templates, you will have the option to select a project template at project creation time. A project template is a set of pages that provide visual cues, predefined queries, documents, and document templates that guide project members through the lifecycle stages of a project.

The following sections describe how CollabNet has implemented project templates.

Note: The information in this Help topic describes the CollabNet Baseline Project template. The contents of a customized project template may differ from that of the Baseline Project template.

About CollabNet-provided project templates

CollabNet provides a set of directories that, when referenced by a project, provide a process-driven environment for project members. A project template is a centrally created and managed collection of process stages, plus application pages for project management and communications. The template guides project members through a complete lifecycle.

The CollabNet Baseline Project template provides information for everyone working on a project, including product managers, engineers, testers, and support people. You can customize the CollabNet Baseline Project template to suit the practices of your organization.

The CollabNet Baseline Project template consists of the following components:

• An icon-based page navigator toolbar and a process-based navigation pane.
  The page navigator is a graphical toolbar. Each entry on the page navigator points to a page that is dedicated to a particular stage in the development process. For example, a Definition icon in the toolbar provides a link to a Definition page that contains documents, queries, and other information that is relevant to the definition subpage of a project. The following is a snapshot of the default page navigator:
  

  

  The following is a snapshot of the default process-based navigation pane:

  

• Pages for each stage of the process
  In addition to the page navigator toolbar and process links in the left navigation pane, each stage subpage contains a set of stage-specific Project Tracker queries. For example, the Definition page displays links to queries that return all requirements currently being defined, all requirements under consideration, and so on. Each page also contains links to stage-specific documents and useful external applications. The following subpages are supported in the CollabNet Sample Project template:
  • Definition
  • Design
  • Code & Build
  • Testing
  • Deployment
  • Support

• Templates for stage-specific documents
  The templates supply project members with "fill-in-the-blanks" guidance to simplify the task of creating project documentation. For example, the CollabNet Baseline Project template provides templates for the Project Requirements Document (PRD), a test plan document, and a test case document.
  
• Specialized artifact types
  Each project that uses the Baseline Project template contains a default set of Project Tracker artifact types, including Requirements, Defects, Incidents, and Action Items.

• A Project Management page.
  The CollabNet Baseline Project template home page contains a Project Management page. This page displays links to project schedules and tasks based on information in the Dashboard tool, queries of all lifecycle artifacts, links to IT governance documents and reports, and links to other documents related to project management.
  
• A Communications page.
  The CollabNet Baseline Project template project home page contains a Communications page. This page displays a list of project members, and links to communication tools such as project Announcements, Mailing Lists, and the WebEx service.
• A Metrics and Reporting page.
  The CollabNet Baseline Project template project home page contains a Metrics and Reporting page. This page displays graphical reports of the different artifacts produced in a project.
• An Integrations page.
  The CollabNet Baseline Project template project home page contains an Integrations page. This page displays links to third-party applications (such as an automated build system) and output from these applications.

Note: Projects that use a project template must also use Project Tracker.

The layout of a subpage

The subpages have a similar layout:

• A page navigator toolbar at the top of the page.
• An Activities area.
  This is an area with a light blue background. The activities area contains links to Project Tracker queries, to documents, and to external tools such as Cruise Control or WebEx. For example, on the Definition page, the Activities area contains a link for a Project Tracker query for viewing all requirements currently under consideration.
• A Documents table.
  Users upload project documentation for inclusion in this table. For example, on the default Definition page, users can add a PRD to this table by clicking an Upload button. The CollabNet Baseline Project template provides document templates upon which users can base the documents shown in these tables. When users upload documents, these documents are automatically stored in Subversion.
• A Resource Links area.
  This table provides links to other information that is relevant to a particular stage of the project.

How the CollabNet Baseline Project template works

The CollabNet Baseline Project template works according to a few principles:

• Easy access to the right tool for the right task.
  Project members can add artifacts that are relevant to a particular stage of a project. For example, a user can add a Requirement to the Definition subpage.
• Promotion of particular artifacts through lifecycle subpages.
  For critical artifact types such as Requirements, project members can promote an artifact along stages of a project and trace a work item from requirements definition through design, coding, and testing by modifying the subpage in Lifecyle attribute for the requirement. Other attributes, such as the Definition Complete attribute signals that the artifact is ready for promotion to the next subpage.

Example of promoting an artifact through lifecycle subpages:

1. A project member clicks the Projects page, clicks the link to a project that uses the CollabNet Baseline project template, and clicks the Definition subpage icon.
2. The project member clicks the New for consideration link, creates a new requirement named Requirement A, and sets the subpage in Lifecycle attribute for Requirement A to Definition.
   Requirement A now appears when any project member clicks the Ready for Definition link in the Activity area of the Definition page.
3. A project manager clicks the New for consideration link, clicks the link for Requirement A, and sets the value of Accepted into current subpage? for Requirement A to Yes.
   Requirement A now appears when anyone clicks the Currently in Definition query.
4. When all use cases are written for Requirement A, the project manager sets the Definition Complete? attribute to Yes for Requirement A and sets the subpage in Lifecycle for Requirement A to Design.
   Requirement A now appears when any project member clicks the Ready for Design link in the Activity area of the Design page.
5. A technical lead reviews the requirements, conducts other activities prescribed by the local development process, and when Requirement A is approved, the technical lead sets the value of Requirement A's Accepted into current subpage? attribute to Yes.
   Requirement A now appears in the results for the Currently in Design query on the Design page.
6. A design engineer, after creating design documents, sets the value of Design complete? for Requirement A to Yes, and sets the subpage in Lifecycle for Requirement A to Code & Build.
   Requirement A now appears when any project member clicks the Ready for Code & Build link in the Activity area of the Code & Build page.
7. An implementation engineer clicks the Ready for Code & Build link in the Activity area of the Code & Build page, and clicks the link for Requirement A.
8. The implementation engineer sets the value of Requirement A's Accepted into current subpage? attribute to Yes.
9. When Requirement A is fully implemented, the implementation engineer sets the value of Code & Build complete? to Yes, sets the subpage in lifecycle attribute to Testing, and sets the Status of Requirement A to Complete .
10. A testing engineer clicks the Testing subpage icon, clicks the Ready for testing query, clicks the link for Requirement A, and sets the value of Accepted into current subpage? for Requirement A to Yes.
11. When testing is complete, the test engineer sets the value of Test complete? for Requirement A to Yes.

In addition to the subpage in Lifecycle attribute, a Status attribute allows users to indicate the work completed or remaining to be done for an artifact. See "Transitions for the Status attribute" for details.