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?
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?
4 comments:
This question sounded to me like: should I make the SPL [all the products related to it] from the scratch [defining the scoping, design, etc] or build it from the existent products? If I understood it right, it seems that the rework is inevitable independently of the path you choose.
If you choose to build it from scratch you will need to develop all products again [with the benefits of SPL], and if you choose to reuse the existing ones you will need to face the existing decision problems. I believe that the later choice is the short path.
Hi Yguarata, let I try to explain better the scenario. I have the products and their source code.
I decide to take a look on them to identify their features. With the features for each product, I can define, for example, a Product Map for my whole SPL.
With this vision, I can start, for example, my design. HOWEVER, as you can see, I will start the design based on the SPL as IT IS, i.e., its current state. It is, I can build the SPL repeating the same mistakes.
So, my point is: Should I recovery the design, evaluate it, and with the improvements identified, improve the scoping AND starting from here, build my SPL?
The point is about the relationship and feedback between these both activities.
Hi Eduardo, I believe the the architecture creation of a product line is (or at least should be) different from the single architectures from single products. In other words, not necessarily the same mistakes of the single architecture definition will be repeated into the product line architecture (PLA).
HOWEVER, of course rationale from the single architecture are great inputs for the PLA definition, since the architects can now avoid some pitfalls and errors of the single product definition.
Furthermore, in the scoping phase you should also plan for the future features (beforehand), and take those features into consideration (of course only the ones that will have impacts on the architecture) in the new PLA architecture. By doing that, you are no longer basing your design on the products as they are in the current time, but you are also considering future changes.
Another possible vision, is that scoping and designing are connected, since you design only what you will have, or your scope (and incrementally). That means that even if you design based on the current state of the products, the design should (definitely should) be refactored each time a new feature arises, and by doing that you can garantee to have updated architecture, and incrementally move towards a more stable and complete architecture. [but of course, code refactors are another story, and should be supported by other techniques such as TDD]
this comment is just to follow up with the answers...
Post a Comment