The Rise and Fall of Product Line Architectures

During the 14 International Software Product Line Conference (SPLC), I was co-organizing a panel with Isabel John and Christa Schwanninger about the The Rise and Fall of Product Line Architectures.

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

The Scoping Process in Software Product Lines - Is there any relationship with Design?

I believe that the scoping process is very important to start a product line project. [If you are not familiar with the topic see Isabel John's papers about it and our systematic review].

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?

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”;

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.

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

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)

IV Workshop to Introduce Reuse in Enterprises (WIRE) - Workshop Report

4th WIRE, the Workshop to Introduce Reuse in Enterprises, the right place to discuss the state of the practice and exchange experiences with the most important reuse experts from Brazil and the world as well, was held at the Hotel Atlante Plaza in Recife, Brazil, in the last June 29 and 30.

The workshop attendance joined reuse practitioners from industry and academy. This year, people from 10 states in Brazil, and from European countries (Portugal, The Netherlands and Ireland) as well, comprising a set of 17 companies and 5 universities, came to the event.

Great discussions on reuse topic were performed, in which practitioners conducted a very interesting environment to discuss such a topic. This edition, WIRE were mainly concerned about the strategic reuse adoption based on Software Product Line (SPL) aspects, with the presence of important experts in this area, John D. McGregor, from Clemson University (US), presenting the tutorial Building Reusable Testing Assets for a Software Product Line and the keynote entitled Goal-driven Product Derivation; Frank van der Linden, from Philips Research (The Netherlands), with the tutorial Software Product Line engineering, the practical aspects, and a speech on Applying open source development in product line engineering; and Eduardo Almeida, from C.E.S.A.R (Brazil), presenting the topic Software Reuse Measurement: What the Experts Think about It.

Moreover, work-in-group sessions (see a picture of this activity in the left) were performed that enabled the attendance to discuss the following questions: 1) What are the main pitfalls and challenges to the SPL adoption in your company and how they can be handled? and 2) Which changes must be implemented in the organization in order to address such issues? This effort made possible to attendance to exchange experience and ideas to be applied in order to solve still opened questions regarding SPL adoption in companies.

At the end of the event it was announced that next WIRE, the 5th edition, will be held in São Paulo - Brazil. We will be pleased to receive you in a next turn in order to make our discussion even better!

In name of the organization, I would like to say thank you for the participants, lecturers, and sponsors. See you next year at WIRE!

Revisiting Parnas: On the Design and Development of Program Families

The paper presents a comparison between techniques to develop program families. “Stepwise refinement”, introduced by Dijkstra, tries to develop programs through the use of informal, intermediate representations of programs that are then refined. The refinement introduces the design decisions by implementing the informal program in actual languages.

The technique introduced by Parnas is called “Module Specification”.  In this technique, the intermediate stages are specifications of behavior that is “encapsulated” into modules. He asserts that this approach leads to decrease the final cost of producing the software as the modularization helps to deal with complexity. Also, the use of modules and specifications helps to postpone design decisions, particularly those that will differentiate family members.

Sometimes, Parnas focus seems to be only to broaden the family possibility, in other words, increase the amount of variation points. This occurs specially at the beginning of the process. His strategy aims in making the design to enable the postponement of the decisions. In some sense, he puts the focus of a software family as it was to have as many members as possible.

Although the use of information hiding to postpone design decisions points is an excellent way to create variation points, leading to the Strategy design pattern, I think it should be used with care because it could lead to overgeneralization of the modules. Modules that are unlikely to change or vary may have to carry the complexity needed to implement the improbable variation. Maybe, this occurs only at early stages in the process.

The most interesting point is that the author starts thinking about planning before developing a program family. He also gives importance to the order in which the design decisions are made. This suggests that an approach for software families should choose the degree of importance of each aspect and characteristic so that the resulting program addresses its purposes properly.

12th International Software Product Line Conference (SPLC) - Conference Report

Last week, during September 8-12, in Limerick, Ireland, was held the 12th International Software Product Line Conference (SPLC). The conference put together more than 220 researchers and practitioners from several places around the world interested in several issues about software product lines.

In the first day, initial ideas were discussed in four workshops approaching Dynamic Software Product Lines (a mix from adaptive systems, middleware and SPL ideas), Aspect Oriented and SPL (conducted by Vander Alves and his colleagues), Service-Oriented Architectures and Software Product Lines and Software Product Line Testing. In my opinion, these workshops discussed current hot topics in the field with some ones more consolidated than others. For example, the community does not have a common understanding about Dynamic Software Product Lines yet. On the other hand, some areas such as testing and AOP start to be more concrete with the integration. In addition, some tutorials were also important to disseminate the topic.

On Tuesday, we had the first keynote speaker: David Parnas. David started discussing his inspiration with the Fred Brooks’ work, and discussed his brilliant ideas about program families and other experiences. His talk was titled Multi-Dimensional Software Families: Document Defined Partitions of a Set of Products. David also discussed about the importance of documentation in software development. Another remarkable moment was his warning about the paper counting process, it was very important. David said that one important point in his papers is that it is still applicable today and makes total sense [This book is a compilation of his work. I strongly recommend it.].
For me, it was special because one day before I was introduced to him by David Weiss. I did not have much time to talk to him but it is very good when you have the opportunity to meet someone that was inspiration in the field for you. David said about his experience in Brazil years ago and other points. My first advice here is to carry on your camera all the time. [I did not have my camera there]. After the talk, David left the conference. Actually, I would like to see him more around.

Next, the sessions were started in parallel. The first one, involving feature models and the second one: SPL experiences. I decided attendant for the second one and it was good. Experiences in banks, automotive and embedded were presented. In this section, Dirk Muthig and his colleagues from Fraunhofer Institute showed their two experiences. Closing the sessions, time for lunch and discussing SPL with different people. In the afternoon sessions, information retrieval and clustering were integrated to discover product lines requirements. At the same time, it was started a panel with experts on scoping. I decided to keep my focus on the first area but I would like to see the second too. During the last sessions, after coffee, I decided to do a merge and saw a presentation about clone detection and SPL and switched for the other room to participate in a good discussion about the SPL roots and its foundations in the software reuse (during the Software Productivity Consortium) area by Grady Campbell. In the end of the day, we went to a reception in a pub with music, food and few of the Irish culture.

On Wednesday, the second keynote speaker, Luc Koch from Phillips Medical System, presented their experience in Phillips Healthcare discussing the past, present and future of this effort. Next, the sessions started and I had to decide again which one to attendant. I did a good choice and DSL and Code Generation was widely discussed. In the afternoon, I participated in a working session about the possible integration between Agile and SPL. It was very good and you can see the summary here. Finally, we ended up in the conference dinner in Irish castle. It was awesome with wine, dance, music, food and more wine.

On Thursday, the conference started with an industrial panel leaded by Charlie Krueger and other companies discussing their experiences in the field. It showed different views and impressions by the companies with different levels of expertise. After the panel, the sessions started and I participated in one about Service-Oriented Product Lines. It was very good but we can see that we have too much room for research in this direction.

After that, it was time to see some tools demo and participated in the Product Line Hall of Fame conducted by David Weiss and Paul Clements. That was awesome. The ceremony is very good with perfect sound, video, lights and sure, their presentation. Everybody loved it. Two companies were nominated. The first one was conducted by Krueger.

In the last day, we have another good agenda with some tutorials, workshops and the Doctoral Symposium. I decided to participate in the last one for two reasons: the first one because I will be the Doctoral Symposium chair in the next year, and the second one, because I was interested in seeing the new research in the field and the future new researchers. The session was conducted by Klaus Schmid and had four presentations discussing since agile and SPL until testing and aspect. The good point here was to see one work from Brazil there. After that, the conference finished.

In summary, the conference was very good with people from industry and academy from different countries, with new ideas, tools and important experiences. Next year, I hope see you in San Francisco, California.

Get the call for papers here.

Product Line Stakeholders - Do you know them?

Managers, Architects, Analysists, Testers, Software Engineers, CEOs...

It was a discussion with RiSE members about who are the stakeholders in a product line approach.

The idea is to define who they are, what they do, and in which phase during the life cycle they participate in the process. We would like to know your opnion based on your research, practical experience or just ideas.

More on Software Product Line Design

In this post I'll bring some initial work from my master thesis, which will bring some contribution on Software Product Line in the Digital Television Domain. Entitled "Designing Software Product Line Architecture", this talk was presented today at the Seminars in Software Reuse course at Cin/UFPE. It shows a survey on the well known Product Line Architecture Methods, comparison of those mathods by Marinlassi, M. and a nice state-of-art work by Hendrickson, S. A. & van derHoek A..

Software product line engineering is a pro-active reuse approach. It introduces software reuse in large scale, throughout the organization. Its adoption benefits from lowering costs and time-to-market as well as raising product quality.
The five best known architecting methods for Software Product lines, which were surveyed in this presentation were the FAST method, by David Weiss; FORM by Kio Kang, that focuses in the feature analysis and develops its architectural model based on its feature model; COPA, developed inside Philips, which is probably the most extense method, covering also organizational issues; the QADA method, by Matinlassi, focuses on architectural quality attributes and proposes designing and assessing the architecture; and last, but not least, the KobrA method, developd by Atkinson, inside the Fraunhofer Institute as a concrete, component-based, object-oriented instantiation of PuLSE-DSSA.
Besides the well known methods proposing a new way of modeling product line architectures, Hendrickson bases his work on change sets and relationships between those change sets. An interesting alternative for tackling complexity.
Agreeing with Matinlassi's comparison of the well known methods, the KobrA approach is the simplest one. It is very pragmatic and focuses directly on defining a conceptual architecture and realizing it through component-based development. The key activities in the KobrA approach are those related to context realization (Application Context, Framework Context...). Therefore, a worthy contribution shall come from closing this gap between the conceptual approach and the Digital TV application domain.

The slides are available here for download, already with some extensions suggested this morning, at the classroom.

Software Product Line Design

In this post I will bring topics about my master thesis presented (see) in Seminars in Software Reuse course at Cin/UFPE. The title is "An approach to software product line Design" where I brought an evaluation of existing Software Product Line (SPL) Design approaches for discussion.

Nowadays software reuse is very important for every software company mainly because it reduces software construction effort and consequently the time to market. SPL is an approach that has being adopted for organizations to address the software reuse issue. The Main objective of SPL is to organize the common assets from a software application domain and instantiate a new application based on these assets including just specific ones from the application. An important point to address in SPL is the variability and commonality from domain. This make possible the mass customization what bring to SPL configuration mechanisms to address specific client needs from the software application.

The focus of my work is on the Domain Design subprocess from the Software Product Line Process in Mobile Game domain. The motivation for the work is the lack of works in academy addressing this issue and the need of the industry to have a process where they can reuse the maximum number of possible assets and address the difficult task of porting the same game on different platforms and models. It was evaluated the FAST process developed by David Weiss at Lucent Technologies Lab. The FAST process focus on variability in a family of products to the telecommunication infrastructure and real-time systems domain, using a commonality analysis as the entrance for design and an architectural modeling language (AML) for specifying family members. After the FAST process guides to design the family and mapping between the AML and the family design. Another presented method was the QUASAR developed by Jan Bosch at Technical Research Center of Finland. QUASAR method focus on the quality of architecture and have two phases: Design and analysis. CoPAM approach is used for sharing knowledge between domains in a company with commonality layers. This brings an increase in reuse, since there is a mix of domains in the sense of commonality. Hassan Gomaa developed the PLUS method that is compatible with the Rational Unified Process (RUP) focusing on the domain architecture with the design of components. The RiSE process for Domain Engineering (RiDE) was developed by Eduado Almeida with the purpose of addressing a general domain. The RiDE process design method has steps where the architect should decompose the modules, define the architectural and design patterns of the domain and structure use cases in components.

It was presented a draft approach based on the CoPAM approach for reuse the major part of the available assets in the game architecture domain architecture reference.

Ednaldo Dilorenzo

Software Product Line Scoping

The goal of this post is present the main topics of a survey performed in software product lines scoping. This survey is part of my master thesis, in which I will define an approach to requirements engineering for software products line. The basic steps of the approach are scoping, elicitation, modeling, validation and requirements management.

Scope gives support for all further product line activities, so it is very important. But some challenges are identified in scoping, such as scope size, wrong products, absence of essential stakeholders, economic problem, social problem , specific context and different needs of organizations.

In the survey, were analyzed 9 approaches. For each approach were identified: activities of scoping, strengths and weaknesses. Then, the more relevant activities found on the survey were grouped on a matrix and the approaches were compared.

The conclusions of the analysis are: the more complete approach is Pulse Scoping Process; the Pulse-ECO is the more referenced approach in the literature identified in this work; few approaches have activities to treat social problem of scoping; one approach has one activity to identify available assets; only one approach defines relation between domains; and only one approach has guidelines to different contexts.

Before this scenario, my initial proposal to software product line scoping is to adapt Pulse Scoping Process to the software reuse tools domain, adding activities to: help the marketing team on product portfolio scoping (e.g. identify customer segments, prioritize each segment; identify essential stakeholders); identify sub-domains and their relations; consider view point of the whole optimal and of the individual optimal; identify available assets.

The presentation (see) of the survey was done for the I.N.1.0.3.8 - Advanced Seminars in Software Reuse course at Cin/UFPE. Participants of the seminar discussed about the approaches comparison criteria and risk in reuse the available assets. The reuse of available assets can reduce efforts, but is necessary evaluate their impact in product line. The approaches comparison matrix can be improved (e.g. define the level of completeness of each activity in the approaches).

Using Requirements Management Tools in Software Product Line Engineering: The State of the Practice

Last week we discussed the paper "Using Requirements Management Tools in Software Product Line Engineering: The State of the Practice" which was published in SPLC 2007. The paper analysis the current scenario of requirements tools being used in Germany companies, and identifies the tools weakness to support software product lines requirements. As result, the authors proposes a set of requirements for requirements management tools.
The majority of the authors work in the industry, and because of that they did not define a systematic approach to do the analysis. They said that it was all based on practical experience, but should it be enough? Doing it does not increase the chance of bias in the research?
Besides, the requirements defined for requirements managements tools were too superficial described, some lacked of reasons why to include it, while others did not explained how it could aid the a software product line process.
On the other hand, the paper was derivated from a report, which may explain what was not very clear in the paper.