Reporting Meeting, 2009-10-02

See Reporting Meetings for meeting logistics.

Agenda and Minutes

Attendees

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

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.

---

---

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) : all 6 respondants are 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) : all 6 respondants are available
Thur 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
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

---

---

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 Reportable Specification) <do we have consensus naming the spec. OSLC Reportable 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 Reportable 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.

---

4. Schedules and Milestones

Let's discuss and establish timeline for some milestones.

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

I like to propose an overal schedule with draft spec. done at the end of Dec. 2009 and final spec. done at the end of Jan. 2010. This would give sufficient time to be able to showcase product implementation at RSC 2010 in June.

Scope	Draft	Converge	Finalize
Oct 2009	Dec 2009	mid Jan 2010	Jan 2010

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

---

5. Use Case Prioritization

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

1. Retrieving small volume of data from a service provider for loading into a data warehouse.
2. Retrievng large volume of data from a service provider for loading into a data warehouse.
3. Retrieving data from multiple domain service providers for loading into data warehouse with traceability between resources.
4. Retrieving incremental changeddata from a service provider for subsequent loading into a data warehouse.
5. Discovering resources available for reporting.
6. Retrieving data from a service provider for operational reporting or document generation.
7. Retrieving data from multiple domain service providers for operational reporting or document generation.

---

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.

---

Next week

Comments

Add your comments here: