Tarea: Obtener confirmación de comprobabilidad
El objetivo de esta tarea es definir, priorizar y promover las necesidades y los beneficios de la comprobabilidad
Objetivo

El objetivo de esta tarea es:

  • Promocionar la creación de software que se pueda probar para satisfacer las necesidades del esfuerzo de prueba
  • Promocionar y dar soporte al uso de técnicas y herramientas de automatización apropiadas
Relaciones
Pasos
Examinar las necesidades de comprobabilidad
Objetivo:  Conocer mejor las necesidades de valoración e implementación de la prueba que deben satisfacerse mediante el proceso de entrega de software o a través de la arquitectura y el diseño del software.  

Estudie la arquitectura de automatización de pruebas y las especificaciones de la interfaz de prueba para conocer mejor las necesidades de valoración e implementación de la prueba. Concretamente, conozca las restricciones que estas necesidades plantearán en el proceso de entrega de software o en la arquitectura y diseño del software.

Valorar el impacto y establecer prioridades
Objetivo:  Identificar las necesidades de comprobabilidad que son más importantes para el esfuerzo de prueba y promover su resolución antes que las necesidades menos importantes.  

Estudie las necesidades de comprobabilidad y realice un análisis básico del impacto que tiene sobre el esfuerzo de prueba el no haber satisfecho la necesidad. Considere también la posibilidad de llevar a cabo un análisis básico del esfuerzo potencial que debe hacer el equipo de desarrollo para investigar y proporcionar una solución a la necesidad. Para cada necesidad, identifique soluciones alternativas potenciales que tengan un impacto menor sobre los equipos de desarrollo.

Utilizando esta información, confeccione una lista en la que tengan prioridad las necesidades con un gran impacto sobre el esfuerzo de prueba si no se cumplen, aunque no tengan una solución alternativa. De esta manera evitará malgastar recursos de desarrollo valiosos en necesidades de comprobabilidad menos esenciales y podrá aprovecharlos para los que realmente son importantes.

Definir los beneficios de la comprobabilidad
Objetivo:  Poder vender el valor de las necesidades de comprobabilidad a los interesados en términos básicos de coste-beneficio.  

Si pide al equipo de desarrollo que desarrolle software con una provisión específica para el esfuerzo de prueba, añadirá requisitos y restricciones adicionales al esfuerzo de desarrollo; esto equivale básicamente a más trabajo y mayor riesgo y complejidad para el equipo de desarrollo. Algunos equipos de desarrollo considerarán que el diseño de la comprobabilidad está fuera del ámbito de su responsabilidad. En otros casos, las necesidades de comprobabilidad deberán competir por los recursos de desarrollo con las necesidades y requisitos del cliente, que normalmente tendrán más prioridad. Como tales, deberá "vender" los beneficios de las necesidades de comprobabilidad al gestor de proyectos, al arquitecto de software y a otros interesados del equipo de desarrollo.

Formule un análisis de los beneficios de cada necesidad de comprobabilidad para la que desea obtener confirmación. Busque artículos y estudios que den soporte al valor de la necesidad de comprobabilidad y utilice las estadísticas del ROI, si están disponibles. Considere los beneficios en términos del valor proporcionado al equipo de desarrollo; ¿qué información de evaluación útil podrá proporcionarles que no se podría proporcionar en caso de no satisfacerse esta necesidad? ¿De qué manera esta información le facilitará o le permitirá más eficacia a la hora de proporcionar al equipo de desarrollo comentarios puntuales, precisos, detallados o útiles durante cada ciclo de creación? ¿Esta necesidad proporciona a los miembros del equipo de desarrollo una característica útil que podrán utilizar en su propio esfuerzo de prueba o en un futuro diagnóstico de anomalía de software? En el caso de competencia con las necesidades del cliente, considere cómo puede demostrar que el hecho de proporcionar de buen principio una solución a la necesidad de comprobabilidad ofrecerá más oportunidades para que los requisitos del cliente tengan soporte en posteriores ciclos de creación.

Identificar y comprometerse con los defensores de la comprobabilidad
Objetivo:  Formar alianzas con interesados importantes que aboguen por la creación de software que se pueda probar y den soporte a las necesidades de los equipos de prueba en este sentido.  

Dado que potencialmente impondrá trabajo o riesgo adicional sobre el equipo de desarrollo, debe identificar y comprometerse con aquellos interesados influyentes que tengan la capacidad de aprobar u ordenar el soporte de la comprobabilidad. Hágalo lo antes posible, antes de promover activamente las necesidades de comprobabilidad a las que desea dar soporte.

Los tres interesados más importantes son el arquitecto de software, el gestor de proyectos y el representante del cliente. Dedique tiempo con el arquitecto de software y promueva al valor de crear una arquitectura de software que dé soporte a la comprobabilidad. Dedique tiempo con el gestor de proyectos y promueva los beneficios de la comprobabilidad en términos de productividad del equipo de prueba y respuesta rápida de la información de evaluación. Anime al cliente a dar valor a un producto de calidad que se entrega.

Promover las necesidades y los beneficios de la comprobabilidad
Objetivo:  Informar a los interesados pertinentes de las importantes necesidades de comprobabilidad del esfuerzo de prueba y obtener su soporte para la comprobabilidad.  

Es importante promover las necesidades de comprobabilidad de la forma correcta. Cada combinación de interesados formados por el gestor de proyectos, el equipo de desarrollo y el cliente tiene su propia dinámica social y cultura, por lo que es importante ser sensible a ello cuando promueva las necesidades de comprobabilidad. Como normal general, no organice una "campaña" de comprobabilidad formal si el equipo es relativamente despreocupado e informal; y no utilice un enfoque informal en un proyecto con un nivel alto de ceremonia.

En algunos casos, una sesión de "tormenta de ideas" (brainstorming) de colaboración es un formato de presentación útil, donde la necesidad se presenta como un reto al equipo de desarrollo y se anima a sus miembros a identificar soluciones creativas que satisfagan la necesidad o necesidades de comprobabilidad. Esto les anima a considerar la solución como de su propiedad y fomenta un sentimiento de colaboración en el esfuerzo.

El tiempo también es importante en este paso. Como regla general, debe intentar identificar y promover lo antes posible las necesidades de comprobabilidad más importantes, generalmente durante la fase de elaboración y, cuando sea posible, en la fase inicial. Cuando las necesidades de comprobabilidad se plantean en estas fases iniciales del proyecto, el equipo normalmente es más pequeño y es más receptivo al cambio. También es más fácil incluir estas necesidades durante el desarrollo del diseño ya que normalmente la revisión que se requiere es mínima.

Una buena manera de identificar las necesidades de comprobabilidad y presentarlas de una forma positiva y menos "oficial" es hacer que el equipo de prueba ofrezca sus servicios para evaluar las actividades de prueba de concepto y para evaluar la selección de componentes de terceros que se utilizarán en la tarea de desarrollo. Concretamente, la implicación de los equipos de prueba durante la selección de componentes de base de datos, control de UI o selección de componentes, componentes de middleware, etc. significa que las necesidades de comprobabilidad pueden utilizarse como un aspecto de los criterios de selección de componentes. Por ejemplo, en muchos casos los equipos de desarrollo apenas se preocupan por la biblioteca de widgets de la UI que deben utilizar; si una biblioteca se puede probar más que otra, el equipo de desarrollo se alegrará de poder seleccionar la biblioteca de widgets que se puede probar más.

Si ha tenido problemas para identificar o comprometerse con los defensores de la comprobabilidad, posiblemente deberá considerar un enfoque que introduzca los cambios más gradualmente de modo que sean potencialmente menos arriesgados y constituyan bloques más pequeños de esfuerzo, o quizás deberá escalar las necesidades de comprobabilidad más importantes como problemas críticos del proyecto que impiden que el desarrollo satisfactorio del esfuerzo de prueba hasta que se resuelven. En este último caso, recomendamos que considere detenidamente todas las opciones antes de tomar una decisión sobre este curso de acción.

Obtener el compromiso para proporcionar soporte y mantener la comprobabilidad
Objetivo:  Obtener un acuerdo para que el equipo de desarrollo siga dando soporte y manteniendo las características de comprobabilidad.  

Es importante garantizar que las necesidades de comprobabilidad se consideren de la misma manera que cualquier otro requisito o restricción de la tarea de desarrollo. Debe tener la seguridad que las características de seguridad que están disponibles hoy no se abandonarán mañana.

En algunos casos, cuando se intenta conseguir este compromiso puede ocurrir que el equipo de desarrollo se niegue a desarrollar o dar soporte a las necesidades de comprobabilidad. Aunque esto pueda ser desalentador, es mejor ser consciente de la situación y afrontar esta realidad lo antes posible; es mucho peor haber empleado una gran cantidad de tiempo y esfuerzo desarrollando una implementación de prueba para la que el equipo de desarrollo abandonará luego el soporte no comprometido.

Fomentar la resolución de problemas de comprobabilidad
Objetivo:  Supervisar y abogar por la resolución de los problemas de comprobabilidad. 

Aunque el equipo de desarrollo esté de acuerdo en proporcionar el soporte necesario para las necesidades de comprobabilidad del esfuerzo de prueba, es importante que usted participe activamente en el diseño, implementación y finalización de este trabajo. No abandone su interés simplemente porque el equipo de desarrollo haya aceptado hacerse cargo de las necesidades de comprobabilidad o haya empezado a trabajar en una solución; debe asegurarse de que se desarrolla una solución apropiada en el tiempo previsto.

Esté preparado y disponible, junto con los otros miembros del equipo de prueba, para contestar las preguntas de los equipos de desarrollo y ofrezca su colaboración para evaluar los prototipos inmediatamente después de que se hayan creado. Proporcione comentarios constructivos y muestre entusiasmo por el esfuerzo que el equipo de desarrollo ha dedicado en ayudarle a satisfacer sus necesidades. Haga que miembros clave de su personal faciliten o participen en talleres de diseño para las necesidades de comprobabilidad más complejas, pero evite que su equipo tenga un papel predominante o quiera controlar el espacio de soluciones del proceso de diseño por encima de los desarrolladores.

Cuando surjan problemas y crea que éstos no reciben la atención adecuada, o no se abordan con la celeridad necesaria, exprese su preocupación al arquitecto de software y al gestor de proyectos. Haga que el gestor de proyectos registre un problema en la lista de problemas del proyecto, si es necesario.

Evaluar y verificar los resultados
Objetivo:  Verificar que la tarea se ha realizado correctamente y que los productos de trabajo resultantes son aceptables. 

Ahora que ha terminado el trabajo, se recomienda verificar que el trabajo tenía el valor suficiente y que no sólo ha gastado una gran cantidad de papel. Debe evaluar si el trabajo tiene la calidad correcta y si es lo suficientemente completo para que resulte útil a aquellos miembros del equipo que vayan a utilizarlo posteriormente como entrada de su trabajo. Siempre que sea posible, utilice las listas de comprobación proporcionadas en RUP para verificar que la calidad y la completitud son lo "suficientemente buenas".

Fomente la participación en la revisión del trabajo interno por parte de las personas que realizan tareas basadas en los resultados de su trabajo. Hágalo mientras todavía tenga tiempo para realizar acciones para solucionar sus problemas. También debe evaluar su trabajo en los productos de trabajo de entrada clave para asegurarse de que los ha representado de forma precisa y suficiente. Para ello, es muy útil hacer que el autor del producto de trabajo de entrada revise su trabajo.

Recuerde que RUP es un proceso de entrega iterativo y que en muchos casos los productos de trabajo evolucionan con el tiempo. Como tal, no siempre es necesario (y a veces es contraproducente) formar completamente un producto de trabajo que sólo se utilizará de forma parcial o que no se utilizará en absoluto en un trabajo inmediatamente posterior. Esto se debe a que existe una alta probabilidad de que la situación alrededor del producto de trabajo cambie (y que las suposiciones realizadas cuando se creó el producto de trabajo se demuestre que son incorrectas) antes de que se utilice el producto, lo que da como resultado un esfuerzo inútil y una revisión costosa. Asimismo, evite la trampa de invertir demasiados ciclos en la presentación en detrimento del valor del contenido. En entornos de proyecto en los que la presentación tenga importancia y un gran valor económico como entregable del proyecto, puede utilizar un recurso administrativo para ejecutar tareas de presentación.



Propiedades
Varias apariciones
Condicionado por sucesos
Continuo
Opcional
Planeado
Se puede repetir