EUDP in detail

Welcome to EUDP - Embedded Unified Development Process

The work around EUDP began in the early part of the 00 decade. In 2003, HIBAT (now Aarhus University, Herning) received a funding from the Ministery of Science, Technology and Development. In cooperation with several companies, the basic EUDP was developed. In 2009, all the pages were moved to this wiki and a few changes were made thereafter. In 2012, a major rewriting of the site was initiated.

What is EUDP

EUDP is basically a method to use when developing embedded systems. EUDP intends to combine the development of software, hardware and mechanicals in order to comprise an embedded system. While developing EUDP, we found that both the traditional waterfall methodology as well as the upcoming agile methods such as Ropes, RUP, Scrum and XP had very good thoughts that could be used in this process. Systems engineering has matured since then, and parts of the revised EUDP include thoughts from this approach.

We have added a business mindset to the development method, as we found that there was a lack of such approach. As a result, the reader will find a complete business-oriented technical development method in EUDP.

The EUDP method consists of four phases.

The EUDP development method at a glance

In the PreProject Phase, we define how to grasp a new project. Typically, the customer contacts the developer to find out if a new idea can be realised and what the financial framework is. In this phase, the developer works without being able to bill the customer. Consequently, this phase must be kept as short as possible. The work necessary to complete should bring the developer to the point, where it is possible to present a quotation that covers the Launch Phase, i.e. the developer should understand enough of the customer's idea to estimate how much time should be spent analysing in detail.

The Launch Phase is normally paid by the customer on an hourly basis and therefore, the developer can analyse the system-to-be more detailed. The developer describes the general design of the system-to-be and gets an idea of how the system-to-be should be implemented. On the exit of the Launch Phase, the developer can estimate a fixed price for developing the total system-to-be and consequently present the customer with a new quotation covering the rest of the project.

If the customer accepts the quote, the project can go into the Realisation Phase, where the developer iterates a number of times through several disciplines developing more and more functionality into the system-to-be, ending up with the system that the customer asked for. Each iteration should be completed in two to six weeks. As a result of each iteration, the developer delivers a product with a certain agreed level of functionality. The customer can use the system, test it and verify that the intentions are correct. If any misunderstandings occur, they can be corrected quickly and early in the development, thereby reducing the cost of correction. Everybody knows that if an error or misunderstanding can be found early in the course of development, the price to correct the problem is far lower than if the error was found late in the development process.

Finally, it is important to leave the project and finalise the cooperation with the customer with a good feeling for both parties. Hence the PostProject Phase. In the PostProject Phase, the customer runs through an acceptance discipline verifying that the product fulfils the requirements. In cooperation with the customer, the developer evaluates the product and the project. It is important to learn from every project completed. The key is to identify what went well but also to find anything that the customer or the developer may wish to improve for future projects. System development is never the same from project to project, nor are the customers or the developers. Constant improvement is the key to success for everyone involved. Improvements can only be made if a thorough evaluation is conducted.

We mention the Four Phases of EUDP, but in fact there is yet another phase that covers methods or rather disciplines that can be introduced in practically all the above-mentioned phases - The Cross-Disciplinary Disciplines (CDD). The CDD cover subjects like contracting, management with different views, human processes, reviewing and other sociological aspects that a developer may need to complete a system development.

A cookbook

EUDP is built like a cookbook full of recipes. Entering a description of an activity, the reader is presented a recipe consisting of the appetising picture or short description of the outcome of the activity. Next is the list of ingredients that are necessary to prepare the outcome followed by instructions of how to use the ingredients. Finally, an argumentation of why and in what circumstances the activity is applicable is included.

It is highly recommended to read the why section the first couple of times performing the activity. After this point, this section becomes redundant as the personal knowledge and experience level take over.

What is next step?

At each phase, there is a description of what the purpose of working through this phase is and a reasoning about why the activities are important. Diving into a phase, the reader will find an overview of the activities.

Please note: The activities are presented in a form suitable for a webpage, but it is not necessarily the order of execution. Often, the project type invites to use one activity over another whereas another project type calls for other activities.

Also note: EUDP is developed to be used in agile development where the same activity is performed over and over, sometimes to gain a deeper and deeper understanding and knowledge or to gain the necessary understanding and knowledge of different tasks.

Use the Roadmap as a jump stone to the different phases to continue from here.