TESIS DE MAESTRÍA EN CIENCIAS

Transcripción

1 Departamento de Ciencias Computacionales TESIS DE MAESTRÍA EN CIENCIAS Metodología para la Elicitación de Requerimientos de Software Utilizando Transacciones del Proceso de Negocio para la Facturación Electrónica presentada por Lucia Morales Morales Ing. en Sistemas Computacionales por el Instituto Tecnológico Superior de Tantoyuca como requisito para la obtención del grado de: Maestría en Ciencias en Ciencias de la Computación Director de tesis: Dr. Máximo López Sánchez Jurado: Dr. René Santaolaya Salgado Presidente Dr. Moisés González García Secretario Dr. Juan Carlos Rojas Pérez Vocal Dr. Máximo López Sánchez Vocal Suplente Cuernavaca, Morelos, México. Febrero de 2012

2

3

4

5 Dedicatorias A Dios Por estar a mi lado y mostrarme que no hay camino difícil que no pueda recorrer. Gracias Dios porque tus promesas son dulces y especiales. Yo sé Dios que las metas que uno tiene en la vida no se pueden lograr si no hay esfuerzo y trabajo. No ha existido ni un momento en que no cuides de mí y de mi familia, además tú me muestras el camino a seguir y me das fortaleza para superar cualquier circunstancia por difícil que parezca. Gracias Dios, por todas las bendiciones que das a mi vida. "Mas el Señor me ha sido por refugio; Y mi Dios por roca de mi confianza" Proverbios 14:26 A mi Mamá Por su gran amor incondicional, por el apoyo, la comprensión y palabras de aliento que me has dado cada día de mi vida, porque a pesar de los momentos difíciles que hemos vivido siempre encontraste la forma de salir adelante y motivarnos a lograr cada una de nuestras metas. Gracias por tanto amor que nos has dado, Dios te bendiga siempre. Te Amo A mis Hermanos: Pedro, Cornelio, Josefa, Xochitl y Lucio Porque más que mis hermanos son mis mejores amigos, juntos hemos vivido momentos que difícilmente olvidaremos, les agradezco cada palabra de aliento y apoyo incondicional que me han brindado en este recorrido de mi vida y de lo porvenir. Gracias los quiero mucho. A Diana, Yamileth y Chrystian Por estar en mi vida y compartir momentos de felicidad, le doy gracias a Dios por regalarme mis dos hermosos sobrinitos que han llenado parte de mi vida con su alegría. Gracias los quiero mucho. A Mis Amigos: Christina, Adrian, Pepe y Pedro Cruz Por apoyarme en todo circunstancia y aceptarme con mis defectos, por compartir momentos inolvidables en esta etapa. Gracias Dios los Bendiga.

6 Agradecimientos A mis amigos Christina, Adrian y Pepe, por su apoyo constante y porque siempre están dispuestos a ayudar, Gracias. A mis amigos y compañeros Liz, Blanca y Ricardo por su compañía en esta etapa, Gracias. A mi asesor de tesis el Dr. Máximo, por haber compartido su conocimiento conmigo, por su guía en la realización de este trabajo y por haberme brindado su amistad, Gracias. Al Dr. René, Dr. Moisés y al Dr. Juan Carlos que han compartido conmigo su conocimiento, su paciencia, por su valiosa disposición en la revisión de este trabajo de tesis, por sus comentarios y sugerencias que contribuyeron a mejorarlo, Gracias. Al Dr. Andrés Rodríguez y al Ing. José Jiménez del Instituto de Investigaciones Eléctricas, por brindarme su tiempo, su apoyo y su conocimiento, su ayuda fue parte fundamental para la realización de este trabajo, Gracias. Gracias al CENIDET, por proporcionarme las oportunidades para mi desarrollo profesional y a todo el personal que en esta institución labora, por permitirme formar parte de esta gran familia. Gracias a CONACYT, por su apoyo económico a lo largo de la maestría. Y a todas aquellas personas que contribuyeron de alguna manera, a la realización de este trabajo, Gracias.

7 Resumen Hoy en día el desarrollo de proyectos de software tiene como base importante la especificación de requerimientos, donde el objetivo primordial es la definición detallada de las especificaciones que deban cubrir la funcionalidad que tendrá el sistema. Debido a que una de las fases que da inicio el ciclo de vida del desarrollo de software es la especificación de requerimientos, en donde el usuario transmite toda la información que debe contener su sistema y el que finalmente utilizará en su trabajo diario. Estudios como el The Chaos Report mencionan que la cantidad de proyectos que cumplen los objetivos planteados se encuentran sólo el 32%, por lo que más del 50% de proyectos no cumplen los objetivos o son cancelados debido a factores relacionados con los requerimientos de software. Lo anterior nos indica que a pesar de que existen metodologías para la elicitación de requerimientos, no se están obteniendo los requerimientos de forma adecuada, por lo que fue necesaria la realización de un estudio que implique el dominio de las metodologías de elicitación y que ayude al análisis e identificación de factores que inciden en los resultados que se están teniendo en los proyectos de desarrollo de software. La presente tesis aporta una propuesta para la disminución de factores como requerimientos ambiguos, requerimientos cambiantes por mencionar algunos que inciden en los proyectos; ya que los requerimientos son la base esencial para que las etapas posteriores de desarrollo tengan éxito. La metodología que se presenta incorpora transacciones de los procesos de negocios a fin de modelar las actividades que intervienen en el sistema que se necesita, en el cual se aplican una serie de acciones a través de guías y formatos que ayudan a detallar los requerimientos a manera de tener como producto final una documento de especificación de requerimientos de software. MERSUTPN (Metodología de Elicitación de Requerimientos de Software Utilizando Transacciones de los Procesos de Negocios) integra cuatro etapas, estas son: Obtención, Análisis, Especificación y Validación de Requerimientos, con el objetivo de obtener un documento de especificación de requerimientos de software bajo el estándar IEEE 830 a través del uso de esta metodología. Centro Nacional de Investigación y Desarrollo Tecnológico Página 1

8 Abstract Today's software development projects have the requirements specification as an important base, where the main objective is the detailed definition of the specifications to cover the functionality that the system has to do. Due to one of the stages that begin the life cycle of software development is the requirements specification, where the user transmits the information to be included in his "system" and ultimately use in their daily work. Studies such as "The Chaos Report" mentioned that the numbers of projects that meet the objectives are only 32%, so that over 50% of projects fail to meet the objectives or are canceled due to factors related with software requirements. This indicates that although there are methodologies for the elicitation of requirements, requirements are not being obtained properly, so it was necessary to do a study involving the domain of elicitation methodologies that will aid the analysis and identification of factors that affect the results obtained in software development projects. This thesis provides a proposal for the reduction of factors that affect the projects like ambiguous requirements, changing requirements, to name a few that affect the projects, since requirements are the essential base for the later stages of development to be successful. The methodology presented incorporates business processes transactions to model the activities involved in the system that is needed, in which a set of actions are implemented through guidelines and formats that help detail the requirements to have as a final product a software requirements specification document. MERSUTPN (Metodología de Elicitación de Requerimientos de Software Utilizando Transacciones de los Procesos de Negocios) has four stages, these are: Collection, Analysis, Specification and Validation of requirements, with the objective of obtain a software requirements specification document under the IEEE 830 standard through the use of this methodology. Centro Nacional de Investigación y Desarrollo Tecnológico Página 2

9 Contenido Resumen....1 Abstract. 2 Contenido Lista de Tablas....5 Lista de Figuras...7 Introducción.. 9 Capítulo 1 Generalidades Antecedentes Trabajos Relacionados Obtención de Requerimientos de Software ERP con modelos de Referencia [GAO10] Una propuesta Metodológica para Modelar Procesos de Negocios de Decisión como Técnica de Elicitación de Requisitos para Sistemas de Inteligencia de Negocios [QUEL09] Uso de Técnicas Etnográficas en el Desarrollo de una Herramienta Móvil para la Obtención de Requerimientos [SHAH09] Escribiendo y Leyendo la Documentación de Software: Como el Proceso puede Afectar a la Comprensión [REMO09] Planteamiento del Problema Objetivo Justificación y Beneficios Metodología de Solución Alcances y Limitaciones Conclusiones Capítulo Capítulo 2 Marco Conceptual Ingeniería de Requerimientos Etapas de la Ingeniería de Requerimientos Técnicas Clásicas de Elicitación de Requerimientos Técnicas Modernas de Elicitación de Requerimientos Procesos de Negocios Centro Nacional de Investigación y Desarrollo Tecnológico Página 3

10 2.3 Transacciones de negocios Patrones de Modelado de los Procesos de Negocios Análisis de Dominio Orientado Características Conclusiones Capítulo Capítulo 3 Desarrollo Análisis de Dominio Orientado a Características Análisis de Contexto Modelado del Dominio Especificación del Proceso de Negocio Proceso de Facturación Electrónica Transacciones de Negocios en el Proceso de Negocio para la Facturación Electrónica Interacción entre Transacciones de Negocios y Patrones de Modelado del Proceso de Negocio Definición de acciones de la metodología Desarrollo de la Metodología Etapas de la Metodología Etapa 1: Obtención de Requerimientos Etapa 2: Análisis Etapa 3: Especificación de Requerimientos de Software Etapa 4: Validación de Requerimientos Conclusiones Capítulo Capítulo 4 Pruebas Descripción General de las pruebas Enfoque de las Pruebas Convención de nombres Especificaciones del Plan de Pruebas Casos de Pruebas Aplicadas a un Escenario Real Metodología de la Tesis (Procedimiento) Etapa 1: Obtención de Requerimientos Etapa 2: Análisis de Requerimientos Etapa 3: Especificación de Requerimientos de Software Etapa 4: Validación de Requerimientos Centro Nacional de Investigación y Desarrollo Tecnológico Página 4

11 4.7 Metodología del Instituto de Investigación Conclusiones de las Pruebas Conclusiones Capítulo Capítulo 5 Conclusiones Conclusiones Generales Trabajos Futuros Referencias..117 Anexos Anexo A: Formalización del Proceso de Negocio para la Facturación Electrónica Anexo B: Descripción de Actividades de la Metodología Representada con BPMN Anexo C: Modelado de Proceso de Negocio con BizAgi Process Modeler Lista de Tablas Tabla Heurística Propuesta para Obtener un MPND [QUEL09] Tabla Comparativa de Trabajos Relacionados Tabla 2-1 Características de los Requerimientos [ARIAS05] Tabla 2-2 Etapas Ingeniería de Requerimientos Tabla 3-1 Descripción del Diagrama de Estructura Tabla 3-2 Descripción Diagrama de Contexto Tabla 3-3 Símbolos Utilizados en el Árbol de Características Tabla 3-4 Descripción del Árbol de Características Tabla 3-5 Definiciones y Abreviaturas Tabla 3-6 Descripción de Roles Tabla 3-7 Descripción del Proceso de Facturación Tabla 3-8 Descripción del Proceso: Facturación\Creación de Órdenes de Facturación Tabla 3-9 Descripción del Proceso: Facturación \Creación de Facturas Tabla 3-10 Descripción de Actividades: Facturación Electrónica Tabla 3-11 Descripción de la Simbología Utilizada en el Proceso de Facturación Tabla 3-12 Descripción de Acciones Obtenidas Tabla 3-13 Formato de Actividad Tabla 3-14 Guía del Formato de Actividad Tabla 3-15 Representación de Distribución en Paralelo [BizAgi11] Tabla 3-16 Formato De Actividades que se Realizan de Manera Concurrente o en Distribución en Paralelo Centro Nacional de Investigación y Desarrollo Tecnológico Página 5

12 Tabla 3-17 Guía del Formato de Actividades que se Realizan de Manera Concurrente o en Distribución en Paralelo Tabla 3-18 Formato de Actividad Sincronizada Tabla 3-19 Guía del Formato de Actividad Sincronizada Tabla 3-20 Formato de Selección Exclusiva Tabla 3-21 Guía del Formato de Selección Exclusiva Tabla 3-22 Formato de Objetivos Tabla 3-23 Guía del Formato de Objetivos Tabla 3-24 Formato de Transacción de Negocio Tabla 3-25 Guía del Formato de Transacción de Negocio Tabla 3-26 Formato de Roles Tabla 3-27 Guía del Formato Roles Tabla 3-28 Guía Básica para la representación del Proceso de Negocio con BPMN Tabla 3-29 Formato 1 de Actividad del PN Tabla 3-30 Formato 2 de Actividades del PN Tabla 3-31 Guía de los Formatos de Actividades de PN Tabla 3-32 Formato 1 de Actividad del Subproceso Tabla 3-33 Formato 2 de Actividades del Subproceso Tabla 3-34 Guía de los Formatos de Actividades de PN Tabla 3-35 Formato de Requerimientos Detectados con Problemas Tabla 3-36 Guía del Formato de Requerimientos Detectados con Problemas Tabla 3-37 Guía de Llenado del Documento de Especificación de Requerimientos de Software Tabla 3-38 Atributos de una SRS de calidad [DAV93] Tabla 4-1 Objetivo Tabla 4-2 Objetivo Tabla 4-3 Definiciones y Abreviaturas Tabla 4-4 Descripción de Rol Asistente Tabla 4-5 Descripción de Rol Jefe de Asistente Tabla 4-6 Descripción de Rol Departamento de Ingresos Tabla 4-7 Descripción de Rol Jefe del Departamento de Ingresos Tabla 4-8 Descripción de Rol Tesorero Tabla 4-9 Descripción Transacción de Negocio Facturación Electronica Tabla 4-10 Descripción de Actividades: Facturación Electrónica Tabla 4-11 Formato de la Actividad Seleccionar líneas del programa de pagos Tabla 4-12 Formato de la Actividad Crear Ordenes de Facturación Tabla 4-13 Formato de la Actividad Enviar Aprobación OF Tabla 4-14 Formato de la Actividad Revisar y Validar la OF Tabla 4-15 Formato de la Actividad Cancelar OF Tabla 4-16 Formato de la Actividad Solicitar Modificación Tabla 4-17 Formato de la Actividad Modificar OF Tabla 4-18 Formato de la Actividad Aprobar OF Tabla 4-19 Formato de la Actividad Enviar Documentación a Soporte a CXC Tabla 4-20 Formato de la Actividad Recibir Documentación de Soporte Centro Nacional de Investigación y Desarrollo Tecnológico Página 6

13 Tabla 4-21 Formato de la Actividad Validar Documentación de Soporte y OF Tabla 4-22 Formato de la Actividad Generar Factura y Completar Información Tabla 4-23 Formato de la Actividad Enviar Factura a Aprobación Tabla 4-24 Formato de la Actividad Recibe Notificación de Aprobación Pendiente Tabla 4-25 Formato de la Actividad Revisar y Validar Factura Tabla 4-26 Formato de la Actividad Cancelar Factura Tabla 4-27 Formato de la Actividad Solicitar Modificación Factura Tabla 4-28 Formato de la Actividad Modificar Factura Tabla 4-29 Formato de la Actividad Aprobar Factura Tabla 4-30 Formato de la Actividad Generar Registro Contable Tabla 4-31 Formato de la Actividad Generar Factura Electrónica Tabla 4-32 Formato de la Actividad Revisar Registro Contable Tabla 4-33 Formato de la Actividad Cancelar Registro Contable Tabla 4-34 Formato de la Actividad Corregir Información Tabla 4-35 Formato de la Actividad Cerrar Factura Tabla 4-36 Formato de Requerimientos Detectados con Problemas Tabla 4-37 Resultados de las Métricas del CP_ Tabla 4-38 Resultados de las Métricas del CP_ Tabla Anexo A-1 Descripción de Elementos Utilizados en la Formalización del PN Tabla Anexo A-2 Abreviaturas en la Formalización PN Tabla Anexo B-3 Descripción de Actividades de la Metodología Representada con BPMN Tabla Anexo B-4 Descripción del Subproceso Etapa de Elicitación de la Metodologia Tabla Anexo B-5 Descripción del Subproceso Etapa de Análisis de la Metodología Tabla Anexo B-6 Descripción del Subproceso Etapa de Especificación de Requerimientos de la Metodología Tabla Anexo B-7 Descripción del Subproceso Etapa de Validación de Requerimientos de la Metodología Lista de Figuras Figura 1-1 Marco de la Metodología [GAO10] Figura 1-2 Modelo de la Metodología [REMO09] Figura 2-1 Proceso de Negocios [BOCAN08] Figura 3-1 Diagrama de Actividades Realizadas del FODA Figura 3-2 Diagrama de Estructura Figura 3-3 Diagrama de Contexto Figura 3-4 Diagrama de Árbol de Características Figura 3-5 Proceso de Facturación Centro Nacional de Investigación y Desarrollo Tecnológico Página 7

14 Figura 3-6 Procesos Implícitos en el Proceso de Facturación Figura 3-7 Descripción de Actividades: Facturación Electrónica Figura 3-8 Representación de Secuencia de Actividades Figura 3-9 Representación de Sincronización Figura 3-10 Representación de Selección Exclusiva Figura 3-11 Etapas de la metodología de la tesis Figura 3-12 Diagrama Metodología de Elicitación Tesis Figura 3-13 Etapa 1: Obtención de Requerimientos Figura 3-14 Diagrama Etapa 1: Obtención de Requerimientos Figura 3-15 Diagrama Etapa 1: Elicitación/Proceso de Negocio Figura 3-16 Proceso de Ejemplo de Creación de Órdenes de Facturación Figura 3-17 Etapa 2: Análisis Figura 3-18 Diagrama Etapa 2: Análisis Figura 3-19 Etapa 3: Especificación de Requerimientos Figura 3-20 Diagrama Etapa 3: Especificación de Requerimientos Figura 3-21 Etapa 3: Validación de Requerimientos Figura 3-22 Diagrama Etapa 4: Validación Figura 4-1 MERSUTPN Figura 4-2 Descripción de Actividades: Facturación Electrónica Figura 4-4 Grafica de Factores Evaluados en los Casos de Prueba Figura Anexo C-1 Pantalla de Selección de la Herramienta BizAgi Figura Anexo C-2 Pantalla Ambiente Grafico BizAgi Figura Anexo C-3 Pantalla Nuevo Diagrama Figura Anexo C-4 Pantalla Evento de Inicio del Diagrama Figura Anexo C-5 Pantalla Continuación de Representación del Diagrama Figura Anexo C-6 Pantalla Cambio de Nombre a un Elemento del Diagrama Figura Anexo C-7 Pantalla Proceso de Negocio de Ejemplo Completado Figura Anexo C-8 Pantalla Guardar Proceso de Negocio Ejemplo Centro Nacional de Investigación y Desarrollo Tecnológico Página 8

15 Introducción Hoy en día es muy demandante contar con sistemas de software que ayuden a la automatización de procesos dentro de una organización. Los ciclos de vida del software han sido parte fundamental, de manera metodológica, para el desarrollo de sistemas de software, una de las fases que da inicio al desarrollo del sistema es la especificación de los requerimientos del software. La importancia que guarda esta fase es primordial, debido a que aquí es donde el usuario transmite toda la información que debe contener su sistema y el que finalmente utilizará en su trabajo diario. Estudios como el The Chaos Report [Standish09] mencionan la cantidad de proyectos que no llegaron a cumplir con los objetivos planteados, encontrando que el 44% de los proyectos son completados con menor alcance, y/o sobrecosto y/o fuera de término y el 24% de los proyectos son cancelados antes de ser terminados. Los principales factores que generan este tipo de problemas se deben a los requerimientos incompletos 13.1 %, falta de involucramiento del usuario 12.4 %, expectativas no realistas 9.9 % y requerimientos cambiantes 8.1 %. Lo anterior nos indica que a pesar de que existen metodologías para la elicitación de requerimientos, no se están obteniendo los requerimientos de forma adecuada, por lo que es necesaria la propuesta de nuevas metodologías para la reducción de estos factores. El presente trabajo se enfoca al desarrollo de software y se centra específicamente en la obtención de requerimientos de software, ya que es necesario proponer un conjunto de acciones que colaboren en la definición de los requerimientos de software del usuario y su forma de transmitir sus necesidades computacionales al experto desarrollador, con el propósito de lograr un documento con las especificaciones que definan el comportamiento del sistema. Centro Nacional de Investigación y Desarrollo Tecnológico Página 9

16 CAPÍTULO 1 1 Generalidades Dentro de este capítulo se presentan los antecedentes que fueron necesarios para el desarrollo de la presente tesis, los trabajos relacionados con el tema, también describe el planteamiento del problema, el objetivo, la justificación y los beneficios, además de los alcances y limitaciones de este trabajo. 1.1 Antecedentes En el programa de Maestría en Ciencias de la Computación, particularmente en la especialidad de Ingeniería de Software que se ofrece en el Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET), se han realizado algunos trabajos de tesis relacionados a la obtención de requerimientos las cuales preceden a esté trabajo de investigación. A continuación se presenta un breve resumen donde se exponen las aportaciones de cada trabajo. a) Ambiente de Modelado y Documentación de Sistemas de Software Utilizando Diagramas de Casos de Uso [CABR04] La idea central es brindarle al desarrollador de software un ambiente visual con el que pueda generar el modelo de requerimientos de un sistema de software, utilizando los diagramas de casos de uso propuestos por el estándar Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling Language). Centro Nacional de Investigación y Desarrollo Tecnológico Página 10

17 b) Definición e Implementación de un Perfil UML para la Adquisición de Requerimientos Funcionales Centrados en el Usuario [ALBO07] Esta tesis plantea la definición e implementación de un perfil del UML el cual se integre a un sistema interactivo, donde los propios clientes capturen sus requerimientos funcionales, generando diagramas de casos de uso, y se demuestre que es indispensable la intervención directa del cliente no solo en la definición sino también en la especificación de sus requerimientos. c) Método de trabajo arquitectónico en grupo [GONZ06] Esta tesis define un método AGD (Desarrollo Arquitectónico en Grupo) para desarrollar software, que utiliza un conjunto preestablecido de productos-del-trabajo (PS) y asocia a cada producto del trabajo un proceso dirigido por modelos (MDP). AGD obtiene cualquier producto del trabajo mediante la transformación de un modelo fuente a un modelo objetivo, o realizando en equipo un conjunto de sub-procesos. El software se desarrolla por grupos de personas colaborando, los productos se revisan en reuniones técnicas por colegas o expertos y el desempeño se monitorea en reuniones de seguimiento del equipo. El método AGD establece que el desarrollo se lleva a cabo en forma: grupal, incremental, cooperativa, adaptable y directa. Trabajo que fue desarrollado en el Centro de Investigaciones y Estudios Avanzados del Instituto Politécnico Nacional dentro del Departamento de Ingeniería Eléctrica en la Sección de Computación. 1.2 Trabajos Relacionados En este apartado se describe el análisis realizado a varios trabajos que existen y que presentan un tópico de la ingeniería de requerimientos, sin embargo, muy pocos son los trabajos que presentan características acerca de los procesos de negocios y sus transacciones. Al final de la descripción de estos trabajos se presenta una tabla comparativa Obtención de Requerimientos de Software ERP con modelos de Referencia [GAO10] Este trabajo propone una metodología integral para obtener los requerimientos de software a través del uso de modelos de referencia como dominio del conocimiento. Los sistemas de planeación de recursos empresariales (Enterprise resource planning, ERP por sus siglas en ingles) proveen de sistemas de software que ayudan a la automatización de procesos de una organización. Aunque son muchas las ventajas que los ERP proporcionan a las empresas, en ocasiones se presentan problemas al intentar implementar un sistema ERP en la empresa, debido a que se deben adaptar los procesos Centro Nacional de Investigación y Desarrollo Tecnológico Página 11

18 de negocios que se realizan en la empresa y/o incluso se puede dar el caso que se tenga que realizarle modificaciones a estos sistemas para poder implementarlos. La metodología consta de tres fases: elaboración de modelos de negocio, la detección de oportunidades y las relaciones de oportunidades. La metodología holística se basa en el modelado de negocios del modelo de referencia del método orientado al objetivo y apoyo (BROM por sus siglas en inglés) que plantea adquirir los requerimientos de software para la implementación del ERP [GAO10]. En la figura 1-1 se muestra el marco de la metodología, en donde la idea principal es que las necesidades de organización y funcionalidades del software se adapten el uno con el otro. Figura 1-1 Marco de la Metodología [GAO10] Una propuesta Metodológica para Modelar Procesos de Negocios de Decisión como Técnica de Elicitación de Requisitos para Sistemas de Inteligencia de Negocios [QUEL09] Este trabajo propone una herramienta basada en la Notación de Modelado de Procesos de Negocios (por sus siglas en inglés BPMN), la que modela Procesos de Negocios Decisionales, el cual considera la toma de decisiones como un proceso a ser modelado. La metodología está enfocada para el desarrollo de un sistema que no es transaccional, si no a un sistema de apoyo para la toma de decisiones; un sistema transaccional es aquel que está diseñado para capturar información y soportar procesos de negocios desde un punto de vista operacional [QUEL09]. Centro Nacional de Investigación y Desarrollo Tecnológico Página 12

19 El Modelo de Procesos de Negocio (MPN) se define como un conjunto de actividades conectadas, las cuales colectivamente representan un objetivo de negocio. Sin embargo, este tipo de modelos no contempla los procesos decisionales, es decir, no representan las decisiones que originan los procesos operacionales que modela. En cambio un Modelo de Procesos de Negocio Decisionales (MPND) proporciona una Herramienta conceptual que contiene un conjunto de elementos, conceptos y sus relaciones, las cuales permiten representar el proceso de toma de decisiones dentro de la organización y cómo éstas afectan las actividades operacionales de la misma [QUEL09]. El trabajo propone la heurística que se presenta en la tabla 1-1 para modelar procesos de negocio decisionales. Tabla Heurística Propuesta para Obtener un MPND [QUEL09] Etapa Descubrir actores Descubrir preguntas de decisión, investigación y actividades operacionales Descubrir recursos y establecer relaciones Pautas 1.1. Identificar los actores primarios Identificar los actores secundarios Identificar a los actores terciarios Identificar la pregunta de decisión principal Identificar las preguntas de decisión secundarias Determinar si las preguntas de decisión son Estructuradas, No Estructuradas o Semi-Estructuradas Identificar las preguntas de investigación. Estas preguntas surgen de las preguntas de decisión primaria y secundaria Determinar las actividades operacionales que son necesarias para dar respuesta a las preguntas de investigación Relacionar cada pregunta de decisión, investigación y actividades operacionales, con sus respectivos actores involucrados Para cada actividad operacional se deben identificar los datos, estructuras de datos e información, necesarias para llevarlas a cabo Relacionar actividades operacionales entre sí, junto a los recursos. Agregar los eventos de inicio y término, y todo lo que sea necesario para representar correctamente la secuencia del proceso. Esta pauta se divide en: Agregar actividades operacionales que surjan de la interacción entre actores Considerar los recursos que nacen como resultado de alguna actividad operacional y que son necesarias para desarrollar otra. Centro Nacional de Investigación y Desarrollo Tecnológico Página 13

20 1.2.3 Uso de Técnicas Etnográficas en el Desarrollo de una Herramienta Móvil para la Obtención de Requerimientos [SHAH09] Este trabajo presenta el desarrollo de una herramienta Web móvil para la elicitación de requerimientos utilizando como base la etnografía (Ethno-MRE por sus siglas en inglés), la que facilitará la recopilación de datos por medio de diversas formas del Asistente Digital Personal (PDA por sus siglas en inglés, Personal Digital Assistant). A través de notas escritas a mano el etnógrafo registra acciones del participante y sus propias interpretaciones. Los dispositivos móviles en los últimos años han ganado popularidad en todo el mundo, por los beneficios que este les proporciona, tal como evitar el inconveniente de llevar una laptop de un lugar a otro, gozando de beneficios como agenda, programas, etc.. Los dispositivos móviles presentan una gran versatilidad y adaptabilidad a las necesidades laborales y personales, a lo que provee una oportunidad de usar estos dispositivos en el campo de la ingeniería de requerimientos Escribiendo y Leyendo la Documentación de Software: Como el Proceso puede Afectar a la Comprensión [REMO09] Este trabajo presenta una metodología de análisis de modelos mentales para la documentación que se elabora para el proyecto, solucionando el problema de la falta de entendimiento que existe entre los miembros que integran un equipo de desarrollo en cuanto a la documentación del software. La metodología se basa en la teoría de los constructos personales, una teoría constructivista de la personalidad y la psicología desarrollada por George Kelly. La teoría dice, la gente puede interpretar cualquier evento de diversas maneras. Los procesos de una persona se canalizan por las formas en las cuales anticipa los eventos [CLON03]. Los constructos se utilizan para conocer el medio ambiente de una persona y proporciona sendas de acción anticipadas, con la finalidad de que el sujeto pueda interpretar y dar sentido a los acontecimientos que se le presentan. La Figura. 1-2 representa el modelo de la metodología. Centro Nacional de Investigación y Desarrollo Tecnológico Página 14

21 Figura 1-2 Modelo de la Metodología [REMO09] Los pasos del método se describen a continuación: 1.- Obtener un modelo mental personal 2.- Determinar el nivel de entendimiento implícito. 3.- Determinar el nivel de comprensión compartida explícita. 4.- Determinar el nivel de comprensión compartida. En la tabla 1-2 siguiente, se muestra un análisis comparativo de los trabajos que fueron citados y descritos anteriormente, en donde se observan características como: interacción cliente/experto, procesos de negocios, documento de requerimientos de software, centra al usuario, centrada al experto, producto intermedio. Centro Nacional de Investigación y Desarrollo Tecnológico Página 15

22 Tabla Comparativa de Trabajos Relacionados Trabajos Obtención de Requerimientos de Software ERP con Modelos de Referencia [GAO10]. Interacción Cliente/Experto Procesos de Negocios Obtención de un Documento de Requerimientos de software Centrada al usuario Centrada al experto Una Propuesta Metodológica para Modelar Procesos de Negocios de Decisión como Técnica de Elicitación de Requisitos para Sistemas de Inteligencia de Negocios [QUEL09]. Uso de Técnicas Etnográficas para el desarrollo de una herramienta Móvil para la Obtención de Requerimientos [SHAH09]. Escribiendo y Leyendo la Documentación de Software: Como el Proceso puede Afectar a la Comprensión [REMO09]. Tesis Centro Nacional de Investigación y Desarrollo Tecnológico Página 16

23 1.3 Planteamiento del Problema Actualmente en el desarrollo de sistemas de software es de gran importancia la recolección de requerimientos para determinar lo que el cliente necesita para su sistema, y en la medida que se haga de la mejor manera se tendrá éxito en el desarrollo del sistema final. Es necesario tener en cuenta que al realizar un producto de software éste debe cumplir con las funcionalidades para lo cual fue desarrollado. La fase de elicitación es importante, sin embargo en ocasiones es afectada por diferentes factores. El estudio The Chaos Report [Standish09] especifica la cantidad de proyectos que fueron finalizados con éxito y cuantos no llegaron a cumplir con los objetivos planteados y, además, presenta un análisis de los principales factores que generaron esos fracasos, que se mencionan a continuación. Requerimientos incompletos. Falta de involucramiento del usuario. Requerimientos cambiantes. Por lo que el problema consiste en que: los proyectos de software no cumplen con los objetivos planteados debido a que la etapa de especificación de requerimientos es afectada por la falta de comunicación y la baja colaboración por parte del cliente y el analista, lo que hace que los requerimientos sean incorrectos, ambiguos y no entendibles en muchos casos. 1.4 Objetivo Ayudar al usuario y al analista a que tengan una participación más directa y definir sus requerimientos de manera correcta, entendible y sin ambigüedades. Centro Nacional de Investigación y Desarrollo Tecnológico Página 17

24 1.5 Justificación y Beneficios El uso de ingeniería de requerimientos, hoy en día, es de gran importancia para definir lo que el sistema deberá realizar a través de la implementación de diferentes procesos y técnicas para la recolección de requerimientos. Dentro de la obtención de requerimientos para el desarrollo de software podemos observar que no se logra conseguir la información de las personas correctas, no habiendo una participación por parte del usuario, donde el usuario no logra expresar de forma clara y concisa lo que requiere para su sistema; esto hace que no se logren identificar los requerimientos de las transacciones que realiza el usuario para su negocio, por lo que al final del desarrollo o durante el mismo, uno puede darse cuenta que los procesos de negocio están incompletos, esto llega a causar que el sistema no se entregue a tiempo, haya que realizarle modificaciones y/o se eleve el costo de lo presupuestado. El estudio realizado por The Chaos Report define la cantidad de proyectos que fueron finalizados con éxito y cuantos no llegaron a cumplir con los objetivos planteados y, además, presenta un análisis de los principales factores que generaron esos fracasos en los proyectos, entre los que se tienen los siguientes porcentajes: a) 44% de los proyectos son completados con menor alcance, y/o sobrecosto y/o fuera de término. b) 24% de los proyectos son cancelados antes de ser terminados. Esto nos indica que sólo el 32% son acabados con base al alcance planteado, en el tiempo planificado y dentro del presupuesto asignado. Los principales factores que generan este tipo de problemas se deben a requerimientos incompletos 13.1 %, falta de involucramiento del usuario 12.4 %, expectativas no realistas 9.9 % y requerimientos cambiantes 8.1 [Standish09]. Con base a lo anterior, esta propuesta de tesis propone definir una metodología utilizando transacciones de procesos de negocios, con el fin de aportar una solución a la problemática antes mencionada. Beneficios: Proporcionar una serie de formatos y guías para detallar cada una de las actividades que se encuentran en el proceso de negocio. Validar que los requerimientos del documento de especificación sean correctos, entendibles y sin ambigüedades. Incorporar el conocimiento respecto a las transacciones de los procesos de negocios a las prácticas de especificación de requerimientos. Centro Nacional de Investigación y Desarrollo Tecnológico Página 18

25 1.6 Metodología de Solución Para el desarrollo de la esté trabajo de tesis se propuso la siguiente metodología de solución: 1. Realizar un análisis detallado de los diferentes métodos de elicitación de requerimientos. 2. Obtener y analizar un proceso de negocio real. 3. Determinar las transacciones que llevan a cabo en el proceso de negocio. 4. Caracterización de las transacciones del proceso de negocio. 5. Determinar las acciones que se llevan a cabo en las transacciones. 6. Desarrollo de la metodología considerando como elemento principal las transacciones. 1.7 Alcances y Limitaciones Alcances Se estudiará solo un proceso de negocio real. Se determinarán y caracterizarán las transacciones que se llevan a cabo en el proceso de negocio. Se definirán acciones para cada una de las transacciones identificadas, que ayuden al usuario a transmitir de forma clara los requerimientos. Se desarrollará y documentará la metodología para la elicitación de requerimientos. Se implementará la metodología para proporcionar al usuario una serie de acciones que permita expresar sus requerimientos de forma clara y consistente. El documento de especificación de requerimientos solo describirá los requerimientos funcionales Limitaciones.No se considerarán requerimientos no funcionales y de interfaz. Se delimitará al estudio de un solo proceso de negocio. Centro Nacional de Investigación y Desarrollo Tecnológico Página 19

26 1.8 Conclusiones Capítulo 1 Dentro de este capítulo se presentaron las generalidades que muestran la información que fue necesaria de manera preliminar para el desarrollo este trabajo de tesis, la metodología cumple con objetivo y beneficios establecidos. En el siguiente capítulo se describen los conceptos que son necesarios para comprender el trabajo realizado. Centro Nacional de Investigación y Desarrollo Tecnológico Página 20

27 CAPÍTULO 2 2 Marco Conceptual Dentro de este capítulo se describen los conceptos necesarios para la comprensión y desarrollo del trabajo de tesis, considerando a la ingeniería de requerimientos, transacciones y procesos de negocios, el análisis de dominio orientado a características (FODA), entre otros. 2.1 Ingeniería de Requerimientos La ingeniería de software comprende la aplicación de principios científicos para realizar la transformación ordenada de un problema en una solución elaborada de software, y el mantenimiento subsecuente de ese software hasta el final de su vida útil. La Ingeniería de software es más que programar. El proceso de ingeniería de software comienza generalmente mucho antes que la escritura de líneas de código y continúa por mucho más tiempo después de la finalización de la versión inicial del programa [Davis93] La experiencia en la construcción de grandes sistemas mostró que un enfoque informal para el desarrollo del software no era viable. Los grandes proyectos frecuentemente tenían años de retraso, costaban mucho más de lo presupuestado, eran irrealizables, difíciles de mantener y no cubrían la funcionalidad requerida. Nuevas técnicas y métodos eran necesarios para controlar la complejidad inherente [SOMM02]. Se integraron modelos de ciclo de vida al desarrollo de software compuesto por una serie de etapas que comprenden todas las actividades, desde que surge la idea de crear un nuevo producto de software, hasta que el producto deja definitivamente de ser utilizado por el último de sus usuarios. Existen diferentes modelos de ciclo de vida del desarrollo de software y la elección de alguno depende del software a realizar, las etapas que incluyen los modelos en general son: análisis, diseño, codificación, pruebas e implementación [PRESS02]. Centro Nacional de Investigación y Desarrollo Tecnológico Página 21

28 En el camino de esa serie de fases o etapas, la fase inicial comprende a la ingeniería de requerimientos. La importancia que guarda esta fase es primordial, debido a que aquí es donde el usuario transmite toda la información que debe contener su sistema y el que finalmente utilizará en su trabajo diario. La ingeniería de requerimientos (IR) tiene que ver con aquellas actividades en pos de entender exactamente las necesidades de los usuarios de un sistema de software y traducir tales necesidades a un conjunto de sentencias precisas, no ambiguas, las cuales serán usadas para el desarrollo del sistema [Loucopoulos95]. La ingeniería de requerimientos pretende cubrir un papel primordial en el proceso de producción de software ya que enfoca un área fundamental: la definición de lo que se desea producir. Su principal tarea consiste en la generación de especificaciones correctas que describan con claridad, sin ambigüedades, en forma consistente y compacta, el comportamiento del sistema; de esta manera, se pretenden minimizar los problemas relacionados al desarrollo de sistemas [RWI03]. Definición de Requerimiento El término requerimiento es una condición o necesidad del usuario para resolver un problema o alcanzar un objetivo o la capacidad que debe exhibir o poseer un sistema para satisfacer un contrato, estándar, especificación, u otra documentación formalmente impuesta [STD ]. Requerimientos Funcionales y No Funcionales Aunque como se describe en el capítulo 1, dentro de los alcances que tendrá el presente trabajo es que sólo estará enfocado a obtener un documento de especificación de requerimientos que describirá los requerimientos funcionales, pero es necesario mencionar que los requerimientos pueden dividirse en: Funcionales, los que definen la naturaleza de las funciones que tendrá el sistema, desde la interacción que tendrá en su entorno y cuáles van a ser sus estados de funcionamiento, además de la capacidad de acción para procesar las entradas para generar las salidas necesarias. No funcionales, los que tienen que ver con características que de una u otra forma puedan limitar al sistema, por ejemplo, el rendimiento, interfaces de usuario, fiabilidad, mantenimiento, seguridad, portabilidad, estándares, etc. [STD830] Centro Nacional de Investigación y Desarrollo Tecnológico Página 22

29 Tabla 2-1 Características de los Requerimientos [ARIAS05] Característica Necesario Conciso Completo Consistente No ambiguo Verificable Descripción Lo que pida un requerimiento debe serlo para el producto. Debe ser fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro. Los requerimientos deben contener en sí mismos toda la información necesaria y no remitir a otras fuentes externas que los expliquen con más detalle. Un requerimiento no debe ser contradictorio con otro requerimiento. Asimismo, el lenguaje empleado entre los distintos requerimientos debe ser consistente. El texto debe ser claro, preciso y tener una única interpretación. El lenguaje usado en su definición no debe causar confusiones al lector. Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas Etapas de la Ingeniería de Requerimientos La metodología desarrollada en el presente trabajo considera las etapas de la ingeniería de requerimientos que fueron adaptabas de acuerdo al objetivo que se plantea, por lo que es necesario describir de manera breve cada una de ellas. El proceso de ingeniería de requerimientos puede ser descrito en cuatro etapas, las que se describen a continuación [PRESS02]: Tabla 2-2 Etapas Ingeniería de Requerimientos Etapa Obtención Extracción Análisis o Descripción Este proceso trata de identificar la procedencia de los requerimientos y la manera en la que el ingeniero de software los puede recolectar. La elicitación es la habilidad de trabajar en colaboración con los clientes y/o representantes de ellos para descubrir las necesidades actuales del producto y acordar la visión y las metas del proyecto propuesto [ARIAS05]. Sobre la base de la extracción realizada previamente, comienza esta fase en la cual se enfoca en descubrir problemas con los requerimientos del sistema identificados hasta el momento. Centro Nacional de Investigación y Desarrollo Tecnológico Página 23

30 Especificación Validación En esta fase se documentan los requerimientos acordados con el cliente, considerando un nivel apropiado de detalle. La validación es la etapa final de la IR. Su objetivo es ratificar los requerimientos, es decir, verificar todos los requerimientos que aparecen en el documento especificado para asegurarse que representan una descripción, por lo menos aceptable, del sistema que se debe implementar. Esto implica verificar que los requerimientos sean consistentes y que estén completos. Algunos autores identifican una serie de problemas que nos ayudan a comprender por qué la obtención de requisitos es costosa [PRESS02]. Problemas de alcance: El límite del sistema está mal definido o los detalles técnicos innecesarios, que han sido aportados por los clientes/usuarios, pueden confundir más que clarificar los objetivos del sistema. Problemas de comprensión: Los clientes/usuarios no están completamente seguros de lo que necesitan, tienen una pobre compresión de las capacidades y limitaciones de su entorno de computación, no existe un total entendimiento del dominio del problema, existen dificultades para comunicar las necesidades al ingeniero del sistema, la omisión de información por considerar que es «obvia», especificación de requisitos que están en conflicto con las necesidades de otros clientes/usuarios, o especificar requisitos ambiguos o poco estables. Problemas de volatilidad: Los requisitos cambian con el tiempo. A pesar que existen diferentes técnicas de elicitación de requerimientos, el porcentaje de los proyectos que se terminan exitosamente, de acuerdo al estudio The Chaos Report, está por debajo del 50% del total de proyectos. Lo anterior nos indica que hay oportunidad de hacer trabajo dirigido a la elicitación de requerimientos de software, tratando de ayudar a reducir los factores que tanto afectan el éxito del producto final de un proyecto de software. Algunas técnicas que se utilizan comúnmente para la obtención de requerimientos se clasifican en técnicas clásicas y modernas según el trabajo de [GANESH08] Técnicas Clásicas de Elicitación de Requerimientos Entrevistas Las entrevistas son las de uso común y es un método muy popular para la obtención de requerimientos. En este método el analista y los ingenieros del proceso de ingeniería de requerimientos realizan un intercambio verbal de información, entre las diferentes partes interesadas para comprender los requisitos del sistema y el objetivo que tienen que cumplir en el sistema. Se definen cuatro fases para la realización de entrevistas: Centro Nacional de Investigación y Desarrollo Tecnológico Página 24

31 identificación de los entrevistados, preparación de la entrevista, realización de la entrevista y documentación de los resultados [GANESH08], [QADEEM10]. Cuestionarios Los cuestionarios son uno de los métodos de recopilación de requisitos que llegan a un gran número de personas, no sólo en menos tiempo sino también en un menor costo [GANESH08]. Los cuestionarios se utilizan como una herramienta simple que puede consistir en preguntas abiertas y / o cerradas. El derecho de obtener resultados y la respuesta, los cuestionarios deben ser claros, definidos y concisos con respecto al dominio del sistema a desarrollar. Las preguntas deben centrarse en el problema [QADEEM10]. Análisis Social El análisis social es también conocido como observación. La observación es el método de colección de las necesidades por observar a las personas en su ambiente laboral. Este método se utiliza generalmente para encontrar las necesidades adicionales de usuario; esto se hace cuando el usuario no logra explicar los requisitos previstos en el nuevo producto y los problemas con los productos existentes [GANESH08]. Este método es muy útil cuando se busca estudiar las actividades y procesos que se están llevando a cabo en una organización en el momento. La observación permite a los investigadores observar lo que los usuarios hacen actualmente en un determinado contexto [CAMA05]. Este análisis social se divide en cuatro tipos que se describen a continuación [GANESH08]. 1. Observación Pasiva: este análisis social se lleva a cabo sin la participación directa del observador en la sociedad. La observación se lleva a cabo mediante el registro con videos, cámaras de vídeo y cámaras de vigilancia en el área laboral de los interesados. La documentación de los problemas y necesidades son obtenidos a partir de los datos registrados. 2. Observación Activa: se lleva a cabo con la participación directa del observador. A las personas se les proporcionan un prototipo del producto nuevo o producto existente para realizar las operaciones sobre el producto. El observador proporciona los conocimientos del dominio al usuario que va a trabajar con el producto y registra las necesidades de las personas mediante la observación de su trabajo con el producto. 3. Observaciones explicativas: en este tipo de observación, los usuarios hablan en voz alta explicando lo que están haciendo mientras que utilizan el producto. El observador toma notas con la explicación dada por el usuario. Centro Nacional de Investigación y Desarrollo Tecnológico Página 25

32 4. Etnografía: en este método el observador se encuentra completamente inmerso en la sociedad. La etnografía ayuda a los analistas a descubrir los requerimientos implícitos en un ambiente organizacional y social, al observar directamente las partes interesadas, para así comprender mejor los requisitos del sistema [SHAH09] Técnicas Modernas de Elicitación de Requerimientos Prototipo El prototipo es la representación o visualización de las partes real del sistema. El prototipo está diseñado en las primeras etapas de la ejecución del proyecto. Proporciona la idea general de las funciones del sistema actual y el flujo de trabajo. Los prototipos se utilizan para recopilar los requisitos de los usuarios mediante la presentación de las funciones en una interfaz gráfica de usuario basado en el sistema [GANESH08]. Un prototipo representa el producto real, tanto en sentido funcional como gráfico. Proporciona la flexibilidad para los usuarios y las partes interesadas a trabajar con la versión inicial del producto para entender el sistema y pensar en las necesidades adicionales que el usuario haya olvidado mencionar. Los prototipos es uno de los métodos más caros. Reuso de Requerimientos En el ámbito de la ingeniería de software la reutilización de los requerimientos del sistema actual es el método común de obtención de requerimientos. Con los actuales conocimientos para desarrollar el nuevo producto, se tienen muchas ventajas que incluyen bajo costo y menos tiempo. Aunque cada producto tiene su propio tipo de partes interesadas y usuarios, todavía hay varias situaciones que la reutilización de los requerimientos lleva a cabo [GANESH08]. Hoy en día en las industrias de software más de la mitad de los requisitos para los requerimientos de un nuevo proyecto se adquieren de los proyectos existentes. Aunque existe la necesidad de comprobar los requisitos antes de que sean utilizados en el producto propuesto [GANESH08]. "El éxito comienza con la reutilización de haber una cultura organizacional que conscientemente fomente la reutilización en lugar de reinvención" [ROBERTSON06]. Escenarios Los escenarios son ejemplos de las sesiones de interacción y estos consisten en descripciones de las acciones secuenciales. Los escenarios son útiles porque a los usuarios finales y otras partes interesadas del sistema les resulta más fácil relacionarse con ejemplos de la vida real, en lugar de descripciones abstractas de las funciones. Los escenarios deben incluir al menos los siguientes tipos de descripciones [PHKTT03]: Centro Nacional de Investigación y Desarrollo Tecnológico Página 26

33 El Estado al entrar en el escenario y el estado después de completar el escenario. El flujo normal de los acontecimientos y las excepciones al flujo normal de los acontecimientos. Información acerca de las cosas al mismo tiempo en curso. Lluvia de Ideas Lluvia de ideas (en inglés Brainstorming) es un proceso donde los participantes de diferentes grupos de interesados participan en un debate informal para generar rápidamente tantas ideas como sea posible, sin centrarse en ninguno en particular. Tanto la crítica severa no está permitido en este tipo de técnica, ya que debido a esto la ideas se pueden generar. Las ideas son libremente explicadas y cada uno tiene que interpretarlo en un ambiente muy agradable con un debate informal [QADEEM10]. Desarrollo de Conjunto de Aplicaciones (JAD por sus siglas en inglés) La técnica denominada JAD es un enfoque de análisis de negocios combinado que resuelve un problema en el que un gran número de partes interesadas están involucrados [QADEEM10]. Es una técnica organizada y estructurada para la obtención de requerimientos. Esto se lleva a cabo de la misma manera como las de brainstorming, salvo que las partes interesadas y los usuarios también pueden participar y discutir sobre el diseño del sistema propuesto. Los participantes en estas sesiones no exceden de 20 a 30. Los ingenieros de requisitos al iniciar la sesión proporcionan una visión general del sistema. El debate con las partes interesadas y los usuarios continúa hasta que al final se reúnen los requisitos. Esto conduce a un mejor descubrimiento de las necesidades en el primer intento y que reduce el tiempo empleado en la fase de requisitos [GANESH08]. El éxito de la JAD depende: del líder de la sesión JAD, de los desarrolladores, usuarios finales y los interesados del producto así como del grupo de participación. Casos de Uso Los casos de uso son una de las técnicas de definición de requerimientos más ampliamente aceptadas, quizá por el respaldo que hoy en día tiene el Lenguaje Unificado de Modelado (UML por sus siglas en inglés). Los Casos de Uso describen bajo la forma de acciones y reacciones el comportamiento de un sistema desde el punto de vista del usuario, permiten definir los límites del sistema y las relaciones entre el sistema y el entorno [ESC02]. Los Casos de Uso son descripciones de la funcionalidad del sistema independientes de la implementación, dividen el conjunto de necesidades atendiendo a la categoría de usuarios que participan en el mismo, están basados en el lenguaje natural. Glosario y Ontologías La diversidad de personas que forman parte de un proyecto de software hace que sea necesario establecer un marco de terminología común. Esta necesidad se vuelve sumamente necesaria en los sistemas de información Web puesto que el equipo de desarrollo en ellas suele ser más interdisciplinario [ESC02]. Centro Nacional de Investigación y Desarrollo Tecnológico Página 27

34 Plantillas o Patrones Esta técnica tiene por objetivo describir los requerimientos mediante el lenguaje natural pero de forma estructurada. Una plantilla es una tabla con una serie de campos y una estructura predefinida que el equipo de desarrollo completa usando para ello el lenguaje del usuario. Las plantillas eliminan parte de la ambigüedad del lenguaje natural al estructurar la información; cuanto más estructurada sea ésta menos ambigüedad ofrece. Sin embargo, si el nivel de detalle elegido es demasiado profundo, el trabajo de rellenar las plantillas y mantenerlas puede absorber mucho tiempo [ESC02]. Lenguajes Formales Otro grupo de técnicas que merece la pena resaltar como extremo opuesto al lenguaje natural, es la utilización de lenguajes formales para describir los requerimientos de un sistema. Las especificaciones algebraicas como ejemplo de técnicas de descripción formal han sido aplicadas en el mundo de la ingeniería de requerimientos desde hace años [PEÑ98]. Sin embargo, resultan complejas en su utilización y comprensión para el cliente. El mayor inconveniente es que no favorecen la comunicación entre cliente y analista. Por el contrario, es la representación menos ambigua de los requerimientos y la que más se presta a técnicas de verificación automatizadas [ESC02]. Una vez que se han descrito algunas de las técnicas para la elicitación de requerimientos, para el caso de la metodología que plantea esté trabajo se hará uso de la técnica de entrevista para el caso de las primeras dos etapas de que contempla la metodología. 2.2 Procesos de Negocios Actualmente son pocas las técnicas de elicitación que consideran como base los procesos de negocios dentro de la elicitación de requerimientos de software, los procesos de negocios son parte fundamental para conocer el proceso operacional de la organización. Por tal razón es necesario tener un panorama general acerca de estos, debido a que los procesos de negocios se consideran como base de desarrollo de la metodología de la tesis, además que también forma parte de la primera etapa que contempla la metodología desarrollada. Los procesos no son nada nuevo, las empresas han tenido siempre procesos. El problema es que no han podido describirlos tan fácilmente como a la Organización. Los departamentos tienen nombres como "Ventas" y "Sistemas"; y una persona responsable asociada a cada puesto. Los procesos son usualmente invisibles y no son descritos ni nombrados. Los procesos atraviesan las organizaciones tradicionales [Peña2006]. Davenport ha expresado muy bien esto: "Mientras que una estructura jerárquica de la organización es una vista de relaciones y responsabilidades, su estructura de proceso es una vista dinámica de cómo la organización entrega valor" [DAVENPORT93]. Centro Nacional de Investigación y Desarrollo Tecnológico Página 28

35 Un proceso de negocios (PN): es un conjunto estructurado de actividades, diseñado para producir una salida determinada o lograr un objetivo. Los procesos describen cómo es realizado el trabajo en la empresa y se caracterizan por ser observables, medibles, mejorables y repetitivos [JIM03]. Es importante conocer la diferencia sustancial entre un proceso y una tarea, señalando que una tarea corresponde a una actividad conducida por una persona o un grupo de personas, mientras que un proceso de negocio corresponde a un conjunto de actividades que, como un todo, crean valor para el cliente externo [HAMMER90]. Para que un proceso pueda cumplir su objetivo es necesario complementarlo con las transacciones de negocio. 2.3 Transacciones de negocios Una transacción de negocio es una interacción entre múltiples participantes, que buscan cumplir un objetivo de negocio. Las transacciones se extienden por largos períodos de tiempo y finalizan cuando se cumplen con éxito las condiciones convenidas [BOCAN08]. Tanto la interacción como la información asociada a esta interacción entre los participantes se le conocen como transacción de negocio debido a que presentan información complementaria a los procesos de negocios.. En la figura 2-1 se muestra la Notación para el Modelado de Procesos de Negocio (BPMN por sus siglas en inglés). Figura 2-1 Proceso de Negocios [BOCAN08] En la Figura 2-1 se visualizan las actividades, el orden en el cual se realizan y los actores que participan. Por ejemplo, podemos ver que el rol Viajero realiza la actividad Buscar Viaje para después pasarle el control al rol Agencia de Viajes. En un proceso de negocio también podemos observar los documentos intercambiados y los mensajes que se originan [BOCAN08]. Los procesos de negocios son el conocimiento de la organización, pues establecen la forma en cómo esa organización trabaja para lograr sus metas. Los Centro Nacional de Investigación y Desarrollo Tecnológico Página 29

36 procesos se clasifican en diferentes categorías que van desde procesos de manufactura hasta procesos de negocio [RPS00]. Un proceso de negocio detalla los requerimientos funcionales de un sistema. Algunas de las características de los procesos de negocios son [Peña2006]: La comprensión y el cumplimiento de los requisitos. La necesidad de considerar los procesos en términos que aporten valor. La obtención de resultados del desempeño y eficacia del proceso. La mejora continua de los procesos con base en mediciones objetivas. Como podemos ver, los procesos de negocios toman un rol muy importante para el cumplimiento de objetivos de una organización, por lo anterior la metodología considera como base los procesos de negocios a fin de obtener requerimientos detallados, ya que es importante conocer no solo las actividades de los procesos de negocios, si no también es necesario conocer que entidades que están interactuando para que se cumpla dicho proceso, con el desarrollo de esta metodología se definieron acciones que ayuden al usuario a transmitir sus necesidades computacionales al experto desarrollador, de tal forma de lograr una definición consistente de las especificaciones que definan el comportamiento del sistema. 2.4 Patrones de Modelado de los Procesos de Negocios Un patrón es la abstracción de una forma concreta el cual mantiene a repetirse en un contexto específico no-arbitrario. Los patrones se han definido por diferentes variables, algunas se describen a continuación [BIZAGI11]: Condiciones que se definen para que el patrón sea aplicable Ejemplos de algunas situaciones de negocio Problemas típicamente semánticos, de la realización en idiomas actuales. Implementación de soluciones. El objetivo del desarrollo de los patrones fue describir la capacidad potencial que un workflow podría tener durante el rendimiento del proceso de negocio. El rango de patrones va desde los más simples a los más complejos y comprende los comportamientos esperados en la mayoría de los modelos de procesos [White04]. Los patrones de modelamiento se agruparon de manera siguiente, posteriormente vendrá la descripción de algunos de ellos, los que fueron de utilidad para el proceso de negocio de este trabajo de tesis. Patrones Básicos de Control de Flujo Patrones de Sincronización y Enrutamiento Avanzada Patrones Estructurales Centro Nacional de Investigación y Desarrollo Tecnológico Página 30

37 Patrones que involucran múltiples instancias Patrones que se basan en el estado del sistema Patrones de Cancelación 2.5 Análisis de Dominio Orientado Características FODA es una metodología de análisis de dominio basado en la identificación de las características distintivas o prominentes de la clase de un sistema [KCHN09]. Este método FODA, se implementó con la finalidad de conocer como está estructurado el dominio específico que plantea este trabajo acerca de la elicitación de requerimientos. FODA está integrada por las fases que se muestran en la figura 2-2. Figura 2-2 Estructura del FODA [KRUT93] A continuación se define cada una de las fases del FODA: Análisis de contexto: define el alcance que tendrá el dominio para su análisis. Modelado de dominio: proporciona una descripción de los problemas que constituye el dominio. Modelado de arquitectura: provee soluciones a los problemas en el dominio a través de la elaboración de una arquitectura del software. FODA es utilizado para analizar aplicaciones existentes buscando [HERNANDEZ11]: Centro Nacional de Investigación y Desarrollo Tecnológico Página 31

38 Características indispensables Implementaciones alternativas Funciones opcionales Dependencias entre características Crear diccionario del dominio Establecer terminología Explorar alternativas Interactuar con usuarios poco comunicativos 2.6 Conclusiones Capítulo 2 Dentro de este capítulo se mostraron los conceptos indispensables para la comprensión de este trabajo iniciando con lo que es la ingeniería de requerimientos, que son los procesos de negocios y transacciones de negocios, así como también los tipos patrones de modelamiento que existen en el modelado de los procesos de negocios. También se realizó una descripción de acerca de la método FODA para poder comprender como fue utilizado en el desarrollo de la metodología. En el siguiente capítulo se describe el desarrollo de la metodología del presente trabajo tesis. Centro Nacional de Investigación y Desarrollo Tecnológico Página 32

39 CAPÍTULO 3 3 Desarrollo Este capítulo se divide en tres partes, llevándose a cabo el desarrollo para aportar una solución al problema planteado: En la primera parte se presentan los resultados de la investigación realizada, utilizando el análisis de dominio orientado a características, enfocándose al estudio del dominio de la elicitación de requerimientos. En la segunda parte se muestran las acciones determinadas que integran la metodología del presente trabajo. En la tercera parte se presenta la metodología desarrollada. 3.1 Análisis de Dominio Orientado a Características A continuación se presentan los resultados obtenidos tras haber aplicado el método FODA sobre el dominio de la elicitación de requerimientos. Es importante mencionar que se realizó una adaptación de los modelos que presenta la metodología FODA, omitiendo algunos diagramas que integra esta, por lo que hay que aclarar que no fue utilizada en su totalidad. Cabe resaltar que el aplicar el método FODA no implica desarrollar todas las actividades de cada una de las fases, ya que estas dependen de lo que se requiera analizar La necesidad de estudiar el dominio de la elicitación de requerimientos surge con el propósito de conocer el domino que abarcará la metodología del trabajo que se plantea, por lo que fue necesario realizar el análisis aplicando el método FODA para poder Centro Nacional de Investigación y Desarrollo Tecnológico Página 33

40 identificar las características de los elementos del dominio de la elicitación de requerimientos y relaciones que se tienen con otros dominios. El dominio que se analizó es el de la metodología de elicitación de requerimientos, en donde se aplicó el FODA dentro de las fases: análisis del contexto, modelado del dominio y modelado de arquitectura, como se describe en el capítulo 2. Para el objetivo de este análisis sólo se realizaron algunas de las actividades que se consideraron necesarias. En la siguiente figura se muestra la estructura del FODA con las actividades que se desarrollaron. Figura 3-1 Diagrama de Actividades Realizadas del FODA Análisis de Contexto La intención de esta fase del FODA es el especificar el alcance de un dominio. En esta fase se analizan las relaciones entre el dominio seleccionado con respecto a otros dominios. Existen diversas metodologías para la elicitación de requerimientos, en donde se aporta una ayuda que facilita la obtención de las necesidades del cliente/usuario. Dentro las actividades que se llevan a cabo para la obtención de los requerimientos está el comprender el dominio del problema, identificar los objetivos y requerimientos funcionales que el sistema deberá realizar. Para iniciar el análisis se definió el dominio a tratar, se elaboraron los diagramas de estructura y de contexto, además de un análisis comparativo de metodologías. Diagrama de estructura El diagrama de estructura de bloques dentro del dominio mencionado muestra como el dominio planteado interactúa con otros dominios, que va desde un nivel inferior al superior Centro Nacional de Investigación y Desarrollo Tecnológico Página 34

41 y muestra donde se sitúa el dominio que se trata. En la figura 3-2 se muestra el diagrama obtenido. Figura 3-2 Diagrama de Estructura La tabla 3-1 define los niveles para el dominio, propuesto en la figura 3-2, en donde se fundamenta una propuesta de metodología de elicitación de requerimientos: Tabla 3-1 Descripción del Diagrama de Estructura Dominio Documento de Requerimiento s de Software Metodologías de Elicitación Procesos de negocios Descripción Define los requerimientos a un nivel de detalle apropiado necesarios para el desarrollo del sistema que se necesita, en donde la fuente de información es proporcionada por el cliente y/o experto, que utiliza como una metodología de investigación, además considera como base el estándar IEEE 830 para el documento. Se encuentran algunas de las metodologías de elicitación que se pueden aplicar para obtener los requerimientos de software. En negritas de encuentra la metodología para elicitación de requerimientos de software utilizando transacciones de los procesos de negocios, que es la que se va estar utilizando para la obtención de los requerimientos. Conjunto de actividades para lograr un objetivo (procesos operacionales) del negocio. Centro Nacional de Investigación y Desarrollo Tecnológico Página 35

42 Información Base de una Metodología de Investigación Estándar IEEE 830 La información proveniente de los clientes y los expertos, en donde definen los diferentes procesos que se requieren para el sistema que se desea desarrollar. De acuerdo a Hernández Sampieri [SAMPIERI06], una metodología de investigación considera los siguientes fases: Concebir la idea a investigar. Plantear el problema: aquí se establecen los objetivos de la investigación, se desarrollan las preguntas de investigación y se justifica la investigación. Elaborar el marco teórico: Revisión de la literatura existente, Definir el tipo de investigación. Establecer la hipótesis: detectar variables, definir las variables y las operaciones. Seleccionar diseño (hace referencia a un plan o una estrategia para poder llegar a la información que se requiere ) Selecciones de la muestra. (en donde se aplicará ) Recolectar datos: elaborar un instrumento de medición y aplicarlo. Analizar los datos: seleccionar las pruebas, elaborar el problema de análisis y realizar el análisis. Presentar resultados: elaborar el reporte de la investigación y presentar el reporte de investigación. Este estándar define un formato y contenido de un documento de Especificación de Requisitos Software. Diagrama de Contexto Una vez que se identificaron, a través del diagrama anterior, los dominios con el que está relacionado el dominio planteado de la elicitación de requerimientos, se realizó el siguiente diagrama de contexto que se muestra en la figura 3-3, en donde se visualizan los flujos de datos que existen de este dominio con los otros dominios con los que interactúa. Centro Nacional de Investigación y Desarrollo Tecnológico Página 36

43 Cliente Experto Resultado Documentos de Requerimientos de Software Información Metodología de Elicitación Solicita Proporciona Revisa Transmite Estandar IEEE 830 Acciones Figura 3-3 Diagrama de Contexto La figura anterior describe todo lo que se procesa dentro de una metodología de elicitación de requerimientos, la tabla 3-2 muestra cada una de las partes que se contempla en el diagrama: Tabla 3-2 Descripción Diagrama de Contexto Dominio Metodología de Elicitación Información Acciones Estándar IEEE 830 Documento de Requerimientos de Software Descripción Procesa la información entrante a través de las acciones almacenadas que se utilizan como base para identificar los requerimientos que se quieren definir, para posteriormente revisar estos requerimientos utilizando el estándar IEEE 830, para así elaborar un formato estándar del documento de requerimientos de software que se obtiene como resultado final. Es proveniente del cliente y del experto. Almacenan las transacciones de los procesos de negocios que ayudaran a detallar el requerimiento que se quiere expresar. Define un formato y contenido de un documento de Especificación de Requerimientos de Software. Es el resultado del proceso que se lleva a cabo y que inicia con la información entrante por parte del cliente y/o experto, en donde a través de las acciones (contempla las transacciones de los procesos de negocios) que se encuentran almacenadas se utilizan como base para identificar los requerimientos que se requieren definir, para posteriormente revisar estos requerimientos utilizando el estándar IEEE 830 y elaborar un formato estándar del documento de requerimientos de software. Centro Nacional de Investigación y Desarrollo Tecnológico Página 37

44 Análisis Comparativo de Metodologías Se realizó un análisis de otras metodologías, se compararon y se revisó qué tanto se relaciona con la metodología de este trabajo de tesis. 1. Obtención de Requerimientos de Software ERP con Modelos de Referencia [GAO10] Este trabajo propone una metodología integral para obtener los requerimientos de software a través del uso de modelos de referencia como dominio del conocimiento. En contraste con la metodología de esta tesis, está enfocado a elicitar los requisitos para la implantación de un sistema ERP. 2. Una propuesta metodológica para modelar procesos de negocios de decisión como técnica de elicitación de requisitos para sistemas de Inteligencia de negocios [QUEL09] Este trabajo propone una herramienta basada en la Notación de Modelado de Procesos de Negocios (por sus siglas en inglés BPMN), que modela Procesos de Negocios Decisionales, el cual considera la toma de decisiones como un proceso a ser modelado. La metodología de la tesis en comparación a este trabajo propone que la elicitación de los requerimientos este enfocada para el desarrollo de un sistema que no es transaccional, sino a un sistema de apoyo para la toma de decisiones [QUEL09]. 3. Uso de Técnicas Etnográficas en el Desarrollo de una Herramienta Móvil para la Obtención de Requerimientos [SHAH09] Este trabajo presenta el desarrollo de una herramienta web móvil para la elicitación de requerimiento utilizando como base la etnografía (Ethno-MRE), la que facilitará la recopilación de datos por medio de diversas formas de asistencia en la PDA. La diferencia que existe con la metodología de la tesis es que este trabajo no utiliza PN en la obtención de requerimientos. 4. Escribiendo y Leyendo la Documentación de Software: Como el Proceso puede afectar a la Comprensión [REMO09] Este trabajo presenta una metodología de análisis de modelos mentales para la documentación que se elabora para el proyecto, solucionando el problema de la falta de entendimiento que existe entre los miembros que integran un equipo de desarrollo en cuanto el formato utilizado para la documentación. La diferencia que existe con la metodología de esta tesis es que este trabajo no utiliza PN para la obtención de requerimientos. Centro Nacional de Investigación y Desarrollo Tecnológico Página 38

45 3.1.2 Modelado del Dominio Análisis de características El objetivo de este análisis, es conocer los elementos que interactúan entre las partes que integran el dominio. Cabe resaltar que el diagrama que se presenta fue realizado a partir del estudio que desarrolló [Bocan09]. La tabla 3-3 muestra la simbología utilizada para la representación de características alternativas, opcionales y obligatorias de los diagramas de árboles de características: Tabla 3-3 Símbolos Utilizados en el Árbol de Características Símbolo Significado Característica obligatoria. Característica alternativa. Característica opcional. Figura 3-4 Diagrama de Árbol de Características Centro Nacional de Investigación y Desarrollo Tecnológico Página 39

46 A continuación se describen las características mostradas en el digrama de árbol de la figura 3-4: Tabla 3-4 Descripción del Árbol de Características Información: Definición: Padre Fuente Experto: Definición: Padre Fuente Cliente: Definición: Padre Fuente Negocio: Definición: Padre Fuente Dominio: Definición: Padre Fuente Objetivo: Definición: Padre Fuente Producto: Definición: Padre Fuente Acciones: Definición: Alternativa Proveniente de quien utilizará la metodología. Metodología de Elicitación. Experto ó Usuario del dominio. Alternativa Experto analista.. Información. Experto del dominio. Obligatoria Usuarios/clientes que requieren se desarrolle el sistema. Información. Usuario del dominio. Obligatoria El dominio para el cual se requiere desarrollar el sistema. Metodología de Elicitación. Experto y/o Usuario del dominio. Obligatoria Identifica una visión general del dominio del negocio (el problema a resolver). Negocio. Experto y/o Usuario del dominio. Obligatoria Describe el objetivo que tendrá que cumplir el negocio con el sistema que se necesita desarrollar. Negocio. Experto y/o Usuario del dominio. Obligatoria Desarrollo de un documento de requerimientos de software. Metodología de Elicitación. Experto del dominio. Obligatoria Guias y formatos para la descripcion detallada del proceso de negocio. Centro Nacional de Investigación y Desarrollo Tecnológico Página 40

47 Padre Fuente Producto. Experto del dominio. Docto. de requerimientos Obligatoria software: Definición: Documento que define de manera detalla los requerimientos funcionales de sofware, bajo el estandar IEEE 830. Padre Producto. Fuente Proceso de negocio: Definición: Padre Fuente Descripción Definición: Padre Fuente Entrada: Definición: Padre Fuente Salida: Definición: Padre Fuente Controles: Definición: Padre Fuente Roles: Definición: Padre Experto del dominio. Obligatoria Identifica un conjunto de actividades para lograr un objetivo (procesos operacionales) del negocio. Negocio. Experto y/o Usuario del dominio. Obligatoria Se realiza una descripción del funcionamiento de la transacción del negocio de forma general. Transacción de negocio. Experto y/o Usuario del dominio. Obligatoria Se describe la(s) entrada(s) de la transacción Transacción de negocio. Usuario del dominio. Obligatoria Se describe la(s) salida(s) de la transacción, es decir, cual es el evento resultante de la ejecución del proceso. Transacción de negocio. Usuario del dominio. Obligatoria Son objetos que gobiernan o regulan cómo, cuándo y si una actividad se ejecuta o no. Ejemplos: Normas, guías, políticas, calendarios, presupuesto, reglas, especificaciones, procedimientos. Transacción de negocio. Experto y/o Usuario del dominio. Obligatoria Identifica que roles van a estar interactuando para poderse llevar a cabo la transacción. Transacción de negocio. Centro Nacional de Investigación y Desarrollo Tecnológico Página 41

48 Fuente Operaciones del negocios Definición: Padre Fuente Actividad Definición: Padre Fuente Descripción de la Actividad: Definición: Padre Fuente Tipo: Definición: Padre Fuente Rol: Definición: Padre Fuente Precondición: Definición: Padre Fuente Postcondición: Definición: Padre Fuente Experto y/o Usuario del dominio. Obligatoria Hace referencia al conjunto de actividades que integra los procesos de negocios que se llevan a cabo y el orden en que se van realizando. Transacción de negocio. Experto y/o Usuario del dominio. Obligatoria Indica el nombre de la actividad. Las actividades son los pasos que deben realizarse para convertir las entradas del proceso en el resultado esperado. Operaciones del negocio. Experto y/o Usuario del dominio. Obligatoria Se describe el funcionamiento de la actividad Operaciones del negocio. Experto y/o Usuario del dominio. Obligatoria Indica el tipo de actividad (Manual, Semi-automatizada, automatizada) Operaciones del negocio. Experto y/o Usuario del dominio. Obligatoria Indica el rol que ejecuta la actividad. Operaciones del negocio. Experto y/o Usuario del dominio. Obligatoria Indican las condiciones necesarias para iniciar una actividad. Operaciones del negocio. Experto y/o Usuario del dominio. Obligatoria Indican las condiciones necesarias que deben cumplirse después de que la actividad ha finalizado. Operaciones del negocio. Experto y/o Usuario del dominio. Centro Nacional de Investigación y Desarrollo Tecnológico Página 42

49 3.2 Especificación del Proceso de Negocio Una vez que se han obtenido los resultados de la implementación de la metodología FODA, se identificaron, a través del diagrama de árbol de características, los elementos que están involucrados en el proceso de negocio. La metodología desarrollada utilizará un proceso de negocio para la facturación electrónica a fin obtener un documento de especificación de requerimientos de software. Para conocer las transacciones fue necesario obtener un caso real de un proceso de negocio, por lo que un Instituto de Investigación nos proporcionó un proceso para facturación electrónica a fin de identificar los elementos que componen un proceso y además saber todo lo que implica para que este proceso de negocio cumpla con el objetivo para el cual fue desarrollado. El proceso que se menciona fue utilizado como base para el desarrollo de la metodología que se plantea en este trabajo. La facturación electrónica es un método que utiliza tecnología digital para generar y resguardar este tipo de comprobantes fiscales digitales. La Factura Electrónica es un documento que comprueba la realización de una transacción comercial entre un comprador y un vendedor, compromete a entregar el bien o servicio y obliga a realizar el pago de acuerdo a lo que establece la factura emitida [EDIFACT10] Proceso de Facturación Electrónica Una descripción breve del panorama del caso de prueba es el siguiente: La empresa requiere de un sistema que genere facturas con el propósito de agilizar la información de los registros contables, así como la reducción de errores en la generación, captura, entrega y el almacenamiento de las facturas. Los objetivos que debe cumplir el proceso de facturación electrónica son los siguientes: Crear ordenes de facturación Generar facturas electrónicas Antes de dar a conocer y describir el proceso de facturación es importante tener en cuenta las siguientes definiciones y abreviaturas Centro Nacional de Investigación y Desarrollo Tecnológico Página 43

50 Tabla 3-5 Definiciones y Abreviaturas Concepto Abreviatura Definición Factura F Es un documento utilizado para hacer cuenta y relación detallada de mercancías o servicios vendidos. Orden de Facturación OF Solicitud electrónica en el Sistema de Información de la organización para facturar un servicio Contrato de ingresos CI Acto jurídico mediante el cual se crea, modifican, transfieren o extinguen obligaciones. El contrato de ingresos se celebra entre las autoridades principales de los clientes de las empresas con la organización, en donde las partes declaran su intención de establecer relaciones de carácter general sobre los aspectos de comunicación, planeación, organización, ejecución y control de los trabajos de la organización. Cuentas por cobrar CXC Las cuentas por cobrar establecen el crédito que la empresa otorga a sus clientes, como resultado de la entrega de productos o servicios Tabla 3-6 Descripción de Roles Nombre del Rol Asistente Jefe Asistente Depto. Ingresos Jefe depto. Ingresos Tesorero Descripción del Rol Se encarga de registrar las órdenes de facturación en el sistema, así como enviar la documentación de soporte de las mismas al área de ingresos una vez que son aprobadas. Es el encargado de revisar, aprobar, solicitar cambios y cancelar las órdenes de facturación. Se encarga de registrar las facturas dentro del sistema, así como hacer el registro contable de las mismas. Se encarga de aprobar las facturas. Se encarga de aprobar las facturas y enviarlas al cliente. Descripción General del Proceso de Facturación Para la descripción de este proceso se elaboró una definición textual de las transacciones de negocio, basado en el modelo de transacciones de negocios (BTM por sus siglas en inglés, Business Transactions Model) como se realiza en [BOCANEGRA08]. Cabe mencionar que los diagramas de la figura 3-5 son una representación informal del proceso. Centro Nacional de Investigación y Desarrollo Tecnológico Página 44

51 Figura 3-5 Proceso de Facturación Tabla 3-7 Descripción del Proceso de Facturación Elemento Proceso de Negocio Descripción Entradas Salidas Roles Restricciones Documentos Actividades (Operaciones del negocio) Descripción Proveer factura electrónica El proceso de facturación consiste en crear y autorizar las facturas, con los cuales el Instituto de Investigación puede obtener ingresos mediante los servicios que les ofrece a sus clientes. Contrato de ingresos autorizado. Factura Aprobada. Asistente, Jefe del asistente, departamento de ingresos, jefe departamento de ingresos. Solo se podrán crear facturas de proyectos. Orden de facturación autorizada, factura electrónica. Seleccionar líneas del programa de pagos, crear OF, enviar aprobación OF, revisar y validar la OF, cancelar OF, solicitar modificación, modificar OF, Aprobar OF y enviar documentación soporte a CXC, Recibir documentación soporte, validar documentación soporte y OF, cancelar OF, solicitar modificación, generar factura y completar información, enviar factura aprobación, revisar y validar factura, cancelar factura, solicitar modificación de factura, modificar factura, aprobar factura, imprimir factura, generar registro contable, firmar factura, firmar factura. Las operaciones del negocio hacen referencia a las actividades que se llevan a cabo para realizar con éxito la transacción. El proceso de facturación electrónica también se puede ver cómo dos procesos: Creación de órdenes de facturación y Creación de facturas, que se muestra en el siguiente diagrama de la figura 3-6 y su descripción en las tablas 3-8 y 3-9. Centro Nacional de Investigación y Desarrollo Tecnológico Página 45

52 Figura 3-6 Procesos Implícitos en el Proceso de Facturación Tabla 3-8 Descripción del Proceso: Facturación\Creación de Órdenes de Facturación Elemento Proceso de Negocio Descripción Descripción Crear ordenes de facturación El proceso de órdenes de facturación consiste en crear las peticiones de cobro para que el área de facturación pueda elaborar las facturas correspondientes. Entradas Contrato de ingresos autorizado, solicitud de modificación. Salidas Roles Restricciones Documentos Actividades (Operaciones del negocio) Orden de facturación aprobada. Asistente, jefe del asistente No se podrán crear órdenes de facturación si no existe un contrato de ingresos. Orden de facturación autorizada. Seleccionar líneas del programa de pagos, crear OF, enviar aprobación OF, revisar y validar la OF, cancelar OF, solicitar modificación, modificar OF, Aprobar OF y enviar documentación soporte a CXC. Tabla 3-9 Descripción del Proceso: Facturación \Creación de Facturas Elemento Proceso de Negocio Descripción Entradas Salidas Roles Restricciones Documentos Crear facturas Descripción El proceso de facturación consiste en elaborar y aprobar las facturas que serán entregadas al cliente para sus respectivos pagos. Orden de facturación aprobada. Factura impresa, solicitud de modificación. Depto. de ingresos, jefe departamento de ingresos, tesorero. No se podrán crear facturas si no existe una orden de facturación aprobada. Factura electrónica. Centro Nacional de Investigación y Desarrollo Tecnológico Página 46

53 Actividades (Operaciones del negocio) Recibir documentación soporte, validar documentación soporte y OF, cancelar OF, solicitar modificación, generar factura y completar información, enviar factura aprobación, revisar y validar factura, cancelar factura, solicitar modificación de factura, modificar factura, aprobar factura, imprimir factura, generar registro contable, firmar factura, firmar factura. Descripción Detallada del Proceso de Facturación En este apartado se describe el conjunto de actividades que se llevan a cabo en el proceso de facturación electrónica. El diagrama de la figura 3-7 fue elaborado con la herramienta libre que se llama BizAgi Process Model, la cual utiliza la Notación para el Modelado de Procesos de Negocios (BPMN por sus siglas en inglés, Business Process Modeling Notation) es una iniciativa mantenida actualmente por el Grupo de administración de objetos (OMG por sus siglas en inglés, Object Management Group), la cual ha sido usada para el modelado en el proceso de negocio, el cual describe las actividades clave de la organización y cómo se relacionan e interactúan con los recursos del negocio para lograr la meta establecida para el proceso [OMG08], [LEON09]. Centro Nacional de Investigación y Desarrollo Tecnológico Página 47

54 Figura 3-7 Descripción de Actividades: Facturación Electrónica En la figura 3-7 vamos a encontrar dos tipos de actividades que son: Automática: Son todas aquellas tareas que realiza el sistema sin intervención humana, como lo puede ser: enviar un . Manual: Es un tarea donde interviene un humano para su realización. Centro Nacional de Investigación y Desarrollo Tecnológico Página 48

55 La siguiente tabla muestra un ejemplo de cada uno de los tipos de actividad que se pueden encontrar dentro del proceso de negocio de facturación electrónica. Tabla 3-10 Descripción de Actividades: Facturación Electrónica Actividad Tipo Descripción de la actividad Seleccionar líneas del programa de pagos Enviar documentación soporte a CXC Automática Manual La persona que registra la orden de facturación selecciona un contrato y una o varias líneas del programa de pagos de acuerdo a lo que va a cobrar. Una vez que el asistente recibe el correo de aprobación de su orden de facturación, envía la documentación soporte al área de CXC. Rol Precondiciones Postcondiciones Asistente Asistente Contrato de ingresos autorizado. Orden de facturación aprobada Líneas de pago seleccionadas. Documentación enviada A continuación en la tabla 3-11 se presenta la simbología utilizada para el modelado del proceso de negocio de acuerdo a lo utilizado en el diagrama de la figura 3-7. Tabla 3-11 Descripción de la Simbología Utilizada en el Proceso de Facturación Símbolo Nombre Descripción Evento de Inicio Actividad o Tarea Indica cuando un proceso inicia. Por proceso sólo es permitido un evento de inicio simple. Son actividades de trabajo que la compañía realiza y que no pueden ser descompuestas en más actividades. Centro Nacional de Investigación y Desarrollo Tecnológico Página 49

56 Evento Intermedio Condicional o compuerta de decisión Evento de Fin Flujo de secuencia Entidad Indican algo que ocurre o puede ocurrir durante el trascurso de un proceso, entre el inicio y el fin. Los eventos intermedios pueden utilizarse dentro del flujo de secuencia, o adjuntos a los límites de una actividad. Son los elementos utilizados para controlar la divergencia y convergencia del flujo. Es utilizada cuando pueden existir diferentes flujos en el proceso y/o actividades. Indican cuando un camino del proceso finaliza. Es usado para mostrar el orden en que los procesos serán realizados. Se emplean para conectar procesos, actividades y eventos. Representa la entidad o el proceso que se lleva a cabo. Participante Participante dentro de un pool, representa los diferentes roles que interactúan dentro del proceso. Para el proceso de negocio de facturación electrónica se utilizó el tipo de evento intermedio de enlace, ya que permite enlazar dos elementos de un proceso para crear situaciones de bucle o para evitar líneas de secuencia de flujo largas o cruzadas y están limitados a un nivel de proceso. También dentro del proceso de negocio para la facturación electrónica se identificaron patrones de modelado de secuencia y selección exclusiva y, que nos servirán de guía para determinar las acciones que ayuden al usuario a determinar sus requerimientos detallados basados en el proceso; para conocer más estos procesos se sugiere ver el trabajo sobre patrones de modelamiento de [BIZAGI11]. 3.3 Transacciones de Negocios en el Proceso de Negocio para la Facturación Electrónica Las transacciones de negocios, como bien se describen en el capítulo 2.3, es la interacción que hay entre los múltiples participantes con el propósito de lograr un objetivo Centro Nacional de Investigación y Desarrollo Tecnológico Página 50

57 común, además la interacción es la información necesaria para llevar a cabo la negociación entre los diferentes roles que participan en el proceso de negocio, incluyendo las restricciones pertinentes dentro del proceso. Las transacciones de negocios aplicadas en el proceso de facturación electrónica son las siguientes: 1. El Asistente envía la orden de facturación para solicitar la aprobación por parte del jefe del asistente. 2. El Asistente realiza las modificaciones solicitadas por el departamento de ingresos, para posteriormente solicitarle al Jefe de Asistente haga la revisión y validación de la orden de facturación. 3. El Jefe del Asistente revisa y valida que la orden de facturación contenga la información requerida, de lo contrario solicita las modificaciones necesarias al Asistente: 4. El Asistente una vez que ha recibido la orden de facturación aprobada por jefe del asistente, envía la documentación a CXC correspondiente al Departamento de Ingresos para solicitar la revisión y validación de la documentación. 5. El Departamento de Ingresos una vez que ha recibido y validado la documentación de soporte y determina que es incorrecta ésta, solicita al Asistente que realice las modificaciones necesarias. 6. Departamento de Ingresos una vez que ha recibido y validado la documentación de soporte y determina que es correcta ésta, procede a generar la factura y solicita la aprobación correspondiente al Jefe del Departamento de Ingresos. 7. Jefe del departamento de Ingresos revisa y valida la factura que contenga la información requerida, de lo contrario solicita las modificaciones necesarias al Departamento de Ingresos: 8. Jefe del Departamento de Ingresos una vez que la factura ha sido aprobada, envía la factura al Departamento de Ingresos para solicitarle que éste genere el registro contable correspondiente. 9. Jefe del Departamento de Ingresos una vez que haya revisado y determinado que es correcta la información del registro contable solicita al Departamento de Ingresos revise que el registro contable sea correcto. 10. El Jefe del Departamento de Ingresos una vez que haya revisado y determinado que es incorrecta la información del registro contable solicita al Jefe del Departamento de Ingresos que proceda a cancelar el registro contable y realice las modificaciones que son necesarias. 11. El Tesorero una vez que haya revisado y determinado que es incorrecta la información del registro contable solicita al Departamento de Ingresos que proceda a cancelar el registro contable y realice las modificaciones que son necesarias. 12. El Tesorero una vez que haya revisado y determinado que es correcta la información del registro contable procede a enviar la factura electrónica al cliente. Centro Nacional de Investigación y Desarrollo Tecnológico Página 51

58 3.4 Interacción entre Transacciones de Negocios y Patrones de Modelado del Proceso de Negocio Como se menciona en el punto 3.2.1, las características y elementos que contiene un proceso de negocio, tales como: roles, entradas, salidas y actividades entre otros, son utilizados para obtener un documento de requerimientos de software. Aquí se dan transacciones entre los usuarios y los desarrolladores, esto es, interactuando e intercambiando información que se utiliza para la ejecución del proceso de negocios. Las transacciones de negocio forman parte muy importante dentro del proceso del negocio, debido a que invoca cada una de las operaciones que se ejecutan o que se interrumpan de acuerdo a los criterios que utilizan cada una de las actividades que conforman el proceso de negocio. Cuando las actividades se van ejecutando dentro del proceso de negocio para la facturación electrónica, se identifican que no solo los criterios de las actividades sean indispensables para llevar a cabo la transacción, sino que además utilicen patrones de modelado de procesos de negocios para representar el flujo de trabajo a seguir y lograr el objetivo del proceso de negocio. Por lo anterior se dio a la tarea de estudiar los tipos de patrones de modelado de procesos de negocios (2.3) con la finalidad de conocer como se lleva el control de flujo de trabajo dentro de un proceso de negocio y a partir de estos, definir las acciones necesarias para recopilar la información a un nivel de detalle apropiado para cada uno de los patrones encontrados en el proceso de negocio del caso de estudio. Debido a que se llegó a la conclusión que las transacciones de negocio están ligadas de alguna manera a los patrones de modelado, resulta útil considerar estos patrones como ayuda para definir algún de tipo de acción que colaboren a definir los requerimientos a partir del proceso de negocio para el sistema que se requiera desarrollar. 3.5 Definición de acciones de la metodología Una vez realizado el análisis detallado del proceso para la facturación electrónica se elaboraron una serie de formatos y guías que ayuden a detallar los criterios necesarios para que una actividad se habilite para su ejecución y así mismo se complete de manera exitosa. Para comenzar fue necesario conocer las propiedades de los procesos de negocios, para posteriormente, definir las acciones que ayudarán al cliente a identificar los requerimientos de manera detallada. Como se presenta en el titulo de esta tesis se considera como base el proceso de negocio para la facturación electrónica, para poder identificar los elementos y patrones implícitos existentes que ayudarán a la elaboración de formas y guías para recolectar información necesaria y mínima para que cada una de las tareas se ejecuten de manera completa, para que cumpla con el objetivo para el cual fue elaborado el proceso. Centro Nacional de Investigación y Desarrollo Tecnológico Página 52

59 El proceso que se plantea en este trabajo, fue de ayuda para conocer un panorama general acerca de todo lo que conlleva una transacción de negocio, de acuerdo a lo identificado en el análisis FODA dentro del árbol de características obtenido. La siguiente tabla representa las acciones que se determinaron de acuerdo a los elementos que se identificaran en el proceso de negocio, así como también los patrones del proceso reconocidos en el proceso de negocio para la facturación electrónica. Los patrones básicos de flujo de control fueron las claves para la elaboración de los formatos y guías; puede consultar en el trabajo de [BIZAGI11]. Tabla 3-12 Descripción de Acciones Obtenidas Nombre Acciones Actividad Para que una actividad se lleve a cabo es importante analizar si está sujeta a alguna restricción. Para identificar algunas de estás es necesario considerar las siguientes interrogantes: Quién es el responsable de que se cumpla esa tarea? Sólo hay un responsable o alguien más lo puede realizar? Hay una regla y/o procedimiento existente para esta actividad? Tipo de actividad (automática o manual)? En caso de ser automática, qué restricciones deberán ejecutarse para que se lleve a cabo. Que la información o función que deberá realizarse para que sea finalizada la actividad? Cuál es la información o función mínima que deberá cumplirse para que la actividad se realice? Una vez teniendo la respuesta a las interrogantes anteriores llenar el Formato de Actividades determinado. Compuertas de decisión o condición Estas acciones están definidas de acuerdo a los patrones de modelado que fueron encontrados en el proceso de facturación (Cada compuerta es un patrón de modelamiento). Secuencia Muestra la secuencia de como se van ejecutando las actividades, en donde, para que una actividad sea habilitada deberá esperar que la anterior actividad sea ejecutada. Es necesario considerar lo siguiente: Mediante que criterio (se dé la información clave de la actividad), se conoce que la actividad A ya se ejecutó completamente, En el caso que no se haya completado la actividad A, debe tenerse en cuenta que puede que no se podrá ejecutar la actividad B y por ende no podrá continuar el proceso. Revisar los formatos de las actividades que cumplan con los criterios anteriores para la ejecución de las actividades en Centro Nacional de Investigación y Desarrollo Tecnológico Página 53

60 secuencia. Distribución en paralelo Cuando encontramos un patrón de distribución en paralelo o en otras palabras encontramos que después de una actividad es necesario que se habiliten dos o más actividades concurrentes, para que el flujo del proceso de negocio siga su secuencia de ejecución. Por lo que es importante responder las siguientes interrogantes cuando la actividad que es antecedente para que se habiliten dos o más actividades posteriores. Qué variables son necesarias para que se habiliten las actividades? La actividad precedente a las actividades sólo debe ser completada sin importar las variables o información que se utilicen posteriormente? Qué tan necesario es que las dos o más actividades que se habiliten se ejecuten de manera concurrente? Cuando se presente este caso, se requiere llenar el formato de distribución en paralelo. Sincronización Cuando tenemos este patrón es necesario conocer qué información de las dos o más actividades se requiere para que la actividad se habilite, por lo que se definen las siguientes interrogantes a considerar. Qué variables son necesarias para que se habilite la actividad? Las actividades precedentes a la actividad sólo deben ser completadas o qué información se necesita de estás? Cuando se identifique este tipo de patrón de sincronización se requiere llenar el formato de Sincronización. Selección exclusiva (basada en datos) Cuando encontramos un patrón de este tipo incluido en nuestro proceso es necesario escoger una de las ramas o alternativas que deberá seguirse para continuar el flujo del proceso. Este tipo de decisiones se toman basándose en datos, se pueden considerar las siguientes acciones para identificar qué decisión ha de tomarse. Para que una actividad A pueda realizar la transición a la actividad B o pueda realizar la transición a la actividad C o pueda realizar la transición a la actividad N, entonces se pueden encontrar con las siguientes interrogantes. Qué criterio es necesario para que esta actividad A vaya de A a B o de A a C, o de A a N? Es necesario evaluar el flujo de secuencia de esta actividad a otra mediante estos criterios o en dado caso puede ser omitido. Cuando se tenga este patrón de selección exclusiva se requiere llenar el formato de selección exclusiva basada en datos. Centro Nacional de Investigación y Desarrollo Tecnológico Página 54

61 Es importante mencionar que las acciones definidas solo ayudaran al usuario a responderse las interrogantes planteadas, con el propósito de definir los requerimientos que necesita y llenar, respectivamente, los formatos definidos. Los formatos se definieron para ayudar a detallar lo que se va identificando dentro del proceso de negocio, acerca de los elementos o los tipos de transacción llevadas a cabo en el proceso de negocio para la facturación electrónica, aunque en esta solo se identificaron dos tipos de patrones (2.3) que corresponden a la agrupación de patrones básicos de control de flujo que son: los de secuencia y de selección exclusiva; también en la tabla anterior se incluyeron estos y otros patrones que son básicos para el control de flujo para un proceso de negocio. Para la metodología que plantea este trabajo de tesis sólo se consideran los patrones básicos de control de flujo. Una vez que se hayan identificado los elementos encontrados en el proceso, es necesario llenar los formatos para determinar los diferentes criterios que se deberán definir para que estos se ejecuten. Para el llenado y detección de los patrones que se ejecutan en el proceso, es necesario el trabajo colaborativo entre los participantes, estos son el experto (analista) y el cliente (quien requiere el sistema a ser desarrollado). Esto a fin de identificar y documentar los diferentes criterios que se necesitan para que se lleven a cabo las actividades. Es necesaria la definición de criterios para que una actividad se ejecute ya sea cumpliendo con todos los criterios o solamente con los criterios mínimos. Por tal motivo se plantean los siguientes formatos y guías Formato y guía de Actividad. Formato y guía de Actividades que se Realizan de Manera Concurrente o en Distribución en Paralelo Formato y guía de Actividad Sincronizada Formato y guía de Selección Exclusiva Tabla 3-13 Formato de Actividad Actividad: Autor: Fecha: Criterio de Éxito: Criterio Alterno: Criterio de Fracaso: Centro Nacional de Investigación y Desarrollo Tecnológico Página 55

62 Tabla 3-14 Guía del Formato de Actividad Actividad: Nombre de la actividad. Guía Formato de Actividad Autor: Nombre de la persona que registró los datos en la forma para actividad. Fecha: Fecha en que se realiza el registro. Criterio de Describir qué valores o variables son necesarios para que se ejecute Éxito. de manera exitosa la actividad. Criterio Describir los valores o variables mínimos necesarios para que inicie y Alternativo: termine de ejecutarse la actividad. Criterio de Describir en que caso no se realiza la actividad. Error: Patrón Secuencia de Actividades: El patrón secuencia, es cuando existe un conjunto de actividades en donde estas tienen dependencia una con otra, de tal manera que una actividad deberá terminarse de ejecutar para que pueda iniciar la siguiente actividad. La secuencia indica que una actividad será habilitada sólo hasta que la actividad anterior sea ejecutada [BIZAGI11]. Figura 3-8 Representación de Secuencia de Actividades Cuando se identifique este patrón es importante tener bien detallado los formatos de Actividad para que estas se ejecuten de manera exitosa, para que el flujo de secuencia de estos siga su curso. Patrón Distribución en Paralelo: Es necesaria cuando dos o más actividades deben ejecutarse de forma concurrente o en paralelo [BIZAGI11] en un punto determinado del proceso de negocio, en donde se encuentra con dos actividades que deberán ejecutarse al mismo tiempo, es decir deberán realizarse de manera simultánea para que pueda continuar el flujo de ejecución del proceso. Estas podrán identificarse de dos maneras como se muestran en la siguiente tabla [BIZAGI11], donde en una se utiliza mejor práctica para representar los elementos y en la otra se realiza de manera simple. Centro Nacional de Investigación y Desarrollo Tecnológico Página 56

63 Tabla 3-15 Representación de Distribución en Paralelo [BizAgi11] Distribución en Paralelo (Mejor práctica) Distribución en Paralelo Una vez identificado el patrón en donde se ejecutan dos o más actividades de forma concurrente, es necesario llenar la siguiente forma para detallar más las actividades que intervienen en este patrón. Tabla 3-16 Formato De Actividades que se Realizan de Manera Concurrente o en Distribución en Paralelo Actividad: Autor: Actividades que habilita: Actividad que se garantiza realizar: Criterio de Éxito: Fecha: Criterio Alterno: Criterio de Fracaso: Tabla 3-17 Guía del Formato de Actividades que se Realizan de Manera Concurrente o en Distribución en Paralelo Guía del Formato de Distribución en Paralelo Actividad: Nombre de la actividad que se realizará de manera simultánea con otra actividad. Actividad que la Nombre de la actividad que habilita las actividades que se ejecutaran habilita. de forma simultánea. Autor: Nombre de la persona que registro los datos en la forma para actividad. Fecha: Fecha en que se realiza el registro. Criterio de Describir qué valores o variables son necesarios para que se ejecute Éxito. de manera exitosa la actividad. Criterio Describir los valores o variables mínimos necesarios para que se inicie Alternativo: y termine de ejecutarse la actividad. Criterio de Describir en que caso no se realiza la actividad. Error: Centro Nacional de Investigación y Desarrollo Tecnológico Página 57

64 Patrón de Sincronización: Es requerido cuando una actividad puede iniciarse sólo cuando dos caminos en paralelo hayan sido completados. Es decir, la sincronización combina las rutas que fueron generadas por el patrón de distribución en paralelo. Figura 3-9 Representación de Sincronización El formato siguiente de la tabla 3-18 es aplicado a una Actividad que se realiza una vez que se haya ejecutado de Manera Concurrente dos o más actividades. Tabla 3-18 Formato de Actividad Sincronizada Nombre de la Actividad: Autor: Actividades que la habilitan: Fecha: Criterio de Éxito: Criterio Alterno: Criterio de Fracaso: Tabla 3-19 Guía del Formato de Actividad Sincronizada Guía del Formato de Actividad Sincronizada Actividad: Nombre de la actividad que se inicia cuando dos actividades en paralelo con completadas. Actividades que Nombre de las actividades que deberán ejecutase de manera la habilitan. sincronizada para que se habilite la actividad. Autor: Nombre de la persona que registro los datos en la forma para actividad. Fecha: Fecha en que se realiza el registro. Criterio de Describir qué valores o variables son necesarios para que se ejecute Éxito. de manera exitosa la actividad. Criterio Describir los valores o variables mínimos necesarios para que se inicie Alternativo: y termine de ejecutarse la actividad. Criterio de Describir en que caso no se realiza la actividad. Error: Centro Nacional de Investigación y Desarrollo Tecnológico Página 58

65 Patrón de Selección Exclusiva: Ocurre cuando en un punto del flujo de trabajo se escoge sólo una de varias ramas del proceso, generalmente esta decisión se toma basándose en datos de control del flujo de proceso [BIZAGI11]. Figura 3-10 Representación de Selección Exclusiva El formato de la tabla 3-20 es empleado en una Actividad que se realiza tomando consideraciones que cumplan con la condición establecida para la selección del estado o actividad con la que continuara el proceso en ejecución. Tabla 3-20 Formato de Selección Exclusiva Actividad: Autor: Condición: Estado 1: Estado n: Fecha: Criterio de Éxito: Criterio Alterno: Criterio de Fracaso: Tabla 3-21 Guía del Formato de Selección Exclusiva Guía del Formato de Selección Exclusiva Actividad: Nombre de la actividad que representa la condición que deberá cumplirse para seleccionar el estado o actividad para continuar con la ejecución del proceso. Autor: Nombre de la persona que registró los datos en la forma para actividad. Fecha: Fecha en que se realiza el registro. Condición: Descripción de la condición que genera diferentes criterios para definir la secuencia en que se seguirá ejecutando el proceso. Estado 1. Describir el estado que deberá cumplirse para continuar con flujo del Centro Nacional de Investigación y Desarrollo Tecnológico Página 59

66 proceso. Estado 2: Describir el estado que deberá cumplirse para continuar con flujo del proceso, es obligatorio que existan por lo menos dos estados para poder evaluar la condición... Estado n: Describir en qué caso no se realiza la actividad. Criterios de Describir la información necesaria para que se cumpla la condición Éxito para cualquiera de los estados definidos. Criterios alternos: Cuál es la información mínima para satisfacer la condición para que se cumpla al menos unos de los estados definidos. 3.6 Desarrollo de la Metodología La base que se tomó para el desarrollo de la metodología fue el proceso de negocio para la facturación electrónica que fue proporcionado por el Instituto de Investigación, este proceso debía de cumplir el estándar de BPMN, por lo cual fue indispensable verificar que el proceso estuviera bien formado para que la metodología cumpliera en tener una base formal para su desarrollo, esta formalización realizada se puede consultar en el Anexo A del presente trabajo. La metodología ayudará en la especificación de los requerimientos, a través del desarrollo de un conjunto de actividades distribuidas en las diferentes etapas que integra la metodología, obteniéndose un documento de especificación de requerimientos definido bajo el estándar IEEE 830, además estos requerimientos serán validados para que se cumpla con las características de ser entendibles, correctos y sin ambigüedades. Con la metodología también se proporciona el conocimiento de cómo elaborar un proceso de negocio, proporcionando diferentes formatos y guías que ayudarán al cliente y experto analista a determinar diferentes criterios que han de satisfacer las actividades para que estás se ejecuten de manera exitosa y a fin de determinar a partir de estos los requerimientos considerado para estos, detalles de criterios de éxito, alternos y de fracaso. Las etapas que integra la metodología de este trabajo de tesis, fueron seleccionadas de acuerdo a las etapas de la ingeniería de requerimientos, que son obtención, análisis, especificación y validación de requerimientos. A continuación se definen las etapas y las respectivas actividades que conforman cada una dentro de la metodología de este trabajo de tesis. Las siglas que identificaran la metodología es MERSUTPN por Metodología de Elicitación de Requerimientos de Software Utilizando Transacciones de los Procesos de Negocios ya que podrá ser utilizada para cualquier proceso de negocio al que se necesite obtener requerimientos de manera detallada. Centro Nacional de Investigación y Desarrollo Tecnológico Página 60

67 3.6.1 Etapas de la Metodología Como se menciona anteriormente dentro de la metodología se consideraran las mismas etapas que utiliza la IR, con el fin de tener un documento de especificación de requerimientos correcto, entendible y sin ambigüedades. La siguiente figura muestra las etapas de la metodología y así como los pasos que se llevarán a cabo para el desarrollo de cada una de ellas. Centro Nacional de Investigación y Desarrollo Tecnológico Página 61

68 Obtención Análisis Especificación Validación Panorama Objetivos Proceso de Negocio Requerimientos preliminares Problemas Alternativas/Sol ución Requerimientos detallados Elaborar los requerimientos con el Estándar IEEE 830 Pruebas Requerimientos Correctos Entendibles Sin Ambigüedades Figura 3-11 Etapas de la metodología de la tesis La metodología MERSUTPN se ha representado mediante BPMN como se muestra en la siguiente figura 3-11, en donde se presenta a más detalle todas las actividades que están implícitas, a comparación de la representación de la metodología mostrada en la figura Consultar el anexo B para conocer la descripción de las actividades que integra la metodología representado con BPMN. Figura 3-12 Diagrama Metodología de Elicitación Tesis Centro Nacional de Investigación y Desarrollo Tecnológico Página 62

69 Esta representación de la metodología se realizó con la herramienta BizAgi process modeler. Nótese que cada etapa de la metodología está simbolizada a través de un subproceso que indica que la actividad puede ser analizada o llevada a cabo con más detalle. En seguida una descripción corta para conocer de manera general qué se hará en cada una de las etapas que componen la metodología. 1. Obtención Requerimientos: Representa la extracción de los requerimientos a través entrevistas, de la elaboración de procesos de negocios, de la aplicación de acciones y también el uso de formatos y guías, que ayudan a identificar los requerimientos que se necesitan para el sistema que se requiere. 2. Análisis de Requerimientos: En esta fase se descubren problemas que existen en los requerimientos registrados en la etapa anterior. 3. Especificación de Requerimientos: Aquí se elabora la documentación de los requerimientos acordados con el cliente, en un nivel apropiado de detalle bajo el estándar IEEE Validación de Requerimientos: Es la etapa final de la metodología en donde el propósito es validar cada uno de los requerimientos especificados en la etapa anterior, a fin de verificar que todos los requerimientos que aparecen en el documento especificado estén de manera entendible, correcta y sin ambigüedades. A continuación se define de manera más detallada cada una de las etapas de la metodología de este trabajo de tesis Etapa 1: Obtención de Requerimientos A) Objetivos Conocer el dominio del problema. Obtener información interna del negocio (procedimientos, políticas, normas). Conocer los objetivos del negocio. Obtener el proceso de negocio. Obtener los requerimientos en base a la aplicación de acciones en el proceso. Obtener documento preliminar de requisitos. B) Descripción Para dar inicio con la primera etapa de la obtención de requerimientos, es necesario realizar reuniones con los clientes y usuarios para poder identificar los requerimientos computacionales; es fundamental definir inicialmente el dominio del problema que se va a resolver y posteriormente haber elaborado el proceso de negocio para cumplir el objetivo de la organización, para que se puedan implementar las acciones correspondientes para que ayuden a la obtención detallada de los requerimientos del proceso de negocio. Centro Nacional de Investigación y Desarrollo Tecnológico Página 63

70 Ya que llevar a cabo un desarrollo de software sin haber definido una especificación de requerimientos, en ocasiones provoca que el sistema final no cumpla con los objetivos para lo cual fue desarrollado. A la vez en esta fase es necesario mantener la comunicación con el cliente para cualquier duda o aclaración que pueda presentarse. Esta fase tiene como objetivo realizar la recolección de requerimientos, siguiendo los siguientes pasos que se muestran en la siguiente figura 3-13: Centro Nacional de Investigación y Desarrollo Tecnológico Página 64

71 Entrevistas clientes y analistas(expertos) Panorama Objetivos Analisis del panorama Actores Operaciones Controles Entrada Salida Proceso de negocio Documento de Requerimientos Acciones Figura 3-13 Etapa 1: Obtención de Requerimientos La figura 3-13 muestra las actividades que integran la etapa de obtención de requerimientos Así mismo en la figura 3-14 se muestra la representación con BPMN de esta etapa, mediante un subproceso que forma parte del proceso de la metodología definida anteriormente. Figura 3-14 Diagrama Etapa 1: Obtención de Requerimientos Centro Nacional de Investigación y Desarrollo Tecnológico Página 65

72 En seguida se realiza la descripción de cada una de las actividades que integra la primera etapa de la metodología. C) Actividades En la figura 3-13, las actividades son definidas de acuerdo a la representación de la etapa, para ver la definición de todas las actividades que integran la etapa de la representación de la figura 3-14 con BPMN consultar el anexo B. 1.- Panorama del Proyecto Como se puede apreciar en la figura 3-14, es la primer actividad a seguir dentro de la primer etapa de la metodología de este trabajo de tesis. Para que ésta pueda ser realizada es necesario usar en primera instancia las técnicas de obtención de requerimientos; se recomienda el uso de entrevistas, para poder conocer de manera general el problema que se desea resolver dentro del dominio específico del negocio. Recuerde que estas técnicas se seguirán utilizando para desarrollar las siguientes actividades. El panorama tiene como objetivo el conocimiento general del caso a trabajar. Se establece la meta Principal del Proyecto la cual estará enfocada a la resolución del problema. De modo que el conocimiento de la problemática a tratar y de la meta propuesta ayude a la localización de riesgos, obstáculos y restricciones en cuanto a la identificación de los requerimientos 2.- Objetivos Una vez que se tenga bien definido el panorama acerca del sistema, es necesario definir cuáles serán los objetivos que deberá cumplir el sistema que se pretende desarrollar. Recuerde que un objetivo es lo que se quiere lograr, alcanzar o concebir. Los objetivos deberán expresarse con claridad, deben ser formulados de manera que su resultado sea alcanzable. Evidentemente los objetivos que se especifiquen requieren ser congruentes entre sí [Sampieri06]. Para construir los objetivos deben considerarse las siguientes interrogantes (los que sean necesarios y en el orden más conveniente): Quién, qué, cómo, cuándo y dónde [Caballero00]. Para elaboración de los objetivos es necesario tener claro lo siguiente. Asegurar que el cliente, usuarios y expertos tienen un entendimiento común del panorama del problema a resolver. Centro Nacional de Investigación y Desarrollo Tecnológico Página 66

73 Tabla 3-22 Formato de Objetivos Objetivo: Autor: Fecha: Descripción: Importancia: Comentarios Adicionales: Tabla 3-23 Guía del Formato de Objetivos Objetivo Autor: Fecha: Descripción Importancia Comentarios adicionales Guía del Formato de Objetivos Nombre del objetivo Nombre de la persona que elaboró el formato. Fecha en que llenó el formato. Describe de manera detallada qué es lo deberá contener para que este objetivo se cumpla. El grado de importancia puede estar dado por: alta, media, baja. Es alta debido a que si no existe orden de facturación no se podrá crear la factura electrónica. Para el caso que no todos tengan un entendimiento claro del sistema que requieren desarrollar, se tendrá que detallar aun más la descripción del panorama del proyecto. Ya que es necesario que todos tengan un mismo entendimiento, para facilitar así las próximas sesiones de entrevistas para la elaboración del proceso y posterior a la obtención de requerimientos, que se realicen con el cliente experto, por eso es muy importante que se entienda en el mismo sentido lo que se desea desarrollar. 3.- Proceso de Negocio Después de haber realizado los dos pasos anteriores de esta etapa de obtención de requerimientos, es necesario que el cliente, experto o cliente/experto definan el proceso de negocio o el conjunto de actividades que se deberán ejecutar para el cumplimento de los objetivos planteados en el paso anterior. Antes de comenzar con la elaboración del proceso de negocio, de acuerdo al autor Quelopana [Quelo09], es necesario considerar las respuestas de los siguientes interrogantes: Qué actores están involucrados en las operaciones? Qué diferencía algunas actividades operacionales de otras? Centro Nacional de Investigación y Desarrollo Tecnológico Página 67

74 Qué actividades son realizadas por un determinado actor? Cuáles son las entradas y las salidas de las actividades? Cuál es la secuencia de actividades que deben llevarse a cabo para un caso específico? Cuáles actividades pueden desarrollarse en paralelo para un caso específico? Para realizar el proceso hay que tener en cuenta que se deben identificar los siguientes elementos, de acuerdo al BPMN [OMG08]. a) Operaciones (el conjunto de actividades a realizarse). b) Entrada c) Salida d) Actores e) Controles El siguiente diagrama representa las actividades que deberá realizarse para poder ejecutar el proceso de negocio de la metodología. Figura 3-15 Diagrama Etapa 1: Elicitación/Proceso de Negocio Es importante mencionar que para la elaboración de los formatos se consideraron los trabajos de [Bocan08], [Quelo09], [Mendez08]. Transacción de Negocio. Para identificar las actividades que conforman las operaciones del negocio es necesario tener claro la transacción de negocio que se necesita. Para ello utilizaremos como primer paso el siguiente formato de transacción de negocio y la guía de llenado del mismo La guía y el formato de transacción de negocio serán utilizados para describir de forma textual y con mayor nivel de abstracción la transacción de negocio de acuerdo a como lo define [Bocan08]. Centro Nacional de Investigación y Desarrollo Tecnológico Página 68

75 Tabla 3-24 Formato de Transacción de Negocio. Transacción de Negocio: Autor: Fecha: Descripción: Entradas: Salidas: Roles: Restricciones: Documentos Actividades (operaciones del negocio): Comentarios: Tabla 3-25 Guía del Formato de Transacción de Negocio Transacción de Negocio: Autor: Fecha: Descripción Entrada: Salida: Guía del Formato de Transacción de Negocio Nombre de la transacción o proceso de negocio que se llevará a cabo. Nombre de quien elaboró la forma. Fecha en la que se elaboró. Describe lo que realizará la transacción de negocio. Describe con qué documento, dato y/o información deberá comenzar la ejecución de la transacción. Cuál es el resultado resultados que se deberá obtener una vez finalizada la transacción. Roles: Asistente, Jefe del asistente. Restricciones: Bajo qué condiciones podrá ejecutarse la transacción. Documentos: Nombre del documento, en caso de que existan documentos internos relacionados al proceso. Actividades (Operaciones del negocio): Nombres de las actividades que se realizarían para que ejecute la transacción de negocio. Comentarios Comentarios adicionales sobre la transacción de negocio Centro Nacional de Investigación y Desarrollo Tecnológico Página 69

76 Una vez definida de manera textual y general los elementos que son necesario para que se ejecute el proceso de negocio, es necesario empezar con la definición general de los roles que intervienen en la transacción de negocio (2.3). Roles Los roles representan a los actores que estarán involucrados en la ejecución del la transacción de negocio. Tabla 3-26 Formato de Roles Rol: Autor: Persona Actual a Cargo: Fecha: Descripción: Comentarios: Tabla 3-27 Guía del Formato Roles Rol Autor: Fecha: Persona Actual a Cargo del Rol. Descripción Comentarios Guía del Formato Roles Nombre del Rol que participa para que el proceso se lleve a cabo, por ejemplo departamento ingresos. Nombre de quien elaboró la forma. Fecha en que se elaboró la forma. Nombre de la persona o personas que tienen el rol asignado. El nombre de quien está a cargo es esencial para poder determinar los requerimientos necesarios, así como la información necesaria de las actividades o tareas que se ejecutan en el proceso Describe las funciones que tiene que realizar durante el proceso. Aquí se describe los detalles adicionales acerca del Rol. La información que se recopile de los roles será también de utilidad para conocer quiénes son las personas con las cuales realizar entrevistas posteriores para la definición de los requerimientos detallados. Una vez habiendo definido de manera textual la transacción de negocio, así como de los roles que lo integran, se prosigue a realizar el modelo del proceso utilizando el diagrama de procesos de negocios de la BPMN [OMG08]. La tabla 3-28 muestra los elementos básicos para representar la transacción o proceso de negocio. Centro Nacional de Investigación y Desarrollo Tecnológico Página 70

77 Tabla 3-28 Guía Básica para la representación del Proceso de Negocio con BPMN Símbolo Nombre Descripción Evento de Inicio Actividad (Atómica) Actividad (Compuesta o Subproceso) Evento Intermedio Condicional Exclusiva Indica cuando un proceso inicia. Por proceso sólo es permitido un evento de inicio simple. Son actividades de trabajo que la compañía realiza y que no pueden ser descompuestas en más actividades. Es un conjunto de actividades incluidas dentro de un proceso. Puede desglosarse en diferentes niveles de detalle denominadas tareas [Analítica11]. Indican algo que ocurre o puede ocurrir durante el trascurso de un proceso, entre el inicio y el fin. Los eventos intermedios pueden utilizarse dentro del flujo de secuencia, o adjunto a los límites de una actividad. Son decisiones que toma el usuario del sistema para decidir el camino en que continuará ejecutándose el proceso. Condicional paralela Indica un punto del proceso donde pueden ser llevadas a cabo actividades en forma concurrente y sincroniza los caminos que parten de una compuerta paralela Evento de Fin Indican cuando un camino del proceso finaliza. Flujo de secuencia Es usado para mostrar el orden en que los procesos serán realizados. Se emplean para conectar procesos, actividades y eventos. Entidad Representa la entidad o el proceso que se lleva a cabo. Centro Nacional de Investigación y Desarrollo Tecnológico Página 71

78 Participante Participante dentro de una entidad, representa los diferentes roles que interactúan dentro del proceso. Existen varias herramientas que nos permiten representar procesos de negocios de software libre y comercial, como por ejemplo BizAgi process modeler, visio de Microsoft office, por mencionar algunas. Para representar los elementos se realizó el siguiente ejemplo, en donde la transacción o proceso que se realiza es el de Registrar la información de un producto, (ver Anexo C, para ver detalles de cómo se modeló el ejemplo con la herramienta de BizAgi process modeler). Figura 3-16 Proceso de Ejemplo de Creación de Órdenes de Facturación Así también para tener un definición más detallada acerca de las actividades que se representan en el proceso de negocio es necesario el siguiente formato. En donde para el llenado de las actividades se puede utilizar el formato 1 o 2 de las tablas 3-12 y 3-30; para el primer caso deberá llenar la forma por cada una de las actividades y para la segunda dentro de la misma forma irán los datos de todas las actividades identificadas en el proceso. Tabla 3-29 Formato 1 de Actividad del PN Actividad: Proceso de Negocio: Autor: Fecha: Tipo: Rol: Precondición: Poscondición: Centro Nacional de Investigación y Desarrollo Tecnológico Página 72

79 Tabla 3-30 Formato 2 de Actividades del PN Autor: Fecha: Proceso de Negocio: Actividad Tipo Descripción Rol Precondición Poscondición Tabla 3-31 Guía de los Formatos de Actividades de PN Actividad Proceso de Negocio Autor: Fecha: Tipo Descripción Rol Precondición Postcondición Guía de los Formatos de Actividades de PN Nombre de la actividad. Nombre del proceso de negocio del que forma parte de la actividad. Nombre de quien elaboró la forma. Fecha en que se elaboró la forma. Indica el tipo de actividad puede ser: Automática: Son todas aquellas tareas que realiza el sistema sin intervención humana, como puede ser: enviar un . Manual: Es un tarea donde interviene un humano para su realización. Se describe el funcionamiento de la actividad Indica el rol que ejecuta la actividad. Indican las condiciones necesarias para iniciar una actividad. Indican las condiciones necesarias que deben cumplirse después de que la actividad se ha completado. Es necesario tener bien especificado el proceso de negocio para que en la siguiente actividad se apliquen las acciones correspondientes para la determinación detallada de los requisitos y de la información necesaria para el desarrollo del sistema que se requiere. En caso de que dentro del proceso de negocio se tengan actividades de tipo subproceso, entonces se deberá utilizar el siguiente formato; es necesario mencionar que en el mismo caso que los formatos de las actividades que integran los procesos de negocios, también se pueden utilizar los formatos 1 y 2 del subproceso, dependiendo si se quiere documentar por actividad o por todas las actividades que lo conforman. Centro Nacional de Investigación y Desarrollo Tecnológico Página 73

80 Tabla 3-32 Formato 1 de Actividad del Subproceso Actividad: Subproceso: Autor: Proceso de Negocio: Fecha: Tipo: Rol: Precondición: Poscondición: Tabla 3-33 Formato 2 de Actividades del Subproceso Autor: Fecha: Subproceso: Proceso de Negocio: Actividad Tipo Descripción Rol Precondición Poscondición Tabla 3-34 Guía de los Formatos de Actividades de PN Guía de los Formatos de Actividades de PN Actividad Subproceso Proceso de Negocio Autor: Fecha: Tipo Descripción Rol Nombre de la actividad. Nombre del subproceso al que pertenece la actividad Nombre del proceso de negocio del que forma parte de la actividad de subproceso. Nombre de quien elaboró la forma. Fecha en que se elaboró la forma. Indica el tipo de actividad puede ser: Automática: Son todas aquellas tareas que realiza el sistema sin intervención humana, como puede ser: enviar un . Manual: Es un tarea donde interviene un humano para su realización. Se describe el funcionamiento de la actividad Indica el rol que ejecuta la actividad. Centro Nacional de Investigación y Desarrollo Tecnológico Página 74

81 Precondición Postcondición Describe las condiciones necesarias para dar comienzo con la actividad. Describe las condiciones que deben cumplirse al ser finalizada la actividad. 4.- Documento de Requerimientos Una vez que se tenga representado y detallado el o los procesos de negocios, es necesario ir analizando cada uno de los elementos y aplicar las acciones que se definieron en el reporte: definición de acciones de la metodología, para obtener los requerimientos necesarios para el desarrollo que se necesita Etapa 2: Análisis A) Objetivos Analizar los requerimientos obtenidos en la etapa 1. Identificar problemas en los requerimientos. Definir alternativas de solución para los requerimientos Detallar los requerimientos. B) Descripción En esta etapa es necesario realizar un análisis de los requerimientos obtenidos en la etapa 1, con la finalidad de identificar anomalías o problemas que puedan originarse en los requerimientos, para así definir alternativas para la solución de estos; a la vez también detallar más cada uno de los requerimientos que puedan ser abstractos. Para el desarrollo de esta etapa se definieron las siguientes actividades que se muestran en la siguiente figura Analizar los Requerimientos Detectar problemas en los requerimientos. Entrevista con Clientes Generar alternativas Aplicar alternativa seleccionada Documento de Requerimientos Detallados Detallar requerimientos Identificación de Problemas/Alternativas de Solución Figura 3-17 Etapa 2: Análisis Centro Nacional de Investigación y Desarrollo Tecnológico Página 75

82 En seguida la representación en BPMN de la etapa de análisis de la metodología. Figura 3-18 Diagrama Etapa 2: Análisis Para que puedan llevarse a cabo las actividades identificación de problemas y alternativas/solución y el de documento de requerimientos detallados, son importantes las entrevistas con todas las personas que participan en el proceso de negocio, por si llega a presentarse invariantes en los requerimientos obtenidos en la etapa anterior. Estas actividades se realizarán de manera colaborativa entre los participantes. Al finalizar esta etapa se tendrá una representación de la información de una manera más detallada teniendo un formato más técnico, lo cual permitirá reducir ambigüedades además de facilitar la definición del futuro diseño [Obprer98]. C) Actividades Las actividades son definidas de acuerdo a la representación de la etapa en la figura 3-17, para ver la definición de todas las actividades que integran la etapa de la representación de la figura 3-18 con BPMN consultar el anexo B. 1.- Identificación de Problemas y Alternativas de Solución En esta actividad es donde se verifica si los requerimientos que fueron identificados son los adecuados o es necesario refinarlos. Aquí es donde se descubren los problemas con los requerimientos del sistema, los cuales han sido identificados hasta el momento y se buscan alternativas de solución. Centro Nacional de Investigación y Desarrollo Tecnológico Página 76

83 Esta actividad no solo depende de que tan claros estén los requerimientos, si no también depende del buen juicio y experiencia que tenga el experto en cuando a la obtención y definición de los requerimientos. El experto deberá tener gran experiencia en analizar la información con cada uno de los participantes para verificar que los requerimientos sean claros no solamente para las personas usuarias expertas, sino también para el cliente. Para esta actividad de análisis se elaboró el siguiente formato, con fin de llevar un control sobre los requerimientos en donde se detectaron problemas: Tabla 3-35 Formato de Requerimientos Detectados con Problemas Requerimiento: Autor: Fecha: Alternativas: Solución: Tabla 3-36 Guía del Formato de Requerimientos Detectados con Problemas Guía del Formato de Requerimientos Detectados con Problemas Requerimiento Nombre del requerimiento detectado con problemas. Autor: Nombre de quien elaboró la forma. Fecha: Fecha en que se elaboró la forma. Alternativas: Descripción de alternativas para la solución del problema detectado. Solución: Descripción de la solución aplicada al requerimiento. 2.- Documento de Requerimientos Detallados Esta actividad puede ser considerada como opcional, ya que no necesariamente tendría que realizarse, todo dependerá de la actividad anterior (Identificación de problemas y alternativas de solución) de si se realiza o no, o dependerá del criterio de los participantes si se requiere detallar más los requerimientos. Una vez concluida la etapa 2, con la finalización de esta actividad, los requerimientos obtenidos y analizados serán documentados de manera apropiada para las personas a las cuales irán dirigidos, para ellos se utiliza el estándar 830 definido por la IEEE830. Centro Nacional de Investigación y Desarrollo Tecnológico Página 77

84 3.6.4 Etapa 3: Especificación de Requerimientos de Software A) Objetivos Obtener un documento de requerimientos de acuerdo al estándar IEEE830. B) Descripción Una especificación de requerimientos de software (SRS) es una descripción detallada del comportamiento del sistema que se requiere. Se compone de un conjunto de casos de usos que representan las interacciones que tienen los usuarios con el sistema. Asimismo el SRS contiene requerimientos no funcionales, los cuales especifican las restricciones que habrá en el diseño o implementación [IEEE830-9]. Para el caso de este trabajo de tesis el SRS sólo detallará los requerimientos funcionales. Para esta etapa sólo se realizará una actividad como se muestra en la siguiente figura: Elaborar Documento de Requerimientos con el estándar IEEE 830 Documento de Especificación de requerimientos Figura 3-19 Etapa 3: Especificación de Requerimientos En seguida la representación de la etapa de especificación de Requerimientos en BPMN. Figura 3-20 Diagrama Etapa 3: Especificación de Requerimientos La forma en que este documento se elabore afecta a la solución, ocasionando problemas en las etapas posteriores de desarrollo del ciclo de vida de la ingeniería de software. Centro Nacional de Investigación y Desarrollo Tecnológico Página 78

85 C) Actividades Las actividades son definidas de acuerdo a la representación de la etapa en la figura 3-19, para ver la definición de todas las actividades que integran la etapa de la representación de la figura 3-20 con BPMN consultar el anexo B. 1.- Elaborar el Documento de Requerimientos al estándar IEEE 830 Al realizar esta actividad si se detectan problemas con los requerimientos se debe regresar a una etapa anterior, de lo contrario la descripción de los requerimientos puede no ser la adecuada, como consecuencia llevará a una confusión en la etapa de diseño. La estructura que deberá contener el documento es el siguiente [IEEE-STD ]: 1. Introducción o 1.1. Propósito o 1.2 Alcance o 1.3 Definiciones, acrónimos y abreviaturas o 1.4 Referencias o 1.5 Revisiones 2. Descripción General o 2.1 Perspectiva del producto o 2.2 Funciones del producto o 2.3 Características de los usuarios o 2.4 Restricciones o 2.5 Dependencias 3. Especificaciones de requerimientos 3.1 Requisitos funcionales Requisito 1 Requisito 2.. Requisito n Tabla 3-37 Guía de Llenado del Documento de Especificación de Requerimientos de Software Guía de Llenado del Documento de Especificación de Requerimientos de Software Propósito Alcance Es una descripción breve, en dos o tres párrafos, a modo de prólogo. Se habla del documento en sí, no del producto software La razón de ser del documento. En la organización: mostrar organigrama sombreando el dpto. a atender. Respecto al producto: Módulos generales y sus módulos, Centro Nacional de Investigación y Desarrollo Tecnológico Página 79

86 puede ser una tabla, un esquema, un diagrama de contexto. Definiciones, acrónimos y abreviaturas Consiste en generar una lista de términos que pudieran tener una interpretación distinta a la real. Se sugiere describir por separado cada elemento y a modo de tabla. o Definiciones o Acrónimos o Abreviaturas Referencias Listado de las fuentes de información utilizadas para comprender en su totalidad el proceso a automatizar. o Libros o Páginas de internet o Entrevistados o Manuales o Software o Folletos o Listados/reportes Revisiones Es necesario llevar el control de revisiones o modificaciones que se realice en el documento, así como el nombre de quien realizó las ediciones en el documento. Perspectiva del producto Funciones del producto Características de los usuarios Restricciones Punto específico para detallar los factores (requerimientos) técnicos que intervienen en el buen desarrollo del producto software(no se considera este punto para el presente trabajo de tesis ya que solo se considera requerimientos funcionales): o Interfaz del sistema o Interfaz de usuario o Interfaz de hardware o Interfaz de software o Interfaz de comunicaciones o Interfaz de memoria o Operaciones o Requerimientos de adaptación Descripción a modo texto de las funciones de los procesos que forman parte del producto. Conviene manejar en texto o gráficamente las relaciones lógicas entre procesos. Educación Nivel de conocimientos Experiencia Conocimientos técnicos Se debe proporcionar una descripción general de Centro Nacional de Investigación y Desarrollo Tecnológico Página 80

87 Dependencias Especificación de requerimientos cualquier otro punto que limite las opciones de los diseñadores (no se considera este punto para el presente trabajo de tesis ya que solo se considera requerimientos funcionales):. Éstos incluyen: o las políticas reguladoras; o las limitaciones del Hardware; o las Interfaces a otras aplicaciones; o el funcionamiento Paralelo; o las funciones de la Auditoría; o las funciones de Control; o los requisitos de lenguaje; o los protocolos Señalados (por ejemplo, XON- XOFF, ACK-NACK); o los requisitos de Fiabilidad; o Credibilidad de la aplicación; o la Seguridad y consideraciones de seguridad. Se debe listar cada uno de los factores que afectan los requisitos declarados en el SRS. Estos factores no son las restricciones del diseño en el software pero son, más bien, cualquier cambio a ellos que pueda afectar los requisitos en el SRS. Se describe la funcionalidad del sistema o Req. funcionales: definen las acciones fundamentales que deben tener lugar en el software, aceptando y procesando las entradas, procesando y generando las salidas. Éstos generalmente se listan como "debe" declaraciones que empiezan con "El sistema debe." o Req. no funcionales: (No se consideran para dentro del documento del SRS en esta metodología). Los casos de uso a menudo define la mayoría de los requerimientos funcionales del sistema, por lo cual se utilizaran estos para representar los requerimientos. Centro Nacional de Investigación y Desarrollo Tecnológico Página 81

88 3.6.5 Etapa 4: Validación de Requerimientos A) Objetivos: Aplicar métrica de correctitud. Aplicar métrica de No ambigüedad. Aplicar Métrica de entendibilidad. B) Descripción: Para llevar a cabo esta etapa de validación de los requerimientos y ultima, deberán ser completadas las etapas anteriores, de manera que se tenga elaborado el documento de especificación de requerimientos. Para que una especificación de requerimientos tenga calidad y se considere correcta, debe contribuir al éxito del proyecto, a una creación rentable y a resolver las necesidades reales del usuario [DAV93]. Concretamente un documento de especificación de requerimientos de calidad debe contener los siguientes atributos: Tabla 3-38 Atributos de una SRS de calidad [DAV93] 1. No ambigua 2. Completa 3. Correcta 4. Entendible 5. Verificable 6. Consistente internamente 7. Consistente externamente 8. Realizable 9. Concisa 10. Con diseño independiente 11. Traceable 12. Modificable 13. Almacenable electrónicamente 14. Ejecutable/Interpretable 15. Documentada por importancia relativa 16. Documentada por estabilidad relativa 17. Documentada por versión 18. No redundante 19. Detallada 20. Precisa 21. Reutilizable 22. Trazada 23. Organizada 24. Referenciada En el presente trabajo de tesis hubo necesidad de delimitar a la selección de las métricas para validar que exista la funcionalidad que se muestra en el documento de especificación de requerimientos, en seguida se describirán en las actividades que integran esta última etapa de la metodología. A continuación se presenta la figura que muestra las actividades que integran la etapa 4 de validación de los requerimientos. Centro Nacional de Investigación y Desarrollo Tecnológico Página 82

89 Requerimientos entendibles Documento de Requerimientos Métrica de correctes Documento de Requerimientos Métrica de entendible Documento de Requerimientos Métrica de ambigüedad Requerimientos correctos Requerimientos No ambiguos Figura 3-21 Etapa 3: Validación de Requerimientos En seguida, la representación de la etapa 2 de validación de requerimientos de BPMN, se muestra en el flujo de secuencia de la realización de las actividades. Figura 3-22 Diagrama Etapa 4: Validación A la vez se asume que en todos los casos n r son todos los requerimientos, n r=requerimientos funcionales (n f) + requerimientos no funcionales (n nf), pero como en el presente trabajo de tesis solo se limita a los requerimientos funcionales, entonces n r = n f + 0. C) Actividades Las actividades son definidas de acuerdo a la representación de la etapa en la figura 3-21, para ver la definición de todas las actividades que integran la etapa en la representación de la figura 3-22 con BPMN consultar el anexo B. Las diferentes actividades solo describen la forma en que se aplicará la métrica en los requerimientos. Centro Nacional de Investigación y Desarrollo Tecnológico Página 83

90 1.- Requerimientos No Ambiguos Una SRS es no ambigua si y sólo si cada requerimiento sólo tiene una interpretación [IEEE-STD ]. Una manera de medir si una SRS es no ambigua es mediante [DAV93]: Q 1=n ui/n r Donde n ui es el número de requerimientos para los cuales todos los revisores dieron la misma interpretación [DAV93]. 2.- Requerimientos Correctos Una SRS es correcta si y sólo si cada requerimiento representa algo requerido del sistema [Dav93], cada requerimiento en la SRS contribuye a la satisfacción de alguna necesidad. La correctes se puede medir para cada requerimiento pero sería una especie de revisión previa, haciendo que el resultado siempre fuese correcto, por lo tanto se aplica una métrica más práctica [Alb07]: Q 3 = n C/(n C+n NV) = n C/n r Donde n C y n NV son los números de requerimientos correctos y no validados respectivamente y n C+n NV = n r [DAV93]. 3.- Requerimientos Entendibles Una SRS es entendible si todos los lectores de la SRS pueden comprender fácilmente el significado de todos los requerimientos con una mínima explicación [DAV93]. La responsabilidad de crear especificaciones comprensibles es de quién la escriba, el lector no tendrá porqué aprender algo. La entendibilidad depende mucho del lector de la especificación, pues para los clientes y usuarios es ideal utilizar lenguaje natural, para los desarrolladores los lenguajes formales serán lo óptimo; bajo este criterio, la métrica a utilizar es [DAV93]: Q 4 = n ur/n r Donde n ur es el número de requerimientos para los cuales todos los revisores entendieron [DAV93]. Centro Nacional de Investigación y Desarrollo Tecnológico Página 84

91 3.7 Conclusiones Capítulo 3 La metodología desarrollada en esté capitulo de este trabajo de tesis incorpora el conocimiento de procesos de negocios a fin de obtener un documento de especificación de requerimientos entendibles, correctos y sin ambigüedades, a través del uso de formatos y guías elaborados que serán utilizados en la diferentes etapas que integra la metodología. En el capítulo 4 se presentan los casos de prueba con los cuales fue experimentada la metodología presentada en esta tesis. Centro Nacional de Investigación y Desarrollo Tecnológico Página 85

92 CAPÍTULO 4 4 Pruebas La metodología planteada en este trabajo de tesis se probó aplicando MERSUTPN para la obtención del SRS que requiere el Instituto de Investigación. Las pruebas realizadas y los resultados obtenidos se definen dentro de este capítulo. 4.1 Descripción General de las pruebas El intención de las pruebas realizadas fue comprobar que la metodología pueda ser utilizada para elaborar un documento de especificación de requerimientos de software de acuerdo al Estándar IEEE 830 y que el resultado de ésta sea un documento de requerimientos que cumpla con las características de ser no ambiguos, correctos y entendibles. La primera de las pruebas se hizo utilizando la metodología desarrollada en la presente tesis de acuerdo a un estudio y análisis realizado a través del uso de la literatura acerca de los procesos de negocios. La segunda prueba fue llevada a cabo con la metodología elaborada por el Instituto de Investigación, que fue desarrollado de acuerdo a la experiencia de años de trabajo en el ámbito de procesos de negocios. En donde el objetivo de ambas metodologías es obtener como producto un documento de especificación de requerimientos, para cualquier sistema que se requiera desarrollar. Centro Nacional de Investigación y Desarrollo Tecnológico Página 86

93 4.2 Enfoque de las Pruebas Para determinar la calidad de los productos obtenidos en la pruebas, se utilizará como base el trabajo Identifying and Measuring Quality in a Software Requirements Specification [DAV93], donde se definen métricas para la calidad en la especificación de requerimientos tales como: No ambiguo, Correcto, Entendible. 4.3 Convención de nombres La convención de nombres utilizada en las pruebas es la siguiente: CP_01: Caso de prueba no.1 realizado con la metodología planteada en este trabajo. CP_02: Caso de prueba no.2 realizado con la metodología del Instituto de Investigación. M_01: Métrica no. 1, requerimientos no ambiguos. M_02: Métrica no. 2, requerimientos entendibles. M_03: Métrica no. 3, requerimientos correctos. 4.4 Especificaciones del Plan de Pruebas Los puntos a considerar en las pruebas son los siguientes: Medición de características de los requerimientos funcionales obtenidos en el SRS realizado con MERSUTPN. Medición de características de los requerimientos funcionales del documento de especificación efectuada con la Metodología del Instituto de Investigación. Características que se probarán Se aplicarán métricas (M_01, M_02, M_03) de cualidades de los requerimientos del SRS para el caso de prueba CP_01. Se aplicarán métricas (M_01, M_02, M_03) de cualidades de los requerimientos del documento de especificación para el caso de prueba CP_02. Características que no se probarán No se evaluará los requerimientos No funcionales para los casos de prueba CP_01 y CP_02. Centro Nacional de Investigación y Desarrollo Tecnológico Página 87

94 Nota: Aunque para el caso CP_02 para poder probar que cumple con las características de las métricas que se definen con anterioridad, se le aplicará las métricas que se describen en la cuarta etapa de la metodología MERSUTPN, a fin de de evaluar la calidad de los requerimientos obtenidos y determinar a través del análisis qué porcentajes de calidad obtuvo este caso de prueba con respecto al CP_ Casos de Pruebas Aplicadas a un Escenario Real Las pruebas se delimitaron a dos casos, con el propósito de extraer datos reales para un sistema que requiere un instituto de investigación, a fin de obtener los requerimientos de software para el desarrollo de un sistema que genere facturas de manera electrónica. Las pruebas se enfocaron a obtener un documento de especificación de requerimientos que sean correctos, entendibles y sin ambigüedades, para la generación de facturas electrónicas de acuerdo a lo estipulado en el Diario Oficial de la Federación, de la Secretaria de Hacienda y Crédito Público (SAT), en la primera Resolución de Modificaciones a la Resolución Miscelánea Fiscal 2010, dentro de su anexo 20 referidos a los Comprobantes Fiscales Digitales (CFD). Antes de describir los casos de pruebas hay que tener claro el concepto de facturación electrónica como sigue: La factura electrónica en México es la representación digital de un tipo de Comprobante Fiscal Digital (CFD) con validez fiscal, que utiliza los estándares definidos por el Anexo 20 en cuanto a forma y contenido, garantizando la integridad, autenticidad y no repudio del documento [SAT2011]: Integridad: Garantiza que la información contenida en el mensaje queda protegida y no puede ser manipulada o modificada, confirmando la no alteración de los datos de origen. Autenticidad: Permite verificar la identidad del emisor y el receptor del CFD. No repudio: El emisor que selle digitalmente un CFD no podrá negar la generación del comprobante. La facturación electrónica es un método que utiliza tecnología digital para generar y resguardar este tipo de comprobantes fiscales digitales. La Factura Electrónica es un documento que comprueba la realización de una transacción comercial entre un comprador y un vendedor, compromete entregar el bien o servicio y obliga a realizar el pago de acuerdo a lo que establece la factura emitida [EDIFACT10]. Para realizar las pruebas se implementó la técnica clásica de entrevistas para la elicitación de los requerimientos, para la especificación de requerimientos se utilizó la técnica de casos de uso. Se tuvo la participación de dos personas (clientes) las cuales fueron indispensables para la realización de caso de prueba realizada con la metodología que se presenta en este trabajo de tesis. Centro Nacional de Investigación y Desarrollo Tecnológico Página 88

95 En la sección 4.6 se presenta las pruebas llevadas a cabo con la metodología desarrollada con este trabajo de tesis y en la sección 4.7 los resultados obtenidos de las pruebas realizas con la metodología desarrollada por el Instituto de Investigación. 4.6 Metodología de la Tesis (Procedimiento) Antes dar inicio con la descripción del CP_01, la siguiente figura muestra las etapas de la metodología que se probó, así como las actividades que contempla cada una de estas. Obtención Análisis Especificación Validación Panorama Objetivos Proceso de Negocio Requerimientos preliminares Problemas Alternativas/Sol ución Requerimientos detallados Elaborar los requerimientos con el Estándar IEEE 830 Pruebas Requerimientos Correctos Entendibles Sin Ambigüedades Figura 4-1 MERSUTPN A continuación se definen cada una de las etapas implementadas a fin de obtener un documento de especificación de requerimientos para el sistema de facturación electrónica que se requiere Etapa 1: Obtención de Requerimientos A.- Panorama General del Sistema La empresa requiere de un sistema que genere facturas con el propósito de administrar la información de los registros contables, así como la reducción de errores en la generación, captura, entrega y el almacenamiento de las facturas. Para generar facturas electrónicas, de acuerdo al diario oficial de la federación, dentro de su anexo 20 de Resolución de Misceláneas Fiscal del Comprobante Fiscal Digital, los criterios que deberán de cumplir son de acuerdo a lo estipulado en las secciones I a la I y de la II a la II del comprobante fiscal digital. Previamente al generar cualquier comprobante fiscal digital, es necesario elaborar una orden de facturación electrónica para llevar un control, revisión y autorización de la información de los diferentes participantes, a fin de disminuir errores que pudieran suscitarse en la factura electrónica. Centro Nacional de Investigación y Desarrollo Tecnológico Página 89

96 B.- Objetivos Tabla 4-1 Objetivo 1 Objetivo: Expedir facturas para obtener ingresos al realizar el cobro a los clientes. Autor: Lucia Morales Morales Fecha: 30/Mayo/2011 Descripción: Importancia: Alta Comentarios Adicionales: Se deberá de generar las facturas digitales para llevar un control de las facturas que se expiden en un determinado periodo, también para llevar el registro de las facturas que se generaron de manera correcta y las facturas que fueron canceladas al tener errores en su información. Tabla 4-2 Objetivo 2 Objetivo: Crear órdenes de facturación, para llevar un control de comprobantes interno de la organización. Autor: Lucia Morales Morales Fecha: 30/Mayo/2011 Descripción: Importancia: Alta Comentarios Adicionales: Respaldo y validez de la información que integra la factura, por lo que surge la necesidad de crear previamente a está ordenes de facturación a fin de que quede evidencia de las personas que participaron en la aprobación de la información correspondiente a la factura Para la organización es importante llevar un control de las personas participantes para la evaluación previa a la generación de la factura. C.- Proceso de negocio Esta actividad que forma parte de la primera etapa de la metodología, no se llevo a cabo en su totalidad, ya que el proceso de negocio para la facturación electrónica fue proporcionado por el Instituto de Investigación a fin de utilizarla como base para el desarrollo de la metodología de este trabajo de tesis. Lo que sí se realizó en esta actividad fue detallar aún más el proceso y posteriormente elaborar el modelo del proceso de negocio utilizando BizAgi Process Model, que es una herramienta de modelado bajo el Centro Nacional de Investigación y Desarrollo Tecnológico Página 90

97 estándar de BPMN; ya que el modelo de negocio del Instituto de Investigación fue modelado en Power Point de Microsoft office. A continuación se inicia con una breve descripción del modelo a manera de conocer algunas definiciones y abreviaturas que serán utilizadas en el modelo. Tabla 4-3 Definiciones y Abreviaturas Concepto Abreviatura Definición Factura Orden de Facturación Contrato de ingresos Cuentas por cobrar F OF CI CXC Es un documento utilizado para hacer cuenta y relación detallada de mercancías o servicios vendidos. Solicitud electrónica en el Sistema de Información de la organización para facturar un servicio Acto jurídico mediante el cual se crean, modifican, transfieren o extinguen obligaciones. Contrato de ingresos se celebra entre las autoridades principales de los clientes de las empresas con la organización, en donde las partes declaran su intención de establecer relaciones de carácter general sobre los aspectos de comunicación, planeación, organización, ejecución y control de los trabajos de la organización. Las cuentas por cobrar establecen el crédito que la empresa otorga a sus clientes, como resultado de la entrega de productos o servicios Tabla 4-4 Descripción de Rol Asistente Persona Actual a Cargo: Rol: Asistente Autor: Lucia Morales Morales Fecha: 30/Mayo/2011 Descripción: Comentarios: Persona 1 Se encarga de registrar las órdenes de facturación en el sistema, así como enviar la documentación a soporte de las mismas al área de ingresos, una vez que son aprobadas. Centro Nacional de Investigación y Desarrollo Tecnológico Página 91

98 Tabla 4-5 Descripción de Rol Jefe de Asistente Rol: Jefe de Asistente Autor: Lucia Morales Morales Fecha: 30/Mayo/2011 Persona Actual a Cargo: Descripción: Persona 2 Es el encargado de revisar, aprobar, solicitar cambios y cancelar las órdenes de facturación. Comentarios: Tabla 4-6 Descripción de Rol Departamento de Ingresos Rol: Departamento de ingresos Autor: Lucia Morales Morales Fecha: 30/Mayo/2011 Persona Actual a Cargo: Descripción: Persona 3 Se encarga de registrar las facturas dentro del sistema, así como hacer el registro contable de las mismas. Comentarios: Tabla 4-7 Descripción de Rol Jefe del Departamento de Ingresos Rol: Departamento de ingresos Autor: Lucia Morales Morales Fecha: 30/Mayo/2011 Persona Actual a Cargo: Persona 4 Descripción: Se encarga de aprobar las facturas. Comentarios: Centro Nacional de Investigación y Desarrollo Tecnológico Página 92

99 Tabla 4-8 Descripción de Rol Tesorero Rol: Departamento de ingresos Autor: Lucia Morales Morales Fecha: 30/Mayo/2011 Persona Actual a Cargo: Persona 5 Descripción: Se encarga de aprobar las facturas y enviarlas al cliente Comentarios: Tabla 4-9 Descripción Transacción de Negocio Facturación Electronica Transacción de Negocio Descripción Entradas Salidas Roles Restricciones Documentos Actividades (Operaciones del negocio) Proveer factura electrónica El proceso de facturación consiste en crear y autorizar las facturas, con los cuales el Instituto de Investigación puede obtener ingresos mediante los servicios que les ofrece a sus clientes. Contrato de ingresos autorizado. Factura Aprobada. Asistente, Jefe del asistente, departamento de ingresos, jefe departamento de ingresos. Sólo se podrán crear facturas de proyectos. Orden de facturación autorizada, factura electrónica. Seleccionar líneas del programa de pagos, crear OF, enviar aprobación OF, revisar y validar la OF, cancelar OF, solicitar modificación, modificar OF, Aprobar OF y enviar documentación soporte a CXC, Recibir documentación soporte, validar documentación soporte y OF, cancelar OF, solicitar modificación, generar factura y completar información, enviar factura a aprobación, revisar y validar factura, cancelar factura, solicitar modificación de factura, modificar factura, aprobar factura, imprimir factura, generar registro contable, firmar factura, firmar factura. Centro Nacional de Investigación y Desarrollo Tecnológico Página 93

100 Figura 4-2 Descripción de Actividades: Facturación Electrónica Centro Nacional de Investigación y Desarrollo Tecnológico Página 94

101 Tabla 4-10 Descripción de Actividades: Facturación Electrónica Autor: Lucia Morales Morales Fecha: 09/Jun/2011 Proceso de Negocio: Facturación Electrónica Actividad Tipo Descripción Rol Precondición Poscondición Seleccionar líneas del programa de pagos Crear ordenes de facturación Enviar aprobación orden de facturación Automática Automática Automática La persona que registra la orden de facturación selecciona un contrato y una o varias líneas del programa de pagos de acuerdo a lo que va a cobrar. Una vez seleccionadas las líneas del programa de pago, se completa la información adicional de la orden de facturación. El asistente envía la orden de facturación a su jefe asistente. Asistente Asistente Asistente Contrato de ingresos autorizado. Líneas de pago seleccionas. Orden capturada, OF en estado de modificación. Líneas de pago seleccionas. Orden capturada. OF en estado en revisión. Revisar y validar la orden de facturación Automática El jefe asistente compara la orden de facturación con la documentación soporte. Jefe asistente OF en estado en revisión OF revisada Cancelar OF Automática Si el jefe asistente determina que la orden de facturación no es válida cancela la orden Solicitar modificación Automática Si el jefe asistente detecta algún error en la OF, solicita a su asistente la corrija. Jefe asistente OF revisada. OF cancelada Jefe asistente Orden de facturación revisada. OF en estado modificación Modificar OF Automática El asistente recibe un correo con las Asistente OF en estado OF modificada Centro Nacional de Investigación y Desarrollo Tecnológico Página 95

102 modificaciones que le solicita su jefe asistente y realiza las modificaciones a la OF. Aprobar OF Automática Si el jefe asistente no detecta errores, aprueba la OF. modificación Jefe asistente OF revisada. OF aprobada Enviar documentación soporte a CXC Recibir soporte documentación Validar documentación soporte y OF Manual Una vez que el asistente recibe el correo de aprobación de su orden de facturación, envía la documentación soporte al área de CXC. Manual El departamento ingresos recibe la documentación soporte de la OF. Automática El auxiliar revisa la orden de facturación contra la documentación soporte. asistente OF aprobada Documentación enviada Departamento ingresos Departamento ingresos OF aprobada y documentación enviada Documentación recibida Documentación recibida OF Revisada Cancelar OF Automática Si el auxiliar determina que la orden de facturación no es válida cancela la orden. Departamento ingresos OF Revisada OF Cancelada Solicitar modificación Automática Si el auxiliar detecta algún error en la OF, solicita a su asistente la corrija. Departamento ingresos OF Revisada OF en modificación Generar factura y completar información Automática Si el auxiliar no detecta errores, crea la factura y completa la información contable necesaria Departamento ingresos OF Revisada Factura creada Enviar factura aprobación Automática Una vez registrada la factura se envía al Jefe departamento ingresos para su revisión Departamento ingresos Factura creada, Factura modificada Factura en estado en revisión Recibe notificación de aprobación pendiente Manual El departamento ingresos recibe la notificación de aprobación pendiente. Jefe departamento de ingresos Factura generada y enviada a Notificación recibida Centro Nacional de Investigación y Desarrollo Tecnológico Página 96

103 aprobación Revisar y validar factura Automática El jefe del departamento de ingresos revisa la factura y la documentación soporte. Jefe departamento ingresos Factura en estado En revisión Factura revisada Cancelar factura Automática Si el jefe del departamento de ingresos determina que la factura no es válida puede cancelarla. Jefe departamento ingresos Factura revisada. Factura cancelada Solicitar modificación de factura Automática Si el jefe depto. Ingresos detecta algún error en la factura, solicita al auxiliar de facturación que la corrija. Jefe departamento ingresos Factura revisada. Factura en estado modificación Modificar factura Automática El auxiliar de facturación recibe un correo con las modificaciones que le solicita su jefe asistente y realiza las modificaciones a la factura. Departamento ingresos Factura en estado modificación Factura modificada Aprobar factura Automática Si el jefe departamento ingresos no detecta errores, aprueba la OF. Jefe departamento ingresos Factura revisada. Factura aprobada Generar registro contable Automática Se crean las entradas contables en el diario del sistema de ingresos. Departamento ingresos Factura aprobada Registro contable generado Generar electrónica factura Automática Una vez aprobada la factura y generado el registro contable, se genera la factura. Departamento ingresos Factura aprobada Factura generada Cancelar contable registro Automática Se cancela el registro contable cuando existen errores. Departamento ingresos Registro contable en revisión Registro contable cancelado Corregir información Automática Se corrige los errores encontrados en el registro. Departamento Registro Registro Centro Nacional de Investigación y Desarrollo Tecnológico Página 97

104 ingresos contable cancelado contable corregido. Revisar registro contable Manual Revisa que no haya inconsistencias dentro del registro contable. Departamento ingresos Registro contable y factura generado Registro contable revisado Revisar registro contable Manual Revisa que no haya inconsistencias dentro del registro contable. Jefe departamento ingresos Registro contable y factura generado Registro contable revisado. Revisar registro contable Manual Revisa que no haya inconsistencias dentro del registro contable. Tesorero Registro contable y factura generado Registro contable revisado Cerrar factura Automática Si se encontraron errores en el registro contable y no pueden ser corregidos, se cierra la factura. Departamento ingresos Registro contable en revisión Factura Cerrada Centro Nacional de Investigación y Desarrollo Tecnológico Página 98

105 Una vez que se ha definido y detallado el modelo del proceso de negocio para la facturación electrónica, se procedió implementar los formatos y guías diseñados para el proceso de negocio, y es como tendremos nuestro primer documento preliminar de requerimientos. Recordemos que los formatos se aplican para cada una de las actividades y patrones detectados en el proceso de negocio. Los resultados, aplicando los formatos, se presentan a continuación: Tabla 4-11 Formato de la Actividad Seleccionar líneas del programa de pagos Actividad: Seleccionar líneas del programa de pagos Criterio de Éxito: Autor: Lucia Morales Morales Fecha: 09/Jun/2011 Una vez contemplando las precondiciones y poscondiciones que deberá contener esta actividad se requiere lo siguiente: Se debe de seleccionar el programa de pagos, el cual se refiere a cuando se registra un contrato de ingresos, es necesario registrar el programa (calendario) de pagos para determinar en qué fechas se van a pagar los servicios que el Instituto de Investigación realiza al cliente. o La información que requerida es: o Fecha en que se cobrará o Importe que se cobrará o Concepto que se cobrará Nota: Ya sea un avance del proyecto o una fecha pactada en el contrato, etc. Criterio Alterno: No aplica, es necesaria toda la información del criterio de éxito. Criterio de Fracaso: Debe existir una línea de pagos con la información correspondiente al programa de pagos de acuerdo al contrato de ingresos. Si no existe el programa no puede continuar el flujo para la generación de la factura. Centro Nacional de Investigación y Desarrollo Tecnológico Página 99

106 Tabla 4-12 Formato de la Actividad Crear Ordenes de Facturación Actividad: Crear ordenes de facturación Criterio de Éxito: Criterio Alterno: Autor: Lucia Morales Morales Fecha: 09/Jun/2011 Criterio de Fracaso: Para generar un orden de facturación se deberá existir previamente una línea de pagos programadas para poder realizar las ordenes de facturación de acuerdo a lo que hay en el programa. La orden de la facturación se crea del contrato de ingresos, con lo datos que se describieron en la actividad anterior de acuerdo al diagrama mostrado en la figura y se complementa con datos que el usuario introduce. Los datos del orden de facturación necesarias son: o Datos del cliente (Identificador, nombre, dirección) o Datos del proyecto (Identificador, nombre, subprograma) o Del contrato de ingresos (numero de contrato interno y externo, fecha) o Fecha en que se hará el cobro o Importe que se cobrará o Concepto por el cual se realiza el cobro Nota: Para el concepto de cobro puede ser un avance del proyecto o una fecha pactada en el contrato, etc., los cobros son de acuerdo al contrato. Para generar un orden de facturación se deberá haber seleccionado un programa de pagos preliminarmente, además deberá contener la siguiente información mínima para poder crearla. Si no se ha seleccionado un programa de pagos de ninguna manera podrá generarse una orden de facturación. Tabla 4-13 Formato de la Actividad Enviar Aprobación OF Actividad: Enviar aprobación orden de facturación Criterio de Éxito: Autor: Lucia Morales Morales Fecha: 16/Jun/2011 Criterio Alterno: No Aplica Criterio de Fracaso: El asistente envía la orden de facturación a su jefe asistente, dentro de la fecha correspondiente. Que el asistente no envié la orden de facturación a su jefe antes de cumplirse la fecha programada de pago. Centro Nacional de Investigación y Desarrollo Tecnológico Página 100

107 Tabla 4-14 Formato de la Actividad Revisar y Validar la OF Actividad: Revisar y validar la orden de facturación Autor: Lucia Morales Morales Fecha: 16/Jun/2011 Condición: Estado 1: Estado 2: Estado 3: Criterio de Éxito: Criterio Alterno: Criterio de Fracaso: El jefe asistente compara la orden de facturación con la documentación soporte, para verificar que exista la información que se expone en las actividades de seleccionar línea del programa de pagos y el de crear ordenes de facturación. Si la información cumple con lo expuesto en la condición, se lleva a cabo la actividad de Aprobar la orden de facturación. Si la información es incorrecta, con lo que se requiere contenga la orden de facturación, se lleva a cabo la actividad de Solicitar modificación de la orden de facturación. Si la información no cumple con lo que necesita y se determina que la orden de facturación no es válida, se lleva a cabo la actividad de Cancelar Orden de facturación. Para que esta actividad sea exitosa deberá cumplir lo descrito en el estado 1. No Aplica Si no existe la información requerida de las actividades de seleccionar línea del programa de pagos y el de crear ordenes de facturación. Tabla 4-15 Formato de la Actividad Cancelar OF Actividad: Cancelar OF Autor: Lucia Morales Morales Fecha: 16/Jun/2011 Criterio de Éxito: Se realiza la cancelación correspondiente ya que la orden no es válida y termina el proceso de facturación electrónica. Criterio Alterno: No Aplica ya que proviene de una actividad de selección exclusiva. Criterio de Fracaso: No Aplica ya que proviene de una actividad de selección exclusiva. Centro Nacional de Investigación y Desarrollo Tecnológico Página 101

108 Tabla 4-16 Formato de la Actividad Solicitar Modificación Actividad: Solicitar modificación Criterio de Éxito: Autor: Lucia Morales Morales Fecha: 16/Jun/2011 Si el encargado de realizar esta tarea detecta algún error en la OF, solicita a la persona correspondiente haga las correcciones necesarias. Criterio Alterno: No Aplica ya que proviene de una actividad de selección exclusiva. Criterio de Fracaso: No Aplica ya que proviene de una actividad de selección exclusiva. Tabla 4-17 Formato de la Actividad Modificar OF Actividad: Modificar OF Criterio de Éxito: Autor: Lucia Morales Morales Fecha: 20/Jun/2011 El asistente recibe notificación con las modificaciones necesarias solicitadas de su jefe asistente y realiza las modificaciones a la OF. Criterio Alterno: No Aplica ya que debe realizar la modificaciones que fue solicitada.. Criterio de Fracaso: No realiza la modificaciones que le fue solicitada, en el tiempo establecido de manera preliminar en el programa de pagos. Tabla 4-18 Formato de la Actividad Aprobar OF Actividad: Aprobar OF Autor: Lucia Morales Morales Fecha: 20/Jun/2011 Criterio de Éxito: Si la orden de facturación cuenta con toda la información necesaria descrita con anterioridad, entonces se realiza la aprobación de la orden. Criterio Alterno: No Aplica ya que proviene de una actividad de selección exclusiva. Criterio de Fracaso: No Aplica ya que proviene de una actividad de selección exclusiva. Centro Nacional de Investigación y Desarrollo Tecnológico Página 102

109 Tabla 4-19 Formato de la Actividad Enviar Documentación a Soporte a CXC Actividad: Enviar documentación soporte a CXC Autor: Lucia Morales Morales Fecha: 24/Jun/2011 Criterio de Éxito: Lo único que se debe realizar es recibir la notificación de aprobación de su orden de facturación, y posteriormente enviar la documentación soporte al área de cuentas por cobrar. Documentación que envía es la siguiente: Copia de contrato de ingresos Orden de facturación Reporte de actividades Criterio Alterno: No Aplica o envía o no envía notificación con la documentación. Criterio de Fracaso: Al no enviar la notificación en el tiempo establecido y la documentación correspondiente esta actividad no puede ser completada. Tabla 4-20 Formato de la Actividad Recibir Documentación de Soporte Actividad: Recibir documentación soporte Autor: Lucia Morales Morales Fecha: 24/Jun/2011 Criterio de Éxito: Esta actividad se cumple de manera satisfactoria si el departamento ingresos recibe la documentación soporte de la orden de facturación correspondiente. Criterio Alterno: No Aplica o recibe o no recibe documentación de la orden de facturación. Criterio de Fracaso: Si no se recibe documentación esta actividad no puede ser realizada. Tabla 4-21 Formato de la Actividad Validar Documentación de Soporte y OF Actividad: Validar documentación soporte y OF Autor: Lucia Morales Morales Fecha: 24/Jun/2011 Condición: La persona encargada de esta actividad revisa la orden de facturación contra la documentación soporte. La información debe estar respaldada por los documentos que se mencionan a continuación: Copia de contrato de ingresos Orden de facturación Centro Nacional de Investigación y Desarrollo Tecnológico Página 103

110 Estado 1: Estado 2: Estado 3: Criterio de Éxito: Criterio de Fracaso: Reporte de actividades La información esencial que deberá contener son: Datos del cliente (Identificador, nombre, dirección) Datos del proyecto (Identificador, nombre, subprograma) Del contrato de ingresos (número de contrato interno y externo, fecha) Si la información cumple con lo expuesto en la condición, se lleva a cabo la actividad de Generar factura y completar información. Si la información es incorrecta con lo que se requiere contenga la orden de facturación, se lleva a cabo la actividad de Solicitar modificación de la orden de facturación. Si la información no cumple con lo que necesita y se determina que la orden de facturación no es válida, se lleva a cabo la actividad de Cancelar Orden de facturación. Para que esta actividad sea exitosa deberá de cumplir lo descrito en el estado 1. Si no existe la información requerida de las actividades de seleccionar línea del programa de pagos y el de crear ordenes de facturación. Tabla 4-22 Formato de la Actividad Generar Factura y Completar Información Actividad: Generar factura y completar información Criterio de Éxito: Autor: Lucia Morales Morales Fecha: 31/Jun/2011 Una vez que se haya aprobado la orden de facturación se complementa la información que contenga esta a fin de tener la información como son: Datos de Verificación o Registro Federal de Contribuyentes. o Número de Serie del Certificado de Sello Digital. o Número de Aprobación. o Folio del Comprobante Fiscal Digital. o Serie del Comprobante Fiscal Digital. (Opcional) Protección de Datos o Cadena Original compuesta por los datos fiscales mínimos requeridos, incluyendo los Datos de Verificación. o Sello Digital (PKI) que vincula la identidad del emisor con el contenido del Comprobante Fiscal Digital. Otros datos: o Lugar y fecha de expedición o RFC de la persona a favor de quien se expida o Cantidad y clase de mercancía y descripción del servicio Centro Nacional de Investigación y Desarrollo Tecnológico Página 104

111 o o Criterio Alterno: No aplica. Criterio de Fracaso: Valor unitario en número o importe total en número o letra Impuestos que deben trasladarse desglosadas por la tasa de impuesto. Nota: Ver anexo para ejemplo de una factura con los datos correspondientes. Si no existe algún dato descrito en el criterio de éxito no se puede llevar a cabo esta actividad. Tabla 4-23 Formato de la Actividad Enviar Factura a Aprobación Actividad: Enviar factura aprobación Autor: Lucia Morales Morales Fecha: 31/Jun/2011 Criterio de Éxito: Al haber registrado la factura se envía al Jefe departamento ingresos para su revisión. Criterio Alterno: No Aplica. Criterio de Fracaso: Si no se envía al jefe del departamento de ingresos la factura esta actividad no podrá cumplirse. Tabla 4-24 Formato de la Actividad Recibe Notificación de Aprobación Pendiente Actividad: Recibe notificación de aprobación pendiente Autor: Lucia Morales Morales Fecha: 31/Jun/2011 Criterio de Éxito: Si recibió la notificación con la factura correspondiente se continúa con la actividad de Revisar y Validar Factura. Criterio Alterno: No Aplica Criterio de Fracaso: Si no existe notificación con la factura no se realiza la actividad. Centro Nacional de Investigación y Desarrollo Tecnológico Página 105

112 Tabla 4-25 Formato de la Actividad Revisar y Validar Factura Actividad: Revisar y validar factura Autor: Lucia Morales Morales Fecha: 31/Jun/2011 Condición: Estado 1: Estado 2: Estado 3: Criterio de Éxito: Criterio de Fracaso: La persona encargada de esta actividad revisa la factura cumpla con la información establecida en la actividad de Generar factura. Si la información cumple con lo expuesto en la condición, se lleva a cabo la actividad de Aprobar Factura. Si la información es incorrecta con lo que se requiere contenga la factura, se lleva a cabo la actividad de Solicitar modificación de la factura. Si la información no cumple con lo que se requiere contenga la factura, se lleva a cabo la actividad de Cancelar factura. Para que esta actividad sea exitosa deberá de cumplir lo descrito en el estado 1. Si no se recibió la notificación previa con la factura correspondiente, no se puede ejecutar esta actividad. Tabla 4-26 Formato de la Actividad Cancelar Factura Actividad: Cancelar factura Autor: Lucia Morales Morales Fecha: 31/Jun/2011 Criterio de Éxito: Si la persona encargada de esta actividad del departamento ingresos determina que la factura no es válida procede a realizar la cancelación correspondiente y termina el proceso de facturación electrónica. Criterio Alterno: No Aplica Criterio de Fracaso: No Aplica ya que proviene de una actividad de selección exclusiva. Tabla 4-27 Formato de la Actividad Solicitar Modificación Factura Actividad: Solicitar modificación de factura Autor: Lucia Morales Morales Fecha: 31/Jun/2011 Criterio de Éxito: Si la persona encargada de esta actividad del departamento ingresos detecta algún error en la factura, solicita al auxiliar de facturación que realice las correcciones que sean necesarias. Criterio Alterno: No Aplica Centro Nacional de Investigación y Desarrollo Tecnológico Página 106

113 Criterio de Fracaso: No Aplica ya que proviene de una actividad de selección exclusiva. Tabla 4-28 Formato de la Actividad Modificar Factura Actividad: Modificar factura Criterio de Éxito: Autor: Lucia Morales Morales Fecha: 31/Jun/2011 Criterio Alterno: No Aplica Criterio de Fracaso: La persona responsable de esta actividad recibe la notificación con las modificaciones que le solicita el jefe asistente, y procede a realizar las correcciones requeridas a la factura. Si no recibe notificación con las modificaciones que se requieren, no se realiza la actividad. Tabla 4-29 Formato de la Actividad Aprobar Factura Actividad: Aprobar factura Autor: Lucia Morales Morales Fecha: 31/Jun/2011 Criterio de Éxito: Si el encargado de esta tarea no detecta errores, procede a aprobar la Factura. Criterio Alterno: No Aplica ya que proviene de una actividad de selección exclusiva. Criterio de Fracaso: No Aplica ya que proviene de una actividad de selección exclusiva. Tabla 4-30 Formato de la Actividad Generar Registro Contable Actividad: Generar registro contable Criterio de Éxito: Criterio Alterno: Autor: Lucia Morales Morales Fecha: 07/Jul/2011 Criterio de Fracaso: Para está actividad es necesario seleccionar que facturas se van a generar para realizar el registro en contabilidad. No Aplica es necesario seleccionar al menos una factura para esta actividad. De no seleccionarse alguna factura no se puede proceder a generar un registro contable y por consecuencia esta actividad no puede completarse. Centro Nacional de Investigación y Desarrollo Tecnológico Página 107

114 Tabla 4-31 Formato de la Actividad Generar Factura Electrónica Actividad: Generar factura electrónica Criterio de Éxito: Autor: Lucia Morales Morales Fecha: 07/Jul/2011 Criterio Alterno: No Aplica Esta actividad depende de la anterior, debido a que es importante haber generado el registro contable, para proceder a generar la factura con toda la información que esta requiere para dar cumplimiento a este criterio. Criterio de Fracaso: Para realizar esta actividad la factura deberá de estar aprobada. Tabla 4-32 Formato de la Actividad Revisar Registro Contable Actividad: Revisar registro contable Autor: Lucia Morales Morales Fecha: 07/Jul/2011 Condición: Estado 1: Estado 2: Criterio de Éxito: Criterio de Fracaso: La persona encargada de esta actividad revisa que la factura cumpla con la información establecida en la actividad Generar Registro Contable. (Esta actividad la realizan los diferentes participantes (ver diagrama del proceso de facturación) que deberán validar que sea correcto,) Si la información cumple con lo expuesto en la condición, se lleva a cabo la actividad de Revisar Registro contable. Si la información es incorrecta con lo que se requiere contenga la factura, se lleva a cabo la actividad de Cancelar Registro Contable. Para que esta actividad sea exitosa deberá de cumplir lo descrito en el estado 1. Si no existe registro contable no se realiza la actividad. Tabla 4-33 Formato de la Actividad Cancelar Registro Contable Actividad: Cancelar registro contable Autor: Lucia Morales Morales Fecha: 07/Jul/2011 Criterio de Éxito: Criterio Alterno: Si la persona o la persona encargada de esta actividad determina que el registro no es válido, procede a realizar la cancelación correspondiente y se realiza la actividad de Corregir información. No Aplica ya que proviene de una actividad de selección exclusiva. Criterio de Fracaso: No Aplica ya que proviene de una actividad de selección exclusiva. Centro Nacional de Investigación y Desarrollo Tecnológico Página 108

115 Tabla 4-34 Formato de la Actividad Corregir Información Actividad: Corregir información Criterio de Éxito: Autor: Lucia Morales Morales Fecha: 07/Jul/2011 Criterio Alterno: No Aplica. La persona responsable de esta actividad realiza las correcciones pertinentes solicitadas del registro contable. Criterio de Fracaso: Si el registro contable no está cancelado no se realiza la actividad. Tabla 4-35 Formato de la Actividad Cerrar Factura Actividad: Cerrar factura Criterio de Éxito: Autor: Lucia Morales Morales Fecha: 07/Jul/2011 Criterio Alterno: No Aplica Criterio de Fracaso: Si el encargado de esta actividad encontró errores en el registro contable y no pueden ser corregidos, se procede al cierre de la factura, y por ende se finaliza el proceso de facturación electrónica. Si no se realizó una revisión previa del registro contable, no puede concluirse esta actividad Etapa 2: Análisis de Requerimientos A través de entrevistas y en conjunto con los clientes dentro de esta etapa, se realizó un análisis general de los requerimientos obtenidos en la primera etapa, aplicando la metodología de este trabajo de tesis, al fin de identificar anomalías o problemas en los requerimientos y dar solución a los problemas encontrados. Dentro de los requerimientos que se encontraron erróneos o faltantes se presentan los siguientes formatos con la descripción de tales errores. Centro Nacional de Investigación y Desarrollo Tecnológico Página 109

116 Tabla 4-36 Formato de Requerimientos Detectados con Problemas Requerimiento: Generar factura y completar información Autor: Lucia Morales Morales Fecha: 18/Jul/2011 Alternativas: Solución: En este requerimiento se agregó información que corresponde a otro requerimiento, por lo que no hay necesidad de la generación de alternativas, solo agregar información en el requerimiento Registro Contable. De acuerdo al modelo del procesos de negocios, primero se aprueba la factura, para posteriormente generar el o los registros contables, por lo que para llevar a cabo esta tarea es necesaria la siguiente información: Datos: Folio, Certificado, No. Aprobación, Serie, datos de la factura Protección de Datos o Cadena Original compuesta por los datos fiscales mínimos requeridos, incluyendo los Datos de Verificación. o Sello Digital (PKI) que vincula la identidad del emisor con el contenido del Comprobante Fiscal Digital. Nota: La protección de datos se realiza a través del algoritmo SH1 que exige el Secretaria de Administración Pública Etapa 3: Especificación de Requerimientos de Software A partir de la realización de las dos primeras etapas correspondientes a la metodología, se elaboró el documento de especificación de requerimientos de software (SRS, Software Requirements Specification) de acuerdo al estándar de la IEEE 830, en donde se presenta a través de diagramas de casos de uso y plantillas, una descripción detallada de los requerimientos funcionales necesarios para el sistema que se requiere desarrollar. En donde los casos de usos representan las interacciones que tienen los usuarios con el sistema. Para definir los casos de uso, a partir del proceso de negocio, se utilizó en el trabajo Patrones para la Extracción de Casos de Uso [Berrocal09]. En este artículo se propone una serie de patrones que permiten identificar los casos de uso del sistema a partir de los procesos de negocio. A continuación sólo se define la estructura del contenido el documento SRS obtenido: Centro Nacional de Investigación y Desarrollo Tecnológico Página 110

117 Figura 4-3 Estructura del Documento de Especificación de Requerimientos de Software Etapa 4: Validación de Requerimientos Para que una especificación de requerimientos tenga calidad y se considere correcta, ésta debe contribuir al éxito del proyecto, a una creación rentable y a resolver las necesidades reales del usuario [DAV93]. Para evaluar cada una de las métricas de especificación obtenidas con la metodología de este trabajo de tesis, se necesitó la colaboración de revisores, para lo que se recurrió al desarrollador y a la vez se utilizó la versión final del documento de especificación de la factura electrónica en su versión 2.0. Se evaluó la calidad de los requerimientos de acuerdo a [DAV93], del documento de especificación de requerimientos de software, tales como las métricas de: No ambigüedad, entendibilidad y correctitud (3.4.5). Centro Nacional de Investigación y Desarrollo Tecnológico Página 111

118 Tabla 4-37 Resultados de las Métricas del CP_01 Métricas: CP_01 No ambigüedad Entendibilidad Correctitud Metodología del Instituto de Investigación Este caso de prueba lo llevo a cabo propiamente el Instituto de Investigación, aplicando su propia metodología para obtener requerimientos, considerando los procesos de negocios para tal circunstancia, con el cual tuvieron como resultado un documento de especificación para la facturación electrónica. Por cuestión de confidencialidad solo se muestran los resultados obtenidos al aplicar las métricas de acuerdo a [DAV93], para la evaluación de su documento de especificación de requerimientos, para la evaluación se consideró la versión 1.0 del documento. Tabla 4-38 Resultados de las Métricas del CP_02 Métricas: CP_02 No ambigüedad Entendibilidad Correctitud Conclusiones de las Pruebas La diferencia del resultado no ambigüedad, en la especificaciones de requerimientos del CP_02 es de 0.59 % sobre el CP_01 de los requerimientos obtenidos en ambas pruebas, ya que el usuario del sistema conoce el dominio de los requerimientos reales, por lo que se deduce que dentro del caso de la metodología de este trabajo de tesis el usuario no difiere en la interpretación de algunos conceptos que generen ambigüedad en su interpretación. La diferencia del resultado de la entendibilidad en el CP_02 es 5.13 % superior al CP_01, de manera general ambas especificaciones fueron respectivamente entendibles, más sin embargo, la diferencia se debe a que la descripción del requerimiento fue más concreta en la especificación realizada con la MERSUTPN. Centro Nacional de Investigación y Desarrollo Tecnológico Página 112

119 No Ambigüedad Correctitud Entendibilidad Metodología para la Elicitación de Requerimientos de Software Utilizando Transacciones del Proceso de Respecto a la calidad de correctitud para el CP_02 y en CP_01 los resultados de las pruebas difieren en un 9.28% ya que para el caso de prueba 1 resultaron incorrectos algunas especificaciones en su minoría. Los indicadores, como se puede observar en la gráfica de la figura 4-3, de los factores evaluados, el indicador de conocimiento en los resultados obtenidos en los casos de prueba se puede deducir que la diferencia que existe entre estos es debido en primera instancia a que la metodología que se desarrolló en este trabajo de tesis fue en base a la teoría acerca de los procesos de negocios estudiados, a lo investigado y analizado en la literatura, además de que faltó la realización de más pruebas con la metodología. Por otra parte vemos que los resultados satisfactorios se obtuvieron con la metodología desarrollada en el Instituto de Investigación, esto es debió a los años de experiencia en el ámbito de los procesos de negocios, así como el estar trabajando continuamente aplicando la metodología en sus diferentes proyectos. Resultados CP_01 CP_02 Figura 4-3 Grafica de Factores Evaluados en los Casos de Prueba Los resultados obtenidos de las pruebas son producto de un estudio basado en las transacciones y los patrones de modelado, obteniendo de estas una descripción detallada de cada una de las actividades, así como de las condiciones que son requeridas para estas se realicen y pueda concretarse el objetivo del proceso de negocio con cada una de las transacciones o negociaciones que se llevan a cabo con los diferentes roles participantes, los cuales permitieron definir la metodología que fue aplicada a un caso real, a través del uso de guías y formatos dentro de las cuatro etapas de integran la metodología. Centro Nacional de Investigación y Desarrollo Tecnológico Página 113

120 4.9 Conclusiones Capítulo 4 Dentro de este capítulo se presentaron los casos de prueba realizados, así como los resultados obtenidos de aplicar la metodología de este trabajo de tesis. Los resultados obtenidos realza la importancia de haber aplicado las pruebas sobre un escenario real, ya que se determina que es necesario seguir realizando pruebas para tener una mejor evaluación de la metodología desarrollada, debido a que el resultado del caso de prueba con la metodología del Instituto de Investigación fue mejor de la obtenida con la metodología desarrollada en este trabajo de tesis. En el capítulo 5 se presentan las conclusiones generales que se obtuvieron del presente del trabajo de tesis. Centro Nacional de Investigación y Desarrollo Tecnológico Página 114

121 CAPÍTULO 5 5 Conclusiones 5.1 Conclusiones Generales La metodología desarrollada en esté trabajo de tesis resulta factible ya que incorpora el conocimiento de procesos de negocios, a fin de obtener un documento de especificación de requerimientos de software bajo el estándar IEEE 830, en donde los requerimientos cumplen cualidades entendibles, correctos y sin ambigüedades. Por otra parte aunque podemos apreciar en las pruebas, que los resultados más satisfactorios se obtuvieron con la metodología del Instituto de Investigación, esto es debido a que si comparamos la forma en que se desarrolló cada una de estas metodologías, vemos que la presentada en este trabajo fue a partir de la investigación y análisis acerca de los procesos de negocios de acuerdo a la literatura; en cambio la metodología del instituto de investigación fue desarrollada en base a la experiencia de años en el ámbito de los procesos de negocios y al desarrollo de proyectos de software, así como el tiempo y experiencia de trabajar con la metodología desarrollada por ellos; ambas metodologías tienen en común los procesos de negocios para la obtención de un documento de especificación de requerimientos de software. A pesar que de los resultados obtenidos muestra la factibilidad del desarrollo de la tesis, es necesario seguir realizando pruebas para comprobar aun más los resultados que se obtienen al utilizar está metodología. Las pruebas que se realizaron fueron aplicadas sobre un escenario real de un Instituto de Investigación que da importancia a los resultados obtenidos con la metodología, esto fue beneficioso para poner a prueba la metodología propuesta y comparándola con una ampliamente utilizada por ellos. La metodología desarrollada consideró como base las transacciones del proceso de negocio para la facturación electrónica, misma que fue formalizada para poder utilizarla Centro Nacional de Investigación y Desarrollo Tecnológico Página 115

122 como base. Es importante mencionar que el contar con un proceso de negocio real es beneficioso, ya que el contar con procesos desarrollados de manera industrial permite revisar más directamente las características que deben contener tales procesos y como a partir de estos pueden obtenerse requerimientos de software de manera detallada. 5.2 Trabajos Futuros Esta metodología incorpora procesos de negocios para la obtención de un documento de especificación de requerimientos de software, con lo que se marca la importancia en la primera etapa del ciclo vida de desarrollo de software y a medida que se obtengan resultados satisfactorios, se garantiza minimizar errores en las etapas posteriores a esta. Por lo tanto, los trabajos futuros se recomiendan los siguientes: Realizar más pruebas utilizando la metodologia. Evaluar los resultados de las pruebas realizadas aplicadas a diferentes procesos de negocios para la extraccion de requerimientos detallados. Incorporar mejoras a la metodologia analizando cada uno de los diferentes patrones de modelamiento de los procesos de negocios para elaborar guias y formatos más especializados. Centro Nacional de Investigación y Desarrollo Tecnológico Página 116

123 Referencias [ALBO07] [ARIAS05] [BOCAN08] [BizAgi11] [CABR02] [CAMA05] [CLON03] [DAV93] Albores Villatoro, Luz Maria. Definición e Implementación de un Perfil UML para la Adquisición de Requerimientos Funcionales Centrados en el Usuario.Tesís de Maestría en Ciencias de la Computación, CENIDET. Cuernavaca, Morelos, Michael, Arias Chávez. La Ingeniería de Requerimientos y su Importancia en Desarrollo de Proyectos de Software. Revista Intercedes, Universidad de Costa Rica Vol.6, 2005, ISSN: Bocanegra, J., J. Pena, y A. Ruiz. Una Aproximación MDA para Modelar Transacciones de Negocio Nivel CIM. Actas de los Talleres de las Jornadas de Ingeniería de Software y Bases de Datos Vol. 2, No. 3, 2008, ISSN BizAgi Process Modeler, Patrones de modelamiento BPMN, Fuente: consultado en febrero 2011 Cabrera Santiago, Nubia. Ambiente de Modelado y Documentación de Sistemas de Software Utilizando Diagramas de Casos de Uso, Tesís de Maestría en Ciencias de la Computación, CENIDET. Cuernavaca, Morelos, Antonio Nicolás Camacho Zambrano. Herramienta para el Análisis de Requerimientos dentro de la Pequeña Empresa Desarrolladora de Software en Bogotá. Proyecto de grado de ingenieria de sistemas, Pontificia Universidad Javeriana, Bogota, Susan C. Cloninger. Teorias de la Personalidad. 3ra. Edición. PEARSON Prentice Hall, 2003, ISBN: DAVIS, A. Identifying and Measuring Quality in a Software Requirements Specification. Proc. 1 st Intl. Software Metrics Centro Nacional de Investigación y Desarrollo Tecnológico Página 117

124 Symposium, IEEE, Baltimore, MD. Mayo [DAVENPORT93] Davenport, Thomas (1993) - Process Innovation, Harvard Business School Press, USA, [EDIFACT10] Edifact MX, Facturación electrónica, Fuente: Consultado en enero [ESC02] Escalona M.J., Koch N. Ingeniería de Requerimientos en Aplicaciones para la Web:Un estudio comparativo Universidad de Sevilla, España - Universidad de Munich, Alemania, Fuente: [GANESH08] Sai Ganesh. Ingenieria de Requerimientos: Tecnicas de Elicitación.Tesís de Maestría, Ingenieria de software, Departamento de de Tecnologia, Matematicas y Ciencias de la Computación, University West. Trollhättan, Sweden, Suecia, [GAO10] [GONZ06] [HAMMER90] Gao, Juntao Yuan, Man Huang, Gan Wang, Zhiyao. ERP software requirement elicitation with reference models. IEEE, 2010, ISBN: Gónzalez Garcia, Moises. Método de Desarrollo Arquitéctonico en Grupo. Tessis de Doctorado, Centro De Investigaciones Y Estudios Avanzados Del Instituto Politécnico Nacional. Hammer, M. (1990) Re-engineering Work: Don t Automate, Obliterate, Harvard Business Review, pp , July-August. [HERNANDEZ11] Hernández Estrada, Adán Definición de Elementos de Transformación entre Diagramas de Casos de Uso y Clases del UML, Tesís de Maestría en Ciencias de la Computación, CENIDET. Cuernavaca, Morelos, [JIM03] [KRUT93] [LEON09] Jiménez Q., Claudia, Lorena Farías V., Francisco Pinto, y Liliana Neriz J. Análisis de Modelos de Procesos de Negocios en Relación a la Dimensión Informática. Revista Ingeniería Informática, No. 9, 2003, ISSN: Krut, Jr. Robert W., Technical Rep CMU/SEI-93-TR-11, Integrating 001 Tool Support into, the Feature-Oriented Domain Analysis Methodology, Instituto de Ingeniería de Software, Universidad Carnegie Mellon, Mayo León L., Oyuky María, y Julio Armando Asato E. La Importancia del Modelado de Procesos de Negocio como Herramienta para la Mejora e Innovación. Revista Panorama Administrativo, nº No [Loucopoulos95] P. Loucopoulos and V. Karakostas: Software Requirements Centro Nacional de Investigación y Desarrollo Tecnológico Página 118

125 Engineering, McGraw-Hill, [OMG08] [OUYANG08] [PEÑA06] [PHKTT03] [PRESS02] [QADEEM10] [QUEL09] [REMO09] [ROBERTSON06] [RPS00] [SAT11] [SAMPIERI06] Object Management Group, Inc. Business Process Model and Notation, V1.1, Remco M. Dijkman, Marlon Dumas, Chun Ouyang, Formal Semantics and Analysis of BPMN Process Models using Petri Nets, Journal Information and Software Technology, Vol. 50,Butterworth- Heinemann Newton, Massachusetts, USA, Alejandro Peña Ayala, Tecnologías de la Información: Su alineamiento al Negocio de las Organizaciones, INSTITUTO POLITÉCNICO NACIONAL, 1ra.Edicion, Mexico, ISBN: X Päivi Parviainen, Hanna Hulkko, Jukka Kääriäinen,Juha Takalo & Maarit Tihinen. Requirements engineering, Inventory of technologies, VTT Publications 508, 2003, ISBN Pressman, Roger S. Ingeniería de Software, un Enfoque Práctico. 5ta. Edición. Mc Graw Hill, 2002, ISBN: MR. Shams-ul-arif, MR. Qadeem khan, S. A. K. Gahyyur. Requirements Engineering Processes, Tools/Technologies, & Methodologies. International Journal Of Reviews In Computing , ISSN: Quelopana, R., Z. Vela, y A. Gallardo. Una Propuesta para Modelar Procesos de Negocio de Decisión como Técnica de Elicitación de Requisitos para Sistemas de Bussiness Intelligence. Departamento de Ingeniería de Sistemas y Computación, Universidad Católica del Norte. Antofagasta, Remo C. de Boer, Hans Van Vliet. Writing and Reading Software Documentation: How Process may Affect Understanding. IEEE, 2009, ISBN: Suzanne Robertson, James Robertson: Mastering the requirements process. Addison Wesley, Andrés F. Rodríguez M., José A. Pineda M. y Ricardo Sánchez O., Sistemas de planificación de recursos empresariales: un caso real, Boletín IIE, Aplicaciones Tecnológicas, Secretaria de Administracion Tributaria, Comprobantes Fiscales Digitales, Fuente: antes/comprobantes_fiscales/66_16599.html, HERNANDEZ, Sampieri Roberto, Metodología de la investigación, Centro Nacional de Investigación y Desarrollo Tecnológico Página 119

126 Graw Hill, [SHAH09] [SOMM09] [STD ] [STD ] Shahidi, Sheyda, y Zarihah Mohn Kasirun. Using Etnography Techniques in developing a mobile tool for requirements elicitation. International Conference on Information Management and Engineering. Kuala Lumpur, Malaysia, IEEE, 2009, ISBN: Sommerville, Ian. Ingeniería de Software. 7ma. Edición. PEARSON Addison Wesley, 2005, ISBN: Standard Standard Glossary of Software Engineering Terminology. IEEE, 1990, ISBN: X. IEEE Standard 830, Software Requirements Specifications, IEEE, [STANDISH09] Standish, Group. The Chaos Report, Boston, Massachusetts, [WHITE04] Stephen A white, Process Modelling Notations and Workflow patterns, Fuente: %20White.pdf, Centro Nacional de Investigación y Desarrollo Tecnológico Página 120

127 Anexos Anexo A: Formalización del Proceso de Negocio para la Facturación Electrónica Para poder utilizar como base el proceso de negocio que plantea este trabajo de tesis fue necesario demostrarlo de manera semántica formal, de tal manera que la metodología para la elicitación de requerimientos tenga una base formal, para esto se utilizo el trabajo de [Ouyang08], que menciona la Semántica Formal de un proceso de BPMN. La demostración del proceso de negocio para la facturación electrónica que es utilizada como base en la metodología de este trabajo de tesis, se presenta con una semántica formal del proceso usando las definiciones anteriores. Estas definiciones son aplicadas al proceso de negocio planteado en esta tesis. La siguiente tabla muestra las abreviaturas utilizadas para la formalización de cada uno de los elementos que integra el proceso para la facturación electrónica. Tabla Anexo A-1 Descripción de Elementos Utilizados en la Formalización del PN Nombre Tipo Abreviatura CI autorizado y creado Evento de Inicio es 1 M Evento de Intermedio ei 1 O Evento de Intermedio ei 2 A Evento de Intermedio ei 3 B Evento de Intermedio ei 4 C Evento de Intermedio ei 5 Centro Nacional de Investigación y Desarrollo Tecnológico Página 121

128 Nombre Tipo Abreviatura D Evento de Intermedio ei 6 E Evento de Intermedio ei 7 OF Cancelada (jefe de asistente) OF Cancelada (departamento de ingresos) OF Cancelada (jefe departamento de ingresos) Evento de fin ef 1 Evento de fin ef 2 Evento de fin ef 3 Factura cerrada Evento de fin ef 4 Factura electrónica generada enviada al cliente Evento de Fin ef 5 Seleccionar líneas del Actividad a 1 programa de pagos Crear ordenes de facturación Actividad a 2 Enviar a aprobación OF Actividad a 3 Revisar y validar OF Actividad a 4 Cancelar OF Actividad a 5 Solicitar modificación Actividad a 6 Modificar OF Actividad a 7 Aprobar OF Actividad a 8 Enviar documentación Actividad a 9 soporte a CXC Recibir documentación Actividad a 10 soporte Validar documentación Actividad a 11 soporte y OF Cancelar OF Actividad a 12 Solicitar modificación Actividad a 13 Generar factura y completar Actividad a 14 información Enviar factura aprobación Actividad a 15 Recibe notificación de a 16 aprobación pendiente Revisar y validar factura Actividad a 17 Cancelar factura Actividad a 18 Solicitar modificación de Actividad a 19 factura Modificar factura Actividad a 20 Aprobar factura Actividad a 21 Generar factura electrónica Actividad a 22 Generar registro contable Actividad a 23 Cancelar registro contable Actividad a 24 Centro Nacional de Investigación y Desarrollo Tecnológico Página 122

129 Nombre Tipo Abreviatura (departamento de ingresos, jefe departamento de ingresos, tesorero) Corregir información Actividad a 25 Revisar registro contable (departamento de ingresos) Revisar registro contable(jefe departamento de ingresos) Revisar registro contable (tesorero) Cerrar factura (departamento de ingresos, tesorero) Orden de facturación correcta? (jefe de asistente) Orden de facturación correcta? (departamento de ingreso) Registro contable (departamento de ingreso) Factura correcta Registro contable (jefe departamento de ingreso) Registro contable (tesorero) Actividad a 26 Actividad a 27 Actividad a 28 Actividad a 29 Compuerta de decisión XOR basada en datos Compuerta de decisión XOR basada en datos Compuerta de decisión XOR basada en datos Compuerta de decisión XOR basada en datos Compuerta de decisión XOR basada en datos Compuerta de decisión XOR basada en datos A continuación la tabla muestra las abreviaturas utilizadas en la formalización de proceso de negocio para la facturación electrónica: Tabla Anexo A-2 Abreviaturas en la Formalización PN Abreviatura Descripción O Conjunto de objetos (A, E, G) A Conjunto de actividades E Conjunto de eventos (inicio, intermedios, fin ) G Conjunto de compuertas G X Compuerta de decisión XOR basado en datos {e S } Conjunto de eventos de inicio E I Conjunto de eventos intermedios {e E } Conjunto de eventos de fin S Conjunto de actividades que invocan los subprocesos Q Conjunto de todos los procesos C conjunto de todas las posibles condiciones g 1 g 2 g 3 g 4 g 5 g 6 Centro Nacional de Investigación y Desarrollo Tecnológico Página 123

130 Formalización definición 1 (Proceso del núcleo de BPMN) o A = {a 1, a 2, a 3, a 4,, a n} o E = {{e S }, E I, {e E }} o G X ={ g 1, g 2, g 3, g 4, g 5 } o G = {G X } o {e S } = {es 1} o E I = { ei 1, ei 2, ei 3, ei 4, ei 5, ei 6 } o {e E } = { ef, ef 2, ef 3, ef 4, ef 5, ef 6 } o O = {A, E, G} Definido los conjuntos se tiene lo siguiente: Para representar la relación del control de flujo (F O O) tenemos lo siguiente, recordemos que un objeto puede ser cualquier actividad, evento o compuerta que integra el proceso para la facturación electrónica, por lo que tenemos: F OxO se obtiene {(es 1, a 1), (a 1, a 2), (a 2, a 3), (a 3, a 4), (a 4, g 1), (g 1, a 6), (g 1, a 5), (g 1, a 8), (a 6, a 7), (a 5, ef 1), (a 8, a 9), (a 9, ei 2), (ei 1, a 7), (ei 2, a 10), (a 10, a 11), (a 11, g 2), (g 2, a 13), (g 2, a 13), (g 2, a 12), (g 2, a 14), (a 13, ei 1), (a 14, a 15), (a 15, ei 3), (ei 4, a 15), (ei 3, a 16), (a 16, a 17), (a 17, g 4), (g 4, a 19), (g 4, a 19), (g 4, a 18), (g 4, a 21), (a 18, ef 3), (a 19, ei 4), (a 21, ei 5), (ei 5, a 23), (a 23, a 22), (a 22, a 26), (a 26, g 3), (g 3, ei 6), (ei 6, a 24), (a 24, a 25), (a 25, a 23), (g 3, a 27), (a 27, g 5), (g 5, ei 6), (g 5, ei 7), (ei 7, a 29), (a 29, ef 4), (g 5, a 28), (a 28, g 6), (g 6, ei 6), (g 6, ei 7), (g 6, ef 5)} Para Cond: F G x x O C se obtiene: {(G 1, A 6), (G 1, A 5), (G 1, A 8), (G 2, A 12), (G 2, A 14), (G 2, A 13), (G 3, A 26), (G 3, A 27), (G 3, EI 6), (G 4, A 21), (G 4, A 19), (G 4, A 18), (G 5, A 28), (G 5, EI 6), (G 5, EI 7), (G 6, A 23), (G 6, EF 5), (G 6, EI 8), (G 6, EI 7)} Excp: Si E I A, esta propiedad no se cumple debido a que un evento intermedio no implica A de tal manera que ocurra una señal de excepción que interrumpa la ejecución de la actividad dentro del proceso de negocio planteado en esté trabajo de tesis, ya que todos elementos de los eventos intermedios son del tipo enlace que conecta con otra actividad con el fin de evitar flujos de control muy largos. Formalización definición 2 (Modelo del núcleo de BPMN) Con base a la definición 2 se formaliza lo siguiente: Q = {P} S = map: S Q se asume que no existe una función inyectiva ya que es necesario tener al menos un subproceso dentro del proceso de negocio para que se de esta propiedad. Centro Nacional de Investigación y Desarrollo Tecnológico Página 124

131 HR = {(P 1, P 2) Q Q SεSP1 map(s) = P 2} se asume que no existe un grafo conexo ya que solo existe un proceso de negocio y para que puede ser un grafo conexo es necesario que se cumpla la propiedad anterior. F M ( P Q (T P E P E E P IM ) P Q (T P E P S E P IM )) \ P Q(O P O P), para que esta propiedad se cumpla es necesario que al igual que la propiedad anterior exista más un elemento para el conjunto Q, para que exista el flujo de mensajes entre los procesos. Para la segunda definición se asume que no se cumplen las propiedades de la definición, por lo cual se puede concluir que debido a que es necesario que dentro de un proceso de negocio exista al menos un conjunto de actividades invocadas en el subproceso; aunque de acuerdo a lo estudiado sobre el tema de procesos de negocios para que un proceso exista no es necesario que integre subprocesos, siempre y cuando integre los elementos básicos de BPMN. Formalización definición 3 (Proceso del núcleo BPMN bien formado) Con base a la definición 2 se asume que la formalización de la definición 1 está bien formada para el proceso de negocio para la facturación electrónica P ya que satisface lo siguiente: s E S dom(excp), in(s) = out(s) = 1, e E E, out(e) = in(e) = 1, x A (EI \dom(excp)), in(x ) = 1 and out(x ) = 1 g G F G X G V : in(g) = 1 out(g) > 1, g G J GM, out(g) = 1 in(g) > 1, g G V, out(g) E IM E IT T R, g G X, un orden < g que es un orden estricto total sobre el conjunto de flujos{g} out(g), y x out(g) tal que f {g} out(g)((g, x )<g f ), es decir, (g, x ) es el flujo por defecto en todos los flujos salientes de g, x O, s E S dom(excp), e E E, s F x xf e. Formalización definición 4 (Modelo del núcleo BPMN bien formado) Y con base a definición 4, un núcleo de modelo BPMN M, es bien formado, si cumple la definición 2, y Q es un conjunto de procesos de núcleo BPMN bien formados y la relación HR es un DAG. De acuerdo a las formalizaciones realizadas de cada una de las definiciones anteriores descritos en el trabajo de [Ouyang08], se asume que no se cumple con las definiciones 2 y 4 para el modelo del núcleo de BPMN, que solo se cumple la definición 1 y 2 que son del proceso del núcleo BPMN. Por lo que para lo que se necesita y de acuerdo al proceso de facturación es más que suficiente que cumpla con las definiciones que integran el proceso, aún cuando no cumpla con las definiciones que integran el modelo. Ya que el proceso de negocio para la facturación electrónica dentro de sus Centro Nacional de Investigación y Desarrollo Tecnológico Página 125

132 elementos de acuerdo el BPMN, los subprocesos no forman parte dentro del proceso planteado en este trabajo de tesis. Por lo anterior se concluye que el proceso de negocio contiene una semántica formal, por lo que sí es factible de utilizarlo como base de la metodología para la elicitación de requerimientos de software utilizando el proceso de negocio. Centro Nacional de Investigación y Desarrollo Tecnológico Página 126

133 Anexo B: Descripción de Actividades de la Metodología Representada con BPMN Tabla Anexo B-3 Descripción de Actividades de la Metodología Representada con BPMN Actividad Tipo Descripción de la actividad Rol Precondiciones Postcondiciones Etapa de elicitación Revisar que se hayan realiza las actividades de la etapa Etapa de análisis Revisar documento de requerimientos Etapa de Especificación de requerimientos Manual En junta de entrevista entre los participantes (cliente y experto (analista)) obtienen los requerimientos que se requieren para el desarrollo del sistema, a través de la relación de un conjunto de actividades. Manual Manual Manual Manual El analista revisa que se hayan realizado y completado las actividades correspondientes a la etapa de elicitación. Los participantes revisan que se que no haya problemas en los requerimientos obtenidos en la etapa de elicitación. Los participantes revisan que se hayan revisado los todos los requerimientos y no presenten problemas. Los analistas elaboran el documento de requerimientos en base al estándar IEEE 830. Cliente y Analista Analista Cliente y Analista Cliente y Analista Analista Programar una reunión entre los participantes. Requerimientos preliminares Requerimientos preliminares y Etapa de elicitación concluida Requerimientos sin problemas y detallados Documento de requerimientos preliminares Requerimientos preliminares Actividad de etapa de elicitación aceptada y finalizada. Requerimientos sin problemas y detallados Requerimientos revisados y sin problemas Documento de Especificación de requerimientos Revisar que el docto. de especificación de requerimientos Manual Los analistas revisan que estén registrados todos los requerimientos de acuerdo al estándar. Analista Documento de Especificación de requerimientos Documento de Especificación de requerimientos revisado Centro Nacional de Investigación y Desarrollo Tecnológico Página 127

134 Tabla Anexo B-4 Descripción del Subproceso Etapa de Elicitación de la Metodologia Actividad Tipo Descripción de la actividad Rol Precondiciones Postcondiciones Analizar la información Elaborar el panorama general del proyecto Manual Los analistas realizan un análisis de la información en la entrevista con los clientes, para conocer el sistema que se requiere desarrollar. Manual Una vez conocida y analizada la información en la entrevista con los clientes se elabora el panorama general del proyecto para el sistema que se necesita. Definir objetivos Manual Los participantes una vez elaborado el panorama del proyecto realiza un análisis detallado para determinar los objetivos que deberán cumplirse con el sistema que de requiere. Proceso de negocio Revisar proceso de negocio Aplicar Acciones Elaborar docto. de req. Manual Manual Manual Una vez definido los objetivos, se realiza el el proceso de negocio a fin de conocer los pasos en se deberán ejecutar las actividades de acuerdo a los objetivos. Los participantes deberán de revisar el proceso para ver que están integradas las actividades que se necesitan para que se cumpla un determinado objetivo. Teniendo el proceso se tendrá que aplicar las determinadas acciones a fin de extraer los requerimientos. Manual Se deberá elaborar un documento preliminar con las los datos obtenidos en las actividades anteriores a esta. Analista Programar una reunión entre los participantes. Información Analizada Analista Información analizada Panorama general del proyecto Clientes y Analista Clientes y Analista Clientes y Analista Clientes y Analista Analista Panorama general del proyecto Objetivos Diagrama del proceso de negocio y descripción de actividades que se utilizan en el proceso. Proceso de negocio aceptado por el cliente. Acciones aplicadas, objetivos y panorama general del proyecto. Objetivos Diagrama del proceso de negocio y descripción de actividades que se utilizan en el proceso. Proceso de negocio revisado y aceptado por el cliente. Acciones aplicadas y realizadas. Documento de requerimientos preliminar Centro Nacional de Investigación y Desarrollo Tecnológico Página 128

135 Tabla Anexo B-2 Descripción del Subproceso Proceso de Negocios de la Etapa de Elicitación de la Metodología Actividad Tipo Descripción de la actividad Rol Precondiciones Postcondiciones Analizar la información Manual El analista con ayuda de los participantes realizan un análisis de actividad a de conjunto de actividades que se llevaran para resolver el problema y cumplir los objetivos definidos. Analista y Cliente Panorama general y objetivos definidos Información analizada Obtener Transacción de Negocio Manual En base al objetivo se determina la transacción de manera textual de lo que se necesita para llevar a cabo el proceso de negocio. Analista y Cliente Información analizada Descripción de la transacción o transacciones de negocio. Definir Roles Manual Realizar una descripción detallada de los roles que intervienen para que el proceso se lleve a cabo. Analista y Cliente Transacción de negocio definida Roles especificados Elaborar Diagrama BPMN Manual El analista elabora el proceso de negocio y con ayuda del cliente determinan el flujo en que las actividades incluidas en el proceso deberán desarrollarse. Analista y Cliente Transacción de negocio definida Diagrama del proceso de negocio elaborado Describir Actividades Manual Los participantes en colaboración realizan una descripción de las actividades, incluyendo en cada una el rol que es reponsable. Analista y Cliente Diagrama del proceso de negocio elaborado Actividades detalladas Revisar proceso Manual El analista presenta el proceso y la descripción de las actividades, para que el cliente revise que está conforme a lo realizado. Analista y Cliente Diagrama del proceso de negocio elaborado y descripción de actividades Proceso de negocio aceptado. Centro Nacional de Investigación y Desarrollo Tecnológico Página 129

136 Tabla Anexo B-5 Descripción del Subproceso Etapa de Análisis de la Metodología Actividad Tipo Descripción de la actividad Rol Precondiciones Postcondiciones Identificar problemas en el docto. de req. Elaborar Alternativas Manual Manual En esta actividad es en donde se identifica si los requerimientos que fueron registrados son los adecuados o es necesario refinarlos. Elaborar alternativas de solución para los problemas identificados. Analista Documento de requerimientos preliminares. Analista Problemas identificados. Problemas identificados en los requerimientos. Lista de alternativas de solución a los problemas Seleccionar Alternativas Implementar alternativas para solución Manual Manual Seleccionar las alternativas de solución en para los problemas en los requerimientos. Aplicar alternativas para solucionar los problemas. Analista Analista Lista de alternativas de solución a los problemas Alternativas seleccionadas Alternativas seleccionadas Docto. de requerimientos sin problemas. Revisar que no existan problemas Manual Se vuelve a realizar una revisión para verificar que no existan más problemas en los requerimientos. Analista Docto. de requerimientos sin problemas. Docto. de requerimientos sin problemas revisados Detallar docto. de req. Manual Es se considera necesario se realiza una descripción detallada para el documento de requerimientos. Analista Docto. de requerimientos sin problemas revisados Docto. de requerimientos detallados Centro Nacional de Investigación y Desarrollo Tecnológico Página 130

137 Tabla Anexo B-6 Descripción del Subproceso Etapa de Especificación de Requerimientos de la Metodología Actividad Tipo Descripción de la actividad Rol Precondiciones Postcondiciones Analizar documento de requerimientos Elaborar el docto. de req. con el estándar IEEE 830. Manual Manual Se realiza un análisis del documento de requerimientos para poder ir verificando y considerando como se va a pasar al estándar IEEE 830. Se elabora el documento de requerimientos de acuerdo al estándar IEEE 830. Analista Documento preliminar de requerimientos y etapa de análisis completada. Documento analizado Analista Documento analizado Documento de Requerimientos bajo el estándar IEEE 830 Revisar documento Manual Se revisa que el documento elaborado cumpla con el estándar. Analista Documento de Requerimientos bajo el estándar IEEE 830 Documento de requerimientos revisado y aceptado con de acuerdo al estándar. Centro Nacional de Investigación y Desarrollo Tecnológico Página 131

138 Tabla Anexo B-7 Descripción del Subproceso Etapa de Validación de Requerimientos de la Metodología Actividad Tipo Descripción de la actividad Rol Precondiciones Postcondiciones Analizar docto. de especificación de requerimientos Manual Se revisa el documento para aplicar las métricas en los requerimientos registrados. Analista Documento de especificación de requerimientos. Iniciar las actividades de implementación de las métricas. Aplicar métrica de correctes Manual Aplica la métrica de correctitud en los requerimientos. Analista Documento de especificación de requerimientos. Resultados de correctitud de los requerimientos Aplicar métrica de entendimiento Manual Aplica la métrica de entendibilidad en los requerimientos. Analista Documento de especificación de requerimientos. Resultados de entendibilidad de los requerimientos Aplicar métrica de No ambigüedad Manual Aplica la métrica de no ambigüedad en los requerimientos. Analista Documento de especificación de requerimientos. Resultados de no ambigüedad de los requerimientos Revisar que todos los req. fueron validados Manual Realiza una revisión que todas las métricas fueron implementadas. Analista Documento de especificación de requerimientos. Todos los requerimientos aceptados. Centro Nacional de Investigación y Desarrollo Tecnológico Página 132

139 Anexo C: Modelado de Proceso de Negocio con BizAgi Process Modeler El Modelador de Procesos BizAgi es la herramienta de gestión de procesos más ágil y fácil de utilizar disponible en el mercado. Con su apariencia única y el "intelisense behavior" se puede diagramar procesos rápidamente sin esperar la rutina de validación al final de cada diagrama. La herramienta puedes ser descargada en A continuación elaboraremos un diagrama incluyendo los elementos básicos de BPMN con los siguientes pasos. Paso 1: Ejecutar la Aplicación de BizAgi. a) Menú Inicio BizAgi Process Modeler Figura Anexo C-1 Pantalla de Selección de la Herramienta BizAgi b) Clic sobre la aplicación y Abrirá la siguiente ventana en donde se muestra el ambiente grafico de BizAgi. Centro Nacional de Investigación y Desarrollo Tecnológico Página 133

140 Figura Anexo C-2 Pantalla Ambiente Grafico BizAgi La siguiente tabla describe algunas de las partes que integra la herramienta. Elemento A B C D Descripción Representa los elementos que integra BPMN definidos en la tabla. Seleccionar para crear un nuevo documento o nuevo diagrama para representar el proceso de negocio. Seleccionar validar una vez concluido el diagrama. Nota: Validar le ayudará a verificar que el diagrama este bien elaborado de acuerdo BPMN, más aún cuando apenas se inicia con BPMN. Seleccionar para guardar la imagen (proporcione los datos que necesite) Pasó 2: Elaborar el diagrama Seleccionar Nuevo Diagrama y abrirá un nuevo diagrama como aprecia en la pantalla siguiente: Centro Nacional de Investigación y Desarrollo Tecnológico Página 134

141 Figura Anexo C-3 Pantalla Nuevo Diagrama Para el caso del ejemplo realizara un diagrama de registrar un producto, en el cual se llevaran a cabo las siguientes actividades. Registrar información Aprobar Solicitud Cancelar Solicitud Notificar Aceptación Una vez definida las actividades comenzamos a modelarlo con BPMN. c) Primero seleccionamos el elemento de Evento de Inicio y lo arrastramos hacia el bloque o Pool que lleva por nombre Proceso 1. d) Después posicionamos el cursor sobre el Evento de Inicio y veremos algunos de los elementos con el que puede seguir el flujo de secuencia para ir representado el proceso, como se muestra en la siguiente pantalla. Centro Nacional de Investigación y Desarrollo Tecnológico Página 135

142 Figura Anexo C-4 Pantalla Evento de Inicio del Diagrama e) Posteriormente seleccionamos el elemento con que se seguirá la secuencia en que se ejecutaran las actividades para que se lleve a cabo el proceso se muestra en la siguiente. Figura Anexo C-5 Pantalla Continuación de Representación del Diagrama Centro Nacional de Investigación y Desarrollo Tecnológico Página 136

143 f) Para cambiar el nombre elegimos el elemento y después seleccionamos propiedades de elemento que se muestra en la parte inferior de diagrama. Figura Anexo C-6 Pantalla Cambio de Nombre a un Elemento del Diagrama g) Repetimos el inciso d hasta terminar el diagrama que representa el proceso. h) Repetimos el inciso f para cambiar los nombres de elementos según se requiera. La siguiente pantalla muestra el diagrama terminado en base a las actividades definidas con anterioridad. Centro Nacional de Investigación y Desarrollo Tecnológico Página 137

144 Figura Anexo C-7 Pantalla Proceso de Negocio de Ejemplo Completado i) Seleccionamos Guardar una vez terminado la imagen, seleccionamos el directorio en donde se ha de guardar y proporcionamos el nombre del diagrama y aceptar. Figura Anexo C-8 Pantalla Guardar Proceso de Negocio Ejemplo Centro Nacional de Investigación y Desarrollo Tecnológico Página 138