Fundamentos para un Entorno de Application Lifecycle Management Dirigido por Procesos

Fundamentos para un Entorno de Application Lifecycle Management Dirigido por Procesos? Juan D. Prez–Jimnez, Amador Durn, and Beatriz Bernrdez Dpto. de Lenguajes y Sistemas Informticos Universidad de Sevilla [email protected], {amador,[email protected]} Abstract. El uso de tcnicas de modelado de procesos es algo comn en diversos campos de la industria desde hace ya muchos aos. Su aplicacin en el mundo de la ingeniera del software es posterior, aunque en los ltimos aos se han realizado numerosas investigaciones al respecto. En este trabajo se pretende recopilar de manera concisa las conclusiones de los trabajos de investigacin ms relevantes y plantear una serie de retos y preguntas que nos permitan construir en un futuro un entorno de application lifecycle management flexible y dirigido por procesos. Key words: ALM, Proceso software, MBSE, PAIS, PCSE, Workflow, BPM, CMMI 1 Introduccin El modelado de procesos para dar solucin a determinados problemas es una tcnica que ha sido utilizada desde hace muchos aos 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 ingeniera del software, su aplicacin comienza durante la segunda mitad de los aos 80, siendo uno de sus principales exponentes el clsico artculo 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 Metodologas de desarrollo,Ciclo de Vida,Workflow,PCSE (Process–Centered Software Engineering),BPM (Business Process Management),PAIS (Process–Aware Information Systems),BAM (Business Activity Monitoring) yMBSE (Model–Based Software Engineering). 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 caractersticas que dificultan la utilizacin de las tcnicas de modelado de procesos. De stas las principales son que el desarrollo de software es un proceso con continuos cambios y ?Este trabajo est financiado por los siguientes proyectos: SETI (TIN 2009–07366), Isabel (TIC– 2533) y Alcuza (Cajasol). Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 3, 2009 ISSN 1988-3455 SISTEDES, 2009 41 en constante evolucin, con una gran participacin del elemento humano, que involucra normalmente a un gran nmero de personas y que adems, en muchas ocasiones, no puede ser completamente definido a priori [1]. Adems, otra de las grandes diferencias con respecto a los procesos de 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 an pendientes es la integracin de procesos, herramientas, vistas, productos y del resto de los elementos que participan en el desarrollo de software. Dicha integracin no es fcil 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 integracin se han centrado nica y exclusivamente en un slo contexto [4], para un determinado tipo de software, un determinado lenguaje, un determinado hardware, un determinado sistema operativo, una determinada plataforma etc... El objetivo de este este artculo es revisar las conclusiones ms importantes de la bibliografa y formular las preguntas ms relevantes que se debern responder para la construccin de un entorno Application Lifecycle Management (ALM) [5] dirigido por procesos. Para ello, el resto del artculo se estructura de la siguiente manera. En la segunda seccin se recogen todos los aspectos a tener en cuenta en relacin al modelado de procesos software, en la tercera seccin se recogen los problemas relacionados con la integracin y en la cuarta seccin se enumeran los objetivos y el trabajo futuro que se pretende desarrollar para continuar la investigacin. 2 Modelando el proceso de desarrollo de software La aplicacin de tcnicas como el modelado de procesos implica una orientacin a procesos del desarrollo de software y nos va a permitir conseguir ciertas mejoras y objetivos [6]: –Conseguir que los proyectos de software sean ms efectivos, desplegando los recursos de manera ms eficiente y obteniendo los productos con menor esfuerzo. –Que sean ms predecibles permitindonos estimar de manera ms precisa el tiempo y los recursos necesarios, en definitiva ms robustos. –Obtener productos de mayor calidad y fiabilidad. Sin embargo, para la consecucin 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 aplicacin del modelado de procesos es la solucin a todos los problemas. Despus del estudio realizado, creemos que los factores ms importantes que se deben tenerse en cuenta para que la aplicacin de la tcnicas de modelado de procesos sea efectiva son los siguientes y se describen en las siguientes secciones. –La tipologa del modelo de procesos que se va a utilizar. –El tipo del proceso que se pretende modelar. –La granularidad de la descripcin que obtenemos con nuestro modelo. –La rigidez del modelo. –El lenguaje o notacin que se va a utilizar para realizar el modelado del proceso. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 3, 2009 ISSN 1988-3455 SISTEDES, 2009 42 2.1 Tipologa de modelos de procesos Los modelos de procesos pueden clasificarse atendiendo a diversos criterios. Segn [7], 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 adems el orden en el que deben ejecutarse, normalmente expresado mediante la utilizacin de notaciones grficos 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 ms flexible pero no permite proporcionar ninguna gua de ejecucin, mientras que el enfoque prescriptivo no permite cambios en tiempo de ejecucin pero facilita el anlisis. Una descripcin ms detallada de las ventajas e inconvenientes de cada uno de estos en enfoques, as como un anlisis de la posibilidad de un enfoque mixto se puede encontrar en [8]. Por otro lado, atendiendo a la cobertura del modelo, podemos distinguir [9]: –Orientados a actividades: el modelo se concentra en las acciones necesarias para obtener el producto y en su orden de ejecucin. –Orientados a productos: similar al enfoque de orientacin a actividades, pero aadiendo 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. 2.2 Tipos de procesos El enfoque habitual en los sistemas de workflow ha sido considerar las tareas de los modelos de procesos con una semntica transaccional, siguiendo el modelo ACID (Atomicity, Consistency, Isolation, Durability) [10]. Sin embargo, este enfoque es en exceso rgido y no es vlido para todos los entornos. As, podemos distinguir tres tipos de procesos segn [10]: –Modelado: El flujo entre las actividades se decide antes de la ejecucin. –Ad–hoc: Cuando el flujo no se puede definir a priori y no se especifica ningn orden concreto de ejecucin. Simplemente, las actividades ocurren. –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 los objetivos marcados en la ltima seccin de este artculo, son los procesos semi–modelados. La importancia de este tipo de procesos radica en la propia naturaleza del proceso de desarrollo de software que, como ya se dijo anteriormente, en ocasiones no pueden ser especificados completamente a priori [1]. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 3, 2009 ISSN 1988-3455 SISTEDES, 2009 43 2.3 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 [6, 9]. Los primeros son los que nos muestran ms detalles, mientras que los de grano grueso son abstracciones de ms alto nivel. Es importante, y se recalcan en [6, 9], que nuestro entorno nos permita dar soporte a modelos de distinto grosor de grano y que adems nos permita un desplazamiento entre estos distintos niveles de detalle. 2.4 Rigidez del modelo Relacionado con los apartados anteriores, en ste introducimos el concepto de rigidez del proceso. La rigidez de un modelo de procesos est relacionada con la posibilidad de que aparezcan cambios en la definicin del proceso una vez ste ya ha sido definido o modelado de alguna manera y en la adaptabilidad a dichos cambios. Vara, segn [9], entre dos extremos, los procesos rgidos, que son procesos cuyos modelos estn completamente predefinidos y son difcilmente adaptables, y los procesos flexibles, que permiten modelos que pueden adaptarse a distintos contextos con tcnicas como la parametrizacin [11]. El equilibrio entre estos dos extremos es complicado, ya que segn [11] el hecho de conseguir modelos de procesos flexibles implica un esfuerzo adicional. Cunto ms flexible es el modelo ms difcil es el soporte y, si llegamos al extremo de permitir la integracin arbitraria de herramientas, nos limitaremos nicamente a llamar a las herramientas en un orden determinado. Esta situacin enlaza directamente con el concepto de integracin que se tratar en la seccin siguiente. La situacin ideal debe decidirse en cada proyecto, aunque lo ms normal es que con un modelo se pueda dar soporte a un rango de procesos con caractersticas similares [3]. 2.5 El lenguaje de modelado La eleccin del lenguaje es una parte fundamental a la hora de modelar el proceso de desarrollo. Dicha eleccin influye en el diseo el proceso, la comprensin del mismo, la formacin, y en la posibilidad de que exista simulacin, optimizacin y soporte [12]. La eleccin de una u otra notacin va a depender de muchos aspectos, entre ellos: –De que sea una notacin formal que nos permita, entre otras cosas, validar los modelos obtenidos. –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 ms destacados son los workflow patterns, resource patterns ydata patterns descritos en [13–15]. –De que posea una semntica bien definida [16] –La existencia de aplicaciones que nos permitan crear modelos con esa notacin o lenguaje de la forma ms usable posible. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 3, 2009 ISSN 1988-3455 SISTEDES, 2009 44 –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 eleccin ltima de una u otra notacin depender tambin 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 afirmacin entronca de nuevo con el concepto de integracin, clave en el tipo de entornos que se pretende desarrollar. 3 El problema de la Integracin El concepto de integracin en el mbito de la ingeniera del software es un concepto clave [17] y ha sido ampliamente definido en la bibliografa. Dos de las definiciones ms aceptadas son: –La actividad mediante la cul se producen entornos completos que soportan el ciclo de vida de un desarrollo de software [17]. –La tcnica para producir coaliciones de herramientas que proporcionen un entorno que de soporte a todas, o algunas, de las actividades que componen el proceso de ingeniera de software [18]. Ambas definiciones relacionan los conceptos de integracin y proceso (entendiendo que el concepto de proceso software se construye sobre el concepto de ciclo de vida [12]). Asimismo, a lo largo de este artculo se ha puesto de manifiesto en varios puntos la estrecha relacin entre la tcnica de modelado de procesos y el concepto de la integracin, provocando que, incluso en determinadas ocasiones los mecanismos de integracin sean diferentes dependiendo del momento del proceso de desarrollo y de las herramientas disponibles[18]. Pese a su importancia y su estrecha relacin con la orientacin a procesos, a da de hoy los distintos enfoques de integracin todava siguen encontrndose con ciertas dificultades y problemas debido, en gran parte, a que que se han ido creando islas de integracin que nicamente se ocupan de dos fases determinadas del proceso de desarrollo, y a que una integracin completa slo se consigue con un proceso claramente definido y bajo ciertas decisiones de negocio asumidas [18]. Para afrontar estos problemas de integracin, nuestra propuesta es aunar a la utilizacin de las tcnicas del modelado de procesos un enfoque ALM (Application LyceCycle Management), que se define en [5] como: La coordinacin de las actividades de un ciclo de vida de desarrollo, incluyendo requisitos, modelado, desarrollo, construccin y pruebas a travs de imponer un proceso que cubra esas actividades, la gestin 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. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 3, 2009 ISSN 1988-3455 SISTEDES, 2009 45 Un entorno ALM permite la mejora de ciertas actividades mediante la integracin de herramientas en el proceso de desarrollo, asegura la coordinacin 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 coleccin sino que estn integradas mediante la plataforma ALM que constituye ”‘el hilo que une todo el ciclo de vida”’ [5]. Este enfoque se basa en los siguientes pilares fundamentales [5]: –Por un lado en la automatizacin de los procesos de alto nivel mediante la utilizacin de motores de procesos. –Proporcionar visibilidad de los progresos y avances que se estn 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 aplicacin de este enfoque se ha encontrado con ciertas dificultades [5], como la existencia de herramientas diferentes para cada uno de los roles implicados en el proceso de desarrollo de software, lo que produce un aumento de la complejidad y una disminucin de la productividad, redundancias e inconsistencias de funcionalidades, lo que provoca la aparicin de silos de funcionalidad y la falta de transparencia e integracin a travs de frgiles mecanismos de sincronizacin mediante repositorios. Para evitar estas dificultades de los entornos ALM de la anterior generacin, en [5] se proponen las caractersticas 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 estndares de integracin, muy relacionados con la tecnologa 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 comn para todas las herramientas. –Un motor de procesos. –Un metamodelo tanto para el proceso como para los aspectos de trazabilidad. Actualmente diversos fabricantes (Microsoft, Borland, MKS, Serena, Compuware, CA, Telelogic, Mercury etc.) estn ofreciendo este tipo de entornos. En la mayora de los casos ofrecen plataformas ALM propietarias que funcionan mejor con sus propias herramientas y que incumplen algunas de las caractersticas que debera tener un entorno ALM 2.0[5]. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 3, 2009 ISSN 1988-3455 SISTEDES, 2009 46 4 Objetivos y trabajo futuro Con este artculo se pretenden sentar las bases para la realizacin de una tesis doctoral en el rea de los procesos de negocio aplicados al proceso de desarrollo de software. Como resultado el objetivo es obtener una descripcin detallada de un entorno ALM dirigido por procesos que cubra el desarrollo de un tipo concreto de aplicaciones: las aplicaciones de gestin en el mbito de los sistemas de informacin. El entorno obtenido deber ser abierto , permitiendo de la manera ms flexible posible la integracin de herramientas de terceros, y deber cumplir con todas y cada una de las caractersticas que idealmente debiera de tener un entorno ALM y que han sido enumeradas en el apartado anterior. Como paso inicial del trabajo se deber realizar un estudio pormenorizado, centrado en las caractersticas 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 artculo. Se deber decidir qu tipo de modelos vamos a utilizar, qu lenguaje o notacin vamos a usar para modelar el proceso, qu punto de granularidad y flexibilidad pretendemos proporcionar al proceso de desarrollo de software y cules van a ser las estrategias de integracin que utilizaremos para dar soporte a la heterogeneidad de los procesos y herramientas. Siendo de partida un objetivo muy ambicioso, lo que se pretende es centrarnos en un principio en las reas de gestin de requisitos y en la gestin de proyectos. Todo ello partiendo de modelos de procesos que sean instanciados posteriormente en un motor de workflow. Se intentar adems que la propuesta sea acorde a CMMI–DEV 1.2 [20]. References 1. Arbaoui, S., Derniame, J.C., Oquendo, F., Verjus, H.: A Comparative Review of Process– Centered Software Engineering Environments. Annals of Software Engineering 14(1-4) (2002) 311–340 2. Osterweil, L.: Software Processes are Software Too. In: ICSE ’87: Proceedings of the 9th International Conference on Software Engineering. (1987) 3. Gruhn, V.: Process–Centered Software Engineering Environments, A Brief History and Future Challenges. Annals of Software Engineering 14(1-4) (2002) 363–382 4. Ossher, H., Harrison, W., Tarr, P.: Software Engineering Tools and Environments: a Roadmap. In: ICSE’00: Proceedings of the Conference on The Future of Software Engineering. (2000) 261–277 5. Schwaber, C.: The Changing Face Of Application Life–Cycle Management. Technical report, Forrester Research, Inc. (2006) 6. Dowson, M.: Software Process Themes and Issues. In: ICSP’93: Proceedings of the International Conference on the Software Process: Continuous Software Process Improvement. (1993) 54–62 7. Barthelmess, P.: Collaboration and Coordination in Process–Centered Software Development Environments: A Review of the Literature. Information and Software Technology 45 (2003) 911–928 Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 3, 2009 ISSN 1988-3455 SISTEDES, 2009 47 8. Heimbigner, D.: Proscription versus Prescription in Process–Centered Environments. In: Proceedings of the 6th International Software Process Workshop. (1990) 99–102 9. Rolland, C.: A Comprehensive View of Process Engineering. In: CAiSE’98: Proceedings of the 10th International Conference on Advanced Information Systems Engineering. (1998) 1–24 10. Dustdar, S.: Caramba—A Process-Aware Collaboration System Supporting Ad hoc and Collaborative Processes in Virtual Teams. Distributed and Parallel Databases 15(1) (2004) 45–66 11. Engels, G., Schafer, W.: Challenges and Achievements in Software Engineering (CHASE). In: ICSE’01: Proceedings of the 23rd International Conference on Software Engineering. (2001) 671–675 12. Fuggetta, A.: Software Process: a Roadmap. In: ICSE ’00: Proceedings of the Conference on The Future of Software Engineering. (2000) 25–34 13. van der Aalst, W.M.P., ter Hofstede, A.H.M., Kiepuszewski, B., Barros, A.P.: Workflow Patterns. Distributed and Parallel Databases 14(3) (2003) 5–51 14. Russell, N., ter Hofstede, A., Edmond, D., van der Aalst, W.: Workflow Data Patterns. Technical Report FIT–TR–2004–01, Queensland University of Technology (2004) 15. Russell, N., ter Hofstede, A., Edmond, D., van der Aalst, W.: Workflow Resource Patterns. Technical Report BETA Working Paper Series, WP 127, Eindhoven University of Technology (2004) 16. van der Aalst, W., Hofstede, A.H.M.T., Weske, M.: Business process management: A survey. In: Proceedings of the 1st International Conference on Business Process Management, volume 2678 of LNCS, Springer-Verlag (2003) 1–12 17. Wasserman, A.I.: Tool Integration in Software Engineering Environments. In: Proceedings of the International Workshop on Environments on Software Engineering Environments. (1990) 137–149 18. Wicks, M.N., Dewar, R.G.: A New Research Agenda for Tool Integration. Journal of Systems and Software 80(9) (2007) 1569–1585 19. Borland Software Corporation: Open Application Lifecycle Management. White paper (2007) 20. CMMI Product Team: CMMI for Development, Version 1.2. Technical Report CMU/SEI– 2006–TR–008, Software Engineering Institute, Carnegie Mellon University. (2006) Reconocimientos: Al Dr. Ruiz-Corts por sus valiosos comentarios durante el desarrollo de este trabajo. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 3, 2009 ISSN 1988-3455 SISTEDES, 2009 48