[Fiware-testbed] Recommended Process for Validation going live

[Sandfuchs, Thorsten]

Dear colleagues,
As agreed in the last call, I'm putting this "public" in the testbed wiki - the URL is currently not linked on the main page, waiting for your comments and feedback. Once agreed, we can link it from the main page.

https://forge.fi-ware.eu/plugins/mediawiki/wiki/testbed/index.php/Testbed_V1_Validation_Plan

I think what is missing is a concrete example how a use case can time their validation for validation-execution

Additionally some templates (to be used by the UC project for each validation) should be jointly conducted within the team:

-          Validation plan template

-          Traceability matrix

-          Validation execution cockpit (I'm imagining something like our implementation cockpit, where we can track for each UC the status of validation execution)

Who would be able to contribute and make the first drafts?

Best regards,

                                                                /Thorsten

From: fiware-testbed-bounces at lists.fi-ware.eu [mailto:fiware-testbed-bounces at lists.fi-ware.eu] On Behalf Of Sandfuchs, Thorsten
Sent: Dienstag, 26. Juni 2012 10:42
To: fiware-testbed at lists.fi-ware.eu
Subject: Re: [Fiware-testbed] Recommended Process for Validation

Dear colleagues,
as the review is now over I'm hoping that we can continue with the discussion on the process, outlined below.

See open questions down below: Do you have any idea on how to smoothen and lean-up the process? Where did I miss something?

I think after our next phc, I will copy the information into the testbed-wiki.

Best regards,

                                                                                /Thorsten

From: fiware-testbed-bounces at lists.fi-ware.eu [mailto:fiware-testbed-bounces at lists.fi-ware.eu] On Behalf Of Sandfuchs, Thorsten
Sent: Freitag, 1. Juni 2012 10:02
To: fiware-testbed at lists.fi-ware.eu
Subject: [Fiware-testbed] Recommended Process for Validation


Dear colleagues,

concerning our ongoing validation planning I think it might make sense to at least draft an initial (possible) validation plan as blueprint for the UC projects for them to adapt.

As this is hopefully pretty straight forward and can be already done even without much dependencies on the current (delayed) activities, I  think we should start the discussion now. This would as well contribute to our deliverable M10.5.a (due in M18) - but can be exploited already in mid June or July, once we approach the UC projects and jointly do the concrete validation planning.

Reference: p 191/DoW "The first of this set of documents is the description of the process the Use Cases Projects will be recommended to follow in order to validate their applications on the FI-WARE testbed."



I would like to input the following rough process description which might fulfill this "recommended" validation planning, for your review and feedback.

Once initially reviewed and commented, we should jointly setup a wiki page accordingly.



Recommended Validation Planning Process



This document outlines time relevant tasks and potential major milestones for FIWARE platform validation planning. It can be used as a blueprint for your validation planning.



Roles involved:

o   Testbed coordinator: should be assigned on a case by case bases for each and every validation phase. Direct contact and

o   UC validation coordinator: should be assigned as coordinator of validation activities and distribution of information.

o   Validation user group: (potential) users carrying out the validation execution

o   GE provider: can be addressed for presentation and walk-through of their components and for 1st and 2nd level questions in relation to the involved GEs.





-1.  Validation Preparation phase (to be carried out before validation execution)

Duration: ~1-2 month

-          Purpose: Plan validation (concrete timing, scope and initial scenario)

-          DoW: "The validation plan will 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 testbed team for platform readiness & scenario suitability



1.       Introduction to FIWARE platform and testbed phase (optional)

Duration: 1-2 weeks

-          Schedule meeting with Testbed coordinator and complete validation team

-          Testbed gives system endpoints and needed access information to the team and gives general introduction to the 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



2.       Platform exploration phase

Duration: 1-3 month

-          Mainly read-only usage of components and guided tours by GE providers and/or WP-leads

-          WP wise run-through - mainly presentation of capabilities and initial discussion on how the scenario can be validated on the platform

-          Validation team to refine scenario, based on first insights. Paper Mock-ups. Findings to persist in validation report first draft.

-          Validation scenario should be fixed after this phase

-          Identification of main contacts & individual touch-points for domain experts on UC and

-          Especially if a larger "Adoption & integration" phase is planned, this needs to be known as early as possible

Recommendation: Schedule interims presentation to UC-WPL and FIWARE-WPL/WPA teams with refined validation plan & scenario adaption at the end of this phase

Recommendation: Agreement (UC & FIWRE) of which further phases the validation will touch upon at the end of this phase



3.       Adaptation phase (optional)

Duration: 2-3 month

-          Introduction of use case (scenario) specific content and data on the platform

-          Further refinement of scenario and first draft of traceability matrix

-          Changes and customization of GEs within the designed scope and functionality

-          Tasks: configuration, customization, introduction of new content, driven by the scenario

-          In parallel: planning of adoption & integration phase (if applicable)

Recommendation: Capture findings



4.       Adoption & integration phase (optional)

Duration: 2-3 month

-          Introduction of use case specific enablers to the testbed

-          Integration of specific components in testbed infrastructure

-          Subsequent refinements of components based on integration requirements



5.       Feedback phase & Definition of potential next steps

Duration: 1-2 weeks

-          Gather subsequent scenario & further development opportunities

-          Finalize definition of gaps and address missing functionality on GE/WP level in the FIWARE trackers

-          Selection and prioritization of defined gaps

-          Complete traceability matrix

-          Complete final report and recommended next steps



Open Questions:

-          Is the overall approach "agile" enough? We could further recommend:

ð  Short cycles: plan do check act

ð  Direct customer feedback?

-          Will have provide a dedicated validation plan template? The validation plan will have to state "scenario description", sizing information, functional & non-functional requierements - basically the things we already capture in our questionnaire, should we as well define a formal "Template" for this?

-          What do you think - is this approach too time consuming and/or does it post too much effort?

-          How to use the existing trackers best for validation? Should we push already early in the process to use a testbed-tracker?

-          How formal should be go?

o   Currently I didn't outline major milestones as "gates". If we would do so, there would be formal sign-off and gap analysis on each gate - and more effort on both sides.

o   Closed and open validation phases formally - with or without sign-off by testbed team? AB? Steering boards?

-          Legal topics: Iff UC would introduce testers which are outside of the FI-PPP - do we need to take care and mention the needed contracting with external parties in this process?



Thanks for any comment and additions & best regards,



                                                                              /Thorsten

--



Thorsten Sandfuchs



SAP AG



SAP Research Center Karlsruhe



Vincenz-Priessnitz-Strasse 1

D - 76131 Karlsruhe

www.sap.com<http://www.sap.com>





Pflichtangaben/Mandatory Disclosure Statements: http://www.sap.com/company/legal/impressum.epx



Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.



This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.


Please consider the environment before printing this mail!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-testbed/attachments/20120720/d3db5d6f/attachment.html>