calidad 09

Upload: carlos-cesar-bolon

Post on 25-Feb-2018

213 views

Category:

Documents


0 download

TRANSCRIPT

  • 7/25/2019 Calidad 09

    1/10

    Estrategia de Pruebas para Software OO que garantiza RequerimientosNo FuncionalesAnna. C Grimn, Mara Prez, Luis. E Mendoza

    Laboratorio de Investigacin de Sistemas de Informacin (LISI)

    Departamento de Procesos y Sistemas, Universidad Simn Bolvar

    Apartado Postal 89000. Caracas 1080-A. Caracas VenezuelaTelf.: +58 (212) 9064017 /3328 /3314 /3304. Fax +58 (212) 9064017 /3303

    {agriman, movalles, lmendoza}@usb.ve

    RESUMENUna disciplina importante en el proceso de desarrollo de los Sistemas de Software es la relativa a Pruebas. Estadisciplina, generalmente no se implementa de forma organizada y sistemtica, y menos cuando se trata deevaluar los Requerimientos No Funcionales. El objetivo de este artculo es proponer un conjunto de Pruebasde Software Orientado a Objetos (OO)para garantizar los Requerimientos No Funcionales, a travs de unaEstrategia de Prueba. Esta Estrategia de Prueba incluye la generacin y la ejecucin de un mtodo deevaluacin, representado por listas de chequeo y casos de prueba, que permiten determinar el nivel de presencia

    de los Requerimientos No Funcionales en un sistema de software.La validacin de la Estrategia de Pruebasse realiz a travs del estudio de un caso.

    Palabras Claves: Estrategias de Pruebas, Requerimientos no-funcionales, desarrollo de software OO, validacin

    INTRODUCCINPropiciar la calidad en el Software es una actividad que ha surgido como consecuencia de la fuerte demanda de

    Sistemas de Software en todos los procesos que se desarrollan en la actualidad; desde programas elementales de

    contabilidad hasta programas complejos como los espaciales. De all el esfuerzo que se ha desplegado para

    obtener software de alta calidad. Segn Gonzales [5], el aseguramiento de la calidad toma en cuenta todas

    aquellas acciones planificadas y sistemticas necesarias para proporcionar la confianza de que un producto oservicio satisfaga los requisitos de calidad establecidos. Para que sea efectivo, se requiere una evaluacin

    permanente de aquellos factores que influyen en la adecuacin del diseo y de las especificaciones segn lasaplicaciones previstas. Pressman [9], por su parte, asegura que la garanta de calidad del software es una

    actividad de proteccin que se aplica a lo largo de todo el proceso de Ingeniera del Software, la cual engloba:

    mtodos y herramientas de anlisis, diseo, codificacin y prueba; revisin de tcnicas formales que se aplican

    durante cada paso; estrategia de prueba multiescalada; control de la documentacin del software y de los

    cambios realizados; procedimientos que aseguren un ajuste a los estndares de desarrollo del software; y

    mecanismos de medida y de informacin. Los requerimientos del software son una descripcin abstracta de losservicios que el sistema debera proporcionar al cliente, y las limitaciones bajo las cuales ste debera operar

    [12]. Ellos cumplen tres propsitos: 1) permiten a los desarrolladores entender cmo el cliente quiere que trabaje

    el sistema, 2) especifican a los diseadores la funcionalidad y las caractersticas que el sistema debe tener, 3)

    especifican a los integrantes del grupo de pruebas lo que deben demostrar para convencer al cliente de que elsistema satisface sus necesidades [10].

    Segn Sommerville [12], Bass et al. [1], Bosch [2], Dromey [4], Pressman [9], entre otros, los requerimientos del

    software se clasifican en: Requerimientos Funcionales (RF) y Requerimientos No Funcionales (RNF). LosRequerimientos RNF son aquellos requerimientos que aparecen junto con las necesidades del usuario y definenlas restricciones y las propiedades de un sistema. El presente artculo tiene por objetivo proponer una Estrategia

    de Pruebas para Software OO que garantice RNF. Se considera necesaria una Estrategia de Pruebas adecuada

    para este tipo de sistema debido al creciente aumento de la complejidad que han adquirido en los ltimos aos;

    dicha complejidad hace que estos sistemas requieran ser sometidos a Pruebas con el propsito de garantizar su

    calidad. En las prximas secciones se describe el mtodo utilizado para la formulacin de la Estrategia de Prueba

    aqu propuesta y su aplicacin en un sistema; finalmente, se presentan las conclusiones ms resaltantes de esta

    investigacin.

    MTODO PARA LA FORMULACIN DE LA ESTRATEGIA DE PRUEBAAlgunos autores como Krutchen [7], Pressman [9], Pfleger [11], Cardoso [3] y Sommerville [12] afirman que el

    proceso de ejecucin de Pruebas debe ser considerado durante todo el ciclo de vida de un proyecto, para as

    obtener un producto de alta calidad. Su xito depender del seguimiento de una Estrategia de Prueba adecuada.La Estrategia de Prueba de software integra un conjunto de actividades que describen los pasos que hay quellevar a cabo en un proceso de prueba: la planificacin, el diseo de casos de prueba, la ejecucin y los

  • 7/25/2019 Calidad 09

    2/10

    resultados, tomando en consideracin cunto esfuerzo y recursos se van a requerir, con el fin de obtener como

    resultado una correcta construccin del software [9].

    La formulacin de la Estrategia de Prueba para Software OO (EPSOO) aqu propuesta contempl cinco pasos:

    i. Identificacin de las Etapas del Proceso de Pruebas,

    ii. Propuesta del Instrumento de Medicin: Las Listas de Chequeo,iii. El Diseo y Registro de Casos de Prueba, y

    iv. Establecimiento de Pautas para Procesar los Resultados y

    v. Diseo Final de la EPSOO.

    A continuacin se describen estos pasos.

    i. Identificacin de las Etapas del Proceso de Pruebas: Se inspir en las Actividades Clsicas del Proceso deDesarrollo (ACPD), es decir: Anlisis, Diseo e Implantacin; ya que las mismas se encuentran actualmente

    presentes, a manera de disciplinas, en la mayora de los procesos de desarrollo. Por lo cual, la adopcin de estas

    etapas no implica necesariamente una secuencialidad en el proceso de desarrollo. Se propone que las pruebas

    sean establecidas como un filtro al final de cada ACPD. Para la ACPD de Implantacin, las pruebas se

    desagregaron en las subactividades de: Unidad, Integracin y Sistema. Una vez establecidas las etapas a seguir

    durante el proceso de prueba, se procedi a asociar las Tcnicas de pruebas para software OO que garantizaran

    los RNF. Para identificar los Requerimientos RNF se parti del Modelo de Calidad Sistmica del producto [8].Este modelo permite identificar las Caractersticas de Calidad que deben ser evaluadas en un software. Estascaractersticas tienen a su vez subcaractersticas asociadas. Se tomaron en cuenta las siguientes caractersticas:

    Fiabilidad, Usabilidad, Eficiencia, Mantenibilidad y Portabilidad.

    Por razones de espacio, en la Tabla 1 se muestra el resultado obtenido de la asociacin de las tcnicas de prueba

    con el RNF Fiabilidad a manera de ejemplo.

    Tabla 1. Tcnicas de prueba al RNF FiabilidadSubcaracterstica Objetivo Tcnicas que aplican

    Madurez Evaluar la capacidad que tiene elsoftware para evitar fallas.

    Prueba Negativa: Hacer que el sistemafalle intencionalmente para medir su

    capacidad de respuesta frente a un error.Tolerancia aFallas

    Verificar la capacidad del software

    para mantener un nivel de

    rendimiento especfico ante un

    error, es decir, la capacidad de

    continuar procesando en caso de

    falla.

    Prueba de Valores Lmites: Evaluarvalores frontera; es decir, los valores

    mnimo y mximo que la unidad puede

    aceptar.Prueba Bajo Stress: Evaluar lahabilidad del sistema para seguir

    operando apropiadamente ante bajos

    recursos o competencias para los

    recursos.

    Ejecutar el sistema de manera que

    demande recursos en cantidad, frecuencia

    o volmenes anormales.

    Prueba Negativa: Hacer que el sistemafalle intencionalmente para medir sucapacidad de continuar su ejecucin a

    pesar de la falla.Prueba de Volumen: Someter alsoftware a una gran cantidad de datos

    para determinar si los lmites alcanzados

    hacen que este falle.

    Recuperabilidad Verificar que el proceso derecuperacin del sistema restaura

    apropiadamente la base de datos,

    la aplicacin y el sistema a un

    estado conocido o deseado.

    Prueba de Recuperacin: Exponer alsoftware a condiciones extremas y

    verificar que la recuperacin se realiza

    correctamente.

    Correctitud 1) Evaluar la capacidad decmputo.2) Comprobar la completitud de

    las formas estructurales y del

    Prueba Estructural: Verificar que lasformas estructurales de las clases seancompletas.Prueba de Ejecucin: La capacidad de

  • 7/25/2019 Calidad 09

    3/10

    Tabla 1. Tcnicas de prueba al RNF FiabilidadSubcaracterstica Objetivo Tcnicas que aplican

    software como un todo.

    3) Evaluar la consistencia.

    cmputo esperada se puede evaluar

    durante la ejecucin del software en

    aquellos mdulos en donde se apliquen

    clculos.

    Prueba de Carga: Probar diferentescargas para evaluar la capacidad de

    cmputo.

    Estructurado En caso de que el software no seadesarrollado en lenguaje OO puro

    se debe verificar que sea

    estructurado; es decir, que siga las

    reglas de la programacinestructurada.

    Prueba Estructural: Esta tcnicapermite evaluar los valores de las

    variables, las constantes y los tipos de

    datos y si stos son usados en el contexto

    en que se definieron.

    Encapsulado Si el software est desarrollado en

    lenguaje OO puro no es necesarioverificar que sea encapsulado,

    pero si no lo es, se debe aplicar las

    tcnicas de la subcaracterstica:

    Estructurado.

    Prueba Estructural: Esta tcnica

    permite evaluar los valores de lasvariables, las constantes y los tipos de

    datos y si stos son usados en el contexto

    en que se definieron.

    La Figura 1 muestra esquemticamente las etapas del proceso de prueba. Una vez establecidas, fueron asociadas

    tcnicas a cada una de ellas. Las tcnicas asociadas son aquellas que son pertinentes para ser aplicadas dentro de

    cada ETAPA identificada.

    Figura 1. Tcnicas asociadas a las Etapas del Proceso de Prueba.

    ii. Propuesta del Instrumento de Medicin: Las Listas de Chequeo. Las Listas de Chequeo estn basadas enla identificacin de las tcnicas de Prueba para evaluar cada Subcaracterstica de las Caractersticas de Calidad.Una lista de chequeo es un formulario de preguntas, las cuales dependen del objetivo para el cual son usadas.

  • 7/25/2019 Calidad 09

    4/10

    Estas listas estn clasificadas segn las etapas del Proceso de Prueba. Para dar respuesta a cada pregunta se

    considera una escala del 1 al 5, en donde el uno (1) siempre es la respuesta menos significativa y cinco (5) la ms

    significativa. A fines ilustrativos, en la Tabla 2 se presenta la Lista de Chequeo para la Caracterstica de

    Fiabilidad durante la actividad de Anlisis.

    Tabla 2. Lista de Chequeo para la Caracterstica Fiabilidad en la Etapa de AnlisisCaracterstica Pregunta Evaluacin

    1) Se realiz un proceso de levantamiento de

    informacin apropiado?

    1= Inaceptable

    2= Debajo del Promedio3= Promedio4= Bueno5= Excelente

    Madurez

    2.- El levantamiento de informacin fueestablecido formalmente?

    1= No5= Si

    Correctitud 1.- Estn siendo considerados todos los procesosnecesarios para dar solucin al problema?

    1= No

    5= Si

    Caracterstica Pregunta Evaluaciniii. El Diseo y Registro de Casos de Prueba: Para registrar cada uno de los Casos de Prueba realizados paradar respuesta a las Listas de Chequeo, se propone una planilla cuyos campos son los datos requeridos para

    estructurar un Caso de Prueba. Cada pregunta de las Listas de Chequeo puede generar uno (1) o ms Casos de

    Prueba. Esta planilla, se muestra en la Figura 2.

    Datos inicialesFecha: N de Caso de PruebaCaracterstica: Subcaracterstica:

    Pregunta de la lista de chequeo

    Informacin del Caso de PruebaDescripcin: Enfoque:

    Datos de entrada: Resultados Esperados:Procedimiento del caso de prueba

    1.- Pasos a seguir:2.- Condiciones externas:

    ResultadosCompletacinAprobadoNo aprobado

    En caso de no ser aprobado especificar:Severidad de la fallaGrave

    Resultados obtenidos:

    MenorObservaciones

    Figura 2. Planilla de Caso de Prueba

    iv.Establecimiento de Pautas para Procesar los Resultados. Se establecieron los pasos a seguir para obtenerlos resultados cuantitativos en base a las respuestas dadas en las Listas de Chequeo. Los resultados estn

    determinados por las respuestas y por la importancia que los involucrados asignan a cada subcaracterstica.

    Luego, las subcaractersticas deben ser ponderadas de acuerdo a la evaluacin; los involucrados dan un peso (en

    una escala del 1 al 5) a cada una de ellas a travs de la Planilla de Ponderacin, en donde el uno (1) siempre es

    el peso menos significativo y cinco (5) el ms significativo. La Figura 3 muestra la planilla de ponderacin parala caracterstica Fiabilidad.

    Caracterstica de calidad: FiabilidadPeso AsignadoSubcaracterstica

    1 2 3 4 5Madurez

    Tolerancia a Fallas

  • 7/25/2019 Calidad 09

    5/10

    Recuperabilidad

    Correctitud

    Estructurado

    Encapsulado

    Figura 3. Planilla de Ponderacin para la Caracterstica Fiabilidad

    Los resultados pueden obtenerse en base a dos criterios: respuestas a las preguntas de las Listas de Chequeo y la

    ponderacin.

    Dar respuesta a las preguntas de las Listas de Chequeo. Las respuestas a las preguntas de las Listas deChequeo se pueden dar de forma directa o mediante la realizacin de Casos de Prueba. De realizarse a travs delos Casos de Prueba, las respuestas dependern de los resultados obtenidos en los mismos.

    Los Casos de Prueba sern evaluados por medio de la siguiente escala:Aprobado = 5

    No Aprobado=

    Una pregunta puede ser contestada por ms de un Caso de Prueba. En este caso la respuesta a la preguntasiempre ser el menor valor obtenido por los casos de prueba considerados. Esto implica que de haber un caso de

    prueba no aprobado, ste afectar al resto en cuanto a la calificacin de la calidad.

    Ponderacin de resultados. A partir del procesamiento de las respuestas dadas en las Listas de Chequeo, segeneran tres (3) tipos de resultados:

    a) Resultados de la presencia de las Subcaractersticas en cada etapa del proceso de prueba, segn laCaracterstica de Calidad a la que corresponde.

    1) Se calcula el promedio aritmtico de las respuestas de cada pregunta de la Subcaracterstica que se

    est evaluando.

    2) Sobre la base de los promedios anteriores, la presencia de las Subcaractersticas tendrn lossiguientes valores:

    1= La Subcaracterstica no est presente en esta etapa.2= La Subcaracterstica se presenta de manera muy deficiente.3= La Subcaracterstica se presenta medianamente.4= La Subcaracterstica se encuentra presente.5= La Subcaracterstica se encuentra altamente presente.

    b) Resultados de la Presencia de las Caractersticas de Calidad (PCC) en cada una de las etapas,considerando la importancia dada por los involucrados. Una vez obtenidos los resultados de todas lasSubcaractersticas, se proceder a realizar los clculos para obtener la evaluacin de la Caracterstica de Calidad.

    Este clculo se realizar de la siguiente manera:

    1) Se calcula el promedio ponderado de las Subcaractersticas tomando en cuenta los pesos que le hansido asignados a cada una de ellas.

    2) Para calcular este promedio ponderado se multiplican los valores obtenidos de cada Subcaracterstica(SC) por su peso correspondiente (P).

    3) Se suman los valores obtenidos de la multiplicacin y se divide este valor entre la suma de todos los

    pesos. Este clculo se representa a travs de la siguiente frmula:

    PCC=

    Este resultado representa la evaluacin de la presencia de la Caracterstica de Calidad dentro de una etapa. Esta

    evaluacin ser representada en un rango del 1 al 5, al igual que los resultados dados para las Subcaractersticas.

    El valor obtenido es llevado a porcentaje con el fin de identificar si el mismo tiene el nivel de aceptabilidad. Elnivel de aceptabilidad es 75% y es el recomendado por [8] para decidir si una caracterstica esta presente o no.

    Para los casos de que no alcance este valor mnimo de presencia se recomienda que sea revisada la Caractersticaen todo el proceso de desarrollo del software.

    c) Resultados de la Presencia de las Caractersticas de Calidad en todo el Sistema (PCCS).

    Falla Menor = 3

    Falla Grave = 1

    SC*P

    P

  • 7/25/2019 Calidad 09

    6/10

    Despus de realizar las evaluaciones de las Caractersticas de Calidad en cada una de las etapas del proceso de

    prueba, se obtiene el Porcentaje de Presencia de cada una de las Caractersticas de Calidad en todo el Sistema

    (PPCS) el cual es el promedio de los Porcentajes de Presencia de cada una de las Caractersticas en cada Etapadel proceso de prueba (PPCE). Es importante sealar que se tom, nuevamente, como nivel de aceptabilidadde la Caracterstica de Calidad un valor del 75%. Una presencia con un valor por debajo del 75% se consideradeficiente en el Software que se est evaluando.

    v. Diseo Final de la Estrategia de Prueba. Todo lo anteriormente presentado soporta el diseo de laEstrategia de Prueba. Esta consiste en un conjunto de acciones organizadas y secunciales que se sintetizan en la

    Tabla 5. Esta Estrategia de Prueba, producto de la investigacin, se ha nombrado, a los fines de su presentacin y

    posterior referencia, como EPS-OO, adicionalmente se desarroll EPS-OO CheckList como herramienta para la

    evaluacin de los requerimientos no funcionales de software orientados a objeto para facilita el proceso de

    pruebas, hacindolo lo ms eficaz posible, EPS-OO CheckList ha sido desarrollada en Visual Basic y est

    basada en listas de chequeos las cuales permiten evaluar las caractersticas no funcionales del software a lo largo

    de cada una de las etapas del proceso de pruebas. En la Tabla 3 se presentan las actividades llevadas a cabo para

    el diseo de la EPS-OO con su descripcin, participantes, producto obtenido y sus entregables.

    Tabla 3. Estrategia de Prueba EPSOOActividad Descripcin Participantes Producto

    ObtenidoDocumento/Entregable

    1) Solicitud dePrueba

    Se debe procesar la planilla

    de solicitud de prueba paradar comienzo al anlisis de la

    prueba solicitada

    - Solicitante -Datos del Solicitante

    - Tiempo estimado.- Informacin del

    equipo-Definicin de

    riesgos- Plan de prueba

    Planilla de Solicitud

    de Prueba

    2) Recepcin de losrequisitos de laprueba

    El evaluador debe verificar

    toda la informacinsuministrada por el solicitantesobre el mdulo o sistema a

    probar. Esta informacin

    servir de apoyo a laejecucin de las pruebas.

    - Lder del

    Proyecto- Evaluador

    -Requerimientos del

    sistema (funcionales,no funcionales, HW,SW)

    - Manuales

    - Documentos deAnlisis y Diseo

    No aplica

    3) Presentacin delSistema o Mdulo

    El evaluador recibe una

    presentacin del mdulo osistema. Debe revisar conel solicitante cmo operael sistema, validaciones,

    clculos, etc

    - Lder de

    Proyecto- Evaluador

    - Certificacin del

    ambiente de prueba- Certificacin de laoperabilidad delsistema o modulo

    - Certificacin de losclculos y procesos

    No aplica

    4) Identificar losrecursos necesariospara ejecutar las

    pruebas

    Se identifican, en base a

    los recursos utilizados porel sistema, los recursos

    necesarios para ejecutarlas pruebas, considerando

    de antemano el programa

    EPS-OO

    -Evaluador.

    -Lder deProyecto

    No aplica Planilla de Solicitud

    de Prueba

    5) Identificarriesgos ylimitaciones

    En esta actividad se debendetallar los riesgos y

    limitaciones que se

    pueden presentar durantela ejecucin de las pruebas

    -Lder deProyecto

    - Evaluador

    Riesgo yLimitaciones

    Certificadas

    Planilla de Solicitudde Prueba

    6) Definir el alcancede la prueba

    Una vez analizados los

    requerimientos se debedefinir cual ser el alcancereal de la prueba, esto

    depende de losrequerimientos iniciales,

    tiempo y limitaciones

    - Lder de

    Proyecto- Evaluador

    Propuesta del alcance

    de la prueba

    Planilla de solicitud

    de prueba

    7) Definir el plan de En esta actividad se - Evaluador Plan detallado de la Diagrama de Gant del

  • 7/25/2019 Calidad 09

    7/10

    Actividad Descripcin Participantes ProductoObtenido

    Documento/Entregable

    pruebas definen y planifican todaslas actividades que se

    deben realizar, estimandolos tiempos y prioridad de

    la ejecucin de las

    mismas, a travs de undiagrama de Gant.

    -Lder de

    Proyecto

    prueba Cronograma de

    actividades

    8) Ponderacin delas caractersticasde calidad

    Se realiza una

    ponderacin a nivel deSubcaractersticas decalidad, para considerar laimportancia dada por el

    solicitante a las mismas, yas establecer prioridad deuna sobre otras almomento de evaluarlas

    Lder de

    Proyecto

    Ponderacin de las

    Subcaractersticas

    Planilla de

    ponderacin

    9) Establecimiento delambiente de prueba Se establece el ambientede prueba para que elevaluador pueda dar inicioal proceso

    Lder deProyecto

    No aplica No aplica

    10) Ejecucin de laspruebas

    Las pruebas se realizanpor etapas a travs de laaplicacin de listas de

    chequeo implementadasen el programa EPS-OO-Checklist el cual genera deforma automtica los

    resultados de las

    preguntas. Para darrespuesta a algunaspreguntas se deben

    procesar y registrar casosde prueba. Otras preguntas

    necesitan ser respondidaspor los usuarios finales

    para lo cual se aplica uncuestionario a los mismos

    -Evaluador-Usuarios

    Finales

    - Desarrollador

    No aplica - Planillas de Casosde Prueba

    -Cuestionario

    realizado-Listado de fallasencontradas-Reporte de

    resultados del EPS-

    OO CheckList-Anlisis deresultados

    11-Culminacin delas pruebas

    El criterio de culminacin

    es completar las listas dechequeo para cada etapa

    del proceso de prueba,tomando en cuenta el

    tiempo previsto para laspruebas.Al culminar el proceso de

    prueba se debe concretarla finalizacin de lasmismas a travs del Actade Culminacin

    -Lder del

    Proyecto- Evaluador

    No aplica Acta de culminacin

    de pruebas

    EVALUACIN DE LA ESTRATEGIA DE PRUEBA: ESTUDIO DE UN CASOPara la validacin y estudio de factibilidad de la Estrategia de Prueba, se estudiaron los criterios tcnicos y

    prcticos que propone la metodologa DESMET [6], la cual permite al evaluador de una organizacin particular

    planear y ejecutar un ejercicio de evaluacin que sea imparcial y fiable, permitiendo analizar el contexto de

    evaluacin. Luego de aplicar DESMET, de los nueve mtodos de evaluacin que propone, arroj como

    resultado el Anlisis de Caractersticas a travs del Estudio de un Caso como el mtodo de evaluacin msadecuado para la Estrategia de Prueba. Se desarrollaron, entonces, los pasos que se sugieren para la realizacin

    de este mtodo de evaluacin; resaltndose entre ellos la definicin de las caractersticas que se analizarandurante el estudio del caso. Las Caractersticas y Subcaractersticas definidas fueron:

    Estructura: Alcance, Documentacin, Enfoque y Resultados. Confort: Comprensivo y Fcil.

  • 7/25/2019 Calidad 09

    8/10

    Efectividad: Flexibilidad, Adecuacin y Utilidad.Se tom como proyecto piloto el Sistema de Comercializacin de la empresa QUIMBIOTECpara el estudiodel caso. El objetivo inmediato de QUIMBIOTEC C. A. es la elaboracin de productos hemoderivados de uso

    teraputico para satisfacer la demanda del sistema de salud venezolano y exportar a los pases de la regin. El

    Sistema de Comercializacin, se encarga de comercializar, con los respectivos clientes de QUIMBIOTEC, losproductos biolgicos y biotecnolgicos que son producidos en la empresa. Se aplic la EPSOO para todas las

    Caractersticas de Calidad en todas las etapas.

    La Figura 4, muestra los resultados de Presencia de las Caractersticas de Calidad del Sistema de Comercializacin.

    Figura 4. Presencia de las Caractersticas de Calidad en el Sistema por Disciplina

    Los resultados reflejan que la Caracterstica de Usabilidad est por debajo del Nivel de Aceptabilidad, lo cual

    conllev a que se hicieran las correcciones, dado que el sistema todava no estaba en operacin. Es de notar que

    en aquellos casos donde los resultados de las Pruebas de Diseo no fueron muy altos, tampoco lo fueron en las

    Pruebas del Sistema. Se observa adems, que aun cuando los resultados de las Pruebas de Integracin fueronsatisfactorios, no necesariamente las Pruebas del Sistema lo fueron.

    La Figura 5 muestra la Presencia de de las Caractersticas en general, la cual muestra de manera no desagregada

    los niveles de aceptacin, obsrvese que Usabilidad es la ms baja.

    Porcentaje de presencia de las Caractersticas de Calidad en el Sistema

    96%

    85%

    99%93% 92%

    20%

    40%

    60%

    80%

    100%

    Fiabilid

    ad

    Usabilid

    ad

    Eficie

    ncia

    Mante

    nibilid

    ad

    Portabilid

    ad

    Caractersticas de Calidad

    Porcen

    tajes

    Figura 5. Presencia de las Caractersticas de Calidad en el Sistema

    Las Figuras 6 y 7 muestran, a manera de ejemplo, los resultados para las Caractersticas de Usabilidad yMantenibilidad a lo largo del Proceso de Prueba. Lo cual parece indicar que el aseguramiento de la calidad en la

    % dePresencia

  • 7/25/2019 Calidad 09

    9/10

    etapa de Anlisis no garantiza calidad en la etapa de Diseo si no se realiza seguimiento a los requerimientos de

    calidad.

    Porcentaje de presencia de la Usabilidad en cada etapa

    100% 100% 100%

    57%68%

    0%

    20%

    40%

    60%

    80%

    100%

    Anlisis Diseo Unidad Integracin Sistema

    Figura 6. Presencia de la Usabilidad en cada Etapa

    Porcentaje de presencia de la Mantenibilidad en cada etapa

    100%

    82%

    95% 100%

    90%

    0%

    20%

    40%

    60%

    80%

    100%

    Anlisis Diseo Unidad Integracin Sistema

    Figura 7. Presencia de la Mantenibilidad en cada Etapa

    Estos resultados fueron consistentes con la percepcin del equipo de desarrollo. El estudio de este caso permiti

    evaluar la aplicabilidad de la Estrategia aqu propuesta y su xito en trminos de deteccin de fallas.

    CONCLUSIONESLa planificacin de la Estrategia de Prueba puede reducir significativamente el esfuerzo necesario para eldesarrollo de las pruebas adecuadas, reducir el tiempo de realizacin y ejecucin de las mismas y disminuir los

    altos costos que se generan. En este articulo de propone una Estrategia de Pruebas para Requerimientos NoFuncionales (RNF) en Sistemas de Software OO (EPS-OO) que demostr ser aplicable y exitosa al permitir

    detectar fallas en el producto. Esta herramienta proporciona retroalimentacin til al equipo de desarrollo, lo que

    le permite ir aplicando correcciones a lo largo de todo el proceso de desarrollo. Esto conduce a un Software de

    alta calidad al permitir detectar reas dbiles dentro del sistema en cuanto a los RNF (Fiabilidad, Usabilidad,

    Eficiencia, Mantenibilidad y Portabilidad); con lo cual se puede llegar a un equilibrio entre las necesidades delos usuarios y los resultados obtenidos de la Estrategia de Prueba. La aplicacin de la EPS-OO ayuda a realizarun seguimiento de las Caractersticas de Calidad en las diferentes etapas del proceso de desarrollo de software.

    AGRADECIMIENTOSEsta investigacin fue financiada por el Fondo Nacional de Ciencia Tecnologa e Innovacin (FONACIT) de la

    Repblica Bolivariana de Venezuela a travs del proyecto S1-2000000437. Los autores desean dar las gracias a

    las Ingenieras Clemente y Fernndez y a QUIMBIOTEC C. A. por su valiosa colaboracin en la culminacinde esta investigacin.

  • 7/25/2019 Calidad 09

    10/10

    REFERENCIAS

    [1] Bass, L., Clements, P. & Kazman, R. (1998). Software Architecture in Practice. Third Edition. Addison Wesley.

    [2] Bosch, J. (2000).Design et Use of Software Architectures.

    [3] Cardoso, R. (2001).Pruebas del Software. Mrida, Venezuela.

    [4] Dromey. (1996). Cornering the Chimera.1996. IEEE Software. Pag 33-43.

    [5] Gonzales, J. (2002).Las normas de la calidad del software. Addison-Wesley. Iberoamericana. Espaa.

    [6] Kitchenham, B. (1996).Evaluation Software Engineering Methods and Tools. Part1: The evaluation context

    and Evaluation Methods. SIGSOFT. Notes.

    [7] Kruchten, P. (2000). The Rational Unified Process as Introduction. 2 nd Edition. Addison Wesley.

    [8] Ortega, M. Prez, M. & Rojas, T. (2003). Construction of a Sistemic Quality Model for Evaluating a

    Software Product. Software Quality Journal, 11, 219-242.

    [9] Pressman, R. (2002).Ingeniera del Software: Un enfoque Prctico. McGraw Hill.

    [10] Pfleeger, S & Fenton N. (1997).PWS Publishing Company.

    [11] Pfleeger, S.(1998). Software Engineering.

    [12] Sommerville, I. (2000). Software Engineering. Pearson Education.