- K. Melin, ‘Volvo S80: Electrical system of the future’, Volvo Technology Report, vol. 1, pp. 3–7, 1998.
- A. Pretschner, M. Broy, I. H. Krüger, and T. Stauner, ‘Software Engineering for Automotive Systems: A Roadmap’, in Future of Software Engineering, 2007, pp. 55–71.
- J. Mössinger, ‘Software in Automotive Systems’, Software, IEEE, vol. 27, no. 2, pp. 92–94, 2010.
- Tsakiris, ‘Managing Software Interfaces of On-Board Automotive Controllers’, IEEE Software, vol. 28, no. 1, pp. 73–76, 2011.
- J. Schäuffele and T. Zurawka, Automotive Software Engineering: Grundlagen, Prozesse, Methoden und Werkzeuge effizient einsetzen, 5th ed. Springer, 2012. (Mostly process oriented, and I don’t know if German works for you. Previous editions are available in English though)
- A. Thums and J. Quante, ‘Reengineering embedded automotive software’, in Proceedings of the IEEE International Conference on Software Maintenance, 2012, pp. 493 –502.
- J. Quante, M. Tarabain, and J. Siegmund, ‘Towards recovering and exploiting domain knowledge from C code: A case study on automotive software’, in IEEE Conference on Software Maintenance, Reengineering and Reverse Engineering, 2014, pp. 383–386.
It has often been said that software engineering is not as mature as other engineering disciplines. I can agree with that, often it seems that the way we design large software systems is more akin to how great cathedrals in europe were constructed, with a blend of some basic understanding of mechanics, craftsmanship and artistry. We don’t have the equivalence of finite element methods for doing structural calculations etc.
But I realised ne thing that also sets software engineering apart from e.g. mechanical or civil engineering. We don’t have a universally accepted set of abstractions that we work with. A mechanical engineer has e.g. a blueprint (often drawn in a CAD program) which everybody can read regardless of where they are educated or which company they belong to (even if they are not familiar with a specific CAD program).
We don’t have a corresponding set of abstractions in software, if you go from one company to another they will use a different set of abstractions, form the low level (.g. choice of programming language), via design descriptions (which could be UML), to how to describe properties or requirements. And our tolls follow that, it is almost the other way around, the abstractions we use are dictate by the tools we choose, instead of the tools adhering to a common “view”, and what they differ in are things like UI, features etc.
I don’t think that software engineering will be considered a mature engineering domain unless we actually have a set of universally accepted abstractions which all software engineers are familiar with.
More and more embedded companies adopts agile development as their way-of-working for software. For small systems this is straightforward, but for large development projects with hundreds of developers working on the same product there seems to be a typical evolution that an organisation goes through before successfully scaling agile.
Typically the transition starts with individual teams adopting agile practices, but fast iterations and shorter lead-times on team level does not automatically lead to shorter lead-times for new or updated products. The organisation as a whole still uses a stage-gate process or V-model for the product development. If the organisation is successful in changing their entire ways-of-working across all departments it becomes evident if the product architecture supports or hinders the new way-of-working.
The presentation concludes with some general guidelines for how software should be designed to support agile development of large embedded software systems.
I will participate in Embedded Conference Syd 10-11 march in Malmö, Sweden and give two talks:
- How to build an open platform for smart buildings
- Does the architecture matter when the ways-of-working change?
Good testing is one of the bottlenecks that needs to be solved if your organisation wants to embrace shorter iterations and quicker feedback. On team level it seems possible to do almost continuos testing, but when it comes to testing integrated systems and products, with deliverables from numerous teams it is critical to have a well-understood test strategy, in the sense what to test, why doing it and when does it needs to be done.
I am the first to admit that I am not a tester, but as a software designer and architect I have been inspired by skilled colleagues who are testers, which is a skill in its own. I regularly follow the blog thoughts from the test eye since they have a view of testing which inspires me as a software architect. Not only do they have a an approach to their craft which I think resonates very well with how I think software design and development should be done in ana agile context. They also produce some really useful reference material, for example i regularly use their Software Quality Characteristics 1.1, which is the best summary of quality attributes in a concise form I know of. They have other useful material, like Den Lilla Svarta om Teststrategi (unfortunately only in Swedish).