Filter
Top Products
Chapter 6. Working with component and release processes
The previous chapter described how to work with parts when the release does not
follow a tracking process. This chapter describes how to work with parts when a
tracking process
is
followed and how to use component processes for features and
defects.
When tracking is part of the process, users must associate any changes to their parts
with the defects or features active for the release. This association is made through a
work area. The work area is the object that ties a defect or feature with a specific
release. When checking out a part, the user must specify the work area with which the
modification is associated. For any release and defect or feature pair, there can be
multiple work area objects.
Aside from their association with a defect or feature, the work areas for a full-tracking
process environment are identical to those defined for working in a no-tracking process
environment. Work areas maintain a separate view for the user working on the
modifications associated with a defect or feature without affecting the release. This view
can be integrated with the release at some point. A work area is implicitly created when
a defect or feature is accepted if the managing component follows a design, size, and
review process for defects and features and if a sizing record is created. The work area
that TeamConnection creates is based on the sizing record and has the same name as
the defect or feature. If sizing records were not created, you must explicitly create the
work area.
As an example of how this all works, suppose that the robot project from the previous
chapter is entering system test. The administrator decides to turn on a full-tracking
process for the release, such as track_full. This process includes the track, approval,
fix, driver, and test subprocesses. The release follows concurrent development, and the
component follows a design, size, and review process for both defects and features.
On a weekly basis the project leader, Carol, creates a driver. A
driver
monitors and
implements the integration of part changes within a release. These part changes are
included in a driver by adding the work areas referenced by the changed parts to the
driver as
driver members
.
One of the testers for the robot project discovers that the autofocus mechanism in the
robot’s eye fails when the robot is placed in front of striped wallpaper. The tester must
open a defect against the component optics, which is owned by Carol. Carol verifies
that the problem does exist, accepts the defect, and assigns it to Alex. This fix will
require the tasks noted in the following table:
For information about this task, Go to this
page.
Changing the defect owner 79
Accepting the defect 80
© Copyright IBM Corp. 1992, 1995, 1996, 1997, 1998
77