BS ISO-IEC 26550-2015 pdf free download – Software and systems engineering — Reference model for product line engineering and management
4 From single-system engineering and management toward product line engineering and management
Single-system engineering and management is the dominant way of conceptualizing and developing software and systems products. This Clause first outlines some of the main challenges software and systems product companies face in using single-system engineering and management approaches. It identifies variability management as the most challenging area. Variability management is discussed in 4.1. The clause concludes by explaining major differences between single-system engineering and management and product line engineering and management. Understanding these differences is a key for successful organizational transitioning from single-system engineering and management toward product line engineering and management.
4.1 Challenges product companies face in the use of single-system engineering and management
The excessive use of single-system engineering and management in environments where the assumptions no longer hold contributes to a variety of issues encountered by customers, end-users, and providers. For example, customers may feel their needs are unique and acquire and sustain expensive tailored systems while commoditized, inexpensive products might be completely adequate. End-users may experience that the functionality they really need is difficult to find and/or use because the software systems are too complex and provide too much functionality. Finally, a provider may sell several interrelated products, which look and feel completely different and do not interoperate, even to the same customers.
Providers of single products typically encounter at least some of the following issues when using single-system engineering: work efforts and costs are underestimated, productivity is overestimated, must-have features are missing, product schedules and/or quality goals are not met, and/or customer satisfaction remains lower than expected. Work efforts may be underestimated and productivity overestimated because the organization has never before created a similar product or if it has, the organizational unit who created the similar product may not want to share its experiences and other possibly reusable assets due to rivalry between organizational units. Inaccurate estimates together with typically fixed budgets result in schedule fluctuations, missing features, and/or quality issues. Quality issues may also result from the lack of a reuse culture because the software developed from scratch typically has much higher defect density than the software reusing well-tested components.
The accommodation of adequate variability is typically the most significant problem faced by the providers of single products. In this context, the variability needs typically emerge over time from interactions with various customers. Providers commonly use one or more seemingly simple but ineffective tactics to deal with emerging variability. For example, a provider may incorporate variability into a single product by introducing more and more (partly end-user-visible) parameters in the product and more and more if-then-else-statements in the source code text of the product to deal with the parameters during run time. As a result, the number of source code lines grows, the source code becomes increasingly complex to understand and maintain, and the testability (and often also the performance) of the software deteriorates. Alternatively, a provider with an existing product may deal with the variable requirements of a new customer by branching a new product from the existing product, modifying the source code of the new product, merging the modified source code back to the main line when there is time and other resources available, and finally deleting the branch. Branching and merging is very expensive and error prone and the source code of the main line will typically become very complex after a few branches and merges, requiring expensive periodical refactoring to utilize the tactic on a long term basis. BS ISO-IEC 26550 pdf download