Jessica Díaz

Mapping CMMI Level 2 to Scrum Practices: An Experience Report

CMMI has been adopted advantageously in large companies for improvements in software quality, budget fulfilling, and customer satisfaction. However SPI strategies based on CMMI-DEV require heavy software development processes and large investments in terms of cost and time that medium/small companies do not deal with. The so-called light software development processes, such as Agile Software Development (ASD), deal with these challenges. ASD welcomes changing requirements and stresses the importance of adaptive planning, simplicity and continuous delivery of valuable software by short time-framed iterations. ASD is becoming convenient in a more and more global, and changing software market. It would be greatly useful to be able to introduce agile methods such as Scrum in compliance with CMMI process model. This paper intends to increase the understanding of the relationship between ASD and CMMI-DEV reporting empirical results that confirm theoretical comparisons between ASD practices and CMMI level2.

Agile product line engineering—a systematic literature review

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 customers 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

Plastic Partial Components: A solution to support variability in architectural components

Software Product Line Engineering is becoming widely used due to the improvement it means when developing software products of the same family. The commonalities and variabilities of Software Product Lines (SPL) are identified during the Domain Engineering process and then, they are realized in the software architecture. Therefore, mechanisms to explicitly specify the commonalities and variabilities of SPLs at the architectural level are required. Most of the current mechanisms specify variations on the architecture by adding or removing architectural elements. However, it is also necessary to specify variations inside components. In this paper, we propose the notion of Plastic Partial Components to support internal variations. The specification of these components is performed using Invasive Software Composition techniques and without tangling the core and product architectures of the SPL. This contribution is illustrated through a SPL for developing domain-specific validation environments.

Change impact analysis in product-line architectures

Change impact analysis is fundamental in software evolution, since it allows one to determine potential effects upon a system resulting from changing requirements. While prior work has generically considered change impact analysis at architectural level, there is a distinct lack of support for the kinds of architectures used to realize software product lines, so-called product-line architectures (PLAs). In particular, prior approaches do not account for variability, a specific characteristic of software product lines. This paper presents a new technique for change impact analysis that targets product-line architectures. We propose to join a traceability-based algorithm and a rule-based inference engine to effectively traverse modeling artifacts that account for variability. In contrast to prior approaches, our technique supports the mechanisms for (i) specifying variability in PLAs, (ii) documenting PLA knowledge, and (iii) tracing variability between requirements and PLAs. We demonstrate our technique by applying it to the analysis of requirements changes in the product-line architecture of a banking system.

Flexible working architectures: agile architecting using PPCs

Software systems need software architectures to improve their scalability and maintenance. However, many agile practitioners claim that the upfront design of software architectures is an investment that does not pay off, since customers can rarely appreciate the value delivered by architectures. Furthermore, conventional architectural practices may be considered unacceptable from the Agile values and principles perspective. In this paper, the development of working architectures in agile iterations is presented as an attempt to solve the problem of designing software architectures in Agile. This contribution is based on the new concept of Plastic Partial Component (PPC). PPCs are highly malleable components that can be partially described, what increases the flexibility of architecture design. PPCs based architectures let reinforce some of the agile values and principles. Our experience of putting this contribution into practice is illustrated through the agile development of a Testing Framework for Biogas Plants.

Agile product-line architecting in practice: A case study in smart grids

Abstract Context Software Product Line Engineering implies the upfront design of a Product-Line Architecture (PLA) from which individual product applications can be engineered. The big upfront design associated with PLAs is in conflict with the current need of “being open to change” . To make the development of product-lines more flexible and adaptable to changes, several companies are adopting Agile Product Line Engineering. However, to put Agile Product Line Engineering into practice it is still necessary to make mechanisms available to assist and guide the agile construction and evolution of PLAs. Objective This paper presents the validation of a process for “the agile construction and evolution of product-line architectures” , called Agile Product-Line Architecting (APLA) . The contribution of the APLA process is the integration of a set of models for describing, documenting, and tracing PLAs, as well as an algorithm for guiding the change decision-making process of PLAs. The APLA process is assessed to prove that assists Agile Product Line Engineering practitioners in the construction and evolution of PLAs. Method Validation is performed through a case study by using both quantitative and qualitative analysis. Quantitative analysis was performed using statistics, whereas qualitative analysis was performed through interviews using constant comparison, triangulation, and supporting tools. This case study was conducted according to the guidelines of Runeson and Host in a software factory where three projects in the domain of Smart Grids were involved. Results APLA is deployed through the Flexible-PLA modeling framework. This framework supported the successful development and evolution of the PLA of a family of power metering management applications for Smart Grids. Conclusions APLA is a well-supported solution for the agile construction and evolution of PLAs. This case study illustrates that the proposed solution for the agile construction of PLAs is viable in an industry project on Smart Grids.

Large-scale smart grids as system of systems

Smart Grids are advanced power networks that introduce intelligent management, control, and operation systems to address the new challenges generated by the growing energy demand and the appearance of renewal energies. In the literature, Smart Grids are presented as an exemplar SoS: systems composed of large heterogeneous and independent systems that leverage emergent behavior from their interaction. Smart Grids are currently scaling up the electricity service to millions of customers. These Smart Grids are known as Large-Scale Smart Grids. From the experience in several projects about Large-Scale Smart Grids, this paper defines Large-Scale Smart Grids as a SoS that integrate a set of SoS and conceptualizes the properties of this SoS. In addition, the paper defines the architectural framework for deploying the software architectures of Large-Scale Smart Grid SoS.

A model for tracing variability from features to product-line architectures: a case study in smart grids

In current software systems with highly volatile requirements, traceability plays a key role to maintain the consistency between requirements and code. Traceability between artifacts involved in the development of software product line (SPL) is still more critical because it is necessary to guarantee that the selection of variants that realize the different SPL products meet the requirements. Current SPL traceability mechanisms trace from variability in features to variations in the configuration of product-line architecture (PLA) in terms of adding and removing components. However, it is not always possible to materialize the variable features of a SPL through adding or removing components, since sometimes they are materialized inside components, i.e., in part of their functionality: a class, a service, and/or an interface. Additionally, variations that happen inside components may crosscut several components of architecture. These kinds of variations are still challenging and their traceability is not currently well supported. Therefore, it is not possible to guarantee that those SPL products with these kinds of variations meet the requirements. This paper presents a solution for tracing variability from features to PLA by taking these kinds of variations into account. This solution is based on models and traceability between models in order to automate SPL configuration by selecting the variants and realizing the product application. The FPLA modeling framework supports this solution which has been deployed in a software factory. Validation has consisted in putting the solution into practice to develop a product line of power metering management applications for smart grids.

Guiding Flexibility Investment in Agile Architecting

Agile software development pursues to deal with continuous change. But software product architectures without enough flexibility can restrict how products cope with change. However, designing for flexibility often entails high costs and risk that comes with the assumption that change will happen. Actually, in software architecture the flexibility investment decision making problem has become challenging. This paper presents a process to assist architects in Making decisions about Flexibility investment in Software Architecture (MAKE Flexi). MAKE Flexi is based on technical debt and real options approaches. Technical debt allows for estimating the additional cost derived from the lack of flexibility in software architectures, whereas the real options valuation allows for estimating the value of the flexibility that a design option could provide. MAKE Flexi has been applied to an industry project for smart grids to assist architects in making decisions about designing for flexibility to vary data storage technologies.

Change-Impact Driven Agile Architecting

Software architecture is a key factor to scale up Agile Software Development (ASD) in large software-intensive systems. Currently, software architectures are more often approached through mechanisms that enable to incrementally design and evolve software architectures (aka. agile architecting). Agile architecting should be a light-weight decision-making process, which could be achieved by providing knowledge to assist agile architects in reasoning about changes. This paper presents the novel solution of using change-impact knowledge as the main driver for agile architecting. The solution consists of a Change Impact Analysis technique and a set of models to assist agile architects in the change (decision-making) process by retrieving the change-impact architectural knowledge resulting from adding or changing features iteration after iteration. To validate our approach, we have put our solution into practice by running a project of a metering management system in electric power networks in an i-smart software factory.