This wiki is locked. Future workgroup activity and specification development must take place at our new wiki. For more information, see this blog post about the new governance model and this post about changes to the website.

Reporting Meeting, 2009-10-02


See Reporting Meetings for meeting logistics.

Agenda and Minutes

Attendees

Member
Attendance
Arthur Ryman X
Scott Bosworth X
Tack Tong X
Benjamin Williams X
Dragos Cojocari X
Mik Kersten regret
Seb Rose regret
Vishy Ramaswamy X
James Moody X
Steve Abrams regret
Steve Speicher X
Scott Fairbrother X
Xiang Dong Hu X

1. Introductions

Since this is our first telecon, let's take a few minutes to introduce ourselves.

Any new agenda items?

Please subscribe to the Reporting Mailing list.


The scope of participants was discussed and it was identified that we like to encourage more participation from external (outside Rational and IBM).

Action Item: Scott Fairbrother to followup with CAST, Actuate, BusinessObject.

Action Item: Tack Tong to followup with Accenture, Cognos, Pentaho, Tivoli

Action Item: Tack Tong to followup with OSLC leads in other topics to solicitate external service providers.

Action Item: Benjamin Williams to followup with InfoSphere Data Architect.



2. Meeting Logistics

How often and when do we meet regularly?

Meet biweekly or weekly? with email/wiki/working meetings in between.

Due to time zone differences (ranging from EDT-3 to EDT+12) between all participants, the time window to meet is very restrictive. The realistic time slots for the meeting are between 10am - noon EDT. This translates into

  • 10am - noon EDT
  • 7am - 9am PDT
  • 3pm - 5pm for UK
  • 5pm - 7pm for Romania
  • 10pm - midnight for China

Obviously, preferrably it will be 10am - 11am so that China does not need to stay up till mid night. But it will be early for PDT though.

Based on availability, these are the candidate time slots.

Mon 10am - 11am EDT (i.e. 7am PDT) : 1 of the respondants will not be available

Mon 11am - noon EDT (i.e. 8am PDT) : 1 of the respondants will not be available
Tue 10am - 11am EDT (i.e. 7am PDT) : 1 of the respondants will not be available

Please fill in your availability - which time slots and which dates?

Member
Availability
Arthur Ryman

Mon 10am - noon EDT

Tue 10am - noon EDT

Wed 11am - noon EDT

Thurs 10am - 11am EDT

Fri 11am - noon EDT

Scott Bosworth  
Tack Tong

Monday - Fridady

10am - noon EDT

Benjamin Williams Mon/Tue/Thur 10am - 11am EDT
Dragos Cojocari 10am - noon EDT any day
Mik Kersten no pre-8am PDT
Seb Rose

Mon, Tues, Fri 10-noon EDT

Thurs 10-11 EDT

Vishy Ramaswamy  
James Moody

Mon 10am - noon EDT

Tue 10am - 11am EDT

Thur 10am - 11am EDT

Steve Abrams  
Steve Speicher  
Scott Fairbrother  
Xiang Dong Hu Monday - Friday

10am - noon EDT



Regular meeting:

Frequency: weekly

Time: every Monday 11:am to noon EDT


3. Workgroup Goals

Let's discuss our goals and scopes.

It is assumed that all domain resources will have REST service defined for retrieving data as part of the OSLC specifications. Currently, there are topics in OSLC on Change Management, Requirement Management, Quality Management, Software Configuration Management, Softare Estimation and Measurement, Asset Management, Architecture Management,.....etc. The REST service defined by these domain specifications are mainly focused on use cases that are transactional. Reporting use cases are typically involved retrieving large volume of data. Reporting clients are typically generic in nature and have no prior knowledge of the domain resources they are dealing with. Thus these unique reporting use cases introduce extra requirements. The objective of this Reporting specification (OSLC Reporting Specification) is to specify these extra requirements on top of the domain specificaitons. The intention is to have this as a cross domain specification. Any service provider can implement this specification to make their OSLC services consumable by reporting clients.

The scope of Reporting includes the following broad categories of information presentation that are important to software and systeme delivery (SSD).

  • operational reporting - e.g. generate tabular or graphical business reports showing the latest data, on demand
  • documentation - e.g. generate complex documents showing tracibility of requirements to architectural elements and test cases
  • analytics - e.g. batch load bulk data nightly to populate a data warehouse for business intelligence reporting

The OSLC Reporting Specification 1.0 should be scoped to address the mandatory features (i.e. features to make it work) first and then address those features for optimization as time allows.


The above goal and scope was discussed and clarified.

The specification will be named OSLC Reporting Specification. <above description was updated accordingly>


4. Schedules and Milestones

Let's discuss and establish timeline for some milestones.

I like to propose time-box OSLC Reporting 1.0 - think agile.

I like to propose an overal schedule as follows. This would align with the other OSLC topic specification schedules.

Scope Draft Converge Finalize
Oct 2009 Dec 2009 Feb 2010 Mar 2010

Base on your experience with OSLC, do you think it is realistic or too agressive?


Based on discussion, the above schedule is updated accordingly.

5. Use Case Prioritization

We have several [Reporting Use Cases] proposed. Are there more? Let's prioritize the list.

  1. Reporting client retrieving data from a service provider for loading into a data warehouse.
  2. Reporting client retrieving data from multiple domain service providers for loading into data warehouse with traceability between resources.
  3. Reporting client retrieving incremental changeddata from a service provider for subsequent loading into a data warehouse.
  4. Reporting client discovering resources available for reporting.
  5. Reporting client retrieving data from a service provider for operational reporting.
  6. Reporting client retrieving data from a service provider for document generation.
  7. Reporting client retrieving data from multiple domain service providers for document generation with traceability between resources.

The above use cases are updated based on discussion.

Ran out of time for a thorough discussion. Will use email to finalize the list and pick a few top ones to work on. Goal is to have 1st draft of the top ones for discussion in next meeting.

Link to ReportingUseCases.


6. Prior Works

Are there any work done in this area that would serve as input to this workgroup?

  • Insight/RPE Reportable REST Specification - current spec. defined for working with current version of Insight/RPE. This could be a good source of use cases and requirements. However, we need to be vigilant not too much influence by this spec. in choosing technologies and defining interfaces.
  • OSLC-CM 1.0 Specification has many features that are somehow related to Reporting. This could be a good source to factor those out as part of the OSLC Reportable Specification and generalize for cross domain purpose.


I moved the above prior work links to the Reporting home page.

Action Item: DragosCojocari to add any prior work from RPE.


Next week

  • Use Cases

Comments

Add your comments here:


 
Topic revision: r13 - 02 Oct 2009 - 22:20:52 - TackTong
 
This site is powered by the TWiki collaboration platform Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use
Ideas, requests, problems regarding this site? Send feedback