Ingeniera de Software

Desarrollar aplicaciones el objetivo principal

TEMARIO
Gestin de calidad
Conceptos de calidad
Tcnicas de revisin
Garanta de calidad del software
Estrategias de pruebas de software
Prueba de aplicaciones convencionales
Prueba de aplicaciones orientada a objetos
Prueba de aplicaciones web
Modelos formales y verificacin
Gestin de configuracin de software
Mtricas de productos

Exmenes(3) 50%
Proyecto 30%
Tareas 20%

Las tareas y proyectos debern ser entregados en el da y hora acordadas.

Las tareas deben ser enviadas al correo: fcorrea@laviria.org
El asunto del correo deber ser el siguiente SoftEng_ApellidoNombreYYYYMMDDx
Donde YYYY = ao, MM = mes, DD = da, x = (a, b, c.) se usa slo si se envan ms de un correo el
mismo da.
Los reportes debern ser enviados como archivo PDF, adjuntos al correo.

El PDF deber ser nombrado como:

SoftEng_ApellidoNombreYYYYMMDDx.pdf
El formato ser discutido en clase.
Si la tarea se incluye cdigo, estos debern ser envidado en un archivo comprimido ZIP o RAR,
nombrado como:
SoftEng_ApellidoNombreYYYYMMDDx.zip
SoftEng_ApellidoNombreYYYYMMDDx.rar
El archivo comprimido deber contener nicamente los archivos del cdigo y otros archivos
relevantes.

Formato para reportes extensos

Los reportes de tareas y proyectos debern seguir el siguiente formato:
Portada
Introduccin
Metodologa
Resultados
 Conclusiones
Bibliografa

Portada deber contener:

Datos de la institucin
Nombre de la materia
Nombre del alumno (o alumnos si es por equipo)
Nmero consecutivo de la tarea o proyecto
Fecha acordada para la entrega

La introduccin deber contener:

En esta seccin se va a describir el reporte.
Problema a tratar.
Descripcin general de la solucin propuesta.
Justificaciones de diseo.
Es decir, se va a describir el trabajo en el reporte, de forma general y sin detalles.

Metodologa:
Esta seccin describe los aspectos tcnicos de lo que se hizo.
Contiene frmulas, algoritmos, herramientas, materiales, etc.

Resultados
Se presentan los resultados obtenidos.
En ocasiones se describe en el protocolo de pruebas
Se discute el significado de estos resultados.

Conclusiones
En esta seccin se reportan los descubrimientos
Es una seccin breve, de un prrafo-
Su objetivo es informar lo que el alumno aprendi al realizar la tarea.

Bibliografa
Lista de fuentes consultadas para realizar el trabajo
Autor, ttulo, fuente, ao.

La bibliografa del curso:

Pressman, R. & Maxim, B. (2014) Software Engineering: A Practicioners Approach (8 th Edition)

Pgina del curso: sites.google.com/site/fcorreasofteng/

Para la IEEE la ingeniera de software es:

La aplicacin de un enfoque disciplinado, cuantificable, sistemtico, para el desarrollo, operacin y
mantenimiento de software; es decir, la aplicacin de la ingeniera de software.
El estudio de los enfoques en el paso anterior.

Procesos de desarrollo de software

Prototipado
Cascada
Espiral
gil

Modelado de software
Requerimientos
Conceptos de diseo
Interfaces
Son conceptos, principios y tcnicas aplicados a la gestin de calidad del software.

Se responder a las siguientes preguntas:

Gestin de calidad
Cules son las caractersticas generales del software de alta calidad?
Cmo se revisa la calidad y cmo se llevan a cabo las revisiones?
Qu es la garanta de calidad del software?
Qu estrategias son aplicables para realizar pruebas de software?
Qu mtodos se usan para disear casos de prueba efectivos?
Existen mtodos que aseguren que el software es correcto?
Cmo se pueden manejar y controlar los cambios que ocurren mientras se construye el software?
Qu medidas y mtricas pueden ser usadas para valorar la calidad del diseo, el cdigos y las
pruebas de software?

Calidad de Software
Obtener software de calidad es una meta importante
La definicin de lo que es calidad es un concepto un poco ms elusivo
A travs del tiempo se ah determinado que el software malo o de baja calidad presenta alrededor
de 3 o 4 defectos por cada 1000 lneas de cdigo
Un programador genera, en promedio, un error por cada 10 lneas de cdigo.
Esto ocasiona que el 45% del tiempo que toma desarrollar un producto de software se emplee en
la identificacin y correccin de errores
Claro que esto incrementa los costos de desarrollo
Otros problemas:
-Inconformidad del cliente por la baja calidad
-inconformidad del programador por exigencias del cliente
-prdida de clientes

La calidad del software se puede definir como:

-Un proceso de software efectivo, aplicado de forma tal que resulte en un producto til,
que proporcione un valor medible para quien lo producen y para quienes lo usan.
Proceso de Software efectivo:
- Diseo de una infraestructura que de soporte al desarrollo de software de calidad.
- Incluye gestin y chequeos que evitan el caos.
- Las prcticas de ingeniera de software permiten analizar el problema y disear soluciones
Solidas

Producto til:
-Proporciona el contenido, funciones y caractersticas que deseaba el usuario final.
-Lo hace de manera confiable, libre de errores.
-Satisface los requerimientos del cliente.
-Tambin, satisface requerimientos implcitos, esperados de un software de calidad.

Valor medible para quienes lo producen y para quienes lo usan:

-El software de calidad beneficia tanto a la firma de software y a la comunidad de usuarios
finales
-La firma de software obtiene valor agregado, ya que el software de calidad requiere menos
mantenimiento y menos soporte tcnico.
-Los programadores emplean ms tiempo en el desarrollo de productos que en
correcciones.
-El usuario final obtiene un software que es til y agiliza su trabajo.

Dimensiones de Calidad
David Garvn sugiere que la calidad deber ser considerada desde un punto de vista de mltiples
dimensiones:
-Calidad de desempeo: Se refiere a si el producto presenta el contenido, funciones y
caractersticas especificadas en los requerimientos, proporcionando valor agregado
-Calidad de caractersticas: Caractersticas que sorprendan y agradan al usuario cuando
lo usa por primera vez.
-Confiabilidad: Si el software proporciona un servicio sin errores
-Conformidad: Si el software se apega a estndares relevantes.
-Durabilidad: Si el software puede ser mantenido o corregido sin la generacin inadvertida
de efectos secundarios, como la degradacin del software en el tiempo.
-Utilidad: Si el software puede ser mantenido o corregido en un periodo de tiempo
aceptable.
-Esttica: Elegancia, presentacin, flujo aunque es algo subjetivo.
-Percepcin: Lo que piensa el usuario del fabricante de software puede afectar su juicio
sobre el mismo.

Las 8 Dimensiones de Calidad de Garvn proporciona una perspectiva suave de la calidad del
software.
Muchas de estas dimensiones de calidad solo pueden ser consideradas de modo subjetivo.
Se requiere un conjunto de factores de calidad duros, divididos en dos grupos:
-Aquellos que pueden ser medidos directamente.
-Factores que solo pueden medirse indirectamente.
Se requieren comparar el software contra datos.

Factores de Calidad de McCall

Propone una categorizacin de factores que afectan la calidad de software.
Se enfocan en 3 aspectos importantes de un producto de software:
-Caractersticas operacionales.
-Habilidad para someterse al cambio.
-Adaptabilidad a nuevos entornos.
Sin embargo, muchos de estos factores solo pueden ser medidos directamente.

Funcionamiento del producto:

-Exactitud: Grado en que un programa satisface sus especificaciones.
-Confiabilidad: Grado en que se espera que un programa realice sus funciones, con la
precisin requerida.
-Eficiencia: Cantidad de recursos computacionales y cdigo requeridos para que el
programa realice sus funciones.
-Integridad: Grado en que se puede controlar el acceso no autorizado al software o a sus
datos.
-Usabilidad: Esfuerzo requerido para aprender o para usar el software, o preparar e
interpretar sus datos de entrada y salida.

Revisin del Producto:

-Mantenibilidad: Esfuerzo requerido para encontrar y corregir un error en el programa.
-Flexibilidad: Esfuerzo requerido para modificar un programa operacional.
-Capacidad de prueba: Esfuerzo requerido para aprobar un programa, a fin de garantizar
que realice las funciones que se supone que debe realizar.

Transposicin del producto:

-Portabilidad: Esfuerzo requerido para transferir el programa de un hardware a otro, o de
un sistema a otro.
-Reutilizacin: Grado en que el programa, o partes de este, pueden ser reutilizadas en otras
aplicaciones.
-Interoperabilidad: Esfuerzo requerido para acoplar un sistema con otro.
CheckList
En lugar de desarrollar medidas precisas de los diferentes factores de calidad del software, se puede
hacer un CheckList.
Este CheckList indica si los diferentes factores estn presentes en el producto o no.
Esta lista en si puede servir como una medida de calidad del producto.
Los diferentes puntos se pueden extender a detalles ms precisos, lo cual aumenta la precisin del
estimado.

El dilema de la calidad de Software

-Si produces un software de una calidad terrible, pierdes porque nadie querr
comprarlo/usarlo
-Si inviertes demasiado tiempo, esfuerzo y dinero en hacer un software perfecto, pierdes
porque tardar mucho en estar listo y ser muy caro
-Hay que encontrar el justo medio que depende en gran medida de los objetivos del
programa

Software suficientemente bueno

-El dilema anterior sugiere que hay que desarrollar software que sea lo suficientemente
bueno para la aplicacin a que est destinado.
-Un software suficientemente bueno proporciona una alta calidad en las funciones que el
usuario desea.
-Tambin proporciona otras funciones ms especializadas que pueden contener algunos
bugs.
-La calidad debe enfocarse en las funciones ms usadas.
-Sin embargo, todo depende del uso que se le dar al software (e.g. ocio, oficina, diseo,
medico).

Costos de calidad:
La calidad cuesta tiempo y dinero.
Los costos de la calidad son aquellos requeridos en la bsqueda de calidad
Se puede dividir en costos asociados con:
-Prevencin:
Actividades de administracin requeridas para planear y coordinar actividades de
calidad.
Actividades tcnicas para desarrollar los modelos y las especificaciones.
Actividades de planeacin de pruebas.
Costo de la capacitacin y entrenamiento necesarios para realizar las actividades.
-Evaluacin:
Actividades para obtener conocimiento de las condiciones en que se encuentra el
producto.
Costo de realizar revisiones tcnicas.
Costo de la recoleccin de datos y medidas de evaluacin
 Costo de las pruebas y de la depuracin de errores.
-Filtros:
Son aquellos que no existiran si el producto no presentara fallos antes o despus
de ser liberado.
Falla interna: Ocurre cuando el fallo se detecta antes de que el software
sea liberado.
-Costo de reparaciones, efectos secundarios, medidas de calidad y
recoleccin de datos.
Falla externa: Ocurre cuando el fallo se detecta despus de liberar el
producto.
-Atencin de quejas, reemplazo, devolucin, asistencia tcnica,
garantas.

Logrado de calidad de software:

La calidad de software es el resultado de una buena administracin de proyecto y prcticas de
ingeniera de software.
La administracin y la prctica se aplican en el contexto de cuatro actividades:
-Mtodos de ingeniera de software:
-Para construir software de calidad, se debe entender el problema a solucionar.
-Se debe es capaz de crear un diseo que se ajuste al problema.
-El diseo debe guiar el desarrollo de modo que el software resultante presente los
factores de calidad ya discutidos
-Tcnicas de administracin de proyectos:
-El administrador del proyecto debe usar estimaciones para verificar que se puede
cumplir con las fechas de entrega.
-Programar dependencias que son bien entendidas.
-El equipo debe evitar tomar atajos.
-Se debe hacer una planeacin de riesgos para que los problemas no resulten en
caos.
-El plan debe incluir tcnicas de calidad y cambio explicitas.
-Acciones de control de calidad:
-Son acciones de ingeniera de software que ayudan a garantizar que el producto
cumpla con los objetivos de calidad.
-Los modelos son revisados para garantizar que sean completos y consistentes.
-El cdigo puede ser inspeccionado a fin de descubrir y corregir errores antes de
comenzar las pruebas.
-Una serie de pasos de prueba se aplican para descubrir errores lgicos, de
manipulacin de datos, y de interfaces.
-Una combinacin de medicin y retroalimentacin ayuda al equipo a ajustar el
proceso cuando algo falla.
-Garanta de calidad de software:
-Establece la infraestructura que soporta mtodos slidos de ingeniera de software
y acciones de control de calidad.
 -Consiste en un conjunto de funciones de auditoria y reporte que garanticen la
efectividad e integridad de las acciones de control de calidad.
-El objetivo es proporcionar al equipo de trabajo los datos necesarios para estar
informados sobre la calidad actual del software (visin).

Tcnicas de revisin:
Las tcnicas de revisin son filtros en el desarrollo de software.
Se aplican en diferentes puntos del desarrollo.
Sirven para revelar errores.
Se aplican a:
-Requerimientos.
-Modelos.
-Cdigo
-Datos de prueba

Necesidad de revisin:
Es imposible no cometer errores.
Hay errores que pasan inadvertidos por quien los genero.
Muchas veces, estos errores son ms fciles de descubrir por terceros.
Por tales motivos, la revisin utiliza a un grupo de personas para:
-Sealar mejoras necesarias.
-Confirmar mejoras no necesarias.
-Lograr una mayor calidad en el producto.

Tipos de revisin
Una reunin informal es un tipo de revisin.
Una presentacin formal (a clientes, administradores o equipo tcnico).
Revisiones tcnicas:
Revisiones casuales
Explicaciones paso a paso
Inspecciones
La revisin tcnica es el filtro mas efectivo desde el punto de vista de control de calidad.
Es un medio efectivo de descubrir errores y mejorar la calidad del software.

Errores y defectos (y Bug)

Desde el punto de vista tcnico, un error es lo mismo que un defecto, a veces se llama bug.
Desde el punto de vista de la ingeniera de software se hace una distincin:
Error es un problema de calidad detectado antes de la liberacin del
software.
Defecto es un problema de calidad detectado despus de la liberacin
del protocolo.
 Bug es un trmino informal en ingeniera, usado para describir defectos
inexplicables.

Beneficios de las revisiones

El beneficio principal de las revisiones tcnicas es el descubrimiento temprano de errores.
Busca encontrar errores durante el proceso de desarrollo para que no se conviertan en defectos.
Tambin, busca encontrar errores antes de que se propaguen a otros niveles de desarrollo.
Estudios en la industria indican que el 50%-65% de los errores se
introducen en la etapa de diseo.
Las tcnicas de revisin han demostrado ser 75% efectivas en el
descubrimiento de errores.

Amplificacin de errores
Durante una actividad en el desarrollo de software se pueden generar errores.
La revisin puede fallar en descubrir algunos de estos errores y otros de etapas previas.
Por lo tanto, algunos errores pasan a las siguientes etapas de desarrollo.
En algunos casos, los errores que pasen de una etapa a otra son amplificados

Costo:
El nmero de errores descubiertos en cada etapa se multiplica por el costo de removerlos, por
ejemplo:
1.5 unidades durante el diseo
6.5 unidades antes de las pruebas
15 unidades durante las pruebas
67 unidades despus de la liberacin
El costo de desarrollo usando revisiones es de 783 unidades.
Sin las revisiones, el costo es de 2177 unidades

Medidas de revisin
Las revisiones tcnicas son una de las muchas acciones requeridas por las buenas prcticas de
ingeniera de software.
Sin embargo, las acciones requieren esfuerzo, y el esfuerzo es finito.
Es importante entender la efectividad de cada accin.
Para ello se requiere de un conjunto de medidas que indiquen la efectividad de dicha accin.
Las siguientes medidas proporcionan una visin del estado del proyecto:
Ep = Esfuerzo de preparacin
Esfuerzo en horas/persona requerido para revisar si un producto antes
de la revisin.
Ea = Esfuerzo de valoracin
Esfuerzo en horas/personas requerido durante la revisin.
Er = Esfuerzo de rehacer
Esfuerzo en horas/personas dedicado a la correccin de los errores
descubiertos en la revisin.
Medidas de revisin.
WPS = Tamao del producto
Medida del tamao del proyecto bajo revisin.
Nmero de modelos UML
Nmero de pginas de documentacin
Nmero de lneas de cdigo
ER_min = Errores menores encontrados
Nmero de errores encontrados que se pueden catalogar como menores, requieren poco
esfuerzo (umbral a definir).
ER_maj = Errores mayores encontrados
Nmero de errores encontrados que requieren ms que el esfuerzo mnimo.

Anlisis de medidas
Antes de iniciar el anlisis, se debe obtener las siguientes medidas derivadas:
Esfuerzo total de la revisin
E_rev = Ep + Ea + Er
Nmero total de errores
ER_t = ER_min + ER_maj
Densidad de errores
E_d = ER_t/WPS
Como la densidad depende de WPS, puede ser calculada en funcin de los diferentes criterios de
esta medida.
Estas medidas se pueden calcular para cada etapa del proyecto (o proyectos).
Los promedios de varios proyectos permiten estimar la cantidad de errores que se esperan en un
producto nuevo.
Tambin, permite comparar el trabajo actual con la evidencia previa, y determina su fue bueno o
malo.
Una vez realizadas las pruebas, se puede recolectar mayor informacin, por ejemplo:
Esfuerzo requerido para encontrar y corregir errores.
Densidad de errores en el software
Los costos de encontrar y corregir estos errores pueden ser comparados con los costos de las
revisiones, y determinar:
Esfuerzo Ahorrado = E_test E_rev

Efectividad de las revisiones

Las revisiones tcnicas proporcionan una medida de costo/beneficio demostrable.
Sin embargo, muchos desarrolladores encuentran esto contra intuitivo.
Las revisiones toman tiempo
No hay tiempo que perder
Sin embargo, la evidencia demuestra que las revisiones de hecho ahorran tiempo.
Formalidad
Las revisiones tcnicas deben ser realizadas con cierto grado de formalidad.
El grado de formalidad depender del producto que se est desarrollando, toma en cuenta:
Si los revisores tienen roles definidos
Si hay suficiente cantidad de planeacin para la revisin
Si hay una estructura bien definida para la revisin
Si hay un seguimiento por parte de los revisores para las correcciones
echas.

Revisiones informales
Consiste en una revisin simple en lugar de trabajo de un compaero desarrollador.
Puede ser una mnima reunin informal de ms de dos personas.
Tambin puede ser realizada mediante programacin por pares (XP).
No hay una planeacin o agenda para la revisin.
No hay un seguimiento de los cambios.
Su efectividad es mejor que la de las revisiones formales.
Sin embargo, es mejor realizar revisiones informales que no realizar revisiones.
Aunque simples, pueden revelar mltiples errores.
Una manera de mejorar el desempeo de estas revisiones es utilizar CheckList.
Las preguntas en la lista son genricas, pero tiles para guiar la revisin.
Los errores o problemas encontrados son registrados por el desarrollador involucrado.
Posteriormente, el desarrollador atiende los problemas encontrados.
La cantidad de material a revisar en este tipo de reuniones es pequeo.
El tiempo empleado en la revisin es corto, una o dos horas.

Programacin por pares.

La metodologa de desarrollo Xtreme Programming (XP) recomienda la programacin por pares.
En este esquema, dos personas trabajan en una misma estacin.
Esto proporciona un mecanismo de revisin informal en el tiempo real.
Fomenta la revisin continua y resulta en un software de mejor calidad.
Algunos programadores argumentan que la programacin por pares desperdicia recursos
Dos programadores desarrollan un nico trabajo, en lugar de que cada
uno desarrolle un trabajo diferente.
Sin embargo, si se demuestra que el trabajo producido usando esta tcnica es de mejor calidad y de
un costo significativamente menor, el esquema queda justificado.

Revisin Tcnica Formal

Objetivos:
Revelar errores
- Funcionales, lgicos, de implementacin, etc.
Verificar que el software en revisin cumpla con los requerimientos.
 Asegurar que el software siga los estndares predefinidos.
Obtener software que es desarrollado de manera uniforme.
Hacer que los proyectos sean mas manejables.
Adicionalmente, las RTF sirven como entrenamiento
Se observan diferentes enfoques para el anlisis, diseo e
implementacin del software.
Promocionan el apoyo y la continuidad.
El equipo de revisin se familiariza con partes del software que no veria
de otro modo.
La RTF incluye revisiones estructuradas (walkthrough) e inspecciones.
La RTF se desarrolla como una reunin. Para que sea exitosa debe ser planteada, controlada y
atendida (sin ausencias) adecuadamente.

La reunin de la revisin
Cualquier reunin de revisin debe acatar las siguientes restricciones:
Deben involucrarse entre tres y cinco personas.
Debe haber preparacin previa, que no tome ms de dos horas por
persona.
La duracin de la reunin no debe exceder las dos horas.
Una RTF se enfoca en una parte especifica del software.
Los walkthroughs se realiza para cada componente (o un grupo pequeo).
Al enfocarse en pequeas partes del software es ms probable que se descubran errores.
La RTF se enfoca en un producto de trabajo.
Una parte del modelo de requerimientos, un diseo detallado de un
componente, el cdigo de un componente.

Puesta en Marcha
El productor: Persona que ha desarrollado un producto de trabajo.
El productor informa al lder del proyecto que el producto de trabajo esta completo y requiere
revisin.
El lder del proyecto contacta al lder de revisin:
Evala si el producto
Genera copias del material necesario.
Distribuye el material con visores.

Preparacin previa
Cada visor debe dedicar de una a dos horas en revisar el material proporcionado.
Tomar notas, familiarizarse con el trabajo.
El lder de revisin tambin revisa el material y establece una agenda para la reunin.
La reunin se realiza al siguiente da, por lo general.

La reunin.
A la reunin asisten:
El lder de la revisin.
El productor.
Otros visores.
Uno de los revisores toma el rol de secretario (registra la sesin).
La RTF comienza con una introduccin de la agenda de la sesin y una introduccin del productor.
El productor hace un walkthrough del producto de trabajo, explicando el material.
Los revisores plantean preguntas basndose en su preparacin previa.
Cuando se encuentran problemas vlidos, el secretario las registra.

Fin de la reunin.
Al final de la reunin, los participantes deben decidir sobre el producto del trabajo:
Aceptar el producto tal y como est (sin modificaciones).
Rechazar el producto debido a errores graves (cuando se corrijan, se
debe hacer otra revisin).
Aceptar el producto de forma provisional (se encontraron problemas
menores que deben corregirse, pero no se requiere otra revisin).
Los participantes cierran la sesin (firmas).

Reporte de la revisin
Durante la sesin de revisin, el secretario registra todos los problemas a corregir.
Al final de la sesin, el secretario enumera los puntos a atender.
Adicionalmente, se hace un resumen tcnico formal, que responde a las siguientes preguntas:
Qu fue lo que se revis?
Quines lo revisaron?
Qu se encontr y cules fueron las conclusiones?
El reporte consta de una sola pgina (y apndices).
Se incorpora al registro histrico del proyecto
Puede enviarse al lder del proyecto u otros interesados.
Sirve para dos propsitos:
Identificar problemticas en el producto.
Servir como CheckList de gua para el productor cuando realice las
correcciones.
La lista de problemas se anexa al reporte.
Seguimiento
Se debe establece un mecanismo de seguimiento para las correcciones.
Esto es con el fin de asegurar que las correcciones fueron hechas, y de forma adecuada.
No hacer el seguimiento puede resultar en problemas no atendidos (que se pierden).
Un enfoque consiste en asignar esta tarea al lder de la revisin.

Lineamientos.
Los lineamientos deben ser establecidos con antelacin, distribuidos a los revisores, aceptados de
comn acuerdo y seguidos.
Todo esto debido a que, una reunin sin control puede ser peor que no hacerla.
A continuacin, se presenta una lista mnima de lineamientos para reuniones tcnicas formales:
Revisar el producto, no al productor.
Los errores deben ser indicados con gentileza, el tono de la reunin
debe ser constructivo. El lder de la reunin debe asegurar el tono de
actitud correctos para la reunin, y detener la reunin si se ha salido de
control
Establecer una agenda y mantenerla
Uno de los mayores problemas de las reuniones es desviarse del tema.
Una RTF debe mantenerse segn la agenda. El lder de la reunin es
responsable de esto, debe corregir el rumbo de la reunin cuando
ocurra una desviacin.
Limitar debates y refutaciones
Cuando surge un problema, puede no haber un comn acuerdo sobre
la solucin. No se debe debatir el asunto, el problema se registra y se
discute fuera de la reunin.
Mencionar reas de problema, pero no intentar resolverlos todos
La revisin no es una sesin de solucin de problemas. Los problemas
los resuelve el productor.
Tomar notas
Es til tomar notas en un pizarrn, para que todos las vean. Tambin en
una laptop.
Limitar el nmero de participantes e insistir en la preparacin previa
Hay que mantener el nmero de personas involucradas al mnimo, pero
deben prepararse con anticipacin. Para ello, el lder de la revisin
puede solicitar comentarios del material.
Desarrollar CheckList para cada producto revisable
Las CheckList ayudan al lder de revisin a estructurar la RTF. Ayuda a
otros revisores a enfocarse en aspectos importantes. Deben realizarse
para todos los productos de trabajo.
Asignar recursos y programar tiempo para RTFs
 Para que las revisiones sean efectivas, deben programarse como tareas
durante el proceso de desarrollo. Tambin, debe agendarse tiempo
para las correcciones producto de las RTFs.
Proporcionar entrenamiento a todos los revisores
Los revisores deben recibir entrenamiento formal. Se estima necesario
un mes de entrenamiento para cada 20 personas que participan en
revisiones.
Revisar revisiones previas
El primer producto a revisar deben ser los lineamientos de revisin.
Finalmente, cada organizacin de desarrollo de software debe ajustar
los lineamientos que favorecen las RTFs, ya que mltiples variables
influyen en los resultados obtenidos.
Idealmente, todo producto de trabajo debe someterse a una RTF.
Sin embargo, esto es difcil de llevar acabo debido a que los recursos son finitos y el tiempo
es escaso.
Es comn que no se realicen muchas de las revisiones.
Como solucin, se pueden programar RTFs de acuerdo a un muestreo previo.
Muestras de todos los productos de trabajo son revisadas para determinar cules son ms
propensas a fallar.
Los recursos destinados a RTFs se utilizan en estos productos clave.
Para que el mtodo sea efectivo, se debe realizar una buena valoracin de las muestras.
Se sugiere considerar los siguientes puntos:
o Inspeccionar una fraccin de un producto y registrar el nmero de fallos descubiertos.
o Estimar el nmero de fallos en el producto con esa informacin.
o Ordenar los productos de acuerdo a este estimado.
o Enfocar los recursos de revisin en aquellos productos con mayor tasa de error.
La fraccin inspeccionada de cada producto debe ser representativa del producto.
Tambin, debe ser lo suficientemente grande para ser significativa.
Garanta de calidad de software
Consiste en una serie de actividades que deben ser aplicadas en todo el proceso de
desarrollo de software.
Las actividades incluyen administracin y actividades especficas de los diferentes procesos.
Trata de asegurar que las acciones correctas sean hechas en el momento adecuado, y de la
forma correcta.
Los objetivos de las tcnicas analizadas son: producir software en tiempo y de alta calidad.
o Se debe definir explcitamente el significado de software de calidad.
o Se debe crear un conjunto de actividades que permitan garantizar que cada
producto de trabajo sea de alta calidad.
o Se deben realizar tareas de control de calidad en cada proyecto de software.
o Deben usarse mtricas para desarrollar estrategias que permitan mejorar el proceso
de desarrollo.
Garanta de calidad de software (GCS)
Todas las personas involucradas en el proceso de ingeniera de software son responsables
de calidad del producto.
Es importante debido a que reduce la calidad de trabajo que hay que rehacer, esto reduce
costo y tiempo de entrega (Lo puedes hacer bien, o lo puedes hacer ora vez).
La GCS se aplica a los diferentes niveles de abstraccin en que se define la calidad del
producto. Un equipo de GCS identifica actividades que filtran errores en cada nivel.
Se crea un plan de Garanta de Calidad de Software.
Este plan permite definir la estrategia a seguir por parte del equipo de GCS.
o Durante el modelado y la codificacin, se usan los resultados de las revisiones
tcnicas.
o Durante las pruebas, se desarrollan planes y procedimientos de prueba.
Se debe trabajar para mejorar la eficiencia del proceso de eliminacin de errores.

Trasfondo
El control de calidad y la garanta de calidad son actividades esenciales para cualquier
negocio que desarrolle productos para otros.
Actualmente, toda compaa implementa mecanismos que garanticen la calidad de sus
productos.
Originalmente, la calidad del software era responsabilidad del programador.
Sin embargo, esto tuvo que cambiar pronto y se adoptaron mecanismos de GCS.
La Garanta de Calidad de Software (GCS) se puede definir como:
o Un patrn de acciones planeadas y sistemticas, que son requeridas para asegurar
una alta calidad en el software.
Las personas del equipo de GCS deben ver el producto desde el punto de vista del cliente.
o Cumple con los factores de calidad?
o Se siguieron los estndares preestablecidos?
o Se han realizado adecuadamente las actividades de GCS?

Elementos de la GCS
La GCS consiste en una serie de actividades enfocadas en la administracin de la calidad del
software. Se pueden resumir en los siguientes 10 puntos:
o Estndares: El trabajo de la GCS es garantizar que los estndares (IEEE, ISO, etc.) sean
adoptados y seguidos en cada producto de trabajo.
o Revisiones y Auditoras: Las auditoras son una especie de revisin hecha por el equipo
de GCS, para asegurar que se han seguido los lineamientos de calidad de software.
o Pruebas: Las pruebas de software son una funcin de control de calidad cuyo objetivo
es encontrar errores. La GCS asegura que las pruebas sean planeadas y ejecutadas
adecuadamente.
o Coleccin y anlisis de errores: La GCS colecta y analiza datos de los errores
encontrados para entender cmo es que se introducen y que actividades son mejores
para eliminarlos.
o Administracin de cambios: Los cambios no planeados introducen confusin y
problemas de calidad. La GCS asegura que existan prcticas para el manejo de cambios.
 o Educacin: Para mejorar las prcticas de ingeniera de software se requiere capacitar
al equipo desarrollador. La GCS lidera el proceso de mejora de software mediante
programas de capacitacin.
o Administracin de vendedores: La GCS sugiere caractersticas de calidad a los
vendedores de software de terceros. Tambin incorpora requerimientos de calidad en
contratos.
o Administracin de la seguridad: La GCS establece polticas para proteger los datos que
usa el software, con el fin de evitar el ciber-crimen y cumplir con exigencias
gubernamentales.
o Confiabilidad: En muchas ocasiones, el software es una herramienta de trabajo. Los
defectos en el software puede traer consecuencias importantes. La GCS evala el
impacto de las fallas y establece procedimientos para disminuir el riesgo.
o Administracin de riesgos: El equipo de GCS se asegura de que as actividades de
manejo de riesgos se realicen adecuadamente, y de que se establezcan planes de
contingencia.

Tareas del equipo de GCS

La tarea del equipo de GCS es la de asistir al equipo de desarrollo a fin de que logren un
producto de calidad.
El instituto de Ingeniera de Software recomienda un conjunto de acciones que garantizan
la calidad:
o Planeacin, vigilacin, registro, anlisis y reporte.
Estas acciones las realiza un equipo de GCS independiente.
Preparar un plan de GCS para un proyecto.
o Especifica evaluacin, revisiones, auditoras, estndares, procedimientos de reporte
y seguimiento de errores, productos de trabajo, retroalimentacin, etc.
Participa en el desarrollo de la descripcin del proceso de software.
o Verifica conformidad con la organizacin, estndares internos y externos.
Revisa las actividades de ingeniera de software para verificar su conformidad con el
proceso definido.
Audita los productos de trabajo designados para verificar su conformidad con el proceso.
Asegura que las desviaciones en el trabajo sean documentadas y manejadas de acuerdo a
un procedimiento.
Registra cualquier incumplimiento y lo reporta a la alta direccin.

Objetivos pragmticos
Calidad de los requerimientos: El equipo de GCS debe asegurarse de que el equipo de
desarrollo haya revisado el modelo de requerimientos.
Calidad del diseo: El equipo de GCS busca atributos del diseo que sean indicadores de
calidad.
Calidad del cdigo: El cdigo debe cumplir con estndares locales de codificacin. La GCS
busca atributos que permitan un anlisis de la calidad del cdigo.
Efectividad del control de calidad: El equipo de GCS analiza el uso de los recursos limitados
para revisiones y pruebas. Verifica que estos recursos sean asignados de la manera ms
eficiente posible

GCS estadstica
La GCS estadstica implica los siguientes pasos:
- La informacin sobre errores y defectos de software es recopilada
y organizada.
- Se intenta determinar la causa de cada error y defecto
Incumplimiento de especificaciones
Error de diseo
Violacin de estndares
Mala comunicacin con el cliente.
- Usar el principio de Pareto para identificar las principales cusas de
errores y defectos.
El 80% de los errores y defectos son producidos por el 20%
de las causas posibles.
- Corregir las causas principales de error fueron identificadas.
Este procedimiento es simple, pero permite implementar un proceso adaptativo enfocado a mejorar
los elementos que introducen el error.

Ejemplo.
Una compaa de software recopila informacin sobre errores y defectos durante un ao.
Algunos fallos se descubren durante el desarrollo (errores).
Otros se descubren despus de liberar el producto (defectos).
Se descubren cientos de problemas, pero todos pueden tener ser relacionados con una o mas de las
siguientes causas:
- Especificaciones errneas o incompletas (IES).
- Malinterpretacin en la comunicacin con el cliente (MCC).
- Desviacin intencionada de las especificaciones (IDS).
- Violacin de estndares de programacin (VPS).
- Error en la interpretacin de los datos (EDR).
- Interfaz de componente inconsistente (ICI).
- Error en la lgica del diseo (EDL).
- Test errneos o incompletos (IET).
- Documentacin incompleta o incorrecta (IID).
- Error en la traduccin del diseo al lenguaje de programacin (PLT).
- Interfaz humano/maquina ambigua o inconsistente (HCI).
- Otras causas.
Con la informacin recopilada y organizada en estas categoras se genera la siguiente tabla:
Las actividades de correccin deben enfocarse en las causas ms comunes (puntos crticos).
A medida que se corrigen, la lista se actualiza con nuevas prioridades (dinmico).
Este tipo de tcnicas han probado lograr un incremento sustancial en la calidad del software.
Algunas compaas han logrado una reduccin del 50% al ao en defectos.

Principio de Pareto
Utiliza tu tiempo enfocndote en aquellas cosas que verdaderamente importan.
Pero primero asegrate de que entiendes que es lo que realmente importa.

Seis sigma
Es la estrategia de GCS estadstica ms usada actualmente.
El termino se deriva de seis desviaciones estndar (2.4 defectos/milln).
La metodologa seis sigma define tres pasos principales:
- Definir: Requerimientos del cliente, entregables, metas del
proyecto. Usando mtodos claros de comunicacin con el cliente.
- Medir: El proceso existente y su salida para determinar la calidad
de desempeo actual.
- Analizar: Las medidas de los defectos para determinar las causas
clave.
Si se requiere mejorar un proceso existente, se sugieren dos pasos adicionales:
- Mejorar: Eliminar las causas de los defectos.
- Control: Para que el trabajo futuro no reintroduzca las causas de los
defectos.
Si una organizacin est desarrollando un proceso de software, en lugar de mejorar uno existente,
los pasos extra son:
- Diseo: Se disea el proceso para evitar las causas de error y para
cumplir con los requerimientos del cliente.
- Verificacin: Se debe verificar que el diseo efectivamente evite
estas causas de error y cumpla con los requerimientos del cliente.

Confiabilidad del software.

Es un factor muy importante en la calidad del software.
A diferencia de otros factores de calidad, se puede medir directamente.
Tambin se puede estimar usando otros datos histricos.
Definicin de confiabilidad: La confiabilidad del software es la probabilidad de operacin libre de
fallos de un programa de computadora, en un entorno y tiempo especficos.
Ejemplo.
Un programa X tiene una confiabilidad de 0.99999 en 8 horas de procesamiento.
Esto quiere decir que: Si un programa se ejecuta 1000, y requiere 8 horas para ejecutarse, operara
correctamente 999 veces (estimado).
Existe el problema de definir que es un fallo.
Se puede definir como un incumplimiento de los requerimientos.
Existen dos grados de fallo, pueden ir desde los molestos hasta los catastrficos.
Unos se pueden corregir fcilmente, otros no.
Medidas de Confiabilidad
Una medida simple de confiabilidad del software es el tiempo medio entre las fallas.
Un usuario se ve ms afectado por la ocurrencia de fallos y no por el nmero total de defectos.
Cada defecto en un programa tiene una tasa de fallo diferente.
Por ello, el nmero de defectos no guarda mucha relacin con la confiabilidad del sistema.
Si se corrigen los defectos que casi no ocurren, el impacto en la confiabilidad es casi nulo.

Disponibilidad del Software.

Es otra medida que nos dice la probabilidad de que un programa opere segn los requerimientos

en un punto del tiempo dado. = 100%
+
MTTF: Tiempo medio de fallo.
MTTR: Tiempo medio de remontar.

Seguridad del Software

Actividad de garanta de calidad del software que se enfoca en la identificacin y evaluacin de
peligros potenciales.
Estos peligros pueden afectar el software negativamente y hacer un sistema fallar.
Si estos peligros se identifican de forma temprana, se puede especificar caractersticas de diseo
que permitan eliminarlos o controlarlos.
Se identifican y catalogan por criticidad y riesgo.
Una vez identificados, se analizan para determinar u severidad y probabilidad de ocurrencia.
Para que sea efectivo, el software debe ser analizado en el contexto de sistema completo.
Esto se debe a que un error sencillo puede ser magnificado por el sistema completo.
Una vez hecho esto, se puede especificar requerimientos de seguridad.
Esta especificacin contiene una lista de eventos no deseados, y las respuestas deseadas del sistema
ante tales eventos.
Aunque la confiabilidad y la seguridad del software son conceptos relacionados, no son lo mismo.
La confiabilidad del software usa el anlisis estadstico para determinar la probabilidad de
ocurrencia de un fallo.
Sin embargo, la ocurrencia de un fallo no necesariamente resulta un peligro o dao.
La seguridad del software examina como un fallo puede resultar en un percance.
Los fallos son evaluados en el contexto de un sistema de cmputo completo y su entorno.

Estndar de calidad ISO 9000

Un sistema de garanta de calidad puede ser definido como estructura organizacional,
responsabilidades, procedimientos, y recursos necesarios para implementar la administracin de la
calidad.
Estos sistemas son creados para ayudar a que las organizaciones aseguren que sus productos y
servicios satisfagan las expectativas del cliente.
Estos sistemas abarcan una variedad de actividades, durante todo el ciclo de vida del producto.
 - Planeacin, control, medicin, prueba, reporte y mejora de los
niveles de calidad.
El estndar ISO 9000 describen los elementos de garanta de calidad en trminos genricos.
Estos pueden ser aplicados a cualquier negocio independientemente de los productos o servicios
que ofrecen.
Para registrarse, el sistema de operaciones y de calidad de la compaa es examinado por auditores.
Si se aprueba la auditoria, se expide un certificado para la compaa.
Dos veces al ao se realizan auditorias de supervisin para garantizar que el estndar se sigue
cumpliendo.
Lo que se revisa en una auditoria es: Responsabilidad de gestin, sistema de calidad, Revisin de
contrato, control de diseo, control de datos y documentos, identificacin de producto y
trazabilidad, control de procesos, inspeccin y prueba, acciones preventivas y correctivas, registros
de control de calidad, auditoras internas de calidad, entrenamiento, mantenimiento, estadsticas.
Para que una compaa de software est registrada con ISO 9001:2000 debe establecer polticas y
procedimientos para cumplir con los requerimientos anteriores.
Tambin, debe ser capaz de demostrar de que estas polticas y procedimientos son aplicados.

Estrategias de prueba de software

Una estrategia para las pruebas de software proporciona un mapa, que describe los pasos a seguir
como parte del proceso de prueba
Cualquier estrategia debe incluir:
- Planeacin de pruebas.
- Diseo de casos de prueba
- Ejecucin de las pruebas
- Coleccin de datos resultantes
- Evaluacin de los datos
Una estrategia de prueba de software debe ser suficientemente flexible para promover un enfoque
personalizado.
Al mismo tiempo, debe ser lo suficientemente rgido para permitir la planeacin y el seguimiento a
medida que el proyecto avanza.
La estrategia proporciona una gua para el desarrollador, y una seria de metas para el administrador.
Las pruebas son un conjunto de actividades que pueden ser planeadas por adelantado, y pueden
realizarse de forma sistemtica.
Una plantilla para las pruebas de software debe definirse para el proceso de desarrollo.
- Casos de prueba posibles.
- Mtodos de prueba
Existen varias estrategias en la literatura que proporciona esa plantilla.

Enfoque estratgico
Todas las estrategias presentan las siguientes caractersticas genricas:
Para realizar las pruebas de forma efectiva, se deben realizar revisiones tcnicas efectivas
(muchos errores se eliminan antes de las pruebas.
Las pruebas comienzan a nivel de componente y van avanzando hacia lo general, hasta llegar a
pruebas para todo el sistema.
 Diferentes tcnicas de prueba son usadas para diferentes enfoques de ingeniera de software y
en diferentes momentos.
Las pruebas son realizadas por el desarrollador del software, y por grupos de prueba
independientes (para proyectos grandes).
Las pruebas y la depuracin son actividades diferentes, pero la depuracin deber ser parte de
cualquier estrategia de prueba.
La estrategia debe incluir pruebas de bajo nivel para verificar que no haya errores, y de alto nivel
para validacin.
El progreso debe ser medible, y los errores deben aparecer lo antes posible.

Verificacin y validacin
Las pruebas de software son un elemento de un tema ms amplio: verificacin y validacin.
Verificacin: Conjunto de tareas que aseguran que el software implementa correctamente una
funcin especfica.
Se est construyendo el producto correctamente?
Validacin: Un conjunto diferente de tareas que aseguran que el software ha sido construido
conforme los requerimientos.
Se est construyendo el producto correcto?
La verificacin y validacin incluyen varias actividades de GCS:
- Revisiones tcnicas
- Auditorias de calidad y configuracin
- Monitoreo de desempeo
- Simulacin
- Estudio de factibilidad
- Revisin de la documentacin
- Revisin de las bases de datos
- Anlisis de algoritmos
- Pruebas de desarrollo.
- Pruebas de usabilidad
- Pruebas de calificacin
- Pruebas de aceptacin
- Pruebas de instalacin
- Otros
Pruebas
Las pruebas son el ltimo paso en el cual se puede juzgar la calidad de un software.
Las pruebas permiten descubrir errores que no fueron advertidos en inspecciones previas.
Las pruebas no deben ser vistas como una red de seguridad, si no hay calidad antes de las pruebas,
no las habr despus.
La calidad se incorpora mediante el proceso de ingeniera de software. (mtodos, revisiones,
administracin, mediciones, etc.)

Organizacin de las pruebas

Existe un conflicto relacionado con las pruebas de software.
El desarrollador crea un modelo para resolver un problema, lo implementa y genera
documentacin.
Luego, se le pide que haga pruebas que intenten hacer fallar al producto.
Hay una tendencia psicolgica a desarrollar pruebas que demuestren que el software es correcto,
en lugar de hacerlas para descubrir fallos.
Debido a esto, las pruebas se organizan de la siguiente manera:
El desarrollador realiza pruebas de cada componente (pruebas unitarias).
En ocasiones el desarrollador tambin realiza pruebas de integracin (del sistema como un
todo).
Luego, un grupo de prueba independiente (GPI) revisa el producto para buscar los errores del
desarrollador (soluciona conflicto de intereses).
El desarrollador y el GPI trabajan en conjunto para descubrir y corregir errores.

Desarrollo de software (Espiral)

Ingeniera de software: rol del software
Requerimientos: dominio, funcin, comportamiento, desempeo, restricciones, validacin.
Diseo
Cdigo
Pruebas unitarias
Pruebas de integracin
Pruebas de validacin
Pruebas del sistema

Pruebas unitarias
Inicialmente, las pruebas se enfocan en los componentes individuales.
Estas pruebas aseguran que el componente funcione como una unidad.
Estas pruebas hacen uso extensivo de tcnicas que activen rutas especficas de la estructura de
control.
Esto asegura la cobertura de todos los aspectos del componente y maximiza la deteccin de errores.

Pruebas de integracin
A continuacin, los componentes se ensamblan (integran) para formar paquetes.
Las pruebas de integracin se enfocan en la verificacin y construccin del programa
Los casos de prueba son, normalmente, colecciones de datos que contienen las entradas al
programa y sus salidas esperadas.
La activacin de rutas no es muy comn en este tipo de pruebas, pero de ser necesario puede usarse.
Pruebas de validacin
Pertenecen a las pruebas de orden superior.
Evalan los criterios de validacin establecidos en la etapa de anlisis de requerimientos.
Proporcionan la garanta final de que el software cumple con los requerimientos establecidos:
- Informacin
- Funcionalidad
- Comportamiento
- Desempeo

Pruebas del sistema

Este tipo de pruebas ya no pertenecen a la ingeniera de software, sino a la ingeniera de sistemas.
Ya validado, el software se pone en prueba en el entorno y bajo las condiciones de uso. (hardware,
usuarios, bases de datos, otro software, etc.).
Las pruebas del sistema verifican que todos los elementos del sistema al final se acoplen.
Garantizan que el sistema final funcione como se espera (funcionalidad, desempeo).

Preguntas.
En qu momento se dan por finalizadas las pruebas?
- Las pruebas nunca terminan. Cada que corre el programa se esta
probando.
- Las pruebas se dan por finalizadas cuando se acaba el tiempo o los
recursos

Cmo saber si hemos probado lo suficiente?

- Se puede estimar haciendo mediciones y analizando los datos
estadsticos que generen.
No existen respuestas definitivas.

Problemas con las estrategias

Para que la estrategia de prueba sea efectiva, se debe cumplir una serie de requerimientos:
Especificar los requerimientos del producto de forma cuantificable mucho antes de empezar las
pruebas.
- Se deben disear pruebas para medir: verificacin, usabilidad,
escalabilidad, portabilidad.
Establecer los objetivos de las pruebas de forma explcita.
 - El plan de prueba debe incluir objetivos de: efectividad, cobertura,
tiempo de fallo, costo de encontrar y corregir, actividades de
prueba.
Comprender a los usuarios del software y desarrollar un perfil por cada categora.
- Permiten acotar casos de uso, y por lo tanto, los casos de prueba
Desarrollar un plan de pruebas que enfatice ciclos rpidos.
- Es recomendable hacer muchos ciclos de prueba cortos que pocos
ciclos largos. Debe ser en incrementos de funcionalidad.
Desarrollar software que este diseado para probarse a s mismo.
- Existen tcnicas de programacin que facilitan el diagnstico de
fallas.
Usar revisiones tcnicas como filtro antes de las pruebas.
- Las pruebas tcnicas revelan errores, lo cual reduce el esfuerzo
requerido en la etapa de prueba.
Usar revisiones tcnicas para evaluar la estrategia y los casos de prueba
- Las revisiones tcnicas pueden revelar errores en el proceso de
prueba mismo.
Desarrollar un enfoque de mejora continua para el proceso de prueba.
- La estrategia de prueba se debe medir para implementar un sistema
de control estadstico.

Estrategias para software convencional

Existen muchas estrategias diferentes.
En un extremo, podemos comenzar las pruebas hasta que el sistema est completo.
Atractivo para los programadores, pero no funciona. El software resultante es de mala calidad.
En el otro extremo, las pruebas pueden realizarse diariamente, cada que se construye una parte del
software.
El mtodo es muy efectivo, pero poco atractivo para el programador.
La mayora de las compaas de software adopta una estrategia que se sita entre ambos extremos.
Adopta un enfoque incrementa del proceso de prueba.
Luego hacen pruebe para facilitar la integracin de los componentes.
Finalmente, prueba el sistema completo.
Se enfocan en la validacin de las unidades ms pequeas de un diseo de software: componente
modulo.
Utilizan el diseo del componente como gua (caja blanca)
Se prueban las diferentes rutas de la estructura de control.
Se enfocan en la lgica interna del componente.
Las pruebas pueden hacer en paralelo con otros componentes.
Consideraciones
Interface: Se debe probar que los datos influyan adecuadamente hacia el componente y
desde el componente-
Estructuras locales: Se debe probar que las estructuras de datos del componente
mantengan su integridad durante la ejecucin.
 Rutas de control: L as pruebas deben ejecutar todas las rutas de la estructura de control, al
menos una vez.
Condiciones lmite: Probar que el componente se comporte adecuadamente en los lmites
de su dominio, y restrinja los valores fuera de este.
Rutas de manejo de errores: Se deben de probar las rutas de control para el manejo de
errores del componente.
Procedimientos
Las pruebas unitarias se consideran parte del proceso de codificacin.
El diseo de las pruebas unitarias puede hacerse antes de la codificacin, o inmediatamente
despus.
Una revisin de la informacin de diseo del componente ayuda para el diseo de los casos de
prueba (categoras anteriores).
Como los componentes no son programas, cada prueba requiere de un driver y quiz stubs.
Driver: Es un programa que pasa datos de prueba a un componente e imprime resultados
relevantes.
Stubs: Son componentes que reemplazan a otros durante la prueba.
Sirve para probar casos especiales o poco frecuentes.
Ejemplo: Reemplazar malloc (C) con un stub que provoque fallos en la asignacin de memoria. Un
error raro y por lo tanto difcil de probar.
Los drivers y stubs implican la escritura de ms cdigo, y por lo tanto tienen un costo.
Son proporciones de software que se entregan con el producto final (o s?).
Los drivers y stubs deben ser simples.
Algunos componentes no pueden probarse con drivers y stubs simples.
En tales casos, mejores pruebas pueden hacerse en la etapa de integracin.
Las pruebas unitarias mejoran si los componentes tienen una alta cohesin (hacen una sola cosa).

Pruebas de integracin
Ocurre despus de que se probaron los componentes de forma individual (pruebas unitarias).
Por qu son necesarias las pruebas de integracin?
Prdida de datos en las interfaces.
Efectos adversos de un componente sobre otro.
Sub-funciones que combinadas no obtiene lo esperado.
Magnificacin de imprecisiones en los datos.
Las pruebas de integracin son una tcnica de construccin de la arquitectura de software.
Tambin revelan problemas con las interfaces.
Su objetivo es tomar componentes probados (pruebas unitarias) y construir la estructura del
software diseada.
Existe una tendencia a no realizar una integracin incremental (big bang)
Es comn que la integracin falle debido a mltiples errores.
Una vez integrado todo el sistema, los errores son difciles de corregir, debido a que, para ello, hay
que aislarlos.
Al corregir un error, pueden aparecer nuevos y pueden propagarse por todo el sistema,
Por otro lado, la integracin incremental resuelve el problema.
El programa es construido y probado en pequeos incrementos.
Los errores que ocurren ya estn aislados.
Por lo tanto, es fcil encontrar y corregir errores. Las interfaces se pueden probar de forma
exhaustiva, lo cual no se puede lograr con el sistema ya integrado.
Se puede aplicar un enfoque de prueba sistemtico.

Integracin Top-Down
Es una metodologa de integracin incremental.
Los mdulos son integrados movindose hacia abajo, partiendo del mdulo principal (main).
Los mdulos subordinados se incorporan ya sea en anchura o en profundidad.

La integracin se realiza en pasos:

El mdulo principal es usado como driver de prueba. Se usan stubs para reemplazar los
componentes subordinados inmediatos.
Los stubs subordinados son reemplazados incrementalmente con los componentes
correspondientes.
Se realizan pruebas cada que se integra un componente.
Terminadas las pruebas, se reemplaza otro stub con un componente.
Se pueden hacer pruebas para la regresin para asegurar que no se introduzcan nuevos errores.
La integracin Top-Down verifica los puntos de control o de decisin ms importantes en una etapa
temprana.
Si se usa integracin en profundidad, se puede tener funcionalidades completas del software (para
mostrar al cliente).
Sin embargo, puede haber problemas con los stubs, si esto se vuelven complicados.

Integracin Bottom-Up
Este enfoque inicia la construccin y prueba del software usando mdulos atmicos.
Como los mdulos dependientes siempre estn disponibles (completos), este enfoque elimina la
necesidad de programar stubs.
Esta estrategia de integracin se puede implementar de la siguiente forma: Los componentes de
bajo nivel se combinan en clusters (builds) que realizan alguna sub-funcin especfica.

Se escribe un driver para coordinar los casos de entrada y salida.

Se prueba el cluster.
Se quitan los drivers* y los cluster son combinados a su vez, hacia arriba en la estructura del
programa.
A medida que la integracin se mueve hacia arriba, la necesidad de drivers distintos disminuye.
El software cambia cada vez que se integra un mdulo nuevo.
Nuevas rutas de flujo de datos
Nuevas operaciones de E/S
Nueva lgica de control
Esto puede causar problemas con mdulos que ya funcionan bien antes de la integracin.
Las pruebas de regresin implican la ejecucin de un conjunto de pruebas que ya se haban
realizado.
Pruebas de Regresin
El software cambia cada vez que e integra un mdulo nuevo.
- Nuevas rutas de flujo de datos.
- Nuevas operaciones de Entrada y Salida
- Nueva lgica de control
Esto puede causar problemas con mdulos que ya funcionaban antes bien de la integracin.
Las pruebas de regresin implican la ejecucin de un conjunto de pruebas que ya se haban
realizado.
Las pruebas re regresin se aseguran que los cambios realizados no produzcan fallas en mdulos ya
probados.
En general, el objetivo de las pruebas es encontrar fallos, y estos deben de corregirse.
Cuando se corrige el software, se modifica algo en el cdigo para tal fin.
Las pruebas de regresin sirven para verificar que estos cambios no produzcan defectos no
deseados.
Las pruebas de regresin pueden realizarse de forma manual o automatizada.
Si se hacen de forma manual, simplemente se ejecuta el conjunto de pruebas requeridas.
Para hacer las pruebas de forma automatizada, se usan herramientas de software.
Estas herramientas permiten capturar los casos de prueba y sus salidas.
Esta informacin se compara con los resultados de pruebas posteriores.
La suite de pruebas de regresin contiene 3 clases diferentes de casos de prueba:
Un conjunto representativo de pruebas que ejercitan todas las funciones del software.
Pruebas adicionales enfocadas en funciones con alta probabilidad de ser afectadas por cambios.
Pruebas que se enfocan en componentes que han cambiado.
Las suites de pruebas de regresin pueden llegar a ser muy grandes. Es importante incluir solo las
pruebas esenciales.

Prueba de Humo
Es un enfoque de pruebas de integracin.
Se realizan durante el desarrollo del producto.
Consiste en evaluar el sistema completo de manera frecuente (diariamente).
El nombre describe el tipo de prueba: Se enciende el dispositivo para verificar que no empiece a
echar humo.
Estas pruebas permiten saber si el producto est en condiciones de ser probado a detalle, en su
lugar se requiere correcciones de fallos.
Las actividades que conforman las pruebas de humo incluyen las siguientes:
Integracin de los componentes recin codificados en un clster.
Diseo de pruebas para exponer aquellos errores que impiden el funcionamiento correcto del
clster.
Realizar una prueba de humo cuando el clster se integra con otros (y tambin diariamente).
Las pruebas diarias permiten obtener una evaluacin realista del proceso de integracin.
Las pruebas de humo deben ejercitar el sistema completo (lo que se ha hecho).
No es necesario que las pruebas sean exhaustivas, pero deben ser capaces de exponer los problemas
mayores.
Las pruebas de humo deben ser lo suficientemente exhaustivas para indicar que, si se pasan las
pruebas, el software es lo suficientemente estable para realizar pruebas ms detalladas.
Las pruebas de humo son ms tiles cuando se tiene un proyecto complejo y con fechas de entrega
estrictas. Ofrecen los siguientes beneficios:
Los riesgos de integracin se reducen.
La calidad del producto final se incrementa.
Se simplifica el diagnstico y correccin de los errores.
Es ms fcil evaluar el progreso.

Opciones Estratgicas
Ha existido mucha discusin respecto a cul estrategia es mejor: top-down vs bottom-up.
La mayora de desventajas de la tcnica top-down se la necesidad de programar stubs, y sus
dificultades.
La mayor desventaja de la tcnica bottom-up es que el programa como tal no existe hasta que se
integra el ultimo modulo.
La seleccin de la estrategia depender de los requerimientos del software y la planeacin.
Se puede optar por una estrategia hibrida (en ocasiones llamada prueba de sndwich) que ofrece
un buen compromiso.
Utiliza pruebas top-down para los niveles superiores de la estructura de software.
- Permite que el programa exista desde etapas tempranas (muestra
al cliente).
Utiliza pruebas bottom-up para los niveles subordinados.
- Reduce la cantidad de los stubs necesarios.

Mdulos Crticos.
Para desarrollar un conjunto de pruebas adecuado, es necesario que el desarrollador identifique los
mdulos crticos, que poseen una o ms de las siguientes caractersticas:
Abordar varios requerimientos.
Tienen un alto nivel de control (nodos altos).
Son complejos o propensos a errores.
Tienen requerimientos de desempeo especficos.
Deben probarse tan pronto como sea posible.
En ellos se enfocan las pruebas de regresin.
Productos de trabajo de integracin
El plan de integracin de software y la descripcin de las pruebas se especifica en un documento
(Especificacin de pruebas).
Incluye un plan de pruebas y procedimientos de prueba.
Las pruebas se dividen en diferentes fases (y tambin por clsters).
Cada fase delinea una categora funcional del software.
Los mdulos tambin se disean de esta forma.

Fases de Prueba
Integridad de interfaz: Las interfaces internas y externas se prueban cada que se incorpora un
mdulo o clster.
Validez Funcional: Se llevan a cabo pruebas que revelen errores funcionales.
Contenido de informacin: Se realizan pruebas para descubrir errores en las estructuras de datos
(locales y globales).
Desempeo: Se realizan pruebas para verificar los niveles de desempeo especificndolos en el
diseo.

Plan de prueba
El plan de prueba debe programar la integracin y el diseo de software de asistencia (drivers y
stubs).
Casa fase est indicada con una fecha de inicio y fin.
Se establece tiempo disponible para pruebas unitarias.
Un historial de resultado de pruebas se registra en otro documento (reportes).
Este documento ser esencial para las tareas de mantenimiento del software.

Estrategias de prueba para OOP

Objetivo de las pruebas:
Encontrar la mayor cantidad de errores posible, con una cantidad de esfuerzo manejable, en un
lapso de tiempo realista.

El objetivo permanece inalterado para el software orientado a objetos.

Sin embargo, la naturaleza de un software orientado a objetos cambia las estrategias de prueba.
Para el software orientado a objetos, el concepto de unidad cambia.
Una clase encapsula datos y mtodos que operan sobre esos datos.
Las pruebas unitarias para software OO se enfocan normalmente en las clases.
Sin embargo. Los mtodos de la clase son los componentes ms pequeos que pueden ser
probados.
En la OOP ya no es posible probar un mtodo (funcin) de forma aislada, debe probarse como parte
de una clase. Por ejemplo:
- Un mtodo es definido en una clase base
 - El mtodo es heredado por varias clases derivadas.
- Cada clase derivada usa el mtodo en el contexto de su definicin,
y su uso cambia.
- Esto hace necesario probar el mtodo en cada clase derivada.
- No es efectivo probar el mtodo de forma aislada.
Las pruebas de clase para el software OO son equivalentes a las pruebas unitarias para el software
modular.
Las pruebas unitarias del software modular se enfocan en el algoritmo del componente, y de los
datos que fluyen por su interfaz.
Las pruebas de clases del software OO se enfocan en las operaciones encapsuladas en la clase, y en
sus variables de estado.
El software OO no posee una estructura jerrquica de control evidente.
Debido a esto, las estrategias de integracin Top-Down y Bottom-up no tienen mucho significado.
Adicionalmente, la integracin incremental de mtodos en una clase es imposible en muchos casos,
debido a la interaccin con otros componentes de la clase.
Hay dos estrategias de integracin.
Pruebas basadas en hilos.
Integran un conjunto de clases requeridas para responder a una entrada o evento del sistema.
Cada hilo es integrado y probado de forma individual.
Se usan pruebas de regresin para asegurarse de que no ocurran defectos secundarios.
Pruebas basadas en uso
La construccin del software comienza probando las clases independientes (requieren muy poco de
otras clases).
Luego, se prueba la siguiente capa, agregando aquellas clases dependientes que usan clases
independientes.
Esta secuencia de prueba de capas de clases dependientes continua hasta que el sistema completo
es integrado.

Drivers y Stubs
En programas OO los drivers se usan tanto para probar operaciones del nivel ms bajo, como para
probar conjuntos completos de clases.
Los drivers tambin se usan para reemplazar la interfaz de usuario, esto permite probar la
funcionalidad del sistema antes de implementar la interfaz.
Los stubs se pueden usar cuando diferentes clases colaboran entre si, pero alguna de llas no esta
implementada aun.

Pruebas de grupos.
Es un proceso de integracin de software OO.
Un grupo (clster) de clases que colaboran entre si es activado por casos de prueba.
Estos casos de prueba intentan revelar errores en la colaboracin de las clases del grupo.
Estrategias de prueba para una aplicacin Web
La estrategia para probar aplicaciones web usa los principios generales de las pruebas de software
y las estrategias para software OO.
Los siguientes pasos resumen la estrategia:
El modelo de contenido se revisa para descubrir errores.
El modelo de interfaz se revisa para garantizar que cubra todos los casos de uso.
El modelo de diseo se revisa para descubrir errores de navegacin.
La interfaz de usuario de prueba para descubrir errores de presentacin y mecnica de navegacin
Cada componente funcional es probado (pruebas unitarias).
Se prueba la navegacin a travs de la arquitectura.
La aplicacin web se implementa en una variedad de configuraciones entorno y se prueba su
compatibilidad de cada una.