Spelling suggestions: "subject:"bproduct line engineering"" "subject:"bproduct line ingineering""
1 |
Optimization techniques for enhancing middleware quality of service for software product-line architecturesKrishna, Arvind S., January 1900 (has links)
Thesis (Ph. D. in Computer Science)--Vanderbilt University, Dec. 2005. / Title from title screen. Includes bibliographical references.
|
2 |
Towards an agile product line requirements engineering frame work : knowledge acquisition and process definition /Feng, Kunwu, January 2009 (has links)
Thesis (Ph.D.)--University of Texas at Dallas, 2009. / Includes vita. Includes bibliographical references (leaves 224-234)
|
3 |
A methodology for risk assessment of product line architecturesJalali, Amir H. January 1900 (has links)
Thesis (M.S.)--West Virginia University, 2008. / Title from document title page. Document formatted into pages; contains xi, 126 p. : ill. (some col.). Includes abstract. Includes bibliographical references (p. 121-126).
|
4 |
A Software Product Line Engineering Approach to Building A Modeling and Simulation as a Service (M&SaaS) Application StoreDiwan, Piyush D. January 2013 (has links)
No description available.
|
5 |
A component-based approach to modelling software product families with explicit variation pointsDi Cola, Simone January 2017 (has links)
In software product line engineering, the construction of an architecture for a product family is still an outstanding engineering challenge. In current practice, a framework is used for configuring individual products by combining solution space artefacts into products with specified features according to a feature model. No architectures are created. In contrast, an architecture for a product family would define the architectures for all the products in the family, allowing engineers to reason at a higher level of abstraction. In this thesis, we present a component model that can be used to define architectures for product families, by incorporating explicit variation points.
|
6 |
Paan : a tool for back-propagating changes to projected documentsKim, Jongwook 08 July 2011 (has links)
Research in Software Product Line Engineering (SPLE) traditionally focuses on product derivation. Prior work has explored the automated derivation of products by module composition. However, it has so far neglected propagating changes (edits) in a product back to the product line definition. A domain-specific product should be possible to update its features locally, and later these changes should be propagated back to the product line definition automatically. Otherwise, the entire product line has to be revised manually in order to make the changes permanent. Although this is the current state, it is a very error-prone process. To address these issues, we present a tool called Paan to create product lines of MS Word documents with back-propagation support. It is a diff-based tool that ignores unchanged fragments and reveals fragments that are changed, added or deleted. Paan takes a document with variation points (VPs) as input, and shreds it into building blocks called tiles. Only those tiles that are new or have changed must be updated in the tile repository. In this way, changes in composed documents can be back-propagated to their original feature module definitions. A document is synthesized by retrieving the appropriate tiles and composing them. / text
|
7 |
QOSPL a quality of service-driven software product line engineering framework for design and analysis of component-based distributed real-time and embedded systems /Liu, Shih-hsi. January 2007 (has links) (PDF)
Thesis (Ph. D.)--University of Alabama at Birmingham, 2007. / Additional advisors: Jeff G. Gray, Marjan Mernik, Rajeev Raje, Chengcui Zhang. Description based on contents viewed Feb. 7, 2008; title from title screen. Includes bibliographical references (p. 216-230).
|
8 |
Investigating styles in variability modeling: Hierarchical vs. constrained stylesReinhartz-Berger, Iris, Figl, Kathrin, Haugen, Øystein 07 1900 (has links) (PDF)
Context: A common way to represent product lines is with variability modeling. Yet, there are different ways to extract and organize relevant characteristics of variability. Comprehensibility of these models and the ease of creating models are important for the efficiency of any variability management approach.
Objective: The goal of this paper is to investigate the comprehensibility of two common styles to organize variability into models - hierarchical and constrained - where the dependencies between choices are specified either through the hierarchy of the model or as cross-cutting constraints, respectively.
Method: We conducted a controlled experiment with a sample of 90 participants who were students with prior training in modeling. Each participant was provided with two variability models specified in Common Variability Language (CVL) and was asked to answer questions requiring interpretation of provided models. The models included 9 to 20 nodes and 8 to 19 edges and used the main variability elements. After answering the questions, the participants were asked to create a model based on a textual description.
Results: The results indicate that the hierarchical modeling style was easier to comprehend from a subjective point of view, but there was also a significant interaction effect with the degree of dependency in the models, that influenced objective comprehension. With respect to model creation, we found that the use of a constrained modeling style resulted in higher correctness of variability models.
Conclusions: Prior exposure to modeling style and the degree of dependency among elements in the model determine what modeling style a participant chose when creating the model from natural language descriptions. Participants tended to choose a hierarchical style for modeling situations with high dependency and a constrained style for situations with low dependency. Furthermore, the degree of dependency also influences the comprehension of the variability model.
|
9 |
An investigation into the application of systematic software reuse in a project-centric organisationChapman, Mark Jonathon 31 January 2007 (has links)
The software development continues to become more competitive and demanding, placing pressure on developers. Changes in the international political climate have resulted in shrinking military budgets, putting developers of defence software under further pressure. At present, systematic reuse is probably the most realistic way of addressing this pressure by improving software development productivity and quality. Software product line (SPL) engineering provides a comprehensive approach to systematic software reuse and is becoming widely accepted.
The focus of this interpretive case study was ground station software development in a small multidisciplinary project-centric company which produces avionics systems for military aircraft. The purpose of the study was to investigate the potential implementation of systematic software reuse in the company.
The study consisted of three phases, a literature study, a contextualisation and a set of field interviews, and used elements of the Carnegie-Mellon Software Engineering Institute (SEI) Product Line Practice Framework to examine the suitability of SPL engineering for the company.
The findings of the study highlight the potential challenges that SPL engineering poses for the company, and emphasise how the company's project-centric structure could impede its implementation of systematic software reuse. / Computing / M.Sc. (Information Systems)
|
10 |
Modelling and Reasoning with Software Product Lines with Design ChoicesKaur, Navpreet 03 1900 (has links)
No description available.
|
Page generated in 0.0897 seconds