Difference between revisions of "EUDP in detail"

Revision as of 11:28, 12 July 2012

Welcome to EUDP - Embedded Unified Development Process.

The work around EUDP began in the early part of the 00 decade. In 2003 HIH (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 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 includes thoughts from it.

We've added some business mindset to the development method, as we saw a clear lack of this angle of development methods. So 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 get the grasp of a new project. Typically the Customer calls the Developer to get an idea of if a new idea can be realised and within what economic frame. 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 customers idea to estimate the how long time should be spent analysing more detailed.

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 for 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 the customer asked for. Each iteration should last 2-6 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 are realised 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 development the price to correct the problem are far lower than if the error was found late in the development.

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 the the product fulfils the requirements. In cooperation the customer and the developer evaluates the product and the project. It is important to learn from every project completed. The key is to find what went well but also to find anything that the customer or the developer find can be improved i further projects. System development is never the same from project to project nor are the customers or the developers. Constant improvement are the key to success for all involved. Improvements can only be gained if a thorough evaluation is conducted.

We mention Four Phases of EUDP. But in reality there are 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 covers subjects like contracting, management with different views, human processes, reviewing and other sociological aspects that a developer may need to complete a system development.