Project Management

From electronic to "Embedded IT"

How to organize an Embedded Linux Project? What is the state-of-the-art in managing software projects, especially projects that take place at the interface between hard- and software? The key for successful projects are agile workflows - but with a sense of proportion.

More Information

In the "conventional" IT industry it is already best practice that projects are realized according to procedure models and predefined software development processes. Within the embedded market, these methodologies are not considered regularly - but why?

Probably, because most of the developers and project managers come from the electronic or automation sector. After many years in which their main focus was on electronics and physics, the 8-Bitters needed to realise that the days when a single DIN-A4 page was enough to cover the whole instruction set and manage a project had come to an end. A couple of years later, the 32-Bitter broadly covered the market enabling technologies like Web-GUIs for parameterization, modern communication interfaces and graphical applications. Suddenly, todays developer have to work within a more IT than electronic environment.

The developing methods for large IT projects changed dramatically in the last years. The initial point was the publication of the famous book "Design Patterns - Elements of Reusable Object-Oriented Software" by Gamma et. al. in 1994, which changed development processes from ad-hoc realizations towards planned procedures and workflows within software development projects. Directly and for our daily business there have been numerous outcomes that we today can hardly imagine to work without:

Using an operating system: Each embedded project does not start with an empty editor, instead we have goz an operating system with 10 million lines of code that covers basic requirements.
Using libraries and frameworks: Instead of writing each piece of code from scratch, today programmers check whether a solution or infrastructure is already available.
Testing: Testing is the key element, which ensures that the functionality provided by a certain software is available for a long term. Only intensive testing procedures warrant that projects have a high durability. We do not want to go back in the age of "never change a running system".
Agility: Requirements are fuzzy. Requirements change constantly. Nobody knows in the beginning of a project all necessary requirements. However, this is no excuse for an inappropriate planing. In contrast, only a reasonable project plan and the ability to react on changes allow realizing software development projects "in time" and "in budget".

Consequently this means: Today we have to manage Embedded Linux projects like the "real" IT has managed its projects for many years. Requirements Engineering, Modeling and regular, honest communication between stakeholders is crucial for a successful realization of a project. However, are all software development processes are also directly applicable to embedded projects?

Characteristics of Embedded Projects

There is a main difference between Embedded Projects and "conventional" IT software projects: we have to deal with hardware. For instance, a Java developer only has to specify the correct version of the SDK to describe a type of platform, we have to handle:

Chip bugs, non-documented errata
Timing errors
Bad, incorrect and non-documented hardware interfaces
External code including incomplete error handling

Problems like this complicate the development processes today, especially in terms of predictability and appreciably. Hence it is extremely important to identify and communicate critical paths as well as coping with them using appropriate project management measures.

In practice, the best methods from agile project management and systematic software engineering have to be identified and with a sense of proportion adjusted to the requirements of embedded systems: In that way methods like testing, e.g. within a Java environment is easier than the testing of systems whose bottom layer interface are JTAG, analogous signals and field bus I/Os with top layers connected via frameworks to object-oriented applications.

However, we think that the creation of appropriate basic conditions will lead to a similar systematic approach for embedded projects like they are available and common for other IT projects. Methods that are very close to the underlying hardware like unit test, integration of electronics in IT-infrastructures, and automatic build systems are available today and are used in the Pengutronix remote lab as well. Along with a variety of tools these methods can be used to achieve this goal.

Our way to achieve that goal

How do we meet these requirements? Important aspects are:

Open and honest communication. We believe that a transparent communication and an open collaboration is the key to success. We work on a solution to all kinds of problems by putting ourselves in their point of view and understanding the challenges. Project mailing lists with all stakeholders enable for the project what the Linux Community shows us: technology user directly interacting with the technology provider.
Understanding problems. As engineers we are used to develop solutions for given problems. However, this is only possible if we understand what the actual problem is. The planing and implementation of a project can only be realized if the problem (and not only already existing solution suggestions) is understood correctly.
Identifying risks. Only with a lot of experiences one can identify and analyze critical issues with ex ante studies in an early stage of the project. However, within projects that are close to the underlying hardware, let's not make a mountain out of a molehill: there are many questions to be answered to find a final solution for that problem whether this is realizable. Therefore a very good planing based on similar project experiences is mandatory.
Living agility. Projects are only reasonably manageable if all stakeholders are willing to adjust to changing requirements and drawing correct conclusions. During that process, status meetings on a regular basis and a joint focus on problem solution strategies are extremely important.