Overview
The ALM schema relies on some primary, interrelated record types for ensuring that requests for change are assessed, assigned, tracked, worked on, and resolved with a process that ensures complete traceability and tracking.
The primary record types are ALMRequest, ALMTask, and ALMActivity. An ALMRequest record represents a request for some type of change. An ALMTask addresses a Request and helps manage the Activities that are the units of work to complete the Task.
An ALMTask can be used by a manager or team lead to manage work to be done and the resources to be allocated for all Activities.
Each of the ALM work record types has a Type field that can be used to describe a work type (such as Defect, Enhancement, and Release requirement). Although the ALM packages include supplied Type values that are common for software development best practices, you are not limited to them, and create your own types.
Relationships between the record types can help facilitate the processes for managing change across multiple roles. For example, when a Request record CreateTask action is executed, one or more Tasks can be created. If Tasks have already been created for this Request, you can specify that the same or a different set of one or more Tasks be created with Task types that are the same as the Request types, or different ones. When a Task record CreateActivity action is executed, one or more Activities of different types can be created. If Activities already exist for that Task, you can create a different set of Activities. The flexibility to customize the work process is available but optional.
Each work type can have specific user roles associated with them (for example, associate Test role with Test Activity). Each role lists the team members who are allowed to perform that type of work.
- A user submits a request. The change request could describe an enhancement request, a release requirement, or a defect.
- A triage team or change control manager reviews the request and accepts or rejects it. If they accept it, they create a task, which is a high-level description of the work to be done to implement the request. The request record includes a link to the task record, and the task is assigned to a project.
- A lead developer or other team lead reviews the task and then activates it. Activating the task creates activities to complete the task. The team lead assigns these activities to team members. Examples of activities are Development activities; Test activities; and Documentation (Doc) activities. The task record includes links to the activity records, and the activity records have links to the task.
- Developer, Test, and Doc leads assign their activities to team members who update the activity records to reflect the status of their work. When they finish work they deliver their changes and mark their activities Complete.
- A release engineer integrates and builds delivered changes, and creates baselines.
- A tester tests changes in the baselines. The Test lead marks a test task Complete, after the test activities are worked on and completed.
- The user who submitted the request reviews the task and its activities and, if satisfied, marks it Complete.
- Submitters. While not a defined ALM role, a submitter can
be anyone, for example, any support engineer, developer, tester, technical
writer, or manager. A submitter can:
- Submit requests.
- Check on request status.
- Development or project managers or team leads. These roles can
triage requests and identify release targets. A manager can:
- Check on request status and close as appropriate.
- Check to see if the workload for developers is balanced appropriately.
- Run reports (request metrics, find, close, incoming, status of release).
- Doc Assessor, Tester, and Developer These roles:
- Find requests assigned to them.
- Work on and resolve requests.
- Support or product manager. These roles:
- Run reports (request metrics, find, close, incoming, status of release).
- Check on request and release status.
While a user may fill multiple roles at any given time, an ALM schema allows for a more clearly defined transition between the roles. For example, the same user, who is a Developer, can submit a Request and then assign an associated Activity to him/herself, and resolve it. In this example, the same user is the Submitter, Developer Lead, Developer, and Tester.