UC AWOB CM 03 SPEC Manage Consortium Project

MPDL,GAVO

=R0.9=

CM_03_6_Link an existing unlinked project to a consortium or a group.

 * R0.9

Precondition

 * 1) A selected project is not linked to any consortium or group.
 * 2) Current user is Project Lead of the selected project

Actor

 * 1) Consortium(or group) lead of the selected consortium/group or
 * 2) consortium(or group) manager of the selected consortium/group or
 * 3) consortium(or group) project manager of the selected consortium/group.

Steps

 * 1) Actor navigates to a consortium/group project list to which (s)he wishes to link a project.
 * 2) From the list, select an option to link a project to the selected consortium/group.
 * 3) Actor is given a list of projects that
 * 4) (s)he is the Project lead
 * 5) standalone project(not linked to any consortium or group)
 * 6) Actor selects a project which (s)he wishes to link from the list.
 * 7) Actor is asked for confirmation.

Post conditions
If actor confirms to continue the action
 * 1) The system makes the selected project a consortium/group project.
 * 2) The project appears on the selected consortium/group project list.
 * 3) The acceptance status of the project is by default 'pending'.
 * 4) Notify (similar rule as creating a project)
 * 5) For linking a project to a consortium
 * 6)  Consortium lead only if (s)he is not the project lead
 * 7) By AWOB messaging, and email
 * 8) For linking a project to a group
 * 9) Group manager only if (s)he is not the project lead
 * 10)  By AWOB messaging, and email
 * 11) Log the change in Process
 * 12) For linking a project to a consortium log in consortium Process
 * 13) For linking a project to a group log in group Process
 * 14) Update the project list on actor's personal workspace to reflect the change.

=R0.8=

Usage Scenarios

 * 1) A working group discusses projects and decides who leads which project.
 * 2) Once a project is agreed on the WG chair or the PI of the project announces it to consortium.
 * 3) Depending on consortium policy one of the followings may occur
 * 4) A steering committee explicitly approves the project
 * 5) The project is in progress as long as no complaint from consortium members.
 * 6) There is a conflict with other projects and the steering committee resolves the conflict.
 * 7) If approved explicitly or no conflict a project is in progress.

Project Statuses in consortium.
A project can have more than one status since members of a consortium or a WG are interested in different project

information. Therefore, a status is defined for each context or scope.

Statuses in different contexts.

It is to share information with all members of a given WG that a project proposed, accepted/approved, or rejected/disapproved. For example, a proposed project is discussed in the WG before announcing it to consortium, and the WG members can request to join the project.
 * 1) Project’s own status:
 * 2) Provide information to whether the project’s status to the project members, WG or consortium members if relevant.
 * 3)  differs from AWOB project status ‘open’ and ‘closed’
 * 4)  A piece of information. No workflow is defined
 * 5) Enumeration
 * 6) Not started
 * 7) In progress
 * 8) Completed
 * 9) Even if a project status is either completed, or cancelled, the project is still editable not like in task.
 * 10) Cancelled
 * 11) Status in WG context: ‘WG project status’
 * 1) Pending
 * 2) Accepted
 * 3) Rejected
 * 4) Withdrawn


 * 1) Status in Consortium context: ‘consortium project status’
 * 2) Pending
 * 3) Accepted/Approved
 * 4) Rejected/Disapproved
 * 5) Withdrawn

WG Project vs project in conceptual model.
A WG can have 0…N number of WG projects. A WG project is a composite association b/w a WG and its project. It has a

pointer to a project, and has an attribute ‘status’ (henceforth called ‘WG project status’ to distinguish).

Consortium Project vs project in conceptual model.
Similar to a WG project, a consortium project is a composite association b/w a consortium and a project. As in WG project it has a pointer to a project and an attribute ‘status’ (henceforth called ‘Consortium project status’ to distinguish). There are two scenarios to create a consortium project in a consortium:
 * 1) Create a project in a WG, and announce it to consortium. In conceptual model terms, it means that for each project there are two associations, one with a WG project, the other, with  a Consortium project:  In this scenario, a project may have three different statuses:
 * 2)  Project’s own status
 * 3) Status in WG context: WG project status
 * 4) Status in Consortium context: consortium project status
 * 5) Create a project directly in consortium level even if there are WGs in consortium. (See UC CM_03_1_Create_Project_In_Consortium) In this scenario, a project may have two different statuses:
 * 6)  Project’s own status
 * 7) Status in Consortium context: consortium project status

Actors

 * 1) consortium lead
 * 2) consortium manager
 * 3) Consortium Project Manager

Preconditions

 * 1) The system status of consortium is open.

Steps

 * 1) From page showing Consortium project list actor chooses an option to add a Consortium project (or create project).
 * 2) Actor is sent to standard "create project page".UC_AWOB_PM_01SPEC_Create_Project

Post conditions
For valid request:


 * 1) The system creates a project in Consortium(similar to Create project use case).
 * 2) It shows up on consortium project list immediately.
 * 3) Default consortium project status = ‘proposed’
 * 4) For setting consortium project status see CM_03_4_Change_Consortium_Project_Status
 * 5) It appears on the project list in the actor’s personal workspace.
 * 6) It appears on what's new of the affected consortium with category like ‘consortium projects’.
 * 7) Notify
 * 8) Whom: the consortium lead of the affected consortium only if he/she didn’t create the new project
 * 9) By
 * 10) Email: sender=the user who creates the project
 * 11) AWOB notification
 * 12) Depending on actor’s choice  the system  brings up
 * 13) ‘overview’ of new project if actor chose to go to ‘overview’ of the new project, or
 * 14) Consortium project list if actor chose to consortium project list.

Actors
Any consortium members can view consortium project list.


 * 1) consortium lead
 * 2) consortium manager
 * 3) Consortium Project Manager
 * 4) Consortium Member

Steps

 * 1) Actors browse consortium project list.
 * 2) See the sketch of the GUI listed on Release 0.8 scope page.

Post conditions

 * 1) See the table:http://colab.mpdl.mpg.de/mediawiki/AWOB_Task_037

CM_03_3_Edit_Project_Metadata_in_Consortium
Until R0.7 both project/consortium lead and manager were able to edit project/consortium/WG metadata. However, the use case is changed so that only Project Lead can change project metadata and the way to keep log of its metadata changes.

Actors

 * 1) Project Lead

Preconditions

 * 1) The selected project’s AWOB system status is ‘open’.
 * 2) The selected consortium’s AWOB system status is ‘open’.

Steps

 * 1) Actor can change the following metadata:
 * 2) Title
 * 3) Goal
 * 4) Status(project)
 * 5) Submit.

Post conditions
The system does the followings:
 * 1) Save the change.
 * 2) Display the change in what’s new of the selected project. (in a category like project info)
 * 3) Synchronize Consortium project list according to the change.

CM_03_4_Change_Consortium_Project_Status

 * 1) mandatory only if project is announced or created in consortium level
 * 2) Enumeration(wording)
 * 3) Pending(default): actor awaits working group's acceptance
 * 4) Accepted
 * 5) Rejected
 * 6) Withdrawn

This use case applies for a project created in consortium level. For changing consortium project status of a project created in WG level, see UC_AWOB_CM_08_SPEC_Manage_Working_Group_Projects

Actors
In the consortium where a selected project is defined
 * 1) consortium lead
 * 2) consortium manager
 * 3) Project Lead who is also a  consortium project manager
 * 4) The additional condition for a Project Lead being at least a consortium project manager is to provide preventive measures against abusing the system. A consortium lead or manager can demote him/her to consortium member if there is a proof that he/she misbehaves in the consortium

Preconditions

 * 1) The selected project’s AWOB system status is ‘open’.
 * 2) The selected consortium’s AWOB system status is ‘open’.

Steps

 * 1) From consortium project list, actor changes ‘consortium project status’ of a project:

Post conditions

 * 1) The system saves the change.
 * 2) The change shows up in what’s new of the consortium where the project belongs to. (in a category like consortium projects)
 * 3) Synchronize consortium project list according to the change.
 * 4) Notify
 * 5) Whom: any of the following roles who didn’t do the action
 * 6)  consortium lead
 * 7)  Project Lead
 * 8) By
 * 9)  AWOB notification
 * 10)  email


 * 1) If the status is ‘completed/cancelled’
 * 2) Is the project still editable? Yes as long as  the awob system status of the project is open.

CM_03_5_Chanage_Project_Overview
This use case is the same as changing ‘overview’ a stand-alone project which is already implemented.

Actors

 * 1) Project Lead
 * 2) Project manager