John Sanderson, President and CEO of Siemens VDO in North America is quoted in April’s AutoTechnology magazine as saying “[Software] truly is a product, and it needs to be managed as a product, from a business standpoint and an engineering standpoint.”

In the past automotive software was considered as something that could just be tacked on to the development of the part on which it ran. However, with the amount of software in a car increasing from thousands to millions of lines of code and software predicted to make up around 13% of the cost of a car by 2010 this is no longer possible.

Moreover, the automotive domain isn’t unique. Systems developers in other embedded domains are also increasingly recognising that software is vital to their future business strategy and are placing more focus on enhancing or building a software development capacity as a consequence.

May’s International Developer magazine has an article by Mercury Interactive on testing mobile applications. The author makes a reasonable argument that developers of enterprise mobile applications, like developers of desktop or server-based applications, should use automated test approaches.

Part of the author’s argument rests upon the high level of variability in the mobile domain. Handsets themselves have many different device characteristics and features. But even the same handset can have different software installed by different operators (e.g. enterprise class security or applications support). With operators and handset manufacturers working “to differentiate themselves by offering maybe 20 or 30 new types of handset to the market every year” there’s no indication that this problem will get any easier.

It’s not clear whether the author is advocating a Software Product Line approach to mobile application development but this would allow mobile application developers to develop multiple application variants efficiently. If they did so by developing feature models to capture the product line variability then they could also use those feature models to derive variant-specific automated tests to perform. Running only those tests that are appropriate would reduce overall testing time and would potentially eliminate tests that should fail for the specific handset variant.

Those of you who are subscribed to the cgn-talk yahoo group will know that we’re planning a Code Generation Network event to take place in Cambridge, England next year.

This past week we’ve been busy trying to find a suitable venue to host the event and it’s not been entirely plain sailing. The first problem has been with our proposed dates of May – June 2007. Unfortunately these clash with peak exam period here in the UK and so many of the larger rooms that would be suitable to hold the 120 or so developers we’re planning for are unavailable. The second problem is that many of the smaller colleges don’t quite have the capacity for 120 people. Finally, some colleges just don’t seem to be interested in a non-residential event such as this one.

Anyway, despite all this there are some suitable venues and we’ve been busy viewing these this week and will visit more next week. Once we have a venue and dates pinned down we’ll then be able to go back to the sponsors with a firmer idea of costs and hopefully we’ll get them on board and be able to start publicising the event more widely.

In the meantime, if you’re interested in sponsoring the event, participating in the event, or helping with the organisation then please get in touch – volunteers from the Cambridge area are particularly welcome

The proposed list of topics is:

• industrial case studies, industrial applications,
• legacy-system migration,
• domain-specific languages and domain-specific modelling,
• software factories,
• software product lines,
• program generation, program transformation,
• generative programming,
• feature-oriented programming
• template meta-programming,
• aspect-oriented software development,
• model-driven architecture, model-driven (software) development,
• feature modelling,
• domain analysis, domain engineering,
• component generation,
• reasoning about models

The event is being planned to last three days. Day 1 will cover in-depth tutorials and workshops. Day 2 – 3 will involve lectures, smaller tutorials, panel sessions, etc.

A small exhibition of leading code generation tools is being planned to run concurrently.

The May issue of Automotive Electronics International hit our doorstep today and contains a number of comments on product differentiation in the automotive sector.

For example, Terry Costlow notes on p22 that Diesel engine developers are facing problems due to varying requirements for different vehicle classes limiting their ability to deliver a one size fits all solution to address new U.S. emissions legislation.

Frank O. Klegon of Chrysler is also quoted on p40 “We have to have products that are differentiated to the customer so that they look very different and have different characteristics, yet ‘behind the scenes’ have more shared commonality.” Chrysler are using a sharable, configurable architecture to achieve this. This has given them benefits such as a decrease in development times, an ability to produce lower volumes of some vehicles due to cost-sharing and an ability to enter new markets more quickly than their competitors – the benefits usually noted for organisations adopting Software Product Line Engineering.

On p42 Visteon is described as “focussing on providing its customers with efficient ways to differentiate their vehicles”, particularly to allow its customers to differentiate between low-, mid, and high series vehicles while using the same tools and facilities.

If anyone sees other examples of pressure for differentiation in the automotive sector, or indeed more widely, then please share these with us.

Nick Levine of Ravenbrook ran a SPA Cambridge session on Common Lisp closures and macros the other night. We had around 25 people with varying levels of Lisp experience from using it a little in EMACS to programming with it for around 20 years so Nick had his work cut out for him to pitch the talk at the right level.

The session began with a quick look at Common Lisp syntax and the read-eval-print loop. We motored on to building some simple functions and then closures before looking at macro definition and macro expansion. Nick used the example of a simple progress bar wrapper to show some of the power of macros as well as some of the potential gotchas. Unfortunately we didn’t have time to look at the XHTML generator example Nick also had but I feel we achieved quite a lot. Nick has taught Common Lisp in 12 weeks, 1 week, 1 day, but never before in 1 hour so he can be pleased with the results.

Nick’s notes for the event, including source code, pointers to Lisp resources, and some book recommendations are available here.

Nick is also organising 2007’s International Lisp Conference which will take place here in Cambridge, England from 1st – 4th April.

There’s an interesting thread on SCM for Product Variants running on the CMCrossroads site at the moment.

One of the comments in the thread is that SCM is not a good solution for implementing variability as it is in fact an anti-pattern; there are better approaches to variability management and so these should be used in preference.

I think the key point is that SCM shouldn’t be the sole mechanism for variability management in most product lines. If you can answer yes to any of the following questions then you should probably consider whether you need to place less emphasis on using SCM as your variability management mechanism:

• Have you written a special application to extract the right software from your SCM system for a product build?
• Are you spending an increasing amount of time maintaining your SCM system and processes at the expense of developing new product features?
• Do you have branched code that could be reused between variants but you haven’t got the time or resources to merge the branches?
• Do you have difficulty building a valid configuration? Is there disproportionate amount of manual work involved? Are configuration errors common?
• Do you need a configuration expert to do your builds? What happens when they aren’t around? What happens if they leave the organisation?
• Can you explain why a product variant was configured in a particular way?
• Do you know the scope of your product line? Can you explain to your marketing group why you cannot (or can) build a specific variant?
• Do you have the need to produce variant requirement specifications, variant test plans, variant user documentation or any other non-software variant?

Mark

I participated on the BCS Configuration Management Specialist Group’s “Show me the money… identifying the value of Configuration Management” workshop on Thursday 27th April. I think there were around 35 people there, most seemed to be from a service management rather than a software management background.

David Cuthbertson of Square Mile Systems ran the event and began by describing Configuration Management and then listing some of the common excuses for failure to implement CM – lack of time or resources, claims that it isn’t worth it, no point unless everyone does it, lack of conviction that it’s achievable, lack of belief in cost benefits. Pretty much the same set of excuses for not making any process change AFAICS.

The bulk of the session consisted of group work, with each group coming up with examples of situations where lack of Configuration Management led to a type of problem. These problem types were:

• Paying unnecessary bills e.g. paying maintenance licenses for hardware you no longer have.
• Losing money through bad change implementation e.g. failing to test software changes (and then being unable to roll back your live systems!)
• Making inadequate use of resources e.g. letting people sit idle because they don’t have enough work
• Loss due to contractual or regulatory reasons e.g. improper data protection controls, fines for failing to deliver contractual service levels, shipping third-party software as your own and being sued

It became apparent that all of the attendees had examples of large amounts of money being lost through lack of configuration management, with many of the problems being seen in multiple organisations. ITIL (and related standards) was proposed as a framework for best practice to avoid these types of problems and is becoming a standard requirement for service provision.

It was a useful and enjoyable event to have attended, despite the service management focus, and I hope something similar can be run for BCS SPA Cambridge in the future, albeit with a greater focus on Software Configuration Management.