Verificacion y Validacion

Embed Size (px)

Citation preview

  • TECNOLOGICO DE ESTUDIOS SUPERIORES DE

    COACALCO

    ING. EN SISTEMAS COMPUTACIONALES

    VALIDACION Y VERIFICACION

    UNIDAD 2: PRUEBAS

  • ndice

    2.1 Tipos de pruebas ............................................................................................... 3

    2.2 Coberturas de las pruebas ................................................................................ 5

    2.3 Preparacin de las pruebas ............................................................................... 7

    2.5 Criterios para la realizacin de pruebas ............................................................ 8

    2.6 Plan de pruebas (verificacin y validacin) ....................................................... 8

    2.7 Estructura de los casos de prueba .................................................................. 10

    2.8 Conceptos generales de los diseos de las pruebas (verificacin y validacin)

    .............................................................................................................................. 10

    2.9 Reporte y seguimiento de errores ............................................................... 11

    2.10 Informe de las pruebas ................................................................................ 12

    2.11 Fuentes de informacin de QA para el control estadstico o mtrico ............ 14

    2.13 Importancia de la calidad, mtricas y control estadstico............................... 15

    Conclusiones ......................................................................................................... 16

    Referencias ........................................................................................................... 16

  • 2.1 Tipos de pruebas

    Existen dos tipos diferentes de prueba, que se utilizan en las diferentes etapas de

    desarrollo del software:

    Las pruebas de defectos: Pretenden encontrar las inconsistencias entre un

    programa y su especificacin. Estas inconsistencias se deben habitualmente a los

    fallos o defectos en el cdigo del programa. Las pruebas se disean para revelar la

    presencia de defectos en el sistema, ms que para evaluar su capacidad

    operacional.

    Las pruebas estadsticas: se utilizan para probar el desempeo y la fiabilidad del

    programa y comprobar cmo trabaja bajo condiciones operacionales. Las pruebas

    se disean para reflejar las entradas de los usuarios y su frecuencia.

    Despus de llevar a cabo las pruebas, se puede hacer una estimacin de la

    fiabilidad operacional del sistema contando el nmero de cadas observadas en el

    sistema. La capacidad del programa se valora midiendo el tiempo de ejecucin y el

    tiempo de respuesta del sistema cuando procesa los datos estadsticos de la

    prueba.

    No existe una separacin clara entre estos dos tipos de pruebas. Durante las

    pruebas de defectos los desarrolladores obtienen una visin intuitiva de la fiabilidad,

    y durante las pruebas estadsticas, se descubren obviamente muchos fallos.

    El objetivo de las pruebas de defecto es detectar los defectos latentes de un sistema

    software antes de entregar el producto.

    --Una prueba de defectos exitosa es aquella que descubre un fallo, esto es, un

    comportamiento contrario a la especificacin.

    --Las pruebas de defectos demuestran la existencia de un fallo, y no la ausencia de

    cualquier fallo.

    Las pruebas exhaustivas no son posibles y deben sustituirse por subconjuntos de

    casos de prueba. Se deben establecer polticas para establecer esos casos de

    prueba. Por ejemplo:

    --Que todas las instrucciones del programa se ejecuten al menos una vez

    --Se deben probar todas las funciones del sistema que se acceden a travs de

    men.

  • --Si la entrada es introducida por el operador, todas las funciones deben probarse

    con entradas correctas e incorrectas.

    Pruebas funcionales (Caja negra) Las pruebas funcionales o de caja negras

    es una poltica de seleccin de casos de pruebas basado en la especificacin del

    componente o programa.

    Las pruebas se seleccionan en funcin de la especificacin y no de la estructura

    interna del software.

    Las pruebas funcionales o de caja negra son una estrategia para seleccionar las

    pruebas de fallos basndose en las especificaciones de los componentes y

    programas, y no del conocimiento de su implementacin. El sistema se considera

    como una caja negra cuyo comportamiento slo se puede determinar estudiando

    las entradas y de contrastarlas con las respuestas que proporciona el sistema.

    Pruebas estructurales (Caja blanca) En las pruebas estructurales las pruebas

    se seleccionan en funcin del conocimiento que se tiene de la implementacin del

    mdulo.

    Se suelen aplicar a mdulos pequeos. El probador analiza el cdigo y deduce

    cuntos y qu conjuntos de valores de entrada han de probarse para que al menos

    se ejecute una vez cada sentencia del cdigo. Se pueden refinar los casos de

    prueba que se identifican con pruebas de caja negra.

    Pruebas de integracin Se prueban la respuesta de grupos de mdulos

    interconectados a fin de detectar fallos resultantes de la interaccin entre los

    componentes.

    Las pruebas de integracin se realizan con referencia a las especificaciones del

    programa.

    La principal dificultad de las pruebas de integracin es la localizacin de los fallos.

    Para facilitar la deteccin de los errores se utilizan tcnicas incrementales.

    --Una vez que se han probado los componentes individuales del programa, deben

    integrarse para crear un sistema parcial o completo. En el proceso de integracin

    hay que probar el sistema resultante con respecto a los problemas que surjan de

    las interacciones de los componentes.

    --Las pruebas de integracin se desarrollan a partir de la especificacin del sistema

    y se inician tan pronto como estn disponible versiones utilizables de algunos

    componentes del sistema.

  • 2.2 Coberturas de las pruebas

    Uno de los principales problemas a la hora de realizar las pruebas de un sistema es

    el gran nmero de casos de prueba necesarios para obtener una seguridad de que

    el sistema bajo prueba funciona correctamente, o con otras palabras, tener un

    conjunto de casos de prueba con la calidad suficiente para estar seguros que el

    programa bajo prueba funciona correctamente.

    Un criterio de cobertura se puede entender segn M. Broy et al. Con dos significados

    diferentes:

    - Como un criterio de adecuacin, el cual sirve para determinar cundo un conjunto

    de casos de prueba tiene la calidad suficiente, por lo que el sistema bajo prueba

    que probado correctamente

    - Como un criterio de seleccin el cual nos sirve para aadir casos de prueba nuevos

    a nuestro conjunto de casos de prueba y de esta manera mejorar la calidad del

    mismo.

    Ambos significados dan la idea de que los criterios de cobertura son interesantes

    para medir la calidad de los conjuntos de casos de prueba. Dentro del mbito de las

    pruebas de caja blanca, las cuales tienen en cuenta la estructura interna del

    programa bajo prueba para comprobar el correcto funcionamiento del mismo, los

    criterios de cobertura se pueden clasificar en base a los siguientes tres aspectos:

    Los criterios estructurales se usan para medir la calidad de un conjunto de casos de

    prueba. Esta calidad se mide en funcin del porcentaje alcanzado en funcin del

    criterio que se haya escogido. Como su propio nombre indica, estos criterios s

    definen en base a la estructura del programa bajo prueba, por ejemplo, si tenemos

    una mquina de estados, un criterio estructural podra definirse en funcin de los

    estados de la misma o en funcin de las transiciones. Una clasificacin bastante

    aceptada de los diferentes criterios de cobertura para las pruebas de caja blanca,

    es clasificar estos criterios en dos grandes grupos: criterios basados en el flujo de

    control y criterios basados en flujo de datos.

    Criterios de cobertura basados en el flujo de control este tipo de criterios estn

    basados en las expresiones lgicas introducidas en la especificacin del sistema

    bajo prueba que determinan cuando existen saltos o bucles dentro de la

    implementacin, en otras palabras, se basa en las condiciones de las estructuras If-

    THENELSE y los LOOP que existe dentro de la implementacin del sistema. Los

    criterios de cobertura de este tipo ms usados son los siguientes:

  • El criterio de cobertura de sentencias, es el criterio ms simple de todos, define

    que han de recorrerse todas las lneas o sentencias del cdigo del programa al

    menos una vez.

    El criterio de cobertura de decisiones o cobertura de ramas expuesto por primera

    vez en requiere que cada posible valor (verdadero o falso) que pueda tomar cada

    una de las decisiones del sistema bajo prueba se d al menos una vez, sabiendo

    que una decisin es un conjunto de condiciones relacionadas mediante operadores

    lgicos (and, or) y una condicin es un conjunto de expresiones algebraicas

    relacionadas con operadores relacionales (=).

    El siguiente criterio es la cobertura de condiciones, el cual requiere que cada

    condicin de cada decisin tome todos los posibles valores al menos una vez.

    Siguiendo con el ejemplo anterior, en este caso necesitaramos dos casos de

    prueba, uno que evale A Falso y B verdadero y otro A Verdadero, y B Falso. A

    pesar de que este criterio es ms restrictivo que el anterior no alcanza la cobertura

    de decisiones, ya que en el ejemplo siempre se evaluara a falso la decisin y nunca

    se ejecutara S.

    EL siguiente criterio de cobertura que soluciona los problemas de los dos anteriores,

    es el criterio de cobertura de condicin decisin, el cual requiere que cada posible

    valor de cada condicin de cada decisin del programa es producida al menos una

    vez y que adems se produzca cada posible valor de cada decisin. Siguiendo el

    ejemplo anterior para este criterio nos bastara con tener dos casos de prueba, uno

    que evaluase A falso y B falso y otro que evaluase A verdadero y B verdadero. De

    esta manera si un conjunto de casos de prueba cumple este criterio va a cumplir

    todos los criterios expuestos anteriormente.

    Criterios de cobertura basados en el flujo de datos este tipo de criterios de

    cobertura se basa en el anlisis de los flujos de los datos. Aqu se requiere que los

    casos de prueba ejecuten secuencias de instrucciones en las cuales se asignen

    valores a variables y posteriormente se usen esos valores. Para definir estos

    criterios de cobertura hay que definir previamente lo que es el grafo de control

    asociado al sistema bajo prueba. Este grafo est compuesto por una serie de nodos

    en los cuales se representan secuencias lineales de instrucciones y una serie de

    enlaces que representan trasferencias de control entre los nodos, de manera que a

    cada enlace se asocia una expresin booleanas que contiene la condicin

    correspondiente a la trasferencia de control. El criterio de cobertura de todas las

    definiciones, se basa en que para cada variable exista al menos un caso de prueba

    de manera que este ejecute las instrucciones del sistema para que se recorra un

    camino en el grafo de control del sistema en el cual se defina la variable y al menos

    se use una vez. Este criterio de cobertura no es muy rigoroso porque podemos tener

    conjuntos de casos de prueba que dejen sin probar muchos usos de las variables.

    Para solucionar ese problema existe el criterio de cobertura de todos los usos, en

    cual se basa en que para cada variable existan dentro del conjunto de casos de

  • prueba, suficientes casos de prueba para que se recorran los caminos del grafo de

    control del sistema en los que se defina la variable y se alcancen todos los usos de

    dicha, es decir, que se ejecuten en el mismo caso de prueba la definicin junto con

    los usos de la variable y en el caso de que no se puedan cubrir todos los usos con

    un nico caso de prueba, aadir ms casos reprueba que cubran siempre la

    definicin de la variable hasta que se cubran todos los usos de dicha variable. Este

    criterio a pesar de que cubre todos los usos de las variables tiene el problema de

    que existe la posibilidad de que a cada uso se pueda llegar desde varios caminos

    diferentes, porque puede ser que existan errores que se den solo llegando desde

    un camino concreto y no sean detectados por el conjunto de casos de prueba.

    Para solucionar el problema presentado anteriormente surge el criterio de

    cobertura de caminos definicin/uso, el cual se basa en recorrer todos los

    caminos posibles desde la definicin hasta el uso de una variable, para todos los

    usos de una variable y para todas las variables. Este criterio de cobertura es muy

    costoso de conseguir y adems existe un problema con los bucles ya que estos

    introducen la posibilidad de que existan caminos infinitos.

    2.3 Preparacin de las pruebas

    A la hora de realizar este tipo de pruebas, es imposible probar una clase con todas

    sus posibilidades, ya que es impracticable probar todos los nmeros enteros para

    un mtodo que recibe un entero como parmetro, por ejemplo. Con lo cual,

    necesitamos criterios para elegir el conjunto de casos de prueba ptimos, de

    manera que podamos saber si el conjunto de casos de prueba tiene calidad o no.

    Un caso de prueba est bien elegido si cumple lo siguiente:

    - Reduce el nmero de casos necesarios para que las pruebas sean de una calidad

    razonable. Esto implica que el caso ejecute el nmero mximo de posibilidades de

    entrada diferentes para as reducir el total de casos.

    - Cubre un conjunto extenso de otros casos posibles, es decir, indica algo acerca

    de la ausencia o la presencia de defectos en el conjunto especfico de entradas, as

    como de otros conjuntos similares.

    En este tipo de pruebas existen algunas tcnicas y criterios que nos pueden ayudar

    a seleccionar el conjunto de casos de prueba ptimo, las cuales se podran adoptar

    para medir la calidad, aunque no han sido desarrolladas para ese fin, sino para

    seleccionar un conjunto de valores de prueba ptimo.

  • 2.5 Criterios para la realizacin de pruebas

    Criterios de cobertura a parte de los criterios mencionados anteriormente existen

    otros criterios de cobertura que se suelen usar la prctica como: la cobertura de

    funciones, que se verifica cuando se han ejecutado todas las funciones del sistema

    bajo prueba; la cobertura de llamadas, que se verifica cuando se cubren todas las

    llamadas a funciones que existen en el programa bajo prueba y la cobertura de

    tablas, que se verifica cuando se han hecho referencia a todos los elementos de

    las tablas

    En definitiva, estos criterios de cobertura pueden ser tiles para medir la clida de

    los casos de prueba, siempre teniendo en cuenta que hablamos de pruebas de caja

    blanca y tenemos acceso al cdigo del programa bajo prueba.

    Cuando no hay acceso al cdigo del sistema, todos los criterios expuestos

    anteriormente no se pueden usar, por lo que la calidad de las pruebas va a venir

    dada por los valores de prueba. As, para medir la calidad tendremos que fijarnos

    en la clida de los valores que usen los casos de prueba.

    Criterios de cobertura para los valores de las pruebas con estos criterios, viene

    a medirse el grado en que los diferentes valores interesantes seleccionados con

    una de las tcnicas expuestas anteriormente o manualmente se utilizan en la batera

    de casos de prueba, ya que aunque seleccionemos valores de prueba de calidad

    para ejecutar las pruebas, las diferentes combinaciones de estos valores van a

    influir en la calidad final del conjunto de casos de prueba. El criterio de cobertura

    de cada uso (each-use, o 1-wise) es el ms simple y el que menos calidad aporta

    al conjunto de casos de prueba. Se satisface cuando cada valor interesante de cada

    parmetro se incluye, al menos, en un caso de prueba, As, mediante las tcnicas

    expuestas anteriormente podramos seleccionar como buenos valores de prueba 0,

    1 y 2 para cada uno de los parmetros correspondientes a cada uno de los lados

    del tringulo. Un conjunto de casos de prueba que satisface el criterio 1-wise estara

    formado por los casos de prueba que ejecutara los valores siguientes: (0, 1, 2), (2,

    0, 1) y (1, 2, 0) sobre la funcionalidad descrita.

    2.6 Plan de pruebas (verificacin y validacin)

    Proporcionan un plano o gua para el desarrollador del software, para la

    organizacin de control de calidad y para el cliente. Es una gua que describe los

    pasos a llevar a cabo como parte de la prueba, cundo se deben planificar y realizar

    esos pasos, y cunto esfuerzo, tiempo y recursos se van a requerir., por lo tanto,

  • cualquier estrategia de prueba debe incorporar la planificacin de la prueba, el

    diseo de los casos de prueba, la ejecucin de las pruebas y la agrupacin y

    evaluacin de los datos resultantes.

    Etapas de un plan de pruebas

    especificar los objetivos de las pruebas.

    determinar con precisin los criterios a seguir en su realizacin.

    Integrar al personal y los elementos necesarios para el desarrollo de las

    pruebas.

    Aplicacin de la prueba o pruebas segn los criterios seleccionados.

    evaluacin de los resultados y consideraciones para llevar a cabo una nueva

    serie de pruebas.

    Un enfoque estratgico para la prueba del software

    Generalmente se proporciona una plantilla para la prueba con las siguientes

    caractersticas generales:

    --La prueba comienza en el nivel de mdulo y trabaja "hacia fuera", hacia la

    integracin de todo el sistema basado en computadora. Se usa el enfoque bottom-

    up.

    --En diferentes momentos se utilizarn diferentes tcnicas de prueba

    --La prueba la lleva a cabo el que desarrolla el software y (para grandes proyectos)

    un grupo de prueba independiente.

    Figura 2: proceso de plan de pruebas

  • 2.7 Estructura de los casos de prueba

    Existen mltiples tcnicas para medir o asegurar la calidad de un conjunto de casos

    de prueba, como las mediciones de cobertura que alcanzan las pruebas, la cantidad

    de fallos encontrados por la pruebas, sin embargo, todas estas tcnicas, que son

    estudiadas en las siguientes secciones, no contribuyen con sus mediciones a la

    evaluacin de la calidad del conjunto de casos de prueba en el marco de un modelo

    de calidad propiamente dicho, sino que simplemente son intentos de mejorar la

    calidad de forma prctica.

    De hecho no existe un modelo de calidad propiamente dicho para los conjuntos de

    casos de prueba, de manera que solo se podra aplicar el modelo presentado en la

    ISO 9126, adaptndolo convenientemente a las caractersticas del software

    referente al conjunto de casos de prueba.

    2.8 Conceptos generales de los diseos de las

    pruebas (verificacin y validacin)

    Pruebas de la estructura de control

    La prueba de condicin se centra en encontrar errores en condiciones lgicas en un

    mdulo, aunque tambin puede detectar errores adicionales en el programa.

    En una condicin se pueden dar los siguientes errores:

    Error de operador lgico

    Error en una variable lgica.

    Error en una condicin simple o compuesta.

    Error en un operador relacional.

    Error en una expresin aritmtica.

    La prueba de flujo de datos selecciona caminos de prueba de un programa de

    acuerdo con la ubicacin de las definiciones y los usos de las variables del

    programa.

    La prueba de bucles es una tcnica de prueba de caja blanca que se centra

    exclusivamente en la validez de las construcciones de condiciones. Hay cuatro tipos

    de estructuras de control: simples, concatenadas, anidadas y no estructuradas. De

    acuerdo al tipo de estructura es la prueba que se aplicar.

    Pruebas de caja negra

    Mtodos de prueba basados en grafos

  • Particin equivalente

    Anlisis de valores lmites

    Prueba de comparacin

    Este tipo de prueba se centra en los requisitos funcionales del software y

    permite obtener entradas que prueben todos los requisitos funcionales del

    programa. Con este tipo de pruebas se intenta encontrar:

    Funciones incorrectas o ausentes.

    Errores de interfaz

    Errores en estructuras de datos o en accesos a bases de datos externas.

    Errores de rendimiento.

    Errores de inicializacin y terminacin.

    Prueba de comparacin

    Esta tcnica consiste en la comparacin de salidas de un mismo software

    pero de sus diferentes versiones.

    2.9 Reporte y seguimiento de errores

    Quien crea la entrada puede ser un desconocido al proyecto los reportes de fallos y

    las solicitudes de caractersticas provienen tanto de los usuarios como de los

    desarrolladores. Una vez enviada, la entrada entra en un estado llamado abierto

    porque ninguna accin ha sido tomada aun. Algunos gestores etiquetan las nuevas

    entradas como sin verificar o como sin iniciar. No est asignada a nadie, o en

    algunos sistemas, es asignada a un usuario fantasma que representa la falta de una

    asignacin real. Llegado a este punto, la entrada se encuentra en el rea de espera:

    ha sido registrada, pero a un no ha sido integrada en la conciencia del proyecto.

    1. Otros leen la entrada, aaden comentarios y quizs soliciten el

    esclarecimiento de algunos puntos a quien realizo la entrada.

    2. El fallo es reproducido. Este puede que sea el momento ms importante en

    su ciclo vital, ya que incluso que el fallo a un no ha sido resuelto, el hecho de

    que alguien haya podido reproducirlo adems de quien creo la entrada

    prueba que es genuino y, no menos importante, confirma al creador de la

    entrada que ha contribuido al proyecto reportando un fallo real.

    3. El fallo es diagnosticado: su causa es identificada, y si es posible, es

    estimado el esfuerzo requerido para repararlo. Hay que asegurarse de que

    todo esto es registrado en la entrada, ya que en el case en que quien haya

    hecho el diagnostico abandona el proyecto (lo cual sucede a menudo con

    desarrolladores voluntarios), alguien ms debe ser capaz de continuar con

    su trabajo.

  • 2.10 Informe de las pruebas

    Informes de Verificacin

    Documento Se genera un documento Informe de Verificacin

    Unitaria por cada prueba unitaria que se realice al

    sistema.

    Creado por Las personas que ejecutan las pruebas.

    Para quien Es el retorno para los implementadores de la tarea

    de verificacin, que detalla los errores encontrados

    para que puedan ser corregidos.

    Fecha de liberacin Ser liberado luego de cada verificacin unitaria.

    [Indique la versin y la fecha de liberacin de todas

    las versiones de este informe.]

    Documento Se genera un documento Informe Consolidacin

    por cada consolidacin que se realice al sistema.

    Creado por Las personas que ejecutan las pruebas.

    Para quien Es el retorno para los implementadores de la tarea

    de consolidacin, que detalla los errores

    encontrados para que puedan ser corregidos.

    Fecha de liberacin Ser liberado luego de cada consolidacin.

    [Indique la versin y la fecha de liberacin de todas

    las versiones de este informe.]

    Documento Se genera un documento Informe de Verificacin

    de Integracin por cada prueba de integracin que

    se realice al sistema.

    Creado por Las personas que ejecutan las pruebas.

    Para quien Es el retorno para los implementadores de la tarea

    de verificacin, que detalla los errores encontrados

    para que puedan ser corregidos.

    Fecha de liberacin Ser liberado luego de cada verificacin de

    integracin. [Indique la versin y la fecha de

    liberacin de todas las versiones de este informe.

  • Documento Se genera un documento Informe de Verificacin

    de Sistema por cada prueba de sistema que se

    realice.

    Creado por Las personas que ejecutan las pruebas.

    Para quien Es el retorno para los implementadores de la tarea

    de verificacin, que detalla los errores encontrados

    para que puedan ser corregidos.

    Fecha de liberacin Ser liberado luego de cada verificacin de sistema.

    [Indique la fecha de liberacin de este informe.]

    Evaluacin de la verificacin

    Documento Se genera un documento Evaluacin de la verificacin por cada prueba que se realice al sistema. Este documento contiene las fallas encontradas en el sistema, la cobertura de la verificacin realizada y el estado del sistema.

    Creado por El Responsable de verificacin, que toma como fuente de su trabajo los Informes de verificacin.

    Para quien Es el resumen de la tarea de verificacin y es el retorno para todo el equipo de trabajo del estado del sistema.

    Fecha de liberacin Ser liberado luego de cada verificacin, unitaria, de integracin y de sistema.

    [Indique la versin y la fecha de liberacin de todas las versiones de este informe.

    Documento El documento Informe final de verificacin es el resumen de la verificacin final del sistema antes de que sea liberado al entorno del usuario.

    Creado por El Responsable de verificacin, que toma como fuente de su trabajo los Informes de verificacin.

    Para quien Indica el estado del sistema.

    Fecha de liberacin Ser liberado luego de la verificacin final del sistema.

  • 2.11 Fuentes de informacin de QA para el control

    estadstico o mtrico

    Elementos de medida.

    Medir es asignar nmeros o smbolos a los atributos de una entidad de acuerdo a

    unas reglas definidas para caracterizar los atributos. Segn esto tenemos los

    siguientes elementos de medida:

    Entidades, que deben de ser objeto de inters

    Atributos, que son las caractersticas de las entidades

    Reglas, que determinan la asignacin de valores a los atributos.

    Mtrica, es el establecimiento de un patrn que se utiliza de referencia para las

    medidas que tengan relacin de homogeneidad con l. De esta manera se puede

    aceptar un convenio que permita definir la distancia entre dos elementos.

    Entidades y Atributos.

    Algunos ejemplos de entidades pueden ser:

    Productos Procesos Recursos

    Actividades Organizaciones Entornos

    Pero entidades tambin pueden ser un conjunto de otras entidades. Por ejemplo,

    un proceso software puede contener a muchos subprocesos, y cada uno de ellos

    estar produciendo, transformando o transmitiendo productos asociados. De la

    misma manera, estos productos ms atmicos, los subprocesos, y sus elementos

    de datos son en s mismo entidades que determinadas organizaciones pueden

    desear caracterizar. Los atributos son caractersticas o propiedades de las

    entidades. De la misma manera que un coche puede describirse por su longitud,

    nmero de puertas, cilindrada, velocidad mxima o consumo, en definitiva atributos,

    las entidades software pueden definirse por atributos tales como tamao, coste,

    tiempo, esfuerzo consumido, tiempo de respuesta, nmero de transacciones por

    unidad de tiempo, nmero de defectos encontrados, etc. La habilidad debe estar en

    saber que atributos deben usarse para obtener medidas que proporcionen datos

    tiles.

    Cada entidad est acompaada por algunos atributos que la caracterizan y por

    medidas que pueden ser usadas para cuantificar los atributos.

  • Entidades de

    Recursos

    Atributos Medidas posibles

    Personal asignado

    Tamao del equipo

    Nmero de personas asignadas

    Experiencia Aos de experiencia en programacin

    Perfil profesional Nombre del perfil profesional (Jefe de proyecto, Analista, Programador)

    Herramientas CASE

    Tipo

    Es usada ?

    Nombre del tipo

    Si/No

    Tiempo Fecha comienzo, Fecha fin

    Duracin

    Fechas del calendario

    Das (laborables o de calendario).

    Figura 6: Ejemplos de medidas de recursos

    Escalas de Medida las escalas de medida proporcionan valores y unidades para la

    descripcin de los atributos. Por ejemplo: un proyecto software puede producir

    30.000 lneas de cdigo, tener una duracin planificada de 12 meses y usar 10.000

    horas de esfuerzo para su desarrollo. Cada una de esas observaciones ha sido

    cuantificada con un valor a partir de una escala que se supone est bien definida.

    Cualquiera que sea la medida y su forma, siempre requiere de una escala bien

    definida para la captura y registro de los resultados de medida.

    2.13 Importancia de la calidad, mtricas y control

    estadstico

    Las medidas de los procesos y los productos, y por tanto los datos que de ellas se

    derivan, deben estn orientadas a demostrar la adecuacin y la eficiencia del

    sistema de gestin de la calidad de la organizacin. Del anlisis de estos datos

    podrn encontrarse oportunidades de mejora, que junto con otras fuentes de

    informacin como resultados de auditoras, polticas de calidad de la organizacin,

  • etc. darn lugar a la puesta en marcha de acciones correctivas o preventivas en el

    intento de mejorar continuamente la eficacia del sistema de gestin de calidad.

    La figura 9 muestra un Sistema de Gestin de la Calidad basado en los procesos,

    tal como se define en ISO 9000:2000. Podemos observar cmo los procesos de

    medidas, anlisis y mejora, son una parte integrada dentro del conjunto de procesos

    de la organizacin.

    Conclusiones

    En este trabajo nos damos cuenta que tan importante son la pruebas en el desarrollo

    de software ya que si en ellas el software a realizar llevara bastantes errores, son

    de suma importancia, si se realizan este tipos de pruebas se podrn corregir los

    errores encontrados a tiempo, y de igual forma poder corregirlo.

    Referencias capacitacion y guia para el desarrollo del software. (s.f.). Obtenido de

    http://materias.fi.uba.ar/7548/PruebasSoftware.pdf

    Mateo, P. R. (s.f.). Master en tecnologas informticas avanzadas . Obtenido de http://alarcos.inf-

    cr.uclm.es/doc/cmsi/trabajos/Pedro%20Reales.pdf

    software. (s.f.). Obtenido de

    http://www.historianaval.cl/publico/publicacion_archivo/publicaciones/2_4.pdf