Cambridge Usability Group meets again on 8th October with presentations on two papers from CHI 2007:

“Usability Testing: What Have We Overlooked?” considers the question of the optimum number of user sessions to include in a usability test.

 ”Capturing life experiences: Software or wetware?: discovering when and why people use digital prosthetic memory” considers the proliferation of digital devices intended to support prosthetic memory (PM) and reports on a lab study that investigates when and why people use PM and Organic memory.

The meeting takes place at Microsoft Research Cambridge at 18:30 for 18:45. Attendance is FREE and you do not need to be a UK UPA member to go along.

Email cambridge.usability@gmail.com to reserve a place.

ACCU Cambridge’s next talk will hear Russel Winder Closing the Case for Groovy (and Ruby, and Python).

Synopsis:

Although a few people still insist on using C and C++ for applications (not systems programming, for that C++ is almost certainly the language of choice), some even use Java or C#, the majority of the wise are moving to Python, Ruby and Groovy — the (popular) dynamic programming languages. Why eschew strong typing in favour of duck typing? Expressivity. The dynamic programming languages allow algorithms to expressed in less code, and as we know, “less is more”.

The triumvirate of Ruby, Groovy and Python actually split into two camps: those that have closures (Ruby and Groovy), and those that would like them (Python). Closures are not new: Scheme, Smalltalk, etc. have had them for ages, but they do represent the next stage of evolution of programming. Witness the rush to get closure included in Java 7.0.

This session will be something of a compare and contrast of the languages to try and tease out why Python, Ruby and Groovy have become “The Next Big Thing” in programming, and why closures are causing such a stir.

The talk will take place on 4th October at DisplayLink, Cambridge and will start at 19:00. You don’t have to be an ACCU member to attend. Visit the ACCU Cambridge page for more information (and to preregister).

The next IBM UK Rational User Group meeting will be held at the Embedded Systems Show on October 17th.

Here’s the agenda:

08:30 – Registrations
09:20 – UK RUG Welcome
09:30 – RUG1: IBM Rational Solutions Update – IBM Rational
10:30 – RUG2: “Magic happens here” – Projects and Process Conjuring – Russell Norlund, REAL Solutions
11:30 – Coffee
12:00 – RUG3: Using protexIP with Rational – BlackDuck Software
13:00 – Lunch – Sponsored by CM-Logic and BlackDuck Software
14:00 – RUG4: UML Explained! – IBM Rational
15:00 – Coffee
15:30 – RUG5: Achieving delivery results with Configuration Management – CM-Logic
16:30 – Final Q&A
17:00 – Close

You can get more information and preregister here.

If you’re a ClearQuest or ClearCase user you might also be interested in coming along to stand 532 of the associated exhibition to find out about the pure::variants add-on modules for these tools.

The Cambridge Wireless Software SIG launches on 3rd October with a talk by Charles Weir of Penrillian entitled “Supporting Many Mobile Platforms: Tackling your Killer Porting Project” and a discussion on the future direction of the SIG. The meeting is being hosted by Symbian.

The talk is free to paid-up Cambridge Wireless members but costs £150+VAT to non-members. Lots of local organisations are members and you can check if your organisation is among them here.

If you’re not a member then it’s probably a good idea to join if you’re planning to come to future events. The next software SIG meeting will be held in April 2008 but there are plenty of other events happening throughout the year.

Earlier in the week I put on my blue shirt and socks and headed down to the UK Rational Software Development Conference 2007  at IBM Bedfont Lakes site.

Bran Selic’s talk on IBM’s strategy for supporting industrial systems development was my main reason for attending but there were many other interesting speakers covering the whole life cycle and range of Rational products.

Bran is in charge of IBM’s tool strategy for the systems space so it was a chance to hear about this from the source as it were. He began by noting the key issues for developers in the systems space:

• complex, flawed and volatile requirements
• the need to deal with complex real-world phenomena
• poor integration between tools leading to traceability issues – traceability being achieved currently through documents or with point-to-point tool integrations
• an increasing need for governance
• (geographically) distributed development teams

IBM’s approach to this space is based around four key strategies:

• Model-Driven Systems Development
• Standards and open frameworks
• Risk-driven iterative software development
• Objective evaluation methods

Model-Driven Systems Development is based on two fundamental concepts:

Abstraction – hiding the details and complexity of the underlying implementation. Since software systems are now among the most complex artefacts produced some form of abstraction is essential to understanding them.

Automation – the transformation from model to target (e.g. source code) is performed without programmer intervention and so is less error-prone and more productive than a manual transformation.

As Bran rightly states, you can’t argue against these concepts even if you may be sceptical about their realisation in current tools.

In Model-Driven Systems Development, the organisation moves from a document-centric to a model-centric approach. Models are created to capture requirements, design etc. in a formal way.

As an example of a modelling langauge for achieving this Bran described SysML, a  UML-based domain-specific language (his term, not mine) for systems development. Using UML as the basis for this leverages the knowledge of existing developers etc. who are familiar with UML and allows organisations to continue to use their existing tools . (But listen to our ‘UML vs. Domain-Specific Languages‘ audio recording for debate on this point.

Bran described a MDSD case study of a telecomms network controller. In this study a team of over 200 developers worked on a single model. The generated output was 4.5 million lines of C++ code. The resulting system performance was +/- 15% of hand-crafted code. Furthermore they recorded a 200% productivity gain and 80% fewer bugs.

According to Bran attempting to encode requirements in a model early-on can also help verify and validate those requirements.

Bran had less to say on the other three strategies but I did note that IBM is continuing to take a federated approach by working with best in-class tool and service providers and their strategy continues to be based on Eclipse – although with the new Jazz team collaboration platform to the fore.

In the follow-up Q&A I raised the issue of resistance among software developers to the idea of model-driven development with Bran. He also sees a lot of scepticism among developers about model-driven approaches.

However, he observes that developers are wrong to be sceptical of these methods due to a fear of a decrease in performance of the finished system. As the case study he described noted this was comfortably close to that of an equivalent hand-coded system. Instead when you’re considering MDD tooling you should think about issues such as scalability and the expertise needed to implement such tools. Does the organisation have the skills to develop code generators for example? (This ties into a recent post at Peter Bell’s application generation blog on involving consultants early-on in your code generation adoption).

Hopefully I’ll get a chance to go along to the conference in the future. It was a well-organised event - and a must if you’re a Rational user I would have thought.

pure-systems and IBM have co-written a new whitepaper looking at the issue of Quality Management in Software Product Lines.

The paper looks at how to manage tests and issues more efficiently in the context of a product line. It’s typically the case that not all tests and issues are relevant for all products in a product line. This knowledge must be formalized in order to be able to avoid unnecessary work.

It’s also important to be able to realize complete variant-specific traceability. With this, the cost and risk associated with new bugs and features can be estimated more accurately. Furthermore, delivered product variants can be treated differently from errors or missed tests in not-yet-deployed product variants.

The paper looks at these issues in the context of a new pure::variants add-on – Connector for IBM® Rational® ClearQuest® but it should be of interest to anyone working with software product lines. The paper is available here (PDF).

I’ve just noticed that builder.au has an interesting interview with Ivar Jacobson where he considers reuse, process, modelling and the future of the field.

“To really automate … you need to find some identifiable patterns and apply these patterns over and over again with slightly different inputs — that makes it hard because it’s not reusable code only. I think reusable code has increased, we definitely use more reusable code than we did 20 years ago — not as much as we could — but we use more. When it comes to patterns you need to have different parameters based upon the context.” – sounds a lot like a Software Product Lines approach is what he’s advocating.

Methods and Tools has been running a poll on the proportion of software budgets that are being devoted to software maintenance.

The poll question is “What part of your software development budget [my emphasis] is devoted to maintenance. Maintenance is defined as process of correcting, enhancing and optimizing deployed software.”

Only 12% of respondents noted that maintenance accounted for 75% or more of their budget.

I was quite surprised by this figure given that the following studies have recorded figures varying from 75% to over 90% of effort being spent on software maintenance:

Is this simply explained by a difference in the terms of the studies – with M&T looking at budgeted costs and the past empirical research looking at effort? Are people budgeting much less for maintenance than they actually spend? Are M&T poll respondents or is the past research atypical? What do you think?

For further information Jussi Koskinen has a good page summarizing the past research in software maintenance costs – although it has not been updated for a few years.

I’ve been invited to give a talk on Software Product Lines at the Open University on 4th October.

Synopsis:

This talk will introduce the Software Product Lines approach – a way of building families of similar-but-different software variants from a set of configurable, reusable assets using a common production method.

Building sets of software variants from reusable assets like this can lead to economies of scope, enabling benefits such as increased productivity, improved quality, reduced time-to-market etc. to be realised. However, the product line approach is not universally applicable, and the talk will describe when you can and when you cannot build such product lines and how to go about it if you do decide it is applicable.

It’s an interesting experience talking to an academic audience – they tend to ask very different questions to a business audience – so I’m excited to see what issues will come up.

If you’re with the OU you can find more details of attending the talk here.

The sponsor packages for next year’s Code Generation 2008 event are available. Instead of looking for 8 sponsors this year we’ve decided to look for 6 so we plan to have 2 Gold, 2 Silver and 2 Bronze sponsors.

If you’re interested in sponsoring the event then please contact us to receive a copy of the sponsorship prospectus.