2015

FACULTAD DE INGENIERIA URBANISMO Y ARQUITECTURA.

ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS

GESTION DE PRUEBAS DE
SOFWARE

ALUMNO:
FERNANDEZ ROMAN, ISMAEL.
DOCENTE:
ING. JHON DENNYS FUENTES ADRIANZEN.

USS 2015
 ndice de Contenido
GESTION DE PROCESOS DE PRUEBA. ............................................................................3
ORGANIZACIN DE PRUEBAS............................................................................................3
La gestin del proceso significa. ..................................................................................................4
Revisemos los niveles de independencia aqu: ...........................................................................4
Los lderes de pruebas llevan a cabo las siguientes tareas: ........................................................4
Planificacin y Estimacin de Pruebas ........................................................................................5
Las secciones del plan de pruebas IEEE 829 incluyen lo siguiente: .............................................5
Hay dos mtodos generales para la estimacin (incluyendo la estimacin de las pruebas). ....6
Hay factores de los procesos: ......................................................................................................6
Hay factores materiales:..............................................................................................................6
Hay factores personales: .............................................................................................................7
Hay factores que hacen demorar: ...............................................................................................7
Monitoreo y Control del Progreso de las Pruebas ......................................................................7
Control de pruebas. .....................................................................................................................7
Hay una serie de mtricas de las pruebas bastante comunes. ...................................................7
stas incluyen lo siguiente: .........................................................................................................7
Riesgo y proceso de Pruebas ....................................................................................................13
Por cada riesgo del proyecto o de hecho cualquier riesgo tiene cuatro opciones: .................13
Una opcin es la mitigacin. .....................................................................................................13
Otra opcin es la contingencia ..................................................................................................13
Otra opcin es la transferencia. ................................................................................................14
Cules son los riesgos de proyecto tpicos para las pruebas?.................................................14
Cules pasos de mitigacin y/o contingencia podemos tomar para controlarlos? ................14
Algunos riesgos surgen de factores organizacionales. ..............................................................15
Estos incluyen lo siguiente: .......................................................................................................15
Algunos riesgos surgen de cuestiones de los proveedores. Estos incluyen lo siguiente:.........15
Gestin de Defectos o Incidencias ............................................................................................15
RESUMEN:..................................................................................................................................19
Referencias Bibiograficas. .........................................................................................................20
Referencias Web........................................................................................................................20

P g i n a 1 | 20
 ndice de Contenido de Imgenes
Imagen 1 Organigrama del equipo de pruebas de Omninet ........................................................5

Imagen 2Progreso de las pruebas ................................................................................................9

Imagen 3 Ejecucin de las pruebas de integracion.......................................................................9

Imagen 4 Cumplimiento de los casos de pruebas planificados ..................................................10

Imagen 5 Defectos de Riesgos de Calidad y Cobertura de Pruebas ............................................12

Imagen 6 Ciclo de Vida o Flujo de Trabajo del Informe de Defecto ............................................17

P g i n a 2 | 20
GESTION DE PROCESOS DE PRUEBA.

ORGANIZACIN DE PRUEBAS

Definicin en el glosario del trmino pruebas es: El proceso que consiste en todas
las actividades del ciclo de vida, ambas estticas y dinmicas, preocupadas por la
planificacin, la preparacin y la evaluacin de los productos de software y los
productos del trabajo relacionados, para determinar que ellos satisfagan los
requisitos especificados, para demostrar que ellos estn aptos para el propsito y
para detectar defectos.

Esto es un gran trabajo. De hecho, en la mayora de las organizaciones y los

proyectos, ese trabajo necesita ser distribuido en parte al desarrollo por lo menos,
las pruebas de unidad y las revisiones del cdigo.

A menudo, un equipo de pruebas independiente se enfoca en un solo nivel de

pruebas o dos niveles relacionados lgicamente.

Las pruebas de sistema y las pruebas de integracin de sistemas.

sta es una misin alcanzable, con la condicin de que cada uno comprenda que no
podemos ser 100% efectivos en ninguna de las siguientes 3actividades los requisitos
de las pruebas, la comprobacin de la aptitud para el propsito o los defectos
detectados.

La imposibilidad de las pruebas exhaustivas limita nuestra efectividad a menos del

100% en cualquiera de estas reas y las restricciones del proyecto relacionadas con
el tiempo y dinero la limitarn an ms.

Tradicionalmente, el control de calidad en la industria manufacturera destin los

procesos para detectar la inconformidad con los requisitos especificados con
precisin, as como el ancho de las cabezas de los tornillos o la eflectividad de una
superficie pulida.

Eso funciona bien para la parte del hardware de un proyecto de desarrollo de

sistemas.

Por otro lado, la satisfaccin con el software puede depender recuentemente de un

nmero de intangibles que estn ms all de nuestra capacidad de probar,
incluyendo atributos de la adquisicin, la entrega y los procesos del soporte.

P g i n a 3 | 20
La gestin del proceso significa.

en este caso, un trabajo continuo para alinear los servicios de las pruebas que usted
provee con las necesidades de la organizacin, el proyecto, y el producto, dentro de
las restricciones que usted debe soportar, junto con el concepto ms tradicional de
gestin en cuanto a definir y llevar a cabo un plan para el conjunto de actividades.

Revisemos los niveles de independencia aqu:

1. En el nivel ms bajo de independencia, las pruebas son realizadas por el autor

del tem de prueba.

2. Las pruebas son realizadas por otra persona o gente dentro del mismo
equipo.

3. Las pruebas son realizadas por una persona o gente de un equipo diferente o
por especialistas de pruebas.

4. En el nivel ms alto de independencia, las pruebas son realizadas por una

persona o gente de una organizacin diferente o compaa.

En otras palabras, las pruebas son como un filtro, capturando un cierto porcentaje
del material no deseado que fluye a travs de stas. En importantes circunstancias
como la purificacin del agua, los sistemas de agua municipales utilizan mltiples
niveles de filtracin.

Entonces, para las aplicaciones complejas y crticas, necesitamos mltiples niveles

de pruebas. Adems necesitamos alguno de esos filtros que sean bastante efectivos
en detectar defectos, si es que queremos tener un nmero muy bajo de defectos,
que fluyen a travs del proceso y hacia los usuarios y clientes.

Las pruebas independientes tienden a ser ms efectivas que las auto pruebas en
encontrar defectos.

Los lderes de pruebas llevan a cabo las siguientes tareas:

Crear las estrategias y los planes de pruebas.

Escribir o revisar las polticas de pruebas.
Consultar acerca de las pruebas para las otras actividades del proyecto, as
como las pruebas de unidad.
Estimar el tiempo, el dinero y los recursos requeridos para las pruebas.
P g i n a 4 | 20
 Adquirir los recursos de las pruebas.
Liderar la especificacin, la preparacin, la implementacin y la ejecucin de
las pruebas.
Monitorear y controlar la ejecucin de las pruebas.
Adaptar el plan de pruebas durante la ejecucin de las pruebas en base a los
esultados de las pruebas, as como el ajuste del nivel de los riesgos en base a
los defectos realmente observados.

Imagen 1 Organigrama del equipo de pruebas de Omninet

Planificacin y Estimacin de Pruebas

Un plan de pruebas es un plan de proyecto para las actividades de las pruebas, que
comienza con la planificacin misma y yendo todo el camino hasta las actividades
del cierre de las pruebas.

En primer lugar, debera definir y seleccionar el mtodo y la estrategia de las pruebas

y darse cuenta de los niveles de pruebas que tienen que ser realizados.

Tambin tendr que integrar, coordinar y alinear las pruebas con el ciclo de vida del
desarrollo del software.

Como con cualquier plan, necesita darse cuenta del quin, el qu, el cundo y el
cmo de las actividades de las pruebas.

Las secciones del plan de pruebas IEEE 829 incluyen lo siguiente:

Identificador del plan de pruebas.

Introduccin.
tems de prueba (es decir, lo que es entregado para las pruebas).
Caractersticas que deben ser probadas.
Caractersticas que no deben ser probadas.
Mtodo (las estrategias, la organizacin y la extensin de las pruebas).
P g i n a 5 | 20
 Criterios paso/falla del tem (es ms raro, para nosotros, porque no
pensamos que los tems pasan o fallan, pero ms bien que las caractersticas
o los atributos no pasan o fallan).

Planificacin.
Asignacin de personal (si aplicable).
Adquisicin y configuracin del entorno de las pruebas.
Desarrollo de las pruebas.
Ejecucin de las pruebas.

Hay dos mtodos generales para la estimacin (incluyendo la estimacin de las

pruebas).

Primero, podemos estimar las tareas individuales por medio del trabajo con el dueo
de las tareas o con los expertos. sta es realizada de abajo hacia arriba y es lo que
hacemos cuando construimos una estructura detallada del trabajo.

Segundo, podemos estimar el esfuerzo de las pruebas basados en las mtricas de los
proyectos anteriores o similares o basados en los valores tpicos.
Si aplicamos esto en un nivel ms alto, como con una regla heurstica para la
proporcin de probador-adesarrollador, entonces estamos realizando una
estimacin descendente.

Si utilizamos los parmetros para estimar las actividades individuales como el

hallazgo de los defectos, la correccin de los defectos, el desarrollo de los casos de
prueba, etc., entonces estamos realizando una estimacin ascendente.

Hay factores de los procesos:

Las pruebas dominantes a travs del ciclo de vida, la gestin del control de los
cambios, el desarrollo en general y la madurez del proceso de pruebas, el ciclo de
vida elegido, la alineacin del desarrollo y los procesos de pruebas, los resultados
de las fases anteriores de las pruebas, los niveles estimados y reales, y el tiempo
necesario para corregir esos defectos.

Hay factores materiales:

la disponibilidad de las herramientas, la calidad del sistema de pruebas, la

disponibilidad de los entornos de depuracin y pruebas separados, la disponibilidad
de una buena documentacin del proyecto, y la similitud de este proyecto con
proyectos anteriores (permitiendo la reutilizacin).

P g i n a 6 | 20
Hay factores personales:

las habilidades del equipo, las expectativas de los participantes, los interesados del
negocio y los jefes, el grado de apoyo de los que no estn participando,
especialmente los patrocinadores, y las relaciones dentro y fuera del proyecto.

Hay factores que hacen demorar:

Un alto nivel de complejidad, muchos interesados del negocio o en contra de los

interesados de los negocios, la demasiada novedad, la distribucin geogrfica y la
zona horaria, la necesidad para producir documentacin

Monitoreo y Control del Progreso de las Pruebas

Control de pruebas.

Una tarea de la gestin de pruebas que se encarga del desarrollo y la

Aplicacin de un conjunto de acciones correctivas para encaminar un proyecto de
pruebas cuando el monitoreo muestra una desviacin de lo que fue planificado.

Hay una serie de mtricas de las pruebas bastante comunes.

stas incluyen lo siguiente:

El porcentaje de realizacin de la preparacin de los casos de prueba (el
porcentaje de los casos de prueba preparados y planificados).

El porcentaje de realizacin de la preparacin del entorno de pruebas (ste es

potencialmente engaoso, si cuenta el nmero de productos instalados o que
algunos productos son ms difciles que otros).

El cmputo y los porcentajes de la ejecucin de los casos de prueba.

Por ejemplo, el nmero de casos de prueba ejecutados/no ejecutados y el nmero

de casos de prueba pasados/fallados.

Nuevamente, esto puede ser engaoso cuando estos nmeros son utilizados como
una mtrica sustituta para la calidad, porque una o dos pruebas pueden fallar con
errores crticos y pueden hacer que el producto no pueda ser enviado.

P g i n a 7 | 20
Varias clases de diagramas y mtricas de defectos, as como la densidad de los
defectos, los defectos encontrados y corregidos y los resultados de la repeticin de
pruebas.

El alcance de la cobertura de las bases de pruebas, as como los requisitos, los riesgos
o el cdigo, por medio de las pruebas. Algunas veces esto puede incluir los resultados
de paso/falla.

Otro es el nivel de confianza, usualmente un nmero subjetivo, que los

probadores tienen en el producto. Usted est contando con su credibilidad si
elige utilizar ste.

Las fechas de los hitos claves de pruebas, incluyendo alguno en el pasado que podra
o no podra haber sido encontrado a tiempo.

Finalmente, los costos de las pruebas, incluyendo el costo del hallazgo del prximo
defecto o la ejecucin de la prxima prueba comparada con el beneficio.

Finalmente, los costos de las pruebas, incluyendo el costo del hallazgo del prximo
defecto o la ejecucin de la prxima prueba comparada con el beneficio. Recuerde
que esto vincula a los criterios de salida que mencionamos antes en una seccin
anterior.

Estas mtricas pueden ser utilizadas para los informes de las pruebas. El informe de
las pruebas puede ser acerca del resumen o el anlisis de los resultados de las
pruebas.

Los anlisis de las mtricas pueden ocurrir en los eventos clave as como la medicin
del cumplimiento de los criterios de salida para una reunin propuesta acerca de la
salida de las pruebas.

Tambin podemos analizar varias mtricas para realizar recomendaciones o guiar los
proyectos.

Esto puede incluir la consideracin de las mtricas como el nmero estimado de los
defectos restantes, los costos y los beneficios de ms pruebas, el nivel residual de
los riesgos o el nivel subjetivo de confianza.
Para evitar la gestin de nuestras pruebas completamente por medio de la intuicin,
nos gusta utilizar mtricas.

Estas mtricas pueden ayudarnos a evaluar si los objetivos de las pruebas fueron
adecuados para el nivel de pruebas que estamos abordando.

Esto puede tambin ayudarnos a evaluar la adecuacin de las estrategias y

actividades de pruebas.

P g i n a 8 | 20
Esto puede tambin ayudarnos a medir la efectividad y la eficiencia de nuestras
pruebas, basadas en nuestros objetivos.

Imagen 2Progreso de las pruebas

Imagen 3 Ejecucin de las pruebas de integracion

P g i n a 9 | 20
Este diagrama tiene dos conjuntos de las pruebas principales, ambos trazados en
contra del eje nico del lado izquierdo.

El primer conjunto de los datos son las horas planificadas de la ejecucin de las
pruebas por da, representadas por las lneas discontinuas.

Tome en cuenta que las horas cambian primero hacia arriba, luego hacia abajo,
durante el proyecto, indicando una intensidad divergente y planificada de las
pruebas.

El segundo conjunto de datos son las horas reales de la ejecucin de las pruebas
logradas por fecha, las cuales estn representadas por las cajitas, donde pensamos
que el progreso del da de la semana es normal.

En otras palabras, las cajitas pueden saltar alrededor aleatoriamente arriba y abajo
de las lneas discontinuas, con la condicin de que ellas permanezcan dentro de las
lneas punteadas. Para aquellas lneas fuera de las lneas punteadas, hemos
proporcionado una explicacin del por qu.

Imagen 4 Cumplimiento de los casos de pruebas planificados

P g i n a 10 | 20
Otro diagrama tpico muestra la tendencia de la realizacin de los casos de prueba
en el tiempo.

Este diagrama tiene cuatro conjuntos de datos principales, todos trazados contra el
eje izquierdo.

El primer conjunto de datos es el nmero de las pruebas planificadas que deben ser
completadas en un paso dado de las pruebas, mostradas con lneas parecidas a
rayos.

Esta seccin plana en la mitad de la lnea parecida a un rayo ocurre debido a los fines
de semana, cuando no se han programado pruebas. El restablecimiento de la
realizacin de las pruebas en otras palabras, por qu cada lnea parecida a un rayo
comienza cerca del cero es debido al hecho de que estamos ejecutando una
secuencia de ejecuciones de pruebas
similares, utilizando la repeticin de pruebas para la gestin de los riesgos de
regresin.

El segundo conjunto de datos es el nmero real de las pruebas completadas para la

ejecucin en el final de cada da, representado con las cajitas.
El tercer conjunto de datos es el nmero de aquellas pruebas completadas las cuales
han pasado en el final del da, representado con los smbolos ms.

El cuarto conjunto de datos es el nmero de aquellas pruebas completadas las cuales

han fallado en el final del da, representadas con los smbolos menos.

Nuevamente, observe que hemos utilizado las notaciones para indicar los aspectos
interesantes de los conjuntos de datos, especialmente por qu razn ciertas
ejecuciones de las pruebas son ms cortas que otras.

P g i n a 11 | 20
Imagen 5 Defectos de Riesgos de Calidad y Cobertura de Pruebas

Otro diagrama, no tan tpico pero til, analiza la relacin entre las categoras clave
de los riesgos de calidad (presumiblemente nuestra base de pruebas), el grado de la
cobertura de los riesgos que hemos alcanzado para cada categora y el nmero de
los defectos que hemos encontrado relacionados a cada categora de los riesgos.

Abajo, tenemos etiquetas que corresponden a cada categora principal de riesgo.

Tenemos la trazabilidad de nuestros casos de prueba hacia atrs a los riesgos de los
cuales se derivaron .

Utilizamos esa trazabilidad, en el nivel no detallado de la categora de riesgo, para

crear este diagrama.

Tambin necesitaremos la clasificacin de nuestros informes de los defectos en

cuanto a los riesgos con los cuales se relacionan, y tambin utilizaremos esa
trazabilidad para crear este diagrama.

P g i n a 12 | 20
Riesgo y proceso de Pruebas

En la planificacin de las pruebas, dijimos que el esfuerzo de las pruebas es un

subproyecto del proyecto general. Por lo tanto, las pruebas estn
sujetas a riesgos, especficamente los riesgos de proyecto.

Porque el riesgo es la posibilidad de un resultado negativo, los riesgos de proyecto

relacionados con las pruebas incluyen eventualidades como versiones de pruebas
atrasadas, problemas del entorno de pruebas, y as sucesivamente.

Recuerde que la plantilla del plan de pruebas IEEE 829 nos pide identificar y evaluar
no slo los riesgos del producto, sino que tambin los riesgos del proyecto,
especficamente aquellos riesgos del proyecto que pondran en riesgo nuestra
aptitud de realizar el subproyecto como planificado.

Por cada riesgo del proyecto o de hecho cualquier riesgo tiene cuatro opciones:

Una opcin es la mitigacin.

Las acciones de mitigacin son pasos preventivos que reducen la probabilidad o el

impacto de un riesgo antes de que llegue a ser un evento o
resultado real no deseado.

Otra opcin es la contingencia

Las acciones de contingencia son pasos planificados con anticipacin o reactivos que
usted tomar para reducir el impacto de este evento o resultado, si el riesgo se
convierte en un evento o resultado real no deseado.

Note que las acciones de contingencia no pueden reducir la probabilidad, porque

asumimos que el evento o resultado no deseado ha ocurrido ya.

P g i n a 13 | 20
Otra opcin es la transferencia.

La transferencia es bsicamente una accin antes del evento en alguna otra parte
para aceptar las consecuencias si el evento o el resultado no deseado en realidad
ocurren. La clave de la transferencia es que la parte que acepta tiene que aceptar
ambas consecuencias antes que el evento ocurra y si ste realmente ocurre.

Una opcin final es de aceptar o ignorar el riesgo. Aqu no hacemos nada acerca del
evento o resultado no deseado de antemano, lo cual es lo mejor si tanto la
probabilidad como el impacto son bajos!
Una forma de transferencia, la opcin de gestin de los riesgos ms tpica en la vida
diaria, es la compra de seguros. Sin embargo, en la mayora de los proyectos de
software o istemas, esta opcin no est disponible usualmente.

Cules son los riesgos de proyecto tpicos para las pruebas?

Cules pasos de mitigacin y/o contingencia podemos tomar para controlarlos?

Algunos riesgos se relacionan con los problemas de logstica o calidad del producto
que bloquean las pruebas. Aqu podemos usar una cuidadosa planificacin, una
buena clasificacin de los defectos y un diseo de pruebas robusto.

Otros riesgos relacionados con los entregables de pruebas que no se instalarn.

Aqu podemos usar pruebas de humo de las compilaciones, compilaciones

nocturnas y un proceso de desinstalacin bien definido.

Otros riesgos se relacionan con el cambio excesivo que invalida los resultados o
necesita actualizaciones de las pruebas. Aqu podemos utilizar buenos procesos de
control de cambios, robustos diseos de pruebas, corta documentacin de las
pruebas y escalamientos a la gerencia si las cosas se ponen demasiado difciles.

Otros riesgos se relacionan al entorno o los entornos de pruebas insuficientes o poco

realistas.

Aqu podemos explicarle a la gerencia, y, para los entornos complejos de las pruebas,
algunas veces podemos tercerizar las pruebas sensibles al entorno como las pruebas
de rendimiento.

Otros riesgos se relacionan con el soporte poco fiable del entorno de pruebas.

Aqu podemos definir buenos procesos de escalamiento del problema de tal forma
que esos problemas no empeoren, o, mejor todava, asegurar que tengamos las
habilidades de la administracin de los sistemas en el equipo de pruebas.
P g i n a 14 | 20
Otros riesgos se relacionan con los vacos en la cobertura de las pruebas.

Algunos riesgos surgen de factores organizacionales.

Estos incluyen lo siguiente:

Habilidades y reduccin de personal.

Cuestiones personales y de capacitacin.
Problemas de comunicacin.
Falta de seguimiento a los resultados de las pruebas, incluyendo las fallas
para utilizar esos resultados para la mejora del proceso.
Una actitud inapropiada hacia las pruebas o hacia las expectativas de las
pruebas, si por medio de los probadores o por otros en el proyecto.
Una organizacin compleja, tal como las organizaciones distribuidas o
externalizadas.

Algunos riesgos surgen de cuestiones de los proveedores. Estos incluyen lo

siguiente:

1. Falla de un tercero, incluyendo un vendedor de herramientas de pruebas.

2. Cuestiones contractuales.

An otros riesgos surgen de cuestiones tcnicas. Estos incluyen lo siguiente:

Problemas en la definicin de los requisitos correctos.

Requisitos inalcanzables (los cuales pueden conducir a pruebas bloqueadas
o no ejecutables).
Falta de calidad del diseo, el cdigo, las pruebas y los datos de prueba.
Un sistema altamente complejo.

Gestin de Defectos o Incidencias

Los informes de incidencias o defectos tienen a menudo las siguientes metas:

Proporcionar informacin detallada acerca de la incidencia o el defecto para

quines lo necesitan.

Ser parte de los datos agregados de los resultados de las pruebas para el
P g i n a 15 | 20
 anlisis, el control y el informe.

Conducir a la mejora del proceso de desarrollo y pruebas.

Sobre todo, la ejecucin de una prueba es una tarea que necesita que su cerebro
est activo en todos los momentos. Las pruebas poco rigurosas resultan en
informes de defectos poco rigurosos.

No todas las fallas son reproducibles, no todas las fallas no reproducibles no son
importantes. De este modo, debemos comprobar siempre la reproducibilidad de la
falla como parte de la escritura de un informe de defecto.

Pensamos que tratando de reproducir la falla tres veces es una buena regla
heurstica.

La comprobacin de la reproducibilidad le ayudar a documentar una secuencia bien

definida de acciones que reproducirn la falla.

Porque las fallas no reproducibles pueden ser importantes, asegure de informar

acerca de las fallas intermitentes, difciles de repetir.

Los problemas de rendimiento y de fiabilidad son notoriamente difciles de

reproducir, pero esas fallas pueden causar verdaderos problemas para los usuarios
y clientes.

Habiendo intentado de reproducir la falla, ahora usted puede anotar la tasa de la

incidencia de fallas en su informe.

los informes de incidencia describen cualquier comportamiento cuestionable.

Los informes de defectos describen el comportamiento debido a los defectos, los

cuales son fallas.

Un informe de defecto a diferencia de un informe de incidencia no debera describir

pruebas o datos de prueba incorrectos, errores de los probadores, problemas del
entorno de pruebas, y similares.

P g i n a 16 | 20
 Imagen 6 Ciclo de Vida o Flujo de Trabajo del Informe de Defecto

Una
vez que el informe de incidencia es reportado, ste va generalmente a travs de
alguna secuencia de pasos hasta su resolucin.

Esta figura muestra un ejemplo de un posible diagrama de estados para la gestin

de incidencias desde su descubrimiento hasta su resolucin.

En cualquier sistema de gestin de informes de defectos el cul debera ser

construido en la herramienta de informes de defectos que usted utiliza los informes
de defectos se mueven a travs de una serie de estados (en el ciclo de vida o flujo de
trabajo) hasta su resolucin.

En cada estado no terminal, un jefe o el comit de clasificacin de defectos especifica

un responsable quien es el que mueve el defecto al prximo estado.
Los sistemas de seguimiento de defectos pueden y deberan implementar y
automatizar estos flujos de trabajo, pero el equipo de trabajo y el soporte de la
gestin realizan el trabajo del flujo de trabajo.

Bueno, antes que dejemos esta cuestin de los informes individuales de incidencias,
Qu otra informacin debera ser incluida en un informe de incidencia?

La configuracin del software o sistema.

Si es posible, la fase de la introduccin, la deteccin y la eliminacin del defecto.

sta es una buena idea, pero desafortunadamente realizada no frecuentemente.

Los campos de la deteccin y de la eliminacin son fcilmente llenados, pero el

campo de la introduccin es algunas veces difcil de determinar con exactitud,
particularmente cuando surgen cuestiones de presin de plazos y culpabilidad.

P g i n a 17 | 20
La urgencia o prioridad de corregir. Ahora, esto es obviamente un tema de opinin y
las opiniones se diferenciarn, pero intentando de alcanzar un consenso en esto,
ayuda a tomar decisiones inteligentes de lo que hay que corregir.

Las conclusiones y recomendaciones recopiladas durante el ciclo de vida, tanto en

cuanto a lo que hay que hacer inmediatamente con el defecto como los cambios a
largo plazo que posiblemente queremos realizar para evitar la introduccin de esos
defectos en el futuro.

P g i n a 18 | 20
RESUMEN:

Son las investigaciones empricas y tcnicas cuyo objetivo es proporcionar

informacin objetiva e independiente sobre la calidad del producto a la parte
interesada o stakeholder. Es una actividad ms en el proceso de control de calidad.
El objetivo de las pruebas es presentar informacin sobre la calidad del producto a
las personas responsables de ste. Las pruebas de calidad presentan los siguientes
objetivos: encontrar defectos o bugs, aumentar la confianza en el nivel de calidad,
facilitar informacin para la toma de decisiones, evitar la aparicin de defectos.

Son bsicamente un conjunto de actividades dentro del desarrollo de software.

Dependiendo del tipo de pruebas, estas actividades podrn ser implementadas en
cualquier momento de dicho proceso de desarrollo

P g i n a 19 | 20
Referencias Bibiograficas.

How are Function Points Useful, www.softwaremetrics.com/download

Estimating and Tracking Software Projects, www.kallista.com/TechPapers/

Track/TrackingProjects.html.

.A Managers Guide to Software Engineering, Roger S. Pressman, McGraw-Hill, Inc.

1993. The handbook of MIS application software testing, methods, techniques, and
tools for assuring quality through testing, Daniel J. Mosley. Yourdon Press, 1993

Object Oriented Software Engineering, Ivar Jacobson,. Addison - Wesley 1992.

Software Management, Donald J. Reifer. IEEE Computer Society Press, 1993.

Managing The Software Process, Watts S. Humphrey. Addison - Wesley, 1989

Standards, Guidelines, and Examples on System and Software Requirements

Engineering, Merlin Dorfman, Ricahard H. Thayer. IEEE Computer Society Press, 1990.

Rapid Development. McConnell, Steve. Ed. Microsoft Press, U.S.A, 1996.

Referencias Web
Atributos externos del software

http://www.sc.ehu.es/jiwdocoj/mmis/externas.htm

Complejidad de software

http://www.geocities.com/txmetsb/compleji.htm

Estimacin de Costos

www.itcdguzman.edu.mx/ingsoft/estimac.htm

Planificacin de Proyectos de Software

http://www.getec.etsit.upm.es/articulos/gproyectos/art4.htm

Estimating Software Projects ,Bill Meacham

http://ourworld.compuserve.com/homepages/bmeacham/ProfWriting.htm

Rediseo del desarrollo de Software

http://www.obarros.cl/diredecambio.html

P g i n a 20 | 20