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

Software Product Line Reengineering: A Case Study on the Geographic Domain

The growing adoption of software product lines (SPL) represents perhaps a paradigm shift in software development aiming at improving cost, quality, time to market, and developer productivity. While the underlying concepts are straightforward enough building a family of related products or systems by planned and careful reuse of a base of generalized software development assets the problems can be in the details, as successful product line practice involves domain understanding, technology selection, and so forth. Today, there is an important increment on reporting experiences and lessons about SPL development by capturing aspects that have been gathered during daily practice. Following this line, in this paper we start from our experiences of developing a software product line on the Marine Ecology domain highlighting our reasons for reengineering a previous SPL. Then, we explain step-bystep reengineering activities in terms of motivation, solutions, and lessons learned, which summarize strengths and limitations of the applied practices. Differently from other cases, here we take advantage of using domain standards as well as open source implementations within the geographic domain.Facultad de Informátic

First turkish software product line engineering workshop summary

Cataloged from PDF version of article.Software reuse has been a goal of the software community since the early days of software engineering. In this context software product line engineering (SPLE) has gained a broad interest in both academic institutions and industry. This trend can also be observed in Turkey. In the recent years an increasing number of software companies in Turkey have adopted a SPLE approach while others are planning to make the transition. This paper summarizes the results of the First Turkish Software Product Line Engineering Workshop that has been organized in Ankara in June 2012. The primary goal of the workshop was to reflect on the state of practice in SPLE in Turkey. For this five leading SPLE companies in Turkey have shared their experiences in adopting SPLE, and using interactive discussions a research agenda for SPLE in Turkey has been defined. We report both on the experiences from the workshop and the resulting research topics

Software Product Line Reengineering: A Case Study on the Geographic Domain

The growing adoption of software product lines (SPL) represents perhaps a paradigm shift in software development aiming at improving cost, quality, time to market, and developer productivity. While the underlying concepts are straightforward enough building a family of related products or systems by planned and careful reuse of a base of generalized software development assets the problems can be in the details, as successful product line practice involves domain understanding, technology selection, and so forth. Today, there is an important increment on reporting experiences and lessons about SPL development by capturing aspects that have been gathered during daily practice. Following this line, in this paper we start from our experiences of developing a software product line on the Marine Ecology domain highlighting our reasons for reengineering a previous SPL. Then, we explain step-bystep reengineering activities in terms of motivation, solutions, and lessons learned, which summarize strengths and limitations of the applied practices. Differently from other cases, here we take advantage of using domain standards as well as open source implementations within the geographic domain.Facultad de Informátic

NASA's Ares I and Ares V Launch Vehicles--Effective Space Operations Through Efficient Ground Operations

The United States (U.S.) is charting a renewed course for lunar exploration, with the fielding of a new human-rated space transportation system to replace the venerable Space Shuttle, which will be retired after it completes its missions of building the International Space Station (ISS) and servicing the Hubble Space Telescope. Powering the future of space-based scientific exploration will be the Ares I Crew Launch Vehicle, which will transport the Orion Crew Exploration Vehicle to orbit where it will rendezvous with the Altair Lunar Lander, which will be delivered by the Ares V Cargo Launch Vehicle (fig. 1). This configuration will empower rekindled investigation of Earth's natural satellite in the not too distant future. This new exploration infrastructure, developed by the National Aeronautics and Space Administration (NASA), will allow astronauts to leave low-Earth orbit (LEO) for extended lunar missions and preparation for the first long-distance journeys to Mars. All space-based operations - to LEO and beyond - are controlled from Earth. NASA's philosophy is to deliver safe, reliable, and cost-effective architecture solutions to sustain this multi-billion-dollar program across several decades. Leveraging SO years of lessons learned, NASA is partnering with private industry and academia, while building on proven hardware experience. This paper outlines a few ways that the Engineering Directorate at NASA's Marshall Space Flight Center is working with the Constellation Program and its project offices to streamline ground operations concepts by designing for operability, which reduces lifecycle costs and promotes sustainable space exploration

Evaluating Company’s Readiness for Adopting Product Line Engineering: a Second Evaluation Round

Product lines have emerged in the software industry as an attractive approach to perform planned reuse of code. Nevertheless, a product line solution is not appropriate in all cases and also requires some conditions to be implemented successfully. The literature offers several contributions regarding the adoption of product lines. However, only a few of them are able to support decision-makers in making informed decisions in favor of or against following this approach. We proposed APPLIES, a framework for evaluating the organization’s motivation and preparation for adopting product lines. This article presents the second version of the APPLIES framework as well as the second iteration of the evaluation of this approach. This evaluation consisted of (i) a workshop with a practitioner who had experience in adopting the product line production approach and; (ii) a review of the content by five product line experts. The results obtained from the evaluation resulted in modifications to the framework content, mainly to simplify the statements and eliminate redundant elements. Also, we detected new functionalities and modifications that we expect to be resolved in the following evaluation iterations. Further evaluations and improvements are needed to mature the framework. Moreover, we expect to incorporate APPLIES into a process that covers the aspects that a company must consider before deciding to adopt this production paradigm

Engineering of next generation cyber-physical automation system architectures

Cyber-Physical-Systems (CPS) enable flexible and reconfigurable realization of automation system architectures, utilizing distributed control architectures with non-hierarchical modules linked together through different communication systems. Several control system architectures have been developed and validated in the past years by research groups. However, there is still a lack of implementation in industry. The intention of this work is to provide a summary of current alternative control system architectures that could be applied in industrial automation domain as well as a review of their commonalities. The aim is to point out the differences between the traditional centralized and hierarchical architectures to discussed ones, which rely on decentralized decision-making and control. Challenges and impacts that industries and engineers face in the process of adopting decentralized control architectures are discussed, analysing the obstacles for industrial acceptance and the new necessary interdisciplinary engineering skills. Finally, an outlook of possible mitigation and migration actions required to implement the decentralized control architectures is addressed.The authors would like to thank the European Commission for the support, and the partners of the EU Horizon 2020 project PERFoRM (2016b) for the fruitful discussions. The PERFoRM project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 680435.info:eu-repo/semantics/publishedVersio