Anteproyecto Fin de Carrera

Universidad de Castilla-La Mancha Escuela Superior de Informática Anteproyecto Fin de Carrera DIMITRI (Desarrollo e Implantación de Metodologías y Tecnologías de Testing) Dirige: Macario Polo Usaola Presenta: Miguel Millán Sánchez-Grande Octubre de 2011

Índice general 1. Introducción 3 2. Objetivos 5 3. Método y fases de trabajo 7 4. Medios que se pretenden utilizar 9 4.1. Hardware............................. 9 4.2. Software.............................. 9 2

CAPÍTULO 1 Introducción El proyecto que se va a desarrollar gira en torno al proceso de pruebas dentro del ciclo de vida de software, pero antes de introducir o destacar la importancia de este proceso, se va a definir el ciclo de vida software. Partiendo de las definiciones que se pueden recoger de [1], se puede decir que el ciclo de vida software es el conjunto de procesos, actividades y tareas que se sigue para construir, entregar y hacer evolucionar el software, desde la concepción de una idea hasta la entrega del sistema que la implementa, pasando por su construcción y utilización, y abarcando hasta que el sistema se retira. Los ciclos de vida software está formado por una serie de procesos, cada uno de estos procesos está formado a su vez por un conjunto de actividades y estas a su vez por tareas. Dentro los procesos de un ciclo de vida software están muy presentes las pruebas software, ya sea para probar el software en sí como para probar que un pequeño apartado cumple correctamente lo que se espera de él. Por qué son importantes las pruebas de software? En los últimos años ha aumentado considerablemente la importancia de las pruebas en el desarrollo de software. En estos tiempos en los que los presupuestos de TI son cada vez más ajustados, la verificación y validación del software se perfila como una actividad imprescindible para asegurar la calidad de los sistemas antes de su puesta en funcionamiento, evitando así errores en la operación, y por tanto costes imprevistos, para corregir dichos errores. Los beneficios de las pruebas no sólo repercuten en el área de desarrollo de proyectos y en el ahorro de costes, sino que también se dejan notar en el resto de las áreas de negocio y especialmente en la satisfacción 3

4 Capítulo 1. Introducción del cliente final. Por un lado, los desarrolladores cumplen su compromiso de alcance, plazo, coste y calidad. Por otro, mejora la transición de la fase de desarrollo a la de puesta en producción. Cuando los proyectos llegan a la fase final, los sistemas deben ser estables, y ofrecer una respuesta mejor a las necesidades funcionales y a los aspectos técnicos. Esto provoca la satisfacción de los usuarios finales y un incremento en la confianza de los responsables de la explotación del nuevo sistema. Ante esta creciente importancia de las pruebas dentro del desarrollo de software aparece la necesidad de gestionar dichos procesos de pruebas usando metodologías para su correcta regulación y aplicación. En la actualidad existen muchas y muy diferentes metodologías de pruebas ya sean pruebas de caja negra, de caja blanca, metodologías ágiles, iterativas,... pero, qué contiene realmente una metodología? Figura 1.1: Componentes de una metodología El gráfico 1.1 muestra los distintos componentes de que consta una metodología, adaptada de [2] acorde con los autores una metodología consta de: Un modelo de procesos. Un conjunto de técnicas. Un conjunto de entregables. Un conjunto de métricas. Guías para la gestión del proyecto, incluyendo roles y estructura del equipo. Herramientas.

CAPÍTULO 2 Objetivos En torno a lo anteriormente tratado en la introducción, se va a desarrollar el proyecto Dimitri (Desarrollo e Implantación de metodologías y Tecnologías de Testing). Este proyecto consiste en una herramienta web para la gestión, el mantenimiento y desarrollo de distintas actividades de pruebas en función de unas metodologías dadas o generadas por el usuario. La aplicación da la posibilidad de definir la metodología a seguir especificando el orden, la cobertura y los resultados a obtener al aplicar cada caso de pruebas. Esta herramienta permite también el seguimiento del día a día durante el periodo de testing dentro de un grupo de usuarios que especifican qué están haciendo, el porcentaje concluido de esa tarea así como los resultados o valores obtenidos al aplicar un proceso definido por la metodología en el proyecto deseado. También permite la comunicación entre los usuarios por medio del correo propio de la aplicación así como consultar distinta información de cada usuario. Por tanto, Dimitri permitirá: Definición de metodologías. La herramienta que se va a desarrollar debe permitir la definición de metodologías intentado ajustarse a la disposición de la figura 1.1. Es decir, la definición de metodología incluye modelos de proceso del ciclo de vida software, entregables de cada etapa o iteración, roles y estructura de equipo en forma de asignación de personal según necesidad de la metodología. Creación de proyectos. Además de las metodologías, Dimitri incluye la aplicación práctica de las metodologías y la posibilidad de crear proyectos de pruebas acorde a las metodologías anteriormente generadas. Estos proyectos incluyen 5

6 Capítulo 2. Objetivos un seguimiento de las diferentes tareas a realizar permitiendo dejar constancia de su evolución. Reutilización. Se propone realizar una herramienta que facilite la reutilización y adaptación de proyectos, de forma que al crear un nuevo proyecto se pueda utilizar la estructura de otro proyecto ya existente, si bien siempre se puede modificar esta estructura, pero esta posibilidad, aparte de agilizar los trámites de creación de un proyecto, aporta homogeneidad al desarrollo software por parte de un grupo de trabajo, un aumento de la calidad de los productos, mejoras en mantenimiento y soporte, reducción en los costes de desarrollo, etc. Accesibilidad. Dado que la idea es generar una aplicación para su divulgación y uso general, además de todo lo mencionado anteriormente, la aplicación permitirá obtener una vista más accesible y general de cada proyecto. Consciencia de grupo Dada la naturaleza cooperativa de la herramienta, va a constar de ciertos matices para facilitar el trabajo en grupo a la hora de desarrollar una tarea. La herramienta cuenta con un sistema de correo interno, cada proyecto o metodología tiene constancia de sus participantes, su creador, cada usuario tiene un espacio reservado en la aplicación a modo de perfil personal donde se muestra su información.

CAPÍTULO 3 Método y fases de trabajo Dada la naturaleza del proyecto, en el que se irán definiendo requisitos y funcionalidades a lo largo de todo su ciclo de vida, con reuniones periódicas en las que se irán refinando las necesidades y posibilidades del mismo, se ha optado por seguir una metodología de desarrollo de software que permita adaptarse a las directrices definidas. Por estas razones, se ha seleccionado el Proceso Unificado de Desarrollo (en adelante PUD) como metodología de trabajo. Figura 3.1: Proceso Unificado de Desarrollo El PUD se define como un conjunto de actividades necesarias para transformar los requisitos de usuario en un sistema software. Es un mar- 7

8 Capítulo 3. Método y fases de trabajo co genérico que puede especializarse para una gran variedad de sistemas de software cualesquiera que sean el área de aplicación o el tamaño del proyecto,[5]. Sus características principales son que está dirigido por casos de uso, centrado en la arquitectura, y es iterativo e incremental, [5], como puede observarse en la imagen 3.1. Cada ciclo de vida constará de cuatro fases: Inicio. Se define el alcance del proyecto, identificando los principales riesgos. Se propone una visión general de la arquitectura y se realiza el plan de fases e iteraciones. Elaboración. Se especifican los casos de uso seleccionados que definirán la arquitectura del sistema y se mitigan la mayor parte de los riesgos. Construcción. Se completa la funcionalidad del sistema. Transición. Asegura que el software esté disponible para los usuarios finales. A su vez durante cada una de estas iteraciones se irán aplicando las actividades definidas en el ciclo de vida clásico. Especificación y análisis de requisitos. Se especifican las características funcionales y no funcionales que deberá cumplir el producto software. Diseño. Se determina la estrategia que se va a utilizar para resolver el problema. Se definen en detalle las unidades y las relaciones entre ellas. Implementación. Codificación de la etapa anterior. Pruebas. Realización de pruebas unitarias y de integración.

CAPÍTULO 4 Medios que se pretenden utilizar 4.1. Hardware Se necesitará un ordenador de sobremesa o portátil, donde se realizarán los diseños, la implementación y las pruebas. También será necesario un dominio en un servidor donde poder implantar el sistema. 4.2. Software JDK 1.6+ (Java Development Kit). Un entorno integrado de desarrollo (IDE o Integrated Development Environment). Se utilizará Eclipse EE Helios. Un sistema para la gestión y construcción de proyectos. Se hará uso de Maven 2. Un servidor web capaz de desplegar aplicaciones web con estructura WAR (Web-Archive). Apache Tomcat 7 es la solución más factible gracias a su licencia, eficiencia y rendimiento. Un sistema gestor de bases de datos. Se empleará MySQL Community Server 5.x. Visual Paradigm para modelado y diseño de diagramas UML. LATEX para la elaboración de documentación técnica y de calidad asociada al proyecto. 9

Bibliografía [1] Tema sobre CICLO DE VIDA DEL SOFTWARE de Ingeniería del Software de la UCLM alarcos.inf-cr.uclm.es/doc/isoftwarei/ Tema03.pdf [2] Graham, I., Henderson-Sellers, B. y Younessi, H. (1997). The OPEN Process Specification. Essex, Reino Unido: ACM Press y Addison-Wesley [3] Tema Pruebas del Software de Ingenieria del Software http://alarcos. inf-cr.uclm.es/doc/isoftwarei/tema09.pdf [4] Artículo sobre Ingeniería del Software en Wikipedia http://es. wikipedia.org/wiki/ingenier%c3%ada_de_software. [5] Jacobson, I., G. Booch, and J. Rumbaugh, The unified software development process. 1999: Addison-Wesley Longman Publishing Co., Inc. 463. 10