Improving quality with well-written requirements

I discussed with a colleague about how to improve specifications and we agreed that one of the actions that would yield quality improvements with very little investment was to educate people in our organisation on how to write good requirements.
Unfortunately such a course is not available internally at Volvo Cars (don't ask me why). But a search found some useful pages that could serve as an introduction:

• The Story of the Paperclip: Writing Good Functional Requirements from StartupCTO
• Writing Good Requirements – The Big Ten Rules from Tyner Blain
• Writing good requirements is a lot like writing good code by Jim Heumann, IBM
• Writing Good Requirements (A Requirements Working Group Information Report)
• SMART Requirements by Mike Mannion and Barry Keepence

Is software engineering immature?

Is software engineering an "immature" engineering discipline? I have often heard this both in presentations and in reading, for example SEMAT states on the homepage:

"Software engineering is gravely hampered today by immature practices."

If I draw parallels between software engineering and civil engineering (arguably the most mature engineering discipline) my spontaneous conclusion was: Yes, software engineering seems to be more like how cathedrals were built in medieval times. The construction of them were based on rules of thumb and the practical skills and experience of architects and stone masons instead of the type of engineering practices taught at universities today. Interestingly enough, one can still see the "successful" cathedrals still standing several centuries later. But it would have been impossible for the architect of  Lund Cathedral to build something like the nearby Turning Torso. So the engineering in civil engineering has certainly "matured".
But where is software engineering failing? Everyone has heard of software projects running over time, over budget or have not been used as intended (or not used at all). But wait a minute! Exactly the same thing is common within civil engineering as well. There are many examples from a single contractor renovating a small house up to world known buildings such as the Sydney Opera House:

"The original cost estimate in 1957 was £3,500,000 ($7 million). The original completion date set by the government was 26 January 1963 (Australia Day).[16] Thus, the project was completed ten years late and over-budget by more than fourteen times."

So in this respect software engineering is as immature as other engineering disciplines.
So what is the fuss about? I agree that there is no consensus in the software community on how to do the equivalence of structural mechanics calculations or stress tests. Are we more hampered by this lack of consensus on how to do engineering tasks than by the difficulty to run large projects, which seem to be common to other engineering disciplines?

Available infotainment platforms

I have previously written about various platforms for infotainment systems. I also had a slide about it in my presentation on Lindholmen Software Development day, where my point was to say that it is possible to use either a commercial platform, such as Windows Embedded Automotive or an open source such as Meego. It is a business decisions which way an OEM wants to go, not a technical.

I have probaly missed some, but here is a list of infotainment platforms available today for an OEM to build an in-vehicle infotainment system on:

• Windows Embedded Automotive, used for example in Ford's Sync.
• QNX Aviage
• Mecel Betula Suite - Automotive Bluetooth Platform
• Meego
• GENIVI, but there is little informaiton about the techical solition on the webiste. They will most likely utilise the Meego platform.
• Harman has an infotainment platform. They recenlty acquired AHA Mobile which probably will be integrated.
• There are alot of notices on using Android for in-vehicle infotainment if one searches the web, but I have not been able to find any open source software based on Android for in-vehicle use.
• Continental's Autolinq seems to be Android-based, but is not open source in the same sense as e.g. Meego, and apps must be approved (by Continental?) to be downloaded.
• Luxoft offers LUXnet, which is also Android-based, but I cannot find any information besides a press release on their homepage.

Disclaimer

The information contained in this website is for general information purposes only. The information is provided by automotiveservices.blogspot.com and while we endeavour to keep the information up to date and correct, we make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability or availability with respect to the website or the information, products, services, or related graphics contained on the website for any purpose. Any reliance you place on such information is therefore strictly at your own risk.
Through this website you are able to link to other websites which are not under the control of Automotiveservices.blogspot.com. We have no control over the nature, content and availability of those sites. The inclusion of any links does not necessarily imply a recommendation or endorse the views expressed within them. Every effort is made to keep the website up and running smoothly. However, automotiveservices.blogspot.com takes no responsibility for, and will not be liable for, the website being temporarily unavailable due to technical issues beyond our control.

Recurring architectural decisions

A lot of academic (and industrial) research is looking at architectural decisions. One of the ideas pursued is that by capturing and managing this type of information it can be reused. I guess in practice it means that if you need to make a similar decision in the future you can look at what you decided the last time. I myself also saw this as an appealing idea. But today it struck me that we really don't have recurring decisions when we work as architects at Volvo. I think that if we had there would no be any need of an architect at all.

What we do have is a long succession of architectural decisions, each with a new set of prerequisites. The task as an architect is to be able to extrapolate from what has been done previously and still maintain some sort of conceptual integrity. To preserve the "feel" or "vision" of the architecture while still fulfilling necessary functional and quality requirements (including cost) and operate within the constraints given by for example our organisation and what is available/possible form suppliers.

Software testing

I have to admit it, I suck at software testing. I do believe in my naive notion of test-driven design, i.e. write the tests first and the program later. My problem is that I just don't have the skills of programming test cases.
Example: I wrote about the "walking skeleton" design principle some days ago.One could write a suitable set of test cases to ensure that the skeleton, with it's various units, always walks. The tests should automatically run before you check in more elaborate units, with more features in them. If the unit doesn't pass you know that you will have integration problems.

There are a lot of resources on testing out there, for example I got an introduction on creating JUnit test cases for Java programs from a colleague. Since I'm trying to learn Erlang I should probably look into EUNIT.
You should also read the blog thoughts from the test eye.

I started working with system integration testing at Volvo Cars many years ago. I learned the basics of test planning, writing test cases and report test results then. Probably very outdated since both it was ten years ago and since the automotive industry has never been on the cutting edge of software development practices. We still have a notion that a specification should be written so that it can easily be tested:

"This easily results in requirements being quantified and often in a contractual style, instead of describing the real needs and desires."

There are many other ways of Synthesizing Test Ideas!

So if experts on testing are open to the notion of having specifications focusing on understanding and real needs, why are we still clinging to contractual requirements ? Is it because of so much of the coding is outsourced in the autotmotive industry?

If one aspires to be a software architect I think working with verification & validation (testing) is a good starting point. You learn a lot about good, and bad, design when you are exposed to the errors and unintended behaviour in a system and the effects they have.

Architectural modelling

To have a more formal definition of what I mean when talking about modelling an architecture (summarised from to IEEE 1471):

An architectural description is organized into one or more views.
A view may consist of one or more architectural models. Each such architectural model is developed using the methods established by its associated architectural viewpoint. An architectural model may participate in more than one view.
The viewpoint determines the languages (including notations, model, or product types) to be used to describe the view, and any associated modelling methods or analysis techniques to be applied to these representations of the view.

I am not against using models to represent architectural views, but there are some fallacies that often seem to happen when using various modelling approaches in architecture descriptions.

• The purpose of the architecture model is unclear (in 1471-terminology: It is not obvious what concerns the model addresses). UML is especially problematic since it provides notation that can be used for so many purposes. Read John Daniels paper Modeling with a Sense of Purpose as an introduction.
• Everything is modelled to the same level of detail. Not everything is equally important to know. For some parts of the system it is important for the architecture (and realisation of qualities) to know the details, for other parts it is not.
• Every part of the system must be represented in the architecture, for example if every class must be traceable from some element in the architecture. This could even be a rule of the architecture, "if it is not explicitly allowed it is forbidden". This reeks very much of waterfall mindset with the architects doing much of the design before any developers get involved. I think it is presumptuous  of the architects to claim to know everything that needs to be implemented.
• Modelling tools always demands a precision in notation, which is not always desirable when sketching an architecture. You cannot model "sort of a class", or "could be a function" when using a tool, which is possible on a whiteboard or a napkin. In a tool it has to be a class, a function or a package, not something in-between.