Download RTC PM and WI Usage Model - PL Implementation

IBM Rational Software
RTC Usage Model
Project Management and Work Items
SCM Build/Deploy
RTC v 4.0.X
Bruce Besch
12/19/2013
RTC Project Management / Work Items Usage Model
Version 1.0
Version History
Version Issue Date
Description of Change
Author
1
11/11/13
Draft
Bruce Besch
1.1
12/19/13
Final
Bruce Besch
© IBM Rational, 2013
Page 2 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
1.
Introduction
1.1 Purpose
1.2 References
1.3 RTC Overview
5
5
5
5
2.
Getting Started in RTC
8
3.
Project Areas and Team Areas
3.1 Introduction
3.2 Project Area and Team Area Mapping
3.3 Project and Team Area Naming Conventions
3.3.1 Project Area
3.3.2 Team Area - Project Planning
3.3.3 Team Area - SCM Applications
9
9
10
10
10
10
10
4.
Timelines and Iterations
4.1 Overview
4.2 Timeline, Iteration, & Team Area Conventions
4.2.1 Timelines
12
12
12
12
5.
Work Item Types, Workflows, Enumerations and Attributes
5.1 Overview
5.2 Implemented Work Item Types
5.3 Work Item Workflows
5.3.1 Defect and Task
5.3.2 Project Change Request
5.3.3 Issue
5.3.4 Milestone
5.3.5 Risk
5.3.6 Work Item Attributes
5.3.7 Business Need Workflow
5.3.8 Build Deploy Request Workflow
5.4 Work Item Enumerations
5.5 Dependent Work Item Enumerations
5.6 Work Item Attributes
5.7 Resolutions
5.8 Tracking Time against Work Items
13
13
13
14
14
15
15
17
17
18
18
18
19
22
22
22
23
6.
Roles, Policies, Permissions and Operation Behavior
6.1 Overview
6.2 Roles
6.3 Permissions
6.4 Process Sharing
6.5 Access Control
6.6 Operation Behavior
23
23
25
26
26
27
27
7.
Work Item Categories
7.1 Overview
7.2 Work Item Category Names
29
29
29
8.
Plans
8.1 Overview
© IBM Rational, 2013
30
30
Page 3 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
Plan Types
8.1.1 Product Backlog Plan
8.1.2 Phase Plan
8.1.3 Schedule Risk Assessment Plan
8.1.4 Schedule Risk Assessed Sprint Backlog Plan
8.1.5 Release Plan
33
33
33
33
34
34
9.
Streams, Components and Workspaces
9.1 Overview
9.1.1 Streams and Components
9.1.2 Baselines and Snapshots
9.1.3 Local and Repository Workspaces
9.2 Naming Conventions
9.2.1 Repository Workspaces
9.2.2 Local Workspaces
9.2.3 Streams
9.2.4 Components
9.2.5 Baselines
9.2.6 Snapshots
9.3 SCM Stream Strategy
9.3.1 <customer> Application Streams:
9.3.2 Work Spaces and Flow Targets
9.3.3 QA Stream
34
34
35
35
37
37
37
38
38
38
38
38
39
39
40
40
10.
Builds
10.1
Overview
10.2
Best Practices for Builds
41
41
41
11.
Appendix A - Glossary of Terms
© IBM Rational, 2013
41
Page 4 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
1. Introduction
1.1 Purpose
Rational Team Concert (RTC) is a collaborative software delivery environment based on IBM's Jazz technology
platform. It provides the following integrated capabilities:






Work Item Management (Defects, Enhancements, and Tasks etc.)
Configuration Management / Source Control
Reporting and Dashboards
Process Support
Planning
Building
This document describes the Process Template implemented to execute an agile process for managing software
development related activities within your customer. The Process implemented is based on the OOTB Agile
Process template. All along the aspiration has been to keep the customizations to a minimum and simplify existing
processes and workflows where possible.
This is a living document which will be updated as needed to further define and clarify key project decisions.
1.2 References
For additional information about Rational Team Concert, see the IBM RTC 4.x Information Center at
http://pic.dhe.ibm.com/infocenter/clmhelp/v4r0m1/index.jsp
1.3 RTC Overview
The picture below (Figure 1) shows an overview of the various objects within Rational Team Concert and how they
relate to each other.
At the highest level, there is a repository that stores all the data and metadata related to the team’s software
development activities. The RTC repository is stored within two databases called JTS and CCM. These could be any
enterprise databases like DB2, Oracle or MS SQL server. Within, the RTC repository, there could be multiple
Project Areas created. Each Project Area is associated with a Process Template. The Process Template describes the
various Process related artifacts like Work Item types, Workflows, Roles, Permissions, Work Item Attributes,
Reports, Plan Views, Builds, SCM operations, etc. A Project Area can have children Team Areas below and they
could have children Team Areas under them. Team areas inherit the Process of their parent, but could also modify
some of the policies coming from the parent.
© IBM Rational, 2013
Page 5 of 43
RTC Project Management / Work Items Usage Model
RTC Repository
Version 1.0
Rational Team Concert 4.0.1
Overview
Process
Template
Project Area
Build
Engine
Stream
Baselines
Build
Definition
TimeLine
Team Area
Component
Builds
Repository
Workspace
Release
Plan
Snapshots
Iteration
Plan
ChangeSet
Plan Items
CI Builds
Local
Workspace
Builds
Execution
WorkItems
Task Management/Release
Planning
Comment
SCM
Figure 1 RTC Functional View
Project Areas/Team Areas have Streams that are used to isolate team based software development. Streams span
across multiple components where the various file artifacts are organized into high level folders. Specific versions of
these files within a component can be tagged as Baselines. Multiple baselines across multiple components are called
Snapshots. When developers want to work in RTC, they first create a Repository workspace which is associated
with a RTC stream. The Repository workspace is a local copy of the components as “seen” by the configuration of
the Repository workspace. This is then loaded into a local workspace (Eclipse or Visual Studio). Any modifications
are checked-in to the Repository workspace. These become ChangeSets and can be associated with a comment or a
work item. These could be delivered to a stream also called the “flow-target” associated with the Repository
workspace. The flow-target can be changed to deliver to different streams targeting different releases or
environments. Work items can be considered as Execution type or Plan type. Execution type work items are usually
associated with the ChangeSets. Plan type work items are usually used to describe high level items like stories or
Business Requirements. The work items can be organized into Iteration Plans or Release Plans. The Plans in
Rational Team Concert are associated with a “TimeLine”. Within a TimeLine, the current time represents the active
State of the Process. Some of the Process driven policies change based on what stage or phase of the project is
currently in. For example, there may be a code-freeze towards the end of a Release milestone. Timelines are used to
capture multiple levels of activities that could be in different phases at any given time. E.g. New development and
Maintenance could be separate sets of activities within an organization.
Builds are managed in RTC using either the RTC Build engine or an external Build Engine like Rational Build
Forge. A Build Engine represents a build server which accepts Build Requests. Build requests are associated with a
Build Definition. A Build Definition describes the Build process along with the related Build configuration like
Build targets and build scripts. Managed Builds can be scheduled, run as Continuous Integration or can be requested
© IBM Rational, 2013
Page 6 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
on demand. Builds run within a predefined Repository workspace. Private Builds can be requested to perform a
managed build but using a personal repository workspace. Builds create Snapshots so they can be reproduced later.
This document provides with an overview of the steps involved in Getting Started with Rational Team Concert
(RTC). It also provides a brief description of the various elements of RTC such as Project Areas, Team Areas,
Timelines, Plans and Work Items, SCM Build/Deploy as implemented within the context of <customer> software
development practices for the <customer> Application.










Getting Started in RTC
Project and Team Areas
Timelines and Iterations
Work Item Types
Roles, Policies, Permissions and Operation Behavior
Work Item Categories
Plans
Streams, Components and Workspaces
Builds
Reports, Queries and Dashboards
© IBM Rational, 2013
Page 7 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
2. Getting Started in RTC
In order to better understand the elements of RTC that can be customized, this section describes the typical steps
that must be performed in order to start a project using RTC. This section assumes that RTC has already been
installed and configured, process templates are deployed, and the RTC client is ready to start with a new Project
Area. This is not meant to be a detailed operational guide on this topics but merely an outline of various items that
need to be setup and configured for the correct use of RTC. As a best practice, RTC should be implemented by
different capabilities starting with Release Planning/Work Item Management. Later SCM and Build capabilities can
be adopted. For this pilot we plan to adopt RTC and Build Forge initially along with RRC.
Release Planning/Work Item Management
1. Setup new Project Area
a. Assign process template to Project Area.
b. Define members, roles and administrators.
c. Set user availability (schedule, absences, etc.)
d. Define the initial Timelines, Iterations, Milestones and Releases.
e. Customize process if needed.
f. Set Project Area Access Control rights.
2. Create Team Areas (typically based on Functional Areas)
a. Define members, roles and administrators.
b. Customize process as needed.
3. Define Work Item Categories (WICs) – typically based on Functional Areas
a. Map Team Areas to WICs per Timeline
4. Create Plans
5. Define Queries/Reports/DashBoards
6. Create a Lifecycle Project with links to the RRC Projects.
Software Configuration Management
1. Define Components and Stream Structure
a. Structure work into components and identify component names
b. Define stream structure and naming convention.
c. Create top-level integration stream for the new effort and add components to the stream.
d. Create top-level TEAM streams as needed and add components to the streams.
e. Set stream flow targets.
f. Change component owner to the Project Area’s team stream.
2. Create and Load Repository Workspace
a. Set flow targets to team or integration stream
b. Add components
3. Import Files
a. Open Eclipse client with RTC Add-on.
b. Copy the files into local sandbox.
c. Open the repository workspace and deliver files.
d. Check-in and Associate with a RTC Work Item.
e. Add Work Item or comment, Deliver the change-sets.
f. Do a build of the solution to validate.
4. Deliver Files to Project/Team stream
5. Create baselines/snapshot
© IBM Rational, 2013
Page 8 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
3. Project Areas and Team Areas
3.1 Introduction
A project area is RTC’s representation of a software project. It defines the project deliverables, team structure,
process, and schedule. A project area is stored as a top-level or root item in the RTC repository. It references
project artifacts and stores the relationships between these artifacts. Project areas can be simple or complex in terms
of their 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 independent of the other. Each timeline can have one or more
iterations in which some set of deliverables and functional improvements are committed.
Separate project areas can be used 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 enables the maintenance team to work
on the same code artifacts but with completely different process, iterations, roles and work items. For this
implementation, there will only be one Project Area per Domain e.g. You will build only one Project Area.
Complex projects can have a hierarchy of team areas. Typically, one or more team areas are assigned to each line
of development. Users might have multiple assignments that require them to work within more than one team area.
Some members, such as the project lead, might belong to the project area, but not to any specific team area. Team
Areas are created in order to isolate development along logical boundaries such as functional lines, new releases,
maintenance, and exploratory development. A Project Release will represent a Team Area. Although there can be
more, at least one Team Area will be created per Release. One additional Team Area will be created per Project
Area, namely MTA Team. This Team Area will be used for all work related to maintenance, etc. In addition
children team areas can be created to isolate work within a release.
Project process (the collection of practices, rules and guidelines used to organize and control the flow of work) is
defined in a project area and can be further customized in team areas, timelines and iterations. Team areas are
necessary when separate groups within a process need to operate using different processes.
Team Areas, Child Team Areas, and Plans, are all various ways the Work Items within a project can be grouped and
ultimately reported upon. They work together to provide users with visibility into the work that they are most
interested in viewing and maintaining.
Team Areas allow work items to be organized at the level of an individually funded project. Some projects have
more than one production release. To accommodate this, a project can track work items for an individual release in a
child Team Area which can have their own milestones. A project needs to specify its start/end date through the use
of Milestones. Specific Milestones must be added to designate any key gates or deadlines in the SDLC process.
Before we can discuss Plans, we need to look at Timelines. Underneath Plans is a shared Timeline at the Project
Area level. This shared Timeline governs the definition and duration of iterations. We will use the Release schedule
to represent the Iterations.
Each Team Area will create a set of Plans as every Work Item is created in and assigned to a Plan. Plans are created
against the shared Project Area Timeline and will contain centrally defined iterations as described above. A Plan can
cover the smallest measured iteration up to the highest level iteration.
© IBM Rational, 2013
Page 9 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
Work Items have associations to both Team Areas (Filed Against) and Plans (Planned For).While the Team Area
denotes "who" will do the work, Plans denote "when" the work will be done.
The SCM domain in RTC involves items like, SCM Components, Streams, Build Engines, Build Definitions,
ChangeSets, Baselines, Snapshots.
We discussed how Team Areas will map to the funded project releases for Project Planning and Work Item
Management purposes. If the funded Projects and Applications were aligned one-to-one then the logical place to
organize them would be in their respective Team Areas. However since they are not we have to organize them
separately. During PM/WI management we used Team Areas to organize your funded projects and their "releases".
Team Areas in RTC also aid in creating boundaries for SCM write access as well as visibility in certain Client UI
screens. One of the attributes of a Team Area is a list of members with specific roles. By making these SCM items
belong to a team Area, we implicitly give permissions and read access (in some cases) to these items to the users
who belong to that Team Area with those roles.
For the purpose of this pilot, the SCM items will be owned by the Project area.
3.2 Project Area and Team Area Mapping
The project area in RTC will map to customer, lines of business and enterprise wide programs. The aspiration is to
have a common process template across all the project areas. Team members will be assigned to the Team Areas as
well as the parent Project area. They will have the relevant roles and licenses assigned to them. The roles are
discussed in more detail later. Children team areas of the funded project team area will be created to manage
different Releases for a specific the funded project. Team members assigned to a team area also have to denote their
percentage allocation to that team. This is used for resource loading calculations in RTC.
In addition, we also represent Applications or a group of Applications into Team Areas. We now discuss the naming
conventions for these items.
3.3 Project and Team Area Naming Conventions
As stated above, project areas are used to control a related set of artifacts and team members who follow a common
process in order to achieve a particular goal. Team areas are used when further isolation within a project area is
needed or desired, or when one team needs to follow a different process than another team.
3.3.1 Project Area
The naming of the Project Areas will follow be based on the Application being developed in RTC:


<customer>
CM (Change Management)
3.3.2 Team Area - Project Planning

Team Areas will also be used to map the releases and maintanance work management in RTC.
Having a separate Team Area for a Release within a the project allows a Project Manager to have a customized
list of team members not just at the Project level but also specific to a release of that Project.
3.3.3 Team Area - SCM Applications
© IBM Rational, 2013
Page 10 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
<LoB><Project>_WEB-scm would be the top-level team area with a hierarchy of children team areas underneath it.
where the <LOB><Project>would represent the application <Project application> and WEB would be the team.
Note that this is an option that you may want to pursue later. For the present the Project area has ownership of the
SCM items.
Table 1 SCM Team Areas,
Parent Team
Sub-team
Sub-team
(optional)
XX-Teams-scm
SubTeam1-scm
SubteamA-scm
SubteamB-scm
SubTeam2-scm
SubteamX-scm
SubteamY-scm
…
..
© IBM Rational, 2013
Page 11 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
4. Timelines and Iterations
4.1 Overview
Each Team Area contains a hierarchy of iterations that define the “heartbeat” of the project. If the development
team needs to pursue concurrent release schedules for the same project, such as performing development work and
maintenance work at the same time, then these distinct schedules are represented in RTC as multiple timelines.
A timeline represents a collection of activities within a project that typically has its own schedule, deliverables,
teams, and process. Timelines are organized into a series of fixed development periods called iterations. Iterations
will represent the scheduled Releases. The timelines will be setup according to the following requirements:


Each Project Area will use a single Timelines, for Development Projects.
The new timeline, Development would be organized into iterations to reflect the different Releases.
4.2 Timeline, Iteration, & Team Area Conventions
Timelines and iterations are named using the following convention:
4.2.1 Timelines
There will be one main Timeline:
 <customer> Development
4.3.2 Iterations
 <customer> will create a iteration for each Release.
a. Release 12.3
b. Release 12.4
c. etc.
© IBM Rational, 2013
Page 12 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
5. Work Item Types, Workflows, Enumerations and Attributes
5.1 Overview
Work items are used to keep track of a team’s tasks and issues during the development cycle. The status and number
of active work items are indicators of the health of your project. RTC defines several out-of-the-box work item
types, but others can easily be created and customized as needed. Work Items have a list of attributes that are builtin. In addition custom attributes can be created to augment the information the information that is tracked by the
built-in attributes. The attributes are displayed in various presentations of the work item in the eclipse clients, web
browser and also within different sections of RTC like Plan views, Work Item Quick View, Work Item Details, and
Short Cuts for Creating work items. Work Items also have work flows associated with them that can be customized.
The remaining sub-sections define the work item types used on the project along with details about their attributes
and work flows. Enumerations are also used for certain attributes to denote a list of values that a user can select
from a dropdown.
5.2 Implemented Work Item Types
The Following Work Items will be used.
 Defect
 Task
 Build Deploy Request
 Issue
 Business Need
 Milestone
The Following Work Items will be considered optional.
 Project Change Request
 Risk
 Risk Action
© IBM Rational, 2013
Page 13 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
Figure 4 Work Item Types
Figure 4 denotes the work items that are available in the Project Area. Note the different icons associated with the
various work items as these are displayed in the Type column in Query results.
5.3 Work Item Workflows
Work Items have a workflow associated with them to track various statuses of the work item. In the figures below,
the text in the balloons denotes the status of the work item and the text on the arrows denotes the action that applies
to transition a work item from one state to another.
5.3.1 Defect and Task
Defect and task work item types use the Default work flow as shown below.
© IBM Rational, 2013
Page 14 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
Reopen
Reopen
Reopened
Reopen
Resolve
Close
Start Working
Initialize
Triage
Stop Working
New
In Progress
Resolve
Resolved
Verify
Verified
Closed
Close
Start Working
Start Working
Set Resolved
Untriage
Triaged
Triage
Resolve
Resolve
Figure 2 Defect Workflow
5.3.2 Project Change Request
Deferred
[Closed]
Reopen
Initialize
New
[Open]
Defer
Assign
Open
[Open]
Review
Ready
[Open]
Approve
Approved
[In Progress]
Assign
In Progress
[In Progress]
Resolve
Resolved
[Closed]
Close
Closed
[Closed]
Reopen
Rejected
[Closed]
Reject
Reject
5.3.3 Issue
© IBM Rational, 2013
Page 15 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
Invalid
[Closed]
Invalidate
Invalidate
Initialize
Stop Working
New
[Open]
Reopen
In Progress
[In Progress]
Start Working
Done
[Closed ]
Complete
Complete
Figure 3 Issue Workflow
© IBM Rational, 2013
Page 16 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
5.3.4 Milestone
New
Inactive
[Open]
Reject
Reopen
New
[Open]
Approved
[Open]
Approve
Close
Closed
[Closed]
Reopen
Figure 4 Milestone workflow
5.3.5 Risk
Invalid
[Closed]
Invalidate
Invalidate
Initialize
Stop Working
New
[Open]
Reopen
In Progress
[In Progress]
Start Working
Done
[Closed ]
Complete
Complete
Figure 5 Risk Workflow
© IBM Rational, 2013
Page 17 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
5.3.7 Business Need Workflow
Close
Deferred
[Closed]
Defer
Commit
New
Defer
Commit
New
[Open]
Propose
Proposed
[Open]
Approved
[Open]
Close
Closed
[Closed]
Uncommit
Reopen
Figure 6 Business Need Workflow
5.3.8 Build Deploy Request Workflow
The figure below denotes the workflow for the Build Deploy Request Workflow. This work item will be used as a
mechanism to document the list of work items that will be deployed to a staging environment in a Build. The work
items will be children work items of a Build Deploy Request work item.
Reject
Rejected
Reject
Reject
New
Reopen Reject
New
[Open]
Approve
Approved
[Open]
Build
Built
[Open]
Stage
Staged
[Closed]
Deploy
Deployed
[Closed]
Figure 7 Build Deploy Request Workflow
© IBM Rational, 2013
Page 18 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
5.4 Work Item Enumerations
Work Items have attributes which can be of various kinds. The following Enumerations will be used as content for
various drop-down lists in RTC work Items. Having a constant list enables consistency and ease in Reporting across
different projects. Listed below are the different Enumerations that will be used.
1. Priority: This is the level of urgency with regards to working on a work item.
Table 2 Priority Enumeration
Priority
Default Value
Unassigned Value
Values
Unassigned
Low
Medium
High
Low
None
2. Severity: This indicates the level of impact that the work item has on the submitter.
Table 3 Severity Enumeration
severity
Default Value
Unassigned Value
Values
Unassigned
Emergency
High
Medium
Low
Unassigned
Unassigned
3. Impact: This indicates the level of effect that the work item has.
Table 4 Impact Enumeration
impact
Default Value
Unassigned Value
Values
Minor
Moderate
Major
Moderate
None
4. Probability: A value to indicate level of probability.
Table 5 Probability Enumeration
Probability
Values
20% - Very Low
40% - Low
© IBM Rational, 2013
Page 19 of 43
RTC Project Management / Work Items Usage Model
Default Value
Unassigned Value
Version 1.0
60% - Moderate
80% - High
100% - Very High
20% - Very Low
None
5. Precision: A value to indicate level of accuracy.
Table 6 Precision Enumeration
Precision
Default Value
Unassigned Value
Values
Low
Medium
High
Medium
None
6. Constraint Type: A value to indicate level the type of schedule constraint to a work item.
Table 7 Constraint Type Enumeration
Constraint Type
Default Value
Unassigned Value
Values
As Soon As Possible
Start No Earlier Than
Finish No Later Than
As Soon As Possible
As Soon As Possible
7. actionstrategy: A value to indicate strategy to address an identified risk.
Table 8 actionstrategy Enumeration
actionstrategy
Default Value
Unassigned Value
Values
Mitigation
Contingency
Avoidance
Mitigation
None
8. Risk Category: A value to indicate the classification of risk.
Table 9 Risk Category Enumeration
Risk Category
Values
Socio-cultural
Political
Economic
Competitive
Technology
Regulatory/legal
Uncertainty/risk
© IBM Rational, 2013
Page 20 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
Market
Socio-cultural
None
Default Value
Unassigned Value
9. Found In: Build Label in which the Defect was found in.
Table 14 Found In Enumeration
Found In
Values
Test
UAT
Prod
Unassigned
Unassigned
None
Default Value
Unassigned Value
10. Filed Against: Work Item Category
Table 15 Filed Against Enumeration
Filed Against
Values
Unassigned
[values vary as project areas are
set up]
Unassigned
Unassigned
Default Value
Unassigned Value
11. Owned By: Work Item Category
Table 16 Owned By Enumeration
Owned By
Default Value
Unassigned Value
Values
Unassigned
[values vary as users are added]
Unassigned
Unassigned
12. Planned For: Iteration when the work item in planned to be done
Table 17 Planed For Enumeration
Planned For
Default Value
Unassigned Value
Values
Unassigned
[values vary as iterations are
added]
Unassigned
Unassigned
© IBM Rational, 2013
Page 21 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
5.5 Dependent Work Item Enumerations
Dependent Enumerations are lists that depend on value of another attribute. We are not going to use any Dependent
Work Item Enumerations.
5.6 Work Item Attributes
Work Item attributes are the fields that can be associated with a work item. Each Work Item has a list of inbuilt
attributes. In addition, there can be some additional custom attributes for a work item type. While all work items
have a built-in list of attributes, they are not used by all of the work item types. For a work-item attribute to be
useful, it also has to be exposed in some of the presentations associated with the work items. We will list all work
item attributes associated to a work item. As a best practice we should not modify the built-in attributes. If some of
these are not meant to be used then we just merely disable them from the presentations of the associated work item.
For the initial imnplementation, no custom attributes were created.
5.7 Resolutions
Resolution reason is associated with a work item type. In this case for defects following resolutions will be used.
Table 2 Defect Resolutions
Defect Resolutions
Unresolved
Later
Fixed
Works for Me
Invalid
Duplicate
Won’t Fix
Fixed Upstream
© IBM Rational, 2013
Page 22 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
5.8 Tracking Time against Work Items
Time tracked in RTC will be a subset of time tracked in TeamView. Time will only be reported if there is a Work
Item. Time will not be entered for Business Need. Estimate, Correction, and Time Spent fields will be used to track
Work Item time. The Time Tracking tab will be used. Time entered in RTC will be the Time Spent on a work item
(Task, Defect). In addition Estimates and any Correction to the Original Estimate will be entered in RTC. It is key
that most of the Tasks and Defects have the Estimate and Time Spent entries. This information helps with the
Project Plan tracking and also with Progress as a roll up on the Business Need that the task is a child of. Time can
be entered in hours. Progress on work items will be tracked by Time Spent. The Ranking attribute will be Priority.
The following will not be logged as actual hours:
 FTO hours
 Training hours
 Project status or planning meetings
 Non-project meetings
The following will be logged as actual hours:
 Requirements elaboration meetings.
Defects will be optional to log as actual hours. The granularity of tasks will be 2-16 hours, with an average of 8
hours. This is a guideline, with rare exceptions.
.
6. Roles, Policies, Permissions and Operation Behavior
6.1 Overview
There are 2 levels of permissions in RTC:
 Repository
 Process Role At Project Area/Team Area
Repository Permissions: The Repository levels permissions are defined in the User Editor of RTC. These are builtin and cannot be customized. The information in Table 3 describes the “Repository” permissions. At the repository
level all users will be “JazzUsers”. Admin Team will be both “JazzUsers” and “JazzAdmins” (giving them server
config and process template modification rights). Adding other users to the repository level groups (other than
JazzUser) has quite a bit of risk associated with it due to its “overriding” nature. ALL the items that PMs or super
users need to perform can still be set via Project Area and Team Area roles and permissions.
Administrative permissions will adhere to the following structure:
 Repository (AdminTeam) – admins over the server
 Project Area (Super Users) – admins over the project areas and team areas
 Team Area (PM) – admins over the team areas
Note: Remember that role/group permissions are inherited down from the parent. So in the bulleted list above, PMs
would also be admins over the Team Areas. Also remember you can override by setting explicit permissions at the
Team Area level.
Super Users will be Project Area Admins (added by the Admin team), which will give them the permissions they
need to admin all Team Areas within that Project Area (including the Project Area itself). The Project Area will be
setup by the Admin Team prior to the domain transitioning to RTC. That way all Team Areas that are created will
inherit the parent users/roles/timelines/etc from the Project Area.
© IBM Rational, 2013
Page 23 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
Doing this will protect the servers/projects/teams from people creating/modifying process templates, creating project
areas outside of the standard, and modifying settings that could potentially break things or bring projects down (or
make them unusable). This will also protect the repositories from getting cluttered with junk project areas and team
areas. In RTC there is no deleting (just archiving).
Process Role Permissions:
A team member’s permissions and operation behaviors are determined by their role. Roles can be defined in a
project area and/or a team area. Permissions and operation behaviors may be defined in a project area by role, and
further refined by team areas, timelines and/or iterations. These can be customized and are discussed in more detail
in the next section.
For further information on the 2 levels of permissions, see the following link:
http://publib.boulder.ibm.com/infocenter/clmhelp/v4r0m1/topic/com.ibm.jazz.platform.doc/topics/c_permissions.ht
ml
Table 3. Repository group permissions
JazzGuests
Read access to
repository
Write access to
repository
Control the data
warehouse
Create and
modify process
templates
Create project
areas
Modify access
control settings for
project areas
Save project
areas
Generate team
member
invitations
Yes
JazzUsers
JazzDWAdmins
JazzProjectAdmins
JazzAdmins
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Create users
Yes
Configure the
server
Yes
© IBM Rational, 2013
Page 24 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
6.2 Roles
Each project area and each team area can define a set of roles. The defined roles are visible in the area where they
are declared and in all child areas. Roles defined in the project area can be assigned to users for the whole project
area or they can be assigned in any team area. Roles defined in a team area can similarly be assigned in that team or
in any child team. It is important that when a user is added to a Project area or Team Area, he/she is also given the
appropriate Process role.
The roles for the project are listed in Table 3.
Table 3 – Roles
Role Name
Default (everyone)
Project Manager
Cardinality
(single,
many)
Many
Many
Team Lead - BA
Many
Team Lead - Dev
Many
Team Lead - QA
Many
Team Member
Many
Tester
Release Engineer
Stakeholder
Many
Many
Many
Description
Default role implicitly assigned to each user.
Leads the planning of the project, coordinates interactions
with the stakeholders, and keeps the project team focused
on meeting the project objectives.
Responsible for the activities of multiple Team Members,
assists with the iteration planning, accountable for
removing impediments to the ability of the team to deliver
the iteration goal/deliverables, acts as a buffer between the
team and any distracting influences related to the Business
Analyst activities
Responsible for the activities of multiple Team Members,
assists with the iteration planning, accountable for
removing impediments to the ability of the team to deliver
the iteration goal/deliverables, acts as a buffer between the
team and any distracting influences related to the
Development activities
Responsible for the activities of multiple Team Members,
assists with the iteration planning, accountable for
removing impediments to the ability of the team to deliver
the iteration goal/deliverables, acts as a buffer between the
team and any distracting influences related to the QA
activities
Responsible for developing a part of the system, including
designing it to fit into the architecture, possibly prototyping
the user-interface, and then implementing, unit-testing, and
integrating the components that are part of the solution.
Testers
Build Engineers
These are the people who enable the project and for whom
the project will produce the agreed-upon benefit[s], which
justify its production. They are only directly involved in the
process during the iteration reviews.
© IBM Rational, 2013
Page 25 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
6.3 Permissions
Each project area and each team area can define a set of permitted actions for each role.
High-Level RTC Permissions Overview
Role
Project Manager
SCM Capabilities
Team Lead
(Dev,QA,BA)
Team Member
R/W
R/W
R/W
R
Stakeholder
Ability to add,
delete, modify
tasks
R/W
R/W
Ability to add team
members
R/W
R/W
Snapshot
(Baseline)
capabilities
R/W
R
R
R
Personalize
Reports
R/W
R/W
R/W
R
Create New Team
Areas (projects)*
R/W
* Creation, deletion of Team Areas will be managed by the Team Leads.
6.4 Process Sharing
Roles, permissions, preconditions and configuration data can be shared between project areas. A project area can
choose to provide this information, consume this information, or not participate in sharing
Process Sharing will be set to “Allow other project areas to share this project area’s process”. Other Project
Areas that are created will use the Process Template associated with Master Formal Project Area.
See figure below.
Figure 8 Shared Process Template
© IBM Rational, 2013
Page 26 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
6.5 Access Control
Access Control designates which users have read access to the project area and its artifacts. If access is granted to
members of the project area hierarchy, anyone who adds a member to any team will implicitly grant access to the
entire project. For strict control, grant access to users in the access list only. Note that repository administrators will
always have access.
If this project area shares its process, anyone who can read a project area that uses the process will be able to read
this project area, regardless of this setting.
Access Control will be set to “Everyone”.
6.6 Operation Behavior
Each project area and each team area can define a set of actions (preconditions or follow-up actions) that are
triggered when certain RTC operations occur. The key actions are defined in Table 4.
Note: In Table 4, P/F stands for Precondition or Follow-Up action.
Table 4 – Operation Behavior
Operation
Process
Accept Team Invitation
(client)
Generate Team Invitation
(server)
Work Items
Save Work Item (server)
Everyone <add’l
role1>
<add’l
role2>
X
X
X
SCM
Deliver (client)
Action
Final P/F
(y/n)
Run Work Item Query
Run a query that displays the
work items assigned to the
logged-in user.
Create Invitation Work Items
Creates a set of initial work
items assigned to a user when
they are invited to join a team.
Y
F
Y
F
Required Properties
Verifies that a work item can
only be saved if all required
attributes are given.
Note:
Filed Against and Summary are
required.
Y
P
Clean Workspace
Do not deliver code that doesn't
compile
Descriptive Change Sets
Associate a work item that is
owned by you and is planned for
an iteration.
Require Work Item Approval
Work Item needs to have a
Developer Review done.
© IBM Rational, 2013
Page 27 of 43
RTC Project Management / Work Items Usage Model
© IBM Rational, 2013
Version 1.0
Page 28 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
7. Work Item Categories
7.1 Overview
Work item categories identify the various components or functional areas of your project. They are used to classify
work items so they can be allocated to specific team areas. Each category should map to its team area whose
members are responsible for developing the component or function. At minimum, each Team area should have at
least one Category associated with it.
When a work item is created, its “Filed Against” property (i.e. work item category) must be set. Members of the
project/team area associated with the work item category receive notifications when the work item is created or
modified.
7.2 Work Item Category Names
Table 5 lists the key work item categories used by the project. For completeness, make sure that all Project/Team
areas listed in Error! Reference source not found. are included in this table. If Projects create children Team
reas for Releases, this has to be reflected in the Work Item Category by creating suitable Category and associating it
with the child team area.
Table 5 –Key Work Item Categories and Mapping to Timelines/Team Areas
Timeline
<customer>
Development
<customer>
Development
<customer>
Development
<customer>
Development
WI Category
Unassigned <Root Category>
Project Area / Team Area
<customer>
CM [Project Area]
<customer>
<customer>
_Dev_12.3
<customer> _<Project
Application><version>
<customer>
_Dev_WEB_12.3
© IBM Rational, 2013
_Dev_12.3
<customer> _<Project
Application><version>
<customer> _WEB
Page 29 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
8. Plans
8.1 Overview
Plans are used to manage work items for a project/team that are planned for completion in an Iteration. As work
items are created, they are assigned to work item categories and iterations. If the work item categories are
associated with a team, the associated work items in the team’s plan are based on the work item’s category and
planned iteration. If the work item is not associated with a team area, a project area is used instead. Plans are used
to create and modify work item assignments and to track the progress of work that is committed for an Iteration.
There are four types of Plans that can be created - Product Backlog, Phase Plan, Release Plan and Schedule Risk
Assessment.
Figure 9 Phase Plan Type Modes
© IBM Rational, 2013
Page 30 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
Figure 10 Schedule Risk Assessment Plan Type Modes
Figure 11 Release Plan Type Modes
© IBM Rational, 2013
Page 31 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
Figure 12 Release Plan Type (Custom) Modes
© IBM Rational, 2013
Page 32 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
Plan Types
8.1.1 Product Backlog Plan
The product backlog plan is the highest-level plan in Rational Team Concert. It provides a brief overview of the
project goals. A product backlog plan displays top-level work items associated with a project or team area, child
team areas, current iteration and its child iterations. A project release plan is typically created only for the top
iteration of a project. Other plan types are created for child iterations. We will not be using the Product Backlog
Plan for the funded Project management.
By default, a product backlog plan groups work items based on the following plan modes:

 Iterations
 Ranked List
 Work Breakdown
8.1.2 Phase Plan
The Phase provides a high-level overview of the work associated with a team for phase in the software development
lifecycle. The plan will show all work items for an iteration and all top-level work items of its child iterations. The
Release Backlog plan will be used for Project Management of the funded Projects. These plans will be named using
following naming convention:
Team Area Phase Name , where Team Area is the name of the Team Area that owns this plan.
E.g. <customer>
Release 12.3 Construction
By default, a team release plan groups work items based on the following plan modes:

 Schedule Variance
 Work Breakdown and Schedule
 Work Breakdown
8.1.3 Schedule Risk Assessment Plan
The Schedule Risk Assessment Plan provides a risk of not completing the work items based on probability of
completing the work items in a given time. The schedule risk assessment plan helps to determine which work items
may or may not make it to completion in an iteration. This plan type will not be used now.
By default, an iteration plan groups work items based on the following plan modes:
 Schedule Risk - Displays work items being completed within a standard deviation of current plan schedule.
© IBM Rational, 2013
Page 33 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
8.1.4 Schedule Risk Assessed Sprint Backlog Plan
The Schedule Risk Assessed Sprint Backlog plan displays the risk assessment for each team member of a team area
or project area based on work item estimates. Given the number of work items, their time-to-complete estimates,
and the duration of an iteration, work items can be categorized based on their probability of completion in an
iteration. The schedule risk assessment plan helps to determine which work items may or may not make it to
completion in an iteration.
8.1.5 Release Plan
The Release Plan displays the different work items that are planned for a specific release by the team that owns the
Release Plan. The Release Plan will be named after the Team Area and Release of the Plan.
e.g. <customer>
Release 12.3 Plan.
9. Streams, Components and Workspaces
9.1 Overview
RTC SCM provides support for version control and configuration management for artifacts that can be stored as
files or folders. At a high level the RTC SCM flow can be described in the picture below referred from here.
Streams are used to associate specific versions of files and folders organized in components. Repository workspaces
are used by developers to flow changes to the streams.
© IBM Rational, 2013
Page 34 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
Figure 13 RTC SCM Flows
9.1.1 Streams and Components
A stream is a collection of one or more components. A component is a collection of related artifacts, such as the
code for a plug-in, or the group of documents that are used on a web site. Artifacts under source control are grouped
into components, which can be included in zero or more streams. Any group of files and folders that share a
common root can be a component.
Streams allow an organization to work on different versions of the same components in parallel. For example, one
stream could be configured for the most recent version of a release’s components while another stream could be
configured for the maintenance of an earlier version of that same software.
9.1.2 Baselines and Snapshots
A component baseline is an object that includes exactly one version of every artifact in the component. It provides
an immutable record of the configuration of a component in a particular workspace or stream. Baselines are fixed
points of reference, useful for reverting a component to an earlier configuration, or for initializing streams and
workspaces for new development.
A snapshot is a repository object that includes exactly one baseline for each component in a repository workspace or
stream. Snapshots are useful for capturing the state of a workspace, and are typically used to record important
workspace configurations so that they can be recreated. A workspace snapshot provides a persistent record of the
configuration of a workspace, expressed as a collection of component baselines.
© IBM Rational, 2013
Page 35 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
9.1.2.1 Baseline Creation and Delivery
Component baselines will be created at key points in the project and delivered to the team integration stream for
dissemination to the rest of the team. This should be driven by Build automation.
9.1.2.2 Snapshot Creation and Promotion
Snapshots can be created at any point during project development. Mandatory snapshots are created for each
significant release and stored on the project’s main integration stream. Builds will be the primary creator of
snapshots.
© IBM Rational, 2013
Page 36 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
9.1.3 Local and Repository Workspaces
A workspace is an area where you can view or modify components. A repository workspace on the server stores
components as versioned artifacts whose data and metadata can be viewed, but not directly modified. Artifacts from
repository workspaces can be loaded into local workspaces on the client machine where they can be modified.
The diagram in Figure 1 depicts the relationships between local workspaces, repository workspaces, streams and
components. Users check in artifacts from their local workspaces to their repository workspace. A user delivers
changes from his repository workspace to a stream. Likewise, a user accepts changes from a stream into his
repository workspace and loads the changes into his local workspaces.
Stream
Component(s)
Deliver
Deliver
Accept
Accept
Repository Workspace1
Repository Workspace2
Accept
Component(s)
Check In
Component(s)
Load
Check In
Load
Local Workspace2
Local Workspace1
`
`
Figure 14 RTC Streams and Workspaces
9.2 Naming Conventions
It is a good practice to use consistent naming conventions for the different RTC SCM items. This helps with
communication and collaboration. In addition, any future automation will be readily possible with pre-planned
names for items like, Repository Workspaces, Components, Streams, Baselines and Snapshots. The following
guidelines will be used to define naming conventions.
1. Team area naming convention for SCM will include “-scm” to differentiate them from the Team Areas that
represent <customer> funded projects.
2. Suffices should be in lowercase.
3. Word boundaries should use dashes instead of underscore.
4. Abbreviations will be in Uppercase.
9.2.1 Repository Workspaces
Repository workspaces are named using the following convention:
stream_name_<user-id>_wks
where stream_name : Stream Name of the Default flow target of Repository workspace
<userid> : Usually User's FLastname. eg BFranklin
© IBM Rational, 2013
Page 37 of 43
RTC Project Management / Work Items Usage Model
Example:
<customer>
<customer>
<customer>
<customer>
_Dev_BFranklin_wks
for User Ben Franklin.
_UAT_BFranklin_wks
for User Ben Franklin.
Version 1.0
Repository workspace for the <customer>
_Dev Stream for
Repository workspace for the <customer>
_UAT Stream for
9.2.2 Local Workspaces
Each user can have one or more local Eclipse workspaces or Sandboxes in case of Visual Studio, on their
workstation that use the following naming convention:
<drive_letter:>[\workspace]\
<Streamname>_<userid>_wks
Examples:
c:\ workspace\ <customer>
Dev Stream development
c:\ workspace \ <customer>
Stream development
_Dev_BFranklin_wks
_UAT_BFranklin_wks
Local workspace for <customer>
Local workspace for <customer>
for
for UAT
9.2.3 Streams
Streams are named using the following convention:

<Application Name>-<Dev/UAT/Prod>_Stream
where
<Dev/UAT/Prod> : Mainline or UAT or Production Support


e.g. <customer>
e.g. <customer>
_Dev_Stream
_UAT_Stream
9.2.4 Components
Component names should be of reasonably short length. The recommendation is to keep component names as short
as possible while still conveying meaning.
<Application Name>-Name_comp
where
Name would be optional if the entire Application is within a single component. Otherwise, name will convey some
characteristic that could have functional or architectural meaning.
Eg. <customer>
_comp
9.2.5 Baselines
Baselines are named using the following convention:

<Type>-<Label>-bl
where
Type: Initial/Manual/Build
Label: Date Time stamp or Qualifier (manual)
e.g. Build-20110831-0240-bl
9.2.6 Snapshots
© IBM Rational, 2013
Page 38 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
Snapshots are named using the following convention:

Streamname_DateTimeStamp_ ss
where
e.g. <customer> _QA_20120426_ss
The Table below summarizes the different naming conventions for the SCM items in Rational Team Concert.
Table 6 Naming Conventions
Item
Repository
Workspace
Prefix
Stream name of
default flow target
Stream
Component
team area for scm
team area for WI
baselines
app name
app name
Snapshot
Stream Name
local workspace
(sandbox)
* need a short name
and path (256 char
limit in windows)
project area
build definition
build label
Name
Last + first init + seq
(if needed)
or Build
Dev or QA or UAT
component
Team Area
Proj Name
Auto generated build
label
date+time
(yyyymmdd-hhmm)
DateTime Stamp
(yyyymmdd)
Initial
build
manual
build def
name
stream
comp
scm
none
bl
(blank for RTC
builds)
ss
wks
<customer>
Dev
QA
UAT
Auto generated build
label
date time
app name
Suffix
wks
build
9.3 SCM Stream Strategy
RTC streams and repository workspaces provide a tremendous amount of flexibility in allowing developers
and teams to support a wide variety of situations. For more examples of using streams and workspaces in a team
environment, see “Multiple Stream Development” at http://jazz.net/library/article/40. In addition the following
article at https://www.ibm.com/developerworks/rational/library/parallel-development-rational-team-concert/ also
details some of the considerations with defining RTC streams. Stream Strategies should support Mainline
development across multiple projects and multiple monthly releases. It should also support teams of different sizes
and using heterogeneous technologies including Java and .NET. We have following recommendations for
organization of streams based on size of the application being developed. Feature based stream discussion is
deferred till we get to the enterprise deployment of RTC.
9.3.1 <customer>
Application Streams:
© IBM Rational, 2013
Page 39 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
The criteria for selecting this stream configuration would be applications that have an extended period of
stabilization where activities like extensive QA testing may occur, before being deployed to production. In addition
there is also support for a period of production support before the next release is deployed to production. During
periods of regular development, developers will collaborate and share changes in a single stream called Dev
(MainLine of Development).
This scenario is illustrated in figure below.
Release
1.0
Prod
Release
2.0
Deliver
UAT
Release
1.0 RC
UAT
UAT
Release
2.0 RC
Deliver
QA
QA
Release
1.0 RC
Deliver
QA
Release
2.0 RC
Deliver
Deliver
Dev
Snapshots
Figure 15 <customer>
Application SCM Streams
9.3.2 Work Spaces and Flow Targets
Initial development will start with a single integration stream, also called <customer> _Dev_stream (Dev). Users
will check files into their respective repository workspaces and deliver their changes to the main integration stream.
9.3.3 QA Stream
Initially for the first time, when a team is ready to provide a build for extended QA, a Release Candidate (RC)
stream is created for QA called <customer> _QA_stream. This will be a long -lived stream and will be used for
sub-sequent releases as well. Team members supporting stabilization and RC defects will create a repository
workspace with default flow target to the RC stream. They will also occasionally flow their fixes to the Dev stream.
It will be the responsibility of the Team Lead to ensure that all Changes delivered to RC stream will have also
flowed to Dev stream if they are relevant.
The scenario can be extended in the case of QA and Production support by adding streams <customer>
_UAT_stream and <customer> _Prod_stream. These will also be a long lived streams and will be used for UAT,
Production and Production Support Builds. A developer supporting Prod, will have a repository workspace whose
default flow target will be <customer> _Prod_stream, but will also optionally deliver their fixes to the Dev stream
and QA stream if there is a future RC activity. There will be a milestone when all fixes in Prod will be flowed back
© IBM Rational, 2013
Page 40 of 43
RTC Project Management / Work Items Usage Model
Version 1.0
to Dev on a regular basis. This will have to be done by a designated developer, likely the Development Team leader.
10. Builds
10.1 Overview
The RTC Build function provides support for automating and monitoring a team’s regular builds. RTC includes the
Jazz Build Engine and an Ant build toolkit that can publish build information to the RTC repository. The following
build-related items are stored in the RTC repository and support the build process:




Build definition - Defines a build, such as a project build.
Build engine - Represents a build system running on a build server.
Build request - Represents a request to run a build.
Build result - Represents the output from a build.
You can use the RTC client to perform the following tasks:



Submit a request to run a build definition.
Check build status.
View completed build outputs, such as logs, downloads, and artifacts.
RTC builds are typically run against files that come from a designated build repository workspace that has incoming
flows from the team's main development stream. Before running a build, the latest changes are accepted from the
team's stream into the build workspace and a reproducible snapshot of the files is created. After a build is
considered good, a Release can be created from it.
<customer>
will implement following types of Builds:
1. Personal Developer Builds
2. CI Builds for Development
3. Scheduled Builds for QA,UAT
4. Prod Builds
5. PS Builds
These will be created by the respective Application owners.
10.2 Best Practices for Builds
The Ant build toolkit and Jazz Build Engine require a username and password for logging in to the Jazz repository.
The following best practices help to manage build users:




Create a separate build user. A separate Build user should be used for each domain.
Assign a Build System client access licence to the build user.
When you create an RTC source control workspace for the build, set the build user as the workspace owner.
If you run multiple JBE processes on a single server carefully select their properties so that there are no
collisions among them.
11. Appendix A - Glossary of Terms
Backlog
A Backlog is a collection of prioritized requests (also known as requirements) of work to
be done.
© IBM Rational, 2013
Page 41 of 43
RTC Project Management / Work Items Usage Model
Baseline
Epic
Iteration Plan
Iterations
Plan Item
Plan Type
Planned For
Product Backlog
Project Area
Project Release
Plan
Project Snapshot
Releases
Role
Business Need
Team Area
Team Release
Plan
Timelines
Version 1.0
A permanent copy of a component in a particular repository workspace or stream. A
component baseline represents a configuration of a component at a particular point in
time.
A collection of stories that would represent a higher level capability.
An artifact that shows the work items and additional unstructured information for a team
or project area within a development phase.
An iteration is a single development cycle, usually measured as one week or two weeks.
Iterations typically have a start and end date. Iterations can be planned to deliver a
result by marking them with "A release is planned for this iteration". The dates and
the delivery information are used by the planning component to calculate availability of
time and which iterations to consider having plans.
Iterations can have an iteration type. Iterations with no delivery planned and with no
dates configured can be used to control the process behavior within a parent iteration.
Each timeline has a current iteration that controls the process behavior.
A set of work item types that are used for project/release planning purposes.
The process of a project area provides available Plan Types to create a new plan. The
plan type determines what the plan will show. Which plan types are available depends
on the Process Template that was used when creating the project.
A work item field that identifies the iteration that the work item is scheduled to be
resolved in.
The container for all not-yet-planned stories.
The representation of a software project, including the project area defines the project
deliverables, team structure, process, and schedule. Project areas define the process
used by everything they include. The initial process definition and description are
provided by a process template.
An artifact that shows plan items and additional unstructured information for a team or
project area and all related child team areas and iterations.
A subset of a baseline that identifies artifacts that have been approved or assigned to a
milestone or other meaningful event.
When planning a product release, product owners execute a top-down approach by
writing down epics and stories, then assigning the stories to the individual Iterations to
be implemented. The product owner creates a plan per team- or project area, targeted
for the release iteration to be tracked.
It is a common need to know for which release or version a work item has been
created. To support this, the project area provides a central place to maintain releases.
Releases such as "1.0", "2.0", "2.0 M3" can be created and maintained manually. It is
also possible to create a release from a build result.
A list of functions within the project that will inherit certain permissions to perform
actions based on the Process template configuration.
A work item that captures a requirement or a capability for the application that is being
developed.
A place within a project area for managing team membership, roles, assignments, and
team artifacts. Team Areas inherit the project area's process, roles, permissions and
operational behavior.
An artifact showing plan items and additional unstructured information for a team or
project area and a development iteration and the associated child iteration plans.
The project area defines one or more timelines which define how a given planned
period of time is partitioned into iterations such as releases milestones etc. A project
area can be assigned to exactly one project timeline to work against at any instance
in time. Team areas contained in a project can also each be assigned to exactly
one timeline to work against at any instance in time.
© IBM Rational, 2013
Page 42 of 43
RTC Project Management / Work Items Usage Model
© IBM Rational, 2013
Version 1.0
Page 43 of 43