Merlin

1
Merlin

• ITEA Symposium 2006

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

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

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

5
Scenario Symposium 2006
6
Work packages

• Work package 1 Collaboration Enablers
• activities 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 Demands
• activities 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 testing
• activities for embedded system software
  implementation. Modelling, implementation,
  code-generation and testing for embedded system
  components in a collaborative context.
• Work package 4 Exploitation
• activities for project exploitation. Focus on
  standardisation, dissemination, marketing and
  experience exchange. Especially exploitation and
  standardisation are its main focus

7
Solution status for problems (year 2005)
Solution status for problems (current)
No solution yet
Idea
Available
Proven

• Confidentiality

• Sharing and maintaining the integration and
  testing knowledge effectively

• Lack of stated criteria for selecting suppliers

• Lack of interface management

• Suppliers not or not timely audited

• Lack of common understanding of architecture

• No detailed plan or clear agreements with
  suppliers

• Lack of integration strategy and plan

• No visibility of collaborative development status
  beyond partner borders

• Integration responsibilities not clearly assigned

• No traceability of requirements in collaborative
  development

• Underestimated integration effort and time

• Lack of knowledge and skills in integration team

• Consistency between engineering tasks not
  manageable

• Integration not centrally controlled

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

• Sharing of same test environment not feasible

• Status of test results not shared

• Not defined change management procedures

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

• No transparency of the collaborative engineering
  chain

• Underestimated impact of changes to other parties
  work

• Problems not reproducible

• Lack of involvement of right people in
  requirements and architecture analysis and
  validation

• Lack of skills for multiple team CM

• Uncontrolled releases

• No common understanding about the requirements

• Lack of library system enabling multi-team CM

• Not defined practices for resolution of
  conflicting requirements

• Sharing resources efficiently, managing access,
  traceability and privacy

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

• Acceptance procedures of mutual deliveries not
  defined

• Unstable requirements

• Escalation mechanisms not defined

• Dependencies between teams not made explicit and
  managed

• Underestimated learning curve

• Diverse RM practices between collaboration
  parties

• Need for explicit communication underestimated

8
Merlin tool
9
Tool chain architecture
10
Outlook to Merlin tool chain
11
Current cases vs handbook topics

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

• 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

Cases often contribute to more topics, this
mapping depicts the main topic addresses.
12
Thank you for your attentionandSee you next
year!

• ITEA Symposium 2006