Step 3: Core Processes, Roles and Tasks

In order to define how the PRM has to be used, core Processes and Roles are required. The aim here is to have the procedures indicating how people can interact with the PRM in the scope of the Project. Every Project is free to define the details of theses processes and roles. We propose here a possible definition.

7.4.1 Core Processes

Change Ownership. This Process enables the change of ownership of the Project if the owner plans to quit the project.

πownership = ProjectActivity.setContact(Actor)

Project Modification. This process allows changing information about the project.

πprojectModification = (ProjectActivity.setTopics(PTopic)||

ProjectActivity.setDescription(Text)||ProjectActivity.setContact(Actor));

Artifact Declaration. This Process is used to register new types of Artifacts for further use within Activities.

πartifactDeclaration = ArtifactActivity.registerArtifactType(TypeDirectory, ValuationDirectory,PI R^,Project);

Activity Declaration. This Process creates a new Activity as a set of operations bound to Integri-tyRules.

πactivityDeclaration = ActivityActivity.declareActivity(Name,P(λ,PI R^));

Activity Association. This Process binds a created Activity to a Project. This allows to share Activities among Projects.

πactivityAssociation = ActivityActivity.associateActivity(Activity,Project);

90 CHAPTER 7. PRM IN ACTION Process Definition. The Process of defining Processes consists in the creation of the different Pro-cessSteps, the declaration of the Process, then the sequencing of the different steps. Note that a Process can be used as a ProcessStep to chain different Processes.

πprocessStepDeclaration = (ProcessActivity.declareProcessStep||

ProcessActivity.declareLoopStep||

ProcessActivity.declareConditionStep);

πprocessDeclaration = π⁺ProcessActivity.processStepDeclaration;

ProcessActivity.declareProcess(Name,ProcessStepfirst,Directoryinterests, Directory_knowledge,Directorycompetences,ProcessType);

ProcessActivity.setProcessStepSequence(ProcessStep_previous,ProcessStep_next)⁻; Role Definition. Processes indicating what the responsibilities of a Person are gathered as Roles.

πroleDeclaration = RoleActivity.declareRole(Text_name,Text_description,PProcess);

Actor Registration. This Process allows the registration of new Actors with the PRM.

πactorRegistration = ActorActivity.registerActor(DirectoryActor);

Actor Invitation. Registered Actors can be invited to become community members of Projects thanks to this Process consisting of proposing a Role to an Actor.

πactorInvitation = ActorActivity.proposeRole(Role,Actor,Project);

Role Acceptance. Actors can retrieve Roles having been proposed to them. Then they can accept or reject them. This is illustrated by the following Process.

πinvitationAcceptance = ActorActivity.getRolesProposed(Actor,Project);

ActorActivity.answerRoleProposition(Role,Actor,Project,Boolean);

Contribution Proposition. Actors can apply for a Role through this Process. This allows Actors to be proactive while searching for Projects where they could help.

πcontributionProposition = proposeRoleContribution(Role,Actor,Project);

Actor Binding. This Process registers an Actor as a Contributor of a Project.

πactorBinding = ProjectActivity.registerContributor(Actor,Project);

Task Attribution. Once a Role has been accepted by an Actor or once an Actor has proposed himself for a Role, the Role can be assigned to him. Role assignment results in the creation of corresponding Tasks. Further the Role can be unassigned as any time, which results in the deletion of corresponding Tasks.

πtaskAssignment = RoleActivity.assignRole(Actor,Project,Role)||

RoleActivity.unassignRole(Actor,Project,Role);

7.4. STEP 3: CORE PROCESSES, ROLES AND TASKS 91 Actor De/activation. As Actors can leave the project or can become inactive while still being a mem-ber of the community of a Project, this Process allows to declare Actors as being active or inactive.

πactorActivation = (ProjectActivity.activateActor(Actor,Project)||

ProjectActivity.deactivateActor(Actor,Project));

7.4.2 Core Roles

Bootstrap. This is the central Role of the Project. When the project is created it includes all other core Roles. The Actor creating the Project receives thus this Role, which enables him to bootstrap the use of the PRM by registering people, assigning tasks etc.

Project Manager. This role enables the person it is assigned to to modify contact information about the Project, it includes the processπprojectModification.

Community Manager. This role enables the Project to keep control over its community, by baning undesirable Actors or inviting need ones. Involved Processes are:πactorBinding andπactorActivation. Activity Manager. The Activity management role handles the declaration and association of new Activities and Artifacts to Projects. This Role is central, as it enables Projects to evolve and to propose new features to the community. It involves two processes: πartifactDeclaration, πactivityDeclaration and πactivityAssociation.

Roles Manager. This role is responsible for the definition of the processes of the Project and for their gathering as new Roles. The two key processes it has to execute are thus: πprocessStepDeclaration, πprocessDeclaration andπroleDeclaration.

Tasks Manager. Defined Roles have to be distributed to the different community members but they also need to be removed from a community member once he or she retires. These are the processes the Task Manager Role has to handle:πactorInvitation,πtaskAssignment.

User. Any user can receive Roles propositions from Task Managers. This involves the following two Processes:πinvitationAcceptance,πinvitationAcceptance. Note that any Person registered on the PRM obtains this Role.

7.4.3 Core Tasks

To be usable, the PRM requires that these core Roles be assigned to the community members of the Project. Here follows how they are dispatched in our scenario.

As Alex created the Project, he obtains the Bootstrap Manager Role. It allows him to associate the other Roles to the other members of the Project. Alex wants to keep control over the information which is published about the Project, he assigns thus the Project Manager Role to himself. He also wants to have contact with the community and be able who will participate in the Project. Thus he also keeps this role.

As John is a PRM specialist Alex assigns the Activities Manager Role to him. Roles Management role is given to Alice because she has expertise in process management and as Shelly is good at evaluat-ing people’s competencies and at organizevaluat-ing teams, she receives the Tasks management Role.

As a bootstrap manager, Alex executes the processes πactorBinding andπtaskAssignment in order to create the core community of the Project and assign to it the core tasks. This results in the following calls to the PRM :

92 CHAPTER 7. PRM IN ACTION

Once the Project is created and core Roles have been assigned, specific Artifacts and Activities can be added. In the case of our scenario, the Course management Activity needs to be declared together with the Artifacts it has to handle, i.e. courses and lessons. John is responsible for this Task, the next sections describe the Artifact types and Activities he creates.

7.5.1 Artifacts Definition

Any course provided by the Project is described using two different Artifacts types: Courses and Lessons. A Course is an envelope gathering Lessons around a set of Topics. Table 7.1 details the Attributes of the Course Artifact. Each Course has a name, a short name, a description, a list of Topics it is related to and a URL where additional information can be found. For instance, a Course can be named

"‘Object Oriented Programing"’, its short name can be "‘ProgObj"’, its description can be "‘Introduction to object oriented programming, and object oriented architectures and methodologies"’, the Topics may include "‘Java"’, "‘programing"’, "‘modeling"’, etc.

Attribute Name Attribute Type Description

Title Text Title of the Course

ShortName Text Short name of the Course Description Text Description of the Course

Topics PTopic Topics of the Course

URL URL URL of the Course

Table 7.1: Course Artifact Attributes

Each course is made of multiple Lessons. The Lesson Artifact represents a single lesson given in the scope of a Course. Table7.2details the Attributes of the Lesson Artifact. Each Lesson has a title, a description providing information about it. It focuses on a set of Topics. The Lesson also holds information about its authors and the URL where the materials related to the Lesson can be found on the Web.

Attribute Name Attribute Type Description

Title Text Title of the Lesson

Description Text Description of the Lesson

Topics PTopic Topics of the Lesson

Authors PActor Authors of the Lesson

URL URL URL where the Lesson’s materials can be found

Table 7.2: Lesson Artifact Attributes