Diferencia entre revisiones de «Automatizacion De Metricas De Producto»

De Dos Ideas.
Saltar a: navegación, buscar
(Página nueva: ==Contexto== Un proyecto de desarrollo de software que precisa mejorar la calidad interna, la mantenibilidad y la operación continua del producto. El proyecto ya debe poseer [[Auto...)
 
 
Línea 46: Línea 46:
  
 
[[Herramientas Para Metricas De Producto]]
 
[[Herramientas Para Metricas De Producto]]
 
  
 
==Reconocimientos==
 
==Reconocimientos==
Línea 57: Línea 56:
 
* (RICHARDSON e GWALTNEY, 2005)
 
* (RICHARDSON e GWALTNEY, 2005)
 
* (TATE, 2005)
 
* (TATE, 2005)
 +
 +
[[Category: Métricas]]

Revisión actual del 01:36 8 sep 2009

Contexto

Un proyecto de desarrollo de software que precisa mejorar la calidad interna, la mantenibilidad y la operación continua del producto.

El proyecto ya debe poseer Automatizacion De Build.

Problema

La calidad interna de un producto de software tiene que ser evaluada a medida que se construye. Sin ella es difícil de determinar otros factores calidad, además de asistir a las necesidades funcionales de clientes. Todavía queda el riesgo de graves defectos que pueden afectar al funcionamiento y mantenimiento del producto a lo largo de su ciclo de vida y son difíciles de detectar sólo a través de pruebas funcionales.

Fuerzas

  • Diversos software puede cumplir con los requisitos funcionales para las reglas de negocio que deben implementar, pero fallan en satisfacer los requisitos no funcionales como comprobabilidad y mantenibilidad.
  • Las pruebas realizadas en el software no necesariamente se llevarán a cabo en líneas de código más críticas de la solución.
  • Reglas, patrones y convenciones de programación no son siempre seguido por los desarrolladores. Existe un alto costo en la revisión por pares para detectar errores básicos como la falta de organización de código y la falta de comentarios.
  • La complejidad interna del código, si no se controla, aumenta la entropía del software y torna su mantenimiento más costoso, difícil y propenso a defectos.

Solución

Utilice herramientas de análisis estático y dinámico de código en el producto para verificar su calidad interna en forma ágil y continua.

Raciocinio

El análisis estático del código es un excelente método para la detección de defectos difíciles de ser encontrados por los métodos tradicionales de prueba unitarias y de aceptación. Algunos de los errores comunes que el análisis de estática puede detectar:

  • Declaraciones correctas para un compilador, pero que pueden generar defectos en tiempo de ejecución.
  • Código que no se utiliza, por ejemplo, variables locales, parámetros y métodos privados nunca llamados.
  • Código duplicado en los diferentes métodos de diversas clases.
  • Expresiones complicadas en métodos con alta complejidad ciclomática.
  • En software orientados a objetos, detección de clases con alto acoplamiento y cohesión baja.

El análisis dinámico, especialmente a través del análisis de la cobertura de código, permite la verificación del porcentaje de código accesado mediante las pruebas unitarias y de aceptación. Le ayuda en la identificación de los módulos de software que tienen poca cobertura realizada por las pruebas.

Contexto Resultante

El proyecto posee métricas decalidad interna de código que pueden ser ejecutadas cuando sea necesario.

La Automatizacion De Build debe tener tareas específicas para realizar la generación de informes de análisis estático y para la instrumentación del código, teniendo en vista la necesidad de generar informes de cobertura. Con la Automatizacion De Build lista para ejecutar el análisis estático y la cobertura se pueden generar y almacenar los informes con su historia en el proyecto siempre que la Integracion Continua se ejerza.

Patrones Relacionados

Ver también

Herramientas Para Metricas De Producto

Reconocimientos

  • (BECK, 2004)
  • (COCKBURN, 2001)
  • (MCCONNELL, 2004)
  • (MCGARRY, 2002)
  • (MUGRIDGE e CUNNINGHAM, 2005)
  • (RICHARDSON e GWALTNEY, 2005)
  • (TATE, 2005)