Automatizacion MC Lucia Morales Morales 2012 PDF

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”
Resumen
Hoy en día el desarrollo de proyectos de software tiene como base importante la

especificación de requerimientos, donde el objetivo primordial es la definición detallada de
las especificaciones que deban cubrir la funcionalidad que tendrá el sistema. Debido a
que una de las fases que da inicio el ciclo de vida del desarrollo de software es la
especificación de requerimientos, en donde el usuario transmite toda la información que
debe contener su “sistema” y el que finalmente utilizará en su trabajo diario.
Estudios como el “The Chaos Report” mencionan que la cantidad de proyectos que
cumplen los objetivos planteados se encuentran sólo el 32%, por lo que más del 50% de
proyectos no cumplen los objetivos o son cancelados debido a factores relacionados con
los requerimientos de software.
Lo anterior nos indica que a pesar de que existen metodologías para la elicitación de
requerimientos, no se están obteniendo los requerimientos de forma adecuada, por lo que
fue necesaria la realización de un estudio que implique el dominio de las metodologías de
elicitación y que ayude al análisis e identificación de factores que inciden en los resultados
que se están teniendo en los proyectos de desarrollo de software.
La presente tesis aporta una propuesta para la disminución de factores como

requerimientos ambiguos, requerimientos cambiantes por mencionar algunos que inciden
en los proyectos; ya que los requerimientos son la base esencial para que las etapas
posteriores de desarrollo tengan éxito. La metodología que se presenta incorpora
transacciones de los procesos de negocios a fin de modelar las actividades que
intervienen en el sistema que se necesita, en el cual se aplican una serie de acciones a
través de guías y formatos que ayudan a detallar los requerimientos a manera de tener
como producto final una documento de especificación de requerimientos de software.
MERSUTPN (Metodología de Elicitación de Requerimientos de Software Utilizando

Transacciones de los Procesos de Negocios) integra cuatro etapas, estas son: Obtención,
Análisis, Especificación y Validación de Requerimientos, con el objetivo de obtener un
documento de especificación de requerimientos de software bajo el estándar IEEE 830 a
través del uso de esta metodología.
Centro Nacional de Investigación y Desarrollo Tecnológico Página 1

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.

CAPÍTULO 1
1 Generalidades
Dentro de este capítulo se presentan los antecedentes que fueron necesarios para el
desarrollo de la presente tesis, los trabajos relacionados con el tema, también describe el
planteamiento del problema, el objetivo, la justificación y los beneficios, además de los
alcances y limitaciones de este trabajo.
1.1 Antecedentes
En el programa de Maestría en Ciencias de la Computación, particularmente en la

especialidad de Ingeniería de Software que se ofrece en el Centro Nacional de
Investigación y Desarrollo Tecnológico (CENIDET), se han realizado algunos trabajos de
tesis relacionados a la obtención de requerimientos las cuales preceden a esté trabajo de
investigación. A continuación se presenta un breve resumen donde se exponen las
aportaciones de cada trabajo.
a) Ambiente de Modelado y Documentación de Sistemas de Software Utilizando

Diagramas de Casos de Uso [CABR04]
La idea central es brindarle al desarrollador de software un ambiente visual con el que

pueda generar el modelo de requerimientos de un sistema de software, utilizando los
diagramas de casos de uso propuestos por el estándar Lenguaje Unificado de Modelado
(UML, por sus siglas en inglés, Unified Modeling Language).

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 2.1. Identificar la pregunta de decisión principal.
preguntas de 2.2. Identificar las preguntas de decisión secundarias.
decisión,
2.3. Determinar si las preguntas de decisión son Estructuradas,
investigación y
No Estructuradas o Semi-Estructuradas.
actividades
2.4. Identificar las preguntas de investigación. Estas preguntas
operacionales
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 3.1. Para cada actividad operacional se deben identificar los
recursos y datos, estructuras de datos e información, necesarias para
establecer llevarlas a cabo.
relaciones 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.

“Metodología para la Elicitación de Requerimientos de Software Utilizando Transacciones del Proceso de Negocio para la Facturación Electrónica”
Tabla 1.2-2 Comparativa de Trabajos Relacionados
Obtención de un
Procesos
Interacción Documento de Centrada al Centrada al
Trabajos de
Cliente/Experto Requerimientos de usuario experto
Negocios
software
“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.

CAPÍTULO 2
2 Marco Conceptual
Dentro de este capítulo se describen los conceptos necesarios para la comprensión y
desarrollo del trabajo de tesis, considerando a la ingeniería de requerimientos,
transacciones y procesos de negocios, el análisis de dominio orientado a características
(FODA), entre otros.
2.1 Ingeniería de Requerimientos
La ingeniería de software comprende la aplicación de principios científicos para realizar la

transformación ordenada de un problema en una solución elaborada de software, y el
mantenimiento subsecuente de ese software hasta el final de su vida útil. La Ingeniería de
software es más que programar. El proceso de ingeniería de software comienza
generalmente mucho antes que la escritura de líneas de código y continúa por mucho
más tiempo después de la finalización de la versión inicial del programa [Davis93]
La experiencia en la construcción de grandes sistemas mostró que un enfoque
informal para el desarrollo del software no era viable. Los grandes proyectos
frecuentemente tenían años de retraso, costaban mucho más de lo presupuestado, eran
irrealizables, difíciles de mantener y no cubrían la funcionalidad requerida. Nuevas
técnicas y métodos eran necesarios para controlar la complejidad inherente [SOMM02].
Se integraron modelos de ciclo de vida al desarrollo de software compuesto por una
serie de etapas que comprenden todas las actividades, desde que surge la idea de crear
un nuevo producto de software, hasta que el producto deja definitivamente de ser utilizado
por el último de sus usuarios. Existen diferentes modelos de ciclo de vida del desarrollo de
software y la elección de alguno depende del software a realizar, las etapas que incluyen
los modelos en general son: análisis, diseño, codificación, pruebas e implementación
[PRESS02].

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]

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.
Los requerimientos deben contener en sí mismos toda la información

Completo necesaria y no remitir a otras fuentes externas que los expliquen con
más detalle.
Un requerimiento no debe ser contradictorio con otro requerimiento.

Consistente 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.
Un requerimiento es verificable cuando puede ser cuantificado de

Verificable 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 Este proceso trata de identificar la procedencia de los requerimientos
Extracción 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.

CAPÍTULO 3
3 Desarrollo
Este capítulo se divide en tres partes, llevándose a cabo el desarrollo para aportar una
solución al problema planteado:
 En la primera parte se presentan los resultados de la investigación realizada,

utilizando el análisis de dominio orientado a características, enfocándose al
estudio del dominio de la elicitación de requerimientos.
 En la segunda parte se muestran las acciones determinadas que integran la
metodología del presente trabajo.
 En la tercera parte se presenta la metodología desarrollada.
3.1 Análisis de Dominio Orientado a Características
A continuación se presentan los resultados obtenidos tras haber aplicado el método

FODA sobre el dominio de la elicitación de requerimientos. Es importante mencionar que
se realizó una adaptación de los modelos que presenta la metodología FODA, omitiendo
algunos diagramas que integra esta, por lo que hay que aclarar que no fue utilizada en su
totalidad. Cabe resaltar que el aplicar el método FODA no implica desarrollar todas las
actividades de cada una de las fases, ya que estas dependen de lo que se requiera
analizar
La necesidad de estudiar el dominio de la elicitación de requerimientos surge con el

propósito de conocer el domino que abarcará la metodología del trabajo que se plantea,
por lo que fue necesario realizar el análisis aplicando el método FODA para poder

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 Define los requerimientos a un nivel de detalle apropiado necesarios

Requerimiento para el desarrollo del sistema que se necesita, en donde la fuente de
s de Software 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 Se encuentran algunas de las metodologías de elicitación que se
de Elicitación 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 Conjunto de actividades para lograr un objetivo (procesos
negocios 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 De acuerdo a Hernández Sampieri [SAMPIERI06], una metodología de
Metodología investigación considera los siguientes fases:
de  Concebir la idea a investigar.
Investigación  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 Este estándar define un formato y contenido de un documento de
830 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.

Documentos de
Cliente Requerimientos
Experto de Software
Resultado
Información
Metodología de
Elicitación
Transmite
Solicita
Revisa
Proporciona
Estandar IEEE
830
Acciones
Figura 3-3 Diagrama de Contexto
La figura anterior describe todo lo que se procesa dentro de una metodología de

elicitación de requerimientos, la tabla 3-2 muestra cada una de las partes que se
contempla en el diagrama:
Tabla 3-2 Descripción Diagrama de Contexto
Dominio Descripción
Metodología de Procesa la información entrante a través de las acciones
Elicitación 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 Define un formato y contenido de un documento de Especificación
830 de Requerimientos de Software.
Documento de Es el resultado del proceso que se lleva a cabo y que inicia con la
Requerimientos información entrante por parte del cliente y/o experto, en donde a
de Software 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 Obligatoria
software:
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 Obligatoria
negocios
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 Obligatoria
Actividad:
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

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 OF Solicitud electrónica en el Sistema de Información de la
Facturación organización para facturar un servicio
Contrato de CI Acto jurídico mediante el cual se crea, modifican,
ingresos 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 CXC Las cuentas por cobrar establecen el crédito que la
cobrar 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. Se encarga de aprobar las facturas.
Ingresos
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 Seleccionar líneas del programa de pagos, crear OF,
negocio) 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 Seleccionar líneas del programa de pagos, crear OF,
del negocio) 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 Recibir documentación soporte, validar documentación

del negocio) 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 Rol Precondiciones Postcondiciones
la actividad
Seleccionar Automática La persona que Asistente Contrato de Líneas de pago
líneas del registra la ingresos seleccionadas.
programa de orden de autorizado.
pagos facturación
selecciona un
contrato y una o
varias líneas
del programa
de pagos de
acuerdo a lo
que va a
cobrar.
Enviar Manual Una vez que el Asistente Orden de Documentación
documentación asistente recibe facturación enviada
soporte a CXC el correo de aprobada
aprobación de
su orden de
facturación,
envía la
documentación
soporte al área
de CXC.
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 Son los elementos utilizados para
compuerta de controlar la divergencia y convergencia
decisión 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 Estas acciones están definidas de acuerdo a los patrones de modelado
de decisión o que fueron encontrados en el proceso de facturación (Cada compuerta
condición 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  Cuando encontramos un patrón de distribución en paralelo o en
en paralelo 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  Cuando encontramos un patrón de este tipo incluido en nuestro
exclusiva proceso es necesario escoger una de las ramas o alternativas que
(basada en deberá seguirse para continuar el flujo del proceso.
datos)  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 Describir qué valores o variables son necesarios para que se ejecute
Éxito. de manera exitosa la actividad.
Criterio Describir los valores o variables mínimos necesarios para que inicie y
Alternativo: termine de ejecutarse la actividad.
Criterio de Describir en que caso no se realiza la actividad.
Error:
Patrón Secuencia de Actividades: El patrón secuencia, es cuando existe un conjunto de

actividades en donde estas tienen dependencia una con otra, de tal manera que una
actividad deberá terminarse de ejecutar para que pueda iniciar la siguiente actividad.
La secuencia indica que una actividad será habilitada sólo hasta que la actividad
anterior sea ejecutada [BIZAGI11].
Figura 3-8 Representación de Secuencia de Actividades
Cuando se identifique este patrón es importante tener bien detallado los formatos de
Actividad para que estas se ejecuten de manera exitosa, para que el flujo de secuencia
de estos siga su curso.
Patrón Distribución en Paralelo: Es necesaria cuando dos o más actividades

deben ejecutarse de forma concurrente o en paralelo [BIZAGI11] en un punto determinado
del proceso de negocio, en donde se encuentra con dos actividades que deberán
ejecutarse al mismo tiempo, es decir deberán realizarse de manera simultánea para que
pueda continuar el flujo de ejecución del proceso.
Estas podrán identificarse de dos maneras como se muestran en la siguiente tabla

[BIZAGI11], donde en una se utiliza mejor práctica para representar los elementos y en la
otra se realiza de manera simple.

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:
Criterio de
Fracaso:
Tabla 3-17 Guía del Formato de Actividades que se Realizan de Manera Concurrente o
en Distribución en Paralelo
Guía del Formato de Distribución en Paralelo

Actividad: Nombre de la actividad que se realizará de manera simultánea con
otra actividad.
Actividad que la Nombre de la actividad que habilita las actividades que se ejecutaran
habilita. de forma simultánea.
Autor: Nombre de la persona que registro los datos en la forma para
actividad.
Criterio Describir los valores o variables mínimos necesarios para que se inicie
Alternativo: y termine de ejecutarse la actividad.
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:
Criterio de
Fracaso:
Tabla 3-19 Guía del Formato de Actividad Sincronizada
Guía del Formato de Actividad Sincronizada

Actividad: Nombre de la actividad que se inicia cuando dos actividades en
paralelo con completadas.
Actividades que Nombre de las actividades que deberán ejecutase de manera
la habilitan. sincronizada para que se habilite la actividad.
Autor: Nombre de la persona que registro los datos en la forma para
actividad.
Criterio Describir los valores o variables mínimos necesarios para que se inicie
Alternativo: y termine de ejecutarse la actividad.
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:
Criterio de
Fracaso:
Tabla 3-21 Guía del Formato de Selección Exclusiva
Guía del Formato de Selección Exclusiva

Actividad: Nombre de la actividad que representa la condición que deberá
cumplirse para seleccionar el estado o actividad para continuar con la
ejecución del proceso.
Autor: Nombre de la persona que registró los datos en la forma para
actividad.
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 Describir la información necesaria para que se cumpla la condición
Éxito para cualquiera de los estados definidos.
Criterios Cuál es la información mínima para satisfacer la condición para que se
alternos: 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.

Obtención Análisis Especificación Validación
•Panorama •Problemas •Elaborar los •Pruebas

•Objetivos •Alternativas/Sol requerimientos Requerimientos
•Proceso de ución con el Estándar •Correctos
Negocio •Requerimientos IEEE 830 •Entendibles
•Requerimientos detallados •Sin
preliminares Ambigüedades
Figura 3-11 Etapas de la metodología de la tesis
La metodología MERSUTPN se ha representado mediante BPMN como se muestra en la siguiente figura 3-11, en donde se
presenta a más detalle todas las actividades que están implícitas, a comparación de la representación de la metodología mostrada
en la figura 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

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:

Objetivos Documento de
•Entrevistas clientes y •Actores Requerimientos
analistas(expertos) •Operaciones
•Analisis del •Acciones
panorama •Controles
•Entrada
•Salida
Panorama Proceso de negocio
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

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.
Actividades (Operaciones del Nombres de las actividades que se realizarían para
negocio): 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 Nombre de la persona o personas que tienen el rol asignado. El
Cargo del Rol. 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 Es un conjunto de actividades
(Compuesta o incluidas dentro de un proceso.
Subproceso) 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 Son decisiones que toma el usuario
Exclusiva 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:
Proceso de
Subproceso:
Negocio:
Autor: Fecha:
Tipo:
Rol:
Precondición:
Poscondición:
Tabla 3-33 Formato 2 de Actividades del Subproceso
Autor: Fecha:
Proceso de
Subproceso:
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.
Documento de Requerimientos
•Analizar los Requerimientos Detallados
•Detectar problemas en los
requerimientos.
•Entrevista con Clientes •Detallar requerimientos
•Generar alternativas
•Aplicar alternativa seleccionada
Identificación de
Problemas/Alternativas de Solución
Figura 3-17 Etapa 2: Análisis

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:
•Elaborar Documento de
Requerimientos con el
estándar IEEE 830
Documento de
Especificación de
requerimientos
Figura 3-19 Etapa 3: Especificación de Requerimientos
En seguida la representación de la etapa de especificación de Requerimientos en

BPMN.
Figura 3-20 Diagrama Etapa 3: Especificación de Requerimientos
La forma en que este documento se elabore afecta a la solución, ocasionando

problemas en las etapas posteriores de desarrollo del ciclo de vida de la ingeniería de
software.

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  Consiste en generar una lista de términos que pudieran
y abreviaturas 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  Punto específico para detallar los factores
producto (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  Educación
usuarios  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  Se describe la funcionalidad del sistema
requerimientos 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 13. Almacenable electrónicamente
2. Completa 14. Ejecutable/Interpretable
3. Correcta 15. Documentada por importancia relativa
4. Entendible 16. Documentada por estabilidad relativa
5. Verificable 17. Documentada por versión
6. Consistente internamente 18. No redundante
7. Consistente externamente 19. Detallada
8. Realizable 20. Precisa
9. Concisa 21. Reutilizable
10. Con diseño independiente 22. Trazada
11. Traceable 23. Organizada
12. Modificable 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.

Requerimientos entendibles
•Documento de •Documento de
Requerimientos Requerimientos
•Métrica de correctes •Documento de •Métrica de ambigüedad
Requerimientos
•Métrica de entendible
Requerimientos No
Requerimientos correctos
ambiguos
Figura 3-21 Etapa 3: Validación de Requerimientos
En seguida, la representación de la etapa 2 de validación de requerimientos de

BPMN, se muestra en el flujo de secuencia de la realización de las actividades.
Figura 3-22 Diagrama Etapa 4: Validación
A la vez se asume que en todos los casos 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.

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.

CAPÍTULO 4
4 Pruebas
La metodología planteada en este trabajo de tesis se probó aplicando MERSUTPN para la
obtención del SRS que requiere el Instituto de Investigación. Las pruebas realizadas y los
resultados obtenidos se definen dentro de este capítulo.
4.1 Descripción General de las pruebas
El intención de las pruebas realizadas fue comprobar que la metodología pueda ser
utilizada para elaborar un documento de especificación de requerimientos de software de
acuerdo al Estándar IEEE 830 y que el resultado de ésta sea un documento de
requerimientos que cumpla con las características de ser no ambiguos, correctos y
entendibles.
La primera de las pruebas se hizo utilizando la metodología desarrollada en la

presente tesis de acuerdo a un estudio y análisis realizado a través del uso de la literatura
acerca de los procesos de negocios. La segunda prueba fue llevada a cabo con la
metodología elaborada por el Instituto de Investigación, que fue desarrollado de acuerdo a
la experiencia de años de trabajo en el ámbito de procesos de negocios.
En donde el objetivo de ambas metodologías es obtener como producto un

documento de especificación de requerimientos, para cualquier sistema que se requiera
desarrollar.

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.
Obtención Análisis Especificación Validación
•Panorama •Problemas •Elaborar los •Pruebas

•Objetivos •Alternativas/Sol requerimientos Requerimientos
•Proceso de ución con el Estándar •Correctos
Negocio •Requerimientos IEEE 830 •Entendibles
•Requerimientos detallados •Sin
preliminares Ambigüedades
Figura 4-1 MERSUTPN
A continuación se definen cada una de las etapas implementadas a fin de obtener

un documento de especificación de requerimientos para el sistema de facturación
electrónica que se requiere.
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.

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

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
Descripción:
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
Crear órdenes de facturación, para llevar un control de comprobantes

Objetivo: interno de la organizació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
Descripción:
que quede evidencia de las personas que participaron en la aprobación de
la información correspondiente a la factura
Importancia: Alta
Para la organización es importante llevar un control de las personas

Comentarios
participantes para la evaluación previa a la generación de la factura.
Adicionales:
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

F Es un documento utilizado para hacer cuenta y relación
Factura
detallada de mercancías o servicios vendidos.
Orden de OF Solicitud electrónica en el Sistema de Información de la
Facturación organización para facturar un servicio
CI Acto jurídico mediante el cual se crean, modifican,
transfieren o extinguen obligaciones. Contrato de
ingresos se celebra entre las autoridades principales de
Contrato de los clientes de las empresas con la organización, en
ingresos 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.
CXC Las cuentas por cobrar establecen el crédito que la
Cuentas por
empresa otorga a sus clientes, como resultado de la
cobrar
entrega de productos o servicios
Tabla 4-4 Descripción de Rol Asistente
Rol: Asistente

Persona Actual a
Persona 1
Cargo:
Se encarga de registrar las órdenes de facturación en el sistema, así como
Descripción: 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 Actual a
Persona 2
Cargo:
Es el encargado de revisar, aprobar, solicitar cambios y cancelar las
Descripción:
órdenes de facturación.
Comentarios:
Tabla 4-6 Descripción de Rol Departamento de Ingresos
Rol: Departamento de ingresos

Persona Actual a
Persona 3
Cargo:
Se encarga de registrar las facturas dentro del sistema, así como hacer el
Descripción:
registro contable de las mismas.
Comentarios:
Tabla 4-7 Descripción de Rol Jefe del Departamento de Ingresos

Persona Actual a
Persona 4
Cargo:
Descripción: Se encarga de aprobar las facturas.
Comentarios:

Tabla 4-8 Descripción de Rol Tesorero

Persona Actual a
Persona 5
Cargo:
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.

Actividades (Operaciones del Seleccionar líneas del programa de pagos, crear OF, enviar
negocio) 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 Automática La persona que registra la orden de facturación Asistente Contrato de Líneas de pago
programa de pagos selecciona un contrato y una o varias líneas del ingresos seleccionas.
programa de pagos de acuerdo a lo que va a autorizado.
cobrar.
Crear ordenes de Automática Una vez seleccionadas las líneas del programa Asistente Líneas de pago Orden
facturación de pago, se completa la información adicional seleccionas. capturada.
de la orden de facturación.
Enviar aprobación orden Automática El asistente envía la orden de facturación a su Asistente Orden OF en estado en
de facturación jefe asistente. capturada, OF en revisión.
estado de
modificación.
Revisar y validar la orden Automática El jefe asistente compara la orden de Jefe asistente OF en estado en OF revisada
de facturación facturación con la documentación soporte. revisión
Cancelar OF Automática Si el jefe asistente determina que la orden de Jefe asistente OF revisada. OF cancelada
facturación no es válida cancela la orden
Solicitar modificación Automática Si el jefe asistente detecta algún error en la OF, Jefe asistente Orden de OF en estado
solicita a su asistente la corrija. facturación modificación
revisada.
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 modificación

realiza las modificaciones a la OF.
Aprobar OF Automática Si el jefe asistente no detecta errores, aprueba Jefe asistente OF revisada. OF aprobada
la OF.
Enviar documentación Manual Una vez que el asistente recibe el correo de asistente OF aprobada Documentación
soporte a CXC aprobación de su orden de facturación, envía la enviada
documentación soporte al área de CXC.
Recibir documentación Manual El departamento ingresos recibe la Departamento OF aprobada y Documentación
soporte documentación soporte de la OF. ingresos documentación recibida
enviada
Validar documentación Automática El auxiliar revisa la orden de facturación contra Departamento Documentación OF Revisada
soporte y OF la documentación soporte. ingresos recibida
Cancelar OF Automática Si el auxiliar determina que la orden de Departamento OF Revisada OF Cancelada

facturación no es válida cancela la orden. ingresos
Solicitar modificación Automática Si el auxiliar detecta algún error en la OF, solicita Departamento OF Revisada OF en
a su asistente la corrija. ingresos modificación
Generar factura y Automática Si el auxiliar no detecta errores, crea la factura y Departamento OF Revisada Factura creada
completar información completa la información contable necesaria ingresos
Enviar factura aprobación Automática Una vez registrada la factura se envía al Jefe Departamento Factura creada, Factura en
departamento ingresos para su revisión ingresos estado en
Factura revisión
modificada
Recibe notificación de Manual El departamento ingresos recibe la notificación Jefe Factura Notificación
aprobación pendiente de aprobación pendiente. departamento generada y recibida
de ingresos enviada a

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

ingresos contable contable

cancelado corregido.
Revisar registro contable Manual Revisa que no haya inconsistencias dentro del Departamento Registro Registro
registro contable. ingresos contable y contable
factura generado revisado
Revisar registro contable Manual Revisa que no haya inconsistencias dentro del Jefe Registro Registro
registro contable. departamento contable y contable
ingresos factura generado revisado.
Revisar registro contable Manual Revisa que no haya inconsistencias dentro del Tesorero Registro Registro
registro contable. contable y contable
factura generado revisado
Cerrar factura Automática Si se encontraron errores en el registro contable Departamento Registro contable Factura
y no pueden ser corregidos, se cierra la factura. ingresos en revisión 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

 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.
Criterio de Éxito: 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.
Debe existir una línea de pagos con la información correspondiente al

Criterio de
programa de pagos de acuerdo al contrato de ingresos. Si no existe el
Fracaso:
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

 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:
Criterio de Éxito: o Datos del cliente (Identificador, nombre, dirección)
o Datos del proyecto (Identificador, nombre, subprograma)
o Del contrato de ingresos (numero de contrato interno y
externo, fecha)
o Fecha en que se hará el cobro
o Importe que se cobrará
o Concepto por el cual se realiza el cobro
Nota: Para el concepto de cobro puede ser un avance del proyecto o una
fecha pactada en el contrato, etc., los cobros son de acuerdo al contrato.
Para generar un orden de facturación se deberá haber seleccionado un
Criterio Alterno: programa de pagos preliminarmente, además deberá contener la siguiente
información mínima para poder crearla.
Si no se ha seleccionado un programa de pagos de ninguna manera podrá
Criterio de
generarse una orden de facturación.
Fracaso:
Tabla 4-13 Formato de la Actividad Enviar Aprobación OF
Actividad: Enviar aprobación orden de facturación

El asistente envía la orden de facturación a su jefe asistente, dentro de la
Criterio de Éxito:
fecha correspondiente.
Criterio Alterno: No Aplica
Criterio de Que el asistente no envié la orden de facturación a su jefe antes de

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

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
Condición:
actividades de seleccionar línea del programa de pagos y el de crear
ordenes de facturación.
Si la información cumple con lo expuesto en la condición, se lleva a cabo la
Estado 1:
actividad de Aprobar la orden de facturación.
Si la información es incorrecta, con lo que se requiere contenga la orden de
Estado 2: facturación, se lleva a cabo la actividad de Solicitar modificación de la orden
de facturación.
Si la información no cumple con lo que necesita y se determina que la orden
Estado 3: de facturación no es válida, se lleva a cabo la actividad de Cancelar Orden
de facturación.
Para que esta actividad sea exitosa deberá cumplir lo descrito en el estado
Criterio de Éxito:
1.
Criterio de Si no existe la información requerida de las actividades de seleccionar línea

Fracaso: del programa de pagos y el de crear ordenes de facturación.
Tabla 4-15 Formato de la Actividad Cancelar OF
Actividad: Cancelar OF

Se realiza la cancelación correspondiente ya que la orden no es válida y
Criterio de Éxito:
termina el proceso de facturación electrónica.
Criterio Alterno: No Aplica ya que proviene de una actividad de selección exclusiva.
Criterio de
No Aplica ya que proviene de una actividad de selección exclusiva.
Fracaso:

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

Si el encargado de realizar esta tarea detecta algún error en la OF, solicita a
Criterio de Éxito:
la persona correspondiente haga las correcciones necesarias.
Criterio de
Fracaso:
Tabla 4-17 Formato de la Actividad Modificar OF
Actividad: Modificar OF

El asistente recibe notificación con las modificaciones necesarias solicitadas
Criterio de Éxito:
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 No realiza la modificaciones que le fue solicitada, en el tiempo establecido

Fracaso: de manera preliminar en el programa de pagos.
Tabla 4-18 Formato de la Actividad Aprobar OF
Aprobar OF
Actividad:

Si la orden de facturación cuenta con toda la información necesaria
Criterio de Éxito:
descrita con anterioridad, entonces se realiza la aprobación de la orden.
Criterio de
Fracaso:

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

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.
Criterio de Éxito: 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 Al no enviar la notificación en el tiempo establecido y la documentación

Fracaso: correspondiente esta actividad no puede ser completada.
Tabla 4-20 Formato de la Actividad Recibir Documentación de Soporte
Actividad: Recibir documentación soporte

Esta actividad se cumple de manera satisfactoria si el departamento
Criterio de Éxito: 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
Si no se recibe documentación esta actividad no puede ser realizada.
Fracaso:
Tabla 4-21 Formato de la Actividad Validar Documentación de Soporte y OF
Actividad: Validar documentación soporte y OF

La persona encargada de esta actividad revisa la orden de facturación
contra la documentación soporte. La información debe estar respaldada por
Condición: 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)
Estado 1:
actividad de Generar factura y completar información.
Si la información es incorrecta con lo que se requiere contenga la orden de
Estado 2: facturación, se lleva a cabo la actividad de Solicitar modificación de la orden
de facturación.
Si la información no cumple con lo que necesita y se determina que la orden
Estado 3: de facturación no es válida, se lleva a cabo la actividad de Cancelar Orden
de facturación.
Para que esta actividad sea exitosa deberá de cumplir lo descrito en el
Criterio de Éxito:
estado 1.
Criterio de Si no existe la información requerida de las actividades de seleccionar línea
Fracaso: 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

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)
Criterio de Éxito:  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 Si no existe algún dato descrito en el criterio de éxito no se puede llevar a

Fracaso: cabo esta actividad.
Tabla 4-23 Formato de la Actividad Enviar Factura a Aprobación
Actividad: Enviar factura aprobación

Al haber registrado la factura se envía al Jefe departamento ingresos para
Criterio de Éxito:
su revisión.
Criterio Alterno: No Aplica.
Criterio de Si no se envía al jefe del departamento de ingresos la factura esta

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

Si recibió la notificación con la factura correspondiente se continúa con la
Criterio de Éxito:
actividad de Revisar y Validar Factura.
Criterio de
Si no existe notificación con la factura no se realiza la actividad.
Fracaso:

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

La persona encargada de esta actividad revisa la factura cumpla con la
Condición:
información establecida en la actividad de Generar factura.
Estado 1:
actividad de Aprobar Factura.
Si la información es incorrecta con lo que se requiere contenga la factura, se
Estado 2:
lleva a cabo la actividad de Solicitar modificación de la factura.
Si la información no cumple con lo que se requiere contenga la factura, se
Estado 3:
lleva a cabo la actividad de Cancelar factura.
Criterio de Éxito:
estado 1.
Criterio de Si no se recibió la notificación previa con la factura correspondiente, no se
Fracaso: puede ejecutar esta actividad.
Tabla 4-26 Formato de la Actividad Cancelar Factura
Actividad: Cancelar factura

Si la persona encargada de esta actividad del departamento ingresos
Criterio de Éxito: 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
Fracaso:
Tabla 4-27 Formato de la Actividad Solicitar Modificación Factura
Actividad: Solicitar modificación de factura

Si la persona encargada de esta actividad del departamento ingresos
Criterio de Éxito: detecta algún error en la factura, solicita al auxiliar de facturación que
realice las correcciones que sean necesarias.

Criterio de
Fracaso:
Tabla 4-28 Formato de la Actividad Modificar Factura
Actividad: Modificar factura

La persona responsable de esta actividad recibe la notificación con las
Criterio de Éxito: modificaciones que le solicita el jefe asistente, y procede a realizar las
correcciones requeridas a la factura.
Criterio de Si no recibe notificación con las modificaciones que se requieren, no se

Fracaso: realiza la actividad.
Tabla 4-29 Formato de la Actividad Aprobar Factura
Actividad: Aprobar factura

Si el encargado de esta tarea no detecta errores, procede a aprobar la
Criterio de Éxito:
Factura.
Criterio de
Fracaso:
Tabla 4-30 Formato de la Actividad Generar Registro Contable
Actividad: Generar registro contable
Autor: Lucia Morales Morales Fecha: 07/Jul/2011

Para está actividad es necesario seleccionar que facturas se van a generar
Criterio de Éxito:
para realizar el registro en contabilidad.
No Aplica es necesario seleccionar al menos una factura para esta
Criterio Alterno:
actividad.
Criterio de De no seleccionarse alguna factura no se puede proceder a generar un
Fracaso: 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

Esta actividad depende de la anterior, debido a que es importante haber
Criterio de Éxito: generado el registro contable, para proceder a generar la factura con toda
la información que esta requiere para dar cumplimiento a este criterio.
Criterio de
Para realizar esta actividad la factura deberá de estar aprobada.
Fracaso:
Tabla 4-32 Formato de la Actividad Revisar Registro Contable
Actividad: Revisar registro contable

La persona encargada de esta actividad revisa que la factura cumpla con la
información establecida en la actividad Generar Registro Contable.
Condición:
(Esta actividad la realizan los diferentes participantes (ver diagrama del
proceso de facturación) que deberán validar que sea correcto,)
Estado 1:
actividad de Revisar Registro contable.
Si la información es incorrecta con lo que se requiere contenga la factura, se
Estado 2:
lleva a cabo la actividad de Cancelar Registro Contable.
Criterio de Éxito:
estado 1.
Criterio de
Si no existe registro contable no se realiza la actividad.
Fracaso:
Tabla 4-33 Formato de la Actividad Cancelar Registro Contable
Actividad: Cancelar registro contable

Si la persona o la persona encargada de esta actividad determina que el
Criterio de Éxito: registro no es válido, procede a realizar la cancelación correspondiente y
se realiza la actividad de Corregir información.
Criterio de
Fracaso:

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

La persona responsable de esta actividad realiza las correcciones
Criterio de Éxito:
pertinentes solicitadas del registro contable.
Criterio Alterno: No Aplica.
Criterio de
Si el registro contable no está cancelado no se realiza la actividad.
Fracaso:
Tabla 4-35 Formato de la Actividad Cerrar Factura
Actividad: Cerrar factura

Si el encargado de esta actividad encontró errores en el registro contable y
Criterio de Éxito: 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 Si no se realizó una revisión previa del registro contable, no puede

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

En este requerimiento se agregó información que corresponde a otro
requerimiento, por lo que no hay necesidad de la generación de
Alternativas:
alternativas, solo agregar información en el requerimiento Registro
Contable.
De acuerdo al modelo del procesos de negocios, primero se aprueba la
factura, para posteriormente generar el o los registros contables, por lo
que para llevar a cabo esta tarea es necesaria la siguiente información:
 Datos: Folio, Certificado, No. Aprobación, Serie, datos de la factura

 Protección de Datos
Solución: 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.
Resultados
1.0000
0.9500
0.9000
0.8500
0.8000
0.7500
0.7000
No Ambigüedad
Correctitud
Entendibilidad
CP_01 CP_02
Figura 4-3 Grafica de Factores Evaluados en los Casos de Prueba
Los resultados obtenidos de las pruebas son producto de un estudio basado en las
transacciones y los patrones de modelado, obteniendo de estas una descripción detallada
de cada una de las actividades, así como de las condiciones que son requeridas para
estas se realicen y pueda concretarse el objetivo del proceso de negocio con cada una de
las transacciones o negociaciones que se llevan a cabo con los diferentes roles
participantes, los cuales permitieron definir la metodología que fue aplicada a un caso
real, a través del uso de guías y formatos dentro de las cuatro etapas de integran la
metodología.

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.

CAPÍTULO 5
5 Conclusiones
5.1 Conclusiones Generales
La metodología desarrollada en esté trabajo de tesis resulta factible ya que incorpora el

conocimiento de procesos de negocios, a fin de obtener un documento de especificación
de requerimientos de software bajo el estándar IEEE 830, en donde los requerimientos
cumplen cualidades entendibles, correctos y sin ambigüedades.
Por otra parte aunque podemos apreciar en las pruebas, que los resultados más
satisfactorios se obtuvieron con la metodología del Instituto de Investigación, esto es
debido a que si comparamos la forma en que se desarrolló cada una de estas
metodologías, vemos que la presentada en este trabajo fue a partir de la investigación y
análisis acerca de los procesos de negocios de acuerdo a la literatura; en cambio la
metodología del instituto de investigación fue desarrollada en base a la experiencia de
años en el ámbito de los procesos de negocios y al desarrollo de proyectos de software,
así como el tiempo y experiencia de trabajar con la metodología desarrollada por ellos;
ambas metodologías tienen en común los procesos de negocios para la obtención de un
documento de especificación de requerimientos de software.
A pesar que de los resultados obtenidos muestra la factibilidad del desarrollo de

la tesis, es necesario seguir realizando pruebas para comprobar aun más los resultados
que se obtienen al utilizar está metodología. Las pruebas que se realizaron fueron
aplicadas sobre un escenario real de un Instituto de Investigación que da
importancia a los resultados obtenidos con la metodología, esto fue beneficioso para
poner a prueba la metodología propuesta y comparándola con una ampliamente utilizada
por ellos.
La metodología desarrollada consideró como base las transacciones del proceso de

negocio para la facturación electrónica, misma que fue formalizada para poder utilizarla

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/principi
antes/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
Evento de fin ef1

OF Cancelada (jefe de
asistente)
OF Cancelada (departamento Evento de fin ef2
de ingresos)
OF Cancelada (jefe Evento de fin ef3
departamento de ingresos)
Factura cerrada Evento de fin ef4
Factura electrónica generada Evento de Fin ef5

enviada al cliente
Seleccionar líneas del Actividad a1
programa de pagos
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 Actividad a9
soporte a CXC
Recibir documentación Actividad a10
soporte
Validar documentación Actividad a11
soporte y OF
Cancelar OF Actividad a12
Solicitar modificación Actividad a13
Generar factura y completar Actividad a14
información
Enviar factura aprobación Actividad a15
Recibe notificación de a16
aprobación pendiente
Revisar y validar factura Actividad a17
Cancelar factura Actividad a18
Solicitar modificación de Actividad a19
factura
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 Actividad a26
(departamento de ingresos)
Revisar registro Actividad a27
contable(jefe departamento
de ingresos)
Revisar registro contable Actividad a28
(tesorero)
Cerrar factura (departamento Actividad a29
de ingresos, tesorero)
Orden de facturación Compuerta de decisión XOR g1
correcta? (jefe de asistente) basada en datos
Orden de facturación Compuerta de decisión XOR g2
correcta? (departamento de basada en datos
ingreso)
Registro contable Compuerta de decisión XOR g3
(departamento de ingreso) basada en datos
Factura correcta Compuerta de decisión XOR g4
basada en datos
Registro contable (jefe Compuerta de decisión XOR g5
departamento de ingreso) basada en datos
Registro contable (tesorero) Compuerta de decisión XOR g6
basada en datos
A continuación la tabla muestra las abreviaturas utilizadas en la formalización de

proceso de negocio para la facturación electrónica:
Tabla Anexo A-2 Abreviaturas en la Formalización PN

Abreviatura Descripción
O Conjunto de objetos (A, E, G)
A Conjunto de actividades
E Conjunto de eventos (inicio, intermedios, fin )
G Conjunto de compuertas
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 Manual En junta de entrevista entre los Cliente y Programar una Requerimientos
elicitación participantes (cliente y experto (analista)) Analista reunión entre los preliminares
obtienen los requerimientos que se participantes.
requieren para el desarrollo del sistema, a
través de la relación de un conjunto de
actividades.
Revisar que se Manual El analista revisa que se hayan realizado y Analista Requerimientos Actividad de etapa de
hayan realiza completado las actividades preliminares elicitación aceptada y
las actividades correspondientes a la etapa de elicitación. finalizada.
de la etapa
Etapa de Manual Los participantes revisan que se que no Cliente y Requerimientos Requerimientos sin
análisis haya problemas en los requerimientos Analista preliminares y Etapa problemas y
obtenidos en la etapa de elicitación. de elicitación detallados
concluida
Revisar Manual Los participantes revisan que se hayan Cliente y Requerimientos sin Requerimientos
documento de revisado los todos los requerimientos y no Analista problemas y revisados y sin
requerimientos presenten problemas. detallados problemas
Etapa de Manual Los analistas elaboran el documento de Analista Documento de Documento de
Especificación requerimientos en base al estándar IEEE requerimientos Especificación de
de 830. preliminares requerimientos
requerimientos
Revisar que el Manual Los analistas revisan que estén registrados Analista Documento de Documento de
docto. de todos los requerimientos de acuerdo al Especificación de Especificación de
especificación estándar. requerimientos requerimientos
de revisado
requerimientos

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

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

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

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

Identificar Manual En esta actividad es en donde se identifica Analista Documento de Problemas
problemas en el si los requerimientos que fueron registrados requerimientos identificados en los
docto. de req. son los adecuados o es necesario preliminares. requerimientos.
refinarlos.
Elaborar Manual Elaborar alternativas de solución para los Analista Problemas Lista de alternativas
Alternativas problemas identificados. identificados. de solución a los
problemas
Seleccionar Manual Seleccionar las alternativas de solución en Analista Lista de alternativas Alternativas
Alternativas para los problemas en los requerimientos. de solución a los seleccionadas
problemas
Implementar Manual Aplicar alternativas para solucionar los Analista Alternativas Docto. de
alternativas problemas. seleccionadas requerimientos sin
para solución problemas.
Revisar que no Manual Se vuelve a realizar una revisión para Analista Docto. de Docto. de
existan verificar que no existan más problemas en requerimientos sin requerimientos sin
problemas los requerimientos. problemas. problemas revisados
Detallar docto. Manual Es se considera necesario se realiza una Analista Docto. de Docto. de
de req. descripción detallada para el documento de requerimientos sin requerimientos
requerimientos. problemas revisados detallados

Tabla Anexo B-6 Descripción del Subproceso Etapa de Especificación de Requerimientos de la Metodología
Analizar Manual Se realiza un análisis del documento de Analista Documento Documento analizado
documento de requerimientos para poder ir verificando y preliminar de
requerimientos considerando como se va a pasar al requerimientos y
estándar IEEE 830. etapa de análisis
completada.
Elaborar el Manual Se elabora el documento de requerimientos Analista Documento analizado Documento de
docto. de req. de acuerdo al estándar IEEE 830. Requerimientos bajo
con el estándar el estándar IEEE 830
IEEE 830.
Revisar Manual Se revisa que el documento elaborado Analista Documento de Documento de

documento cumpla con el estándar. Requerimientos bajo requerimientos
el estándar IEEE 830 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. Manual Se revisa el documento para aplicar las Analista Documento de Iniciar las actividades
de métricas en los requerimientos registrados. especificación de de implementación de
especificación requerimientos. las métricas.
de
requerimientos
Aplicar métrica Manual Aplica la métrica de correctitud en los Analista Documento de Resultados de
de correctes requerimientos. especificación de correctitud de los
requerimientos. requerimientos
Aplicar métrica Manual Aplica la métrica de entendibilidad en los Analista Documento de Resultados de
de requerimientos. especificación de entendibilidad de los
entendimiento requerimientos. requerimientos
Aplicar métrica Manual Aplica la métrica de no ambigüedad en los Analista Documento de Resultados de no
de No requerimientos. especificación de ambigüedad de los
ambigüedad requerimientos. requerimientos
Revisar que Manual Realiza una revisión que todas las métricas Analista Documento de Todos los
todos los req. fueron implementadas. especificación de requerimientos
fueron requerimientos. aceptados.
validados

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ú InicioBizAgi Process Modeler
Figura Anexo C-1 Pantalla de Selección de la Herramienta BizAgi
b) Clic sobre la aplicación y Abrirá la siguiente ventana en donde se muestra el

ambiente grafico de BizAgi.

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

Automatizacion MC Lucia Morales Morales 2012 PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Automatizacion MC Lucia Morales Morales 2012 PDF

Cargado por

Copyright:

Formatos disponibles

Departamento de Ciencias Computacionales

TESIS DE MAESTRÍA EN CIENCIAS

Metodología para la Elicitación de Requerimientos de Software Utilizando

Lucia Morales Morales

como requisito para la obtención del grado de:

Cuernavaca, Morelos, México. Febrero de 2012

A mis Hermanos: Pedro, Cornelio, Josefa, Xochitl y Lucio

A Diana, Yamileth y Chrystian

A Mis Amigos: Christina, Adrian, Pepe y Pedro Cruz

Gracias al CENIDET, por proporcionarme las oportunidades para mi desarrollo profesional

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

Hoy en día el desarrollo de proyectos de software tiene como base importante la

La presente tesis aporta una propuesta para la disminución de factores como

MERSUTPN (Metodología de Elicitación de Requerimientos de Software Utilizando

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

Today's software development projects have the requirements specification as an

MERSUTPN (Metodología de Elicitación de Requerimientos de Software Utilizando

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Estudios como el “The Chaos Report” [Standish09] mencionan la cantidad de

El presente trabajo se enfoca al desarrollo de software y se centra específicamente

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

En el programa de Maestría en Ciencias de la Computación, particularmente en la

a) Ambiente de Modelado y Documentación de Sistemas de Software Utilizando

La idea central es brindarle al desarrollador de software un ambiente visual con el que

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

b) Definición e Implementación de un Perfil UML para la Adquisición de

c) Método de trabajo arquitectónico en grupo [GONZ06]

Esta tesis define un método AGD (Desarrollo Arquitectónico en Grupo) para

1.2 Trabajos Relacionados

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

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

La metodología consta de tres fases: elaboración de modelos de negocio, la

En la figura 1-1 se muestra el marco de la metodología, en donde la idea principal

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

1.2.2 Una propuesta Metodológica para Modelar Procesos de Negocios de

Este trabajo propone una herramienta basada en la Notación de Modelado de Procesos

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

El Modelo de Procesos de Negocio (MPN) se define como un conjunto de