Project area

The project area is the system's representation of a software project. The project area defines the project deliverables, team structure, process, and schedule.

A project area is stored as a top-level or root item in a repository. A project area references project artifacts and stores the relationships between these artifacts. Access to a project area and its artifacts is controlled by permissions. A project area cannot be deleted from the repository; however, it can be archived, which places it in an inactive state.

Project deliverables as lines of development

A project can be quite simple or complex in terms of its committed product deliverables, process, and schedules. An established project can have multiple active lines of development, known as timelines, such as:
  • Maintenance for one or more shipped releases
  • Development of a new release
  • Exploratory development for a future release

All of these timelines can work in parallel, each in a different state. Each timeline can have one or more iterations in which some set of deliverables and functional improvements are committed.

Note: You can also create separate project areas to manage different activities related to the same artifacts, and one project area can reference artifacts from another. For example, if your team has developed a code base in a development project area, you can create a separate project area to maintain the same code. This is done in the stream editor in the maintenance project by replacing a component with a component from a snapshot in the development project. This enables the maintenance team to work on the same code artifacts but with completely different process iterations, roles, rules, and work items.

Project teams as team areas

The structure of the project teams is defined by one or more team areas. Complex projects can have a hierarchy of team areas. Typically, one or more teams are assigned to each line of development. Users might have multiple assignments that require them to work on more than one team. Some members, such as the project lead, might not belong to a team area, but are defined as members at the project level in the project area overview.

Projects without team areas

You can create a project area that does not include any team areas. Typically, this type of project area might be appropriate for a small team of developers who want to get up and running quickly and do not need to organize their work into multiple teams. The Simple Team process template defines a project area without team areas. You can also create a process template that does not specify team areas.

Project process

Process is the collection of practices, rules, and guidelines used to organize and control the flow of work. The project process is defined in a project area and can be further customized in a team area, timeline, and iteration. In Jazz™, you use process to define user roles and their permissions for performing operations within the tool, such as changing the state of a work item. Because each component in Jazz is process aware, you can add operation behavior rules in the form of preconditions and follow-up actions.

Process is typically based on a template and then modified to meet the overall project and team area needs. The basic process structure is defined as a set of timelines and iterations in the project area overview. Process details for roles, permissions, reports, work items types and workflows, operation behavior preconditions and follow-up actions can be customized in the process configuration.

Project schedule as iterations

The project schedule is specified by process iterations, which represent intervals in the life of the project. Each set of iterations is specific to one line of development. Teams can configure iterations in a hierarchy; for example a timeline could have multiple milestone iterations. Each of those milestones could contain one or more phase iterations. The iteration hierarchy and names are user-defined.

You can define the timelines and an iteration hierarchy in the project area overview. The overview contains controls for adding timelines, start and end dates for iterations and a designation for the current iteration. After iterations are defined, work items can be assigned to an iteration and tracked in an iteration plan.

Example project area

The following graphic provides an example of a project area that has team areas and process configurations that are specific to timelines and their iterations. The project area can include some users, such as administrators, project managers, and business analysts, at the project level; others users are added to team areas. The process specification includes project-wide roles, permissions, and process behaviors; these are inherited by all iterations within the project area. Other roles, permissions, and behaviors are defined at the timeline or iteration level; these override the project-level process configuration. Team members are assigned roles that have specific permissions, as defined in the process specification.

Figure 1. An example project area that defines team areas, timelines, iterations, and process configurations
The graphic shows a repository with one project area, which includes team areas, timelines and iterations, and process configurations.

Feedback

Did this help? You can provide feedback at Jazz.net (registration required): Comment in the forums or submit a bug