Capturing variability in Model Based Systems Engineering

International audienceAutomotive model-based systems engineering needs to be dapted to the industry specific needs, in particular by implementing appropriate means of representing and operating with variability. We rely on existing modeling techniques as an opportunity to provide a description of variability adapted to a systems en- gineering model. However, we also need to take into account requirements related to backwards compatibility with current practices, given the industry experience in mass customization. We propose to adopt the product line paradigm in model-based systems engineering by extending the orthogonal variability model, and adapting it to our specific needs. This brings us to an expression closer to a description of constraints, related to both orthogonal variability, and to SysML system models. We introduce our approach through a discussion on the different aspects that need to be covered for expressing variability in systems engineering. We explore these aspects by observing an automotive case study, and relate them to a list of contextual requirements for variability management

Relationship of Genotype, Phenotype, and Treatment in Dopa-Responsive Dystonia: MDSGene Review

Background Pathogenic variants in 5 genes (GCH1, TH, PTS, SPR, and QDPR), involved in dopamine/tetrahydrobiopterin biosynthesis or recycling, have been linked to Dopa-responsive dystonia (DRD). Diagnosis and treatment are often delayed due to high between- and within-group variability. Objectives Comprehensively analyzed individual genotype, phenotype, treatment response, and biochemistry information. Methods 734 DRD patients and 151 asymptomatic GCH1 mutation carriers were included using an MDSGene systematic literature review and an automated classification approach to distinguish between different forms of monogenic DRDs. Results Whereas dystonia, L-Dopa responsiveness, early age at onset, and diurnal fluctuations were identified as red flags, parkinsonism without dystonia was rarely reported (11%) and combined with dystonia in only 18% of patients. While sex was equally distributed in autosomal recessive DRD, there was female predominance in autosomal dominant DYT/PARK-GCH1 patients accompanied by a lower median age at onset and more dystonia in females compared to males. Accordingly, the majority of asymptomatic heterozygous GCH1 mutation carriers (>8 years of age) were males. Multiple other subgroup-specific characteristics were identified, showing high accuracy in the automated classification approach: Seizures and microcephaly were mostly seen in DYT/PARK-PTS, autonomic symptoms appeared commonly in DYT/PARK-TH and DYT/PARK-PTS, and sleep disorders and oculogyric crises in DYT/PARK-SPR. Biochemically, homovanillic acid and 5-hydroxyindoleacetic acid in CSF were reduced in most DRDs, but neopterin and biopterin were increased only in DYT/PARK-PTS and DYT/PARK-SPR. Hyperphenylalaninemia was seen in DYT/PARK-PTS, DYT/PARK-QDPR, and rarely reported in autosomal recessive DYT/PARK-GCH1. Conclusions Our indicators will help to specify diagnosis and accelerate start of treatment. © 2021 The Authors. Movement Disorders published by Wiley Periodicals LLC on behalf of International Parkinson and Movement Disorder Societ

Process Line Configuration: an Indicator-based Guidance of the Intentional Model MAP

International audienceVariability has proved to be a central concept in different engineering domains to develop solutions that can be easily adapted to different organizational settings and different sets of customers at a low price. The MAP formalism has a high level of variability as it is expressed in an intentional manner through goals and strategies. However, a high level of variability means a high number of variation points. A process customization is then required to offer a better guidance. The Product lines have appeared with this management of variability and customization. Furthermore, we propose the Process line concept to represent the processes that may be customized to a given project. Our goal is to enhance the Map guidance by specifying the MIG (Map Indicator-based Guidance) approach. We suggest several guidance approaches based on an indicators' typology. We illustrate our proposal with an example from the requirement engineering field

Challenges and industry practices for managing software variability in small and medium sized enterprises

Software variability is an ability to change (configure, customize, extend) software artefacts (e.g. code, product, domain requirements, models, design, documentation, test cases) for a specific context. Optimized variability management can lead a software company to 1) shorter development lead time, 2) improved customer and improved user satisfaction, 3) reduced complexity of product management (more variability, same $) and 4) reduced costs (same variability, less$). However, it is not easy for software companies, especially small and medium size of enterprises to deal with variability. In this paper we present variability challenges and used practices collected from five SMEs. Our study indicates that increased product complexity can lead growing SMEs to the time-consuming decision-making. Many of the analyzed medium size of companies also expect improved tool support to help them to boost their productivity when managing increasingly complex products and increasing amount of variants In fact, in many of the analysed SMEs, a high level of automation in design, release management and testing are or become a key factor for market success By introducing the challenges and used practices related to variability the paper deepens understanding of this highly relevant but relatively under-researched phenomenon and contributes to the literature on software product line engineering

Capturing product line information from legacy user documentation

The development of a software product line is seldom a green field task. Legacy systems exist that serve as an information source or that should be integrated into a product line. The information needed is usually elicited interactively with high involvement by the domain experts of the application domain. As domain experts have a high workload and are often unavailable, relying primarily on high expert involvement is a risk for the successful introduction of a product line engineering approach into an organization. This chapter presents an approach for the extraction of requirements from user documentation, which gives guidance on how to elicit knowledge from existing user documentation and how to transform information from this documentation into product line models. This approach is called the PuLSE-Framework for product line engineering. We describe the metamodel that is the basis of the approach, the extraction patterns that are derived from the metamodel, and the process that guides the application of the patterns and the derivation of information relevant for building a product line. This information can be features of legacy products, parts of use cases that can be used for product line analysis, different kinds of requirements and, most important forproduct line engineering, commonalities and variabilities among existing products. With thehelp of this information, a product line model with the product line requirements can be builtmuch faster and the workload of the domain experts is significantly reduced. We performedan initial validation of the approach in industrial case studies and in a controlled experiment