No abstract

No abstract

Technical debt, a metaphor for the long-term consequences of weak software development, must be managed to keep it under control. The main goal of this article is to identify and analyze the elements required to manage technical debt.The research method used to identify the elements is a systematic mapping, including a synthesis step to synthesize the elements definitions. Our perspective differs from previous literature reviews because it focused on the elements required to manage technical debt and not on the phenomenon of technical debt or the activities used in performing technical debt management. Additionally, the rigor and relevance for industry of the current techniques used to manage technical debt are studied. The elements were classified into three groups (basic decision-making factors, cost estimation techniques, practices and techniques for decision-making) and mapped according three stakeholders' points of view (engineering, engineering management, and business-organizational management).The definitions, classification, and analysis of the elements provide a framework that can be deployed to help in the development of models that are adapted to the specific stakeholders' interests to assist the decision-making required in

The development of software systems must be done using platforms that allow the description of quality, complex, distributed, dynamic and reusable architectural models. We present in this paper PRISMA, an architectural modelling approach based on aspects and components, that uses a component definition language (components, connectors and systems) to define architectural types at a high abstraction level and a configuration language to design the architecture of software systems. The component definition language increases reuse allowing importation of COTS and reduces complexity by integrating two modern software development approaches: Component-Based Software Development and Aspect-Oriented Software Development. The configuration language designs the architecture of software systems by creating and interconnecting instances of the defined types including possible imported COTS. PRISMA has a metalevel with reflexive properties for these two languages. For this reason, the types of PRISMA may evolve and the topologies of PRISMA may be reconfigured dynamically.

No abstract

No abstract

Software Product Line Engineering (SPLE) demands upfront long‐term investment in (i) designing a common set of core‐assets and (ii) managing variability across the products from the same family. When anticipated changes in these core‐assets have been predicted with certain accuracy, SPLE has proved significant improvements. However, when large/complex software product line projects have to deal with changing market conditions, alternatives to supplement SPLE are required. Agile Software Development (ASD) may be an alternative, as agile processes harness change for the customer's competitive advantage. However, when the aim is to scale Agile projects up to effectively manage reusability and variability across the products from the same family, alternatives to supplement agility are also required. As a result, a new approach called Agile Product Line Engineering (APLE) advocates integrating SPLE and ASD with the aim of addressing these gaps. APLE is an emerging approach, which implies that organizations have to face several barriers to achieve its adoption. This paper presents a systematic literature review of experiences and practices on APLE, in which the key findings uncover important challenges about how to integrate the SPLE model with an agile iterative approach to fully put APLE into practice. Copyright © 2011 John Wiley & Sons, Ltd.

Innovation is a driver of global economy growth. Software intensive systems (SiSs) are embedded in the systems of various leading sectors, such as the automotive, robotics, and mobile phone industries and they are creating new opportunities for innovation. However, SiSs are affected by a rapidly changing market and a reduced time to market. Software product innovation assessment is becoming important because firms need to know as soon as possible if their products are aligned with the market and customer demands.However, this is not a simple process. To identify the existing assessment schemas applicable to software product innovation, we have undertaken a systematic literature review. We found no studies specific to the development of software, but several approaches for products in general are applicable to software even when no one finding is conclusive. Therefore, this is just the first stage for assessing software product innovation. Our findings are related to three areas of focus: (i) general, (ii) product innovation assessment preparation, (iii) the assessment process.