Más con menos

Plus avec moinUna pregunta que podemos encontrar muy a menudo: ¿cómo mejorar la productividad de los departamentos de TI? En nuestros tiempos de crisis económica, de creciente competencia, de globalización, ¿cómo reducir aún más los costes? ¿dónde encontrar nuevas fuentes de optimización? En pocas palabras, ¿cómo hacer « más con menos » ?

Seguro que muchos pensarán « ¿Cómo mejorar la productividad de los desarrolladores y de los proyectos? » pero, creo que, cada vez más, son los departamentos de Producción que son más capaces de responder a esta pregunta, gracias a la virtualización.

Sigue leyendo

La deuda técnica y los consultores de Calidad

¿Sabes cual es mi broma favorita respecto a los consultores?

Un hombre entra en una tienda de animales y ve a un mono en una jaula con una etiqueta ‘Mono C – $ 2.000’. El dueño de la tienda se acerca y el cliente le pregunta: « Es caro su mono. ¿Qué tiene de especial? ». Y el dueño le dice « Es un mono que sabe programar en C. Muy bueno, es rápido, produce un código de calidad sin errores. A ese precio, es un buen negocio ».

El cliente mira una otra jaula con una etiqueta ‘Mono C++ – $3 000’. « Oye, este es aún más caro. ¿Qué sabe hacer? ». « Igual que el primero, pero con C++, un lenguaje Objeto, más complejo, pero también un programador muy bueno. Y conoce un poco Java ».

El cliente descubre una tercera jaula con una etiqueta ‘Mono – $5 000’. « Ah, este es tan caro como los otros dos. Debe ser muy bueno. ¿Qué puede hacer? ».

« Pues, la verdad que no lo sé », responde el dueño. « Pero él dice que es un consultor ». (1)

Sigue leyendo

El futuro de la Calidad de software

Volví a pensar en el post anterior sobre las medidas del esfuerzo de proyecto, y la estimación de los costes de desarrollo y de QA antes del inicio del proyecto, cuando encontré un anuncio en un foro donde se habla de medición de la Calidad de software, para una conferencia sobre el mismo tema.

Ya sabes, uno de esos eventos en los que diferentes expertos hacen una presentación sobre temas tales como ‘¿qué métricas para evaluar los proyectos’ o mesas redondas para hablar de ‘métodos para la estimación de los costes de desarrollo y de mantenimiento’.

El autor de este anuncio pidió a los miembros del foro qué temas de debate les gustaría que se trataran en esta conferencia, y esa pregunta ha desencadenado una serie de respuestas y reacciones que voy a resumir brevemente:

  • Basta, stop, alto, ya, deje las presentaciones y los ‘papers’ en « ¿Cómo medir la productividad en el mantenimiento de software? », « Medidas efectivas de riesgo » o « Uso de Function Points en la industria aeroespacial ».
  • Hace ya más de 35 años que usamos métricas y sin embargo los departamentos de TI continúan ignorando las medidas de Calidad de software y el número de proyectos que fallan o se retrasan es siempre mayor. Sigue leyendo

Evaluar el esfuerzo antes del proyecto

Vicente Merino preguntaba en el último post sobre la complejidad y el esfuerzo de QA: «¿Cómo evaluar el esfuerzo cuando no tienes ya código» y «¿Es posible decidir al principio del proyecto si es suficientemente importante para requerir un equipo de control de calidad independiente y formalizar un plan de pruebas? »

Imaginamos que eres responsable de TI en una empresa de telecomunicaciones. Por tanto, es de tu responsabilidad:

  • que los clientes puedan conectarse en el sitio web de la empresa para ver su factura, su número de puntos, adquirir nuevos servicios, un nuevo movil, etc.
  • que los empleados que atienden a estos clientes puedan conectarse al mismo sitio, sino también a otras aplicaciones para verificar la cuenta de un cliente, un problema de pago, etc.
  • pues que las aplicaciones comerciales permiten vender y que las aplicaciones financieras permiten cobrar. Sigue leyendo

Complejidad y esfuerzo de QA

En el post anterior, yo pregunté «¿Qué es una aplicación de gran tamaño? ‘Y propusé clasificar aplicaciones en tamaño ‘simple’, ‘medio’, ‘grande’ y ‘muy grande’ basándose en diferentes medidas de número de líneas de código (LOC) o de número de objetos .

Esta semana, otro ‘quizz’ del mismo tipo ‘¿Qué es una aplicación compleja? ¿Es posible evaluar el esfuerzo de pruebas en función de la complejidad de la aplicación?’ Sigue leyendo

Tamaño de aplicación

Ya se acabaron las vacaciones, es hora de volver a nuestros posts.

Tengo bastante ideas para esta nueva temporada, pero voy a empezar con un ‘quiz’.

Se te pide clasificar una aplicación según su tamaño, el número de líneas de código (LOC) o el número de objetos. ¿Cuál es tu estimación de una pequeña aplicación? Cuando dices que una aplicación es grande? Con qué valores crees que es ‘monstruosa’ o atípica?

Sigue leyendo

Benchmark de aplicaciones

Yo pensaba que el post anterior respecto a la evaluación de la calidad de una aplicación era el último de nuestra serie en el análisis de código Cobol con Sonar. Pero he descubierto esta semana un nuevo plugin eXcentia, muy útil: el Sonar Benchmark Plugin.

Este plugin permite una evaluación comparativa – un benchmark – de una aplicación con todo el código en tu repositorio de Sónar.

¿Te acuerdas de que hemos analizado diferentes aplicaciones Cobol, con las que he creado una View Sonar. Con esta View, hemos realizado una evaluación de la calidad de una aplicación, no la más voluminosa, pero que tenía un número importante de violaciónes.

Luego, hemos visto los valores que nos permiten realizar nuestra evaluación y proponer recomendaciones. Pero ¿como se mide nuestro proyecto con otras aplicaciones?

Esto es lo que vamos a hacer con este Benchmark Sonar plugin. Sigue leyendo

Auditoria de código Cobol con Sonar (2/2)

Hoy terminamos nuestra evaluación de la calidad del código Cobol analizado con el Sonar.

En el post anterior, hemos trabajado con las métricas que medían el tamaño del código, su complejidad, el nivel de documentación y de duplicación, lo que nos permitió formular algunas primeras recomendaciones a los responsables de esta aplicación. Sigue leyendo

Auditoria de código Cobol con Sonar (1/2)

La calidad de código de las aplicaciones es una preocupación constante desde siempre. Las malas prácticas de programación son responsables de defectos que impactan a los usuarios y los costes de mantenimiento. La Deuda Técnica, simple metáfora al principio, se ha convertido en una herramienta para medir la calidad y estos costes.

Unos cuantos años antes, los softwares que permiten la identificación de estos defectos eran raros y costosos. Hoy en día, herramientas Open Source tales como Sonar permiten que todos – equipos de proyectos, proveedores, consultores de Calidad, etc. – puedan detectar de manera sencilla y a buen precio estas malas prácticas.

El mundo Open Source ha sufrido durante mucho tiempo de una imagen de ‘geek’, porque primero fueron los entusiastas del mundo J2EE que utilizaron estas herramientas. Pero los tiempos cambian y ahora es posible analizar código Legacy como Cobol y ABAP con Sonar.

Este es el objetivo de nuestra serie de posts: demostrar que es posible evaluar la calidad de las aplicaciones Cobol sin saber nada del mundo Mainframe. Sigue leyendo