Introduction to the Connected Software Engineer (XSF) Role

Overview

Managing software in a multidiscipline product development in effective manner is essential as it influences the overall cost, value, and experience of these products. Increased product complexity requires the integration of hardware and software development processes. Most often, in such multi-disciplined product development, software is developed and managed in a silo and its output (.exe/package) is added to the final product without any traceability or governance abilities.

The Connected Software Engineer (XSF) role is available both On Cloud and on Premise and provides a single dashboard app ‘Connected Software’ that provides the ability to govern software in context of a multi-discipline product development. Software engineers can use respective connectors to fetch and review software code managed in external Source Code Management (SCM) tools (e.g. GIT or DesignSync) into the 3DEXPERIENCE platform.

Managing Software in a Multidiscipline Product Development

With the app Connected Software, you can seamlessly manage software with effective collaboration and traceability between other disciplines in a multidiscipline product development. The following process is the high level overview of how you can manage Software in Multidiscipline Product Development:

                            Image 1: Managing Software in Multidiscipline Product Development

  1. Connect: Connect software development content to the platform to manage changes and release processes of the software in a holistic view.
  2. Federate: Federate the software content metadata to the platform for traceability and governance. This allows you to leverage planning and governance of software development as part of the overall development plan of the product.
  3. Implement: Start leveraging the ability to implement software in the context of configured multi-discipline solution, composed of modular configured HW, SW and service products.

Software Item

A software item can be Software Logical Item or Physical Product.

  • Software Logical Item can contain:
    • Source code where the development work occurs.
    • Planning documents, specifications, testing plans and other types of planning and abstracted concepts managed by revision control.
  • Physical Product is the physical form of the software, such as software build (compiled executables, libraries, and other types of physical elements)

Software Connector

Software connectors are created in the platform to connect the Software Items to the External SCM System where the software development takes place. You can connect the repository in the platform to any of the following SCM systems:

  • GIT
  • DesignSync

These connectors allow you to locate and fetch the software data from external SCM system to the platform. It also ensures that you are viewing up-to-date software code at any time using the web-based, language sensitive viewer.

NOTE: Software connectors should be defined in the platform in advance. User must have an ‘Owner’ role in the Collaborative Space to create new connector.

Integrating Software into Multidiscipline Structure

              Image 2: Process showing how to integrate software into multidiscipline product structure

Software code development is performed in the external SCM system such as GIT, DesignSync. You can create a new Software Logical Item and connect it with the required SCM system using connector. You can open it to review software source code in a language sensitive viewer, and freeze it to avoid any further modifications.

You can create a Software Physical Product that represent the physical form of the software, such as software build. Build artifacts are accessed in the platform by connecting Physical Product to the external SCM system via a connector created in the platform. You can then insert the Software Physical Product in the existing multi-disciplined product structure. Once successfully integrated, you can promote the Software Logical Items and Software Physical Products to Released state.

Govern Software Code Changes using Formal Issues and Change Action

You can raise Formal Issue on Software Physical Product, add contextual information, and assign it to responsible person. Raising formal issue allows you to track issue resolution status. Teams can collaborate to resolve the software issue and close it with the right information or start a formal change process.

                                        Image 3: Change Action (Proposed Changes)

You can also raise a Change Action to formally manage the change process of the software code. Modifications done using the change action are recorded in the Realized Changes tab of the change action.