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).
2 comments:
I see this work as a great contribution to the area. As we talked in class, I missed a slide about the main picture of your propousal, saying that scoping would be only a part of your research.
Again, I raise the question I've already asked: would it realy be a weak point not to identify available assets to reuse? There might be a good reason not to do this during the scoping process. I think that identifying code assets too early in the process can be deceiving. A good approach could be adding more asset kings as the spiral turns and the scoping process begin again.
I agree with Ricardo. I would like to see a general picture of the area and showing where your approach will work. In addition, I think that a systematic review will help to identify gaps in the approaches in a more systematic way. At the end, during the first hands-on experiences with the initial approach in the reuse tools domains we could see it working in more details and identify issues for improvements.
Post a Comment