- Nov 22, 2016
- 1,409
- 1,655
- 136
A few questions for the audience, I'd prefer responses only from those with experience at this please (sorry for anyone that doesn't, I mean no offence, but postulation and speculation aren't gonna help me here!).
As far as I can see, there are three approaches to reusable software components:
1. opportunistic
2. systematic
3. product lines
Q1: If you were in relatively small scale manufacturing, making somewhat disparate products with only a few having commonality at the moment, is it worthwhile to try going beyond opportunistic?
Q2: Regardless of above question, what do you think are the three most important things to get right to make each of the above work (preferably speaking from experience)?
-------------------------------
I've seen systematic go horribly wrong, I've seen opportunistic work quite well given its limited scope. I've never been involved in software product lines.
I'm hoping someone will post up something I haven't thought about when trying to implement at least some aspects of reusable components within an R&D environment that currently doesn't.
My current (main) list is (more for systematic than opportunistic, of the below, (b) and (d) would carry to opportunistic):
(a) air-tight requirements with full traceability (including data dictionaries and variable bounds).
(b) repository/repositories that is/are easily searched.
(c) air-tight requirements.
(d) use of wrappers and dictionaries for going between high level application and low level API.
(e) did I mention top quality requirements?
As far as I can see, there are three approaches to reusable software components:
1. opportunistic
2. systematic
3. product lines
Q1: If you were in relatively small scale manufacturing, making somewhat disparate products with only a few having commonality at the moment, is it worthwhile to try going beyond opportunistic?
Q2: Regardless of above question, what do you think are the three most important things to get right to make each of the above work (preferably speaking from experience)?
-------------------------------
I've seen systematic go horribly wrong, I've seen opportunistic work quite well given its limited scope. I've never been involved in software product lines.
I'm hoping someone will post up something I haven't thought about when trying to implement at least some aspects of reusable components within an R&D environment that currently doesn't.
My current (main) list is (more for systematic than opportunistic, of the below, (b) and (d) would carry to opportunistic):
(a) air-tight requirements with full traceability (including data dictionaries and variable bounds).
(b) repository/repositories that is/are easily searched.
(c) air-tight requirements.
(d) use of wrappers and dictionaries for going between high level application and low level API.
(e) did I mention top quality requirements?
Facebook
Twitter