Fundamentos de Pruebas de Software

28-4-2014
FUNDAMENTOS DE
PRUEBAS DE
SOFTWARE
PRUEBAS DE SOFTWARE
NOVENO CICLO
FUNDAMENTOS DE PRUEBAS DE SOFTWARE

Pgina 2

AO DE LA PROMOCIN DE LA INDUSTRIA RESPONSABLE Y DEL COMPROMISO
CLIMTICO
UNIVERSIDAD NACIONAL
FACULTAD DE INGENIERIA DE SISTEMAS

TEMA

INTENGRANTES
Condea Flores, Moiss
Muante Velzquez Mercedes
Palomino Lvano, Rosa
Yancce Buleje Jean Carlos
Yarmas Mosquera, ngel

CURSO
PRUEBA DE SOFWARE

DOCENTE
Ing. Alonso Morales Loayza

ICA PER
2014
SAN LUIS GONZAGA DE ICA

Pgina 3

DEDICATORIA

El presente trabajo est dedicado a nuestros Padres que nos han
apoyado en nuestra formacin como personas y profesionales.


Pgina 4

INDICE
Contenido
INDICE ................................................................................................................................................. 4
INTRODUCCION ................................................................................................................................. 7
1. CALIDAD Y EL SOFTWARE ......................................................................................................... 8
1.1. Calidad ................................................................................................................................ 8
1.2. Calidad en la Ingeniera de Software .................................................................................. 9
1.3. Calidad del Software ......................................................................................................... 10
1.4. Aseguramiento de calidad de software (Software Quality Assurance , SQA) ................. 11
1.4.1. Grupo de SQA ................................................................................................................ 12
1.4.2. Actividades del proceso de Aseguramiento de la calidad de software ....................... 12
1.4.3. Tcnicas de Aseguramiento de la calidad de software ................................................ 14
2. MODELOS DE CALIDAD DE SOFTWARE ................................................................................ 16
2.1. Estructura De Un Modelo De Calidad De Software .......................................................... 16
2.2. Modelos de Calidad del Software ..................................................................................... 17
2.2.1. Modelos de Calidad del Software a nivel proceso ....................................................... 17
2.2.2. Modelos ........................................................................................................................ 21
3. VERIFICACIN Y VALIDACIN ................................................................................................ 28
3.1. Definiciones de Verificacin y Validacin: ....................................................................... 28
3.2. Objetivo De La Verificacin Y Validacin .......................................................................... 28
3.3. Tcnicas De Verificacin Y Validacin .............................................................................. 29
4. OBJETIVOS Y RESTRICCIONES ................................................................................................. 33
4.1. Objetivos de Las Pruebas .................................................................................................. 33
4.2. Limitaciones de las Pruebas de Software ......................................................................... 34
4.3. Errores por la Falta de Pruebas de Software .................................................................... 38
5. PLANIFICACIN........................................................................................................................ 39
5.1. Planificacin ...................................................................................................................... 39
5.2. Plan de Prueba. ................................................................................................................. 39
5.2.1. Caso de Prueba. ............................................................................................................ 40
6. MTRICAS Y MEDICIONES ....................................................................................................... 42

Pgina 5

6.1. Medicin del Software ...................................................................................................... 42
6.2. Mtricas de Software ........................................................................................................ 44
6.3. Panorama de las Mtricas del Producto. ......................................................................... 46
6.3.1. Mtricas para el Modelo de Anlisis. ........................................................................... 46
6.3.2. Mtricas para el Modelo de Diseo. ............................................................................ 47
6.3.3. Mtricas para el Cdigo Fuente. ................................................................................... 47
6.3.4. Mtricas para Pruebas. ................................................................................................. 47
6.4. Anlisis de las Mediciones. ............................................................................................... 48
7. PROCESOS DE V & V EN EL DESARROLLO DE SOFTWARE .................................................. 49
7.1. Actividades de Verificacin ............................................................................................... 49
7.2. V&V Prevencin y eliminacin de fallos ........................................................................... 50
8. BIBLIOGRAFA ........................................................................................................................... 52


Pgina 6

Contenido de Imgenes
Figura 1.1 Kaoru shikawa
Figura 1.2 William Edwards Deming
Figura 1.3 Desarrollo de Software en la Actualidad
Figura 1.4 Cooperacin del Equipo de Trabajo para una buena Calidad de Software
Figura 1.5 calidad
Figura 1.6 niveles del CMM
Figura 2.1. Estructura de un Modelo de Calidad Del Software
Figura 2.2. Representaciones CMMI
Figura 2.3. Factores de Calidad del Modelo de McCall
Figura 2.4. Modelo de Boehm
Figura 2.5. Caractersticas Modelo de Calidad para la Calidad Interna y Externa
Figura 3.1: tcnicas de verificacin y validacin
Figura 3.2: clasificaciones de las tcnicas dinmicas.
Figura 3.3. Clasificacin de tcnicas estticas
Figura 4.1: Porque Realizar pruebas?
Figura 4.2: estndar internacional
Figura 4.3: usos de metodologas
Figura 4.4: Diferencia con respecto al proceso de desarrollo y el proceso de pruebas
Figura 4.5: problemas o Retrasos en las pruebas de software
Figura 4.6: Apagn en EE.UU
Figura 4.7: mquina de radioterapia
Figura 6.1 Proceso de medicin de un software dentro de un proceso de control de
calidad.
Figura 6.2 Mtricas de prediccin y control.
Figura 6.3 Relacin entre los atributos internos y externos del software.
Figura 7.1 .Actividades de verificacin
Figura 7.2 Prevencin y eliminacin de fallos
Figura 7.3 Proceso de gestin de fallos.


Pgina 7

INTRODUCCION

El presente documento pretende dar a conocer todo lo referente a la calidad,
calidad de software y a la verificacin y validacin de un software (Prueba de
software)
Estos conceptos son fundamentales a la hora de gestionar la calidad de un proyecto
de software pero muchas veces no aplicados o no entendidos, es por ello que este
documento pretende ser una gua de apoyo a la implementacin de dichas reas de
proceso, y de sus metas y actividades.

El Software testing o como se conoce en espaol las pruebas de software se aplican
como una etapa ms del proceso de desarrollo de software, su objetivo es asegurar
que el software cumpla con las especificaciones requeridas y eliminar los posibles
defectos que este pudiera tener. En un principio la mayora de empresas de
desarrollo contaban con una etapa de pruebas demasiado informal, en la actualidad
el software testing se ha convertido en una de las etapas ms crticas del ciclo de
vida del desarrollo de software y esto ha causado el origen de diversas
metodologas.

En la actualidad el software testing se hace ms complicado ya que debe hacer
frente a una gran cantidad de metodologas de desarrollo, lenguajes de
programacin, sistemas operativos, hardware etc.


Pgina 8

1. CALIDAD Y EL SOFTWARE
1.1. Calidad
Definiciones: Podemos encontrar muchas definiciones en los textos de calidad, todas
ellas muy similares:

Propiedad o conjunto de propiedades inherentes a un objeto que permiten
apreciarlo como mejor, igual o peor que otros objetos de su especie [DRAE:
Diccionario de la Real Acadmica Espaola]
Conjunto de propiedades y de caractersticas de un producto o servicio que le
confieren capacidad para satisfacer necesidades expresadas o implcitas. [ISO
8042:1994]
Grado en el que un conjunto de caractersticas inherentes cumple con los requisitos.
[ISO 9000: 2000]

Las definiciones ms completas o formales:

Calidad, significa desarrollar, disear y producir y mantener un producto que
sea el ms econmico, el ms til y siempre satisfactorio para el consumidor.
[Kaoru Ishikawa]

Figura 1.1 Kaoru shikawa
Calidad, es la aplicacin de los principios y tcnicas estadsticas en todas las fases
de la produccin, dirigida a la fabricacin ms econmica de un producto
(servicio) que es til en grado mximo y que tiene mercado. [William Edwards
Deming]

Pgina 9

Figura 1.2 William Edwards Deming

Conceptos de Calidad: Segn la UNE 66-001-92 [AENOR, 1992], se define la calidad como:
Totalidad de caractersticas de un producto o servicio que le confieren su aptitud para
satisfacer unas necesidades expresadas o implcitas

La consecucin de la calidad puede tener tres orgenes:

Calidad Realizada: La que es capaz de obtener la persona que realiza el trabajo.
Calidad Programada: La calidad que se ha pretendido obtener.
Calidad Necesaria: La calidad que el cliente exige con mayor o menor grado de
concrecin.

1.2. Calidad en la Ingeniera de Software

Hay que tener en cuenta a la hora de abordar la calidad en el software un conjunto de
caractersticas del mismo que lo hace un producto peculiar:

Se desarrolla, no se fabrica en el sentido clsico del mismo.
Se trata de un producto lgico, sin existencia fsica.
No se degrada con el uso.
Por la complejidad del SW y la ausencia de controles adecuados, se suele
entregar el SW conscientemente con defectos (incluso pblicamente
declarados).
Un gran porcentaje de la produccin se hace an a medida en vez de emplear
componentes existentes y ensamblar.
Es muy flexible. Se puede cambiar con facilidad e incluso reutilizar
fragmentos.


Pgina 10

Figura 1.3 Desarrollo de Software en la Actualidad
1.3. Calidad del Software

Definicin oficial (IEEE Std. 610-1990) Es el grado con el que un sistema,
componente o proceso cumple:

Los requisitos especificados.
Las necesidades o expectativas del cliente o usuario.

Concordancia del software producido con los requisitos funcionales y de rendimiento
explcitamente establecidos, con los estndares de desarrollo explcitamente
documentados y con las caractersticas implcitas que se espera de todo software
desarrollado profesionalmente. [Pressman, 1998]

o Los requisitos establecidos explcitamente se reflejan en el documento de
especificacin de requisitos del sistema:
o Funcionales: funciones a realizar por el software.
o No funcionales (o extendidos): requisitos de seguridad, de rendimiento, etc
o Los requisitos implcitos no aparecen en el documento de especificacin de
requisitos del sistema. Si se cumplen los explcitos y no los implcitos, la calidad
del software queda en entredicho.
o El uso de estndares y las normas de desarrollo permiten que se consiga
una calidad tcnica.


Pgina 11

Figura 1.4 Cooperacin del Equipo de Trabajo para una buena Calidad de Software
1.4. Aseguramiento de calidad de software (Software Quality Assurance , SQA)
El propsito del Aseguramiento de la Calidad (Software Quality Assurance, SQA) es entregar
a la administracin una visibilidad adecuada del proceso utilizado y los productos
construidos mediante acciones planificadas y sistemticas que aseguren la calidad de
dichos procesos y productos.
Por ello, SQA abarca revisar, auditar e informar a la administracin del proyecto sobre la
adherencia de los productos y procesos a los estndares y procedimientos establecidos. El
proceso incluye todas las actividades, mtodos y prcticas para desarrollar o mantener
software y sus productos asociados. El producto comprende el software y todos los
artefactos creados como parte de la definicin, mantencin y uso del proceso de software,
incluyendo especificaciones, descripciones de procesos, planes, procedimientos, cdigo y
documentacin relacionada.
Basndose en lo anterior, los objetivos principales de SQA son:
1. Planificar las actividades de SQA.
2. Verificar la adherencia de los productos de trabajo y de las actividades a los
estndares, procedimientos y requerimientos establecidos.
3. Informar a los grupos e individuos afectados sobre las actividades de SQA y sus
resultados.
4. Comunicar a la administracin superior sobre desviaciones no resueltas dentro del
proyecto.

Pgina 12

Para alcanzar estos objetivos se requiere comprender la necesidad de un grupo responsable
de SQG (Software Quality Group), las actividades del proceso de SQA, sus tareas a lo largo
del ciclo de vida de un proyecto y su relacin con otras reas de prcticas del desarrollo de
software.
1.4.1. Grupo de SQA
El rol del grupo de SQA es guiar al equipo de desarrollo para alcanzar un producto de alta
calidad. La implantacin de la calidad es responsabilidad de la administracin superior y de
los grupos de desarrollo.
Es ms, la existencia de un grupo de calidad dedicado no garantiza por s sola que los
procesos sean seguidos y que la calidad se introduzca mgicamente en el producto. Debe
existir un compromiso de toda la organizacin por orientarse hacia una cultura de calidad
Dentro de las actividades de este grupo destacan
Preparar el Plan de SQA para cada proyecto
Participar en el desarrollo de la descripcin del proceso de software para un proyecto.
Revisar las actividades de ingeniera en acuerdo con el proceso definido.
Auditar los productos de trabajo designados, para verificar su adherencia con aquellos
definidos en el modelo de proceso.
Asegurar que las desviaciones en el desarrollo y en los productos de trabajo sean
documentadas y apoyadas por el procedimiento de documentacin.
Registrar cualquier disconformidad e informar a la administracin superior.
Coordinar la gestin de configuracin.
Apoyar la recoleccin y anlisis de mtricas de software.
1.4.2. Actividades del proceso de Aseguramiento de la calidad de software
SQA se define como un conjunto de actividades planificadas y sistemticas, cuyo primer
objetivo es evaluar la calidad y la adherencia de los productos de software a los estndares,
procesos y procedimientos. La conformidad con los estndares y procedimientos es
evaluada a travs del monitoreo de procesos, la evaluacin del producto y las auditoras
usando como medias estas actividades:
Estndares
Los estndares son los cimientos de cualquier sistema de calidad de software, pues
proveen la base para la evaluacin y medicin de las actividades y de los productos
de trabajo durante todo el ciclo de vida del software. Por tanto, ellos establecen el
marco de trabajo para el desarrollo de software, constituyndose en un factor
crtico de este ltimo.

Revisiones
Las revisiones son una metodologa definida, estructurada y disciplinada para la
deteccin e identificacin de defectos en los productos de trabajo durante el ciclo

Pgina 13

de vida del software. Cuenta con seis etapas: planificacin, orientacin,
preparacin, inspeccin, re-work y seguimiento, las cuales son llevadas a cabo por
un equipo con tareas y responsabilidades definidas, con documentacin especfica
y por un perodo determinado.

Prueba
La prueba es la ltima actividad de evaluacin del producto que permite detectar
defectos y establecer el nivel de satisfaccin de los requerimientos. Sus
actividades incluyen la planificacin, diseo, ejecucin y reporte sobre los
diferentes niveles de prueba existentes durante el proyecto. Estos niveles van
desde las pruebas de unidad, pasando por la de integracin, hasta las del sistema y
aceptacin.

Anlisis de defectos
Los defectos ocurren a lo largo de todo del ciclo de vida del software sin
excepcin. Por ello resulta natural concentrar esfuerzos en su deteccin y
correccin. No obstante a que la correccin de defectos es importante, ms lo es
su prevencin. Esta slo puede alcanzarse a partir del registro y seguimiento de los
defectos, puntapi inicial para un posterior anlisis. Es, entonces, el anlisis de
defectos la actividad responsable de corregir las deficiencias actuales en el
proceso y as disminuir los defectos en futuros proyectos

Gestin de Configuracin
El propsito de la Gestin de Configuracin (Software Configuration Management,
SCM) es establecer y mantener la integridad de los productos a travs de todo el
ciclo de vida del software, proveyendo un adecuado control de los cambios
producidos en los diversos tems de configuracin. Para ello, SCM se compone de
cuatro actividades principales: identificacin de la configuracin, control de
cambios, contabilidad y auditoras de la configuracin.

La identificacin de la configuracin proporciona un mtodo nico y especfico
para identificar cada instancia (release, versin, etc.) de un producto de software.
El control de cambios asegura que cada modificacin sobre alguna instancia del
producto sea conocida, autorizada y documentada. La contabilidad de la
configuracin permite establecer un seguimiento e informar sobre el estado de la
configuracin en un tiempo dado. Y, finalmente, las auditoras establecen si el
producto ha sido construido de acuerdo a los requerimientos y que el software
est realmente representado por la documentacin que le acompaa.


Pgina 14

1.4.3. Tcnicas de Aseguramiento de la calidad de software
El aseguramiento de la calidad aborda principalmente tres reas o tcnicas:
1. Mtricas del software: para el control del proyecto
2. Verificacin y validacin: a lo largo del ciclo de vida del software, incluyendo
pruebas y procesos de revisin.
3. Gestin de la configuracin del software
A. Mtricas del software
Por trmino general, para la evaluacin de la calidad, es ms habitual centrarse en
medidas del producto que en medidas del proceso.
Una mtrica es una asignacin de un valor a un atributo (tiempo, complejidad, etc.) de una
entidad software, ya sea un producto (cdigo) o un proceso (pruebas). Dentro de las
mtricas de las caractersticas del software se puede clasificar de la siguiente manera:
Clasificacin 1:
Mtricas de producto
Mtricas de proceso.

Clasificacin 2:
A) Mtricas basadas en atributos internos del producto:
Medidas de estructuracin de un programa.
Mtricas de complejidad.
Mtricas de cobertura de pruebas.
Mtricas de calidad del diseo.

B) Mtricas basadas en atributos externos del producto:
Mtricas de portabilidad.
Mtricas de defectos.
Mtricas de usabilidad.
Mtricas de mantenibilidad.
Mtricas de fiabilidad.

C) Mtricas basadas en cdigo fuente:
N de lneas de cdigo.
N de lneas de comentario.
N de instrucciones.

Pgina 15

Densidad de documentacin.

D) Mtricas basadas en estructura de diseo:
Relacionadas con el control intramodular.
Relacionadas con el acoplamiento entre clases.

E) Mtricas para sistemas orientados a objetos:
Acoplamiento.
Herencia.
Cohesin.
B. Verificacin y validacin
Verificacin y validacin es el proceso de garantizar que un diseo cumple con los
requisitos.
La verificacin confirma que los productos reflejan los requisitos especificados para
cada caso concreto, garantizando que desarroll el producto correctamente.

La validacin confirma que el producto final se ajustar al uso pretendido,
garantizando que desarroll el producto correcto.

C. Gestin de la configuracin de software
Es un conjunto de actividades diseadas para identificar y definir los elementos en el sistema que
probablemente cambien, controlando el cambio de estos a lo largo del ciclo de vida, estableciendo
relaciones entre ellos, definiendo mecanismos para gestionar distintas versiones de estos
elementos, y auditando e informando de los cambios realizados.
Se podra decir que su propsito principal es el de establecer y mantener la integridad de los
productos de software a travs del ciclo de vida del proceso del software.
La necesidad de esto surge dado que los requerimientos del sistema siempre cambian durante su
desarrollo y su uso, y se tienen que incorporar estos requerimientos en nuevas versiones del
sistema.
Es as que la importancia de la gestin de la configuracin de software aparece, ya que cambios
incontrolados aplicados a un proyecto de software lo llevan al fracaso.


Pgina 16

2. MODELOS DE CALIDAD DE SOFTWARE
2.1. Estructura De Un Modelo De Calidad De Software
Tienen una estructura, por lo general, en tres niveles:

Figura 2.1. Estructura de un Modelo de Calidad Del Software
Factores de Calidad
Criterios de Calidad de un
Producto
Mtricas del Producto

Pgina 17

Factores de Calidad: Es el nivel ms alto de la jerarqua, representa la calidad
desde un punto de vista del usuario. Son las caractersticas que componen la
calidad. Se les llama Atributos de Calidad Externos.
Criterios de Calidad de un Producto: Cada uno de los factores se descomponen en
un conjunto de Criterios de Calidad. Cuando estn presenten contribuyen al
aspecto de la calidad. Se les llama Atributos de Calidad Internos.
Mtricas del Producto: Para cada uno de los Criterios de Calidad se definen un
conjunto de Mtricas, que son medidas cuantitativas de ciertas caractersticas del
producto que, cuando estn presentes, dan una indicacin del grado en que dicho
producto posee un determinado atributo de calidad.
2.2. Modelos de Calidad del Software
2.2.1. Modelos de Calidad del Software a nivel proceso
A. Modelo CMMI (Capability Maturity Model Integration)
Bsicamente el CMMI son normas para calidad enfocada al mundo del Software.
Estas se aplican a los diferentes procesos que hay que llevar a cabo para lograr
producir software con calidad, es muy importante mencionar que igual que las
normas ISO 90003, este modelo nos dice que hay que hacer, y no como hay que
hacerlo.
El modelo CMMI permite:

Describir los componentes del modelo y sus relaciones.
Comprender las reas de proceso.
Localizar informacin relevante en el modelo.
Aplicar los conocimientos a su entorno de trabajo y en un equipo de
evaluacin de componentes y sus relaciones de un modelo.

Modelo Escalonado
Se representa mediante niveles o escalones para calificar la madurez de una
organizacin.

Niveles de Madurez:
Definen 05 niveles

Nivel 1: Inicial
La mayora de los procesos son "ad-hoc" y caticos. La organizacin usualmente
no provee un ambiente estable para soportar los procesos. Estas
organizaciones son caracterizadas por la tendencia a no cumplir sus
compromisos, al abandono de procesos durante tiempos de crisis, y a la
incapacidad para repetir sus xitos. Es claro que el nivel de madurez 1 de
CMMI es uno donde ninguna organizacin quiere estar y donde por lo general
la mayora que no tiene sus procesos definidos se encuentra.


Pgina 18

Nivel 2: Gestionado
Se ordena el caos. En el nivel 2 las organizaciones se enfocan en tareas
cotidianas referentes a la administracin. Cada proyecto de la organizacin
cuenta con una serie de procesos para llevarlo a cabo, los cuales son planeados
y ejecutados de acuerdo con polticas establecidas; son monitorizados,
controlados y revisados; y son evaluados segn la descripcin del proceso. La
disciplina del proceso reflejada por el nivel de madurez 2 de CMMI ayuda a
asegurar que existen prcticas y los proyectos son realizados y manejados de
acuerdo a los planes documentados.

Nivel 3: Definido
Los procesos son caracterizados y entendidos de buena forma, y son descritos
en estndares, procedimientos, herramientas, y mtodos. El conjunto de
procesos estndares de la organizacin, los cuales son la base para el nivel de
madurez 3 de CMMI, es establecido y mejorado continuamente.

Nivel 4: Cuantitativamente Gestionado
La organizacin y proyectos establecen objetivos cuantitativos para medir la
calidad y realizacin de los procesos y los usa como criterios en el manejo de
ellos. La calidad y realizacin de procesos son entendidos en trminos
estadsticos y son manejados durante todo el ciclo de vida del proceso.

Nivel 5: Optimizado
Una organizacin mejora continuamente sus procesos basndose en el
conocimiento de las causas comunes de variacin inherente en los procesos. El
nivel de madurez 5 de CMMI se focaliza sobre la mejora continua de los
procesos a travs de mejoras continuas, incrementales y tecnolgicas.

Modelo Continuo
Enfoca las actividades de mejora y evaluacin en la capacidad de los diferentes
procesos, el cual es medido en diferentes niveles de capacidad.

Niveles de Capacidad
Definen 06 Niveles

Capacidad 0: Incompleto
Un "proceso incompleto" es un proceso que, o bien no se ejecuta, o se ejecuta
parcialmente. Al menos una de las metas especficas del rea del proceso no se
satisface y no existe metas genricas para ese nivel, ya que no hay ninguna
razn para institucionalizar un proceso ejecutado parcialmente.

Capacidad 1: Realizado
Un proceso realizado es un proceso que satisface las metas especficas del rea
de proceso. Soporta y permite el trabajo necesario para producir los productos

Pgina 19

del trabajo. Aunque el nivel de capacidad 1 da como resultado mejoras
importantes, esas mejoras pueden perderse en el tiempo si no se
institucionalizan. La aplicacin de la institucionalizacin (las prcticas genricas
de CMMI en los niveles de capacidad 2 a 5) ayuda a asegurar que las mejoras se
mantendrn.

Capacidad 2: Gestionado
Un proceso de nivel de capacidad 2 se caracteriza cmo un "proceso
gestionado". Un proceso gestionado es un proceso realizado (nivel de
capacidad 1) que tiene la infraestructura bsica dispuesta para soportar el
proceso. Se planifica y ejecuta de acuerdo a polticas; emplea personal con
habilidades; tiene los recursos adecuados para producir resultados controlados;
involucra a las partes interesadas relevantes; se monitoriza, controla y revisa; y
se evala la adherencia a su descripcin del proceso. La disciplina de proceso
reflejada por el nivel de capacidad 2 ayuda a asegurar que las prcticas
existentes se mantienen durante tiempo de estrs.

Capacidad 3: Definido
Adems de ser un proceso gestionado (nivel de capacidad 2) se ajusta a la
poltica de procesos que existe en la organizacin.

Capacidad 4: Gestionado Cuantitativamente
Un proceso gestionado cuantitativamente es un proceso definido (nivel de
capacidad 3) que se controla utilizando tcnicas estadsticas y otras tcnicas
cuantitativas. Se establecen los objetivos cuantitativos de calidad y de
ejecucin del proceso, y se utilizan cmo criterios para gestionar el proceso. Se
comprende la calidad y el rendimiento del proceso en trminos estadsticos y
se gestionan a lo largo de la vida del proceso.

Capacidad 5: Optimizado
Un proceso en optimizacin es un proceso gestionado cuantitativamente (nivel
de capacidad 4) que se mejora en base a una comprensin de las causas
comunes de variacin inherentes al proceso. El enfoque de un proceso en
optimizacin es mejorar continuamente el rango de la ejecucin del proceso
mediante mejoras, tanto incrementales cmo innovadoras.

Figura 2.2. Representaciones CMMI

Pgina 20

B. Modelo ISO/IEC 15504 Spice

El modelo ISO/ IEC 15504, utiliza una gua para la evaluacin de proyectos, que
envuelve la medicin de un proceso, este mtodo de medicin plantea uso de
Mtricas de calidad, la administracin de datos (incluyendo datos histricos), y el
manejo de mtricas en la organizacin, su principal objetivo es la generacin de
mtricas de proceso y de producto para dar soporte a la planificacin efectiva y as
mejorar la calidad de los productos, Este engloba un modelo de referencia para los
procesos y sus potencialidades sobre la base de la experiencia de compaas
grandes, medianas y pequeas.

Niveles de Madurez

Nivel 0: Organizacin Inmadura: La organizacin no tiene una implementacin
efectiva de los procesos.

Nivel 1: Organizacin Bsica: La organizacin implementa y alcanza los objetivos
de los procesos.

Nivel 2: Organizacin Gestionada: La organizacin gestiona los procesos y los
productos de trabajo se establecen, controlan y mantienen.

Nivel 3: Organizacin Establecida: La organizacin utiliza procesos adaptados
basados en estndares.

Nivel 4: Organizacin Predecible: La organizacin gestiona cuantitativamente los
procesos.

Nivel 5: Organizacin Optimizada: La organizacin mejora continuamente los
procesos para cumplir los objetivos de negocio.

C. Modelo IT Mark

Es un servicio internacional de certificacin que estudia los procesos tcnicos y de
negocio, diseado especialmente para PYMES del sector Ti, para medir el
reconocimiento de Excelencia en Tecnologas de la Informacin. Tambin
podemos decir que es un servicio clave diseado para PYMES, que las ayuda a
posicionarse a travs de la Mejora Continua con sostenibilidad.

Este mtodo es adaptado para PYME, ayuda al mejoramiento de procesos de
software y a la mejora de otros procesos importantes de empresas que desarrollan
y mantienen soluciones en TI.


Pgina 21

Este modelo est diseado principalmente para pequeas empresas y micro
empresas, aunque tambin es aplicable para grandes organizaciones.

Niveles IT Mark

I.T. Mark: acredita que la empresa es consciente de los temas relacionados con la
gestin tcnica, de la Seguridad y del Negocio y ha realizado pasos para
controlarlos.

I.T. Mark Premium: acredita que la empresa ha alcanzado un Buen nivel de la
capacidad de los procesos de Negocio, Seguridad y Desarrollo de Software segn
los modelos reconocidos en el mundo.

I.T. Mark Elite: acredita que la empresa ha alcanzado un Alto nivel de Definicin e
Institucionalizacin de sus procesos de Negocio, Seguridad y Desarrollo de
Software, as como que la calidad de sus productos es buena debido a su proceso
de mejora continua.

2.2.2. Modelos
A. Modelo de McCall
La calidad de un sistema, aplicacin o producto es tan buena como los requisitos
que describen el problema, el diseo que modela la solucin, el cdigo que
conduce a un programa ejecutable y las pruebas que ejercitan el software para
detectar errores. Un buen Ingeniero del Software utiliza mediciones que evalan la
calidad del anlisis y los modelos de diseo, el cdigo fuente y los casos de prueba
que se han creado al aplicar la Ingeniera de Software. Para lograr estas
evaluaciones de la calidad en tiempo real, el Ingeniero debe utilizar medidas
tcnicas que evalan la calidad con objetividad, no con subjetividad. Hace 25 aos
se definieron factores de calidad como los primeros pasos hacia el desarrollo de
mtricas de calidad del software.
El modelo de McCall organiza los factores en tres ejes o puntos de vista desde los
cuales el usuario puede contemplar la calidad de un producto Operacin del
producto, Revisin del producto y Transicin del producto. Cada punto de vista se
descompone en una serie de factores que determinan la calidad de cada una de
ellos. Cada factor determinante de la calidad, se descompone, a su vez, en una
serie de criterios o propiedades que determinan su calidad. Los criterios pueden
ser evaluados mediante un conjunto de mtricas. Para cada criterio deben fijarse
unos valores mximo y mnimo aceptables para cada criterio.

El modelo de McCall se basa en 11 factores de calidad, que se organizan de la
siguiente:

Visin del Usuario Factores de Calidad Segn McCall
Operacin del Producto Facilidad de Uso Integridad Correccin

Pgina 22

Confiabilidad Eficiencia.
Revisin del Producto Facilidad de Mantenimiento Facilidad de Prueba
- Flexibilidad
Transicin del Producto Reusabilidad Interoperabilidad - Portabilidad
Tabla 1. Visin del Usuario respecto a los Factores de Calidad del Modelo de
McCall

Operacin del Producto
Requiere que el software pueda ser entendido fcilmente, que opere
eficientemente y que los resultados obtenidos sean los requeridos
inicialmente por el usuario.

Revisin del Producto
Tiene como objetivo realizar revisiones durante el proceso de desarrollo para
detectar los errores que afecten a la operacin del producto.

Transicin del Producto
Requiere de la definicin de estndares y procedimientos que sirvan como
base para el desarrollo de software.

Figura 2.3. Factores de Calidad del Modelo de McCall

B. Modelo de Boehm

Este modelo es el ms conocido y representado por Barry Boehm en 1978
este modelo introduce caractersticas de alto nivel, caractersticas de nivel
intermedio y caractersticas primitivas, cada una de las cuales contribuye al
nivel general de calidad.

I. Caractersticas de Alto Nivel


Pgina 23

Las caractersticas de alto nivel representan requerimientos generales de
uso, pueden ser:

Utilidad per-se cuan (usable, confiable, eficiente) es el producto en s
mismo.
Mantenibilidad cun fcil es modificarlo, entenderlos y retestearlo.
Utilidad general si puede seguir usndose si se cambia el ambiente.

II. Caractersticas de Nivel Intermedio

Las caractersticas de nivel intermedio representan los factores de
calidad de Boehm:

Portabilidad (utilidad general).
Confiabilidad (utilidad per-se).
Eficiencia (utilidad per-se).
Usabilidad (utilidad per-se).
Testeabilidad (mantenibilidad).
Facilidad de entendimiento (mantenibilidad).
Modificabilidad o flexibilidad (mantenibilidad).
III. Caractersticas Primitivas

El nivel ms bajo corresponde a caractersticas directamente
asociadas a una o dos mtricas de calidad:

A. DE PORTABILIDAD

Independencia de dispositivos
Auto-contencin. De confiabilidad
Auto-contencin.
Exactitud
Completitud
Consistencia
Robustez/integridad

B. DE EFICIENCIA

Accesibilidad
Eficiencia de uso de dispositivos

C. DE USABILIDAD

Robustez/integridad
Accesibilidad
Comunicacin


Pgina 24

D. DE TESTEABILIDAD

Contabilidad
Accesibilidad
Comunicabilidad
Auto Descriptivo
Estructuracin

E. DE ENTENDIBILIDAD

Consistencia
Auto Descriptivo
Estructuracin
Concisin
Legibilidad

F. DE MODIFICALIDAD

Estructuracin
Aumentabilidad

Pgina 25

Figura 2.4. Modelo de Boehm
C. Modelo ISO 9126

Pgina 26

El estndar 9126 propone un modelo de calidad que se divide en tres vistas: interior,
exterior y de uso. Estas estn compuestas por caractersticas, las que se dividen en
sub caractersticas

I. Caractersticas de Calidad Internas y Externas

En ISO 9126 se reconocen seis factores de calidad que se pueden considerar tanto
internos como externos.

A. FUNCIONALIDAD

Adecuacin
Exactitud
Seguridad
Interoperabilidad
Cumplimiento

B. CONFIABILIDAD

Madurez
Tolerancia a las fallas
Recuperacin
Cumplimiento

C. EFICIENCIA

En tiempo
En recursos
Cumplimiento

D. USABILIDAD

Entendimiento
Aprendizaje
Operabilidad
Atractivo
Cumplimiento

E. MANTENIBILIDAD

Analizabilidad
Facibilidad para el cambio
Estabilidad
Testeabilidad
Cumplimiento

F. PORTABILIDAD

Pgina 27

Adaptabilidad
Instalabilidad
Conformidad
Reemplazo

Figura 2.5. Caractersticas Modelo de Calidad para la Calidad Interna y Externa

II. Caractersticas de Calidad de Uso

En ISO 9126 se reconocen cuatro factores de calidad de uso.

Eficiencia
Productividad
Satisfaccin
Seguridad

Figura. Caractersticas de Vista de Uso (Calidad de Uso)


Pgina 28

3. VERIFICACIN Y VALIDACIN

3.1. Definiciones de Verificacin y Validacin:

La verificacin y la validacin no son lo mismo, aunque a menudo se confunden.
Boehm expres la diferencia entre ellas de la siguiente manera:
- Verificacin: Se est construyendo el producto de la manera correcta?
- Validacin: Se est construyendo el producto correcto?
A. DEFINICIN DE VERIFICACIN:
Comprobar o examinar la verdad de algo. Es el proceso que se realiza para revisar si un
determinado producto est cumpliendo con los requisitos y normas previstos.
La verificacin implica comprobar que el software est de acuerdo con su especificacin.
Debera comprobarse que satisface sus requisitos funcionales y no funcionales.
B. DEFINICIN DE VALIDACIN:
Dar fuerza o firmeza a algo, hacerlo vlido. Es el proceso que se realiza para revisar si un
determinado producto es el que el usuario necesita.
La validacin, sin embargo, tiene como objetivo asegurar que el sistema satisface las
expectativas del cliente. Va ms all de la comprobacin de que el sistema satisface su
especificacin para demostrar que el software hace lo que el cliente espera que haga, ya
que las especificaciones del sistema no siempre reflejan los deseos o necesidades reales
de los usuarios y los propietarios del sistema.
3.2. Objetivo De La Verificacin Y Validacin
El objetivo es establecer la seguridad de que el sistema es lo suficientemente bueno para su
uso predeterminado. Ayuda en la toma de decisiones con respecto a cundo hay que dejar
de probar y liberar el software.
El propsito o funcin del sistema. El nivel de confianza necesario depende de lo crtico que
sea el software para una organizacin. Por ejemplo, el nivel de confianza del software que
se utiliza para controlar un sistema de seguridad crtico es mucho ms alto que el requerido

Pgina 29

para un prototipo de un sistema software que ha sido desarrollado para demostrar nuevas
ideas.
Las expectativas del usuario. Una reflexin lamentable sobre la industria del software es
que a muchos usuarios no les sorprende cuando su software falla durante su uso. Estn
dispuestos a aceptar estos fallos del sistema cuando los beneficios de su uso son mayores
que sus desventajas. Sin embargo, la tolerancia de los usuarios a los fallos de los sistemas
est decreciendo en los ltimos aos. Actualmente es menos aceptable entregar sistemas
no fiables, por lo que las compaas deben invertir ms esfuerzo en llevar a cabo las
actividades de verificacin y validacin.
Entorno de mercado actual. Cuando un sistema se comercializa, los vendedores del sistema
deben tener en cuenta los programas competidores, el precio que sus clientes estn
dispuestos a pagar por el sistema y los plazos requeridos para entregar dicho sistema.
Cuando una compaa tiene pocos competidores, puede decidir entregar un programa antes
de que haya sido completamente probado y depurado, debido a que quiere ser el primero
en el mercado. Cuando los clientes no estn dispuestos a pagar precios altos por el
software, pueden estar dispuestos a tolerar ms defectos en l. Todos estos factores
pueden considerarse cuando se decide cunto esfuerzo debera invertirse en el proceso de
validacin y verificacin.
3.3. Tcnicas De Verificacin Y Validacin
Existen 2 Tcnicas de Verificacin y Validacin:
Tcnicas dinmicas, tambin conocido como prueba o Experimentacin
Tcnicas estticas, tambin conocido como Anlisis

Pgina 30

Figura 3.1: tcnicas de verificacin y validacin
I. TECNICAS DINMICAS (PRUEBA, EXPERIMENTACIN)
Concepto
Se realiza durante la ejecucin del software, y comprueba dinmicamente su
comportamiento; Para ello introducen una serie de valores de entrada, y examinan la salida
comparndola con los resultados esperados.
Clasificaciones de las tcnicas dinmicas

Figura 3.2: clasificaciones de las tcnicas dinmicas.
a) Basadas en la especificacin: Son conocidas como tcnicas de pruebas de caja negra o
conducida por entradas/salidas, porque tratan el software como una caja negra con
entradas y salidas, pero no tienen conocimiento de cmo est estructurado el programa.
A continuacin, se detallarn las tcnicas basadas en la especificacin ms comunes.

Pgina 31

Particionamiento de equivalencia: Esta tcnica consiste en dividir un conjunto de
condiciones de prueba en grupos o conjuntos que puedan ser considerados iguales por el
sistema.
Anlisis de valor frontera: Los errores generados por los programadores tienden a
agruparse alrededor de las fronteras. Por ejemplo, si un programa debera aceptar una
secuencia de nmeros entre 1 y 10, el error ms probable ser que los valores justo fuera
del rango sean aceptados de forma incorrecta o que los valores justo en los lmites del
rango sean rechazados.
Una tabla de decisin: lista todas las condiciones de entrada que pueden ocurrir y todas
las acciones que pueden surgir de ellas.
Las pruebas de transicin de estados: se usan cuando alguno de los aspectos del sistema
se pueden describir en lo que se denomina una mquina de estados finitos. Esto
significa que el sistema puede estar en un nmero (finito) de estados, y las transiciones de
un estado a otro estn determinadas por las reglas de la mquina.
Los casos de uso: describen el flujo de proceso a travs de un sistema basado en su uso
ms probable. Esto hace que los casos de prueba obtenidos de los casos de uso sean
particularmente tiles a la hora de encontrar defectos en el uso real del sistema

b) Basadas en la estructura: Las pruebas estructurales son una aproximacin al diseo de
casos de prueba donde las pruebas se derivan a partir del conocimiento de la estructura e
implementacin del software. Esta aproximacin se denomina a veces pruebas de caja
blanca.
Pruebas de sentencia: El objetivo de las pruebas de sentencia es ir probando las
distintas sentencias a lo largo del cdigo. Si se prueban todas y cada una de las
sentencias ejecutables del cdigo, habr una cobertura de sentencia total.
Pruebas de decisin: Las decisiones son parte de las estructuras de seleccin e
iteracin.
Pruebas de caminos: Las pruebas de caminos son una estrategia de pruebas
estructurales cuyo objetivo es probar cada camino de la ejecucin
independientemente. En todas las sentencias condicionales, se comprueban los casos
verdadero y falso.

c) Basadas en la experiencia: Las tcnicas basadas en experiencia son aquellas a las que se
recurre cuando no hay una especificacin adecuada desde la que crear casos de prueba
basados en especificacin, ni hay tiempo suficiente para ejecutar la estructura completa
del paquete de pruebas.
Adivinar errores: Las tcnicas basadas en experiencia usan la experiencia de los usuarios y
de los tcnicos de pruebas.
Pruebas exploratorias: Tcnicas de pruebas ms sofisticadas que se realizan sobre la base
del conocimiento y experiencia de los tcnicos de pruebas;

II. TCNICAS ESTTICAS (ANLISIS)

Pgina 32

Concepto
Analizan y comprueban las representaciones del sistema tales como el documento de
requerimientos, diagramas de diseo y cdigo fuente del programa. Puede usarse en todas
las etapas del proceso. La mayora de las tcnicas estticas son tcnicas de verificacin que
pueden probar cualquier tipo de documentacin ya sea cdigo fuente, o documentacin y
modelos de diseo, o especificacin funcional o de requisitos.
Clasificacin de las tcnicas estticas

Las revisiones: son una tcnica esttica que consiste en realizar un anlisis de un documento con
el objetivo de encontrar y eliminar errores.
No existe una revisin perfecta, sino que cada una tiene un propsito distinto durante las
etapas del ciclo de vida del documento. Los principales tipos de revisiones se describen a
continuacin:

Informal: Dar un borrador de un documento a un colega para que lo lea es el ejemplo ms
simple de revisin. Es una forma de conseguir beneficios (limitados) a un bajo costo ya que
no siguen ningn proceso formal a seguir.
Walkthrough: Un walkthrough se caracteriza porque el autor del documento bajo revisin
va guiando al resto de participantes a travs del documento exponiendo sus ideas para
conseguir un entendimiento comn y recoger respuestas.
Revisin tcnica: Una revisin tcnica es una reunin que se centra en conseguir consenso
sobre el contenido tcnico de un documento, por lo que es posible que sea dirigida por un
experto tcnico.
Inspecciones: La inspeccin es el tipo de revisin ms formal. El documento bajo
inspeccin es preparado y validado minuciosamente por revisores antes de la reunin, se
compara el producto con sus fuentes y otros documentos, y se usan listas de
comprobacin. En la reunin de la inspeccin, se registran los defectos encontrados y se
pospone toda discusin para la fase de discusin. Todo esto hace que la inspeccin sea
una reunin muy eficiente.

Se define completamente el proceso. Revisin en detalle, por una persona o grupo distintos
del autor, para:
Figura 3.3. Clasificacin de
tcnicas estticas

Pgina 33

Verificar si el producto se ajusta a sus especificaciones o atributos de Calidad y
a los estndares utilizados en la empresa.

Sealar las desviaciones sobre los estndares y las especificaciones.

Recopilar datos que realimenten inspecciones posteriores defectos recogidos,
esfuerzo empleado, etc.).

Estas pruebas, son las primeras que se aplican al software y buscan defectos sin
ejecutar cdigo. Por esta razn, tambin se llaman tcnicas de no ejecucin

4. OBJETIVOS Y RESTRICCIONES

4.1. Objetivos de Las Pruebas
Las pruebas presentan una interesante anomala para el ingeniero del software.
Durante las fases anteriores de definicin y de desarrollo, el ingeniero intenta construir el
software partiendo de un concepto abstracto y llegando a una implementacin tangible. A
continuacin, llegan las pruebas. El ingeniero crea una serie de casos de prueba que
intentan demoler el software construido. De hecho, las pruebas son uno de los pasos de la
ingeniera del software que se puede ver como destructivo en lugar de constructivo.
(Pressman, 2005)
Algunos objetivos de las pruebas de software de acuerdo a Pressman (2002) son:
La prueba es el proceso de ejecucin de un programa con la intencin de descubrir un error.
Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no
descubierto hasta entonces.
Una prueba tiene xito si descubre un error no detectado hasta entonces.
En general los objetivos de las pruebas de software es disear pruebas que
sistemticamente saquen a la luz diferentes clases de errores, hacindolo con la menor
cantidad de tiempo y de esfuerzo.
Adems, los datos que se van recogiendo a medida que se lleva a cabo la prueba
proporcionan una buena indicacin de la fiabilidad del software y, de alguna manera,
indican la calidad del software como un todo. Sin embargo, la prueba no puede asegurar la
ausencia de defectos; slo puede demostrar que existen defectos en el software.
En resumen los objetivos de las pruebas de software es el proceso de encontrar errores y
fallas, es decir la razn primordial de las pruebas es tratar que el software falle o tenga

Pgina 34

errores con el mnimo de tiempo y recursos. Se busca en cada prueba que el software tenga
errores, y no que este absuelto de ellos.

4.2. Limitaciones de las Pruebas de Software

Algunas de las limitaciones existentes a nivel de pruebas de software son:
No existe una recopilacin formal que especifique y describa los tipos de prueba que se
deben aplicar a una pieza de software y se detalle la implementacin precisa de cada uno de
ellos. Aunque existen algunos documentos, en su mayora son de carcter muy acadmico y
poco prctico. Por otro lado, y aunque ISO plantea en normas como la ISO/FDIS 9126 ciertos
aspectos en los cuales el producto de software debe ser conforme, no es suficientemente
especifico.

Figura 4.2: estndar internacional
Las tcnicas de pruebas generalmente son subestimadas como tiles, en tanto que no se
usan en la prctica para el diseo de casos de prueba formales. En general y en entornos
productivos, las tcnicas utilizadas para la deteccin de errores son del tipo suposicin de
errores y en el mejor de los casos de tipo aleatorio el cual por sus caractersticas propias no
es un mtodo que aporte mucho a la deteccin de errores en el producto de software.
Los estndares y modelos planteados en torno al aseguramiento de la calidad de los
productos de software por su carcter de universales y genricos son muy poco especficos
Figura 4.1: Porque Realizar pruebas?

Pgina 35

a la hora de describir la forma de realizar implementaciones en entornos productivos reales;
en la mayora de los casos la generalidad es una de sus principales caractersticas. Esto
permite que su aplicacin en diversos ambientes sea posible, pero limita las prcticas a
realizar puesto que deben ser diseadas en su detalle por la organizacin, lo cual en muchos
casos exige un conocimiento experto y asesoras externas que hacen a una compaa
aferrarse a una prctica con un conjunto de particularidades que no siempre son las
mejores.
Tomando en cuenta que una organizacin debe estar basada en un modelo de calidad que
permita un tratamiento global de los procesos, y que adicionalmente deben existir un
conjunto de estndares, reglas, prcticas y normativas extras no especificadas en el modelo
aplicado a la misma, es importante comentar la inexistencia casi total de una descripcin
formal que encierre en conjunto un modelo de calidad, un modelo de pruebas, una
metodologa y unas prcticas especficas en pruebas de software que sean concordantes
entre si y entre las polticas generales de un modelo de calidad determinado; en cambio de
ello toda la informacin est desagregada mediante modelos y estndares.
Adicionalmente por ser modelos de calidad orientados a la madurez de los procesos y los
productos, los periodos de tiempo necesarios para que la madurez llegue a un nivel
deseable son relativamente largos, lo cual conlleva a que aunque se logren avances en la
calidad de los productos paulatinamente se logra la madurez, solo se empieza a tener un
esfuerzo ms proporcional al beneficio cuando todo el proceso es idealmente maduro y la
organizacin logra converger hacia las prcticas que plantea el modelo de calidad general
implantado.
Los estndares diseador por la ISO especficamente el ISO/FDIS 9126, ISO 14598 e
ISO/IEC 15504 presentan un nivel de complejidad variable al momento de ser usados de
acuerdo a la organizacin en donde se desee implantar, sin embargo, una caracterstica
anexa, es que aunque es posible su establecimiento en una organizacin que no cuenta de
antemano con un modelo de calidad ya preestablecido, lo recomendable y casi requisito no
especificado, es que si lo exista, ya que dichos estndares exigen elementos como proceso
definidos, polticas de aseguramiento de la calidad claras, y prcticas que lleven a la
madurez entre otras para cumplir sus propios objetivos. Lo ms comn es tener modelos de
calidad y de mejoramiento continuo como ISO 9000 y CMMI con el fin de que la aplicacin

Pgina 36

de estndares de aseguramiento de calidad exigentes como los mencionados tengan
elementos suficientes como para que su adhesin a los procesos organizacionales sea
exitosa.
La razn por la cual la industria no adopta metodologas y estndares es la dificultad de la
utilizacin de estos para pruebas de software. En las pequeas y medianas empresas la
dificultad radica en la necesidad que estas tienen de competir mediante tiempos y precios y
dada la poco practicidad que los estndares tienen asociados se incurre en consumos de
recursos poco tolerables; por otra parte las grandes compaas adems de los factores
anteriores, compiten mediante calidad y para lograr un buen indicador deben implementar
los diferentes metodologas y estndares que garanticen la madurez de los procesos, para
estas compaas la falta de practicidad de los estndares en ms un requisito de sus clientes
que un riesgo asociado al uso de recursos.

Implementar un proceso de pruebas al interior de una compaa es costoso, adems el
proceso debe madurar para que se adapte a las necesidades especficas de la organizacin;
este hecho obliga a muchas empresas a subcontratar los procesos de pruebas. En ocasiones
esta es una buena opcin puesto que evita posibles sesgos en las pruebas pero en general
puede conllevar serios problemas al interior de la organizacin que van desde la
confidencialidad de la informacin hasta el incremento de los tiempos de desarrollo.
Las pruebas de software ms complejas basan su diseo y su ejecucin en los artefactos
desarrollados en etapas de anlisis y diseo; si estos artefactos no son construidos o tienen
deficiencias como falta de consistencia y coherencia; aparte de afectar todo el proceso de
desarrollo se ver comprometido el aseguramiento de la calidad y dentro de est las
Figura 4.3: usos de metodologas

Pgina 37

pruebas los tipos de pruebas de software que buscan hallar defectos ms profundos. La
buena ingeniera de software se convierte en una necesidad bsica para el correcto
desarrollo
de las pruebas de
software.

Figura 4.4: Diferencia con respecto al proceso de desarrollo y el proceso de pruebas
En general los problemas que se encuentran en un proceso de pruebas son:
- Los probadores desconocen el dominio o los tipos y tcnicas a utilizar cuando se requieren
pruebas de alto nivel, en general este problema se da al tener personal poco capacitado
para la labor.
- Los proveedores de pruebas generalmente posponen la labor de pruebas a las etapas
finales del ciclo de vida del software, lo que ocasiona problemas por retrasos. Estos
retrasos se dan generalmente por que el equipo de pruebas debe adquirir el conocimiento
del dominio necesario y disear las pruebas, tareas que se pueden realizar de forma
transversal al proceso de desarrollo optimizando los recursos disponibles.


Pgina 38

Figura 4.5: problemas o Retrasos en las pruebas de software
- En ocasiones los probadores no cuentan con los insumos necesarios para realizar un
proceso de pruebas maduro y completo. Estos insumos corresponden a una buena
documentacin y a un completo y correcto levantamiento de requisitos, que orienten al
probador, tanto en la ejecucin y desarrollo de las pruebas como en el aprendizaje del
dominio.
- Muchas organizaciones contemplan su proceso de QA basado en las pruebas de software
lo cual trae perjuicios en la calidad de los productos al no incluir procesos como medicin,
anlisis, verificacin y validacin, todos ellos componentes esenciales de QA.}

4.3. Errores por la Falta de Pruebas de Software
Apagn de 2003 en Norteamrica
Priv de electricidad a un estimado de 50 millones de personas. El apagn se debi a un
error en el software de monitoreo basado en Unix de General Electric, que impidi que los
operadores se dieran cuenta de un corte local de energa. El efecto domin de la falla afect
a ocho estados de Estados Unidos y a Ontario, en Canad.

Figura 4.6: Apagn en EE.UU

Pgina 39

Therac-25
Estuvo envuelta en al menos seis accidentes entre 1985 y 1987, en los que los pacientes
recibieron sobredosis masivas de radiacin, de aproximadamente cien veces la dosis
esperada. Tres de los seis pacientes murieron como consecuencia directa. Estos accidentes
remarcaron los riesgos del control por software de sistemas de seguridad crtica, y estos se
convirtieron en un caso de estudio tpico de la informtica mdica y la ingeniera de
software.

Figura 4.7: mquina de radioterapia

5. PLANIFICACIN
5.1. Planificacin
La planificacin de la calidad es el proceso en el cual se desarrolla un plan de calidad para un
proyecto. El plan de calidad define la calidad de software deseado y describe como valorar
sta. Por lo tanto, define lo que es software de alta calidad. Sin sta definicin, los
diferentes ingenieros pueden trabajar en direcciones opuestas para optimizar los atributos
del proyecto.
El plan de calidad selecciona los estndares organizacionales apropiados para un producto y
un proceso de desarrollo particulares. Si el proyecto utiliza nuevos mtodos y herramientas,
se tienen que definir nuevos estndares.
5.2. Plan de Prueba.
El plan de prueba es un documento con un abordaje sistemtico para la prueba de sistemas
como hardware o software. Generalmente consiste en un modelado detallado del flujo de
trabajo durante el proceso.
El plan de prueba es uno de los ocho documentos descritos en la IEEE 829, una norma que
especifica la forma y el conjunto de artefactos en la prueba de software. En consonancia con

Pgina 40

ella, la estructura del plan de prueba consiste de una serie de secciones descritas a
continuacin.
El documento comienza con un identificador del documento de plan de prueba, seguido de
una introduccin, que adems de resumir el documento definiendo su propsito y el
propsito del sistema probado, referencia otros documentos asociados del proyecto. La
prxima seccin relaciona los tems de prueba, describiendo todos los elementos siendo
probados; las secciones siguientes describen, aisladamente, funcionalidades a ser probadas
y funcionalidades a no ser probadas. Estipulando as el escapo del documento, esa seccin
es un catlogo de todos los casos de prueba presentes en el documento.
Se sigue con una seccin describiendo la estrategia de la prueba, generalmente para cada
grupo de funcionalidades de las secciones anteriores. Son abordadas cuestiones como
actividades y herramientas usadas en la prueba. Hay tambin una seccin describiendo el
criterio de xito o fallo del caso de prueba, y otra describiendo el criterio de suspensin y
requisitos de reinicio, como por ejemplo actividades que deben ser hechas antes de
reiniciarse la prueba despus de un evento de suspensin.
La prxima seccin relaciona los productos de la prueba, artefactos generados con el
proceso de prueba. Adems del propio plan de prueba, otros documentos generalmente
incluyen especificaciones de modelado, registros de ejecucin y diversos tipos de informe
generados. Sigue una seccin de las tareas de prueba, y una seccin de necesidades fsicas
para la realizacin de la prueba, como por ejemplo hardware y software, y como ellas
pueden afectar la ejecucin de la prueba. Hay una seccin de responsabilidades, los
diferentes papeles desempeados en el proyecto de prueba. Hay tambin una seccin para
sobre recursos humanos y requisitos de entrenamiento del equipo de prueba.
El documento termina con secciones de cronograma, riesgos y contingencias, aprobaciones;
esta, una seccin en que los lderes del proyecto firman, aprobando el documento.
5.2.1. Caso de Prueba.
En la ingeniera del software, los casos de PRUEBA o Test Case son un conjunto de
condiciones o variables bajo las cules el analista determinar si el requisito de una
aplicacin es parcial o completamente satisfactorio.
Se pueden realizar muchos casos de prueba para determinar que un requisito es
completamente satisfactorio. Con el propsito de comprobar que todos los requisitos de
una aplicacin son revisados, debe haber al menos un caso de prueba para cada requisito a
menos que un requisito tenga requisitos secundarios. En ese caso, cada requisito secundario
deber tener por lo menos un caso de prueba. Algunas metodologas como RUP
recomiendan el crear por lo menos dos casos de prueba para cada requisito. Uno de ellos
debe realizar la prueba positiva de los requisitos y el otro debe realizar la prueba negativa.
Si la aplicacin es creada sin requisitos formales, entonces los casos de prueba se escriben
basados en la operacin normal de programas de una clase similar.

Pgina 41

Lo que caracteriza un escrito formal de caso de prueba es que hay una entrada conocida y
una salida esperada, los cuales son formulados antes de que se ejecute la prueba. La
entrada conocida debe probar una precondicin y la salida esperada debe probar una post-
condicin.
Bajo circunstancias especiales, podra haber la necesidad de ejecutar la prueba, producir
resultados, y luego un equipo de expertos evaluara si los resultados se pueden considerar
como "correctos". Esto sucede a menudo en la determinacin del nmero del rendimiento
de productos nuevos. La primera prueba se toma como lnea base para los subsecuentes
ciclos de pruebas/lanzamiento del producto.
Los casos de prueba escritos, incluyen una descripcin de la funcionalidad que se probar, la
cual es tomada ya sea de los requisitos o de los casos de uso, y la preparacin requerida
para asegurarse de que la prueba pueda ser dirigida.
Los casos de prueba escritos se recogen generalmente en una suite de prueba.
Las variaciones de los casos de prueba son comnmente utilizadas en pruebas de
aceptacin. La prueba de aceptacin es realizada por un grupo de usuarios finales o los
clientes del sistema, para asegurarse que el sistema desarrollado cumple sus requisitos. La
prueba de aceptacin de usuario se distingue generalmente por la incorporacin de un
trayecto feliz o casos de prueba positivos.

Estructura de los Casos de Pruebas
I. Introduccin/visin general: Contiene informacin general acerca de los Casos de
Prueba.
Identificador: Es un identificador nico para futuras referencias, por ejemplo,
mientras se describe un defecto encontrado.
Caso de prueba dueo/creador: Es el nombre Del analista o diseador de pruebas,
quien ha desarrollado pruebas o es responsable de su desarrollo.
Versin: La actual definicin del caso de prueba.
Nombre: El caso de prueba debe ser un ttulo entendible por personas, para la fcil
comprensin del propsito del caso de prueba y su campo de aplicacin.
Identificador de requerimientos el cual est incluido por el caso de prueba. Tambin
aqu puede ser un identificador de casos de uso o de especificacin funcional.
Propsito: Contiene una breve descripcin del propsito de la prueba, y la
funcionalidad que chequea.
Dependencias: Indica qu otros subsistemas estn involucrados y en qu grado.
II. Actividades de los Casos de Pruebas.

Pgina 42

Ambiente de prueba/configuracin: Contiene informacin acerca de la
configuracin del hardware o software en el cul se ejecutar el caso de prueba.
Inicializacin: Describe acciones, que deben ser ejecutadas antes de que los casos
de prueba se hayan inicializado. Por ejemplo, debemos abrir algn archivo.
Finalizacin: Describe acciones, que deben ser ejecutadas despus de realizado el
caso de prueba. Por ejemplo si el caso de prueba estropea la base de datos, el
analista debe restaurarla antes de que otro caso de prueba sea ejecutado.
Acciones: Pasos a realizar para completar la prueba.
Descripcin de los datos de entrada
III. Resultados.
Salida esperada: Contiene una descripcin de lo que el analista debera ver tras
haber completado todos los pasos de la prueba.
Salida obtenida: Contiene una breve descripcin de lo que el analista encuentra
despus de que los pasos de prueba se hayan completado.
Resultado: Indica el resultado cualitativo de la ejecucin del caso de prueba, a
menudo con un Correcto/Fallido.
Severidad: Indica el impacto del defecto en el sistema: Grave, Mayor, Normal.
Evidencia: En los casos que aplica, contiene un link al print de pantalla (screenshot)
donde se evidencia la salida obtenida.
Seguimiento: Si un caso de prueba falla, frecuentemente la referencia al defecto
implicado se debe enumerar en esta columna. Contiene el cdigo correlativo del
defecto, a menudo corresponde al cdigo del sistema de tracking de bugs que se
est usando.
Estado: Indica si el caso de prueba est: No iniciado, En curso, o terminado.
6. MTRICAS Y MEDICIONES

Las revisiones son el mtodo ms utilizado para validar la calidad de un proceso o de un
producto. Involucran a un grupo de personas que examinan todo o una parte del proceso
del software.

Las revisiones de la calidad son caras. Si se hace durante la etapa de desarrollo, consumen
tiempo e inevitablemente retrasan la entrega del software. Idealmente, sera
posible acelerar el proceso de revisin utilizando herramientas que procesarn el diseo de
software o el programa e hiciesen valoraciones automticas del software. Estas
valoraciones permitirn comprobar que el software evaluado tiene un umbral de calidad
requerido.

6.1. Medicin del Software

Las mediciones de software se utilizan para recoger datos cuantitativos acerca del

Pgina 43

software y sus procesos.

La medicin del software se refiere a derivar un valor numrico desde algn atributo del
software o del proceso del software. Comparando estos valores entre s y con los
estndares aplicados en la organizacin, es posible sacar conclusiones sobre la calidad del
software o de los procesos para desarrollarlo.

Las mediciones de software pueden realizarse para:

o Hacer predicciones generales acerca del sistema: Haciendo mediciones de las
caractersticas de los componentes del| sistema y reuniendo stas, podremos
derivar una estimacin general de algunos atributos del sistema, como el nmero
de fallos.

o Identificar componentes anmalos: Mediante las mediciones podemos identificar
los componentes que se salgan de lo normal. Por ejemplo podemos identificar los
de complejidades ms altas, los cuales suponemos que tendrn ms errores,
para centrarnos en ellos en el proceso de revisin.

Los pasos claves para el proceso de medicin son:

Seleccionar las medidas a realizar.
Seleccionar los componentes a evaluar.
Medir las caractersticas de los componentes.
Identificar las mediciones anmalas
Analizar los componentes anmalos.

Figura 6.1 Proceso de medicin de un software dentro de un proceso de control de calidad.


Pgina 44

6.2. Mtricas de Software

Una mtrica de software es cualquier tipo de medida relacionada con un sistema, proceso
o documentacin de software. Algunos ejemplos son las medidas que se utilizan para
calcular el tamao de un producto en lneas de cdigo.

Los valores de las mtricas de software recogidas se utilizan para hacer inferencias de la
calidad del producto o proceso.

Sin embargo, pocas compaas utilizan sistemticamente mtricas para valorar la calidad
de software. Una razn de esto es que, en muchas compaas, los procesos de software
estn definidos y controlados, y no son lo suficientemente maduros para utilizar medidas.
Otra razn es que no existen estndares para las mtricas y, por lo tanto, las herramientas
para recogida y anlisis de datos son muy limitadas. Muchas compaas no estarn
dispuestas a introducir mediciones hasta que estn disponibles tales estndares y
herramientas.

Debido a que no existen mtricas de software estandarizadas y aplicables universalmente.,
las organizaciones deben seleccionar mtricas y analizar mediciones basadas en el
conocimiento y circunstancias locales.

Las mtricas pueden ser:
Mtricas de control, generalmente asociadas a los procesos.

Mtricas de prediccin, asociadas a los productos.

Ambas pueden influir en la toma de decisiones de gestin.


Pgina 45

Figura 6.2 Mtricas de prediccin y control.

Ejemplo de las mtricas de control o de procesos son el esfuerzo y tiempo promedio
requeridos para reparar los defectos encontrados.

Ejemplo de mtricas de prediccin o de producto son la complejidad ciclomtica de un
mdulo, la longitud media de los identificadores de un programa, y el nmero de atributos
y operaciones asociadas con los objetos de un diseo.

Las mtricas del producto se refieren a las caractersticas del software mismo, estas
mtricas se dividen en dos clases:

o tricas dinmicas, que son recogidas por las mediciones hechas en un programa
en ejecucin.

o Mtricas estticas, que son recogidas por las mediciones hechas en las
representaciones del sistema como el diseo, el programa o la documentacin.

Estas diferentes mtricas estn relacionadas con diversos atributos de calidad. Las
mtricas dinmicas ayudan a valorar la eficiencia y fiabilidad de un programa. Las
mtricas estticas ayudan a valorar la complejidad, la comprensin y
mantenibilidad de un sistema de software.

Frecuentemente, es imposible de medir los atributos de software directamente. Los
atributos de calidad como la mantenibilidad, la comprensin y la usabilidad son atributos
externos que nos dicen cmo ven el software los desarrolladores y los usuarios. Estos se
ven afectados por diversos factores y no existe un camino simple para medirlos. Ms
bien es necesario medir atributos internos del software y suponer que existe una
relacin entre lo que queremos medir y lo que queremos saber.

Pgina 46

Figura 6.3 Relacin entre los atributos internos y externos del software.

6.3. Panorama de las Mtricas del Producto.

Aunque se proponen una amplia variedad de taxonomas mtricas, el siguiente esquema
atiende las reas ms importantes de las mtricas:

Mtricas para el modelo de anlisis.

Mtricas para el modelo de diseo.

Mtricas para el cdigo fuente.

Mtricas para pruebas

6.3.1. Mtricas para el Modelo de Anlisis.

Estas mtricas examinan el modelo del anlisis con la intencin de predecir el tamao del
sistema resultante. El tamao es, en ocasiones (pero no siempre), un indicador de la
complejidad del diseo y casi siempre resulta un indicador de un mayor esfuerzo de
codificacin, integracin y prueba.

Estas mtricas incluyen:

o Funcionalidad entregada: proporciona una medida indirecta de la
funcionalidad que se empaqueta en el software.


Pgina 47

o Tamao del sistema: mide el tamao general del sistema, definido desde el punto
de vista de la informacin disponible como parte del modelo de anlisis.

o Calidad de la especificacin: proporciona una indicacin de la
especificidad o el grado en que se ha especificado la especificacin de requisitos.

6.3.2. Mtricas para el Modelo de Diseo.

Muchos expertos argumentan que se necesita ms experimentacin antes que emplear las
mediciones de diseo. Sin embargo un diseo sin medicin es inaceptable.

Mtricas arquitectnicas: proporcionan un indicio de la calidad del diseo
arquitectnico.

Mtricas a nivel de componente: miden la complejidad de los
componentes del software y de sus caractersticas que impactan la calidad.
Mtricas de diseo de interfaz: se concentran principalmente en la facilidad
de uso.

Mtricas especializadas en diseo orientado a objetos:
6.3.3. Mtricas para el Cdigo Fuente.

Mtricas de Halstead: controversiales pero fascinantes, estas mtricas
proporcionan medidas nicas de un programa de cmputo.

Mtricas de complejidad: miden la complejidad lgica del cdigo fuente
(Esta se consideran mtricas de diseo a nivel de componentes).

Mtricas de longitud: proporcionan un indicio del tamao del software.

6.3.4. Mtricas para Pruebas.

En general, quienes aplican las pruebas, deben depender de las mtricas de anlisis, diseo
y cdigo como gua para el diseo y ejecucin de los casos de prueba.

Mtricas de cobertura de instrucciones y ramas: lleva al diseo de casos de prueba
que proporcionan cobertura del programa.

Mtricas relacionadas con los defectos: se concentran en encontrar defectos y
no en las propias pruebas.

Efectividad de la prueba: proporcionan un indicio en tiempo real de la
efectividad de las pruebas aplicadas.

Mtricas en el proceso: mtricas relacionadas con el proceso que se
determinan a medida que se aplican las pruebas.

Pgina 48

6.4. Anlisis de las Mediciones.

Uno de los problemas con la recogida de datos cuantitativos en el software y en los
proyectos de software es comprender lo que significan realmente los datos. Es fcil
malinterpretar los datos y hacer inferencias incorrectas. Las mediciones se deben de
analizar cuidadosamente para comprender lo que realmente significan.

Los procesos y productos para medir no estn aislados de su entorno y los cambios en ese
entorno invalidan las comparaciones de los datos. Los datos cuantitativos de las
actividades humanas no siempre deben tomarse como valores de entrada. Las razones
subyacentes al valor medio deben investigarse.


Pgina 49

7. PROCESOS DE V & V EN EL DESARROLLO
DE SOFTWARE

7.1. Actividades de Verificacin

Revisiones tcnicas, walkthroughs e inspecciones de software.

Comprobar que los requerimientos de software son trazables a los requerimientos
del usuario.
Comprobar que los componentes del diseo son trazables a los requerimientos
del software.

Pruebas unitarias.
Pruebas de integracin
Pruebas del sistema.
Pruebas de aceptacin
Auditoria.

Figura 7.1 .Actividades de verificacin


Pgina 50

7.2. V&V Prevencin y eliminacin de fallos

Figura 7.2 Prevencin y eliminacin de fallos

Fallo: defecto (ya sea hardware o software) dentro de un sistema o de usuario o
procedimiento.

Error: la desviacin detectada a partir de la especificacin de requisitos.

Fracaso: incapacidad software de componentes para realizar una funcin determinada (ya
sea prdida de funcin o mal funcionamiento)

Causas de fallos:

Requisitos SW son incorrectos, incompletos o ambiguos, por ejemplo, no
controlada estados o condiciones ambientales no controladas, no conformidad en
el software o deficiencias en el cdigo (que provocan fallos de software)

Requisitos de SW no se han aplicado, validado y verificado adecuadamente.

SW no se ha probado suficientemente o se ha probado inadecuadamente.

Defectos de software:

Software se utiliza incorrectamente.

Mal diseo o implementacin.

Eventos raros puede llevar a estados no controlados.

Procesos gestin de fallos.


Pgina 51

Figura 7.3 Proceso de gestin de fallos.

Tcnicas de prevencin de fallos se puede utilizar en cualquier ingeniera o actividades de
desarrollo para evitar fallas.

Tcnicas de tolerancia a fallos son mecanismos directos que se implementado en
el diseo y el cdigo con el fin de tolerar fallos.

Para verificar que las tcnicas de tolerancia estn siendo utilizados como diseado
para, fallas tcnicas de remocin se necesitan: desviacin detectada especificacin
de requisitos


Pgina 52

8. BIBLIOGRAFA

http://www.eqsoft.net/presentas/modelos_de_calidad_y_software_libre.pdf
http://iidia.com.ar/rgm/tesistas/scalone-tesis-maestria-ingenieria-en-calidad.pdf
http://www.allsoft.mx/recursos/ElModeloCMMI.pdf
http://www.qualitrain.com.mx/Aseguramiento-de-la-Calidad-de-Software.html
http://pfsanchez.blogspot.com/2006/08/aseguramiento-de-la-calidad-del.html
http://sftquality.wordpress.com/tecnicas-de-aseguramiento-de-calidad/
http://es.scribd.com/doc/155230997/clase05acalidadverificacionvalidacion-
130222075332-phpapp02

Fundamentos de Pruebas de Software

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Fundamentos de Pruebas de Software

Uploaded by

Copyright:

Available Formats

28-4-2014

You might also like