Merlin

MerlinITEA Symposium 2006

2006 Merlin Overview 2

Problem domain

• Companies hardly develop embedded products completely on their own

• Embedded systems need to be developed:– globally distributed– in collaboration with subcontractors, third party

developers and in-house development– using the advantages of collaboration, solving the

disadvantages• Embedded systems industry still growing

– Embedded systems more dominant in all markets– Increasingly demanding requirements

• Development technologies insufficiently prepared for different collaboration modes

2006 Merlin Overview 3

Consortium

• Finland:– Nokia Application partner– Solid Application partner (SME)– Oulu University Technology partner– VTT Technology and exploitation partner– Incode Application partner (SME)

• Netherlands:– Philips Technology and application partner– LogicaCMG Application and exploitation partner– Delft University Technology partner

• Sweden:– Sony Ericsson Technology and application partner– Ericsson Technology and application partner– Lund University Technology partner

2006 Merlin Overview 4

What does Merlin Project do?

• Enabling the collaborative development of embedded systems with multiple partners

• Emphasising the advantages of collaborative development and neutralising the disadvantages of collaboration

• Developing dedicated effective and efficient processes and technologies for collaboration

• Increasing deployability by initiating industrial cases to validate Merlin solutions

• Enhance project results into exploitable solutions for collaborative development

2006 Merlin Overview 5

Scenario Symposium 2006

2006 Merlin Overview 6

Work packages

Work package 1: Collaboration Enablersactivities for collaborative embedded product development;

concepts and tool-chains for inter-organisational collaboration, such as partnering, open source-based co-operation

Work package 2: Non-functional Demandsactivities for non-functional (quality) aspects of embedded

systems development. Modelling and validation of non-functional aspects for collaborative product development with a focus on requirement engineering and architecting

Work package 3: Advanced coding and testingactivities for embedded system software implementation.

Modelling, implementation, code-generation and testing for embedded system components in a collaborative context.

Work package 4: Exploitationactivities for project exploitation. Focus on standardisation,

dissemination, marketing and experience exchange. Especially exploitation and standardisation are its main focus

2006 Merlin Overview 7

Solution status for problems (year 2005)

• Lack of interface management• Lack of common understanding of architecture• Lack of integration strategy and plan

• Lack of knowledge and skills in integration team• Underestimated integration effort and time• Integration responsibilities not clearly assigned

• Status of test results not shared• Sharing of same test environment not feasible• Integration not centrally controlled

• Lack of skills for multiple team CM• Problems not reproducible

• Uncontrolled releases• Lack of library system enabling multi-team CM

• Acceptance procedures of mutual deliveries not defined

• Need for explicit communication underestimated• Underestimated learning curve• Escalation mechanisms not defined

• Suppliers not or not timely audited• Lack of stated criteria for selecting suppliers• Confidentiality

• No detailed plan or clear agreements with suppliers

• Not defined change management procedures

• Lack of leveling of local and global change requests and problem reports

• Underestimated impact of changes to other parties work• Lack of involvement of right people in requirements and

architecture analysis and validation• No common understanding about the requirements

• Diverse RM practices between collaboration parties

• Dependencies between teams not made explicit and managed

• Unstable requirements

• Not defined prioritization rules and practices of the requirements in case of many interest groups

• Not defined practices for resolution of conflicting requirements

No solution yetIdeaAvailableProven

• No traceability of requirements in collaborative development

• No transparency of the collaborative engineering chain

• Consistency between engineering tasks not manageable

• No visibility of collaborative development status beyond partner borders

• Not traceable whether the product meets the requirements in collaborative development

• Sharing and maintaining the integration and testing knowledge effectively

• Sharing resources efficiently, managing access, traceability and privacy

Solution status for problems (current)

2006 Merlin Overview 8

Merlin tool

2006 Merlin Overview 9

Tool chain architecture

Requirements mgmt tool

Configuration mgmt tool

Testing tool

Requirements Design Implementation TestingIntegration

Eclipse

Requirements Management

view

Configuration Management

view

Testing view

Project Mgmt

tool

Project Management

view

Improved traceability

Eclipse-based Merlin tool

2006 Merlin Overview 10

Outlook to Merlin tool chain

Fixed PM View

Separated Tool

Plug-in

RM Tool

Separated Tool

Plug-in

PM Tool

Separated Tool

Plug-in

CM Tool

TraceabilityDatabase

MASTERPlug-in

Separated Tool

Plug-in

Testing Tool

Fixed RM View

Fixed CM View

Fixed Testing View

2006 Merlin Overview 11

Current cases vs handbook topics

Management practices– Collaboration strategy– Contracts– Collaboration management– Project management– Risk management– Information management

Engineering practices– Requirements development– Requirements management– Architecture design– Software design– Software implementation– Integration– Testing– Release

Support practices– Configuration management– Quality assurance– Documentation– Improvement process– Human resource management– Infrastructure– Co-operative work

Cases often contribute to more topics, this mapping depicts the main topic addresses.

Thank you for your attentionand

See you next year!

ITEA Symposium 2006