18 research outputs found
Recommended from our members
Creating product line architectures
The creation and validation of product line software architectures are inherently more complex than those of software architectures for single systems. This paper compares a process for creating and evaluating a traditional, one-of-a- kind software architecture with one for a reference software architecture. The comparison is done in the context of PuLSE-DSSA, a customizable process that integrates both product line architecture creation and evaluation
Recommended from our members
Implementation issues in product line scoping
Often product line engineering is treated similar to the waterfall model in traditional software engineering, i.e., the different phases (scoping, analysis, architecting, implementation) are treated as if they could be clearly separated and would follow each other in an ordered fashion. However, in practice strong interactions between the individual phases become apparent. In particular, how implementation is done has a strong impact on economic aspects of the project and thus how to adequately plan it. Hence, assessing these relationships adequately in the beginning has a strong impact on performing a product line project right. In this paper we present a framework that helps in exactly this task. It captures on an abstract level the relationships between scoping information and implementation aspects and thus allows to provide rough guidance on implementation aspects of the project. We will also discuss the application of our framework to a specific industrial project
A Component Based Approach to Scientific Workflow Management
CRISTAL is a distributed scientific workflow system used in the manufacturing and production phases of HEP experiment construction at CERN. The CRISTAL project has studied the use of a description driven approach, using meta- modelling techniques, to manage the evolving needs of a large physics community. Interest from such diverse communities as bio-informatics and manufacturing has motivated the CRISTAL team to re-engineer the system to customize functionality according to end user requirements but maximize software reuse in the process. The next generation CRISTAL vision is to build a generic component architecture from which a complete software product line can be generated according to the particular needs of the target enterprise. This paper discusses the issues of adopting a component product line based approach and our experiences of software reuse
Domain-specific languages
Domain-Specific Languages are used in software engineering in order to enhance quality, flexibility, and timely delivery of software systems, by taking advantage of specific properties of a particular application domain. This survey covers terminology, risks and benefits, examples, design methodologies, and implementation techniques of domain-specific languages as used for the construction and maintenance of software systems. Moreover, it covers an annotated selection of 75 key publications in the area of domain-specific languages
APPLYING THE ISO/IEC 26550 AND ISO/IEC 26551 STANDARDS TO INCORPORATE THE QUALITY OF THE SOFTWARE IN A PRODUCT LINE
The Software Product Line (SPL) is geared toward large-scale reuse of software artifacts and components, productivity, cost reduction and time to market, and to improve quality. It based on two processes, domain engineering and application engineering. Before the diffusion of the series of own ISO standards to SPL, the engineering of the domain was formed by the analysis disciplines, design and implementation of the domain. However, in the ISO/IEC 26550 standard a new reference model is defined in which domain analysis is replaced by the scope of the SPL and domain requirements engineering. On the other hand, the ISO/IEC 26551 standard defines the reference model for the requirements engineering of SPL structured in five processes, the scope of the SPL is one of them and the first one to be considered in the development of SPL. In addition, in one of the scope of the SPL activities, it specified that the quality of the product must be considered. In this sense, this work proposes to incorporate the obtaining of the domain quality model of the SPL, which provides information on the software quality of any product. The quality model of the domain is obtained using the ISO/IEC 25010 standard. The artifacts that are built, relative to product quality, will be part of the product portfolio artifact, result of the scope of the product.La Línea de Productos de Software (LPS), está orientada a la reutilización a gran escala de artefactos y componentes de software, productividad, reducción de costos y tiempo de comercialización, y a mejorar la calidad. Se basa en dos procesos, la ingeniería del dominio y la ingeniería de la aplicación. Antes de la difusión de la serie de estándares ISO propios a una LPS, la ingeniería del dominio estaba formada por las disciplinas análisis, diseño e implementación del dominio. Sin embargo, en el estándar ISO/IEC 26550 se define un nuevo modelo de referencia en el cual el análisis del dominio es sustituido por el alcance de la LPS y la ingeniería de requisitos del dominio. Por otra parte, en el estándar ISO/IEC 26551 se define el modelo de referencia para la ingeniería de requisitos de una LPS estructurado en cinco procesos, el alcance de la LPS es uno de ellos y el primero que debe ser considerado en el desarrollo de una LPS. Además, en una de las actividades del alcance de la LPS, se especifica que debe ser considerada la calidad del producto. En tal sentido, este trabajo propone incorporar la obtención del modelo de calidad del dominio de la LPS, que proporcione información sobre la calidad de software de cualquier producto. El modelo de calidad del dominio se obtiene haciendo uso del estándar ISO/IEC 25010. Los artefactos que se construyen, relativos a la calidad del producto, formarán parte del artefacto portafolio del producto, resultado del alcance del producto.