Analysis eight secrets of the Software Measurement

In the paper “ Eight secrets of Software Measurement”, Betsy Clark gave us eight points on how to make a high measurement and some factors, which could impact the large scale and long term software measurement.

“It is not about the metrics”

In the paper, there is an example (It is not about the bike: my journey back to life) to illustrate the measurement is a vehicle for produce some estimates, which could help people find the best way to reach their your goal.

I completely agree with this point. Measurement plays a role in regulating your program. It will estimate the schedule, size, cost, quality, ability and performance of the project. In the end of the program, people still need to make a decision by themselves and put all the theory into practice. In order to create an effective software measurement for the long term and large-scale program, the first thing for us is to understand the aims and find the reasons why we want to make a measurement.

However, during the long history of the software measurement, metrics are always the useful and famous tools for preparing the projects. When we tend to establish good metrics, we should abide by six principles. Initially, we should focus on meet the schedule of the program and reach its quality goals. Secondly, when we make a plan, we should build quantitative goals to allow us to realize them. At the following stage, we should compare the plans with the real performance to find out the potential problem. After that, we should collect data rather than focus on the actual values because the tendency of the data could demonstrate the potential problem better than the data values, and minimize the deviation. Although sometimes there seem to be no problem by the metrics, the problem would be explored by the data values. Metrics would become clarify or obscure their messages.

Measurement metrics are only tools. When we use metrics to make a software measurement, the conclusions are not accurate. For instance, my undergraduate major is system engineering. System engineering method ask experts to list all the factors which would affect the program and category them. Then they set the weight scores to different factors by their specialist knowledge. After we complete the pro-preparation of the data, we should use system evaluation to calculate the matrixes and predict the different kinds of results of the program. This method is so similar to the measurement metrics, especially for the large scale and long-term software program. Apparently, both of these two methods are inaccurate. System engineering matrixes rely on experts’ opinions, and some significant factors selections are intense subjectivity as well as measurement metrics. Therefore, we should not only depend on tools, which will also make some mistakes. Although measurement metrics have a long history and many successful instances, we still need concentrate on the aim of the projects, and then put the measurement into practice.

“Success comes from channeling an organization’s pain into action”

During the program, we prefer to have the strong motivation to understand and improve the measurement, and then it is standard practice for people to implement the measurement in reality. In according to the experience of the long software measurement history, we can see that metrics cannot address the entire problem perfectly. Part of this opinion is correct. We have to bridge the gap between the measurement research and measurement practice. Because all the software measurement should be feasible in the real world, that is the baseline of the measurement.

However, in my view, before we put the plan into practice, we have to ensure that is it worth doing that? We need one wonderful measurement to act it, so measurement theory would be significant here. In this theory, we should measure the scale of the program and make sure that the metrics we create should suit the goals. We still need to understand the difficulty of measuring software in any special fields.

After we construct one great software measurement. We have to consider how to put the plan in reality. Many researchers focus on the importance of practice, but most of the practitioners and customers ignore it. When we tend to put the idea of the measurement into practice, we are always establishing models to estimate the conclusion, and the winners’ experience confirmed this.

 “Establishing a measurement program is easy, keeping the program going is hard.”

I do not think so. To be honest, I think both establishing the model and keeping the program going are very difficulty. The paper told us that making a useful potential measurement is easy. The difficulties for us are implementing it efficiently and transforming the enthusiasm to action.

Nevertheless, I am sure that establishing a great measurement is also very important. It could create a useful engineering approach to software improvement and process development, which could replace the traditional approach in the past. One successful software measurement should have a close link to the clear definition, detailed explanations and well manipulation. It is easy to establish a model for long term and large scale program by drawing on this information from the measurement.

Absolutely, I agree with the view that put the software measurement into practice is very difficult. We often build models to test the plans, especially for empirical models, we must identify the culture, technology, structure and business issues, which could make a contribution to the model. Also, according to the paper said, some companies even make mistakes that they ignore the business issues and management issues while they make a software measurement. They have to remove these barriers if they want to build the models easily.

“People skills matter more than quantitative skills”

In the paper, every step of the software measurement process gains the input information from the people who are attribute to the program. Since all the input information is from human beings, the conclusion of the measurement would be very subjective, such as emotion. Hence when we make a measurement by individuals, emotion would have a huge impact on the measurement. In this case, build a measurement by individuals would unwise.

Also, author prefer to find people who have the talent to understand the requirements and advantages, so the data from this talented people could provide the data efficiently. However, I disagree this idea. It is essential that people should complete some sections of the measurement independently. If people in the organization cooperate together, it would boost the efficiency and avoid some subjective mistakes. For example, The RAND corporation in the USA, their work is so similar to make a large scale and long term measurement. Nevertheless, they never complete by someone individually. They analyzed many different aspects of the program and enquire many experts’ professional ideas. Then they use system science to make the matrixes, in the following stage, they calculate the matrixes and predict the future. Because of their strong cooperation spirit and professional technology, their estimates are always accurate. Hence, people skills play a dominant role in making software measurement. We cannot rely on one person even he is a talented one.

 “Senior-level sponsorship and leadership are critical”

In terms of the leadership, author shows us two leaderships are significant. One of them is people on the top should participate in the measurement program to familiar with the projects. Another one is measurement program need senior level sponsorship. As a leader, they should clarify organizational goals; their behaviors need identical to these goals, encouraging expose the problem rather than hide the problem. What’s more, leaders should read the conclusion of the data analysis and reflect some questions, and then they have to make decisions depending on the practical results and their experience.

I agree that every measurement needs leadership to control groups and make the final decision. However, sometimes, manager stay in the group would cause some opposite effect. For instance, in china, when the manager participant in making measurement, others would prefer to yield to manager’s opinion, it would lose some great creative idea from the groups. So it is necessary to allow the people of making measurement understand that they just need to assume their responsibility, and the manager need to find the hide problems and try to address them.

“Measuring individuals can be Okay”

Here, author argues that individual work would not fulfill drawbacks. When people make the measurement, they want to escape their responsibility, so they hide the problem. This would make a contribution to delay the completion time and cause a model uselessly. If we can allocate the tasks to individuals, everyone has to shoulder their own parts of responsibility; they would try their best to make the measurement perfectly. Meanwhile, companies could make some schemes to encourage people who can find useful potential problems in the measurement.

Individual work and group work are all good; individual work can stimulate the creativity of the measurement. When we divided the large program into small parts, different people with different background could do different parts of the measurement. It can boost efficiency for the long term and large scale program. In the team, people can integrate their work and exchange their thoughts to improve the software measurement. Hence, if we can combine the independence and cooperation, we could make a better measurement.

“Do not go overboard trying to be perfect” and “Understanding the reasons for variability in the data provides a powerful decision tool”

If we want to make a software measurement and establish a model, the most important thing is collecting data. When we collect information from the environment, we have tried to remove the subjective and collect more objective data.

I agree that it would be hard to reach this level because we have to collect information by people. It is possible that we could introduce machine learning to collect data from the environment, which would reduce the impact on subjective emotion. However, the most significant process is how to understand the data and how to represent the data clearly. Different people have different comprehension of the data. When the data represent to the public, people could have different ways to explain the data. If we cannot convey the data so that readers have a consistent understanding, the measurement models are difficult to establish.

I completely agree the “variability in the data provides a powerful decision tool”. Apparently, one predominant characteristic of the real data is its variation. The main point is that if we can investigate what the variation represent, we could well understand the meaning of the data. Although collect data is a time-consuming job, it is worth doing it. When we preprocess the data by statistics methods, we could use these update data and build new models to estimate the significant factors of the potential program.

Overall, create a perfect measurement is very complex and difficult. We must consider the good and bad effects on the model factors. For a large scale and long term software measurement, we should focus on the schedule, cost, size, quality, ability and performance. If we can make models have more cohesion and less coupling, the accuracy of the model will become better. All of the eight points are very informative and fantastic, and if we implement all these points successfully, we can reach a higher level of the large scale and long term software measurement.

Reference

1. Eight Secrets of Software Measurement. B. Clark. IEEE Software, September/October 2002.(KEY PAPER)
2. Getting Started on Software Metrics. J. Clapp. IEEE Software, January 1993.
3. Software Metrics: Progress after 25 Years?, S.L. Pfleeger. IEEE Software, November/December 2008.
4. Status Report on Software Measurement. S.L. Pfleeger, R. Jeffery, B. Curtis, B. Kitchenham. IEEE Software, March/April 1997.
5. Establishing Software Measurements Programs. R.J. Offen, R. Jeffery. IEEE Software, March/April 1997.