[Fiware-testbed] Status and potential next steps towards validation planning with use case projects

[Sandfuchs, Thorsten]

Hi Paolo and team,
I have possibilities to extract text like the goal and description of features via a small command line tool, so it would be possible to generate (not manually, but rather automated) the table you or I provided.

BUT: Given the mere amount of "features" this does not seem to be feasible.
We have in the Apps-wiki 98 features linked - take e.g. the page: https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Category:AppsFeature
Overall and if you look at the Category:Feature, we have 666 (!) features in total (not all are from FI-WARE, I know, but still).

The task of rating every feature for every scenario you have, becomes quiet heavy.

My second suggestion would be to "just" link to the to the so called "Architecture descriptions" and extract a short introducing text out of there in the metric
Let's take WP3 as an example: https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Apps.Marketplace
   There are subpages for the open specifications, and one could imagine that we even integrate links or a general section on relevant "features" on such a page.
   Another example for WP8 is: https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Identity_Management_Generic_Enabler
Taking these architecture descriptions into account and e.g. just placing the "overiew"-Text and the Link to the subsequent description on the Metric would I think help a lot.
It would allow a use case project to rate on GE basis and, iff needed as well browse, deep-dive and find related features and more.
The complexity is reduced to "only" the number of GEs, but would be finally manageable.

What do you think?

Secondly I want to stress the point in the comments, I made: I think it would be more desirable to have a "gated"-approach, rather than the metric.
For FI-WARE it is more relevant if a GE passes a "quality" gate-defined by the UC and can be used, than the mere rating of a GE to be "excellent" or not.

ð  Therefore I think: "accepted", "accepted with comments", "rejected with comments" would try to encourage the UC project to even specify what needs to be fixed, in order to get a "green" light.
This finally would help the GE providers to be more customer centric.

Again: What do you think?

Best,
                                                                /Thorsten

From: Paolo Zampognaro [mailto:paolo.zampognaro at eng.it]
Sent: Dienstag, 4. September 2012 17:00
To: Sandfuchs, Thorsten; fiware-testbed at lists.fi-ware.eu
Subject: R: [Fiware-testbed] Status and potential next steps towards validation planning with use case projects

Hi All,

as attached you can find a reviewed version of the circulated document on validation activity.
Basically I have used a new template for the feature coverage matrix (as attached the excel sheet as well) (i) by introducing the new feature description as reported in the roadmap wiki page and (ii) by putting in the same sheet all involved Use Case Projects. Furthermore I have gathered the features by categories in order to offer to the Use Case Projects a more intuitive search criteria.
Finally, in the last section of the document, I have put an example about how to aggregate judgements from each single Use Case Project in order to extract global and high level conclusions.

Cheers,

Paolo

________________________________
Da: fiware-testbed-bounces at lists.fi-ware.eu<mailto:fiware-testbed-bounces at lists.fi-ware.eu> [mailto:fiware-testbed-bounces at lists.fi-ware.eu]<mailto:[mailto:fiware-testbed-bounces at lists.fi-ware.eu]> Per conto di Sandfuchs, Thorsten
Inviato: lunedì 3 settembre 2012 12.59
A: fiware-testbed at lists.fi-ware.eu<mailto:fiware-testbed at lists.fi-ware.eu>
Oggetto: Re: [Fiware-testbed] Status and potential next steps towards validation planning with use case projects

Hi,
Sorry there was a misplacement of layout information on my previous mail - corrected.

Best,
                                  ; & bsp;                         /Thorsten

From: fiware-testbed-bounces at lists.fi-ware.eu<mailto:fiware-testbed-bounces at lists.fi-ware.eu> [mailto:fiware-testbed-bounces at lists.fi-ware.eu]<mailto:[mailto:fiware-testbed-bounces at lists.fi-ware.eu]> On Behalf Of Sandfuchs, Thorsten
Sent: Montag, 3. September 2012 10:43
To: fiware-testbed at lists.fi-ware.eu<mailto:fiware-testbed at lists.fi-ware.eu>
Subject: [Fiware-testbed] Status and potential next steps towards validation planning with use case projects


< 0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Dear colleagues,
In order to prepare the topic of "validation planning and execution" for our next PHC on Wednesday, I would like to take the time to subsume the status and the potential next steps.

Find attached the commented version of Paolos "FI-WARE evaluation approach" the document outlines not only the process given on the wiki page (https://forge.fi-ware.eu/plugins/mediawiki/wiki/testbed/index.php/Testbed_V1_Validation_Plan<https://forge.fi-ware.eu/plugins/mediawiki/wiki/test%0d%0aValidation_Plan>) it as well introduces potenti x and further documentation for the use case projects in order to document validation.

If you have further comments and suggestions, please contribute directly in the document or comment via email.

As we want to have first validation results by M18, I think we have to approach the use case projects rather sooner than later.

Potential next steps would be (as outlined in the wiki & the document) to firstly approach the WPA/WPL meeting and introduce the overall plan. Then subsequently the use case projects and start with the first phases of the validation process:

1.  Validation Preparation phase (to be carried out before validation execution)
Duration: ~1-2 month
Purpose: Plan validation (concrete timin g, scope p>
DoW: " be defined with the support of FI-WARE partners participating in this task and should contain the technology requirements as well as the functional and non-functional requirements to be validated. Such test plans will be mapped versus the functionality offered by the FI-WARE instance under test in order to establish a coverage matrix."
A separate template for the validation plan will be provided by the Testbed team
Send validation plan to testbed coordinator
Recommendation: bi-weekly call with testbed coordinator, get formal green-light by te stbed te & scenario suitability
2. Introduction to FIWARE platform and testbed phase (optional)
Duration: 1-2 weeks
Schedule meeting with Testbed coordinator and complete va lang=EN-GB>
Testbed gives system endpoints and needed access information to the team and gives g e infrastructure
During second validation phase, this phase might be optional
Recommendation: UC to schedule Kick-off meeting with all FIWARE WPL/WPA for this validation phase, outlining the envisioned scenario

Any questions, don't hesitate to ask.

                                                                                /Thorsten

From: fiware-testbed-bounces at lists.fi-ware.eu<mailto:fiware-testbed-bounces at lists.fi-ware.eu>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-testbed/attachments/20120904/7e83d5e3/attachment.html>