gestion de proceso de software_parte2

1

Proceso Software y Gestión del Conocimiento

Félix GarcíaDepartamento de Tecnologías y Sistemas de Información

Escuela Superior de InformáticaUniversidad de Castilla-La Mancha

Ciudad Real, 2008

2a 2a –– GestiGestióón de n de Procesos SoftwareProcesos Software

2UCLM-TSI. Curso Doctorado PSGC. Parte 2a. Gestión de Procesos Software

El Proceso SoftwareObjetivos parciales (i)

• En una Ingeniería es fundamental la idea de Procesoel cómo hacer.

• En los últimos años se ha desarrollado un nuevo campo en la Ingeniería del Software:

La Tecnología de Proceso SoftwareSu finalidad es aportar al mundo del software algunas soluciones que han sido eficaces en el mundo de la ingeniería de producción tradicional para Facilitar la Gestión de los Proyectos

• Sistema Software – Proceso – Producto - Proyecto

2


El Proceso SoftwareContenidos (i)

• Introducción• Conceptos básicos

Proceso de NegocioProceso Software

• Perspectiva Histórica del Proceso Software• Tecnología de Proceso Software

Proceso vs Modelo de ProcesoModelos de Proceso

ElementosNivelesVistas

Evolución de un PS. Metaproceso.Cuestiones pendientes.

• Lenguajes de Modelado de PS (LMP).Introducción al MetamodeladoRequerimientos en LMP.Propiedades de un LMP.


Tecnologías útiles.Taxonomía.Ejemplos:

MVP-L.LMP basado en redes de PetriLMP basado en reglasLMP basado en OOLMP basado en Grafos

• Entornos de Ingeniería del Software.Conceptos básicos.Modelo de servicios: ISO 15940.

Servicios de gestión del proceso.

EIS orientados a procesos.Arquitectura PSEE.

El Proceso SoftwareContenidos (ii)

3


• BásicasPiattini, M., García, F., Caballero, I. (2006). Calidad de los Sistemas Informáticos. Ra-Ma. Capítulo 6. NOVATICA. Tecnología de Procesos Software. Nº 171. Sept/Oct 2004. http://www.ati.es/novatica/2004/171/nv171sum.htmlFuggetta, A. (2000): Software Process: A Roadmap. 22nd Int. Conf. on Software Engineering (ICSE’2000), Future ofSoftware Engineering Track, June 4-11, Limerick (Irlanda). ACM Cugola, G., Guezzi, C. (1998). Software Processes: a Retrospective and a Path to the Future. In Software Process Improvement and Practice 4(3), pp. 101-123.

El Proceso SoftwareLecturas (i)


El Proceso SoftwareLecturas (ii)

• Complementarias:Derniame, J.C., Kaba, B.A., & Wastell, D. (1999): “Software Process: Principles, Methodology and Technology”. LNCS 1500, Springer-Verlag. Capítulos 1, 3, 4 (4.1-4.4) y 5 (5.1).

ISO/IEC (2001): CD 15940: Information Technology – Software Engineering Environment Services, working draft 5, May-2001.

Harrison, W., Ossher, H. & Tarr. P. (2000): Software EngineeringTools and Environments: a Roadmap. 22nd Int. Conf. on Software Engineering (ICSE’2000), Future of Software Engineering Track, June 4-11, Limerick (Irlanda). ACM.

SWEBOK (2004): Guide to the Software Engineering Body ofKnowledge; 2004 version 1.00 (May-2001). IEEE Computer Society Professional Practices Committee. Capítulos 1, 8, 9 y 10.

4



• Introducción

• Conceptos básicosProceso de NegocioProceso Software







Introducción (i)

• Ingeniería del Software - Problemática actual:El desarrollo y mantenimiento de software es un trabajo altamente complejo.

Los proyectos software son difíciles de gestionar.La tecnología de Proceso Software (PS) intenta simplificar la gestión de proyectos software.

• La importancia que la tecnología de PS tiene dentro de la Ingeniería del Software (IS) se comprueba viendo su aparición en el SWEBOK (Software Engineering Body of Knowledge):

3 de las 10 áreas de conocimiento que forman la IS se refieren a esta tecnología.

también utiliza 4 de las 7 disciplinas relacionadas.

• En suma, se trata de incidir más en los aspectos ingenieriles.

5


Introducción (ii)

• SWEBOK es un proyecto conjunto de IEEE-CS y ACM.• Está siendo debatido en el Subcomité JTC1/SC7 de ingeniería del software

de ISO.• Los objetivos principales de SWEBOK son cinco:

Promover una visión consistente del mundo de la IS.Clarificar el papel –y delimitar las fronteras- de la IS con respecto a otras disciplinas asociadas: ciencia de la computación, gestión de proyectos, ingeniería de computadores, y matemáticas.Caracterizar los contenidos de la disciplina.Proveer acceso a los contenidos del cuerpo de conocimientos.Proveer las bases para desarrollar planes de estudios o materiales para certificaciones individuales.


Introducción (iii)

• SWEBOK considera que la IS está formada por 10 áreas de conocimiento, y que tiene 7 disciplinas relacionadas:

Áreas de Conocimiento Disciplinas RelacionadasRequisitos Software Ciencias Cognitivas y Factores HumanosCiencias Cognitivas y Factores HumanosDiseño de Software Ingeniería de ComputadoresConstrucción de Software Ciencia de la ComputaciónPrueba del Software GestiGestióón y Ciencia de la Gestin y Ciencia de la GestióónnMantenimiento del Software MatemáticasGestión Configuración Software GestiGestióón de Proyectosn de ProyectosGestión de la IS IngenierIngenieríía de Sistemasa de SistemasProceso de ISHerramientas y Métodos en ISCalidad del Software

PSPS

6


Introducción (iv)

La importancia de

un buen Proceso:

Una casa en 4 horas

©Building Industry Association, San Diego, CA.



• Introducción

• Conceptos básicosProceso de NegocioProceso Software





• Lenguajes de Modelado de PS (LMP).Requerimientos en LMP.Propiedades de un LMP.

7


Proceso de negocio: definición

• Definición (Sharp, 2001):

Colección de tareas de trabajo interrelacionadas, iniciadas en respuesta a un evento, que permiten alcanzar un

resultado específico para el cliente del proceso.

• Es decir, un proceso de negocio (PN) esun proceso para entregar un resultado a un cliente.


Proceso de negocio: características

• Otras características son:Medible: debe poderse medir el PN en la forma que interese a los participantes (stakeholders).

Automatizable: las tareas pueden ser manuales, semiautomáticas y automáticas.

Niveles: se puede definir a distintos niveles de detalle (hitos, flujos de trabajo, etc.).

Para un cliente interno o externo.

8


Proceso Software: definición

• Un Proceso Software (PS) es

Un conjunto coherente de políticas, estructuras organizacionales, tecnologías,

procedimientos y artefactos que son necesarios para concebir, desarrollar,

instalar y mantener un producto software.(Fugetta, 2000)


Proceso Software: apoyos

• Un PS aprovecha diversas contribuciones y conceptos:

Tecnologías de desarrollo de software: herramientas, infraestructuras y entornos.

Métodos y Técnicas de desarrollo de software: cómo usar la tecnología.

Comportamiento Organizacional: la ciencia de las organizaciones y la personas.

Marketing y economía: como cualquier otro producto, el software debe dirigirse a clientes reales y, por tanto, está sujeto a las reglas del mercado.

9


Proceso Software: vs PN

• Por tanto, debemos prestar atención a la compleja interrelación que se produce en un PS entre los diversos factores organizacionales, culturales, tecnológicos y económicos.

=>

• Un PS es un PN realizado por una organización para desarrollar y mantener un producto software.


Procesos Software: naturaleza (i)

• Son complejos:• No son procesos de producción:

Dirigidos por excepciones,

Muy determinados por circunstancias impredecibles,

Cada uno con sus peculiaridades.

• No son procesos de ingeniería “pura”:Desconocemos las abstracciones adecuadas,

Dependen demasiado de demasiada gente,

Diseño y producción no están claramente separados,

Presupuestos, calendarios, calidad no pueden ser planificados deforma fiable.

10


Procesos Software: naturaleza (ii)

• No son (completamente) procesos creativos:Algunas partes pueden ser descritas en detalle,

Algunos procedimientos han sido impuestos.

• Están basados en descubrimientos que dependen de la comunicación, coordinación y cooperación dentro de marcos de trabajo predefinidos:

Los entregables generan nuevos requisitos,

Los costes del cambio del software no suelen reconocerse,

El éxito depende de la implicación del usuario y de la coordinación de muchos roles (ventas, desarrollo técnico, cliente, etc.).


Procesos Software: Gestión (i)

• Calidad enfocada al proceso: Los Procesos Software tienen una influencia directa en la calidad de los productos software:

Creciente interés en las empresas software para promover la mejora de los procesos software a la hora de mejorar la calidad de los productos

Las aplicaciones software son productos cada vez más complejor lo que influye en la complejidad de sus procesos de desarrollo y mantenimiento

• Requisitos de calidad de los procesos software:Producir los resultados esperadosCorrecta definiciónSer mejorados en función de los objetivos de negocio

Gestión del Proceso Software

11


Procesos Software: Gestión (ii)

• Responsabilidades Clave en la Gestión del PS:

Improve the Process

Control the Process

Define the Process

Measure the Process

Execute the

Process

Punto de partida para la comprensión, ejecución y mejora continua

Representación Precisa

(sin ambigüedad)

Gran diversidad de propuestas:

– Elementos comunes:

Actividad, Artefacto, Recursos

Organizaciones y Roles

ModeladoMedición


El Proceso SoftwareContenidos (i)• Introducción• Conceptos básicos


• Perspectiva Histórica del Proceso Software

• Tecnología de Proceso SoftwareProceso vs Modelo de ProcesoModelos de Proceso



• Lenguajes de Modelado de PS (LMP).Requerimientos en LMP.Propiedades de un LMP.

12


• El Proceso como una caja negra

Sólo visibilidad de las entradas y salidasNo hay forma de controlar lo que sucede en el procesoConsecuencias:

Grandes retrasos en la entregaIncremento significativo de los costes

ProcesoProceso

Requisitos del Requisitos del ProductoProducto ProductoProducto

Perspectiva Histórica de los Procesos Software (i)


• El Proceso como una caja negraEn PS la no visibilidad del proceso tiene consecuencias aún peores respecto a otros tipos de procesos dada la naturaleza del software:

Especificación informal de requisitosVariabilidad de los requisitos

Consecuencias:El producto no coincide con los requisitos especificadosLos costes de modificación del producto una vez desarrollado son muy altos

Necesidad de un Proceso Visible (Transparente)

requisitosrequisitos

Perspectiva Histórica de los Procesos Software (ii)

13


Perspectiva Histórica de los Procesos Software (iii)

• Mitos (Cugola y Ghezzi, 1999):1.Ciclos de Vida del Software

2.Metodologías

3.Desarrollo Formal

4.Automatización

5.Gestión y Mejora

6.Programación del Proceso


Perspectiva Histórica de los Procesos Software (iv)

• 1. Ciclos de Vida del SoftwareAños 60

Definen la vida de un producto desde su concepción hasta la finalización de su uso

Un Modelo de Ciclo de Vida estandarizan la descomposición de un proceso en fases, actividades y los artefactos que fluyen entre fases

Ejemplo: CV en cascada

Mito: Un modelo de Ciclo de Vida puede ser definido para guiar el proceso de desarrollo/mantenimiento

14


Perspectiva Histórica de los Procesos Software (v)

• 2. MetodologíasInicio Años 60, 70 con propuestas de metodologías de desarrollo estructurado

Guía de actividades, procedimientos, productos, técnicas, participantes, etc..

Incluyen buenas prácticas basadas en la experiencia

Algunos inconvenientes:Algunas metodologías fueron aplicadas en contextos diferentes a aquellos en los que se obtuvo la experiencia sobre buenas prácticas de desarrolloEn ocasiones implicaban una documentación pesada y falta de soporte automáticoNotaciones informales dificultad para evaluar la corrección/consistencia de los productos


Perspectiva Histórica de los Procesos Software (vi)

• 3. Desarrollo FormalFinales 60

Enfoque de desarrollo de software basado en las matemáticas

Los programas son entidades matemáticas que pueden ser especificadas formalmente:

Transformación automática de Especificación Formal a Código

Como solución general para el problema del software presentaba en sus orígenes algunos inconvenientes:

Imposibilidad de conocer todos los requisitos al comienzoEscalabilidadRequisitos no funcionales

15


Perspectiva Histórica de los Procesos Software (vii)

• 4. Automatización:Años 70, 80

La mejora de la tecnología (HW, SW) facilita la aparición de:Software Development Environments (SDE)Lenguajes de Cuarta Generación

Este tipo de entornos facilitaba la tarea de programación

Inconveniente: La programación no es la única actividad involucrada en el proceso de desarrollo/mantenimiento de software


Perspectiva Histórica de los Procesos Software (viii)

• 5. Gestión y Mejora:Años 80Creciente Importancia en la industria Software por la calidadAparecen estándares como la familia ISO 9000 y modelos de madurez como CMM (finales de los 80)Estándares ISO 9000

Certificación Calidad Garantía de que una organización software entregará productos de calidad

Estos estándares y modelos incluyen prácticas que facilitan la gestión de los procesos softwareAparecen ciertas limitaciones:

¿una organización con certificación de calidad obtendrá siempre productos de alta calidad?Incremento de Burocracia

16


Perspectiva Histórica de los Procesos Software (ix)

• 6. Programación del Proceso :Años 90“Software Processes are software too” (Osterweil, 1987)Cada organización software es diferente (cultura, habilidades, personal, productos..). Incluso en la misma organización los distintos proyectos pueden ser muy diferentes

No hay un único proceso de desarrollo de software

Necesidad de lenguajes para describir los procesos Modelos de Procesos:

VerificablesEjecutables

Entornos para dar soporte al desarrollo, documentación, análisis ejecución y evolución de modelos de procesos

PSEE: Entornos de Ingeniería del Software Orientados al Proceso


El Proceso SoftwareContenidos (i)• Introducción• Conceptos básicos


• Perspectiva Histórica del Proceso Software

• Tecnología de Proceso SoftwareProceso vs Modelo de ProcesoModelos de Proceso

Elementos, Niveles, Vistas



17


Tecnología de Proceso Software: Impacto

Proceso de Gestión Proceso de Producción

Tecnología de Gestión

Tecnología de Producción

Entorno exterior

Proporciona Proporciona

Estandariza Justifica

Controla

Realimenta

ExplotaExplotaEntorno de IngenierEntorno de Ingenieríía del Software a del Software orientado al Procesoorientado al ProcesoPSEE

ExplotaIntegraIntegra

Soporta

Tecnología deProcesos

Proporciona


Tecnología de Proceso Software: Objetivo

Dominar la complejidad inherente al PS mediante una comprensión profunda del proceso en sí mismo y mediante un soporte automatizado por medio de un PSEE

18


Proceso vs Modelo de Proceso (MP) (i)

• Los procesos de diferentes proyectos tienden a seguir patrones comunes.

• Es necesario intentar capturar estos aspectos comunes en una representación del proceso, la cuál describe estas características comunes y fomenta la homogeneidad.

• El estudio de los procesos de producción de software ha llevado al desarrollo de varios Ciclos de Vida del software que pueden ser empleados en la IS: en Cascada, Evolutivo y en Espiral.

Estos modelos del Ciclo de Vida ayudan a comprender mejor el PS, y a determinar el orden de actividades globales envueltas en la producción de software.


Proceso vs MP (ii)

• El objetivo final de la tecnología de PS es lograr que la representación de un proceso pueda ser usada para conducir los actuales procesos de desarrollo y mantenimiento del software.

• Con tal fin, surgen varios conceptos:PSEE: Process-sensitive Software EngineeringEnvironment.Modelo de Procesos (MP): representación abstracta de una familia de procesos expresada en una adecuada notación de modelado de procesos (formalismo).

19


Proceso vs MP (iii)

• La disponibilidad de un MP (computerizado) proporciona capacidades para:

Soporte directo a los desarrolladores vía control de su trabajo, su coordinación con otros, etc.);

Soporte indirecto, como información del estado actual del proceso, el significado de los puntos de decisión, etc. dirección

automatización: invocación automática de herramientas no interactivas);

eficiencia: un MP preciso es primordial en el aumento de la efectividad, ya que proporciona una base no ambigua para la comunicación entre los procesos.


Proceso vs MP (v)

• Los MP juegan un rol esencial en la supervisión, simulación, validación, verificación y mejora de procesos:

supervisión: permiten una clara comprensión de lo que puede ser observado y por qué;simulación: el comportamiento de un proceso puede ser estudiado al menor coste sin desarrolladores reales o herramientas.Verificación y validación: son necesarios para probarformalmente las propiedades de interés del proceso.

Todas las capacidades anteriores son necesarias para la Mejora de procesos.

20


Elementos de un MP

Actividad

Desarrollador

Rol Norma

Herramienta

Producto

Tiene sub Tiene sub

Tiene sub

Tiene entrada

Tiene intermedioTiene salida

Utiliza

Obedece

Necesita

Juega

Actividad Recurso Producto Organización


Niveles de un MP (i)

• Los procesos pueden ser representados con niveles incrementales de detalle, capturando sub-procesoscada vez más pequeños, correspondientes a asuntos cada vez más detallados:

Ciclo de Vida;

MP genérico;

MP detallado (customized);

Reificable (enactable);

Reificado (enacting).

21


Niveles de un MP (ii)

• Además, se distinguen dos dominios en cada nivel:Realización (performance) del proceso:

concerniente al acto de participar en un proceso, personas y herramientas.

Reificación (enactment) del proceso:relacionado con el acto de conducir automáticamente el proceso, es decir, interpretar con más detalle el MP.

• Dualidad de pertenencia a los dominios:Las herramientas y las personas, al ser condicionadas por el entorno, también pertenecen al dominio de reificación.Mientras que un proceso se realiza en el mundo real, es reificado en el mundo abstracto del modelo computerizado.Puesto que los computadores son parte del mundo real, se dice que la reificación es parte de la realización.


Vistas de un MP (i)

• Expresan un punto de interés particular en vez del MP completo (similar a vistas en BD):

Sub-modelos (en modelado bottom-up).Modelos parciales (en modelado top-down).

• Las más habituales son:De Actividades,De Productos,De Recursos, yDe Roles.

• Nos son disjuntas: una vista no puede ser definida sin usar conceptos de otras.

22


Evolución de un PS (i)

• Se deben considerar dos aspectos en un entorno de producción de software:

Un proceso en desarrollo, P, es decir el proceso de producción del mundo real incluyendo actores humanos y herramientas que acompañan a todas las actividades dirigidas al desarrollo y mantenimiento de un producto software, yUn modelo de procesos, MP, que es una representación del mundo real, y captura el estado actual de las actividades para guiar, hacer cumplir o automatizar partes del proceso de producción o de mantenimiento.


Evolución de un PS (ii)

• Idealmente, P y MP deben estar perfectamente alineados: el estado interno de MP debe ser una fiel representación del actual estado de los asuntos en el mundo real.

=> P es una instancia de PM

• Pero cualquier PS en el mundo real es un proceso creativo y dinámico que abarca a mucha gente, y no puede ser reducido a la programación de autómatas.⇒El MP debe coordinar actividades y gestionar el flujo de información, y

⇒MP debe adaptarse a cualquier evolución del proceso P en el mundo real.

23


Evolución de un PS (iii)

• Hay diversas razones por las que puede cambiar un PS:puede ser erróneo;

ciertos pasos importantes no están previstos;

el MP puede ser genérico y necesita ser detallado para obtener resultados específicos;

las presunciones sobre las cuales se construyó el MP ya no son válidas;

las dinámicas políticas, humanas y tecnológicas pueden inducir a su cambio.

• Como resultado, el proceso P del mundo real y el MP debenevolucionar de forma conjunta y coherente.


Metaproceso

• Conclusión: la evolución de un PS es en sí misma un proceso completo.

• Este proceso de alto nivel es llamado meta-proceso:El gestor del proyecto necesitará implicar los servicios del modelador para desarrollar un MP aumentado, validar el nuevo modelo, y decidir cuando comenzar a realizarlo.

Este metaproceso incluye:Los pasos para cambiar los procesos del mundo real, yLos pasos para introducir cambios en el MP.

Su principal función es asegurar que P y MP permanecen consistentes.

24


Cuestiones pendientes

• Surgen una serie de preguntas que debemos plantearnos e intentar responderlas:

¿Cómo construimos un MP?¿Cómo lo reificamos?¿Qué características debe tener el formalismo a utilizar?¿Cómo se puede cambiar y mejorar un PS y su MP asociado?¿Qué arquitectura debe tener un PSEE?¿Qué papel desempeñan las personas?........................


El Proceso SoftwareContenidos (ii)• Tecnología de Proceso Software


Elementos, Niveles, VistasEvolución de un PS. Metaproceso.Cuestiones pendientes.

• Lenguajes de Modelado de PS (LMP).Introducción al MetamodeladoRequerimientos en LMP.Propiedades de un LMP.Tecnologías útiles.Taxonomía.Ejemplos:

MVP-L.LMP basado en redes de PetriLMP basado en reglasLMP basado en OOLMP basado en Grafos

25


Introducción al Metamodelado

• Arquitecturas de Modelización en 4 capas:

Modelo de meta-meta-metadatos (=MetaMetaModelo)

Modelo de metadatos (=Modelo)

Datos

Modelo de meta-metadatos (=MetaModelo)

Lenguaje estándar para definición de

metamodelos

Ej Metamodelos E/R UML

Diagramas E/R Modelos UML

Base datos empresa

etc..L



Datos



metamodelos



Base datos empresa

etc..L



Datos



metamodelos



Base datos empresa

etc..L



Datos



metamodelos



Base datos empresa

etc..L



Datos



metamodelos



Base datos empresa

etc..L



• Metamodelo = Modelo de un Modelo. Arquitectura estándar MOF (Meta Object Facility)

Estándar OMG para definición, representación y gestión de metadatos

Modelo MOF

Modelo E/R

Esquemas

ModeloModelo Modelo Modelo Modelo Datos

Modelo Relacional



Esquemas

M3

M1

M2

M0

DOMINIO DATOS DOMINIO PROCESOS

Modelo MOF

MetamodeloProcesos Software

Modelo Modelo Modelo Modelo Modelo Datos



M3

M1

M2

M0

MANTEMA Otras Metodologías

26



• Metamodelado. Caso Procesos:

Lenguaje de Modelado de Procesos


Lenguajes de Modelado de PS

• Un lenguaje de modelado de PS (LMP) expresa los procesos software (PS) en forma de modelos de procesos software (MP).

• Todos los elementos de proceso (actividades, roles, recursos, etc.) deben poderse describir.

• Los elementos del metaproceso (evolución del proceso) también se deben poder expresar.

• Un LMP puede ser:Formal: tiene sintaxis y semántica formales.

Semi-formal: tiene notación formal (normalmente gráfica) pero no tiene semántica formal.

Informal: sin sintaxis y semánticas formales (leng. natural).

27


Requerimientos en LMP (i)

• Hay 6 elementos de proceso (primarios) que debe poder modelar un LMP:

Actividades.Productos.Roles.Personas.Herramientas.Soporte para la evolución (al menos del MP):

a nivel técnico (p.e., mediante reflexión o interpretación), ya nivel conceptual (mediante un metamodelo asociado).


Requerimientos en LMP (ii)

• Los elementos del metaproceso (secundarios) son:Proyecto/Organización.

Organizaciones consisten de humanos relacionados con otros humanos y elementos.Un proyecto es una estructura temporal de la organización montada para poder alcanzar un objetivo específico.

Contexto de Trabajo.Formado por espacios de trabajo.Cada espacio de trabajo contiene y controla artefactos para un (sub)proceso.Estos artefactos suelen ser ficheros en un repositorio.

Vista de usuario.Interfaz general para ayudar al usuario a comprender el MP y guiarlo durante su reificación.Hay un modelo interno (cómo trabaja) y otro externo (cómo se hace).

28


Requerimientos en LMP (iii)

• Elementos del metaproceso (cont.):Modelo de Cooperación.

Permitir modos de cooperación secuencial y paralelo.Incluir protocolos de comunicación de objetos.Coordinación de acciones (ordenación y sincronización).

Modelo de Versionado/Transacciones.

Modelo de Calidad/Rendimiento.Modelo de Calidad del Producto, incluye objetivos de calidad del producto y métricas asociadas.Modelo de Rendimiento del Proceso, expresa el cumplimiento con respecto a tiempos, costes, roles, etc.


Requerimientos en LMP (iv)

• Un LMP se usa de diferente forma por diferentes roles durante las diferentes fases del metaproceso; por tanto, en cada fase interesan unas características diferentes en el LMP. Ejemplos:

En Especificación de requisitos del proceso: orientado al modelado conceptual, intuitivo y con notación fácil para los usuarios no técnicos (gráfica).

En Implementación del Proceso: debe permitir el suficiente detalle para que el MP sea reificado; por tanto, el LMP debe ser ejecutable (formal).

29


Propiedades de un LMP

• Formalidad.• Expresividad.• Comprensibilidad.• Abstracción y modularidad.• Ejecutabilidad.• Analizabilidad.• Soporte de evolución.• Múltiples vistas.


Tecnologías útiles

• Gestión de proyectos: diagramas de barras, redes de actividades.

• Lenguajes de especificación formal: redes de Petri (SLANG).

• Notaciones informales de diseño: OO (E3), UML.Estáticas: ER.

De comportamiento: diagramas de transición de estados.

Funcionales: diagramas de flujo de datos.

• Lenguajes de programación: ADA (APPL/A).

• Lenguajes de bases de datos: BD activas (ADELE).

• Herramientas CASE y mecanismos de integración.

• Flujos de Trabajo y Trabajo en Grupo.

30


Taxonomía (i)

• Según el elemento del proceso en el que se centran:Producto: EPOS, Adele.Actividades: MARVEL, MERLIN, SLANG.Proyecto: MS-Project.Roles: PWI.

• Otra clasificación alternativa:Funcionales: centrados en describir las actividades.De Comportamiento: centrados en cuando y como se realizan las actividades.Organizacionales: centrados en el “cuando” y “por quién”.Informacionales: centrados en los artefactos y procesos y sus asociaciones.

• Otra clasificación es según la fase del metaproceso a la que se orientan: elicitación, análisis, diseño, implementación, reificación, y evaluación.


Taxonomía (ii)

• Formalismos utilizados en LMP:Lenguajes de Programación: APPL/A, JIL.

Reglas: Marvel, Oz, Atlantis.

Orientación a Objetos: E3, EPOS/Spell.

Grafos y gramáticas: Hakoniwa.

Redes de Petri: SLANG/SPADE.

31


Ejemplo: MVP-L

• Multi View Process Modeling LanguageDesarrollado en las universidades de Maryland y Kaiserslautern (Rombach, Marsh, Lott, Bröckers, Verlage).

Objectivo principal:

Modelado descriptivo de grandes procesos del mundo real paracomprender, analizar, guiar y mejorar los proyectos de desarrollo de software.


MVP-L: constructores (i)

• Modelos (Tipos) para la descripción deModelos de proceso: describen procesos, flujos de información, y descomposición del trabajo.

Modelos de producto: atributos de los productos creados durante la ejecución.

Modelos de recurso: herramientas y personas.

Los modelos pueden ser adaptados al contexto actual durante suinstanciación.

• AtributosSon globales o relacionados con uno de los 3 modelos.

Sus valores corresponden a medidas de datos y estados.

32


MVP-L: constructores (ii)

• Objeto Ejecutable: plan del proyecto.

• Relaciones entre objetos:Flujo de producto (consume, produce, ..)

Flujo de control (criterios de entrada/salida de procesos, invariantes)

Descomposición/Agregación (refinamiento)

Ocultamiento de información (interfaz de modelo vs cuerpo de modelo)


MVP-L: representación gráfica

Producto

Proceso

Recurso

Criterio de Entrada/Salida

EntradaSalida

consume

produce

consume_produce

33


problem: PD

def_requisitos: R_Def

req: RD

ood: OODesign

st_code: ST

diseñar: OO_Des

codificar: ST_Coding

Frank: System_Analyst

Problem.status=completereqDef.status=complete

Paco: Analista_Sistemas

problem.status=completedef_requisitos.status=complete

Ana: Diseñador_OO

def_requisitos.status=completediseñar.status=complete

Jaime: Programador

diseñar.status=completecodificar.status=complete

MVP-L: ejemplo gráfico


MVP-L: ejemplo textual

project_planimports

product_model PD, RD, OODesign, ST;process_model R_Def, OO_Des, ST_Coding;resource_model Analista_Sistemas, Diseñador_OO, Programador

objectsproblem: PD; def_requisitos: R_Def;req: RD; diseñar: OO_Des;ood: OODesign; codificar: ST_Coding;st_code: ST;

object_relationsdef_requisitos(i1=>problem, o1=>req, r1=>Paco);diseñar(i1=>req, o1=>ood, r1=>Ana);codificar(i1=>ood, o1=>st_code, r1=>Jaime);

end project_plan

34


Ejemplo: LMP basado en redes de Petri

• SLANG:Basado en ERnets(Environments/ Relationships)

Proporcionan una manera formal para añadir datos, funcionalidad y temporalidad a las redes de Petri


• Programación lógica, Minsky.

r1: canPass(S,^ new(_,_), programmer) :- memberOf(S, manager). r2: canPass(S,^ new(newborn,_), 1Module) :-

memberOf(S, programmer), newborn.level=S.level, newborn.owner=S. r3: canPass(S, ^M, T) :- memberOf(S, programmer),

T.owner=S,not(M = set(level,_). r4: canPass(S, @M, T) :- memberOf(S, user), memberOf(T, user). r5: canPass(S, @M, T) :- memberOf(S, 1Module),

memberOf(T, 1Module), (S.level = T.level | S.level = T.level+1).

Ejemplo: LMP basado en reglas

35


• Sistemas de producción (Marvel).

(neverpermitted compiled-module-with-non-analyzed-proc(E (mod proc) (and (mod-proc mod proc) (mod-status mod :compiled)

(not (proc-status proc :analyzed))) :repair (lambda (mod proc) (++ mod-status mod :uncompiled)))

(defautomation analyze-procedure((proc) s.t. (start (proc-status proc :unanalyzed))) (lambda (proc) (analyze proc)))

(defautomation compile-module ((mod) s.t. (start (and (not (mod-status mod :compiled))

(A (proc) (implies (mod-proc mod proc) (proc-status proc :analyzed))))))

(lambda (mod) (compile-mod mod)))

Ejemplo: LMP basado en reglas


• E3Árbol de herencia de clases.

Ejemplo: LMP basado en OO

36


• APEL

Ejemplo: LMP basados en grafos:


LMPs: Propuestas de Metamodelos

• Diagramas de Gantt y PERT• Formato de Intercambio de Procesos

(PIF) (Lee et al., 1998) • Lenguaje de especificación de procesos

(PSL) (Schlenoff et al., 1998) • Modelo del Proceso Unificado (UPM)

(Unified Process Model, UPM) (Kruchten, 1999a)

• Core Plan Representation (CPR) (Pease, 1998)

• Definición de Proceso de la WorkflowManagement Coalition (WfMC, 1998)

• Arquitectura de Sistemas de Información Integrados (ARIS) (Scheer, 1998)

Metamodelo de Metamodelo de Procesos de Procesos de

IngenierIngenieríía dela delSoftwareSoftware(SPEM)

(OMG, 2002c)

37


Ro l Pro d u cto d e T rabajo0..*1

Activ id ad0..*

1

0..*

0..*

0..*

0..*

e s re sp o n sa b le d e

rea l iz a U sa P ro d u ce

+ entrada + s alida0..* 0..*

0..* 0..*

0..*

1

1 0..*

PaquetesElementos BásicosDependenciasEstructura del Proceso

Componentes del ProcesoCiclo de Vida del Proceso

Metamodelo genérico para la creación de modelos de procesos concretosNo da soporte a la ejecución (enactment) de los procesosSe describe como un metamodelo y como un perfil (profile) UMLModelo Conceptual de SPEM

SPEM (Software Process Engineering Metamodel) (i)


Classifier(fro m Co re)

Parameter

kind : Param eterDirecti onKind(from Co re)

ActivityParameterhasWorkPerArtifact : Boolean

W orkDefinition

0..* 0..*

+subW ork

0..*

+parentW ork

0..*

ProcessPerformer

0..* 1

+work

0..*{ordered}

+performer

1

Operation(from Core)

ActionState(from Activ ityGraphs)

ModelElement(from Core)

StepActivity0..*1

+step

0..*1ProcessRole

0..*

0..*

+assistant 0..*+activity

0..*

W orkProductisDeliverable : Boolean

0..*

0.. 1

+work Product0..*

+responsibleRole

0.. 1

W orkProductKind

0 ..*

1

0 ..*

+k ind 1

PaqueteEstructuradel Proceso

SPEM (ii)

38


• Notación Gráfica:SPEM no dispone de notación gráfica propia

Se pueden utilizar los distintos Diagramas de UML (Clases, Paquetes, Actividad, Casos de Uso, Secuencia) para describir modelos de SPEM añadiendo iconos y estereotipos:

Actividad Rol del ProcesoProducto de Trabajo

OtrosGuía (Técnica)Fase

SPEM (iii)


• Diagramas de Paquetes:

SPEM (iv)

39


• Diagramas de Casos de Uso:

SPEM (v)


SPEM (vi)

• Diagramas de

Actividad:

40


Tecnologías útiles.Taxonomía.Ejemplos:

MVP-L, LMP basado en redes de Petri, LMP basado en reglas, LMP basado en OO, LMP basado en Grafos

• Entornos de Ingeniería del Software.Conceptos básicos.Modelo de servicios: ISO 15940.

Servicios de gestión del proceso.

EIS orientados a procesos.Arquitectura PSEE.

El Proceso SoftwareContenidos (ii)


Entornos de Ingeniería del Software (EIS)

Colección de herramientas que proporcionan un soporte automático, parcial o total, a las actividades de ingeniería del

software.

Un EIS da soporte a actividades humanas mediante una serie de servicios que describen las capacidades del entorno.

Mediante la automatización de actividades, de forma parcial o total, un EIS aporta beneficios a una organización:

reducción de costes (mayor productividad),mejora en la gestión, ymayor calidad en el producto final.

41


EIS: Integración

• Lo que más diferencia un EIS de un simple conjunto de herramientas ejecutándose en una computadora es el grado de integración que provee.

• La integración en un EIS abarca varias dimensionesdiferentes (Wasserman, 1990):

Datos: habilidad de compartir la información dentro del EIS.Control: habilidad de combinar las funcionalidades ofrecidas de forma flexible.Presentación: habilidad de interactuar con las funcionalidades del entorno mediante modos de interacción similares.Procesos: habilidad de acceder a las funcionalidades del entorno utilizando un proceso software reificable predefinido.Marco de Trabajo: grado en que las herramientas hacen uso del marco de trabajo.


EIS: Modelo de Servicios: ISO 15940

• ISO 15940: Information Technology - Software EngineeringEnvironment Services.

Proporciona un modelo de referencia: descripción de todos los servicios que soportan a los procesos del ciclo de vida del software (según ISO 12207).

Cada descripción de un servicio incluye: concepto, operaciones básicas, y automatización.

En enseñanza y entrenamiento de Ingeniería del Software:Utiliza una base comúnmente acordada, de conceptos y definiciones, para la presentación de EIS.Permite enseñar Ingeniería del Software basándose en un completo abanico de servicios.

42


EIS: Categorías de Servicios

• Los servicios de un EIS se clasifican en categorías que reflejan la amplitud de las actividades de Ingeniería del Software:

Ingeniería Técnica (compilación)

Gestión Técnica (gestión de configuraciones)

Gestión del Proyecto (análisis de riesgos)

Gestión del Proceso (mejora de procesos)

Soporte (publicación)

Globales (gestión de objetos)


Servicios EIS: Ingeniería Técnica

• Soportan actividades relacionadas con la especificación, diseño, implementación, prueba y mantenimiento de software:

Ing. de requisitos softwareDiseño softwareSimulación y modelado softwareVerificación de softwareGeneración de software basado en componentesGeneración de código fuenteCompilaciónAnálisis estático de softwareDepuración

Prueba de softwareIntegración de componentesIngeniería inversa de softwareReingeniería de softwareTrazabilidad de softwarePruebas de cualificación de softwarePrototipado softwareDocumentación de usuario

43


Servicios EIS: Gestión Técnica

• Soporte a actividades mixtas comunes a ingenieros y gestores:

Gestión de configuraciones.

Gestión de cambios.

Gestión del repositorio EIS.

Reutilización.

Colección y análisis de métricas.

Aseguramiento de calidad.

Auditoría.


Servicios EIS: Gestión del Proyecto

• Soporte a actividades relacionadas con la planificación y ejecución de un proyecto software:

Planificación.

Estimación.

Análisis de riesgos.

Seguimiento.

Evaluación.

44


Servicios EIS: Gestión del Proceso

• Ayudan a los proyectos a alcanzar disciplina, control y comprensión clara de sus procesos y actividades:

Definición de procesos.

Biblioteca de procesos.

Iniciación de procesos.

Utilización de procesos en proyectos.

Supervisión de procesos.

Mejora de procesos.

Documentación de procesos.


Servicios EIS: Soporte

• Usados por todos los usuarios. Asociados con procesar y distribuir datos en formato manejable por personas.

Soporte global.

Publicación.

Soporte al trabajo en grupo.

Soporte a la comunicación de usuarios.

Administración del EIS.

Cumplimiento de políticas.

45


Servicios EIS: Globales

• Ayudan a que la infraestructura del EIS de soporte a las aplicaciones y herramientas.

Gestión de la infraestructura del EIS.

Comunicación inter-proceso.

Gestión de objetos.


Servicios de Gestión del Proceso (i)

• Definición de procesosProvee para el establecimiento de los procesos organizacionales,cubriendo el ciclo de vida del software a través de la adaptación y particularización de un conjunto de clases de procesos de referencia de alto nivel.

Operaciones básicas: Analizar los requisitos de proceso, incluyendo los específicos del dominio y los específicos de la aplicación.Instanciar, componer, descomponer, particularizar y modularizardefiniciones de proceso.Simular, modelar y validar definiciones de proceso.

Automatización:Todo lo anterior.

46


Servicios de Gestión del Proceso (ii)

• Biblioteca de procesosSoporta la reutilización de capacidades de procesos en base a activos de proceso (assets). Un activo puede oscilar desde la definición de una actividad simple hasta un ciclo de vida completo. Activos pueden ser objetos versionados.

Operaciones básicas: Crear, modificar y eliminar activos de proceso.Certificar, medir y administrar activos de proceso.

Automatización:Almacenamiento y versionado de activos de proceso.Procesamiento de informes de estado.


Servicios de Gestión del Proceso (iii)

• Iniciación de procesosSoporta la asignación de un modelo de ciclo de vida (metamodelo), un conjunto de procesos, y el EIS para satisfacer los requisitos y restricciones de un proyecto particular.

Operaciones básicas: Revisar criterios y restricciones de un proyecto y seleccionar modelo de ciclo de vida.Definir interrelaciones y particularizar procesos y actividades.

Automatización:Definición de interrelaciones y particularización de procesos y actividades.

47


Servicios de Gestión del Proceso (iv)

• Utilización de procesos en proyectosCapacidades para ayudar a utilizar procesos dentro de un proyecto (p.e., asignación de usuarios, facilidades navegacionales, etc.).

Operaciones básicas: Ayudar sobre el proceso y facilitar orientación para miembros del equipo del proyecto.Consultar e informar sobre utilización y estado de procesos.Especificar, recolectar y reportar sobre métricas de procesos.Simular interactivamente definiciones de proceso, y gestionar representaciones de alto nivel.

Automatización:Consulta y reporte de utilización y estado de procesos.


Servicios de Gestión del Proceso (v)

• Supervisión de procesosSoporta la observación, detección, registro y traza de actividades de procesos (dentro de proyectos).

Operaciones básicas: Establecer condiciones y criterios de supervisión.Observar la evolución en el estado de la reificación de procesos.Detectar la ocurrencia de eventos de proceso específicos.Registrar la ocurrencia de eventos de proceso específicos.

Automatización:Detección y registro de la supervisión.Presentación de datos de supervisión, incluidos gráficos.Distribución de datos de supervisión.

48


Servicios de Gestión del Proceso (vi)

• Mejora de procesosSoporta la evaluación, medición y modificación de los procesos organizacionales y de proyectos específicos, y de los ciclos de vida de proyectos.Operaciones básicas:

Definir objetivos de eficiencia.Identificar mediciones, relacionados con los objetivos.Establecer valores límites para la consecución de objetivos.Evaluar la capacidad de los procesos.Preparar informes de evaluación que comparan los datos actuales con los buscados.Planificar las evaluaciones.

Automatización:Recolección de datos de medidas.Preparación de informes de evaluación.


Servicios de Gestión del Proceso (vii)

• Documentación de procesosDa soporte para la documentación del proceso a todos los demás servicios.Operaciones básicas:

Identificar los requisitos de documentación.Diseñar y desarrollar los documentos.Producir y editar documentos.Distribuir los documentos.Mantener dichos documentos.

Automatización:Diseño, producción y edición de la documentación.Distribución y mantenimiento de la documentación.

49


Arquitectura PSEE (i)

• Personal-sensitive Software EngineeringEnvironment.

EIS centrados en procesos.

EIS basados en la Tecnología de Proceso Software:Soporte computerizado al proceso, es decir,

• Disponibilidad de un MP, y• Medios adecuados para definirlo, modificarlo, analizarlo y reificarlo.


EIS orientados a procesos: Arquitectura PSEE (i)

Producto, Modelo de

Procesos y Repositorio de

Procesos

Capa de Comunicación

Usuarios Usuarios

Espacio de Trabajo

Espacio de Trabajo

Motor de Procesos

Canales de importación y exportación

Arquitectura funcional de un PSEE según Fugettaet al (1999)

50


EIS orientados a procesos: Arquitectura PSEE (ii)

• Servicios básicos requeridos:Una gestión del diálogo para dar a los usuarios información sobre los procesos y permitirles llevar a cabo actividades.

Una gestión del proceso cuya tarea es ejecutar un MP particular y coordinar las actividades concurrentes de múltiples usuarios.

Una gestión del espacio de trabajo personal para cada usuario en cada uno de sus roles. Incluye todos los objetos software a los que tiene que acceder cada usuario con cada rol.

Un gestor del repositorio PSEE para almacenar de forma persistente los objetos software y sus correspondientes relaciones, y poder acceder a ellos eficientemente.


EIS orientados a procesos: Arquitectura PSEE (iii)

51


PSEE: Gestión del diálogo

• Encapsula la interfaz de usuario de un PSEE.• Incluye:

Visualización de procesos.Asistencia en el diseño de procesos.Computación de agendas.Facilidades de consulta.

• Habitualmente los usuarios de un PSEE pueden interactuar con diferentes roles:

desarrolladores de software,gestores de proyecto, eingenieros de procesos.

• Hay un patrón de interacción diferente para cada rol.


PSEE: Gestión del proceso

• Coordina las diferentes actividades de los múltiples actoresinvolucrados en un proyecto software.

• Computa el espacio de trabajo específico de cada usuario involucrado en un proyecto de desarrollo software, reflejando el estado actual del proyecto.

• Incluye:Conocimiento del proceso:

LMP,Instanciación del procesoGestión de restricciones

Transacciones:Estrategias predefinidasNegociación

52


PSEE: Gestión del espacio de trabajo

• Las dos motivaciones básicas que subyacen en la capa de gestión del espacio de trabajo son la abstracción y el aislamiento.

• Los espacios de trabajo permiten a los usuarios concentrarse en sus tareas específicas abstrayendo información irrelevante de otras partes del proyecto.

• Incluye:Creación/borrado de espacios de trabajoNotificaciónOperaciones de transferencia/uniónRelaciones entre espacios de trabajoGestión de versionesVistas


PSEE: Gestión del repositorio (i)

• Este servicio es responsable de mantener la consistencia y disponibilidad de la información que necesitan los otros componentes del PSEE.

• A esta información deben poder acceder al mismo tiempo diferentes usuarios del PSEE (concurrencia).

• Incluye:Modelo de objetos

Identidad de objetos

Evolución del esquema

Transacciones ACID

Disparadores

53


PSEE: Gestión del repositorio (ii)

• Un proyecto de desarrollo software habitualmente genera muchas formas diferentes de datos:

datos de productos: código fuente, datos de gestión de la configuración, documentación, ejecutables, juegos de pruebas, resultados de pruebas, simulaciones ....

datos del proceso: definición explícita de un MP, información delestado de la reificación de un proceso, datos para análisis y evolución del proceso, datos históricos, datos de gestión del proyecto, ....

datos organizacionales: información sobre propietarios de componentes del proyecto, roles y responsabilidades, datos de gestión de los recursos, ....


PSEE: Gestión del repositorio (iii)

• Características deseables:soporte multiusuario,eficiencia,persistencia e integridad,distribución,heterogeneidad,Evolución (de los datos y de los metadatos),versionado y gestión de configuración,gestión de transacciones flexible (ACID),facilidades de consulta “ad-hoc”.

54


PSEE: Gestión de la comunicación

• Los usuarios prefieren los PSEE con una arquitectura abierta que soporte diferentes niveles de integración. Esto es debido a que:

el soporte a proyectos tiene que manejar distintos tipos de proyectos

debe ser adaptable a las necesidades cambiantes de un proyecto

debe ser adaptable a los nuevos avances tecnológicos

debe ser posible añadir nuevas herramientas

• Una buena técnica para integrar las diferentes partes es usar un entorno de comunicación.

• Incluye:Adaptadores de protocolos

Notificaciones

Peticiones Síncronas/asíncranas


PSEE: Evolución (i)

• Primera Generación de EIS:Años 70Basados en el uso de herramientas que daban soporte a actividades aisladas como la programación o depuración pero no al PS como talNecesidad de integrar las herramientas aisladas

Los resultados obtenidos por una herramienta tenían que ser procesados por otra

Se seguía un ciclo parecido al modelo de CV cascada El resultado del análisis era entrada para la herramienta de especificación, la salida de la herramienta de especificación era una entrada para la herramienta de diseño, etc.

Problemas derivados de este enfoque:Modificación de resultados en fases posteriores que invalidaban los resultados de las fases anteriores. Ejemplo:

• Si un requisito aparecía después de liberar una versión del software, entonces había dos posibles alternativas: Modificar todos los documentos para reflejarlo o modificar sólo el código del software con los problemas de inconsistencia derivados.

Condiciones de consistencia que afectaban a más de un documento • Dos requisitos que deberían ser siempre probados en conjunto eran difíciles de expresar

y no podían ser tratadas a través del uso de estas herramientas aisladas centradas en actividades concretas.

55


PSEE: Evolución (ii)

• Segunda Generación de EIS:

Años 80

Se construyeron conjuntos integrados de herramientas cada vez más enfocadas en la noción de PS.

Centrados en mantener la consistencia entre documentos

• En ocasiones el progreso del desarrollo era sobrecargado por las numerosas actividades de mantenimiento de la consistencia que debían realizar los desarrolladores.

• Soporte a un único tipo de proceso software (basado en la noción de consistencia de documentos)

• Alto nivel de consistencia entre los documentos producidos.

• Guía para los desarrolladores de software a lo largo del proceso soportado.

• Conocimiento del estado del proceso software.

• Capacidad de automatización de partes del proceso.

DesventajasVentajas


PSEE: Evolución (iii)

• Primera Generación de PSEE:Objetivo: Proporcionar un entorno que de soporte a diferentes tipos de procesos software y fuese parametrizable a través de un modelo de proceso que determinase su comportamiento Requisito Clave: Modelado de procesos

A pesar de la obvia mejora de los PSEE sobre la segunda generación de EIS, estos también presentan desventajas:

El proceso de despliegue de un PSEE puede ser una tarea tediosa y extensa debido a la complejidad de para la definición de los PS y propensión a errores de los LMPS.

Dificultades de Integración de herramientas de soporte a actividades del PS debido a incompatibilidades

El propósito de los PSEE es guiar la ejecución de los procesos de acuerdo al modelo de proceso software agregado. Para ello, los mecanismos empleados en muchas ocasiones siguen la filosofía de los flujos de trabajo:

se indica a los desarrolladores de software lo que tienen que hacer, en qué orden y a través del uso de qué herramientas. Esta rigidez no es apropiada para algunas partes de los procesos software.

Consecuencias:Los PSEE no han tenido un impacto en el desarrollo de software industrial por ahora:

• ayudaron a establecer la noción de proceso en muchas compañías, pero los PSEE comerciales disponibles aún son escasos y no muy exitosos.

56


PSEE: Evolución (y iv)

• Situación Actual:Desde mediados de los 90 se sigue una tendencia hacia PSEE simples:

Soporte completo a PS considerado como demasiado restrictivo, costoso y torpe

Búsqueda de PSEE:mayor flexibilidad y menor intrusión en las tareas de los desarrolladores.Mayor atención al trabajo colaborativo.

• Los PS son “human-intensive”

Arquitectura distribuida vs Centralizada


PSEE: Ejemplos (i)

• SPADE:Universidad Politécnica de Milan

LMP: SLANG

Soporte multiusuario y paralelismo entre actividades (cada actividad concurrente se asocia con un motor de proceso)

Repositorio: SGBD OO

Entorno de Interacción con el usuario: Basado en DEC FUSE (FriendlyUnified Software Environment)

Estructura:Entorno de Interacción de UsuarioEntorno de Ejecución de Proceso: Intérpretes SLANG (motores de proceso) y repositorio.Filtro de comunicación del Entorno de Interacción de usuario y los Motores de Proceso.

57


PSEE: Ejemplos (ii)

• SPADE:Entorno de Interacción del Usuario

Herramienta 1 Herramienta 2 Herramienta n

...........

Servidor de Mensajes FUSE

Usuario 1

Herramienta 1 Herramienta 2 Herramienta n

...........

Servidor de Mensajes FUSE

Usuario n...........

Filtro

Interfaz de Comunicación

SPADE

PERoot PE1 PEn..................

Cliente O2 Cliente O2 Cliente O2

Servidor O2

Entorno de Ejecución del Proceso (Process Enactment Environment, PEE)

BBDD OO


PSEE: Ejemplos (iii)

• APEL:Laboratoire Logiciels, Systèmes, Réseaux”, en Francia

Objetivos, soporte a: Interoperabilidad y Evolución del Proceso

Lenguaje APEL

Arquitectura: Arquitectura basada en control

• las interacciones entre los PSEE se produce mediante llamadas a rutinas de proceso, en la que cada PSEE es una entidad autónoma que encapsula sólo la parte del proceso del que es responsable

Arquitectura basada en estados, • cada PSEE comparte una representación común del estado del proceso global

de forma que la interacción entre PSEE es implícita (no se realizan nunca llamadas directas entre PSEE).

• cada PSEE de la federación puede modificar su estado local o cambiar el estado común como resultado de variaciones en su estado local.

58


PSEE: Ejemplos (iv)

• APEL:Agente

CF/DFSD

ProductoActividad

Editores Gráficos APEL

Texto APEL

Compilador/ Intérprete

Soporte en Tiempo de Ejecución

Métodos Built-in

Métodos de Usuario

Herramientas de Usuario

Modelo Principal

Motor del Proceso

Estado Reificado del

Proceso

Servidor de Estado

Evolución

Control

Interfaz de Usuario

Instanciación

Gestión Errores

Servicios de "Enactment"


PSEE: Ejemplos (v)

• Serendipity:Basado en soporte al trabajo colaborativo (Computer-SupportedCooperative Work , CSCW)Lenguaje de Modelado: EVPL (Extended Visual Planning Language):

Permite tanto el modelado descriptivo de procesos indicando el trabajo a realizar, asícomo una extensión para modelar los eventos que intervienen en la ejecución del proceso.

59


PSEE: Ejemplos (vi)

• Serendipity:

gestion de proceso de software_parte2

Documents