Project area

In each of the IBM® Engineering Lifecycle Management (ELM) applications, teams perform their work within the context of a project area. A project area is an area in the repository where information about one or more software projects is stored. A project area defines the project deliverables, team structure, process, and schedule. You access all project artifacts, such as iteration plans, work items, requirements, test cases, and files under source control within the context of a project area.

Each project area has a process, which governs how members work. For example, the project area process defines:
  • User roles
  • Permissions assigned to roles
  • Timelines and iterations
  • Operation behavior (preconditions and follow-up actions) for Change and Configuration Management and Quality Management
  • Work item types and their state transition models (for Change and Configuration Management and Quality Management)

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 access control settings and permissions. A project area cannot be deleted from the repository; however, it can be archived, which places it in an inactive state.

Project timelines

A project area can be simple or complex in terms of its artifacts, process, and schedules. An established project area can have multiple active 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 stage of development. Each timeline can have one or more iterations in which some set of deliverables and functional improvements are committed. Testing activities for new features and improvements are typically scheduled for the same iteration.

Project schedule as iterations

The project schedule is specified by iterations, which represent intervals in the life of the project. Each set of iterations is specific to one timeline. Teams can configure iterations in a hierarchy; for example a timeline can have multiple milestone iterations. Each of those milestones can 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 editor. The editor 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.

Project teams as team areas

The structure of a project team 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 timeline. Users might have multiple assignments that require them to work on more than one team area. Some members, such as the project lead, might not belong to a team area, but are defined as members of the project area.

Project areas 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. You can also create a process template that does not specify team areas.

Project area process

When you create a project area, you must specify a process template. The process template defines the initial process (roles, permissions, timelines, iterations, operation behavior, work item types, and so on) for the project area. You can then modify the process within the project area to meet your overall project and team area needs. You can also customize the process in team areas, timelines, iterations, and iteration types.

Sharing project area process

After you create a project area, you can make its process available to other project areas. By sharing a project area process, you ensure that all project areas across your organization use the same process. You also centralize process maintenance; changes that you make to the process of the sharing project area immediately apply to the project areas and team areas that consume that process. You can change the process for all project areas by configuring the process in the sharing project area.

For quality management, you can create a process template that includes test categories, custom attributes, artifact templates, and other artifacts, and use that template to initialize new project areas.

Example project area

The following graphic provides an example of a change and configuration management 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; other users are added to team areas. The process includes project-wide roles, permissions, and operation behavior; these are inherited by all iterations within the project area. Some permissions and behaviors are defined at the timeline or iteration level; these override the project-level settings. Team members are assigned roles, which have specific permissions. Some roles are specific to a team area.

An example quality management or requirements management project area might look different than the one shown in Figure 1. For example, operation behavior is available only in change and configuration management and quality management project areas.

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.