What an Agile architect can learn from hurricane meteorologist... (paper review)
http://dx.doi.org.proxy.lib.chalmers.se/10.1109/MS.2011.152
For a late night reading I've chosen to look at the IEEE software's latest issue. What I've found was really nice - a paper discussing making decisions and predictions in Agile architecting.
I recommend reading this paper since it discusses the uncertainty of software architecting in the Agile software development environment. The analogy to the hurricane is, of course, to get the attention, but the overall article has a few nice points:
- predictions: "it's ok to be a little wrong"
- requirements for architects: "should know everything"
- BDUP (Bad Design Up Front) vs. NDUP (No Design Up Front)
Generally, a nice food for thought for the saturday evening...
Saturday, October 29, 2011
Friday, October 28, 2011
Feature planning in Agile SD... (paper)
Feature planning in distributed Agile software development...
http://www.springerlink.com/content/978-3-642-20676-4/#section=891594&page=1&locus=0
A standard problem with Agile software development with multiple parallel teams is the dependency between teams. The teams that develop features/parts of features which are dependent on each other (or one is dependent on the other one) cannot work in parallel. Parallel work is then a recipe for disaster or at least a serious headache...
I've looks for some support in this matter for a while now and this is one of the very good articles that I can recommend. The article shows how distributed teams can plan feature development to avoid parallel development of the same functionality.
In a nutshell: the authors use the concepts of feature architectural similarity analysis and feature chunk contruction to calculate distances between features and use that as an input for feature planning. The idea is pretty simple, although there is some maths in the paper.
Definitely a recommended reading for this weekend... although not for a friday evening.
Wednesday, October 26, 2011
Embedded system design for automotive... (paper review)
In search for useful metrics - embedded system design for automotive applications
http://dx.doi.org/10.1109/MC.2007.344
In search for metrics to measure dependability of software systems, I've encountered this interesting article. It has nothing to do with Agile or development processes - it's the real deal measuring product properties.
The metrics described in this article are mainly related to the automotive software development, but they gave me an idea that we should be very observant on how we can measure dependability in early development phases.
Say that we have an agile project in an automotive domain, when does it make sense to measure dependability? Which metrics should we collect over time? Which models should we measure?
And most importantly, how do we provide teams with the support to reason about dependability when no product is around...
It's interesting to look into this paper to get a few research ideas out.
http://dx.doi.org/10.1109/MC.2007.344
In search for metrics to measure dependability of software systems, I've encountered this interesting article. It has nothing to do with Agile or development processes - it's the real deal measuring product properties.
The metrics described in this article are mainly related to the automotive software development, but they gave me an idea that we should be very observant on how we can measure dependability in early development phases.
Say that we have an agile project in an automotive domain, when does it make sense to measure dependability? Which metrics should we collect over time? Which models should we measure?
And most importantly, how do we provide teams with the support to reason about dependability when no product is around...
It's interesting to look into this paper to get a few research ideas out.
Agile methods in European embedded software development companies ... a survey
A survey on the actual use and usefuleness of XP and Scrum (paper review)
http://dx.doi.org/10.1049/iet-sen:20070038
Agile methods are here to stay one would say. However, I often stumble upon a question how much they are used and how. In this particular paper the authors review the actual use of XP and Scrum in embedded software development companies in Europe.
Some of the interesting findings and reflections:
- most commonly adopted Agile practice was the use of "open office space" - great, but is that really one of Agile principles?
- 51% of respondents claimed that core practices of XP like pair-programming are "rarely" or "never" practiced in their companies - hmmm.... interesting
What I find very interesting was the fact that the authors looked at both the use and usefulness of the practices - and revealed that adoption of Agile is not friction-free (ca. 28% of respondents admitted that they've had negative expectations for the Agile adoption).
One of the things I would like to see a reflection on is the situation in Sweden and Finland with a number of large companies working according to Agile, e.g. http://onlinelibrary.wiley.com/doi/10.1002/spip.355/abstract.
http://dx.doi.org/10.1049/iet-sen:20070038
Agile methods are here to stay one would say. However, I often stumble upon a question how much they are used and how. In this particular paper the authors review the actual use of XP and Scrum in embedded software development companies in Europe.
Some of the interesting findings and reflections:
- most commonly adopted Agile practice was the use of "open office space" - great, but is that really one of Agile principles?
- 51% of respondents claimed that core practices of XP like pair-programming are "rarely" or "never" practiced in their companies - hmmm.... interesting
What I find very interesting was the fact that the authors looked at both the use and usefulness of the practices - and revealed that adoption of Agile is not friction-free (ca. 28% of respondents admitted that they've had negative expectations for the Agile adoption).
One of the things I would like to see a reflection on is the situation in Sweden and Finland with a number of large companies working according to Agile, e.g. http://onlinelibrary.wiley.com/doi/10.1002/spip.355/abstract.
Monday, October 24, 2011
Software metrics - what every software engineer should know
Software metrics curriculum from SEI:
Quite often we get questions about what kind of metrics exist and how they should be used. Many companies look for specific kind of metrics or would just like to know how many they have/do not have.
I've usually steered my answer based on the curriculum from SEI's metrics course (available via the link below). The curriculum contains information about metrics for project managers, quality managers, etc. It is not complete, as it is only a curriculum, but it is a very good dictionary of what every software engineer should know about metrics.
IMHO: advanced software engineers should know something about the measurement theory as well, but that is a subject for a separate discussion.
My recommendation is to complement this reading with the standards:
- ISO/IEC 159393: Software and systems engineering - measurement processes
- ISO/IEC 25000 series
- ISO/IEC 9001: 2008 (Quality metrics)
For researchers: I recommend section III.
For companies: I recommend section I and II.
http://www.google.com/url?sa=t&rct=j&q=software%20metrics&source=web&cd=12&ved=0CCoQFjABOAo&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.83.6110%26rep%3Drep1%26type%3Dpdf&ei=Ml-kTtylBqXk4QTF8-jJBA&usg=AFQjCNEFrTg-n5iD5Cy3XmQiU5qU702W_A&sig2=91zNibxZ-Kkas0WmxcihwA
Quite often we get questions about what kind of metrics exist and how they should be used. Many companies look for specific kind of metrics or would just like to know how many they have/do not have.
I've usually steered my answer based on the curriculum from SEI's metrics course (available via the link below). The curriculum contains information about metrics for project managers, quality managers, etc. It is not complete, as it is only a curriculum, but it is a very good dictionary of what every software engineer should know about metrics.
IMHO: advanced software engineers should know something about the measurement theory as well, but that is a subject for a separate discussion.
My recommendation is to complement this reading with the standards:
- ISO/IEC 159393: Software and systems engineering - measurement processes
- ISO/IEC 25000 series
- ISO/IEC 9001: 2008 (Quality metrics)
For researchers: I recommend section III.
For companies: I recommend section I and II.
http://www.google.com/url?sa=t&rct=j&q=software%20metrics&source=web&cd=12&ved=0CCoQFjABOAo&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.83.6110%26rep%3Drep1%26type%3Dpdf&ei=Ml-kTtylBqXk4QTF8-jJBA&usg=AFQjCNEFrTg-n5iD5Cy3XmQiU5qU702W_A&sig2=91zNibxZ-Kkas0WmxcihwA
Sunday, October 23, 2011
Software metrics: A roadmap (review)
Software Metrics: A Roadmap (review):
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.98.374&rep=rep1&type=pdf
On a sunday evening I've decided to settle for some easy reading about metrics and searched for "dependability" metrics, hoping this would yield interesting reading... Well, in the end I've settled for reading the classical roadmap once again.
The article is very good and I sincerely recommend reading the example about the road traffic (see the link above takes you directly to the paper).
In short, the example talks about the "undesired" behavior yielded by blindly obeying the statistics - if one wanted to opt for "safe" driving one should drive during the winter when the weather is a dreary. Obviously this is not true, but this is what the data suggests.
In the studies in industry, however, we often can observe the need for metrics, statistics, and indicators that would replace the common sense and could be blindly obeyed. However, it is (almost) impossible to provide this kind of metrics.
What I really like about this article is the set of causality aspects of metrics, the uncertainty of data and (above all) the need to complement quantitative data with other sources of information - IMHO "gut feeling".
Have a nice sunday reading...
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.98.374&rep=rep1&type=pdf
On a sunday evening I've decided to settle for some easy reading about metrics and searched for "dependability" metrics, hoping this would yield interesting reading... Well, in the end I've settled for reading the classical roadmap once again.
The article is very good and I sincerely recommend reading the example about the road traffic (see the link above takes you directly to the paper).
In short, the example talks about the "undesired" behavior yielded by blindly obeying the statistics - if one wanted to opt for "safe" driving one should drive during the winter when the weather is a dreary. Obviously this is not true, but this is what the data suggests.
In the studies in industry, however, we often can observe the need for metrics, statistics, and indicators that would replace the common sense and could be blindly obeyed. However, it is (almost) impossible to provide this kind of metrics.
What I really like about this article is the set of causality aspects of metrics, the uncertainty of data and (above all) the need to complement quantitative data with other sources of information - IMHO "gut feeling".
Have a nice sunday reading...
Friday, October 21, 2011
Tracking the Evolution of Object-Oriented... (paper review)
Tracking the evolution of object-oriented metrics... (paper review)
http://www.springerlink.com/content/ml1ml2053441g898/
This paper shows trends in how CK OO metrics evolve during mutliple iterations in Agile projects. The trends look interesing, but the paper cannot draw conclusions about what the trends mean.
What I find as the most interesting:
- the paper presents trends and focuses on trends (the values are not important)
- the trends are not always growing - i.e. there are iterations where refactoring is applied and this does improve the situation.
I think this approach is in line with the Agile thinking - do not compute the metric once, do it iteratively. I wonder how many Agile-thinking companies do it the same way.
This paper can be used as an example of what kind of values OO metrics can have in Agile projects. The good thing is that the study was not calculated on a single project, but in many projects.
http://www.springerlink.com/content/ml1ml2053441g898/
This paper shows trends in how CK OO metrics evolve during mutliple iterations in Agile projects. The trends look interesing, but the paper cannot draw conclusions about what the trends mean.
What I find as the most interesting:
- the paper presents trends and focuses on trends (the values are not important)
- the trends are not always growing - i.e. there are iterations where refactoring is applied and this does improve the situation.
I think this approach is in line with the Agile thinking - do not compute the metric once, do it iteratively. I wonder how many Agile-thinking companies do it the same way.
This paper can be used as an example of what kind of values OO metrics can have in Agile projects. The good thing is that the study was not calculated on a single project, but in many projects.
Subscribe to:
Posts (Atom)