This article is based on examinable work that I submitted for the postgraduate Open University module M813 – Software Development.
Software components
With the end of the 19th century came the introduction of the now ubiquitous form of transportation that is the automobile. Early models were mostly hand crafted by skilled operators and priced accordingly, which was prohibitive to their widespread adoption. Industry pioneer Henry Ford then developed and capitalised on a new method of mass production, utilising standardised components that could be easily combined to form a complete, cost-effective product (Sakai and Amasaka, 2008).
The notion of reusable software components dates back as far as software engineering practice itself, take for example the utility libraries for sorting and maths functions proposed by Mcllroy (1969). Modern object-orientated technology continues to build on these foundations, with computing students now being universally taught design principles such as programming to well defined interfaces and striving for loose coupling between classes, in order to promote reuse and aid future maintenance.
Current trends
While certain industries are starting to benefit from commercially available software component libraries, such as those bundled with the Java Enterprise Edition, many organisations are still relying on skilled engineers to effectively hand craft projects from scratch. An example of this practice is described in a case study by Clements and McGregor (2012), which focuses on the company Cummins Inc.
Cummins produces a market leading range of diesel and natural gas engines which share similar software based control systems. When the need arose for a new engine model, the company’s initial development strategy involved engineers copying software from previous designs and modifying it to suite the new requirements. This approach was both technically challenging and labour intensive, taking a large team of developers an average of one year to bring a new engine to market.
However by shifting their focus from the development of a single engine at a time to the creation of a library of software components that could then be deployed on a family of future engines, the case study shows that Cummins were able to drastically reduce their overheads. Average software development times were reduced to one week, with a typical project team consisting of only one or two members. The company now outputs fourteen times the previous number of products using only two-thirds of the software resources.
Software product line engineering
This development paradigm is referred to as software product line engineering (SPLE) and was the basis of a critical literature review that I carried out for the end of module assessment (EMA) in my previous Open University MSc module.
Fundamental to the development of a software product line is an understanding of the products that are to be included, their common features and their variation. This process however is not as simple as just considering the set of components or classes that are to be included in each product (Andersson and Bosch, 2005).
Indeed, the SPLE development paradigm differs from a traditional software development process at all lifecycle stages. For this reason, I chose to analyse three recent peer-reviewed articles covering topics ranging from initial project conception and scoping, through to product design and variation management, and finally strategies for testing a product line.
Conclusions
While the EMA itself was a relatively substantial piece, coming in at around 2,500 words, it was concluded that all three of the articles analysed did offer useful contributions to the subject area.
The authors of each article however also expressed concern over shortcomings in the existing literature. One author commented, for example, that many research concerns regarding product line testing that were originally described in 2003 have still not been addressed over a decade later.
Therefore, much like the automotive industry pioneer Henry Ford, any organisation hoping to achieve benefits similar to those enjoyed by Cummins Inc. must be prepared to carry out their own practical process experimentation.
To learn more about software product line engineering, a good initial resource would be the Product Line Hall of Fame.
DW.
References
Andersson, J. and Bosch, J. (2005) ‘Development and use of dynamic product-line architectures’, IEE Proceedings — Software, vol. 152, no. 1, pp. 15-28.
Clements, P. and McGregor, J. (2012) ‘Better, faster, cheaper: Pick any three’, Business horizons, vol. 55, no. 2, pp. 201-208.
Mcllroy, M. (1969) ‘Mass-produced software components’, in P. Naur and B. Randell, (Eds.). Software Engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7-11 Oct. 1968, Brussels, Scientific Affairs Division, NATO (1969) 231pp.
SAKAI, H. and AMASAKA, K. (2008) ‘Demonstrative Verification Study for the Next Generation Production Model:: Application of the Advanced Toyota Production System’, Journal of Advanced Manufacturing Systems, vol. 7, no. 2, pp. 195-219.