1 / 24

Introducing Model Driven System Engineering for Thales systems A Thales Unit Deployment Story

Introducing Model Driven System Engineering for Thales systems A Thales Unit Deployment Story. Agenda. What is MDSysE A Thales Unit Deployment Story Lessons learned Today’s Change Management Organization Future Change Management Organization. Agenda. What is MDSysE

velmadonaldson
Download Presentation

Introducing Model Driven System Engineering for Thales systems A Thales Unit Deployment Story

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Introducing Model Driven System Engineering for Thales systemsA Thales Unit Deployment Story Research & Technology

  2. Agenda • What is MDSysE • A Thales Unit Deployment Story • Lessons learned • Today’s Change Management Organization • Future Change Management Organization Research & Technology

  3. Agenda • What is MDSysE • A Thales Unit Deployment Story • Lessons learned • Today’s Change Management Organization • Future Change Management Organization Research & Technology

  4. <<sys.Context>> Context <<sys.Logical>> Logical architecture <<sys.Physical>> <<sys.EPBS>> Physical architecture EPBS What is MDSysE? MDSysE: Tooling environment providing support for Model Driven System Engineering • MDSysE closely aligns with • SYS-EM  Thales Methodology for system engineering • SysML concepts  Standard for modeling systems. Formalization of system requirements Validation Product Verification Allocation of requirements Product Integration Formalization of component requirements Research & Technology

  5. MDSysE’s IDE Research & Technology

  6. Agenda • What is MDSysE • A Thales Unit Deployment Story • Lessons learned • Today’s Change Management Organization • Future Change Management Organization Research & Technology

  7. A Thales Unit Deployment Story • First evaluation of MDSysE February 2005 • Assumption: process is self explained through the tool functions. • Results • MDSysE is a generic tool that needs to be specialized • MDSysE implements a process framework • Many process structure decisions need to be taken • E.g. What to refine and how refining from level of abstraction to level of abstraction is not clear. • There is a need to refine the method for the Thales unit. • Some defects needs to be fixed. Research & Technology

  8. A Thales Unit Deployment Story • Second evaluation of MDSysE mid may 2005 • Delegate full time a TRT consultant to help the Thales Unit to elaborate its methodology. • 3 Thales Unit Process & tool experts involved in this task. • Objective: Build the method and qualify the tool for an effective deployment early 2006 • First step: mid may 2005: post mortem engineering of an existing system. • Try to emulate the mental process of system engineers and describe how the tool can support it. • Objective: Capture the decisions in slides that will serve for the creation of a “tool and process” training. • We do not target to create a model of the system. • Second step: October 2005: parallel engineering of a new system. • Do not impact the existing process. No synchronization constraints. • Capture with the new process what the engineering team has build. • Objective: Obtain the model of the system. • Complete and validate the process. Complete the training Slides. • January 2006: Engineer a new project with MDSysE. Research & Technology

  9. Current Results • First Step has been covered • 230 Slides Produced to capture the considered Thales Unit process. • All the system levels of abstraction handled by MDSysE clarified for the Thales Unit • We need more generic behavior in MDSysE to build a process that can support more system engineering concerns. • Second Step Covered • Third Step started Research & Technology

  10. Agenda • What is MDSysE • A Thales Unit Deployment Story • Lessons learned • Lack of definitions • Lack of best practices • Technology instability • Multiplicity of processes • Collaterals effects • External impacts • Cultural gap • Today’s Change Management Organization • Future Change Management Organization Research & Technology

  11. Lessons learned (1) • Lack of guidance • What are system engineering flavors? • Software predominant systems. • Hardware predominant systems. • Object orientated systems. • We need to define guidance to select the process type at first or build the process before executing it. • What is system engineering? • Each Thales Unit has a different perception of what it « should » be. • Thales builds a wide wealth of systems. « System » means different things for different units. • Each Thales unit (project?) has a different perception on how a system should be elaborated. • Target objective not assigned to system engineering activities. • E.g. What doe the system engineer targets to check or define with the physical architecture description? Throughput? Distribution? Other? • No Thales Unit has time or is willing to harmonize its views with others. • Is this necessary? • What is system engineering versus software engineering? • When saying “this is no more system engineering but software engineering?” • To which level middleware has to be abstracted in the system architecture? • … Research & Technology

  12. Lessons learned (2) • Lack of best practices • Example: What is the optimum level of granularity for a system capability? • How to measure cohesion, isolation, completeness etc. • What rules could help us to assess our work? • E.g. Use the 3rd normal form to assess the robustness of our data exchange model. • We need to capture and disseminate the system engineering best practices among Thales Units Research & Technology

  13. Lessons Learned (3) • Technology instability • PIM / PSM does not mean anything • System externally visible behavior can be platform specific • There is still a lot to discover • How expressing the binding of an architecture on an execution platform? • How to guide architects in choosing and expressing their decisions? • Typically when binding an architecture on an execution platform • What tooling support can be provided to support product line engineering? Research & Technology

  14. Distribution Internet Hard Real Time Time Distributed Soft Real Time No constraint MDSysE Embedded Culture Functional Decomposition Object Orientated Component based Lessons Learned (4) • Multiplicity of processes • The definition of an MDE/MDA process depends on multidimensional parameters. • E.g. culture • Functional decomposition does exists • Object orientated • Component based architecture Research & Technology

  15. Lessons Learned (5) • Collateral effects • Deploying an MDA/MDE approach pulls other disciplines in the picture. In Thales case: • Revisiting the requirements taxonomy is a must. • Concept of “Capability” is too wide. It does not align with the semantic of a MDSysE Capability. • Integration and Test • Formal system modeling helps at mastering the integration process. • Test • Not yet addressed but System Test Cases link to system architecture. How? • Configuration Management: • System modeling provides the mean to build the configuration management strategy. • Revisiting the configuration management elements is a must • CSCI must be able to be broken down in smaller configuration items. This is not yet the case. • Software Engineering • Integration of system engineering modeling platform and Middleware design studio: • Technical integration • Semantic alignment  MDE / MDA requires that there is some effort put in updating the corporate artifacts templates (SSS, SSDD, SRS etc.) Research & Technology

  16. T0 SSS SSDD Time T0 SSS SSDD Time Lessons Learned (6) • Customer Relationship Short term Impact. • Deliverable milestones. • The set of documents to be delivered to the customer at well defined milestones may slip. • The system organization was not captured in UML models • The system organization is now captured in UML Model during the engineering process, but later. • The deliverables are now partly made of UML Model views. • Less ambiguity • More formality, consistency, completeness. • Does the customer understand this formalism? Does he agree the process? Standard scenario MDE / MDA scenario Research & Technology

  17. Time Lessons Learned (7) • Cultural Gap needs to be managed • There is a lot to learn by the process end users • Need to build a phased coaching strategy to manage the cultural gap • Therefore for a Thales business line the deployment process depends on • The unit maturity • The technology progress • The level of dissemination. Maturity Dissemination Time Technology Time Research & Technology

  18. Consequences • Create Specialized versions of MDSysE according to the needs of each unit. • Manage MDSysE as a product line. • Core set of standard modules • Domain specific modules • Need: Create a strong CCB process to help harmonizing / factorizing views. • Views cannot be 100% unique. • Put as much as possible in MDSysE Core. • Need: Create a strong coaching infrastructure acting as Thales units proxies. • MDSysE evolutions derive from: • Thales units needs. • Technology progress • The coaching infrastructure • Provides expertise in formalizing Thales know how in an MDE/MDA process. • Increase the shared part between Thales Units. • Capture and disseminate System Engineering best practices. • Are not tool experts. • Are not a specific business domain experts. Research & Technology

  19. Agenda • What is MDSysE • A Thales Unit Deployment Story • Lessons learned • Today’s Change Management Organization • Future Change Management Organization Research & Technology

  20. MDSysE4Unit B MDSysE4Unit A Today’s Management Organization Thales Unit MDSysE Software Development Team Coach CCB Deployment support • TRT Software Development team is in charge of developing the core of MDSysE. This excludes process specific behavior. • TRT Parameterization team is in charge of parameterizing MDSysE according to Thales Units process specific needs. • TRT Deployment support is in charge of educating each Thales Unit and guarantees the homogeneity and optimum reuse accross the Thales Units processes. Thales Unit Coach Parameterization Team Research & Technology

  21. Agenda • What is MDSysE • A Thales Unit Deployment Story • Lessons learned • Today’s Change Management Organization • Future Change Management Organization Research & Technology

  22. Need for an evolving organization • This organization will evolve • TRT cannot have the responsibility to maintain all the MDSysE flavors. • TRT needs to concentrate on common needs: • Need for provision of a pattern engine. • Need for provision of product line approach. • Need to provide a support for trade-off analysis. • … • TRT needs to provide the support required to easily create specialized versions of MDSysE. • MDSysE as a software factory. • Thales units must identify in their organization people in charge of maintaining their own instance of MDSysE. • Next level of Thales unit maturity. • Coaching is still required to facilitate understanding and formalization of units needs. Research & Technology

  23. MDSysE Core Specialization Engine MDSysE Software Development Team Coach CCB Deployment support Coach Thales Unit Thales Unit Parameterization Team Parameterization Team Medium term organization target • This organization is already proposed for some projects Research & Technology

  24. Question? Research & Technology

More Related