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