Construcción y Pruebas de Software

Transcripción

1 UNIVERSIDAD DE CARABOBO Facultad Experimental de Ciencias y Tecnología Departamento de Computación Construcción y Pruebas de Software Elaborado por: Gustavo Bazán Francisco Rosas Bárbula, Junio de 2012

2 Introducción La construcción de software es el proceso en el cual se genera el programa que pueda ejecutarse, esta construcción está altamente ligada al diseño 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 enfocándose solo en los aspectos de la construcción, este tipo de enfoque puede llegar a afectar la calidad del código, y por ende la calidad del producto final. Es por ello que la construcción debe tomar en cuenta sus relaciones con el diseño, 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 permitirán comprobar el estado del software. Construcción de Software El término Software Construction (Construcción del software) se refiere a la creación de software productivo y significativo a través de los procesos de codificación, verificación, pruebas unitarias, pruebas de integración y depuración de errores. El área del conocimiento de la 'construcción del software' está íntimamente relacionada a las otras áreas del conocimiento del software como lo son: el diseño, las pruebas, la gestión de configuraciones, la calidad y las herramientas y métodos Los límites entre el diseño y la construcción variaran dependiendo del proceso de ciclo de vida del software utilizado en el proyecto. Aunque ciertas tareas de diseño puedan ser desarrolladas antes del proceso de construcción, gran parte del trabajo de diseño es realizado en si, durante el proceso de construcción. Software que se construye deberá ser validado y verificado, en esta área suelen emplearse pruebas de software, mostrando así como la salida de la construcción será la entrada de las pruebas. Los ingenieros del software suelen realizar pruebas unitarias y pruebas de integración, demostrando así la cercanía que existen entre el área de conocimiento de la 'construcción del software' y el área de las 'pruebas del software'. Típicamente la 'construcción del software' produce el mayor volumen de ítems configurables que necesitan ser manejados en un proyecto de software (código fuente, contenido, casos de uso, etc). Es por ello que el área de 'construcción del software' también está íntimamente relacionada con el 'gerencia de configuraciones del software'. Mientras la calidad del software es importante en todas las áreas del conocimiento, el código es uno de los entregables primordiales en un proyecto de software, y por lo tanto la 'calidad del software' está muy ligada a la 'construcción del software'.

3 Desde que la 'construcción del software' depende altamente en las herramientas y métodos, y es probablemente el área de conocimiento que haga el uso más intensivo de herramientas. Esto demuestra el enlace tan fuerte que tiene el área de 'construcción del software' con el área de 'herramientas y métodos del software La ingeniería de software dentro del área de la construcción busca, minimizar la complejidad, anticipar los cambios, construir teniendo en cuenta la verificación, construir usando estándares. Minimizar la complejidad La necesidad de reducir la complejidad aplica esencialmente a cada aspecto de la 'construcción del software', y es particularmente crítica en el proceso de verificación y pruebas. La reducción de la complejidad se consigue haciendo énfasis en que el código creado tiene que ser sencillo y legible más que inteligente. La aplicación de las buenas prácticas del lenguaje que se esté empleando así como estándares de desarrollo suele ayudar a reducir la complejidad. Se debe considerar que la legibilidad y sencillez de código puede afectar el rendimiento de la aplicación, 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 mayoría sean desarrollos un gran número de cambios y nuevos requerimientos que van surgiendo durante la ejecución 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 construcción 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 modificación y actualización. Construcción Según Modelos de Desarrollo Lo que es considerado como 'construcción' dependerá en cierto grado del modelo de software utilizado. Mientras más linear sea el enfoque más se tiende a enfatizar en las actividades que preceden al proceso de construcción. Otros modelos son más iterativos y tienden a tratar el proceso de construcción como una actividad que ocurre concurrentemente con otras actividades del desarrollo del Software. Planificación de la construcción La elección del método de construcción afecta en cierta forma como son realizados los prerrequisitos de la construcción, afecta la habilidad del proyecto de disminuir la complejidad, anticipar el cambio, y la construcción en función de la verificación. Cada uno de estos objetivos puede también ser considerados en el nivel del proceso, requerimientos o diseño; pero también pueden ser influenciados por la elección del método de construcción. La planificación de la construcción puede definir el orden en que los componentes del Software son creados e

4 integrados, los procesos de gestión de calidad del Software, el posicionamiento de las asignaciones a los ingenieros del software, y otras tareas, de acuerdo obviamente al método elegido. Medición de la construcción Numerosas actividades de la construcción y ciertos artefactos deben ser medidos, incluyendo el código desarrollado, el código modificado, el código re-usado, el código destruido, la complejidad del código, las estadísticas del código, búsqueda y eliminación de errores, esfuerzo y calendario. Estas medidas pueden ser útiles para los propósitos de la gerencia de la construcción, asegurando la calidad durante la construcción, mejorando también el proceso de construcción. La construcción es una actividad en la cual el Software tiene que lidiar con las restricciones arbitrarias y caóticas provenientes del mundo real, y cumplirlas exactamente. Debido a la proximidad con las restricciones del mundo real, la construcción es manejada por consideraciones del orden práctico, y en medida muchas que otras áreas del conocimiento, y por lo tanto la ingeniería del software es quizás mucho más artesanal en el área de 'construcción del software.' Diseño de la Construcción Algunos proyectos suelen colocar más actividades de diseño en la construcción, otros tienden a tener una fase exclusivamente a diseño. Sin importar cuál es el carácter exacto, varios trabajos de diseño ocurrirán en la construcción, y ese trabajo de diseño se regirá por los límites impuestos por el problema de la vida real que está buscando resolver el software. Lenguaje de Construcción Los lenguajes de construcción incluyen todas las formas de comunicación por las cuales el ser humano puede implantar una solución ejecutable al computador. Se pueden dividir en: 'lenguaje de configuración', Toolkits Lenguajes de programación. Re-uso Implementar el re-uso del software involucra mucho más que crear librerías. Requiere formalizar la práctica 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 construcción del software que es incluido como un tópico.

5 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 validación, donde se espera que el sistema funcione correctamente usando casos de prueba específicos que reflejen el uso esperado del sistema. El segundo objetivo lleva a la prueba de defectos, donde los casos de prueba son diseñados 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 validación y viceversa. Las pruebas no pueden demostrar que un software esta libre de defectos o que siempre se comportara según 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 verificación y validación. Validación: Estamos construyendo el producto adecuado? Verificación: Estamos construyendo bien el producto? Este proceso de verificación y validación 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 continúa a lo largo de las etapas de desarrollo. La verificación apunta a revisar que el producto alcance los requerimientos funcionales y no funcionales. La validación sin embargo es un proceso más 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 validación es tan importante. Adicionalmente de las pruebas de software el proceso de verificación y validación puede involucrar inspecciones y revisiones de software, estas analizan y revisan los requerimientos de sistema, los modelos de diseño, el código fuente e incluso las pruebas propuestas. Estas inspecciones suelen enfocarse generalmente en el código fuente pero cualquier representación o modelo del software es inspeccionable. Mediante el conocimiento del sistema, el dominio de la aplicación, el lenguaje de programación o modelado se pueden llegar a descubrir errores.

6 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 desempeño. 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 métodos. 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 codificación. Esencialmente se desarrolla el código 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 código debe hacer, y a su vez este entendimiento facilita la escritura del código. Adicionalmente tenemos: Cobertura del código: como cada segmento de código debe tener al menos una prueba asociada, podemos estar seguros que todo el código del sistema ha sido ejecutado. El código es probado mientras se escribe por ende los defectos son encontrados en etapas tempranas del desarrollo Pruebas de regresión: se pueden ejecutar pruebas anteriores, garantizando que cambios en el programa no introduzcan nuevas fallas.

7 Debugging simplificado: cuando una prueba falla debería ser obvio donde esta el problema, El código recientemente escrito necesita ser revisado y modificado. Documentación del sistema: estas pruebas funcionan a su vez como documentación de lo que el código debería estar haciendo Pruebas de lanzamiento Estas pruebas consisten en permitir que grupos ajenos al equipo de desarrollo interactúen y evalúen el sistema desarrollado, estas pruebas suelen tener diferentes enfoques según lo que se desee evaluar, ya sea validando contra los requisitos, simulando posibles escenarios de uso de la aplicación brindando un aproximado de lo que será la implantación final del sistema, o bien enfocarse en probar el rendimiento de la aplicación y se responde según los parámetros establecidos para la prueba. Pruebas de usuario Consiste en permitir a los usuarios o clientes evaluar versiones preliminares de la aplicación para poder recibir comentarios con respecto a funcionalidades o posibles fallas. Según 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 aplicación bastante cercana a la aplicación 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 construcción. Pero bien es cierto que grandes equipos de trabajo o recursos ilimitados dedicados exclusivamente a la construcción de software sean garantía de alcanzar los objetivos finales. Es por ello que es importante la relación que existe entre la construcción, el análisis y el diseño de las diferentes funcionalidades, y la importancia de construir software empleando de la mejor manera las herramientas disponibles así como los principios y métodos asociados a lenguajes, frameworks y marcos de trabajo, para contar no solo con un buen producto sino con un código que pueda ser mantenible a través del tiempo. De igual manera una de las grandes herramientas en las cuales se puede apoyar la construcción para mejorar la calidad del código esta en las pruebas de software, bien sea realizando pruebas al final del proceso de construcción, o empleando técnicas de construcción 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.

8 Bibliografía Beck, K. (2002). Test Driven Development: By Example. Addison-Wesley Longman. Chelimsky, D., Astels, D., Dennis, Z., Hellesøy, 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: Sommerville, I. (2010). Ingeniería del software. Adison Wesley.