Help index

About project templates

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:

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:

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

The layout of a subpage

The subpages have a similar layout:

How the CollabNet Baseline Project template works

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

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.