TESIS DE MAESTRÍA EN CIENCIAS - cenidet.edu.mx Lucia Morales... · software requirements...

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

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.

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.

“Metodología para la Elicitación de Requerimientos de Software Utilizando Transacciones del Proceso de Negocio para la Facturación Electrónica”

Centro Nacional de Investigación y Desarrollo Tecnológico Página 1

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.



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.



Contenido

Resumen ………………………………………………………………….………………………………...1

Abstract ………………………………………………………………………………………………….…2

Contenido …………………………………………………………………………………….…….……....3

Lista de Tablas ……………………………………………………………………………..……………..5

Lista de Figuras ……………………………………………………………………….…………………..7

Introducción …………………………………………………………………………..……………………9

Capítulo 1 Generalidades ........................................................................................... 10

1.1 Antecedentes ..................................................................................................... 10

1.2 Trabajos Relacionados ...................................................................................... 11

1.2.1 “Obtención de Requerimientos de Software ERP con modelos de

Referencia” [GAO10] ................................................................................................ 11

1.2.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] ................................................................................................. 12

1.2.3 “Uso de Técnicas Etnográficas en el Desarrollo de una Herramienta Móvil

para la Obtención de Requerimientos” [SHAH09] ..................................................... 14

1.2.4 “Escribiendo y Leyendo la Documentación de Software: Como el Proceso

puede Afectar a la Comprensión” [REMO09] ............................................................ 14

1.3 Planteamiento del Problema .............................................................................. 17

1.4 Objetivo ............................................................................................................. 17

1.5 Justificación y Beneficios ................................................................................... 18

1.6 Metodología de Solución ................................................................................... 19

1.7 Alcances y Limitaciones..................................................................................... 19

1.8 Conclusiones Capítulo 1 .................................................................................... 20

Capítulo 2 Marco Conceptual ..................................................................................... 21

2.1 Ingeniería de Requerimientos ............................................................................ 21

2.1.1 Etapas de la Ingeniería de Requerimientos ................................................ 23

2.1.2 Técnicas Clásicas de Elicitación de Requerimientos .................................. 24

2.1.3 Técnicas Modernas de Elicitación de Requerimientos ................................. 26

2.2 Procesos de Negocios ....................................................................................... 28



2.3 Transacciones de negocios ............................................................................... 29

2.4 Patrones de Modelado de los Procesos de Negocios ........................................ 30

2.5 Análisis de Dominio Orientado Características .................................................. 31


Capítulo 3 Desarrollo .................................................................................................. 33

3.1 Análisis de Dominio Orientado a Características ............................................... 33

3.1.1 Análisis de Contexto ................................................................................... 34

3.1.2 Modelado del Dominio ................................................................................ 39

3.2 Especificación del Proceso de Negocio ............................................................. 43

3.2.1 Proceso de Facturación Electrónica ........................................................... 43

3.3 Transacciones de Negocios en el Proceso de Negocio para la Facturación

Electrónica ................................................................................................................... 50

3.4 Interacción entre Transacciones de Negocios y Patrones de Modelado del

Proceso de Negocio ..................................................................................................... 52

3.5 Definición de acciones de la metodología .......................................................... 52

3.6 Desarrollo de la Metodología ............................................................................. 60

3.6.1 Etapas de la Metodología ........................................................................... 61

3.6.2 Etapa 1: Obtención de Requerimientos ...................................................... 63

3.6.3 Etapa 2: Análisis ......................................................................................... 75

3.6.4 Etapa 3: Especificación de Requerimientos de Software ............................ 78

3.6.5 Etapa 4: Validación de Requerimientos ...................................................... 82


Capítulo 4 Pruebas ...................................................................................................... 86

4.1 Descripción General de las pruebas .................................................................. 86

4.2 Enfoque de las Pruebas .................................................................................... 87

4.3 Convención de nombres .................................................................................... 87

4.4 Especificaciones del Plan de Pruebas ............................................................... 87

4.5 Casos de Pruebas Aplicadas a un Escenario Real ............................................ 88

4.6 Metodología de la Tesis (Procedimiento) ........................................................... 89

4.6.1 Etapa 1: Obtención de Requerimientos ...................................................... 89

4.6.2 Etapa 2: Análisis de Requerimientos ........................................................ 109

4.6.3 Etapa 3: Especificación de Requerimientos de Software .......................... 110

4.6.4 Etapa 4: Validación de Requerimientos .................................................... 111



4.7 Metodología del Instituto de Investigación ....................................................... 112

4.8 Conclusiones de las Pruebas .......................................................................... 112

4.9 Conclusiones Capítulo 4 .................................................................................. 114

Capítulo 5 Conclusiones ........................................................................................... 115

5.1 Conclusiones Generales .................................................................................. 115

5.2 Trabajos Futuros ............................................................................................. 116

Referencias ……………………………………………………………………………………….…….117

Anexos …………………………………………………………………………..……………………….121

Anexo A: Formalización del Proceso de Negocio para la Facturación Electrónica ..... 121

Anexo B: Descripción de Actividades de la Metodología Representada con BPMN ... 127

Anexo C: Modelado de Proceso de Negocio con BizAgi Process Modeler ................. 133

Lista de Tablas

Tabla 1.2-1 Heurística Propuesta para Obtener un MPND [QUEL09] .............................. 13

Tabla 1.2-2 Comparativa de Trabajos Relacionados ....................................................... 16

Tabla 2-1 Características de los Requerimientos [ARIAS05] ........................................... 23

Tabla 2-2 Etapas Ingeniería de Requerimientos .............................................................. 23

Tabla 3-1 Descripción del Diagrama de Estructura .......................................................... 35

Tabla 3-2 Descripción Diagrama de Contexto .................................................................. 37

Tabla 3-3 Símbolos Utilizados en el Árbol de Características .......................................... 39

Tabla 3-4 Descripción del Árbol de Características .......................................................... 40

Tabla 3-5 Definiciones y Abreviaturas .............................................................................. 44

Tabla 3-6 Descripción de Roles ....................................................................................... 44

Tabla 3-7 Descripción del Proceso de Facturación .......................................................... 45

Tabla 3-8 Descripción del Proceso: Facturación\Creación de Órdenes de Facturación ... 46

Tabla 3-9 Descripción del Proceso: Facturación \Creación de Facturas .......................... 46

Tabla 3-10 Descripción de Actividades: Facturación Electrónica ..................................... 49

Tabla 3-11 Descripción de la Simbología Utilizada en el Proceso de Facturación ........... 49

Tabla 3-12 Descripción de Acciones Obtenidas ............................................................... 53

Tabla 3-13 Formato de Actividad ..................................................................................... 55

Tabla 3-14 Guía del Formato de Actividad ....................................................................... 56

Tabla 3-15 Representación de Distribución en Paralelo [BizAgi11] .................................. 57

Tabla 3-16 Formato De Actividades que se Realizan de Manera Concurrente o en

Distribución en Paralelo ................................................................................................... 57



Tabla 3-17 Guía del Formato de Actividades que se Realizan de Manera Concurrente o

en Distribución en Paralelo .............................................................................................. 57

Tabla 3-18 Formato de Actividad Sincronizada ................................................................ 58

Tabla 3-19 Guía del Formato de Actividad Sincronizada ................................................. 58

Tabla 3-20 Formato de Selección Exclusiva .................................................................... 59

Tabla 3-21 Guía del Formato de Selección Exclusiva ...................................................... 59

Tabla 3-22 Formato de Objetivos ..................................................................................... 67

Tabla 3-23 Guía del Formato de Objetivos ...................................................................... 67

Tabla 3-24 Formato de Transacción de Negocio. ............................................................ 69

Tabla 3-25 Guía del Formato de Transacción de Negocio ............................................... 69

Tabla 3-26 Formato de Roles .......................................................................................... 70

Tabla 3-27 Guía del Formato Roles ................................................................................. 70

Tabla 3-28 Guía Básica para la representación del Proceso de Negocio con BPMN ....... 71

Tabla 3-29 Formato 1 de Actividad del PN ....................................................................... 72

Tabla 3-30 Formato 2 de Actividades del PN ................................................................... 73

Tabla 3-31 Guía de los Formatos de Actividades de PN .................................................. 73

Tabla 3-32 Formato 1 de Actividad del Subproceso ......................................................... 74

Tabla 3-33 Formato 2 de Actividades del Subproceso ..................................................... 74

Tabla 3-34 Guía de los Formatos de Actividades de PN .................................................. 74

Tabla 3-35 Formato de Requerimientos Detectados con Problemas ............................... 77

Tabla 3-36 Guía del Formato de Requerimientos Detectados con Problemas ................ 77

Tabla 3-37 Guía de Llenado del Documento de Especificación de Requerimientos de

Software .......................................................................................................................... 79

Tabla 3-38 Atributos de una SRS de calidad [DAV93] ..................................................... 82

Tabla 4-1 Objetivo 1 ........................................................................................................ 90

Tabla 4-2 Objetivo 2 ........................................................................................................ 90

Tabla 4-3 Definiciones y Abreviaturas .............................................................................. 91

Tabla 4-4 Descripción de Rol Asistente ........................................................................... 91

Tabla 4-5 Descripción de Rol Jefe de Asistente ............................................................... 92

Tabla 4-6 Descripción de Rol Departamento de Ingresos ............................................... 92

Tabla 4-7 Descripción de Rol Jefe del Departamento de Ingresos ................................. 92

Tabla 4-8 Descripción de Rol Tesorero .......................................................................... 93

Tabla 4-9 Descripción Transacción de Negocio Facturación Electronica ........................ 93

Tabla 4-10 Descripción de Actividades: Facturación Electrónica ..................................... 95

Tabla 4-11 Formato de la Actividad Seleccionar líneas del programa de pagos .............. 99

Tabla 4-12 Formato de la Actividad Crear Ordenes de Facturación ............................... 100

Tabla 4-13 Formato de la Actividad Enviar Aprobación OF ............................................ 100

Tabla 4-14 Formato de la Actividad Revisar y Validar la OF .......................................... 101

Tabla 4-15 Formato de la Actividad Cancelar OF .......................................................... 101

Tabla 4-16 Formato de la Actividad Solicitar Modificación ............................................. 102

Tabla 4-17 Formato de la Actividad Modificar OF .......................................................... 102

Tabla 4-18 Formato de la Actividad Aprobar OF ............................................................ 102

Tabla 4-19 Formato de la Actividad Enviar Documentación a Soporte a CXC ............... 103

Tabla 4-20 Formato de la Actividad Recibir Documentación de Soporte ........................ 103



Tabla 4-21 Formato de la Actividad Validar Documentación de Soporte y OF ............... 103

Tabla 4-22 Formato de la Actividad Generar Factura y Completar Información ............. 104

Tabla 4-23 Formato de la Actividad Enviar Factura a Aprobación .................................. 105

Tabla 4-24 Formato de la Actividad Recibe Notificación de Aprobación Pendiente ........ 105

Tabla 4-25 Formato de la Actividad Revisar y Validar Factura ....................................... 106

Tabla 4-26 Formato de la Actividad Cancelar Factura ................................................... 106

Tabla 4-27 Formato de la Actividad Solicitar Modificación Factura ................................ 106

Tabla 4-28 Formato de la Actividad Modificar Factura ................................................... 107

Tabla 4-29 Formato de la Actividad Aprobar Factura ..................................................... 107

Tabla 4-30 Formato de la Actividad Generar Registro Contable .................................... 107

Tabla 4-31 Formato de la Actividad Generar Factura Electrónica .................................. 108

Tabla 4-32 Formato de la Actividad Revisar Registro Contable ..................................... 108

Tabla 4-33 Formato de la Actividad Cancelar Registro Contable ................................... 108

Tabla 4-34 Formato de la Actividad Corregir Información .............................................. 109

Tabla 4-35 Formato de la Actividad Cerrar Factura ....................................................... 109

Tabla 4-36 Formato de Requerimientos Detectados con Problemas ............................. 110

Tabla 4-37 Resultados de las Métricas del CP_01 ......................................................... 112

Tabla 4-38 Resultados de las Métricas del CP_02 ......................................................... 112

Tabla Anexo A-1 Descripción de Elementos Utilizados en la Formalización del PN ....... 121

Tabla Anexo A-2 Abreviaturas en la Formalización PN .................................................. 123

Tabla Anexo B-3 Descripción de Actividades de la Metodología Representada con BPMN

...................................................................................................................................... 127

Tabla Anexo B-4 Descripción del Subproceso Etapa de Elicitación de la Metodologia .. 128

Tabla Anexo B-5 Descripción del Subproceso Etapa de Análisis de la Metodología ...... 130

Tabla Anexo B-6 Descripción del Subproceso Etapa de Especificación de Requerimientos

de la Metodología .......................................................................................................... 131

Tabla Anexo B-7 Descripción del Subproceso Etapa de Validación de Requerimientos de

la Metodología ............................................................................................................... 132

Lista de Figuras

Figura 1-1 Marco de la Metodología [GAO10] .................................................................. 12

Figura 1-2 Modelo de la Metodología [REMO09] ............................................................ 15

Figura 2-1 Proceso de Negocios [BOCAN08] .................................................................. 29

Figura 3-1 Diagrama de Actividades Realizadas del FODA ............................................. 34

Figura 3-2 Diagrama de Estructura .................................................................................. 35

Figura 3-3 Diagrama de Contexto .................................................................................... 37

Figura 3-4 Diagrama de Árbol de Características ............................................................ 39

Figura 3-5 Proceso de Facturación .................................................................................. 45



Figura 3-6 Procesos Implícitos en el Proceso de Facturación .......................................... 46

Figura 3-7 Descripción de Actividades: Facturación Electrónica ...................................... 48

Figura 3-8 Representación de Secuencia de Actividades ................................................ 56

Figura 3-9 Representación de Sincronización .................................................................. 58

Figura 3-10 Representación de Selección Exclusiva ....................................................... 59

Figura 3-11 Etapas de la metodología de la tesis ............................................................ 62

Figura 3-12 Diagrama Metodología de Elicitación Tesis .................................................. 62

Figura 3-13 Etapa 1: Obtención de Requerimientos ........................................................ 65

Figura 3-14 Diagrama Etapa 1: Obtención de Requerimientos ........................................ 65

Figura 3-15 Diagrama Etapa 1: Elicitación/Proceso de Negocio ...................................... 68

Figura 3-16 Proceso de Ejemplo de Creación de Órdenes de Facturación ...................... 72

Figura 3-17 Etapa 2: Análisis ........................................................................................... 75

Figura 3-18 Diagrama Etapa 2: Análisis ........................................................................... 76

Figura 3-19 Etapa 3: Especificación de Requerimientos .................................................. 78

Figura 3-20 Diagrama Etapa 3: Especificación de Requerimientos .................................. 78

Figura 3-21 Etapa 3: Validación de Requerimientos ........................................................ 83

Figura 3-22 Diagrama Etapa 4: Validación ....................................................................... 83

Figura 4-1 MERSUTPN .................................................................................................. 89

Figura 4-2 Descripción de Actividades: Facturación Electrónica ...................................... 94

Figura 4-4 Grafica de Factores Evaluados en los Casos de Prueba .............................. 113

Figura Anexo C-1 Pantalla de Selección de la Herramienta BizAgi ................................ 133

Figura Anexo C-2 Pantalla Ambiente Grafico BizAgi ...................................................... 134

Figura Anexo C-3 Pantalla Nuevo Diagrama ................................................................. 135

Figura Anexo C-4 Pantalla Evento de Inicio del Diagrama ............................................. 136

Figura Anexo C-5 Pantalla Continuación de Representación del Diagrama ................... 136

Figura Anexo C-6 Pantalla Cambio de Nombre a un Elemento del Diagrama ................ 137

Figura Anexo C-7 Pantalla Proceso de Negocio de Ejemplo Completado ...................... 138

Figura Anexo C-8 Pantalla Guardar Proceso de Negocio Ejemplo................................. 138



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.



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).

CAPÍTULO 1



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.

1.2.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. 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



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]

1.2.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), 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].



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 1.2-1 Heurística Propuesta para Obtener un MPND [QUEL09]

Etapa Pautas

Descubrir actores

1.1. Identificar los actores primarios.

1.2. Identificar los actores secundarios.

1.3. Identificar a los actores terciarios.

Descubrir

preguntas de

decisión,

investigación y

actividades

operacionales

2.1. Identificar la pregunta de decisión principal.

2.2. Identificar las preguntas de decisión secundarias.

2.3. Determinar si las preguntas de decisión son Estructuradas,

No Estructuradas o Semi-Estructuradas.

2.4. Identificar las preguntas de investigación. Estas preguntas

surgen de las preguntas de decisión primaria y secundaria.

2.5. Determinar las actividades operacionales que son

necesarias para dar respuesta a las preguntas de investigación.

2.6. Relacionar cada pregunta de decisión, investigación y

actividades operacionales, con sus respectivos actores

involucrados.

Descubrir

recursos y

establecer

relaciones

3.1. Para cada actividad operacional se deben identificar los

datos, estructuras de datos e información, necesarias para

llevarlas a cabo.

3.2. 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:

3.2.1. Agregar actividades operacionales que surjan de la

interacción entre actores.

3.2.2. Considerar los recursos que nacen como resultado de

alguna actividad operacional y que son necesarias para

desarrollar otra.



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.

1.2.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 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.



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.



Tabla 1.2-2 Comparativa de Trabajos Relacionados

Trabajos Interacción

Cliente/Experto

Procesos

de

Negocios

Obtención de un

Documento de

Requerimientos de

software

Centrada al

usuario

Centrada al

experto

“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 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



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.



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.



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.



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.



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].

CAPÍTULO 2



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” [STD610.12-90].

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]

http://www.monografias.com/trabajos5/recicla/recicla.shtml#papel

http://www.monografias.com/trabajos16/comportamiento-humano/comportamiento-humano.shtml

http://www.monografias.com/trabajos15/calidad-serv/calidad-serv.shtml#PLANT

http://www.monografias.com/trabajos11/teosis/teosis.shtml

http://www.monografias.com/trabajos7/mafu/mafu.shtml

http://www.monografias.com/trabajos10/carso/carso.shtml

http://www.monografias.com/trabajos15/mantenimiento-industrial/mantenimiento-industrial.shtml

http://www.monografias.com/trabajos/seguinfo/seguinfo.shtml



Tabla 2-1 Características de los Requerimientos [ARIAS05]

Característica Descripción

Necesario Lo que pida un requerimiento debe serlo para el producto.

Conciso 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.

Completo 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.

Consistente Un requerimiento no debe ser contradictorio con otro requerimiento.

Asimismo, el lenguaje empleado entre los distintos requerimientos

debe ser consistente.

No ambiguo 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.

Verificable 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.

2.1.1 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 Descripción

Obtención o

Extracció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].

Análisis 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.



Especificación En esta fase se documentan los requerimientos acordados con el

cliente, considerando un nivel apropiado de detalle.

Validación 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].

2.1.2 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:



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.



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].

2.1.3 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]:



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].



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].



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



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



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]:



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


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.



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

CAPÍTULO 3



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

3.1.1 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



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 Descripción

Documento de

Requerimiento

s de Software

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.

Metodologías

de Elicitación

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.

Procesos de

negocios

Conjunto de actividades para lograr un objetivo (procesos

operacionales) del negocio.



Información 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.

Base de una

Metodología

de

Investigación

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.

Estándar IEEE

830

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.



Cliente

Experto

Estandar IEEE

830

Documentos de

Requerimientos

de Software

Metodología de

Elicitación

Acciones

Información

Solicita

Proporciona

Resultado

Revisa

Transmite

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 Descripción

Metodología de

Elicitació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.

Información Es proveniente del cliente y del experto.

Acciones Almacenan las transacciones de los procesos de negocios que

ayudaran a detallar el requerimiento que se quiere expresar.

Estándar IEEE

830

Define un formato y contenido de un documento de Especificación

de Requerimientos de Software.

Documento 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.



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.



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



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: Alternativa

Definición: Proveniente de quien utilizará la metodología.

Padre Metodología de Elicitación.

Fuente Experto ó Usuario del dominio.

Experto: Alternativa

Definición: Experto analista..

Padre Información.

Fuente Experto del dominio.

Cliente: Obligatoria

Definición: Usuarios/clientes que requieren se desarrolle el sistema.

Padre Información.

Fuente Usuario del dominio.

Negocio: Obligatoria

Definición: El dominio para el cual se requiere desarrollar el sistema.


Fuente Experto y/o Usuario del dominio.

Dominio: Obligatoria

Definición: Identifica una visión general del dominio del negocio (el

problema a resolver).

Padre Negocio.


Objetivo: Obligatoria

Definición: Describe el objetivo que tendrá que cumplir el negocio con

el sistema que se necesita desarrollar.

Padre Negocio.


Producto: Obligatoria

Definición: Desarrollo de un documento de requerimientos de

software.



Acciones: Obligatoria

Definición: Guias y formatos para la descripcion detallada del proceso

de negocio.



Padre Producto.


Docto. de requerimientos

software:

Obligatoria

Definición: Documento que define de manera detalla los

requerimientos funcionales de sofware, bajo el estandar

IEEE 830.

Padre Producto.


Proceso de negocio: Obligatoria

Definición: Identifica un conjunto de actividades para lograr un objetivo

(procesos operacionales) del negocio.

Padre Negocio.


Descripción Obligatoria

Definición: Se realiza una descripción del funcionamiento de la

transacción del negocio de forma general.

Padre Transacción de negocio.


Entrada: Obligatoria

Definición: Se describe la(s) entrada(s) de la transacción



Salida: Obligatoria

Definición: Se describe la(s) salida(s) de la transacción, es decir, cual

es el evento resultante de la ejecución del proceso.



Controles: Obligatoria

Definición: 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.



Roles: Obligatoria

Definición: Identifica que roles van a estar interactuando para poderse

llevar a cabo la transacción.





Operaciones del

negocios

Obligatoria

Definición: 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.



Actividad Obligatoria

Definición: Indica el nombre de la actividad. Las actividades son los

pasos que deben realizarse para convertir las entradas del

proceso en el resultado esperado.

Padre Operaciones del negocio.


Descripción de la

Actividad:

Obligatoria

Definición: Se describe el funcionamiento de la actividad



Tipo: Obligatoria

Definición: Indica el tipo de actividad (Manual, Semi-automatizada,

automatizada)



Rol: Obligatoria

Definición: Indica el rol que ejecuta la actividad.



Precondición: Obligatoria

Definición: Indican las condiciones necesarias para iniciar una

actividad.



Postcondición: Obligatoria

Definición: Indican las condiciones necesarias que deben cumplirse

después de que la actividad ha finalizado.





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].

3.2.1 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

http://www.edifact.com.mx/edifactmx/facturaelectronica.php




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 Descripción del Rol

Asistente 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.

Jefe Asistente Es el encargado de revisar, aprobar, solicitar cambios y cancelar las

órdenes de facturación.

Depto. Ingresos Se encarga de registrar las facturas dentro del sistema, así como

hacer el registro contable de las mismas.

Jefe depto.

Ingresos

Se encarga de aprobar las facturas.

Tesorero 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.



Figura 3-5 Proceso de Facturación

Tabla 3-7 Descripción del Proceso de Facturación

Elemento Descripción

Proceso de Negocio Proveer factura electrónica

Descripción 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.

Entradas Contrato de ingresos autorizado.

Salidas Factura Aprobada.

Roles Asistente, Jefe del asistente, departamento de

ingresos, jefe departamento de ingresos.

Restricciones Solo se podrán crear facturas de proyectos.

Documentos Orden de facturación autorizada, factura electrónica.

Actividades (Operaciones del

negocio)

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.



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


Proceso de Negocio Crear ordenes de facturación

Descripció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 Orden de facturación aprobada.

Roles Asistente, jefe del asistente

Restricciones No se podrán crear órdenes de facturación si no existe un

contrato de ingresos.

Documentos Orden de facturación autorizada.

Actividades (Operaciones

del negocio)

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


Proceso de Negocio 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.

Entradas Orden de facturación aprobada.

Salidas Factura impresa, solicitud de modificación.

Roles Depto. de ingresos, jefe departamento de ingresos,

tesorero.

Restricciones No se podrán crear facturas si no existe una orden de

facturación aprobada.

Documentos Factura electrónica.



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].



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 email.

Manual: Es un tarea donde interviene un humano para su realización.



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

Rol Precondiciones Postcondiciones

Seleccionar

líneas del

programa de

pagos

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.

Asistente Contrato de

ingresos

autorizado.

Líneas de pago

seleccionadas.

Enviar

documentación

soporte a CXC

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.

Asistente Orden de

facturación

aprobada

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 Indica cuando un proceso inicia. Por

proceso sólo es permitido un evento de

inicio simple.

Actividad o Tarea Son actividades de trabajo que la

compañía realiza y que no pueden ser

descompuestas en más actividades.



Evento Intermedio 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.

Condicional o

compuerta de

decisión

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.

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.

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



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.



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.



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



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.



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:



Tabla 3-14 Guía del Formato de Actividad

Guía Formato de Actividad

Actividad: Nombre de la 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

Éxito.

Describir qué valores o variables son necesarios para que se ejecute

de manera exitosa la actividad.

Criterio

Alternativo:

Describir los valores o variables mínimos necesarios para que inicie y

termine de ejecutarse la actividad.

Criterio de

Error:

Describir en que caso no se realiza la actividad.

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.

http://wiki.bizagi.com/es/index.php?title=Archivo:Modeling_the_Process11_Image002.jpg



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: Fecha:

Actividades que habilita:

Actividad que se garantiza realizar:

Criterio de Éxito:

Criterio Alterno:


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

habilita.

Nombre de la actividad que habilita las actividades que se ejecutaran

de forma simultánea.

Autor: Nombre de la persona que registro los datos en la forma para

actividad.


Criterio de

Éxito.



Criterio

Alternativo:

Describir los valores o variables mínimos necesarios para que se inicie

y termine de ejecutarse la actividad.

Criterio de

Error:






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: Fecha:

Actividades que la habilitan:

Criterio de Éxito:

Criterio Alterno:


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

la habilitan.

Nombre de las actividades que deberán ejecutase de manera

sincronizada para que se habilite la actividad.

Autor: Nombre de la persona que registro los datos en la forma para

actividad.


Criterio de

Éxito.



Criterio

Alternativo:

Describir los valores o variables mínimos necesarios para que se inicie

y termine de ejecutarse la actividad.

Criterio de

Error:





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: Fecha:

Condición:

Estado 1:

…

Estado n:

Criterio de Éxito:

Criterio Alterno:


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.


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




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

Éxito

Describir la información necesaria para que se cumpla la condición

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.



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.



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 3-12. 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

Obtención

•Panorama

•Objetivos

•Proceso de Negocio

•Requerimientos preliminares

Análisis

•Problemas

•Alternativas/Solución

•Requerimientos detallados

Especificación

•Elaborar los requerimientos con el Estándar IEEE 830

Validación

•Pruebas Requerimientos

•Correctos

•Entendibles

•Sin Ambigüedades



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 830.

4. 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.

3.6.2 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.



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:



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

•Entrevistas clientes y analistas(expertos)

Panorama

•Analisis del panorama

Objetivos•Actores

•Operaciones

•Controles

•Entrada

•SalidaProceso de negocio

•Acciones

Documento de Requerimientos



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.



Tabla 3-22 Formato de Objetivos

Objetivo:

Autor: Fecha:

Descripción:

Importancia:

Comentarios Adicionales:

Tabla 3-23 Guía del Formato de Objetivos

Guía del Formato de Objetivos

Objetivo Nombre del objetivo

Autor: Nombre de la persona que elaboró el formato.

Fecha: Fecha en que llenó el formato.

Descripción Describe de manera detallada qué es lo deberá contener

para que este objetivo se cumpla.

Importancia El grado de importancia puede estar dado por: alta, media,

baja.

Comentarios adicionales 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?



– ¿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].



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

Guía del Formato de Transacción de Negocio

Transacción de Negocio: Nombre de la transacción o proceso de negocio que

se llevará a cabo.

Autor: Nombre de quien elaboró la forma.

Fecha: Fecha en la que se elaboró.

Descripción Describe lo que realizará la transacción de negocio.

Entrada: Describe con qué documento, dato y/o información

deberá comenzar la ejecución de la transacción.

Salida: 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.


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



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: Fecha:

Persona Actual a Cargo:

Descripción:

Comentarios:

Tabla 3-27 Guía del Formato Roles

Guía del Formato Roles

Rol Nombre del Rol que participa para que el proceso se lleve a cabo,

por ejemplo departamento ingresos.


Fecha: Fecha en que se elaboró la forma.

Persona Actual a

Cargo del Rol.

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

Descripción Describe las funciones que tiene que realizar durante el proceso.

Comentarios 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.



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 Indica cuando un proceso inicia. Por

proceso sólo es permitido un evento

de inicio simple.

Actividad (Atómica) Son actividades de trabajo que la

compañía realiza y que no pueden

ser descompuestas en más

actividades.

Actividad

(Compuesta o

Subproceso)

Es un conjunto de actividades

incluidas dentro de un proceso.

Puede desglosarse en diferentes

niveles de detalle denominadas

tareas [Analítica11].

Evento Intermedio 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.

Condicional

Exclusiva

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.



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:



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

Guía de los Formatos de Actividades de PN

Actividad Nombre de la actividad.

Proceso de Negocio Nombre del proceso de negocio del que forma parte de la

actividad.



Tipo 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 email.

Manual: Es un tarea donde interviene un humano para su

realización.

Descripción Se describe el funcionamiento de la actividad

Rol Indica el rol que ejecuta la actividad.

Precondición Indican las condiciones necesarias para iniciar una

actividad.

Postcondición 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.



Tabla 3-32 Formato 1 de Actividad del Subproceso

Actividad:

Subproceso:

Proceso de Negocio:

Autor: Fecha:

Tipo:

Rol:

Precondición:

Poscondición:

Tabla 3-33 Formato 2 de Actividades del Subproceso

Autor:

Fecha:

Subproceso:

Proceso de Negocio:


Tabla 3-34 Guía de los Formatos de Actividades de PN

Guía de los Formatos de Actividades de PN

Actividad Nombre de la actividad.

Subproceso Nombre del subproceso al que pertenece la actividad

Proceso de Negocio Nombre del proceso de negocio del que forma parte de la

actividad de subproceso.



Tipo 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 email.

Manual: Es un tarea donde interviene un humano para su

realización.

Descripción Se describe el funcionamiento de la actividad

Rol Indica el rol que ejecuta la actividad.



Precondición Describe las condiciones necesarias para dar comienzo

con la actividad.

Postcondición 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.

3.6.3 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 3-17.

Figura 3-17 Etapa 2: Análisis

•Analizar los Requerimientos

•Detectar problemas en los requerimientos.

•Entrevista con Clientes

•Generar alternativas

•Aplicar alternativa seleccionada

Identificación de Problemas/Alternativas de Solución

•Detallar requerimientos

Documento de Requerimientos Detallados



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.



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.



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.



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:

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.

•Elaborar Documento de Requerimientos con el estándar IEEE 830

Documento de Especificación de requerimientos



C) Actividades


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-830-98]:

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 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.

Alcance En la organización: mostrar organigrama sombreando el

dpto. a atender.

Respecto al producto: Módulos generales y sus módulos,



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

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

Funciones del producto 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.

Características de los

usuarios

Educación

Nivel de conocimientos

Experiencia

Conocimientos técnicos

Restricciones Se debe proporcionar una descripción general de



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.

Dependencias 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.

Especificación de

requerimientos

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.



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.



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 nr son todos los requerimientos,

nr=requerimientos funcionales (nf) + requerimientos no funcionales (nnf), pero como en el

presente trabajo de tesis solo se limita a los requerimientos funcionales, entonces nr = nf

+ 0.

C) Actividades


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.

•Documento de Requerimientos

•Métrica de correctes

Requerimientos correctos


•Métrica de entendible

Requerimientos entendibles


•Métrica de ambigüedad

Requerimientos No ambiguos



1.- Requerimientos No Ambiguos

Una SRS es no ambigua si y sólo si cada requerimiento sólo tiene una interpretación

[IEEE-STD-830-98].

Una manera de medir si una SRS es no ambigua es mediante [DAV93]:

Q1=nui/nr

Donde nui 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]:

Q3 = nC/(nC+nNV) = nC/nr

Donde nC y nNV son los números de requerimientos correctos y no validados

respectivamente y nC+nNV = nr [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]:

Q4 = nur/nr

Donde nur es el número de requerimientos para los cuales todos los revisores

entendieron [DAV93].




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.



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.

CAPÍTULO 4



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.



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_01.

4.5 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.





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.

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.

4.6.1 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.2. 11.1 a la I.2.11.8 y de la II.2.8.1 a la II.2.8.4 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.

Obtención

•Panorama

•Objetivos

•Proceso de Negocio

•Requerimientos preliminares

Análisis

•Problemas

•Alternativas/Solución

•Requerimientos detallados

Especificación

•Elaborar los requerimientos con el Estándar IEEE 830

Validación

•Pruebas Requerimientos

•Correctos

•Entendibles

•Sin Ambigüedades



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:

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.

Importancia: Alta

Comentarios

Adicionales:

Tabla 4-2 Objetivo 2

Objetivo: Crear órdenes de facturación, para llevar un control de comprobantes

interno de la organización.


Descripción:

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

Importancia: Alta

Comentarios

Adicionales:

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



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 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 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.

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 4-4 Descripción de Rol Asistente

Rol: Asistente



Persona 1

Descripción: 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.

Comentarios:



Tabla 4-5 Descripción de Rol Jefe de Asistente

Rol: Jefe de Asistente



Persona 2

Descripción: 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



Persona 3

Descripción: 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




Persona 4

Descripción: Se encarga de aprobar las facturas.

Comentarios:



Tabla 4-8 Descripción de Rol Tesorero




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 Proveer factura electrónica

Descripción 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.

Entradas Contrato de ingresos autorizado.

Salidas Factura Aprobada.

Roles Asistente, Jefe del asistente, departamento de ingresos,

jefe departamento de ingresos.

Restricciones Sólo se podrán crear facturas de proyectos.

Documentos Orden de facturación autorizada, factura electrónica.


negocio)

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.



Figura 4-2 Descripción de Actividades: Facturación Electrónica



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


Seleccionar líneas del

programa de pagos

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.

Asistente Contrato de

ingresos

autorizado.

Líneas de pago

seleccionas.

Crear ordenes de

facturación

Automática Una vez seleccionadas las líneas del programa

de pago, se completa la información adicional

de la orden de facturación.

Asistente Líneas de pago

seleccionas.

Orden

capturada.

Enviar aprobación orden

de facturación

Automática El asistente envía la orden de facturación a su

jefe asistente.

Asistente Orden

capturada, OF en

estado de

modificación.

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

Jefe asistente OF revisada. OF cancelada

Solicitar modificación Automática Si el jefe asistente detecta algún error en la OF,

solicita a su asistente la corrija.

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



modificaciones que le solicita su jefe asistente y

realiza las modificaciones a la OF.

modificación

Aprobar OF Automática Si el jefe asistente no detecta errores, aprueba

la OF.

Jefe asistente OF revisada. OF aprobada

Enviar documentación

soporte a CXC

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.

asistente OF aprobada Documentación

enviada

Recibir documentación

soporte

Manual El departamento ingresos recibe la

documentación soporte de la OF.

Departamento

ingresos

OF aprobada y

documentación

enviada

Documentación

recibida

Validar documentación

soporte y OF

Automática El auxiliar revisa la orden de facturación contra

la documentación soporte.

Departamento

ingresos

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



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 factura

electrónica

Automática Una vez aprobada la factura y generado el

registro contable, se genera la factura.

Departamento

ingresos

Factura

aprobada

Factura

generada

Cancelar registro

contable

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



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


registro contable.

Jefe

departamento

ingresos

Registro

contable y

factura generado

Registro

contable

revisado.


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



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:

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.



Tabla 4-12 Formato de la Actividad Crear Ordenes de Facturación

Actividad: Crear ordenes de facturación


Criterio de Éxito:

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.

Criterio Alterno:

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.

Criterio de

Fracaso:

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: El asistente envía la orden de facturación a su jefe asistente, dentro de la

fecha correspondiente.

Criterio Alterno: No Aplica

Criterio de

Fracaso:

Que el asistente no envié la orden de facturación a su jefe antes de

cumplirse la fecha programada de pago.



Tabla 4-14 Formato de la Actividad Revisar y Validar la OF

Actividad: Revisar y validar la orden de facturación


Condición:

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.

Estado 1: 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.

Estado 2:

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.

Estado 3:

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.

Criterio de Éxito: Para que esta actividad sea exitosa deberá cumplir lo descrito en el estado

1.


Criterio de

Fracaso:

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


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.



Tabla 4-16 Formato de la Actividad Solicitar Modificación

Actividad: Solicitar modificación


Criterio de Éxito: Si el encargado de realizar esta tarea detecta algún error en la OF, solicita a

la persona correspondiente haga las correcciones necesarias.


Criterio de


Tabla 4-17 Formato de la Actividad Modificar OF

Actividad: Modificar OF


Criterio de Éxito: 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


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.



No Aplica ya que proviene de una actividad de selección exclusiva.



Tabla 4-19 Formato de la Actividad Enviar Documentación a Soporte a CXC

Actividad: Enviar documentación soporte a CXC


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


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


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



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)


actividad de Generar factura y completar información.

Estado 2:

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.

Estado 3:

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.

Criterio de Éxito: Para que esta actividad sea exitosa deberá de cumplir lo descrito en el

estado 1.

Criterio de

Fracaso:

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:

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



o Valor unitario en número o importe total en número o letra

o Impuestos que deben trasladarse desglosadas por la tasa de

impuesto.

Nota: Ver anexo para ejemplo de una factura con los datos

correspondientes.

Criterio Alterno: No aplica.

Criterio de

Fracaso:

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


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


Criterio de Éxito: Si recibió la notificación con la factura correspondiente se continúa con la

actividad de Revisar y Validar Factura.


Criterio de

Fracaso: Si no existe notificación con la factura no se realiza la actividad.



Tabla 4-25 Formato de la Actividad Revisar y Validar Factura

Actividad: Revisar y validar factura


Condición: La persona encargada de esta actividad revisa la factura cumpla con la

información establecida en la actividad de Generar factura.


actividad de Aprobar Factura.

Estado 2: 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.

Estado 3: Si la información no cumple con lo que se requiere contenga la factura, se

lleva a cabo la actividad de Cancelar factura.


estado 1.

Criterio de

Fracaso:

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


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 de


Tabla 4-27 Formato de la Actividad Solicitar Modificación Factura

Actividad: Solicitar modificación de factura


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 de


Tabla 4-28 Formato de la Actividad Modificar Factura

Actividad: Modificar factura


Criterio de Éxito:

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.


Criterio de

Fracaso:

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


Criterio de Éxito: Si el encargado de esta tarea no detecta errores, procede a aprobar la

Factura.


Criterio de


Tabla 4-30 Formato de la Actividad Generar Registro Contable

Actividad: Generar registro contable

Autor: Lucia Morales Morales Fecha: 07/Jul/2011

Criterio de Éxito: Para está actividad es necesario seleccionar que facturas se van a generar

para realizar el registro en contabilidad.

Criterio Alterno: No Aplica es necesario seleccionar al menos una factura para esta

actividad.

Criterio de

Fracaso:

De no seleccionarse alguna factura no se puede proceder a generar un

registro contable y por consecuencia esta actividad no puede completarse.



Tabla 4-31 Formato de la Actividad Generar Factura Electrónica

Actividad: Generar factura electrónica


Criterio de Éxito:

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.



Para realizar esta actividad la factura deberá de estar aprobada.

Tabla 4-32 Formato de la Actividad Revisar Registro Contable

Actividad: Revisar registro contable


Condición:

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,)


actividad de Revisar Registro contable.

Estado 2: Si la información es incorrecta con lo que se requiere contenga la factura, se

lleva a cabo la actividad de Cancelar Registro Contable.


estado 1.

Criterio de

Fracaso: Si no existe registro contable no se realiza la actividad.

Tabla 4-33 Formato de la Actividad Cancelar Registro Contable

Actividad: Cancelar registro contable


Criterio de Éxito:

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.


Criterio de




Tabla 4-34 Formato de la Actividad Corregir Información

Actividad: Corregir información


Criterio de Éxito: La persona responsable de esta actividad realiza las correcciones

pertinentes solicitadas del registro contable.

Criterio Alterno: No Aplica.


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:

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.


Criterio de

Fracaso:

Si no se realizó una revisión previa del registro contable, no puede

concluirse esta actividad.

4.6.2 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.



Tabla 4-36 Formato de Requerimientos Detectados con Problemas

Requerimiento: Generar factura y completar información


Alternativas:

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.

Solución:

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.

4.6.3 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:



Figura 4-3 Estructura del Documento de Especificación de Requerimientos de Software

4.6.4 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).



Tabla 4-37 Resultados de las Métricas del CP_01

Métricas: CP_01

No ambigüedad 0.86363636

Entendibilidad 0.81818182

Correctitud 0.86363636

4.7 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 86.9565217

Entendibilidad 86.9565217

Correctitud 95.6521739

4.8 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.



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.

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.

0.70000.75000.80000.85000.90000.95001.0000

No AmbigüedadCorrectitud

Entendibilidad

Resultados

CP_01 CP_02




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.



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

CAPÍTULO 5



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.



Referencias

[ALBO07] 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, 2007.

[ARIAS05] 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: 1409-4746.

[BOCAN08] 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 1988–3455.

[BizAgi11] BizAgi Process Modeler, “Patrones de modelamiento BPMN”,

Fuente: http://wiki.bizagi.com/es, consultado en febrero 2011

[CABR02] 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, 2004.

[CAMA05] 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, 2005.

[CLON03] Susan C. Cloninger. “Teorias de la Personalidad”. 3ra. Edición.

PEARSON Prentice Hall, 2003, ISBN: 209-26-0228-9

[DAV93] DAVIS, A. “Identifying and Measuring Quality in a Software Requirements Specification”. Proc. 1st Intl. Software Metrics



Symposium, IEEE, Baltimore, MD. Mayo 1993.

[DAVENPORT93] Davenport, Thomas (1993) - “Process Innovation”, Harvard Business School Press, USA, 1993.

[EDIFACT10] Edifact MX, Facturación electrónica, Fuente: http://www.edifact.com.mx/edifactmx/facturaelectronica.php, Consultado en enero 2010.

[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, 2002.

Fuente:http://www.lsi.us.es/docs/informes/LSI-2002-4.pdf

[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, 2008.

[GAO10] Gao, Juntao Yuan, Man Huang, Gan Wang, Zhiyao. “ERP software requirement elicitation with reference models ”. IEEE, 2010, ISBN: 978-1-4244-7324-3.

[GONZ06] 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 .

[HAMMER90] Hammer, M. (1990) – “Re-engineering Work: Don’t Automate, Obliterate”, Harvard Business Review, pp 104-112, 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, 2011.

[JIM03] 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: 0717–4195.

[KRUT93] 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 1993.

[LEON09] 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.7. 2009.

[Loucopoulos95] P. Loucopoulos and V. Karakostas: Software Requirements



Engineering, McGraw-Hill, 1995.

[OMG08] Object Management Group, Inc. “Business Process Model and Notation, V1.1”, 2008.

[OUYANG08] 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, 2008.

[PEÑA06] 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: 970-94797-5-X

[PHKTT03] Päivi Parviainen, Hanna Hulkko, Jukka Kääriäinen,Juha Takalo & Maarit Tihinen. Requirements engineering, Inventory of technologies, VTT Publications 508, 2003, ISBN 951.38.6245.3

[PRESS02] Pressman, Roger S. Ingeniería de Software, un Enfoque Práctico. 5ta. Edición. Mc Graw Hill, 2002, ISBN: 0-07-709677-0

[QADEEM10] MR. Shams-ul-arif, MR. Qadeem khan, S. A. K. Gahyyur. “Requirements Engineering Processes, Tools/Technologies, & Methodologies”. International Journal Of Reviews In Computing. ©2009-2010, ISSN: 2076-3328.

[QUEL09] 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, 2009.

[REMO09] Remo C. de Boer, Hans Van Vliet. “Writing and Reading Software Documentation: How Process may Affect Understanding”. IEEE, 2009, ISBN: 978-1-4244-3712-2.

[ROBERTSON06] Suzanne Robertson, James Robertson: “Mastering the requirements process”. Addison Wesley, 1998.

[RPS00]

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, 2000.

[SAT11]

Secretaria de Administracion Tributaria, “Comprobantes Fiscales Digitales”, Fuente: http://www.sat.gob.mx/sitio_internet/asistencia_contribuyente/principiantes/comprobantes_fiscales/66_16599.html, 2011.

[SAMPIERI06] HERNANDEZ, Sampieri Roberto, Metodología de la investigación,



Graw Hill, 2006.

[SHAH09] 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: 978-0-7695-3595-1.

[SOMM09] Sommerville, Ian. “Ingeniería de Software”. 7ma. Edición. PEARSON Addison Wesley, 2005, ISBN: 84-7829-074-5.

[STD610.12-90] Standard 610.12. Standard Glossary of Software Engineering Terminology. IEEE, 1990, ISBN: 155937067X.

[STD-830-98] IEEE Standard 830, “Software Requirements Specifications”, IEEE,

1998.

[STANDISH09] Standish, Group. The Chaos Report, Boston, Massachusetts, 2009.

[WHITE04] Stephen A white, “Process Modelling Notations and Workflow patterns, Fuente: http://www.bptrends.com/publicationfiles/03-04%20WP%20Notations%20and%20Workflow%20Patterns%20-%20White.pdf, 2004.



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 es1

M Evento de Intermedio ei1

O Evento de Intermedio ei2

A Evento de Intermedio ei3

B Evento de Intermedio ei4

C Evento de Intermedio ei5




D Evento de Intermedio ei6

E Evento de Intermedio ei7

OF Cancelada (jefe de asistente)

Evento de fin ef1

OF Cancelada (departamento de ingresos)

Evento de fin ef2

OF Cancelada (jefe departamento de ingresos)

Evento de fin ef3

Factura cerrada Evento de fin ef4

Factura electrónica generada enviada al cliente

Evento de Fin ef5

Seleccionar líneas del programa de pagos

Actividad a1

Crear ordenes de facturación Actividad a2 Enviar a aprobación OF Actividad a3 Revisar y validar OF Actividad a4 Cancelar OF Actividad a5

Solicitar modificación Actividad a6

Modificar OF Actividad a7

Aprobar OF Actividad a8

Enviar documentación soporte a CXC

Actividad a9

Recibir documentación soporte

Actividad a10

Validar documentación soporte y OF

Actividad a11

Cancelar OF Actividad a12

Solicitar modificación Actividad a13

Generar factura y completar información

Actividad a14

Enviar factura aprobación Actividad a15 Recibe notificación de aprobación pendiente

a16

Revisar y validar factura Actividad a17

Cancelar factura Actividad a18

Solicitar modificación de factura

Actividad a19

Modificar factura Actividad a20

Aprobar factura Actividad a21

Generar factura electrónica Actividad a22

Generar registro contable Actividad a23

Cancelar registro contable Actividad a24




(departamento de ingresos, jefe departamento de ingresos, tesorero)

Corregir información Actividad a25

Revisar registro contable (departamento de ingresos)

Actividad a26

Revisar registro contable(jefe departamento de ingresos)

Actividad a27

Revisar registro contable (tesorero)

Actividad a28

Cerrar factura (departamento de ingresos, tesorero)

Actividad a29

Orden de facturación correcta? (jefe de asistente)

Compuerta de decisión XOR basada en datos

g1

Orden de facturación correcta? (departamento de ingreso)


g2

Registro contable (departamento de ingreso)


g3

Factura correcta Compuerta de decisión XOR basada en datos

g4

Registro contable (jefe departamento de ingreso)


g5

Registro contable (tesorero) Compuerta de decisión XOR basada en datos

g6

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

GX Compuerta de decisión XOR basado en datos

{eS} Conjunto de eventos de inicio

EI Conjunto de eventos intermedios

{eE} 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



Formalización definición 1 (Proceso del núcleo de BPMN)

o A = {a1, a2, a3, a4,…, an}

o E = {{eS}, EI, {eE}}

o GX ={ g1, g2, g3, g4, g5 }

o G = {GX}

o {eS} = {es1}

o EI = { ei1, ei2, ei3, ei4, ei5, ei6 }

o {eE} = { ef, ef2, ef3, ef4, ef5, ef6 }

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 {(es1, a1), (a1, a2), (a2, a3), (a3, a4), (a4, g1), (g1, a6), (g1, a5), (g1, a8),

(a6, a7), (a5, ef1), (a8, a9), (a9, ei2), (ei1, a7), (ei2, a10), (a10, a11), (a11, g2), (g2, a13), (g2, a13), (g2,

a12), (g2, a14), (a13, ei1), (a14, a15), (a15, ei3), (ei4, a15), (ei3, a16), (a16, a17), (a17, g4), (g4, a19), (g4,

a19), (g4, a18), (g4, a21), (a18, ef3), (a19, ei4), (a21, ei5), (ei5, a23), (a23, a22), (a22, a26), (a26, g3), (g3,

ei6), (ei6, a24), (a24, a25), (a25, a23), (g3, a27), (a27, g5), (g5, ei6), (g5, ei7), (ei7, a29), (a29, ef4), (g5,

a28), (a28, g6), (g6, ei6), (g6, ei7), (g6, ef5)}

Para Cond: F ∩ Gx x O → C se obtiene: {(G1, A6), (G1, A5), (G1, A8), (G2, A12), (G2, A14),

(G2, A13), (G3, A26), (G3, A27), (G3, EI6), (G4, A21), (G4, A19), (G4, A18), (G5, A28), (G5, EI6), (G5, EI7),

(G6, A23), (G6, EF5), (G6, EI8), (G6, EI7)}

Excp: Si EI ↛ 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}

– 𝑆△ = ∅

– map: 𝑆△ → 𝑄 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.



– HR = {(P1, P2) ∈ Q × Q | ∃𝑆𝜖𝑆𝑃1 map(s) = P2} 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.

– FM ⊆ (∪P∈Q (TP ∪ 𝐸𝑃𝐸 ∪ 𝐸𝑃

𝐼𝑀) × ∪P∈Q (TP ∪ 𝐸𝑃𝑆 ∪ 𝐸𝑃

𝐼𝑀 )) \ ∪P∈Q(OP × OP), 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 ∈ ES ∪ dom(Excp), in(s) = ∅ ∧ | out(s) | = 1,

– ∀ e ∈ EE, out(e) = ∅ ∧ | in(e) | = 1,

– ∀ x ∈ A∪(EI \dom(Excp)), | in(x ) | = 1 and | out(x ) | = 1

– ∀ g ∈ GF ∪ GX ∪ GV : | in(g) | = 1 ∧ | out(g) | > 1,

– ∀ g ∈ GJ ∪ GM, | out(g) | = 1 ∧ | in(g) | > 1,

– ∀ g ∈ GV , out(g) ⊆ EIM ∪EIT ∪T R,

– ∀ g ∈ GX , ∃ 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 ∈ ES ∪ dom(Excp), ∃ e ∈ EE, s 𝐹∗x ∧ x𝐹∗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



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.



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

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.

Cliente y

Analista

Programar una

reunión entre los

participantes.

Requerimientos

preliminares

Revisar que se

hayan realiza

las actividades

de la etapa

Manual

El analista revisa que se hayan realizado y

completado las actividades

correspondientes a la etapa de elicitación.

Analista Requerimientos

preliminares

Actividad de etapa de

elicitación aceptada y

finalizada.

Etapa de

análisis

Manual

Los participantes revisan que se que no

haya problemas en los requerimientos

obtenidos en la etapa de elicitación.

Cliente y

Analista

Requerimientos

preliminares y Etapa

de elicitación

concluida

Requerimientos sin

problemas y

detallados

Revisar

documento de

requerimientos

Manual

Los participantes revisan que se hayan

revisado los todos los requerimientos y no

presenten problemas.

Cliente y

Analista

Requerimientos sin

problemas y

detallados

Requerimientos

revisados y sin

problemas

Etapa de

Especificación

de

requerimientos

Manual

Los analistas elaboran el documento de

requerimientos en base al estándar IEEE

830.

Analista Documento de

requerimientos

preliminares

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.


Especificación de

requerimientos

Documento de

Especificación de

requerimientos

revisado



Tabla Anexo B-4 Descripción del Subproceso Etapa de Elicitación de la Metodologia


Analizar la

información

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.

Analista Programar una

reunión entre los

participantes.

Información Analizada

Elaborar el

panorama

general del

proyecto

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.

Analista Información analizada Panorama general del

proyecto

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.

Clientes y

Analista

Panorama general del

proyecto

Objetivos

Proceso de

negocio

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.

Clientes y

Analista

Objetivos Diagrama del proceso

de negocio y

descripción de

actividades que se

utilizan en el proceso.

Revisar proceso

de negocio

Manual

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.

Clientes y

Analista

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.

Aplicar

Acciones

Manual

Teniendo el proceso se tendrá que aplicar

las determinadas acciones a fin de extraer

los requerimientos.

Clientes y

Analista

Proceso de negocio

aceptado por el

cliente.

Acciones aplicadas y

realizadas.

Elaborar docto.

de req.

Manual

Se deberá elaborar un documento

preliminar con las los datos obtenidos en

las actividades anteriores a esta.

Analista Acciones aplicadas,

objetivos y panorama

general del proyecto.

Documento de

requerimientos

preliminar



Tabla Anexo B-2 Descripción del Subproceso Proceso de Negocios de la Etapa de Elicitación de la Metodología


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


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



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



y descripción de

actividades

Proceso de negocio

aceptado.



Tabla Anexo B-5 Descripción del Subproceso Etapa de Análisis de la Metodología


Identificar

problemas en el

docto. de req.

Manual En esta actividad es en donde se identifica

si los requerimientos que fueron registrados

son los adecuados o es necesario

refinarlos.


requerimientos

preliminares.

Problemas

identificados en los

requerimientos.

Elaborar

Alternativas

Manual Elaborar alternativas de solución para los

problemas identificados.

Analista Problemas

identificados.

Lista de alternativas

de solución a los

problemas

Seleccionar

Alternativas

Manual Seleccionar las alternativas de solución en

para los problemas en los requerimientos.

Analista Lista de alternativas

de solución a los

problemas

Alternativas

seleccionadas

Implementar

alternativas

para solución

Manual Aplicar alternativas para solucionar los

problemas.

Analista 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



Tabla Anexo B-6 Descripción del Subproceso Etapa de Especificación de Requerimientos de la Metodología


Analizar

documento de

requerimientos

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.

Analista Documento

preliminar de

requerimientos y

etapa de análisis

completada.

Documento analizado

Elaborar el

docto. de req.

con el estándar

IEEE 830.

Manual Se elabora el documento de requerimientos

de acuerdo al estándar IEEE 830.

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.


Requerimientos bajo

el estándar IEEE 830

Documento de

requerimientos

revisado y aceptado

con de acuerdo al

estándar.



Tabla Anexo B-7 Descripción del Subproceso Etapa de Validación de Requerimientos de la Metodología


Analizar docto.

de

especificación

de

requerimientos

Manual Se revisa el documento para aplicar las

métricas en los requerimientos registrados.


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.


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.


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.


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.


especificación de

requerimientos.

Todos los

requerimientos

aceptados.



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 http://www.bizagi.com.

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ú InicioBizAgi 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.



Figura Anexo C-2 Pantalla Ambiente Grafico BizAgi

La siguiente tabla describe algunas de las partes que integra la herramienta.


A Representa los elementos que integra BPMN definidos en la tabla.

B Seleccionar para crear un nuevo documento o nuevo diagrama para representar el proceso de negocio.

C 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.

D 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:



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.



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



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.



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

TESIS DE MAESTRÍA EN CIENCIAS - cenidet.edu.mx Lucia Morales... · software requirements...

Documents

Transcript of TESIS DE MAESTRÍA EN CIENCIAS - cenidet.edu.mx Lucia Morales... · software requirements...