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

1 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 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, 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 Specification Development and Review Team Mikio Aoyama, Kazuhiro Funakoshi, Yoshio Horiuchi, Tsutomu Kamimura, Shigeaki Matsumoto, Arthur Ryman, 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

2 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 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  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

3 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 Upcoming TC Meeting Schedule Proposed ScheduleDate/Time [EST]Date/Time [JST]Note 17TC Meeting7.00 p.m., Dec. 239:00 a.m., Dec. 24 18TC Meeting7.00 p.m., Jan. 69:00 a.m., Jan. 7 19TC Meeting7.00 p.m., Jan. 209:00 a.m., Jan. 21 20TC Meeting7.00 p.m., Feb. 39:00 a.m., Feb. 4 21TC Meeting7.00 p.m., Feb. 179:00 a.m., Feb. 18 Note: Start of US DST: March 8, 2015 (Sun)

7 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 Rationale of Proposed Revision to Domain Model [Nov. 11]  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  State of Issue: Open to users due to its variety in each project (OSLC CM, PMBOK)  Add a property “State” defined by URI like UnitTupe  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  State of Issue: Open to users due to its variety in each project (OSLC CM, PMBOK)  Add a property “State” defined by URI like UnitTupe

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

11 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 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

12 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 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

13 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 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

14 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 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

15 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 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

16 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 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

17 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 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)

19 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 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

21 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 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+

23 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 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 * *

24 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 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

25 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 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

26 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 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

27 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 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

28 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 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.

29 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 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.

30 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 Use Case “Project Execution with PROMCODE” Review and Actions for Schedule Problems [Dec. 10]  Schedule Delay 1.PM-A compares previous report and current report and highlights the difference. 2.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. 3.PM-A interacts with PM-S on further update. 1.Reasons for delay 2.Outlook of meeting a schedule. 4.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. 5.If it is necessary, plan will be changed [See details in “Plan Change” scenario]

31 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 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]

32 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 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

33 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 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”.

34 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 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

35 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 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

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

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

39 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 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

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

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

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

44 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 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.

45 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 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.

47 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 TOC of Draft Specification (1/2) TOC Based on OASIS TOSCAPICPROMCODE Spec 1.0 1. IntroductionAoyama1. Introduction 2. Interface Specification Design 2.1 Dependencies on Other Specs4.2 Compliance ?: Core, FOAF, 2.2 Notational Conventions 2.3 Normative References5. References 2.4 Non-Normative References5. References 2.5 Typographical Conventions 2.6 Namespaces4.2.2 Namespaces 2.7 Extensibility? 3. Core Concepts and Usage Patterns 3.1 Core ConceptsAoyama, Supply Chain Concept 2. PROMCODE Modeling Framework 3.2 Use Cases Aoyama, Matsumoto, Yabuta New-> Separate document

48 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 TOC of Draft Specification TOC Based on OASIS TOSCAPICPROMCODE Spec 1.0 4. PROMCODE Domain ModelYoshida3. PROMCODE Domain Model 4.1 Domain Model3.1 Domain Model 4.2 Examples of Project Models3.2 Examples of Project Models 5. PROMCODE Resource Definitions Wakao, Horiuchi 4. PROMCODE Service Specification 5.1 PROMCODE Resource Definitions4.3 PROMCODE Resource Definitions 6. PROMCODE Service Specification Wakao, Horiuchi 4.4 Service Provider Capabilities 7. Common Practices for Adoption4.5 Common Practices for Adoption Appendix: Example Appendix: Vocabulary, Resource Shape Funakoshi, Arthur

49 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 Time Line Revised MilestoneInitial PlanRevised TC LaunchedMar. 25, 2014 Start Writing Initial Working DraftAug. 5, 2014 Initial Working DraftMay 26, 2014Sep. 16, 2014 Committee Working DraftJun. 30, 2014Oct. 2014 Committee Spec. Public ReviewJul. 31, 2014Nov. 2014 Committee SpecificationSep. 15, 2014Dec. 2014 Candidate of OASIS StandardDec. 2014Feb. 2015 OASIS StandardMar. 2015 Specification Development Team: Aoyama, Funakoshi, Horiuchi, Matsumoto, Wakao, Yoshida Specification Review Team: Development Team and Kamimura, Ryman, Yabuta

50 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 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, OSLC Resource Shape: A Language for Defining Constraints on Linked Data,. [ 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/.

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

Similar presentations

Presentation on theme: "1 All Rights Reserved, Copyright Next-Generation Project Management Data Exchange Architecture Committee, 2014 OASIS OSLC PROMCODE TC Domain Model Revisited."— 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 OASIS OSLC PROMCODE TC Domain Model Revisited.

Similar presentations

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

Similar presentations

About project

Feedback