I’ve had a chance to catch up with Software Engineering Radio recently and I was particularly impressed with their podcasts on Software Architecture. These are definitely worth a listen for anyone who wants to get a basic understanding of what a software architecture is and what issues are involved when creating a software architecture.

Episode 23: Architecture Pt. 1 covers ‘fundamental topics’ e.g. what is architecture? and how does it differ from design?

Episode 25: Architecture Pt. 2 talks about quality attributes and their inter-relationships.

Episode 30: Architecture Pt. 3 talks about some of the standard approaches an architect can use and how they relate to the different quality attributes discussed in the previous episode.

After a lot of behind the scenes work from a number of people and positive feedback from potential sponsors we’re now very happy to confirm that the (as yet unamed) Code Generation Network event I mentioned previously will definitely take place from May 18th - 20th at Homerton College, Cambridge.

Proposed topics include:

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

Day 1 is planned to consist of workshops and in-depth tutorials.

Days 2 and 3 will include plenary sessions, keynotes, panels and other sessions from leading Code Generation practitioners.

We’ll be putting together a conference website soon but in the meantime watch out here or at the Code Generation Network for further announcements or send us your email address and we’ll keep you updated on any further conference news.

Call us sad here at Software Acumen but every month or so we track our position on Google and other search engines to see how our websites are doing against their competitors. We do this primarily using GoogleRankings.

The Code Generation Network, our site on, er, Code Generation, always rates very highly on the keywords we expect e.g. Code Generation, Code Generator and variants thereof. This is largely due to the sterling efforts of the previous editor Jack Herrington in building and promoting the site’s great content.

However, we’ve been pleased to see that our software-acumen.com site has been doing rather well of late. So well in fact that we’re now officially number 1 for the term ’software variants’.

Now given the dynamic nature of the web this could all have changed by the time you read this but we were pretty excited. Also, the issue still remains, how to persuade potential customers that they should be typing ’software variants’ into Google in order to solve their variant management problems - answers on a postcard please.

An early rise on Day 2 of SPLC 2006 saw me in Salon B at 7:45 setting up for my tutorial on Software Product Line Scoping – The Scoping Game. I had 33 people registered so had asked SEI for some assistance to help run the session with this expanded group, and John Hunt, a student of John McGregor’s kindly offered to assist. I’d sent him the game rules and taken him through the game the previous evening so all was in place for a good session.

In the end we had 30 participants, including John. This was a good number that allowed for a wide range of questions and some variation in game play. By 8:35 all but a couple of participants had arrived so we got started. We began by reviewing the tutorial objectives:

• Understand Scoping and why it is an essential Product Line activity.

• Understand Scoping as an economic decision driven by business objectives and involving Scope trade-offs.

• Be able to identify stakeholders (and participants) in the Scoping activity and relate this to your own organisation.

• Understand the sources of information that underpin Scoping.

• Be aware of alternative Scoping approaches (and factors affecting the choice of approach).

• Understand Scoping as an iterative, on-going activity with a relationship to other Product Line activities.

• Know where to look for more information.

and then continued with a mixture of slides, simple class exercises and game-play of The Scoping Game. This is a game I invented to give people a chance to perform a simple Scoping exercise and thereby reinforce their learning through the session.

The Scoping Game places participants in a (fictional) software development organization embarking on a Software Product Line effort. Participants take on the role of stakeholders in the organization tasked with collaborating to create (and maintain) the Product Line Scope. Certain simplifications mean that no prior knowledge of Scoping or economic decision-making is required, other than that provided at the start of the tutorial, and so the Scoping Game can be used at the outset of an organization’s Product Line activities in order to familiarize their employees with this essential Product Line Engineering activity.

The participants were divided into groups of three. Some pictures of the game play will be available in my full conference report when I release that.

The game was played in two rounds. In round 1 participants played the role of product managers responsible for a single (mobile phone) product. Each player had to try and maximise the revenue for their own product. However, each team had to maximise the revenue for the team as a whole. The tension between these goals reflects real conflicts that can occur between stakeholders when launching and evolving Software Product Lines.

Revenue was earned for a product when all of its mandatory features had been bought by the team. Optional features could also be added, and this led to increased product revenue. Features could be bought either just for a single product or could be made reusable (at higher cost) for all products. Each player had a finite amount of money, so not every feature could be bought – players weren’t told this in advance and this led to an interesting aha moment during game-play.

In Round 2 the team was given its round 1 earnings and was asked to develop three further products. This time there was only a team goal, not an individual one. Furthermore, features that had been made reusable in Round 1 could count towards the new products so it was easier to develop the new products. (In fact, it turned out that I’d got the money slightly wrong and everything could be developed anyway which was a little disappointing for me and for the participants but this didn’t detract from the pedagogical element).

Aside from the glitch in round 2 the game was well-received and several people asked me for permission to use it in their training exercises. I’m still waiting for the full feedback analysis from SEI but the session as a whole also seems to have gone down well so hopefully I will be able to run it again some time in a refined form.

I have also collected all player-generated artefacts and will include pictures of these in the fuller report. One team even used a simple software spreadsheet to help them.

I will also include the final results in that report - there was quite a big deviation in earned revenue even though all teams were working with the same raw data and there was only a small random factor in revenue potential. This needs further analysis.

A full report, including this tutorial report, will appear on the Software Acumen website shortly.

SPA Cambridge’s next free software event is entitled “Web 2.0 - the Second Coming of the Internet?“. The event will take place at Microsoft Research Cambridge on Wednesday 11th October and is free and open to all.

A Van Emmenis will present an informal survey of some of the current techniques for writing web apps and the new technologies that promise us a better way. He will also consider the particular problems of writing web apps and how new techniques (”AJAX, JSON and all the ..er.. REST”) claim to solve them.

You can sign up here.

SPA 2007 is still a while away yet but the programme is now being put together.

The call for session proposals closed on 11th September and the submitted proposals are now being reviewed. This review process involves several independent reviewers assessing the proposal to see how likely it is that it will be successful and of interest to SPA participants. A standard form is used to assist in generating reviews.

Having multiple reviewers, many of whom have successfully led past SPA sessions, should improve the chances of a session being assessed appropriately. This raw review data is then used by a smaller panel of reviewers to create a session ranking.

This year I’d volunteered to help with the review process for the first time and so spent a few hours last week reviewing my assigned proposals. On the whole I was pretty impressed with what I’d read, although some proposals needed work. I also found the review process itself a useful insight into how I can improve my own proposals in future years.

Once the review process is complete all session proposers are informed of whether they have been accepted or rejected. The nice thing about SPA though is that they are given the review forms for their session and so can see how their proposal was received, what the reviewers liked or disliked about it etc. and so are in a better position to prepare proposals for future years. In the case of an accepted proposal these review results can also be used as the starting point for any corrective action that is needed in advance of the conference.

I always make a point of asking for feedback on any conference sessions I propose to other conference organisers. However, I rarely get any, in fact, some conferences don’t even bother to tell you that you’ve been rejected! Very rude.

I’ve been invited to give a talk on Software Product Lines at the BCS Software Practice Advancement group in London on November 29th.

The talk, entitled “Software Product Lines, What, Why, When and How” will, perhaps unsurprisingly, give an overview of Software Product Lines, the benefits of the Software Product Line approach, when to start a Software Product Line and how to start a Software Product Line.

Preregistration is required but you don’t have to be a BCS or BCS SPA member to attend. The sign-up page is here.

The August edition of Methods and Tools has results of a recent poll of software developers on their perception of the quality of open source software development tools in comparison to commercially-developed tools. This was a follow-up to a similar poll conducted two years ago.

It turns out that most developers (38%) don’t see a difference in quality between commercially-developed tools and open-source tools, although there has been a slight drop (6%) in the number of people who see open-source as higher-quality then commercially-developed tools.

A different article at Application Development Trends notes survey results showing a near doubling in the number of organisations using Eclipse over the past year. Interestingly, Eclipse take-up is proving most popular in larger organisations. Could this be due to cost issues?

September’s ESE Magazine has an interesting article entitled “Systematic Reuse of Safety-Critical Components will usher new age of Embedded Software Development”.

The article notes that the FAA has been looking for ways to cope with the increasing amount of software that is needed in avionics applications and issued guidelines (FAA AC 20-148 Resuable Software Components) in December 2004 on reusable software acceptance.

These guidelines mean that, with certain restrictions, using software that is certified as reusable will require less effort on behalf of the software integrator to have their system certified by FAA - prior certification of the reusable software component will count to some extent towards future certification of the component in a wider software system.

The article raises interesting questions about precisely how much verification work has to be done on a reusable component for its initial certification and how much verification work should be done on a reusable software component when it is reused in a new context.

When first verifying a reusable component, more work will have to be done to verify it than a non-reusable component. This is partly because the component developers have to describe to the FAA the assumptions they have about how the component will be reused, but also because reusable components generally require more verification effort than non-resuable ones because they are typically configurable in some way whereas non-reusable software is not.

In terms of reusing a component another issue is managing exactly what is different about the software in its new context. As Frank McCormick, president of CSI says in an earlier article for Aviation Today “Executable code might change without disrupting the requirements and design data that led to the code. So a nontrivial body of upstream data might well remain stable.” It’s not just the software configuration that may change when a reusable component is reused and the FAA needs to understand exactly what has changed in its new context when a component is submitted to it for certification as part of a wider system.

It seems to me that a Software Product Line approach is exactly what’s needed here to maximize the benefits of systematic reuse while addressing the essential need to build safe systems.

Software Product Lines are built around core assets that have been built to be configurable in predefined ways. Defining how a component is planned to be reused is a key activity in Software Product Line development and (some) well-established techniques are available to support this. This should address the FAA’s requirement to understand the assumptions made by the component developer about how the component will be reused.

Furthermore, configuration of reusable assets is usually performed through tool support, so asset configuration parameters are well-known and completely captured in formal models, such as feature models. This changed configuration need not just be code but could also be requirements, documentation, test plans etc. In fact any artefact associated with the component can in principle be configurable. Having these formal models of the reusable asset should support the process of informing the FAA of exactly what is different about the component as it has been reused in its new context.

There are examples of Software Product Lines in the avionics domain but I wonder whether they’re taking advantage of this FAA Guidance. If anyone knows then please get in touch, also, if anyone is aware of similar standards in other safety-critical domains then we’d like to hear about those too.

The upcoming Embedded Systems Show Technical Conference has a stream on Model-Based Development on 12th October to be chaired by Andrew Watson of OMG.

This includes talks from the following:

• Stephen Mellor of Mentor Graphics - From UML to Embedded System - Is it possible?
• Brian Hooper of IBM - How model-driven development revolutionised the UML.
• Mark Richardson of Telelogic - Optimized design-level debugging with model-driven development and UML.

The Mathworks, OSGI Alliance and National Instruments have also provided speakers and there will be a panel discussion on Model-Driven Design: Is it relevant in Embedded?

Discount registration rates for the conference are available until 29th September. Click here for conference registration.

If you do attend the conference, drop by the free exhibition taking place concurrently. We will be on stand 741 demonstrating pure::variants and would be happy to talk about how model-based development can work in a Software Product Line setting or about our work with the Code Generation Network.