Date: Aug 26 2009

Agenda:

• Introduce new members
  • Sogeti (Michael)
  • Big Lever (Glenn)
  • Tieto (Ingrid)
• Discuss the proposed scenarios
  • Background on Collaborative Application Lifecycle Management (CALM)
  • Scenario A: Validate a set of requirements
  • Scenario B: Test whether a requirement has been satisfied
  • Scenario C: Test a deliverable according to an established test methodology
    • May be impacted by cross-OSLC resource metadata initiative
• Discuss likely specification deliverables
  • REST API
  • Service Discovery
  • Test plan and test case resource formats
  • See OSLC-CM 1.0 Specifications as an example
  • Propose adoption of OSLC Service Provider Catalog 1.0 Specification
• Proposed schedule for 1.0 deliverables
  • 8/28 scenarios finalized
  • 10/1 draft
  • 11/1 final
  • Volunteers?

Minutes

Attendance: PaulMcMahan, MikeSaylor, ScottBosworth, JimConallen, IanGreen, MichaelPena, GoshenPan

• Introduced new workgroup member from Sogeti
• Discussed Tieto's recent introduction into the workgroup. Tieto has experience integrationg QM with CaliberRM? , and other types of products. Tieto contact sent regrets for today's meeting.
• Feedback on CALM scenarios A and B
  • These scenarios present a lot of similarities to the scenarios being developed at RmHome
  • Terminology used in scenarios is OK except "requirement set" should be "requirement collection"
  • It should be more clear when product/tool boundaries are being crossed
  • Need more explicit language around searching/creating test plan and test case resources
• Feedback on scenario C
  • This scenario may have a good deal in common with other OSLC topic areas where process and metadata are important.
  • Change management workgroup made an explicit decision to set process-oriented scenarios aside for v1.0 specification work.
  • Paul suggested that this scenario could be investigated with the OSLC group at large as opposed to basing it solely on the "template" idea employed by RQM
  • This scenario does not have enough definition yet to provide scope for a draft specification. Due to time constraints for v1.0 specs it may need to be incorporated into a follow-on spec. This should should not prevent the workgroup from continuning to investigate the scenario in parallel with the 1.0 specification activities.
• Workgroup suggested that we consider adding scenarios which discuss
  • Versioning
  • Reporting. Would be helpful for QM to provide reporting scenarios to newly formed reporting workgroup
  • Query
• Workgroup raised no issues with proposal to deliver the following OSLC QM 1.0 specifications:
  • REST API
  • Service Discovery
  • Test plan and test case resource formats
• Workgroup raised no issues with adoption of OSLC Service Provider Catalog 1.0 Specification
• Ensuing discussion about the scenarios is encouraged via the new OSLC QM mailing list. OSLC-QM@open-servicesNOSPAM.net
• Proposed schedule for 1.0 deliverables lists 8/28 for scenarios being finalized. Extending to early next week so that feedback from today's meeting can be incorporated into the scenarios.
• Volunteers requested for authoring and reviewing forthcoming draft specifications. Paul to work on first rough draft of specs and invite collaboration and review based on interest in particular areas.

-- PaulMcMahan - 28 Aug 2009