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.
|
|