PROCESOS SOFTWARE. Según esta estrategia, todo proceso debe planificarse, implantarse y evaluarse, para luego actuar sobre él.

Transcripción

1 PROCESOS SOFTWARE MOTIVACIÓN? Con independencia de la metodología o modelo implementado, es común la estrategia para la mejora continua de la calidad, basada en el Círculo de Deming o Plan, Do, Check, Act (PDCA). Según esta estrategia, todo proceso debe planificarse, implantarse y evaluarse, para luego actuar sobre él. Los procesos software son conjuntos coherentes de políticas, estructuras organizacionales, tecnologías, procedimientos y artefactos que son necesarios para concebir, desarrollar, instalar y mantener un producto software. La definición explícita de los procesos juega un papel fundamental en las principales iniciativas para la mejora de procesos software. 1

2 PROCESOS SOFTWARE MOTIVACIÓN? Las notaciones y lenguajes de procesos llevan ya varias décadas usándose en numerosos campos de la industria. Su objetivo principal siempre ha sido la búsqueda de costes y tiempos óptimos. Sin embargo, el uso de esta técnica es relativamente reciente dentro del ámbito de la Ingeniería del Software. Su aplicación dentro de este campo, (Ingeniería del Software), no solo se limita al intento de optimizar el proceso de desarrollo software en sí mismo. además se está utilizando como elemento de comunicación durante la elicitación de requisitos y como elemento fundamental dentro de enfoques como MDD (Model Driven Engineering) que buscan una gradual automatización del proceso de desarrollo. 2

3 MOTIVACIÓN? PROCESOS SOFTWARE Están tomando cada vez más importancia actividades como el modelado y el análisis de procesos de negocio. Un proceso de negocio es un conjunto de actividades relacionadas dentro de una organización que tienen como objetivo conseguir un determinado resultado. La gestión de estos procesos, BPM (Business Process Management), conlleva una serie de actividades de las cuales las más importantes son: 1. La definición de los procesos, normalmente mediante una notación formal, y la creación del correspondiente modelo. 2. La configuración de los procesos como paso previo a su ejecución. 3. La ejecución y/o simulación de los mismos. 4. El control y análisis de las distintas ejecuciones. 3

4 MOTIVACIÓN? PROCESOS SOFTWARE Los modelos de procesos de negocio se usan para mejorar la comunicación tanto entre el analista y el desarrollador como entre el analista y el cliente, se están utilizando para analizar el comportamiento de procesos de desarrollo de software con el objetivo de comprobar cuáles son las causas del retraso en las fechas de entrega y cuáles alternativas existen para reducir los costes y además, se están empezando a utilizar para integrar la definición, el modelado y el análisis de procesos dentro de las metodologías de desarrollo que tienen un enfoque MDD / MDA (Model Driven Development / Model Driven Architecture) con el objetivo de ir automatizando, poco a poco, y en la medida de lo posible, el desarrollo de productos software dentro de un dominio determinado. 4

5 MOTIVACIÓN? PROCESOS SOFTWARE La Ingeniería de Procesos Software promueve la producción sistemática de software mediante el seguimiento de una serie de procesos bien definidos. Una gestión integral de dichos procesos implica el desarrollo de una serie de actividades como son el diseño de los modelos de procesos, la verificación, la validación, el despliegue y la posterior evaluación. Los lenguajes de modelado permiten construir descripciones de procesos de forma homogénea, utilizando habitualmente una notación gráfica. Estos lenguajes ayudan a mejorar la correcta comprensión de los procesos por parte de todos los implicados en el mismo. 5

6 MOTIVACIÓN? PROCESOS SOFTWARE Revisaremos estos lenguajes para el modelado de procesos: Los diagramas de actividad de UML Business Process Modeling Notation (BPMN) El consorcio OMG publicó el estándar Software Process Engineering Metamodel (SPEM), un lenguaje destinado a facilitar y potenciar el entendimiento, la reutilización y la mejora de los procesos software. 6

7 DIAGRAMAS DE ACTIVIDAD (UML) o Describe una secuencia de actividades. o Describen comportamiento condicional y paralelo. o Son una variante de los diagramas de estados donde los estados son actividades. o Originalmente destinados a representar el comportamiento de un método o de un Caso de Uso. Aunque sintácticamente los Diagramas de Actividad se definen como una variante de los Diagramas de Estados, pues sus símbolos son en principio los mismos, su semántica es bastante diferente. Los Diagramas de Actividad están más orientados a mostrar las acciones, mientras que los Diagramas de Estados están centrados en los estados; y los Diagramas de Actividad pueden involucrar a objetos de varias clases, mientras que los Diagramas de Estados describen siempre el comportamiento de los objetos de una clase específica. Los Diagramas de Actividad son en esencia diagramas de flujo, con algunos elementos adicionales que les permiten expresar conceptos como la concurrencia y la división del trabajo. 7

8 DIAGRAMAS DE ACTIVIDAD (UML) ESTADO DE ACTIVIDAD o El símbolo principal es el Estado de Actividad o comúnmente Actividad o Es un estado que hace algo o Símbolo: Invocar Orden TRANSICIONES o Las actividades se enlazan por transiciones automáticas o Cuando una actividad termina se desencadena el paso a la siguiente actividad o Las actividades no poseen transiciones internas ni transiciones desencadenadas por eventos o Símbolo: 8

9 DIAGRAMAS DE ACTIVIDAD (UML) EJEMPLO: 9

10 DIAGRAMAS DE ACTIVIDAD (UML) COMPORTAMIENTO CONDICIONAL o Se modela mediante: o Guardas o Branch y Merges o Los branch y merges se utilizan para enfatizar el comportamiento condicional, pero siempre pueden sustituirse por guardas BRANCH o o o o Modelan Comportamiento Condicional Tienen una sola entrada y varias salidas etiquetadas por guardas mutuamente excluyentes. Puede usarse [else] como guarda Símbolo: 10

11 DIAGRAMAS DE ACTIVIDAD (UML) MERGE o Modelan Comportamiento Condicional o Tienen múltiples entradas y una salida. o Marcan el final del comportamiento condicional que comenzó con un branch o Símbolo: 11

12 SINCRONIZACIÓN o Se modela mediante o Fork o Join o Los anteriores, por lo general, estarán equilibrados FORK o Modelan el comportamiento paralelo o Tienen una entrada y varias salidas o Cuando la transición entrante se dispara todas las transiciones de salida ocurren en paralelo o Símbolo: DIAGRAMAS DE ACTIVIDAD (UML) 12

13 DIAGRAMAS DE ACTIVIDAD (UML) JOIN o Sincronizan el comportamiento paralelo o Tienen varias entradas y una salida o Símbolo: 13

14 SWIMLANES o o o DIAGRAMAS DE ACTIVIDAD (UML) Los D. Actividad cuentan qué ocurre pero no dónde. Una solución es etiquetar cada actividad con el lugar donde ocurre y la forma de hacerlo es con las swimlanes Las swimlanes dividen el diagrama en zonas verticales las cuales representan donde se lleva a cabo la actividad 14

15 DIAGRAMAS DE ACTIVIDAD (UML) 15

16 Proceso de Negocio: Proceso de Contratación DIAGRAMAS DE ACTIVIDAD (UML) 16