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.
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.
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.
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.
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.
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.
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.
Did this help? You can provide feedback at Jazz.net (registration required): Comment in the forums or submit a bug