Un Entorno de Application Lifecycle Management Dirigido por Procesos Juan Diego Pérez Jiménez, X

Transcripción

1 Un Entorno de Application Lifecycle Management Dirigido por Procesos Juan Diego Pérez Jiménez, X Supervised by Prof. Dr. Amador Durán Toro Thesis project submitted to the Department of Computer Languages and Systems of the University of Sevilla in partial fulfilment of the requirements for the degree of Ph.D. in Computer Engineering. (Thesis Project)

2

3 Índice general 1. Introducción 2 2. Hipótesis y Objetivos Modelando el proceso de desarrollo Tipología de modelos de procesos Tipos de procesos Granularidad del modelo Rigidez del modelo El lenguaje de modelado El problema de la integración Objetivos Trabajo Relacionado Metodología Plan de Trabajo Conclusiones 16 A. Curriculum vitae 18 i

4 Índice de figuras 4.1. Infraestructura RUP/SOMA Elementos del modelo de servicio y su relación con las fases de RUP/SOMA Diagrama de Gannt. Cronograma de elaboración de la Tesis ii

5 Índice de cuadros iii

6 Agradecimientos A todos toditos... iv

7 Resumen El uso de técnicas de modelado de procesos es algo común en diversos campos de la industria desde hace ya muchos años. Su aplicación en el mundo de la ingeniería del software es posterior, aunque en los últimos años se han realizado numerosas investigaciones al respecto. En este trabajo se pretende presentar los retos y problemas a los que se han enfrentado dichas investigaciones e intentar abordarlos para obtener un entorno Application LifyCycle Management flexible y dirigido por procesos. 1

8 Capítulo 1 Introducción El modelado de procesos para dar solución a determinados problemas es una técnica que ha sido utilizada desde hace muchos años en numerosos campos de la industria, en especial la manufacturera [1], con el doble objetivo de reducir costes y de mejorar la calidad de los productos obtenidos. En el campo de la ingeniería del software, su aplicación comienza durante la segunda mitad de los años 80, siendo uno de sus principales exponentes el clásico artículo de Osterweil [2] en el que plantea considerar el proceso de desarrollo de software como un proceso software en sí mismo. A partir de la idea seminal de Osterweil, se han realizado numerosas investigaciones de las que han surgido propuestas que combinan de una forma u otra conceptos como: Metodologías de desarrollo Ciclo de Vida Workflow PCSE (Process Centered Software Engineering) BPM (Business Process Management) PAIS (Process Aware Information Systems) BAM (Business Activity Monitoring) MBSE (Model Based Software Engineering) etc... Pese a todos estos esfuerzos, las investigaciones se han encontrado con que el proceso de desarrollo de software es un proceso complejo que presenta ciertas características que dificultan la utilización de las técnicas de modelado de procesos. De éstas las principales son que el desarrollo de software es un proceso con continuos cambios y en constante evolución, con una gran participación del elemento humano, que involucra normalmente a un gran número de personas y que además, en muchas ocasiones, no puede ser completamente definido a priori [1]. Además, otra de las grandes diferencias con respecto a los procesos de 2

9 otro tipo de industrias es la intangibilidad tanto del producto final como de los productos intermedios[2]. Por otro lado, en el modelado de procesos software uno de los retos aún pendientes es la integración de procesos, herramientas, vistas, productos y del resto de los elementos que participan en el desarrollo de software. Dicha integración no es fácil por la complejidad del desarrollo y porque no todas las partes del proceso son iguales, lo que obliga al uso de diferentes tipos de herramientas en las diferentes fases [3]. Por ese motivo, los enfoques de integración se han centrado única y exclusivamente en un sólo contexto [4], para un determinado tipo de software, un determinado lenguaje, un determinado hardware, un determinado sistema operativo, una determinada plataforma etc... Frente a estas peculiaridades del proceso de desarrollo y los problemas derivados la integración de todos los elementos nosotros proponemos la creación de un entorno de desarrollo de software dirigido por modelos de procesos. Para presentar este proyecto estructuraremos el resto del documento de la siguiente manera: Capítulo 2: Hipótesis y Objetivos: Capítulo en el cuál estableceremos las consideraciones y decisiones que deberemos tomar y fijaremos los objetivos de investigación que se pretenden conseguir con la elaboración de la tesis. Capítulo 3: Trabajo Relacionados: En este capítulo se presentan los trabajos y tecnologías más relevantes relacionadas con el ámbito de nuestra investigación. Capítulo 4: Metodología. Donde describiremos la metodología de investigación que pretendemos seguir. Capítulo 5: Plan de Trabajo. En este capítulo se presentarán, a grandes rasgos la planificación para la realización de la tesis. Capítulo 6: Conclusiones. Para concluir en este capítulo se expondrán las conclusiones que hemos podido sacar de las investigaciones realizadas previamente. 3

10 Capítulo 2 Hipótesis y Objetivos Lo que a grandes rasgos pretendemos es afrontar las peculiaridades del proceso de desarrollo de software y los problemas que supone la integración de todos los elementos de dicho proceso mediante la creación de un entorno de desarrollo de software dirigido por procesos. Para ello en primer lugar vamos a especificar qué aspectos debemos de tener en cuenta para adaptar las técnicas de modelado a nuestro proyecto y, en segundo lugar, cuáles son los problemas que han ido apareciendo a lo largo de los años en relación a la integración de los distintos elementos que componen el proceso y cómo vamos a afrontar éstos problemas. Una vez especificados estos dos puntos describiremos los objetivos que nos planteamos con la realización de la tesis de una forma más detallada Modelando el proceso de desarrollo La aplicación de técnicas como el modelado de procesos implica una orientación a procesos del desarrollo de software y nos va a permitir conseguir ciertas mejoras y objetivos [5]: Conseguir que los proyectos de software sean más efectivos, desplegando los recursos de manera más eficiente y obteniendo los productos con menor esfuerzo. Que sean más predecibles permitiéndonos estimar de manera más precisa el tiempo y los recursos necesarios, en definitiva más robustos. Obtener productos de mayor calidad y fiabilidad. Sin embargo, para la consecución de estos objetivos, y dadas las peculiaridades inherentes a los proyectos de desarrollo de software, se han de tener en cuenta varios factores y no se ha de pensar que la simple aplicación del modelado de procesos es la solución a todos los problemas. Tras un estudio previo creemos que los factores más importantes que se deben tenerse en cuenta para que la aplicación de la técnicas de modelado de procesos sea efectiva son los siguientes y se describen en las siguientes secciones de este proyecto de tesis. La tipología del modelo de procesos que se va a utilizar. 4

11 El tipo del proceso que se pretende modelar. La granularidad de la descripción que obtenemos con nuestro modelo. La rigidez del modelo. El lenguaje o notación que se va a utilizar para realizar el modelado del proceso Tipología de modelos de procesos Los modelos de procesos pueden clasificarse atendiendo a diversos criterios. Según [6], podemos distinguir dos tipos de modelos de procesos: Modelo de procesos proscriptivo: se permite cualquier secuencia de actividades siempre que se cumplan una serie de restricciones, normalmente expresadas mediante reglas. Modelo de proceso prescriptivo: se especifican detalladamente las acciones a desarrollar indicando además el orden en el que deben ejecutarse, normalmente expresado mediante la utilización de notaciones gráficos o procedurales. Cada uno de estos enfoques en el modelado de procesos posee una serie de ventajas e inconvenientes. De manera resumida, el enfoque proscriptivo es mucho más flexible pero no permite proporcionar ninguna guía de ejecución, mientras que el enfoque prescriptivo no permite cambios en tiempo de ejecución pero facilita el análisis. Una descripción más detallada de las ventajas e inconvenientes de cada uno de estos en enfoques, así como un análisis de la posibilidad de un enfoque mixto se puede encontrar en [7]. Por otro lado, atendiendo a la cobertura del modelo, podemos distinguir [8]: Orientados a actividades: el modelo se concentra en las acciones necesarias para obtener el producto y en su orden de ejecución. Orientados a productos: similar al enfoque de orientación a actividades, pero añadiendo enlaces entre las actividades, su entradas y sus salidas. Orientados a decisiones: se centra en las transformaciones sufridas por los productos del proceso y causadas por las decisiones que se han ido tomando a lo largo del mismo Tipos de procesos El enfoque habitual en los sistemas de workflow ha sido considerar las tareas de los modelos de procesos con una semántica transaccional, siguiendo el modelo ACID (Atomicity, Consistency, Isolation, Durability) [9]. Sin embargo, este enfoque es en exceso rígido y no es válido para todos los entornos. Así, podemos distinguir tres tipos de procesos según [9]: Modelado: El flujo entre las actividades se decide antes de la ejecución. Ad hoc: Cuando el flujo no se puede definir a priori y no se especifica ningún orden concreto de ejecución. Simplemente, las actividades ocurren. 5

12 Semi modelado: Cuando tenemos una mezcla de los dos enfoques, con partes del proceso modeladas y partes del modelo ad hoc. De especial importancia, y muy a tener en cuenta a la hora de conseguir nuestros objetivos son los procesos semi modelados. La importancia de este tipo de procesos radica en la propia naturaleza del proceso de desarrollo de software que, en muchas ocasiones, no pueden ser especificados completamente a priori [1] Granularidad del modelo La granularidad de un modelo de proceso es el nivel de profundidad o detalle al que se va a llegar a la hora de describir y modelar el proceso. Podemos distinguir entre modelos de grano fino y modelos de grano grueso [5, 8]. Los primeros son los que nos muestran más detalles, mientras que los de grano grueso son abstracciones de más alto nivel. Es importante, y se recalca en [5, 8], que nuestro entorno nos permita dar soporte a modelos de distinto grosor de grano y que además nos permita un desplazamiento entre estos distintos niveles de detalle Rigidez del modelo La rigidez de un modelo de procesos está relacionada con la posibilidad de que aparezcan cambios en la definición del proceso una vez éste ya ha sido definido o modelado de alguna manera y en la adaptabilidad a dichos cambios. Varía, según [8], entre dos extremos, los procesos rígidos, que son procesos cuyos modelos están completamente predefinidos y son difícilmente adaptables, y los procesos flexibles, que permiten modelos que pueden adaptarse a distintos contextos con técnicas como la parametrización [10]. El equilibrio entre estos dos extremos es complicado, ya que según [10] el hecho de conseguir modelos de procesos flexibles implica un esfuerzo adicional. Cuánto más flexible es el modelo más difícil es el soporte y, si llegamos al extremo de permitir la integración arbitraria de herramientas, nos limitaremos únicamente a llamar a las herramientas en un orden determinado. Esta situación enlaza directamente con el concepto de integración que se tratará más adelante. La situación ideal debe decidirse en cada proyecto, aunque lo más normal es que con un modelo se pueda dar soporte a un rango de procesos con características similares [3] El lenguaje de modelado La elección del lenguaje es una parte fundamental a la hora de modelar el proceso de desarrollo. Dicha elección influye en el diseño el proceso, la comprensión del mismo, la formación, y en la posibilidad de que exista simulación, optimización y soporte [11]. La elección de una u otra notación va a depender de muchos aspectos, entre ellos: De que sea una notación formal que nos permita, entre otras cosas, validar los modelos obtenidos. 6

13 De la expresividad, es decir, de que podamos expresar con el lenguaje el proceso que queremos representar (en este caso un proceso de desarrollo de software). Para comprobar esta expresividad los trabajos más destacados son los workflow patterns, resource patterns y data patterns descritos en [12, 13, 14]. De que posea una semántica bien definida [15] La existencia de aplicaciones que nos permitan crear modelos con esa notación o lenguaje de la forma más usable posible. La existencia de motores que nos permitan crear instancias de los procesos descritos e, idealmente, monitorizar y simular dichos procesos. No obstante, pese a todos esos factores la elección última de una u otra notación dependerá también del contexto en el que se va a desplegar. No todos los tipos de desarrollos de software van a necesitar el mismo tipo de proceso e incluso a veces distintas fases de un mismo proceso global van a necesitar distintos enfoques, soporte y mecanismos [3]. Esta afirmación entronca de nuevo con el concepto de integración, clave en el tipo de entornos que se pretende desarrollar El problema de la integración El concepto de integración en el ámbito de la ingeniería del software es un concepto clave [16] y ha sido ampliamente definido en la bibliografía. Dos de las definiciones más aceptadas son: La actividad mediante la cuál se producen entornos completos que soportan el ciclo de vida de un desarrollo de software [16]. La técnica para producir coaliciones de herramientas que proporcionen un entorno que de soporte a todas, o algunas, de las actividades que componen el proceso de ingeniería de software [17]. Ambas definiciones relacionan los conceptos de integración y proceso (entendiendo que el concepto de proceso software se construye sobre el concepto de ciclo de vida [11]). Asimismo, a lo largo de este proyecto de tesis se ha puesto de manifiesto en varios puntos la estrecha relación entre la técnica de modelado de procesos y el concepto de la integración, provocando que, incluso en determinadas ocasiones, los mecanismos de integración sean diferentes dependiendo del momento del proceso de desarrollo y de las herramientas disponibles[17]. Pese a su importancia y su estrecha relación con la orientación a procesos, a día de hoy los distintos enfoques de integración todavía siguen encontrándose con ciertas dificultades y problemas debido, en gran parte, a que que se han ido creando islas de integración que únicamente se ocupan de dos fases determinadas del proceso de desarrollo, y a que una integración completa sólo se consigue con un proceso claramente definido y bajo ciertas decisiones de negocio asumidas [17]. 7

14 Para afrontar estos problemas de integración, nuestra propuesta es darle a la herramienta que resulta de nuestra tesis un enfoque ALM (Application LyceCycle Management), que se define en [18] como: La coordinación de las actividades de un ciclo de vida de desarrollo, incluyendo requisitos, modelado, desarrollo, construcción y pruebas a través de imponer un proceso que cubra esas actividades, la gestión de las relaciones entre los productos usados y producidos por esas actividades y una serie de informes que describan el progreso del desarrollo de manera global Objetivos Lo que pretendemos es la construcción de un un entorno ALM Application LifeCycle Managemet dirigido por procesos centrándonos en el desarrollo de un tipo concreto de aplicaciones: Las aplicaciones de gestión en el ámbito de los sistemas de información. El entorno obtenido deberá ser abierto, permitiendo de la manera más flexible posible la integración de herramientas de terceros. Como paso inicial del trabajo se deberá realizar un estudio pormenorizado, centrado en las características del rango de aplicaciones elegido, de todos y cada uno de los aspectos que, por su importancia en el mundo del modelado de procesos, han sido incluidos en el presente artículo. Se deberá decidir qué tipo de modelos vamos a utilizar, qué lenguaje o notación vamos a usar para modelar el proceso, qué punto de granularidad y flexibilidad pretendemos proporcionar al proceso de desarrollo de software y cuáles van a ser las estrategias de integración que utilizaremos para dar soporte a la heterogeneidad de los procesos y herramientas. Este tipo de entorno permite la mejora de ciertas actividades mediante la integración de herramientas en el proceso de desarrollo, asegura la coordinación entre las diferentes actividades que constituyen el ciclo de vida del desarrollo software y permite que las distintas herramientas que se utilizan durante el ciclo de vida no sean una mera colección sino que estén integradas mediante la plataforma ALM que constituye el hilo que une todo el ciclo de vida [18]. Se basará en los siguientes pilares fundamentales [18]: Por un lado en la automatización de los procesos de alto nivel mediante la utilización de motores de procesos (Y por lo tanto en la utilización de modelos de procesos que son los que nos van a guiar durante todo el proceso de desarrollo) Proporcionar visibilidad de los progresos y avances que se están produciendo en el desarrollo. Mantener la trazabilidad entre los productos que se generan a los largo de todo el ciclo de desarrollo. Hasta ahora la aplicación de este enfoque se ha encontrado con ciertas dificultades [18], como la existencia de herramientas diferentes para cada uno de 8

15 los roles implicados en el proceso de desarrollo de software, lo que produce un aumento de la complejidad y una disminución de la productividad, redundancias e inconsistencias de funcionalidades, lo que provoca la aparición de silos de funcionalidad y la falta de transparencia e integración a través de frágiles mecanismos de sincronización mediante repositorios. Para evitar estas dificultades de los entornos ALM de la anterior generación, en [18] se proponen las características que debiera de tener lo que la autora llama un entorno ALM 2.0 : Herramientas ensambladas a base de plug ins. Servicios comunes disponibles para todos los participantes, para evitar los silos. Neutralidad de repositorios. Usos de estándares de integración, muy relacionados con la tecnología de servicios (por ejemplo Web Services). Macro y microprocesos dirigidos por un motor de workflow. Y todo esto con una serie de elementos principales [19]: Un interfaz de usuario común para todas las herramientas. Un motor de procesos. Un metamodelo tanto para el proceso como para los aspectos de trazabilidad. Como objetivo adicional buscaremos también que el entorno ALM resultante nos facilite que los productos obtenidos mediante su utilización sean acordes a las exigencias impuestas por CMMI DEV 1.2 [20]. Esta decisión no obliga a tener muy en cuenta las Process Areas, los Specific & Generic Goals, las Specific & Generic Practices y todos los demás elementos que nos marca esta especificación. Por lo tanto las decisiones iniciales relacionados con el modelado de procesos deberán de tener muy presente todos los elementos que constituyen este modelo de madurez. Además, y dado que nuestra propuesta, tal y cómo se ha indicado en este mismo capítulo, va a ser una propuesta con servicios comunes para todos los usuarios y que va usar estándares de integración relacionados con la tecnología de servicios, creemos que es muy conveniente que la infraestructura de servicios resultante sea acorde con alguno de los modelos de madurez existentes en este campo como OSIMM (Open Service Integration Maturity Model) [21], SOAMM o isoamm [22] que deberemos evaluar para seleccionar el modelo de madurez que mejor se adecue a los objetivos de nuestro proyecto. 9

16 Capítulo 3 Trabajo Relacionado Actualmente diversos fabricantes (Microsoft, Borland, MKS, Serena, Compuware, CA, Telelogic, Mercury e IBM ) están ofreciendo este tipo de entornos. En la mayoría de los casos ofrecen plataformas ALM propietarias que funcionan mejor con sus propias herramientas y que incumplen algunas de las características que debería tener un entorno ALM 2.0 [18]. La idea es construir un entorno 10

17 Capítulo 4 Metodología La metodología elegida para la elaboración de la herramienta que dará sustento práctico al desarrollo de nuestro proyecto de investigación es RUP/SOMA que es un marco metodológico para el elaboración de soluciones orientadas a servicios que respetando la base de RUPRational Unified Proceess[?] añade nuevos conceptos de la metodología SOMA Service Oriented Modeling and Architecture[23] que es una metodología de desarrollo para diseñar y construir soluciones basadas en servicios desarrollada por IBM. Se optado por esta metodología porque tal y como se dijo en capítulos anteriores, nuestra propuesta va a ser una propuesta con servicios comunes para todos los usuarios y que va usar estándares de integración relacionados con la tecnología de servicios. La infraestructura de esta metodología RUP/SOMA se describe en la figura 4.1 que nos muestra las principales fases, las dependencias de cada una de las fases con respecto a los distintos tipo de requisitos y también los artifacts más importantes producidos por cada una de las fases. aquí no tengo muy claro si poner RUP o UP Figura 4.1: Infraestructura RUP/SOMA. 11

18 Como se puede ver, el artifact más importante es el modelo de servicio ya que un producto complejo y compuesto que está presente en todas las fases y que nos va a permitir asociar y relacionar todos los elementos participantes: servicios, proveedores, especificaciones, particiones, mensajes,colaboraciones etc... Los elementos claves de estos artifacts y las relaciones con las distintas fases de la metodología RUP/SOMA se pueden ver en la figura 4.2. Figura 4.2: Elementos del modelo de servicio y su relación con las fases de RUP/SOMA. Este método elegido sigue siente un método iterativo e incremental, las distintas actividades que lo componen, que se describen brevemente más abajo se realizan en varias iteraciones que pueden estar centradas en distintos servicios o en distintas áreas de dominio a la vez. Análisis de Transformación Empresarial: Fase en la que los procesos y componentes que representan las funciones más importantes son modelados y analizados, ya sea en toda la organización o dentro del un área de dominio concreta que represente nuestro objetivo. Identificación: Fase mediante la cuál son identificados los tres elementos principales de una infraestructura orientada a servicios: servicios, componentes y flujos. Para esta utilizaremos principalmente tres técnicas: Descomposición de dominios. Modelado de objetivos de servicios. Análisis del sistema existente. 12

19 Especificación: Donde completamos el diseño de los servicios y componentes identificados en la fase anterior. Se completa el modelo de servicio añadiendo dependencias, flujos, composición de servicios, operaciones, mensajes, requerimientos no funcionales, reglas y políticas etc... Realización: En esta fase se decide qué servicios serán realizados y cuáles serán integrados mediante la utilización de tecnologías de integración de servicios. 13

20 Capítulo 5 Plan de Trabajo El plan de trabajo establecido inicialmente para la elaboración de la tesis tiene un duración total aproximada de dos años, partiendo de Septiembre del año 2009 y teniendo en cuenta que para esa fecha ya se han superado tanto el período docente como el período investigador con la obtención del Diploma de Estudios Avanzados (DEA) en Junio del año En líneas generales este plan de trabajo se dividirá en los siguiente grupos de actividades cuya planificación y duración estimada podemos ver en el siguiente diagrama de Gantt 5.1 : Selección de Tecnologías: Actividad mediante la cuál elegiremos las tecnologías más adecuadas para la realización nuestro proyecto respondiendo a las preguntas planteadas a lo largo de este proyecto en relación a las técnicas de modelado de procesos y a los problemas de integración en los procesos de desarrollo de software. Todo esto centrándonos en el ámbito concreto que hemos elegido, el desarrollo de aplicaciones de gestión en el área de los sistemas de información. Desarrollo de la herramienta: Esta actividad consiste en la realización de una herramienta ALM Application LifeCycle Management dirigida por procesos que represente la validación práctica de las conclusiones obtenidas durante la elaboración de la tesis. Publicaciones: Es la actividad que más tiempo va a ocupar. La intención es ir realizando publicaciones graduales conforme se vayan obteniendo resultados en los foros que se han presentado a lo largo de este documento. Versiones de la tesis: En relación a esta actividad, que será un continuo desde su comienzo, se van a establecer dos hitos, un primer hito que representará la entrega de una versión preliminar y un segundo hito que representa el momento aproximado en el cuál pretendemos tener disponible la versión final de la tesis para realizar su entrega. 14

21 Figura 5.1: Diagrama de Gannt. Cronograma de elaboración de la Tesis 15

22 Capítulo 6 Conclusiones En este trabajo de investigación, que es resultado de investigaciones previas y que pretende ser el punto de partida y la base del posterior desarrollo de tesis, ha quedado de manifiesto las aportaciones que pretendemos obtener mediante la construcción y utilización de un entorno ALM Application Lyfe Cycle Managemetdirigido por procesos. De manera concisa un entorno de este tipo nos debe permitir aportar, por un lado, la ventajas de aplicar las técnicas del modelado de procesos al proceso de desarrollo de software, es decir más eficiencia, mejor gestión y mayor calidad de los productos obtenidos y, por otro lado, nos va a facilitar la integración de los diversos elementos que participan el propio proceso que como ya hemos visto es una de los aspectos más problemas presentan en este tipo de entornos. Se han identificado para ello diversos factores que se deberán considerar a la hora de elegir las tecnologías relacionadas con el modelado de procesos de negocio y uno de los primeros pasos que deberemos tomar, y así se indica en la planificación, es la concreción de todos estos factores al ámbito en el que nos vamos a centrar, la creación de aplicaciones de gestión el marco de sistemas de información. La integración de todos los elementos que van a participar se pretende abordar mediante el enfoque ALM 2.0 propuesto en [18], enfoque que como ya se dijo debe poseer idealmente las siguientes características: Herramientas ensambladas a base de plug ins. Servicios comunes disponibles para todos los participantes, para evitar los silos. Neutralidad de repositorios. Usos de estándares de integración, muy relacionados con la tecnología de servicios (por ejemplo Web Services). Macro y microprocesos dirigidos por un motor de workflow. Y todo esto con una serie de elementos principales [19]: 16

23 Un interfaz de usuario común para todas las herramientas. Un motor de procesos. Un metamodelo tanto para el proceso como para los aspectos de trazabilidad. Como se puede apreciar en las características ideales de esta propuesta ya están entremezclados elementos y tecnologías relacionados con la técnica de modelado de procesos con las relacionadas con las tecnologías de servicios que son la opción elegida para afrontar los problemas de integración. Y en aras de la calidad tanto de la herramienta que se pretende obtener, como del marco que se va a proporcionar a los futuros usuarios del entorno, se han tenido especialmente en cuenta los modelos de madurez más extendidos lo que pretende ser además un rasgo diferenciador de nuestra solución frente al resto de las soluciones analizadas. Somos conscientes de que conseguir un entorno que cubra todo el ciclo de vida de un desarrollo de software mediante este tipo de enfoque es un objetivo muy ambicioso, dadas las peculiaridades y complejidad de este tipo de procesos, por ello mismo nos proponemos hacer una aproximación incremental centrándonos un un inicio en determinadas áreas y creando la infraestructura que facilite las incorporación al entorno de herramientas que vayan a cubrir otras áreas diferentes a las que inicialmente seleccionemos. 17

24 Apéndice A Curriculum vitae Datos Personales Nombre: Juan Diego Pérez Jiménez DNI: X Fecha de nacimiento: 27/05/1976 Correo electrónico: jdiego.perez.ext@juntadeandalucia.es Formación Académica Licenciatura: Ingeniería Superior en Informática Universidad: Universidad de Zaragoza Estudios de Postgrado: Master en Animación por ordenador e imagen de síntesis (MA-ISCA) Universidad: Universidad de las Islas Baleares Doctorado: Diploma de estudios avanzados (DEA) Universidad: Universidad de Sevilla Artículos *Participación en Proyectos de Investigación Experiencia Profesional Posición: Programador de aplicaciones de banca electrónica Empresa: Intercomputer Duración: 01/10/1998 a 01/06/

25 Posición: Técnico de automatismos Empresa: Inditex Duración: 01/01/2003 a 01/07/2003 Posición: Profesor Ed. Secundaria (especialidad informática) Institución: Junta de Andalucía (Consejería de Educación) Duración: 01/09/2004 a 31/08/2006 Posición: Jefe de Departamento de Informática Institución:Junta de Andalucía (Consejería de Educación) Duración: 01/09/2006 al 31/08/2007 Posición: Secretario de Centro Institución: Junta de Andalucía (Consejería de Educación) Duración: 01/09/2007 al 30/06/2008 Posición: Adscrito a Servicios Centrales. Servicio de Educación Permanente Institución: Junta de Andalucía (Consejería de Educación) Duración: 01/09/2008 al 31/08/2009 Posición: Responsable del subprograma de enseñanzas no presenciales Institución: Junta de Andalucía (Consejería de Educación) Duración: 01/09/2009 Posición: Profesor a tiempo parcial Institución: Universidad de Sevilla. Escuela Superior de Ingeniería Informática Duración: 01/03/2009 al 31/08/2009 Posición: Profesor del Curso de Experto en Comunicación Institucional y Marketing Político Institución: Universidad de Sevilla. Faculta de Comunicación Duración: 01/05/2007 al 01/05/