FYI. It summarizes what we reviewed during our follow-up confcall yesterday. What is specific to our WP is the initial selection of assets (and therefore, the assignment of people responsible to start working in definition of entries in the FI-WARE backlog.
This initial selection was agreed as follows:
* Publish/Subscribe Broker GE: here we intend to develop two different reference implementations, one based on the asset from TI and another one based on the asset from Orange (unless they agree to join developments at some point). They should coordinate the creation of entries in the FI-WARE backlog for this GE, under leadership of TI (Boris)
* Complex Event Processing GE: we intend to develop a reference implementation based on the asset from IBM. Responsible: Guy
* BigData Analysis GE: we intend to develop a reference implementation based on the asset from Telefonica I+D. Responsible: Juanjo (indeed, another person will lead this who will be incorporated during August)
* Multimedia analysis GE: we intend to develop a reference implementation based on the asset from Siemens. Responsible: Peter
* Meta-data preprocessing GE: we intend to develop a reference implementation based on the asset from Siemens. Responsible: Peter
* Query Access GE: we intend to develop a reference implementation based on the asset from Siemens. Responsible: Peter. See notes below.
* Localization Platform GE (SLP component): we intend to develop a reference implementation based on the asset from Thales. Responsible: Remi. See notes below
* Semantic Annotation GE: we intend to develop a reference implementation based on the asset from TI. Responsible: Boris
* Semantic Application Support GE: we intend to develop a reference implementation based on the asset from ATOS. Responsible: Tomás ?
A very IMPORTANT point: entries in the backlog should not describe what the assets adopted as baseline already provide, but what must, should, could be developed in those assets (see MoSCoW priority field in the attached template for FI-WARE backlog entries). Remember that entries in the backlog are about "work to be done".
The second release of the FI-WARE High-level Description (Product Vision) should include a dedicated section per GE elaborating on the asset selected as baseline, which mostly will contain links to existing documentation which explains what the asset already provides today (user's/programmers guide, etc)
Notes:
* We have to schedule a number of confcalls during August to discuss on how the Query Access GE relates to query functions provided by the Publish/Subscribe Broker GE. TI, Siemens, Orange and TID should at least be involved in these confcalls, others members of the WP team are welcome to join. Siemens will be responsible to schedule these confcalls.
* We have to schedule a number of confcalls during August to discuss on how extend the SLP component of the Localization Platform GE as to incorporate the kind of functions proposed by TI (see question marks section - points still under discussion). TI, Thales and TID should at least be involved in these confcalls, others members of the WP team are welcome to join. TI will be responsible to schedule these confcalls. In addition, Boris has to write a post summarizing TI's proposal prior to these confcalls.
-------- Original Message --------
Subject: VERY IMPORTANT: Coordination of FI-WARE backlog related activities
Date: Thu, 28 Jul 2011 03:24:44 +0200
From: Juanjo Hierro <jhierro at tid.es><mailto:jhierro at tid.es>
To: fiware-wpl at lists.fi-ware.eu<mailto:fiware-wpl at lists.fi-ware.eu> <fiware-wpl at lists.fi-ware.eu><mailto:fiware-wpl at lists.fi-ware.eu>, fiware-wpa at lists.fi-ware.eu<mailto:fiware-wpa at lists.fi-ware.eu> <fiware-wpa at lists.fi-ware.eu><mailto:fiware-wpa at lists.fi-ware.eu>
Hi all,
Once we have dealt with the FI-WARE High-level Description (Product Vision) we have to start working in three major tasks on which we should concentrate our efforts until our plenary meeting in Turin:
1. Launch of activities dealing with final decision on assets and the creation of the FI-WARE backlog
2. Management of relationship with FI-PPP UC projects
3. Launch of activities dealing with development of contents of the FI-WARE website (setup of the public Wiki and start of activities in blogs)
This email elaborates on the first two points. We will review this in the confcall we have scheduled for July 28, 11:30am
Cheers,
-- Juanjo
1. Launch of activities dealing with final decision on assets and the creation of the FI-WARE backlog
At this point, I assume that you already understand the basis of how we plan to use Agile in our project. It summary, we will use it for managing the FI-WARE requirements, which will take the form of entries in what we refer as the FI-WARE backlog. In any case, please review the presentation I made during our kick-off meeting in May:
https://forge.fi-ware.eu/docman/view.php/7/37/FI-WARE+agile+Intro+vfinal.pptx
Following is the list of steps and considerations to take into account when launching the activities dealing with final decision on assets and the creation of the FI-WARE backlog:
* The first step we have to deal with has to do with closing the decision on the assets we will adopt as baseline for the reference implementation of each of the GEs. For this, every WP will have to come with a first proposal by August 31st on what asset, from what project+partner, will be adopted as baseline for the reference implementation of each of the GEs in the corresponding chapter. The different WP/chapter teams have to start this exercise now. It may not be feasible to close the mapping of assets for each of the GEs identified in a given chapter. This may be particularly the case for assets related to GEs for which there are still may points under discussion. It may also happen that we have identified assets for some of the components of a GE but not all. But at least we should have a relatively mature list of assets identified for the main GEs in each chapter by August 31st. This represents a first action point on WPLs and WPAs.
* Then we have to start to populate the FI-WARE backlog as soon as the asset(s) for a given GE have been identified.
* The fields for entries in the FI-PPP backlog (which includes the Fi-WARE backlog) have already been defined and correspond to the ones described in the attached template (spreadsheet). Note that entries in the FI-PPP backlog will not comprise just features/user-stories linked to FI-WARE GEs but to other platform enablers which may happen to be common to several applications while still domain-specific. If you have any question/doubt regarding semantics of any field in the template, please let Thomas or me know.
* Regarding tools to create, maintain and manage requests on entries of the FI-PPP backlog, the following has been agreed:
* The FI-PPP will use Agilefant in order to perform the overall management of entries in backlogs. The FI-PPP will go for a configuration where we will define multiple backlogs in Agilefant. One per GE in each chapter, one covering entries for all the still uncategorized platform enablers, one (at least) for other platform enablers that are common but domain-specific (therefore out of the scope of FI-WARE) and one per each of the UC projects that wish to use Agilefant to manage their own application backlog. This with the ability to transfer entries from one backlog to another.
* However, Agilefant is pretty simple, and entries of a backlog in Agilefant cannot be flexibly configured as to contain all of the fields we have defined for the FI-PPP backlog template (attached). Therefore, the description field of each entry in an Agilefant backlog will have to include an URL link to a page on a Wiki (based on Wikimedia) where all fields for that entry, as defined in the attached spreadsheet, can be fully specified. Regarding entries linked to the FI-WARE backlogs, and probably also for entries linked to platform enablers in general, this wiki will be provided by FI-WARE. Thomas or me will provide concrete instructions on how to create backlog entries in the Wiki and in Agilefant before Thursday next week. In the meantime, you may wish to start working on entries, just using spreadsheets following the attached template.
* FI-WARE will put in place some system to manage the lifecycle of requests to create new entries in the FI-WARE backlogs or modify existing ones by third parties. This tool should not be offered just to UC projects but to the general public, because we have to be open to other communities. Most probably this tool will be the tracker system in FusionForge but we are still analyzing whether it could be managed directly through Agilefant, defining an intermediate backlog about "request for platform enablers" where request for entries formulated by UC projects would be created and only transferred to the FI-WARE backlogs when agreed with FI-WARE. However, the issue of dealing with other third parties/communities may lead to the need to put a more formal system such as tracker. We will inform before Thursday next week about what tool has been decided and what will be the procedures to follow.
* One point that was already understood and agreed during the FI-PPP AB is that requirements from end-users on applications to be developed by UC projects are different from requirements on FI-WARE (on platform enablers in general). During investigation of a end-user requirement "X" (no matter if it is a Theme, an EPIC or an user-story), a given UC project may conclude that it needs to rely on a platform that support a number of features "a", "b", and "c" plus develop an application implementing functionalities "M", "N", "O" on top of that platform. These "a", "b" and "c" features should translate into entries initially linked to the "platform enablers" backlog. Some of them will finally be addressed in FI-WARE so therefore will be transferred to the FI-WARE backlog. Whether we will manage this transference directly on Agilefant or through a tracker system, is something to decide. Nevertheless, note that specification of "X", "M", "N", "O" will not be part of the FI-WARE backlog. The level of concreteness is also different: "X" and even "M", "N" and "O" may be very concrete, with a quite detailed specification. However, "a", "b" and "c", at the time they are formulated by a UC project, may be just in the form of a "theme" or "epic", according to Agile terminology.
* At a given point in time, features "a", "b" and "c" will be submitted to FI-WARE for consideration. FI-WARE will then determine whether the feature is considered inside the scope of FI-WARE and what priority is finally assigned. This decision will most probably imply several interactions with the UC projects that have identified the features. As mentioned before, we will come in the coming days with a concrete proposal on tools and procedures adopted for managing this process.
* During this process, UC projects may additionally require further clarifications about what we intend to deliver in a given chapter, for a given GE. In other words, they may ask for clarifications on parts of the FI-WARE High-level Description (Product Vision). This should be driven in a formal manner, to avoid getting into chaos. Therefore, a specific tracker system associated to the Product Vision will be put in place for UC projects (and the general public) to formulate their questions. Explanations given to resolve tickets should lead to creation/update of contents in a FAQ Wiki we should start creating.
* Parallel to UC projects running the process described above, FI-WARE should, own its own, work in defining entries for the FI-WARE backlogs. Whether they will be still generic ("themes" or "epics") or already detailed as to be ready for implementation will depend on how clear we have things regarding the GEs in each of the chapters. There are three different types of entries that FI-WARE chapter teams should be able to generate from now until the Turing meeting (as a first milestone)
* Entries related to new functional or non-functional features we need to implement in an asset adopted as baseline for the development of the reference implementation of a given GE (or part of it), in order to cover the gap between what that given asset supports at the time it is contributed by a given partner to the project and what it should support to actually become (part of) a reference implementation of the given GE.
* Entries related to new functional or non-functional features we wish to implement in an asset adopted as baseline for the development of the reference implementation of a given GE (or part of it), in order to further evolve it and therefore, evolve the corresponding GE (since GEs specifications may evolve over time and offer different functionality in subsequent releases of FI-WARE)
* Entries related to integration of assets, in those cases where an asset has to be combined with other assets to build the reference implementation of a given GE. Note that these entries are different than those ones related to implementing interfaces/protocols, etc in an asset implementing (part of) a GE, in order to support integration with another GE, because interfaces/protocols enabling integration of GEs should be part of their open specifications and, therefore, should be considered a particular case of points 1. or 2.
* Note, that regarding a given feature request, there will be essentially five scenarios:
* The feature applies to some of the GEs we have already identified in the FI-WARE High-level Description, and for which an asset has already been identified (therefore we have already identified entries for it in the FI-WARE backlog)
* The feature applies to some of the GEs we have already identified in the FI-WARE High-level Description, but for which an asset hasn't already been identified (it is a gap we have already identified that none of the partners in FI-WARE is able to fill contributing an asset)
* The feature applies to some GE we hadn't identified initially in FI-WARE (in the FI-WARE High-level Description) but we agree to incorporate it in the roadmap, despite no partner has an asset that can be contributed as baseline for development of a reference implementation
* The feature applies to some GE we hadn't identified initially in FI-WARE (in the FI-WARE High-level Description) but we agree to incorporate it, and there is a partner that has an asset that may be contributed as baseline for development of a reference implementation
* The feature applies to some enabler we hadn't identified initially in FI-WARE and we don't agree to accept it as GE since it is a common, yet domain-specific, platform enabler, but not a GE
The first case will lead to negotiation of priorities between us and the UC project. The second and third case will lead to requirements that we should take into account in our Open Calls. The fourth case require careful consideration because we won't be able to change the assignment of resources to a given partner. We need to calibrate whether the partner can adjust its efforts to deal with more GEs that the originally expected (maybe addressing less new functionality in each) or we should finally lead to definition of requirements for an Open Call.
* Despite the most active UC projects may start creating some initial requests for entries in the FI-WARE backlog during August, I do not expect so much activity, so keep going on your own, generating entries in the FI-WARE backlogs based on the principles of the previous point. During September negotiations with UC projects should become more intense. We indeed agreed with the UC projects to have a milestone by end of September in which we should already have produced a number of entries in the FI-WARE backlogs on our own, and they should have been produced some requests for entries in our FI-WARE backlogs. A period of negotiation/consolidation is then planned, which should end by end of November, with the first official release of the FI-WARE backlog to be considered for the first release of FI-WARE and also a clear definition of what we are going to request in the first Open Call of FI-WARE
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20110728/90f209c2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Backlog entries description v0 1 11-07-12.xls
Type: application/vnd.ms-excel
Size: 52224 bytes
Desc: not available
URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20110728/90f209c2/attachment.xls>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jhierro.vcf
Type: text/x-vcard
Size: 429 bytes
Desc: not available
URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20110728/90f209c2/attachment.vcf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy