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

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

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

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

MDSysE’s IDE Research & Technology

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

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

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

First Step has been covered 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

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

Lessons learned (1) What are system engineering flavors? 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

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

Technology instability 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

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 Culture Functional Decomposition Object Orientated Component based Distribution Time Embedded Distributed Internet No constraint Soft Real Time Hard Real Time MDSysE Research & Technology

Collateral effects Lessons Learned (5) 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

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? Time T0 SSS SSDD Standard scenario MDE / MDA scenario Research & Technology

Cultural Gap needs to be managed 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 Time Technology Time Research & Technology

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

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

Today’s Management Organization MDSysE4Unit A Thales Unit MDSysE Software Development Team Coach CCB Deployment support Thales Unit MDSysE4Unit B Parameterization Team Coach 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. Research & Technology

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

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

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

Question? Research & Technology