Software Architecture Recovery as a Tool to Introduce Reuse in Companies

According to Ducasse and Pollet, software architecture reconstruction is a reverse engineering approach that aims at reconstructing viable architectural views of a software application [1]. The process of software architecture recovery (SAR) may be utilized in many ways, namely redocumentatation, understanding of already existing systems, evolution, conformance between the conceptual and concrete architectures, and some other applications.

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[2], ARMIN[3][4], MAP[5] and PULSE[6]. 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?

[1] D. Stéphane, P. Damien, "Software Architecture Reconstruction: A Process-Oriented Taxonomy", IEEE Transactions on Software Engineering., Vol 35, No. 4, 2009.

[2] 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.

[3] R. Kazman, L. O’Brien, and C. Verhoef, “Architecture Reconstruction Guidelines,” technical report, third ed., Carnegie Mellon Univ., SEI, 2003.

[4] 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.

[5] C. Stoermer and L. O’Brien, “Map—Mining Architectures for Product Line Evaluations,” Proc. Working IEEE/IFIP Conf. Software Architecture, pp. 35-41, 2001.

[6] J. Knodel, D. Muthig, M. Naab, and M. Lindvall, “Static Evaluation of Software Architectures,” Proc. Conf. Software Maintenance and Reeng., pp. 279-294, 2006.

Regression Test Selection in SPL

According to Harrold One factor contributing to high cost spent on the maintenance phase it’s a time required to reanalyze and retest the software after it has been changed.

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 [2];

Some criteria are used for apply test selection [3]:

• Test suite reduction;
• Test execution time;
• Test selection time;
• Total time;

Find and explores efficient test selection criteria for spl can help to reduce more cost involved in spl testing context. The two main key: variability and commonalities must be explored for support the criteria, together traceability between variability and test cases or commonalities and test cases. With goal to support the definition of Test selection criteria for SPL;

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;

[1]Harrold, MJ, and ML Souffa. 1988. "An incremental approach to unit testing during maintenance." Software Maintenance, 1988;
[2]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.
[3]Engstron, Emelie, Per Runeson, and Mats Skoglund Pii. 2009. "A Systematic Review on Regression Test Selection Techniques." English (July).
[4] Gaurav Duggal, Mrs. Bharti Suri.2008.” UNDERSTANDING REGRESSION TESTING TECHNIQUES”;

Inspection in Software Product Line

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 [1].

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 [2].

Benefits of Software Product Lines [3]:

• 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 [4]
• Assure Software Quality [3]
• Optimize the software process [5]
• Work product more readable [6]

The key challenge is the adaptation of inspections, reviews, and walkthrough techniques for use in domain and application of Software Product Lines Engineering. For example, the results of inspections, reviews, and walkthroughs, obtained in domain engineering, should be effectively compared and monitored in application engineering. Taking 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.

[1] Jan Bosch, "Software Product Lines: Organizational Alternatives," icse,pp.0091, 23rd International Conference on Software Engineering (ICSE'01), 2001

[2] Paul C. Clements: A Competition of Software Product Line Economic Models. SPLC 2005: 136

[3] Christian Denger and Ronny Kolb, Testing and inspecting reusable product line components: first empirical results, ISESE'06 at Rio de Janeiro, Brazil, September 21–22

[4]David L. Parnas, Mark Lawford: The Role of Inspection in Software Quality Assurance. IEEE Trans.Software Eng. (TSE) 29(8):674-676 (2003)

[5] H. Dieter Rombach, Marcus Ciolkowski, D. Ross Jeffery, Oliver Laitenberger, Frank E. McGarry, Forrest Shull: Impact of research on practice in the field of inspections, reviews and walkthroughs: learning from successful industrial uses. ACM SIGSOFT Software Engineering Notes (SIGSOFT) 33(6):26-35 (2008)

[6] Forrest Shull, Ioana Rus, Victor R. Basili: Improving Software Inspections by Using Reading Techniques. ICSE 2001:726-727

Software Product Line in Small and Medium Sized Company

Software development costs and time to deploy a software-intensive system significantly decrease when Software Product Line (SPL) approach is applied [3]. However software product line engineering requires long-term planning, the companies that have used it successfully are large ones that can afford to take the long view [1].

But smaller enterprises must be flexible and fast in reacting to customer requests. Moreover most publicized software product lines come with pedigrees written in large script: Nokia, Motorola, Hewlett Packard, CelsiusTech, Philips, and others. These organizations boast hundreds of developers, with budgets more than ample enough to cover an experiment or two with a new and untried paradigm. And if it fails – well, there’s always a bit of a risk with an R&D project, isn’t there? It’s not as though the company will be in peril [1].

For small companies, R&D is an unaffordable luxury. And experiments are for laboratories, not lean need-it-now production shops where every product has to strike market gold for the company to survive [3]. No wonder the conventional wisdom views software product lines as a game only for the heavyweights. For the record, the conventional wisdom is utterly wrong. In fact, software product lines offer many small companies their last best hope for success.

Today, we have significant examples of application of SPL in SMEs. In most cases SMEs use research groups as Reuse Software Engineering (RiSE) kind of an external research department.

Advantages of a small company over a large one include the following [2]:

· It is much more easy to articulate a vision in a small organization and make it stick. This is true of any vision, but especially true of a product line vision. Product lines are typically sold to management because they hold the promise of lower cost and quicker turnaround. In a large organization, those goals are fairly abstract to the troops grinding out code. But in a small company, the developers are much more tuned in to the company’s economic picture; there is a short distance from economics to developers.

· A corollary to the previous point is that it is much easier to find places where the vision needs reinforcing.

· A small organization can get by with lightweight product line processes, for they are used to lightweight processes anyway.

· A small organization’s developers can more easily acquire useful domain knowledge.

· Managers in a small organization typically apply their hand at many tasks, including development, so they know firsthand where the approach is falling short.

[1] Peter Knauber, Dirk Muthig, Klaus Schmid, Tanya Widen: : “Applying Product Line Concepts in Small and Medium-Sized Companies. ”;

[2] Martin Verlage, Thomas Kiesgen: “Five years of product line engineering in a small company.”

[3] José L. Barros, José M. Marqués: Support to Development-with-Reuse in Very Small Software Developing Companies.”;

[4] David Sellier, Gorka Benguria Elguezabal, Gorka Urchegui: “Introducing Software Product Line Engineering for Metal Processing Lines in a Small to Medium Enterprise.”;

Product Derivation in Software Product Lines

During application engineering concrete products are built based on the reusable assets. The idea behind the SPLE (Software Product Line Engineering) is that the investments required to develop the reusable artifacts during domain engineering, are outweighed by the benefits in deriving the individual products during application engineering [2].

Product derivation is a key activity in application engineering and addresses the selection and customization of assets from the product line [2]. According to Jhon D.McGregor [3], the Product derivation is the focus of a software product line organization and its exact form contributes heavily to the achievement of targeted goals. However, when isn’t realized through sistematic process, the software product line goal can’t be achieve, diminishing the expected gains.

Beyond the sistematic process, according to Cirilo[1], ideally the product derivation process would be accomplished with the help of instantiation tools to facilitate the selection, composition and configuration of SPL code assets and their respective variabilities.

In the product derivation context, some approaches apply model-driven development techniques; others are merely a collection of guidelines. Yet other approaches provide a high-level methodology or process framework [4]. For instance, PULSE-I process[5], Bosh Framework[6], and COVAMOF process[7].

Unfortunately, in the analysis of existing product derivation approaches showed that great part of the available product derivation approaches do not cover all the steps of application engineering, and neither define activities, sub-activities, roles, inputs and outputs of each step in a systematic way, aspects that should be considered. Moreover, the majority of them doesn't has a tool support.

[1] Cirilo, E., Nunes, I., Kulesza, U., Nunes, C., and Lucena, C. 2009. Automatic product derivation of multi-agent systems product lines. In Proceedings of the 2009 ACM Symposium on Applied Computing (Honolulu, Hawaii). SAC '09. ACM, New York, NY, 731-732.

[2] Deelstra, S., Sinnema, M., and Bosch, J. 2005. Product derivation in software product families: a case study. J. Syst. Softw.74, 2 (Jan. 2005), 173-194.

[3] Deelstra, S., Sinnema, M., Bosch, J., 2003. A Product Derivation Framework for Software Product Families, accepted for the 5th Workshop on Product Family Engineering (PFE-5), November 2003.

[4] John D. Mc Gregor: "Goal-driven Product Derivation", in Journal of Object Technology, vol. 8, no. 5, July-August 2009, pp. 7-19.

[5] J. Bayer, C. Gacek, D. Muthig, T. Widen. PuLSE-I: Deriving Instances from a Product Line Infrastructure. In Proceedings of the 7th IEEE International Conference and Workshop on the Engineering of Computer-Based Systems, pages 237-245, 2000.

[6] Rabiser, R., Grünbacher, P., Dhungana, D.: Requirements for Product Derivation Support: Results from a Systematic Literature Review and an Expert Survey. Information and Software Technology, International Journal. Elsevier, 2009.

[7] Sinnema, M., Deelstra, S., Hoekstra, P., 2006b. The COVAMOF derivation process. In: Proceedings of the Ninth International Conference on Software Reuse.

Looking at Software Product Line Testing Tools

Software testing is a practice often used to determine and sometimes improve software quality. It is also a very labor and resource intensive process that often accounts for more than 50% of the total cost of software development[1]. According to Geppert[2] Software Testing is an area with high potential for reuse and reducing the current testing effort is a high priority topic.

Finding an effective and efficient software testing tool could be a life-saver for a project or a company. Yet there is no single test tool suitable for all possible systems and industry sectors. Deciding what criteria to apply when selecting a specific tool for a project is quite tricky [3].

In 2000, Harrold[4] said that: "We must develop methods and tools that implement the techniques and that can be used to demonstrate their effectiveness. To accomplish this, an important criterion is that these methods and tools be scalable to large systems. An efficient approach for development of methods and tools is to provide ways to automatically create them."

In our study of Software Product Lines Testing Tools we can see a tendency directed to Automatic Test Case Generation Tools and according to Bertolino [5] "The dream would be a powerful integrated test environment which by itself, as a piece of software is completed and deployed, can automatically take care of possibly instrumenting it and generating or recovering the needed scaffolding code (drivers, stubs, simulators), generating the most suitable test cases, executing them and finally issuing a test report".

Product lines exploit the commonalities and variability of reusable assets across different products. Nowadays, the most evident and perhaps most urging question is how to handle and represent variability[6]. Due to the large scale and huge complexity of today’s software-intensive systems, tool support is a key success factor in Software Product Line Engineering[7] and Software Product Line Testing.

[1]Myers, Glenford J., The art of software testing, New York: Wiley, c1979.

[2]Geppert, B., Robler, L. F., Weiss D. M., Towards Generating Acceptance Tests for Product Lines,Software Reuse: Methods, Techniques and Tools: 8th International Conference, ICSR 2004, Lecture Notes in Computer Science, 2004.

[3]Yang, Q., Li J. J., Weiss D., A Survey of Coverage Based Testing Tools, Proceedings of the 2006 International Workshop on Automation of Software Test.

[4]Harrold, M. J., Testing: A Roadmap, International Conference on Software Engineering, Proceedings of the Conference on The Future of Software Engineering, 2000.

[5]Bertolino A., Software Testing Research: Achievements, Challenges, Dreams, International Conference on Software Engineering, Future of Software Engineering, 2007.

[6]Jaring, M., and Bosch, J. Representing Variability in Software Product Lines: A Case Study. In Chastek G. J. (Ed.): Proc. Software Product Lines, 2nd Int. Conf, SPLC 2, San Diego, CA, USA, August 19-22, 2002, LNCS 2379, p.15-36.

[7]Clements, P. and Northrop, L., Software Product Lines: Practices and Patterns: SEI Series in Software Engineering, Addison-Wesley, 2001.

Traceability in Software Product Lines

The quality of any product line depends largely on the importance attached to the development process and its evolution. A good software development process takes place in an integrated environment that manages the process of product development as well as its evolution. This is possible only if the development process sends back information relating to its behavior to the process management and the process management is able to use this information to control the evolution process. Therefore, in order for this to take place, a well managed traceability mechanisms are required. These mechanisms are based on the dependency relationships between the different artifacts of the product line development process and its environment. To evolve a product line development process, it is necessary to analyze the factors that contribute to the evolution.

First of all, in order to design the primitive mechanisms to support the evolution, Samuel A. Ajila and Ali B. Kaba [1] suggest that we need to be able to answer the folIowing questions:

1. What are the different types of changes that can occur in a software product line process?

2. How can these changes be classified?

3. Based on the identified changes, is it possible to provide a (reference) model of change that will define the different change management processes?

4. Can the model of change be used to capture the interactions between the different artifacts in the product line and can it be used to identify the basic mechanisms to support the evolution process?

Moreover, Samuel A. Ajila and Ali B. Kaba [1] show the dependency relationships between the product line (PL) artifacts. The relationships between the artifacts of a PL life cycle phase (e.g. product line phase) are divided into two: intra-relationships and inter-relationships. These relationships allow for two levels of horizontal traceability while the relationships between the phases allow for vertical traceability. Each product in the product line has a three-dimensional plane consisting of a set of intra-relationships, inter-relationships, and vertical relationships.

Therefore, we can see that the task of maintaining the traceability between artifacts is a challenge.

Traceability relations can be used to mitigate the difficulties associated with product line engineering. More specifically, traceability relations can assist with the:

1. Identification of common and variable functionalities in product members;

2. Reduction of inconsistencies between product members;

3. Reuse of core assets that are available in a product line system;

4. Maintenance of historical information of the development process;

5. Establishment of relationships between product line and product members specification documents.

However, the majority of the approaches concerning traceability for product line systems focus on traceability metamodels and do not provide ways of generating traceability relations automatically.

Recently, Waraporn Jirapanthong and Andrea Zismanhas[2] have been working in a rule-based approach to support automatic generation of traceability relations between feature-based object-oriented documents.

[1] Ajila, S.A.a, K.A. Using traceability mechanisms to support software product line evolution Memon A.M., Z. N. (ed.) Proceedings of the 2004 IEEE International Conference on Information Reuse and Integration, IRI-2004, 2004, pp. 157-162

[2] Jirapanthong, W. & Zisman, A. XTraQue: traceability for product line systems. Software and System Modeling, 2009, Vol. 8(1), pp. 117-144

Agile Software Product Line

In the column, Agile Software Product Line, Deconstructed and Mix and Match, John D. McGregor depicted the software product line through the SEI's practice framework and agile approach through the agile manifesto principles in order to discuss some options to combining these approaches in a software development and the implications of these.

Furthermore, John compared the pieces of each approach, and depicted some suggestions about how to re-construct a hybrid method, through the deconstruction the product line and agile practices.

Some personal assumptions were highlighted by John:

(i) Agile product line method can improve how we develop software intensive products

(ii) No one wants to do extra work

(iii) Strategic levels of reuse is what provides the productivity and time improvements that make the software product line approach useful

He assumes that agile is an adjective for software product line treating agility as a quality attribute of the process.

It is important to highlight that agile approaches are strongly based on incremental, iterative, adaptive and evolutionary approaches. Several agile methods are defined, documented and publicized (XP, SCRUM, DSDM, FDD). All these methods and approaches have a common base, the agile manifesto.

The agile manifesto has values and principles and John uses the twelve principles to deconstruct the agile approach.

As John, I don't disagree with any of those agile principles, as well as, the agile values. However, he remembers that maybe some relative term drove by the business goals is better. For example, in the face-to-face communication, in a scenario with few financial resources, what is the better? We have a person with experience occasionally or a person without experience every day!? I prefer a person with experience occasionally, and you?

The Software Engineering Institute (SEI) has developed a Framework with 29 practices that affect the success of a software product line organization. John uses this framework to deconstruct the process of a product line. He uses two different decompositions of the practices as the base for the discussion. Both decompositions have activities that are smaller and more tractable with agile practices.

The first decomposition is in the practice areas: Software Engineering, Technical Management and Organizational Management. The second decomposition is in the essential activities: core asset development, product development and management.

In the column, John considers that three dimensions have an affect into agile software product line method: the degree of commonality among the products, the volatility of the relevant domains and the size of products, teams, and of the organization. Considering the coordinate system 3 dimensions, the point position can indicate the agile degree into software product line, as well as, the systematic reuse degree into agile approach. Thus, this point can indicate the method for this context. See the image below, adapted from Barry Boehm.

John, remember that both agile and software product line approaches are collaborative, operate within a scope and maximize the amount of work not done. Moreover, agile accepts the requirement changes while software product line accepts variable requirements by anticipating and planning them by including variation points in the design of each asset. In addition, agile produces pieces of software early during the software development, while product building teams in a product line do so as well, by assembling and configuring core assets.

Thus, John described some method fragments that could be used in some particular situations. He described a proposal by starting with the software product line method (SEI's framework) and adding the quality of agility when it is appropriate and possible. Thus, the two approaches been arose: Micro and Macro approaches.

In the micro approach each of the 29 practice areas are examined in order to apply some agile principle. In Mix and Match it is addressed several specific practices.

In the macro approach it is necessary to identify a place where a narrow interface is possible and allow tasks on one side of the interface to use an agile approach. In the software product line, this interface can be the communication between core asset team and product building team. If the process of feedback among them is agile, then faster the core asset team can comply with new assets. Here, it is important to observe that both teams can apply independent methods. Thus, product building can use agile method to build their products independently from the core asset team, because product building team has a contact direct with the customer, though the context be stable, well-understood domain. On the other hand, core asset team can use agile approach because is an exploratory process that could have benefit from those highly-motivated people.

John summarized that there are evident synergies between the agile and software product line methods. Some research are being conducted in Calgary, Canada and Dallas, EUA where tailored instantiations of these methods preserving the basic characteristics of each method.

I think that others possibilities or adjusts in the John’s ideas can be thought to combined the approaches: bottom-up approach where the software product line is built iteratively from products instances; test–driven development approach that need all feature development be driven by acceptance tests defined by the business stakeholders. This acceptance tests are core assets that drive reuse of artifacts in the product line and the large-scale component-driven development each component with teams (maybe less 10 people) could apply agile approach individually, for component development.

Visualization in Software Product Lines

Software product lines (SPL) have become a reality in software development. Tools are appearing to deal with the different activities in SPL. One fundamental problem in software product line engineering is related to the fact that a product line of industrial size can easily incorporate thousands of variation points, and therefore, imposing a limitation of the amount of information that users are able to manage at the same time.

Visualization has proven useful to deal with large data sets and amplify cognition in many ways, for example, by increasing the “memory” and “amount of processing” available to users, by supporting the search for information, and by encoding information in a manipulable medium [1]. Then, in 2007, Nestor et al. [2] proposes some visualization techniques to improve some common tasks in SPL engineering.

Since, several works have been developed using visualization techniques, in different tasks of software product line engineering, for example: feature modeling, variability management, product derivation, design and implementation. How variability management and product derivation are essentials in SPL, the effort spent on these activities has been greater.

So, some questions remain interesting for discussion:

• Which others tasks could be benefited by visualization techniques?

Other tasks should be investigated in order to find advantages in using visualization

• Would be interesting create (implement) a visual framework to support all tasks of SPL projects?

To get more benefits and to avoid inconsistencies between the artifacts, tools should be integrated


[1] S. K. Card, J. D. Mackinlay, and B. Shneiderman, Readings in Information Visualization: Using Vision to Think. Morgan Kaufmann Publishers, 1999.
[2] Daren Nestor, Luke O'Malley, Aaron J. Quigley, Ernst Sikora, Steffen Thiel: Visualisation of Variability in Software Product Line Engineering. First International Workshop on Variability Modelling of Software-Intensive Systems (VaMoS 2007)

13th International Software Product Line Conference (SPLC)

Now in its 13th year, the International Software Product Line Conference (SPLC) 2009 was held August 24 – 28 in San Francisco, California. In this edition, the presence of industrial and academy people was remarkable, resulting in more than 150 attendees. Practitioners and researchers from different countries had the opportunity to discuss hot topics regarding to Software Product Lines area.

During the first two days, current SPL topics were discussed through different workshops and tutorials. Some workshops were realized at the first time, which indicates the emergence of new hot topics, indicating the need of investigation and study. For example, 1st workshop on consolidating community consensus in product line practice, which counter with the presence of different companies (SEI, BigLever, Yahoo, IBM), and 1st international workshop on Model-Driven Approaches in Software Product Line Engineering. Although the workshop on Dynamic Software Product Lines (DSPL) is in the third edition, this edition was marked by the research and practitioners discussion that did not achieved a consensus regarding to the concept of dynamic SPL, which highlights the lack of maturity in this field. They were discussing the difference between Dynamic SPLs and Single systems, since to dynamically change the code the software needs to be completely developed and integrated. The workshop Scalable Modeling Techniques for Software Product Lines (SCALE 2009 ), have Tomoki Kishi and Kyo Kang, and they start showing the problems when modeling scalable systems, for example, size, complexity, distributed environment, long life cycle and multiple stakeholders. In SPL context the main problems are variability management, configuration management, model based development and complicated development style. Later, the Service-Oriented Architectures and Software Product Lines (SOAPL) which was marked with the presence of the RiSE group represented by Flavio Medeiros, presenting the paper entitled "Towards an Approach for Service-Oriented Product Line Architectures".

On Wednesday, the first keynote speaker, Richard Gabriel from IBM discuss the about "Science is Not Enough: On Creation of Software", which presented a different perspective in the field. His talk was a mix between a talk and lecture including the strong relationship with arts. During this day, papers regarding to configuration, scoping and variability were presented and discussed.

On Thursday, the second keynote speaker, Jacob G. Refstrup - lead architect for the Owen software product line architecture from HP - which is used across multiple inkjet product families. He talked about "Adapting to Change: Architecture, Processes and Tools: a closer look at HP's Experience in Evolving the Owen Software Product Line".

On Friday, the last keynote speaker, Kyo Chul Kang presents the "FODA: Twenty Years ofk for feature analysis and simple but comprehensive way to modeling commonalities and variabilities. He also report the remaining problems of it, for example, addressing other parts of the life cycle (especially application engineering), clear the mapping between Perspective on Feature Models". Kyo shows that FODA has approximately 1300 citations, highlighting the importance of it. He presents as main contributions of FODA: systematic domain analysis, lying the groundworfeatures and software artifacts, standardization of feature model extensions, trade-offs between expressiveness and simplicity, scalability of feature model, managing complexity in view of many inter-dependent features, feature model evaluation and integration with UML model.

During this day the Goldfish Panel "How to Maximize Business Return of Software Product Line Development", had the presence of the most renowned researchers in the area as John D. McGregor, Dirk Murthig, David M. Weiss, Klaus Smith, Jan Bosch, Charles Krueger and Eduardo Almeida, which put in discussion the Brazilians company reality, reporting that they have not a specific domain and asking how is the best way to introduce the SPL approach in these companies. Others issues to think about were discussed as: Is it worthwhile at all?, What are the three top-most value-generating activities?, How to recognize where to focus efforts? (subsystem, functionality,..) and What was your worst ever product line experience?

Finally, the waiting hall of fame was presented by David Weiss showing the results of the evaluation from 2008 and presented the candidates for 2009. Two new companies were trying to have her names in the hall of fame, the TomTom company presents a GPS software product line and Lockeed Martin . In the end, the TomTom was nominated and will be evaluated during this year. The results will be available in the next SPLC 2010 held in Korea.