REPUBLICA BOLIVARIANA DE VENEZUELA UNIVERSIDAD BICENTENARIA DE ARAGUA FACULTAD DE INGENIERIA ESCUELA DE SISTEMAS CATEDRA SOFTWARE LIBRE

CALIDAD DEL SOFTWARE LIBRE

Ing. Alejandra Reyes Integrantes: Parada, Betty Cruz, Erick Ojeda, Alberto Di Rosa, Salvador Len, Ramn

SAN JOAQUIN DE TURMERO, ENERO DE 2013

INTRODUCCION La obtencin de un software con calidad implica la utilizacin de metodologas o procedimientos estndares para el anlisis, diseo, programacin y pruebas del software que permitan uniformar la filosofa de trabajo, en reas de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software. Los requisitos del software son la base de las medidas de calidad. La falta de concordancia con los requisitos es una falta de calidad.

Los estndares o metodologas definen un conjunto de criterios de desarrollo que guan la forma en que se aplica la ingeniera del software. Si no se sigue ninguna metodologa siempre habr falta de calidad.

La poltica establecida debe estar sustentada sobre tres principios bsicos: tecnolgico, administrativo y ergonmico. El principio tecnolgico define las tcnicas a utilizar en el proceso de desarrollo del software. El principio administrativo contempla las funciones de planificacin y control del desarrollo del software, as como la organizacin del ambiente o centro de ingeniera de software. El principio ergonmico define la interfaz entre el usuario y el ambiente automatizado. La adopcin de una buena poltica contribuye en gran medida a lograr la calidad del software, pero no la asegura. Para el aseguramiento de la calidad es necesario su control o evaluacin. A partir del siguiente grfico se observa la interrelacin existente entre la Gestin de la Calidad, el Aseguramiento de la Calidad y el Control de la Calidad. 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.

Cualquier 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. Los proyectos que no integran un control de calidad como parte de su ciclo de desarrollo a la larga tienen un coste 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. 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.

1.- Que es un modelo de calidad de software Es un conjunto de buenas prcticas para el ciclo de vida del software, enfocado en los procesos de gestin y desarrollo de proyectos. Los modelos de calidad te dicen que hacer no como hacerlo. Depende las metodologas que uses. Depende de tus objetivos de negocio. 2.- Cuantos modelos existen: CMMI v. 1.2: Orientado a mejora de procesos en diferentes niveles de madurez, mas hacia proyectos especficos. Problemtica CMMI Requiere mucho esfuerzo, compromiso de toda la organizacin. Comenzar a disear y/o documentar procesos, luego desplegarlos y ponerlos en prctica. Requiere un mnimo de cantidad de personal (no menos de 10 personas en la prctica). Fuerte inversin econmica. Soluciones CMMI Compromiso asegurado. Automatizar los mas posible las actividades de control y gestin de los procesos de los proyectos. Comenzar a documentar los procesos implcitos, en la medida de lo posible 0 plantillas en *office, implementacin de sistemas de gestin. Utilizacin de sistemas libres para minimizar los costos de implementacin de CMMI. Primeras Medidas CMMI Clientes requiriendo implementacin de sistemas de calidad (ISO 12207 y CMMI), dejar extremme Programming por Metrica3. Comenzar a dejar las primeras evidencias para una auditoria. Cumplir en la prctica con al menos Nivel 2 de CMMI.

CMMI Nivel 2 reas de Procesos: Gestin de Requisitos. Planificacin de proyectos. Monitorizacin y Control de proyectos. Medicin y Anlisis. Aseguramiento de la calidad. Gestin de la configuracin. Gestin de Requisitos: Gestionar los requerimientos tcnicos y no tcnicos pactados en un contrato, estndar o especificacin formalmente documentado. (Los usuarios necesitan el software, conversa con ellos primero, consulta a los especialistas. El software no solo necesita funcionalidad sino usabilidad.) Planificacin de Proyectos: Estimar razonablemente el uso de recursos y tiempo para la realizacin de un proyecto, debe actualizarse conforme se avance el proyecto y deber tomar en cuenta escenarios a favor como en contra. (Dejar de lado la frase de el software esta cuando software esta cuando esta hay que estimar realistamente y tomar en cuenta que una donacin de tiempo de trabajo tiene un costo por lo tanto no hay que desperdiciarlo.) Monitorizacin y control de Proyectos: Basados en el plan del proyecto debemos monitorear las acciones a llevarse a cabo, as como aplicar medidas correctivas de ser necesario, tomar en cuenta que estas impactarn en nuestro Plan de Proyecto. (El compromiso del equipo de desarrollo debe ser real, deben trazarse metas bien definidas). Medicin y Anlisis: Copiar datos y seleccionar indicadores que permitan medir la evolucin de los procesos crticos del proyecto, comparar los real vs los planificados. (Hay que valorizar el trabajo de la gente, buscar maneras de donde reducir donde estn los mayores costos, solo con mtricas podemos determinar donde mejorar). Aseguramiento de la Calidad: Conjunto de actividades planificadas y constantes requeridas para asegurar que el software cumplir con ciertos criterios esperados de calidad, debe planificarse desde antes de desarrollar el software nunca despus o en el camino. (Hay que formalizar los procesos de calidad, documentar las pruebas de caja blanca y negra).

Gestin de la Configuracin: Administracin y control de los tems que conforman nuestro proyecto, es el proceso mas largo y solo culmina cuando el software es retirado de circulacin, requiere una organizacin impecable de los componentes en desarrollo. (Acompaar el software de toda la documentacin necesaria para seguir su evolucin, cambios, mejoras, etc.) Norma ISO/IEC 12007: Orientado al proceso del ciclo de vida del software. Metrica3: Modelo e Implementacin. Documentacin: En el mundo del software libre, apenas se usan procesadores de texto WYSIWYG y otras herramientas ofimticas que tanto xito tienen en otros entornos, a pesar de haber ya herramientas libres, como Open Office. Ello es debido a varios factores importantes:

Es conveniente mantener la documentacin bajo control de fuentes, y los sistemas de control de fuentes, como CVS, aunque admiten formatos binarios, prefieren formatos textuales transparentes, editables con un editor de texto normal y procesables con herramientas desarrolladas para programas, que nos permitan ver fcilmente las diferencias entre versiones, generar y aplicar parches basados en esas diferencias, y realizar operaciones de mezcla. Ciertas licencias de documentacin libre, especialmente la GFDL (Licencia de documentacin libre de GNU), exigen formatos transparentes, sobretodo por facilitar el trabajo a los que realicen documentos derivados. Las herramientas WYSIWYG (what you see is what you get) generalmente no contienen ms informacin que la estricta de visualizacin, haciendo muy difcil, si no imposible, el procesamiento automtico, como identificar autores o ttulo, y la conversin a otros formatos. Incluso aunque permitan conversin de formatos, sta suele hacerse de forma interactiva, siendo muchas veces imposible automatizarla (con make, por ejemplo).

Generalmente las herramientas ofimticas generan unos formatos de ficheros muy voluminosos, asunto muy desagradable para los desarrolladores o los repositorios.

Por todo ello el programador libre, acostumbrado tambin a programar y compilar, prefiere formatos de documentacin transparentes, en muchos casos simple texto puro, en muchos otros formatos de documentacin procesables. Los formatos procesables utilizados no son muchos. Tradicionalmente en el mundo Unix los programas se han documentado en los formatos esperados por la familia de procesadores roff, con versin libre [groff] de Norman Walsh. No obstante esta prctica se ha ido abandonando, excepto para las pginas de manual tradicionales, ya que es casi obligado preparar pginas de manual para las herramientas ms bsicas del sistema. Debido a que muchas pginas de manual han crecido excesivamente, de modo que difcilmente se les puede llamar pginas, fue necesario elaborar un formato alternativo hiper-textual, que permitiera seguir documentos estructurados con ndices y referencias cruzadas. El proyecto GNU dise el formato texinfo [texinfo] y lo convirti en su estndar. Este formato permite obtener documentos navegables con la herramienta info o dentro del editor emacs, y a su vez obtener documentos impresos de calidad con ayuda del procesador de textos TeX, de Donald Knuth [knuth:tex]. El formato texinfo puede traducirse a HTML multipgina si se desea, y mucha gente prefiere ver la informacin con un navegador Web, pero se pierde la capacidad de bsqueda de palabras en un documento. Esta es una de las consecuencias indeseables de la popularidad de HTML, ya que los navegadores no implementan el concepto de documento multipgina, a pesar de que existen elementos link que permiten enlazar las partes. Existe una imperiosa demanda de que los documentos complejos se puedan ver como pginas Web multipgina fcilmente navegables. Hay gente que escribe documentacin en LaTeX[lamport:latex], tambin aplicacin de TeX, muy popular entre los cientficos, ms expresivo que Texinfo, y convertible a HTML multipgina con ciertas herramientas[goosens:texweb], siempre que se guarde cierta disciplina. En efecto, las aplicaciones de TeX son conjuntos de macros que combinan operadores tipogrficos de muy bajo nivel para convertirlos en lenguajes abstractos que trabajan con conceptos de alto nivel (autor, ttulo, resumen, captulo, apartado, etc.). Si slo se utilizan las macros bsicas, la conversin es sencilla. Pero como nadie impide usar operadores de bajo nivel y, adems, existen cantidades enormes de paquetes de macros fuera de la capacidad de mantenimiento de los mantenedores de los conversores, es difcil conseguir que las conversiones salgan bien.

Docbook El problema radica en que no existe separacin entre contenido y presentacin, ni en las aplicaciones de TeX ni en las de nroff, ya que la abstraccin se construye por capas. Esta separacin la tienen las aplicaciones de SGML[sgml] y XML[XML], donde la presentacin se especifica con hojas de estilo completamente separadas. Muy pronto empezaron a

utilizarse aplicaciones muy sencillas de SGML, como linuxdoc y debiandoc, pero debido a su escasa capacidad expresiva, se opt por ir a DocBook[walsh:docbook]. DocBook es una aplicacin de SGML originalmente desarrollada para documentacin tcnica informtica, y hoy con una variante XML. DocBook es hoy el estndar de formato de documentacin libre para muchos proyectos (Linux Documentation Project, KDE, GNOME, Mandriva Linux, etc.) y un objetivo a alcanzar en otros (Linux, *BSD, Debian, etc). Sin embargo DocBook es un lenguaje complejo, plagado de etiquetas, por lo que es conveniente disponer de herramientas de ayudas a la edicin, an escasas y elementales, siendo la ms popular el modo psgml de emacs. Tambin es pesado de procesar y los procesadores libres an generan una calidad de documentos poco atractiva Wikis Mucha gente encuentra demasiado complicado escribir documentacin con lenguajes tan complejos como DocBook y mecanismos de colaboracin como CVS. Por ello se ha hecho muy popular un nuevo mecanismo de colaboracin para la elaboracin de documentos en lnea va web llamado Wiki, inventado por Ward Cunningham[ward:wiki], puesto por primera vez en servicio en 1995, y hoy ampliamente utilizado en muy diversas variantes para elaborar documentos muy dinmicos, no destinados a ser impresos, y muchas veces con una vida corta (por ejemplo, organizacin de una conferencia). Al contrario que DocBook, un Wiki tiene un lenguaje de marcas muy simple y conciso, que recuerda la presentacin final, sin ser exactamente como ella. Por ejemplo, los prrafos se separan por una lnea en blanco, los elementos de listas empiezan por un guin si no se numeran y por un cero si se numeran, o las celdas de tablas se separan por barras verticales y horizontales. Tampoco existe el concepto de documento completo, sino que un Wiki es ms bien un conjunto de pequeos documentos enlazados que se van creando a medida que es necesario explicar un nuevo concepto o tema. La creacin de los documentos es casi automtica, ya que la herramienta de edicin muestra muy claramente que hemos introducido un concepto (a travs de un NombreWiki, casi siempre dos palabras juntas con la primera letra en maysculas). Casi ningn Wiki admite hiperenlaces dentro de la misma pgina. Al contrario que en CVS, cualquiera puede escribir en un Wiki, aunque se aconseja que se identifique el autor con un registro previo. Cuando se visita un Wiki veremos que todas las pginas tienen un botn para permitir su edicin. Si se pulsa, el navegador nos mostrar en un formulario la fuente del documento, que podremos cambiar. No es una edicin WYSIWYG, lo que disuade al que quiera fastidiar, pero es tan sencillo que cualquier interesado puede modificar documentos con muy pequeo esfuerzo.

Los Wikis llevan su propio control de versiones de documentos, de modo que generalmente estn accesibles todas sus versiones con indicacin de quien las hizo y cuando. Tambin se pueden comparar con facilidad. Tambin suelen llevar mecanismos de bsqueda, al menos por nombre de pgina y por palabra contenida. Normalmente el autor original de una pgina querr enterarse de las modificaciones que se le hacen. Para ello puede suscribirse a los cambios, recibiendo notificaciones de los mismos por correo electrnico. A veces el que ve un documento no se atreve a cambiar nada, pero puede hacer un comentario. Normalmente toda pgina wiki tiene asociado un foro de comentarios que se pegan al final del documento y que, bien el autor original, bien alguien que asuma el rol de editor, puede emplearlos para reformar el texto original, posiblemente moviendo frases de los comentarios a los sitios oportunos. Sugerencia: La mejor forma de entender un Wiki es accediendo a uno y experimentando en una pgina destinada a ello, denominada habitualmente SandBox.

EL SOFTWARE LIBRE NECESITA DOCUMENTACIN LIBRE La mayor deficiencia en los sistemas operativos libres no se encuentra en el software, sino en la falta de buenos manuales libres que podamos incluir en esos sistemas. Muchos de nuestros programas ms importantes no vienen acompaados de manuales completos. La documentacin es una parte esencial de cualquier paquete de software; cuando un paquete de software libre relevante no est acompaado de un manual libre, se da una tremenda laguna. Hoy en da tenemos muchas de estas lagunas. rase una vez, hace muchos aos, pens voy a aprender Perl. Consegu una copia de un manual libre, pero lo encontr difcil de leer. Cuando ped a los usuarios de Perl que me dieran alternativas, me dijeron que haba mejores manuales de introduccin, pero estos no eran libres. Qu ocurra? Los autores haban escrito buenos manuales para OReilly Associates, que los edit con condiciones restrictivas no se podan copiar ni modificar, y los archivos originales no estaban disponibles, lo que los dejaba al margen de la comunidad del software libre No era la primera vez que haba pasado tal cosa y para desgracia de nuestra comunidad estaba lejos de ser la ltima. Desde entonces, los editores de manuales propietarios han incitado a muchsimos autores a hacer restrictivos sus manuales. Cuntas veces habr odo a un usuario de GNU hablarme apasionadamente sobre un manual que est escribiendo, con el que espera ayudar al proyecto GNU y despus me deja con un palmo de narices, mientras procede a explicar que ha firmado un contrato con un editor que lo limitar tanto que no podremos usarlo.

Dado que entre los programadores escribir bien en un ingls correcto es una habilidad poco habitual, difcilmente nos podremos permitir perder manuales de esta manera. La documentacin libre, como el software libre, es un asunto de libertad y no de precio. El problema con estos manuales no era que OReilly pusiera un precio por ejemplar impreso lo cual en s est bien. (La Free Software Foundation tambin vende ejemplares impresos de manuales sobre GNU). Pero los manuales de GNU estn disponibles con su cdigo fuente, mientras que estos manuales slo estn disponibles en papel. Los manuales de GNU vienen con un permiso de copia y modificacin; los manuales de Perl, no. Estas restricciones son el problema.

El criterio con los manuales libres es bastante parecido al del software libre: se trata de proporcionar ciertas libertades a todos los usuarios. La distribucin incluyendo la distribucin comercial debe ser permitida, de modo que el manual pueda acompaar a cada copia del programa, en papel o en la Red. El permiso de modificacin es tambin crucial. Como norma general, no creo que tener permiso para modificar todo tipo de artculos y libros resulte esencial para la gente. Los problemas para el texto impreso no son necesariamente los mismos que los del software. Por ejemplo, no me parece que t o yo estemos obligados a dar permiso para modificar artculos como ste, que describen nuestras prcticas y nuestros puntos de vista. Pero hay un motivo particular por el que la libertad de modificacin es crucial para la informacin que acompaa al software libre. Cuando la gente ejercita su derecho a modificar el software y aade o cambia sus caractersticas, si es concienzuda tambin cambiar su correspondiente manual de este modo pueden suministrar informacin precisa y til con el programa modificado. Un manual que impide a los programadores ser concienzudos y acabar el trabajo, o para ser ms exactos, que les obliga a escribir desde cero un nuevo manual si cambian el programa, no responde a las necesidades de nuestra comunidad. Si bien es inaceptable prohibir de pleno la modificacin, cierto tipo de lmites a los medios de modificacin no suponen ningn problema. Por ejemplo, son aceptables las exigencias de mantener la nota del copyright original del autor, las condiciones de distribucin o la lista de autores. Tampoco es un problema obligar a que en las versiones modificadas aparezca constancia de que han sido modificadas, o incluso tener secciones enteras que no pueden ser borradas o cambiadas, siempre que esas secciones traten sobre asuntos no tcnicos. (Algunos manuales de GNU las tienen).

Este tipo de restricciones no son un problema porque, en la prctica, no impiden que el programador concienzudo adapte el manual para que corresponda con el programa modificado. En otras palabras, no coartan a la comunidad del software libre en su pleno uso del manual. De todos modos, debe ser posible modificar todo el contenido tcnico del manual y luego distribuir el resultado a travs de todos los medios, a travs de todos los canales habituales; de no ser as, las restricciones coartarn a la comunidad, el manual no ser libre y por lo tanto necesitaremos otro. Por desagracia, a menudo cuesta encontrar a alguien que escriba otro manual cuando ya existe un manual propietario. El obstculo es que muchos usuarios piensan que un manual propietario resulta suficientemente aceptable y de este modo no consideran la necesidad de escribir un manual libre. No comprenden que el sistema operativo libre tiene una necesidad que se debe cubrir. Por qu piensan los usuarios que los manuales propietarios son suficientes? Algunos no se han parado a pensar en ello. Espero que este artculo ayude a cambiar esta situacin. Otros usuarios consideran aceptables los manuales propietarios por el mismo motivo que mucha gente considera aceptable el software propietario: juzgan segn trminos puramente prcticos, sin considerar la libertad como criterio. Esta gente tiene derecho de opinar as, pero dado que estas opiniones brotan de valores que no incluyen la libertad, no son una gua para los que s valoramos la libertad. Tambin podemos animar a los editores comerciales a vender manuales libres basados en copyleft en lugar de manuales propietarios. Puedes ayudar si compruebas las condiciones de distribucin de un manual antes de comprarlo y eliges los manuales copyleft frente los que no los son. LAS PRUEBAS DE SOFTWARE (EN INGLS SOFTWARE TESTING) Son las investigaciones empricas y tcnicas cuyo objetivo es proporcionar informacin objetiva e independiente sobre la calidad del producto a la parte interesada o stakeholder. Son una actividad ms en el proceso de control de calidad. Las pruebas son bsicamente un conjunto de actividades dentro del desarrollo de software. Dependiendo del tipo de pruebas, estas actividades podrn ser implementadas en cualquier momento de dicho proceso de desarrollo. OBJETIVOS El objetivo de las pruebas es presentar informacin sobre la calidad del producto a las personas responsables de este.

Teniendo esta afirmacin en mente, la informacin que puede ser requerida es de lo ms variada. Esto hace que el proceso de testing sea completamente dependiente del contexto9 en el que se desarrolla.

A pesar de lo que muchos promueven, no existen las "mejores prcticas" como tal. Toda prctica puede ser ideal para una situacin pero completamente intil o incluso perjudicial en otra. Por esto, las actividades, tcnicas, documentacin, enfoques y dems elementos que condicionarn las pruebas a realizar, deben ser seleccionadas y utilizadas de la manera ms eficiente segn contexto del proyecto. PRUEBAS ESTTICAS Son el tipo de pruebas que se realizan sin ejecutar el cdigo de la aplicacin. PRUEBAS DINMICAS Todas aquellas pruebas que para su ejecucin requieren la ejecucin de la aplicacin. TIPOS DE PRUEBAS POR SU EJECUCIN

Pruebas manuales Pruebas automticas

ENFOQUES DE PRUEBAS O APPROACHES

Scripted Testing Exploratory Testing Pruebas de Caja blanca Pruebas de Caja negra

NIVELES DE PRUEBAS

Pruebas unitarias Pruebas de Integracin Pruebas de sistema

PRUEBAS FUNCIONALES

Pruebas funcionales Pruebas de humo

Pruebas de regresin Pruebas de aceptacin Alpha testing Beta testing

PRUEBAS NO FUNCIONALES

Pruebas no funcionales Pruebas de seguridad Pruebas de usabilidad Pruebas de rendimiento Pruebas de internacionalizacin y localizacin Pruebas de escalabilidad Pruebas de mantenibilidad Pruebas de instalabilidad Pruebas de portabilidad

ESTRATEGIAS DE PRUEBA DEL SOFTWARE Una estrategia de prueba del software integra las tcnicas de diseo de casos de prueba en una serie de pasos bien planificados que dan como resultado una correcta construccin del software. Las pruebas son un conjunto de actividades que se pueden planificar por adelantado y llevar a cabo sistemticamente. Se debe definir en el proceso de ingeniera del software una plantilla para las pruebas del software: un conjunto de pasos en los que podamos situar los mtodos especficos de diseo de casos de prueba: PLANTILLA PARA LA PRUEBA: Las pruebas comienzan a nivel de mdulo y trabajan hacia fuera, hacia la integracin de todo el sistema basado en computadora. Segn el momento, son apropiadas diferentes tcnicas de prueba. La prueba la lleva a cabo el responsable del desarrollo del software y un grupo independiente de pruebas. La prueba y la depuracin son actividades diferentes, pero la depuracin se debe incluir en cualquier estrategia de prueba.

VERIFICACIN Y VALIDACIN (V&V) Verificacin: se refiere al conjunto de actividades que aseguran que el software implementa correctamente una funcin especfica. Validacin: se refiere a un conjunto diferente de actividades que aseguran que el software construido se ajusta a los requisitos del cliente. La verificacin y la validacin abarcan una amplia lista de actividades de SQA(garanta de calidad del software) que incluyen: 1.-Revisiones tcnicas formales. 2.-Auditorias de calidad y de configuracin. 3.-Monitorizacin de rendimientos. 4.-Simulacin. 5.-Estudios de factibilidad. 6.-Revisin de la documentacin. 7.-Revisin de la base de datos. 8.-Anlisis de algoritmos. 9.-Pruebas de desarrollo. 10.-Pruebas de validacin. 11.-Pruebas de instalacin. La calidad se incorpora en el software durante el proceso de ingeniera del software. La calidad se confirma durante las pruebas ORGANIZACIN PARA LAS PRUEBAS DE SOFTWARE Desde un punto de vista psicolgico, el anlisis y el diseo del software son tareas constructivas.

Cuando comienza la prueba, aparece una sutil, aunque firma intencin de romper lo que el ingeniero ha construido.

El responsable del desarrollo del software siempre es responsable de probar las unidades individuales (mdulos) del programa, asegurndose de que cada una lleve a cabo la funcin para la que fue diseada. Solo una vez que la arquitectura del software est completa entra en juego un grupo independiente de prueba. Grupo independiente de prueba (GIP): Un grupo de prueba independiente elimina el conflicto de intereses. UNA ESTRATEGIA DE PRUEBA DEL SOFTWARE El proceso de ingeniera del software se puede ver como una espiral. Inicialmente, la ingeniera de sistemas define el papel del software y conduce al anlisis de los requisitos del software, donde se establece el dominio de informacin. Una estrategia de prueba del software integra las tcnicas de diseo de casos de prueba en una serie de pasos bien planificados que dan como resultado una correcta construccin del software. Y lo que es ms importante, una estrategia de prueba del software proporciona un mapa a seguir para el responsable del desarrollo del software, a la organizacin de control de calidad y al cliente: un mapa que describe los pasos que hay que llevar a cabo como parte de la prueba, cundo se deben planificar y realizar esos pasos, y cunto esfuerzo, tiempo y recursos se van a requerir. Por tanto, cualquier estrategia de prueba debe incorporar la planificacin de la prueba, el diseo de casos de prueba, la ejecucin de las pruebas y la agrupacin y evaluacin de los datos resultantes. Una estrategia de prueba del software debe ser suficientemente flexible para promover la creatividad y la adaptabilidad necesarias para adecuar la prueba a todos los grandes sistemas basados en software. Al mismo tiempo, la estrategia debe ser suficientemente rgida para promover un seguimiento razonable de la planificacin y la gestin a medida que progresa el proyecto. Shooman trata estos puntos: En muchos aspectos, la prueba es un proceso individualista y el nmero de tipos diferentes de pruebas vara tanto como los diferentes enfoques de desarrollo. Durante muchos aos, nuestra nica defensa contra los errores de programacin era un cuidadoso diseo y la propia inteligencia del programador. Ahora nos encontramos en una era en la que las tcnicas modernas de diseo (y las revisiones tcnicas formales) nos ayudan a reducir el nmero de errores iniciales que se encuentran en el cdigo de forma inherente. De forma similar, los diferentes mtodos de prueba estn empezando a agruparse en varias filosofas y enfoques diferentes.

UN ENFOQUE ESTRATGICO PARA LA PRUEBA DEL SOFTWARE La prueba es un conjunto de actividades que se pueden planificar por adelantado y llevar a cabo sistemticamente. Por esta razn se debe definir en el proceso de la ingeniera del software una plantilla para la prueba del software: un conjunto de pasos en los que podamos situar los mtodos especficos de diseo de casos de prueba. Se han propuesto varias estrategias de prueba del software en distintos libros. Todas proporcionan al desarrollador de software una plantilla para la prueba y todas tienen las siguientes caractersticas generales: La prueba comienza en el nivel de mdulo y trabaja hacia fuera, hacia la integracin de todo el sistema basado en computadora. Segn el momento son apropiadas diferentes tcnicas de prueba. La prueba la lleva a cabo el responsable del desarrollo del software y (para grandes proyectos) un grupo independiente de pruebas. La prueba y la depuracin son actividades diferentes, pero la depuracin se debe incluir en cualquier estrategia de prueba. Una estrategia de prueba del software debe incluir pruebas de bajo nivel que verifiquen que todos los pequeos segmentos de cdigo fuente se han implementado correctamente, as como pruebas de alto nivel que validen las principales funciones del sistema frente a los requisitos del cliente. Una estrategia debe proporcionar una gua al profesional y proporcionar un conjunto de hitos para el jefe de proyecto. Debido a que los pasos de la estrategia de prueba se dan a la vez cuando aumenta la presin de los plazos fijados, se debe poder medir el progreso y los problemas deben aparecer lo antes posible. VERIFICACIN Y VALIDACIN La prueba del software es un elemento de un tema ms amplio que, a menudo, se le conoce como verificacin y validacin (V&V). La verificacin se refiere al conjunto de actividades que aseguran que el software implementa correctamente una funcin especfica. La validacin se refiere a un conjunto diferente de actividades que aseguran que el software construido se ajusta a los requisitos del cliente. Bohem lo define de otra forma: Verificacin: Estamos construyendo el producto correctamente? Validacin: Estamos construyendo el producto correcto?

ORGANIZACIN PARA LA PRUEBA DEL SOFTWARE En cualquier proyecto de software existe un conflicto de intereses inherente que aparece cuando comienza la prueba. Se pide a la gente que ha construido el software que lo pruebe. Esto parece totalmente inofensivo: despus de todo, quin puede conocer mejor un programa que los que lo han desarrollado? Desgraciadamente, los mismos programadores tienen un gran inters en demostrar que el programa est libre de errores, que funciona de acuerdo con las especificaciones del cliente y que estar listo de acuerdo con los plazos y el presupuesto. Cada uno de estos intereses se convierte en inconveniente a la hora de encontrar errores a lo largo del proceso de prueba. Desde un punto de vista psicolgico, el anlisis y el diseo del software (junto con la codificacin) son tareas constructivas. El ingeniero de software crea un programa de computadora, su documentacin y sus estructuras de datos asociadas. Al igual que cualquier constructor, el ingeniero de software est orgulloso del edificio que acaba de construir y se enfrenta a cualquiera e intente sacarle defectos. Cuando comienza la prueba, aparece una sutil, aunque firme intencin de romper lo que el ingeniero del software ha construido. Desde el punto de vista del constructor, la prueba se puede considerar (psicolgicamente) destructiva. Por lo tanto, el constructor anda con cuidado, diseando y ejecutando pruebas que demuestren que el programa funciona, en lugar de detectar errores. Desgraciadamente, los errores seguirn estando. Y si el ingeniero de software no los encuentra, el cliente si lo har. A menudo, existen ciertos malentendidos que se pueden deducir equivocadamente de la anterior discusin: (1) el responsable del desarrollo no debera entrar en el proceso de prueba; (2) el software debe ser puesto a salvo de extraos que puedan probarlo de forma despiadada; (3) los encargados de la prueba slo aparecen en el proyecto cuando comienzan las etapas de prueba. Todas estas frases son incorrectas. El responsable del desarrollo del software siempre es responsable de probar las unidades individuales (mdulos) del programa, asegurndose de que la una lleva a cabo la funcin para la que fue diseada. En muchos casos, tambin se encargar de la prueba de integracin, el paso de prueba que lleva a la construccin (y prueba) de la estructura total del sistema. Slo una vez que la arquitectura del software est completa entra en juego un grupo independiente de prueba. El papel del grupo independiente de prueba (GIP) es eliminar los inherentes problemas asociados con el hecho de permitir al constructor que pruebe lo que ha construido. Una prueba independiente elimina el conflicto de intereses que, de otro modo, estara presente. Despus de todo, al personal del equipo que forma el grupo independiente se le paga para que encuentre errores.

Sin embargo, el responsable del desarrollo del software no entrega simplemente el programa al GIP y se desentiende. El responsable del desarrollo y el GIP trabajan estrechamente a lo largo del proyecto de software para asegurar que se realizan pruebas exhaustivas. Mientras se realiza la prueba, el desarrollador debe estar disponible para corregir los errores que se van descubriendo. El GIP es parte del equipo del proyecto de desarrollo de software en el sentido de que se ve implicado durante el proceso de especificacin y sigue implicado (planificacin y especificacin de los procedimientos de prueba) a lo largo de un gran proyecto. Sin embargo, en muchos casos, el GIP informa a la organizacin de garanta de calidad del software, consiguiendo de este modo un grado de independencia que no sera posible si fuera una parte de la organizacin de desarrollo del software.

UNA ESTRATEGIA DE PRUEBA DEL SOFTWARE El proceso de ingeniera del software se puede ver como una espiral, como se ilustra en la Figura 10.1. Inicialmente, la ingeniera del sistema define el papel del software y conduce al anlisis de los requisitos del software, donde se establece el dominio de informacin, la funcin, el comportamiento, el rendimiento, las restricciones y los criterios de validacin del software. Al movernos hacia el interior de la espiral, llegamos al diseo y, por ltimo, a la codificacin. Para desarrollar software de computadora, damos vueltas en espiral a travs de una serie de flujos o lneas que disminuyen el nivel de abstraccin en cada vuelta. Tambin se puede ver la estrategia para la prueba del software en el contexto de la espiral. La prueba de unidad comienza en el vrtice de la espiral y se centra en cada unidad del software, tal como est implementada en cdigo fuente. La prueba avanza, al movernos hacia fuera de la espiral, hasta llegar a la prueba de integracin, donde el foco de atencin es el diseo y la construccin de la arquitectura del software. Dando otra vuelta por la espiral hacia fuera, encontramos la prueba de validacin, donde se validan los requisitos establecidos como parte del anlisis de requisitos del software, comparndolos con el sistema que ha sido construido. Finalmente, llegamos a la prueba del sistema, en la que se prueban como un todo el software y otros elementos del sistema. Para probar software de computadora nos movemos hacia fuera por una espiral que, a cada vuelta, aumenta el alcance de la prueba.

Si consideramos el proceso desde el punto de vista procedimental, la prueba, en el contexto de la ingeniera del software, realmente es una serie de cuatro pasos que se llevan a cabo secuencialmente. Inicialmente, la prueba se centra en cada mdulo individualmente,

asegurando que funcionan adecuadamente como una unidad. De ah el nombre de prueba de unidad. La prueba de unidad ejercita caminos especficos de la estructura de control del mdulo para asegurar un alcance completo y una deteccin mxima de errores. A continuacin se deben ensamblar o integrar los mdulos para formar el paquete de software completo. La prueba de integracin se dirige a todos los aspectos asociados con el doble problema de verificacin y de construccin del programa. Despus de que el software se ha integrado (construido), se dirigen un conjunto de pruebas de alto nivel. Se deben comprobar los criterios de validacin (establecidos durante el anlisis de requisitos). La prueba de validacin proporciona una seguridad final de que el software satisface todos los requisitos funcionales, de comportamiento y de rendimiento. El ltimo paso de prueba de alto nivel queda fuera de los lmites de la ingeniera del software, entrando en el ms amplio contexto de la ingeniera de sistemas de computadora. El software, una vez validado, se debe combinar con otros elementos del sistema (p.ej.: hardware, gente, bases de datos). La prueba del sistema verifica que cada elemento encaja de forma adecuada y que se alcanza la funcionalidad y el rendimiento del sistema total. CRITERIOS PARA COMPLETAR LA PRUEBA Cada vez que se trata la prueba del software surge una pregunta clsica: Cundo hemos terminado la prueba, cmo sabemos que hemos probado lo suficiente? Desgraciadamente, no hay una respuesta definitiva a esta pregunta, pero hay algunas respuestas prcticas y nuevos intentos de base emprica. Una respuesta a la pregunta anterior es: La prueba nunca termina, ya que el responsable del desarrollo del software carga o pasa el problema al cliente. Cada vez que el cliente/usuario ejecuta un programa de computadora, dicho programa se est probando con un nuevo conjunto de datos. Otra respuesta (algo cnica, pero sin embargo cierta) es: Se termina la prueba cuando se agota el tiempo o el dinero disponible para tal efecto. Aunque algunos profesionales se sirvan de estas respuestas como argumento, un ingeniero de software necesita un criterio ms riguroso para determinar cuando se ha realizado la prueba suficiente. Musa y Ackerman sugieren una respuesta basada en un criterio estadstico: No, no podemos tener la certeza absoluta de que el software nunca fallar, pero en base a un modelo estadstico de corte terico y validado experimentalmente, hemos realizado las pruebas suficientes para decir, con un 95 por ciento de certeza, que la probabilidad de funcionamiento libre de fallo de 1.000 horas de CPU, en un entorno definido de forma probabilstica, es al menos 0,995. Mediante el modelado estadstico y la teora de fiabilidad del software, se pueden desarrollar modelos de fallos del software (descubiertos durante la prueba) como una funcin del tiempo de ejecucin. Una versin del modelo de fallos, denominado modelo logartmico de Poisson de tiempo de ejecucin, adquiere la siguiente forma: f(t) = (1/p)ln(l0pt + 1) (1)

donde f(t) =nmero acumulado de fallos que se espera que se produzcan una vez que se ha probado el software durante una cierta cantidad de tiempo de ejecucin t, l0 = la intensidad de fallos inicial del software (fallos por unidad de tiempo) al principio de la prueba p = la reduccin exponencial de intensidad de fallo a medida que se encuentran los errores y se van haciendo las correcciones. La intensidad de fallos instantnea, l(t) se puede obtener mediante la derivada de f(t): l(t) = l0 / (l0pt+ 1) (2) Mediante la relacin de la ecuacin (2), los que realizan la prueba pueden predecir la disminucin de errores a medida que avanza la prueba. La intensidad de error real se puede trazar junto a la curva predecida. Si los datos reales recopilados durante la prueba y el modelo logartmico de Poisson de tiempo de ejecucin estn razonablemente cerca unos de otros, sobre un nmero de puntos de datos, el modelo se puede usar para predecir el tiempo de prueba total requerido para alcanzar una intensidad de fallos aceptablemente baja. Mediante la agrupacin de mtricas durante la prueba del software y haciendo uso de los modelos de fiabilidad del software existentes, es posible desarrollar directrices importantes para responder a la pregunta: cundo terminamos la prueba? No hay duda de que todava queda mucho trabajo por hacer antes de que se puedan establecer reglas cuantitativas para la prueba, pero los enfoques empricos que existen actualmente son considerablemente mejores que la pura intuicin.

ASPECTOS ESTRATGICOS Ms adelante exploramos una estrategia sistemtica para la prueba del software. Pero incluso la mejor estrategia fracasar si no se tratan una serie de aspectos invalidantes. Tom Gilb plantea que se deben abordar los siguientes puntos si se desea implementar con xito una estrategia de prueba del software: Especificar los requisitos del producto de manera cuantificable mucho antes de que comiencen las pruebas. Aunque el objetivo principal de la prueba es encontrar errores, una buena estrategia de prueba tambin evala otras caractersticas de la calidad tales como la

transportabilidad, facilidad de mantenimiento y facilidad de uso. Todo esto debera especificarse de manera que sea medible para que los resultados de la prueba no sean ambiguos. Establecer los objetivos de la prueba de manera explcita. Se deberan establecer en trminos medibles los objetivos especficos de la prueba. Por ejemplo la efectividad de la prueba, la cobertura de la prueba, tiempo medio de fallo, el coste para encontrar y arreglar errores, densidad de fallos remanente o frecuencia de ocurrencia, y horas de trabajo por prueba de regresin deberan establecerse dentro de la planificacin de la prueba. Comprender qu usuarios va a tener el software y desarrollar un perfil para cada categora de usuario. Usar casos, que describan el escenario de interaccin para cada clase de usuario pudiendo reducir el esfuerzo general de prueba concentrando la prueba en el empleo real del producto. Desarrollar un plan de prueba que haga hincapi en la prueba de ciclo rpido. Gilb recomienda que un equipo de ingeniera del software aprenda a probar en ciclos rpidos (2 por ciento del esfuerzo del proyecto) de incrementos de funcionalidad y/o mejora de la calidad tiles para el cliente y que se puedan probar sobre el terreno. La realimentacin generada por estas pruebas de ciclo rpido puede usarse para controlar los niveles de calidad y las correspondientes estrategias de prueba. Construir un software robusto diseado para probarse a s mismo. El software debera disearse de manera que use tcnicas de depuracin anti-errores. Es decir, el software debera ser capaz de diagnosticar ciertas clases de errores. Adems, el diseo debera incluir pruebas automatizadas y pruebas de regresin. Usar revisiones tcnicas formales efectivas como filtro antes de la prueba. Las revisiones tcnicas formales pueden ser tan efectivas como las pruebas en el descubrimiento de errores. Por este motivo, las revisiones pueden reducir la cantidad de esfuerzo de prueba necesaria para producir software de alta calidad. Llevar a cabo revisiones tcnicas formales para evaluar la estrategia de prueba y los propios casos de prueba. Las revisiones tcnicas formales pueden descubrir inconsistencias, omisiones y errores claros en el enfoque de la prueba. Esto ahorra tiempo y tambin mejora la calidad del producto. Desarrollar un enfoque de mejora continua al proceso de prueba. Debera medirse la estrategia de prueba. Las mtricas agrupadas durante la prueba deberan usarse como parte de un enfoque estadstico de control del proceso para la prueba del software.

PRUEBA DE UNIDAD

La prueba de unidad centra el proceso de verificacin en la menor unidad del diseo del software: el mdulo. Usando la descripcin del diseo procedimental como gua, se prueban los caminos de control importantes, con el fin de descubrir errores dentro del lmite del mdulo. La complejidad relativa de las pruebas y de los errores descubiertos est limitada por el alcance estricto establecido por la prueba de unidad. CONSIDERACIONES SOBRE LA PRUEBA DE UNIDAD Las pruebas que se dan como parte de la prueba de unidad estn esquemticamente ilustradas en la Figura 10.4. Se prueba la interfaz del mdulo para asegurar que la informacin fluye de forma adecuada hacia y desde la unidad de programa que est siendo probada. Se examinan las estructuras de datos locales para asegurar que los datos que se mantienen temporalmente conservan su integridad durante todos los pasos de ejecucin del algoritmo. Se prueban las condiciones lmite para asegurar que el mdulo funciona correctamente en los lmites establecidos como restricciones de procesamiento. Se ejercitan todos los caminos independientes (caminos bsicos) de la estructura de control con el fin de asegurar que todas las sentencias del mdulo se ejecutan por lo menos una vez. Y, finalmente, se prueban todos los caminos de manejo de errores.

Antes de iniciar cualquier otra prueba es preciso probar el flujo de datos de la interfaz del mdulo. Si los datos no entran correctamente, todas las dems pruebas no tienen sentido. Myers, en su libro sobre prueba del software, propone una lista de comprobaciones para la prueba de interfaces: 1. Es igual el nmero de parmetros de entrada al nmero de argumentos? 2. Coinciden los atributos de los parmetros y los argumentos? 3. Coinciden los sistemas de unidades de los parmetros y de los argumentos? 4. Es igual el nmero de argumentos transmitidos a los mdulos de llamada que el nmero de parmetros? 5. Son iguales los atributos de los argumentos transmitidos a los mdulos de llamada y los atributos de los parmetros? 6. Son iguales los sistemas de unidades de los argumentos transmitidos a los mdulos de llamada y de los parmetros? 7. Son correctos el nmero de los atributos y el orden de los argumentos de las funciones incorporadas? 8. Existen referencias a parmetros que no estn asociados con el punto de entrada actual? 9. Entran slo argumentos alterados? 10. Son consistentes las definiciones de variables globales entre los mdulos? 11. Se pasan las restricciones como argumentos?

Cuando un mdulo lleve a cabo E/S externa, se deben llevar a cabo pruebas de interfaz adicionales. Nuevamente, de Myers: 1. Son correctos los atributos de los archivos? 2. Son correctas las sentencias ABRIR/CERRAR? 3. Coinciden las especificaciones de formato con las sentencias de E/S? 4. Coincide el tamao del buffer con el tamao del registro? 5. Se abren los archivos antes de usarlos? 6. Se tienen en cuenta las condiciones de fin-de-archivo? 7. Se manejan los errores de E/S? 8. Hay algn error textual en la informacin de salida? Las estructuras de datos locales de cada mdulo son una fuente potencial de errores. Se deben disear casos de prueba para descubrir errores de las siguientes categoras: 1. 2. 3. 4. 5. Tipificacin impropia o inconsistente. Inicializacin o valores implcitos errneos. Nombres de variables incorrectos (mal escritos o truncados). Tipos de datos inconsistentes. Excepciones de desbordamiento por arriba o por abajo, o de direccionamiento.

Adems de las estructuras de datos locales, durante la prueba de unidad se debe comprobar (en la medida de lo posible) el impacto de los datos globales sobre el mdulo. Durante la prueba de unidad, la comprobacin selectiva de los caminos de ejecucin es una tarea esencial. Se deben disear casos de prueba para detectar errores debidos a clculos incorrectos, comparaciones incorrectas o flujos de control inapropiados. Las pruebas del camino bsico y de bucles son tcnicas muy efectivas para descubrir una gran cantidad de errores en los caminos. Entre los errores ms comunes en los clculos estn: (1) precedencia aritmtica incorrecta o mal interpretada; (2) operaciones de modo mezcladas; (3) inicializaciones incorrectas; (4) falta de precisin; (5) incorrecta representacin simblica de una expresin. Las comparaciones y el flujo de control estn fuertemente emparejadas (p. ej.: el flujo de control cambia frecuentemente tras una comparacin). Los casos de prueba deben descubrir errores como: (1) comparaciones ente tipos de datos distintos; (2) operadores lgicos o de precedencia incorrectos; (3) igualdad esperada cuando los errores de precisin la hacen poco probable; (4) variables o comparaciones incorrectas; (5) terminacin de bucles inapropiada o inexistente; (6) fallo de salida cuando se encuentra una iteracin divergente y (7) bucles que manejan variables modificadas de forma inapropiada. Un buen diseo exige que las condiciones de error sean previstas de antemano y que se dispongan unos caminos de manejo de errores que redirijan o terminen de una forma

limpia el proceso cuando se d un error. Yourdon llama a este enfoque antipurgado. Desgraciadamente, existe una tendencia a incorporar la manipulacin de errores en el software y as no probarlo nunca. Como ejemplo, sirve una historia real: Mediante un contrato se desarroll un importante sistema de diseo interactivo. En un mdulo de proceso de transacciones un bromista puso el siguiente mensaje de manipulacin de error que apareca tras una serie de pruebas condicionales que invocaban varias ramificaciones del flujo de control: ERROR! NO HAY FORMA DE QUE UD. LLEGUE HASTA AQU. Este mensaje de error fue descubierto por un cliente durante la fase de puesta a punto! Entre los errores potenciales que se deben comprobar cuando se evala la manipulacin de errores estn: 1. Descripcin ininteligible del error. 2. El error sealado no se corresponde con el error encontrado 3. La condicin de error hace que intervenga el sistema antes que el mecanismo de manejo de errores 4. El proceso de la condicin excepcional es incorrecto 5. La descripcin del error no proporciona suficiente informacin para ayudar en la localizacin de la causa del error. La prueba de lmites es la ltima (y probablemente, la ms importante) tarea del paso de la prueba de unidad. El software falla frecuentemente en sus condiciones lmite. Es decir, con frecuencia aparece un error cuando se procesa el elemento n-simo de un array ndimensional, cuando se hace la i-sima repeticin de un bucle de i pasos o cuando se encuentran los valores mximo o mnimo permitidos. Los casos de prueba que ejerciten las estructuras de datos, el flujo de control y los valores de los datos por debajo, en y por encima de los mximos y los mnimos son muy apropiados para descubrir estos errores. PROCEDIMIENTOS DE LA PRUEBA DE UNIDAD Normalmente, se considera a la prueba de unidad como algo adjunto al paso de codificacin. El diseo de casos de prueba de unidad comienza una vez que se ha desarrollado, revisado y verificado en su sintaxis el cdigo a nivel de fuente. Un repaso de la informacin del diseo proporciona directrices para el establecimiento de los casos de prueba que ms probablemente descubrirn errores de las categoras previamente mencionadas. Cada caso de prueba debe ir acompaado de un conjunto de resultados esperados. Debido a que un mdulo no es un programa independiente, se debe desarrollar para cada prueba de unidad un software que controle y/o resguarde. En la Figura 5 se ilustra el entorno para la prueba de unidad. En la mayora de las aplicaciones, un conductor no es ms que un programa principal que acepta los datos del caso de prueba, pasa estos datos al mdulo (a ser probado) e imprime los resultados importantes. Los resguardos sirven para reemplazar mdulos que estn subordinados (llamados por) al mdulo que hay que probar. Un resguardo o un subprograma simulado usa la

interfaz del mdulo subordinado, lleva a cabo una mnima manipulacin de datos, imprime una verificacin de entrada y vuelve. Los conductores y los resguardos son una sobrecarga de trabajo. Es decir, ambos son software que debe desarrollarse pero que no se entrega con el producto de software final. Si se mantienen simplificados los conductores y los resguardos, el trabajo adicional real es relativamente pequeo. Desgraciadamente, muchos mdulos no se pueden probar en una unidad de forma adecuada con un simple software adicional. En tales casos, la prueba completa se pospone hasta que se llegue al paso de prueba de integracin (donde tambin se usan conductores o resguardos).

La prueba de unidad se simplifica cuando se disea un mdulo con un alto grado de cohesin. Cuando un mdulo slo se dirige a una funcin, se reduce el nmero de casos de prueba y los errores se pueden predecir y descubrir ms fcilmente.

PRUEBA DE INTEGRACIN Un nefito del mundo del software podra, una vez que se les ha hecho la prueba de unidad a todos los mdulos, cuestionar de forma aparentemente legtima lo siguiente: Si todos funcionan bien por separado, por qu dudar de que funcionen todos juntos?. Por supuesto, el problema es ponerlos juntos (interaccin). Los datos se pueden perder en una interfaz; un mdulo puede tener un efecto adverso e inadvertido sobre otro; las subfunciones, cuando se combinan, pueden no producir la funcin principal deseada; la imprecisin aceptada individualmente puede crecer hasta niveles inaceptables; y las estructuras de datos globales pueden presentar problemas; desgraciadamente, la lista sigue y sigue. La prueba de integracin es una tcnica sistemtica para construir la estructura del programa mientras que, al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interaccin. El objetivo es coger los mdulos probados en unidad y construir una estructura de programa que est de acuerdo con lo que dicta el diseo. A menudo hay una tendencia a intentar una integracin no incremental; es decir, a construir el programa mediante un enfoque de big bang. Se combinan todos los mdulos por anticipado. Se prueba todo el programa en conjunto. Normalmente se llega al caos! Se encuentra un gran conjunto de errores. La correccin se hace difcil, puesto que es complicado aislar las causas al tener delante el programa entero en toda su extensin. Una

vez que se corrigen esos errores aparecen otros nuevos y el proceso contina en lo que parece ser un ciclo sin fin. La integracin incremental es la anttesis del enfoque del big bang. El programa se construye y se prueba en pequeos segmentos en los que los errores son ms fciles de aislar y de corregir, es ms probable que se puedan probar completamente las interfaces y se puede aplicar un enfoque de prueba sistemtica. A continuacin se tratan varias estrategias de integracin incremental diferentes.

INTEGRACIN DESCENDENTE La integracin descendente es un planteamiento incremental a la construccin de la estructura de programas. Se integran los mdulos movindose hacia abajo por la jerarqua de control, comenzando por el mdulo de control principal (programa principal). Los mdulos subordinados (de cualquier modo subordinados) al mdulo de control principal se van incorporando en la estructura, bien de forma primero-en-profundidad o bien de forma primero-en-anchura.

La estrategia de integracin descendente verifica los puntos de decisin o de control principales al principio del proceso de prueba. En una estructura de programa bien fabricada, la toma de decisiones se da en los niveles superiores de la jerarqua y, por tanto, se encuentran antes. Si existen problemas generales de control, es esencial reconocerlos cuanto antes. Si se selecciona la integracin primero-en-profundidad, se puede ir implementando y demostrando las funciones completas del software. Por ejemplo, considere una estructura de transaccin clsica en la que se requiere una compleja serie de entradas interactivas, obtenidas y validadas por medio de un camino de entrada. Ese camino de entrada puede ser integrado en forma descendente. As, se puede demostrar todo el proceso de entradas (para posteriores operaciones de transaccin) antes de que se integren otros elementos de la estructura. La demostracin anticipada de las posibilidades funcionales es un generador de confianza tanto para el desarrollador como para el cliente. La estrategia descendente parece relativamente fcil, pero en la prctica, pueden surgir algunos problemas logsticos. El ms comn de estos problemas se da cuando se requiere un proceso de los niveles ms bajos de la jerarqua para poder probar adecuadamente los niveles superiores. Al principio de la prueba descendente, los mdulos de bajo nivel se reemplazan por resguardos; por tanto, no pueden fluir datos significativos hacia arriba por la estructura del programa. El responsable de la prueba tiene tres opciones: (1) retrasar muchas de las pruebas hasta que los resguardos sean reemplazados por los mdulos reales; (2) desarrollar resguardos que realicen funciones limitadas que simulen los mdulos reales; o (3) integrar el software desde el fondo de la jerarqua hacia arriba. La

Figura 10.7 ilustra varias clases de resguardos tpicas, desde la ms simple (resguardo A) hasta la ms compleja (resguardo D). El primer enfoque (retrasar pruebas hasta reemplazar los resguardos por los mdulos reales) hace que perdamos cierto control sobre la correspondencia de ciertas pruebas especficas con la incorporacin de determinados mdulos. Esto puede dificultar la determinacin de las causas del error y tiende a violar la naturaleza altamente restrictiva del enfoque descendente. El segundo enfoque es factible pero puede llevar a un significativo incremento del esfuerzo a medida que los resguardos se hagan ms complejos. El tercer enfoque, denominado prueba ascendente, se estudia a continuacin. INTEGRACIN ASCENDENTE La prueba de la integracin ascendente, como su nombre indica, empieza la construccin y la prueba con los mdulos atmicos (es decir, mdulos de los niveles ms bajos de la estructura del programa). Dado que los mdulos se integran de abajo hacia arriba, el proceso requerido de los mdulos subordinados a un nivel dado siempre estn disponibles y se elimina la necesidad de resguardos. Se puede implementar una estrategia de integracin ascendente mediante los siguientes pasos: 1. Se combinan los mdulos de bajo nivel en grupos (a veces denominados construcciones) que realicen una sub funcin especfica del software. 2. Se escribe un controlador (un programa de control de la prueba) para coordinar la entrada y la salida de los casos de prueba. 3. Se prueba el grupo. 4. Se eliminan los controladores y se combinan los grupos movindose hacia arriba por la estructura del programa. La integracin sigue el esquema ilustrado en la Figura 8. Se combinan los mdulos para formar los grupos 1, 2 y 3. Cada uno de los grupos se somete a prueba mediante un controlador (mostrado como un bloque punteado). Los mdulos de los grupos 1 y 2 son subordinados de Ma. Los controladores D1 y D2 se eliminan y los grupos interaccionan directamente con Ma. De forma similar, se elimina el controlador D3 del grupo 3 antes de la integracin con el mdulo Mb Tanto Ma como Mb se integrarn finalmente con el mdulo Mc y as sucesivamente. En la Figura 9 se muestran diferentes categoras de controladores. A medida que la integracin progresa hacia arriba, disminuye la necesidad de controladores de prueba diferentes. De hecho, si los dos niveles superiores de la estructura del programa se integran de forma descendente, se puede reducir sustancialmente el nmero de controladores y se simplifica enormemente la integracin de grupos.

PRUEBA DE REGRESIN Cada vez que se aade un nuevo mdulo como parte de una prueba de integracin, el software cambia. Se establecen nuevos caminos de flujo de datos, pueden ocurrir nuevas E/S y se invoca una nueva lgica de control. Estos cambios pueden causar problemas con funciones que antes trabajaban perfectamente. En el contexto de una estrategia de prueba de integracin, la prueba de regresin es volver a ejecutar un subconjunto de pruebas que se han llevado a cabo anteriormente para asegurarse que los cambios no han propagado efectos colaterales no deseados. En un contexto ms amplio, las pruebas con xito (de cualquier tipo) dan como resultado el descubrimiento de errores, y los errores hay que corregirlos. Cuando se corrige el software, se cambia algn aspecto de la configuracin del software (el programa, su documentacin o los datos que lo soportan). La prueba de regresin es la actividad que ayuda a asegurar que los cambios (debidos a las pruebas o por otros motivos) no introducen un comportamiento no deseado o errores adicionales. La prueba de regresin se puede hacer manualmente, volviendo a realizar un subconjunto de todos los casos de prueba o utilizando herramientas automticas de reproduccin de captura. Las herramientas de reproduccin de captura permiten al ingeniero del software capturar casos de prueba y los resultados para la subsiguiente reproduccin y comparacin. El conjunto de pruebas de regresin (el subconjunto de pruebas a realizar) contiene tres clases diferentes de casos de prueba:

Una muestra representativa de pruebas que ejercite todas las funciones del software. Pruebas adicionales que se centran en las funciones del software que se van a ver probablemente afectadas por el cambio. Pruebas que se centran en los componentes del software que se han cambiado.

COMENTARIOS SOBRE LA PRUEBA DE INTEGRACIN Ha habido muchos estudios sobre las ventajas y desventajas de la prueba de integracin ascendente frente a la descendente. En general, las ventajas de una estrategia tienden a convertirse en desventajas para la otra estrategia. La principal desventaja del enfoque descendente es la necesidad de resguardos y dificultades de prueba que pueden estar asociados con ellos. Los problemas asociados con los resguardos pueden quedar compensados por la ventaja de poder probar de antemano las principales funciones de

control. La principal desventaja de la integracin ascendente es que "el programa como entidad no existe hasta que se ha diseado el ltimo mdulo". Este inconveniente se resuelve con la mayor facilidad de diseo de casos de prueba y con la falta de resguardos. La seleccin de una estrategia de integracin depende de las caractersticas del software y, a veces, de la planificacin del proyecto. En general, el mejor compromiso puede ser un enfoque combinado (a veces denominado "prueba de sndwich") que use la descendente para los niveles superiores de la estructura del programa, junto con la ascendente para los niveles subordinados. A medida que progresa la prueba de integracin, el responsable de las pruebas debe identificar los mdulos crticos. Un mdulo crtico es aquel que tiene una o ms de las siguientes caractersticas: (1) est dirigido a varios requisitos del software; (2) tiene un mayor nivel de control (est relativamente alto en la estructura del programa); (3) es complejo o propenso a errores; o (4) tiene unos requisitos de rendimiento muy definidos. Los mdulos crticos deben probarse lo antes posible. Adems, las pruebas de regresin se deben centrar en el funcionamiento de los mdulos crticos.

DOCUMENTACIN DE LA PRUEBA DE INTEGRACIN Un plan global para la integracin del software y una descripcin de las pruebas especficas deben quedar documentados en una especificacin de prueba. La especificacin es un resultado del proceso de ingeniera de software y forma parte de la configuracin del software. La Figura 10.8 presenta un esquema de una especificacin de prueba que puede usarse como marco de trabajo para este documento.

PRUEBA DE VALIDACIN Tras la culminacin de la prueba de integracin, el software est completamente ensamblado como un paquete; se han encontrado y corregido los errores de interfaz y puede comenzar una serie final de pruebas del software: la prueba de validacin. La validacin puede definirse de muchas formas, pero una simple (aunque vulgar) definicin es que la validacin se consigue cuando el software funciona de acuerdo con las expectativas razonables del cliente. En este punto, un desarrollador de software estricto podra protestar: Qu o quin es el rbitro de las expectativas razonables?.

Las expectativas razonables estn definidas en la especificacin de requisitos del software un documento que describe todos los atributos del software visibles para el usuario. La

especificacin contiene una seccin denominada Criterios de validacin. La informacin contenida en esa seccin forma la base del enfoque a la prueba de validacin.

CRITERIOS DE LA PRUEBA DE VALIDACIN La validacin del software se consigue mediante una serie de pruebas que demuestran la conformidad con los requisitos. Un plan de prueba traza las clases de pruebas que se han de llevar a cabo, y un procedimiento de prueba define los casos de prueba especficos en un intento por descubrir errores de acuerdo con los requisitos. Tanto el plan como el procedimiento estarn diseados para asegurar que se satisfacen todos los requisitos funcionales, que se alcanzan todos los requisitos de rendimiento, que la documentacin es correcta e inteligible y que se alcanzan otros requisitos (p ej.: transportabilidad, compatibilidad, recuperacin de errores, facilidad de mantenimiento). Una vez que se procede con cada caso de prueba de validacin, puede darse una de las dos condiciones siguientes: (1) las caractersticas de funcionamiento o de rendimiento estn de acuerdo con las especificaciones y son aceptables o (2) se descubre una desviacin de las especificaciones y se crea una lista de deficiencias. Las desviaciones o errores descubiertos en esta fase del proyecto raramente se pueden corregir antes de la terminacin planificada. A menudo es necesario negociar con el cliente un mtodo para resolver las deficiencias. REVISIN DE LA CONFIGURACIN Un elemento importante del proceso de validacin es la revisin de la configuracin. La intencin de la revisin es asegurarse de que todos los elementos de la configuracin del software se han desarrollado apropiadamente, se han catalogado y estn suficientemente detallados para soportar la fase de mantenimiento durante el ciclo de vida del software.

PRUEBAS ALFA Y BETA Es virtualmente imposible que un constructor de software pueda prever cmo usar realmente el programa el usuario. Se pueden malinterpretar las instrucciones de uso, se

pueden utilizar habitualmente extraas combinaciones de datos y una salida que puede parecer clara para el responsable de las pruebas puede ser ininteligible para el usuario. Cuando se construye software a medida para un cliente, se llevan a cabo una serie de pruebas de aceptacin para permitir que el cliente valide todos los requisitos. Las realiza el usuario final en lugar del responsable del desarrollo del sistema, una prueba de aceptacin puede ir desde un informal paso de prueba hasta la ejecucin sistemtica de una serie de pruebas bien planificadas. De hecho, la prueba de aceptacin puede tener lugar a lo largo de semanas o meses, descubriendo as errores acumulados que pueden ir degradando el sistema. Si el software se desarrolla como un producto que se va a usar por muchos clientes, no es prctico realizar pruebas de aceptacin formales para cada uno de ellos. La mayora de los constructores de productos de software llevan a cabo un proceso denominado prueba alfa y beta para descubrir errores que parezca que slo el usuario final puede descubrir. La prueba alfa se lleva a cabo en el lugar de desarrollo pero por un cliente. Se usa el software de forma natural con el desarrollador como observador del usuario y registrando los errores y los problemas de uso. Las pruebas alfa se llevan a cabo en un entorno controlado. La prueba beta se lleva a cabo por los usuarios finales del software en los lugares de trabajo de los clientes. A diferencia de la prueba alfa, el desarrollador no est presente normalmente. As, la prueba beta es una aplicacin en vivo del software en un entorno que no puede ser controlado por el desarrollador. El cliente registra todos los problemas (reales o imaginarios) que encuentra durante la prueba beta e informa a intervalos regulares al desarrollador. Como resultado de los problemas informados durante la prueba beta, el desarrollador del software lleva a cabo modificaciones y as prepara una versin del producto de software para toda la clase de clientes.

PRUEBA DEL SISTEMA Al principio, pusimos nfasis en el hecho de que el software es slo un elemento de un sistema mayor basado en computadora. Finalmente, el software es incorporado a otros elementos del sistema (p. ej.: nuevo hardware, informacin) y realizan una serie de pruebas de integracin del sistema y de validacin. Estas pruebas caen fuera del mbito del proceso de ingeniera del software y no las realiza nicamente el desarrollador del software. Sin embargo, los pasos dados durante el diseo del software y durante la prueba pueden mejorar enormemente la probabilidad de xito en la integracin del software en el sistema. Un problema tpico de la prueba del sistema es la delegacin de culpabilidad. Esto ocurre cuando se descubre un error y cada uno de los creadores de cada elemento del sistema echa la culpa del problema a los otros. En vez de verse envuelto en esta absurda situacin, el ingeniero del software debe anticiparse a los posibles problemas de interaccin y: (1) disear caminos de manejo de errores que prueben toda la informacin procedente de

otros elementos del sistema; (2) llevar a cabo una serie de pruebas que simulen la presencia de datos en mal estado o de otros posibles errores en la interfaz del software; (3) registrar los resultados de las pruebas como evidencia en el caso de que se le seale con el dedo; (4) participar en la planificacin y el diseo de pruebas del sistema para asegurarse de que el software se prueba de forma adecuada. La prueba del sistema, realmente, est constituida por una serie de pruebas diferentes cuyo propsito primordial es ejercitar profundamente el sistema basado en computadora. Aunque cada prueba tiene un propsito diferente, todas trabajan para verificar que se han integrado adecuadamente todos los elementos del sistema y que realizan las funciones apropiadas.

PRUEBA DE RECUPERACIN Muchos sistemas basados en computadora deben recuperarse de los fallos y continuar el proceso en un tiempo previamente especificado. En algunos casos, un sistema debe ser tolerante con los fallos; es decir, los fallos del proceso no deben hacer que cese el funcionamiento de todo el sistema. En otros casos, se debe corregir un fallo del sistema en un determinado periodo de tiempo para que no se produzca un serio dao econmico. La prueba de recuperacin es una prueba del sistema que fuerza el fallo del software de muchas formas y verifica que la recuperacin se lleva a cabo apropiadamente. Si la recuperacin es automtica (llevada a cabo por el propio sistema) hay que evaluar la correccin de la inicializacin, de los mecanismos de recuperacin del estado del sistema, de la recuperacin de datos y del proceso de arranque. Si la recuperacin requiere la intervencin humana, hay que evaluar los tiempos medios de reparacin para determinar si estn dentro de unos lmites aceptables.

PRUEBA DE SEGURIDAD Cualquier sistema basado en computadora que maneje informacin sensible o lleve a cabo acciones que puedan perjudicar (o beneficiar) impropiamente a las personas es un posible objetivo para entradas al sistema impropias o ilegales. Este acceso al sistema incluye un amplio rango de actividades: piratas informticos que intentan entrar en los

sistemas por deporte, empleados disgustados que intentan penetrar por venganza e individuos deshonestos que intentan penetrar para obtener ganancias personales ilcitas. La prueba de seguridad intenta verificar que los mecanismos de proteccin incorporados en el sistema lo protegern, de hecho, de accesos impropios. Durante la prueba de seguridad, el responsable de la prueba desempea el papel de un individuo que desea entrar en el sistema. Todo vale! Debe intentar conseguir las claves de acceso por cualquier medio, puede atacar al sistema con software a medida, diseado para romper cualquier defensa que se haya construido, debe bloquear el sistema, negando as el servicio a otras personas, debe producir a propsito errores del sistema, intentando acceder durante la recuperacin o debe curiosear en los datos sin proteccin, intentando encontrar la clave de acceso al sistema, etc. Con tiempo y recursos suficientes, una buena prueba de seguridad terminar por acceder en el sistema. El papel del diseador del sistema es hacer que el coste de la entrada ilegal sea mayor que el valor de la informacin obtenida.

PRUEBA DE RESISTENCIA Las pruebas de resistencia estn diseadas para enfrentar a los programas con situaciones anormales. En esencia, el sujeto que realiza la prueba de resistencia se pregunta: A qu potencia puedo ponerlo a funcionar antes de que falle? La prueba de resistencia ejecuta un sistema de forma que demande recursos en cantidad, frecuencia o volmenes anormales. Por ejemplo: (1) disear pruebas especiales que generen diez interrupciones por segundo, cuando las normales son una o dos; (2) incrementar las frecuencias de datos de entrada en un orden de magnitud con el fin de comprobar cmo responden las funciones de entrada; (3) ejecutar casos de prueba que requieran el mximo de memoria o de otros recursos; (4) disear casos de prueba que puedan dar problemas en un sistema operativo virtual o (5) disear casos de prueba que produzcan excesivas bsquedas de datos residentes en disco. Esencialmente, el responsable de la prueba intenta romper el programa.

Una variante de la prueba de resistencia es una tcnica denominada prueba de sensibilidad. En algunas situaciones (la ms comn se da con algoritmos matemticos), un rango de datos muy pequeo dentro de los lmites de una entrada vlida para un programa puede producir un proceso exagerado e incluso errneo o una profunda degradacin del rendimiento. Esta situacin es anloga a una singularidad en una funcin matemtica. La prueba de sensibilidad intenta descubrir combinaciones de datos dentro de una clase de entrada vlida que pueda producir inestabilidad o un proceso incorrecto.

PRUEBA DE RENDIMIENTO Para sistemas de tiempo real y sistemas empotrados, es inaceptable el software que proporciona las funciones requeridas pero no se ajusta a los requisitos de rendimiento. La prueba de rendimiento est diseada para probar el rendimiento del software en tiempo de ejecucin dentro del contexto de un sistema integrado. La prueba de rendimiento se da durante todos los pasos del proceso de la prueba. Incluso al nivel de unidad, se debe asegurar el rendimiento de los mdulos individuales a medida que se llevan a cabo las pruebas de caja blanca. Sin embargo, hasta que no estn completamente integrados todos los elementos del sistema no se puede asegurar realmente el rendimiento del sistema. Las pruebas de rendimiento, a menudo, van emparejadas con las pruebas de resistencia y, frecuentemente, requieren instrumentacin tanto de software como de hardware. Es decir, muchas veces es necesario medir la utilizacin de recursos (p. ej.: ciclos de procesador), de un modo exacto. La instrumentacin externa puede monitorizar los intervalos de ejecucin, los sucesos ocurridos (p. ej.: interrupciones) y muestras de los estados de la mquina en un funcionamiento normal. Instrumentando un sistema, el encargado de la prueba puede descubrir situaciones que lleven a degradaciones y posibles fallos del sistema. EL ARTE DE LA DEPURACIN La prueba del software es un proceso que puede planificarse y especificarse sistemticamente. Se puede llevar a cabo el diseo de casos de prueba, se puede definir una estrategia y se pueden evaluar los resultados en comparacin con las expectativas prescritas. La depuracin ocurre como consecuencia de una prueba efectiva. Es decir, cuando un caso de prueba descubre un error, la depuracin es el proceso que provoca la eliminacin del error. Aunque la depuracin puede y debe ser un proceso ordenado, sigue teniendo mucho de arte. Un ingeniero del software, al evaluar los resultados de una prueba, se encuentra frecuentemente con una indicacin sintomtica de un problema en el software. Es decir, la manifestacin externa de un error, y la causa interna del error pueden no estar relacionadas de una forma obvia. El proceso mental, apenas comprendido, que conecta un sntoma con una causa es la depuracin.

EL PROCESO DE DEPURACIN La depuracin no es una prueba, pero siempre ocurre como consecuencia de la prueba. Como se muestra en la Figura 10.9, el proceso de depuracin comienza con la ejecucin de un caso de prueba. Se evalan los resultados y aparece una falta de correspondencia entre los esperados y los encontrados realmente. En muchos casos, los

datos que no concuerdan son un sntoma de una causa subyacente que todava permanece oculta. El proceso de depuracin intenta hacer corresponder el sntoma con una causa, llevando as a la correccin del error. El proceso de depuracin siempre tiene uno de los dos resultados siguientes: (1) se encuentra la causa, se corrige y se elimina; o (2) no se encuentra la causa. En este ltimo caso, la persona que realiza la depuracin debe sospechar la causa, disear un caso de prueba que ayude a confirmar sus sospechas y el trabajo vuelve hacia atrs a la correccin del error de una forma iterativa. Por qu es tan difcil la depuracin? Todo parece indicar que la respuesta tiene ms que ver con la psicologa humana que con la tecnologa del software. Sin embargo, varias caractersticas de los errores nos dan algunas pistas: 1. El sntoma y la causa pueden ser geogrficamente remotos entre s. Es decir, el sntoma puede aparecer en una parte del programa, mientras que la causa est localizada en otra parte muy alejada. Las estructuras de programa fuertemente acopladas resaltan esta situacin. 2. El sntoma puede desaparecer (temporalmente) al corregir otro error. 3. El sntoma puede realmente estar producido por algo que no es un error (p.ej.: inexactitud en los redondeos). 4. El sntoma puede estar causado por un error humano que no sea fcilmente detectado. 5. El sntoma puede ser el resultado de problemas de temporizacin en vez de problemas de proceso. 6. Puede ser difcil reproducir exactamente las condiciones de entrada (p.ej.: una aplicacin de tiempo real en la que el orden de la entrada no est determinado). 7. El sntoma puede aparecer de forma intermitente. Esto es particularmente corriente en sistemas empotrados que acoplan el hardware y el software de manera confusa. 8. El sntoma puede ser debido a causas que se distribuyen por una serie de tareas ejecutndose en diferentes procesadores.

Durante la depuracin encontramos errores que van desde lo ligeramente inesperado (p. ej.: un formato de salida incorrecto) hasta lo catastrfico (p.ej.: el sistema falla, producindose serios daos econmicos o fsicos). A medida que las consecuencias de un error aumentan, crece la presin por encontrar su causa. A menudo la presin fuerza a un ingeniero de software a corregir un error introduciendo dos ms. No slo por costos se usa software libre

La compatibilidad, estabilidad y el valor, entre otras caractersticas, son atributos que ofrece el software libre, amn del menor costo por uso del sistema operativo o aplicaciones de cdigo abierto. Magnabyte es una empresa que se dedica a la integracin y venta de integracin de herramientas de negocio; en su cartera ostenta una serie de soluciones para la Pyme, como ERP y CRM, as como software para la calidad en certificaciones ISO 9000. De igual manera, ofrece la puesta a punto de servidores, con el enfoque principal en Linux. Somos un partner de IBM, nuestros productos corren sobre bases de datos que tienen alguna aplicacin, como la colaboracin de Lotus y otras soluciones, coment a eSemanal scar Flores, director general de Magnabyte. El directivo destac que las instalaciones que realizan son pensadas en servidores de misin crtica y aplicaciones, sobre todo ERP O CRM, que tienen el objetivo de correr 24 horas por siete das a la semana; por tal motivo, siempre recomiendan montar las soluciones que comercializan sobre Linux Lo anterior ha llevado a Magnabyte a tener una divisin dentro de su organizacin para el rea de servicios y configuracin, ya que existen clientes que no necesariamente requieren una solucin que les compre si no ofrecen el servicio en su servidor de correo, Internet o la parte interna que forma Linux. Por la experiencia adquirida en el trabajo con Suse, el integrador es socio de Novell. A la fecha 80% de sus servicios corren sobre Linux y el porcentaje restante es en Unix. Lo anterior ha llevado a Magnabyte a tener una divisin dentro de su organizacin para el rea de servicios y configuracin, ya que existen clientes que no necesariamente requieren una solucin que les compre si no ofrecen el servicio en su servidor de correo, Internet o la parte interna que forma Linux. Por la experiencia adquirida en el trabajo con Suse, el integrador es socio de Novell. A la fecha 80% de sus servicios corren sobre Linux y el porcentaje restante es en Unix.

AHORRO Y DESEMPEO El entrevistado seal a eSemanal que una de las razones por las cuales trabajan con Linux es por el desempeo, ms que por ahorro de dinero, en el caso de las grandes empresas que requieren servidores de misin crtica; sin embargo, en la parte de licenciamiento para las medianas compaas, el ahorro en costos es bastante significativo. La resistencia del mercado para adoptar las soluciones basadas en software libre sigue existiendo y de acuerdo con la experiencia de Magnabyte, el principal temor que han encontrado con los prospectos de clientes es que piensan que al adoptar Linux tienen que cambiar su actual infraestructura.

El enfoque que hacemos es que se puede hacer una red hbrida; es decir, tener estaciones de trabajo con otro tipo de sistemas operativos y servidores de misin crtica con Linux. Es el temor de cambiar todo en lo que han invertido; sin embargo, pueden convivir ambos sistemas. En estaciones de trabajo, la compaa ha observado que en algunas reas es conveniente cambiar el sistema operativo por Linux; por ejemplo, en cuanto a ERP, inventarios, manufactura, produccin o el uso de otras aplicaciones de este tipo es conveniente Linux, ya que implica ahorro en licenciamiento de sistemas operativos e incluso en lo correspondiente a seguridad. Con respecto a que en el futuro se manejen esquemas de funcionamiento de software Linux con aplicaciones propietarias en las empresas, el entrevistado destac que cada da se ve ms este fenmeno en la industria, el gobierno y muchas otras instituciones que ya trabajan con Linux. Hay casos en el gobierno que han cambiado todo, inclusive hasta sus lenguajes de desarrollo hacia plataformas totalmente GNU sin estar pagando licenciamiento. Creo que al principio haba el tab de que Linux era para universidades o slo para estudiantes; hoy por hoy ese mito se ha superado, as tambin como en el tema de GNU que ya se trabajan en corporativos, a nivel Pyme y gobierno. EL SERVICIO ES RENTABLE Respecto de que el negocio de trabajar con Linux radica en el soporte, servicio y capacitacin que debe dar el distribuidor. El integrador opin que para muchas empresas este es el foco de su negocio, pero para Magnabyte se maneja como un servicio, pues su objetivo principal es la lnea de soluciones.

Proveerles herramientas empresariales bsicamente es un servicio adicional que se ofrece a un costo realmente accesible. Da con da se ve gente esta interesada en la tecnologa e incluso dominan Linux, agreg. Para finalizar, Flores detall que se observa cmo las ventajas de utilizar software o GNU en servidores de misin crtica para aplicaciones empresariales es una excelente opcin de respuesta y con disponibilidad del 100%, y est muy ligado con las plataformas de base de datos y aplicaciones REDUCIR COSTOS Y ENTREGAR VALOR De acuerdo con Sebastin Cao, Ingeniero de Ventas de Red Hat para AL, una de las distribuciones ms nombradas de Linux, existen amplias expectativas de negocio para los integradores porque las empresas medianas y grandes ya estn pidiendo soluciones con

aplicaciones de software libre, toda vez que se han dado cuenta que su valor es mayor que el de cdigos cerrados. Explic, adems, que existen varias soluciones que van desde el sistema operativo ms bajo, un motor de procesos o herramientas para SOA y tiene productos en todos esos niveles de cdigo libre. Al venderse en el modelo de suscripcin, lo nico por lo que paga el cliente es por el soporte, y al no haber licencia se reducen los costos, mencion el experto de Red Hat, al tiempo que resalt que inclusive en las grandes empresas los presupuestos de TI estn a la baja, pero sus requerimientos al alta. En este sentido, a la estrategia SOA tiene ms justificacin, sobre todo para que las empresas sean cada vez ms giles con el fin de responder a las tendencias del mercado, a la competencia o al lanzamiento de nuevos productos o procesos. La compaa del sombrero rojo tiene dos divisiones; por un lado est Red Hat Enterprice Linux, sistema operativo que brinda una distribucin de Linux preparada para misin crtica, con la salvedad de soportar software de logstica como empresa en la parte de soporte. Por otro lado, dispone de herramientas de integracin de aplicacin y desarrollo para Java Enterprise Edition, donde dispone las formas estndares que cumplen con las industrias que permite a las empresas desarrollar sobre el lenguaje de Sun. Para finalizar, el ejecutivo mencion: El objetivo de reducir los costos no slo es por el precio, si no por el tema del valor y pagar soporte no el software se aplica a todas las empresas. En cuanto a gobierno, es importante decir que nuestra regin est muy fuerte el apoyo de varios gobiernos, explcitamente a OpenSource sobre plataformas comerciales en varios.

CALIDAD DEL SOFTWARE 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 software de la mejor calidad posible, que cumpla, y si puede supere las expectativas de los usuarios.

Es la cualidad de todos los productos, no solamente de equipos sino tambin de programas.

En el desarrollo de software, la calidad de diseo acompaa a la calidad de los requisitos, especificaciones y diseo del sistema. La calidad de concordancia es un aspecto centrado

principalmente en la implementacin; Si la implementacin sigue al diseo, y el sistema resultante cumple con los objetivos de requisitos y de rendimiento, la calidad de concordancia es alta. Se puede seguir los siguientes aspectos para evaluar la calidad del software: CALIDAD DE SOFTWARE Caractersticas propias del software aquellas que tu quieres controlar y asegurar, el software es un producto inmaterial que no se fabrica, tampoco se degradan fsicamente, sino que se desarrolla. El software puede tener errores, incidencias pero no son similares a lo que cualquier equipo de carcter fsico. La calidad del software se encuentra casi a la par de la calidad tradicional, ligeramente detrs debido a que la calidad tradicional tiene varias dcadas de historia, mientras que la calidad de software tiene entre 50 y 30 aos de haber surgido. CERTIFICACIN DEL SOFTWARE Consecuencia de un proceso que es asegurar la calidad pero nunca es el objetivo final. La calidad de software no se certifica, lo que se certifica son los procedimientos para construir un software de calidad, los procedimientos deben ser correctos y estar en funcin de la normalizacin (ISO 9000, CMMI, MoProSoft...). NORMATIVA ISO 9000 Pone a disposicin de un auditor o certificador los procesos internos, de forma que este indique si cumple o no la normativa al 100%, audita el sistema; Si los resultados son positivos se emite la certificacin y cada cierto tiempo se tiene que renovar; La certificacin es costosa, a consecuencia de costes que ocasionan la lejana y el tiempo de duracin de proceso (aprox. 6 meses). Se certifica la empresa y la metodologa para el desarrollo de la aplicacin. MEDICIN DEL SOFTWARE En el software lo que se mide son atributos propios del mismo, se descompone un atributo general en otros ms simples de medir, a veces se mide bien o mal ya que la descomposicin del atributo genrico de calidad en otros sub-atributos se torna irreal, se mide con datos estadsticos no avalados, es imposible decir que la medicin se hace en forma correcta. El concepto de medida va de ms a menos, va de lo general a lo concreto y lo concreto es asociado a la mtrica, cuya combinacin te dara el nivel de calidad o seguridad de tu producto. Las ciencias bien estructuradas se basan en medidas bien hechas, se basan en la matemtica.

TIPOS DE MEDIDAS

Nmero de errores durante un periodo determinado. Fallo en la codificacin o diseo de un sistema que causa que el programa no funcione correctamente o falle.

Tamao de un producto informtico (lneas de cdigo) Mtrica de punto funcin (IBM): relaciona funcionalidades que ofreca. Estimacin de costes y esfuerzos. COCOMO

UTILIDAD DE LA MEDIDA DEL SOFTWARE Consecuencia de su proceso interno de asegurar la calidad, cuantificar los atributos que constituyen la calidad para el usuario final, ah tenemos los resultados cuantitativos. Saber que aquello que al usuario final le interesa lo tenga o no un producto y permita cuantificar almacenar otros productos.

Normativa ISO 9126, medida de la calidad de software descomponiendo atributos, para no tener mrgenes de error e interpretacin. Atributo de funcionalidad. Atributo de capacidad de respuesta frente a errores externos. Atributo de nivel de seguridad. La calidad no puede existir sin seguridad, un producto sin seguridad seria un producto sin calidad. El observador o usuario final indica que atributos ms o menos importantes de seguridad.

CALIDAD GLOBAL SISTMICA Y LOS MODELOS DE CALIDAD Callaos y Callaos proponen un concepto de calidad del software en el cual estn involucrados tanto caractersticas internas como el contexto organizacional, lo que genera un enfoque sistmico del concepto de Calidad del Software. Este enfoque es considerado tambin por Dromey y, particularmente reforzado por Voas, cuando se refiere al Tringulo de la Certificacin de la Calidad del Software. La definicin de calidad sistmica en el desarrollo de los Sistemas de Informacin consta de cuatro (4) tipos de Calidades: Eficiencia del Producto, Efectividad del Producto, Eficiencia del Proceso y efectividad del Proceso, considerando las dimensiones del Cliente y del Usuario. Esta divisin se justifica en un sentido, porque un proyecto incluye tanto la eficiencia como la efectividad y en el

otro, porque el Sistema concebido (el producto) es diferente al Sistema de las actividades humanas (el proceso) mediante el cual el Sistema-Producto es diseado. Segn Callaos, la calidad global no es la suma de las calidades parciales, sino el compromiso entre todo el conjunto de calidades que conlleve a un ptimo global con cierto sacrificio de los ptimos parciales. Para establecer con mayor detalle los atributos que garantizan la calidad del proceso y del producto basados en el enfoque de Calidad Sistmica, el Laboratorio de Investigacin en Sistemas de Informacin (LISI) de la Universidad Simn Bolvar propuso dos modelos de calidad con enfoque sistmico: uno enfocado hacia el producto y otro hacia el proceso. El primer modelo enlaza las ideas del Estndar ISO/IEC 9126 para el producto y del Modelo de Dromey. El resultado es un conjunto de atributos que deben estar presentes en un sistema de calidad y los factores que influencian a stos, los cuales se agrupan en cuatro (4) grupos representados por las cuatro (4) dimensiones del enfoque de Callaos. El segundo modelo desarrollado en LISI, integra el enfoque de calidad sistmica con las caractersticas presentes en el modelo de procesos SPICE, adaptado a la realidad venezolana, conformado por una jerarqua de 5 niveles: Ciclos de Vida, Categoras, Procesos, Principios, y Bases Prcticas, que son un conjunto de directrices a ser ejecutadas por la organizacin para lograr alcanzar un principio. Este modelo garantiza el balance entre la eficiencia y la efectividad del proceso de desarrollo a travs de una propuesta

Estudio del Modelo Sistmico de Calidad ,como Instrumento para la Evaluacin de Calidad en Sistemas de Software de Tres Capas Con el transcurrir del tiempo, las empresas han venido dando importancia a la verificacin y determinacin de la calidad de los sistemas de software, de los cuales un tipo que han tenido un gran crecimiento en la organizaciones es aquel que tiene una conformacin estructural de tres capas, lo cual se ha hecho muy relevante en las aplicaciones de software orientadas a satisfacer las funciones administrativas de las organizaciones, rea que requiere software de calidad para de esta forma estar acordes a las necesidades existentes en la organizacin. Adicionalmente, hoy en da las organizaciones han considerado la importancia que tiene el conocer la calidad de los instrumentos que utiliza para la realizacin de las labores, lo que hace que en la actualidad sea absolutamente necesario el poder contar con instrumentos claros y precisos para realizar la evaluacin de los sistemas. A nivel mundial y especficamente en sistemas automatizados, se ha desarrollado una gran cantidad de modelos para realizar estas labores, ms aun, una de las organizaciones que ha trabajado arduamente en este aspecto es la Universidad Simn Bolvar en Venezuela, en su laboratorio de investigacin en Sistemas de informacin (LISIUSB), ya que ha consolidado estudios al crear una metodologa para la evaluacin de sistemas de software denominada Modelo Sistmico de Calidad MOSCA. Ahora bien, es muy importante determinar si esta metodologa es un instrumento eficiente para la evaluacin de cualquier tipo software especialmente software de tres capas. De all que sea, el objetivo de este trabajo estudiar el Modelo Sistmico de Calidad MOSCA, el cual plantea un Marco para evaluar la calidad de software. Este trabajo est concebido bajo un diseo bibliogrfico y de campo, pues fueron revisadas fuentes

documentales bibliogrficas, se aplic un instrumento de medicin y la observacin directa en un caso de estudio real finalmente la modalidad se corresponde con un proyecto factible sobre la base de un estudio documental, lo cual conlleva el anlisis de una situacin desde el punto de vista terico y prctico para generar una propuesta de aplicacin del modelo sistmico de calidad de software MOSCA para la evaluacin de este tipo de software, puede considerar tanto los aspectos tcnicos como los procesos con los cuales se desarrolla el mismo. Como ejemplo de software de tres capas se usar un sistema administrativo, se enumeran una seria de requerimientos, ya que el mismo debe satisfacer las expectativas relacionadas con las variables de calidad exigidas para las funcionalidades de un sistema en particular, tales como, seguridad, mantenibilidad, modificabilidad, escalabilidad, modularidad, alta calidad, tiempos cortos de entrega, cumplimiento de normas, menos costos, libre de errores, entre otros. En Venezuela no se cuenta con estndares para evaluar este tipo de sistemas, los cuales son fundamentales para precisar la calidad de software, sea este un desarrollo propio o adquirido por una empresa. Para ello se utiliz el modelo sistmico de calidad de software MOSCA tomando en cuenta los aspectos tcnicos del producto y los procesos implicados directamente, y de esta forma presentas la aplicacin del modelo. Palabras Claves: calidad de software, modelo de calidad, Mosca, software de tres capas, medicin de calidad

CONCLUSIN No se puede medir la calidad del software de forma correcta debido a su naturaleza, la certificacin se da a los procesos, la correcta consecucin de los mismos garantizara un buen software. No se puede medir al software como tal, sino los atributos que la conforman, tales mtodos de medida deben ser exactos. El usuario final mide la calidad del software segn lo que tenga o no, es en ese sentido de que la calidad del software depende de quien la juzgue. El hecho de que una empresa tenga certificacin en calidad de software no garantiza que su software sea de calidad.