Tarea: Definir necesidades de valoración y rastreabilidad
En esta tarea se describe cómo definir los requisitos para la valoración y la rastreabilidad, así como la estrategia general que se seguirá.
Relaciones
Pasos
Identificar requisitos de valoración y rastreabilidad
Objetivo:  Comprender los entregables para el proceso de valoración de software y obtener los requisitos asociados. 

Revise el plan de iteración e identifique las necesidades de valoración específicas para este próximo volumen de trabajo. Pregunte a los interesados qué necesitan tanto de la valoración como de la rastreabilidad.

Además, considere si el esfuerzo de prueba se auditará formalmente durante o al final del esfuerzo de prueba. Los requisitos de la auditoría formal podrían necesitar el mantenimiento de documentación y registros adicionales como prueba de que se han llevado a cabo pruebas suficientes.

Considerar las restricciones
Objetivo:  Identificar las restricciones que afectarán a la capacidad (o necesidad) de implementar los requisitos.  

A pesar de que normalmente hay una lista interminable de "deseos" que pueden considerarse como requisitos para las estrategias de rastreabilidad y valoración, es importante centrarse en las "necesidades" más importantes que a) proporcionan información esencial al equipo del proyecto y b) pueden seguirse y medirse. Es poco probable que se disponga de suficientes recursos para que la estrategia proporcione más de lo que es esencialmente necesario.

Subtemas:

Nivel de calidad aceptable Ir a la parte superior de la página

Es importante identificar qué nivel de calidad se considerará "suficientemente bueno" y desarrollar una estrategia de valoración apropiada. Tenga en cuenta que a menudo las dimensiones de calidad crecen y decrecen en importancia y que los niveles de calidad aumentan y disminuyen ante los ojos de los interesados durante todo el ciclo de vida del proyecto.

Revise el plan QA, revise el plan de desarrollo de software y entreviste directamente a los interesados importantes para determinar qué es lo que ellos consideran debe ser un nivel de calidad aceptable.

Habilitación de procesos y herramientas Ir a la parte superior de la página

Aunque probablemente pueda imaginar un mundo de rastreabilidad y valoración sin esfuerzo a un nivel bajo de granularidad, la realidad es que resulta difícil y normalmente antieconómico implementar estos enfoques. Con el soporte de herramientas sofisticadas, todavía puede ser difícil y requerir mucho tiempo gestionar enfoques de rastreabilidad de bajo nivel; sin herramientas de soporte, es prácticamente imposible. El propio proceso de ingeniería de software podría poner restricciones a la rastreabilidad: por ejemplo, si se desea una rastreabilidad desde las pruebas a los requisitos de motivación, pero los propios requisitos no se están gestionando cuidadosamente, podría resultar imposible implementar esta rastreabilidad.

Considere las restricciones y limitaciones tanto de las herramientas como del proceso de ingeniería de software y elija un enfoque apropiado de rastreabilidad y valoración que pueda llevarse a cabo.

Considerar las estrategias posibles
Objetivo:  Identificar y resaltar una o más estrategias que faciliten el proceso de valoración necesario.  

Ahora que tiene una idea más clara de los requisitos de valoración y rastreabilidad, y de las restricciones que imponen sobre ellos el nivel de calidad deseado y el soporte de herramientas y procesos disponible, debe considerar las estrategias potenciales de valoración y evaluación que puede llevar a cabo. Para un tratamiento más detallado de las posibles estrategias, le sugerimos que lea el artículo de Cem Kaner titulado "Measurement of the Extent of Testing (medida del grado de prueba)" de octubre de 2000. (Obtener Adobe Reader)

Subtemas:

Análisis de la cobertura de la prueba Ir a la parte superior de la página

Existen muchos enfoques distintos para la cobertura de la prueba y ninguna medida de cobertura por sí sola proporciona toda la información de cobertura necesaria para formar una valoración de la magnitud o completitud del esfuerzo de prueba. Tenga en cuenta que diferentes estrategias de cobertura requieren más o menos esfuerzo de implementación, y con cualquier categoría de medidas concreta normalmente habrá una profundidad de análisis de la cobertura en la que resultará antieconómico registrar más información detallada.

Algunas categorías de medidas de cobertura de la prueba incluyen: requisitos, código fuente, reclamaciones de producto y estándares. Le recomendamos que considere la posibilidad de incorporar más de una categoría de cobertura en la estrategia de valoración de la prueba. En la mayoría de casos, la cobertura de la prueba hace referencia a la planificación e implementación de pruebas específicas en primera instancia. Sin embargo, las métricas de cobertura de la prueba y su análisis también son útiles considerarlas conjuntamente con el análisis de los resultados de la prueba o el análisis de defectos.

Análisis de los resultados de la prueba Ir a la parte superior de la página

Un enfoque habitual en el análisis de los resultados de la prueba consiste simplemente en hacer referencia al número de resultados que han sido positivos o negativos en forma de porcentaje del número total de pruebas ejecutadas. Nuestra opinión, así como la de otros profesionales de la comunidad de pruebas, es que este enfoque es simplista e incompleto a la hora de analizar los resultados de la prueba.

En su lugar, le recomendamos que analice los resultados de la prueba en términos de tendencia relativa a lo largo del tiempo. En cada ciclo de prueba, considere la distribución relativa de las anomalías de prueba en diferentes dimensiones como, por ejemplo, el área funcional que se está probando, el tipo de riesgos de la calidad que se están explorando, la complejidad relativa de las pruebas y los recursos de prueba aplicados a cada área funcional.

Análisis de defectos Ir a la parte superior de la página

A pesar de que los defectos en sí mismos están claramente relacionados con los resultados del esfuerzo de prueba, el análisis de los datos de defectos no proporciona ninguna información útil sobre el progreso del esfuerzo de prueba ni de la completitud o minuciosidad de dicho esfuerzo. Sin embargo, un error cometido por algunos equipos de prueba y gestores de proyectos debe utilizar el recuento de defectos actual para medir el progreso de la prueba o como un indicador de la calidad del software desarrollado. Nuestra opinión, así como la de otros profesionales de la comunidad de pruebas, es que este enfoque no tiene ningún sentido.

En su lugar, le recomendamos que analice la tendencia relativa del recuento de defectos a lo largo del tiempo para tener una medida de estabilidad relativa. Por ejemplo, suponiendo que el esfuerzo de prueba permanece relativamente constante, normalmente se esperaría ver el nuevo índice de descubrimiento de defectos medido en una "curva de campana" de período de tiempo regular a lo largo del transcurso de la iteración; un índice de descubrimiento en aumento que llega a un máximo y luego desciende hacia el final de la iteración. Sin embargo, deberá proporcionar esta información junto con un análisis de otras métricas de defectos, como por ejemplo: índices de resoluciones de defectos, incluido un análisis del tipo de resolución; distribución de defectos por gravedad; distribución de defectos por área funcional.

Con el soporte de herramientas sofisticadas, puede realizar análisis complejos de datos de defectos con relativa facilidad; sin el soporte de herramientas apropiadas resulta una tarea mucho más difícil.

Tratar las estrategias posibles con los interesados
Objetivo:  Recoger comentarios a través de la revisión inicial de los interesados y ajustar las estrategias según sea necesario.  

Presente las estrategias posibles a los diferentes interesados. Normalmente se espera que éstos incluyan un grupo formado por los siguientes roles: gestor de proyectos, el arquitecto de software, el gestor de desarrollo, el analista de sistemas, el gestor de configuración y cambios, el gestor de despliegue y el representante del cliente. Cada uno de estos roles está interesado en cómo se valora la calidad.

Dependiendo de la cultura del proyecto, debe elegir un formato apropiado para presentar las estrategias posibles. El formato puede variar desde una o varias reuniones informales hasta una presentación formal o sesión de taller.

Definir y acordar la estrategia de valoración
Objetivo:  Obtener el acuerdo de los interesados sobre la estrategia que se utilizará. 

A partir de los comentarios obtenidos en las discusiones perfeccione la estrategia de valoración y cree una única estrategia que satisfaga las necesidades de todos los interesados.

Presente la estrategia de valoración para su acuerdo y aprobación final.

Definir los requisitos de las herramientas
Objetivo:  Definir los requisitos de configuración de las herramientas de soporte que permitirán llevar a cabo el proceso de valoración.  

Como se ha mencionado anteriormente, con el soporte de herramientas sofisticadas puede realizar análisis complejos de datos de medidas con relativa facilidad; sin el soporte de herramientas apropiadas resulta una propuesta mucho más difícil.

Para las siguientes categorías, considere el soporte de herramientas que necesitará: cobertura y rastreabilidad, análisis de defectos.

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, podría resultar útil hacer que el autor del producto de trabajo de entrada revise su trabajo.

Recuerde que RUP es un proceso 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
Más información