As previously posted, we analyzed current problems in product line engineering. One case study was a healthcare software product line, one was a business software product line, and one was a telco carrier software product line. All developers in their respective product line were homogeneous in time and culture (one main location, one social culture), that is, we had no problems of globally distributed software development. This both made the analyses easier but also limits the generalizability of our conclusions.
We presented our analysis using cause-and-effect chain diagrams. The following figures shows an excerpt of these diagrams.
One important cause and effect chain starts with the recognition that the traditional domain engineering process, in which product units contribute requirements for the platform to develop, is not effective in terms of communicating these requirements well. Rather, they are often first misunderstood and need repeated communication. Here are a few selected quotes from our case study participants:
- “Our silo culture and the lack of collaboration hinders the effectiveness of domain engineering. We seem to never agree on […] important reusable assets […]” Developer (product unit), case 1.
- “We didn’t understand the reusable asset requirements as communicated by the product units. […] Not much worked when we first delivered the component.” Developer (platform), case 1.
- “Reusable assets often don’t work. They don’t meet our [product unit] requirements.” Manager (product unit), case 1.
Thus, insufficient collaboration between product units and the platform limited the understanding of new requirements and therefore led to an increased defect rate and rework. Please note that this problem is inherent to how domain engineering is being performed today (but can be solved with an inner source approach).
Read next about political power play between product units.
Leave a Reply