Hallo Sibylle,
ist es möglich, vor einer weiteren Verbreitung des Dokumentes den Abschnitt 5 zu konsolidieren? Um das Dokument nutzbar zu machen, ist eine Klärung der dort beschriebenen
Verantwortlichkeiten unter Bezugnahme auf die aktuell in der community besetzten Rollen nötig.
Bitte holt Euch zu dieser Frage (Definition und Besetzung einer neuen Rolle in der community oder Beibehaltung des temporären Delegationsprinzip an den „Paten“)
eine Entscheidung vom steering committee als owner des requirements service.
Mit freundlichen Grüßen, Sven.
Von: open-measured-data-wg-bounces@xxxxxxxxxxx [mailto:open-measured-data-wg-bounces@xxxxxxxxxxx]
Im Auftrag von Sibylle Peter
Gesendet: Dienstag, 21. April 2015 22:34
An: open-measured-data-wg@xxxxxxxxxxx
Betreff: [open-measured-data-wg] Requirements Engineering Document
Hi all
as stated in the steering committee meeting today, I prepared an update of the Requirements Document (attached) It also serves as input for the telco tomorrow - the main discussion point is do we have ONE backlog for the whole openmdm and several filters (via
labels/tags) and boards for the different projects (our recommendation) or do we need to have several projects.
Feedback welcome.
Since questions popped up regarding the Rich Client and web project, I can give a quick summary about the Rich Client
Last week we had a sprint review meeting together with Gigatronik at their office in Stuttgart - 2nd implementation sprint for the Rich Client:
- we are working on the navigator (explorer) component, including components needed for this (e.g. the headless Dataprovider component). We are making good progress in implementing the navigator concept as presented earlier.
- we still need to submit officially the initial contribution, but before being able to do so we need to clarify the copyright statements in the header of the files. The OEMs had some discussion about it and as soon we have the final information we will submit
the code.
- we are currently stubbing the MDM API resp. our best guess how the API will/should be. It is crucial that we are able to get the API of at least the access of tests very soon.
- the implemenetation work gives a good feel on how the architecture behaves at least down to the MDM connector layer. Since there are at least two components involved, we get some impressions about the interaction between components.
- in the discussion with Gigatronic, it was also recognized, that quite some existing elements, like search drivers (Suchtreiber) can be reused with the existing architecture, but not as components but behind the MDM API (because they make extensive use of
Corba).
Another result of the last sprint review was the recognition, that we are not sure, who isresponsible to provide and implement the MDM connector layer. It became obvious that working in horizontal layers (client, MDM API etc.) makes it difficult to provide
working software from end to end. This was pointed out in the Requirements document earlier and we strongly suggest to order functionality and let this build through all layers.
The next sprint review will be around May 4th - everybody interested is invited to attend the review meeting. The detailled progress and the planned scope for Milestone 1 can be seen here:
https://openmdm.atlassian.net/secure/RapidBoard.jspa?rapidView=52&selectedIssue=OMDM-51&quickFilter=122
(I have yet to update bugzilla with the final image of sprint 2 and create the issue for sprint 3 - will do that tomorrow).
Best regards
Sibylle
|
