Dear readers,
When I started this blog one of the goals was to get feedback and a rewarding dialogue that would help me and others to develop in this field. Unfortunately the amount on monologue from my side has been much greater than the dialogue. Therefore I have decided to put this blog on hold for now.
Kind regards
Anders
Monday 7 June 2010
Tuesday 11 May 2010
Be flexible on product scope. Not time and quality!
Dear reader,
This is the third and last part of “How to reach deadlines”. This is possibly the simplest part and it might be that I am kicking in open doors for many of you. But I am going to write about it anyway.
To be able to be fully flexible on your product scope it is best to work with agile development. If you have developed your product starting from the showstoppers going down the product backlog to the "good to have" stuff, you are in a quite good position to decide when to stop adding new functionality. Many times we think that a functionality is a showstopper, but I am sure that it might not be if you think really hard about it...So be smart and de-scope things that you surely can live without and add them as an upgrade later. Even fundamental things that have been on your showstopper list might not be a showstopper.
For example, with the very much hyped iPhone, I am quite sure that they wanted to have multitasking even in the first release. But they probably ran low on memory when opening too many applications, which creates the feeling of a slow UI etc. They simply had to make a decision not to include the multitasking; to be able to release the product with as good quality as possible. Many people have of course criticized Apple for not having multitasking, but they are selling like no one else, so I think Apple is not too sorry about it. In my opinion it was a very very wise decision and I know another company that might had been more successful today if they would have made the same type of decisions in 2005/06.
So the point is, always look at the scope first and be creative, the showstoppers you think you have might not be showstoppers and never compromise on time and quality.
Best regards
Anders
This is the third and last part of “How to reach deadlines”. This is possibly the simplest part and it might be that I am kicking in open doors for many of you. But I am going to write about it anyway.
To be able to be fully flexible on your product scope it is best to work with agile development. If you have developed your product starting from the showstoppers going down the product backlog to the "good to have" stuff, you are in a quite good position to decide when to stop adding new functionality. Many times we think that a functionality is a showstopper, but I am sure that it might not be if you think really hard about it...So be smart and de-scope things that you surely can live without and add them as an upgrade later. Even fundamental things that have been on your showstopper list might not be a showstopper.
For example, with the very much hyped iPhone, I am quite sure that they wanted to have multitasking even in the first release. But they probably ran low on memory when opening too many applications, which creates the feeling of a slow UI etc. They simply had to make a decision not to include the multitasking; to be able to release the product with as good quality as possible. Many people have of course criticized Apple for not having multitasking, but they are selling like no one else, so I think Apple is not too sorry about it. In my opinion it was a very very wise decision and I know another company that might had been more successful today if they would have made the same type of decisions in 2005/06.
So the point is, always look at the scope first and be creative, the showstoppers you think you have might not be showstoppers and never compromise on time and quality.
Best regards
Anders
Friday 23 April 2010
Create teams that avoids the five dysfunctions
Dear reader,
When I was twenty years old I was still quite naive when it comes to leadership. Then I did my military service as reconnaissance squad leader. Before the recruits started, the squad leaders were trained in leadership. I learnt both the theory around FIRO and about formal/informal leadership. I also had the “pleasure” to practice this leadership training the following 9 months with the recruits that joined my squad. For example we had survival training where we all were pushed to our limits with no food or sleep. This changed me as a person and I discovered many new things about myself and about other people. So why I am writing about this? Because this was probably my biggest paradigm shift in life when it came to understand interpersonal communication or actually even see that it existed. In this post I am going to explain how to generate a paradigm shift for the people in your group to be able to avoid the five dysfunctions and to be able to create a very effective team that everyone enjoys working in.
Below I will explain hands-on how I use the theory from Patrick Lencioni´s book: “The Five Dysfunctions of a Team” and how to avoid them as much as possible.
Just to repeat from the book these are the Five Dysfunctions:
On the second day focus on group psychology, for example the theory from 1958 created by Will Schutz during the Korea war: Fundamental Interpersonal Relations Orientation (FIRO). (Read more about FIRO here). Also explain and talk about the theory around the five dysfunctions. Let the group do group exercises about the two subjects. This will give the team the fundamentals to avoid the dysfunctions, because they will have a common language to start understanding the main issues (i.e. you will get the group communicating with each other about these things). But do not forget that FIRO also tells you that there is a lot of work to get to the “openness phase”. Therefore you can not rush it, but you can give the team the tools to get there (which is a giant step to take and a great step for the team if they can get there, many teams never do) and most of the time you will help the team to get there even quicker than normal.
2: After the kick-off give them each a copy of the book (no I am not sponsored by Patrick Lencioni :-). Also in some cases you have people in the group that might not want to take part in this, some developers might not want to speak in bigger groups or share with the team. Therefore I also recommend you to give everyone a copy of the book “The 7 habits of highly effective people” by Stephen R. Covey. This might/ or will get these few people onboard as well since they might need a bigger paradigm shift to be able to be part of this change. Nonetheless your team will learn a lot form this book.
3: Keep on talking about these issues and talk about how important it is to have a good communication in the group. Since this might be a big change for some people, you need to repeat the message as often you can without sounding like their mother :-). In the long run you will see results and get team members that will enjoy working in your team/group, hence delivering more and producing better results.
4: Use processes and methods that support this way of working. For example “Scrum” that among other things increase communication with daily meetings and/or XP that creates interaction and understanding between team members.
Sounds simple? No it is not, it requires that your leadership is more a servant type of leadership and that you yourself lead by example. I believe that servant leadership will give you better results in the long run, however the world is not black and white, therefore you also have to be able to use other leadership styles if necessary (more on the servant leadership style in another blog post later).
Yet another long post, so I will save the: “be flexible on the product scope. Not time and quality” for a coming post.
Thank you for reading and please give some feedback!
Best regards
Anders
When I was twenty years old I was still quite naive when it comes to leadership. Then I did my military service as reconnaissance squad leader. Before the recruits started, the squad leaders were trained in leadership. I learnt both the theory around FIRO and about formal/informal leadership. I also had the “pleasure” to practice this leadership training the following 9 months with the recruits that joined my squad. For example we had survival training where we all were pushed to our limits with no food or sleep. This changed me as a person and I discovered many new things about myself and about other people. So why I am writing about this? Because this was probably my biggest paradigm shift in life when it came to understand interpersonal communication or actually even see that it existed. In this post I am going to explain how to generate a paradigm shift for the people in your group to be able to avoid the five dysfunctions and to be able to create a very effective team that everyone enjoys working in.
Below I will explain hands-on how I use the theory from Patrick Lencioni´s book: “The Five Dysfunctions of a Team” and how to avoid them as much as possible.
Just to repeat from the book these are the Five Dysfunctions:
- Absence of Trust,
- Fear of Conflict
- Lack of Commitment
- Avoidance of Accountability, and
- Inattention to Results.
On the second day focus on group psychology, for example the theory from 1958 created by Will Schutz during the Korea war: Fundamental Interpersonal Relations Orientation (FIRO). (Read more about FIRO here). Also explain and talk about the theory around the five dysfunctions. Let the group do group exercises about the two subjects. This will give the team the fundamentals to avoid the dysfunctions, because they will have a common language to start understanding the main issues (i.e. you will get the group communicating with each other about these things). But do not forget that FIRO also tells you that there is a lot of work to get to the “openness phase”. Therefore you can not rush it, but you can give the team the tools to get there (which is a giant step to take and a great step for the team if they can get there, many teams never do) and most of the time you will help the team to get there even quicker than normal.
2: After the kick-off give them each a copy of the book (no I am not sponsored by Patrick Lencioni :-). Also in some cases you have people in the group that might not want to take part in this, some developers might not want to speak in bigger groups or share with the team. Therefore I also recommend you to give everyone a copy of the book “The 7 habits of highly effective people” by Stephen R. Covey. This might/ or will get these few people onboard as well since they might need a bigger paradigm shift to be able to be part of this change. Nonetheless your team will learn a lot form this book.
3: Keep on talking about these issues and talk about how important it is to have a good communication in the group. Since this might be a big change for some people, you need to repeat the message as often you can without sounding like their mother :-). In the long run you will see results and get team members that will enjoy working in your team/group, hence delivering more and producing better results.
4: Use processes and methods that support this way of working. For example “Scrum” that among other things increase communication with daily meetings and/or XP that creates interaction and understanding between team members.
Sounds simple? No it is not, it requires that your leadership is more a servant type of leadership and that you yourself lead by example. I believe that servant leadership will give you better results in the long run, however the world is not black and white, therefore you also have to be able to use other leadership styles if necessary (more on the servant leadership style in another blog post later).
Yet another long post, so I will save the: “be flexible on the product scope. Not time and quality” for a coming post.
Thank you for reading and please give some feedback!
Best regards
Anders
Tuesday 13 April 2010
How to reach deadlines?
Dear reader,
“I love deadlines. I like the whooshing sound they make as they fly by” (Douglas Adams English humorist & science fiction novelist 1952 - 2001).
I like this quote because it is a bit therapeutic for someone that always chase deadlines and also because it is totally the opposite of my personality, since I hate missing a deadline. However a lot of statistics show the gruesome fact that SW projects most of the time do not get delivered on time and within budget.
Even projects with unlimited founding and the best people fail as an anonymous person commented on the blog on my post form 22nd of February this year: “It is interesting to read the the GAO reports from DoD (www.gao.gov/products/GAO-09-326SP) which goes through of the 50 major weapons programs in USA which has (almost) unlimited founding, the best people and still fail. Many of the reasons identified for these failures apply in smaller scale as well - failure to understand complexity, mistaking new technologies for proven and shear optimism that "it will probably be worked out" without any contingency if the expected miracle does not happen”.
So what should you do to reach deadlines? First of all, imo I think that if you can deliver on time with the right quality and with a maximum overdraft of 10 % over budget you are doing very well for a SW project. Secondly to be able to repeat (only once does not count) your success, you need to have processes, people with the right technical knowledge and tools etc that paves the way for the projects. But setting this a side there are a lot of things that is less tangible and more based on the soft side and they are often even more important. These soft things are what I am going to write about today.
Never give up, but face the brutal facts as early as possible:
I have been working as a project manager for many years and a too common thing you hear from project members or sub-project managers are we have failed to deliver this or that and we need to move the deadline since we do not see the possibility to get ready on time. Unfortunately it is also all too common that you get this feedback very late. Many project managers then accepts the situation without looking at all options and gives up the target deadline and starts working hard on new plans and suggesting a new deadline to management or the steering committee. If you have a good project team you should instead sit down with them and look at all your possible options before you “give up”. Be as creative and innovative as you can, you might have to delay this particular activity, but you can almost always find other solutions that speed things up on other parts of the critical chain. If it is really tight you often have to increase the risk level, but that is okay if you can stay on the target (please note: just adding developers seldom has an effect). Imo too many people too easily accept delays, I think this mostly is a mindset issue or maybe they like the whooshing sound :-). By mindset I mean that somehow they have got use to that delays are okay and as long as I can make a new plan everything is fine. If you instead do not accept the delay and try your utmost to find an alternative route most times you will. If you on top of this have a team that avoids the five dysfunctions, hence faces the brutal facts as early as possible instead of waiting to tell you about the problems until it might be too late, you will have even more options to reach the deadline in time. In the very good book: Good to Great you can read more about “Face the brutal fact” (Jim Collins is the author of the book: Good to Great, Built to Last, and How the Mighty Fall).
This post is already too long. I will save the two other parts: "Create a team that avoids the five dysfunctions" and "be flexible on the product scope, not time and quality" for my next blog post.
As a final note, of course there are cases when you have to delay a project, all I am saying is that do not be to quick to accept delay. Because if you are you will create a culture in your department that might think it is okay with the whooshing sound or even start liking it ;-)
Thank you for reading and please give some feedback?
Anders
“I love deadlines. I like the whooshing sound they make as they fly by” (Douglas Adams English humorist & science fiction novelist 1952 - 2001).
I like this quote because it is a bit therapeutic for someone that always chase deadlines and also because it is totally the opposite of my personality, since I hate missing a deadline. However a lot of statistics show the gruesome fact that SW projects most of the time do not get delivered on time and within budget.
Even projects with unlimited founding and the best people fail as an anonymous person commented on the blog on my post form 22nd of February this year: “It is interesting to read the the GAO reports from DoD (www.gao.gov/products/GAO-09-326SP) which goes through of the 50 major weapons programs in USA which has (almost) unlimited founding, the best people and still fail. Many of the reasons identified for these failures apply in smaller scale as well - failure to understand complexity, mistaking new technologies for proven and shear optimism that "it will probably be worked out" without any contingency if the expected miracle does not happen”.
So what should you do to reach deadlines? First of all, imo I think that if you can deliver on time with the right quality and with a maximum overdraft of 10 % over budget you are doing very well for a SW project. Secondly to be able to repeat (only once does not count) your success, you need to have processes, people with the right technical knowledge and tools etc that paves the way for the projects. But setting this a side there are a lot of things that is less tangible and more based on the soft side and they are often even more important. These soft things are what I am going to write about today.
Below you can see my top three things:
- Never give up, but face the brutal facts as early as possible
- Create a team that avoids the "Five Dysfunctions"
- Be flexible on the product scope, not time and quality
Never give up, but face the brutal facts as early as possible:
I have been working as a project manager for many years and a too common thing you hear from project members or sub-project managers are we have failed to deliver this or that and we need to move the deadline since we do not see the possibility to get ready on time. Unfortunately it is also all too common that you get this feedback very late. Many project managers then accepts the situation without looking at all options and gives up the target deadline and starts working hard on new plans and suggesting a new deadline to management or the steering committee. If you have a good project team you should instead sit down with them and look at all your possible options before you “give up”. Be as creative and innovative as you can, you might have to delay this particular activity, but you can almost always find other solutions that speed things up on other parts of the critical chain. If it is really tight you often have to increase the risk level, but that is okay if you can stay on the target (please note: just adding developers seldom has an effect). Imo too many people too easily accept delays, I think this mostly is a mindset issue or maybe they like the whooshing sound :-). By mindset I mean that somehow they have got use to that delays are okay and as long as I can make a new plan everything is fine. If you instead do not accept the delay and try your utmost to find an alternative route most times you will. If you on top of this have a team that avoids the five dysfunctions, hence faces the brutal facts as early as possible instead of waiting to tell you about the problems until it might be too late, you will have even more options to reach the deadline in time. In the very good book: Good to Great you can read more about “Face the brutal fact” (Jim Collins is the author of the book: Good to Great, Built to Last, and How the Mighty Fall).
This post is already too long. I will save the two other parts: "Create a team that avoids the five dysfunctions" and "be flexible on the product scope, not time and quality" for my next blog post.
As a final note, of course there are cases when you have to delay a project, all I am saying is that do not be to quick to accept delay. Because if you are you will create a culture in your department that might think it is okay with the whooshing sound or even start liking it ;-)
Thank you for reading and please give some feedback?
Anders
Monday 12 April 2010
Product SW quality (part 2): The quality factor Correctness
Dear reader,
Quality factor correctness is maybe the most common measure for SW quality, and it might be kicking in open doors writing about them? However as Henrik quite correctly pointed out in his comment on my first post about Product SW quality, “correctness is measured at a specific point in time”. This fact makes these quality metrics less trustworthy the more changes you make to the code without performing the right regression testing. Therefore I use them for making release decisions on the maturity of the product together with the other quality factors at a specific point in time. Normally it should be measured against a preset targets for beta SW or final SW. Only looking at one or two of the quality factors correctness can give you a false sense of good quality. For example: You might have low number of open defects and a good pass rate. Without knowing the test converge and the S-curve you will still be in the dark.
Here are some details that I think of when using the correctness quality metrics.
Open defects rank of A, B and C :
This metric is very straight forward, nevertheless the truly hard part is to set the targets that is right for your product. It can be very different for a mobile game compared to a heart-lung machine. The only way I have found that works so far is actually to learn the right limit as you go ahead (maybe not the best way if you do heart-lung machines :-) and releases your product and get customer feedback (if possible before market launch using beta testers). I.e. is zero A-ranks something your customers expect or is 10 A-rank okay? If you have any better way of doing the target setting please let me know? Also what is important is that you use a good ranking system and that everyone gets trained and good at using the ranking system when reporting defects. In addition to this it is very important that everyone buy-in on always adding all defect that is found to your defect tracking system to get traceability. Without 99,9% buy-in form the organization you are in trouble.
% pass rate for test cases:
This metric is also quite straight forward. You just measure the passed test case divided by the total amount of available test cases. This should be measure for at least unit tests, integration testing and system testing.
% test coverage:
Again this metric is not rocket science .You measure % test converge of all the available test cases you have, to validate that the % pass rate tells you the true story. This should be done for all test cases. The targets in an optimal world is of course 100% if you have no blocked areas. For for example unit test it is also good to try to accomplish as close to 100% code converge as possible for the metric to be even better.
Performance metrics:
It is of great help for the development organization to receive targets for none functional requirements like performance metrics from product management in the product specification, before the development starts. Then it is much easier to spend time on estimating the needed work to archive the targets. One example could be the start up time for the product. Without targets you often end-up arguing before launch what is good or bad. If product management do a good job they benchmark with competitors or set good metric targets based on customer expectations.
Thank you for reading and please give some feedback?
Anders
Quality factor correctness is maybe the most common measure for SW quality, and it might be kicking in open doors writing about them? However as Henrik quite correctly pointed out in his comment on my first post about Product SW quality, “correctness is measured at a specific point in time”. This fact makes these quality metrics less trustworthy the more changes you make to the code without performing the right regression testing. Therefore I use them for making release decisions on the maturity of the product together with the other quality factors at a specific point in time. Normally it should be measured against a preset targets for beta SW or final SW. Only looking at one or two of the quality factors correctness can give you a false sense of good quality. For example: You might have low number of open defects and a good pass rate. Without knowing the test converge and the S-curve you will still be in the dark.
Here are some details that I think of when using the correctness quality metrics.
Open defects rank of A, B and C :
This metric is very straight forward, nevertheless the truly hard part is to set the targets that is right for your product. It can be very different for a mobile game compared to a heart-lung machine. The only way I have found that works so far is actually to learn the right limit as you go ahead (maybe not the best way if you do heart-lung machines :-) and releases your product and get customer feedback (if possible before market launch using beta testers). I.e. is zero A-ranks something your customers expect or is 10 A-rank okay? If you have any better way of doing the target setting please let me know? Also what is important is that you use a good ranking system and that everyone gets trained and good at using the ranking system when reporting defects. In addition to this it is very important that everyone buy-in on always adding all defect that is found to your defect tracking system to get traceability. Without 99,9% buy-in form the organization you are in trouble.
% pass rate for test cases:
This metric is also quite straight forward. You just measure the passed test case divided by the total amount of available test cases. This should be measure for at least unit tests, integration testing and system testing.
% test coverage:
Again this metric is not rocket science .You measure % test converge of all the available test cases you have, to validate that the % pass rate tells you the true story. This should be done for all test cases. The targets in an optimal world is of course 100% if you have no blocked areas. For for example unit test it is also good to try to accomplish as close to 100% code converge as possible for the metric to be even better.
Performance metrics:
It is of great help for the development organization to receive targets for none functional requirements like performance metrics from product management in the product specification, before the development starts. Then it is much easier to spend time on estimating the needed work to archive the targets. One example could be the start up time for the product. Without targets you often end-up arguing before launch what is good or bad. If product management do a good job they benchmark with competitors or set good metric targets based on customer expectations.
Thank you for reading and please give some feedback?
Anders
Friday 2 April 2010
Product SW quality (part 2): The quality factor Reliability
Dear reader,
Today I will drill down more into the details of the quality factor Reliability.
For this measure I think you should included “everything” that is a failure. Not just a crash or restart of the SW, but also when the product hangs in some way. It can also be very good to include a sub-measure like mean time to fist failure (MTTFF). Since MTTFF impact very much on the customer perceived reliability of your product.
S-curve:
The S-curve is mostly used to understand the quality maturity (or reliability status) of your product. The accumulated number of found defects over time is a measure that I think tells you the most when it is 100% connected with the correctness quality metrics like number of open defects, pass rate and test coverage. You also need testing done consistently and defect needs to be registered consistently in your ALM tools otherwise you might be fooled.
SW complexity metrics (i.e. Cyclomatic complexity)
This measure is not very often used but I believe many organization would be able to increase the SW reliability a lot if used the right way.
Cyclomatic complexity will tell you how error prone a function, module, method or classes is. If you would like to know more details look at this Wikipedia link: http://en.wikipedia.org/wiki/Cyclomatic_complexity.
The important part here is to make sure that your cyclomatic complexity is lower than 10 for all modules within your product. Otherwise the risk of faults increases a lot and your SW reliability is at risk. A number of studies have investigated cyclomatic complexity's correlation to the number of defects contained in a module. Most such studies find a strong correlation between cyclomatic complexity and defects: modules that have the highest complexity tend to also contain the most defects. For example, a 2008 study by metric-monitoring software supplier Enerjy analyzed classes of open-source Java applications and divided them into two sets based on how commonly faults were found in them. They found strong correlation between cyclomatic complexity and their faultiness, with classes with a combined complexity of 11 having a probability of being fault-prone of just 0.28, rising to 0.98 for classes with a complexity of 74 (Rich Sharpe. "McCabe Cyclomatic Complexity: the proof in the pudding". Enerjy.).
As mentioned before there are a lot of automatic tools available and I am looking forward to TFS 2010 that will also have this measure included.
Happy Ester!
Anders
Today I will drill down more into the details of the quality factor Reliability.
The following three measures are of importance:
- Mean time between failure (MTBF),
- S-curve (accumulated number of found defects over time)
- SW complexity metrics (i.e. Cyclomatic complexity).
For this measure I think you should included “everything” that is a failure. Not just a crash or restart of the SW, but also when the product hangs in some way. It can also be very good to include a sub-measure like mean time to fist failure (MTTFF). Since MTTFF impact very much on the customer perceived reliability of your product.
S-curve:
The S-curve is mostly used to understand the quality maturity (or reliability status) of your product. The accumulated number of found defects over time is a measure that I think tells you the most when it is 100% connected with the correctness quality metrics like number of open defects, pass rate and test coverage. You also need testing done consistently and defect needs to be registered consistently in your ALM tools otherwise you might be fooled.
SW complexity metrics (i.e. Cyclomatic complexity)
This measure is not very often used but I believe many organization would be able to increase the SW reliability a lot if used the right way.
Cyclomatic complexity will tell you how error prone a function, module, method or classes is. If you would like to know more details look at this Wikipedia link: http://en.wikipedia.org/wiki/Cyclomatic_complexity.
The important part here is to make sure that your cyclomatic complexity is lower than 10 for all modules within your product. Otherwise the risk of faults increases a lot and your SW reliability is at risk. A number of studies have investigated cyclomatic complexity's correlation to the number of defects contained in a module. Most such studies find a strong correlation between cyclomatic complexity and defects: modules that have the highest complexity tend to also contain the most defects. For example, a 2008 study by metric-monitoring software supplier Enerjy analyzed classes of open-source Java applications and divided them into two sets based on how commonly faults were found in them. They found strong correlation between cyclomatic complexity and their faultiness, with classes with a combined complexity of 11 having a probability of being fault-prone of just 0.28, rising to 0.98 for classes with a complexity of 74 (Rich Sharpe. "McCabe Cyclomatic Complexity: the proof in the pudding". Enerjy.).
As mentioned before there are a lot of automatic tools available and I am looking forward to TFS 2010 that will also have this measure included.
Happy Ester!
Anders
Sunday 28 March 2010
Product SW quality (part 1)
Dear reader,
Nice to be back after a relaxing vacation. In this first post about product SW quality I want to focus on number 2 from my post on the 22nd of February. Lack of quality control and good quality code measures (software Metrics). Most companies measure SW quality in some form, for example number of open defects often connected to a ranking system. This is one simple way of measuring product quality, even if it standalone will not tell you very much. To be able to get a full overview of your products quality you need more than just one measure, you need to find a number of measures that give you the full picture of your product SW quality. However, first I want to elaborate some on what I mean with SW quality. There are of course a lot of things that can fit into this term. My number one focus is on product SW quality and the main quality factors for me are reliability, usability and correctness. Of course you also have many other factors like maintainability, reusability, portability etc but it is not as important as the other three in succeeding with a good customer "perceived" quality level (looking from the out side an in).
If you make sure you get reliable data on the above quality factors you are getting very good input into how to improve you product quality. More importantly you will also have the right information on your product quality status to be able to make the often hard decision on when to release you product to real customers.
Even the most mature companies I worked at best case use most of the correctness quality factor and MTBF from the reliability quality factor. This often lead to products that are released too early (i.e. with too low quality), since missing the S-curve and a good complexity metrics you miss 2 out of 3 metrics for reliability. The SW complexity metrics has been around for over 20 years, but I have yet see any company using them, even if there has been automated tools available since at least 15 years back. I myself did my master thesis at Volvo Cars in 1995 on SW complexity metrics (I do not know if they ever went ahead and implemented my suggestions :-). However in TFS 2010 you will find a automated tool for measuring Cyclomatic complexity, maybe that will make it more frequently used?
That’s it for today. In coming posts I will drill down to details for each quality factor.
Kind regards
Anders
Nice to be back after a relaxing vacation. In this first post about product SW quality I want to focus on number 2 from my post on the 22nd of February. Lack of quality control and good quality code measures (software Metrics). Most companies measure SW quality in some form, for example number of open defects often connected to a ranking system. This is one simple way of measuring product quality, even if it standalone will not tell you very much. To be able to get a full overview of your products quality you need more than just one measure, you need to find a number of measures that give you the full picture of your product SW quality. However, first I want to elaborate some on what I mean with SW quality. There are of course a lot of things that can fit into this term. My number one focus is on product SW quality and the main quality factors for me are reliability, usability and correctness. Of course you also have many other factors like maintainability, reusability, portability etc but it is not as important as the other three in succeeding with a good customer "perceived" quality level (looking from the out side an in).
Below you can see the metrics I think you need to use on a top level:
- Reliability: Mean time between failure (MTBF), the S-curve (accumulated number of found defects over time) and SW complexity metrics (i.e. Cyclomatic complexity).
- Correctness: Open defects rank of A, B and C, % pass rate for test cases (all test areas: i.e. function test, integration test etc), test coverage, performance metrics.
- Usability: Performance metrics (latency), effectiveness, efficiency, user satisfaction (or perceived quality).
If you make sure you get reliable data on the above quality factors you are getting very good input into how to improve you product quality. More importantly you will also have the right information on your product quality status to be able to make the often hard decision on when to release you product to real customers.
Even the most mature companies I worked at best case use most of the correctness quality factor and MTBF from the reliability quality factor. This often lead to products that are released too early (i.e. with too low quality), since missing the S-curve and a good complexity metrics you miss 2 out of 3 metrics for reliability. The SW complexity metrics has been around for over 20 years, but I have yet see any company using them, even if there has been automated tools available since at least 15 years back. I myself did my master thesis at Volvo Cars in 1995 on SW complexity metrics (I do not know if they ever went ahead and implemented my suggestions :-). However in TFS 2010 you will find a automated tool for measuring Cyclomatic complexity, maybe that will make it more frequently used?
That’s it for today. In coming posts I will drill down to details for each quality factor.
Kind regards
Anders
Subscribe to:
Posts (Atom)
Posts
