Showing posts with label requirements. Show all posts
Showing posts with label requirements. Show all posts

Wednesday, September 2, 2009

35th Euromicro Conference on Software Engineering and Advanced Applications


On last week, between 27-29 August, it was run the 12th Euromicro Conference on Digital System Design (DSD) and the 35th Euromicro Conference on Software Engineering and Advanced Applications (SEAA) 2009.

Both conferences took place at the Cultural and Conference Center, in the University of Patras. The event put togther research from various places of the world. All of them interested in discussing new ideas, such work in progress, and concluded work. The RiSE group was represented by Yguaratã Cerqueira Cavalcanti, in the SEAA 2009 sessions, where he presented three works from the group, as follows:

1 - Martins, A. C; Garcia, V. C.; Almeida, E. S.; Meira, S. R. L. Suggesting Software Components for Reuse in Search Engines Using Discovered Knowledge Techniques, 35th IEEE EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA), Service and Component Based Software Engineering (SCBSE) Track, Patras, Greece, 2009.

2 - Neiva, D. F. S; Almeida, E. S.; Meira, S. R. L. An Experimental Study on Requirements Engineering for Software Product Lines, 35th IEEE EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA), Service and Component Based Software Engineering (SCBSE) Track, Short Paper, Patras, Greece, 2009.

3 - Silva, F. R. C; Almeida, E. S.; Meira, S. R. L. A Component Testing Approach Supported by a CASE Tool, 35th IEEE EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA), Service and Component Based Software Engineering (SCBSE) Track, Short Paper, Patras, Greece, 2009.

The paper "A Component Testing Approach Supported by a CASE Tool" was presented in the SCBSE: Component-based Systems Correctness and Test session. In conjunction with this work, several other articles were presented , showing really interesting approaches.

The paper "Suggesting Software Components for Reuse in Search Engines Using Discovered Knowledge Techniques" was presented in the session SCBSE: Experiences and Applications. And th paper "An Experimental Study on Requirements Engineering for Software Product Lines" was showed in the session SPPI: Empirical Approaches.

All the work presented were very interesting. People showed a lot of new ideas to solve the most well know problems regarding SCBSE, and the importance of the empirical approaches session should be emphasized, since there is a lack of well made empirical validation in most of CS work.

Oh, we had also a very amazing gala dinner organized by the Euromicro committee, in front of a very beautiful beach. There we could taste really nice Greek food, and it was also possible to see some Greek dance and to listen Greek music. Really nice!!!

The next Euromicro will take place on Lilly, France. I hope to see you there.

Monday, November 5, 2007

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

Sunday, October 28, 2007

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.