120 likes | 290 Views
Merlin. ITEA Symposium 2006. 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
E N D
Merlin ITEA Symposium 2006
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 Merlin Overview
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 Merlin Overview
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 Merlin Overview
Scenario Symposium 2006 Merlin Overview
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 Merlin Overview
Solution status for problems (year 2005) Solution status for problems (current) Proven Available Idea No solution yet • 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 Merlin Overview
Merlin tool Merlin Overview
Improved traceability Testing view Project Management view Requirements Management view Configuration Management view Eclipse Eclipse-based Merlin tool Project Mgmt tool Requirements mgmt tool Configuration mgmt tool Testing tool Testing Requirements Design Implementation Integration Tool chain architecture Merlin Overview
Outlook to Merlin tool chain Merlin Overview
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. Merlin Overview
Thank you for your attentionandSee you next year! ITEA Symposium 2006