From lorant.farkas at nsn.com Mon Aug 8 08:57:58 2011 From: lorant.farkas at nsn.com (Farkas, Lorant (NSN - HU/Budapest)) Date: Mon, 8 Aug 2011 09:57:58 +0300 Subject: [Fiware-wpa] FW: [Fiware-wpl] About the recular (weekly) status calls. Message-ID: <93D28BDF64839C468B848D14227151A2021777DD@FIESEXC014.nsn-intra.net> -----Original Message----- From: ext thierry.nagellen at orange-ftgroup.com [mailto:thierry.nagellen at orange-ftgroup.com] Sent: Monday, August 08, 2011 8:32 AM To: Farkas, Lorant (NSN - HU/Budapest) Subject: TR: [Fiware-wpl] About the recular (weekly) status calls. -----Message d'origine----- De?: fiware-wpl-bounces at lists.fi-ware.eu [mailto:fiware-wpl-bounces at lists.fi-ware.eu] De la part de Bohnert, Thomas Michael Envoy??: jeudi 4 ao?t 2011 20:43 ??: fiware-wpl at lists.fi-ware.eu Objet?: [Fiware-wpl] About the recular (weekly) status calls. Dear all, since there are no particular issue we will skip the coming Friday/Monday calls. Instead you'll soon receive an invitation for a joint call in which we plan to show you a demo on how FI-WARE will handle requests (technical support + backlog entries) via the FORGE tracker system. Right now we are still in the evaluation phase of a proper process and the required tooling via FORGE (combination of tracker + tasks). My hope is that we can settle this issue by next Wednesday but I will keep you posted. As a final remark and in response to some requests be told that the D2.2 deliverable is just receiving a final touch via Juanjo (which is on vacations as you know so let us grant some extra grace period). Having said this I wish a nice weekend. Best - Thomas Thomas Michael Bohnert Technical Director SAP (Schweiz) AG, Kreuzplatz 20, 8008 Zurich, Switzerland T +41 58 871 7801, M +41 79 7018941, F +41 58 871 7812 email: thomas.michael.bohnert at sap.com web: tmb.nginet.de, twitter: tmbohnert Please consider the impact on the environment before printing this e-mail. _______________________________________________ Fiware-wpl mailing list Fiware-wpl at lists.fi-ware.eu http://lists.fi-ware.eu/listinfo/fiware-wpl From pascal.bisson at thalesgroup.com Tue Aug 9 14:38:14 2011 From: pascal.bisson at thalesgroup.com (BISSON Pascal) Date: Tue, 9 Aug 2011 14:38:14 +0200 Subject: [Fiware-wpa] [Fiware-wpl] Fwd: Re: [FI-PPP AB] SafeCity initial feedback on the High Level Description document In-Reply-To: <4E30C430.7090606@tid.es> References: <4E30C430.7090606@tid.es> Message-ID: <10576_1312893495_4E412A37_10576_12651_1_CBBCD6C304123F4AB23FAAE3055C8C0E020605BD31A6@THSONEA01CMS04P.one.grp> Dear Juanjo, Back to you on the topic and apologize for the delay. Find attached to this email complementary answer from WP8 to SafeCity UC project regarding feedback they provided us as per presentation of Security chapter at last AB Meeting. Best Regards, Pascal De : fiware-wpl-bounces at lists.fi-ware.eu [mailto:fiware-wpl-bounces at lists.fi-ware.eu] De la part de Juanjo Hierro Envoy? : jeudi 28 juillet 2011 04:07 ? : fiware-wpl at lists.fi-ware.eu; fiware-wpa at lists.fi-ware.eu Objet : [Fiware-wpl] Fwd: Re: [FI-PPP AB] SafeCity initial feedback on the High Level Description document Dear colleagues, Please find enclosed, if you read bottom-up: * A message sent by the Safecity UC project providing initial feedback on our FI-WARE High-level Description draft * My initial response to their comments WPLs/WPAs of the Cloud, Data/Context Management, I2ND and Security Chapters are entitled to: * Review the comments from Safecity (see attached document) * Review my response and confirm they are Ok or comment on them I believe it is worth answering quickly to this first set of comments to demostrate responsiveness to UC projects inputs. Please try to provide your feedback asap, tomorrow noon at the latest. Thanks and best regards, -- Juanjo -------- Original Message -------- Subject: Re: [FI-PPP AB] SafeCity initial feedback on the High Level Description document Date: Wed, 27 Jul 2011 06:07:24 +0200 From: Juanjo Hierro To: ab at fi-ppp.eu CC: safecity-ptc at hi-research.eu Hi Peretz and Roberto, Thanks very much for your input. We promise to come back with a more detailed response later once we analyze your input document together with experts from the Cloud, Data/Context Management, I2ND and Security teams. However, let me share with you a very quick response to your comments just on my own (therefore you cannot take it as definitive): 1. On the issue about private Clouds: There is nothing in the definition of FI-WARE that prevents you to setup your own private Cloud or, more specifically, your own virtual infrastructure on the Cloud where your applications are only accessible through private, dedicated, connections. Remember that a fundamental concept in FI-WARE is that there is not "single universal FI-WARE Instance" as such. A trial in phase 2 may setup its own dedicated FI-WARE instance, although it's true that several trials may agree to share a FI-WARE Instance. As a security measure, for example, you may decide to setup your own FI-WARE Cloud Hosting Instance were you plan to host just your applications. You may also, share a FI-WARE Cloud Hosting Instance with other trials, but configure your IaaS virtual infrastructure so that your applications hosted there are only accessible through dedicated VPN connections, for example. It is up to a trial in phase 2 to decide what is the FI-WARE Instance(s) it is going to rely on and, as a consequence, who is going to play the roles of FI-WARE Instance Providers in the trial. In addition, it is up to the FI-WARE Instance Provider to determine how a given FI-WARE Instance is setup and configured. Besides, it is up to the Application Provider to decide what sort of virtual infrastructure it wants to setup to host its applications. As an example, you may setup in your trial a FI-WARE Instance that includes Cloud Hosting capabilities and allows to setup virtual hosting infrastructures that host applications only available through VPNs or even more private/dedicated connections. All concepts regarding FI-WARE Instances, FI-WARE Instance Providers, etc were defined in the "FI-WARE Overall Vision" chapter. Nevertheless, your comment raise the fact that some of the explanations we have provided are not that clear and that is what really matters (like when you compare Quality of Experience vs Quality of Service :-) We were finishing integration of the official deliverable and expecting to get it done by today, a little bit late compared to what it was expected, but I believe that is worth trying to introduce the necessary changes that may clarify this matter. Of course, we will not be able to solve all the questions. We plan to continuously enhance the description, as comments like yours arrive and are handled. I take the opportunity to clarify that the kind of advanced features we described in the Cloud Hosting and the I2ND chapters related to dynamic management of network resources are mostly oriented to go beyond existing Cloud hosting services in order to take the most of available network resources, being able to use spare network resources (capacity) when they exist. Currently, you can setup a VPN to your application hosted in the Cloud, but your connection has a established bandwidth and doesn't change so dynamically. As a consequence, if your application is not using the whole bandwith during a certain period of time, another application you may own cannot use the spare bandwith and increase its VPN bandwidth during the period (both VPNs may have been setup through the same physical, private communication line). Essentially, we are trying to have more dynamic solutions here and translate the same kind of concepts used in current Clouds regarding management of computing resources to network resources. But this is something that goes beyond your most critical need, which would be that of creating private Clouds or, more specifically, Clouds accessible through virtual private connections. There, I can assure you that you would get your requirement fulfilled as explained above. I believe it was inherent in the description of the Cloud Hosting chapter since we describe there that VPNs, etc may be part of the IaaS virtual infrastructure you may define for your application (this is referred as the IaaS Service Manifest). However, it seems like we just need to state that more explicitly because apparently you derived that setting up private Clouds where applications are accessible through dedicated virtual private connections was not possible, and that is wrong. 2. On the issue about multi-media analysis: As you explain in your document, there are multiple ways to solve an scenario like the one you describe. But precisely that is the point. FI-WARE is a general purpose platform, therefore, it doesn't dictate neither how a particular FI-WARE Instance has to be setup for a particular trial, nor how applications will be designed to use that FI-WARE Instance. We follow here a fundamental principle in design of general-purpose platforms: if you take many decisions on behalf of the application designer and provider, you will end up taking the worst ones. The two possible solutions you describe for your scenario can be programmend to run on FI-WARE Instances. Both. It is up to you to decide what is the one that better suites your needs. I have to say that you mention in your document that while the two solutions are valid, the second one would be safer (although less efficient). I have to comment that it really depends on how you decide to setup your FI-WARE Instance: * You may decide that your application will be hosted in a dedicated FI-WARE Instance. Therefore, there is no risk that third-party applications can access information gathered by your application. As such, there is nothing that prevents you to set up your own FI-WARE Instance hosting the multimedia analysis GE, together with the DB of faces, and your own application in a safe way. Again, the point is that this would be up to you. Note that, in addition, you would be able to setup the Security Monitoring GE in that FI-WARE instance, which may help you to monitor and handle any security attack that you may receive. But this would go in addition. * A slight variation of the previous configuration would be that of keeping your application in a shared FI-WARE Instance supporting Cloud Hosting capabilities, then configuring your virtual hosting infrastructure so that resources (computing, storage, network) are not shared with those from other applications (in other words, you setup your own VDC, and establish a number of RA-SLOs establishing restrictions such as your software/data is never going to run on a server node where third party applications may be co-located to run). Of course, this option is more risky than the previous, because the more isolated your resources are, the safer. But should be safe anyway. And again, the point is that this would be up to you. Same comment regarding benefits of the Security monitoring capabilities would apply here. The second solution would probably be the best one if you decide to run the multimedia analysis GE in a FI-WARE Instance and you don't want to setup restriction on whether your application can be reallocated together with those from others. In this solution, you have decided to adopt a design decision that allows to take advantage of sharing resources in a FI-WARE Instance, but still be safe. Again, it is up to you to go for this option and FI-WARE should not preclude you to do that. 3. Bottom-line: There are many decisions that you should leave on the hands of application provider or the application developer when you design a general-purpose platform. Otherwise, you are doing things wrong and you are going to fail. We have tried to follow this principle as much as possible, not only in the design of GEs and the Reference Architecture of each of the FI-WARE chapters but also introducing the concept of FI-WARE Instances that can be federated (or not, depends on the decision of a particular FI-WARE Instance Provider). That's why there is no concept of single, universal FI-WARE Instance (like google.com) where all Future Internet applications would be hosted. The ability to create dedicated FI-WARE Instances, and even use multiple FI-WARE chapter instances, where some might be shared while others won't in a kind of hybrid solution, brings the greatest flexibility to be able to cope with the needs of almost all applications. Needs that we cannot predict in advance. We may have decided that all data/context elements interchanged through the Publish/Subscribe Broker GE or processed through the Complex Event Processing GE should comply to a particular XML document format we may dictate a standard in FI-WARE. That had made our lifes easier at the implementation phase as you may imagine. But this had been a wrong decission because many applications wish to be free to decide what concrete format to use. Therefore, we decided that data/context elements can follow any format a given application may decide to adopt and that the Data/Context Management GEs should be able to cope with any of them, without this meaning that you pay a performance penalty. This is the kind of design decisions we believe we also have to adopt at the level of GEs, in addition to the principles about FI-WARE Instances and federation of FI-WARE Instances. BTW, I'm almost positive that the Complex Event Processing or the Publish/Subscribe Broker GEs are some of the GEs that would be rather useful for the kind of applications you need to design in Safecity (and I'm almost positive that they will be useful for most of the UC projects because they are truly generic). I guess you will have to deal with events and the need to process them or broadcast them to target applications or users. I would like to learn why you find the multimedia analysis GE useful but not these other two. UC projects should provide a rationale why they plan to use a specific enabler in those cases there is a GE provided by FI-WARE that already serves their needs. Otherwise, this would go against the spirit of the FI-PPP program. Best regards, -- Juanjo On 26/07/11 11:01, Peretz Gurel wrote: Dear FI-PPP AB partners, The attached short document is an initial feedback (at a high level) by SafeCity about the FI-WARE High Level Description document that was presented during the last FI-PPP AB meeting on July 11-12 in Madrid. We have already raised these concerns during the meeting. After the FI-PPP AB meeting we met with one of SafeCity end users (Madrid Police) and they have confirmed the concerns we had. The attached document is not replacing SafeCity requirements for Generic Enablers that will be provided in the required backlog format in due time. However, it is very important for us to understand the direction that FI-WARE is taking, particularly in regard to communications and security, as this has direct impact on SafeCity. Best regards, Peretz Gurel and Roberto Gavazzi SafeCity ________________________________ 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 ________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: WP8 Answer to Safecity on Securityconcerns-THA.doc Type: application/msword Size: 30208 bytes Desc: WP8 Answer to Safecity on Securityconcerns-THA.doc URL: From jhierro at tid.es Wed Aug 10 18:06:46 2011 From: jhierro at tid.es (Juanjo Hierro) Date: Wed, 10 Aug 2011 18:06:46 +0200 Subject: [Fiware-wpa] Hints and examples about entries for the FI-WARE backlog Message-ID: <4E42AC96.4090808@tid.es> Hi all, One of the action points that were agreed had to do with providing some detail examples of what the entries for an EPIC and a User Story (or Story, for short) in the FI-WARE backlog. Please find enclosed a spreadsheet where I have included two separate sheets describing: * The template to be used for entries in the backlog. This is an update of the one you already had where I have addressed some points that were unresolved or required some clarifications. I have found also the need to add a new field (Detailed Status). * An example of an EPIC * An example of an User Story The examples are not "official". I just elaborate them on my own (although the EPIC was based on an initial proposal made by Fernando L?pez from TID). They just pretend to serve as example of the level of "granularity" associated to an EPIC compared to a User Story in an Agile backlog. What can be considered at the level of "user story" according to Agile ? Well ... there is no a black or white frontier between things nor a mathematical formula you can apply and then determine when something should be considered an EPIC rather than a User Story. As mentioned in the presentation on Agile we made at the FI-WARE kick-off meeting, User Stories have to comply with "INVEST" properties which mean they should be "Independent, Negotiable, Valuable, Estimatable, Small and Testable". Some resources that may be helpful in finding out what we mean by INVEST properties can be found at [1], [2] and even [3] but in general: * Bear in mind that User Stories have to be something "Small" as to be affordable in a Sprint. Sprints should be of a maximum of two months in FI-WARE, unitary tests included (I'm even seriously considering to make them shorter, of about one month, therefore closer to the spirit of Agile). In general, something that would go beyond one single sprint should be considered an EPIC. * It should be also detailed enough so that you can say "I understand what I want well enough that I could think how a test for it could be designed." This is what means it should be "Testable". * User stories also should be "Estimatable" meaning that it should contain enough information enabling a developer to make a rough estimation of how much it would take to develop it (and shouldn't go beyond the time limits of a sprint :-). In our case, we are supposed to bring on the table tangible assets per GEs. Therefore, "Estimatable" means that the corresponding development team should be able to answer you how much would it take to implement the user story you are providing. Therefore, you can make a simple test: take one of your entries, go to the teams, and ask them "how much effort (roughly) would it take ?" ... if they give you answers like "unless you give me more details, it's simply impossible ... what you provide is too vague", then you don't have a user story for sure but probably an EPIC. * They don't need to have ALL the details nor have everything closed. There should be details that may be worked out while developing it (again, bear the duration of sprints in mind, i.e., maximum between 1-2 months). You shouldn't enter into that level of detail at which you are probably wasting time and unnecessarily delaying development. But good developers are able to provide accurate estimations without knowing all details. This is why they should be "Negotiable" (detailed description may vary/be-refined over time even during development but without this implying a relevant deviation from the original estimation) "Independent" and "Valuable" are also relevant but I guess there may be many EPICs that would also cope with those properties. That's why I would make emphasis on the previous points. Some references (but you may find much more, just search for INVEST properties for User Stories in Agile or discussions on EPICs vs User Stories): [1] - http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ [2] - http://agilesoftwaredevelopment.com/blog/vaibhav/good-user-story-invest [3] - http://en.wikipedia.org/wiki/INVEST_%28mnemonic%29 Themes, are much more high-level or abstract than EPICs. The frontier between Themes and EPICs is also fuzzy, but is not that relevant as the frontier between EPICs and User Stories because this last frontier is what matters to know when you may stop refining. Indeed, we may adopt a convention regarding what to call Theme and what to call an EPIC. For example, we may map the notion of "Theme" to the notion of Generic Enabler in FI-WARE. Therefore, there would be a Theme linked to the "Publish/Subscribe Broker GE" which establishes as a goal that "Applications should be able to publish data and subscribe to data of their interest". The "target usage" text in the FI-WARE Product Vision / High-level Description deliverable for a given GE may well work as the content for the description of the corresponding Theme. Given said this, don't feel too frustrated if you are not able to identify too many User Stories in a first shot. I believe that we should feel confident if we end August with a complete and comprehensive set of EPICs per Generic Enabler. Then, during September, we may focus in trying to derive a number of User Stories from those EPICs that will enable to plan the first sprint in FI-WARE (which we should be able to start by early October) Please remind that we are supposed to rely the development of the reference implementation of FI-WARE GEs in a number of assets. We should concentrate on what will map into development tasks on those assets (so that they can integrate with other assets, comply with the final standard open royalty-free specification of interfaces we want them to provide, incorporate any function that we agree a target reference implementation must/should offer but our asset still do not offer). Don't focus on describing things already supported by an asset. Remember: backlog = work to be done. Review my previous mails on the matter if you have any doubt. Please share this with your teams. And don't hesitate to bring on the table any doubt, concern or comment you may have. Let's share them and share the answer. Last but not least, please send back two separate responses: a) first to Thomas and me, a response confirming that you have received this email b) later, to the fiware-wpl and fiware-wpa, an email confirming that you have read it and you feel like there is no essential obstacle for moving forward. If you have any initial questions/doubts/comments you would like to share at the time you send the response, please do so. Best regards, -- Juanjo ________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: Backlog entries examples by TID 11-08-09.xls Type: application/vnd.ms-excel Size: 70656 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: jhierro.vcf Type: text/x-vcard Size: 429 bytes Desc: not available URL: From lorant.farkas at nsn.com Thu Aug 11 12:36:58 2011 From: lorant.farkas at nsn.com (Farkas, Lorant (NSN - HU/Budapest)) Date: Thu, 11 Aug 2011 13:36:58 +0300 Subject: [Fiware-wpa] Hints and examples about entries for the FI-WARE backlog In-Reply-To: <4E42AC96.4090808@tid.es> References: <4E42AC96.4090808@tid.es> Message-ID: <93D28BDF64839C468B848D14227151A2021C1337@FIESEXC014.nsn-intra.net> Dear All, Your e-mail was received and read through, from IoT SE side I think there is no essential obstacle for moving forward (someone please forward to the WPL list as I am not allowed to send e-mails to that list). Br, Lorant ________________________________ From: fiware-wpa-bounces at lists.fi-ware.eu [mailto:fiware-wpa-bounces at lists.fi-ware.eu] On Behalf Of ext Juanjo Hierro Sent: Wednesday, August 10, 2011 6:07 PM To: fiware-wpl at lists.fi-ware.eu; fiware-wpa at lists.fi-ware.eu Subject: [Fiware-wpa] Hints and examples about entries for the FI-WARE backlog Hi all, One of the action points that were agreed had to do with providing some detail examples of what the entries for an EPIC and a User Story (or Story, for short) in the FI-WARE backlog. Please find enclosed a spreadsheet where I have included two separate sheets describing: * The template to be used for entries in the backlog. This is an update of the one you already had where I have addressed some points that were unresolved or required some clarifications. I have found also the need to add a new field (Detailed Status). * An example of an EPIC * An example of an User Story The examples are not "official". I just elaborate them on my own (although the EPIC was based on an initial proposal made by Fernando L?pez from TID). They just pretend to serve as example of the level of "granularity" associated to an EPIC compared to a User Story in an Agile backlog. What can be considered at the level of "user story" according to Agile ? Well ... there is no a black or white frontier between things nor a mathematical formula you can apply and then determine when something should be considered an EPIC rather than a User Story. As mentioned in the presentation on Agile we made at the FI-WARE kick-off meeting, User Stories have to comply with "INVEST" properties which mean they should be "Independent, Negotiable, Valuable, Estimatable, Small and Testable". Some resources that may be helpful in finding out what we mean by INVEST properties can be found at [1], [2] and even [3] but in general: * Bear in mind that User Stories have to be something "Small" as to be affordable in a Sprint. Sprints should be of a maximum of two months in FI-WARE, unitary tests included (I'm even seriously considering to make them shorter, of about one month, therefore closer to the spirit of Agile). In general, something that would go beyond one single sprint should be considered an EPIC. * It should be also detailed enough so that you can say "I understand what I want well enough that I could think how a test for it could be designed." This is what means it should be "Testable". * User stories also should be "Estimatable" meaning that it should contain enough information enabling a developer to make a rough estimation of how much it would take to develop it (and shouldn't go beyond the time limits of a sprint :-). In our case, we are supposed to bring on the table tangible assets per GEs. Therefore, "Estimatable" means that the corresponding development team should be able to answer you how much would it take to implement the user story you are providing. Therefore, you can make a simple test: take one of your entries, go to the teams, and ask them "how much effort (roughly) would it take ?" ... if they give you answers like "unless you give me more details, it's simply impossible ... what you provide is too vague", then you don't have a user story for sure but probably an EPIC. * They don't need to have ALL the details nor have everything closed. There should be details that may be worked out while developing it (again, bear the duration of sprints in mind, i.e., maximum between 1-2 months). You shouldn't enter into that level of detail at which you are probably wasting time and unnecessarily delaying development. But good developers are able to provide accurate estimations without knowing all details. This is why they should be "Negotiable" (detailed description may vary/be-refined over time even during development but without this implying a relevant deviation from the original estimation) "Independent" and "Valuable" are also relevant but I guess there may be many EPICs that would also cope with those properties. That's why I would make emphasis on the previous points. Some references (but you may find much more, just search for INVEST properties for User Stories in Agile or discussions on EPICs vs User Stories): [1] - http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ [2] - http://agilesoftwaredevelopment.com/blog/vaibhav/good-user-story-invest [3] - http://en.wikipedia.org/wiki/INVEST_%28mnemonic%29 Themes, are much more high-level or abstract than EPICs. The frontier between Themes and EPICs is also fuzzy, but is not that relevant as the frontier between EPICs and User Stories because this last frontier is what matters to know when you may stop refining. Indeed, we may adopt a convention regarding what to call Theme and what to call an EPIC. For example, we may map the notion of "Theme" to the notion of Generic Enabler in FI-WARE. Therefore, there would be a Theme linked to the "Publish/Subscribe Broker GE" which establishes as a goal that "Applications should be able to publish data and subscribe to data of their interest". The "target usage" text in the FI-WARE Product Vision / High-level Description deliverable for a given GE may well work as the content for the description of the corresponding Theme. Given said this, don't feel too frustrated if you are not able to identify too many User Stories in a first shot. I believe that we should feel confident if we end August with a complete and comprehensive set of EPICs per Generic Enabler. Then, during September, we may focus in trying to derive a number of User Stories from those EPICs that will enable to plan the first sprint in FI-WARE (which we should be able to start by early October) Please remind that we are supposed to rely the development of the reference implementation of FI-WARE GEs in a number of assets. We should concentrate on what will map into development tasks on those assets (so that they can integrate with other assets, comply with the final standard open royalty-free specification of interfaces we want them to provide, incorporate any function that we agree a target reference implementation must/should offer but our asset still do not offer). Don't focus on describing things already supported by an asset. Remember: backlog = work to be done. Review my previous mails on the matter if you have any doubt. Please share this with your teams. And don't hesitate to bring on the table any doubt, concern or comment you may have. Let's share them and share the answer. Last but not least, please send back two separate responses: a) first to Thomas and me, a response confirming that you have received this email b) later, to the fiware-wpl and fiware-wpa, an email confirming that you have read it and you feel like there is no essential obstacle for moving forward. If you have any initial questions/doubts/comments you would like to share at the time you send the response, please do so. Best regards, -- Juanjo ________________________________ 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: From pierangelo.garino at telecomitalia.it Thu Aug 11 10:52:24 2011 From: pierangelo.garino at telecomitalia.it (Garino Pierangelo) Date: Thu, 11 Aug 2011 10:52:24 +0200 Subject: [Fiware-wpa] R: [Fiware-wpl] Hints and examples about entries for the FI-WARE backlog In-Reply-To: <4E42AC96.4090808@tid.es> References: <4E42AC96.4090808@tid.es> Message-ID: Hi Juanjo, I confirm there shouldn't be obstacles to proceed at the moment. In general there is some 'slowness' in providing the expected contributions due to the holiday period; however, as we planned it, I expect this will not affect the timing at least for the definition of assets. Maybe for backlog entries it could be slightly different, as not all of us had the opportunity to check guidelines and timings before going on holiday. I have an I2ND confcall next week, in case some issues concerning the activity, or doubts about the descriptions, raise I'll keep you (and all WPLs/WPAs) posted. BR Pier Da: fiware-wpl-bounces at lists.fi-ware.eu [mailto:fiware-wpl-bounces at lists.fi-ware.eu] Per conto di Juanjo Hierro Inviato: mercoled? 10 agosto 2011 18:07 A: fiware-wpl at lists.fi-ware.eu; fiware-wpa at lists.fi-ware.eu Oggetto: [Fiware-wpl] Hints and examples about entries for the FI-WARE backlog Hi all, One of the action points that were agreed had to do with providing some detail examples of what the entries for an EPIC and a User Story (or Story, for short) in the FI-WARE backlog. Please find enclosed a spreadsheet where I have included two separate sheets describing: * The template to be used for entries in the backlog. This is an update of the one you already had where I have addressed some points that were unresolved or required some clarifications. I have found also the need to add a new field (Detailed Status). * An example of an EPIC * An example of an User Story The examples are not "official". I just elaborate them on my own (although the EPIC was based on an initial proposal made by Fernando L?pez from TID). They just pretend to serve as example of the level of "granularity" associated to an EPIC compared to a User Story in an Agile backlog. What can be considered at the level of "user story" according to Agile ? Well ... there is no a black or white frontier between things nor a mathematical formula you can apply and then determine when something should be considered an EPIC rather than a User Story. As mentioned in the presentation on Agile we made at the FI-WARE kick-off meeting, User Stories have to comply with "INVEST" properties which mean they should be "Independent, Negotiable, Valuable, Estimatable, Small and Testable". Some resources that may be helpful in finding out what we mean by INVEST properties can be found at [1], [2] and even [3] but in general: * Bear in mind that User Stories have to be something "Small" as to be affordable in a Sprint. Sprints should be of a maximum of two months in FI-WARE, unitary tests included (I'm even seriously considering to make them shorter, of about one month, therefore closer to the spirit of Agile). In general, something that would go beyond one single sprint should be considered an EPIC. * It should be also detailed enough so that you can say "I understand what I want well enough that I could think how a test for it could be designed." This is what means it should be "Testable". * User stories also should be "Estimatable" meaning that it should contain enough information enabling a developer to make a rough estimation of how much it would take to develop it (and shouldn't go beyond the time limits of a sprint :-). In our case, we are supposed to bring on the table tangible assets per GEs. Therefore, "Estimatable" means that the corresponding development team should be able to answer you how much would it take to implement the user story you are providing. Therefore, you can make a simple test: take one of your entries, go to the teams, and ask them "how much effort (roughly) would it take ?" ... if they give you answers like "unless you give me more details, it's simply impossible ... what you provide is too vague", then you don't have a user story for sure but probably an EPIC. * They don't need to have ALL the details nor have everything closed. There should be details that may be worked out while developing it (again, bear the duration of sprints in mind, i.e., maximum between 1-2 months). You shouldn't enter into that level of detail at which you are probably wasting time and unnecessarily delaying development. But good developers are able to provide accurate estimations without knowing all details. This is why they should be "Negotiable" (detailed description may vary/be-refined over time even during development but without this implying a relevant deviation from the original estimation) "Independent" and "Valuable" are also relevant but I guess there may be many EPICs that would also cope with those properties. That's why I would make emphasis on the previous points. Some references (but you may find much more, just search for INVEST properties for User Stories in Agile or discussions on EPICs vs User Stories): [1] - http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ [2] - http://agilesoftwaredevelopment.com/blog/vaibhav/good-user-story-invest [3] - http://en.wikipedia.org/wiki/INVEST_%28mnemonic%29 Themes, are much more high-level or abstract than EPICs. The frontier between Themes and EPICs is also fuzzy, but is not that relevant as the frontier between EPICs and User Stories because this last frontier is what matters to know when you may stop refining. Indeed, we may adopt a convention regarding what to call Theme and what to call an EPIC. For example, we may map the notion of "Theme" to the notion of Generic Enabler in FI-WARE. Therefore, there would be a Theme linked to the "Publish/Subscribe Broker GE" which establishes as a goal that "Applications should be able to publish data and subscribe to data of their interest". The "target usage" text in the FI-WARE Product Vision / High-level Description deliverable for a given GE may well work as the content for the description of the corresponding Theme. Given said this, don't feel too frustrated if you are not able to identify too many User Stories in a first shot. I believe that we should feel confident if we end August with a complete and comprehensive set of EPICs per Generic Enabler. Then, during September, we may focus in trying to derive a number of User Stories from those EPICs that will enable to plan the first sprint in FI-WARE (which we should be able to start by early October) Please remind that we are supposed to rely the development of the reference implementation of FI-WARE GEs in a number of assets. We should concentrate on what will map into development tasks on those assets (so that they can integrate with other assets, comply with the final standard open royalty-free specification of interfaces we want them to provide, incorporate any function that we agree a target reference implementation must/should offer but our asset still do not offer). Don't focus on describing things already supported by an asset. Remember: backlog = work to be done. Review my previous mails on the matter if you have any doubt. Please share this with your teams. And don't hesitate to bring on the table any doubt, concern or comment you may have. Let's share them and share the answer. Last but not least, please send back two separate responses: a) first to Thomas and me, a response confirming that you have received this email b) later, to the fiware-wpl and fiware-wpa, an email confirming that you have read it and you feel like there is no essential obstacle for moving forward. If you have any initial questions/doubts/comments you would like to share at the time you send the response, please do so. Best regards, -- Juanjo ________________________________ 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 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. [cid:00000000000000000000000000000001 at TI.Disclaimer]Rispetta l'ambiente. Non stampare questa mail se non ? necessario. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo Ambiente_foglia.jpg Type: image/jpeg Size: 677 bytes Desc: logo Ambiente_foglia.jpg URL: From GLIKSON at il.ibm.com Thu Aug 11 16:16:40 2011 From: GLIKSON at il.ibm.com (Alex Glikson) Date: Thu, 11 Aug 2011 17:16:40 +0300 Subject: [Fiware-wpa] Hints and examples about entries for the FI-WARE backlog In-Reply-To: <4E42AC96.4090808@tid.es> References: <4E42AC96.4090808@tid.es> Message-ID: Sounds good. One concern is the vacations that most of the people are going to take in the upcoming 2 months -- making it more difficult to make progress with the WP-wide discussions, which could affect the M5 deliverable(s). Regards, Alex From: Juanjo Hierro To: "fiware-wpl at lists.fi-ware.eu" , "fiware-wpa at lists.fi-ware.eu" Date: 10/08/2011 07:10 PM Subject: [Fiware-wpl] Hints and examples about entries for the FI-WARE backlog Sent by: fiware-wpl-bounces at lists.fi-ware.eu Hi all, One of the action points that were agreed had to do with providing some detail examples of what the entries for an EPIC and a User Story (or Story, for short) in the FI-WARE backlog. Please find enclosed a spreadsheet where I have included two separate sheets describing: The template to be used for entries in the backlog. This is an update of the one you already had where I have addressed some points that were unresolved or required some clarifications. I have found also the need to add a new field (Detailed Status). An example of an EPIC An example of an User Story The examples are not "official". I just elaborate them on my own (although the EPIC was based on an initial proposal made by Fernando L?pez from TID). They just pretend to serve as example of the level of "granularity" associated to an EPIC compared to a User Story in an Agile backlog. What can be considered at the level of "user story" according to Agile ? Well ... there is no a black or white frontier between things nor a mathematical formula you can apply and then determine when something should be considered an EPIC rather than a User Story. As mentioned in the presentation on Agile we made at the FI-WARE kick-off meeting, User Stories have to comply with "INVEST" properties which mean they should be "Independent, Negotiable, Valuable, Estimatable, Small and Testable". Some resources that may be helpful in finding out what we mean by INVEST properties can be found at [1], [2] and even [3] but in general: Bear in mind that User Stories have to be something "Small" as to be affordable in a Sprint. Sprints should be of a maximum of two months in FI-WARE, unitary tests included (I'm even seriously considering to make them shorter, of about one month, therefore closer to the spirit of Agile). In general, something that would go beyond one single sprint should be considered an EPIC. It should be also detailed enough so that you can say "I understand what I want well enough that I could think how a test for it could be designed." This is what means it should be "Testable". User stories also should be "Estimatable" meaning that it should contain enough information enabling a developer to make a rough estimation of how much it would take to develop it (and shouldn't go beyond the time limits of a sprint :-). In our case, we are supposed to bring on the table tangible assets per GEs. Therefore, "Estimatable" means that the corresponding development team should be able to answer you how much would it take to implement the user story you are providing. Therefore, you can make a simple test: take one of your entries, go to the teams, and ask them "how much effort (roughly) would it take ?" ... if they give you answers like "unless you give me more details, it's simply impossible ... what you provide is too vague", then you don't have a user story for sure but probably an EPIC. They don't need to have ALL the details nor have everything closed. There should be details that may be worked out while developing it (again, bear the duration of sprints in mind, i.e., maximum between 1-2 months). You shouldn't enter into that level of detail at which you are probably wasting time and unnecessarily delaying development. But good developers are able to provide accurate estimations without knowing all details. This is why they should be "Negotiable" (detailed description may vary/be-refined over time even during development but without this implying a relevant deviation from the original estimation) "Independent" and "Valuable" are also relevant but I guess there may be many EPICs that would also cope with those properties. That's why I would make emphasis on the previous points. Some references (but you may find much more, just search for INVEST properties for User Stories in Agile or discussions on EPICs vs User Stories): [1] - http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ [2] - http://agilesoftwaredevelopment.com/blog/vaibhav/good-user-story-invest [3] - http://en.wikipedia.org/wiki/INVEST_%28mnemonic%29 Themes, are much more high-level or abstract than EPICs. The frontier between Themes and EPICs is also fuzzy, but is not that relevant as the frontier between EPICs and User Stories because this last frontier is what matters to know when you may stop refining. Indeed, we may adopt a convention regarding what to call Theme and what to call an EPIC. For example, we may map the notion of "Theme" to the notion of Generic Enabler in FI-WARE. Therefore, there would be a Theme linked to the "Publish/Subscribe Broker GE" which establishes as a goal that "Applications should be able to publish data and subscribe to data of their interest". The "target usage" text in the FI-WARE Product Vision / High-level Description deliverable for a given GE may well work as the content for the description of the corresponding Theme. Given said this, don't feel too frustrated if you are not able to identify too many User Stories in a first shot. I believe that we should feel confident if we end August with a complete and comprehensive set of EPICs per Generic Enabler. Then, during September, we may focus in trying to derive a number of User Stories from those EPICs that will enable to plan the first sprint in FI-WARE (which we should be able to start by early October) Please remind that we are supposed to rely the development of the reference implementation of FI-WARE GEs in a number of assets. We should concentrate on what will map into development tasks on those assets (so that they can integrate with other assets, comply with the final standard open royalty-free specification of interfaces we want them to provide, incorporate any function that we agree a target reference implementation must/should offer but our asset still do not offer). Don't focus on describing things already supported by an asset. Remember: backlog = work to be done. Review my previous mails on the matter if you have any doubt. Please share this with your teams. And don't hesitate to bring on the table any doubt, concern or comment you may have. Let's share them and share the answer. Last but not least, please send back two separate responses: a) first to Thomas and me, a response confirming that you have received this email b) later, to the fiware-wpl and fiware-wpa, an email confirming that you have read it and you feel like there is no essential obstacle for moving forward. If you have any initial questions/doubts/comments you would like to share at the time you send the response, please do so. Best regards, -- Juanjo 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[attachment "Backlog entries examples by TID 11-08-09.xls" deleted by Alex Glikson/Haifa/IBM] [attachment "jhierro.vcf" deleted by Alex Glikson/Haifa/IBM] _______________________________________________ Fiware-wpl mailing list Fiware-wpl at lists.fi-ware.eu http://lists.fi-ware.eu/listinfo/fiware-wpl -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhierro at tid.es Mon Aug 15 10:44:33 2011 From: jhierro at tid.es (Juanjo Hierro) Date: Mon, 15 Aug 2011 10:44:33 +0200 Subject: [Fiware-wpa] First release of the FI-WARE High-level Description (Product Vision) deliverable Message-ID: <4E48DC71.5090304@tid.es> Hi all, Finally, I have been able to close the first official release of the FI-WARE High-level Description (Product Vision) deliverable. The official, .pdf version is available at: https://forge.fi-ware.eu/docman/view.php/7/308/FI-WARE+High-Level+Description+v1.0+11-08-15.pdf The MS Word version is privately available at: https://forge.fi-ware.eu/docman/view.php/7/309/FI-WARE+High-Level+Description+v1.0+11-08-15.doc Please try to make a final review and check that everything was fine with your chapter. Despite I have already sent it to the EC, I would kindly ask you to perform this final revision, just in case that I have miss something. You are entitled to share this document with the rest of your teams. Best regards, -- Juanjo P.S.: I will be travelling most of today. If you send some particular request to me, I won't be able to respond until later tonight. 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 -------------- A non-text attachment was scrubbed... Name: jhierro.vcf Type: text/x-vcard Size: 429 bytes Desc: not available URL: From thomas.michael.bohnert at sap.com Mon Aug 15 10:49:29 2011 From: thomas.michael.bohnert at sap.com (Bohnert, Thomas Michael) Date: Mon, 15 Aug 2011 10:49:29 +0200 Subject: [Fiware-wpa] [Fiware-wpl] Hints and examples about entries for the FI-WARE backlog In-Reply-To: References: <4E42AC96.4090808@tid.es> Message-ID: <771C9B001456D64783596DDC3801C6EA2815CAAB92@DEWDFECCR09.wdf.sap.corp> Dear Alex, all, I agree that the current vacations period affects the progress of our delivery but would like to add that we need to keep an eye on our surrounding eco-system. FI-WARE is supposed to deliver a platform to the Usage Areas and in order to provide enough evidence about capabilities / capacities of the solution we have in mind to this research issue, we must not loose time. Otherwise, FI-WARE may be considered as (allegedly ) slowing down the progress of the whole FI-PPP. Bottom line. The M5 deliverable should pose a convincing argument in favor of the conceptual, architectural, and technological choices we did. Cheers, Thomas From: fiware-wpl-bounces at lists.fi-ware.eu [mailto:fiware-wpl-bounces at lists.fi-ware.eu] On Behalf Of Alex Glikson Sent: Donnerstag, 11. August 2011 16:17 To: Juanjo Hierro Cc: fiware-wpl at lists.fi-ware.eu; fiware-wpa at lists.fi-ware.eu Subject: Re: [Fiware-wpl] Hints and examples about entries for the FI-WARE backlog Sounds good. One concern is the vacations that most of the people are going to take in the upcoming 2 months -- making it more difficult to make progress with the WP-wide discussions, which could affect the M5 deliverable(s). Regards, Alex From: Juanjo Hierro To: "fiware-wpl at lists.fi-ware.eu" , "fiware-wpa at lists.fi-ware.eu" Date: 10/08/2011 07:10 PM Subject: [Fiware-wpl] Hints and examples about entries for the FI-WARE backlog Sent by: fiware-wpl-bounces at lists.fi-ware.eu ________________________________ Hi all, One of the action points that were agreed had to do with providing some detail examples of what the entries for an EPIC and a User Story (or Story, for short) in the FI-WARE backlog. Please find enclosed a spreadsheet where I have included two separate sheets describing: * The template to be used for entries in the backlog. This is an update of the one you already had where I have addressed some points that were unresolved or required some clarifications. I have found also the need to add a new field (Detailed Status). * An example of an EPIC * An example of an User Story The examples are not "official". I just elaborate them on my own (although the EPIC was based on an initial proposal made by Fernando L?pez from TID). They just pretend to serve as example of the level of "granularity" associated to an EPIC compared to a User Story in an Agile backlog. What can be considered at the level of "user story" according to Agile ? Well ... there is no a black or white frontier between things nor a mathematical formula you can apply and then determine when something should be considered an EPIC rather than a User Story. As mentioned in the presentation on Agile we made at the FI-WARE kick-off meeting, User Stories have to comply with "INVEST" properties which mean they should be "Independent, Negotiable, Valuable, Estimatable, Small and Testable". Some resources that may be helpful in finding out what we mean by INVEST properties can be found at [1], [2] and even [3] but in general: * Bear in mind that User Stories have to be something "Small" as to be affordable in a Sprint. Sprints should be of a maximum of two months in FI-WARE, unitary tests included (I'm even seriously considering to make them shorter, of about one month, therefore closer to the spirit of Agile). In general, something that would go beyond one single sprint should be considered an EPIC. * It should be also detailed enough so that you can say "I understand what I want well enough that I could think how a test for it could be designed." This is what means it should be "Testable". * User stories also should be "Estimatable" meaning that it should contain enough information enabling a developer to make a rough estimation of how much it would take to develop it (and shouldn't go beyond the time limits of a sprint :-). In our case, we are supposed to bring on the table tangible assets per GEs. Therefore, "Estimatable" means that the corresponding development team should be able to answer you how much would it take to implement the user story you are providing. Therefore, you can make a simple test: take one of your entries, go to the teams, and ask them "how much effort (roughly) would it take ?" ... if they give you answers like "unless you give me more details, it's simply impossible ... what you provide is too vague", then you don't have a user story for sure but probably an EPIC. * They don't need to have ALL the details nor have everything closed. There should be details that may be worked out while developing it (again, bear the duration of sprints in mind, i.e., maximum between 1-2 months). You shouldn't enter into that level of detail at which you are probably wasting time and unnecessarily delaying development. But good developers are able to provide accurate estimations without knowing all details. This is why they should be "Negotiable" (detailed description may vary/be-refined over time even during development but without this implying a relevant deviation from the original estimation) "Independent" and "Valuable" are also relevant but I guess there may be many EPICs that would also cope with those properties. That's why I would make emphasis on the previous points. Some references (but you may find much more, just search for INVEST properties for User Stories in Agile or discussions on EPICs vs User Stories): [1] - http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ [2] - http://agilesoftwaredevelopment.com/blog/vaibhav/good-user-story-invest [3] - http://en.wikipedia.org/wiki/INVEST_%28mnemonic%29 Themes, are much more high-level or abstract than EPICs. The frontier between Themes and EPICs is also fuzzy, but is not that relevant as the frontier between EPICs and User Stories because this last frontier is what matters to know when you may stop refining. Indeed, we may adopt a convention regarding what to call Theme and what to call an EPIC. For example, we may map the notion of "Theme" to the notion of Generic Enabler in FI-WARE. Therefore, there would be a Theme linked to the "Publish/Subscribe Broker GE" which establishes as a goal that "Applications should be able to publish data and subscribe to data of their interest". The "target usage" text in the FI-WARE Product Vision / High-level Description deliverable for a given GE may well work as the content for the description of the corresponding Theme. Given said this, don't feel too frustrated if you are not able to identify too many User Stories in a first shot. I believe that we should feel confident if we end August with a complete and comprehensive set of EPICs per Generic Enabler. Then, during September, we may focus in trying to derive a number of User Stories from those EPICs that will enable to plan the first sprint in FI-WARE (which we should be able to start by early October) Please remind that we are supposed to rely the development of the reference implementation of FI-WARE GEs in a number of assets. We should concentrate on what will map into development tasks on those assets (so that they can integrate with other assets, comply with the final standard open royalty-free specification of interfaces we want them to provide, incorporate any function that we agree a target reference implementation must/should offer but our asset still do not offer). Don't focus on describing things already supported by an asset. Remember: backlog = work to be done. Review my previous mails on the matter if you have any doubt. Please share this with your teams. And don't hesitate to bring on the table any doubt, concern or comment you may have. Let's share them and share the answer. Last but not least, please send back two separate responses: a) first to Thomas and me, a response confirming that you have received this email b) later, to the fiware-wpl and fiware-wpa, an email confirming that you have read it and you feel like there is no essential obstacle for moving forward. If you have any initial questions/doubts/comments you would like to share at the time you send the response, please do so. Best regards, -- Juanjo ________________________________ 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[attachment "Backlog entries examples by TID 11-08-09.xls" deleted by Alex Glikson/Haifa/IBM] [attachment "jhierro.vcf" deleted by Alex Glikson/Haifa/IBM] _______________________________________________ Fiware-wpl mailing list Fiware-wpl at lists.fi-ware.eu http://lists.fi-ware.eu/listinfo/fiware-wpl -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.michael.bohnert at sap.com Tue Aug 16 10:44:36 2011 From: thomas.michael.bohnert at sap.com (Bohnert, Thomas Michael) Date: Tue, 16 Aug 2011 10:44:36 +0200 Subject: [Fiware-wpa] FI-WARE Backlog Management Message-ID: <771C9B001456D64783596DDC3801C6EA2815D4C29A@DEWDFECCR09.wdf.sap.corp> Dear all, We are getting closer to a final concept for maintaining the FI-WARE backlog. As you may recall, the system we will use to manage requests and actual backlog entries is a combination of the FORGE tracker, AgileFant, and a media wiki. Based on my own experience AgileFant in particular requires some effort to get acquainted with. Since the FI-WARE internal backlog will be managed by WP-Leads/-Architect I enclose the demo presentation provided by the AgileFant providers. Please make yourself familiar with it. In the near future we'll go through an some examples on how to use AgileFant within FI-WARE and familiarity with AgileFant terminology and concepts will be a prerequisite. I'll also put additional documentation on FORGE, under "WP2 - Global Technical Activities". In case of questions drop me mail. Best - Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: Agile-Fant-Demo_fantti_2011_07_12.pdf Type: application/pdf Size: 1334524 bytes Desc: Agile-Fant-Demo_fantti_2011_07_12.pdf URL: From thomas.michael.bohnert at sap.com Tue Aug 16 12:34:51 2011 From: thomas.michael.bohnert at sap.com (Bohnert, Thomas Michael) Date: Tue, 16 Aug 2011 12:34:51 +0200 Subject: [Fiware-wpa] First release of the FI-WARE High-level Description (Product Vision) deliverable In-Reply-To: <4E48DC71.5090304@tid.es> References: <4E48DC71.5090304@tid.es> Message-ID: <771C9B001456D64783596DDC3801C6EA2815D4C4B1@DEWDFECCR09.wdf.sap.corp> Dear Juanjo, Figure 1 in Chapter 3 is upside down. Best - Thomas -----Original Message----- From: fiware-wpa-bounces at lists.fi-ware.eu [mailto:fiware-wpa-bounces at lists.fi-ware.eu] On Behalf Of Juanjo Hierro Sent: Montag, 15. August 2011 10:45 To: fiware-wpl at lists.fi-ware.eu; fiware-wpa at lists.fi-ware.eu Subject: [Fiware-wpa] First release of the FI-WARE High-level Description (Product Vision) deliverable Hi all, Finally, I have been able to close the first official release of the FI-WARE High-level Description (Product Vision) deliverable. The official, .pdf version is available at: https://forge.fi-ware.eu/docman/view.php/7/308/FI-WARE+High-Level+Description+v1.0+11-08-15.pdf The MS Word version is privately available at: https://forge.fi-ware.eu/docman/view.php/7/309/FI-WARE+High-Level+Description+v1.0+11-08-15.doc Please try to make a final review and check that everything was fine with your chapter. Despite I have already sent it to the EC, I would kindly ask you to perform this final revision, just in case that I have miss something. You are entitled to share this document with the rest of your teams. Best regards, -- Juanjo P.S.: I will be travelling most of today. If you send some particular request to me, I won't be able to respond until later tonight. 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 From jhierro at tid.es Thu Aug 18 10:33:50 2011 From: jhierro at tid.es (Juanjo Hierro) Date: Thu, 18 Aug 2011 10:33:50 +0200 Subject: [Fiware-wpa] Publication of the FI-WARE High-level Description document (Product Vision) Message-ID: <4E4CCE6E.1040900@tid.es> Hi, As you probably are aware, we have finished edition of the first public document of the project, namely the "FI-WARE High-level Description", also referred as "FI-WARE Product Vision". A draft rather close to the final version was already available on July 6th and we have submitted it to the EC on August 15th. According to the current draft of the CA (unfortunately, not yet signed) this deliverable can be published if there is no objection by any party after 20 days the document was ready. In addition, any objection could only apply to anything that was added from the draft available on July 6th. So unless I hear about any objection before Saturday September 3th, we will make it publicly available. Enclosed at the end of this mail you may find the text from the CA regulating publication of deliverables for your convenience. Best regards, -- Juanjo P.S.: Honestly speaking, a period of 20 days is painful for public deliverables other than the GE specifications. I will ask lawyers to reduce it to 10 days (at least for those cases where drafts have been circulated) 4.4.1 Publications No Party shall have the right to publish or allow the publishing of any data which constitutes Foreground, Sideground, Background or Confidential Information of another Party, even where such data is amalgamated with such first Party's Foreground, Sideground, Background or other information, document or material. Any such publication without such other Party's written agreement justifies, in addition to any other available remedies, objection to the publication by the Party concerned in accordance with GA Article II.30.3. a.- A copy of any draft of FIWARE Generic Enabler specifications shall be sent to the Project Coordinator and by the Project Coordinator to the Parties at the earliest time possible. Any of the Parties may object to the publication within 30 days after receipt of a copy of the proposed publication on any of the following grounds: (i) that they consider that the protection of the objecting Party's Foreground would be adversely affected by the proposed publication, (ii) that the proposed publication includes the Confidential Information of the objecting Party, or (iii) the publication of such information would be contrary to the commercial interests of the objecting Party. The proposed publication shall not take place until the expiry of the above period of 30 days. In the absence of any objection within the above mentioned period, it is deemed that the Parties agree to the proposed publication. Following the end of the above mentioned period, the Project Coordinator shall inform the Parties whether or not any objection has been received. Objections to publication of the final specifications of a Generic Enabler Specification will not apply if there were no objections to previously distributed drafts of FIWARE Generic Enabler Specifications, unless the changes between the draft and final version of the FIWARE Generic Enabler Specifications precisely provide the ground for the objection to publish the final version. In the event that an objection is raised on any of the above defined grounds within the above period of 30 days, the Party proposing the publication and the Party objecting shall seek in good faith to agree a solution on a timely basis, that will not exceed of 30 days, whereby such objection is resolved. In case that the objection raised affects the publication of the FIWARE Generic Enabler Specifications (as defined in this Consortium Agreement) if no solution is found within the term established in this paragraph, the parties will submit the controversy to the General Assembly, which decision will be final and binding and in accordance with the confidentiality provisions established in this Consortium Agreement.. b.- The same rules as in 4.4.1.(a) shall apply for any other proposed publication in connection with or relating to the Project, but for such publications a period of 20 days shall be applicable ________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: jhierro.vcf Type: text/x-vcard Size: 429 bytes Desc: not available URL: From maarten.los at atosresearch.eu Mon Aug 22 14:47:48 2011 From: maarten.los at atosresearch.eu (Maarten Los) Date: Mon, 22 Aug 2011 14:47:48 +0200 Subject: [Fiware-wpa] FI-WARE Backlog Management In-Reply-To: <771C9B001456D64783596DDC3801C6EA2815D4C29A@DEWDFECCR09.wdf.sap.corp> References: <771C9B001456D64783596DDC3801C6EA2815D4C29A@DEWDFECCR09.wdf.sap.corp> Message-ID: <76BD4E6231F77947B6885C75E5214FA505FCCB9D@INTMAIL01.es.int.atosorigin.com> Dear all, In the telco of 28/7 about the coordination of FIWARE Backlog related activities, as leaders of Task 2.1, we proposed a procedure and a supporting tool (to be set up, hosted and supported by Atos) for the requirements gathering process, as an entry point for the backlog entries to be passed into AgileFant. The idea behind our proposed tool and procedure is that requirement contributors can directly provide their input into the system, requiring it to be assigned to a relevant WP representative (no 'dangling', un-owned requirements allowed). It allows for a decentralized way of handling the requirements and for a one-to-one dialog between those providing the requirements and the technical leaders responsible for fulfilling them. In our opinion, there is a risk involved when one single point of contact (whether that's Atos or anyone else), is responsible for evaluating, assigning, discussing and coordinating all the requirements between all contributors and all WP representatives. The amount of requirements that will be generated will be of a too significant amount to be realistically dealt with that way. The proposed tool supports topics (for a division between WPs), visibility/access levels for different staff, transfer of tickets, both private and public discussion threads for the tickets (to facilitate mentioned one-to-one dialogs), access without required registration, as well as the usual features such as email notifications, attachments, etc. Meanwhile, it is becoming apparent that the proposal is being disregarded in favor of Forge Tracker and a different process (more centralized). Let's be clear upfront that we have no problem with any tool that does the job right. However, we would like to emphasize that Atos will not assume the role of a central requirement handler. Atos will contribute to this task by providing end user and technical requirements and is still open to contribute with any further coordination activities required by the WP leader, as far as they reasonably fit within our assigned efforts. Best regards, Maarten -----Original Message----- From: fiware-wpa-bounces at lists.fi-ware.eu [mailto:fiware-wpa-bounces at lists.fi-ware.eu] On Behalf Of Bohnert, Thomas Michael Sent: martes, 16 de agosto de 2011 10:45 To: fiware-wpl at lists.fi-ware.eu; fiware-wpa at lists.fi-ware.eu Subject: [Fiware-wpa] FI-WARE Backlog Management Dear all, We are getting closer to a final concept for maintaining the FI-WARE backlog. As you may recall, the system we will use to manage requests and actual backlog entries is a combination of the FORGE tracker, AgileFant, and a media wiki. Based on my own experience AgileFant in particular requires some effort to get acquainted with. Since the FI-WARE internal backlog will be managed by WP-Leads/-Architect I enclose the demo presentation provided by the AgileFant providers. Please make yourself familiar with it. In the near future we'll go through an some examples on how to use AgileFant within FI-WARE and familiarity with AgileFant terminology and concepts will be a prerequisite. I'll also put additional documentation on FORGE, under "WP2 - Global Technical Activities". In case of questions drop me mail. Best - Thomas ------------------------------------------------------------------ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. Este mensaje y los ficheros adjuntos pueden contener informacion confidencial destinada solamente a la(s) persona(s) mencionadas anteriormente pueden estar protegidos por secreto profesional. Si usted recibe este correo electronico por error, gracias por informar inmediatamente al remitente y destruir el mensaje. Al no estar asegurada la integridad de este mensaje sobre la red, Atos no se hace responsable por su contenido. Su contenido no constituye ningun compromiso para el grupo Atos, salvo ratificacion escrita por ambas partes. Aunque se esfuerza al maximo por mantener su red libre de virus, el emisor no puede garantizar nada al respecto y no sera responsable de cualesquiera danos que puedan resultar de una transmision de virus. ------------------------------------------------------------------ From jhierro at tid.es Mon Aug 22 18:20:09 2011 From: jhierro at tid.es (Juanjo Hierro) Date: Mon, 22 Aug 2011 18:20:09 +0200 Subject: [Fiware-wpa] Fwd: Minutes of the last two meetings of the FI-PPP AB In-Reply-To: <4E52817D.1090009@tid.es> References: <4E52817D.1090009@tid.es> Message-ID: <4E5281B9.8060309@tid.es> FYI. Please distribute to members of your teams. Cheers, -- Juanjo -------- Original Message -------- Subject: Minutes of the last two meetings of the FI-PPP AB Date: Mon, 22 Aug 2011 18:19:09 +0200 From: JUAN JOSE HIERRO SUREDA To: Arian.ZWEGERS at ec.europa.eu CC: Annalisa.Bogliolo at ec.europa.eu , INFSO-ICT-285248 at ec.europa.eu , Wout.VAN-WIJK at ec.europa.eu , Peter.Fatelnig at ec.europa.eu , JOSE JIMENEZ DELGADO , JUAN JOSE HIERRO SUREDA Dear Arian, Annalisa, Wout, Peter, Please find enclosed the minutes of our last two FI-PPP AB meetings. I hope they can help you to have an overall picture of what's going on regarding activities of the AB. Overall, I believe things are going Ok, given the fact we are in the third month of FI-WARE. People acknowledge that start of the project is being much more intense than any other regular EU FP project. The amount of info provided in the FI-WARE High-level Description document (first deliverable providing the FI-WARE product vision, released as a draft early in July and officially mid August) is a proof of this. UC projects are eager to know more details about what we intend to provide which I would interpret as a good signal. We are now in the process of defining the way in which we can collect their input and get it prioritized together with the roadmap defined by FI-WARE contributing partners and linked to assets being considered as baseline for the reference implementation of FI-WARE GEs. The template for entries in the FI-PPP AB backlog (of which the FI-WARE backlog will be part of) has already been defined) but the actual process (and supportive tools) are been agreed these days. The ultimate goal is to have a well-defined backlog of FI-WARE features closed by end of November as planned. We should also establish a process which allows us to make sure that UC projects try to use what FI-WARE provides which can address their needs, otherwise a good rationale has to be provided. Cheers, -- Juanjo Hierro ________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: FI-PPP-AB-Meeting-Minutes 11-07-11 v1.0 clean.doc Type: application/msword Size: 586752 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FI-PPP-AB-Meeting-Minutes 11-06-16 v1.0.doc Type: application/msword Size: 591360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: jhierro.vcf Type: text/x-vcard Size: 429 bytes Desc: not available URL: From jhierro at tid.es Thu Aug 25 17:59:33 2011 From: jhierro at tid.es (Juanjo Hierro) Date: Thu, 25 Aug 2011 17:59:33 +0200 Subject: [Fiware-wpa] Plenary WPLs/WPAs confcall and next steps Message-ID: <4E567165.9020401@tid.es> Hi all, First thing I wanna say is that I have just come back from holidays. I hope you have already enjoyed yours ! Now that I came back, and the August period is almost finished, we will resume our follow-ups. We will start with a plenary confcall involving all WPLs/WPAs. Then, we will resume our WP-specific follow-up confcalls but will go for trying to have them bi-weekly. The plenary confcall would take place on Friday September 2nd at 10:00am CET. Please pencil this on your agendas. Dial-in details to be provided later. There, Thomas and me will share with you the process (and supporting tools) we will put in place for managing: a) Communication with UC projects regarding doubts, clarifications and any other sort of Technical Support. As an example, clarification of parts of the FI-WARE High-level Description (Product Vision) document b) creation and lifecycle of entries in the FI-WARE backlog Therefore, it is crucial that you attend this confcall. We will not only explain you the process but rather show you the tools we are configuring for this purpose. Then you should start using them to feed the FI-WARE backlog with the entries you are supposed to be working on these days (I remind you that deadline for first list of EPICs was planned for end of August, check my previous email on the matter) An early presentation of both the process and the tools has been made today to the rest of members of the FI-PPP Architecture Board and has been rather welcomed. Still we have to fine-tune a couple of things but we should have everything ready (at least regarding definition of the process) for our plenary confcall. Then we would collect your feedback and do any additional-final fine tuning until a presentation we have committed to make to UC project by September 7-8. As an advanced notice, prior to official distribution of the minutes of the AB meeting that took place today, we can tell you that UC projects are mostly in the process of finishing the requirements of their end users and are now in the process of performing the necessary analysis of those requirements as to be able to produce the first requests for entries to the FI-WARE backlog by end of September on the average (one project mentioned they will try to start providing input by mid September while some would be doing early in October, but most of them mentioned "end of September"). This matches pretty well with our current planning so that we should be able to endup with a collection of FI-WARE backlog entries by the end of September (part of it being generated by us on our own, part coming from the UC projects). Regarding the bi-weekly follow-up confcalls, we will keep them on Mondays and Fridays because this will allow us to resume weekly confcalls whenever is needed (hopefully not that frequently). The next three bi-weekly follow-up confcalls will be scheduled as follows: * for those on Mondays: September 5th, September 26th, October 10th * for those on Fridays: September 2nd, September 23th, October 7th Main topic for the first of these list of bi-weekly follow-up confcall will be to revise the status on collection of the EPICs related to your chapter as well as discussion on assets adopted as baseline for GEs in your chapter and issues about their integration. Cheers, -- Juanjo ________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: jhierro.vcf Type: text/x-vcard Size: 429 bytes Desc: not available URL: From jhierro at tid.es Mon Aug 29 15:15:44 2011 From: jhierro at tid.es (Juanjo Hierro) Date: Mon, 29 Aug 2011 15:15:44 +0200 Subject: [Fiware-wpa] Reminder about Backlog entries and some hints In-Reply-To: <4E5B75B6.1010108@tid.es> References: <4E5B75B6.1010108@tid.es> Message-ID: <4E5B9100.7010902@tid.es> Hi all, This mail is to remind you that you should be about providing entries for the FI-WARE Backlog in your respective chapters. There are some comments that have applied to the first take on the entries within the Data/Context Management WP so that I'm sharing them with you because may be they are helpful in collecting your own entries. They are, of course, generic: * Try to stick to the formula proposed for goals in the example templates ("Applications should be able to ..." / "It should be possible ..."). This is common practice in Agile. So, as far as it feasible, and not too much artificious, try to follow it. Following a defined formula, we gain in uniformity but, overall it will be easier to extract , and . Note that in Agile, some people like to use a cannonical form which is "As a , I can so that ". We tried just to adapt this a bit to description of stories for a software platform, but the notion of "cannonical form" itself is something we should try to stick to. * Chapter field: should be the name of your chapter: "Cloud Hosting", "Data/Context Management", "IoT Service Enablement", ... * Source and Stakeholder fields: You should write "FI-WARE" in here, at least for the time being. Keep Source contact empty for the time being. * Owner and Owner contact: this should be the name of your company (the company or companies behind the asset being considered as "baseline"). Fill the owner contact with your email for the time being but we'll see how to handle this later (we don't want that making entries publicly available becomes a source of spam :-) * We mentioned that "name" should be an acronymun (indeed the last part of the Id) but I have found itself a little bit useless itself if it is actually part of the Id. Therefore, I suggest that we follow the approach of Thales and use it as a short description (should not be longer than 7 words, preferably 4-5 excluding "and"s "the"s and similar auxiliary articles, prepositions, etc) * The Description field is free. Put there whatever makes sense to you and would be helpful to understand the entry. Don't hesitate to add URLs to complementary documents, standards, whatever you believe may be useful if read. You can upload a document to the docman system at FusionForge and then use the link if you wish. * Regarding the Rationale: at least for entries prioritized with a MUST MoSCoW, try to give more info about why "it would have no sense" if we do not develop the corresponding feature. Note that a MUST priority is considered to be assigned for features that "If not done, the project will be considered a failure". In other words: the product doesn't make sense to you unless it supports that feature. UC projects may argue that some of the features they propose are going to be of a higher priority than these ones, so that better you work the rationale for keeping your priority. * About the MoSCoW priority: It is assumed that you are bringing here an asset that your company had developed and had plans to keep evolving because it is of relevant priority to you. Therefore, here you are some guidelines that I would suggest you to bear in mind when reviewing the MoSCoW priorities you had assigned. * You should assign a MUST priority to features you would plan to address in the following 12 months in your product (asset), no matter whether FI-WARE had existed or not. Again, the product doesn't make sense if you are not allowed to address this MUST priority. That's why you had it in your roadmap no matter if FI-WARE exists or not. * You may assign a SHOULD priority to features that were in your roadmap and you believe were important although perhaps you couldn't address them in the next 12 months prior existence of FI-WARE because lack of resources. FI-WARE actually gaves you the opportunity to address them. * You should assign a COULD priority to features you believe are nice to have and could be addressed thanks to FI-WARE. But you are open to learn about better ideas that may get assigned a higher priority. Hope all these comments become useful. Don't hesitate to formulate any question. Best regards, -- Juanjo ________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: jhierro.vcf Type: text/x-vcard Size: 429 bytes Desc: not available URL: From maarten.los at atosresearch.eu Tue Aug 30 13:32:27 2011 From: maarten.los at atosresearch.eu (Maarten Los) Date: Tue, 30 Aug 2011 13:32:27 +0200 Subject: [Fiware-wpa] Plenary WPLs/WPAs confcall and next steps In-Reply-To: <4E567165.9020401@tid.es> References: <4E567165.9020401@tid.es> Message-ID: <76BD4E6231F77947B6885C75E5214FA506024D66@INTMAIL01.es.int.atosorigin.com> Dear Juanjo, Regarding point b), I would like to indicate that from Atos' standpoint this topic is far from concluded. In the last months, despite repeated attempts, as far as we know, no concrete effort has been made to reach consensus with us as the leader of the requirements specification task. For example, we have outlined on various occasions our vision on the risks, and proposed mitigating procedures to follow, when ingesting the huge amount of requirements that will be generated, as well as a supporting tool, but this has been ignored. Instead, an alternative approach is now being proposed (and apparently has already been presented to the FI-PPP Architecture Board). We would like to object formally to these proceedings, as we think it is not compatible with the way the consortium should work, especially given the scope and impact of a project this size. In any case, we are looking forward to hear, and make an evaluation of what is proposed in this Friday's meeting with respect to the requirements specification process. Best regards, Maarten From: fiware-wpa-bounces at lists.fi-ware.eu [mailto:fiware-wpa-bounces at lists.fi-ware.eu] On Behalf Of Juanjo Hierro Sent: jueves, 25 de agosto de 2011 18:00 To: fiware-wpl at lists.fi-ware.eu; fiware-wpa at lists.fi-ware.eu Subject: [Fiware-wpa] Plenary WPLs/WPAs confcall and next steps Hi all, First thing I wanna say is that I have just come back from holidays. I hope you have already enjoyed yours ! Now that I came back, and the August period is almost finished, we will resume our follow-ups. We will start with a plenary confcall involving all WPLs/WPAs. Then, we will resume our WP-specific follow-up confcalls but will go for trying to have them bi-weekly. The plenary confcall would take place on Friday September 2nd at 10:00am CET. Please pencil this on your agendas. Dial-in details to be provided later. There, Thomas and me will share with you the process (and supporting tools) we will put in place for managing: a) Communication with UC projects regarding doubts, clarifications and any other sort of Technical Support. As an example, clarification of parts of the FI-WARE High-level Description (Product Vision) document b) creation and lifecycle of entries in the FI-WARE backlog Therefore, it is crucial that you attend this confcall. We will not only explain you the process but rather show you the tools we are configuring for this purpose. Then you should start using them to feed the FI-WARE backlog with the entries you are supposed to be working on these days (I remind you that deadline for first list of EPICs was planned for end of August, check my previous email on the matter) An early presentation of both the process and the tools has been made today to the rest of members of the FI-PPP Architecture Board and has been rather welcomed. Still we have to fine-tune a couple of things but we should have everything ready (at least regarding definition of the process) for our plenary confcall. Then we would collect your feedback and do any additional-final fine tuning until a presentation we have committed to make to UC project by September 7-8. As an advanced notice, prior to official distribution of the minutes of the AB meeting that took place today, we can tell you that UC projects are mostly in the process of finishing the requirements of their end users and are now in the process of performing the necessary analysis of those requirements as to be able to produce the first requests for entries to the FI-WARE backlog by end of September on the average (one project mentioned they will try to start providing input by mid September while some would be doing early in October, but most of them mentioned "end of September"). This matches pretty well with our current planning so that we should be able to endup with a collection of FI-WARE backlog entries by the end of September (part of it being generated by us on our own, part coming from the UC projects). Regarding the bi-weekly follow-up confcalls, we will keep them on Mondays and Fridays because this will allow us to resume weekly confcalls whenever is needed (hopefully not that frequently). The next three bi-weekly follow-up confcalls will be scheduled as follows: * for those on Mondays: September 5th, September 26th, October 10th * for those on Fridays: September 2nd, September 23th, October 7th Main topic for the first of these list of bi-weekly follow-up confcall will be to revise the status on collection of the EPICs related to your chapter as well as discussion on assets adopted as baseline for GEs in your chapter and issues about their integration. Cheers, -- Juanjo ________________________________ 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 ------------------------------------------------------------------ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. Este mensaje y los ficheros adjuntos pueden contener informacion confidencial destinada solamente a la(s) persona(s) mencionadas anteriormente pueden estar protegidos por secreto profesional. Si usted recibe este correo electronico por error, gracias por informar inmediatamente al remitente y destruir el mensaje. Al no estar asegurada la integridad de este mensaje sobre la red, Atos no se hace responsable por su contenido. Su contenido no constituye ningun compromiso para el grupo Atos, salvo ratificacion escrita por ambas partes. Aunque se esfuerza al maximo por mantener su red libre de virus, el emisor no puede garantizar nada al respecto y no sera responsable de cualesquiera danos que puedan resultar de una transmision de virus. ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.michael.bohnert at sap.com Tue Aug 30 14:19:51 2011 From: thomas.michael.bohnert at sap.com (Bohnert, Thomas Michael) Date: Tue, 30 Aug 2011 14:19:51 +0200 Subject: [Fiware-wpa] [Fiware-wpl] Plenary WPLs/WPAs confcall and next steps In-Reply-To: <76BD4E6231F77947B6885C75E5214FA506024D66@INTMAIL01.es.int.atosorigin.com> References: <4E567165.9020401@tid.es> <76BD4E6231F77947B6885C75E5214FA506024D66@INTMAIL01.es.int.atosorigin.com> Message-ID: <771C9B001456D64783596DDC3801C6EA28161D3EC6@DEWDFECCR09.wdf.sap.corp> Dear Maarten, Let me add a few comments since I don't think there is need for escalation nor formal complains. Upfront, you are right. No explicit attempt has been made to achieve consensus. The reason is simple. Before we can discuss something, especially with a complexity that reaches way beyond a single Chapter, FI-WARE, and potentially even beyond the FI-PPP, we should have a sound basis upon which we can have a profound discussion. It was indicated in several mails that we are working on such a proposal- one that serves the needs of the whole program. I thought to have the same over the phone when we spoke last week. Anyways, you'll receive a presentation as soon as we have it at the next stable level. The reason why we presented a "sneak preview" to the AB is that AB meetings are scheduled periodically and right in advance. We simply didn't manage to get draft procedures defined and a system up early enough (we settled at 2.30am at the day of the AB meeting). I trust that that there is no need to elaborate more on vacations periods and other delay factors of the like. So let me ask for a bit more patience in order to let us finalize the approach (concepts + prototypical implementation). The first feedback was encouraging and I am convinced that we can get your concerns addressed as well. Perhaps to alleviate your worries for the moment. Rest assured that you are, as a task leader, not solely responsible for this task. On top of, mind that requirements collection/engineering is not necessarily the same as the collection of User Stories/Epics, etc. Task leadership is foremost a management activity. For the content and procedures, you can count on the support by other project members. Comments welcome. Best - Thomas From: fiware-wpl-bounces at lists.fi-ware.eu [mailto:fiware-wpl-bounces at lists.fi-ware.eu] On Behalf Of Maarten Los Sent: Dienstag, 30. August 2011 13:32 To: Juanjo Hierro; fiware-wpl at lists.fi-ware.eu; fiware-wpa at lists.fi-ware.eu Subject: Re: [Fiware-wpl] [Fiware-wpa] Plenary WPLs/WPAs confcall and next steps Dear Juanjo, Regarding point b), I would like to indicate that from Atos' standpoint this topic is far from concluded. In the last months, despite repeated attempts, as far as we know, no concrete effort has been made to reach consensus with us as the leader of the requirements specification task. For example, we have outlined on various occasions our vision on the risks, and proposed mitigating procedures to follow, when ingesting the huge amount of requirements that will be generated, as well as a supporting tool, but this has been ignored. Instead, an alternative approach is now being proposed (and apparently has already been presented to the FI-PPP Architecture Board). We would like to object formally to these proceedings, as we think it is not compatible with the way the consortium should work, especially given the scope and impact of a project this size. In any case, we are looking forward to hear, and make an evaluation of what is proposed in this Friday's meeting with respect to the requirements specification process. Best regards, Maarten From: fiware-wpa-bounces at lists.fi-ware.eu [mailto:fiware-wpa-bounces at lists.fi-ware.eu] On Behalf Of Juanjo Hierro Sent: jueves, 25 de agosto de 2011 18:00 To: fiware-wpl at lists.fi-ware.eu; fiware-wpa at lists.fi-ware.eu Subject: [Fiware-wpa] Plenary WPLs/WPAs confcall and next steps Hi all, First thing I wanna say is that I have just come back from holidays. I hope you have already enjoyed yours ! Now that I came back, and the August period is almost finished, we will resume our follow-ups. We will start with a plenary confcall involving all WPLs/WPAs. Then, we will resume our WP-specific follow-up confcalls but will go for trying to have them bi-weekly. The plenary confcall would take place on Friday September 2nd at 10:00am CET. Please pencil this on your agendas. Dial-in details to be provided later. There, Thomas and me will share with you the process (and supporting tools) we will put in place for managing: a) Communication with UC projects regarding doubts, clarifications and any other sort of Technical Support. As an example, clarification of parts of the FI-WARE High-level Description (Product Vision) document b) creation and lifecycle of entries in the FI-WARE backlog Therefore, it is crucial that you attend this confcall. We will not only explain you the process but rather show you the tools we are configuring for this purpose. Then you should start using them to feed the FI-WARE backlog with the entries you are supposed to be working on these days (I remind you that deadline for first list of EPICs was planned for end of August, check my previous email on the matter) An early presentation of both the process and the tools has been made today to the rest of members of the FI-PPP Architecture Board and has been rather welcomed. Still we have to fine-tune a couple of things but we should have everything ready (at least regarding definition of the process) for our plenary confcall. Then we would collect your feedback and do any additional-final fine tuning until a presentation we have committed to make to UC project by September 7-8. As an advanced notice, prior to official distribution of the minutes of the AB meeting that took place today, we can tell you that UC projects are mostly in the process of finishing the requirements of their end users and are now in the process of performing the necessary analysis of those requirements as to be able to produce the first requests for entries to the FI-WARE backlog by end of September on the average (one project mentioned they will try to start providing input by mid September while some would be doing early in October, but most of them mentioned "end of September"). This matches pretty well with our current planning so that we should be able to endup with a collection of FI-WARE backlog entries by the end of September (part of it being generated by us on our own, part coming from the UC projects). Regarding the bi-weekly follow-up confcalls, we will keep them on Mondays and Fridays because this will allow us to resume weekly confcalls whenever is needed (hopefully not that frequently). The next three bi-weekly follow-up confcalls will be scheduled as follows: * for those on Mondays: September 5th, September 26th, October 10th * for those on Fridays: September 2nd, September 23th, October 7th Main topic for the first of these list of bi-weekly follow-up confcall will be to revise the status on collection of the EPICs related to your chapter as well as discussion on assets adopted as baseline for GEs in your chapter and issues about their integration. Cheers, -- Juanjo ________________________________ 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 ------------------------------------------------------------------ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. Este mensaje y los ficheros adjuntos pueden contener informacion confidencial destinada solamente a la(s) persona(s) mencionadas anteriormente pueden estar protegidos por secreto profesional. Si usted recibe este correo electronico por error, gracias por informar inmediatamente al remitente y destruir el mensaje. Al no estar asegurada la integridad de este mensaje sobre la red, Atos no se hace responsable por su contenido. Su contenido no constituye ningun compromiso para el grupo Atos, salvo ratificacion escrita por ambas partes. Aunque se esfuerza al maximo por mantener su red libre de virus, el emisor no puede garantizar nada al respecto y no sera responsable de cualesquiera danos que puedan resultar de una transmision de virus. ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: