Filter
Top Products
Chapter 4. The states of TeamConnection objects
The actions that you can perform on certain TeamConnection objects are controlled by
two factors:
v The process followed by the component and by the release
v The current state of the object
Certain TeamConnection objects follow certain states through their life cycle. An
instance where an object might not follow all the possible states is when it moves
through the states defined in the subprocesses of the component and the release. The
following table briefly lists the component and release subprocesses. For more
information on component and release subprocesses, refer to the
Administrator’s Guide
.
Component subprocesses
v dsrDefect - Design, size, and review fixes to be made for defects
v verifyDefect - Verify that defect fixes work
v dsrFeature - Design, size, and review changes to be made for features
v verifyFeature - Verify that feature changes work
Release subprocesses
v track - Relate all part changes to a specific defect or feature and a specific release
v approval - Require all changes to be approved before incorporating them into a
release
v fix - Use fix records to ensure that all required changes are made
v driver - Use drivers to integrate changes into a release
v test - Require all changes to be tested before they are integrated into the release
This chapter explains the possible states of certain TeamConnection objects and how
objects are moved from one state to the next. It also explains how component and
release subprocesses affect the flow of states. For a diagram showing the flow of
states, refer to the poster
Staying on Track with TeamConnection Processes.
Defects and features
Use defects to report problem information; use features to record information about
proposed design changes. After you open defect or feature, TeamConnection tracks the
progress of the defect or feature through various states. Defects and features are
tracked according to the processes followed by the release and component that they
are assigned to. The possible states for defects and features are:
Open state
When you open a defect or feature, it is in the open state and you are
considered the originator.
You assign the defect or feature to a component. The owner of this component
becomes the feature or defect owner and is responsible for managing its
© Copyright IBM Corp. 1992, 1995, 1996, 1997, 1998 41