Did you know that Symbian has already over 10 million lines of code published in our public OSS repositories? Well, that is what Ohloh.net is telling us!
In previous posts, I have refer to the use of bugzilla metrics to take snapshots of quality related statistics. Ohloh is another great example of free services available to open source projects. Over the last few weeks some guys in the team have decided to get Ohloh up and running for Symbian open sourced packages and other supporting assets. We currently have 18 packages open sourced (of a total of 140) and we are working hard to open the rest before end of H1 2010.
I have refered on the past to the capability of reporting metrics against the Symbian Platform. Finally we are there!
This week the team produce the first snapshot of Bug , Code size and Code Churn with real data. The snapshot is to be presented on Friday to the Release Council for feedback. Let’s have a look at it in more detail:
These are graphics auto-generated from Bugtracker Metrics, it allows you to drill down to as much detail as you want. The data in the snapshot is frozen from an specific date, but you can re-run the queries live from the bugtracker metrics interface.
Now that we can measure it, we can start introducing some standard defect management practices.
Every person has a different risk profile. This is the willingness of that person to take a chance to achieve a reward versus the probability of failure. The amount of risk we are willing to take seems to be correlated to the reward promised and the time frame associated to it (i.e. will I get teh reward tomorrow, in 2 or 10 years). Risk profiles of companies are somehow a weighted average of the risk profiles of their employees. Hence, different companies (even in the same market segment) have different risk profiles. Continue reading “Risk Analysis – Integration plan (part 2)”→
Maintaining the current high quality levels of the platform assets is a big priority for both our members and ourselves.
In the past, Symbian Ltd. did a good job at understanding how the software maturity was evolving and when the platform would be ready for releasing. Moving to open source has changed the sources of information available to us and their reliability. So, can we still measure the quality of our platform?
To answer this question, the Release Council launched a working group, back in June, that has identified a set of initial metrics for the job.