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

1
Introducing Model Driven System Engineering for
Thales systemsA Thales Unit Deployment Story
2
Agenda

• What is MDSysE
• A Thales Unit Deployment Story
• Lessons learned
• Todays Change Management Organization
• Future Change Management Organization

3
Agenda

• What is MDSysE
• A Thales Unit Deployment Story
• Lessons learned
• Todays Change Management Organization
• Future Change Management Organization

4
What is MDSysE?
MDSysE Tooling environment providing support
for Model Driven System Engineering
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.

5
MDSysEs IDE
6
Agenda

• What is MDSysE
• A Thales Unit Deployment Story
• Lessons learned
• Todays Change Management Organization
• Future Change Management Organization

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.

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.

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

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
• Todays Change Management Organization
• Future Change Management Organization

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?

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

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?

14
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

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.)

16
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
17
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
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.

19
Agenda

• What is MDSysE
• A Thales Unit Deployment Story
• Lessons learned
• Todays Change Management Organization
• Future Change Management Organization

20
Todays Management Organization
Thales Unit
MDSysE Software Development Team
Coach
CCB
Deployment support
Thales Unit
Coach
Parameterization Team

• 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.

21
Agenda

• What is MDSysE
• A Thales Unit Deployment Story
• Lessons learned
• Todays Change Management Organization
• Future Change Management Organization

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.

23
Medium term organization target

• This organization is already proposed for some
  projects

24
Question?