Integration Plan
From Symbian Developer Community
The Integration Plan contains selected package features from the package backlogs which are followed closely by the Release Council in order to understand the status of the releases and the availability of content in the kits.
Week05 Update
The following graph represents that current contribution intent for key features to be integrated into the Symbian SCM system:
Main updates this week are:
- SMP OS layer is now tested for safeness at 70% using SW methods and 55% using SMP HW
- The Symbian^3 integration plan has 7 package features pending out of 43 (i.e 30 already delivered)
- The current PDK contains all the features in the week04 baseline - the fully EPL PDK is planned for week06.
- The Symbian^4 package backlogs contain now over 181 package features. This should allow us to flesh out an integration plan for Symbian^4 shortly
Getting the Integration Plan
To download the latest version of the integration plan, please click here
Creating the Integration Plan
What is a Key Feature?
A Key Feature (KF) is a high level feature that has been selected by the Release Council as critical for a particular release, for one or more of the reasons below:
- The feature has a large or complex integration
- The feature has a pervasive impact on the platform
- The feature is a headline selling point for the platform that raises interest in the community. This is highlighted by the F&R Council
- The features is requested to be added by the release council
An example of a KF is the new graphics architecture (ScreenPlay) in S^3. The KF list is approved and owned by the Release Council
How do we track the evolution of Key Features?
A KF is tracked to completion by selecting a set of representative package features that enable or demonstrate the main use cases targeted for the release. We aim to have all the package features that are part of the integration plan documented in our feature tracker.
Key Features are selected by the Release Council. The release council bases its selection on recommendations from the F&R council, the Technology Domain Managers and the Release Management Team. The list is reviewed, expanded and approved by the Release Council.
Supporting package features are selected from the package backlogs by the Release Management Team, and referenced with KFs and approved BC breaks.
Reading the Integration Plan
Our aim is to collect information provided by the package owners and use it to analyse the health of the release. We have a regular two-week heartbeat for our kit releases and tracking feature increments. If you are familiar with Agile software development you will recognise the two-week integration cycle.
Any data beyond six months ahead of “today” is displayed in quarters since we need to remain flexible and responsive to change (a “scaling agile” practice). We consider that the detailed plan beyond three months is fluid and beyond six months is only an indication of intent.
It is probably worth noting at this point that the integration plan is based on voluntary contributions, and that we aim to increase confidence in it by promoting frequent stage deliveries and asking contributors to provide regular updates when changes occur.
We will provide additional value to the Bugzilla data by providing a statement of the risk level of each contribution.
The risk level reflects the release manager’s personal judgement after taking into consideration other aspects of the submission such as dependencies with other backlog items, IP licensing issues, engagement of the contributors with package owners or the foundation team and so on. This is signified by a B.R.A.G. (Black Red Amber Green) status.
Other Related Symbian Release Planning Pages
- The Symbian Release Plan
- The Symbian Integration Plan
- The Symbian Kit Schedule
- The Symbian Release Model
- The Release Council
Comments
Sign in to comment…
