Papyrus IC/Product Management

From Wiki
Jump to: navigation, search
Papyrus IC logo

This page is managed by the Product Management Committee


Committee Members

  • Chairman: Charles Rivet Zeligsoft
  • Co-Chairman: Xavier Plavis Airbus
  • TBD (Ericsson)
  • Francis Bordeleau (Cmind)
  • Sebastien Gérard (CEA)
  • TBD (Saab)
  • Maximilian Koegel (EclipseSource)
  • Cortland Starrett (OneFact)

Minutes of Meetings (MoM)

You can find the MoM here.

Eclipse Papyrus Platform ("Papyrus")

Papyrus Platform.png

Platform Lead: Sebastien Gerard (CEA)

The Papyrus Platform is the platform for the development of modeling tools and domain-specific modeling languages (DSML) based on UML.

The Papyrus platform provides specialized tools allowing a toolsmith to completely tailor Papyrus for a specific DSML, which can be based either any of the Papyrus-based products listed on this web site.

The Papyrus Platform also provides components that can be reused by and in products.

Papyrus lets toolsmiths define specialized languages with tailored modeling environment specific to your application domain, based existing modelling standards (e.g., UML) or on one of the existing Papyrus-based products. The full Papyrus platform includes many components that can be combined to form powerful applications. This is the basis of a growing line of industrial products, such as Papyrus-RT, addressing specific industries, specified and guided by the Papyrus Industry Consortium, an Eclipse working group, lead by users, suppliers, and research/academia, that focuses on the development of an advanced, industry-ready, open source, standards-based (UML, SysML), model-based engineering platform and tool suite built on Papyrus.

Please note that product management requirements applicable to product similarly apply to the Papyrus Platform.

Links of interest

Papyrus includes the following Components ==

Papyrus Core

Product Lead: Someone (company)

Provides capabilities for TBC

Links of interest

  • TBD

Papyrus Collaborative Modeling

Product Lead: Someone (company)

Provides capabilities for TBC

Links of interest

  • TBD

Papyrus Product Requirements

Papyrus Product technical Requirements

This section defines the technical requirements for Papyrus products

  • Products shall be stored in an Eclipse project to benefit from all associated infrastructure (CI, wiki, mailing list, forum).
  • Products shall provide a governance on their handling of requirements, bugs, etc. in order to set and manage expectations.
  • Products shall be delivered with test suite(s) to evaluate quality. Results from these will be used to determine milestone releases.
  • Products shall have both a product lead and a project lead assigned.
  • Products shall contain assets facilitating adoption, e.g.,
    • shall have a simple installation procedure for modeling users
    • shall have documentation available, the form of which will need to be determined
    • Should have tool-based guidance for tasks
  • Products shall be composable (e.g., products in the Papyrus product line can be installed in each other; access of separate models in a single workspace. Other use cases to be determined).
  • Product Leads shall provide, twice a year, plans and roadmaps covering the next 12 months for inclusion into the Papyrus IC overall roadmap

Papyrus Product Naming

Note: The following requirements only apply to the Papyrus Products and not to the names of Papyrus Platform or its components.

  • Papyrus products shall have both a long and a short name.

Papyrus Product Names Usage

  • The Papyrus product long name shall be used:
    • For official document titles
    • On first use in all marketing materials, e.g., web sites, posters, and user stories.
  • The Papyrus product short name can be used:
    • In any document after the long name is used at least once.
    • In software, e.g., copyright, module/component names, and folder names.
    • Basically anywhere other than where the long name is required.

Papyrus Product Long Name

  • The Papyrus product long name shall be of the form (in EBNF notation):
    • <Papyrus Product Long Name> = Eclipse Papyrus for <long name postfix>
      where long name postfix is a short description of the domain of application (see examples in the list of products, below).

Papyrus Product Short Name

  • The Papyrus product short name shall be of the form (in EBNF notation):
    • <Papyrus Product Short Name> = Eclipse Papyrus - <short name postfix>
      where short name postfix can be an acronym, an abbreviation, or just visual similarities in the letters used in the long name postfix. Although no length requirements are imposed, it should ideally be 2-5 letters long and can not be longer than the long name postfix.
      It is mainly important that some recognizable link exists between the long name postfix and the short name postfix and that the latter be recognizable as indicative of the purpose/function of the product (which should be self-evident in the former).

Papyrus Products

This section contains the alphabetical list of the products currently available or actively being developed.

To be part of this list, a Papyrus product must have or be a major part of an Eclipse project, thereby having a source repository, a continuous improvement infrastructure with build and automated testing capabilities, a development mailing list, and a forum.

Eclipse Papyrus for Enterprise Architecture ("Papyrus-EA")

Product Lead: Thomas Wiman (Adocus)

Papyrus-EA focuses on the use of Papyrus for enterprise architecture. It includes notations like ArchiMate, BPMN, BMM, UML, and other UML/SysML profiles used to model different aspects of enterprise architecture.

Although the Eclipse project is not yet created, some functionality, such as BPMN, ArchiMate and BMM, is currently available.

Links of interest

Eclipse Papyrus for Information Modeling ("Papyrus-IM")

PapyrusIMLogo.png

Product Lead: Philip Langer (EclipseSource) You can find information on Papyrus for Information Modeling here
The Papyrus for Information Modeling Customization Guide is also available here

Links of interest

Eclipse Papyrus for Real-Time ("Papyrus-RT")

Papyrus-RT.png

Product Lead: Charles Rivet (Zeligsoft)

Papyrus-RT is an industrial-grade, complete modeling environment for the development of complex, software intensive, real-time, embedded, cyber-physical systems.

Papyrus-RT provides an implementation of the UML-RT modeling language together with editors, code generator for C++ and a supporting runtime system.

Links of interest

Eclipse Papyrus for UML ("Papyrus", "Papyrus-UML")

Papyrus-UML.png

Product Lead: Sebastien Gerard (CEA)

Provides a complete UML development environment that conforms to the OMG specification, including the ability to create and use UML profiles.

This product contains all the modeling capabilities of the Papyrus platform and, for the time being, therefore equivalent to the Papyrus Platform.

Links of interest

Eclipse Papyrus for xtUML ("Papyrus-xtUML")

Product Lead: Cortland Starrett (One Fact)

Executable, translatable UML (xtUML) is a dialect of UML based upon the Shlaer-Mellor Method which supports Model-Driven Development (MDD). Papyrus-xtUML (BridgePoint) provides the system design community with xtUML editing, execution and translation capabilities.

Editing is provided with a mixed graphical and textual user interface. Components, class diagrams and state machines are edited as UML2 graphical elements. Activities are edited using a textual action language.

Models are interpretively executed (including partial models).

xtUML models are translated using model compilers. C, C++ and SystemC model compilers are the most popular.

Links of interest

Future Papyrus Products

This section contains the alphabetical list of the products currently being planned or that do not yet have an Eclipse project.

Eclipse Papyrus for Safety and Security Engineering ("Papyrus-SSE")

PapyrusSSE.png

Product Lead: someone (CEA)

Description TBD

Links of interest

  • TBD

Eclipse Papyrus for SysML System Engineering ("Papyrus-SysML")

Product Co-Lead: Francis Bordeleau (Cmind), Gert Johansson (Saab)

Papyrus-SysML focuses on the use of Papyrus for Systems Engineering (SE) based on the OMG SysML. It includes SysML 1.1/1.4. It is optimized for efficient specification of top level behavior and quality requirements as well as structural design, use case realizations with white box interaction analysis and inherent subsystem functionality allocation to subsystems, definition of interfaces and internal connections using ports. The specialized variant of Papyrus for SE will be focused on the essentials for SE and is a planned future product with a proposed roadmap in draft version. Currently, the Papyrus platform can be used for SE. Input to Papyrus for SE can be sent to the product lead

Links of interest

Testing/QA Process

This section is focused on the establishment of a community Testing/QA process for the different Papyrus products.

PMC Testing Requirements

To ensure that proper testing is done to help ensure quality of the milestone releases, the Papyrus Product Management Committee has the following testing requirements:

  • A continuous integration infrastructure shall be provided to meet the following testing requirements.
  • Automated and required manual tests shall be run at least once for every new major and minor milestone builds, prior to milestone acceptance.
  • Ideally, tests as specified above should be run as often as possible, without degrading build system or development capabilities.

Members Testing Efforts

This section is used to capture the testing that members of the Papyrus community (Papyrus IC members and non-members) are doing on Papyrus products. We strongly encourage people/organizations using Papyrus products in different contexts to describe their current usage and the testing they do (directly or indirectly). The overall goal is to understand the aspects of Papyrus products that are being actively used/tested.

Description Format

Please describe the work you do in terms of

  • Identifier: Please provide a short identifier for you test/usage description
  • Person/Organization:
  • Papyrus product used: For example Papyrus, Papyrus-RT, Papyrus for Information Modeling, etc
  • Usage context: Brief description of the modeling context in which you are using Papyrus and the different profiles used (if any)
  • Aspects used/tested: List of the types of diagrams or specific aspects of Papyrus (e.g. customization, DSL, etc)
  • Test description:
    • Description of the type of testing done. If you are not formally testing Papyrus, but rather just using it, please mention it. There is still a lot of value in understanding the different aspects of Papyrus that are actually being used used, event of it is not formal testing
    • Is the testing manual of automated? Do you have a systematic testing process or is it rather ad hoc.

Test/Usage Descriptions

Identifier:

  • Person/Organization:
  • Papyrus product used:
  • Usage context:
  • Aspects used/tested:
  • Test description:


Proposed Improvements

This section is used to capture improvements to the testing process proposed by members of the Papyrus community.

Marketing and services

Marketing Materials

You can find, on this wiki, marketing material related to the Papyrus Industry Consortium:

Suppliers expectations

The suppliers expect the following from the Papyrus IC:

  • Provide Papyrus IC branding elements (e.g., logo, tag lines, various images, to be fully defined) to be used in their marketing materials to promote their membership in the Papyrus IC.
  • Provide social media support and coverage for suppliers events, publications, events, and social media presence (form and content TBD).
  • Coordinate members participation at conferences and provide onsite support (booth, logistics) to suppliers participation at events and conferences to which the Papyrus IC is present. (Note that this does not extend to supplier travel and living costs, supplier's own marketing material, or fees to attend conference).
  • Provide a web-accessible listing of suppliers and their offers that are directly related to the Papyrus IC's activities and areas of concern.
  • Actively promote commercial solutions offered by members.Supplier members will provide acceptable material to support this.
  • Encourage, promote and help coordinate co-marketing efforts between suppliers.
  • Continue to provide services defined as part of PolarSys, as defined by the suppliers (i.e., continuation of service), unless the suppliers agree by super-majority to discontinue a service. The PolarSys services are:
    • Access to the LTS Build Infrastructure
    • Access to LTS binary releases
    • Host custom build on WG infrastructure
    • Maturity assessment program
    • Access to qualification kits

PIC Supplier Promotion Guidelines

Introduction

The Papyrus Industry Consortium (PIC) is devoted to assuring the availability of open and accessible Model-Based Engineering (MBE) tool chains. It does this by fostering and leveraging collaborations between users, suppliers and academics. Commercial suppliers are recognized as playing a key role.

Supplier Advocacy

In support of suppliers, the PIC permits, encourages and advocates promotion of commercial products and services closely associated to and aligned with the PIC mission and vision. The PIC is devoted to Open Source Software (OSS) and the accessibility and community that follow from solutions founded on OSS. Commercial offerings are critical to the ecosystem underlying OSS solutions. Such offerings may involve relevant proprietary or licensed elements when relevant and clearly disclosed.

Relevance

Promotion of products and services by PIC suppliers among PIC members and during PIC activities should be limited to those services that are closely related to and in alignment with the PIC mission and vision. Promotion of unrelated products and services on PIC media or at PIC events is discouraged.

Transparency and Disclosure

Promotional activity around a product or service offered by PIC supplier members must include transparency and disclosure of proprietary or licensed components. PIC suppliers must be clear about which parts of their products and services are not OSS or which may result in vendor lockin.

Governance

The PIC Product Management Committee (PMC) will provide the first level of oversight regarding supplier product and service promotion. The PMC may call into question promotions that seem to be irrelevant, non-transparent or otherwise inappropriate for PIC endorsement. The PIC Steering Committee will serve to resolve questions and concerns escalated by suppliers or the PMC and has the final authority over PIC-related media and activities.