5to Debate ISSADIO 21/10

Los invitamos a la edición número 5 de ISSADIO. Debates y exposiciones sobre temas actuales relacionados con el desarrollo de software.
Estos son los temas y expositores de la próxima reunión, como siempre en UNTREF / SADIO el 21/10 en Galerías Pacifico de 9.30 (café) a 12.30 (estrictos).


¿Es posible certificar ISO 9001 en serio usando agilidad?

La vigencia de la llamada Ley de Software trajo como consecuencia un boom de certificaciones de calidad, y es de esperar que su renovación por otros 10 años, continuará el auge de las certificaciones. 

En este marco ISO 9001 aparece como la certificación más requerida. El atractivo de los beneficios puede hacer que la tentación de "prefabricar" la certificación sea muy grande.

Es totalmente factible hacer una implementación de un sistema de gestión de la calidad, con principios y métodos ágiles, que sea sencilla minimalista y compatible con las normas ISO y los principios ágiles. 

Alvaro Ruiz de Mendarozqueta

Alvaro Ruiz de Mendarozqueta se desempeña como consultor independiente en temas de gestión, calidad, desarrollo, estrategia, planificación, capacitación e ingeniería del software. También es consultor en la Fundación Sadosky. Es Consultor Ejecutivo en Liveware IS y Consultor Principal en Taller Technologies en temas de gestión, calidad e ingeniería del software. Tiene más de 34 años de experiencia en desarrollo de software en áreas tales como telecomunicaciones, finanzas, seguridad pública, sistemas embebidos y transporte. Docente de posgrado en UTN FRC y UTN FRSF.v

Entendamos a la TI de hoy

Dado el crecimiento y la relevancia que han adquirido en la actualidad las Tecnologías de la Información, los responsables de áreas de TI tienen el desafío de alinearse con el negocio, generar valor y demostrarlo. Para poder hacerlo, es necesario evolucionar en el gobierno y la gestión de TI. Pero, como siempre, primero hay que saber de qué se trata.

¿Gobierno y gestión, es lo mismo? ¿En qué se diferencian? ¿Qué comprende cada uno? ¿Existe algún marco de referencia que los abarque? ¿Por dónde se empieza?

Guillermo Angelani

Profesional de nivel gerencial de Tecnología Informática, con más de treinta y cinco años de trayectoria. Ha conducido diferentes áreas de TI responsables de planificar, implementar y dar soporte a servicios de misión crítica. Además de la conducción, ha llevado a cabo profundas reorganizaciones de estas áreas, fijando no sólo el marco de gestión sino también su rumbo estratégico, siempre sobre la base de metodologías, estándares y buenas prácticas de la industria. También ha liderado múltiples proyectos de TI de gran envergadura y exposición

Ser o parecer

Entre los elementos básicos a tener en cuenta, planificar y diseñar al gestionar un área de QC o pensar una estrategia de pruebas para un proyecto o servicio específicos, no podemos dejar de lado los ambientes y datos de prueba necesarios.

Ambientes y datos de prueba ocasionan en algunos casos preguntas como “¿Realmente se necesitan? ¿No puede ser la máquina del desarrollador / ambiente de desarrollo? ¿Por qué no Producción antes de liberar?  ¿Un equipo potente les es suficiente? ¿No pueden crear sus propios datos, o traer una base / archivos productivos? …”,
o directamente objeciones como “Nunca los hemos tenido; en nuestro caso no es necesario; saldrá muy caro…”

Afortunadamente estas preguntas y objeciones son cada vez menos frecuentes. Sin embargo, aún pueden aparecer, y es parte de nuestra misión al gestionar un área de pruebas o un proyecto / servicio dados, ocuparnos seriamente de ambientes y datos de prueba. Desde contestar adecuadamente las preguntas y objeciones, pasando por saber diseñarlos, solicitarlos y gestionarlos.
Ellos contribuirán a la fiabilidad de nuestras pruebas. En definitiva, lograremos que lleguen a Producción productos donde las pruebas realizadas serán más representativas de lo que ocurre en la realidad, deseablemente con menos fallas evidentes u ocultas.

Hemos aprendido y enseñado habitualmente que al menos tres ambientes bien diferenciados son los mínimos recomendables:

• Desarrollo. Donde trabajan los desarrolladores  con todas sus herramientas.
• Pruebas. Donde trabajan los testers con sus propias herramientas y datos.
• Producción. Donde trabajan los usuarios con sus datos y donde las aplicaciones conviven con otras.

Y que deseablemente se agrega un cuarto ambiente entre Pruebas y Producción:

• Pre-producción. Donde pueden trabajar los usuarios con copias de sus datos durante las pruebas de aceptación, existirán algunos de los sistemas con los que convivirá la aplicación, se pueden dar capacitaciones y demostraciones sobre los productos a liberar o modificados, y se pueden realizar pruebas de requerimientos no funcionales.

Y la disyuntiva que suele plantearse es la del título de este artículo:
Ser o parecer.

• ¿Puede nuestro ambiente de Pruebas ser Desarrollo / Producción / Pre-producción, tal vez utilizando distintas instancias de los datos?
• ¿Pueden nuestros datos de prueba ser directamente los datos de Producción?
• ¿Cuánto se tienen que parecer los ambientes que nos suelen ocupar, Pruebas y Pre-producción, al ambiente de Producción?
• ¿Cuánto se tienen que parecer los datos de prueba que generemos a los datos productivos?

Lamentablemente no tenemos una respuesta terminante y taxativa a estas preguntas, sólo que deberían “parecerse tanto como sea posible”.

Y esa recomendación parte del sentido común, y de la necesidad y conveniencia de llevar a cabo pruebas que realmente diagnostiquen la calidad de los productos entregados. Al margen de considerar que muchos tipos de pruebas directamente no tienen sentido en ambientes o con volúmenes o variedad y tipo de datos no similares a Producción.

Como ya he mencionado, ambientes y/o datos mal configurados o estructurados, generan riesgos respecto a la calidad de nuestras pruebas. Entonces, ¿por qué no gestionar esos riesgos como gestionamos los del producto de software que estamos probando? ¿por qué no justificar la inversión necesaria en adquirir / configurar los ambientes y generar los datos de prueba, en función al riesgo de pérdidas potenciales para el negocio que ocasionan  pruebas no fiables?

Poder pensar, planificar y luego gestionar, ambientes y datos con los que controlamos la calidad de los productos de software, ayuda a mitigar adecuadamente los riesgos identificados en relación al producto, a su contexto y a su evolución. Entonces:

• Ajustemos los diseños y estrategias a lo importante para mitigar los riesgos y potenciales pérdidas, dentro de las restricciones existentes.
• Justifiquemos y negociemos alternativas para los ambientes y datos de prueba, mostrando los riesgos de cada una.

Hasta la próxima
Pilar

Nota: imagen tomada de faro - http://www.e-faro.info/

El mapa y el camino - Supuestos y realidad

Hicimos nuestra estimación de la prueba, planificamos para lograr el objetivo buscado y nos preparamos a ejecutar.....
Luego viene la realidad, con sus detalles y cambios. 
Podemos adelantarnos a algunas cosas? Sirven los supuestos? 

Se presentan algunas ideas simples a tener en cuenta al estimar el esfuerzo y el tiempo y la posterior planificación de una prueba de producto de software. 
No nos centraremos en estimar, sino en supuestos y riesgos. 
Son pequeñas ayudas de todos los días, para tener en cuenta al desarrollar la estimación y en la posterior planificación del trabajo de prueba.

Proceso de estimación y presupuesto original

Para hacerlo más comprensible, tomemos como escenario una contratación en la modalidad de proyecto de prueba, no "body shopping" y siguiendo un proceso tradicional. La estimación puede (y deseablemente debe) tomar como base, entre otras cosas:

• El Alcance, que determina la cantidad de trabajo a hacer en función a la cantidad de requerimientos funcionales y no funcionales y contextos a probar
• Los riesgos y en función de ellos, la rigurosidad de la prueba. 
• La experiencia o seniority de los perfiles requeridos en el Equipo de prueba y los del resto de los equipos de trabajo intervinientes.
• El proceso que seguirá el Desarrollador u otro equipo de trabajo, para producir los entregables objeto de la prueba.
• La calidad esperada de los entregables a recibir.
• .....

Factores que pueden alteran el presupuesto original

1. Errores propios de la estimación del Equipo de prueba

El equipo puede  introducir errores en su estimación provenientes de:

• Diferencias entre los estimadores.
• Interpretaciones equivocadas de la complejidad de las tareas, producto de la poca información disponible al momento de la estimación.
• .....

Estos desvíos no deberían incidir en más de un porcentaje relativamente bajo, 5% a 10% por ejemplo, del esfuerzo y/o calendario original, y no alterarán el presupuesto original para el Cliente. 
En otras palabras, si a este nivel nos equivocamos, lo tendremos que asumir.

2. Otras fuentes de desvíos

Los siguientes puntos, identifican otras posibles fuentes de desvíos, ya no imputables al Equipo de prueba. 
Cada uno de ellos debería figurar como un Supuesto en el propuesta, de modo que un cambio en el supuesto pueda justificar un cambio en la propuesta original.

Fuentes de Desvío	Desvío que puede generarse	Comentarios
Entregas fuera de fecha	Esfuerzo no productivo incurrido por entrega tardía por parte del Desarrollador u otro equipo de trabajo, o bien entrega de menos productos que los planificados, estando el personal de prueba ya asignado.	El Equipo de Prueba deberá tratar de utilizar estos tiempos muertos en tareas que puedan adelantarse, si bien esto no siempre es posible.
Desvíos por cambio de Alcance y/o cambio de Requerimientos	Esfuerzo y/o tiempo adicional por cambio o extensión de los requerimientos funcionales y/o no funcionales, o contextos de prueba, en cantidad y/o complejidad.
Desvíos por re-trabajo o baja calidad de los entregables	Esfuerzo y/o tiempo adicional por productos entregados al Equipo de Prueba con calidad inaceptable, o incompletos. La columna siguiente muestra los parámetros y supuestos que se pueden tomar en cuenta para la planificación y para explicitar en la propuesta.	Cantidad de entregas: -Plan desarrollado en base a una cantidad de entregas determinada. Un indicador de baja calidad es un número de entregas mayor al planificado. Parámetros de estimación: -Cantidad de entregas esperadas -Frecuencia esperada de las entregas Tiempo de estabilización: -Calculado en base a una calidad comprometida de la entrega. Una calidad más baja redunda en un mayor tiempo de estabilización. Parámetros de estimación: -Tiempos de estabilización planificados - Desvíos aceptables Cantidad de Defectos Críticos: -Defectos críticos abiertos y no corregidos, que impiden la continuidad de la prueba. Parámetro de estimación: -Cantidad de defectos críticos esperados Entrega en fecha, pero no con la calidad esperada: -Producto con fallas que extienden el tiempo entre la entrega al Equipo de Prueba y la liberación al próximo paso. Supuesto en la estimación: -Calidad del entregable recibido igual a la esperada Capacitación y seniority de los grupos de trabajo: -Se asumen equipos de trabajo de seniority equivalente; una falla en esa nivelación produce estimaciones erradas por las reiteradas devoluciones de los productos. Supuesto en la estimación: -Nivel de seniority esperado de los recursos de los distintos equipos de trabajo
Desvíos por incremento de horas de supervisión	Esfuerzo adicional debido al crecimiento no planificado de la cantidad de recursos del Equipo de Prueba, que causa aumento en la supervisión requerida.	Un líder no puede gestionar adecuadamente y en forma simultánea a más de 5 a 8 recursos. Se recomienda que en estos tamaños de equipo, ese líder no tenga tareas operativas asignadas, adicionales a la supervisión.
Desvíos por supuestos incorrectos de otros equipos de trabajo	La estimación de esfuerzo del Equipo de prueba, además de lo detallado, toma en cuenta un porcentual del esfuerzo del Desarrollador u otro equipo de trabajo como base para calcular su esfuerzo.	Una estimación errónea del esfuerzo de los desarrolladores arrastra un error también en la estimación de la prueba. Ejemplo: el esfuerzo de prueba es el 40% del esfuerzo de desarrollo.
Otros desvíos con motivo de extensiones / eventos desconocidas en la planificación original	El desplazamiento del calendario se impacta con eventos no previsibles en el momento de la planificación original.	Desplazamientos por: - Licencias del personal por vacaciones. -Requerimientos del personal por urgencias u otros proyectos. - ....

3. Conclusión

Lo anterior no pretende ser una lista exhaustiva y se recomienda seguir completándola con la experiencia de cada uno. 

Tampoco es una lista de excusas ante problemas de desplazamientos en los objetivos del proyecto que todos debemos colaborar a que se logren. Simplemente intenta explicar supuestos que solemos hacer y la diferente realidad que podemos encontrar.

Algunas de estas fuentes de desvíos podrán expresarse como riesgos, otras como supuestos,  en nuestras propuestas y compromisos de trabajo con los clientes, pero lo importante es recordarlos  al momento de tener que administrar y explicar cambios a la propuesta original.

Finalmente todo, mapa y camino, formará parte de las lecciones aprendidas para el próximo proyecto. 


Nota: Revisión del artículo originalmente publicado en excelza en marzo 2010.