More on Change Request Duplication Problem

In a previous post we had a little discussion about Change Requests duplication problem, showing how it can impact on software development and some works that approached it. However, our curiosity led us to a much bigger investigation of the problem to see its real dimension.

Thus, with this objective in mind, was performed a formal characterization study of CR duplication problem to see how it impacts on software development productivity. Furthermore, it was selected several different projects -- which include private and open source projects -- with different characteristics in order to expand our study as much as possible. Among these characteristics, we can cite software domain, team size and experience, software size and life time, CR tracking system used, and so on. In addition, it was performed some interviews with developers and people which deal with CR tracking systems.

The values and answers obtained for the metrics and questions we have defined confirmed the initial expectations, in most cases passing them, showing that the CR duplication problem is very critical to the project productivity, evolution and maintenance. In other words, many hours are lost in the task of identifying duplicate CRs, which could be used with other tasks. In addition, not only hours are lost, but also this problem turns difficult the engagement of new people to deal with CR tasks. In the last case, it happens because people need to have a good knowledge of the past CRs of a repository in order to avoid the problem.

Moreover, we have not only performed this characterization study but, given that the problem has a industrial scale, some studies and works is being conducted to solve the problem. For example, an approach based on keyword-based search engines was applied to the problem. However, although the result were satisfactory, we think that it can be improved much more with the combination of other techniques.

Reuse in Software Engineering (RiSE) - The New Face

Today, is one more day to celebrate. The Reuse in Software Engineering (RiSE) launched its enterprise website. It is one more step towards the world-wide market. In the new website, you can see the new logo, information about our products and services (consulting and training), feedbacks from the main reuse specialists around the world from industry and university, our customers, partners, videos, and etc.

Enjoy the new website and next features are coming. Credits for our new member Robson Ribeiro design engineer responsible for the website. Send us your feedback also, please!

Ingredients for Reuse Introduction: Make your Mix

In several talks which I have given, different attendants have asked me about how to introduce reuse in companies. At the RiSE, we have many papers and seminars about reuse introduction, reuse maturity models, frameworks, tools, etc. But, the main question often is: what are the ingredients to perform it?

During the First RiSE Summer School on Software Reuse (RiSS), we had some interviews with the keynotes speakers about this aspect too. In this post, I will not concentrate in academic references or papers. You can read some of them here or with other researchers such as Bill Frakes, Maurizio Morisio, Jeff Poulin, Ruben Prieto, Martin Griss, Wayne Lim, Will Tracz, etc.

First of all, your CEO or Top Manager should be convinced that reuse can be a good way for your organization to improve the time-to-marketing, quality and reduce costs. It is necessary because they will send this message for all the organization. It happens often in quality programs, for example. In addition, I believe that all the organization should understand and believe in this idea, i.e., the culture should be spread from project managers until software engineers. Otherwise, this effort cannot work properly. But just understand and accept the idea is not enough. We need to train the necessary staff to introduce reuse. In some cases, the people need to know what can help, what are the available techniques, tools and metrics. With people convinced/motivated and trained, I think that is also important to have a reuse plan. It is necessary for the reuse team as well as for the CEO because you should show clearly the steps to introduce reuse, the milestones, the risks, the costs, the benefits, i.e., you should show that the approach is systematic with a defined begin-end cycle.

So, in this path, a pilot project based on a specific domain or not should be considered to show it. For this pilot, the plan can address to analyze applications in the organization [what is common and variable, profile of the developed software], change or adapt the current process, collect other data, define some [specific] tools and track the pilot. It working well is time to analyze the pilot, understand the problems and strong points, learn with the process, present the results for the sponsors, and spread it for more areas in the organization.