[Fiware-cloud] Planning of the 1st major release

Alex Glikson GLIKSON at il.ibm.com
Fri Oct 28 14:20:43 CEST 2011


Team,

While outlining our features and user stories for the first minor
release/sprint, it is important to make sure that we are in sync in the
broader perspective of the first major release (M12) -- which is our next
official deliverable. Hence, I would like to outline the main objectives
that we should aim at, the way I see it (Juanjo -- would appreciate your
input). This will help us deciding on the exact scope of each of the two
releases (Nov-Jan, Feb-Apr).

Our main objectives for M12 include:
   detailed architecture, GEs specification
   design, integration of baseline assets to create functional end-to-end
   stack, detailed gap analysis
   implementation of few selected enhancements (preferably including those
   which can be demonstrated end-to-end)
   user guide, admin guide, programming guide
   detailed requirements specification for 2nd major release --
   incorporating feedback from UC projects (M24)
   design of new functions to be developed targeting 2nd major release
   (M24)

Please, take the above objectives into consideration when planning the
first minor release. Of course, feel free to comment on the list above
and/or suggest improvements.

For Resource Management GE, I envision the following features
(draft/partial list):
   Setup of internal testbed
   Basic environment up and running -- including partial set of baseline
   assets (OpenStack, Glance, maybe others)
   Education and gap analysis
   Selection of enhancements to be implemented for the first major release
   Implement few of the selected enhancements targeting the first major
   release (TBD)
   Design of individual capabilities, focusing on enhancements and new
   functions tentatively targeted for the second major release (M24)
      resource pooling, QoS, capacity mgmt, monitoring, network, storage,
      image library, placement, federation, security, APIs, fabric,
      management of physical machines, security
   Design of integration with Service Manager
   "Digest" requirements of the UC Projects related to Resource Management
   GE

This way the last 3 months can be dedicated to implementation of the
enhancements/new functions, further integration (including cross-GE),
documentation of M12 deliverables (especially A and D above), etc.

Please, note that although the final integration between GEs is planned for
months 13-15, we should explore the integration as soon as possible
(especially between Service Manager and Resource Manager) -- because I
expect this to be the most significant risk in delivering and end-to-end
functional stack by M15, and the way to mitigate it (and avoid surprised
too late in the cycle) is to start the integration sooner rather than later
-- desirably even during the first minor release.

Would appreciate your input.

Regards,
Alex



From:	Alex Glikson/Haifa/IBM at IBMIL
To:	fiware-cloud at lists.fi-ware.eu
Date:	27/10/2011 12:21 AM
Subject:	Re: [Fiware-cloud] WP status
Sent by:	fiware-cloud-bounces at lists.fi-ware.eu



My comments below

One more important thing: it is very important to outline in the
description of each Epic the scope of work to be done -- which also implies
that we need to mention the baseline assets that will be used. It is
important that whoever reads an Epic, understands what we are trying to,
why, what already exists as part of the baseline assets, and what is the
'delta', or work to be done, associated with this particular work item --
integration, enhancements, new pieces, etc.

Regards,
Alex

P.S. I've completed the description of most of the RM epics



From:        Alex Glikson/Haifa/IBM at IBMIL
To:        fiware-cloud at lists.fi-ware.eu
Date:        26/10/2011 08:14 AM
Subject:        Re: [Fiware-cloud] WP status
Sent by:        fiware-cloud-bounces at lists.fi-ware.eu



Andy, Fernando -- thanks for the initiative! This is very helpful. I will
send more detailed comments later. One important comment, meanwhile:

Regarding user stories and sprints -- I'm not sure we should manage user
stories in the same public tracker. That's why the "User Story" category
and the "Sprint" field are not there.
Moreover, strictly speaking, those are not supposed to be part of the
Backlog -- which is by definition a set of work items which have not been
scheduled to any sprint.

So, besides completing and reviewing Themes and Epics in the backlog, and
completing the description of baseline assets we want to use, what I would
like to ask from all of you is to send me (or to the list) a much more
detailed description, in whatever format is convenient for you (sets of
bullets are fine for now -- we can then attach them to the wiki entry) of
the following:
1) Features that you would like to include in the first minor release --
outlining specific scope of work that you expect to be completed by
January, 31th, 2012, and
2) User Stories that you would like to include in the first sprint -- i.e.,
specific work items that will be done by November 30th.

For both, I would like to see a very clear 'acceptance criteria' -- how
exactly will we measure and validate whether the corresponding work items
are done, and what can others expect as an outcome of this work.

Thanks,
Alex




From:        FERNANDO LOPEZ AGUILAR <fla at tid.es>
To:        "Edmonds, AndrewX" <andrewx.edmonds at intel.com>
Cc:        Alex Glikson/Haifa/IBM at IBMIL
Date:        25/10/2011 07:20 PM
Subject:        Re: WP status



Thank you Andy,

I write them inline.


Tracker
* Only 2 from Alex and the rest are from Fernando (currently only EPICs and
Features -- this is OK, as explained above)
* FI-WARE Backlog Entry Type without User-Story option.
* We have release box but we have to change it to FI-WARE Release Id box
and FI-WARE Sprint Id box.
* We need to specify there for each EPIC, Feature and User Story in which
Release and Sprint we plan to develop it. Not really. Only for the first
one. The priorities might change over time, so we shouldn't try deciding up
front for longer than one minor release.
* We have to select which Feature and User Stories we want to implement in
the first minor release.

Wiki Asset Descriptions
•       None from Cloud Proxy
•       None from Self-service Interfaces
•       Listed but not detailed from Monitoring
•       None that covers T4.2 -- Updated
* We have to differentiate between basseline asserts and needed assests.
The real asset is explained in more detail (e.g. Claudia in IaaS SM) and
the others are explained with less details (see MySQL). But the sections
that we use would be the same that all the assets have to use.

We should describe here *only* the baseline assets. If they have
pre-requisites -- it is described in their documentation. and we may
mention that within the description of the asset. But we should not mention
them in the main list.

Wiki Epics
* Here I want to give you some clarification about the different between
EPICs, Features and User Stories.
* EPICs is anything that we planned to develop (or have any idea about the
expended time to develop it) in a period of time bigger than a minor
release (3 months).
* Feature is anything that we planned to develop (or have any idea about
the expended time to develop it) in a period of time less than a minor
release (3 months).
* User Story is anything that we planned to develop (or have any idea about
the expended time to develop it) in a period of time equal to a sprint (1
months). [or less]
* We have provided neither Features or User Stories except for IaaS SM and
PaaS Mgmt. Yep. As I mentioned above, we must update both the Wiki and the
Tracker with features for the first release, and also outline the stories
for the first sprint.
* Anyway, I could see some Epics like
FIWARE.Epic.Cloud.ResourceManager.Security.APIs
which is not a EPIC (IMHO), The Epic would be
FIWARE.Epic.Cloud.ResourceManager.Security.  This should be a User Story.
Well, it is a matter of scope and sizing. If we figure out that the entire
Epic can be covered in a single sprint (which I don't believe is the case)
-- we can definitely 'downgrade' it to a story.

IaaS Data Center Resource Management: 9/20 not complete
•       FIWARE.Epic.Cloud.ResourceManager.MgmtFabric -- done
•       FIWARE.Epic.Cloud.ResourceManager.QoS -- done
•       FIWARE.Epic.Cloud.ResourceManager.Mobility -- done
•       FIWARE.Epic.Cloud.ResourceManager.Placement -- done
•       FIWARE.Epic.Cloud.ResourceManager.PhysPlatformMgmt
•       FIWARE.Epic.Cloud.ResourceManager.Capacity -- done
•       FIWARE.Epic.Cloud.ResourceManager.Toolkit
•       FIWARE.Epic.Cloud.ResourceManager.Federation
•       FIWARE.Epic.Cloud.ResourceManager.Security.APIs
* IMHO, OCCI is not a basseline asset, it is a specific interface within
the rest of baseline assets (Openstack Nova, Glance, ...).
* Each Basseline assets have to describe the following subsections
Brief Description
Programming artifacts
Technologies used
Runtime pre-requisites (including Known software requirements)
IPR
Publicly available documentation

except the needed assests like MySQL in IaaS SM that only need to describe
Brief Description
IPR
Publicly available documentation
* There are no Features and User Stories

Object Storage
* Openstack switch, need to describe Technologies used and Runtime
pre-requisites subsections.
* No Features
* No User Stories (remenber that *.Security.SSO and *.Security.RBAC should
be a User Stories).

Security 1/2 not complete
•       FIWARE.Epic.Cloud.Security.RBAC
* Openstack keynote, need to describe Technologies used and Runtime
pre-requisites subsections.
* Check if the Epics are Features.

Self-Service Interfaces: 4/5 not complete
* No Baseline assets described
•       FIWARE.Epic.Cloud.SelfServiceInterfaces.UserCLI
•       FIWARE.Epic.Cloud.SelfServiceInterfaces.AdminCLI
•       FIWARE.Epic.Cloud.SelfServiceInterfaces.AdminPortal
•       FIWARE.Epic.Cloud.SelfServiceInterfaces.Security
* No Features, no User Stories

Cloud Proxy: 5/8 not complete
* No baseline asset described
•       FIWARE.Epic.Cloud.CloudProxy.VirtualizationLayer
•       FIWARE.Epic.Cloud.CloudProxy.ManagementAPI
•       FIWARE.Epic.Cloud.CloudProxy.CloudAppProvisioning
•       FIWARE.Epic.Cloud.CloudProxy.ManagementProxy
•       FIWARE.Epic.Cloud.CloudProxy.Security
* Only Epics

Monitoring: 5/11 not complete
* Some baseline assets without description (working in progress between
Fernando and Andy)
•       FIWARE.Epic.Cloud.Monitoring.Analysis.SLAIntegration
•       FIWARE.Epic.Cloud.Monitoring.Visualization
•       FIWARE.Epic.Cloud.Monitoring.Management
•       FIWARE.Epic.Cloud.Monitoring.Security.Metrics
•       FIWARE.Epic.Cloud.Monitoring.ServiceMgrIntegration
* Only Epics.

Themes: 1/3 not complete
•       Accounting

@Andy TODO:
•       Supply monitoring asset details
•       FIWARE.Epic.Cloud.Security.RBAC
•       FIWARE.Epic.Cloud.Security.APIs
•       FIWARE.Epic.Cloud.Monitoring.Visualization
•       FIWARE.Epic.Cloud.Monitoring.Management
•       FIWARE.Epic.Cloud.Monitoring.Security.Metrics

@Alex TODO:
* Refine the tracker page.

@All
* Refine the Epics, Features and User Stories
* Provide baseline assets with their appropriate description information
* Provide information in the tracker system (be careful, in the FIWARE
Cloud track section, not in the FIWARE track section)
* Provide the list of Features and User Stories to be implemented in the
first minor release and put this information into the tracker system.


I think that this information could be send to the rest of cloud members. I
hope that I could take some light into the dark.

Best regards,

Fernando López Aguilar
Cloud Computing
fla at tid dot es
+34 914 832 729
Telefónica I+D (R&D)
Ronda de la Comunicación s/n
Distrito C, Edificio Oeste 1, Planta 5
28050 Madrid, Spain



El 25/10/2011, a las 18:02, Edmonds, AndrewX escribió:


-------------------------------------------------------------
Intel Ireland Limited (Branch)
Collinstown Industrial Park, Leixlip, County Kildare, Ireland
Registered Number: E902934

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


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
_______________________________________________
Fiware-cloud mailing list
Fiware-cloud at lists.fi-ware.eu
http://lists.fi-ware.eu/listinfo/fiware-cloud
_______________________________________________
Fiware-cloud mailing list
Fiware-cloud at lists.fi-ware.eu
http://lists.fi-ware.eu/listinfo/fiware-cloud


More information about the Old-Fiware-cloud mailing list

You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy   Cookies policy