=Paper=
{{Paper
|id=Vol-1728/paper4
|storemode=property
|title=Designing a System Engineering Environment in a Structured Way
|pdfUrl=https://ceur-ws.org/Vol-1728/paper4.pdf
|volume=Vol-1728
|authors=Anna Todino,Ivo Viglietti,Bruno Tranchero,Ruben de Juan Marín
|dblpUrl=https://dblp.org/rec/conf/ciise/TodinoVTJ16
}}
==Designing a System Engineering Environment in a Structured Way==
https://ceur-ws.org/Vol-1728/paper4.pdf
Designing a System Engineering Environment in a
structured way
Anna Todino Rubén de Juan Marín
Ivo Viglietti Instituto Tecnológico de Informática
Valencia, Spain
Bruno Tranchero
Leonardo-Finmeccanica Aircraft Division
Torino, Italy
Copyright © held by the authors.
Abstract— Defining and designing a System Engineering Keywords—development process; SPEM 2.0; System
Environment in a complex industrial context is not a Engineering Environment; Engineering Methods; Engineering
trivial task. Experiences, best practices, internal rules, tool functions, IOS capability, Tool taxonomy, Tool Integration;
company procedures and applicable standards, all play a Tool-chain
role in the definition of a development process covering
the different phases of development of a complex I. INTRODUCTION
product. Engineers from various industrial domains Within the industrial domains, it is a common practice to
need to develop complex systems in accordance with have a well-defined development process in order to
System Development Life Cycle Processes, defined manufacture a given product. A product development
within domains themselves, to assure project success in process defines a workflow of activities and related work
terms of time-to-market and product quality. These products. A product development process is always
success criteria require reducing the development costs supported by a proper System Engineering Environment
and applying an appropriate Design to Cost (SEE) that is a framework which defines software, in terms
methodology to the different engineering projects, and of software tools used for development, hardware where the
the use of best practices is a mean to achieve this goal. SEE is deployed, and data in terms of work products, models
Best practices consist of cross-domain and/or cross- and other information relevant to the specific activities
project engineering methods and their application in the defined in the product development process. So the
development of systems, where a specific engineering definition and configuration of a proper SEE is an essential
part of a development process. One of the difficulties lies in
method addresses a preferred workflow by means of
the fact that depending on the available resources and on the
tools, involved artefacts and required interoperability skills of process engineers, it is not always straightforward to
between tools. Since the choice of a development tool can define a SEE.
have some influence on the resulting system design, the
characteristics of such tool must be clearly understood The CRYSTAL Platform Builder (PB) is a solution based
before the selection is made, and often the selection of on the availability of an engineering methodology and the
tools is demanded to the ICT department, that related engineering tools and also on an already defined
sometimes is not completely aware of the system development process, to support the definition and
development engineers’ needs. The idea is to reduce the configuration of an instance of the SEE to be used by
development costs by reducing the time required to company engineers to manufacture the product. This
approach starts from an existing product development
select the tool-set using ICT skill, process knowledge and
process, which is the combination of a development process
applying cross-project engineering methods in order to
and of a product specific use case, and from Engineering
specify and select the best solution. In this paper is Methods (EM) applicable within the engineering
presented a solution that is one of the outcomes of the methodology and defined during the CRYSTAL project.
CRYSTAL Research Project, for selecting a System This article is mainly composed by two sections:
Engineering Environment that satisfies the development
process needs and supports engineering methods, which
are formalized through SPEM 2.0. • Concepts and meta-models: this is an overview and
This solution is based on the Platform Builder Modeler, specification of concepts and meta-models dealing
which allows to instantiate and validate a System with PB methodology
Engineering Environment that includes tool-chain, IT
infrastructure and data, dedicated to accomplish a • Platform Builder Modeler: this is an overview of the
selected development process. implemented solution based on the specified
methodology.
Copyright © (2016) Leonardo-Finmeccanica S.P.A. & Instituto Tecnológico de Informática Permesso concesso a AISE di
pubblicare e utilizzare
II. CONCEPTS AND META-MODELS • Validation phase: where the tool-chain is evaluated
against some business and technical constraints
A. State of the Art within the organization context.
Nowadays even if the definition and formalization of the Many different types of data must be classified and
system development environment is presented as a set of formalized in order to be used within different phases. This
consolidated formal steps, for example included in System task was performed in the CRYSTAL project, where meta-
development plan document, at industrial level no meta- models and data-models where defined. The result of the
models are available to describe a SEE. The topic is Tailoring phase is a Tailored Process, describing activities to
challenging and this is also demonstrated by the several be performed and engineering methods to be applied to
research initiatives in the fields; for instance DevOps - develop a product according to the specified Use Case. The
toolchain group [7] is a tentative to collaborate about tool- Tailored Process will contain information required to enable
chain taxonomy, in order to classify tools, following configuring a SEE using the PB Modeler. In the SEE
software development life cycle phases. Tool-chain configuring phase, using a catalogue of the available tools
taxonomy is also addressed by CRYSTAL PB approach and their functionalities, a PB user will be able to define the
where standardization and formalization of tools and tool- best SEE solution for the Tailored Process in the given
chain information and features is one of the major goals. context. The Validation phase facilitates the configuration of
Another example is the SafeCer project a consistent and usable SEE. In the validation phase the SEE
(http://www.safecer.eu), an ARTEMIS JU project, which configuration shall be adapted to satisfy requirements and
provides CTF (Certification Tool Framework) that is a constraints for instantiating the SEE on the company IT
software platform that aims to integrate the different tools in infrastructure, thus producing the optimal solution in the
a unique framework and allows building a tool-chain for provided company/organization context. Project data
certification purposes. encompasses all information to set-up the SEE for a specific
While SafeCER allows building a tool-chain for Tailored Process and project and it addresses mainly
certification purposes, the CRYSTAL PB Modeler allows information relevant to user management and product
instantiating and validating a SEE, that includes tool-chain, management.
IT infrastructure and data, dedicated to accomplish a
selected development process and it is based on tool
descriptors that formalize tool information within
CRYSTAL PB.
B. PB Approach Workflow
The PB approach is based on process activities definition
and relevant EM to be applied. Generally in a system life
cycle process, activities to be performed for developing a
system are defined together with work products to be
produced and roles skilled to perform activities. This
information is used by the PB approach to instantiate a SEE,
to support the identified process in terms of engineering Fig. 1. SEE configuration and instantiation workflow
methods selected for an identified use case context, and to
select proper tools to be used in the identified engineering C. PB Conceptual Meta-model
methods. This approach requires the definition of a proper Data and information, involved in the PB workflow, are
meta-model to facilitate the description of the process and represented in the PB conceptual meta-model (Fig. 2), where
for enabling the mapping between process activities, elements and their relationships for configuring the SEE are
engineering methods and functions provided by tools. While depicted. Some elements are aggregation of formalized data
a development process describes activities to be performed in and they are defined as catalogues: Activity catalogue,
an engineering process, engineering methods describe how Engineering Methods (EM) catalogue, Tool catalogue and
to perform the different activities addressing engineering tool Engineering Tool Functions (ETF) catalogue. All identified
functions to be applied. Fig. 1 shows the complete workflow,
catalogues were populated to be used in different PB phases.
identified in the CRYSTAL project, to configure and
Other PB elements specify data needed for PB method
instantiate a SEE. Actually the PB scope encompasses only
implementation. Herein each element of PB conceptual
three phases of the complete workflow and implemented in
meta-model is defined. The main input for PB Modeler is the
the PB Modeler solution. For each phase different inputs and
use case defining the project and the system to be developed
outputs are outlined:
in a defined business context. This includes also work
• Tailoring phase: where the development process is products and activities to be performed in respect of business
described and formalized generating the Tailored process and it is usually documented in natural language and
Process. not formalized. Use case information, relevant for the PB
scope, is formalized in a process, which describes activities,
• Configuring phase: where the tailored process is used roles, artifacts and engineering methods to be applied.
to select tools and configure the best-fit tool-chain.
Copyright © (2016) Leonardo-Finmeccanica S.P.A. & Instituto Tecnológico de Informática Permesso concesso a AISE di
pubblicare e utilizzare
The process, herein also called Tailored Process, is used collection of descriptors of tools and their relationships (tool-
to describe all activities and engineering methods to be chain) through interoperability. In this article,
applied for the business context and for the specific use case. interoperability stands for Interoperability Specification
An activity is a concrete work identified within a capability (IOS Capability) which is a specialization of ETF.
development process and it represents a general unit of work
assignable to specific user, with a role, able to perform it. An D. Process Activity and EM classification
activity is a set of actions that consume time and resources The tailored process has to be defined in order to
and whose performance is necessary to achieve, or contribute formalize the development process taking into account EMs
to, the realization of one or more outcomes (artefact). An to be applied during a system development. In the PB
activity depends on the identified system life cycle process method this tailoring phase is facilitated by categorization of
and it is specified within system development process. activities and EMs. Analyzing the needed information to be
Indeed Tailored Process specifies which activities are used for tailoring phase, the PB method has adopted the
selected for the specific use case, and the system Software & Systems Process Engineering Meta-Model
development process, indicated by the (SPEM) and identified some SPEM elements to formalize a
process in the PB scope using a reference method library [1].
The tailored process, defined as a delivery process,
encompasses activities, which groups EMs. Activities and
EM are related to task element in the SPEM meta-model.
The CRYSTAL reference method library includes
activities and engineering methods to be used during the
tailoring process phase. The activities and EMs
categorization was based on different domain use cases. The
difficulty to make this classification and definition depends
on the fact that the definition of activity is interpreted by
engineers. Basically, using the activity definition and the
SPEM task definition element, an activity is classified using
a name and a description [5], considering that an activity
describes a task to be performed within a system engineering
life cycle process. Also for EM classification (refer to Table
1) is used the SPEM task element but in this case to describe
Fig. 2. PB conceptual meta-model it, the EM definition is applied: an EM describes tasks to be
applied to satisfy an activity with support of tools.
use case, is tailored with selected activities and detailed with
Ems. While activity describes a task within a process, EM
specifies how the activity has to be performed and in detail it TABLE I. EM
describes a method which can accomplish a given identified Engineering Method Example
result by defining steps to perform it and also artefacts that
are produced or consumed. An Engineering method is Name Name of the EM as Insert Requirements
formalized using ETFs that should be applied to satisfy it. unique identifier.
On the other hand, a tool, that is any software application, (Verb + Object)
can be described through the functionalities that it provides.
Description Short description Identified requirements are
A set of tool’ functionalities, also said ETFs, are used to about the EM to be inserted and described into a
define a tool in a formalized way and this helps to select a applied. Requirements database.
tool to satisfy EMs.
Work Products List of Artefacts • Database-of- requirements
The core of the PB method is the mapping between (Artefacts) handled by EM.
• Textual-description
engineering methods and engineering tool functions. In order
to fulfil this mapping, the Engineering tool function Guidance Generic type of tool. Requirements repository tool
taxonomy is crucial. Indeed engineering method will be
Steps List of steps to • Create a new requirement
specified using engineering tool function as well, in this way perform the EM.
the mapping between engineering methods and engineering • Describe requirement
tool functions make semi-automatic the selection of tools.
Engineering tool function identification and categorization
was made in extensive but not exhaustive way in the Using this classification of activities and EMs a reference
CRYSTAL project. For different examined use cases, method library can be populated and it is considered as the
engineering tool functions were listed and formalized in ETF activity and EM catalogue.
catalogue to be recognized in the definition of Tool
Catalogue and EM catalogue. E. ETF taxonomy
The SEE model [4] is configured using both tool As anticipated in the PB conceptual meta-model
information and tailored process information, and it is a paragraph, the engineering tool function taxonomy is crucial
Copyright © (2016) Leonardo-Finmeccanica S.P.A. & Instituto Tecnológico de Informática Permesso concesso a AISE di
pubblicare e utilizzare
for the PB Modeler. To help a PB Modeler end user to functionalities and system requirements for its deployment in
configure a SEE, the selection of tools is facilitated through an informal way, through brochure or web site, and
the mapping between ETF provided by tools and those ETF sometimes Tool vendors provide a formal description using
required by engineering methods. manifest files. A tool descriptor collects in a formalized way
all needed information to describe and to characterize
An ETF is a detailed function of a task that will be software tool’s functionalities, system requirements and
performed by means of a tool. Analysing use-cases proposed extension relationships. This improves and facilitates the tool
in CRYSTAL and engineering methods, a sort of ETF selection based on a non-ambiguous functionality.
classification was identified. ETF has to be identified in a
unique way and it can be used in different tools and also
required by different engineering methods. Since a definition
of ETF is necessary, we have identified different data to be TABLE III. TOOL PROPERTIES
specified to characterize ETF, and Table 2 shows the main
Name Description
attributes to be specified. In the PB conceptual meta-model,
ETF are specialized as IOS capability and internal tool Id Unique identifier for the tool.
function. The difference between IOS capability and internal
Name Name of the Tool. Used for listing purposes.
tool function is the type of ETF: if it is a proper internal
function or if the function addresses interoperability with Version This field supports defining and distinguishing
another tool. An ETF is classified as internal tool function if between different versions of the same Tool.
it manages data and it is not related directly to adapt data to Vendor Identifier of the Vendor.
provide/consume to/from another tool. It is any functionality
provided by a tool that performs a functional operation Description Short description about the feature provided by this
within tool itself. Tool
Open-source Indicates if the Tool is open-source or not.
On the other hand, IOS capability is a ETF that
implements interoperability with a different tool, in order to License Type of license
adapt data, to be provided or consumed, and that will be
Extended-by This field is used when the vendor of a tool knows that
managed by another tool. Every type of interoperability this tool is extended by another. Used for stating the
between tools can be considered and interoperability use of IOS adapters (IOS service).
specification can be defined for each kind of tool. Within the
CRYSTAL project, IOS is referring Open Services for Extends This field is used when the vendor of a tool knows that
this tool extends the features of other tools. Used for
Lifecycle Collaboration (OSLC) specification [3]. stating the use of IOS adapters (IOS service).
SW-functions List of ETFs provided by this tool (Internal tool
TABLE II. ETF ATTRIBUTES function).
Name Description IT-requirement Specifies the IT requirements of the tool.
ID Unique identifier for the ETF
Name Name of the ETF A software component is defined to describe any kind of
Description Short description about the ETF. software, both system or application software: tool
application, database, server, adapter, service, and so on. A
Type This field states if this ETF is an IOS service or an internal generic software component represents information to
tool function.
identify any software implementation to be installed in a
Artefacts Specify artefacts handled by ETF computer machine.
Tool-class Tools that can provide this ETF
F. Tool and Tool-chain Taxonomy
In the PB scope, tool properties formalization is
important to facilitate tool selection. Indeed in configuring
phase, tools that fit the EM requirements are presented and
an end-user is able to select a suitable solution. Tool
selection facility based on EM coverage, needs the tool
categorization based on ETF classification. Different
properties to describe a tool are listed in Table 3.
The formalization of a software tool based on ETFs shall
be represented as a generic software (SW) component of
tool-chain, refer to Fig. 3, where elements’ relationships are
depicted. Often, tool vendors give an overview of tools’
Copyright © (2016) Leonardo-Finmeccanica S.P.A. & Instituto Tecnológico de Informática Permesso concesso a AISE di
pubblicare e utilizzare
Fig. 4. SEE meta-model
In the SEE model, the tool-chain associated to the
process is the main information. In the configuration phase,
the tools selection is based on some required constraints that
can be technical or business constraints. Technical
constraints are relevant to tool characteristics, such as
provided ETFs (IOS and internal tool functions), and IT
constraints, such as availability of machines and network for
SEE deployment and installation requirements (system
requirements). Business constraints are relevant to the type
of contract, if there exists, with Tool Vendor and company,
the specific Tool type of contract: such as type of license,
maximum number of users, and duration of contract.
Technical and Business constraints are used in the PB
Modeler to support tools selection in order to configure and
validate the SEE model.
Fig. 3. Tool descriptor as a generic SW Component III. PLATFORM BUILDER MODELER
The PB Modeler is the implemented solution of
G. SEE Meta-model described PB methodology based on EPF Composer, for
The PB approach mainly addresses the instantiation of a authoring the process using SPEM language, and some
SEE which is configured through the PB Modeler tool based added plugins to configure and validate the SEE.
on, and extending Eclipse Process Framework Composer
(EPF) [2]. All the needed information have to be described A. Core Features
and formalized as specified by the PB approach in order to Core features correspond to the main features of the PB
make the SEE configuration feasible in a semi-automatic and Modeler tool implemented to address the PB workflow:
assisted way.
The SEE is a set of information that specifies: which 1. Tailor the process;
process is used for system development, which engineering 2. Configure the SEE;
methods are applied within the selected process, which
software tools and their characteristics are foreseen for the 3. Validate the SEE;
needed and identified tool-chain links to satisfy engineering 4. Generate the description of the SEE.
methods. All these information are collected and specified in
the SEE meta-model as shown in Fig. 4. A SEE model is the
result of grouping and relating selected information from
identified catalogues. 1) Tailor the process
This feature allows defining the resources that are needed
for describing the development process, tailored for the
specific use case. This is done using a graphical user
interface to add data that encompass the PB meta-model for
covering the relevant aspects. The PB meta-model
specification is based on the SPEM meta-model, from which
it selects relevant concepts for the Business Process, and it is
enriched by concepts that are relevant to the SEE needs. This
phase includes:
• The definition of activities sequence and activities
themselves,
• The definition of work products,
• The definition of roles to perform activities and
• The application of engineering methods (EM) to
perform an activity.
Generally these functionalities are already provided by a
process authoring tool, nevertheless what is missing is a
guideline and ontology to properly define activities and also
engineering methods in a standard way. To facilitate the
Copyright © (2016) Leonardo-Finmeccanica S.P.A. & Instituto Tecnológico de Informática Permesso concesso a AISE di
pubblicare e utilizzare
tailoring phase using an authoring tool, a CRYSTAL tool-chain and services to be deployed in the selected IT
Reference Library was defined, containing at least the infrastructure. Project data useful to set-up the SEE will be
ontology about process activities (activity catalogue) and generated starting from the required data infrastructure.
also for standardization of other meta-model identified Project data includes repository information and user
elements, such as roles, work products and engineering management information.
methods (EM catalogue). The tailored process is the output
of this phase and it is the main input of the following B. Additional features of PB
configuration phase. The PB is mainly used for providing a model of a SEE,
based on process activities to be performed in a product
2) Configure the SEE development. In addition to core functionalities, some
The configuration phase groups all the functionalities that features were as well implemented since they are
are necessary to formalize a SEE. This requires the enriched propaedeutic to the Platform Builder goal. Indeed, such
meta-model that includes the elements that are needed for additional features produce outputs (EM, ETF and Tool
defining a tool-chain, interoperability aspects and the catalogues, and also company IT infrastructure description)
deployment environment that is addressed in the IT that are necessary as inputs to the different PB phases:
infrastructure definition. The tool-chain is composed by • Manage the Tool Catalogue: create a catalogue and
software tools and the IT infrastructure is composed by describe tools in the catalogue applying the tool
network set-up, repositories and services that are the descriptor meta-model and tool properties.
backbone for the selected tools. This phase includes the
following functionalities: • Manage the IT infrastructure: describe the IT
infrastructure as it is currently in the company
• Import a tailored process (the tailored process as (available IT infrastructure) using the proper meta-
defined in the tailoring phase is used as input); model.
• Describe the general tool-chain in terms of tool • Manage stakeholders: describe users and roles of the
function properties and IOS properties; company’s employees.
• Select tools, available tools in the business domain; • Manage ETF and EM catalogues thought respective
• Specify the IT infrastructure; identified meta-models.
• Define repositories for the work products (data C. Operational View
structure).
In this section, tailoring, configuration and validation
3) Validate the SEE phases are detailed in order to describe user’s operations. As
depicted in Fig. 5, each identified phase in PB workflow
The validation of the SEE is performed on the configured depends on the previous phase: for example configuring
environment that includes the tool-chain and the IT phase depends on the tailoring phase which means that in
infrastructure and project data. In order to validate the order to configure the SEE, the Tailored Process has to be
configured tool-chain, the following inputs are required: available before starting the configuration phase.
• the IT infrastructure as currently available in the Furthermore the validation phase depends on the result of
company and defined using the PB meta-model; configuration phase, because validation is done on the
configured SEE. A Process Architect is in charge of tailoring
• a selection of tools in the catalogue as available in the the process activities and it has knowledge on its company
company (available tools). business domain, while a SEE Architect is in charge of
The validation considers the tool-chain adaptability configuring the SEE and it has mainly knowledge on
against the existing IT infrastructure, the evaluation of tools information technology department.
availability, and checking that defined IOS links are valid.
The SEE has to be validated taking into account also the
technological and business constraints (specific constraints
on allowed vendors, standards, license type and if needed
cost, in order to validate the data infrastructure, it is required
to have the defined data structure in terms of work products
and relevant repositories and to check its compatibility on
the available IT infrastructure; e.g. the user management
information includes the maximum number of users and
which users are able to manage data, check the repository
configuration and the network accessibility.
4) Generate the description of the SEE
After the validation, a SEE descriptor is generated. Such
descriptor is a model and it contains information about the
Copyright © (2016) Leonardo-Finmeccanica S.P.A. & Instituto Tecnológico de Informática Permesso concesso a AISE di
pubblicare e utilizzare
Fig. 6. UML use case diagram of tailoring a process
In order to facilitate the steps of the tailoring phase, it is
necessary to provide a catalogue for each kind of identified
elements in the process definition (such as process activity
and roles) in a standardized way, and this is accomplished in
the CRYSTAL reference library that specify an activity
catalogue. Furthermore, an improvement concerns the
Fig. 5. UML use case diagram of PB definition of a catalogue of EMs to be applied. Generally,
authoring tools provide interfaces to describe the product
The manage Library use case is a pre-tailoring phase. It development process, but the Process Architect needs also
is part of authoring phase in order to prepare the CRYSTAL guidelines to perform this task and information that can help
reference Library where are defined generic catalogues for to describe the process. Tailoring steps could be based on
activities and engineering methods. already existing authoring tools, extending them with the
1) Tailoring the process catalogue that define some needed elements addressed in the
process. User interfaces, that should be defined to author a
This phase is intended to describe all the tasks needed to product development process covering also aspects relevant
tailor the process in terms of operations to perform. Tasks to to SEE configuration, will be used to describe:
be performed are relevant to the description of a
development process and to manage information in a • Activities of the process and relevant elements
formalized way to be used to configure the SEE. In Fig. 2 • Engineering methods to be applied.
tailoring phase side, there are elements to define a
development process using information of a process for 2) Configuring the Platform
developing a given product in a defined CRYSTAL use case.
This phase encompasses all the tasks to be done by the
The Process Architect has to describe the development
SEE Architect for configuring the SEE in terms of operations
process and apply EMs during the tailoring process phase.
to be performed. In Fig. 2 configuration phase side, there are
To facilitate this task, when using a process authoring tool,
all the elements and their relationships. The configuring
process guidance, activities catalogue and EM catalogue are
phase is the core of PB method in terms of functionalities to
provided. During the tailoring phase, the following steps
describe the SEE. Basically, it is centred on the creation of a
have to be performed:
new SEE model related to a Tailored Process. After this step,
• definition of the sequence of the process activities as the SEE Architect is able to configure the tool-chain (refer to
well as the activities themselves; Fig. 7) for each selected EM that is defined in the Tailored
Process. This tool-chain configuration is based on mapping
• definition of roles to perform activities; between EMs and ETFs and then between ETFs and tools
• definition of engineering methods applied to the which support identified ETFs. A SEE Architect has to select
process. tools in order to satisfy the process activities and the applied
EMs This task is supported by the ETF Catalogue and the
Any process authoring tool has to provide at least these Tool Catalogue. Furthermore, it has to describe the IT
steps that are also depicted in Fig. 6. infrastructure (configure IT infrastructure use case) and
formalize project data (configure project data use case)
dealing with development process work products and
roles/users of SEE. In the configuration phase the following
activities have to be performed:
• Assign to the EM used in each process activity of the
Tailored Process the required ETFs (IOS capability
Copyright © (2016) Leonardo-Finmeccanica S.P.A. & Instituto Tecnológico de Informática Permesso concesso a AISE di
pubblicare e utilizzare
and internal ETF). This maps each EM to as many as
required ETFs (map EM to ETFs use case)
• Select tools that will provide the ETF, thus becoming
part of the tool-chain; the tool will be selected from
the Tool Catalogue (select Tool use case)
• Establish the Tool interconnections (through IOS
capabilities) in order to establish the needed tool
interactions.
• Define the IT infrastructure needed for the tool-chain
deployment, deriving it from the tools being used,
foreseen users and needed services.
• Specify the permissions over the artefacts that each Fig. 8. Configuring IT infrastructure
role has in each tool.
3) Validate the SEE configuration
In order to validate the SEE configuration that satisfies
the development process objectives, the validation phase
consists mainly in validating the tool-chain by comparing it
with some criteria imposed by:
• the tailored process
• IT requirements and data infrastructure,
• Technological and business constraints such as
applicable standards, specific constraints on
allowed vendors, licence types and cost.
The SEE configuration validation could be implicitly
made during the tool selection. Indeed some filter criteria can
be applied to Tool Catalogue to propose a sub-set of tools
that satisfy such criteria. For example, availability, license
type and cost are filter criteria applicable to Reference
Fig. 7. Configuring the tool-chain Technological Platform (RTP) Tool Catalogue. Furthermore,
IOS services coherence and IT infrastructure adaptability are
Once this process is finished, the SEE Architect has validation criteria. The following figure shows validation
defined the tool-chain that will be used in the product tasks in order to validate the SEE configuration.
development process and the IT infrastructure needs. IT
infrastructure identification depends on selected tools to
build-up a tool-chain, and some IT infrastructure properties
could be described implicitly in Tool Descriptors. Fig. 8
shows what has to be identified for the IT infrastructure
definition. IT infrastructure deals with all needed elements to
build-up the backbone of the tool-chain and it encompasses
services, repositories, network properties and user
management.
The Data Structure identification, Fig. 5, depends on
Artefacts required by the development process and it could
be a simple list of Artefacts or more complex data structure.
Data structure deals with work products involved in the
process activities and project data includes data structure and
also other information about roles/users and relevant
properties to define access constraints, servers, repositories
Fig. 9. UML Use Case diagram - Validation
and also network information. For preparing project data, the
SEE Architect needs information on IT infrastructure such as
The validation of a configured SEE implies:
selected repositories and user access constraints.
• checking tool availability, which means selected
tools are present and available in the company to
deploy the tool-chain.
Copyright © (2016) Leonardo-Finmeccanica S.P.A. & Instituto Tecnológico de Informática Permesso concesso a AISE di
pubblicare e utilizzare
• checking the IOS services coherence: verifying that REFERENCES
tool-chain links are valid.
• adapting, if necessary, the IT Infrastructure within [1] Object Management Group, "Software & Systems Process Engineering
Meta-Model Specification Version 2.0," 1 April 2008. [Online]. Available:
the company organization: compare the required IT http://www.omg.org/spec/SPEM/2.0/PDF. [Accessed 30 March 2015].
infrastructure’s properties against the existing [2] The Eclipse Foundation, “Eclipse Process Framework Project (EPF),”
company’s IT Infrastructure. 2015. [Online]. Available: http://eclipse.org/epf/.
[3] OSLC, “Open Services for Lifecycle Collaboration,” 2015. [Online].
4) Generate the description of SEE Available: http://open-services.net/.
[4] “CRYSTAL deliverable - Meta-model specification - V2,” 2015.
After these configuration and validation phases, the [Online].
configured and validated SEE is the output that basically is a [5] “CRYSTAL deliverable – Platform Builder specification - V2,” 2016.
model to describe the configuration to be instantiated. The [Online].
PB generates as output model the SEE configuration [6] “CRYSTAL deliverable – Platform Builder prototype - V2,” 2016.
descriptor, which includes the tool-chain descriptor, the IT [Online].
infrastructure descriptor and also a description of Project [7] DevOps - toolchain group http://code.google.com/p/devops-toolchain/
data.
IV. CONCLUSIONS
This paper describes the implemented Platform Builder
method including identified and formalized meta-models for
those relevant elements needed for SEE instantiation. It also
describes the PB Modeler, that is a software tool that allows
formalizing development processes and assisting SEE
instantiation, which includes both process and tools
information (such as Reference Technology Platform
components). More in detail, the SEE model includes
information related to:
• the required tools for the design of the desired
product
• the Information Technology (IT) infrastructure
where these tools are to be deployed
• data to be manipulated during the product
development process.
The presented solution has been validated on many
CRYSTAL industrial scenarios and it proven to be able to
allow cost and complexity reduction for the activity of
selecting the proper SEE for a given development process.
ACKNOWLEDGMENT
The research leading to these results has received funding
from the research project CRYSTAL (Critical System
Engineering Acceleration), funded from the ARTEMIS
Joint Undertaking under grant agreement n. 332830 and
from ARTEMIS member states Austria, Belgium, Czech
Republic, France, Germany, Italy, Netherlands, Spain,
Sweden, United Kingdom.
We would also like to thank our CRYSTAL partners among
whom Pietro Braghieri (FBK), Luis Andreu (ITI),
Guilherme Baungarten (OFFIS), whose active participation
and collaboration in PB related subjects were essential for
the achievement of the results.
Copyright © (2016) Leonardo-Finmeccanica S.P.A. & Instituto Tecnológico de Informática Permesso concesso a AISE di
pubblicare e utilizzare