[Fiware-iot] FW: IoT Backlog: actions to do

[t.elsaleh at surrey.ac.uk]

Hello Fermin, (Thierry),

In relation to the point by Thierry about:

"For release 3 also I've asked to create name for the instance when we have several instances for the same GE. Typically for Backend Conf Management we should have common features for Orion and IoT Discovery and some should be specific so for the specific ones, you just have now to chose the specific instance. It will be also useful for the workitems and the course to trace that we are preparing content for a specific instance.
This part is more critical for Protocol Adapter because from one protocol to another one, of course we will have specific features."

We had a similar discussion about this a few months ago about "functional and non-functional features". I guess the common features will lie with the functional features, meaning the ones related to implementation of the NGSI spec. I believe these are (at least):

·         Standard operations

·         Convenience operations

·         Associations

·         JSON support

Now I am not sure about the next step. There are some features you have defined in release 2 that relate to the above features, but under "ContextBroker".  The conflict with what Thierry wants is that the GE instance is used in the naming of the feature. Even if we don't chose an GE Implementation in the tracker, the GE implementation is still referred to in the name (or "summary") itself. Does this mean we need to rename some or all the features we have described in Release 2, so that all features come under:

"FIWARE.Feature.IoT.Backend.ConfManager..."?

Also, how do we differentiate when it comes to the progress (workflow state) for each common feature (or it's work items) of a GEi? For example, there some that might have been completed for one GEi, and another has not yet been completed.


Best regards,
Tarek




From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of thierry.nagellen at orange.com
Sent: 11 September 2013 15:08
To: fiware-iot at lists.fi-ware.eu
Subject: [Fiware-iot] IoT Backlog: actions to do

Hi all,

Based on the exchange with Manuel, you can find in this new version of the spreadsheet a first sheet with the current architecture of IoT chapter and how we will use the backlog for release 3. So some GE will disappear because we will never use them (Advanced connectivity) but we have to check the related features/epics and workitems to transfer them, if relevant, in another GE. You can find in RED who has to check which "old" GE and in which GE the existing features should go.

We have to provide for October the new deliverable "Backlog" so we have also to clean everything and sometimes also to update the content.

Basically, everything related to R2.3 should be closed because we delivered it in July, and what we could not deliver should now be scheduled (or under execution or closed) in Release 3 In each specific sheet per GE, you have to scroll down to find the list of what is not very well distributed (Release 1, Release 2...), so please take time to update the last topics. We have not so many things to do, thanks to some of you who did a good work before.

For release 3 also I've asked to create name for the instance when we have several instances for the same GE. Typically for Backend Conf Management we should have common features for Orion and IoT Discovery and some should be specific so for the specific ones, you just have now to chose the specific instance. It will be also useful for the workitems and the course to trace that we are preparing content for a specific instance.
This part is more critical for Protocol Adapter because from one protocol to another one, of course we will have specific features.

I have a new check point with Manuel in 2 weeks. The first urgent action point is cleaning the old GEs and if relevant and pushing the features to existing GEs. Second urgent action point: clean old backlogs and populate R3 backlog (consistency with Technical Roadmap).

Thanks for your support.

BR
Thierry

PS: Backend Device Management requests a strong effort because nothing is aligned with IDAS as far as I can check.

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20130918/e3a5bce8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FIWARE.backlog.iot.report.20130909-1531-TNA.xlsx
Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Size: 246492 bytes
Desc: FIWARE.backlog.iot.report.20130909-1531-TNA.xlsx
URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20130918/e3a5bce8/attachment.xlsx>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT00001.txt
URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20130918/e3a5bce8/attachment.txt>