To see the other types of publications on this topic, follow the link: Software product line scoping.

Journal articles on the topic 'Software product line scoping'

Create a spot-on reference in APA, MLA, Chicago, Harvard, and other styles

Select a source type:

Consult the top 50 journal articles for your research on the topic 'Software product line scoping.'

Next to every source in the list of references, there is an 'Add to bibliography' button. Press on it, and we will generate automatically the bibliographic reference to the chosen work in the citation style you need: APA, MLA, Harvard, Chicago, Vancouver, etc.

You can also download the full text of the academic publication as pdf and read online its abstract whenever available in the metadata.

Browse journal articles on a wide variety of disciplines and organise your bibliography correctly.

1

John, Isabel. "Using Documentation for Product Line Scoping." IEEE Software 27, no. 3 (2010): 42–47. http://dx.doi.org/10.1109/ms.2010.34.

Full text
APA, Harvard, Vancouver, ISO, and other styles
2

Marchezan, Luciano, Elder Rodrigues, Wesley Klewerton Guez Assunção, Maicon Bernardino, Fábio Paulo Basso, and João Carbonell. "Software product line scoping: A systematic literature review." Journal of Systems and Software 186 (April 2022): 111189. http://dx.doi.org/10.1016/j.jss.2021.111189.

Full text
APA, Harvard, Vancouver, ISO, and other styles
3

LEE, JIHYUN, SUNGWON KANG, and DANHYUNG LEE. "A COMPARISON OF SOFTWARE PRODUCT LINE SCOPING APPROACHES." International Journal of Software Engineering and Knowledge Engineering 20, no. 05 (2010): 637–63. http://dx.doi.org/10.1142/s021819401000489x.

Full text
Abstract:
During the past decade a number of methods and techniques for software product line scoping have been developed. Although their basic goal is the same, when it comes to details it is often hard to see what they have in common, where they differ and what their strengths and weaknesses are. This makes it difficult for the user to decide when and how to use them because these methods and techniques sometimes describe the same concepts and activities with different terminologies and, more often than not, by that the activities and tasks defined in them do not exactly match with each other and their inputs/outcomes are not clearly defined. In this paper, we compare and analyze the mainstream approaches to software product line scoping, deduce their essential components and develop them into a unified approach that can be easily referred to and utilized by the user companies planning to launch product lines.
APA, Harvard, Vancouver, ISO, and other styles
4

Karimpour, Reza, and Guenther Ruhe. "Evolutionary robust optimization for software product line scoping: An explorative study." Computer Languages, Systems & Structures 47 (January 2017): 189–210. http://dx.doi.org/10.1016/j.cl.2016.07.007.

Full text
APA, Harvard, Vancouver, ISO, and other styles
5

da Silva, Ivonei Freitas, Paulo Anselmo da Mota Silveira Neto, Pádraig O’Leary, Eduardo Santana de Almeida, and Silvio Romero de Lemos Meira. "Software product line scoping and requirements engineering in a small and medium-sized enterprise: An industrial case study." Journal of Systems and Software 88 (February 2014): 189–206. http://dx.doi.org/10.1016/j.jss.2013.10.040.

Full text
APA, Harvard, Vancouver, ISO, and other styles
6

Faisal, Sadaf, Devine Samoth, Yusra Aslam, et al. "Key Features of Smart Medication Adherence Products: Updated Scoping Review." JMIR Aging 6 (December 19, 2023): e50990. http://dx.doi.org/10.2196/50990.

Full text
Abstract:
Background Older adults often face challenges in self-managing their medication owing to physical and cognitive limitations, complex medication regimens, and packaging of medications. Emerging smart medication dispensing and adherence products (SMAPs) offer the options of automated dispensing, tracking medication intake in real time, and reminders and notifications. A 2021 review identified 51 SMAPs owing to the rapid influx of digital technology; an update to this review is required. Objective This review aims to identify new products and summarize and compare the key features of SMAPs. Methods Gray and published literature and videos were searched using Google, YouTube, PubMed, Embase, and Scopus. The first 10 pages of Google and the first 100 results of YouTube were screened using 4 and 5 keyword searches, respectively. SMAPs were included if they were able to store and allowed for the dispensation of medications, tracked real-time medication intake data, and could automatically analyze data. Products were excluded if they were stand-alone software applications, not marketed in English, not for in-home use, or only used in clinical trials. In total, 5 researchers independently screened and extracted the data. Results This review identified 114 SMAPs, including 80 (70.2%) marketed and 34 (29.8%) prototypes, grouped into 15 types. Among the marketed products, 68% (54/80) were available for consumer purchase. Of these products, 26% (14/54) were available worldwide and 78% (42/54) were available in North America. There was variability in the hardware, software, data collection and management features, and cost of the products. Examples of hardware features include battery life, medication storage capacity, availability of types and number of alarms, locking features, and additional technology required for use of the product, whereas software features included reminder and notification capabilities and availability of manufacturer support. Data capture methods included the availability of sensors to record the use of the product and data-syncing capabilities with cloud storage with short-range communications. Data were accessible to users via mobile apps or web-based portals. Some SMAPs provided data security assurance with secure log-ins (use of personal identification numbers or facial recognition), whereas other SMAPs provided data through registered email addresses. Although some SMAPs were available at set prices or free of cost to end users, the cost of other products varied based on availability, shipping fees, and subscription fees. Conclusions An expanding market for SMAPs with features specific to at-home patient use is emerging. Health care professionals can use these features to select and suggest products that meet their patients’ unique requirements.
APA, Harvard, Vancouver, ISO, and other styles
7

Pohl, Klaus, and Andreas Metzger. "Software product line testing." Communications of the ACM 49, no. 12 (2006): 78–81. http://dx.doi.org/10.1145/1183236.1183271.

Full text
APA, Harvard, Vancouver, ISO, and other styles
8

Fukaya, Naohiko. "SPL (Software Product Line)." Journal of The Institute of Image Information and Television Engineers 65, no. 7 (2011): 930–32. http://dx.doi.org/10.3169/itej.65.930.

Full text
APA, Harvard, Vancouver, ISO, and other styles
9

Schmid, Klaus, and Eduardo Santana de Almeida. "Product Line Engineering." IEEE Software 30, no. 4 (2013): 24–30. http://dx.doi.org/10.1109/ms.2013.83.

Full text
APA, Harvard, Vancouver, ISO, and other styles
10

Northrop, L. M. "SEI's software product line tenets." IEEE Software 19, no. 4 (2002): 32–40. http://dx.doi.org/10.1109/ms.2002.1020285.

Full text
APA, Harvard, Vancouver, ISO, and other styles
11

Badiehneshin, Abbas. "Indicator Based Software Product Line." International Journal of Engineering Trends and Technology 57, no. 1 (2018): 11–17. http://dx.doi.org/10.14445/22315381/ijett-v57p203.

Full text
APA, Harvard, Vancouver, ISO, and other styles
12

Dikel, D., D. Kane, S. Ornburn, W. Loftus, and J. Wilson. "Applying software product-line architecture." Computer 30, no. 8 (1997): 49–55. http://dx.doi.org/10.1109/2.607064.

Full text
APA, Harvard, Vancouver, ISO, and other styles
13

Afzal, Muhammad Fezan, and Khalid Mahmood. "Review on product derivation approaches in the software product line." Scandic Journal Of Advanced Research And Reviews 2, no. 2 (2022): 042–56. http://dx.doi.org/10.55966/sjarr.2022.2.2.0033.

Full text
Abstract:
: Product derivation is one of the most important challenges in the software product line. Obtaining the individual product from the shared software is a costly and time-consuming job. Various approaches have been proposed for product derivation in the software product line in previous times. This paper will review approaches concerning the product derivation in the software product line. This paper will provide a state-of-the-art literature review on product derivation in software line approaches. Moreover, this will be more useful in order to obtain a novel valid feather combination approach for product derivation in software product line.
APA, Harvard, Vancouver, ISO, and other styles
14

Kim, Haeng-Kon, and Lee-Kyeong Son. "Product Line Development Process for Mobile Software based on Product Line." KIPS Transactions:PartD 12D, no. 3 (2005): 395–408. http://dx.doi.org/10.3745/kipstd.2005.12d.3.395.

Full text
APA, Harvard, Vancouver, ISO, and other styles
15

Etxeberria, Leire, Goiuria Sagardui, and Lorea Belategi. "Quality aware software product line engineering." Journal of the Brazilian Computer Society 14, no. 1 (2008): 57–69. http://dx.doi.org/10.1590/s0104-65002008000100006.

Full text
APA, Harvard, Vancouver, ISO, and other styles
16

Ouali, Sami, Naoufel Kraiem, and Henda Ben Ghezala. "Framework for Evolving Software Product Line." International Journal of Software Engineering & Applications 2, no. 2 (2011): 34–51. http://dx.doi.org/10.5121/ijsea.2011.2204.

Full text
APA, Harvard, Vancouver, ISO, and other styles
17

Eriksson, Magnus, Jürgen Börstler, and Kjell Borg. "Software product line modeling made practical." Communications of the ACM 49, no. 12 (2006): 49–54. http://dx.doi.org/10.1145/1183236.1183265.

Full text
APA, Harvard, Vancouver, ISO, and other styles
18

Fernando Capretz, Luiz, Faheem Ahmed, Shereef Al‐Maati, and Zaher Al Aghbari. "COTS‐based software product line development." International Journal of Web Information Systems 4, no. 2 (2008): 165–80. http://dx.doi.org/10.1108/17440080810882351.

Full text
APA, Harvard, Vancouver, ISO, and other styles
19

Etxeberria, Leire, Goiuria Sagardui, and Lorea Belategi. "Quality aware software product line engineering." Journal of the Brazilian Computer Society 14, no. 1 (2008): 57–69. http://dx.doi.org/10.1007/bf03192552.

Full text
APA, Harvard, Vancouver, ISO, and other styles
20

Faust, D., and C. Verhoef. "Software product line migration and deployment." Software: Practice and Experience 33, no. 10 (2003): 933–55. http://dx.doi.org/10.1002/spe.530.

Full text
APA, Harvard, Vancouver, ISO, and other styles
21

Chen, Yu, Gerald C. Gannod, and James S. Collofello. "A software product line process simulator." Software Process: Improvement and Practice 11, no. 4 (2006): 385–409. http://dx.doi.org/10.1002/spip.281.

Full text
APA, Harvard, Vancouver, ISO, and other styles
22

KIM, YOUNG-GAB, SEOK KEE LEE, and SUNG-BONG JANG. "VARIABILITY MANAGEMENT FOR SOFTWARE PRODUCT-LINE ARCHITECTURE DEVELOPMENT." International Journal of Software Engineering and Knowledge Engineering 21, no. 07 (2011): 931–56. http://dx.doi.org/10.1142/s0218194011005542.

Full text
Abstract:
Software Product-Line Engineering (SPLE) is composed of two areas, namely domain engineering and application engineering. Domain engineering is associated with product-line architecture, which is a core asset of the product-line. One of the key issues of the software product-line, especially in domain engineering, is handling the variability among product families. That is, variation management for the software product-line architecture determines the success of software development. Therefore, this paper proposes processes and artifacts to build the software product-line architecture and to manage uniform variability over the life cycle of software product-lines. Furthermore, a case study, namely, the Electronic Medical Record (EMR) system, is presented.
APA, Harvard, Vancouver, ISO, and other styles
23

Camacho, Marta Cecilia, Francisco Álvarez, César A. Collazos, Paul Leger, Julián Dario Bermúdez, and Julio Ariel Hurtado. "A Collaborative Method for Scoping Software Product Lines: A Case Study in a Small Software Company." Applied Sciences 11, no. 15 (2021): 6820. http://dx.doi.org/10.3390/app11156820.

Full text
Abstract:
SPL scoping is the activity for bounding Software Product Lines (SPL), gathering heterogeneous knowledge from diverse sources. For achieving an agreement among different stakeholders, a commonalty scope must be understood and committed to. However, gathering this knowledge from stakeholders with individual interests is a complex task. This paper reports the experience of scoping the SPL of a small Colombian software company, applying and evaluating a collaborative method called CoMeS-SPL. The company was looking to develop a set of products from a product previously developed with great potential to be adapted and sold to different customers. From a collaborative relationship university–enterprise model, the research groups that developed CoMeS-SPL proposed to use it answering to the company needs for defining an organization-suitable reuse scope around its platform called CORA. Both parties joined in the scoping co-production of the first SPL of the company. This method implied that the company would perform new tasks and involve other roles different for those who are used to defining the scope of a single product. The company actors considered that they obtained a useful scope and perceived the collaboration as valuable because they shared different knowledge and perspectives. The researchers were able to provide feedback on their proposed model, identifying successes and aspects to improve. The experience allowed strengthening the ties of cooperation with the company, and new projects and consultancies are being carried out.
APA, Harvard, Vancouver, ISO, and other styles
24

OliveiraJr, Edson, Itana M. S. Gimenes, José Carlos Maldonado, Paulo Masiero, and Leonor Barroca. "Systematic Evaluation of Software Product Line Architectures." JUCS - Journal of Universal Computer Science 19, no. (1) (2013): 25–52. https://doi.org/10.3217/jucs-019-01-0025.

Full text
Abstract:
The architecture of a software product line is one of its most important artifacts as it represents an abstraction of the products that can be generated. It is crucial to evaluate the quality attributes of a product line architecture in order to: increase the productivity of the product line process and the quality of the products; provide a means to understand the potential behavior of the products and, consequently, decrease their time to market; and, improve the handling of the product line variability. The evaluation of product line architecture can serve as a basis to analyze the managerial and economical values of a product line for software managers and architects. Most of the current research on the evaluation of product line architecture does not take into account metrics directly obtained from UML models and their variabilities; the metrics used instead are difficult to be applied in general and to be used for quantitative analysis. This paper presents a Systematic Evaluation Method for UML-based Software Product Line Architecture, the SystEM-PLA. SystEM-PLA differs from current research as it provides stakeholders with a means to: (i) estimate and analyze potential products; (ii) use predefined basic UML-based metrics to compose quality attribute metrics; (iii) perform feasibility and trade-off analysis of a product line architecture with respect to its quality attributes; and, (iv) make the evaluation of product line architecture more flexible. An example using the SEI's Arcade Game Maker (AGM) product line is presented as a proof of concept, illustrating SystEM-PLA activities. Metrics for complexity and extensibility quality attributes are defined and used to perform a trade-off analysis.
APA, Harvard, Vancouver, ISO, and other styles
25

Lee, Jihyun. "An Introductory Study on an Architecture-Based Software Product Line Test Generation Method." International Journal of Software Engineering and Knowledge Engineering 29, no. 08 (2019): 1071–89. http://dx.doi.org/10.1142/s0218194019400096.

Full text
Abstract:
Architecture-based testing allows test engineers to focus on the structure of complicated software and the interactions between software components that constitute the architecture of a software product. By observing and controlling the connections and interactions between components of complex or large systems during software testing, architecture-based testing can detect and localize such faults at those locations. The complexity of software product line testing is high because an implementation under test contains variability given the different binding times and is used by multiple products. This paper introduces how architecture-based testing is applied to test generation for a software product line and examines the strengths of the proposed method against existing software product line testing methods. The paper also illustrates the use of product line architecture and architectural artifacts to generate product line interaction tests. It was found that architecture-based testing can be applied to software product line test generation by tailoring it to deal with variability and product-line specific processes. The results of a comparison with existing methods show that architecture-based software product line test generation provides better capabilities in terms of variability in the testing stage, the explicit formation and application of binding, test coverage, and architectural awareness.
APA, Harvard, Vancouver, ISO, and other styles
26

Yehia Hassan, Ayat. "A SURVEY ON SOFTWARE PRODUCT-LINE TESTING." International Journal of Advanced Research 9, no. 01 (2021): 90–96. http://dx.doi.org/10.21474/ijar01/12280.

Full text
Abstract:
SPL (Software Product Line) is known as a set of software systems that share a mutual set of features. It is a powerful concept to achieve more efficient software system development. One of the necessary steps in software development processes is Testing. It consumes typically more than 50% of the whole development costs. Testing SPLs is challenging due to the exponential number of products in the number of features. Several approaches have been proposed to reduce the number of products to be tested. However, the testing aspect of SPL is still underdeveloped. This study aims at surveying the latest research on SPL testing to identify useful approaches and needs for future research. seven papers are classified concerning the following: the used Approach, the algorithms, and the type of testing that the research focuses on. The survey found that more validation and evaluation research is required to produce a more robust foundation for SPL testing. Finally, directions for future software product line testing recommendations.
APA, Harvard, Vancouver, ISO, and other styles
27

Ripon, Shamim, Sk Jahir Hossain, and Touhid Bhuiyan. "Managing and Analysing Software Product Line Requirements." International Journal of Software Engineering & Applications 4, no. 5 (2013): 63–75. http://dx.doi.org/10.5121/ijsea.2013.4505.

Full text
APA, Harvard, Vancouver, ISO, and other styles
28

Krueger, Charles W. "New methods in software product line practice." Communications of the ACM 49, no. 12 (2006): 37–40. http://dx.doi.org/10.1145/1183236.1183262.

Full text
APA, Harvard, Vancouver, ISO, and other styles
29

Schaefer, Ina, and Reiner Hahnle. "Formal Methods in Software Product Line Engineering." Computer 44, no. 2 (2011): 82–85. http://dx.doi.org/10.1109/mc.2011.47.

Full text
APA, Harvard, Vancouver, ISO, and other styles
30

Costa, Gabriella Castro B., Regina Braga, José Maria N. David, Fernanda Campos, and Wagner Arbex. "PL-Science: A Scientific Software Product Line." Procedia Computer Science 18 (2013): 759–68. http://dx.doi.org/10.1016/j.procs.2013.05.240.

Full text
APA, Harvard, Vancouver, ISO, and other styles
31

Borba, Paulo, Leopoldo Teixeira, and Rohit Gheyi. "A theory of software product line refinement." Theoretical Computer Science 455 (October 2012): 2–30. http://dx.doi.org/10.1016/j.tcs.2012.01.031.

Full text
APA, Harvard, Vancouver, ISO, and other styles
32

Fajar, Ahmad Nurul, Ditdit Nugeraha Utama, and Gunawan Wang. "Intelligent Software Product Line For Supply Chain." Journal of Physics: Conference Series 1090 (September 2018): 012043. http://dx.doi.org/10.1088/1742-6596/1090/1/012043.

Full text
APA, Harvard, Vancouver, ISO, and other styles
33

Tan, Lei, Yuqing Lin, and Huilin Ye. "Quality-Oriented Software Product Line Architecture Design." Journal of Software Engineering and Applications 05, no. 07 (2012): 472–76. http://dx.doi.org/10.4236/jsea.2012.57054.

Full text
APA, Harvard, Vancouver, ISO, and other styles
34

Niemelä, Eila, and Tuomas Ihme. "Product line software engineering of embedded systems." ACM SIGSOFT Software Engineering Notes 26, no. 3 (2001): 118–25. http://dx.doi.org/10.1145/379377.375271.

Full text
APA, Harvard, Vancouver, ISO, and other styles
35

Insfran, Emilio, Gary Chastek, Patrick Donohoe, and Julio César Sampaio do Prado Leite. "Requirements engineering in software product line engineering." Requirements Engineering 19, no. 4 (2013): 331–32. http://dx.doi.org/10.1007/s00766-013-0189-0.

Full text
APA, Harvard, Vancouver, ISO, and other styles
36

Hanssen, Geir K. "Agile software product line engineering: enabling factors." Software: Practice and Experience 41, no. 8 (2011): 883–97. http://dx.doi.org/10.1002/spe.1064.

Full text
APA, Harvard, Vancouver, ISO, and other styles
37

Coallier, François, and Roger Champagne. "A Product Line engineering practices model." Science of Computer Programming 57, no. 1 (2005): 73–87. http://dx.doi.org/10.1016/j.scico.2004.10.006.

Full text
APA, Harvard, Vancouver, ISO, and other styles
38

Kumar, Satendra, Mohit Mittal, and Vinod Kumar Yadav. "Cost-effective product prioritisation technique for software product line testing." International Journal of Engineering Systems Modelling and Simulation 12, no. 2/3 (2021): 83. http://dx.doi.org/10.1504/ijesms.2021.115518.

Full text
APA, Harvard, Vancouver, ISO, and other styles
39

Yadav, Vinod Kumar, Satendra Kumar, and Mohit Mittal. "Cost-effective product prioritisation technique for software product line testing." International Journal of Engineering Systems Modelling and Simulation 1, no. 1 (2021): 1. http://dx.doi.org/10.1504/ijesms.2021.10035529.

Full text
APA, Harvard, Vancouver, ISO, and other styles
40

Ferreira, Thiago N., Jackson A. Prado Lima, Andrei Strickler, Josiel N. Kuk, Silvia R. Vergilio, and Aurora Pozo. "Hyper-Heuristic Based Product Selection for Software Product Line Testing." IEEE Computational Intelligence Magazine 12, no. 2 (2017): 34–45. http://dx.doi.org/10.1109/mci.2017.2670461.

Full text
APA, Harvard, Vancouver, ISO, and other styles
41

Sepúlveda, Samuel, Ricardo Pérez-Castillo, and Mario Piattini. "A software product line approach for developing hybrid software systems." Information and Software Technology 178 (February 2025): 107625. http://dx.doi.org/10.1016/j.infsof.2024.107625.

Full text
APA, Harvard, Vancouver, ISO, and other styles
42

Ding, Jian Jie. "Software Product Line Measurement Process Capability Maturity Model." Applied Mechanics and Materials 536-537 (April 2014): 673–77. http://dx.doi.org/10.4028/www.scientific.net/amm.536-537.673.

Full text
Abstract:
Software product line has been a key area of concern in software industry due to its advantage on the productivity and quality of software products. At same time, both software organizations and the academic community are aware that the software measurement is necessary in software product line. However, there are many problems: what is difference in software product line measurement, how about their measurement process in the end, etc. It addresses this problem by creating a specialized Software Product Line Measurement Process Capability Maturity Model (SPLMP-CMM). SPLMP-CMM including five maturity levels: initial, tentatively, defined, compesive and optimized. The model focus on the basic practice areas which should be implementing of every level, it helps the originations to assess their measurement process and provides guidance for them to a higher maturity level.
APA, Harvard, Vancouver, ISO, and other styles
43

Laguna, Miguel A., and Yania Crespo. "A systematic mapping study on software product line evolution: From legacy system reengineering to product line refactoring." Science of Computer Programming 78, no. 8 (2013): 1010–34. http://dx.doi.org/10.1016/j.scico.2012.05.003.

Full text
APA, Harvard, Vancouver, ISO, and other styles
44

Ebert, C. "Hands-on experience implementing a product line - Software Product-Line Engineering: A Family-Based Software Development Process [Book Review]." IEEE Software 18, no. 1 (2001): 105–6. http://dx.doi.org/10.1109/ms.2001.903177.

Full text
APA, Harvard, Vancouver, ISO, and other styles
45

Schwanninger, Christa, and David Benavides. "Editorial for the special section on Software Product Line Engineering: Selected papers from Software Product Line conference in 2012." Information and Software Technology 56, no. 9 (2014): 1099–100. http://dx.doi.org/10.1016/j.infsof.2014.03.008.

Full text
APA, Harvard, Vancouver, ISO, and other styles
46

Lee, Wen-Tin, and Chih-Hsien Chen. "Agile Software Development and Reuse Approach with Scrum and Software Product Line Engineering." Electronics 12, no. 15 (2023): 3291. http://dx.doi.org/10.3390/electronics12153291.

Full text
Abstract:
Agile methods and software product line engineering (SPLE) are widely recognized as practical approaches for delivering high-quality software, adapting to evolving stakeholder needs, and tackling complex problems. This study proposes a hybrid agile software development and reuse approach called SPLE-Scrum based on the activities of software product line engineering and Scrum. Within the SPLE process, we incorporate requirement engineering and design practices to create a reference architecture with reusable components called core assets by introducing a product management meeting. The core assets are reused to build a series of applications with various product lines. The product increments are delivered in each Sprint with the review and retrospective meetings based on Scrum lifecycle and practices. We present a case study involving a blockchain online store to demonstrate the practical application of SPLE-Scrum, highlighting the benefits of integrating Scrum and software product line engineering. The research hypotheses of the proposed approach were validated through a study of structured interviews with 5 experts and 44 software practitioners, showing that the key factors of product management, project requirements, and product architecture in the SPLE-Scrum approach have a beneficial impact on project success. The SPLE-Scrum approach provides valuable insights and practical guidance for organizations seeking to optimize their software engineering practices while incorporating agile development and software reuse capabilities.
APA, Harvard, Vancouver, ISO, and other styles
47

Ah Kim, Jeong. "Variability Management Mechanism for Domain Engineering and Case Study in SunRoof Control Domain." Tehnički glasnik 18, no. 1 (2024): 12–20. http://dx.doi.org/10.31803/tg-20230216195620.

Full text
Abstract:
Abstract: This study aims to suggest variability mechanisms for software product line development and to explain the results of case study. Software product line engineering is an extension of software engineering and many organizations constantly engage in reengineering and refactoring to adopt the software product line engineering. Software product line engineering has two engineering processes: domain engineering process and application engineering process. Feature Identification and feature model are key success factor to construct variability model. Feature model describes the variable parts to be extended or replaced and common part to be reuse by themselves. Feature model gives the directions to the following architecture design and component implementation. However, feature model is not the design strategy and variability mechanism for product line implementation. Therefore, these are the obstacles for organizations that are unfamiliar with feature model and variability mechanism to adopt software product line engineering. Several variability mechanisms for software intensive software are suggested but these are not applicable for embedded software since it has different development process and structure. In this paper, variability elements in architecture design and component design of embedded software are identified as state variable, state transition information, and algorithm. Variability management mechanisms are defined for these elements. To provide the detail strategy and to evaluate the suggested variability management methods, process and results of real case study are described.
APA, Harvard, Vancouver, ISO, and other styles
48

Castro, Thiago, Leopoldo Teixeira, Vander Alves, Sven Apel, Maxime Cordy, and Rohit Gheyi. "A Formal Framework of Software Product Line Analyses." ACM Transactions on Software Engineering and Methodology 30, no. 3 (2021): 1–37. http://dx.doi.org/10.1145/3442389.

Full text
Abstract:
A number of product-line analysis approaches lift analyses such as type checking, model checking, and theorem proving from the level of single programs to the level of product lines. These approaches share concepts and mechanisms that suggest an unexplored potential for reuse of key analysis steps and properties, implementation, and verification efforts. Despite the availability of taxonomies synthesizing such approaches, there still remains the underlying problem of not being able to describe product-line analyses and their properties precisely and uniformly. We propose a formal framework that models product-line analyses in a compositional manner, providing an overall understanding of the space of family-based, feature-based, and product-based analysis strategies. It defines precisely how the different types of product-line analyses compose and inter-relate. To ensure soundness, we formalize the framework, providing mechanized specification and proofs of key concepts and properties of the individual analyses. The formalization provides unambiguous definitions of domain terminology and assumptions as well as solid evidence of key properties based on rigorous formal proofs. To qualitatively assess the generality of the framework, we discuss to what extent it describes five representative product-line analyses targeting the following properties: safety, performance, dataflow facts, security, and functional program properties.
APA, Harvard, Vancouver, ISO, and other styles
49

Armaya'u, Zango Umar, and Lee Jaejoon. "Properties of a Feature in Code-Assets: An Exploratory Study." International Journal of Software Engineering & Applications (IJSEA) 12, no. 5 (2021): 41–53. https://doi.org/10.5281/zenodo.5588443.

Full text
Abstract:
Software product line engineering is a paradigm for developing a family of software products from a repository of reusable assets rather than developing each individual product from scratch. In featureoriented software product line engineering, the common and the variable characteristics of the products are expressed in terms of features. Using software product line engineering approach, software products are produced en masse by means of two engineering phases: (i) Domain Engineering and, (ii) Application Engineering. At the domain engineering phase, reusable assets are developed with variation points where variant features may be bound for each of the diverse products.
APA, Harvard, Vancouver, ISO, and other styles
50

Haupt, Michael, Stefan Marr, and Robert Hirschfeld. "CSOM/PL — A Virtual Machine Product Line." Journal of Object Technology 10 (2011): 12:1. http://dx.doi.org/10.5381/jot.2011.10.1.a12.

Full text
APA, Harvard, Vancouver, ISO, and other styles
We offer discounts on all premium plans for authors whose works are included in thematic literature selections. Contact us to get a unique promo code!

To the bibliography