MODELADO DE PROCESOS Así como su nombre lo indica, tiene 2 aspectos que lo definen: el modelado y los procesos.Un modelo es una representación de una realidad compleja. Modelar es desarrollar una descripción lo más exacta posible de un sistema y de las actividades llevadas a cabo en él. Cuando un proceso es modelado, con ayuda de una representación gráfica (diagrama de proceso), pueden apreciarse con facilidad las interrelaciones existentes entre distintas actividades, analizar cada actividad, definir los puntos de contacto con otros procesos, así como identificar los subprocesos comprendidos. Al mismo tiempo, los problemas existentes pueden ponerse de manifiesto claramente dando la oportunidad al inicio de acciones de mejora.

EN EL MODELADO DE PROCESOS SE CONTEMPLAN CUATRO ASPECTOS: FUNCIONAL, DESEMPEÑO, ORGANIZACIONAL E INFORMATIVO. En el aspecto funcional se consideran las actividades del proceso que están siendo ejecutadas y los flujos de entidades (documentos) más relevantes. En el aspecto de comportamiento o desempeño se presta atención al tiempo en que se realizan las actividades, así como al modo en que se efectúan (condiciones, secuencia e iteraciones). La vista organizacional del proceso se enfoca en el lugar físico, dentro de la organización donde se realizan las actividades y en la persona que tiene la responsabilidad de efectuarlas. El aspecto informativo aborda el aporte de los documentos en la coordinación y comunicación entre las funciones.

DIAGRAMAR Es establecer una representación visual de los procesos y subprocesos, lo que permite obtener una información preliminar sobre la amplitud de los mismos, sus tiempos y los de sus actividades. Diagramar es una actividad íntimamente ligada al hecho de modelar un proceso, que es por sí mismo un componente esencial en la gestión de procesos de negocios.

LENGUAJE UNIFICADO DE MODELADO (UML) Es uno de los lenguajes de modelado de procesos más conocidos y utilizados en la actualidad. Está respaldado por el OMG, Object Management Group o Grupo de Gestión de Objetos). El UML es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. Además, ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables. Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.

BUSINESS PROCESS MODELING NOTATION (BPMN) En español, Notación para el Modelado de Procesos de Negocio, es una notación gráfica estandarizada que permite el modelado de procesos de negocio, en un formato de flujo de trabajo (workflow). BPMN fue inicialmente desarrollada por la organización Business Process Management Initiative (BPMI), y es actualmente mantenida por el OMG (Object Management Group), luego de la fusión de las dos organizaciones en el año 2005. Su versión actual es la 1.2 y hay una versión futura propuesta, la 2.0. El principal objetivo de BPMN es proveer una notación estándar que sea fácilmente legíble y entendible por parte de todos los involucrados e interesados del negocio (stakeholders). Entre estos interesados están los analistas de negocio (quienes definen y redefinen los procesos), los desarrolladores técnicos (responsables de implementar los procesos) y los gerentes y administradores del negocio (quienes monitorizan y gestionan los procesos). En síntesis BPMN tiene la finalidad de servir como lenguaje común para cerrar la brecha de comunicación que frecuentemente se presenta entre el diseño de los procesos de negocio y su implementación.

PROCESOS, MODELADO Y FORMAS DE ELICITACIÓN DE REQUISITOS Siendo que la captura, elicitación y especificación de requisitos, es una parte crucial en el proceso de desarrollo de software, ya que de esta etapa depende el logro de los objetivos finales previstos, se han ideado modelos y diversas metodologías de trabajo para estos fines. También existen herramientas software que apoyan las tareas relativas realizadas por el ingeniero en requisitos. El estándar IEEE 830-1998 brinda una normalización de las "Prácticas Recomendadas para la Especificación de Requisitos Software". A medida que se obtienen los requisitos, normalmente se los va analizando, el resultado de este análisis, con o sin el cliente, se plasma en un documento, conocido como ERS o Especificación de Requisitos Software, cuya estructura puede venir definida por varios estándares, tales como CMM-I.

Un primer paso para realizar el relevamiento de información es el conocimiento y definición acertada lo que se conoce como "Universo de Discurso" del problema, que se define y entiende por: Universo de Discurso (UdeD): es el contexto general en el cual el software deberá ser desarrollado y deberá operar. El UdeD incluye todas las fuentes de información y todas las personas relacionadas con el software. Esas personas son conocidas también como actores de ese universo. El UdeD es la realidad circunstanciada por el conjunto de objetivos definidos por quienes demandaron el software. A partir de la extracción y análisis de información en su ámbito se obtienen todas las especificaciones necesarias y tipos de requisitos para el futuro producto software.

El objetivo de la Ingeniería de Requisitos (IR) es sistematizar el proceso de definición de requisitos permitiendo elicitar, modelar y analizar el problema, generando un compromiso entre los Ingenieros de Requisitos y los clientes/usuarios, ya que ambos participan en la generación y definición de los requisitos del sistema. La IR aporta un conjunto de métodos, técnicas y herramientas que asisten a los ingenieros de requisitos (analistas) para obtener requerimientos lo más seguros, veraces, completos y oportunos posibles, permitiendo básicamente: Comprender el problema Facilitar la obtención de las necesidades del cliente/usuario Validar con el cliente/usuario Garantizar las especificaciones de requisitos

Si bien existen diversas formas, modelos y metodologías para elicitar, definir y documentar requerimientos, no se puede decir que alguna de ellas sea mejor o peor que la otra, suelen tener muchísimo en común, y todas cumplen el mismo objetivo. Sin embargo, lo que si se puede decir sin dudas es que es indispensable utilizar alguna de ellas para documentar las especificaciones del futuro producto software. Así por ejemplo, hay un grupo de investigación argentino que desde hace varios años ha propuesto y estudia el uso del LEL (Léxico Extendido del Lenguaje) y Escenarios como metodología, aquí se presenta una de las tantas referencias y bibliografía sobre ello. Otra forma, más ortodoxa, de capturar y documentar requisitos se puede obtener en detalle, por ejemplo, en el trabajo de la Universidad de Sevilla sobre "Metodología para el Análisis de Requisitos de Sistemas Software".

Una posible lista, general y ordenada, de tareas recomendadas para obtener la definición de lo que se debe realizar, los productos a obtener y las técnicas a emplear durante la actividad de elicitación de requisitos, en fase de Especificación de Requisitos Software es: Obtener información sobre el dominio del problema y el sistema actual (UdeD). Preparar y realizar las reuniones para elicitación/negociación. Identificar/revisar los objetivos del usuario. Identificar/revisar los objetivos del sistema. Identificar/revisar los requisitos de información. Identificar/revisar los requisitos funcionales. Identificar/revisar los requisitos no funcionales. Priorizar objetivos y requisitos. Algunos principios básicos a tener en cuenta: Presentar y entender cabalmente el dominio de la información del problema.

DEFINICIONES Y CARACTERÍSTICAS DE UN MODELO. Para la modelación de un proceso o un negocio Scheer define los siguientes aspectos como características clave : Una representación de algo real Construido a cierta escala y cierto nivel de detalle para mostrar puntos de vista Representativo de una foto fija en el tiempo Construido para un propósito Los Modelos son representaciones justas de cosas reales, modeladas para un propósito en particular y por tanto con puntos de vistas particulares. Algunas de las partes del negocio serán modeladas superficialmente mientras que otras necesitan ser exactamente definidas en aras de automatizarlas.

IMPORTANCIA DE MODELAR UN NEGOCIO. Varias compañías acostumbran a invertir mucho tiempo en hablar respecto a objetivos y estructuras organizativas y muy poco en reflexionar acerca de la modelación e identificación de procesos, como si esta etapa del desarrollo administrativo hubiese caído en desuso. Pero resulta muy difícil automatizar un negocio si no se entiende cómo funciona. Una compañía no puede tener interfases de negocio sofisticadas con otros negocios si no se entiende qué hace su propio negocio.

Aún más, no puede sobrevivir a los rápidos cambios en el mercado si no tiene la visión de qué necesita su negocio para desarrollarse. Por último, no puede tener un negocio electrónico exitoso si no tiene sus procesos, datos y sistemas bajo control . Algunos aciertos acerca de la importancia que representa modelar un modelo se relacionan a continuación: Introduce rigor y métodos Provee un record único y consistente Integra procesos, sistemas, organización, información y datos Permite ver y analizar las relaciones Provee múltiples puntos de vista Soporta validación y prueba Provee un medio ideal para la evaluación de escenarios Provee una plataforma para ingeniería rápida de procesos.

FASES DE LA MODELACIÓN. Típicamente, un proyecto de modelación incluye varias fases: La materia de modelación ¿Qué Modelar? (la empresa o áreas de la empresa) La perspectiva ¿Para qué propósito Modelar? (certificación, selección de Software o rediseño organizacional) Métodos y herramientas de modelación ¿Cómo Modelar? (métodos y herramientas) Los requerimientos esenciales de las técnicas de modelación están basados en la identificación de los propósitos y en los modeladores o usuarios involucrados en la modelación del proceso. A diferencia de los modelos de datos, aún no se ha establecido un estándar único para la modelación de procesos. Una muestra de los estándares de modelos de BPM y especificaciones, incluye: Business Process Execution Language (BPMEL); el Business Process Modeling Initiative (BPMI); el Workflow Management Coalition (WfMC); el World Wide Web Consortium (W3C) .

A continuación se listan requerimientos típicos para técnicas de modelación de procesos, centrándose sobre la modelación para la documentación y mejoramiento de procesos: Presentar claramente la secuencia de funciones incluyendo conexiones y divisiones. Permitir diferentes jerarquías de modelos además de enlazar modelos de procesos en el mismo nivel a través de interfases. Describir el modelo de proceso en modelos de datos, modelos de organización, diagramas de descomposición funcional y además que sea competente. Definir las técnicas de modelación en un formato suficientemente formal para que sea capaz de proveer al menos una solución básica provechosa para aplicaciones extendidas, tales como simulación, diseño de software o gestión de flujo de trabajo también llamados workflow. Finalmente, es vital que exista una herramienta que soporte estas técnicas de modelación. De hecho, las ventajas de las técnicas de modelación, así como aquellas herramientas de modelación, siempre estarán a la vez evaluadas.

MODELADO DE PROCESOS DE NEGOCIO EJECUTABLES   MODELADO DE PROCESOS DE NEGOCIO EJECUTABLES Objetivos:   Transmitir información de forma explicita y ajustada a la audiencia. Visualizar los procesos desde la perspectiva de una entidad controladora y ejecutora. Capturar detalle de la ejecución de los procesos. Documentar el rol y responsabilidad de cada actor dentro del proceso. Manejar escenarios de ejecución para rutas normales y excepcionales. Mantener un máximo de separación entre la definición del proceso de negocio y los participantes tecnológicos.

BIBLIOGRAFIA http://redie.uabc.mx/contenido/vol3no2/contenido-mireles.pdf http://otroblogmas.fullblog.com.ar/post/modelado-de-procesos/ http://es.wikipedia.org/wiki/Software#Procesos.2C_modelado_y_formas_de_elicitaci.C3.B3n_de_requisitos http://www.monografias.com/trabajos55/modelacion-de-procesos/modelacion-de-procesos2.shtml. http://www.slideshare.net/estebanf/el-arte-del-modelado-de-procesos-de-negocio-ejecutables-1951469