In the ALM work process, requests are resolved by completed tasks
and activities.
The Application Lifecycle Management (ALM) schema and packages provide
an out-of-the-box process for using Rational® ClearQuest® to track your team's work
on a product release. ALM uses defined roles, record types, and state transition
models to help you manage the software development process from requirements
submission through development, build management, and testing.
The basic ALM process is as follows:
- A stakeholder submits a request against a software project. The stakeholder
could be a developer, tester, writer, trainer, product manager, customer support
representative, or other member of the project team or user of the product.
A request can initiate a change to the software project. A request can be
a defect, a request for enhancement (RFE), or a task.
- The triage team reviews the request and decides whether to accept it or
reject it. If they accept the request, the triage administrator creates one
or more tasks (one per project) that describe at a high level the work required
to satisfy the request.
- The lead developer for each project reviews the task and assesses the
work required to implement it. The lead developer then activates the task
and creates three activities associated with the task:
- Dev activity
- Test activity
- Doc Assess activity
The lead developer assigns the Dev activity to a developer.
- The lead tester reviews the task and the Test activity, then assigns the
Test activity to a tester. The documentation leader reviews the task and the
Doc Assess activity, then assigns the Doc Assess activity to a writer.
- The developer works on the Dev activity and makes the necessary changes
to files. The developer then moves the Dev activity to the Completed state.
- The release engineer creates a new baseline record that selects the newly
completed activity and its associated change set.
- The release engineer builds the project by using the newly created baseline.
The release engineer creates a build record that identifies the baseline used
and indicates whether the build succeeded or failed.
- The tester installs and tests the build. When the build successfully passes
all tests, the tester moves the Test activity to the Completed state.
- The writer assesses the impact of the task on the documentation and makes
all necessary changes. The writer then moves the Doc Assess activity to the
Completed state.
- The lead tester reviews the task, sees that the necessary activities have
been completed, and moves the task to the Completed state. Alternatively,
the lead tester creates additional activities, or comments on existing activities,
if more work needs to be done.
- The stakeholder who submitted the request reviews it and sees that one
or more associated tasks have been completed. The stakeholder can open the
task and review the resolution. From within the task record form, the stakeholder
can open the associated activities and review the details of the development,
documentation, and testing work done to complete the task. If everything looks
satisfactory, the stakeholder accepts the request, which moves it to the Completed
state. Otherwise, the stakeholder can reject the request and comment on the
task, which notifies the lead tester by E-mail, with instructions for additional
work.