About

I'm an currenly a R+D engineer at IK4 Ikerlan. I got my PhD in Computer Science from the University of The Basque Country, Spain. Supervised by Prof. Oscar Díaz, at ONEKIN research group . My thesis was on Software Product Lines (SPLs). Specifically, I explored ways to support the development and evolution of SPLs. During my PhD studies I visited Danfoss company for 4 months.

I got my Bachelor degree from the University of Mondragón (Spain), and my Master's from the Polytechnic University of Catalonia (UPC - BarcelonaTech). I developed my bachelor and master projects at Johannes Kepler University (Linz, Austria) and Everis (Barcelona, Spain), respectively.

Check out my CV


Checkout my Thesis manuscript here

Skills

  • Java, C, HTML, JS
  • Eclipse, Spring Boot, IntelliJ
  • mySQL, Oracle
  • Git, Github, GitLab
  • SPLE engineering, variability management
  • English, Spanish, Basque
  • Social, commited, hard-worker

Rersearch projects

Below are listed the projects I have developed as part of my thesis

The role of customization analysis for SPL evolution

CustomDIFF from Leticia Montalvillo on Vimeo.

The long life-span of Software Product Lines (SPLs) makes evolution a top priority. Evolution can come in many flavours. In their infancy, SPLs strive to fix defects. At adulthood, SPLs might have less defects, but their wider customer base more likely increases the chances for new functionality requests. The point is that it is not always possible to handle this evolution directly through the reusable SPL core assets. Time-to-market pressure, expedite bug fixes or single-product behaviour might lead evolution to first happen at the product level, and to be later merged and refactored during the next core-asset release. Deciding when and what should go into the next release is far from trivial. A main decision-making input is the effort that has been put into product customization, i.e. how core assets have been upgraded to promptly account for the products’ demands. This work proposes the use of data warehouses to analyze this customization effort. Requirement Analysis, Dimensional Modeling and Reporting Tools are discussed, that end up in CustomDIFF, a data warehouse tool that uses Git as the operational system and pure::variants as the SPL framework. This research is motivated and validated in the context of Danfoss Drives.

Reducing Coordination Overhead in SPLs: Peering in on Peers

GitLine from Leticia Montalvillo on Vimeo.

SPL product customers might not always wait for the next core asset release. When an organization aims to react to market events, quick bug fixes or urgent customer requests, strategies are needed to support fast adaptation, e.g. with product-specifc extensions, which are later propagated into the SPL. This leads to the grow-and-prune model where quick reaction to changes often requires copying and specialization (grow) to be later cleaned up by merging and refactoring (prune). This paper focuses on the grow stage. Here, application engineers branch of the core-asset Master branch to account for their products’ specifcs within the times and priorities of their customers without having to wait for the next release of the core assets. However, this practice might end up in the socalled "integration hell". When long-living branches are merged back into the Master, the amount of code to be integrated might cause build failures or requires complex troubleshooting. On these premises, we advocate for making application engineers aware of potential coordination problems right during coding rather than deferring it till merging time. To this end, we introduce the notion of "peering bar" for Version Control Systems, i.e. visual bars that refect whether your product’s features are being upgraded in other product branches. In this way, engineers are aware of what their peers are doing on the other SPL’s products. Being products from the same SPL, they are based on the very same core assets, and hence, bug fxes or functional enhancements undertaken for a product might well serve other products. This work introduces design principles for peering bars. These principles are fheshed out for GitHub as the Version Control System, and pure::variants as the SPL framework.

Tunning Github for SPL Development: Branching Model and Repository Operations for Product Engineers

GitLine from Leticia Montalvillo on Vimeo.

SPLs distinguish between domain engineering (DE) and ap-plication engineering (AE). Though each realm has its own lifecycle, they might need to be regularly synchronized to avoid SPL erosion during evolution. This introduces two sync paths: update propagation (from DE to AE ) and feed-back propagation (from AE to DE). This work looks at how to support sync paths in Version Control Systems (VCSs) using traditional VCS constructs (i.e. merge, branch, fork and pull). In this way, synchronization mismatches can be resolved `a la VCS, i.e. highlighting difference between distinct versions of the same artifact. However, this results in a conceptual gap between how propagations are conceived (i.e. update, feedback) and how propagation are realized (i.e. merge, branch, etc). To close this gap, we propose to enhance existing VCSs with SPL sync paths as first-class operations. As a proof-of-concept, we use Web Augmen-tation techniques to extend GitHub’s Web pages with this extra functionality. Through a single click, product engineers can now (1) generate product repositories, (2) update propagating newer feature versions, or (3), feedback propa-gating product customizations amenable to be upgraded as core assets.

Systematic Mapping Study on SPL evolution

Highlights
•We conducted a systematic mapping study on SPL evolution.
•We identified 107 relevant contributions on the topic up to mid 2015.
•We elaborated on the traditional change mini-cycle to classify the contributions.
•We identified well-established topics, trends and open research issues.

Contact Me

  • Check my Linkedin Linkedin
  • Check my Github projects Github
  • Email me Email