UNIVERSIDAD DE CARABOBO Facultad Experimental de Ciencias y Tecnologa Departamento de Computacin

Construccin y Pruebas de Software

Elaborado por: Gustavo Bazn Francisco Rosas

Brbula, Junio de 2012

Introduccin
La construccin de software es el proceso en el cual se genera el programa que pueda ejecutarse, esta construccin est altamente ligada al diseo del sistema y a su vez estar muy relacionado con las prueba que validen la correctitud del sistema. Debido a la facilidad con la que se pueden realizar proyectos de software enfocndose solo en los aspectos de la construccin, este tipo de enfoque puede llegar a afectar la calidad del cdigo, y por ende la calidad del producto final. Es por ello que la construccin debe tomar en cuenta sus relaciones con el diseo, y siempre resultara de importancia la capacidad de poder verificar el software que se esta construyendo, es en esta parte donde se emplean las pruebas, que permitirn comprobar el estado del software.

Construccin de Software
El trmino Software Construction (Construccin del software) se refiere a la creacin de software productivo y significativo a travs de los procesos de codificacin, verificacin, pruebas unitarias, pruebas de integracin y depuracin de errores. El rea del conocimiento de la 'construccin del software' est ntimamente relacionada a las otras reas del conocimiento del software como lo son: el diseo, las pruebas, la gestin de configuraciones, la calidad y las herramientas y mtodos Los lmites entre el diseo y la construccin variaran dependiendo del proceso de ciclo de vida del software utilizado en el proyecto. Aunque ciertas tareas de diseo puedan ser desarrolladas antes del proceso de construccin, gran parte del trabajo de diseo es realizado en si, durante el proceso de construccin. Software que se construye deber ser validado y verificado, en esta rea suelen emplearse pruebas de software, mostrando as como la salida de la construccin ser la entrada de las pruebas. Los ingenieros del software suelen realizar pruebas unitarias y pruebas de integracin, demostrando as la cercana que existen entre el rea de conocimiento de la 'construccin del software' y el rea de las 'pruebas del software'. Tpicamente la 'construccin del software' produce el mayor volumen de tems configurables que necesitan ser manejados en un proyecto de software (cdigo fuente, contenido, casos de uso, etc). Es por ello que el rea de 'construccin del software' tambin est ntimamente relacionada con el 'gerencia de configuraciones del software'. Mientras la calidad del software es importante en todas las reas del conocimiento, el cdigo es uno de los entregables primordiales en un proyecto de software, y por lo tanto la 'calidad del software' est muy ligada a la 'construccin del software'.

Desde que la 'construccin del software' depende altamente en las herramientas y mtodos, y es probablemente el rea de conocimiento que haga el uso ms intensivo de herramientas. Esto demuestra el enlace tan fuerte que tiene el rea de 'construccin del software' con el rea de 'herramientas y mtodos del software La ingeniera de software dentro del rea de la construccin busca, minimizar la complejidad, anticipar los cambios, construir teniendo en cuenta la verificacin, construir usando estndares.

Minimizar la complejidad
La necesidad de reducir la complejidad aplica esencialmente a cada aspecto de la 'construccin del software', y es particularmente crtica en el proceso de verificacin y pruebas. La reduccin de la complejidad se consigue haciendo nfasis en que el cdigo creado tiene que ser sencillo y legible ms que inteligente. La aplicacin de las buenas prcticas del lenguaje que se est empleando as como estndares de desarrollo suele ayudar a reducir la complejidad. Se debe considerar que la legibilidad y sencillez de cdigo puede afectar el rendimiento de la aplicacin, es por ello que resulta conveniente siempre evaluar los requisitos tanto funcionales como no funcionales en aras de establecer un balance entre legibilidad y mantenibilidad contra rendimiento y tiempos de respuesta y saber en donde es conveniente mantener mas de uno que otro.

Anticipar Cambios
La naturaleza de los proyectos de software hace que en su gran mayora sean desarrollos un gran nmero de cambios y nuevos requerimientos que van surgiendo durante la ejecucin del mismo. Es por ello que los ingenieros del software deben ser capaces de prever este tipo de situaciones y planificar y gestionar el proyecto de forma tal que sea posible reaccionar a tiempo a estos cambios, donde quien se ve mayor mente afectada es la fase de construccin quien puede tener que re implementar funcionalidades o generar nuevas antes no contempladas. Este es uno de los motivos por los cuales es importante desarrollar sistemas que puedan ser mantenibles, ya que facilita estos procesos de modificacin y actualizacin.

Construccin Segn Modelos de Desarrollo

Lo que es considerado como 'construccin' depender en cierto grado del modelo de software utilizado. Mientras ms linear sea el enfoque ms se tiende a enfatizar en las actividades que preceden al proceso de construccin. Otros modelos son ms iterativos y tienden a tratar el proceso de construccin como una actividad que ocurre concurrentemente con otras actividades del desarrollo del Software.

Planificacin de la construccin
La eleccin del mtodo de construccin afecta en cierta forma como son realizados los prerrequisitos de la construccin, afecta la habilidad del proyecto de disminuir la complejidad, anticipar el cambio, y la construccin en funcin de la verificacin. Cada uno de estos objetivos puede tambin ser considerados en el nivel del proceso, requerimientos o diseo; pero tambin pueden ser influenciados por la eleccin del mtodo de construccin. La planificacin de la construccin puede definir el orden en que los componentes del Software son creados e

integrados, los procesos de gestin de calidad del Software, el posicionamiento de las asignaciones a los ingenieros del software, y otras tareas, de acuerdo obviamente al mtodo elegido.

Medicin de la construccin
Numerosas actividades de la construccin y ciertos artefactos deben ser medidos, incluyendo el cdigo desarrollado, el cdigo modificado, el cdigo re-usado, el cdigo destruido, la complejidad del cdigo, las estadsticas del cdigo, bsqueda y eliminacin de errores, esfuerzo y calendario. Estas medidas pueden ser tiles para los propsitos de la gerencia de la construccin, asegurando la calidad durante la construccin, mejorando tambin el proceso de construccin. La construccin es una actividad en la cual el Software tiene que lidiar con las restricciones arbitrarias y caticas provenientes del mundo real, y cumplirlas exactamente. Debido a la proximidad con las restricciones del mundo real, la construccin es manejada por consideraciones del orden prctico, y en medida muchas que otras reas del conocimiento, y por lo tanto la ingeniera del software es quizs mucho ms artesanal en el rea de 'construccin del software.'

Diseo de la Construccin
Algunos proyectos suelen colocar ms actividades de diseo en la construccin, otros tienden a tener una fase exclusivamente a diseo. Sin importar cul es el carcter exacto, varios trabajos de diseo ocurrirn en la construccin, y ese trabajo de diseo se regir por los lmites impuestos por el problema de la vida real que est buscando resolver el software.

Lenguaje de Construccin
Los lenguajes de construccin incluyen todas las formas de comunicacin por las cuales el ser humano puede implantar una solucin ejecutable al computador. Se pueden dividir en: 'lenguaje de configuracin', Toolkits Lenguajes de programacin.

Re-uso
Implementar el re-uso del software involucra mucho ms que crear libreras. Requiere formalizar la prctica del re-uso al integrar procesos de re-uso y actividades dentro del ciclo de vida del software. Sin embargo, el re-uso es lo suficientemente importante en la construccin del software que es incluido como un tpico.

Pruebas de Software
Las pruebas de Software tienen 2 objetivos: Demostrar al desarrollador y al cliente que el software alcanza sus requisitos. En el caso de software hecho a la medida esto representa que debe existir al menos 1 prueba por cada requerimiento. Para software preempaquetado significa que debe existir al menos 1 prueba por cada funcionalidad y sus combinaciones Descubrir situaciones donde el comportamiento del software es incorrecto, indeseable o no esta ajustado a las especificaciones. Estas son las consecuencias de defectos del software.

El primer objetivo lleva a la prueba de validacin, donde se espera que el sistema funcione correctamente usando casos de prueba especficos que reflejen el uso esperado del sistema. El segundo objetivo lleva a la prueba de defectos, donde los casos de prueba son diseados para exponer potenciales errores. Los casos de prueba para detectar defectos, pueden ser intencionalmente oscuros y no reflejar como es usado el sistema normalmente. Estos dos enfoques de prueba no son exclusivos el uno del otro, y en ocasiones se encontraran defectos del sistema durante pruebas de validacin y viceversa. Las pruebas no pueden demostrar que un software esta libre de defectos o que siempre se comportara segn lo especificado en cada circunstancia. Siempre es posible que una prueba que se haya pasado por alto lleve a problemas con el sistema. Las pruebas forman parte de un proceso mayor llamado verificacin y validacin. Validacin: Estamos construyendo el producto adecuado? Verificacin: Estamos construyendo bien el producto?

Este proceso de verificacin y validacin se asegura que el software desarrollado alcance las expectativas de la gente que esta pagando por el producto. Este proceso se inicia tan pronto existan requerimientos y contina a lo largo de las etapas de desarrollo. La verificacin apunta a revisar que el producto alcance los requerimientos funcionales y no funcionales. La validacin sin embargo es un proceso ms general donde se busca validar que el software satisfaga las expectativas del cliente. Recordemos que los requerimientos no siempre reflejan los deseos del cliente y es por ello que la validacin es tan importante. Adicionalmente de las pruebas de software el proceso de verificacin y validacin puede involucrar inspecciones y revisiones de software, estas analizan y revisan los requerimientos de sistema, los modelos de diseo, el cdigo fuente e incluso las pruebas propuestas. Estas inspecciones suelen enfocarse generalmente en el cdigo fuente pero cualquier representacin o modelo del software es inspeccionable. Mediante el conocimiento del sistema, el dominio de la aplicacin, el lenguaje de programacin o modelado se pueden llegar a descubrir errores.

Las inspecciones suelen representar en mayor parte la manera en la que se descubren fallas del sistema, aun as estas no pueden remplazar las pruebas de software, debido a que no son buenas para descubrir errores que pueden surgir de interacciones inesperadas, problemas de tiempo o problemas de desempeo.

Pruebas de Desarrollo
El probador del software es usualmente el programador que desarrollo el producto, aunque este no siempre es el caso. Suelen emplearse 3 niveles al momento de realizar las pruebas. 1. Pruebas Unitarias, donde partes individuales del programa u objetos de las clases son probadas. Estas pruebas se deben enfocar en probar las funcionalidades de objetos o mtodos. 2. Pruebas de Componentes, donde varias pruebas unitarias son integradas para crear componentes compuestos. Estas pruebas deben enfocarse en probar las interfaces de los componentes. 3. Pruebas de Sistema, donde algunos o toso los componentes en un sistema son integrados, probando el sistema como un todo. Estas pruebas se enfocan en probar las interacciones de los componentes.

Test-Driven Development
El desarrollo orientado a pruebas (TDD) es un en foque de desarrollo donde se intercalan las actividades de prueba y codificacin. Esencialmente se desarrolla el cdigo incrementalmente, junto con una prueba para ese incremento.

Una de las ventajas de TDD es que ayuda a los programadores a entender lo que un segmento de cdigo debe hacer, y a su vez este entendimiento facilita la escritura del cdigo. Adicionalmente tenemos: Cobertura del cdigo: como cada segmento de cdigo debe tener al menos una prueba asociada, podemos estar seguros que todo el cdigo del sistema ha sido ejecutado. El cdigo es probado mientras se escribe por ende los defectos son encontrados en etapas tempranas del desarrollo Pruebas de regresin: se pueden ejecutar pruebas anteriores, garantizando que cambios en el programa no introduzcan nuevas fallas.

Debugging simplificado: cuando una prueba falla debera ser obvio donde esta el problema, El cdigo recientemente escrito necesita ser revisado y modificado. Documentacin del sistema: estas pruebas funcionan a su vez como documentacin de lo que el cdigo debera estar haciendo

Pruebas de lanzamiento
Estas pruebas consisten en permitir que grupos ajenos al equipo de desarrollo interacten y evalen el sistema desarrollado, estas pruebas suelen tener diferentes enfoques segn lo que se desee evaluar, ya sea validando contra los requisitos, simulando posibles escenarios de uso de la aplicacin brindando un aproximado de lo que ser la implantacin final del sistema, o bien enfocarse en probar el rendimiento de la aplicacin y se responde segn los parmetros establecidos para la prueba.

Pruebas de usuario
Consiste en permitir a los usuarios o clientes evaluar versiones preliminares de la aplicacin para poder recibir comentarios con respecto a funcionalidades o posibles fallas. Segn el estado de funcionalidad en el que se encuentre el sistema y el numero y tipo de usuario a los que este dirigido estas pruebas pueden llamarse Alfa, para un muy reducido numero de usuarios y muchas posibles fallas aun por corregir, o Beta, mayor numero de usuarios y una aplicacin bastante cercana a la aplicacin final.

Conclusiones
Los proyectos de software tiene como finalidad la entrega de un producto funcional y que cubra las expectativas del cliente, la mayor cantidad de esfuerzo a este tipo de proyecto suele darse a la fase de construccin. Pero bien es cierto que grandes equipos de trabajo o recursos ilimitados dedicados exclusivamente a la construccin de software sean garanta de alcanzar los objetivos finales. Es por ello que es importante la relacin que existe entre la construccin, el anlisis y el diseo de las diferentes funcionalidades, y la importancia de construir software empleando de la mejor manera las herramientas disponibles as como los principios y mtodos asociados a lenguajes, frameworks y marcos de trabajo, para contar no solo con un buen producto sino con un cdigo que pueda ser mantenible a travs del tiempo. De igual manera una de las grandes herramientas en las cuales se puede apoyar la construccin para mejorar la calidad del cdigo esta en las pruebas de software, bien sea realizando pruebas al final del proceso de construccin, o empleando tcnicas de construccin orientada a pruebas, es importante contar con formas de poder verificar el producto y que si bien no se podr garantizar este libre de fallas se estar seguro que el comportamiento ser el deseado. Al final de todos estos procesos lo importante ser siempre validar con los clientes o usuarios que sus expectativas han sido alcanzadas y se les esta brindando una herramienta con la cual obtienen beneficio real al usar dicha herramienta.

Bibliografa
Beck, K. (2002). Test Driven Development: By Example. Addison-Wesley Longman. Chelimsky, D., Astels, D., Dennis, Z., Hellesy, A., Helmkamp, B., & North, D. (2010). The RSpec Book. The Pragmatic Programmers LLC. IEE Computer Society. (2004 ). Guide to the Software Engineering Body of Knowledge (SWEBOK). North, D. (2006). DanNorth.net. Recuperado el 14 de Junio de 2012, de Introducing BDD: http://dannorth.net/introducing-bdd/ Sommerville, I. (2010). Ingeniera del software. Adison Wesley.