Overview of ALM work process

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 HCL Compass 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.

A typical ALM process is as follows:

  1. 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.
  2. 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.
  3. 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 activities required to complete the task, such as:
    • Dev activity
    • Test activity
    • Doc Assess activity

    The lead developer assigns the Dev activity to a developer.

  4. 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.
  5. 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.
  6. The release engineer creates a new baseline record that selects the newly completed activity and its associated change set.
  7. 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.
  8. The tester installs and tests the build. When the build successfully passes all tests, the tester moves the Test activity to the Completed state.
  9. 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.
  10. 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.
  11. 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.