OSLC PLM Workgroup: Detailed Use Cases & Alignment to OSLC V0.2

1. Towards detailed use cases and alignment to OSLC V0.2 Gray Bachelor 19th July 2011 OSLC PLM Workgroup

2. What’s in here ? • This is working material used to build out the OSLC PLM scenarios to support more detailed workings on Spec usage and extension by way of detailed use-cases and data analysis leading to service identification and modification • This aims to work up ideas ahead of building up more formal models OSLC PLM Workgroup

3. Pains to target • Increasing time and cost to manage integrity of complex system designs and its relevant requirements • Increasing impact of an error arising from system design not updated correctly from changes • Increasing need to coordinate work across larger and more dispersed work locations and organisational responsibilities OSLC PLM Workgroup

4. Business goal • To reduce the time and cost to manage changes to complex systems arising from changes to requirements OSLC PLM Workgroup

5. There are 3 related concerns • The primary domains of the target operating environment are • Product design • Enterprise integration • Corporate compliance OSLC PLM Workgroup

6. Product design OSLC PLM Workgroup

7. Existing OSLC sources • Activity diagram • Who does what when • Sequence diagram • Which system component does what when OSLC PLM Workgroup

8. Which roles • Product change administrator (Must • System Engineer (Must • Sub-system owner (Should • Software Engineer (Could • Business analyst (Should • IT administrator (Could • Enterprise Integration developer (Must • Application support leader (Could OSLC PLM Workgroup

9. Which scenarios • OSLC PLM SE Scenario #1 • A Systems Engineer responds to a change in requirements • OSLC PLM SE Scenario #2 New • A Product Change owner assigns a change to a product release plan • OSLC PLM EI Scenario #1 New • A Business Analyst identifies required information and process support for a SE scenario • An Integration Developer delivers process support through enterprise integration • An IT administrator deploys process support to users • An Application support leader handles problems with the deployed process support OSLC PLM Workgroup

10. OSLC PLM SE Scenario #1 A Systems Engineer responds to a change in requirements OSLC PLM Workgroup

11. Outline of OSLC PLM SE Scenario #1 1. Assign & communicate the change request (a1, a2, a3) Assign change request context Communicate change request Locate change request from notification 2. Apply request context to establish impacted requirements & implementation (a4, a5, a6) Locate requirements in change request context Create new revision of requirements context and reserve for editing Open new revision of context 3. Locate re-usable implementations to meet changed requirements (a7) Located reusable implementation to satisfy change? (A decision that drives alternative flows) 4a. Either update solution by way of adaption of re-usable implementations (a8, a9, a10, a13, a14, a15) Add selected implementation to change request as solution Merge selected implementation into context Trace to discipline responsibility Analyse detailed requirements & existing implementation Design minor updates to existing implementation Design by sub-team needed ? 4b. Or design solution by original design (a10, a11, a12, a15) Trace to discipline responsibility Design new implementation Add new design to change request solution Design by sub-team needed ? 5. Approve change request solution (a16, a17) Passed review of implementation for change request closure? Close change request OSLC PLM Workgroup * Note: 4 has alternative flows

12. Scenario Activity Diagram – 1 of 3 Page 1 of 3 Page 2 of 3 OSLC PLM Workgroup

13. SE use-cases (1 of View My CRs1 a3: Locate CR a3: View CR and its Product context a4: View impacted / new requirements a4: Explore associated information Collaborate with colleagues Plan work Start work a5: Create new revision of impacted configuration a5: Reserve affected items a6: Edit new revision OSLC PLM Workgroup Note 1: Assume CR is assigned, not claimed

14. Scenario Activity Diagram – 2 of 3 Page 1 of 3 Page 2 of 3 CR Page 2 of 3 Page 3 of 3 OSLC PLM Workgroup

15. SE use-cases (2 of Collaborate with colleagues a7: Identify impacted requirements Update existing requirements Search requirement catalog a7: Identify re-usable requirements Notify colleagues Propose changes to requirements Gain approval for requirements changes Commit changes to requirements Search system catalog a14: Minor updates to solution Gain approval for system level changes a7: Identify candidate solutions a9: Assess impact of working set changes a8: Add solution candidates to working set Gain approval for system level candidates Propose candidate solutions OSLC PLM Workgroup

16. SE use-cases (3 of a11: System level design to meet changed requirements Verify systems level design a12: Add system level design changes to solution proposal Collaborate with colleagues Manage system level design changes Propose system level changes Notify colleagues Gain approval for system level changes Commit system level changes OSLC PLM Workgroup

17. Scenario Activity Diagram – 3 of 3 Page 2 of 3 Page 3 of 3 OSLC PLM Workgroup

18. SE use-cases (4 of Search people catalog a15: Identify sub-system owner Collaborate with colleagues a11: Preparation for sub-system or discipline engineering Notify project manager a11: Proposal for sub-system or discipline engineering Estimate sub-system or discipline engineering Approval for sub-system or discipline engineering Release system level design package to sub-system Notify colleagues Support the system level design Support design review Handle changes to system level design a16: Approve sub-system engineering Escalate sub-system engineering OSLC PLM Workgroup

19. Activity diagram analysis • We don’t say what artefacts need to be dominated • What is the vital meta-data to make association ? OSLC PLM Workgroup

20. Object diagram User Target Portfolio Role Budget CR Product family Requirement set Configuration Org Note Approval Product Requirement System component Customer Bug Work estimate Catalog Order CR artefact Requirement artefact System artefact Issue Product artefact Market segment Verification artefact Plan Review meeting Work item Practice OSLC PLM Workgroup

21. Supporting objects and types Types More detailed related objects Metric Stakeholder requirement Use case Capability catalog Configuration System requirement Test case Practice catalog Document Activity diagram Regulatory requirement People catalog Model configuration Sequence diagram Product catalog Model element State machine Requirements catalog Algorithm System catalog Verification result System component catalog OSLC PLM Workgroup

22. More detailed analysis of the Requirement Change Handling towards OSLC service alignment OSLC PLM Workgroup

23. SE use-cases (1 of View My CRs1 a3: Locate CR a3: View CR and its Product context a4: View impacted / new requirements a4: Explore associated information Collaborate with colleagues Plan work Start work a5: Create new revision of impacted configuration a5: Reserve affected items a6: Edit new revision OSLC PLM Workgroup Note 1: Assume CR is assigned, not claimed

24. Example of use cases: understanding the impact of changes to Requirements Login Set my profile Query Work Item View My CRs1 Open Work Item a3: Locate CR Query CR a3.1: Open CR a3.2: Explore & view CR a3.3: View CR product context Query product context a3.4: Locate CR affected requirements Query requirements baseline Query requirements a4: View impacted / new requirements OSLC PLM Workgroup Colouring represents different “levels” aN were in the Activity diagram, aN.M are new

25. Next steps • Align to sequence diagrams • For detailed area identified • Clarify objects • Identify attributes • Identify use of existing services • Identify extensions • Propose to look at the preceding stage to build up the CR OSLC PLM Workgroup

26. OSLC PLM SE Scenario #2 New A Product Change owner assigns a change to a product release plan OSLC PLM Workgroup

27. Assumptions about CRs • These arise from • customer request or marketing input (requests • internal feedback from quality assessment • analysis of field problems • i.e. bugs that require more significant action OSLC PLM Workgroup

28. The CR preparation area to focus upon • The assignment of the CR to a product context • Identity, version or release • Organisation, product responsible • Optionally • The association of CR with any related requirements , requests or associated information • The association of a the CR with an existing (e.g. in process) configuration OSLC PLM Workgroup

29. Clarification of what mean to achieve by assignment and association • The primary goal is to assign a CR to a target development org, responsible and activity to answer the customers question • “who is assigned to work on my request ?” • The secondary goal is to assign a CR to a target product, release / system build plan, to answer the customers question • “when will it be available?” • We may associate requirements and existing configurations as targets, candidates or hints prior to significant work beginning • Work may start using one configuration as a basis and be switched to another as work progresses or plans finalised, even up to a late stage of commitment in some cases • Requirements may get altered as the work proceeds, there is likely to be some changes up until a commit point where a core set of requirements becomes a must/shall and others marked for attention by development depending upon available time/resource. Typically organisations only assign resource to the must/shall, in some cases the assigned requirements and their ranking priorities are modified in flight such as to alter the CR and/or requirement to another CR, release, requirement OSLC PLM Workgroup

30. Out of scope • Assessment of importance • Analysis of feasibility, high level design or solutioning • Estimating, Costing and revenue estimation • Refinement of Cust Request to Formal CR • CR triage, split, group, merge, consolidate, refine and extend • Portfolio trade-off or scenarios prior to commitment • Risk assessment • Release planning • Commitment to Plan • Spin off to new product, variant or devt (e.g. project, org) • Grouping in a queues prior to handling • Escalation to win product responsibility acceptance • Descoping or changes to assignment • Negotiation of requirements to meet and contract a CR OSLC PLM Workgroup

31. CR handling cases • CRs that prescribe a (target) product release (Yes • CRs that need to be negotiated prior to acceptance by a product owner (OOS) • CRs that fall into a single product area (Yes • CRs that span multiple products (OOS • CRs where there is an existing devt stream • CRs where there is no existing stream (OOS) • CRs that are queued not fully assigned (OOS OSLC PLM Workgroup

32. Introduction to the CR assignment and association use cases • A relatively full and rich set of steps are shown • These of course can be collapsed to • Query available products – select one • Query available versions – select one • Query available requirements baselines – select one • Query available requirements – select n • Query available configurations – select one OSLC PLM Workgroup

33. Sketch of the preceding Activity Diagram: Assigning a CR to a Product Context Assign to product area responsible Capture notes Analyse description Assign to orgs Raise issues to address Assign to product families Assign to portfolio manager Assign to products1 Assign to product manager Assign to release manager Assign to releases1 Assign to CR stream Assign to architect analyst/SE Product unassigned Consult product analysts Validate product assignment Confirm product assignment Approve OSLC PLM Workgroup Notify responsibles Note 1 – one product release only

34. Example of use cases: Assigning a CR to a Product Context (Basic stuff same as before Login Set my profile Query Work Item View My CRs1 Open Work Item a3: Locate CR Query CR a3.1: Open CR a3.2: Explore & view CR … .. .. Overleaf OSLC PLM Workgroup Colouring represents different “levels” aN were in the Activity diagram, aN.M are new

35. Example of use cases: Assigning a CR to a Product Context a3.3: View CR product context Query Product Context of CR Query products Identify available products Select available products Associate Product Context with CR Identify available product releases Query product versions Select available product version Validate product context Approve product context 1. Colouring represents different “levels” aN were in the Activity diagram, aN.M are new 2. a3.3 is included if a context is already assigned OSLC PLM Workgroup

36. Sketch of the preceding Activity Diagram: Optionally associating requirements Existing requirements linked ? Validate existing requirements Capture notes Analyse description Locate relevant requirements Raise issues to address Select / propose relevant requirements Call meetings / raise to-dos Identify product coverage Support CR/Req mtgs Identify product responsibility Consult SMEs Update product responsibility ? Confirm associated requirements Validate product assignment Approve OSLC PLM Workgroup Notify responsibles

37. Example of use cases: Optionally associating requirements (Basic stuff same as before Login Set my profile Query Work Item View My CRs1 Open Work Item a3: Locate CR Query CR a3.1: Open CR a3.2: Explore & view CR … .. .. Overleaf OSLC PLM Workgroup Colouring represents different “levels” aN were in the Activity diagram, aN.M are new

38. Example of use cases: Optionally associating requirements a3.3: View CR product context Query Product Context of CR Query associated Requirements of CR Identify product context requirements Select product context requirements Query requirements Identify available requirements Associate Requirement with CR Evaluate product context of identified requirements Query products Select requirement Query product versions Validate associated requirements Approve associated requirements 1. Colouring represents different “levels” aN were in the Activity diagram, aN.M are new 2. Side by side comparison is out of scope here OSLC PLM Workgroup

39. Sketch of the preceding Activity Diagram: Optionally associating configurations Existing configurations linked ? Validate existing configurations Capture notes Analyse description Locate relevant configurations from product releases Raise issues to address Locate relevant configurations from requirements Call meetings / raise to-dos Select / propose relevant configurations Support CR/Req mtgs Identify product coverage Consult SMEs Identify product responsibility Update product responsibility ? Confirm associated configurations Approve Validate product assignment Notify responsibles OSLC PLM Workgroup

40. Example of use cases: Optionally associating configurations (Basic stuff same as before Login Set my profile Query Work Item View My CRs1 Open Work Item a3: Locate CR Query CR a3.1: Open CR a3.2: Explore & view CR … .. .. Overleaf OSLC PLM Workgroup Colouring represents different “levels” aN were in the Activity diagram, aN.M are new

41. Example of use cases: Optionally associating configurations a3.3: View CR product context Query Product Context of CR Identify product context configurations Query configurations Associate Configuration with CR Select product context configurations Identify product configurations of associated requirements Query associated Requirements of CR Query Requirement Associated with CR Identify available configurations Associate Configuration with Requirement and CR Evaluate product context of identified configurations Select configuration Validate associated configurations Approve associated configurations 1. Colouring represents different “levels” aN were in the Activity diagram, aN.M are new 2. Side by side comparison is out of scope here OSLC PLM Workgroup

42. Proposal at 19/7 • Organisational assignment OOS • If Product “included in” and “consists of” allow n:m assignment i.e. loose collections then Product Family can be treated as a type of Product, hence deprecated • Validation of relevance of assignment and association is by query with possible annotation by SME/Analyst i.e. judgement not by testing configuration rules • Address assignment to 1 product release only • Re-Confirm product assignment, requirement and configuration association should include saving or “registering” the relationship OSLC PLM Workgroup

43. Changes • V0.1 Initial version • V0.2 Updates to include the CR assignment to product context and relevant requirements OSLC PLM Workgroup