LogicLibrary have produced a nice whitepaper on Selling Software Reuse to Management (PDF, opens in new window).

The paper begins by looking at how to build a business case for software reuse. The authors have found that using easy-to-understand metrics is sufficient to convince management of the potential benefits of reuse e.g. noting that reuse can save 50-100% of effort compared to writing something from scratch.

The second part of the paper notes that developers can build better software that satisfies more people by assessing customer needs across a broader audience than they would normally have done. This is partly because in looking at a wider range of customer needs and approaches the developers get more information on best practices and how to embody these in a generalised set of software assets (as in a Software Product Line). Another observation is that modern platforms (.NET, J2EE) seem to encourage this more generalized approach to software development.

One comment I’d make is that it often isn’t senior management who are the barrier to improved software reuse – they usually understand the benefits and costs of reuse. Product managers on the other hand are paid to focus on the products they manage and this often works against sharing reusable assets across products. (Some) developers also have a mistrust of using others software, or are motivated by writing stuff from scratch rather than by reusing the work of others. In these cases a strong software architect or software product line manager is needed to balance these various factors to deliver the benefits of a successful software reuse programme.

December’s SPA Cambridge meeting saw John Daniels of Syntropy talk about Sun SPOTS. John has been working with the devices for a good part of this year so it was an ideal opportunity to learn about what they were capable of.

Sun SPOTS are small wireless sensor devices that run Java ‘on the metal’ as John put it. The devices shown had accelerometers, light & temperature sensors, LEDs, buttons, digital and analogue inputs, and digital outputs.

John showed various ‘applications’ of the device including use of the device’s LEDs to show messages (ably assisted by the glamourous Charles Looker), tracking device motion (and graphing this by send the data back to a Sun SPOT connected to John’s laptop), communication between the devices to transfer a light token, and an on-the-fly demo of light detection – bravely coded up live in the manner of the best improvisations. More practical applications include machine control, environmental monitoring, security, vibration detection & emergent behaviour.

The devices are an output from an on-going project at Sun Labs, but they will be available commercially some time soon. Two thousand packs of them (each pack has two remote sensors and one base station) are apparently sitting in a warehouse somewhere as I write. Perhaps if you have a word with Santa you could get one…

The article on Software Product Line Engineering with Feature Models that I co-authored with Danilo Beuche of pure-systems has now been published in the Winter 2006 edition of Methods and Tools. A slightly longer version of the article (PDF 568kb, opens in new window) is now available on the Software Acumen website.

The article covers Domain Engineering – development of core, reusable assets to support the Software Product Line – and Application Engineering – selection and configuration of core assets to realise applications.

Also introduced are the concepts of Problem Space – the marketing or customer view of a Software Product Line as embodied in a Feature Model - and Solution Space -the engineering (or software architect’s) view of a Software Product Line as embodied in a Family Model.

The article explains these concepts using the example of a weather station product line and discusses a number of typical Software Product Line problems and solutions in this context.

The article gives such a nice overview of Software Product Line Engineering in an embedded system setting that I wish we’d written it before now…

Arvind Hosagrahara and Paul Smith’s article on ‘Measuring Productivity and Quality in Model-Based Design’ got me thinking about metrics for model-based development and Software Product Lines in particular.

In the article they argue that LOC-based metrics aren’t all that relevant in a model-based development setting – because code is produced automatically – and so more emphasis must be placed on other metrics.

They also argue for automatic data collection in preference to manual data collection – in my experience the former are strongly preferred – it’s just plain hard work to get people to collect data manually and it’s rarely necessary given the wealth of data that can be collected automatically, and naturally, as part of everyday tool use.

The article describes a tool they’ve developed (the Modeling Metric Tool) for automatic measurement of Simulink® / Stateflow® models. This is a customizable tool that allows collection of data around time spent working on a model, resources used, model size, functional content of the model, automatic vs. hand-written code etc. The code for the application was freely available at the time of writing.

In a Software Product Line setting, additional metrics for model-reuse would be essential. These could show how effectively the product line architecture was supporting product variants. They could also pick up problems where a product variant was not making sufficient use of the product line’s reusable assets. Productivity metrics could also be used in validating the business case for the Software Product Line.

NB Simulink and Stateflow are registered trademarks of The Mathworks Inc.

I dropped by Hillel Glazer’s Agile CMMI blog recently while thinking about the relationship between Agile methods and ISO 9000 / TickIT.

Hillel points out that CMMI (like ISO 9000 and TickIT) doesn’t expect documentation – what it expects is evidence of a process being followed. Given this, Agile methods should not be considered de facto incompatible with CMMI or ISO 9000 and TickIT for that matter.

An article by Keith Southwell entitled Agile Process Improvement? goes into similar ground and explicitly analyzes the Agile Manifesto against ISO 9000:2000 / TickIT Guide Issue 5.0. Keith’s analysis also suggests that Agile is not incompatible with these standards although in some cases there may be a slightly different emphasis.

The December 2006 issue of Communications of the ACM focusses on Software Product Lines.

The editor writes: “The software product line (SPL) has surfaced as one of the most promising software development paradigms for dramatically increasing productivity and one of the key elements in the quest to discover new ways to use existing architectures and components.”

Articles cover topics including SPL testing, SPL Product Management and introducing SPL into an organisation.

Microsoft has signed as a Gold sponsor for our upcoming Code Generation 2007 conference.

I don’t yet know exactly who from Microsoft will be present at the event but there will be a chance to explore their Domain-Specific Language Tools for Microsoft Visual Studio. These enable you to create a Visual Studio editor for your own diagrammatic modelling language, with the ability to generate code and other artefacts from the models.

Our first corporate sponsor has signed-up for next May’s Code Generation 2007 event.

Metacase, supplier’s of  MetaEdit+, a toolset for building Domain-Specific Languages, have joined as Silver sponsors of the event.

The company’s Juha-Pekka Tolvanen and Steven Kelly will join other industry veterans participating at the event.

 

An article in Oct / Nov 06’s Automotive Electronics magazine describes the role that programmable logic devices can play in providing a platform for different automotive designs.

The article notes that car manufacturers have for decades used the approach of having a common chassis for different vehicle types in their product lines – with vehicle types differing in bodywork, engine, trim etc.

By using a common platform with variable elements manufacturers have realised significant benefits in terms of reutrn-on-investment and time-to-market.

The article notes that automotive electronics (and software) developers have begun to use this approach to gain the same benefits and to enable systems that differ for each model, price-point or geographic area to be developed efficiently.

This platform, or ‘programmable product approach’, cut development time on Blaupunkt’s Trevelpilot Rome automotive navigation systems by six months according to the article, and is finding applications in other automotive applications such as infotainment and communications.

A similar approach should be possible in other sectors, and the article notes consumer electronics, home automation networks and computer peripherals as candidates.

The article also notes some other benefits of the platform approach:

1. Allows more product differentiation with potentially better margins.
2. Can reduce risk of product obsolescence.
3. Platforms look better engineered and so may positively infleunce your client’s perception of you.

Regular readers will recognise the similarities of this approach to a Software Product Line approach. 

The call for papers for SPLC 2007 was issued a few weeks ago and we’ve been thinking about what we will submit.

We ran a successful tutorial at SPLC 6 on Software Product Line scoping called The Scoping Game, and will probably submit a proposal for an improved version of this session. We received good feedback from participants in this session and some have been kind enough to keep in touch to help us refine the session.

We’ve also been working on a paper on best-practice in Software Product Line adoption, but this is still in an early stage of development, so we may not make it in time for the submission deadline of 28th February 2007. More details on this if we are able to complete the paper in time.

SPLC 2007 will take place in Kyoto, Japan from September 10th – 14th 2007.