Software Engineering Afternoon

The Department of Computer Science of the University of Chile is having a bi-weekly meeting to discuss Software Engineering ideas, problems and results. It is usually being held between 16:00 and 17:30.

In addition to this page, a mailing list is used for the organization and the diffusion of announcements. If you want to register to the mailing list, send an email to

Presentations are in Spanish, even though, English may be occasionally used.

Date: 5 or 26 /04/2010

Title: Visualizing Dynamic Metrics with Profiling Blueprints

Authors: Alexandre Bergel, Romain Robbes, Walter Binder

Speaker: Alexandre Bergel

Abstract: While traditional approaches to code profiling help locate performance bottlenecks, they offer only limited support for removing these bottlenecks. The main reason is the lack of visual and detailed runtime information to identify and eliminate computation redundancy.

We provide two profiling blueprints which help identify and remove performance bottlenecks. The structural distribution blueprint graphically represents the CPU consumption share for each method and class of an application. The behavioral distribution blueprint depicts the distribution of CPU consumption along method invocations, and hints at method candidates for caching optimizations. These two blueprints helped us to significantly optimize Mondrian, an open source visualization engine. Our implementation is freely available for the Pharo development environment and has been evaluated in a number of different scenarios.

Date: 29/04/2010

Title: Software Process Model Blueprints

Authors: Julio Ariel Hurtado Alegría, Alejandro Lagos, Alexandre Bergel and María Cecilia Bastarrica

Speaker: Julio Ariel Hurtado Alegría

Abstract: Explicitly defining a software process model is widely recognized as a good software engineering practice. However, having a defined process does not necessarily mean that this process is good, sound and/or useful. There have been several approaches for software process evaluation including testing, simulation and metrics; the first and second require software process enactment, i.e., an expensive, risky and long process, and the third requires high expertise for correctly interpreting their meaning. In this paper we propose a visual approach for software process model evaluation based on three architectural view types, each one focusing on basic process elements: Role Blueprint, Task Blueprint and Work Product Blueprint. They enable visual evaluation of different perspectives of a software process, each being relevant for a particular stakeholder. We illustrate the proposed approach by applying it to the software process defined for a real world company that develops software for retail. We show how design errors were identified and provide a number of improvements.

Date: 18/10/2010, 16:00.

Lugar: Piso 4, DCC

Mini talks:

  1. Alcides Quispe Sanca (PhD): Requirements Engineering Practices in Very Small Software Enterprises
  2. Víctor Codocedo (PhD): Semi-automatic hierarchy construction for software engineering
  3. Hernán Astudillo: Recovering Software Architecture Rationale
  4. Alexandre Bergel: Agile Profiling Framework

Date: 08/11/2010, 16:00.

Lugar: Piso 4, DCC

  1. Julio Hurtado: Analyzing the Scrum Process Model with AVISPA
  2. Cécilia Bastarrica: serie de preguntas

Abstract de Cécilia: Las líneas de procesos de sofware son conjuntos de procesos similares configuradas a partir de activos de proceso comunes de acuerdo con las necesidades particulares del producto a desarrollar. Los productos pueden caracterizarse por un contexto que define sus características: tamaño, complejidad, novedad tecnológica, experiencia del equipo de desarrollo, presupuesto, etc. Por su parte, las líneas de productos de software organizan el proceso de desarrollo de tal forma de poder producir una serie de productos de sofware similares maximizando la productividad a través del reuso organizado de activos. O sea que se trata en principio de un mismo proceso para desarrollar una serie de distintos productos. Pero, ¿qué significa “similares”? ¿podemos caracterizar esta similitud con el mismo modelo de contexto usado para las líneas de procesos? ¿qué sucede si algunos productos de la línea difieren en alguna dimensión tal que exigiría la existencia de más de un proceso de desarrollo?