CALIDAD DEL SOFTWAREINTRODUCCION.El espectro De La Gestin: La gestin eficaz de la La calidad del software es una preocupacin a la que se dedican muchos esfuerzos. Sin embargo, el software casi nunca es perfecto.Todo proyecto tiene como objetivo producir el software de la mejor calidad posible, que cumpla, y si puede ser supere, las expectativas de sus usuarios. Existe abundante literatura sobre los procesos de calidad de software y actualmente se realiza una considerable investigacin acadmica en este campo dentro de la ingeniera del software.

En esta seccin nos intentaremos en dar una visin prctica de los controles de calidad y de pruebas en el caso particular, tanto de prcticas como de aplicaciones, del software, y veremos cules son los principales principios, tcnicas y aplicaciones que se utilizan para garantizar la calidad de los productos de software en general CALIDAD DEL SOFTWARE

OBJETIVOSLos materiales didcticos asociados a este mdulo permitirn al estudiante obtener los siguientes conocimientos: Familiarizarse con la terminologa relacionada con el control de calidad y pruebas que es de uso comn en la ingeniera del software. Conocer las principales tcnicas de comprobacin manual de software usadas en la ingeniera del software y en entornos libres. Conocer las principales tcnicas de comprobacin automtica de software usadas en ingeniera del software y el software libre que se utiliza en ellas.

OBJETIVOS continuacin Conocer los sistemas de comprobacin de unidades de software y entender su funcionamiento. Conocer los sistemas de gestin de errores, la anatoma de un error, su ciclo de vida, y familiarizarse con el sistema de gestin de errores libre Bugzilla.

CONTROL DE CALIDAD Y PRUEBASCualquier usuario o desarrollador sabe, por experiencia propia, que los programas no son perfectos. Los programas tienen errores. Cuanto mejor sea el proceso de ingeniera del software y el proceso de control de calidad y pruebas que se utilice, menos errores tendr. El software tiene una media de 0,150 errores por cada 1.000 lneas de cdigo. Si tenemos en cuenta que un producto como OpenOffice.org 1.0 tiene aproximadamente 7 millones de lneas de cdigo, la aritmtica es sencilla.

Hoy en da cualquier proyecto de software integra dentro de su ciclo de desarrollo procesos de control de calidad y pruebas. No existe una nica prctica unnimemente aceptada, ni el mundo acadmico ni empresarial para llevar a cabo estos procesos. Tampoco existe ningn mtodo que se considere mejor que los otros. Cada proyectode software utiliza la combinacin de mtodos que mejor se adapta a sus necesidades.CONTROL DE .

CONTROL DE .Los proyectos que no integran un control de calidad como parte de su ciclo de desarrollo a la larga tienen un costo ms alto. Esto es debido a que cuanto ms avanzado est el ciclo de desarrollo de un programa, ms costoso resulta solucionar sus errores. Se requieren entonces un mayor nmero de horas de trabajo dedicadas a solucionar dichos errores y adems sus repercusiones negativas sern ms graves. Por esto, siempre que iniciemos el desarrollo de un nuevo proyecto deberamos incluir un plan de gestin de calidad.

CONTROL DE .Para poder llevar a cabo un control de calidad, es imprescindible haber definido los requisitos del sistema de software que vamos a implementar, ya que son necesarios para disponer de una especificacin del propsito del software. Los procesos de calidad verifican que el software cumple con los requisitos que definimos originalmente.

Las tcnicas y sistemas de control de calidad y pruebas tienen una terminologa muy especfica para referirse a conceptos singulares de este tipo de sistemas. A continuacin veremos los conceptos y trminos ms habituales:

Error (bug). Fallo en la codificacin o diseo de un sistema que causa que el programa no funcione correctamente o falle.

Alcance del cdigo (code coverage). Proceso para determinar qu partes de un programa nunca son utilizadas o que nunca son probadas como parte del proceso de pruebas.TERMINOS COMUNES

TERMINOS COMUNES. Prueba de estrs (stress testing). Conjunto de pruebas que tienen como objetivo medir el rendimiento de un sistema bajo cargas elevadas de trabajo. Por ejemplo, si una determinada aplicacin web es capaz de satisfacer con unos estndares de servicio aceptables

Prueba de regresin (regression testing). Conjunto de pruebas que tienen como objetivo comprobar que la funcionalidad de la aplicacin no ha sido daada por cambios recientes que hemos realizado.Por ejemplo, si hemos aadido una nueva funcionalidad a un sistema o corregido un error, comprobar que estas modificaciones no han daado al resto de funcionalidad existente del sistema. un nmero concreto de usuarios simultneos.

Prueba de usabilidad (usability testing). Conjunto de pruebas que tienen como objetivo medir la usabilidad de un sistema por parte de sus usuarios. En general, se centra en determinar si los usuarios de un sistema son capaces de conseguir sus objetivos con elsistema que es objeto de la prueba.

Probador (tester). Persona encargada de realizar un proceso de pruebas, bien manuales o automticas, de un sistema y reportar sus posibles errores.TERMINOS COMUNES.

PRINCIPIOS DE LA COMPROBACION DE SWCualquiera que sea la tcnica o conjunto de tcnicas que utilicemos para asegurar la calidad de nuestro software, existen un conjunto de principios que debemos tener siempre presentes. A continuacin enumeramos los principales: Es imperativo disponer de unos requisitos que detallen el sistema. Los procesos de calidad se basan en verificar que el software cumple con los requisitos del sistema. Sin unos requisitos que describan el sistema de forma clara y detallada, es imposible crear un proceso de calidad con unas mnimas garantas.

PRINCIPIOS DE LA COMPROBACION DE SW Los procesos de calidad deben ser integrados en las primeras fases del proyecto. Los procesos de control de calidad del sistema deben ser parte integral del mismo desde sus inicios. Realizar los procesos de pruebas cuando el proyecto se encuentra enuna fase avanzada d e su desarrollo o cerca de su fin es una mala prctica en ingeniera del software. Por ejemplo, en el ciclo final de desarrollo es muy costoso corregir errores de diseo. Cuanto antes detectemos un error en el ciclo, ms econmico ser corregirlo.

PRINCIPIOS DE LA COMPROBACION DE SWLa persona o grupo de personas que realizan el desarrollo de un sistema no deben ser en ningn caso las mismas que son responsables de realizar el control de pruebas. De la mismamanera que sucede en otras disciplinas, como por ejemplo laescritura, donde los escritores no corrigen sus propios textos. Es importante recordar que a menudo se producen errores en la interpretacin de la especificacin del sistema y una persona que no ha estado involucrada con el desarrollo del sistema puede ms fcilmente evaluar si su interpretacin ha sido o no correcta.

PRINCIPIOS DE LA COMPROBACION DE SW Quien desarrolle un sistema no debe ser quien prueba su funcionalidad. La persona o grupo de personas que realizan el desarrollo de un sistema no deben ser en ningn caso las mismas que son responsables de realizar el control de pruebas. De la misma manera que sucede en otras disciplinas, como por ejemplo la escritura, don de los escritores no corrigen sus propios textos. Es importante recordar que a menudo se producen errores en la interpretacin de la especificacin del sistema y una persona que no ha estado involucrada con el desarrollo del sistema puede ms fcilmente evaluar si su interpretacin ha sido o no correcta.

TECNICAS MANUALES DE COMPROBACION DE SWLas tcnicas manuales de comprobacin de software son un conjunto de mtodos ampliamente usados en los procesos de control de pruebas. En su versin ms informal consisten en un grupo de probadores que instalan una aplicacin y, sin ningn plan predeterminado, la utilizan y reportan los errores que van encontrando durante su uso para que sean solucionados.En la versin ms formal de este mtodo se utilizan guiones de pruebas, que son pequeas guas de acciones que un probador debe efectuar y los resultados que debe obtener si el sistema est funcionando correctamente. Es habitual en muchos proyectos que antes de liberar una nueva versin del proyecto deba superarse con satisfaccin un conjunto de estos guiones de pruebas.

TECNICAS MANUALES DE COMPROBACION DE SWLa mayora de guiones de pruebas tienen como objetivo asegurar que la funcionalidad ms comn del programa no se ha visto afectada por las mejoras introducidas desde la ltima versin y que un usuario medio no encontrar ningn error grave.Ejemploste es un ejemplo de guin de pruebas del proyecto OpenOffice.org que ilustra su uso.rea de la prueba: Solaris - Linux - WindowsObjetivo de la prueba Verificar que OpenOffice.org abre un fichero .jpg bienRequerimientos: Un fichero .jpg es necesario para poder efectuar esta pruebaAcciones Descripcin: Desde la barra de mens, seleccione File-open2) La caja de dilogo de abertura del archivo debe mostrarse.3) Introduzca el nombre del fichero .jpg y seleccione el botn Open.4) Cierre el fichero grfico.Resultado esperado:OpenOffice.org debe mostrar una nueva ventana mostrando el archivo grfico.Fuente: Ejemplo de guin de pruebas extrado del proyectoOpenOffice.org. http://qa.openoffice.org/

Como vemos, se trata de una descripcin de acciones que el probador debe seguir, junto con el resultado esperado para dichas acciones.Aunque este sistema hoy en da se usa ampliamente en combinacin con otros sistemas, confiar el control de calidad nicamente a un proceso de pruebas manuales es bastante arriesgado y no ofrece garantas slidas de la calidad del producto que hemos producido.TECNICAS MANUALES DE COMPROB

TECNICAS AUTOMATICAS DE COMPROBACION DE SWPrueba de caja blancaLa prueba de caja blanca es un conjunto de tcnicas que tienen como objetivo validar la lgica de la aplicacin. Las pruebas se centran en verificar la estructura interna del sistema sin tener en cuenta los requisitos del mismo. Existen varios mtodos en este conjunto de tcnicas, los ms habituales son la inspeccin del cdigo de la aplicacin por parte de otros desarrolladores con el objetivo de encontrar errores en la lgica del programa, cdigo que no se utiliza (code coverage en ingls) o la estructura interna de los datos. Existen tambin aplicaciones propietarias de uso extendido que permiten automatizar todo este tipo de pruebas, como PureCoverge de Rational Software

TECNICAS AUTOMA.Prueba de caja negra.La prueba de caja negrase basa en comprobar la funcionalidad de los componentes de una aplicacin. Determinados datos de entrada a una aplicacin o componente deben producir unos resultados determinados. Este tipo de prueba est dirigida a comprobar los resultados de un componente de software no a validar como internamente ha sido estructurado. Se llama black box (caja negra) porque el proceso de pruebas asume que se desconoce la estructura interna del sistema, slo se comprueba que los datos de salida producidos por una entrada determinada son correctos.

TECNICAS AUTOMA.Imaginemos que tenemos un sistema orientado a objetos donde existe una clase de manipulacin de cadenas de texto que permite concatenar cadenas, obtener su longitud, y copiar fragmentos a otras cadenas. Podemos crear una prueba que se base en realizar varias operaciones con cadenas predeterminadas: concatenacin, medir la longitud, fragmentarlas, etc. Sabemos cul es el resultado correctode estas operaciones y podemos comprobar la salida de esta rutina. Cada vez que ejecutamos la prueba, la clase obtiene como entradas estas cadenas conocidas y comprueba que las operaciones realizadas han sido correctas.Este tipo de pruebas son muy tiles para asegurar que a medida que el software va evolucionando no se rompe la funcionalidad bsica del mismo.

Cuando trabajamos en proyectos de una cierta dimensin, necesitamos tener procedimientos que aseguren la correcta funcionalidad de los diferentes componentes del software, y muy especialmente, de los que forman la base de nuestro sistema. La tcnica de las unidades de comprobacin, pruebas de unidad en ingls, se basa en la comprobacin sistemtica de clases o rutinas de un programa utilizando unos datos de entrada y comprobando que los resultados generados son los esperados. Hoy en da, las unidades de comprobacin son la tcnica caja megra es la ms extendida.UNIDADES DE COMPROBACION

UNIDADES DE COMPROBACION Una unidad de prueba bien diseada debe cumplir los siguientes requisitos: Debe ejecutarse sin atencin del usuario (desatendida). Una unidad de pruebas debe poder ser ejecutada sin ninguna intervencin del usuario: ni en la introduccin de los datos ni en la comprobacin de los resultados que tiene como objetivo determinar si la prueba se ha ejecutado correctamente. Debe ser universal. Una unidad de pruebas no puede asumir configuraciones particulares o basar la comprobacin de resultados en datos que pueden variar de una configuracin a otra. Debe ser posible ejecutar la prueba en cualquier sistema que tenga el software que es objeto de la prueba.

UNIDADES DE COMPROBACION Debe ser atmica. Una unidad de prueba debe ser atmica y tener como objetivo comprobar la funcionalidad concreta de un componente, rutina o clase.Dos de los entornos de comprobacin ms populares en entornos de software libre con JUnit y NUnit. Ambos entornos proporcionan la infraestructura necesaria para poder integrar las unidades de comprobacin como parte de nuestro proceso de pruebas. JUnit est pensado para aplicaciones desarrolladas en entorno Java y Nunit para aplicaciones desarrolladas en entorno .Net. Es habitual el uso del trmino xUnit para referirse al sistema de comprobacin independientemente del lenguaje o entorno que utilizamos.

UNIDADES DE COMPROBACION El siguiente ejemplo es un fragmento de la unidad de comprobacin de la clase StringFormat del namespace System.Drawing del proyecto Mono que son ejecutados con el sistema Nunit de comprobacin de unidades.namespace MonoTests.System.Drawing{[TestFixture]public class StringFormatTest{[Test]public void TestClone(){ StringFormat smf = new StringFormat(); StringFormat smfclone = (StringFormat) smf.Clone(); Assert.AreEqual (smf.LineAlignment, smfclone. LineAlignment); Assert.AreEqual (smf.FormatFlags, smfclone.FormatFlags); Assert.AreEqual (smf.LineAlignment, smfclone. Assert.AreEqual (smf.Alignment, smfclone. Alignment); Assert.AreEqual (smf.Trimming, smfclone.Trimming); }}Fragmento de la unidad de comprobacin de la clase StringFormat del proyecto Mono

UNIDADES DE COMPROBACION El mtodo TestClone tiene como objetivo comprobar la funcionalidad del mtodo Clone de la clase StringFormat. Este mtodo realiza una copia exacta del objeto. Las pruebas se basan en asegurar que las propiedades del objeto han sido copiadas correctamente.

SISTEMA DE CONTROL DE ERRORESLos sistemas de control de errores son herramientas colaborativas muy dinmicas que proveen el soporte necesario para consolidar una pieza clave en la gestin del control de calidad: el almacenamiento, seguimiento y clasificacin de los errores de una aplicacin de forma centralizada. El uso de estos sistemas en la mayora de proyectos se extiende tambin a la gestin de mejoras solicitadas por el usuario e ideas para nuevas versiones, e incluso, algunos usuarios los utiliza para tener un control de las llamadas de un soporte tcnico, pedidos, o los utilizan como gestores de tareas que hay que realizar.

REPORTES DE ERRORCuando un usuario encuentra un error, una buena forma de garantizar que ser buen candidato a ser corregido es escribir un informe de error lo ms preciso y detallado posible.Independientemente de cul sea el sistema de control de errores que utilicemos, los siguientes consejos reflejan las buenas prcticas en el reporte de errores:

REPORTES DE ERROR Comprobar que el error no ha sido reportado anteriormente. Suele ocurrir con frecuencia que errores que los usuarios encuentran a menudo son reportados en ms de una ocasin. Esto causa que el nmero de errores totales pendientes de corregir vaya aumentando y que el nmero total de errores registrados no refleje la realidad. Este tipo de errores se llaman duplicados y suelen ser eliminados tan pronto como son detectados. Antes de reportar un nuevo error, es importante hacer una bsqueda en el sistema de control de errores para comprobar que no ha sido reportado anteriormente.

REPORTES DE ERROR Dar un buen ttulo al informe de error. El ttulo del informe de error debe ser muy descriptivo, ya que esto ayudar a los desarrolladores a poder valorar el error cuando hagan listados de los mismos, y adems, ayudar a otros usuarios a encontrar errores ya reportados y evitar reportar posibles duplicados.Por ejemplo, un ttulo del tipo El programa se cuelga sera un ejemplo de un mal ttulo para describir un error por ser muy poco descriptivo. Sin embargo, El programa se cuelga en la previa visualizacin de imgenes es mucho ms preciso y descriptivo.

REPORTES DE ERROR Dar una descripcin detallada y paso a paso de cmo reproducir el error. Es importarte que el error sea determinista y que podamos dar una gua paso a paso de cmo reproducirlo para que la persona que debe corregirlo pueda hacerlo fcilmente. Siempre debemos tener presente que la claridad en la descripcin del error facilita el trabajo de todos los involucrados en el proceso. Dar la mxima informacin sobre nuestra configuracin y sus particularidades. La mayora de sistemas de reporte de error disponen de campos que permiten especificar nuestra configuracin (tipo de ordenador, sistema operativo, etc.). Debemos dar la mxima informacin sobre las particularidades de nuestra configuracin, ya que estos dos datos a menudo son imprescindibles para solucionar un error.

Reportar un nico error por informe. Cada informe de error que efectuemos debe contener la descripcin de un nico error. Esto facilita que el error pueda ser tratado como una unidad por el equipo de desarrollo. Muy a menudo diferentes mdulos de un programa estn bajo la responsabilidad de diferentes desarrolladores.Siguiendo todos estos consejos se mejora la claridad de nuestros informes de error y nos ayuda a alcanzar el objetivo final de cualquier reporte de error, que es conseguir que ste pueda ser solucionado con la mayor rapidez y el menor coste posible.REPORTES DE ERROR

ANATOMIA DE UN INFORME DE ERRORCualquiera que sea el sistema de control de errores que usemos, todos los sistemas detallan el error con una serie de campos que permiten definirlo y clasificarlo de forma precisa. A continuacin describimos los principales campos que forman parte de un informe de error: Identificador. Cdigo nico que identifica el informe de error de forma inequvoca y que asigna el sistema de forma automtica. Normalmente, los identificadores suelen ser numricos, permitindonos referirnos al error por su nmero, como por ejemplo el error 3210. Ttulo. Frase de aproximadamente unos 50 caracteres que describe el error de forma sinttica y le da un ttulo.

ANATOMIA DE UN INFORME DE ERROR Informador. Persona que enva el informe de error. Normalmente, un usuario registrado en el sistema de control de errores. Fecha de entrada. Fecha en la que el error fue registrado en el sistema de control de errores. Estado. Situacin en la que se encuentra el error. En el apartado de ciclo de vida de un error, veremos los diferentes estados por los cuales puede pasar un error. Gravedad. Indica la gravedad del error dentro del proyecto. Existen diferentes categoras definidas que abarcan desde un error trivial a un error que puede ser considerado grave.

ANATOMIA DE UN INFORME DE ERROR Palabras clave. Conjunto de palabras clave que podemos usar para definir el error. Por ejemplo, podemos usar crash para indicar que es un error que tiene como consecuencia que el programa se cuelgue. Esto es muy til porque luego permite a los desarrolladores hacer listados o bsquedas por estas palabras clave. Entorno. Normalmente existen uno o ms campos que permiten definir el entorno y configuracin del usuario donde se produce el error. Algunos sistemas, como Bugzilla, tienen campos que permiten especificar la informacin por separado, como por ejemplo: sistema operativo, arquitectura del sistema, etc.

ANATOMIA DE UN INFORME DE ERROR Descripcin. Una descripcin del error y cmo reproducirlo. Algunos sistemas permiten que diferentes usuarios puedan ir ampliando la informacin del error a medida que el ciclo de vida del error avanza con detalles relacionados con su posible solucin, su implicacin para otros errores, o simplemente para concluir que el error ha sido solucionado.stos son los campos que podemos considerar los mnimos comunes a todos los sistemas de control de errores. Cada sistema aade campos adicionales propios para ampliar esta informacin bsica o permitir realizar funciones avanzadas propias.

CICLO DE VIDA DE UN ERROREl ciclo de vida de un error comienza cuando es reportado y finaliza cuando el error se soluciona. Entre estos extremos del ciclo de vida existen una serie de estados por los cuales va pasando el error.Aunque no hay un estndar definido entre los diferentes sistemas de control de errores, utilizaremos la terminologa que utiliza el sistema Bugzilla, ya que es el ms extendido dentro del mundo del software.stos son los principales estados en los que se puede encontrar un error durante su ciclo de vida con Bugzilla: Sin confirmar. Se produce cuando el informe de error ha sido introducido en el sistema. Es el estado inicial por el que pasa cualquier error.

CICLO DE VIDA DE UN ERROR Nuevo. El error estaba en estado Sin Confirmar y se ha comprobado su validez y ha pasado al estado Nuevo, que representa que ha sido aceptado formalmente como error. Asignado. El error ha sido asignado a un desarrollador para que lo solucione. Ahora debemos esperar a que el desarrollador tenga tiempo para poder evaluar el error y solucionarlo. Corregido. El error ha sido corregido y debera estar solucionado. Cerrado. El error ha sido corregido y ha confirmado la solucin como correcta. ste es el fin de ciclo de vida del error.

CICLO DE VIDA DE UN ERROR Invlido. El error no era un error vlido o simplemente no era un error. Por ejemplo, cuando se describe una funcionalidad que es correcta.A continuacin vamos a ver un esquema que ilustra los principales estados, Bugzilla y otros sistemas disponen de estados adicionales en los que puede estar un error durante su ciclo de vida.

CICLO DE VIDA DE UN ERROR

CICLO DE VIDA DE UN ERRORPodemos observar que cuando un error entra en el sistema queda clasificado como Sin Confirmar. Una vez es revisado, puede descartarse como error y marcarse como Invlido para luego Cerrar el error. Si el error es aceptado como Nuevo, el siguiente paso es asignarlo a un desarrollador, que es un usuario en el sistema de control de errores. Una vez est asignado, el error es corregido, y una vez verificado, es cerrado.

Un aspecto central en cualquier proyecto de software es la gestin y el seguimiento de los errores. Cuando Netscape en 1998 liber el cdigo de Mozilla, se encontr con la necesidad de tener una aplicacin de gestin de errores va web que permitiera la interaccin entre usuarios y desarrolladores. Decidieron adaptar la aplicacin que usaban internamente en Netscape a las necesidades de un proyecto abierto y as naci Bugzilla. Inicialmente, fue el sistema de gestin y seguimientode errores del proyecto Mozilla, pero con el tiempo ha sido adoptado por muchos proyectos libres, incluyendo KDE y GNOME, entre otros. Bugzilla permite a los usuarios enviar errores facilitando la clasificacin del error, su asignacin a un desarrollador para que lo resuelva y todo el seguimiento de las incidencias relacionadas.Entre las caractersticas que provee Bugzilla, destacan las siguientes:BUGZILLA MANEJADOR DE ERRORES

BUGZILLA MANEJADOR DE ERRORES Interfaz web . Una completa interfaz web que permite que cualquier persona con un simple navegador pueda enviarnos un error o administrar el sistema. Entorno colaborativo. Cada reporte de error se convierte en un hilo de discusin donde usuarios, probadores y desarrolladores pueden discutir sobre las implicaciones de un error, su posible origen o cmo corregirlo. Notificacin por correo. Bugzilla permite notificar por correo a los usuarios de diferentes eventos, como por ejemplo informar a los usuarios involucrados en un error concreto de cambios en el mismo.

BUGZILLA MANEJADOR DE ERRORES Sistema de bsquedas. El sistema de bsquedas es muy completo, permitindonos buscar errores por su tipo, por quin inform de ellos, por la prioridad que tienen o por la plataforma en que han surgido. Informes. Tiene integrado un completo sistema que permite generar informes sobre el estado de los errores del proyecto. Votaciones. Bugzilla permite la votacin de los errores pudindose as establecer prioridades para su resolucin basndose en los votos que han recibido de usuarios. Seguro. Contempla registro de usuarios, diferentes niveles de seguridad y una arquitectura diseada para preservar la privacidad de sus usuarios.

BUGZILLA MANEJADOR DE ERRORES

Gnats (GNU problem report management system) es la herramienta de gestin de errores para entornos Unix desarrollada por la Free Software Foundation a principios de los aos noventa. Es ms antigua que Bugzilla. Gnats es usado por proyectos como FreeBSD o Apache, y lgicamente, por los proyectos impulsados por la propia Free Software Foundation.El ncleo de Gnats es un conjunto de herramientas de lnea de comandos que exponen toda la funcionalidad del sistema. Tiene todas las ventajas y flexibilidad de las herramientas GNU, pero su uso puede resultar difcil a los que no estn familiarizados con este tipo de herramientas. Existe tambin una interfaz web que fue desarrollada posteriormente y es el front-end ms usado hoy en da.GNATS SISTEMA MANEJADOR DE REPORTE DE ERRORES

GNATS SISTEMA MANEJADOR DE REPORTE DE ERRORES

CONCLUSIONESDurante este captulo hemos constatado la necesidad de integrar los procesos de control de calidad y pruebas dentro del ciclo de desarrollo de un programa desde el inicio del mismo. Hemos visto los principios que rigen la comprobacin del software, la escritura de un buen informe de error y de una unidad de comprobacin.Tambin hemos conseguido una visin prctica de los sistemas de control de calidad y pruebas en el caso particular, tanto de prcticas como de aplicaciones del software libre y hemos visto cules son los principales principios, tcnicas y aplicaciones que se utilizan para garantizar la calidad de los productos de Software y software libres.

GARANTIA DE CALIDAD DE SOFTWARELa garanta de calidad de SW (SQA, GCS) es una actividad de proteccin que aplica a lo largo de todo el proceso de SW.Antes del siglo XX, SQA era responsabilidad nica de la persona que construa el producto. La primera funcin de control de calidad y de garanta de calidad formal fue introducida por los laboratorios Bell en 1916 y se extendi rpidamente por todo el mundo de las manufacturas. Hoy en da, cada compaa tiene un mecanismo que asegura la calidad de sus productos de hecho, durante le dcada pasada, se han usado ampliamente como tcticas de mercado la declaracin explicita de mensajes que ponan de manifiesto la calidad ofrecida por las compaas.La historia de SQA en el desarrollo de SW ha sido paralela a la historia de de la fabricacin del hardware. Aunque en un inicio la responsabilidad recay en el programador.

GARANTIA DE CALIDAD DE SOFTWAREDurante la dcada de los 70s se introdujeron estndares para SQA en los contratos militares de desarrollo de software y se han extendido rpidamente en los desarrollos de SW comerciales.La SQA forma parte de una funcin ms amplia de calidad y engloba las siguientes actividades:Un enfoque de gestin de calidad.Mtodos y herramientas.Revisiones tcnicas formales,Documentacin.La calidad de SW es importante porque:Se reduce la repeticin de actividades o tareas .Supone costos ms bajos de desarrollo.Se mejora el proceso de SW y por ende el producto.

CONCEPTOS DE CALIDADCalidad segn ISO-9000 es un conjunto de caractersticas de una entidad que le confieren su actitud para satisfacer las necesidades expresadas y las implcitas. Segn Pressman es una caracterstica o atributo de algo.Otras definiciones plantean:Es la medida en que las propiedades de un bien o servicio cumplen con los requisitos establecidos en la norma o especificaciones tcnicas, as como las exigencias del usuario de dicho bien o servicio.Aquellas caractersticas del producto que responden a las necesidades del cliente.El significado histrico de la palabra calidad es el de aptitud o adecuacin al uso.La asociacin americana para control de calidad (ASQC), ls define como un conjunto de caractersticas de un producto proceso o servicio que satisface las necesidades del usuario o cliente.

GARANTIA DE CALIDAD DE SOFTWARE

A nivel general podemos tener las siguientes definiciones:El control de calidad comprende aquellas actividades realizadas en una empresa u organizacin para aplicar los principios de calidad en las actividades relazadas por la empresa.Es la actividad por la cual una empresa determina si el producto o servicio cumple o no con las especificaciones del mismo.El control de calidad se ocupa de garantizar el logro de los objetivos de calidad del trabajo respecto a realizacin del nivel de calidad previsto para la produccin y sobre la reduccin de costos de la calidad.

COSTOS DE CALIDADSon los costos acarreados en la busca de la calidad o en las actividades relacionadas con la obtencin de la calidad, se dividen en:

TENDENCIA DE LA CALIDADExisten infinidad de estndares o modelos que tienen tendencia a eliminar los errores que se producen. El modelo Kaizen se refiere al sistema de mejora continua en el proceso cuyo objetivo es llegar a la Gestin de Calidad Total (GTC), se basa en las cinco S.SEIRE Organizacin: cada cosa en su lugar y un lugar para cada cosa.SEITON Reducir bsquedas: Facilitar el movimiento de las cosas, servicios y personas.SEISO Limpieza: Cuando todo esta limpio, todo esta ordenado, se simplifican los procedimientos.SEIKETSU Estandarizacin y simplificacin de procesos: Mantener el orden, organizacin y limpieza en el ambiente y las personas.SHITZUKE Disciplina y buenos hbitos de trabajo: Basados en el respeto a las reglas y a las personas (compaeros y clientes)

GARANTIA DE CALIDAD DE SOFTWARE (SQA)La calidad de SW es el grado con el que un sistema, competente o proceso cumple con los requerimientos especificaciones y necesidades o expectativas del cliente o usuario. (IEEE, Std. 610-1990).Concordancia en los requerimientos funcionales y de rendimiento explcitamente establecidos, con los estndares de desarrollo explcitamente documentados, y con las caractersticas implcitas que se espera de todo SW desarrollado profesionalmente, (Pressman 2002).La garanta de calidad de SW SQA comprende un conjunto de tareas y acciones sistemticas y planificadas que permiten asegurar la calidad del SW.

GARANTIA DE CALIDAD DE SOFTWARE (SQA)A este conjunto de tareas y acciones se le denomina actividades de SQA y comprende:Plan SQA para el proyecto.- El plan debe involucrar: Evaluaciones, auditorias, revisiones, estndares que se pueden aplicar al proyecto. Procesamiento de informacin, seguimiento de errores y retroalimentacin. El grupo de SQA debe adems documentar la informacin necesaria.Proceso de SW del proyecto.- Se determina el proceso y se realiza la revisin de la descripcin del proceso para poder establecer los ajustes de acuerdo a las polticas de la organizacin.Ajustes al proceso de SW.- el grupo SQA se encarga de revisar, documentar y verificar que se han hecho los ajustes al proceso.

GARANTIA DE CALIDAD DE SOFTWARE (SQA)Auditora de productos de SW.- El grupo SQA est en constante revisin del proceso de SW e informa peridicamente los resultados al gestor del proyecto.Documentacin de productos de SW.- Se debe de documentar todas las desviaciones encontradas a nivel: De procesos, De estndares y Tcnicos.Requisitos de ajustes a requisitos e informes.- Se realiza un seguimiento a los requisitos que no se ajustan y se elaboran los informes respectivos.El grupo SQA, adems de tener a cargo el plan SQA tambin debe coordinar, controlar y gestionar los cambios, recopilar y analizar las mtricas del SW.

REVISIONES DEL SOFTWARELas revisiones del SW, son el conjunto de actividades que suceden como resultado del anlisis, el diseo y la codificacin y que sirven para depurar las actividades de ingeniera de SW. Una revisin tiene como objetivos:Sealar las mejoras al producto.Continuar las partes de un producto en las que no es necesaria o no es deseable una mejora.Conseguir un trabajo tcnico en una calidad ms uniforme, o al menos ms predecible, que la que pueda ser conseguida sin revisiones, con el fin e hacer mas manejable el trabajo tcnico.Las revisiones de SW se usan como modelo para la amplificacin de defectos y para ilustrar la generacin y deteccin de errores durante los pasos de diseo preliminar, diseo detallado y codificacin del proceso de ingeniera de SW.

En cada paso del proceso de desarrollo de SW, se presentan errores que pasan inadvertidos y que producen un mayor numero de errores si las revisiones no lo detectan.Los errores amplificados corresponden, a aquellos que pasan inadvertidos desde pasos anteriores. De igual forma se representa el porcentaje de eficiencia de la deteccin de errores.REVISIONES DEL SOFTWARE

REVISIONES TECNICAS FORMALES (RTF)Las RTF son un medio efectivo para mejorar la calidad del SW. Los objetivos de las RTF son: Descubrir errores en la funcin, le lgica o la implementacin de cualquier representacin de SW.Verificar que el SW bajo revisin alcanza sus requisitos.Garantizar que el SW ha sido representado de acuerdo a ciertos estndares predefinidos.Conseguir un SW desarrollado de forma uniforme.Hacer que los proyectos sean manejables.Las RTF incluyen: Recorridos, inspecciones, revisiones cclicas, evaluaciones tcnicas de SW.Cada RTF debe ser debidamente planificada, controlada y atendida por el grupo encargado de cada RTF.Cada reunin debe tener las siguientes caractersticas: Deben convocarse para revisin entre 3 y 5 personas, se debe preparar por adelantado, la duracin de una revision no debe ser menor a dos horas.

REVISIONES TECNICAS FORMALES (RTF)Quines participan en la reunin: El jefe de revisin quien lidera la reunin, los revisares uno de los cuales se encarga de registrar todos los sucesos de la reunin, el productor.Registro e informe de la revisin. Como se menciono anteriormente, uno de los revisores es el encargado de registrar todos los acontecimientos y sugerencias que van surgiendo durante la RTF. Al final dela reunin, hace un resumen de las conclusiones y genera una lista de sucesos de revisin. Adems prepara un informe sumario de la RTF que responda a las siguientes preguntas: Qu fue revisado? Quin lo revis? Qu se descubri y cuales son las conclusiones?La lista de suceso de revisin que se genera permite: Identificar rea de problemas dentro del producto, servir como lista de comprobacin para hacer las correcciones.

REVISIONES TECNICAS FORMALES (RTF)Adems se adjunta, la lista de conclusiones al informe sumario.Directivas para la revisin.Revisar el producto no al productor. Se deben sealar los errores y no dificultar el proceso de revisin. Es importante mantener el control de la reunin y descartar situaciones que se salgan de control.Fijar una agenda y mantenerla. Se debe de tener un lan de trabajo antes de la reunin. Se debe de seguir el orden del plan para que la reunin tenga xito y cumplir con los tiempos asignados al plan.Limitar el debate y las impugnaciones. No se debe perder tiempo debatiendo situaciones que no presenten unanimidad, es importante registrar el hecho y dedicar otros tiempos para su debate.

REVISIONES TECNICAS FORMALES (RTF)4. Enunciar areas problemas pero no intentar resolver los problemas que se pongan de manifiesto. La resolucin de problemas se debe programar para otros espacios despus de la reunin de revisin.5. Tomar notas escritas. Es buena idea utilizar diferentes herramientas para toma de notas, por ejemplo, pizarras, tableros, computador para que se pueda hacer seguimiento a la asignacin de prioridades.6. Limitar el nmero de participantes e insistir en la preparacin anticipada. Se debe limitar el nmero de revisores, los cuales deben estar preparados para cada reunin y participar activamente en los procesos de revisin.7. Desarrollar una lista de comprobacin para cada producto que haya de ser revisado. Se deben desarrollar listas de comprobacin para los documentos de anlisis, diseo, codificacin y pruebas.

REVISIONES TECNICAS FORMALES (RTF)8. Disponer recursos y una agenda para las RTF. Cada RTF debe ser planificada e involucrar modificaciones.9. Capacitacin y entrenamiento de los revisores. Todas las personas que participan en el proceso de revisin deben de recibir un entrenamiento que se debe basar en:El proceso.Sicologa Humana.10. Revisar las revisiones anteriores. Son beneficiosas porque permiten descubrir problemas del proceso de revisin.

ESTADISTICA GARANTIA DE LA CALIDADLa garanta de calidad estadstica, permite establecer la calidad mas cuantitativamente. Para el SW existen los siguientes casos:Agrupar y clasificar la informacin sobre los defectos de SW.Encontrar la causa de cada defecto.Mediante graficas de Paretto se asla el 20% de las causas.Una vez que se han identificado los defectos vitales, se acta para corregir los problemas que han producido los defectos.

FIABILIDAD DEL SWLa fiabilidad del SW, de que en un tiempo y entorno determinado el SW en operacin este libre de fallos. Los fallos de SW, se producen por problemas de diseo o de implementacin, y esta est dada por:TMEF = TMDF + TMDRTMEF Tiempo medio entre fallos.TMDF Tiempo medio de fallo.TMDR Tiempo medio de reparacin.Estos datos deben de ser medidos o estimados por medio de datos histricos o de desarrollo.

ESTNDAR DE CALIDAD ISO 9001El ISO se estableci en 1947, y su misin fue promover l desarrollo de la organizacin y de las actividades relacionadas en el mundo, con la idea de facilitar el cambio de bienes y servicios a nivel internacional. Algunas normas del ISO especifican requisitos para sistemas de calidad (ISO 9001, 9002 9003), y otras dan una gua para ayudar en la interpretacin e implementacin del sistema de calidad )ISO 9000-2, ISO 9004-1. Para la industria de SW los estndares relevantes son:ISO 9004-2 Este documento proporciona las directrices para el servicio del SW como soporte a de o usuarios.La satisfaccin de expectativas de los clientes, as como el logro y mantenimiento de la calidad deseado por los mismos, son metas deseables para cualquier organizacin, y son mas palpables cuando la organizacin se dedica a la prestacin de servicios.

ESTANDARES DE CALIDADISO 9003. este es el documento especifico que interpreta el ISO 0991 oara el desarrollador de SW.

ESTANDARES DE CALIDAD