Cases of QA in Lean software development...
http://lnkd.in/SYcD_F
This weekend my Twitter feed showed a series of great articles from Tom Gilb @TomGilb where he provided a set of really interesting examples of companies who moved towards Lean.
The examples include Google and how they work with Chrome. What I like about that example was the analysis of short- and long- term costs of low quality. Not monetary or resource costs, but branding costs, for example - variety of programming languages which make it hard to debug lead to winning grounds of languages like Python or Ruby.
Another case from Hanssen which he shows is a great example of how companies engage customers and shorten interations.
Following the link above opens up a lot of great material about QA.
@MiroslawStaron
Sunday, November 25, 2012
Wednesday, November 21, 2012
More projects == better defect predictions?
More efficient defect prediction when using data from multiple projects?
http://dx.doi.org/10.1016/j.infsof.2012.10.003
By looking at the newest research in the defect prediction field I've discovered this piece of work which intrigued me a bit. Usually we build statistical models in forms of equations describing defect inflows or use analogy based estimates - we use historical data to create models for new projects. This usually works fine, but this paper discusses things one step further, namely (and I quote):
RQ2: How much within project data should be enriched with data from other projects to achieve comparable performance with full within project data predictions?
The results show that using only 10% of the data can yield results of the same quality, which can significantly improve the cost-efficiency of defect predictions in industrial contexts.
@Miroslaw Staron
Friday, September 14, 2012
Supporting Agile transformation with defect management...
Supporting Agile transformation...
http://dspace.cc.tut.fi/dpub/handle/123456789/21063
Usually I write about articles, but this time I wanted to point out a doctoral thesis work from a large telecom company in Finland. The company has undergone a transformation from project-driven to Agile software development and it seems that they are gaining on the market, looking at more feature-rich products and faster cycles.
I especially recommend Part IV where they discuss the effects of Agile transformation on defect management and quality. Not many companies were able to measure such a strong effect. I will use this reference often to point toward numbers :)
@MiroslawStaron
http://dspace.cc.tut.fi/dpub/handle/123456789/21063
Usually I write about articles, but this time I wanted to point out a doctoral thesis work from a large telecom company in Finland. The company has undergone a transformation from project-driven to Agile software development and it seems that they are gaining on the market, looking at more feature-rich products and faster cycles.
I especially recommend Part IV where they discuss the effects of Agile transformation on defect management and quality. Not many companies were able to measure such a strong effect. I will use this reference often to point toward numbers :)
@MiroslawStaron
Friday, August 10, 2012
Relationships about commenting the code and software bugs...
On the relationship between comment update practices and Software Bugs - a recent paper from JSS
http://dx.doi.org/10.1016/j.jss.2011.09.019
Looking closer and closer into the field of Mining Software Repositories and finding dependencies between code and defects, I've come across this paper. It shows how insufficient or wrong commenting influences quality.
I am sure I need not convince anyone about the direction of this relationship :) However, i wanted to highlight the actual numbers that they've worked with:
- If the number of inconsistent changes are large, then adding new changes (even if they are consistent) usually leads to bugs.
To sum up - interesting article to read for all of us who want to build automated prediction systems for defects.
@MiroslawStaron
http://dx.doi.org/10.1016/j.jss.2011.09.019
Looking closer and closer into the field of Mining Software Repositories and finding dependencies between code and defects, I've come across this paper. It shows how insufficient or wrong commenting influences quality.
I am sure I need not convince anyone about the direction of this relationship :) However, i wanted to highlight the actual numbers that they've worked with:
- In FreeBSD, there are 2x more inconsistency (i.e. misleading) comments that the consistent ones - this causes the developers to mistrust comments and skip them at all. A vicious circle
- Eclipse has a majority of consistent comments - probably caused by the involvment of more rigid processes.
- A link to the graphs showing these dependencies: http://www.sciencedirect.com/science/article/pii/S016412121100238X#gr2
- If the number of inconsistent changes are large, then adding new changes (even if they are consistent) usually leads to bugs.
To sum up - interesting article to read for all of us who want to build automated prediction systems for defects.
@MiroslawStaron
Wednesday, July 4, 2012
ISO 26262 and Agile practices
ISO 26262 and Agile practices:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/invisiblethread/entry/five_benefits_of_agile_practices?lang=en
This is a very interesting article tackling a very tangible problem in industry - footprint of standard implementation. The article explains how the process footprint can be decreased by adopting certain Agile practices.
The article shows that there can be possibilities of tailoring agile to heavier processes where (for example) safety requirements are not something to play around with.
In non-Agile processes, the standard compliance usually takes a lot of effort and requires a lot of documentation. This article shows how this can be combined with agile practices on "minimum" documentation.
Recommended reading for all interested in standards implementation - not only in the automotive industry.
@MiroslawStaron
https://www.ibm.com/developerworks/mydeveloperworks/blogs/invisiblethread/entry/five_benefits_of_agile_practices?lang=en
This is a very interesting article tackling a very tangible problem in industry - footprint of standard implementation. The article explains how the process footprint can be decreased by adopting certain Agile practices.
The article shows that there can be possibilities of tailoring agile to heavier processes where (for example) safety requirements are not something to play around with.
In non-Agile processes, the standard compliance usually takes a lot of effort and requires a lot of documentation. This article shows how this can be combined with agile practices on "minimum" documentation.
Recommended reading for all interested in standards implementation - not only in the automotive industry.
@MiroslawStaron
Tuesday, July 3, 2012
Agile metrics from IBM
Software Econometrics
http://public.dhe.ibm.com/common/ssi/ecm/en/ral14037usen/RAL14037USEN.PDF
This is a nice paper that conceptually describes goals with metrics in the Agile software development. A very good starter reading. I like the concepts and the ideology, but what I lack in the paper is the depth of how to measure things.
Some aspects that come to my mind as and old "metric" guy are:
- How to define "change" in the cost of change metric? What is the difference between rework and change?
- How to define scrap and rework? How to measure those concepts in software development? Is the first feature that one develops to show proof-of-concept a waste - or is it a learning activity?
In short - nice article, but requires digging deeper into the context.
@MiroslawStaron
http://public.dhe.ibm.com/common/ssi/ecm/en/ral14037usen/RAL14037USEN.PDF
This is a nice paper that conceptually describes goals with metrics in the Agile software development. A very good starter reading. I like the concepts and the ideology, but what I lack in the paper is the depth of how to measure things.
Some aspects that come to my mind as and old "metric" guy are:
- How to define "change" in the cost of change metric? What is the difference between rework and change?
- How to define scrap and rework? How to measure those concepts in software development? Is the first feature that one develops to show proof-of-concept a waste - or is it a learning activity?
In short - nice article, but requires digging deeper into the context.
@MiroslawStaron
Tuesday, June 5, 2012
Selecting self-managing teams...
Selecting and understanding self-managing teams...
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=5287005&contentType=Journals+%26+Magazines&sortType%3Dasc_p_Sequence%26filter%3DAND%28p_IS_Number%3A5286993%29
The dream about self-managing, high performance teams is still out there. Although it seems that benefits of those teams are plenty, one could always start thinking about the environment where they function best.
In this article in IEEE Software the authors look at these environments. Shared leadership, common decision-making and trust seem to be one of the most important internal characteristics of the teams. Knowledge sharing and organizational support were the most important factors at the organizational level.
I recommend this article as it can open eyes on the fact that having x-functional teams (testers, designers, analysts,...) might not be enough to achieve high team performance. And high team performance is one of the first steps towards high organizational performance.
@MiroslawStaron
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=5287005&contentType=Journals+%26+Magazines&sortType%3Dasc_p_Sequence%26filter%3DAND%28p_IS_Number%3A5286993%29
The dream about self-managing, high performance teams is still out there. Although it seems that benefits of those teams are plenty, one could always start thinking about the environment where they function best.
In this article in IEEE Software the authors look at these environments. Shared leadership, common decision-making and trust seem to be one of the most important internal characteristics of the teams. Knowledge sharing and organizational support were the most important factors at the organizational level.
I recommend this article as it can open eyes on the fact that having x-functional teams (testers, designers, analysts,...) might not be enough to achieve high team performance. And high team performance is one of the first steps towards high organizational performance.
@MiroslawStaron
Subscribe to:
Posts (Atom)