1 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 OASIS OSLC PROMCODE TC Domain Model.

1 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 OASIS OSLC PROMCODE TC Domain Model Revisited and Use Cases Development Plan of Specifications (Memorandum) Specification Development and Review Team Mikio Aoyama, Kazuhiro Funakoshi, Yoshio Horiuchi, Tsutomu Kamimura, Shigeaki Matsumoto, Arthur Ryman, Masaki Wakao, Kazuo Yabuta, Hiroyuki Yoshida, 2014/07/21, 08/05, 08/19, 9/02, 9/16, 9/19, 10/01,11/11, 11/25, 12/10, 12/24, 2015/01/07, 01/21, 02/04,02/18(2/20), 03/04, 04/08, 04/22, 05/13 Specification Development and Review Team Mikio Aoyama, Kazuhiro Funakoshi, Yoshio Horiuchi, Tsutomu Kamimura, Shigeaki Matsumoto, Arthur Ryman, Masaki Wakao, Kazuo Yabuta, Hiroyuki Yoshida, 2014/07/21, 08/05, 08/19, 9/02, 9/16, 9/19, 10/01,11/11, 11/25, 12/10, 12/24, 2015/01/07, 01/21, 02/04,02/18(2/20), 03/04, 04/08, 04/22, 05/13

2 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Contents  Upcoming TC Meeting Schedule Proposed  Domain Model Revised  Use Cases and Scenarios  Resources Associated with the Scenarios  Basic Vocabulary  TOC of the Draft Specifications  Time Line Revised  References  Related Links:  PROMCODE TC Wiki: https://wiki.oasis-open.org/oslc-promcode/  OSLC Core TC Wiki: https://wiki.oasis-open.org/oslc-core/FrontPage  Upcoming TC Meeting Schedule Proposed  Domain Model Revised  Use Cases and Scenarios  Resources Associated with the Scenarios  Basic Vocabulary  TOC of the Draft Specifications  Time Line Revised  References  Related Links:  PROMCODE TC Wiki: https://wiki.oasis-open.org/oslc-promcode/  OSLC Core TC Wiki: https://wiki.oasis-open.org/oslc-core/FrontPage

3 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Upcoming TC Meeting Schedule Proposed ScheduleDate/Time [EST]Date/Time [JST]Note 25TC Meeting8:00 p.m., May. 129:00 a.m., May 13 26TC Meeting8:00 p.m., May. 269:00 a.m., May 27 27TC Meeting8:00 p.m., Jun. 99:00 a.m., Jun. 10 28TC Meeting8:00 p.m., Jun. 239:00 a.m., Jun. 24 Note: Start of US DST: March 8, 2015 (Sun)

5 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Action Items Raised TC24(Apr. 22)  Introduction  Add explanation of project context, i.e. the scope of PROMCODE  Terminology  Architecture (Tentative) [New]  Explain the holistic view of solution architecture  Domain Model  Add introduction to the meaning of the model  The model is about data collected by aquirer (?)  Through review:  Multiplicity of 0 from ManagedItemCollection to Project  Service Specification  Add REST API  Ref: IBM Rational Focal Point Linked Data and RDF REST API, https://jazz.net/wiki/bin/view/LinkedData/FPLinkedData  Resource Definitions  Introduction  Add explanation of project context, i.e. the scope of PROMCODE  Terminology  Architecture (Tentative) [New]  Explain the holistic view of solution architecture  Domain Model  Add introduction to the meaning of the model  The model is about data collected by aquirer (?)  Through review:  Multiplicity of 0 from ManagedItemCollection to Project  Service Specification  Add REST API  Ref: IBM Rational Focal Point Linked Data and RDF REST API, https://jazz.net/wiki/bin/view/LinkedData/FPLinkedData  Resource Definitions

6 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 TOC (Rev. 4/22, 5/13)  1. Introduction [Aoyama]  2. Architecture [Aoyama]  3. Domain Model [Yoshida, Aoyama]  4. Service Specification [Wakao, Horiuchi, Ryman]  5. Resource Definitions [Matsumoto, Funakoshi, Ryman]  Vocabulary, Resource Shape  6. Use Case [Matusmoto, Aoyama, Yabuta]  7. Sample Implementation of Use Case [Wakao, Horiuchi, Kamimura]  8. References [Aoyama]  1. Introduction [Aoyama]  2. Architecture [Aoyama]  3. Domain Model [Yoshida, Aoyama]  4. Service Specification [Wakao, Horiuchi, Ryman]  5. Resource Definitions [Matsumoto, Funakoshi, Ryman]  Vocabulary, Resource Shape  6. Use Case [Matusmoto, Aoyama, Yabuta]  7. Sample Implementation of Use Case [Wakao, Horiuchi, Kamimura]  8. References [Aoyama] References Core Wiki: https://wiki.oasis-open.org/oslc-core/

7 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Time Line Revised MilestoneRevised (Mar. 3) Revised (4/22) TC LaunchedMar. 25, 2014 Start Writing Working DraftMar. 05, 2015 Working DraftApr. 10, 2015May 10 TC Review30 days Update Draft for Comments14 days Committee DraftMay 24, 2015Jun. 24 Review of Member Section & Core14 days (2 Weeks) Committee Draft (Due)Jun. 7Jul. 8 Committee Draft Public Review60 days Aug. 7Sep. 8 Update Spec for Comments => Candidate of OASIS Standard 14 days Committee Specification and SoU DueAug. 21, 2015Sep. 22 Vote14 days+7 days OASIS StandardSep. 4, 2015Oct. 4

13 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 State of Issues  Basic set of states (Yabuta-san)  Closed  In-progress  Raised  Reference: OSLC CM 3.0  Basic set of states (Yabuta-san)  Closed  In-progress  Raised  Reference: OSLC CM 3.0 oslc_cm:Closed Completely done, no further fixes or fix verification is needed. oslc_cm:In-progressActive work is occurring. oslc_cm:Fixed oslc_cm:Approved oslc_cm:Reviewed oslc_cm:VerifiedThe resolution or the fix is verified.

16 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Rationale of Proposed Revision to Domain Model [Nov. 11/Nov. 25 ]  Changes arising from Use Cases  Relationship between Plan and Report should be explicitly specified -> Add association: correspondsTo [reportsOn]  Structure of Issue and its Collection  Add IssueCollection similar to ManagedItemCollection  Relate IssueCollection to Project similar to ManagedItemCollection: belongsTo  Add an attribute, RaisedDate, to Issue  Changes arising from Use Cases  Relationship between Plan and Report should be explicitly specified -> Add association: correspondsTo [reportsOn]  Structure of Issue and its Collection  Add IssueCollection similar to ManagedItemCollection  Relate IssueCollection to Project similar to ManagedItemCollection: belongsTo  Add an attribute, RaisedDate, to Issue

17 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Rationale of Proposed Revision to Domain Model [Nov. 11/Nov. 25 ]: State of Issues  State of Issue: Open to users due to its variety in each project (OSLC CM, PMBOK)  Add a property “State” defined by URI like UnitType  Example: OSLC CM 3.0( http://open-services.net/wiki/change- management/Specification-3.0/ )  Resource State  Name: State, Type URI http://open-services.net/ns/cm#State  State of Issue: Open to users due to its variety in each project (OSLC CM, PMBOK)  Add a property “State” defined by URI like UnitType  Example: OSLC CM 3.0( http://open-services.net/wiki/change- management/Specification-3.0/ )  Resource State  Name: State, Type URI http://open-services.net/ns/cm#State RangeDescription oslc_cm:ClosedCompletely done, no further fixes or fix verification is needed. oslc_cm:In-progressActive work is occurring. oslc_cm:Fixed oslc_cm:Approved oslc_cm:Reviewed oslc_cm:Verified The resolution or the fix is verified.

18 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Proposed Revision to Domain Model v. 2.26 <-correspondsTo <-belongsTo collects +raisedDate: DateTime IssueCollection State

21 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Issues and Proposed Changes to Domain Model Discussed at the TC on 9/17  Update of domain model  Change name:  MeasurementCriteria -> Target  Consistent definition of attributes:  Project -> Add properties (identifier, title, description, plannedStartDate, actualStartDate, plannedEndDate, actualEndDate)  Issue: Need to discuss whether state should be added  Multiplicity: Refer “Properties of Attributes in UML Class Diagrams”  Default value is 1, eliminate * after TypeName  “O..1” represents possibility of null  + AttributeName : TypeName [*]  Metrics and MeasureType:  Clarify the rationale of using “Measure”  Scenarios  Refine the scenarios by adding concrete resources, and show the usage of domain model  Validating the domain model  Update of domain model  Change name:  MeasurementCriteria -> Target  Consistent definition of attributes:  Project -> Add properties (identifier, title, description, plannedStartDate, actualStartDate, plannedEndDate, actualEndDate)  Issue: Need to discuss whether state should be added  Multiplicity: Refer “Properties of Attributes in UML Class Diagrams”  Default value is 1, eliminate * after TypeName  “O..1” represents possibility of null  + AttributeName : TypeName [*]  Metrics and MeasureType:  Clarify the rationale of using “Measure”  Scenarios  Refine the scenarios by adding concrete resources, and show the usage of domain model  Validating the domain model

22 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Reference Properties of Attributes in UML Class Diagrams  Multiplicity [Default value is 1]  1 - this attribute has a single value of the specified Type.  0..1 - this attribute can have a value of null.  * - this attribute's value is a collection of values.  1..* - this attribute's value is a collection that contains at least one value.  n.. m - this attribute's value is a collection that contains between n and m values.  Multiplicity [Default value is 1]  1 - this attribute has a single value of the specified Type.  0..1 - this attribute can have a value of null.  * - this attribute's value is a collection of values.  1..* - this attribute's value is a collection that contains at least one value.  n.. m - this attribute's value is a collection that contains between n and m values. Reference: Properties of Attributes in UML Class Diagrams, http://msdn.microsoft.com/en-us/library/dd323861.aspx

23 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 On Use of Measure and Metrics SWEBOK  Guide to the Software Engineering Body Of Knowledge (SWEBOK), Version 3, 2014  Chapter 8, Software Engineering Management  6. Software Engineering Measurement  Key terms on software measures and measurement methods have been defined in [ISO15939-02] on the basis of the ISO international vocabulary of metrology [ISO93]. Nevertheless, readers will encounter terminology differences in the literature; for example, the term "metrics" is sometimes used in place of "measures.“  6.2. Plan the Measurement Process  Select measures. Candidate measures must be selected, with clear links to the information needs. Measures must then be selected based on the priorities of the information needs and other criteria such as cost of collection, degree of process disruption during collection, ease of analysis, ease of obtaining accurate, consistent data, and so on [ISO15939-02: 5.2.3 and Appendix C].  Guide to the Software Engineering Body Of Knowledge (SWEBOK), Version 3, 2014  Chapter 8, Software Engineering Management  6. Software Engineering Measurement  Key terms on software measures and measurement methods have been defined in [ISO15939-02] on the basis of the ISO international vocabulary of metrology [ISO93]. Nevertheless, readers will encounter terminology differences in the literature; for example, the term "metrics" is sometimes used in place of "measures.“  6.2. Plan the Measurement Process  Select measures. Candidate measures must be selected, with clear links to the information needs. Measures must then be selected based on the priorities of the information needs and other criteria such as cost of collection, degree of process disruption during collection, ease of analysis, ease of obtaining accurate, consistent data, and so on [ISO15939-02: 5.2.3 and Appendix C]. Reference: http://www.computer.org/portal/web/swebok/html/ch8#Ref6

24 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 On Use of Measure and Metrics ISO 15939:2007 Appendix  A.2.3 Base measure  A measure defined in terms of an attribute and the method for quantifying it. (A measure is a variable to which a value is assigned.) A base measure is functionally independent of other measures. A base measure captures information about a single attribute. Data collection involves assigning values to base measures. Specifying the expected range and/or type of values of a base measure helps to verify the quality of the data collected.  A.2.3.1.2.2 Unit of measurement  A particular quantity, defined and adopted by convention, with which other quantities of the same kind are compared in order to express their magnitude relative to that quantity. Only quantities expressed in the same units of measurement are directly comparable. Examples of units include the hour and the meter.  A.2.3 Base measure  A measure defined in terms of an attribute and the method for quantifying it. (A measure is a variable to which a value is assigned.) A base measure is functionally independent of other measures. A base measure captures information about a single attribute. Data collection involves assigning values to base measures. Specifying the expected range and/or type of values of a base measure helps to verify the quality of the data collected.  A.2.3.1.2.2 Unit of measurement  A particular quantity, defined and adopted by convention, with which other quantities of the same kind are compared in order to express their magnitude relative to that quantity. Only quantities expressed in the same units of measurement are directly comparable. Examples of units include the hour and the meter. Reference: ISO, ISO/IEC 15939:2007: Systems and Software Engineering – Measurement Process, 2007. ISO 9126 Metric ISO 25010 Measure

25 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Domain Model v. 2.4(Revised Sep. 16) FP (sizeOfScopeItem) FP metric “CodeSize” Title: login screen actualSize: 10 KLOC State? Add attributes: identifier title description plannedStartDate actualStartDate plannedEndDate actualEndDate Change mame: MeasurementCriteria -> Target

26 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Domain Model Issues Related to EMS in Domain Model  Commonality and Difference between EMS and PROMCODE  Policy: If PROMCODE use a concept which is defined in EMS, PROMCODE should not define it, but refer it.  Use of “Estimation in PROMCODE”:  Estimation in EMS is out of scope of PROMCODE. The “planned” value in PROMCODE is a value agreed between an acquirer and an supplier after estimation  Measurement/Measure&Mertics/Measurement  Use consistent model  Measure of ScopeItem is not defined  Associate MeasureType and UnitType to Project  Unification of Vocabulary  Use the same vocabulary to those of the same meaning  metric, unitOfMeasure  Commonality and Difference between EMS and PROMCODE  Policy: If PROMCODE use a concept which is defined in EMS, PROMCODE should not define it, but refer it.  Use of “Estimation in PROMCODE”:  Estimation in EMS is out of scope of PROMCODE. The “planned” value in PROMCODE is a value agreed between an acquirer and an supplier after estimation  Measurement/Measure&Mertics/Measurement  Use consistent model  Measure of ScopeItem is not defined  Associate MeasureType and UnitType to Project  Unification of Vocabulary  Use the same vocabulary to those of the same meaning  metric, unitOfMeasure

27 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Domain Model Comparison of EMS and PROMCODE EMSPROMCODE Estimation and Measurement Use Estimation and Measurement i Estimation is out of scope. Planned is a value for agreement between Acquirer and Supplier. Value might be based on estimation, but estimation id not in the included in the activities of project control. Metricmetric metric:Sloc (URI)Measure value:Decimal -> MeasureType [refer to] MeasurementCriteria Unit of MeasureunitOfMeasure unit:Loc (URI) UnitType <-[referred by] Measure unit ->unitOfMeasure Measurement numericValue xsd:double Measurement -> ScopeItemUnit of PlannedSize is undefined ->Associate MeasureType and UnitType to Project (A unique measure across the project)

29 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Domain Model Revisited for v 2.2 on 9/2  Structure around ManagedItem  Attributes of ManagedItem: Add type for classification  Add “ManagedItemCollection” as a collection of ManagedItem, which represents a collection of status, or snapshot, of the project  Attributes: Add identifier and title  Add “Plan” and “Report” as subclasses of ManagedItemCollection:  Plan reflects an order from the acquirer to Supplier when the project is started  Report reflects a report compiled from the snapshot in ManagedItemCollection  Add “Project” as a reference to the project under management  The entity Project is only for reference, and is considered as out of scope of the PROMCODE domain model  Structure around ManagedItem  Attributes of ManagedItem: Add type for classification  Add “ManagedItemCollection” as a collection of ManagedItem, which represents a collection of status, or snapshot, of the project  Attributes: Add identifier and title  Add “Plan” and “Report” as subclasses of ManagedItemCollection:  Plan reflects an order from the acquirer to Supplier when the project is started  Report reflects a report compiled from the snapshot in ManagedItemCollection  Add “Project” as a reference to the project under management  The entity Project is only for reference, and is considered as out of scope of the PROMCODE domain model

31 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Domain Model Revisited (2/2)  Structure Measure/Measurement  Add “MeasurementCriteria” as a criteria of Measure  Add attributes of type and title to Measure  Title: Bug density, Type: NoOfBugsPerKLOC, Unit: 1, Value: 3  Attributes  Structure Measure/Measurement  Add “MeasurementCriteria” as a criteria of Measure  Add attributes of type and title to Measure  Title: Bug density, Type: NoOfBugsPerKLOC, Unit: 1, Value: 3  Attributes Measurement MeasurementCriteriaMeasure Title + ++ Identifier + +NA Type + NA+

33 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Use Cases and Scenarios Usage Context of Software Supply Chain  Project Context  Context: Data Interface between Acquirer and Supplier  Supply chain is formed by chaining the Acquirer and Supplier through the PROMCODE interface  Scope of time: Assume the plan is completed and the project scope is defined, which implies that scope definition including planning is out of scope of PROMCODE  Project Context  Context: Data Interface between Acquirer and Supplier  Supply chain is formed by chaining the Acquirer and Supplier through the PROMCODE interface  Scope of time: Assume the plan is completed and the project scope is defined, which implies that scope definition including planning is out of scope of PROMCODE Organization A Organization Bn Organization Cnm AcquirerSupplier Acquirer * *

34 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Tool S Use Cases and Scenarios Deployment Patterns and High-level Scenario  Deployment Pattern A is appropriate for PROMCODE  PROMCODE Usage Conditions  Assumption  The Acquirer and Suppliers use different PM tools including Excel of different schema.  Use of REST  High-level Scenario  Supplier pushes a report in PROMCODE resources to a PROMCODE Provider deployed in a Web server.  Acquirer collects the reports from the PROMOCDE Provider as a PROMCODE Consumer, and presents the project status on its dashboard.  ()  Deployment Pattern A is appropriate for PROMCODE  PROMCODE Usage Conditions  Assumption  The Acquirer and Suppliers use different PM tools including Excel of different schema.  Use of REST  High-level Scenario  Supplier pushes a report in PROMCODE resources to a PROMCODE Provider deployed in a Web server.  Acquirer collects the reports from the PROMOCDE Provider as a PROMCODE Consumer, and presents the project status on its dashboard.  () P Supplier 1 Tool S1 C (Tool A) Pull (Web Service) Push P: Provider, C: Consumer P/C SupplierAcquirer PC Supplier Push Pull Acquirer Deployment Pattern A Deployment Pattern B Deployment Pattern C Report Dashboard SupplierAcquirer PROMCODE

35 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Use Cases and Scenarios Use Cases (Top Level)  Use vocabulary practically common in project management in contracted delivery ISO 21500:2012  Consistent with global standards: PMBOK, ISO 21500:2012  Use vocabulary practically common in project management in contracted delivery ISO 21500:2012  Consistent with global standards: PMBOK, ISO 21500:2012 Project Initiation and Planning Project Execution Acquirer Supplier Project Closing

36 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Project Execution and Control Use Cases and Scenarios Use Cases: Project Execution  Use vocabulary practically common in project management in contracted delivery ISO 21500:2012  Consistent with global standards: PMBOK, ISO 21500:2012  Use vocabulary practically common in project management in contracted delivery ISO 21500:2012  Consistent with global standards: PMBOK, ISO 21500:2012 Project Start Status Reporting Acquirer Supplier Project Closing Status Aggregation

37 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Project Execution Use Cases and Scenarios Use Cases: Project Execution  Use vocabulary practically common in project management in contracted delivery ISO 21500:2012  Consistent with global standards: PMBOK, ISO 21500:2012  Use vocabulary practically common in project management in contracted delivery ISO 21500:2012  Consistent with global standards: PMBOK, ISO 21500:2012 Schedule Problem Quality Problem Acquirer Supplier Re-schedule/Re-planning

38 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Use Case “Project Start with PROMCODE” [Nov. 25]  Preconditions  Scenario  An acquirer registers “Project ID”, “Project plan”, and “Mapping Rules” to the PROMCODE Consumer.  The acquirer generates a data in the PROMCODE model with the PROMCODE Consumer and stores it to a DB.  A supplier registers the “Project ID”, “Project Plan”, and “Mapping Rules” to the PROMCODE Provider.  Preconditions  Scenario  An acquirer registers “Project ID”, “Project plan”, and “Mapping Rules” to the PROMCODE Consumer.  The acquirer generates a data in the PROMCODE model with the PROMCODE Consumer and stores it to a DB.  A supplier registers the “Project ID”, “Project Plan”, and “Mapping Rules” to the PROMCODE Provider.

39 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Use Case “Project Execution with PROMCODE” [Nov. 25/Dec. 10]  Preconditions  The acquirer and supplier respectively register “Project ID”, “Project plan”, and each “Mapping Rules” to the PROMCODE.  The supplier agreed to push the Report to the PROMCODE Provider on the Web until the specified date and time.  The acquirer and suppliers agreed to the schema of the “Report” to be reported from suppliers to the acquirer.  Scenario  A supplier registers its “Report” data to the PM tool S1.  The supplier converts the “Report” from the PM tool S1 to the PROMCODE resources.  The supplier pushes the “Report” in the PROMCODE schema to the PROMCODE Provider on the Web.  The Acquirer, a PROMCODE Consumer, pulls the collection of “Reports” from the PROMCODE Providers.  The Acquirer converts the collection of the “Reports” in the PROMCODE resources to the PM tool A.  The Acquirer reviews the “Report” on the PM tool A.  Preconditions  The acquirer and supplier respectively register “Project ID”, “Project plan”, and each “Mapping Rules” to the PROMCODE.  The supplier agreed to push the Report to the PROMCODE Provider on the Web until the specified date and time.  The acquirer and suppliers agreed to the schema of the “Report” to be reported from suppliers to the acquirer.  Scenario  A supplier registers its “Report” data to the PM tool S1.  The supplier converts the “Report” from the PM tool S1 to the PROMCODE resources.  The supplier pushes the “Report” in the PROMCODE schema to the PROMCODE Provider on the Web.  The Acquirer, a PROMCODE Consumer, pulls the collection of “Reports” from the PROMCODE Providers.  The Acquirer converts the collection of the “Reports” in the PROMCODE resources to the PM tool A.  The Acquirer reviews the “Report” on the PM tool A.

40 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Use Case “Project Execution with PROMCODE” Review and Actions for Schedule Problems [Dec. 24]  Schedule Delay 1.Reviews the difference and raises a concern if the following is observed. 1.No progress from the previous report 2.Risk of not meeting a schedule emerges with the current pace of progress. May use past data on productivity to project risk. 2.PM-A interacts with PM-S on further update. 1.Reasons for delay 2.Outlook of meeting a schedule. 3.Based on the interaction, PM-A takes one of the following actions. 1.No formal action, but with notice on the situation to monitor. 2.Raise an issue on the situation and create actions 3.Escalate to stakeholders for possible plan change. 4.If it is necessary, plan will be changed [See details in “Plan Change” scenario]

41 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Use Case “Project Execution with PROMCODE” Review and Actions for Schedule Problems [Dec. 24]  Schedule Delay 1.Reviews the difference and raises a concern if the following is observed. 1.No progress from the previous report 2.Risk of not meeting a schedule emerges with the current pace of progress. May use past data on productivity to project risk. 2.PM-A interacts with PM-S on further update. 1.Reasons for delay 2.Outlook of meeting a schedule. 3.Based on the interaction, PM-A takes one of the following actions. 1.No formal action, but with notice on the situation to monitor. 2.Raise an issue on the situation and create actions 3.Escalate to stakeholders for possible plan change. 4.If it is necessary, plan will be changed [See details in “Plan Change” scenario]

42 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Use Case “Project Execution with PROMCODE” Review and Actions for Quality Problems [Dec. 10]  Quality Concern 1.PM-A compares previous report and current report and highlights the difference. 2.Reviews the difference and raises a concern if the progress is not sufficient and there is a risk of not meeting quality goal. 3.PM-A interacts with PM-S on further update. 1.Reasons of the current problem 2.Outlook of meeting a goal 3.Assess the impact to the overall project. 4.Based on the interaction, PM-A takes one of the following actions. 1.Raise an issue on the situation and create actions 2.Escalate to stakeholders for possible plan change. 5.If it is necessary, actions will be taken place [see details in “Plan Change” scenario]

43 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Use Case “Project Execution with PROMCODE” Review and Actions for Quality Problems [Dec. 10]  Quality Concern 1.PM-A compares previous report and current report and highlights the difference. 2.Reviews the difference and raises a concern if the progress is not sufficient and there is a risk of not meeting quality goal. 3.PM-A interacts with PM-S on further update. 1.Reasons of the current problem 2.Outlook of meeting a goal 3.Assess the impact to the overall project. 4.Based on the interaction, PM-A takes one of the following actions. 1.Raise an issue on the situation and create actions 2.Escalate to stakeholders for possible plan change. 5.If it is necessary, actions will be taken place [see details in “Plan Change” scenario]

44 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Use Case “Project Execution with PROMCODE” Plan Change[Dec. 10]  About Plan Change: “Plan change” may change  ScopeItem including “PlannedSize”, and entities in the ScopeItem  WorkItem including PlannedEndDate, and  Artifact  Scenario of Plan Change [Change of ScopeItem]  The Acquirer determines to change the ScopeItem  The Acquirer notifies the changes of ScopeItem and associated new plan to appropriate Suppliers.  The Supplier reviews the new ScopeItem and associated new plan, and notify its agreement to the Acquirer.  The Acquirer and Supplier get agreed.  The Acquirer set the new plan to the “plan”.  The Acquirer and Supplier review the ScopeItem revised, and associated WorkItem if necessary  About Plan Change: “Plan change” may change  ScopeItem including “PlannedSize”, and entities in the ScopeItem  WorkItem including PlannedEndDate, and  Artifact  Scenario of Plan Change [Change of ScopeItem]  The Acquirer determines to change the ScopeItem  The Acquirer notifies the changes of ScopeItem and associated new plan to appropriate Suppliers.  The Supplier reviews the new ScopeItem and associated new plan, and notify its agreement to the Acquirer.  The Acquirer and Supplier get agreed.  The Acquirer set the new plan to the “plan”.  The Acquirer and Supplier review the ScopeItem revised, and associated WorkItem if necessary

45 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Use Case “Publishing Issue(s) with PROMCODE” [Nov. 25]  Precondition  Acquirer creates an instance of “IssueCollection”.  Scenario  A Supplier registers an “Issue(s)” to the PROMCODE Provider.  The PROMCODE provider notifies the registration of the “Issue(s)” to the Acquirer.  The Acquirer, a PROMCODE Consumer, pulls the published “Issue(s)” from the PROMCODE Provider.  The Acquirer reviews the “Issues”.  Precondition  Acquirer creates an instance of “IssueCollection”.  Scenario  A Supplier registers an “Issue(s)” to the PROMCODE Provider.  The PROMCODE provider notifies the registration of the “Issue(s)” to the Acquirer.  The Acquirer, a PROMCODE Consumer, pulls the published “Issue(s)” from the PROMCODE Provider.  The Acquirer reviews the “Issues”.

46 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Use Case “Project Start” Revised [Nov. 11]  Preconditions  Project Plan is determined and agreed by both acquirer and supplier.  The size measure and its unit of Scope are respectively defined by “MesureType” and “UnitType”, which are specified by the URIs.  The measure and its unit of the Artifact are respectively defined by “MesureType” and “UnitType”, which are specified by the URIs.  Scenario  Acquirer creates a Project resource, and sets the measure and its unit of project scope to typeOfMeasure and unitOfMeasure of Project.  Acquirer creates a ScopeItem.  Supplier creates an Artifact and its subclasses to meet the ScopeItem, and allocates the Artifacts to the ScopeItem.  Supplier creates a set of WorkItem to produce the Artifacts, and allocates the WorkItems to the Artifacts.  Supplier appoints a Person as a representative to the ScopeItem.  Preconditions  Project Plan is determined and agreed by both acquirer and supplier.  The size measure and its unit of Scope are respectively defined by “MesureType” and “UnitType”, which are specified by the URIs.  The measure and its unit of the Artifact are respectively defined by “MesureType” and “UnitType”, which are specified by the URIs.  Scenario  Acquirer creates a Project resource, and sets the measure and its unit of project scope to typeOfMeasure and unitOfMeasure of Project.  Acquirer creates a ScopeItem.  Supplier creates an Artifact and its subclasses to meet the ScopeItem, and allocates the Artifacts to the ScopeItem.  Supplier creates a set of WorkItem to produce the Artifacts, and allocates the WorkItems to the Artifacts.  Supplier appoints a Person as a representative to the ScopeItem. Obsolete

47 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Use Case “Project Execution with PROMCODE” Simple Use Case  User roles  Project manager of acquirer (PM-A)  Project manger of supplier (PM-S)  Pre-condition  A legal contract to bind an acquirer and a supplier is handled separately.  There is no cascading of acquirer-supplier relationships.  Project environment of an acquirer and a supplier are not shared; i.e., project environment of a supplier is not accessible to PM-A and therefore, project information needs to be sent to PM-A for project management by an acquirer.  Steps 1.PM-A and PM-S work together to define ScopeItems, WorkItems and artifacts as a plan and establish agreement between them. Details of steps in establishing agreement may vary and we will not specify them further.. 2.PM-S updates on regular basis actual values of properties of WorkItems and of measurements and measures attached to artifacts. This can be done by PM-A requesting a report to PM-S or by PM-S posting a report to an agreed location. 3.PM-S sends an update as a Report to PM-A. 4.PM-A reviews updates and takes actions such as such as creating and managing Issues. In particular, 1.Review the possibility of schedule delay 2.Review Quality Details of these will be elaborated in the next pages. 5.Repeat Steps 2-4 as necessary 6.Conduct acceptance review and close a project  User roles  Project manager of acquirer (PM-A)  Project manger of supplier (PM-S)  Pre-condition  A legal contract to bind an acquirer and a supplier is handled separately.  There is no cascading of acquirer-supplier relationships.  Project environment of an acquirer and a supplier are not shared; i.e., project environment of a supplier is not accessible to PM-A and therefore, project information needs to be sent to PM-A for project management by an acquirer.  Steps 1.PM-A and PM-S work together to define ScopeItems, WorkItems and artifacts as a plan and establish agreement between them. Details of steps in establishing agreement may vary and we will not specify them further.. 2.PM-S updates on regular basis actual values of properties of WorkItems and of measurements and measures attached to artifacts. This can be done by PM-A requesting a report to PM-S or by PM-S posting a report to an agreed location. 3.PM-S sends an update as a Report to PM-A. 4.PM-A reviews updates and takes actions such as such as creating and managing Issues. In particular, 1.Review the possibility of schedule delay 2.Review Quality Details of these will be elaborated in the next pages. 5.Repeat Steps 2-4 as necessary 6.Conduct acceptance review and close a project Obsolete

49 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Resources Created before “Start Project”(1/3)[Nov. 11] ResourceAttributesCreatorValue ProjectIdentifierAcquirer TitleAcquirer DescriptionAcquirer plannedStartDateAcquirer plannedEndDateAcquirer metricOfScopeItemSizeAcquirerURI unitOfScopeItemSizeAcquirerURI ResourceAttributesCreatorValue PlanIdentifierAcquirer TitleAcquirer DateAcquirer belongsToAcquirer collectsAcquirer

50 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Resources Created before “Start Project”(2/3)[Nov. 11] ResourceAttributesCreatorValue ScopeItemIdentifierAcquirer TitleAcquirer DescriptionAcquirer plannedSizeAcquirer isPartOfAcquirer ResourceAttributesCreatorValue WorkItemIdentifierAcquirer TitleAcquirer DescriptionAcquirer plannedStartDateAcquirer plannedEndDateAcquirer isPartOfAcquirer requiredByAcquirer representedBySupplier

51 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Resources Created before “Start Project”(3/3)[Nov. 11] ResourceAttributesCreatorValue ArtifactIdentifierAcquirer TitleAcquirer DescriptionAcquirer isPartOfAcquirer producedByAcquirer ResourceAttributesCreatorValue TargetIdentifierAcquirer TitleAcquirer determinesAcquirer designedForAcquirer ResourceAttributesCreatorValue MeasureIdentifierAcquirer TitleAcquirer ValueAcquirer typeOfMeasureAcquirer unitOfMeasureAcquirer

52 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Resources Created/Changed in “Status Reporting”(1/2)[Nov. 11] ResourceAttributesCreatorValue ReportIdentifierAcquirer TitleSupplier DateSupplier correspondsToSupplier belongsToSupplier collectsSupplier ResourceAttributesCreatorValue WorkItemactualStartDateSupplier actualEndDateSupplier ResourceAttributesCreatorValue MeasurementDateSupplier ResourceAttributesCreatorValue MeasureValueSupplier

53 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Resources Created/Changed in “Status Reporting”(2/2)[Nov. 11] ResourceAttributesCreatorValue IssueCollectionIdentifierAcquirer TitleSupplier DateSupplier collectsSupplier ResourceAttributesCreatorValue IssueIdentifierAcquirer/ Supplier TitleAcquirer/ Supplier raisedDateAcquirer/ Supplier DescriptionAcquirer/ Supplier

54 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Resources Created/Changed in “Project Closing”[Nov. 11] ResourceAttributesCreatorValue ProjectactualEndDateSupplier ResourceAttributesCreatorValue ScopeItemactualSizeSupplier

56 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Vocabulary [2014/12/23]  acquirer: stakeholder that acquires or procures a product or service from a supplier [ISO/IEC 15288:2002]  measure (noun): variable to which a value is assigned as the result of measurement. [ISO/IEC 15939: 2007]  NOTE: The plural form “measures” is used to refer collectively to base measures, derived measures and indicators.  measure (verb): make a measurement. [ISO/IEC 14598-1:1999]  measurement: set of operations having the object of determining a value of a measure. [ISO/IEC 15939: 2007]  NOTE Adapted from the International Vocabulary of Basic and General Terms in Metrology, 1993.  project: a temporary endeavor undertaken to create a unique product, service, or result. [PMBOK V5]  quality measure: measure that is defined as a measurement function of two or more values of quality measure elements [ISO/IEC 25010: 2011]  scope: The sum of the products, services and results to be provided as a project. See also “project scope” and “product scope”.[PMBOK V5, 2013]  supplier: organization or individual that enters into an agreement with the acquirer for the supply of a product or service. [ISO/IEC 15939: 2007]  NOTE 1: Other terms commonly used for supplier are contractor, producer, seller and vendor.  NOTE 2: The acquirer and the supplier may be part of the same organization.  acquirer: stakeholder that acquires or procures a product or service from a supplier [ISO/IEC 15288:2002]  measure (noun): variable to which a value is assigned as the result of measurement. [ISO/IEC 15939: 2007]  NOTE: The plural form “measures” is used to refer collectively to base measures, derived measures and indicators.  measure (verb): make a measurement. [ISO/IEC 14598-1:1999]  measurement: set of operations having the object of determining a value of a measure. [ISO/IEC 15939: 2007]  NOTE Adapted from the International Vocabulary of Basic and General Terms in Metrology, 1993.  project: a temporary endeavor undertaken to create a unique product, service, or result. [PMBOK V5]  quality measure: measure that is defined as a measurement function of two or more values of quality measure elements [ISO/IEC 25010: 2011]  scope: The sum of the products, services and results to be provided as a project. See also “project scope” and “product scope”.[PMBOK V5, 2013]  supplier: organization or individual that enters into an agreement with the acquirer for the supply of a product or service. [ISO/IEC 15939: 2007]  NOTE 1: Other terms commonly used for supplier are contractor, producer, seller and vendor.  NOTE 2: The acquirer and the supplier may be part of the same organization.

57 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 Vocabulary References [2014/12/23] [ 1] P. Bourque and R.E. Fairley (eds.), Guide to the Software Engineering Body of Knowledge, Version 3.0, IEEE Computer Society, 2014, http://www.swebok.org. [ 2] ISO/IEC 14598-1:1999, Information technology - Software product evaluation - Part 1: General overview. [ 3] ISO/IEC 15288:2002, Systems engineering - System life cycle processes. [ 4] ISO/IEC 15939:2007, Systems and software engineering - Measurement process. [ 5] ISO/IEC 25010:2011, Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models. [ 6] ISO, International Vocabulary of Basic and General Terms in Metrology, 1993. [ 7] PMI, A Guide to Project Management of Body Of Knowledge (PMBOK Guide), Fifth Edition, 2013.

58 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 References [ 1] R. Cyganiak, et al. (eds.), RDF 1.1 Concepts and Abstract Syntax, W3C Recommendation, 25 February 2014, http://www.w3.org/TR/2014/REC-rdf11-concepts- 20140225/#dfn-iri [ 2] R. Cyganiak, An RDF Design Pattern: Inverse Property Labels, Jun. 2006, http://richard.cyganiak.de/blog/2006/06/an-rdf-design-pattern-inverse-property-labels/. [ 3] A. G. Ryman, et al., OSLC Resource Shape: A Language for Defining Constraints on Linked Data, Proc. of the WWW2013 Workshop on Linked Data on the Web (LDOW 2013), May 2013, 5 pages, http://events.linkeddata.org/ldow2013/papers/ldow2013-paper-02.pdf. [ 4] A. G. Ryman, Vocabulary Annotation Vocabulary, Sep. 2013, http://open-services.net/wiki/core/Vocabulary-Annotation-Vocabulary/. [ 5] A. G. Ryman, Resource Shape 2.0, W3C Member Submission, Feb. 2014, http://www.w3.org/Submission/2014/SUBM-shapes-20140211/. [ 6] Open Services for Lifecycle Collaboration Change Management Specification, Version 3.0, http://open-services.net/wiki/change-management/Specification-3.0/

1 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 OASIS OSLC PROMCODE TC Domain Model.

Similar presentations

Presentation on theme: "1 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 OASIS OSLC PROMCODE TC Domain Model."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

1 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 OASIS OSLC PROMCODE TC Domain Model.

Similar presentations

Presentation on theme: "1 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014-2015 OASIS OSLC PROMCODE TC Domain Model."— Presentation transcript:

Similar presentations

About project

Feedback