Presentation is loading. Please wait.

Presentation is loading. Please wait.

Specification Development and Review Team

Similar presentations


Presentation on theme: "Specification Development and Review Team"— Presentation transcript:

1 Specification Development and Review Team
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

2 Contents Upcoming TC Meeting Schedule Proposed Domain Model Revised
Use Cases and Scenarios Resources Associated with the Scenarios TOC of the Draft Specifications Time Line Revised References

3 Upcoming TC Meeting Schedule Proposed
オブジェクト指向'98シンンポジウム チュートリアル Upcoming TC Meeting Schedule Proposed 1998年9月16日 Schedule Date/Time [EST] Date/Time [JST] Note 16 TC Meeting 7.00 p.m., Dec. 9 9:00 a.m., Dec. 10 17 7.00 p.m., Dec. 23 9:00 a.m., Dec. 24 18 7.00 p.m., Jan. 6 9:00 a.m., Jan. 7 19 7.00 p.m., Jan. 20 9:00 a.m., Jan. 21 20 7.00 p.m., Feb. 3 9:00 a.m., Feb. 4 21 7.00 p.m., Feb. 17 9:00 a.m., Feb. 18 Note: Start of US DST: March 8, 2015 (Sun)

4 Domain Model Revised

5 Domain Model v. 2.31(Revised Nov. 25)

6 Domain Model v. 2.30(Revised Nov. 11)

7 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

8 Proposed Revision to Domain Model v. 2.26
State <-belongsTo IssueCollection collects <-correspondsTo +raisedDate: DateTime

9 Domain Model v. 2.26(Revised Sep. 25)

10 Domain Model v. 2.25(Revised Sep. 30/Oct. 1)

11 オブジェクト指向'98シンンポジウム チュートリアル
Issues and Proposed Changes to Domain Model Discussed at the TC on 9/17 1998年9月16日 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 Reference Properties of Attributes in UML Class Diagrams
Multiplicity [Default value is 1] 1 - this attribute has a single value of the specified Type. 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,

13 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 [ISO ] 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 [ISO : and Appendix C]. Reference:

14 On Use of Measure and Metrics ISO 15939:2007 Appendix
オブジェクト指向'98シンンポジウム チュートリアル On Use of Measure and Metrics ISO 15939:2007 Appendix 1998年9月16日 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 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 Measure

15 Domain Model v. 2.4(Revised Sep. 16)
オブジェクト指向'98シンンポジウム チュートリアル Domain Model v. 2.4(Revised Sep. 16) Add attributes: identifier title description plannedStartDate actualStartDate plannedEndDate actualEndDate 1998年9月16日 (sizeOfScopeItem) FP Title: login screen actualSize: 10 State? FP Change mame: MeasurementCriteria -> Target metric KLOC “CodeSize”

16 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

17 Domain Model Comparison of EMS and PROMCODE
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. Metric metric metric:Sloc (URI) Measure value:Decimal -> MeasureType [refer to] MeasurementCriteria Unit of Measure unitOfMeasure unit:Loc (URI) UnitType <-[referred by] Measure unit ->unitOfMeasure Measurement Measurement  numericValue xsd:double -> ScopeItem Unit of PlannedSize is undefined ->Associate MeasureType and UnitType to Project (A unique measure across the project)

18 Domain Model v. 2.2(Revised Sep. 2)

19 Domain Model Revisited for v 2.2 on 9/2
オブジェクト指向'98シンンポジウム チュートリアル Domain Model Revisited for v 2.2 on 9/2 1998年9月16日 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

20 オブジェクト指向'98シンンポジウム チュートリアル
Domain Model (Aug. 6) オブジェクト指向'98シンンポジウム チュートリアル 1998年9月16日

21 Domain Model Revisited (2/2)
オブジェクト指向'98シンンポジウム チュートリアル Domain Model Revisited (2/2) 1998年9月16日 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 MeasurementCriteria Measure Title + Identifier NA Type

22 Use Cases and Scenarios

23 Use Cases and Scenarios Usage Context of Software Supply Chain
オブジェクト指向'98シンンポジウム チュートリアル 1998年9月16日 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 Acquirer Supplier Acquirer Supplier Organization A Organization Bn Organization Cnm * *

24 Use Cases and Scenarios Deployment Patterns and High-level Scenario
オブジェクト指向'98シンンポジウム チュートリアル 1998年9月16日 Deployment Pattern A 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. () Supplier Acquirer PROMCODE Dashboard Tool S Supplier 1 Tool S1 P C (Tool A) Push Pull Report (Web Service) Report P: Provider, C: Consumer Deployment Pattern B Supplier Acquirer Push P/C Deployment Pattern C Supplier Acquirer Pull P C

25 Use Cases and Scenarios Use Cases (Top Level)
オブジェクト指向'98シンンポジウム チュートリアル Use Cases and Scenarios Use Cases (Top Level) 1998年9月16日 Use vocabulary practically common in project management in contracted delivery Consistent with global standards: PMBOK, ISO 21500:2012  Project Initiation and Planning  Project Execution Acquirer Supplier  Project Closing

26 Use Cases and Scenarios Use Cases: Project Execution
オブジェクト指向'98シンンポジウム チュートリアル Use Cases and Scenarios Use Cases: Project Execution 1998年9月16日 Use vocabulary practically common in project management in contracted delivery Consistent with global standards: PMBOK, ISO 21500:2012 Project Execution and Control  Project Start  Status Reporting  Status Aggregation Acquirer Supplier Project Closing

27 Use Cases and Scenarios Use Cases: Project Execution
オブジェクト指向'98シンンポジウム チュートリアル Use Cases and Scenarios Use Cases: Project Execution 1998年9月16日 Use vocabulary practically common in project management in contracted delivery Consistent with global standards: PMBOK, ISO 21500:2012 Project Execution  Schedule Problem  Quality Problem Acquirer Supplier Re-schedule/Re-planning

28 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.

29 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.

30 Use Case “Project Execution with PROMCODE” Review and Actions for Schedule Problem [Dec. 10]
Schedule Delay PM-A compares previous report and current report and highlights the difference. Reviews the difference and raises a concern if the following is observed. No progress from the previous report Risk of not meeting a schedule emerges with the current pace of progress. May use past data on productivity to project risk. PM-A interacts with PM-S on further update. Reasons for delay Outlook of meeting a schedule. Based on the interaction, PM-A takes one of the following actions. No formal action, but with notice on the situation to monitor. Raise an issue on the situation and create actions Escalate to stakeholders for possible plan change. If it is necessary, plan will be changed [See details in “Plan Change” scenario]

31 Use Case “Project Execution with PROMCODE” Review and Actions for Quality Problems [Dec. 10]
Quality Concern PM-A compares previous report and current report and highlights the difference. Reviews the difference and raises a concern if the progress is not sufficient and there is a risk of not meeting quality goal. PM-A interacts with PM-S on further update. Reasons of the current problem Outlook of meeting a goal Assess the impact to the overall project. Based on the interaction, PM-A takes one of the following actions. Raise an issue on the situation and create actions Escalate to stakeholders for possible plan change. If it is necessary, actions will be taken place [see details in “Quality Action” scenario]

32 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 sustimer.a 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 nd WorlItem if necessary

33 Use Case “Project Execution with PROMCODE” Plan Change[Dec. 10]
スコープ(ScopeItem), 納期,予算,成果物(Artifact)の変更 ScopeItem: 要素の増減とサイズの変更 納期変更: 延伸 予算: 追加 成果物: 要素の増減とサイズの変更[ScopeItemによる] シナリオ[スコープの変更] A: ScopeItemの(要素の)変更を決定 A: 削減したScopeItemの内容とPlanを該当するSへ通知 S: 通知されたScopeItemの内容とPlanをレビューし,妥当であれば,その旨をAへ通知 S&A: Planを合意する A: 合意したPlanを新しいPlanとする A&S: 変更されたScopeItemに対応して必要であればArtifactとWorkItemを変更

34 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”.

35 Use Case “Project Start” Revised [Nov. 11]
Obsolete 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.

36 Use Case “Project Execution with PROMCODE” Simple Use Case
Obsolete 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 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. . 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. PM-S sends an update as a Report to PM-A. PM-A reviews updates and takes actions such as such as creating and managing Issues. In particular, Review the possibility of schedule delay Review Quality Details of these will be elaborated in the next pages. Repeat Steps 2-4 as necessary Conduct acceptance review and close a project

37 Resources Associated with the Scenarios

38 Resources Created before “Start Project”(1/3)[Nov. 11]
Attributes Creator Value Project Identifier Acquirer Title Description plannedStartDate plannedEndDate typeOfScopeItemSize URI unitOfScopeItemSize Resource Attributes Creator Value Plan Identifier Acquirer Title Date belongsTo collects

39 Resources Created before “Start Project”(2/3)[Nov. 11]
Attributes Creator Value ScopeItem Identifier Acquirer Title Description plannedSize isPartOf Resource Attributes Creator Value WorkItem Identifier Acquirer Title Description plannedStartDate plannedEndDate isPartOf requiredBy representedBy Supplier

40 Resources Created before “Start Project”(3/3)[Nov. 11]
Attributes Creator Value Artifact Identifier Acquirer Title Description isPartOf producedBy Resource Attributes Creator Value Target Identifier Acquirer Title determines designedFor Resource Attributes Creator Value Measure Identifier Acquirer Title typeOfMeasure unitOfMeasure

41 Resources Created/Changed in “Status Reporting”(1/2)[Nov. 11]
Attributes Creator Value Report Identifier Acquirer Title Supplier Date correspondsTo belongsTo collects Resource Attributes Creator Value WorkItem actualStartDate Supplier actualEndDate Resource Attributes Creator Value Measurement Date Supplier Resource Attributes Creator Value Measure Supplier

42 Resources Created/Changed in “Status Reporting”(2/2)[Nov. 11]
Attributes Creator Value IssueCollection Identifier Acquirer Title Supplier Date collects Resource Attributes Creator Value Issue Identifier Acquirer/Supplier Title raisedDate Description

43 Resources Created/Changed in “Project Closing”[Nov. 11]
Attributes Creator Value Project actualEndDate Supplier Resource Attributes Creator Value ScopeItem actualSize Supplier

44 TOC of the Draft Specifications

45 TOC of Draft Specification (1/2)
TOC Based on OASIS TOSCA PIC PROMCODE Spec 1.0 1. Introduction Mikio 2. Interface Specification Design 2.1 Dependencies on Other Specs 4.2 Compliance ?: Core, FOAF, 2.2 Notational Conventions 2.3 Normative References 5. References 2.4 Non-Normative References 2.5 Typographical Conventions 2.6 Namespaces 4.2.2 Namespaces 2.7 Extensibility ? 3. Core Concepts and Usage Patterns 3.1 Core Concepts Mikio, Matsumoto Supply Chain Concept 2. PROMCODE Modeling Framework 3.2 Use Cases New

46 TOC of Draft Specification
TOC Based on OASIS TOSCA PIC PROMCODE Spec 1.0 4. PROMCODE Domain Model Yoshida 3. PROMCODE Domain Model 4.1 Domain Model 3.1 Domain Model 4.2 Examples of Project Models 3.2 Examples of Project Models 5. PROMCODE Resource Definitions Wakao, Horiuchi 4. PROMCODE Service Specification 5.1 PROMCODE Resource Definitions 4.3 PROMCODE Resource Definitions 6. PROMCODE Service Specification 4.4 Service Provider Capabilities 7. Common Practices for Adoption 4.5 Common Practices for Adoption Appendix: Example Appendix: Vocabulary, Resource Shape Funakoshi, Arthur

47 オブジェクト指向'98シンンポジウム チュートリアル
Time Line Revised 1998年9月16日 Milestone Initial Plan Revised TC Launched Mar. 25, 2014 Start Writing Initial Working Draft Aug. 5, 2014 Initial Working Draft May 26, 2014 Sep. 16, 2014 Committee Working Draft Jun. 30, 2014 Oct. 2014 Committee Spec. Public Review Jul. 31, 2014 Nov. 2014 Committee Specification Sep. 15, 2014 Dec. 2014 Candidate of OASIS Standard Feb. 2015 OASIS Standard Mar. 2015 Specification Development Team: Aoyama, Funakoshi, Horiuchi, Matsumoto, Wakao, Yoshida Specification Review Team: Development Team and Kamimura, Ryman, Yabuta

48 References [ 1] R. Cyganiak, et al. (eds.), RDF 1.1 Concepts and Abstract Syntax, W3C Recommendation, 25 February 2014, [ 2] R. Cyganiak, An RDF Design Pattern: Inverse Property Labels, Jun. 2006, [ 3] A. G. Ryman, OSLC Resource Shape: A Language for Defining Constraints on Linked Data, . [ 4] A. G. Ryman, Vocabulary Annotation Vocabulary, Sep. 2013, [ 5] A. G. Ryman, Resource Shape 2.0, W3C Member Submission, Feb. 2014,


Download ppt "Specification Development and Review Team"

Similar presentations


Ads by Google