Roles in an ALM process

The ALM packages provide support for a role-based change management (CM) system design through a collection of record types that apply to role-based development.

Your work process determines what actions are available for each record type (such as Project, Request, Task, Activity, Baseline, and Build). For example the following roles might perform these actions:
  • Submitter is a role that submits a Request.
  • The Triage role triages requests, and can add and plan Tasks.
  • The Developer Lead and Test Lead roles activate a Task, and assign Activities. They assign different kinds of activities for the Tester, Doc Assessor, and Developer roles.
  • Developer is a role that can deliver a change, and complete an Activity.
  • Builder is a role that can create a Baseline, run a Build, and validate and promote a Build.
  • Tester is a role that can perform tests (as a kind of Activity), and complete an Activity.
  • The Test Lead can review the status of and complete a Task.
  • When a Task is completed, the original Submitter can accept a Task, if the completed Task resolves the original Request, or reject the Task.

Because a Request can be Completed or Withdrawn at any time with work still proceeding with the associated Task, or a Task can be Completed at any time regardless of the state of the associated Activities, only a manager or team lead user role should have the user privileges to Complete a Task once the associated Activities are Completed.

A Request submitter can be any user of the system and the submitter can Accept or Reject Request resolution. All users can also perform Comment record type actions.

When an Activity is Submitted, the mastership of it can transfer to the site of the person responsible for doing the next Activity action. Mastership is controlled by the ratl_mastership property of the Role Primary member included on the WorkConfiguration Activity record for each given Type. Also, if the Role Primary member is supposed to do the next action on an Activity they must have the action listed in the Role ApprovedActions to allow them to perform the action (for example, to Open an Activity if they are going to work on it). The OOTB sample configurations provided you with and enable you to use a system that incorporates these best practices.