Thesis chapter 12.1.1: Research answer 1

RQ1 is answered in chapter 7. Based on a mapping survey 5 archetypical approaches of embedded software development were identified:

• Approach E: Rorqual organisations The business goal is to minimise risks associated with technology investments. The architecture optimises qualities observable at run-time for the user/customer. Stage-gate or V process based on calendar time with gate progression corresponding to design artefacts. The organisation is functionally structured with a central systems engineering team responsible for the complete product properties which interacts with all the development teams.
• Approach D: Autonomous Teams The business focus is on physical delivery of a product (or thousands of products) to the customer and minimising technical risks. The architecture is still tailored towards satisfying product qualities, requiring a lot of effort spent on defining, verifying and maintaining interfaces, as well as integration of subsystems throughout the project. Development is done in short iterations on the module/team level (figure 7.4), but the deliveries are still planned towards scheduled integration points. The organisations consist of self-directed teams, who usually want to adopt practices such as XP or Scrum. The teams are more or less autonomous in their approach with respect to other teams they are interacting with.
• Approach C: Adaptive processes The business is focused on technology and technological innovation while still preserving key product quality attributes common in the domain. The architecture of the product is still tailored towards satisfying product qualities. The process adaptation adjusts the schedule to the size and scope of what is being developed with no fixed integration times, the teams practice continuous integration. As a result the software and hardware development processes are usually decoupled. The teams are self-directed, both in their ways-of-working and also in defining the deployment date for their deliverables.
• Approach B: Architecture for composition The architecture, processes and organisation is adapted to fast development in short iterations, but the product management and business model is still “traditional”, focusing on delivering and getting paid for each product. The architecture supports qualities affecting the speed, effort and cost for the developing organisation which are weighted against product qualities discernible at run-time and cost of ownership. The organisation as a whole develop software in short iterations and likely to apply e.g. continuous integration of software. Teams are self-directed with responsibility for end-customer value.
• Approach A: Marlin Organisations One of the major business drivers is to minimise the risk associated with offering the wrong product or developing undesirable features. Software is a major differentiator in the ability to attract and maintain customers, and therefore short leadtimes to launch is needed to stay competitive. The architectures optimise the ability to develop products and features with the shortest possible leadtime. Typical properties are modularity and composability of software from different teams. The process is highly iterative aiming to take small development steps and validate these in each evolution, in some cases with real customer feedback. The organisation consists of self-directed and self-organised teams containing cross-functional competences of product management, architecture, design & implementation and testing, capable of invention and launch of new features autonomously.

The first key observation is that the Rorqual (E) approach is the most common way to develop embedded software and can be considered the common practice1. The second most common approach is having autonomous teams (D) using e.g. agile development on the team level.
The second key observation is that the evolution of an organisation goes from E to A, with the most common just being going from E to D. In no case there was a description of an movement in the opposite direction, and my conclusion is that evolution through the model is always uni-directional.
These two observations together suggests an order in which organisation may adapt new practices and is therefore suggested as a prescription of process and architecture changes.
The scientific contribution is the multidimensional model of R&D approaches. In contrast to one-dimensional models this one describes the approaches in the four dimensions of business, architecture, process and organisation, highlighting that differences between R&D approaches may not be seen when observing e.g. just the process dimension.