Topselectos by Juan Carlos Olivares Rojas

T贸picos Selectos de Sistemas de Informaci贸n Juan Carlos Olivares Rojas MSN: juancarlosolivares@hotmail.com jcolivar@itmorelia.edu.mx http://antares.itmorelia.edu.mx/~jcolivar/ @jcolivares Social Network: Facebook, LinkedIn. Hi5

Herramientas de Calidad

• Algunos ejemplos de herramientas de calidad aplicadas al software más específicos son: • • • • •

Auditorías (revisión en la parte del proceso) Control estadísticos de errores de codificación. Encuestas Benchmarking Realización de pruebas de escritorio.

Formatos Tabulares

Hojas Tabulares

Pair Programming

• Realizar un programa que permita realizar operaciones aritméticas entre números complejos (6 operaciones). • Se deberá tener una clase complejo que tenga como métodos las propiedades solicitadas. • El programa será dado en modo texto o bien con JOptionPane (es indiferente la interface).

Pair Programming

• El programa se deberá codificar renglón por renglón, cuadro por cuadro en el formato de hoja de codificación. • Tener la seguridad de lo que se está haciendo está bien.

NĂşmeros Complejos

(a,b) â&#x20AC;&#x201C; (c,d) = (a-c)+(b-d)i

Pair Programming

• De la hoja de codificación dada, realizar la implementación necesaria. Tomar el tiempo de inicio de la codificación. • Correr el programa. Si presenta errores de “dedo” (faltó un punto y coma, está mal un carácter en mayúsculas y debe ser en minúsculas, etc.) corregirlos hasta que se pueda ejecutar. Tomar el tiempo de finalización de la codificación hasta que el programa compile.

Pair Programming

• CONTABILIZAR realizadas.

todas

las

modificaciones

• Correr el programa con las siguientes valores de caso de prueba: • Suma: (2+3i) + (3-5i) = (5-2i) • Resta: (2+3i) + (3-5i) = (-1+8i)

Pair Programming

• División: (2+3i) 0.2647+0.5588i)

(3-5i)

• Igualdad: (2+3i) <> (3-5i) y (2+3i) = (2+3i) • Multiplicación por escalar: 3 (2+3i) = 6+9i • Indicar si con estos casos de prueba son suficientes. Si no es suficiente, indicar que

Pair Programming

• Sino se ejecuta bien tomar tiempo de inicio de reparación y hasta que esté correcto, tomar tiempo final de reparación • Sumar tiempos de codificación y de reparación. • Contabilizar LOCs del programa final. Dividir las LOCs entre el tiempo. Por ejemplo: 100LOCs/4 horas = 25 LOC/hr

ELOC

• Líneas de código efectivas. El siguiente código puede llegar a tener 6 LOC pero solo 2 ELOC. public int suma (int a, int b) { int c; c = a+b; return c; }

ELOC

• Se simplifica en: public int suma(int a, int b) { return a +b; } • No cuentan: • Declaración de variables o atributos • Ni inicialización • Si: • Llamadas a métodos

ELOC

• Contabilizar las ELOC del programa. • Las líneas de código no cuentan • En la vida real este estimado se ignora dado que se asume que la codificación es de calidad. • Implementar los 4 casos de pruebas a través de un test con JUnit.

Personal Software Proccess

• Watts S. Humphrey es el inventor del PSP (Personal Software Process) y el TSP (Team Software Process). • PSP se utiliza cuando no existe un equipo de programadores (un solo desarrollador). • Es un proceso de mejora continua. Está diseñado para que se realicen varias pruebas antes de liberar el producto.

PSP

• ¿Por qué surgen las metodologías de desarrollo de software personal? • Por que cada Ingeniero es diferente. • Para lograr la mejora continua se necesita que cada Ingeniero debe tener procesos bien definidos y cuantificados. • Para lograr la calidad de software cada desarrollador debe de asumir las responsabilidad de hacer su trabajo con calidad.

PSP

• Metodologías del SEI CMU

CMM

TSP

Organización

Equipos

Personas PSP

Proceso del PSP

PSP

• Consta de varias tareas que el programador tiene que realizar repetidamente. • Para tener una buena calidad se requiere de tener métricas de calidad bastante elevadas, esto es, aproximadamente un error por cada mi líneas de código. • El cuaderno de ingeniería (bitácora) es el elemento clave de esta metodología.

PSP

• Las diferentes etapas del PSP son: • Proceso base: el programador conoce las necesidades del cliente para tener una idea clara de lo que programará. • Ambiente de mejora: en caso de tener un proyecto ya hecho esta es la etapa de depuración, se utiliza para mejorar el proyecto anterior.

PSP

• Estimación de tamaño de proyecto, pruebas: en caso de ser un proyecto nuevo se estima el tamaño que tendrá el software. Tomando en cuenta el tiempo que se le dedicará y las especificaciones del cliente. • Plantación de tareas y horario: ya teniendo el tamaño del software se puede hacer una estimación del tiempo que se tomará para hacer la programación, así como, las diferentes tareas.

PSP

• Se debe realizar un horario para tomar en cuenta cuanto tiempo debe tomar cada tarea y terminar a tiempo. • Control de calidad personal: por medio de pruebas se califica la eficiencia del sistema así como los errores que pueda llegar a tener, se tiene que confirmar que la calidad del software es la deseada.

PSP

• Proceso Cíclico: teniendo en cuenta la calidad con la que el programa será liberado se decide si el software se liberara o tiene que volver a entrar en el proceso como proceso base. • El problema mas grande que se presenta con el PSP es que para los programadores es difícil tratar de visualizar todas las tareas y etapas del desarrollo.

Actividades de PSP

• Desarrollar un plan para cada proyecto y/o componente. • • Registrar su tiempo de desarrollo. • Registrar sus defectos • Conservar sus datos en informes del proyecto

Actividades de PSP

â&#x20AC;˘ Utilizar sus datos para planear los proyectos y/o los componentes futuros. â&#x20AC;˘ â&#x20AC;˘ Analizar sus datos para desarrollar sus procesos con mas calidad para mejorar su funcionamiento.

Niveles de Madurez de PSP

PSP

• Hasta estos momentos se ha realizado de manera informal el nivel PSP0. • Se necesita hacer reingeniería al proceso actual para poder evolucionar a la parte 1. • Necesitamos estandarizar errores y estilos de codificación. • PSP1

hace

hincapié

planeación

Ejercicio PSP

• Se necesita realizar un software que en base a métricas de software pueda determinar rendimientos de programadores. Programador

LOC ELOC Otros Métodos

1 2 3 4 5

66 41 68 90 75

20 10 5 34 12

… … … … …

1 2 8 5 14

Ejercicio PSP

• Los programadores pueden ser diversos al igual que las métricas (de manera predeterminada hay tres). • Se deberá calcular quién es el mejor programador considerando la siguiente fórmula empírica (LOC/ELOC)(Methods*0.1). • El mejor programador es aquel que tiene la métrica más baja siempre y cuando sea >0

Ejercicio PSP

Ejercicio PSP

• En PSP la gestión del tiempo es de suma importancia. Es el único recurso que no se puede recuperar. • Implementación de la solución con todos los aspectos planeados. Tomar tiempos en base al formato dado del cuaderno de ingeniería. • Comprobar que tan efectiva fue la estimación que realizamos en la planeación.

Formato PSP

â&#x20AC;˘ CPI: precio de la actividad. Por ejemplo se pagan $100 por cada 25 LOC/hora. â&#x20AC;˘ %Nuevo reusado es el conjunto de nuevas APIs realizadas. Para ello considerar el siguiente formato.

Formato PSP

• LOC Base. Programa Original

• LOC Modificado. Líneas de Código Modificadas • • LOC Suprimido. Línea de códigos eliminadas

Formato PSP

• Nuevo y cambiante. Cuando se crean nuevas funcionalidades a un programa (note que no es ni modificado ni suprimido). • Reutilizado. Código que se toma de una biblioteca realizada por nosotros • LOC Total = Base - Suprimido + Agregado + Reutilizado

Manejo de Errores en PSP

PSP

• ¿Realmente se ahorra tiempo con PSP? • Si, dado que al haber menos errores se eficientiza todo el proceso. • Es necesario como para casi cualquier actividad el trabajo en Equipo que con las técnicas anteriormente descritas no nos sirve.

Equipos de Trabajo

• Es uno de los pasos más importantes del proceso de planeación. • Debe existir acuerdo en la selección de las herramientas y metodología para evitar ineficiencias que impidan al equipo de trabajo progresar y concebir el objetivo deseado.

Equipos de Trabajo

• Las características deseables de un equipo de trabajo son: • Debe de haber un líder. • Los miembros del equipo deben de ser creíbles y acreditados. • Los miembros del equipo deben entender y estar de acuerdo con las metas. • Debe existir múltiple cooperación y compañerismo.

Equipos de Trabajo

• Se debe tomar en cuenta:

• Determinar las tareas a llevar a cabo. • Estimar esfuerzos. • Estimar el numero de gente requerida. • Especificar los roles y responsabilidades de cada

Equipos de Trabajo

• Seleccionar el personal apropiado con las tareas y trabajos a llevar a cabo con el paso de la metodología. • Sesiones de entrenamiento y capacitación requerida al hacer comprender la metodología. • Tener un espacio de trabajo. • Seleccionar consultas externas

Equipos de Trabajo

• Algunos problemas de trabajar en equipo: • Liderazgo poco efectivo • Falta de compromiso/coperación • Falta de participación • Procrastinación

TSP

• En muchas ocasiones se necesita de otros programadores para terminar un proyecto, pero al estar más de uno no se puede utilizar el proceso de software personal, este problema se soluciona formando un equipo de trabajo y llevando a cabo el desarrollo por medio de TSP. • TSP, en conjunto con PSP, ayuda al Ingeniero de Software a mejorar la calidad tanto del proceso como del producto de software.

TSP

• Conjunto de procesos definidos y estructurados para formar y guiar equipos de ingenieros que desarrollan Software. • TSP = PSP + Desarrollo Organizacional + Teoría de Grupos/Equipos + Control Estadístico de Procesos + Admón. de Proyectos + Enfoque de Procesos.

TSP

• Equipos de 3 a 15 miembros (recomendable de 5 a 10) • Los miembros deben saber PSP. • Diseñado para ayudar a:

– Formación de equipos – Administración del Equipo – Formación de equipos Definición de objetivos – Asignación de Roles

TSP

• Diseñado para ayudar a:

– Definir/Ajustar el proceso del equipo – Planeación detallada y balanceada – Administración del Equipo Comunicación – Coordinación Control del proyecto – Análisis de Riesgos

• Los proyectos TSP son dirigidos por el equipo. Esto es, el equipo se administra así mismo.

TSP

• Cada miembro del equipo es responsable de: • Planea y le da seguimiento al progreso de su trabajo • Administra la calidad de su trabajo • Trabaja agresivamente objetivos del equipo.

para

lograr

los

TSP

• El equipo también debe mostrarle a los gerentes y al cliente que el equipo se auto-administra. • Reporta constantemente el avance y el status del proyecto • Anticipa, planea acciones concretas, y hace reportes sobre los riesgos que conlleva el proyecto

TSP

• Los planes detallados tanto del equipo como de cada miembro del equipo facilitan un seguimiento preciso del avance del proyecto. • Cada miembro del equipo es responsable de:

– Recolectar los datos (métricas) de sus actividades – Verificar que su plan de trabajo se vaya cumpliendo

TSP

• Cada miembro del equipo es responsable de:

– Mantener informado al equipo – Cada miembro del equipo también es responsable de la calidad del trabajo que produce

• El proceso consta de 4 etapas y de los procesos de lanzamiento (sesiones en equipo inicial), relanzamiento (sesiones intermedias) y análisis postmortem.

TSP

โ ข Composiciรณn de un launch

• • • • • • • • • •

TSP

Roles en TSP: Gerente de Interfase con el Usuario Gerente de Diseño Gerente de Implementación Gerente de Planeación Gerente de Procesos Gerente de Calidad Gerente de Soporte Técnico Gerente de Pruebas El líder del equipo se convierte en el mentor

Resultados de PSP/TSP

â&#x20AC;˘ Una empresa Nivel 5 de CMM logro:

CMM

• No todo es trabajar en equipo ni de manera personal. Se necesita definir una estructura organizacional que permita el desarrollo de software. • CMM (Modelo de Madurez de Capacidades) ayuda en esta parte al brindar un marco de trabajo de mejores prácticas a nivel organizacional. • La madurez de un proceso indica el grado de

CMM

â&#x20AC;˘ Niveles de Madurez. TambiĂŠn debe incluir el Nivel 0 sin madurez. Mejoramiento continuo de procesos Proceso predecible

Proceso estĂĄndar y consistente Proceso disciplinado

Administrado (4)

Definido (3)

Repetible (2)

Inicial (1)

Optimizando (5)

CMM

• Para medir el grado de madurez se necesita de métricas lo que en esta metodología son los KPA (Key Process Area). • Nivel 1 Inicial: Proceso hecho a la medida y dependiente de “heroes”. No existen KPA • Nivel 2 Repetible: Proceso intuitivo y dependiente de los individuos: Admon. Requerimientos, Planificación de Proyectos, Seguimiento y Control de Proyectos,

CMM

• Administración de la configuración, Admon. de subcontractos. • Nivel 3 Definido: Proceso definido e institucionalizado. KPA: Enfoque a procesos. Definición de Procesos. Programas de Entrenamiento. Administración Integrada del Software. Coordinación entre grupos. Revisiones de pares.

CMM

• Nivel 4 Administrado: proceso medido y administrado cualitativamente. KPA: Administración cuantitativa del proceso, admon. de la calidad del software. • Nivel 5 Optimizado: Proceso continuamente mejorado. KPA: Prevención de defectos. Admon. Del cambio tecnológico. Admon del proceso de cambio (mejoramiento continuo).

CMM

• Cada KPA tiene su objeto principal así como indicadores de cumplimiento sugerido. Ejemplo • Administración de Requerimientos. • Objetivo: Determinar el estado actividades de administración requerimientos.

de de

las los

• Indicadores:

CMM

– Estado de cada requerimiento aprobado. – Actividades de cambio de cada requerimiento especificado. – Cantidad de cambios acumulados para los requerimientos aprobados, incluyendo el total de cambios propuestos, abiertos, probados e incorporados a la baseline del proyecto.

• A nivel mundial se tienen: 75% empresas Nivel 1, 15% Nivel 2, 10% Nivel3, 5% Nivel 4 y <1% del total de empresas en Nivel 5.

CMM

• La madurez va enfocada a la organización, mientras que la capacidad va orientada hacia los procesos. • CMMI (CMM mejorado) trae muchas mejoras a CMM integrando otros frameworks (desarrollo, adquisición y servicios). Permitiendo que todas las empresas de TI se puedan integrar en el mismo modelo.

CMM

• Otras de las carácterísticas de CMMI es su flexibilidad al momento de evaluar procesos. Mientras en CMM si todas las categorías son nivel 5 y se tiene una nivel 3 el desempeño general es de 3. En CMMI se pueden tener multiniveles en diferentes partes del proceso (proceso escalonado). • Se puede medir CMMI a través de Standard CMMI Appraisal Method for Process Improvement (SCAMPI).

MOPROSOFT

• Modelo de PROcesos para la industria del SOFTware es la norma oficial mexicana (NMX-059/01-NYCE-2005) para el desarrollo de aplicaciones. • Es una versión ligera de CMMI adaptada a las necesidades de la Industria del Software en México. • Deriva del proyecto federal PROSOFT. Se publicó por vez primera en 2002

MOPROSOFT

â&#x20AC;˘ Se divide en tres procesos generales:

MOPROSOFT

• Se tiene una fácil y rápida integración hacia CMMI para el caso de certificaciones internacionales. • Actividad: propuesto.

seguir

con

plan

personal

SEMAT

• Software Engineering Method and Theory es una propuesta de los principales investigadores sobre Ingeniería del Software por tratar de mejorar las prácticas de está disciplina. • Entre las problemáticas encuentran:

resolver

• La Ing. Del Sw son más prácticas de modas que una verdadera disciplina de ingeniería.

SEMAT

• Falta de consenso en fundamentos básicos. • La gran variedad de métodos, técnicas y metodologías que realmente no se autodistinguen. • La falta de evaluación y experimental realmente creíble

validación

SEMAT

• La división de las prácticas industriales de la investigación académica. • Se propone la construcción de un kernel donde todos los métodos y técnicas estén basados en prácticas y patrones ya establecidos con anterioridad. • Se manejan 13 principios básicos: – Calidad – Simplicidad

SEMAT

– Teoría – Realismo y escabilidad – Justificación – Falsabilidad – Perspectiva hacia delante – Modularidad – Automejora – Abierto – Rectitud – Objetividad – Oportunidad

Tendencias Desarrollo Sw

• Cómputo en la nube • Web como plataforma • Cómputo paralelo

• Dispositivos conectados • Procesos ágiles

SPICE

• Software Process Improvment and Capability dEtermination, es una metodología para la evaluación de procesos de software definida en el estándar ISO/IEC 15504. • Maneja una escala de valores donde van más allá de ser si o no. No 0

Parcial 15 16

Adecuado 50 51

Completo 85 86 100 %

SPICE Proceso

Identifica cambios a

Es evaluado por Evaluaci贸n del Proceso

Gu铆a a Mejoramiento del Proceso

Identifica capacidad y riesgos del Gu铆a a

Motiva

Determinaci贸n de Capacidades

SPICE Parte 1

Parte 9

Conceptos y guía introductoria

Vocabulario

Parte 7

Parte 8

Parte 6

Guía para la mejora de procesos

Guía para la determinación de la madurez de los procesos de proveedores

Guía para la cualificación de los evaluadores

Parte 3

Parte 4

Realizando una evaluación

Guía para realizar evaluaciones

Parte 2

Parte 5

Un modelo de referencia para procesos y madurez de procesos

Un modelo de evaluación y directrices

SPICE Procesos Primarios CUS.1 Adquisición -Preparar adquisicón -selecc proveedor -confrolar proveedor -aceptación del cliente

Procesos de Soporte CUS.2 Suministro

SUP.1 Documentación

CUS.4 Operación

SUP.2 Gestión de la Configuración

Uso operacional Soporte al cliente

CUS.3 Obtención de Requerimientos ENG.1 Desarrollo -An.Reqs. y diseño SIS -Construir SW -Integrar y -An. Reqs. SW -Integrar SW probar SIS -Diseño SW -Probar SW

SUP.3 Aseguramiento de la Calidad SUP.4 Verificación SUP.5 Validación SUP.6 Revisión Conjunta SUP.7 Auditoría SUP.8 Resolución de Problemas

ENG.2 Mantenimiento SIS y SW Procesos Organizativos MAN.1 Gestión MAN.2 Gestión de proyecto

ORG.1 Alineamiento con la organización ORG.2 Mejora -establecer procesos - evaluarlos -mejorarlos

MAN.3 Gestión de la Calidad

ORG.3 Gestión de recursos humanos ORG.5 Infraestructura ORG.5 Medición

MAN.3 Gestión de Riesgos

ORG.6 Reuso

SPICE

โ ข Ejemplo de Evaluaciรณn Process

Process Atttributes Performed Managed Established Predictable 1.1

2.1

2.2

3.1

3.2

4.1

4.2

Level 5.1

5.2

Requirements elicitation

Customer Support

Software Design

3 3

Software construction Software testing

3 Fully Achieved Partially Achieved

Largely Achieved Not Achieved

Proceso de negocios

• Un proceso de negocios es un conjunto de pasos o actividades relacionadas en las que intervienen gente, información y otros recursos para crear valor. • • Los procesos de negocios se integran de pasos que se pueden identificar en el tiempo y el espacio • Tiene un principio y un fin

Procesos de Negocios

â&#x20AC;˘ Tienen entradas y salidas

â&#x20AC;˘ Tiene un grado de formalizaciĂłn pero no necesitan ser totalmente estructurados

Procesos de negocios

• Los procesos de negocios son la manera más común de mejorar el desempeño de los sistemas de trabajos ya que podemos cambiar el proceso de negocio cambiando, eliminando o agregando pasos al proceso o también cambiando los métodos de cómo se usan estos pasos

Proceso de Negocios

Procesos de Negocio

Modelado de Procesos

• El modelado de procesos es en si mismo el proceso de negocio. • Es la subdivisión del proceso de negocios en sus elementos básicos con el propósito de poderlos estudiar y mejorarlos

Modelado de Procesos

โ ข El modelado de procesos es esencial en el desarrollo de los sistemas de informaciรณn ya que nos ayuda a identificar el problema que el sistema de informaciรณn deberรก resolver y la manera en como deberรก resolverlo

Función vs. Proceso

• Función: identificada por un verbo. Es continua. – – – – –

Comercializar Fabricar Vender Expedir Comprar

• Proceso:

identificado por verbo+sustantivo. Tiene un inicio y un fin. No es continuo. – – – –

Tomar un pedido Ensamblar un pieza Facturar a un cliente Solicitar materiales

Procesos de Negocio

• Las aplicaciones empresariales están diseñadas para apoyar la coordinación e integración de procesos que abarcan toda la empresa. • Ejemplos de estas Aplicaciones empresariales se muestran a continuación: • Sistemas de administración de la cadena de suministro (SCM).

Procesos de Negocio

• Sistemas de administración de relaciones con clientes (CRM). • Sistemas de administración del conocimiento (Business Intelligence). • Sistemas Integrales que abarcan los procesos de la organización, llamados ERP (Enterprise Resource Plannig).

Procesos de Negocio

â&#x20AC;˘ Los Sistemas de AdministraciĂłn del Conocimiento recolectan todo el conocimiento y experiencia relevantes en la empresa y la hacen disponible donde y cuando sea necesaria para apoyar los procesos de la empresa y las decisiones administrativas. TambiĂŠn enlazan a la empresa a fuentes externas de conocimiento.

Procesos de Negocio

BPMN • Desarrollado por Business Initiative (BPMI).

Process

Management

• Es un estándar: BPMN Business Process Modeling Notation. • La especificación BPMN 1.0 fue publicada en Mayo del 2004.

Introducción • El objetivo principal de desarrollar BPMN es proveer una notación que sea fácilmente entendible por todos los usuarios de negocio. • Desde los analistas que crean los borradores iniciales de procesos hasta los desarrolladores técnicos que son responsables de implementar la tecnología que ejecutará dichos procesos. Y por supuesto, la gente de negocio que manejará y monitoreará estos procesos.

Introducción

• BPMN define un Diagrama de Procesos de Negocio (BPD), basado en la técnica de “flowcharting” (diagramado de flujos) que ajusta modelos gráficos de operación de procesos de negocio. • Un modelo de procesos de negocio es una red de objetos gráficos, correspondientes a actividades y controles de flujo que definen el orden de ejecución de éstas.

Elementos

Un BPD (diagrama de procesos de negocio) se estructura con un grupo de elementos gráficos. Las cuatro categorías básicas de elementos son:

•

Flow Objects (objetos de flujo) • Connecting Objects (objetos de conexión) • Swimlanes (Carriles) • Artifacts (artefáctos)

Elementos: Flow Objects

Un BPD tiene un peque帽o grupo de elementos centrales (tres), los cuales son los Flow Objects: -

Event (Evento)

Activity (Actividad)

- Gateway (Decisi贸n)

Flow Objects: Event •Un evento se representa por un circulo y es algo que “sucede” durante el curso de un proceso de negocio. •Los eventos afectan el flujo del proceso y usualmente tienen un causa (trigger - disparador) o un impacto (result – resultado). •Los eventos se representan con círculos con el centro abierto para permitir anotar diferentes disparadores o resultados.

Flow Objects: Event โ ข Hay tres tipos de eventos basado en cuรกndo ellos afectan el flujo: - Start (comienzo) - Intermediate (intermedio) - End (final)

Flow Objects: Activity • Una actividad (Activity) se representa por un rectángulo con sus bordes redondeados y es un término genérico para el trabajo que un organización realiza. • Un actividad puede ser atómica o no atómica (compuesta).

Flow Objects: Activity â&#x20AC;˘ Los tipos de actividades son: - Task (tareas) - Sub-process (subproceso)

Los subprocesos se distinguen por un pequeĂąo + al centro y abajo en la figura.

Flow Objects: Gateway • Un Gateway es representado por la figura de un diamante y se usa para controlar la divergencia de la secuencia de un flujo. • Determina las “tradicionales” decisiones, tanto de bifurcaciones, como uniones y acoplamientos de flujos. • Las anotaciones al interior indican el tipo de comportamiento de control.

Elementos: Connecting Objects • Los objetos de flujo se conectan entre ellos en un diagrama para crear el esqueleto básico de la estructura de un proceso de negocio. • Existen tres Connecting Objects que proveen esta función de conexión. - Sequence Flow - Message Flow - Association

Connecting Objects: Sequence Flow

Un Sequence Flow se representa por una línea sólida con el extremo sólido Es usada para mostrar el orden (secuencia) de la actividad dentro del proceso. Note que el término “control flow” generalmente no es usado en BPMN.

Connecting Objects: Message Flow

Un Message Flow se representa por una lĂnea segmentada con el extremo sin relleno. Es usada para mostrar el flujo de mensajes entre dos participantes de procesos separados (business entities o business roles). En BPMN, dos â&#x20AC;&#x153;Poolsâ&#x20AC;? en el diagrama representan a dos participantes.

Connecting Objects: Association

Una Association se representa por una lĂnea segmentada finamente con el extremo en punta. Se usa para asociar datos, textos u otros artefactos con flujos de objetos. Las asociaciones son usadas para mostrar las entradas y salidas de las actividades.

Ejemplo con formas bรกsicas

Ejemplo de Proceso de Negocio Simple

Ejemplo BPMN

Segmento de un Proceso con mรกs detalles

Elementos: Swimlanes Muchas tĂŠcnicas de modelados utilizan el concepto de swimlanes como mecanismo de organizaciĂłn de actividades en categorĂas visuales separadas para ilustrar las diferentes capacidades funcionales o responsabilidades. BPMN soporta swimlanes con dos constructores principales: - Pool - Lane

Swimlanes : Pool Un Pool representa un Participante en un Proceso.

Nombre

El Pool también actúa como contenedor gráfico para separar al grupo de actividades realizadas por un participante de otros Pools. Los Pools se usan generalmente en el contexto de situaciones B2B.

Swimlanes : Lane Un Lane es una partici贸n dentro de un pool y se extiende a lo largo de todo el pool, tanto vertical como horizontalmente.

Nombre

Los Lanes son usados para organizar y categorizar actividades.

Swimlanes : Pool & Lane Los Pools se usan cuando los diagramas involucran a dos entidades de negocios o participantes separados. Están físicamente separados en el diagrama. Las actividades dentro de Pools separados son consideradas auto contenidas en el proceso. De esta forma, la secuencia del flujo podría no atravesar el límite del Pool.

Swimlanes : Pool & Lane

Los flujos de mensajes son los mecanismos que muestran la comunicaci贸n entre dos participantes, conectando de esta manera a dos Pools (u objetos dentro de los Pools).

Swimlanes : Pool & Lane

Ejemplo de BPD con Pools

Swimlanes : Pool & Lane Los Lanes son más cercanos a los swimlanes que tradicionalmente se utilizan para modelar procesos de negocio. Los Lanes son usados para separar actividades asociadas con una función específica de la organización. La secuencia de flujos podría atravesar los límites del Lane dentro de un Pool, pero podrían no usarse flujos de mensajes entre Flow Objects en Lanes del mismo Pool.

Swimlanes : Pool & Lane

Segmento de un Proceso con Lanes

Elementos : Artifacts BPMN fue diseñado para permitir a los modeladores y herramientas de modelado algunas flexibilidades para extender la notación básica y proveer la habilidad poder modelar diferentes contextos apropiadamente. No está limitado el número de Artefactos que se pueden agregar a un diagrama para que éste represente más apropiadamente al contexto del negocio. La versión actual de BPMN predefine sólo tres tipos de artefactos.

Elementos : Artifacts Data object Nombre [Estado]

Group

Annotation

Anotaciones de Texto permiten al Modelador agregar informaci贸n adicional

Artifact : Data Object Los Data Objects son un mecanismo para mostrar como las actividades requieren o producen objetos. Se conectan a las actividades a travĂŠs de asociaciones.

Nombre [Estado]

Artifact : Group Un Group es representado por un rectángulo redondeado dibujado con línea segmentada El agrupamiento puede ser usado para propósitos de documentación o análisis, y no afecta la secuencia del flujo.

Artifact : Annotation Las Annotations son mecanismos para que un modelador pueda agregar informaci贸n textual adicional para el lector del diagrama BPMN.

Anotaciones de Texto permiten al Modelador agregar informaci贸n adicional

Artifact Los modeladores puede crear sus propios tipos de artefactos que agreguen mรกs detalle al proceso. Con bastante frecuencia se muestran entradas y salidas de actividades en los procesos. Sin embargo, la estructura bรกsica del procesos, es especificada con actividades, gateways, y flujos de secuencia.

Artifact

Segmento de un Proceso con Lanes. Sin artefactos.

Segmento de un Proceso con Lanes. Con artefactos.

Elementos centrales de los diagramas

Lista completa de elementos

Ejemplo

Elementos del Proceso

Usos Generales de BPMN

Dentro de la variedad de objetivos de modelado de procesos, hay dos tipos básicos que pueden ser creados con un BPD: • Collaborative (Public) B2B Processes • Internal (Private) Business Processes

Collaborative (Public) B2B Processes

Ejemplo proceso colaborativo

Ejemplo Proceso de Alto Nivel

Ejemplo de proceso de alto nivel el cual es b谩sicamente una serie de subprocesos con tres puntos de decisi贸n.

Ejemplo Proceso de Alto Nivel

Ej. Proceso Interno: Mรกs bajo Nivel

多Preguntas?