Reporting Meeting, 2009-10-02

See Reporting Meetings for meeting logistics.

Agenda and Minutes

Attendees

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?

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

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