El Análisis de Impacto en desarrollo de Software

El análisis de impacto permite identificar los componentes de un sistema que pueden verse afectados en la modificación de una funcionalidad. Antes del cambio permite planificar el desarrollo, estimar el esfuerzo y evaluar el costo económico. Después del cambio es útil para determinar los tipos de pruebas que se deben de realizar en la fase de testing. Y aunque no existe un estándar para este tipo de análisis, vamos a proponer una guía básica y sencilla para llevar a cabo esta labor de forma segura.

La herramienta

En proyectos complejos con miles de elementos, listar manualmente aquellos afectados por un cambio requiere mucho tiempo y no es fiable. Antes de redactar la presente entrada, me di a la tarea de revisar las principales herramientas que permiten realizar el análisis de dependencias de forma automática y son muy pocas, una de las que encontré con licencia libre, estable y suficientemente actualizada para trabajar con proyectos modernos fue JRipples.

A modo de ejemplo, se procedió a instalar este plugin directamente desde el Marketplace de Eclipse (versión 2020-12), su único prerrequisito es tener integrada la librería Apache Lucene, dejaré un link de descarga con los JARs al final. El análisis de impacto fue aplicado en un proyecto utilizando el framework Spring compilado con Java 11. Al terminar la instalación de la herramienta, deberá aparecer la sección de JRipples en el toolbar.

Después de dar click en la opción de “Start analysis”, se debe seleccionar el proyecto y la clase principal donde iniciaremos a realizar el análisis de dependencias.

Posteriormente se selecciona la opción “Table Presentation” en el combo de “Presentation” y se da click en finalizar.

Aparecerá un nuevo tab con los artefactos de la aplicación. El análisis estático se inicia con la clase «Main» marcada en color verde, después de visitarla podemos hacer click derecho y aparecerán tres opciones: «Located», «Propagating» y «Unchanged». Para este ejemplo se asume que el cambio realizado en esta clase, se propagó a otras.

Después de seleccionar «Propagating», JRipples indentifica las clases a las que el cambio pudo haberse propagado.

El análisis continuará con cada una de los elementos marcados en color verde, para determinar si el cambio se propagó o no a esas otras clases. Si el cambio requiere que la clase sea modificada, se marca con la opción «Located», de lo contrario se elige «Unchanged». Es importante mencionar que se pueden elegir tantas clases «Propagating» como sea requerido, iniciando así nuevos ciclos de revisión.

El documento

El documento de análisis puede usarse como un checklist, donde se utilizan colores para representar el impacto. Los componentes marcados con rojo son aquellos afectados por el cambio principal y que requieren alguna acción a tomar, los anaranjados son los que producen el cambio y los verdes son los que tienen dependencia pero no son afectados y se pueden ignorar. Otro punto positivo de JRipples es que permite exportar la lista de dependencias y abrirla en un Excel para documentar los resultados del análisis de impacto.

PaqueteClaseAcción a tomar
com.javausergroupcr.springboot.app.models.entityClientePruebas de unidad
com.javausergroupcr.springboot.app.controllersClienteControllerPruebas de unidad
com.javausergroupcr.springboot.app.models.serviceClienteServiceImpl
com.javausergroupcr.springboot.app.controllersFacturaController
com.javausergroupcr.springboot.app.models.daoIClienteDao
com.javausergroupcr.springboot.app.models.entityFactura
com.javausergroupcr.springboot.app.models.serviceIClienteService
Ejemplo de la tabulación de los resultados, el listado de los elementos «Unchanged» es opcional.

Mejores prácticas

  1. Determinar si se requiere modificar o eliminar alguna interfaz de usuario.
  2. Evaluar si se deben realizar pruebas de unidad, pruebas de aceptación o pruebas de regresión.
  3. Identificar el impacto en aplicaciones externas, incluyendo cambios en las configuraciones y comunicaciones.
  4. Informar el resultado del análisis de impacto a las partes interesadas antes de iniciar a desarrollar una solicitud de cambio, para ayudarles a decidir si lo aprueban o lo descartan. Es preferible durar un par de horas haciendo un análisis, en lugar no poder cumplir con la estimación acordada con el cliente por modificaciones no planeadas que se encontraron sobre la marcha.

JARs de Lucene: https://sourceforge.net/projects/jripples/files/latest/download

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *