martes, 4 de diciembre de 2012

No más “Dependes”


Año 2011. Presentación de resultados anuales de la mejora de la calidad como resultado de la operación de un equipo de pruebas sobre el proceso de desarrollo.

Consultor de pruebas: El resultado de las pruebas realizadas durante el año 2011 es el siguiente:
·       256 defectos detectados en las pruebas de Sistema realizadas por el equipo de pruebas (un 6% menos que en 2010).
·       127 defectos detectados en las pruebas de Aceptación realizadas por el equipo de Negocio (un 2% menos que en 2010).
·       38 incidencias detectadas en Producción (un 42% menos que en 2010).

Cliente: Eso está muy bien  J . ¿Eso quiere decir que hemos aumentado la calidad de los desarrollos que han realizado nuestros proveedores?

Consultor de pruebas: Depende…

Cliente: ¿De qué depende?

Consultor de pruebas: Depende del volumen de desarrollos que se hayan realizado en el 2010 y los que se hayan realizado en el 2011.

Cliente: No hay problema, sabemos que en el 2010 realizamos 35 proyectos y en 2011 hicimos 29 proyectos. …¿Eso quiere decir entonces que hemos empeorado la calidad? L

Consultor de pruebas: Depende…

Cliente: ¿De qué depende?

Consultor de pruebas: Depende del volumen de desarrollos que representen esos proyectos en cada año. Pueden haber sido menos número de proyectos pero proyectos más grandes.

Cliente: No hay problema, sabemos que en el 2011 nos gastamos 300.000 € más que en 2010, porque el proveedor de desarrollo hizo 7.000 horas-hombre más que en 2010. …¿Eso quiere decir entonces que hemos mejorado la calidad? J

Consultor de pruebas: Depende…

Cliente: ¿De qué depende? :-X (enfadado)

Consultor de pruebas: Depende del volumen de desarrollos que se han realizado con ese exceso de horas-hombre cada año. Pueden haber necesitado más horas-hombre porque, como las tarifas están bajando, el proveedor haya tenido que poner gente con menos experiencia y más barata, y esta gente no sea capaz de ir tan rápido como los expertos.

Cliente: ¿Entonces qué?

Consultor de pruebas: Como nuestras valoraciones no son subjetivas ni se mueven por impresiones solo te puedo dar los datos absolutos. Lo que se podría hacer el año que viene para evitar estas incertidumbres es “pesar” en Puntos Función el software realizado durante el 2011, y hacer lo mismo con el del 2010 de forma retroactiva para poder comparar.


Año 2012. Presentación de resultados anuales de la mejora de la calidad como resultado de la operación de un equipo de pruebas sobre el proceso de desarrollo.

Cliente: ¿Sabemos ahora si la calidad ha mejorado o ha empeorado? Espero que haya desaparecido la palabra “depende” del informe…

Consultor de pruebas: El resultado de las pruebas realizadas durante el año 2012 es el siguiente: 295 defectos detectados en las pruebas de Sistema realizadas por el equipo de pruebas.

Cliente: ¡Un 15% más que en 2011 en valor absoluto! Eso es demasiado…

Consultor de pruebas: Como ahora medimos el volumen de software en Puntos Función, sabemos que en valor relativo realmente hemos empeorado un 7% respecto al año 2011, porque hemos pasado de tener 0,10 defectos por Punto Función en 2011 a tener 0,11 defectos por Punto Función en 2012.

Cliente: Bueno dicho así no es tan malo como parecía…

Consultor de pruebas: Afortunadamente los errores se han detectado a tiempo porque el equipo de Negocio ha detectado en las pruebas de Aceptación 105 defectos.

Cliente: ¡Eso es un  17% menos que en 2011 en valor absoluto! Eso es estupendo…

Consultor de pruebas: Es incluso mejor que eso. Realmente es un 23% mejor que en 2011 en valor relativo al tamaño, porque hemos pasado de detectar 0,05 defectos en Aceptación por Punto Función en 2011 a detectar 0,04 defectos por Punto Función en 2012.

Cliente: Mejor todavía. ¿Y qué ha pasado en Producción?

Consultor de pruebas: Los usuarios han reportado 40 incidencias.

Cliente: ¡Eso es un 5% más que en 2011 en valor absoluto! No me extraña que los usuarios estén tan enfadados…

Consultor de pruebas: Aunque en valor absoluto sea así, la realidad es que es un 3% mejor que en 2011 en valor relativo al tamaño, porque los usuarios han pasado de reportar 0,0152 incidencias por Punto Función en 2011 a reportar 0,0148 incidencias por Punto Función en 2012.

Cliente: Genial  J   . Ahora ya tenemos toda la información para conocer lo que está pasando realmente y podemos enfocarnos en seguir mejorando la calidad, porque tenemos datos que no nos pueden discutir, y eso nos pone en una situación mejor para saber exactamente dónde actuar.

5 comentarios:

  1. Como me recuerda a un dibujo de la Guía ISO 20000. Pag. 29.

    Si alguien quiere verlo puede descargarla aquí

    http://gestionhumorti.blogspot.com.es/p/publicaciones.html

    ResponderEliminar
  2. Cambiar "depende" por "relativo a" no creo que aporte mucho más. Eso si, es un término politicamente correcto, lo mezclas con cifras y añades el verbo bajar y...
    se va pareciendo demasiado en el modo en que los políticos se refieren a nuestra monstruosa tasa de paro.
    por ejemplo:El ritmo de crecimiento de la tasa de paro ha bajado un 0.2% respecto/relativo al mismo periodo del año pasado.

    El padre de un amigo mio, que era profesor de historia, en una ocasión me respondío de esta guisa cuando le hable de promedios:

    Si pones la cabeza en el horno y los pies en el congelador, en promedio estas bién ?
    Una presentación de resultados anuales debería ser capaz de identificar
    que estamos bien en términos generales pero que tenemos problemas en...la cabeza y los pies en el ejemplo anterior.

    No digo que se deba evitar hablar de ratios/promedios, pero sí que sean el gran _criterio_.

    Una presentación de resultados anuales me la imagino de otra forma (ehhh que nunca he hecho ninguna y la ignorancia es muy atrevida)
    A primeros de año teníamos identificados "x" problemas y tomamos las siguientes medidas/decisiones.
    A lo largo del año, ha ocurrido "y". Al final de año hemos solventado tantos problemas,
    han aparecido "z" otros. Nuestra previsión para el año que viene es... y recomendamos ...

    La reflexión final es para el punto función como medida del volumen de software.
    Einstein definió: el tiempo es lo que mide un buen reloj.
    Desgraciadamente no tenemos definición para el kilo de software, para el kilo de calidad de software
    ni aparato o criterio aceptado que permita medirlo.
    Si, se han propuesto algunas opciones, puntos función,LOC ...pero a día de hoy ninguna ha cuajado como estandar en la industría.

    Mi opinion personal en este aspecto, es que la clave no está en medir la complejidad o volumen del software.
    Esto lo podemos medir, como mucho, a posteriory del desarrollo.
    Para que un criterio triunfe tiene que ser capaz de predecir, a priory, los costes finales del kilo de SW. Aunque sea de forma basta.

    Tal vez se deba medir la proporcionalidad entre el trabajo/horas a invertir entre las distintas fases del ciclo de vida del SW.
    Algo asi como: si la toma de requisitos me cuesta 4 horas, el analisis me costara en promedio 10*4=40H
    Desarrollar los casos de test (7*tiempo de analisis). El esfuerzo de mantenimiento anual un 10% del coste del desarrollo inicial etc...

    Leñe, he caido en la trampa del promedio ;-)

    Yo quería hacer una critica constructiva... de verdad ...Sorry.
    Es que cuando escucho a Wagner, me pierdo.

    ResponderEliminar
  3. Antonio, primeramente quiero darte las gracias por tu participación y por tus opiniones.

    Voy a empezar comentando el final de tu argumentación: Los puntos Función.

    Es cierto que los puntos función llevan bastantes años en marcha y que les ha costado avanzar. En parte por algunos de los problemas que indicas pero afortunadamente han progresado bastante desde sus inicios en los años 80 hasta ahora. Tanto en las evoluciones realizadas al método como en la forma de aplicarlos.

    Afortunadamente los puntos Función actualmente son un estándar internacional (soportado por ISO/IEC) con un nivel de implantación a nivel internacional bastante amplio (aunque aún queda mucho por hacer para que esté totalmente generalizado). En España vamos por el mismo camino y empresas como Telefónica, Vodafone, Orange, Iberia, Mapfre, Verti, Endesa, Cepsa, Ericsson … , lo usan de forma más o menos habitual en sus organizaciones para distintas cosas (análisis de productividad, estimaciones, calidad, gestión de requisitos, gestión de proyectos,…)

    Respecto a medir el tamaño de los proyectos en LoC (Lines of Code) te recomiendo que leas este otro post: http://cuantovaleelkilodesoftware.blogspot.com.es/2012/10/la-loca-loca-loca-historia-de-las.html

    Si usas los esfuerzos, entonces puedes caer en la trampa de “pagar más al más torpe” como decía el director de informática de un gran banco.

    En cuanto a la presentación de resultados lo que indicas es correcto. El problema es cuando te preguntan ¿pero en qué situación estamos respecto al año pasado? Y entonces solo puedes decir “depende, depende, depende,…” porque comparando solamente los valores absolutos vas a tener una información en la mayor parte de casos falseada, porque para eso necesitarías que todos los años se realizase exactamente el mismo volumen de software. Y eso es imposible.

    Tienes razón que dar solamente promedios puede dar lugar a equivoco como el que comentaba el padre de tu amigo, o como el de las dos personas que se comen un pollo de promedio (y una de ellas no ha comido nada). Lo que ocurre es que esa información tienes que darla de forma global, acompañarla de datos de dispersión y además realizar un análisis top-down que permita bucear en los indicadores para saber realmente donde tienes el problema y que zonas del software que estás construyendo están dentro del horno o en el congelador.

    Por último te recomiendo que oigas mejor a Vivaldi, Albinoni o si te gusta algo más animado a Bruce Springsteen :-)

    ResponderEliminar
  4. Muy buen articulo, pedagógico y realista. [JOSE ANTONIO DEL RIO]

    ResponderEliminar

Related Posts Plugin for WordPress, Blogger...