Thursday, June 30, 2011
Thursday, February 24, 2011
Hence, we would like to continue our efforts in this direction and invite submissions for the 1st International Workshop on Comparing Software Retrieval Approaches (CORA 2011, co-located with ICSR). More information can be found on the CORA website.
Thursday, September 16, 2010
The panel had the goldfish bowl format and had as panelists the main experts in the field: Paul Clements, Charles W. Krueger, John McGregor, Dirk Muthig, and David Weiss.
The panel discussed issues as: How do you think a good product line architecture should look like? How much up-front design do we need for a product line architecture? What are hot research topics in product line architecture?
The mind-map summarizing the panel can be seen here. [thanks to Klaus Schmid].
Thursday, June 10, 2010
However, while the development of such systems has made considerable progress, their evaluation is still largely driven by proprietary approaches which are all too often neither comprehensive nor really comparable to one another. Consequently, it is also hard if not impossible to assess whether existing tools are really beneficial in a practical context.
Driven by these shortcomings, I submitted a paper ("Facilitating the Comparison of Software Retrieval Systems through a Reference Reuse Collection") to the SUITE workshop at ICSE in Cape Town where we discussed this challenge and agreed to start the creation of a reference reuse collection. Meanwhile the Universities of Irvine and Mannheim have started a first initiative and shared reusable material from their Sourcerer and merobase repositories (which comprise far more than 50,000 open source projects) with the scientific community.
Clearly, we appretiate if other researchers would join this initiative and share their data in order to have a broad basis for future comparisons of reuse tools. The next steps required for this undertaking are briefly outlined in the paper mentioned above, but as always: the devil is in the details and hence there are plenty of oportunities to contribute to this project.
Saturday, March 27, 2010
In particular, I would like to emphasize the keynote speech of Serge Demeyer about in vitro and in vivo research for Software Evolution. Currently, it is a common sense in the research community that more well done experiment should be performed to evaluate our research. However, in this keynote, there was an special call for more in vivo evaluation for researches. It means that we, researchers, should be more concerned with evaluating our research/proposals in a real context, for example, applying it in real companies with the researcher shipped in it.
The RiSE group participated in the Software Evolution session of CSMR, with the the paper "An Initial Study on the Bug Report Duplication Problem", written by Yguaratã Cavalcanti, Eduardo Almeida, Carlos Cunha, Daniel Lucrédio e Silvio Meira. One interesting point for this paper, was the close relation with the keynote speech of Judith Bishop. In his speech, Bishop talked about how Microsoft has been deal with the large amount of bug reports that are coming daily through their system for bug reports submission.
We had also a good session dedicated to Software Architecture papers, where it was clear that software architecture is still increasingly becoming a fundamental step through the software development life-cycle. I specially noticed some trends to researches on software architecture recovery and reflection. In the session for software evolution, where we presented our paper, it could be noticed that change impact analysis will continue playing an important field of research.
I hope to see you in the next edition of CSMR. I would like also to thank the hospitality of Spanish people. ;)
Wednesday, January 27, 2010
However, I would like to understand more the relationship between it and the design. Let me explain better: Suppose that I am starting a product line based on a set of products. We collect all the documentation, define a product map with their features, understand and document all the commonality and variability, and that is it!
But in this case, we are defining the SPL scoping based on the existing assets (source code and documentation). From here, we can move, for example, to design the SPL architecture. However, you can observe that we are taking decisions based on the current state of the family, i.e., how it is. What are the implications for the next steps? Are we repeating the same decisions problems when the previous team created the products?
What could be a better solution: define the scope, recovery the SPL design, evaluate this design, reflect it in Scoping and moving forward?
In general sense the point is: for you, what is the relationship between scoping and design? is there any one?
Tuesday, January 19, 2010
Wednesday, December 23, 2009
In general, the SAR approaches can be classified as Bottom-Up, Top-Down and Hybrid. In the Bottom-Up approach, starts with the low level knowledge, such as source-code, and progressively tries to reach the higher level understanding using reverse engineering. The Top-Down approach is the opposite, as it begins with high-level concepts, such as architectural views and requirements, and tries to build the architecture through hypotheses that are confirmed by the source-code. The Hybrid approach merges the last two approaches, abstracting the low-level knowledge and refining the high-level knowledge ratifying correspondences between both the conceptual and concrete architectures.
In the SAR approaches we can have inputs of architectural nature, like viewpoints and styles, and non-architectural inputs, like souce-code, human knowledge, etc. As output we can have, for example, visual software views, the architectural conformance and the architecture analysis.
Some approaches that aim at the investigation of reuse and software product line (SPL) migration have been identified: ARES, ARMIN, MAP and PULSE. As a goal for these approaches we can highlight the identification of commonalities, variabilities, components that can be extracted of pre-existing systems that, for example, might be turned into services.
Now, our studies focus on identifying if SAR can be used as a tool to support the introduction of reuse in organizations. Our main challenges are:
– What approaches are more complete/ to introduce Reuse?
– What approach can we use?
– Are the companies producing these artifacts?
– Can these processes be agile?
– How much of this processes can be automated?
– How to systematize this approach?
 D. Stéphane, P. Damien, "Software Architecture Reconstruction: A Process-Oriented Taxonomy", IEEE Transactions on Software Engineering., Vol 35, No. 4, 2009.
 W. Eixelsberger, M. Ogris, H. Gall, and B. Bellay, “Software Architecture Recovery of a Program Family,” Proc. Int’l Conf. Software Eng., pp. 508-511, 1998.
 R. Kazman, L. O’Brien, and C. Verhoef, “Architecture Reconstruction Guidelines,” technical report, third ed., Carnegie Mellon Univ., SEI, 2003.
 L. O’Brien, D. Smith, and G. Lewis, “Supporting Migration to Services Using Software Architecture Reconstruction,” Proc. Int’l Workshop Software Technology and Eng. Practice, pp. 81-91.
 C. Stoermer and L. O’Brien, “Map—Mining Architectures for Product Line Evaluations,” Proc. Working IEEE/IFIP Conf. Software Architecture, pp. 35-41, 2001.
 J. Knodel, D. Muthig, M. Naab, and M. Lindvall, “Static Evaluation of Software Architectures,” Proc. Conf. Software Maintenance and Reeng., pp. 279-294, 2006.
Some regression techniques have been proposed:
One important technique is Regression Test Selection that consist Choose a subset of tests from the old test set, and uses this subset to test the modified program ;
Some criteria are used for apply test selection :
• Test suite reduction;
• Test execution time;
• Test selection time;
• Total time;
In this moment we study e test a mix of possibilities between techniques and criteria with focus in application in SPL testing context… in another day we going to write more about this subject;
Harrold, MJ, and ML Souffa. 1988. "An incremental approach to unit testing during maintenance." Software Maintenance, 1988;
Rothermel, G. and Harrold, M.J. 1993. A safe, efficient algorithm for regression test selection. Software Maintenance ,1993. CSM-93, Proceedings., Conference on. 358-367.
Engstron, Emelie, Per Runeson, and Mats Skoglund Pii. 2009. "A Systematic Review on Regression Test Selection Techniques." English (July).
 Gaurav Duggal, Mrs. Bharti Suri.2008.” UNDERSTANDING REGRESSION TESTING TECHNIQUES”;
A software product line consists of a product line architecture, a set of reusable components and a set of products derived from the shared assets .
Organizations developing or acquiring systems using the product line approach have enjoyed significant (sometimes order-of magnitude) improvements in time to market, cost, productivity, and quality .
Benefits of Software Product Lines :
- Product line development has increasingly received attention in industry as it enables organizations to reduce both cost and time of developing and maintaining increasingly complex systems.
- Successful product line development requires high quality of reusable artifacts in order to achieve the promised benefits.
Moreover, software inspection approaches implements techniques to provide qualities atributes for assets and product of software development processes, such:
- Ensure correct system is built 
- Assure Software Quality 
- Optimize the software process 
- Work product more readable 
aking into consideration that the review process for reusable artifacts of product lines need to present efficient (catching faults) and not very dense (time) performance, to enable a better adoption in organizations.
 Jan Bosch, "Software Product Lines: Organizational Alternatives," icse,pp.0091, 23rd International Conference on Software Engineering (ICSE'01), 2001