Analisis Comparativo PDF

FACULTAD DE INGENIERÍAS Y ARQUITECTURA
PROGRAMA DE INGENIERÍA DE SISTEMAS
TRABAJO PRESENTADO PARA OPTAR POR EL TITULO DE

INGENIERO DE SISTEMAS
TÍTULO
ANALISIS COMPARATIVO DE TECNICAS DE OBTENCION DE

REQUERIMIENTOS PARA EL MODULO DE FACTURACION DEL
APLICATIVO GESTASOFT HOSPITALARIO PARA IMSALUD.
AUTORA
ADRIANA MILENA RANGEL CARRILLO
DIRECTOR
MS. C WILLIAM MAURICIO ROJAS
PAMPLONA COLOMBIA
ENERO DE 2007
UNIVERSIDAD DE PAMPLONA
FACULTAD DE INGENIERÍAS Y ARQUITECTURA
DEPARTAMENTO DE INGENIERÍA ELÉCTRICA, ELECTRÓNICA, SISTEMAS Y
TELECOMUNICACIONES
PROGRAMA DE INGENIERÍA DE SISTEMAS
Siendo las ______ horas, del día _____ del mes ______ _del año ________
El jurado calificador conformado por:

Presidente: C. Dr. Luís Alberto Esteban
Oponente: MS.c. Ailin Orjuela Duarte
Secretario: Ing. Jorge Omar Portilla
Terminadas las deliberaciones he llegado a las siguientes conclusiones:
PRIMERA CONCLUSIÓN: OTORGAR LA CALIFICACIÓN DE
_______________________________________________________________
Aprobado, Excelente, Incompleto

(Reg. Estudiantil Cap. VIII, Art. 90)
AL TRABAJO DE GRADO TITULADO:
“ANÁLISIS COMPARATIVO DE TÉCNICAS DE OBTENCIÓN DE REQUERIMIENTOS

PARA EL MODULO DE FACTURACIÓN DEL APLICATIVO GESTASOFT
HOSPITALARIO PARA IMSALUD”.
De la autora: Adriana Milena Rangel Carrillo

Director: MS.c. William Mauricio Rojas
SEGUNDA CONCLUSIÓN: RECOMENDAR
1. Recomendar para presentar en eventos científicos: ____________

2. Recomendar para publicación: ____________
3. Incluir en el fondo bibliográfico de la Universidad de Pamplona: ____________
4. Recomendar para ser continuado en otros trabajos: ____________
5. Recomendar para patente: ____________
6. Recomendar continuar como trabajo de maestría: ____________
7. Recomendar continuar como trabajo de doctorado: ____________
8. Recomendar para categoría de meritorio: ____________
9. Recomendar para categoría de Laureado: ____________
10. Otras____________________________________________ ____________
TERCERA CONCLUSIÓN: OTORGAR
EL TITULO DE INGENIERO:
FIRMAS DEL JURADO
___________________ _________________ __________________

PRESIDENTE OPONENTE SECRETARIO
Dedicatoria
La esperanza es el sueño del hombre despierto… (Aristóteles)

Esperanza que ilumina mi vida en cada recuerdo, recuerdos que permiten saborear la
dulzura de mi Mamá Celina quien siempre está conmigo para mostrarme el camino y
acompañarme en mis silencios.
Dedico este logro a su presencia…
Al refugio cálido de mi tía Yolanda,

Al apoyo incondicional de mi tía Martha que trasciende fronteras,
A la palabra de ánimo de mi tía Alix,
A la personita que acompaña mis sueños y acoge mis temores en su esencia, Leady
A aquella fuerza necesaria en mi vida, mi Papá
A quien siempre camina conmigo sin importar el terreno, Néstor
A todos aquellos que incondicionalmente me brindaron su apoyo, mi Familia.
Y al ser que hace posible que la esperanza llegue a nuestros corazones y los sueños se
hagan realidad, Dios.
Pensamiento
"Solo es útil el conocimiento que nos hace mejores."

Sócrates
Agradecimientos
Agradezco a Dios y la virgen quienes iluminan y guían mis pensamientos.
Al profesor William Mauricio Rojas por su apoyo y dedicación, a la profesora Luz

Marina Santos que durante estos años me enseñó a valorar cada gota de conocimiento,
al profesor Luís Alberto Esteban, Jorge Omar Portilla y demás docentes que ayudaron
a forjar este sueño.
A toda mi familia en la cual están incluidos mis amigos y amigas que entre risas,
paciencia y colaboración acompañaron la huella de cada paso.
Al Ingeniero Avilio Villamizar y demás personal de la Vicerrectoria de Gestión y

Desarrollo Tecnológico de la Universidad de Pamplona, por acogerme en su familia y
permitirme presenciar el ocaso de una etapa y el alba de una nueva oportunidad.
RESUMEN
La base de un proyecto de desarrollo software lo constituyen los requerimientos

que soportan su estructura y definen su dinámica. Para garantizar que el
producto final satisfaga las necesidades y expectativas de los usuarios, se
debe construir con requerimientos tomados del ambiente real del negocio, los
cuales sean consistentes y actuales.
El Modelamiento del Negocio facilita la recolección de información necesaria

para desarrollar de manera iterativa los diferentes puntos visuales del entorno
de la organización objetivo. Esta información constituye los cimientos
fundamentales de la Obtención de Requerimientos.
La Obtención de Requerimientos es la fase de la cual depende en gran medida

el grado de éxito del proyecto, por tal razón es necesario aplicar un método
flexible, iterativo y orientado en el usuario, el cual haga uso de un conjunto de
técnicas y herramientas que faciliten la extracción, análisis, especificación y
validación de los requerimientos del producto.
En este documento se presenta al Modelamiento del Negocio y la Obtención de

Requerimientos como solución a algunas causas de los fracasos de los
proyectos de software, reduciendo gran parte de su sobrecosto, permitiendo la
estimación de tiempo y esfuerzos acordes a la realidad, y facilitando la
elaboración de un producto con calidad.
ABSTRACT
The basis of a Project of development / software is constituted by the requests

that support its structure and define its dynamics. To guarantee that the final
product satisfies the needs and the users’ expectations, it must build with
request taken from the real business environment which they must be
consistent and currents.
The Business Model facilitates the gathering of necessary information to

develop different visual points from the objective organization environment in an
iterative way. This information represents the principal foundation of the
request obtaining.
The project’s success depends on the Request Obtaining phase for this reason,
it’s necessary to apply a flexible, iterative method oriented in the user, who will
use a set of techniques and tools that facilitates the extraction, analysis,
specification and validation of the product’s request.
In this document “the Business Model” and “the Request Obtaining” are shawn
as solution to some failures‘ causes from the software’s projects reducing
overcost, allowing the estimation of time and efforts, according to the reality and
facilitating the elaboration of a product with quality.
Modelo del Negocio y Obtención de Requerimientos
INDICE
LISTA DE FIGURAS .......................................................................................... 7
LISTA DE TABLAS .......................................................................................... 12
LISTA DE ANEXOS ......................................................................................... 13
INTRODUCCION ............................................................................................. 14
JUSTIFICACION.............................................................................................. 16
PROBLEMA ..................................................................................................... 18
OBJETIVOS..................................................................................................... 19
1. MARCO TEORICO ...................................................................................... 20
1.1 MODELO DEL NEGOCIO.......................................................................... 20
1.1.1 Escenarios .............................................................................................. 21
1.1.2 Método del Modelamiento del Negocio BMM.......................................... 23
1.1.2.1 Modelo del Producto de BMM.............................................................. 24
1.1.2.1.1 Metas del Negocio ............................................................................ 24
1.1.2.1.2 Procesos del Negocio ....................................................................... 24
1.1.2.1.3 Actores, Unidades y Estructura del Negocio..................................... 25
1.1.2.1.3.1 Actores........................................................................................... 25
1.1.2.1.3.2 Unidades del Negocio .................................................................... 26
1.1.2.1.4 Tecnologías ...................................................................................... 26
1.1.2.1.5 Reglas del Negocio ........................................................................... 26
1.1.2.1.6 Objetos del Negocio.......................................................................... 26
1.1.2.1.7 Eventos ............................................................................................. 27
-1-
1.1.2.2 Modelo del Equipo ............................................................................... 27
1.1.2.3 El proceso de modelado del Negocio .................................................. 28
1.2 OBTENCION DE REQUERIMIENTOS ...................................................... 29
1.2.1 Proceso de la Ingeniería de Requerimientos .......................................... 31
1.2.1.1 Extración, Captura o Elicitación de Requerimientos ............................ 34
1.2.1.2 Análisis................................................................................................. 36
1.2.1.3 Especificación ...................................................................................... 37
1.2.1.4 Validación ............................................................................................ 37
1.2.2 Técnicas de Obtención de Requerimientos ............................................ 38
1.2.2.1 Entrevistas y cuestionarios .................................................................. 39
1.2.2.2 Sistemas existentes ............................................................................. 39
1.2.2.3 Grabaciones de video y de audio......................................................... 40
1.2.2.4 Tormenta de ideas (Brainstorming)...................................................... 40
1.2.2.5 Arqueología de Documentos................................................................ 41
1.2.2.6 Aprendiz............................................................................................... 41
1.2.2.7 Observación......................................................................................... 42
1.2.2.8 Talleres de trabajo basados en los casos de uso (Run Use Case
Workshop)........................................................................................................ 42
1.2.2.9 Prototipos............................................................................................. 43
1.2.2.10 DOFA ................................................................................................. 44
1.2.2.11 Cadena de valor................................................................................. 45
1.2.2.12 Modelo de clase conceptual............................................................... 45
1.2.2.13 Diagrama de Pescado........................................................................ 46
1.2.2.14 Glosario.............................................................................................. 46
1.2.2.15 DCO ................................................................................................... 47
1.2.2.16 Diagrama de Actividad ....................................................................... 47
-2-
1.2.2.17 Documento ESRE / Casos de Uso .................................................... 47
1.2.2.18 Casa de Calidad QFD ........................................................................ 48
1.2.2.19 Checklist ............................................................................................ 49
1.3 METODOLOGIAS DE OBTENCION DE REQUERIMIENTOS .................. 49
1.3.1 Metodología DoRCU ............................................................................... 49
1.3.2 Goal – Bases Requirements Analysis Method ........................................ 55
1.3.2.1 Enfoque de escenarios de Leite........................................................... 56
1.3.2.1.1 Léxico Extendido del Lenguaje (LEL) ............................................... 57
1.3.3 SSM Soft System Methodology .............................................................. 60
1.3.4 Color - X.................................................................................................. 63
1.3.5 Rare - Idiom ............................................................................................ 64
1.3.6 RUP (Rational Unified Process).............................................................. 66
1.3.7 Desarrollo Conjunto de Aplicaciones ...................................................... 68
2. DISEÑO METODOLOGICO......................................................................... 69
2.1 METODO DE INVESTIGACION ................................................................ 69
2.1.1 Las diversas clases de métodos de investigación .................................. 69
2.1.1.1 Métodos lógicos ................................................................................... 69
2.1.1.1.1 Método lógico deductivo ................................................................... 69
2.1.1.1.2 Método hipotético - deductivo ........................................................... 70
2.1.1.1.3 Método lógico inductivo..................................................................... 71
2.1.1.1.4 Método lógico: la analogía ................................................................ 71
2.1.1.1.5 El método histórico ........................................................................... 72
2.1.1.1.6 Método sintético ................................................................................ 72
2.1.1.1.7 Método analítico................................................................................ 72
2.1.1.1.8 Método de la abstracción .................................................................. 73
-3-
2.1.1.1.9 Método de la concreción ................................................................... 73
2.1.1.1.10 Método genético ............................................................................. 73
2.1.1.1.11 Método de la modelación ................................................................ 73
2.1.1.1.12 Método sistémico ............................................................................ 74
2.1.1.1.13 Método dialéctico ............................................................................ 74
2.1.1.2 Método empíricos ................................................................................ 75
2.1.1.2.1Observación científica........................................................................ 75
2.1.1.2.2 La experimentación científica............................................................ 75
2.1.1.2.3 La medición....................................................................................... 76
2.2 DISEÑO METODOLOGICO....................................................................... 77
3. MODELO DEL NEGOCIO............................................................................ 87
3.1 METODO DE MODELAMIENTO DEL NEGOCIO BMM ............................ 87
3.1.1 Modelo del Producto ............................................................................... 87
3.1.1.1 Metas del Negocio ............................................................................... 87
3.1.1.2 Procesos del Negocio .......................................................................... 89
3.1.1.3 Actores, Unidades y Estructura del Negocio...................................... 107
3.1.1.3.1 Actores............................................................................................ 107
3.1.1.3.2 Unidades del Negocio ..................................................................... 132
3.1.1.4 Tecnologías ....................................................................................... 135
3.1.1.5 Reglas del Negocio ............................................................................ 136
3.1.1.6 Objetos del Negocio........................................................................... 138
3.1.1.7 Eventos .............................................................................................. 144
3.1.2 Modelo del Equipo ................................................................................ 144
3.1.3 Proceso de Modelado del Negocio ....................................................... 146
-4-
4. METODO PROPUESTO PARA LA OBTENCION DE

REQUERIMIENTOS ...................................................................................... 154
4.1 ANALISIS DE TECNICAS Y HERRAMIENTAS ....................................... 154
4.2 TECNICAS Y HERRAMIENTAS SELECCIONADAS............................... 157
4.3 METODO PARA LA OBTENCION DE REQUERIMIENTOS ................... 157
4.3.1 Captura ................................................................................................. 160
4.3.2 Análisis.................................................................................................. 160
4.3.3 Especificación ....................................................................................... 161
4.3.4 Validación ............................................................................................. 161
4.3.5 Prácticas ............................................................................................... 162
4.4 APLICACIÓN DEL METODO A LA OBTENCION DE

REQUERIMIENTOS ...................................................................................... 163
4.4.1 Captura ................................................................................................. 163
4.4.2 Análisis.................................................................................................. 164
4.4.3 Especificación ....................................................................................... 165
4.4.4 Validación ............................................................................................. 166
4.5 RESULTADOS OBTENIDOS DE LA APLICACIÓN DEL METODO ........ 166
4.5.1 Requerimientos obtenidos .................................................................... 166
4.5.2 Diagrama de casos de uso ................................................................... 168
4.5.3 Cadena de valor.................................................................................... 173
4.5.4 DCO (Documento de Concepto de Operaciones)................................. 173
4.5.4.1 Descripción de la Empresa Social del Estado IMSALUD................... 173
4.5.4.2 Organigrama de la Empresa .............................................................. 176
4.5.4.3 Misión................................................................................................. 176
4.5.4.4 Visión ................................................................................................. 177
4.5.4.5 Prestación de Servicios de Salud ...................................................... 177
4.5.5 QFD ...................................................................................................... 179
-5-
4.6 RELACION ENTRE EL MODELADO DEL NEGOCIO Y EL METODO

PROPUESTO PARA LA OBTENCIÓN DE REQUERIMIENTOS................... 181
5. EL MODELO DEL NEGOCIO Y LA OBTENCION DE REQUERIMIENTOS

COMO SOLUCION A ALGUNAS DE LAS CAUSAS DE FRACASOS DE LOS
PROYECTOS DE SOFTWARE ..................................................................... 184
5.1 FRACASO DE LOS PROYECTOS SOFTWARE..................................... 184
5.1.1 Por qué fracasan los proyectos?........................................................... 184
5.1.2 Causas de los fracasos de los proyectos en Colombia......................... 190
5.2 EL MODELO DEL NEGOCIO Y LA OBTENCION DE REQUERIMIENTOS

COMO SOLUCION A LOS FRACASOS DE LOS PROYECTOS
SOFTWARE................................................................................................... 191
ANALISIS ECONOMICO Y ADMINISTRATIVO............................................. 194
ANALISIS DE LEGALIDAD............................................................................ 196
CONCLUSIONES .......................................................................................... 197
RECOMENDACIONES.................................................................................. 200
ANALISIS BIBLIOGRÁFICO .......................................................................... 201
REFERENCIAS BIBLIOGRAFICAS......................................................... 201
REFERENCIAS WEB .............................................................................. 202
ANEXOS ........................................................................................................ 205
-6-
LISTA DE FIGURAS
Figura 1 Ubicación del método BMM en un modelo de procesos de sistemas

de información y Desarrollo de software.......................................................... 23
Figura 2 Diagrama de relación entre actores - roles - unidades y procesos del
negocio ............................................................................................................ 25
Figura 3 Proceso de modelado del negocio.................................................... 29
Figura 4 Posible visión de la ingeniería de requerimientos [POHL, 1994] ...... 30
Figura 5 Proceso de la Ingeniería de Requerimientos [LOCOPOULOS et all,
1995]................................................................................................................ 31
Figura 6 Proceso de la Ingeniería de Requerimientos [KOTONYA et all, 1997]
…….................................................................................................................. 31
Figura 7 Proceso de la Ingeniería de Requerimientos [KOTONYA et all, 1997],
un modelo en espiral........................................................................................ 32
Figura 8 Proceso de la Ingeniería de Requerimientos [POHL, 1996].............. 32
Figura 9 Modelo de madurez para la Ingeniería de Requerimientos
[SOMMERVILLE, 1997] ….. ............................................................................ 33
Figura 10 Diagrama de actividad de la ingeniería de Requerimientos ............ 34
Figura 11 Diagrama de actividad de la Extracción de Requerimientos ........... 35
Figura 12 Diagrama de actividad del Análisis de Requerimientos .................. 36
Figura 13 Diagrama de pescado ..................................................................... 46
Figura 14 Metodología DoRCU ....................................................................... 51
Figura 15 Diagrama Entidad - Relación para el modelo del Léxico Extendico
del Lenguaje .................................................................................................... 58
Figura 16 Modelo del Léxico Extendico del Lenguaje ..................................... 59
Figura 17 Formas utilizadas en SSM .............................................................. 60
Figura 18 Los siete estados del modelo de SSM ............................................ 61
Figura 19 Forma de trabajar con COLOR - X.................................................. 63
Figura 20 Reuso de ERS anteriores ............................................................... 64
Figura 21 Flujo de trabajo de la disciplina de requerimientos ......................... 66
-7-
Figura 22 Cadena de valor.............................................................................. 89

Figura 23 Jerarquía de procesos de la División de Atención en Salud ........... 90
Figura 24 Jerarquía de procesos del Departamento de Promoción y Prevención
………………………………………………………………………………………….91
Figura 25 Jerarquía de procesos de Farmacia................................................ 92
Figura 26 Jerarquía de procesos de Almacén................................................. 93
Figura 27 Procesos Primarios y de Soporte de la División de Atención en
Salud) .............................................................................................................. 94
Figura 28 Procesos Primarios y de Soporte del Departamento de Promoción y
Prevención)...................................................................................................... 95
Figura 29 Procesos Primarios y de Soporte de Farmacia............................... 95
Figura 30 Procesos Primarios y de Soporte de Almacén................................ 96
Figura 31 Diagrama del proceso: Gestionar atención en salud....................... 96
Figura 32 Diagrama del proceso: Gestionar calidad ....................................... 97
Figura 33 Diagrama del proceso: Gestionar cita ............................................. 97
Figura 34 Diagrama del proceso: Gestionar consultas - Facturación y Servicio
de Enfermería .................................................................................................. 98
Figura 35 Diagrama del proceso: Elaborar contratos con ARS....................... 98
Figura 36 Diagrama del proceso: Elaborar informes....................................... 99
Figura 37 Diagrama del proceso: Gestionar glosas ........................................ 99
Figura 38 Diagrama del proceso: Gestionar HIstoria clínica y RIPS ............. 100
Figura 39 Diagrama del proceso:Gestionar hospitalización .......................... 100
Figura 40 Diagrama del proceso: Gestionar examen de laboratorio ............. 101
Figura 41 Diagrama del proceso: Gestionar personal médico y paramédico 101
Figura 42 Diagrama del proceso: Gestionar programas de DI - DP - PE...... 102
Figura 43 Diagrama del proceso: Gestionar coves ....................................... 102
Figura 44 Diagrama del proceso: Gestionar equipos e insumos................... 103
Figura 45 Diagrama del proceso: Gestionar programas de atención ............ 103
Figura 46 Diagrama del proceso: Seguir y controlar actividades de Promoción y
Prevención ..................................................................................................... 104
Figura 47 Diagrama del proceso: Controlar farmacias satélites.................... 104
Figura 48 Diagrama del proceso: Gestionar inventario ................................. 105
-8-
Figura 49 Diagrama del proceso: Gestionar medicamentos ......................... 105

Figura 50 Diagrama del proceso: Gestionar bienes ...................................... 106
Figura 51 Diagrama del proceso: Gestionar mercancías .............................. 106
Figura 52 Diagrama Actor / Role: Gestionar atención al cliente.................... 113
Figura 53 Diagrama Actor / Role: Gestionar calidad ..................................... 113
Figura 54 Diagrama Actor / Role: Gestionar citas ......................................... 114
Figura 55 Diagrama Actor / Role: Gestionar consultas ................................. 114
Figura 56 Diagrama Actor / Role: Elaborar contratos con ARS..................... 115
Figura 57 Diagrama Actor / Role: Gestionar examen de laboratorio............. 115
Figura 58 Diagrama Actor / Role: Gestionar facturación............................... 116
Figura 59 Diagrama Actor / Role: Gestionar glosas ...................................... 116
Figura 60 Diagrama Actor / Role: Gestionar Historia clínica y RIPS ............. 117
Figura 61 Diagrama Actor / Role: Gestionar hospitalización ......................... 117
Figura 62 Diagrama Actor / Role: Elaborar informes..................................... 118
Figura 63 Diagrama Actor / Role: Gestionar personal médico y paramédico 118
Figura 64 Diagrama Actor / Role: Gestionar programas de DI - DP - PE...... 119
Figura 65 Diagrama Actor / Role: Gestionar coves ....................................... 119
Figura 66 Diagrama Actor / Role: Gestionar equipos e insumos................... 120
Figura 67 Diagrama Actor / Role: Gestionar programas de atención............ 120
Figura 68 Diagrama Actor / Role: Seguir y Controlar actividades de Promoción
y Prevención .................................................................................................. 121
Figura 69 Diagrama Actor / Role: Gestionar farmacias satélites................... 121
Figura 70 Diagrama Actor / Role: Gestionar inventario................................. 122
Figura 71 Diagrama Actor / Role: Gestionar medicamentos ......................... 122
Figura 72 Diagrama Actor / Role: Gestionar bienes...................................... 123
Figura 73 Diagrama Actor / Role: Gestionar mercancías.............................. 123
Figura 74 Diagrama Role / Actividad: Auxiliar Administrativo ....................... 124
Figura 75 Diagrama Role / Actividad: Auxiliar ............................................... 124
Figura 76 Diagrama Role / Actividad: Auxiliar operativo ............................... 125
Figura 77 Diagrama Role / Actividad: Bacteriólogo....................................... 125
Figura 78 Diagrama Role / Actividad: Cajero ................................................ 125
Figura 79 Diagrama Role / Actividad: Coordinador IPS ................................ 126
-9-
Figura 80 Diagrama Role / Actividad: Digitador ............................................ 126

Figura 81 Diagrama Role / Actividad: Funcionario comité de bajas .............. 126
Figura 82 Diagrama Role / Actividad: Gerente.............................................. 127
Figura 83 Diagrama Role / Actividad: Jefe de Almacén ................................ 127
Figura 84 Diagrama Role / Actividad: Jefe del departamento de personal ... 127
Figura 85 Diagrama Role / Actividad: Jefe de división de atención en salud 128
Figura 86 Diagrama Role / Actividad: Jefe PAI ............................................. 128
Figura 87 Diagrama Role / Actividad: Jefe de presupuesto y contabilidad ... 128
Figura 88 Diagrama Role / Actividad: Jefe de promoción y prevención ........ 129
Figura 89 Diagrama Role / Actividad: Jefe de servicios generales ............... 129
Figura 90 Diagrama Role / Actividad: Jurídico .............................................. 129
Figura 91 Diagrama Role / Actividad: Médico ............................................... 130
Figura 92 Diagrama Role / Actividad: Odontólogo ........................................ 130
Figura 93 Diagrama Role / Actividad: Promotor de salud ............................. 131
Figura 94 Diagrama Role / Actividad: Regente de farmacia ......................... 131
Figura 95 Diagrama Role / Actividad: Secretaria .......................................... 131
Figura 96 Diagrama Role / Actividad: Tesorero ............................................ 132
Figura 97 Organigrama de la ESE IMSALUD ............................................... 132
Figura 98 Parte del diagrama de objetos ...................................................... 143
Figura 99 Diagrama de actividad: Gestionar atención al cliente ................... 146
Figura 100 Diagrama de actividad: Gestionar calidad................................... 146
Figura 101 Diagrama de actividad: Gestionar cita ........................................ 147
Figura 102 Diagrama de actividad: Gestionar consultas............................... 147
Figura 103 Diagrama de actividad: Elaborar contrato con ARS .................... 147
Figura 104 Diagrama de actividad: Gestionar servicio de enfermeria........... 148
Figura 105 Diagrama de actividad: Gestionar facturación ............................ 148
Figura 106 Diagrama de actividad: Gestionar glosas.................................... 148
Figura 107 Diagrama de actividad: Gestionar Historia clínica y RIPS........... 148
Figura 108 Diagrama de actividad: Gestionar hospitalización ...................... 149
Figura 109 Diagrama de actividad: Elaborar informes .................................. 149
Figura 110 Diagrama de actividad: Gestionar examen de laboratorio .......... 149
- 10 -
Figura 111 Diagrama de actividad: Gestionar personal médico y

paramédico .................................................................................................... 150
Figura 112 Diagrama de actividad: Gestionar programas de DI - DP - PE ... 150
Figura 113 Diagrama de actividad: Gestionar coves..................................... 150
Figura 114 Diagrama de actividad: Gestionar equipos e insumos ................ 150
Figura 115 Diagrama de actividad: Gestionar programas de atención ......... 151
Figura 116 Diagrama de actividad: Seguir y controlar actividades de Promoción
y Prevención .................................................................................................. 151
Figura 117 Diagrama de actividad: Gestionar farmacias satélites ................ 151
Figura 118 Diagrama de actividad: Gestionar medicamentos....................... 152
Figura 119 Diagrama de actividad: Gestionar inventario .............................. 152
Figura 120 Diagrama de actividad: Gestionar bienes ................................... 152
Figura 121 Diagrama de actividad: Gestionar mercancías ........................... 153
Figura 122 Método propuesto para la Obtención de Requerimientos ........... 159
Figura 123 Etapas y Sub-Etapas del método propuesto para la obtención de
requerimientos ............................................................................................... 159
Figura 124 Diagrama de Casos de Uso general ........................................... 168
Figura 125 Diagrama de Casos de Uso de Almacén .................................... 169
Figura 126 Diagrama de Casos de Uso de Farmacia ................................... 170
Figura 127 Diagrama de Casos de Uso de la División de Atención en
Salud…… ..................................................................................................... 171
Figura 128 Diagrama de Casos de Uso del Departamento de Promoción y
Prevención .................................................................................................... 172
Figura 129 Cadena de valor.......................................................................... 173
Figura 130 Organigrama ESE IMSALUD ...................................................... 176
Figura 131 Distribución de IPS...................................................................... 177
Figura 132 Factores de daño o cancelación ................................................. 187
Figura 133 Origen de los errores de proyectos software .............................. 188
Figura 134 Costo relativo de corregir un error de software ........................... 188
- 11 -
LISTA DE TABLAS
Tabla 1 Técnicas y herramientas de Obtención de Requerimientos ............... 38

Tabla 2 Esquema de objetivo de GBRAM ....................................................... 55
Tabla 3 Esquema de escenario de Leite ......................................................... 57
Tabla 4 Reuso mediante las actividades del proceso de Obtención de
Requerimientos................................................................................................ 65
Tabla 5 Objetivos específicos y Metas del Negocio ........................................ 87
Tabla 6 Reglas del negocio ........................................................................... 136
Tabla 7 Objetos del Negocio ......................................................................... 138
Tabla 8 Eventos del Negocio......................................................................... 144
Tabla 9 Líder del Proyecto ............................................................................ 144
Tabla 10 Usuarios expertos........................................................................... 144
Tabla 11 Analistas del Negocio ..................................................................... 145
Tabla 12 Análisis de Técnicas y Herramientas.............................................. 154
Tabla 13 Técnicas y Herramientas seleccionadas ........................................ 157
Tabla 14 Etapa de captura de Requerimientos ............................................. 163
Tabla 15 Etapa de Análisis de Requerimientos ............................................. 164
Tabla 16 Etapa de Especificación de Requerimientos .................................. 165
Tabla 17 Etapa de Validación de Requerimientos......................................... 166
Tabla 18 Matriz QFD ..................................................................................... 179
Tabla 19 Relación entre el modelamiento del negocio y la obtención de
requerimientos ............................................................................................... 183
Tabla 20 Factores de daño o cancelación..................................................... 186
Tabla 21 Origen de los errores de proyectos software .................................. 187
Tabla 22 Costo relativo de corregir un error de software............................... 188
Tabla 23 Factores críticos de éxito de un proyecto ....................................... 189
Tabla 24 Opiniones de expertos sobre los fracasos de proyectos TI en
Colombia........................................................................................................ 190
Tabla 25 Posibles soluciones a algunas de las causas de los fracasos de los
proyectos de software.................................................................................... 193
- 12 -
LISTA DE ANEXOS
Anexo 1. Análisis comparativo de Metodologías utilizadas en la Obtención de

Requerimientos.
Anexo 2. Glosario
Anexo 3. Plantillas
Anexo 4. Siglas
- 13 -
INTRODUCCION
Antes de empezar a diseñar un software, es necesario saber qué se quiere

construir realmente, las necesidades y problemas que se deben suplir. Dejar
bien claro lo que los interesados en el software desean de él no es tarea fácil
pues intervienen en esta labor de investigación factores técnicos,
administrativos, económicos, sociales, y ambientales.
Es de vital importancia contar con información actual y real, la cual sea la base
para definir el alcance del sistema a realizar, por esta razón el desarrollo de un
Modelamiento del Negocio, como proyecto aparte o como parte del proyecto de
desarrollo de software, facilita la obtención y análisis de dicha información, de
esta manera el equipo de trabajo conoce la ejecución de los procesos de la
organización objetivo, su cadena de valor, las fortalezas y oportunidades por
explotar, las debilidades y amenazas por corregir y mitigar, y demás datos de
interés que describan y permitan visualizar el ambiente en el cual se instalará el
sistema y la forma de trabajo de cada uno de los entes involucrados en la
organización, con el objetivo de producir un software a la medida que satisfaga
las necesidades del usuario.
El modelo del negocio provee una amalgama de artefactos (tales como

documentos, diagramas y modelos) que pueden utilizarse en la fase
fundamental del desarrollo de software, la Obtención de Requerimientos, con
esta información se puede construir la base estructural para desarrollar el
proyecto, todos estos esfuerzos con el objetivo de proveer soporte a las tres
situaciones que se presentan en la Obtención de Requerimientos. En la
primera se encuentran los aspectos humanos, que es donde el analista o
ingeniero de requerimientos conocerá a sus interesados (clientes, usuarios,
proveedores de información) y su medio ambiente. En la segunda el analista
tratará de modelar los requerimientos y resolver conflictos entre ellos mismos,
los cuales surgen de los diferentes puntos de vista de los interesados. En la
- 14 -
tercera, el analista debe contemplar la traducción de los requerimientos a una

notación clara para el diseñador. En todo momento el analista se enfrenta a
problemas que van desde la definición del alcance, dominio del problema,
estimaciones y planeación del proyecto hasta la decisión de lo que realmente
es importante incluir en el software para considerarse exitoso, pasando por la
resolución de conflictos y asignación de prioridades a los requerimientos.
En este proyecto se realizó un modelo del negocio, utilizando el método BMM

(Business Modeling Method), como base para las siguientes fases y etapas del
desarrollo de software, principalmente para la Obtención de Requerimientos, la
cual se desarrolla con un método propuesto, basado en las necesidades del
cliente, flexible, iterativo e incremental, en el cual se aplican ciertas técnicas y
herramientas que facilitan la extracción, análisis, especificación y validación de
requerimientos, ajustándolos al ambiente real de los clientes.
- 15 -
JUSTIFICACION
El resultado final de un proyecto de software es un producto que toma forma a

lo largo del desarrollo del proyecto. La calidad del producto final, está
estrechamente ligada a la calidad del proceso de desarrollo de software, en el
cual el modelado del negocio y la Obtención de Requerimientos constituyen
factores críticos para las demás etapas del desarrollo de proyectos software.
"La parte más difícil de construir un sistema es precisamente saber qué

construir. Ninguna otra parte del trabajo conceptual es tan difícil como
establecer los requerimientos técnicos detallados, incluyendo todas las
interfaces con gente, máquinas y otros sistemas. Ninguna otra parte del
trabajo afecta tanto el sistema si es hecha mal. Ninguna es tan difícil de
corregir más adelante... Entonces, la tarea más importante que el ingeniero de
sistemas realiza para el cliente es la extracción iterativa y el refinamiento de los
requerimientos del producto." [BROOKS, 1987].
Un requerimiento existe porque el tipo de producto demanda ciertas funciones

o cualidades, o porque el cliente quiere que ese requerimiento sea parte del
producto final. Así que si no se tienen los requerimientos correctos, no se
puede diseñar o construir el producto correcto y, consecuentemente, el sistema
desarrollado no permitirá a los usuarios finales realizar su trabajo.
A medida que pasa el tiempo los analistas de sistemas han descubierto que a
partir de un proceso estructurado denominado modelo del negocio, basado en
la información de los procesos de la empresa cliente, se puede obtener gran
parte de las características, propiedades, forma de ejecución y producción, y
demás información relevante para la definición del alcance y ámbito de
aplicación del sistema deseado. A partir del modelo del negocio, es posible
obtener de manera sistemática y directa, tanto la colección inicial de casos de
uso del sistema (requerimientos funcionales) como el modelo conceptual
- 16 -
preliminar, facilitando de esta manera el desarrollo de la fase de obtención de

requerimientos.
Debido a la importancia y relevancia del desarrollo de un Modelamiento del

negocio se aplica un método basado en principios, procesos y conceptos
tomados de la Ingeniería de métodos, modelamiento empresarial e Ingeniería
del software orientada a objetos, cubriendo tres pilares fundamentales como lo
es el Producto que se desea construir, el Equipo de Desarrollo y el Proceso de
Modelado, los cuales conforman las bases estructurales para la construcción
iterativa del sistema y el refinamiento continuo de los requerimientos. Además
para fortalecer la obtención de requerimientos se hace necesario el análisis,
selección y aplicación de técnicas y herramientas que faciliten y optimicen
dicho proceso, contando con cimientos reales del negocio, con el objetivo de
producir sistemas, que cumplan con los requisitos de realidad, flexibilidad,
eficiencia, efectividad y facilidad de uso para los usuarios finales.
- 17 -
PROBLEMA
Actualmente el creciente uso de las tecnologías de información y la

sistematización de la mayoría de los procesos de las empresas requiere que se
desarrollen sistemas que suplan sus necesidades y permitan la optimización de
las actividades, para ello se necesita un enfoque sistemático de desarrollo y
operación, denominado “Ingeniería del Software”.
Dentro de la Ingeniería del Software la Obtención de Requerimientos cumple

un papel primordial en el proceso de producción de software, debido a que se
enfoca en 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. Como soporte a esta fase
se puede realizar un modelamiento del negocio, en el cual se obtenga la
información necesaria para validar la claridad y realidad de los requerimientos.
En la mayoría de los proyectos la mayor causa de fracaso se da por no tener

en cuenta un modelo del negocio lo cual conduce a obtener requerimientos
incompletos o inconsistentes, por tal motivo los participantes del equipo de
desarrollo se enfrentan a una situación desconocida a la hora de comenzar el
ciclo de vida del software, causando estimaciones irreales de esfuerzo, tiempo,
costos y requerimientos que posiblemente no concuerden con los procesos
actuales de la empresa, contribuyendo con el declive del proyecto. Por lo tanto
es necesario contar con la información del negocio y definir una forma de
capturar las necesidades del cliente, procurando aplicar técnicas y
herramientas que ayuden a optimizar dicha fase, con el objetivo de extraer,
analizar, especificar y validar cada uno de estos requerimientos de la mejor
manera posible, permitiendo construir modelos enmarcados en las necesidades
reales de los clientes y así conformar una base sólida para el desarrollo de las
siguientes fases del proyecto.
- 18 -
OBJETIVOS
OBJETIVO GENERAL
Realizar un análisis comparativo de técnicas de obtención de requerimientos

para el módulo de Facturación del aplicativo Gestasoft Hospitalario para
IMSALUD (Institución Municipal de Salud de San José de Cúcuta).
OBJETIVOS ESPECIFICOS
♦ Identificar las principales actividades de la obtención de requerimientos.

♦ Identificar y seleccionar las técnicas y herramientas adecuadas para el
desarrollo de las actividades de la obtención de requerimientos.
♦ Desarrollar un análisis comparativo de técnicas y herramientas de obtención
de requerimientos.
♦ Aplicar en la obtención de requerimientos las técnicas y herramientas
previamente seleccionadas.
♦ Extraer los requerimientos para el módulo de Facturación del aplicativo
Gestasoft Hospitalario.
♦ Analizar y especificar los requerimientos identificados para el módulo de
facturación.
- 19 -
1. MARCO TEORICO
1.1 MODELO DEL NEGOCIO
Desde el surgimiento mismo de la computación y a lo largo de toda su

evolución se ha intentado modelar o simular el pensamiento humano y los
procesos que ocurren en él. En los inicios solo se trataba de representar en las
computadoras el pensamiento estructurado, los algoritmos de cálculos que
podían definirse claramente como un conjunto de pasos que podían ser
interpretados por las máquinas y de cierta forma sustituir o contribuir a elevar la
eficiencia del ser humano en este tipo de actividades. [DELGADO, 2006]
Se hace necesario, entonces, combinar técnicas y herramientas con la

experiencia de los especialistas para afrontar los nuevos retos que impone
diseñar sistemas eficientes y novedosos en las condiciones actuales,
sumamente cambiantes. Esta necesidad es aún más imperiosa cuando cada
individuo en una organización tiene su propia forma de abordar los problemas y
no siempre tiene todo el conocimiento y experiencia necesarios sobre el
negocio. [DELGADO, 2006]
El modelado del negocio es una parte fundamental para el desarrollo de

software. Permite que el analista capture el esquema general y los
procedimientos que gobiernan el negocio.
Este modelo proporciona una descripción del sitio donde quedará instalado el
software propuesto en la estructura de la organización y las actividades diarias
de la misma. Puede también proporcionar la justificación para construir el
sistema, capturando los procedimientos actuales de forma manual o
automatizada, los cuales serán cargados en un nuevo sistema, los beneficios
de costo asociados y permite que el analista rastree claramente cuál es el
alcance del sistema propuesto y las funcionalidades a implementar.
- 20 -
Es primordial crear un modelo detectable de los procesos generales a los

requerimientos funcionales y eventualmente a los artefactos de software que
serán construidos realmente.
El modelo del negocio se desarrolla según las consideraciones y necesidades

del proyecto, a continuación se describen algunos de los posibles escenarios
de implementación.
1.1.1 Escenarios
ESCENARIO 1 – MAPA DE LA ORGANIZACIÓN
Se Construye un mapa de la organización y los procesos involucrados, para de

esta manera capturar y comprender de una forma más rápida y sencilla los
requerimientos necesarios para la construcción del sistema. En este caso, el
modelamiento del negocio es parte del proyecto de ingeniería del software,
ejecutado principalmente en la fase inicial del desarrollo. [VILLAMIZAR, 2006].
ESCENARIO 2 – MODELAMIENTO DE DOMINIO
Si se están construyendo aplicaciones con el propósito principal de gestionar y

presentar información, se puede seleccionar construir un modelo de dicha
información a nivel de negocio, sin considerar los flujos de trabajo del negocio.
Esto se refiere al modelo de dominio. Típicamente el modelo de dominio es
parte del proyecto de ingeniería del software. [VILLAMIZAR, 2006].
ESCENARIO 3 – UN NEGOCIO MUCHOS SISTEMAS
Si se está construyendo un sistema extenso, o una familia de aplicaciones, es

necesario realizar un modelamiento del negocio que servirá como entrada a
proyectos complejos de software. Los modelos de negocios ayudan a
encontrar requerimientos funcionales, y ellos sirven como entrada para
- 21 -
construir la arquitectura de la familia de aplicaciones. En un negocio y muchos

sistemas el esfuerzo de modelamiento del negocio se trata como un proyecto
en propiedad. [VILLAMIZAR, 2006].
ESCENARIO 4 – MODELO GENERICO DE NEGOCIOS
Si el objetivo es construir una aplicación que podría ser usada por varias
organizaciones – por ejemplo, aplicación de soporte de ventas o de facturación-
puede ser útil realizar un esfuerzo de modelamiento del negocio para alinear
las organizaciones evitando requerimientos demasiado complejos (mejora del
negocio). Si la alineación de las organizaciones no es una opción, el
modelamiento del negocio puede ayudar a entender y manejar diferencias de
usabilidad entre las organizaciones, lo cual facilitará determinar las
funcionalidades a priorizar. [VILLAMIZAR, 2006].
ESCENARIO 5 – NUEVOS NEGOCIOS
Si una organización ha decidido comenzar una nueva línea de negocios y

construirá sistemas de información para soportarlos, se requiere un buen
modelado del negocio. En este caso, el propósito del modelamiento del
negocio no es únicamente encontrar los requerimientos del sistema, sino
también determinar la viabilidad de la nueva línea de negocios, de esta manera
el modelo del negocio es tratado como un proyecto en propiedad.
[VILLAMIZAR, 2006]
ESCENARIO 6 – RENOVACION (MEJORA)
En la reingeniería de negocios, el modelamiento del negocio puede ser uno o

varios proyectos en propiedad. Típicamente, la reingeniería de negocios es
realizada en varias etapas: previsión del nuevo negocio, ingeniería inversa del
negocio existente, ingeniería avanzada del nuevo negocio e instalación del
nuevo negocio. [VILLAMIZAR, 2006].
- 22 -
1.1.2 Método de Modelamiento del Negocio BMM.

[BARRIOS et all, 2003]
Proceso de Post -
Desarrollo
Modelo del
Negocio
Entrega de la Definición y
Aplicación Especificación de
Requerimientos
Prueba de la Diseño de la
Proceso
Aplicación Arquitectura
Directivo
Ensamble de Especificación de
Componentes Componentes
Aprovisionamiento de
Componentes
Figura 1. Ubicación del Método BMM en un modelo de procesos de Sistemas de

Información y Desarrollo de Software
El modelamiento del negocio es realizado entre la Planificación del Proyecto, la

cual es una de las actividades iniciales de la gestión de procesos, y la fase de
Definición y Especificación de Requerimientos. (Ver figura 1).
El BMM fue diseñado basándose en principios, procesos y conceptos tomados

de la Ingeniería de métodos, modelamiento empresarial y la Ingeniería del
software orientada a objetos.
Una práctica común de este método es estructurar un proyecto en 3

componentes:
- 23 -
1. Modelo del Producto Describe la estructura general, características

del producto y conceptos que caracterizan algunos sistemas de
negocios y las relaciones entre ellos.
2. Modelo del Equipo Describe la manera de organizar el equipo de
modelado y describe los roles de los miembros del equipo.
3. Modelo de Procesos Describe la estructura y dinámica de las
actividades necesarias para construir el modelo del negocio.
1.1.2.1 Modelo del Producto de BMM
Identifica y representa un conjunto de conceptos generales que están

presentes en algunos sistemas de negocios, entre ellos se seleccionan
aquellos que deben ser representados durante los procesos de modelado del
dominio de la aplicación.
El modelo del producto está conformado por un conjunto de meta-modelos, los

cuales describen en forma más detallada los conceptos genéricos del negocio.
Cada meta-modelo representa un concepto del negocio y sus relaciones.
1.1.2.1.1 Metas del Negocio
Son establecidas por los gestores y clientes del proyecto para cumplir con los
intereses del negocio y las necesidades demandadas por el ambiente. Pueden
ser clasificadas de acuerdo con tres alcances: Visión, Misión y Objetivos.
1.1.2.1.2 Procesos del Negocio
Para alcanzar las metas de un sistema del negocio se debe diseñar, organizar
y realizar un conjunto de actividades llamadas procesos del negocio. Los
procesos del negocio están constituidos por actividades estructuradas y
diseñadas jerárquicamente para alcanzar las metas del negocio.
- 24 -
Los procesos se descomponen en niveles, los cuales a su vez llegan a

descomponerse en actividades.
Los procesos primarios y de soporte, por instancia, son categorías asociadas a

la cadena de valor de una empresa. Los procesos del negocio deben ser
modelados como una jerarquía de procesos y actividades en diversos niveles
de abstracción.
1.1.2.1.3 Actores, Unidades y Estructura del Negocio
Los actores pueden clasificarse en internos y externos según el alcance del

sistema del negocio, por medio de ellos se pueden identificar los roles que
intervienen en el sistema del negocio.
Responsable Hacen parte

Proceso
Rol Tarea del
s negocio
Ejecuta
Actor Es
Unidad de Negocio
asignado
Figura 2. Diagrama de relación entre actores – roles – unidades y procesos del negocio
1.1.2.1.3.1 Actores
Internos Son parte del sistema del negocio, ellos pueden representar una
persona o una máquina y están definidos por tareas o acciones. Las tareas
son asignadas a actores humanos, ellas representan las unidades mínimas de
trabajo. Las acciones se les atribuyen a los actores automáticos (componente
de software, aplicación, etc.).
- 25 -
Externos Son parte del ambiente del sistema del negocio, ellos
interaccionan con el sistema para satisfacer ciertas necesidades o proveer
recursos. (Ej. Clientes, proveedores, acciones y / o actores de otros sistemas).
1.1.2.1.3.2 Unidades del Negocio
Están organizadas en una estructura jerárquica, la cual representa, según las

líneas de autoridad que gobiernan, las relaciones entre las unidades del
negocio.
1.1.2.1.4 Tecnologías
Los procesos del negocio utilizan tecnologías para realizar sus actividades más
eficiente y efectivamente.
1.1.2.1.5 Reglas del negocio
Los procesos del negocio son delimitados por las tecnologías que utilizan y por
las reglas que debe cumplir.
El sistema debe regirse por las regulaciones y leyes impuestas por las
operaciones del ambiente. Debe satisfacer las políticas, planes y estándares
establecidos en la empresa a nivel interno.
Las reglas pueden ser compuestas por otras reglas formando una jerarquía, las
del nivel inferior son expresadas en términos de condiciones y acciones.
1.1.2.1.6 Objetos del negocio
La ejecución de un proceso del negocio involucra un conjunto de entidades

llamadas objetos del negocio.
- 26 -
Un objeto es un pensamiento concreto o abstracto que es relevante para el

sistema. (Ej. Dinero, datos, materia prima, etc.).
1.1.2.1.7 Eventos
Los procesos son activados por la ocurrencia de eventos. Un evento es una

acción de corta duración que ocurre dentro o fuera del sistema del negocio, es
una señal para iniciar o finalizar un proceso, pueden ser programados (se
encuentran dentro de un cronograma) o casuales. Estos pueden clasificarse
en internos y externos.
Evento externo: Ocurre en el ambiente del sistema. Por ejemplo una orden de
servicio.
Evento interno: Puede cambiar el estado de uno o más objetos del negocio.
Un cambio de estado implica cambios en algunos de los valores de los
atributos del objeto. Los atributos que no cambian con la ocurrencia de un
evento se denominan “Invariantes”. Por ejemplo: Nombre, fecha de
cumpleaños, entre otros.
1.1.2.2. Modelo del equipo
Definir los roles de los miembros del equipo es una tarea importante para la
aplicación del modelo de procesos, debido a que le facilita al líder del equipo la
selección de las personas y la asignación de las actividades apropiadas.
Organización del equipo:
Líder del proyecto Planifica, organiza, dirige y controla el esfuerzo y los

recursos necesarios para modelar el sistema.
- 27 -
Usuarios expertos Proporcionan el conocimiento para el modelado del

sistema.
Analistas del negocio Interpreta el conocimiento de los usuarios y representa

este conocimiento utilizando lenguajes de modelado indicados en el modelo del
producto. Estos son responsables de validar el modelo del negocio.
1.1.2.3. El proceso de modelado del negocio
Describe el flujo de trabajo que se necesita para producir el modelo del negocio
durante el desarrollo de un sistema, en este proceso se realizan los diagramas
de actividades.
Ciclo de ejecución del proceso de modelamiento: El proceso de modelado

involucra una serie de ciclos; al final de cada ciclo el equipo entrega una
versión del modelo, si esta versión es aceptada se finaliza el proceso y se
entrega el modelo al equipo de desarrollo. Si la versión del modelo no es
aceptada se inicia un nuevo ciclo para realizar, corregir o probar la versión más
reciente del modelo del negocio.
Ejecución iterativa del proceso de modelado: En cada paso, el equipo produce

un entregable, esto es, un submodelo o componente del modelo del negocio.
La producción de un entregable en cada uno de los pasos intermedios es
verificado por el equipo antes de avanzar al siguiente paso.
El paso de “verificación y validación” determina cuando se avanza de paso, o

cuando se debe regresar a un paso previo para adicionar, modificar o corregir
elementos del submodelo. En el paso de “Entrega del modelo del negocio” se
entrega una versión, la cual debe ser validada por el gestor del sistema del
negocio para posteriormente iniciar otro ciclo o concluir el proceso de
modelado.
- 28 -
Planificación del
proyecto
Especificación y definición
de requerimientos
Definición del sistema

del negocio
Entrega del modelo

del negocio Modelado de metas
Modelado de Modelado de reglas

actores Verificación y
y tecnologías
validación
Modelado de Modelado de procesos

eventos del negocio
Modelado de objetos
del negocio
Figura 3. Proceso del modelado del negocio
1.2 OBTENCION DE REQUERIMIENTOS
En el proceso de desarrollo de un sistema, el equipo de desarrollo se enfrenta

al problema de la identificación de requisitos. La definición de las necesidades
del sistema es un proceso complejo, pues en él hay que identificar los
requisitos que el sistema debe cumplir para satisfacer las necesidades de los
usuarios finales y de los clientes.
- 29 -
Para realizar este proceso, no existe una única técnica estandarizada y

estructurada que ofrezca un marco de desarrollo que garantice la calidad del
resultado. Existe en cambio un conjunto de técnicas, cuyo uso proponen las
diferentes metodologías para el desarrollo de aplicaciones. Se debe tener en
cuenta que la selección de las técnicas y el éxito de los resultados que se
obtengan, depende en gran medida tanto del equipo de análisis y desarrollo,
como de los propios clientes o usuarios que en ella participen.
Una posible visión de la ingeniería de requerimientos es considerarla como un

proceso de construcción de una especificación de requerimientos en el que se
avanza desde especificaciones iniciales, que no poseen las propiedades
oportunas, hasta especificaciones finales completas, formales y acordadas
entre todos los participantes. [POHL, 1994]
Figura 4. Posible visión de la ingeniería de requerimientos [POHL, 1994]
La Ingeniería de Requerimientos se ocupa de los aspectos de la Ingeniería de

Software, relacionados con la comprensión y producción de descripciones de
problemas para resolverlos a través de la construcción de Sistemas de
Software. Los fundamentos del sistema (el por qué) están abarcados por los
“objetivos” de la organización, y se definen usualmente como las metas a ser
cumplidas por el sistema y su entorno. Como todo producto de la fase de
- 30 -
requerimientos, los objetivos del sistema deben recorrer un proceso de captura,

análisis, especificación y validación, estas actividades difieren según el autor
que lo plantee, a continuación se presentan algunas representaciones gráficas
sobre el proceso de la Ingeniería de Requerimientos.
1.2.1 Proceso de la Ingeniería de Requerimientos
Figura 5. Proceso de la Ingeniería de requerimientos [LOCOPOULOS et all, 1995]
Figura 6. Proceso de la Ingeniería de requerimientos [KOTONYA et all, 1997]
- 31 -
Figura 7. Proceso de la Ingeniería de requerimientos [KOTONYA et all, 1997], un modelo

en espiral
Figura 8. Proceso de la Ingeniería de requerimientos [POHL, 1996]
- 32 -
Figura 9. Modelo de madurez para la Ingeniería de Requerimientos [SOMMERVILLE,

1997]
El proceso comienza con la realización de la captura de requisitos, el grupo de

técnicos toma la información suministrada por los usuarios y clientes. Esta
información puede provenir de fuentes muy diversas: documentos, aplicaciones
existentes, a través de entrevistas, etc. En base a esta información, el equipo
de desarrollo elabora la documentación de los requisitos. Finalmente con la
validación de requisitos se realiza la valoración de los mismos, comprobando si
existen inconsistencias, errores o si faltan requisitos por definir. El proceso de
definición-validación es iterativo y en algunos proyectos complejos resulta
necesario ejecutarlo varias veces.
- 33 -
ad Ingenieria de requerimientos
«Input» «Actividad»
Información Captura de
Requerimientos
«Actividad»
Definición de
Requerimientos
«Actividad» «Output»
Validación de
Documentación de
Requisitos
Requerimientos
«Input»
Correcciones
Figura 10. Diagrama de actividad de la Ingeniería de Requerimientos
1.2.1.1 Extracción, Captura o Elicitación de Requerimientos
Extracción es el nombre comúnmente dado a las actividades involucradas en el

descubrimiento de los requerimientos del sistema. Los analistas deben trabajar
con el cliente para descubrir el problema a resolver, los diferentes servicios que
el sistema debe prestar, las restricciones que se pueden presentar, etc.
Esto no suele ser tarea fácil: muchas veces los clientes/usuarios no tienen una
idea clara de sus necesidades reales, diversas personas dentro de la
organización tienen necesidades encontradas, pueden existir limitaciones
técnicas o tecnológicas para cumplir con algunos requerimientos, etc. Pero, en
definitiva, descubrir los requerimientos del sistema no sólo implica preguntar a
- 34 -
las personas qué quieren: es un proceso delicado que involucra comprender el

domino de aplicación, el problema en sí, lo que implica que se debe extender y
especializar el conocimiento sobre el dominio general para que se aplique al
cliente en particular; comprender el negocio, por tanto, se debe entender en
profundidad cómo es que este sistema interactuará, afectará a las partes del
negocio que estarán involucradas y cómo puede contribuir a lograr las metas
de la empresa.
Es importante, que la extracción sea efectiva, ya que la aceptación del sistema

dependerá de la satisfacción de las necesidades del cliente y de la
sistematización del trabajo. [DAVILA, 2006].
Figura 11. Diagrama de actividad de la Extracción de Requerimientos
- 35 -
1.2.1.2 Análisis
Sobre la base de la extracción realizada previamente, comienza esta fase la

cual se enfoca en descubrir problemas con los requerimientos del sistema
identificados hasta el momento. Usualmente se hace un análisis luego de
haber producido un bosquejo inicial del documento de requerimientos; aquí se
leen los requerimientos, se conceptúan, se investigan, se intercambian ideas
con el resto del equipo, se resaltan los problemas, se buscan alternativas y
soluciones, y luego se van fijando reuniones con el cliente para discutir los
requerimientos. [DAVILA, 2006]
ad Análisis
«sub-actividad»
Analizar si el requerimiento es consistente
con los obj etiv os del sistema
«sub-actividad»
Analizar si todos los requerimientos tienen
el niv el adecuado de abstracción
«sub-actividad»
Identificar si el requerimiento es
necesario o representa una característica
añadida
«Actividad»
Realizar un análisis inicial «sub-actividad»
de los requerimientos Analizar si cada requerimiento está
obtenidos en la etapa delimitado y sin ambigüedad
anterior
«sub-actividad»
Analizar si existe un origen conocido para
cada requerimiento
«sub-actividad»
Identificar si existen incompatibilidades
«Actividad» entre requrimientos
Agrupar los
requerimientos por
categorías y organizarlos
en subconj untos «sub-actividad»
Analizar si se puede probar el
requerimiento una v ez implementado
«Actividad» «Actividad» «Actividad»

Estudiar cada Examinar los Clasificación final de los
requerimiento con requerimientos en su requerimientos según las
respecto al resto nde consistencia, completitud necesidades de los
requerimientos y ambigüedad usuarios
Figura 12. Diagrama de actividad del Análisis de Requerimientos
- 36 -
1.2.1.3 Especificación
En esta fase se documentan los requerimientos acordados con el cliente, en un

nivel apropiado de detalle.
Una especificación puede ser un documento escrito, un modelo gráfico, un

modelo matemático formal, una colección de escenarios de uso, un prototipo o
una combinación de lo anteriormente citado.
En la práctica, esta etapa se va realizando al mismo tiempo que el análisis,

pero se podría decir que la Especificación es el "pasar en limpio" el análisis
realizado previamente aplicando técnicas y/o estándares de documentación,
como la notación UML. [DAVILA, 2006]
1.2.1.4 Validación
La validación es la etapa final de la Ingeniería de Requerimientos. Su objetivo

es analizar todos los requerimientos que aparecen en el documento, para
asegurarse que representan una descripción, por lo menos, aceptable del
sistema que se debe implementar. Esto implica corroborar que los
requerimientos sean consistentes, estén completos y que el resultado del
trabajo se ajuste a los estándares establecidos para el proceso, el proyecto y el
producto.
Se prefiere que el documento de requerimientos obtenido en la etapa anterior

sólo debe incluir los requerimientos que son aceptables para los usuarios.
Pero es inevitable que durante la validación se descubran algunos problemas
relacionados con los usuarios, y esto se debe corregir antes de aprobarse el
documento final de requerimientos. [DAVILA, 2006]
- 37 -
1.2.2 Técnicas de Obtención de Requerimientos
Herramienta Instrumento. Por ejemplo, un cronograma informal de

entrevistas o un cuestionario son herramientas para recopilar información. Una
herramienta se puede aplicar mediante distintos métodos o técnicas.
Técnica La técnica es el procedimiento o el conjunto de procedimientos que

tienen como objetivo obtener un resultado determinado, ya sea en el campo de
la ciencia, de la tecnología o en otra actividad.
Nombre Clasificación Extracción Análisis Especificación Validación

Entrevistas Técnica X
Cuestionarios Herramienta X
Sistemas existentes Técnica X X
Grabaciones de video Herramienta X X
y de audio
Brainstorming Herramienta X X
(Tormenta de ideas)
Arqueología de Herramienta X X
documentos
Aprendiz Técnica X
Observación Técnica X
Run Use Case Herramienta X
Workshop (talleres)
Prototipo bosquejado Herramienta X X X
Prototipo tangible / Herramienta X X X
Usable
DOFA Herramienta X
Cadena de valor Herramienta X
Modelo de clase Herramienta X X
conceptual
Diagrama de pescado Herramienta X X X
Glosario Herramienta X X X X
DCO Técnica X X
Diagrama de actividad Herramienta X X
ESRE Técnica X X X X
Casos de uso Herramienta X X X X
Casa de calidad o Herramienta X
QSD
Checklist Herramienta X X
Tabla 1. Técnicas y herramientas de Obtención de Requerimientos
- 38 -
1.2.2.1 Entrevistas y cuestionarios
Las entrevistas son la técnica de captura más utilizada, y de hecho son

prácticamente inevitables en cualquier desarrollo debido a que es una de las
formas de comunicación más naturales entre personas. En las entrevistas se
pueden identificar tres fases: Preparación, realización y análisis.
Preparación Es necesario, estudiar el dominio del problema, seleccionar a

las personas a las que se va a entrevistar, determinar el objetivo y contenido de
la entrevista y su planificación (fecha, hora, lugar, duración).
Realización Está fase a su vez se divide en tres actividades, como son:

Apertura (presentación del entrevistador, objetivos, como se va a utilizar la
información, mecánica de las preguntas, explicar, si se va a utilizar, alguna
notación gráfica o matemática), Desarrollo (la duración de la entrevista no debe
ser mayor a 2 horas, aplicación de los diferentes tipos de preguntas y anotar,
grabar o filmar las respuestas del entrevistado) y Finalización (recapitular para
confirmar que no ha habido confusiones en la información recogida).
Análisis Una vez finalizada la entrevista es necesario leer las notas tomadas,
pasarlas a limpio, reorganizar la información, contrastarla con otras fuentes.
Una vez organizada la información se puede enviar al entrevistado para
confirmar los contenidos. [KOMER, 1993].
1.2.2.2 Sistemas existentes
Esta técnica consiste en analizar distintos sistemas ya desarrollados que estén

relacionados con el sistema a ser construido.
Se pueden analizar las interfases de usuario, observando el tipo de información

y cómo se maneja. También es útil analizar las distintas salidas que los
sistemas producen (listados, consultas, etc.). Esto puede ser útil para
- 39 -
descubrir requisitos importantes, que tal vez el cliente/usuario haya fallado en

comunicar.
Otra ventaja que presenta esta técnica es que como estos sistemas ya están
en producción, ya han pasado por la curva de aprendizaje del dominio del
problema. [DAVILA, 2006]
1.2.2.3 grabaciones de video y de audio
En cuanto a su función de apoyo, es importante por cuanto permite centrar la

atención en la entrevista en sí en vez de distraerse tomando notas de todo lo
que se dice. Cuando se está grabando la conversación, basta con "puntear" en
una libreta los temas tratados para después tener una guía básica de los temas
tratados y saber en qué lugar de la grabación buscar. Además, permite
analizar los temas con más detenimiento y con una visión más global, pues ya
se ha conversado sobre todos los puntos necesarios.
Cuando se trata de analizar algún proceso en particular, su ayuda es

inestimable (sobretodo las filmaciones de video) ya que permite ver y analizar
en detalle determinado proceso la cantidad de veces que sea necesario.
Además al filmar el lugar de trabajo se está capturando el proceso de trabajo,
lo que evita que se impongan las expectativas y preferencias del modelador.
[DAVILA, 2006]
1.2.2.4 Tormenta de ideas (Brainstorming)
Es una técnica de reuniones en grupo cuyo objetivo es la generación de ideas

en un ambiente libre de críticas o juicios. Las sesiones de brainstorming suelen
estar formadas por un número de 4 a 10 participantes, uno de los cuales es el
jefe de la sesión. Puede ayudar a generar una gran variedad de vistas del
problema y a formularlo de diferentes formas, sobre todo al comienzo del
proceso, cuando los requerimientos son todavía muy difusos. [DAVILA, 2006]
- 40 -
1.2.2.5 Arqueología de documentos
Con la aplicación de esta herramienta se tratan de determinar posibles

requerimientos sobre la base de inspeccionar la documentación utilizada por la
empresa; por ejemplo, boletas, facturas, remitos, etc.
Esta herramienta sirve como complemento de las demás técnicas, y nos ayuda
a obtener información que de otra manera sería sumamente difícil conseguir.
[DAVILA, 2006].
Para el análisis de cada uno de estos documentos, se deben realizar algunas

preguntas, como:
¿Cuál es el propósito de este documento?

¿Quién lo usa? ¿Por qué? ¿Para qué?
¿Cuáles son las tareas que realizan con este documento?
¿Se puede encontrar una relación entre los documentos?
¿Cuál es el proceso que realiza la conexión?
¿Cuál es el documento que da más problemas a los usuarios?
1.2.2.6 Aprendiz
Esta técnica se basa en la idea del maestro y el aprendiz, y es una buena

forma de observar el trabajo real. Aquí, el aprendiz es representado por el
analista, y el usuario/cliente cumple el rol de maestro.
El aprendiz se sienta con el maestro a aprender por medio de la observación.

Puede ser combinada con la herramienta de modelo conceptual. A medida que
el trabajo es observado y explicado, el analista puede realizar bosquejos para
cada una de las tareas realizadas, y también puede bosquejar como se
conectan por medio de los distintos flujos de datos.
- 41 -
Su aplicación es muy útil, ya que a veces es difícil para el cliente/usuario el

explicar cómo realiza su trabajo. Es apropiada para un proyecto donde el
problema no es estructurado, ya que es una de las mejores formas de obtener
el conocimiento que se encuentra en la "cabeza" del cliente. Su principal
inconveniente es que requiere mucho tiempo. [DAVILA, 2006].
1.2.2.7 Observación
Observar como se hacen las cosas es una buena manera de entender lo que
estas requieren. Conectarse íntimamente con la cultura de la organización,
vivirla, es una técnica que debe ser tomada en cuenta.
Dentro de la estrategia de observación se deben buscar estructuras y patrones.

La estructura del trabajo suele ser invisible para los usuarios, por lo que será
trabajo del analista realizar las abstracciones necesarias. [DAVILA, 2006]
1.2.2.8 Talleres de trabajo basados en los casos de uso (Run Use Case
Workshop)
Estos talleres de trabajo se realizan entre el cliente/usuario y el equipo de

requerimientos. La primera parte del WorkShop consiste en generar los
escenarios. Para esto se necesita la información que tiene para brindar el
usuario/cliente.
La idea es conversar por medio de los casos de uso y extraer de los usuarios
las cosas esenciales que suceden cuando ocurre un evento determinado. Así,
se trata de definir la serie de usuarios y reconocer los pasos que se realizan
para el caso de uso en estudio. Como resultado de este proceso se obtiene
como resultado un excelente bosquejo de casos de uso. [Robertson et all,
1999].
- 42 -
1.2.2.9 Prototipos
Durante la actividad de extracción de requerimientos, puede ocurrir que

algunos de ellos no estén claros o que el equipo de análisis no este seguro de
haber entendido correctamente los requerimientos obtenidos hasta el
momento, lo cual puede llevar a un desarrollo no eficaz del sistema final.
Los prototipos son simulaciones del posible producto, que luego son utilizados
por el usuario final, permitiendo conseguir una importante retroalimentación en
cuanto a si el sistema diseñado en base a los requerimientos recolectados le
permite al usuario realizar su trabajo de manera eficiente y efectiva. Los
prototipos se pueden clasificar en:
A - Prototipo evolutivo
Se puede plantear cuando el usuario no puede o no está dispuesto a articular

sus requerimientos de ninguna forma, sólo se podrán determinar mediante un
proceso de ensayo y error. Así se van realizando evoluciones sobre la base
del mismo prototipo hasta determinar claramente los requerimientos.
B - Prototipo Bosquejado
Para realizar esta clase de prototipo es necesario apoyarse en el rol del

analista de requerimientos, simulando las respuestas del sistema y realizando
bosquejos de las interfases de usuario; y en el usuario, que es quien realiza las
entradas ("utiliza el prototipo").
Una de las ventajas más importantes es el poco esfuerzo que se realiza para
aplicar cambios. Como desventaja se puede mencionar que si bien se captura
la idea, el usuario no percibe como será realmente el diálogo hombre-máquina,
sobre todo si existe un requerimiento no funcional como el de usabilidad.
- 43 -
C - Prototipo Tangible/usable
Los términos tangible y usable se refieren a desarrollar una aplicación

(software) que el usuario pueda utilizar, es decir, con la cual pueda interactuar
como si fuera la aplicación final.
Los prototipos deben cumplir lo siguiente:
♦ Demandar poco esfuerzo para realizar los cambios

♦ Poseer amplia flexibilidad para el manejo de las interfases de usuario.
♦ Consumir poco tiempo para generar un nuevo prototipo (maqueta).
El prototipo tangible/usable también resulta de suma utilidad cuando se ha

planteado un requerimiento no funcional de usabilidad.
Entre las desventajas más importantes de los prototipos, se encuentran:
♦ Costo de entrenamiento/capacitación en la herramienta

♦ Costo de realizar el prototipo.
♦ Problema de calendario.
♦ Incompletitud (puede confundir a los usuarios, haciéndolos pensar que el
producto final quedará como el prototipo, incompleto).
[KOTONYA et all, 1997]
1.2.2.10 DOFA
Con este análisis se intentan identificar las principales fortalezas,

oportunidades, debilidades y amenazas con las que se enfrenta una empresa.
Las oportunidades y las amenazas, se refieren a los factores externos que
pueden afectar el futuro del negocio y las fuerzas y debilidades son factores
internos; estas fuerzas señalan ciertas estrategias cuya aplicación podría
- 44 -
conducir al éxito, mientras que las debilidades señalan aquello que la empresa
debe corregir. [KOMER, 1993]
1.2.2.11 Cadena de valor
Todas las empresas son una colección de actividades que se llevan a cabo
para diseñar, producir, distribuir, entregar y apoyar a su producto. La cadena
de valor divide las empresas en actividades estratégicas a fin de comprender el
comportamiento de los costos en determinado negocio o industria y en las
fuentes de diferenciación presentes y futuras.
En este análisis se deben examinar los costos y el funcionamiento de cada una

de las actividades productoras de valor, tratando de mejorarlos. [KOMER,
1993]
1.2.2.12 Modelo de clase conceptual
Un modelo conceptual es una representación de conceptos del dominio del

problema. Permite mostrar conceptos, asociaciones entre conceptos y
atributos de conceptos. La creación del modelo también ayuda a comprender
la terminología del dominio y comunica cuáles son los términos importantes y
las relaciones existentes entre ellos.
Concepto: categoría de idea o cosas. La intención del concepto es la

descripción de sus atributos, operaciones y significado.
Para representar un concepto se puede emplear la metodología orientada a

objetos, utilizando las clases como forma de representar un concepto del
dominio del problema que abarca un amplio espectro.
Es una buena forma para obtener una idea general de cómo funciona el
negocio (relaciones entre las clases/concepto), y capturar vocabulario y
- 45 -
conceptos (clase). También es de ayuda para incluir nuevos conceptos al

glosario. [CRAIG, 1999].
1.2.2.13 Diagrama de pescado
Ejemplo:
Figura 13. Diagrama de Pescado
Con esta herramienta se puede analizar cómo impacta la solución planteada

para un requerimiento dado. Por ejemplo, cómo afecta al trabajo diario del
empleado. También en el caso de que la solución planteada interactúe con
otros sistemas existentes (modificando, consultando o intercambiando
información) el diagrama de pescado nos permite analizar los posibles
problemas que pueden surgir.
Esta herramienta se puede utilizar conjuntamente con una tormenta de ideas

(brainstorming), para ayudar a ordenar las posibles soluciones a un problema.
Es decir, por un lado se generan ideas y luego se utiliza esta herramienta para
organizarlas. [DAVILA, 2006]
1.2.2.14 Glosario
El glosario es una simple lista de términos en donde se explica su significado.

En esta lista se incluyen y definen todos los términos que requieren explicación,
- 46 -
mejorando así la comunicación intergrupal y la comunicación con el cliente, y

mitigando el riesgo de malos entendidos.
Los términos que se incluyen provienen de todas las áreas del proyecto: casos
de uso, terminología propia del negocio, etc. [DAVILA, 2006]
1.2.2.15 DCO
El objetivo del DCO (Documento de Concepto de Operaciones) es el de

comprender el entorno en el cual se encuentra el negocio, describiendo su
funcionamiento interno y su relación con el ambiente.
Los puntos tratados en el documento básicamente son:
Análisis del entorno, descripción general, organigrama de la empresa,

misión/visión, políticas de desarrollo, de servicios, comercial, de personal, de
dirección, etc. [DAVILA, 2006]
1.2.2.16 Diagrama de actividad
El diagrama de actividad, se asemeja a un mapa de procedimientos, mostrando

el flujo de actividades: se toman decisiones (bifurcaciones) de acuerdo a las
condiciones (condición de guarda), para luego pasar a la siguiente actividad o
estado (transición). Este modelo también permite representar actividades que
ocurren en paralelo, o aquellos casos en los que una única actividad
desencadena más de una tarea (división de control), o cuando se unen dos o
más actividades para formar una tercera (unión de control). [DAVILA, 2006]
1.2.2.17 Documento ESRE / Casos de Uso
El objetivo del documento ESRE (Documento de ESpecificación de

REquerimientos) es el de especificar los requerimientos del sistema, o sea
"qué" debe hacer el sistema. Solamente se incluyen los requerimientos del
- 47 -
producto. Estos requerimientos se pueden clasificar en dos grandes

categorías, los no-funcionales y los funcionales.
Lista de requerimientos
La lista de requerimientos forma parte del documento de especificación de

requerimientos. En este documento se listan los requerimientos funcionales
que el sistema debe satisfacer. [CRAIG, 1999]
Caso de uso
El caso de uso es un documento narrativo que describe la secuencia de

eventos de un actor (agente externo) que utiliza un sistema para completar un
proceso. Es una herramienta diseñada para especificar el comportamiento de
un sistema.
Este documento describe la posible secuencia de interacciones entre el

sistema y uno o más actores, en respuesta a un estímulo inicial proveniente de
un actor. Constituye una descripción de un conjunto de escenarios. [CRAIG,
1999]
1.2.2.18 Casa de calidad QFD
El esquema QFD (Quality Function Deployment) es una matriz que representa

las casas de calidad, en las cuales las filas representan los "qué", o sea, la lista
de los requerimientos, mientras que las columnas representan los "cómo", es
decir, cómo se llevan a cabo los requerimientos (casos de uso). [DAVILA, 2006]
Casa de calidad: Requerimientos versus Casos de Uso
Dado un requerimiento, se marcan todos los casos de uso que lo implementan

y, dado un caso de uso, se marcan todos los requerimientos en los que éste
participa.
- 48 -
1.2.2.19 Checklist
Es una lista de preguntas que el analista debe usar para evaluar cada
requerimiento. Los analistas deben verificar y marcar los puntos de esta lista
mientras leen el documento de requerimientos. Cuando se descubren
problemas potenciales, deben ser anotados, preferiblemente en una lista de
análisis.
Las checklist son útiles porque brindan un recordatorio de lo que se debe

buscar y reducen las oportunidades de pasar por alto alguna verificación
importante. También se puede aplicar con los casos de uso. [DAVILA, 2006]
1.3 METODOLOGÍAS DE OBTENCIÓN DE REQUERIMIENTOS
1.3.1 Metodología DoRCU
"La esencia de una metodología -en forma opuesta a lo que ocurre en un

método o técnica- es que ofrece un conjunto de pautas o principios que en
cualquier instancia específica pueden ser ajustadas tanto a las características
de la situación en la cual debe ser aplicada como a las personas que usan el
enfoque. Es tal la variedad de situaciones problemáticas humanas que no
habrá ningún enfoque para solución de problemas que pueda ser reducido a
una fórmula estándar y manejar aún toda la riqueza de las situaciones en
particular". (Diferencia entre método y metodología [CHECKLAND, 1989]).
Metodología DoRCU
La metodología DoRCU (Documentación de Requerimientos Centrada en el

Usuario), consta de las siguientes etapas:
• Captura de requerimientos
• Análisis de Requerimientos
- 49 -
• Especificación de Requerimientos
• Validación y Certificación de los Requerimientos
• Captura de Requerimientos.
Esta es la etapa en donde se adquiere el conocimiento del trabajo del
cliente/usuario, se busca comprender sus necesidades y se detallan las
restricciones medioambientales. Como resultado de las acciones realizadas se
tiene el conjunto de los requerimientos de todas las partes involucradas.
• Análisis de Requerimientos.
En esta etapa se estudian los requerimientos extraídos en la etapa previa a los
efectos de poder detectar, entre otros, la presencia de áreas no especificadas,
requisitos contradictorios y peticiones que aparecen como vagas e irrelevantes.
El resultado de haber llevado a cabo las tareas que involucran estos términos
puede, en más de una oportunidad, hacer que se deba regresar a la primera
etapa, a los efectos de eliminar todas las inconsistencias y falencias que se han
detectado. En esta etapa ya se realizan aproximaciones a un lenguaje técnico.
• Especificación de Requerimientos
Partiendo de lo elaborado en la etapa anterior tales como funciones, datos,
requerimientos no funcionales, objetivos, restricciones de
diseño/implementación o costos, e independientemente de la forma en que se
realice, esta etapa es un proceso de descripción del requerimiento. Si se
presentan dificultades para especificar un requerimiento se debe volver a la
etapa anterior que se crea conveniente.
• Validación y Certificación de los Requerimientos.

Esta etapa final se nutre de las anteriores y realiza la integración y validación
final de lo obtenido en cada una de las etapas anteriores dando, como
resultado final, el Documento de Requerimientos. Este documento no es uno
solo sino que, como mínimo, existen dos que son isomórficos entre sí: uno
destinado al cliente/usuario a los efectos de la certificación de los Requisitos y
- 50 -
el otro técnico, orientado a nutrir las restantes etapas de la Ingeniería de

Software; y, al igual que en el caso anterior, su resultado puede ser la
necesidad de retornar a la especificación e incluso a la captura; iterando entre
etapas y sin perder contacto con el cliente/usuario.
Por consiguiente, la representación gráfica de la propuesta metodológica que

se hace para la Ingeniería de Requerimientos es la que se puede ver en la
figura 14. [BAEZ et all, 2006].
Figura 14. Metodología DoRCU
Considerando el tronco metodológico planteado anteriormente, se detallan a

continuación sus correspondientes subetapas.
A. Captura de Requerimientos.
- Formar el equipo multidisciplinario:

La recolección de requerimientos se debe efectuar con el asesoramiento de
profesionales especializados.
- Buscar hechos:
Declaración del contexto del problema, de los objetivos globales, límites e
interfaces para el sistema original.
- 51 -
- Recolectar y clasificar requerimientos:

En esta etapa se obtienen: objetivos, necesidades y requerimientos de clientes
y usuarios. Estas necesidades y requerimientos son verificadas
comparándolas con los objetivos globales del sistema original expresados
durante el hallazgo de hechos.
Una vez recolectados los requerimientos, se debe proceder a clasificar los

mismos en funcionales y no funcionales.
- Evaluar y racionalizar:
Debe realizarse una valoración del riesgo, para encaminar las inquietudes
técnicas, de costos y de tiempo. Debe examinarse la coherencia en la
información reunida en subetapas previas, para determinar si los
requerimientos verdaderos están escondidos o expresados explícitamente.
- Dar prioridad:
En esta etapa, contando ya con requerimientos consistentes, se da un orden de
prioridades, esto permite una disminución de los costos y ahorro de tiempo en
procesamiento de los inevitables cambios de los requerimientos.
Los requerimientos deben tener prioridades basándose en las necesidades del

usuario, costo y dependencia.
- Integrar y validar:
Esta tarea se lleva a cabo de manera tal que sea posible obtener un conjunto
de requerimientos, expresados en el lenguaje del usuario, de los cuales se
pueda validar la consistencia con respecto a las metas organizacionales
obtenidas en la primera etapa.
- Documentar la etapa:
Elaborar la lista final de los términos del lenguaje del UdI, y la de sentencias de
los requerimientos obtenidos (DE).
- 52 -
B. Análisis de Requerimientos
- Reducir ambigüedades en los requerimientos:

En esta subetapa se realizan las tareas que permiten eliminar los términos que
tienen más de una acepción (significado).
- Traducir a lenguaje técnico los requerimientos:

Los requerimientos, ya con menos ambigüedades, deben ser tratados a los
efectos de llevarlos a un lenguaje que se vaya aproximando al lenguaje técnico.
Mediante esta traducción se busca aproximar los términos del usuario a los
términos del sistema de software.
- Plantear un modelo lógico:

En la presente subetapa se debe construir un modelo del problema ya sea en
términos de diagramas de flujo o cualquier otro tipo de representación que se
considere conveniente para el modelado y que permita, además, establecer un
vínculo con la Etapa de Especificación.
Este documento, dado el caso, puede resumirse a la colección de los modelos
lógicos a que se ha arribado (DA)
C. Especificación de Requerimientos
- Determinar el tipo de requerimiento:

Considerando que existen diferentes tipos de requerimientos, determinar
unívocamente a cual de ellos pertenece el que se está tratando.
- Elegir la herramienta de especificación acorde al tipo de requerimiento:

Una vez definido el tipo de requerimiento, seleccionar la herramienta de
representación (esta debe ser formal o semiformal) acorde a dicho tipo y al tipo
de especificación que se desea realizar.
- 53 -
- Especificar de acuerdo a la herramienta seleccionada:

Representar el requerimiento sobre la base de la elección realizada en la etapa
anterior.
Confeccionar el documento representativo de la etapa, incorporando al mismo
toda extensión que se considere de utilidad para la etapa de Validación y
Certificación de Requerimientos (DP).
D. Validación y Certificación de los Requerimientos
- Seleccionar las fuentes de información entre DE y DA a los fines de validar el

DP: En esta etapa se procede a validar el documento de especificación DP a
partir de los documentos obtenidos de las etapas de captura (DE) y análisis
(DA), seleccionando como fuente de información aquellos materiales que más
aportan. El documento de especificación (DP) validado se llamará, en
adelante, documento de requerimientos técnico (DRT).
- Elegir o diseñar el modelo de documento acorde al grado de detalle requerido

y al lector final.
- Elegir la herramienta de documentación que mejor se aplica al modelo

seleccionado: Como no todos los modelos pueden ser plasmados con una
misma herramienta, se debe seleccionar la que mejor se adecue al problema
entre todas las alternativas posibles.
- Documentar respetando los estándares vigentes a la fecha de realización del

documento de requerimientos: Elaborar el documento de requerimientos
orientado al usuario (DRU) a partir del documento de requerimientos técnico
(DRT).
- 54 -
- Verificar que el documento de requerimientos del usuario DRU sea isomórfico

con el documento técnico DRT.
- Certificar el documento de requerimientos DRU a través del conforme del

usuario: Proceder a la aprobación del DRU por medio del conforme del cliente,
y de esta manera dar por aprobado el Documento de Requerimientos Técnico
DRT, el que será utilizado por las restantes etapas de la Ingeniería de
Software.
1.3.2 Goal-Based Requirements Analysis Method
Goal-Based Requirements Analysis Method (GBRAM) provee mecanismos de

representación adecuados para la comprensión de los stakeholders, facilita la
comunicación de los stakeholders con los analistas a través de un lenguaje
entendible, y produce requerimientos relativamente fáciles de validar. Como
método basado en Objetivos, se concentra en establecer los fundamentos que
justifican los requerimientos de software.
El propósito de GBRAM es desarrollar, validar y afirmar un método basado en

metas u objetivos, otorgando soporte procedural para la identificación,
elaboración, refinamiento, y organización de objetivos, en la especificación de
Sistemas de Información basados en Software. En este enfoque los objetivos
se describen mediante un esquema particular de componentes (ver Tabla 2).
[THOMAS, 2006].
Componente Descripción
Nombre de Meta Es el identificador único para cada
Objetivo.
Tipo Las metas son clasificadas de
acuerdo al comportamiento
requerido: obtener algún estado
(“Achievement”) o mantener alguna
condición o estado (“Maintenance”).
Descripción Es un texto informal que describe
una meta u objetivo.
Acción Es el nombre que se le otorga a la
operacionalización de una meta.
Representa el comportamiento
- 55 -
necesario para satisfacer el objetivo.
Agente Es el responsable de completar o

cumplir un objetivo.
Stakeholders Son las personas interesadas en
que una meta u objetivo sea
cumplido.
Restricciones Limitaciones bajo las cuales un
objetivo debe cumplirse. Una
restricción especifica algún
requerimiento o condición que debe
cumplirse para lograr un objetivo.
Obstáculos Circunstancias que puedan impedir
que un objetivo sea cumplido.
Precondiciones Condición que debe existir para
posibilitar el logro de un objetivo.
Post-condiciones Condición a la que se arriba luego
de obtener o completar un objetivo.
Sub-Metas Cada sub-meta debe mapear a una
acción. Si mapea a varias acciones,
debería ser descompuesta y
refinada.
Tabla 2. Esquema de objetivo de GBRAM
En GBRAM se ejecutan las siguientes actividades principales:
a. Identificar Metas y Objetivos

b. Organizar y Clasificar Metas
c. Refinar y Elaborar Metas
d. Operacionalizar Metas en Requerimientos.
1.3.2.1 Enfoque de escenarios de Leite
Los Escenarios son descripciones parciales del funcionamiento del sistema,

que se concentran en un momento específico de la aplicación. Los Escenarios
no son formales, y se los puede representar con una variedad de recursos.
Si bien cada Escenario es una descripción parcial del comportamiento de la

aplicación, ninguno es independiente del resto y cada uno tiene una relación
semántica con los otros. En la siguiente tabla se reproduce el esquema de
representación del enfoque de escenarios elegido.
- 56 -
Componente Descripción
Nombre Identifica al escenario
Objetivo Establece la finalidad del escenario
Contexto Describe las acciones previas
necesarias para iniciar el escenario,
las precondiciones, la ubicación
física y temporal.
Recursos Identifican los objetos pasivos con
los cuales los actores trabajan
Actores Detalla las entidades que se
involucran activamente en el
escenario
Set de episodios Cada episodio representa una
acción realizada por un actor, donde
participan otros actores y se utilizan
recursos. Los episodios se ejecutan
secuencialmente. Un episodio
también puede referenciar a un
escenario. Se incluyen restricciones
del escenario o episodio según
corresponda
Casos alternativos Menciona los casos de excepción,
que pueden corresponder a otros
escenarios
Tabla 3. Esquema de escenario de Leite
El Objetivo del Escenario es parte de la descripción del Objetivo con formato

GBRAM. El enfoque de Julio Leite incluye el uso de lenguaje natural para la
captura y construcción de Escenarios, utiliza un vocabulario bien definido del
Universo de Discurso: el Léxico Extendido del Lenguaje (LEL). La construcción
de Escenarios se basa en el LEL. [THOMAS, 2006].
1.3.2.1.1 Léxico Extendido del Lenguaje (LEL)

[GIL, 2006]
El Léxico Extendido del Lenguaje (LEL) es un conjunto de términos

provenientes del lenguaje de la aplicación, donde se identifica la semántica de
cada término, permitiendo de esta manera que el Ingeniero de Software
conozca el lenguaje del usuario y enfoque la traceabilidad de los
requerimientos.
El LEL está compuesto por un conjunto de símbolos que identifican el lenguaje

de la aplicación. Los símbolos son, en general, las palabras o frases utilizadas
- 57 -
por el usuario y que repite con más frecuencia. También se incluyen aquellas
palabras o frases que son relevantes para el dominio del problema más allá de
su frecuencia de repetición. Los símbolos se obtienen por ejemplo, mediante
entrevistas, observaciones directas e indirectas y lectura de documentos. Se
genera una lista con todos los símbolos reconocidos. Durante el proceso de
recolección, el ingeniero de software procura entender el significado de cada
símbolo.
La semántica de cada símbolo se representa con una o más nociones y uno o

más impactos. El impacto puede no existir. La noción indica qué es el
símbolo y el impacto cómo repercute en el sistema. Ambos atributos se
formulan desde el punto de vista de la aplicación. Por lo tanto, cada símbolo
tiene un “nombre” que lo identifica, una “noción” y un “impacto” que lo
describen. El conjunto de símbolos forman una red, que permite representar al
LEL en un hipertexto y navegar en él para conocer todo el vocabulario del
dominio.
Figura 15. Diagrama Entidad-Relación para el modelo del Léxico Extendido del Lenguaje
A continuación se presenta el modelo utilizado para representar los símbolos

del LEL:
- 58 -
Figura 16. Modelo del Léxico Extendido del Lenguaje
Donde:
Sentencia está compuesto por Símbolos y No-Símbolos pertenecientes al
vocabulario mínimo, + significa composición, {x} significa cero o más
ocurrencias de x, ( ) es usado para agrupamiento, | significa or, y [x] significa
que x es opcional.
El proceso de construcción consta de 6 etapas dependientes entre sí, y que, en

algunos casos, se desarrollan en forma simultánea.
• Identificar las fuentes de información.

• Identificar los símbolos.
• Clasificar los símbolos.
• Describir los símbolos.
• Verificar el LEL.
- 59 -
• Validar el LEL con los clientes-usuarios.
1.3.3 SSM Soft System Methodology.

[SUMANO, 2006]
Metodología desarrollada en Inglaterra por Peter Chekland en la década de los

1970, cuyo enfoque orientado a la meta se ha venido perfeccionando
paulatinamente basándose en el Pensamiento de Sistemas y aceptando una
enorme influencia de las ciencias sociales.
Aunque la notación es variada y flexible se hace hincapié en el uso de gráficas

para lograr una rica imagen (rich picture) de situaciones. Entre los gráficos
propuestos (sin limitarse a ellos) están los que se muestran en la Figura 17 y
tienen el significado siguiente:
Una actividad determinada es una acción tomada por un grupo de seres

humanos que se basan en su experiencia del mundo real y en intenciones que
se forman debido al medio ambiente en que se esté trabajando y las
restricciones que se tengan. Las actividades determinadas repercutirán en un
grupo de personas y podrán verse afectadas por otras actividades
determinadas.
Figura 17. Formas utilizadas en SSM
En SSM se trata de plantear el sistema deseado para alcanzar la meta. Para

ello debe fundamentarse el Análisis de la situación del problema desde varios
puntos de vista. SSM consiste en siete etapas como se muestra en la Figura
18.
- 60 -
Figura 18. Los siete estados del modelo de SSM
• Poner en claro la situación del problema. El propósito es identificar quienes

están involucrados, cuál es su percepción de la situación, cuáles son las
estructuras organizacionales y qué procesos se llevan a cabo.
• Expresar la situación. Se recomienda que se haga gráficamente, utilizando

lo que SSM denomina una rica imagen (rich picture) en donde, por medio de
iconos de varios tipos, incluidos los de la Figura 11, se muestre el flujo de la
situación actual.
• Hacer la selección de como ver paulatinamente la situación de manera que

se pueda producir percepciones que den pié a definiciones raíz. Lo
esencial en este punto es producir varias imágenes ricas en detalles de
cada punto de vista diferente o subsistemas. Así, cada punto de vista
relevante tendrá su definición raíz. Cada definición raíz en SSM es
construida para posteriormente determinar su relevancia en el sistema a
- 61 -
desarrollar. Para determinar si la definición raíz está bien escrita debe

contener los elementos de la guía CATWOE mnemónico correspondiente a
las siglas que se explican en seguida:
o C (Customer). Se trata de la persona que será beneficiaría o víctima
del sistema.
o A (Actors). Los actores, que llevarán a cabo las actividades
definidas.
o T (Transformation). Las transformaciones de entrada o salida.
o W (Weltanschauung). Punto de vista del mundo real.
o (Owner). Propietario que tiene el poder de autorizar o rechazar el
sistema.
o E (Environmental). Restricciones del medio ambiente.
• Construir modelos conceptuales. Un modelo debe corresponder a las

actividades humanas de alguna definición raíz; de tal manera que hay una
gran iteración entre las actividades 3 y 4.
• Comparar los modelos conceptuales con el mundo real. Se hace una
comparación de las actividades modeladas en el paso cuatro versus el
mundo real. Para cada actividad deben contestarse las siguientes
preguntas:
o ¿Es una actividad que realmente se lleva a cabo en el mundo real?
o ¿Cómo se realiza?
o ¿Cómo se mide su funcionamiento?
o ¿La actividad se lleva a cabo de manera efectiva?
• Identificar cambios factibles y deseables. En esta etapa se deben investigar

si son factibles culturalmente y sistemáticamente deseables. Esto se
determina a través de reuniones conjuntas con la gente involucrada para
recoger los diferentes puntos de vista y analizar la situación actual.
• Recomendaciones para la toma de acciones que mejoren la percepción

problema.
- 62 -
1.3.4 Color-X.
Es una herramienta automática y una metodología basada en la lingüística

computacional y el análisis orientado a objetos. Comprende varias etapas de la
Ingeniería de Requerimientos: especificación, validación y verificación de
requerimientos. COLOR-X es un acrónimo de Conceptual Linguistically based
Object oriented Representation language for information and communication
systems, más una X que agrega el autor J.F.M. Burg. La metodología fue
realizada como una tesis doctoral en la Universidad de Vrije, Holanda [BURG,
1997].
La forma en que COLOR-X trabaja se muestra en la Figura 19. Todos los

procesos son automáticos o semiautomáticos, es decir, son en línea con el
usuario. Se parte del hecho de que ya existe al menos una primera redacción
de los requerimientos del sistema.
Figura 19. Forma de trabajar con COLOR-X.
Cada fase está representada en la Figura 19 por un círculo, que a su vez se

divide en otras etapas y que utilizan los modelos conceptuales de COLOR-X,
- 63 -
los cuales son los escenarios y modelos de Lenguaje natural. Todas las fases
son ejecutadas iterativamente para actualizar la ERS de acuerdo con los
resultados de la validación y la verificación. Los usuarios pueden dar
información adicional en cualquier momento. [SUMANO, 2006]
1.3.5 Rare-Idiom.
Esta metodología presenta el enfoque de reuso, el cual ha tomado fuerza en la

última década. Se basa en las propiedades estructurales de los documentos
de requerimientos y los procesos realizados para su producción. La
metodología propone varias formas de reusar los requerimientos y sus
artefactos asociados, todo descrito en términos de patrones de reuso de
requerimientos. [SUMANO, 2006]
RARE-IDIOM fue elaborada por Jacob Cybulski en la Universidad de

Melbourne en Australia y es un acrónimo de Reuse-Assisted Requirement
Engineering with Informal Document Interpreter Organizer and Manager, su
idea es reutilizar en todo momento a partir de que el sistema es solicitado por
el cliente partiendo de ERS anteriores como se muestra en la Figura 20.
Figura 20. Reuso de ERS anteriores.
Además propone un nuevo ciclo de vida de Ingeniería de Requerimientos que

introduce el reuso y que quedaría como se muestra en la Tabla 4. En la fase
tres de la Tabla 4 se propone la aplicación de varios tipos de técnicas:
- 64 -
analíticas, de procesos y por productos. Para la Generación y Evaluación de

Alternativas RARE-IDIOM propone los siguientes pasos:
• Clasificar los requerimientos y artefactos reutilizables del sistema actual en
términos precisos para que tal clasificación pueda ser usada al compararlos
con los artefactos reutilizables anteriores.
• Precisar la búsqueda de artefactos candidatos mediante la selección de
categorías de requerimientos en términos del dominio del problema, tipos
de requerimientos y su semántica.
• Reducir el alcance de la búsqueda de artefactos al seleccionar categorías
de artefactos en términos de la solución del problema.
• Comparar el texto de la descripción del problema contra la colección
estructurada de artefactos reusables, aspecto por aspecto.
• Comparar los beneficios y daños de seleccionar cada artefacto candidato
para refinar un enunciado de requerimiento actual.
• Seleccionar la variante que mejor empate con el requerimiento actual.
• Continuar seleccionando categorías de requerimientos alternativas
mediante la generalización de los requerimientos actuales hasta encontrar
un artefacto adecuado o ya no haya posibilidad de hallarlo.
Tabla 4. Reuso mediante las actividades del proceso de obtención de requerimientos.
- 65 -
1.3.6 RUP (Rational Unified Process)
Una disciplina es una colección de actividades relacionadas, las cuales se unen

a un área mayor dentro del total del proyecto. La agrupación de actividades en
disciplinas es principalmente una ayuda para comprender el proyecto de una
forma “tradicional”. La obtención de requerimientos es una de las disciplinas
consideradas en el RUP.
El flujo de trabajo de la obtención de requerimientos se muestra a continuación:
Figura 21. Flujo de trabajo de la disciplina de Requerimientos.
Análisis del problema
El propósito del flujo de trabajo de detalle es acordar la magnitud del problema

y la forma de resolverlo. El análisis del problema incluye identificar los
stakeholders, definir el límite, e identificar las restricciones que debe tener el
- 66 -
sistema. El primer paso en el análisis del problema es asegurarse de que

todas las partes involucradas estén de acuerdo en cual es el problema y las
necesidades por resolver con el sistema.
Comprender las necesidades de los stakeholders
El propósito de este flujo de trabajo detallado es comprender las necesidades

de los stakeholders para recopilar la información sobre el producto deseado o
considerado.
Definir el sistema
El propósito de este flujo de trabajo es definir el alcance y los requerimientos de

alto nivel para de esta manera detallar los requerimientos del sistema.
Gestión del alcance del sistema
Su propósito es hacer que el alcance del sistema sea lo más explícito posible y
enfocarse en la gestión del cuerpo de requerimientos de trabajo de la iteración.
Refinar la especificación del sistema (SRS)
La especificación de requerimientos software (SRS) captura los requerimientos

para todo el sistema, o una porción de este.
Gestión de cambios de requerimientos
El propósito de este flujo de trabajo detallado es determinar el impacto de

cambios en los requerimientos y gestionar el bajo impacto de los cambios
aprobados para ser accionados.
- 67 -
Artefactos Reglas del negocio, visión, requerimientos de los stakeholders,

especificaciones suplementarias, plan de gestión de requerimientos, atributos
de requerimientos, Modelo de casos de uso, Casos de uso y glosario, plan de
iteración, plan de desarrollo del software, cambios en los requerimientos
(aprobados) y un storyboard (descripción lógica y conceptual de la
funcionalidad del sistema para un escenario específico).
1.3.7 Desarrollo Conjunto de Aplicaciones (JAD, Join Application

development)
Fue desarrollada por IBM en 1977, se desarrollan a lo largo de un conjunto de

reuniones en grupo durante un período de 2 a 4 días. En estas reuniones se
ayuda a los clientes a y usuarios a formular problemas y explorar posibles
soluciones, involucrándolos y haciéndolos sentirse partícipes en el desarrollo
del proyecto.
Esta técnica se basa en 4 principios: 1) Dinámica de grupo, 2) uso de ayudas

visuales para mejorar la comunicación, 3) mantener un proceso organizado y
racional y 4) una filosofía de documentación WYSIWYG (lo que se ve es lo que
se obtiene), por la que durante las reuniones se trabaja directamente sobre los
documentos a generar.
El JAD tiene dos grandes pasos, el JAD / Plan cuyo objetivo es elicitar y
especificar requerimientos y JAD / Desing, en el que se aborda el diseño del
software. Debido a las necesidades de organización que requiere y a que no
suele adaptarse a los horarios de trabajos de los clientes y usuarios, está
técnica no suele utilizarse con frecuencia, aunque cuando se aplica se suelen
obtener buenos resultados. [SUMANO, 2006].
- 68 -
2. DISEÑO METODOLÓGICO
2.1 MÉTODO DE INVESTIGACIÓN

[OCHOA, 2006]
Definición: Es una especie de brújula en la que no se produce automáticamente

el saber, pero que evita perderse en el caos aparente de los fenómenos,
aunque solo sea porque indica como no plantear los problemas y como no
sucumbir en el embrujo de ciertos prejuicios predilectos. El método
independiente del objeto al que se aplique, tiene como objetivo solucionar
problemas.
2.1.1 Las diversas clases de métodos de investigación
Se pueden establecer dos grandes clases de métodos de investigación: los

métodos lógicos y los empíricos. Los primeros son todos aquellos que se
basan en la utilización del pensamiento en sus funciones de deducción, análisis
y síntesis, mientras que los métodos empíricos, se aproximan al conocimiento
del objeto mediante su conocimiento directo y el uso de la experiencia, entre
ellos se encuentra la observación y la experimentación.
2.1.1.1 Métodos lógicos
2.1.1.1.1 Método lógico deductivo
Mediante ella se aplican los principios descubiertos a casos particulares, a

partir de un enlace de juicios. El papel de la deducción en la investigación es
doble:
- 69 -
a. Primero consiste en encontrar principios desconocidos, a partir de los

conocidos. Una ley o principio puede reducirse a otra más general que la
incluya.
b. También sirve para descubrir consecuencias desconocidas, de principios
conocidos. Si se sabe que la formula de la velocidad es v=e/t, se puede
calcular la velocidad de un avión. La matemática es la ciencia deductiva por
excelencia; parte de axiomas y definiciones.
- Método deductivo directo – inferencia o conclusión inmediata. Se

obtiene el juicio de una sola premisa, es decir que se llega a una conclusión
directa sin intermediarios. Ejemplo: "Los libros son cultura", "En consecuencia,
algunas manifestaciones culturales son libros".
- Método deductivo indirecto – inferencia o conclusión mediata - formal.

Necesita de silogismos lógicos, en donde silogismo es un argumento que
consta de tres proposiciones, es decir se comparan dos extremos (premisas o
términos) con un tercero para descubrir la relación entre ellos. La premisa
mayor contiene la proposición universal, la premisa menor contiene la
proposición particular, de su comparación resulta la conclusión. Ejemplo: "Los
ingleses son puntuales" - "William es ingles" - "Por tanto, William es puntual".
2.1.1.1.2 Método hipotético-deductivo
Un investigador propone una hipótesis como consecuencia de sus inferencias

del conjunto de datos empíricos o de principios y leyes más generales. En el
primer caso arriba a la hipótesis mediante procedimientos inductivos y en
segundo caso mediante procedimientos deductivos. Es la vía primera de
inferencias lógico/deductivas para arribar a conclusiones particulares a partir de
la hipótesis y que después se puedan comprobar experimentalmente.
- 70 -
2.1.1.1.3 Método lógico inductivo
Es el razonamiento que, partiendo de casos particulares, se eleva a

conocimientos generales. Este método permite la formación de hipótesis,
investigación de leyes científicas, y las demostraciones.
En el método de inducción se hallan otros métodos para encontrar causas a

partir de métodos experimentales:
- Método de concordancia: Compara entre si varios casos en que se presenta

un fenómeno natural y señala lo que en ellos se repite, como causa del
fenómeno.
- Método de diferencia: Se reúnen varios casos y se observa que siempre

falta una circunstancia que no produce el efecto, permaneciendo siempre todas
las demás circunstancias, concluimos que lo que desaparece es la causa de lo
investigado.
- Método de variaciones concomitantes: Si la variación de un fenómeno se

acompaña de la variación de otro fenómeno, concluimos que uno es la causa
de otro.
- Método de los residuos: Consiste en ir eliminando de un fenómeno las

circunstancias cuyas causas son ya conocidas. La circunstancia que queda
como residuo se considera la causa del fenómeno.
2.1.1.1.4 Método lógico: la analogía
Consiste en inferir de la semejanza de algunas características entre dos

objetos, la probabilidad de que las características restantes sean también
semejantes. Los razonamientos analógicos no son siempre validos.
- 71 -
2.1.1.1.5 El método histórico
Está vinculado al conocimiento de las distintas etapas de los objetos en su

sucesión cronológica, para conocer la evolución y desarrollo del objeto o
fenómeno de investigación se hace necesario revelar su historia, las etapas
principales de su desenvolvimiento y las conexiones históricas fundamentales.
Mediante el método histórico se analiza la trayectoria concreta de la teoría, su
condicionamiento a los diferentes períodos de la historia. Los métodos lógicos
se basan en el estudio histórico poniendo de manifiesto la lógica interna de
desarrollo, de su teoría y halla el conocimiento más profundo de esta, de su
esencia. La estructura lógica del objeto implica su modelación.
2.1.1.1.6 Método sintético
Es un proceso mediante el cual se relacionan hechos aparentemente aislados y

se formula una teoría que unifica los diversos elementos. Consiste en la
reunión racional de varios elementos dispersos en una nueva totalidad, este se
presenta más en el planteamiento de la hipótesis. El investigador sintetiza las
superaciones en la imaginación para establecer una explicación tentativa que
someterá a prueba.
2.1.1.1.7 Método analítico
Se distinguen los elementos de un fenómeno y se procede a revisar

ordenadamente cada uno de ellos por separado. La física, la química y la
biología utilizan este método; a partir de la experimentación y el análisis de
gran número de casos se establecen leyes universales. Consiste en la
extracción de las partes de un todo, con el objeto de estudiarlas y examinarlas
por separado, para ver, por ejemplo las relaciones entre las mismas.
Estas operaciones no existen independientes una de la otra; el análisis de un

objeto se realiza a partir de la relación que existe entre los elementos que
- 72 -
conforman dicho objeto como un todo; y a su vez, la síntesis se produce sobre

la base de los resultados previos del análisis.
2.1.1.1.8 Método de la abstracción
Es un proceso importantísimo para la comprensión del objeto, mediante ella se

destaca la propiedad o relación de las cosas y fenómenos. No se limita a
destacar y aislar alguna propiedad y relación del objeto asequible a los
sentidos, sino que trata de descubrir el nexo esencial oculto e inasequible al
conocimiento empírico.
2.1.1.1.9 Método de la concreción
Mediante la integración en el pensamiento de las abstracciones puede el

hombre elevarse de lo abstracto a lo concreto; en dicho proceso el
pensamiento reproduce el objeto en su totalidad en un plano teórico. Lo
concreto es la síntesis de muchos conceptos y por consiguiente de las partes.
Las definiciones abstractas conducen a la reproducción de lo concreto por
medio del pensamiento. Lo concreto en el pensamiento es el conocimiento
más profundo y de mayor contenido esencial.
2.1.1.1.10 Método genético
Implica la determinación de cierto campo de acción elemental que se convierte

en célula del objeto, en dicha célula están presentes todos los componentes del
objeto así como sus leyes más trascendentes.
2.1.1.1.11 Método de la modelación
Es justamente el método mediante el cual se crean abstracciones con vistas a

explicar la realidad. El modelo como sustituto del objeto de investigación. En
el modelo se revela la unidad de lo objetivo y lo subjetivo.
- 73 -
La modelación es el método que opera en forma práctica o teórica con un

objeto, no en forma directa, sino utilizando cierto sistema intermedio, auxiliar,
natural o artificial.
2.1.1.1.12 Método sistémico
Está dirigido a modelar el objeto mediante la determinación de sus

componentes, así como las relaciones entre ellos. Esas relaciones determinan
por un lado la estructura del objeto y por otro su dinámica.
2.1.1.1.13 Método dialéctico
La característica esencial del método dialéctico es que considera los

fenómenos históricos y sociales en continuo movimiento. Dio origen al
materialismo histórico, el cual explica las leyes que rigen las estructuras
económicas y sociales, sus correspondientes superestructuras y el desarrollo
histórico de la humanidad. Aplicado a la investigación, afirma que todos los
fenómenos se rigen por las leyes de la dialéctica, es decir que la realidad no es
algo inmutable, sino que está sujeta a contradicciones y a una evolución y
desarrollo perpetuo. Por lo tanto propone que todos los fenómenos sean
estudiados en sus relaciones con otros y en su estado de continuo cambio, ya
que nada existe como un objeto aislado.
Este método describe la historia de lo que nos rodea, de la sociedad y del

pensamiento, a través de una concepción de lucha de contrarios y no
puramente contemplativa, más bien de transformación. Estas concepciones
por su carácter dinámico exponen no solamente los cambios cuantitativos, sino
los radicales o cualitativos.
- 74 -
2.1.1.2 Métodos empíricos
Definidos de esa manera por cuanto su fundamento radica en la percepción

directa del objeto de investigación y del problema.
2.1.1.2.1 Observación científica
El investigador conoce el problema y el objeto de investigación, estudiando su

curso natural, sin alteración de las condiciones naturales, es decir que la
observación tiene un aspecto contemplativo.
La observación configura la base de conocimiento de toda ciencia y, a la vez,

es el procedimiento empírico mas generalizado de conocimiento. Mario Bunge
reconoce en el proceso de observación cinco elementos:
a. El objeto de la observación
b. El sujeto u observador
c. Las circunstancias o el ambiente que rodean la observación
d. Los medios de observación
e. El cuerpo de conocimientos de que forma parte la observación
2.1.1.2.2 La experimentación científica
Implica alteración controlada de las condiciones naturales, de tal forma que el

investigador creará modelos, reproducirá condiciones, abstraerá rasgos
distintivos del objeto o del problema. La experimentación depende del grado
de conocimiento del investigador, a la naturaleza, a las circunstancias del
objeto y al problema de investigación, es decir no siempre se podrá realizar
experimentación. La experimentación debe seguir ciertas reglas:
a. El fenómeno de que se trate debe aislarse para estudiarlo mejor.
b. El experimento debe repetirse en las mismas circunstancias para
comprobar si siempre es el mismo.
- 75 -
c. Las condiciones del experimento deben alterarse para investigar en que

grado modifican al fenómeno.
d. El experimento debe durar el tiempo suficiente para que se produzca el
fenómeno deseado.
2.1.1.2.3 La medición
Se desarrolla con el objetivo de obtener la información numérica acerca de una

propiedad o cualidad del objeto o fenómeno, donde se comparan magnitudes
medibles y conocidas. Es decir es la atribución de valores numéricos a las
propiedades de los objetos. En la medición hay que tener en cuenta el objeto y
la propiedad que se va a medir, la unidad y el instrumento de medición, el
sujeto que realiza la misma y los resultados que se pretenden alcanzar.
En las ciencias sociales, naturales y técnicas no basta con la realización de las

mediciones, sino que es necesario la aplicación de diferentes procedimientos
que permitan revelar las tendencias, regularidades y las relaciones en el
fenómeno objeto de estudio, uno de estos procedimientos son los estadísticos,
tanto los descriptivos como los inferenciales.
- 76 -
2.2 DISEÑO METODOLÓGICO
Objetivo General
Realizar un análisis comparativo de técnicas de obtención de

requerimientos para el módulo de Facturación del aplicativo
Gestasoft Hospitalario para IMSALUD (Institución Municipal de
Salud de San José de Cúcuta).
Objetivos Específicos
1. Identificar las 2. Identificar y seleccionar 3. Desarrollar un 4. Aplicar en la 5. Extraer los 6. Analizar y

principales las técnicas y herramientas análisis obtención de requerimientos especificar los
actividades de la adecuadas para el comparativo de requerimientos para el módulo requerimientos
obtención de desarrollo de las actividades técnicas y las técnicas y de Facturación identificados
requerimientos. de la obtención de herramientas de herramientas del aplicativo para el módulo
requerimientos. obtención de previamente Gestasoft de facturación.
requerimientos. seleccionadas. Hospitalario.
- 77 -
1. Identificar las
principales actividades
de la obtención de
requerimientos.
Tareas
1.1 Investigar las actividades 1.2 Analizar las actividades de

propias de la obtención de la obtención de requerimientos
requerimientos y las diversas y los esquemas propuestos
opiniones de los autores por los autores para cada una
respecto a ellas. de ellas.
Resultado
Marco teórico sobre las actividades de la

obtención de requerimientos y demás temas
de interés tales como el Modelo del Negocio
y las Metodologías utilizadas en la obtención
de Requerimientos. (Capítulo 1)
Métodos utilizados
Método Histórico: Se analizó la Método analítico: Se extrae de la

sucesión cronológica de cada una Obtención de Requerimientos, sus
de las actividades que conforman partes, es decir, cada una de las
la obtención de requerimientos, actividades de la obtención de
sus características principales, requerimientos, con el objetivo de
definiciones y concepciones estudiarlas y analizar sus
propuestas por algunos autores. características, objetivos y
principios.
- 78 -
2. Identificar y seleccionar las técnicas y

herramientas adecuadas para el desarrollo
de las actividades de la obtención de
requerimientos.
Tareas
2.1 Investigar técnicas y 2.2 Ubicar las técnicas y 2.3 Seleccionar técnicas
herramientas. herramientas según su y herramientas.
aplicación en las
actividades de la
obtención de
requerimientos
Resultado Resultado
Resultado
Marco teórico sobre las Cuadro con la Cuadro con las Técnicas
técnicas y herramientas clasificación de las y herramientas
existentes para la técnicas y herramientas seleccionadas. (Capítulo 4)
obtención de requeri - según las actividades de
mientos. (Capítulo 1) la obtención de requeri -
mientos. (Capítulo 1)
Método
Utilizado Método
Utilizado
Método Histórico: Se Método analítico: Se tomó

analizó la sucesión cada una de las técnicas y
cronológica de cada una herramientas con el objetivo
de las técnicas y de analizarlas y clasificarlas
herramientas utilizadas en según las actividades de la
la obtención de obtención de
requerimientos. requerimientos.
- 79 -
3. Desarrollar un análisis
comparativo de técnicas y
herramientas de obtención de
requerimientos.
Tarea
3.1 Realización de un cuadro

comparativo con ventajas y
desventajas de las técnicas y
herramientas.
Resultado
Análisis comparativo de
técnicas y herramientas.
(Capítulo 4).
Método utilizado
Método de la abstracción: Se trata de

comprender cada una de las técnicas y
herramientas utilizadas en la obtención de
requerimientos, para determinar sus
propiedades e interrelaciones, con el objetivo
de conocer sus ventajas y desventajas
respecto a si mismas, a su efectividad y uso.
- 80 -
4. Aplicar en la obtención de requerimientos las técnicas y

herramientas previamente seleccionadas.
Tareas
4.1 Consulta y análisis de 4.2 Propuesta de un 4.3 Definición del 4.4 Explicación de 4.5 Ubicación de las
diferentes metodologías y método para la método propuesto para las etapas y técnicas y herramientas en
métodos empleados en la obtención de la obtención de subetapas del cada una de las etapas y
obtención de requerimientos como requerimientos. requerimientos. método. subetapas.
base para proponer uno nuevo.
Resultado
Resultados
Investigación de algunas metodologías

utilizadas en la obtención de Método para la obtención de Aplicación del método para la
requerimientos las cuales se definen en el requerimientos. (Capítulo 4) obtención de requerimientos.
(Capítulo 4)
marco teórico. (Capítulo 1)
Método utilizado
Método Histórico: Se analizaron algunas

metodologías con el objetivo de conocer Métodos utilizados
su desarrollo, propiedades y
características de aplicabilidad al proyecto.
- 81 -
Método de la abstracción: Se Método de la Método sistémico: Se Método de Modelación:

destacan las relaciones entre cada concreción: Se reprodujo determinaron las etapas Representación gráfica y
una de las actividades de la obtención el método propuesto para y subetapas del método visual del método para
de requerimientos facilitando de esta la obtención de para facilitar su permitir su comprensión,
manera su comprensión, con el requerimientos en un modelado, describiendo creando abstracciones con
objetivo de formular un método plano teórico donde se y la estructura y el fin de explicar la
efectivo, enfocado en el usuario. especifican sus principios. dinámica del mismo. realidad.
- 82 -
5. Extraer los requerimientos para el módulo de

Facturación del aplicativo Gestasoft Hospitalario.
Tareas
5.1 Realización del 5.2 Aplicación del método de la 5.3 Extracción de los
modelo del negocio con el obtención de requerimientos requerimientos en el área de
objetivo de obtener reutilizando ciertos artefactos salud utilizando el método
información real y actual obtenidos durante el modelado del propuesto.
sobre la empresa objetivo. negocio.
Resultado Resultados
Modelo del Requerimientos extraídos al Relación entre el modelamiento

negocio. aplicar el método propuesto para del negocio y el método
(Capítulo 3) la obtención de requerimientos. propuesto para la obtención de
(Capítulo 4) requerimientos. (Capítulo 4)
- 83 -
Métodos utilizados
Método utilizado
Método de Método analítico: Se Método de la

modelación: analizan cada una de concreción: Se
Representación visual, las etapas del plasma en un
por medio de diagramas modelado del negocio plano teórico la
y modelos, de los y del método relación entre
requerimientos. propuesto para los objetos
Métodos utilizados establecer su relación. involucrados.
Método Método Método de la Método de la Método Método de

histórico: analítico: Se abstracción: Se concreción: sistémico: Modelación:
Análisis tomaron cada analizó cada Tomando como Según el Representación
cronológico uno de los uno de los base el análisis de las visual de los
sobre los procesos y procesos y conocimiento partes de la anteriores
diferentes subprocesos, demás entes obtenido de la organización, en artefactos
procesos de la con los actores que estos abstracción se el área de salud, teóricos y
organización. y demás incluyen, sus procede a se pudo análisis
participantes relaciones, organizar la describir su realizados de
que los propiedades, información en estructura y los procesos y
conforman, para ambiente y artefactos dinámica, subprocesos de
de esta manera modo de teóricos para basados en la organización
investigar sus operación, con facilitar su información (diagramas de
propiedades y el fin de compresión. actual y real. procesos,
comprender su comprender el actividad, entre
modo ejecución todo que otros).
y relación. conforman.
- 84 -
6. Analizar y especificar los

requerimientos identificados
para el módulo de
facturación.
Tareas
6.1 Aplicación del 6.2 Análisis y

método propuesto especificación de los
para la obtención requerimientos según
de requerimientos el método propuesto
reutilizando ciertos haciendo uso de las
artefactos herramientas y
obtenidos durante técnicas
el modelado del seleccionadas para
negocio. dicho fin.
Resultados
Análisis y especificación Relación entre el

de los requerimientos modelamiento del negocio
obtenidos con la y el método propuesto
aplicación del método para la obtención de
propuesto. (Capítulo 4) requerimientos. (Capítulo 4)
Método utilizado Métodos utilizados
Método de Método analítico: Se Método de la

modelación: analizan cada una de concreción: Se
Representación las etapas del plasma en un plano
visual, por medio de modelado del negocio teórico la relación
diagramas y y del método entre las etapas del
modelos, de los propuesto para modelado del
requerimientos. establecer su relación. negocio y el método
propuesto.
- 85 -
Valor agregado
(Objetivo adicional)
Apoyo y demostración de
viabilidad.
Resultado
El modelo del negocio y la obtención de

requerimientos como solución a algunas de
las causas de fracasos de los proyectos de
software. (Capítulo 5)
Métodos utilizados
Método histórico: Método de concordancia Método de

Consulta [tomado de (lógico inductivo): variaciones
ACIS, 17 de Comparación y análisis de concomitantes
Noviembre de 2006] varias opiniones o casos (lógico inductivo):
sobre algunas de las dados por algunos Análisis de las
causas de los fracasos expertos nacionales e variaciones de las
de los proyectos de internacionales como causas y sus efectos
software a nivel Orlando Cuevas (Director en los fracasos de los
nacional con el de proyectos de proyectos para así
objetivo de identificar Informática del CIFI, proponer soluciones
sus características, Universidad de los Andes), efectivas a dichos
propiedades y Oscar Aldana (Gerente de problemas e identificar
evolución según los proyectos de Getronics la importancia del
avances Colombia), Marco Antonio modelo del negocio y
empresariales y Jiménez (ejecutivo IBM la obtención de
tecnológicos. Colombia) y Sara Cristina requerimientos en la
Mantilla (Gerente de solución.
proyecto para el área de
América Latina), respecto
a las causas de los
fracasos de los proyectos
de software, para de esta
manera identificar su
incidencia y variación
según la empresa y el
proyecto.
- 86 -
3. MODELO DEL NEGOCIO
3.1 METODO DE MODELAMIENTO DEL NEGOCIO BMM
3.1.1 Modelo del Producto
3.1.1.1 Metas del Negocio
Visión La Empresa Social del Estado (ESE) IMSALUD desea convertirse en

la Empresa líder en la prestación de servicios de salud con un alto índice de
lucro social, financiero, calidad humana y técnica de servicio, en el Municipio de
San José de Cúcuta, mediante la conservación de los principios corporativos
de eficiencia, eficacia, valor humano y calidad en la atención en un término de
cinco (5) años.
Misión Prestar servicios de salud del primer nivel de atención tanto a los
usuarios del régimen subsidiado como particulares, vinculados y del régimen
contributivo de manera eficiente, eficaz y oportuna, contribuyendo, por ende al
mejoramiento continuo de la situación de salud y de la calidad de vida en el
municipio de San José de Cúcuta.
Objetivo Contribuir al desarrollo social del municipio mejorando la calidad

de vida y reduciendo la morbilidad, la mortalidad, la incapacidad, el dolor y la
angustia evitables en la población usuaria, en la medida en que esto este a su
alcance. Producir servicios de salud eficientes y efectivos, que cumplan con
las normas de calidad establecidas, de acuerdo con la reglamentación que se
expida para tal propósito.
Objetivo Específico Metas
Optimizar el proceso de atención médica al usuario, por

Gestionar los procesos de la medio de la gestión de consultas.
división de atención en salud.
Mejorar y controlar el servicio de hospitalización.
- 87 -
Obtener exámenes de laboratorio de una manera más ágil y

efectiva.
Controlar los programas de Demanda Inducida (DI) –

Detección Precoz (DP) – Protección Específica (PE), con el
objeto de mejorar la calidad de vida de los usuarios.
Mejorar el proceso de atención al cliente.
Controlar las observaciones de tipo administrativo y técnico

(Glosas) con el fin de objetar los valores cobrados por la
prestación de servicios de salud.
Gestionar el personal médico y paramédico de la Empresa

Social del Estado, para de esta manera fortalecer los
procesos misionales.
Elaborar informes de las actividades y procedimientos que se

realizan en la división.
Formular y verificar contratos con ARS (Administradora del

Régimen Subsidiado), permitiendo un mayor cubrimiento de
salud a nivel local.
Fortalecer la calidad del personal médico y paramédico de la

institución.
Facturar los servicios prestados a determinado usuario

teniendo en cuenta su régimen y nivel de afiliación.
Controlar el estado de salud de los pacientes mejorando la

gestión de sus historias clínicas y RIPS (Registro Individual
de Prestación de Servicios).
Seguir y controlar las actividades de Promoción y Prevención

Gestionar los procesos del con el fin de mejorar la calidad de vida de los usuarios.
departamento de Promoción y
Prevención. Optimizar los programas de atención.
Gestionar los equipos e insumos necesarios para la mejora

progresiva de los servicios de atención.
Permitir un mejor cubrimiento del área de influencia de la

institución gestionando las reuniones de los comités de
vigilancia epidemiológica de cada IPS (Institución Prestadora
de Servicios de salud) y del municipio.
Elaborar informes de las actividades y procedimientos

ejecutados en el departamento.
Facturar los servicios prestados a determinado usuario

teniendo en cuenta su régimen y nivel de afiliación.
Controlar el estado de salud de los pacientes mejorando la

gestión de sus historias clínicas y RIPS (Registro Individual
de Prestación de Servicios).
- 88 -
Optimizar el proceso de requisición y entrega de

medicamentos.
Controlar el inventario, para tener disponibles los
Gestionar los procesos de medicamentos requeridos por los usuarios.
Farmacia.
Elaborar informes sobre el suministro, adquisición y
devolución de medicamentos.
Mejorar el proceso de gestión de medicamentos ejerciendo

Control sobre las farmacias satélites.
Facturar los medicamentos entregados a los usuarios según

su régimen y nivel de afiliación.
Gestionar los bienes y mercancías.
Gestionar aquellos procesos Controlar el inventario, para tener disponibles los

de Almacén que tengan medicamentos requeridos por los usuarios.
relación directa con el control
de Medicamentos. Elaborar informes sobre la adquisición y salida de
medicamentos.
Facturar los procesos de obtención y salida de

medicamentos.
Tabla 5. Objetivos específicos y Metas del negocio
3.1.1.2 Procesos del negocio
Cadena de valor:
Figura 22. Cadena de Valor
- 89 -
Jerarquía de procesos:
• Gestionar Procesos de la División de Atención en Salud
Figura 23. Jerarquía de Procesos de la División de Atención en Salud
- 90 -
• Gestionar Procesos del Departamento de Promoción y Prevención
Figura 24. Jerarquía de Procesos del Departamento de promoción y prevención

- 91 -
• Gestionar Procesos de Farmacia
Figura 25. Jerarquía de Procesos de Farmacia

- 92 -
• Gestionar Procesos de Almacén
Figura 26. Jerarquía de Procesos de Almacén
- 93 -
Procesos Primarios y de Soporte
• Gestionar Procesos de la División de Atención en Salud.
Figura 27. Procesos Primarios y de Soporte (División de Atención en Salud)
- 94 -
• Gestionar los procesos del Departamento de Promoción y Prevención
Figura 28. Procesos Primarios y de Soporte (Departamento de Promoción y Prevención)
• Gestionar los procesos de Farmacia
Figura 29. Procesos Primarios y de Soporte (Farmacia)
- 95 -
• Gestionar los procesos de Almacén
Figura 30. Procesos Primarios y de Soporte (Almacén)
Diagramas de Procesos
Gestionar Procesos de la División de Atención en Salud.
• Gestionar Atención al cliente
Figura 31. Diagrama del proceso: Gestionar atención al cliente
- 96 -
• Gestionar calidad
od Calidad
Datos de Pruebas
Personal
«Supply» «Input»
Gestionar calidad
Control de Prueba resuelta
calidad del
personal «Output»
Jefe de la Div isión
«goal»
«goal»
Fortalecer la calidad del personal
médico y paramédico de la institución.
Figura 32. Diagrama del proceso: Gestionar calidad
• Gestionar cita
od Cita
Datos de Usuario Asignar, eliminar

o modificar Citas
«Supply»
«goal»
Gestionar Cita
Asignar o Cita
Modificar cita «Output»
Auxiliar
«Supply»
Datos del
Médico
Figura 33. Diagrama del proceso: Gestionar cita
- 97 -
• Gestionar consultas
Figura 34. Diagrama de los proceso: Gestionar consultas – Facturación y Servicio de

Enfermería
• Gestionar contrato con ARS

od Contratos con ARS
Información para crear Formato

Minuta Contractual contractual
«Input» «Supply»
Elaborar contrato con ARS

Solicitud Contrato
de
Contrato «Output»
Jefe de
Div isión/Secretaria
«goal»
«goal »
Formular y v erificar contratos con ARS, permitiendo un
mayor cubrimiento de salud a niv el local
Figura 35. Diagrama del proceso: Elaborar contratos con ARS
- 98 -
• Elaborar informes
od Elaborar Informes
Datos según el
informes a realizar
«Supply»
Elaborar Informes
Solicitud Informe
de
Informe «Output»
Secretaria/Auxiliar
Administrativ o
«goal»
«goal»
Elaborar informes de las
activ idades y procedimientos
que se realizan en la div isión
Figura 36. Diagrama del proceso: Elaborar informes
• Gestionar Glosas
od Glosas
Factura Glosada
«Input»
Gestionar Glosas
Recepción Concepto
de glosas «Output»
Jefe de Div isión de

Atención en Salud
«goal»
«goal»
Controlar las observ aciones de tipo
administrativ o y técnico (Glosas) con el
fin de obj etar los v alores cobrados por la
prestación de serv icios de salud
Figura 37. Diagrama del proceso: Gestionar glosas
- 99 -
• Gestionar historia clínica y RIPS
od HC y RIPS
«goal»
Controlar el estado de salud de
Formato de Datos de Usuario los pacientes mej orando la
RIPS
gestión de sus historias clínicas y
RIPS
«Supply» «Supply»
«goal»
Gestionar Historia Clínica y RIPS

Registrar o Historia
Actualizar Clínica/RIPS
«Output» diligenciado
datos
Enfermera/Médico/Odontólogo
«Input»
Anamnesis/Procedimiento
aplicado
Figura 38. Diagrama del proceso: Gestionar Historia clínica y RIPS
• Gestionar hospitalización
od Hospitalización
Prestar serv icio de «goal»

Datos de Usuario Historia Clinica
Hospitalización a Mej orar y controlar el
los usuarios serv icio de hospitalización
«Supply» «Supply»
«goal» «goal»
Gestionar hospitalización
Orden de Historia Clinica
Hospitalización «Output»
Médico
«Uses»
«Input»
Getionar Facturación
Facturar Factura
Servicios «Output»
Caj ero
«Supply»
«goal»
Tarifa de
Prestación de Elaborar facturas
Serv icios de prestación de
serv icios
Figura 39. Diagrama del proceso: Gestionar Hospitalización
- 100 -
• Gestionar examen de laboratorio
od Laboratorio
Datos de Usuario Muestras

Obtener exámenes
de laboratorio de una
manera más ágil y
efectiv a
«Supply»
«Input»
«goal»
Gestionar Examen de Laboratorio

Orden de Resultado
Laboratorio «Output»
Médico o Auxiliar de
Laboratorio
«Uses»
«Input»
Gestionar Facturación
Facturar Factura
Servicios «Output»
Caj ero
«Supply» «goal»
Elaborar Facturas de
Tarifas de
Prestación de
Prestación de
Serv icios
Serv icios
Figura 40. Diagrama del proceso: Gestionar examen de laboratorio
• Gestionar personal médico y paramédico
od Personal Médico y Paramédico
Datos del
personal
«Supply»
Gestionar Personal médico y

Notificación de
Solicitud de paramédico
actos
Personal «Output» administrativ os

Atención en Salud
«goal»
«goal»
Gestionar el personal médico y
paramédico de la Empresa Social
del Estado, para de esta manera
fortalecer los procesos misionales
Figura 41. Diagrama del proceso: Gestionar Personal médico y Paramédico
- 101 -
• Gestionar programas de DI – DP – PE
od Programas DI - DP - PE
Plantilla informe Datos de cada

programa
«Supply»
«Input»
Gestionar Programas de DI - DP - PE
Informe mensual
Solicitud (estadísticas y correctiv os)
de Informe «Output»

Atención en Salud
«goal»
«goal»
Controlar los programas de DI – DP –
PE, con el obj eto de mej orar la
calidad de v ida de los usuarios
Figura 42. Diagrama del proceso: Gestionar Programas de DI – DP - PE
Gestionar los procesos del Departamento de Promoción y Prevención
• Gestionar coves
od Cov es
Calendario Acta Cov e de

Epidemiológico cada IPS
Gestionar Cov es
Reunión según Acta de Reunión
calendario
epidemiológico «Output»
Medico Coordinador
«goal»
«goal»
Permitir un mej or cubrimiento del área de
influencia de la institución gestionando las
reuniones de los comités de v igilancia
epidemiológica de cada IPS y del municipio
Figura 43. Diagrama del proceso: Gestionar Coves
- 102 -
• Gestionar equipos e insumos
od Equipos e insumos
Solicitud de
Requisición
«Input»
Gestionar Equipos e Insumos

Solicitud de Solicitud de orden de
Equipos/Insumos compra de
«Output»
equipos/insumos
Coordinador IPS
«goal»
«goal»
Gestionar los equipos e insumos
necesarios para la mej ora progresiv a
de los serv icios de atención
Figura 44. Diagrama del proceso: Gestionar equipos e insumos
• Gestionar programas de atención
od Programas de Atención
«goal»
Datos de usuario Información de
Historia Clínica Optimizar los
programas de atención
«goal»
Gestionar Programas de Atención

Solicitud de Historia clínica y
atención «Output» RIPS
Usuario
«Uses»
«Input»
Facturar Factura
servicios «Output»
Caj ero
«goal»
«Supply»
Elaborar Facturas de
Tarifas de Prestación de
Prestación de Serv icios
Serv icios
Figura 45. Diagrama del proceso: Gestionar programas de atención
- 103 -
• Seguir y controlar actividades
od Seguir y Controlar Activ idades
Informe de Rendimiento en cada

IPS (según el tipo de activ idad)
«Input»
Realizar un balance Seguir y Controlar Activ idades de Promoción y

Prev ención Informe
sobre la prestación de
servicios del consolidado de las
«Output» activ idades
Jefe del Departamento Departamento
de Promoción y
Prev ención
«goal»
«goal»
Seguir y controlar las activ idades de
Promoción y Prev ención con el fin de
mej orar la calidad de v ida de los
usuarios
Figura 46. Diagrama del proceso: Seguir y controlar actividades de promoción y

prevención
Gestionar los procesos de Farmacia
• Coordinar farmacias satélites
od Farmacias Satélites
Informe de cada
Faramcia
«Input»
Controlar Farmacias Satelites

Control Informe General
Logístico «Output»
Auxiliar
Administrativ o
«goal»
«goal»
Mej orar el proceso de gestión de
medicamentos ej erciendo Control
sobre las farmacias satélites.
Figura 47. Diagrama del proceso: Controlar farmacias satélites
- 104 -
• Gestionar inventario
od Inv entario
Informe reciente
de inv entario
«Input»
Gestionar Inv entario

Actualizar Nuev o inv entario
inventario «Output»
Jefe de área
«goal»
«goal»
Controlar el inv entario, para tener
disponibles los medicamentos
requeridos por los usuarios
Figura 48. Diagrama del proceso: Gestionar inventario
• Gestionar medicamentos
od Medicamentos
Recibe Medicamento/Solicitud de
Entrega (salida IPS - Usuario)
«Input»
Gestionar Medicamentos
Necesidad de Acta de
Medicamento Recibo/salida
«Output»
Regente de farmacia
«goal»
«goal»
Facturar los medicamentos entregados a
los usuarios según su régimen y niv el de
afiliación.
Figura 49. Diagrama del proceso: Gestionar medicamentos
- 105 -
Gestionar los procesos de Almacén
• Gestionar bienes
od Bienes
Información sobre el
estado de los bienes
«Input»
Gestionar Bienes
Revisión Acta y Actualización
de bienes del Kardex
«Output»
Jefe de Almacén
«goal»
«goal»
Gestionar bienes
Figura 50. Diagrama del proceso: Gestionar bienes
• Gestionar mercancías
od Mercancías
Recibe
mercancía/Solicitud de
pedido
«Input»
Necesidad de Gestionar Mercancías Acta de

alguna Recibo/Salida
«Output»
mercancía
Jefe de Almacén
«goal»
«goal»
Gestionar las mercancías
del almacén
Figura 51. Diagrama del proceso: Gestionar mercancías
- 106 -
3.1.1.3 Actores, Unidades y Estructura del Negocio
3.1.1.3.1 Actores
Internos
• Auxiliar.
• Auxiliar administrativo.
• Auxiliar operativo.
• Bacteriólogo.
• Cajero.
• Coordinador IPS.
• Digitador.
• Funcionario comité de bajas.
• Gerente.
• Jefe de Almacén.
• Jefe del Departamento de Personal.
• Jefe de División de Atención en Salud.
• Jefe PAI (Programa Ampliado de Inmunizaciones).
• Jefe de Presupuesto y Contabilidad.
• Jefe de Promoción y Prevención.
• Jefe de Servicios Generales.
• Jurídico.
• Médico.
• Odontólogo.
• Promotor de salud.
• Regente de Farmacía.
• Secretaria.
• Tesorero.
Externos
• Base de Datos POS – S.

• Software PAIDSA.
- 107 -
Descripción:
Auxiliar
Persona encargada de:
♦ Asignar al paciente el turno para la cita.
♦ Recibir y Verificar los datos de los usuarios.
♦ Comprobar factura de cancelación.
♦ Diligenciar el RIPS.
♦ Revisar órdenes médicas (si se tienen).
♦ Revisar y Registrar información en la Historia Clínica del paciente (signos
vitales, peso, talla, tensión, etc.).
♦ Realizar tratamiento médico (si es el caso).
♦ Realizar notas de enfermería.
♦ Tomar muestras (si se requiere).
♦ Rotular muestra, Diligenciar hoja de resultados de laboratorio y Controlar
calidad (si pertenece al área de laboratorio).
♦ Suministrar medicamentos y elaborar tarjeta de drogas (si se requiere).
♦ Anexar resultados de laboratorio a la Historia Clínica.
♦ Entregar fórmulas, remisiones y/o resultados al usuario.
♦ Manejar programas de salud pública.
♦ Revisar hojas de gastos.
Auxiliar administrativo
Se encarga de recibir y codificar los RIPS provenientes de las IPS, controla los
ingresos y egresos de medicamentos, verifica y organiza el inventario, además
elabora informes sobre los medicamentos de control y organiza la información
proveniente de las farmacias satélites.
Auxiliar operativo
Se encarga de:
♦ Comparar la cantidad, referencia, modelo, fecha de expedición y
vencimiento, seriales, precios de los elementos, etc. Con relación a lo
- 108 -
descrito en el contrato de adquisición de mercancías.

♦ Ordena los elementos que ingresan a Almacén.
♦ Procede a sacar el elemento del depósito para despacharlo al solicitante y
cerrar el proceso.
Bacteriólogo
♦ Recibir las muestras tomadas por la auxiliar de laboratorio.
♦ Procesar y producir resultados de laboratorio.
♦ Realizar estadísticas diarias.
♦ Control de calidad interno y externo de los análisis.
Base de Datos POS – S

Retorna los medicamentos del POS – S que son autorizados para los
diferentes usuarios según el régimen de salud al que pertenecen.
Cajero
Persona encargada de facturar las actividades y procedimientos que se le
realizan a determinado usuario, teniendo en cuenta sus derechos y tipo de
afiliación, para de esta manera tarifar dicho servicio.
Coordinador IPS
Coordina la elaboración del informe sobre el diagnóstico situacional de salud
del área de influencia.
Digitador
Se encarga de de digitar los RIPS y elaborar informes mensuales por cada
ARS.
Funcionario comité de bajas

Se encarga de gestionar las bajas de bienes de almacén, los cuales se
encuentren corruptos.
- 109 -
Gerente
Firmar contratos con ARS para su legalización, además se encarga de
gestionar la donación, venta, destrucción o baja de los bienes existentes en
almacén.
Jefe de Almacén
Se encarga de gestionar la entrada y salida de mercancías, la donación, venta,
baja y destrucción de bienes, además de manejar el inventario de las diferentes
dependencias y elaborar a su vez informes para el departamento de
Contabilidad.
Jefe del Departamento de Personal

Está encargado de validar y verificar la calidad de los procesos realizados en la
división de Atención en salud, además gestiona el personal médico y
paramédico que se desempeñará en el área de salud.
Jefe de División de Atención en Salud

Está encargado de supervisar las actividades y procesos que se desarrollan en
la división de atención en salud, algunas de sus funciones involucra la gestión
de la elaboración de informes, contratos y glosas, verificar y validar la calidad
de la prestación de servicios de salud, la atención al cliente, entre otros.
Jefe PAI (Programa Ampliado de Inmunizaciones)

Persona que se encarga de cumplir con los objetivos del Programa Ampliado
de Inmunizaciones, controla las actividades concernientes a la vacunación y las
reuniones del comité de vigilancia epidemiológica (Coves). El objetivo principal
de dicho programa es el de alcanzar la vacunación de por lo menos 90% en los
menores de 6 años con todos los antígenos del PAI, la erradicación de la
poliomielitis, la eliminación del tétanos neonatal, la eliminación del sarampión y,
en las zonas de riesgo, el suministro de micronutrientes suplementarios
adecuados.
- 110 -
Es un programa que tiene alta prioridad política y las vacunas están

consideradas como un Bien Público de Salud, por lo tanto su acceso debe ser
garantizado para toda la población, independientemente del sistema de salud al
cual se encuentre adscrito.
Jefe de Presupuesto y Contabilidad

Recibe el informe mensual proveniente de almacén.
Jefe de Promoción y Prevención

Está encargado de supervisar las actividades de promoción y prevención que
se ofrecen a los diferentes usuarios en esta dependencia, gestiona la
elaboración de informes y coves, además supervisa la existencia y buen uso de
los equipos e insumos que se requieren para la prestación efectiva de los
servicios.
Jefe de Servicios Generales

Se encarga de gestionar la compra de mercancías cada vez que almacén
requiere algún elemento, gestiona la baja y avalúo de bienes.
Jurídico
Se encarga de elaborar el concepto jurídico concerniente al contrato que se
realizará con determinada ARS.
Médico
♦ Realizar valoración médica.
♦ Originar diagnóstico.
♦ Elaborar y/o aplicar tratamiento.
♦ Elaborar fórmula médica.
♦ Elaborar órdenes médicas: hospitalización, laboratorio, remisión, salida,
entre otras. (si se requiere).
- 111 -
♦ Obtener ayudas diagnósticas (si se requiere).

♦ Diligenciar RIPS.
Odontólogo
♦ Valorar al usuario.
♦ Elaborar carta dental.
♦ Aplicar procedimiento.
♦ Realizar remisión (si se requiere).
Promotor de salud
Se encarga de la aplicación de Biológico (vacunas) y el diligenciamiento de
Registros. (Diario de vacunación y los RIPS 2)
Regente de Farmacía
Se encarga de la recepción y despachos de mercancías a las diferentes
dependencias, revisa y actualiza el inventario de la farmacia y elabora informes
sobre el despacho y recepción de medicamentos de control.
Secretaria
Persona encargada de gestionar los documentos relacionados con los
contratos realizados con las ARS, la elaboración de informes y la atención al
cliente.
Software PAIDSA
Registra los datos sobre biológico y jeringas utilizando el Software PAIDSA, el
cual genera el Informe Mensual de de dichas actividades.
Tesorero
Se encarga del envío de copias de las facturas glosadas solicitadas, de la
recepción y análisis del concepto emitido y gestiona la cancelación total de las
facturas glosadas.
- 112 -
Diagrama Actor / Role (según el Proceso del Negocio)
• Gestionar Atención al cliente
Figura 52. Diagrama Actor / Role: Gestionar atención al cliente
Figura 53. Diagrama Actor / Role: Gestionar calidad
- 113 -
• Gestionar citas
Figura 54. Diagrama Actor / Role: Gestionar cltas
cd Consultas
«Business Process»
Gestionar Consultas
«Role» «Role» «Role» «Role»

«Role»
Auxiliar Bacteriólogo Caj ero Médico
Auxiliar
Administrativ o
Responsable Responsable Responsable Responsable Responsable

Responsable
Responsable
«Actor» «Actor» «Actor»

«Actor» «Actor» «Actor» «Actor»
Auxiliar de Citas Auxiliar de Auxiliar de Caj ero
Bacteriólogo Auxiliar Médico
Laboratorio Enfermería Administrativ o
Figura 55. Diagrama Actor / Role: Gestionar consultas
- 114 -
• Gestionar contratos con ARS

cd Gestionar Contratos con ARS
Elaborar Contratos con
ARS
«Role» «Role»
Jefe de la Div isión de Secretaria
Atención en Salud
Responsable Responsable
«Actor»
«Actor»
Jefe de la Div isión de
Atención en Salud Secretaria
Figura 56. Diagrama Actor / Role: Elaborar contratos con ARS

cd Gestionar Examen de Laboratorio
Gestionar Examen de
Laboratorio
«Role» «Role»
Auxiliar Bacteriólogo
«Actor» «Actor»
Auxiliar de Bacteriólogo
Laboratorio
Figura 57. Diagrama Actor / Role: Gestionar examen de laboratorio
- 115 -
• Gestionar facturación
cd Gestionar Facturación
«Role»
Caj ero
Responsable
«Actor»
Caj ero
Figura 58. Diagrama Actor / Role: Gestionar Facturación
• Gestionar glosas
cd Gestionar Glosas
Gestionar Glosas
«Role»
«Role»
Jefa de la Div isión de
Atención en Salud Tesorero
Responsable
Responsable
«Actor»
«Actor»
Jefe de la Div isión de
Atención en Salud Tesorero
Figura 59. Diagrama Actor / Role: Gestionar glosas
- 116 -
Figura 60. Diagrama Actor / Role: Gestionar Historia clinica y RIPS
Figura 61. Diagrama Actor / Role: Gestionar hospitalización
- 117 -
Figura 62. Diagrama Actor / Role: Elaborar informes
cd Gestionar Personal Médico y Paramédico
Gestionar Personal Médico y
Paramédico
«Role» «Role» «Role»

Coordinar IPS Jefe del Departamento Jefe de la Div isión de
de Personal Atención en Salud
Responsable Responsable Responsable

Coordinador IPS Jefe del Departamento de Jefe de la Div isión de
Personal Atención en Salud
Figura 63. Diagrama Actor / Role: Gestionar Personal médico y Paramédico
- 118 -
• Gestionar programas de DI – DP – PE
cd Gestionar Programas DI - DP - PE
Gestionar Programas DI - DP - PE
«Role»
«Role» «Role»
Auxiliar «Role»
Jefe de la Div isión de Jefe de Promoción y Médico
Atención en Salud Prev ención
Responsable
Responsable
«Actor» «Actor» «Actor» «Actor» «Actor»

Jefe de Jefe de la Div isión de Jefe de Promoción y Médico Médico
Enfermería Atención en Salud Prev ención Coordinador
Figura 64. Diagrama Actor / Role: Gestionar programas de DI – DP – PE
• Gestionar coves
cd Gestionar Cov es
«Role»
Gestionar Cov es
«Role» «Role» «Role» «Role»
Auxiliar Jefe PAI Jefe de Promoción y Médico

Prev ención
Responsable Responsable Responsable Responsable
Responsable Responsable
«Actor» «Actor» «Actor» «Actor» «Actor»

«Actor»
Auxiliar de Jefe PAI Jefe PAI Jefe de Promoción y Médico
Médico
Enfermería Prev ención Coordinador
Figura 65. Diagrama Actor / Role: Gestionar coves
- 119 -
cd Gestionar Equipos e Insumos
Gestionar Equipos e
Insumos

Auxiliar Digitador Jefe de Promoción y
Administrativ o
Prev ención
«Actor»
«Actor» «Actor»
Auxiliar
Digitador Jefe de Promoción y
Administrativ o
Prev ención
Figura 66. Diagrama Actor / Role: Gestionar Equipos e insumos
Figura 67. Diagrama Actor / Role: Gestionar programas de atención
- 120 -
• Seguir y controlar actividades
Figura 68. Diagrama Actor / Role: Seguir y Controlar actividades
• Controlar farmacias satélites

cd Gestionar Farmacias Satélites
Controlar Farmacias Sattélites
«Role»
Auxiliar
Administativ o
Responsable
«Actor»
Auxiliar
Administrativ o
Figura 69. Diagrama Actor / Role: Gestionar Farmacias satélites
- 121 -
cd Gestionar Inv entario
Gestionar Inv entario
«Rol e» «Role» «Role»

Auxiliar Jefe de Almacén Regente de
Administrativ o Farmacia

Auxiliar Jefe de Almacén Regente de
Administrativ o
Farmacia
Figura 70. Diagrama Actor / Role: Gestionar inventario
cd Gestionar Medicamentos
Gestionar Medicamentos
«Role» «Role» «Actor Externo»

Auxiliar Regente de Base de Datos
Administrativ o Farmacia POS - S
«Actor»
«Actor»
Auxiliar
Regente de
Administrativ o
Farmacia
Figura 71. Diagrama Actor / Role: Gestionar medicamentos
- 122 -
Figura 72. Diagrama Actor / Role: Gestionar bienes
cd Gestionar Mercancías
Gestionar Mercancías

Jefe de Almacén Auxiliar Jefe de Serv icios
Operativ o Generales

Jefe de Almacén Auxiliar Jefe de Serv icios
Operativ o Generales
Figura 73. Diagrama Actor / Role: Gestionar mercancías
- 123 -
Diagrama Role/Actividad
• Auxiliar Administrativo
cd Auxiliar Administrativ o
«Actividad»
«Actividad»
Recibir y Codificar
Organizar información
RIPS (IPS)
de las farmacias satélites
«Role»
Auxiliar
Administrativ o
«Actividad»
«Actividad»
Controlar ingreso
Elaborar informaes sobre
de medicamentos
medicamentos de control
«Actividad» «Actividad»
Controlar egreso de Verificar y Organizar
medicamentos inv entario
Figura 74. Diagrama Role / Actividad: Auxiliar administrativo
• Auxiliar
cd Auxiliar
«Actividad»
«Actividad»
Asignar turno
para la cita Rev isar hoj as de
gastos
«Actividad»
Recibir y Verificar «Actividad»
datos de los usuarios Manej ar programas
de salud pública
«Actividad»
Comprobar factura «Role» «Actividad»
de cancelación Entregar fórmulas -
Auxiliar
remisiones y/o resultados
«Actividad»
Diligenciar RIPS «Actividad»
Anexar resultados de
laboratorio a HC
«Actividad»
Opcional Rev isar órdenes «Actividad»
médicas
Suministrar medicamentos y Opcional
elaborar tarj eta de drogas
«Actividad»
«Actividad»
Rev isar y Registrar
información en la Historia Realizar notas
Clínica del Paciente de enfermería
«Actividad» «Actividad» «Actividad» «Actividad»

Realizar Controlar Tomar y rotular Diligenciar hoj as de
Tratamiento médico calidad muestras resultados de laboratorio
Opcional
Opcional
Es necesario tener acceso al
área de laboratoio clínico
Figura 75. Diagrama Role / Actividad: Auxiliar
- 124 -
• Auxiliar operativo
cd Auxiliar operativ o
«Role»
Auxiliar
Operativ o
«Actividad»
Comparar las «Actividad»
«Actividad»
características de la Despachar elementos
mercancía con el Ordenar elementos que de almacén
contrato de adquisición ingresan a almacén
Figura 76. Diagrama Role / Actividad: Auxiliar operativo
• Bacteriólogo
cd Bacteriólogo
«Actividad» «Role» «Actividad»

Recibir muestras Bacteriólogo Control de calidad interno
y externo de los análisis
Procesar y producir Realizar estadísticas
resultados de laboratorio diarias
Figura 77. Diagrama Role / Actividad: Bacteriólogo
• Cajero
cd Caj ero
«Role»
Caj ero
«Actividad»
«Actividad» Facturar activ idades y
«Actividad»
Rev isar y v erificar datos procedimientos practicados a los
Rev isar tarifas pre-
de los usuarios usuarios
establecidas
Figura 78. Diagrama Role / Actividad: Cajero
- 125 -
• Coordinador IPS
cd Coordinador IPS
«Role»
Coordinador IPS
«Actividad»
Elaborar informe sobre el diagnóstico situacional
de salud del área de influencia
Figura 79. Diagrama Role / Actividad: Coordinador IPS
• Digitador
cd Digitador
«Role»
Digitador
Digitar RIPS Elaborar informes
para ARS
Figura 80. Diagrama Role / Actividad: Digitador
• Funcionario comité de bajas
cd Funcionario comité de ba...
«Role»
Funcionario
comité de baj as
«Actividad»
Gestionar las baj as de
bienes de almacén
Figura 81. Diagrama Role / Actividad: Funcionario comité de bajas
- 126 -
• Gerente
cd Gerente
«Role»
Gerente
Firmar contratos Gestionar destrucción de
con ARS bienes
«Actividad»
Gestionar donaciones de Gestionar baj a de bienes
bienes Gestionar v entas de bienes
Figura 82. Diagrama Role / Actividad: Gerente
• Jefe de Almacén
cd Jefe de Almacén
«Acti vi dad» «Acti vi dad»

Gestionar entrada de Gestionar baj a
mercancías de mercancías
«Rol e»
Jefe de Almacén
Gestionar salida Gestionar destrucción
de mercancías de bienes
«Actividad» «Acti vi dad»

Gestionar Donación Gestionar v enta
de bienes de bienes

Manej ar inv entario de las Elaborar informes para
diferentes dependencias contabilidad
Figura 83. Diagrama Role / Actividad: Jefe de Almacén
• Jefe del Departamento de Personal
cd Jefe del Departamento de Personal
«Rol e»
Jefe del Departamento
de Personal
«Acti vidad»
Validar y v erificar la calidad de los «Activi dad»
procesos realizados en la Div isión de Gestionar Personal
Atención en Salud médico y paramédico
Figura 84. Diagrama Role / Actividad: Jefe del Departamento de Personal
- 127 -
• Jefe de División de Atención en Salud
cd Jefe de Div isión de Atención en Salud

Superv isar activ idades y Jefe de Div isión de Atención en Salud Gestionar Atención al cliente
procesos que se desarrollan en
la div isión
Gestión de la Verificar la calidad de la
Gestión de contratos con Gestión de
elaboración de informes glosas prestación de serv icios de salud
ARS
Figura 85. Diagrama Role / Actividad: Jefe de División de Atención en Salud
• Jefe PAI (Programa Ampliado de Inmunizaciones)
cd Jefe PAI
«Role»
Jefe PAI
«Actividad» «Actividades»
«Actividad»
Cumplir con los obj etiv os del Participar y Controlar reuniones del
Controlar las activ idades
Programa Ampliado de comité de v igilancia epidemiológica
relativ as a v acunación
Inmunizaciones (Cov es)
Figura 86. Diagrama Role / Actividad: Jefe PAI
• Jefe de Presupuesto y Contabilidad
cd Jefe de Presupuesto y Contabili...
«Role»
Jefe de Presupuesto y
Contabilidad
«Actividad»
Recibe el informe mensual
prov eniente de almacén
Figura 87. Diagrama Role / Actividad: Jefe de Presupuesto y Contabilidad
- 128 -
• Jefe de Promoción y Prevención
cd Jefe de Promoción y Prev ención

Superv isar las activ idades de Jefe de Promoción y Superv isa la existencia y buen uso de
promoción y prev ención Prev ención los equipos e insumos
Gestionar la elaboración Gestionar la elaboración de
de informes informes Cov es
Figura 88. Diagrama Role / Actividad: Jefe de Promoción y Prevención
• Jefe de Servicios Generales
cd Jefe de Serv icios Generales
«Role»
Jefe de Serv icios Generales
Gestionar la compra de
Gestionar la baj a y
mercancías
av alúo de bienes
Figura 89. Diagrama Role / Actividad: Jefe de Servicios generales
• Jurídico
cd Jurídico
«Role»
Jurídico
«Actividad»
Elaborar el concepto j urídico
concerniente al contrato que se realizará
con determinada ARS
Figura 90. Diagrama Role / Actividad: Jurídico
- 129 -
• Médico
cd Médico
«Actividad» «Role» «Activi dad»

Realizar v aloración Médico Elaborar y/o aplicar
médica tratamiento
«Actividad»
Originar «Activi dad»
diagnóstico Diligenciar RIPS
«Activi dad»
«Actividad» «Activi dad»
Elaborar
fórmula médica Elaborar órdenes Obtener ayudas
médicas diagnósticas
Si se requi ere
Figura 91. Diagrama Role / Actividad: Médico
• Odontólogo
cd Odontólogo
«Actividad»
Odontólogo
«Actividad» «Acti vidad» «Activi dad» «Actividad»

Valorar al Elaborar carta Aplicar
usuario Realizar
dental procedimiento remisión
Si se requiere
Figura 92. Diagrama Role / Actividad: Odontólogo
- 130 -
• Promotor de salud
cd Promotor de salud
«Role»
Promotor de
salud
Aplicar v acunas Diligenciar
registros
Figura 93. Diagrama Role / Actividad: Promotor de salud
• Regente de Farmacía
cd Regente de Farmacía
«Role»
Regente de
Farmacía
«Actividad» «Actividad» «Actividad» «Actividad»

Recepción de Despacho de Rev isar y Actualizar el Elaborar
medicamentos medicamentos inv entario informes
Figura 94. Diagrama Role / Actividad: Regente de farmacia
• Secretaria
cd Secretaria
«Role»
Secretaria
«Actividad»
Gestionar los documentos Gestioanr
Elaborar
relacionados con los contratos atención al
informes
realizados con las ARS cliente
Figura 95. Diagrama Role / Actividad: Secretaria
- 131 -
• Tesorero
cd Tesorero
«Role»
Tesorero
«Actividad» «Actividad» «Actividad»

Env iar copia de las Recepción y análisis de Gestionar cancelación total de
facturas glosadas concepto emitido las facturas glosadas
Figura 96. Diagrama Role / Actividad: Tesorero
3.1.1.3.2 Unidades del Negocio
Figura 97. Organigrama de la ESE IMSALUD
o IPS satélite
Agua clara.
La floresta.
- 132 -
Palmarito.
Guaramito.
San Faustino.
Guimaral.
San Martín.
Santa Ana.
San Luís.
San Mateo.
El Pórtico.
El contento.
Cundinamarca.
Belén.
Los Alpes.
Loma Bolívar.
Niña CECI.
Policlínico J Atalaya.
Sevilla.
Claret.
Toledo Plata.
Aeropuerto.
Buena Esperanza.
Banco Arena.
Ospina Pérez.
La Ermita.
Belisario.
Palmeras.
Antonia Santos.
El rodeo.
o Unidad básica
La libertad.
- 133 -
Puente Banco Leones.

Comuneros.
Descripción
• IPS Satélite
Son 32 IPS (puestos de salud) distribuidas a nivel urbano y rural del municipio
de Cúcuta. Se constituye como el módulo ejecutor del Sistema General de
Seguridad Social en Salud a través del cual se suministran los servicios de
salud en favor de los beneficiarios (pertenecientes al régimen Contributivo,
subsidiado, particulares o vinculados).
• Unidad Básica
Son 4 Unidades básicas ubicadas en la zona urbana del municipio de Cúcuta,

en las cuales se prestan la mayoría de los servicios de salud incluyen los
servicios de hospitalización y procedimientos quirúrgicos.
Responsabilidades
• IPS Satélite
o Se prestan los siguientes servicios:

o Medicina general
o Odontología general
o Actividades de Enfermería
o Actividades de Demanda inducida
o Detección precoz y Protección específica
• Unidad Básica
o Se prestan los siguientes servicios:

o Medicina general
o Odontología general
o Actividades de Enfermería
- 134 -
o Actividades de Demanda inducida

o Detección precoz y Protección específica
o Laboratorio clínico
o Optometría
o Radiología
o Trabajo social
o Servicio de información y atención al usuario
o Ecografía
o Urgencias 24 horas
o Hospitalización
o Transporte asistencial básico
o Electrocardiograma
o RX odontológico
3.1.1.4 Tecnologías
Recursos humanos y físicos:
La ESE IMSALUD cuenta con equipos de computación actualizados junto con

un grupo de personal capacitado para sacar adelante los proyectos de
modernización de los SISTEMAS DE INFORMACIÓN de las dependencias y
por ende de la empresa.
1- Ingeniero de Sistemas.
1- Ingeniero Electrónico.
1- Auxiliar de información en Salud.
1- Auxiliar de Oficina.
2- Codificadores.
1- Digitadores software SISVAN.
4- Digitadores RIPS.
Recursos software:
Software SISVAN
- 135 -
Software de Facturación hospitalaria de TNS

Acceso a la Base de Datos POS - S
3.1.1.5 Reglas del negocio
Los procesos del negocio para este proyecto se rigen por las siguientes reglas
del negocio:
Regla del negocio Descripción

La ley 100 establece el Sistema General de
Seguridad Social en Salud, desarrolla los
fundamentos que lo rigen, determina su
dirección, organización y funcionamiento, sus
normas administrativas, financieras y de
Ley 100 de 1993 control y las obligaciones que se derivan de
su aplicación.
Los objetivos del Sistema General de
Seguridad Social en Salud son regular el
servicio público esencial de salud y crear
condiciones de acceso en toda la población al
servicio en todos los niveles de atención.
Por la cual se adoptan medidas para la
prevención del desplazamiento forzado; la
Ley 387 de 1997 atención, protección, consolidación y
estabilización socioeconómica de los
desplazados internos por la violencia en la
República de Colombia.
Las Empresas Sociales del Estado tienen por
objeto la prestación de los servicios de salud,
Decreto 1750 de 2003 como servicio público esencial a cargo del
Estado o como parte del servicio público de la
seguridad social
Para efectos de este Decreto se entiende por
nivel de atención la responsabilidad del ente
Decreto 1760 de 1990 territorial en la organización de los servicios
de salud a través de una o varias entidades
para satisfacer las necesidades de salud de
su población.
las entidades administradoras del Régimen
Subsidiado y de las entidades territoriales, de
acuerdo con sus competencias, ejecutar
Acuerdo 117 del CNSSS aquellas actividades, procedimientos e
intervenciones de demanda inducida
definidas en el Acuerdo 117 del CNSSS y que
se encuentren incluidas en el Plan Obligatorio
de Salud del Régimen Subsidiado
Definir los medicamentos esenciales y
Acuerdo 83 de 1920 alternativos según el tipo y grado de la
enfermedad. Este acuerdo es reemplazado
por el acuerdo 228 de 2002.
Por la cual se establecen las actividades,
- 136 -
procedimientos e intervenciones de demanda

inducida y obligatorio cumplimiento y se
Resolución 0412 de 2000 adoptan las normas técnicas y guías de
atención para el desarrollo de las acciones de
protección específica y detección temprana y
la atención de enfermedades de interés en
salud pública.
Dentro de la empresa se definieron ciertos
Aplicación de procedimientos según rangos rangos de edades, según los cuales se puede
de edad pre-establecidos prestar la atención necesaria a las personas
de acuerdo a su condición y clasificación.
Consulta externa 15 – 20 minutos de
atención.
Índices de rendimiento y calidad del ministerio Consulta médico-especializada 20 – 25
de salud. minutos de atención.
Urgencias Sin restricción. Disponible las 24
horas.
Hospitalización Duración superior a 24
horas.
Régimen subsidiado Tienen derecho al
Régimen Subsidiado las personas
pertenecientes a los niveles 1 y 2 del
SISBEN, quienes podrán acceder a través de
Atención según el régimen de salud al cual un subsidio total y las personas del área
pertenezca el usuario. urbana pertenecientes a los niveles 2 y 3 del
SISBEN, quienes podrán acceder a través de
un subsidio parcial.
Régimen contributivo pertenecen a este
régimen todos los empleados, trabajadores
independientes (más de 1 salario mínimo) y
pensionados.
Particular y Vinculado
Prestación de servicios según especialidad de La prestación de los servicios de salud se
los profesionales de salud. realiza según la especialidad que requiera el
usuario y el programa al cual pertenezca.
Baja complejidad Atención, estabilización y
Atención de salud según el nivel de resolución.
complejidad del paciente. Alta complejidad Se remite según sistema
de referencia y contrarreferencia.
Por la cual se fijan algunos lineamientos en
Resolución 00951 de 2002 relación con el Registro Individual de
Prestación de Servicios de Salud, RIPS.
por la cual se adopta la Primera Actualización
Resolución 2333 de 2000 de la Clasificación Única de Procedimientos
en Salud
Por la cual se reglamentan los datos básicos
que deben reportar los prestadores de
Resolución 03374 de 2000 servicios de salud y las entidades
administradoras de planes de beneficios
sobre los servicios de salud prestados
La E.S.E. "IMSALUD" fue creado por acuerdo
Creación 087 del 29 de Enero de 1999 emanado del
honorable concejo Municipal de San José de
Cúcuta
Naturaleza Jurídica Es una entidad pública descentralizada del
orden Municipal dotados personería jurídica,
autonomía administrativa y patrimonio propio
- 137 -
adscrita a la dirección local de salud,

integrante del Sistema General de Seguridad
Social en Salud sometido al régimen jurídico
previsto en la ley 100 y sus decretos
reglamentarios.
La Empresa Social del Estado del Primer
Nivel de Atención en Salud del Municipio de
Jurisdicción San José de Cúcuta, tiene jurisdicción en
todo el territorio del Municipio de San José de
Cúcuta, su domicilio y sede de sus
organismos administrativos en la Ciudad de
Cúcuta.
Tabla 6. Reglas del negocio
3.1.1.6 Objetos del negocio
Objeto Atributos Métodos

Identificación del acta Crear
Actas de reuniones Fecha Modificar
COVE Descripción Eliminar
Consultar
Número de carnet
Tipo de usuario (contributivo, subsidiado, Registrar
Afiliación vinculado, particular, desplazado, otro). Modificar
Tipo de afiliación (cotizante, beneficiario, otro Eliminar
miembro, adicional) Consultar
Ficha sisben
Puntaje sisben
Zona (urbano, rural)
Identificación de la entidad
Historia clínica (tiene si / no)
Discapacidad
Código Crear
Centro de costos de Descripción Modificar
servicios Unidad funcional Eliminar
Cuenta de ingresos Consultar
Concepto de cartera
Usuario
Cita Identificación del profesional Crear
Observaciones Registrar
Tipo de asignación Modificar
Fecha Eliminar
Cantidad Cancelar
Hora de inicio Consultar
Hora fin
Lugar de la cita
Forma de solicitud
Número de factura
Número
Fecha de inicio Crear
Contrato Fecha de vencimiento Modificar
Descripción Eliminar
Tipo de contrato Consultar
Tipo de pago
- 138 -
Tipo de póliza
Valor total
Valor máximo mensual
Número de afiliados
Entidad
Tarifa POS
Tarifa no POS
Observaciones
Datos de integración con otros módulos
Crear
Departamento Código Modificar
Consultar
Identificación del diagnóstico Crear
Diagnóstico Tipo de diagnóstico Registrar
Especialidad Modificar
Descripción Consultar
Código del profesional Crear
Disponibilidad del Fecha inicial Registrar
Profesional Fecha final Modificar
Tiempo Actualizar
Cupo Eliminar
Consultar
Código
NIT Crear
Entidad Razón social Modificar
Dirección Eliminar
Teléfono Consultar
Representante
Tipo de entidad
Municipio
Código del concepto de cartera (integración con
otros módulos)
Número
Fecha Crear
Hora Modificar
Factura Tipo de factura Eliminar
Estado (asentada) Consultar
Tipo de ingreso
Identificación del cajero
Identificación del usuario
Identificación del contrato
Programa
Autorización
Fecha de autorización
Servicio prestado
Observaciones
Profesional que remisiona
Profesional que la elabora
Identificación de la glosa Crear
Glosas Fecha Modificar
Observaciones Eliminar
Consultar
Número de Historia Clínica
Historia Clínica Fecha – Hora Crear
Identificación de usuario Registrar
Identificación de RIPS Modificar
Identificación de Profesional de salud Actualizar
- 139 -
Motivo de consulta Consultar

Datos de Enfermería (toma de signos vitales)
Antecedentes
Anamnesis
Examen general (procedimientos aplicados)
Diagnóstico
Tratamiento
Identificación del informe
Informes Fecha Crear
título Modificar
Elaborado por Consultar
Recibido por
Identificación del informe
Informes de IPS Fecha Crear
Título Modificar
IPS Consultar
Recibido por
Identificación del inventario Crear
Inventario Fecha de actualización Modificar
Consultar
Identificación Crear
IPS Satélite Nombre Modificar
Dirección Eliminar
Teléfono Consultar
Identificación del elemento (bien) Crear
Kardex Nombre Modificar
Descripción Descargar
Consultar
Crear
Lugar de servicio Código Modificar
Consultar
Código Crear
Manuales tarifarios Descripción Modificar
Identificación del servicio Eliminar
Identificación de la tarifa Consultar
Referencia
Medicamento Nombre Registrar
Lote Modificar
Fecha de vencimiento Descargar
Fabricante Consultar
Clasificación (legal)
Identificación del inventario
Código Crear
Municipio Nombre Modificar
Código del departamento Eliminar
Consultar
Código
Cédula Registrar
Fecha Modificar
Profesional de salud Nombre Actualizar
Especialidad Eliminar
Dirección Consultar
Teléfono
Celular
- 140 -
Correo
Registro profesional
Tipo de persona
Estado
Porcentaje de pago
Código Crear
Programa de atención Descripción Modificar
Sexo Eliminar
Edad inicial Consultar
Edad final
Identificación de la prueba Crear
Pruebas de calidad Fecha Modificar
Contenido Eliminar
Consultar
Identificación del usuario Registrar
RIPS Identificación de la factura Modificar
Consultar
Fecha
RIPS de Consulta Servicio Registrar
Finalidad Modificar
Causa externa Consultar
Identificación del diagnóstico
Fecha – Hora ingreso
RIPS de Autorización Registrar
Hospitalización Vía ingreso Modificar
Causa externa Consultar
Estado de salida
Identificación de diagnóstico
Fecha Registrar
RIPS de medicamentos Identificación del medicamento Modificar
Tipo (POS - no POS) Consultar
Fecha
RIPS de Procedimiento Servicio Registrar
Ámbito (ambulatorio, hospitalario, urgencias) Modificar
Finalidad Consultar
Persona que atiende
Acto quirúrgico
Identificación del diagnóstico
Fecha
Control prenatal Registrar
RIPS Recién nacidos Edad gestasional Modificar
Sexo Consultar
Peso
Fecha de muerte
Fecha – Hora de ingreso
RIPS de urgencias Destino al salir Registrar
Estado (vivo - muerto) Modificar
Fecha – Hora salida Consultar
Código interno
Código SOAT Crear
Servicios de salud Código CUP Modificar
Código ISS Eliminar
Descripción Consultar
Especialidad
POS (si / no)
- 141 -
Factor (manual de tarifas)

Aplica a sexo
Edad
Tipo de RIPS
Ámbito
Identificación del manual tarifario Crear
Tarifa Identificación del servicio Modificar
Valor Eliminar
Consultar
Identificación Crear
Unidad Básica Nombre Modificar
Dirección Eliminar
Teléfono Consultar
Crear
Unidad funcional Código Modificar
Consultar
Identificación
Tipo de documento Registrar
Usuario Nombres Modificar
Apellidos Actualizar
Dirección Eliminar
Teléfono Consultar
Barrio
Ocupación
Estado civil
Nombre del Padre
Nombre de la madre
Observaciones
Número del carnet
Tabla 7. Objetos del negocio
- 142 -
cd Diagrama de obj etos
Profesional de salud
Disponibilidad del
Profesional
Prueba de calidad
Actas de reuniones
Informe de IPS IPS Satélite
COVE
Kardex
Inv entario Entidad Departamento
Afiliación Municipio
Medicamento
Cita
Historia Clínica Usuario
Figura 98. Parte del diagrama de objetos
- 143 -
3.1.1.7 Eventos
Evento Clasificación
Registrar o actualizar datos de usuario Casual interno
Revisión de enfermería Casual interno
Ejecutar consulta Programado interno
Facturar servicio Casual interno
Orden de hospitalización Casual interno
Orden de laboratorio Casual interno
Solicitud de informe Programado interno
Solicitud de información o quejas Casual externo
Recepción de glosas Programado interno
Solicitud de personal Casual externo
Solicitud de contrato Casual externo
Control de calidad del personal Programado interno
Realizar un balance sobre la prestación de servicios Programado interno
Solicitud de atención Casual externo
Solicitud de equipos e insumos Casual interno
Reunión según calendario epidemiológico Programado interno
Solicitud de Medicamentos Casual interno
Actualizar inventario Casual interno
Control logístico de farmacias satélites Programado interno
Solicitud de mercancía Casual interno
Revisión de bienes Casual Interno
Asignar o modificar citas Casual interno
Tabla 8. Eventos del negocio
3.1.2. Modelo del equipo
Líder del Proyecto
Planea, maneja y asigna recursos, asigna prioridades a los procesos así

como fijar metas al equipo del proyecto, interacciona con los clientes y
Funciones:
usuarios, establece un sistema de prácticas que aseguran la integridad y
la calidad de los artefactos del proyecto.
Nombre Holger Andrés Cáceres Medina
Cargo Vicerrector de Gestión y Desarrollo Tecnológico
Teléfono (*7) 5682022
Mail vicegdtec@unipamplona.edu.co
Tabla 9. Líder del Proyecto
Usuarios expertos
Es el personal de la ESE IMSALUD que apoya al líder y analistas para

Funciones: obtener los criterios unificados durante el proyecto, este equipo de trabajo
esta conformado con personal técnico y administrativo con conocimiento
- 144 -
de los procesos y procedimientos que realiza IMSALUD.
Miguel Tonino Botta

Nombre (Interviene en el momento de tomar decisiones que involucren el riesgo del
desarrollo del convenio.)
Cargo Gerente
Teléfono 5843434-5843031 Ext. 209
Mail eseimsalud@hotmail.com
Yolanda Sánchez
(Quien expresa las necesidades de la institución con criterio unificado
apoyado en su equipo de trabajo. Quien esta a cargo por la institución de
Nombre llevar feliz termino el proyecto. Encargado de la coordinación de las
actividades al interior de la institución, y de la comunicación con la
Universidad de Pamplona. Debe resolver asuntos del convenio y escalar
los asuntos dentro de la organización del Instituto Municipal de Salud
Cúcuta, según sea necesario.)
Cargo Profesional universitario informática
Teléfono 5843434 Ext. 102 - 103
Mail yosanar@hotmail.com
Nombre Luz Ángela Diaquiz
Cargo Técnico financiero
Teléfono 5843434
Mail
Tabla 10. Usuarios expertos
Analistas del negocio
Interacciona y atiende las inquietudes de los clientes, asegura el

cumplimiento de cada una de las fases del proyecto así como la calidad de
las mismas. Interpreta y plasma la información proporcionada por los
Funciones:
usuarios expertos.
Mantiene informado al líder del proyecto de todas las actividades
realizadas.
Nombre Johana García Poveda
- 145 -
Cargo Subdirección de Producto
Teléfono (*7) 5686367 - 3133764884
Mail producto.plataforma@unipamplona.edu.co
Nombre Yesenia Barrera Rangel
Cargo Analista de consultoría
Teléfono 5843434 Ext. 102 - 103
Mail producto.plataforma@unipamplona.edu.co
Tabla 11. Analistas del negocio
3.1.3. El proceso de modelado del negocio
Diagramas de Actividad
• Gestionar atención al cliente
Figura 99. Diagrama de actividad: Gestionar atención al cliente
Figura 100. Diagrama de actividad: Gestionar calidad
- 146 -
• Gestionar cita
Figura 101. Diagrama de actividad: Gestionar cita
Figura 102. Diagrama de actividad: Gestionar consultas
• Elaborar contrato con ARS
ad Contrato con ARS
«send»
«receive»
«Actividad» Enviar contratos «Actividad»
Recibir
Transcripción de a división Elaborar concepto
contratos concepto
encargada
Elaborar minuta Enviar contrato a ARS
contractual para du legalización
Figura 103. Diagrama de actividad: Gestionar contrato con ARS
- 147 -
• Gestionar servicio de enfermería
Figura 104. Diagrama de actividad: Gestionar servicio de enfermería
• Gestionar Facturación
Figura 105. Diagrama de actividad: Gestionar facturación
• Gestionar glosas
Figura 106. Diagrama de actividad: Gestionar glosas
Figura 107. Diagrama de actividad: Gestionar Historia clínica y RIPS
- 148 -
Figura 108. Diagrama de actividad: Gestionar hospitalización
Figura 109. Diagrama de actividad: Elaborar informes
Figura 110. Diagrama de actividad: Gestionar examen de laboratorio
- 149 -
ad Personal
«Actividad»
Coordinar oficios de
traslados o
Solicitud de personal asignación Realizar notificación
de actos
administrativos
Figura 111. Diagrama de actividad: Gestionar Personal médico y paramédico
• Gestionar programas de DI – DP - PE
Figura 112. Diagrama de actividad: Gestionar programas de DI – DP - PE
• Gestionar coves
Figura 113. Diagrama de actividad: Gestionar coves
Figura 114. Diagrama de actividad: Gestionar equipos e insumos
- 150 -
Figura 115. Diagrama de actividad: Gestionar programas de atención
• Seguir y controlar actividades de promoción y prevención
Figura 116. Diagrama de actividad: Seguir y controlar actividades de Promoción y

Prevención
• Gestionar farmacias satélites
Figura 117. Diagrama de actividad: Gestionar farmacias satélites
- 151 -
Figura 118. Diagrama de actividad: Gestionar medicamentos
Figura 119. Diagrama de actividad: Gestionar inventario
Figura120. Diagrama de actividad: Gestionar bienes
- 152 -
Figura 121. Diagrama de actividad: Gestionar mercancías
- 153 -
4. METODO PROPUESTO PARA LA OBTENCION DE REQUERIMIENTOS
4.1 ANALISIS DE TECNICAS Y HERRAMIENTAS
Las técnicas y herramientas seleccionadas para el desarrollo de la obtención

de requerimientos están clasificadas según la actividad de la ingeniería de
requerimientos a la cual proporciona soporte, su utilidad, facilidad de aplicación
y las ventajas que se derivan de sus resultados.
A continuación se presenta una tabla con las principales características de las

técnicas y herramientas empleadas en la ingeniería de requerimientos.
Nombre Clasificación Actividad(es) Ventajas Desventajas

Técnica conocida, fácil
de aplicar, permite
Entrevistas Técnica Extracción estudiar el dominio del Requiere
problema, disposición del
comunicación y cliente.
retroalimentación con
el usuario / cliente.
Herramienta fácil de Están limitados
Cuestionarios Herramienta Extracción aplicar, comprensible, por el tipo de
varía según el tipo de preguntas y el
preguntas aplicadas y objetivo que se
su enfoque objetivo. busca.
Útil para analizar las
salidas de los sistemas Diferencia en el
Sistemas Técnica Extracción y actuales de la enfoque y
existentes Análisis organización, permite concepción del
descubrir sistema,
requerimientos necesidad
importantes, son (expresada por el
sistemas que usuario) de
presentan estabilidad mejorar la
en el dominio del aplicación actual.
problema.
Permite centrar la
Grabaciones Extracción y atención en la
de video y de Herramienta Análisis entrevista, analizar los Autorización del
audio temas con más cliente.
detenimiento, captura
el proceso de trabajo.
Generación de
múltiples ideas
Brainstorming Extracción y Genera ideas, permite inconexas,
(Tormenta de Herramienta Análisis obtener varias vistas inversión de
- 154 -
ideas) del problema. tiempo en

clasificación y
eliminación de
ideas.
Ayuda a determinar Bases
posibles incorrectas, las
Arqueología Extracción y requerimientos cuales se quieren
de Herramienta Análisis implícitos en los mejorar y
documentos resultados o salidas de posiblemente no
los sistemas de uso se tenga en
actual. cuenta este factor
Permite observar el
trabajo en tiempo real, Requiere mucho
realizar bosquejos para tiempo,
Aprendiz Técnica Extracción cada actividad a disposición del
sistematizar, obtener la cliente.
información que está
en la cabeza del
cliente.
Comprensión de los
Observación Técnica Extracción procesos y su entorno, Inversión grande
permite identificar de tiempo por
estructuras y patrones, parte del analista.
facilita la abstracción.
Definir actores,
Run Use escenarios, secuencia Se necesita tener
Case Herramienta Extracción de actividades, un bosquejo
Workshop eventos, inicial de casos de
(talleres) retroalimentación uso.
continua del cliente.
El usuario no
Retroalimentación por alcanza a
Prototipo Herramienta Extracción – parte del cliente / visualizar el
bosquejado Análisis y usuario, poco tiempo y diálogo hombre-
Especificación esfuerzo en la máquina
aplicación de cambios. (requerimiento no
funcional)
Permite visualizar los Costo de
Prototipo Extracción – requerimientos no realización,
tangible / Herramienta Especificación funcionales, entrenamiento,
Usable y Validación retroalimentación, confusión de los
validación de entradas usuarios por
y salidas. incompletitud.
Permite identificar las
debilidades,
DOFA Herramienta Análisis oportunidades,
fortalezas y amenazas
del sistema.
Identificar las
actividades
Cadena de Herramienta Análisis estratégicas de la
valor empresa, análisis de
costos y
funcionamiento de
cada actividad.
Identificar conceptos Es necesario
Modelo de Análisis y del dominio del contar con un
- 155 -
clase Herramienta Especificación problema, comprensión glosario del

conceptual de la terminología, dominio del
facilita la construcción problema
del glosario.
Extracción – Impacto de las Dependiente del
Diagrama de Herramienta Análisis y soluciones planteadas caso de estudio,
pescado Especificación en la empresa, interpretación
organización de ideas. sesgada.
Extracción – Mejora la
Glosario Herramienta Análisis – comunicación Requiere continua
Especificación intergrupal, con el actualización.
y Validación cliente, mitiga el riesgo
de malos entendidos.
Comprensión del
entorno del negocio,
funcionamiento e
Análisis y interacción con el
DCO Técnica Especificación ambiente, permite
modelar
recursivamente la
empresa en sus
diferentes niveles.
Permite representar las Herramienta no
Diagrama de Herramienta Análisis y actividades, flujos de apta para la
actividad Especificación información, comprensión del
condiciones y usuario, este
restricciones. requiere cierta
capacitación.
Extracción – Especificar los Sólo incluye
ESRE Técnica Análisis – requerimientos del requerimientos
Especificación sistema. del producto.
y Validación
Especifica el
funcionamiento del
Extracción – sistema, describe la
Casos de uso Herramienta Análisis – secuencia de
Especificación interacciones entre el
y Validación sistema y los actores,
descripción de un
conjunto de
escenarios.
Casa de Herramienta Validación Representa la relación
calidad o QFD de qué (requerimiento)
con el cómo (casos de
uso), control de
calidad.
Especificación Evaluar cada
Checklist Herramienta y Validación requerimiento,
recuerdan que se debe
buscar y ajustar.
Tabla 12. Análisis de Técnicas y Herramientas
- 156 -
4.2 TECNICAS Y HERRAMIENTAS SELECCIONADAS
Las herramientas y técnicas que fueron seleccionadas para este proyecto se

describen a continuación. El criterio de selección se basó en: facilidad de uso,
utilidad, resultados, tiempo, recursos y personal (equipo de trabajo).
Actividad Técnica Herramienta

Entrevista Cuestionario
Captura Sistemas existentes Glosario
ESRE Casos de uso
Lista de requerimientos
Cadena de Valor
Glosario
Análisis DCO Casos de uso
ESRE Diagrama de actividad
Modelo de clase conceptual
Modelo de clase conceptual
Especificación ESRE Glosario
Diagrama de actividad
Casos de uso
Validación ESRE Casos de uso
QFD
Tabla 13. Técnicas y Herramientas seleccionadas
4.3 METODO PARA LA OBTENCION DE REQUERIMIENTOS
Luego de haber estudiado y analizado la información y materiales a los cuales

se pudo acceder, en el presente trabajo se propone la definición de un método
iterativo e incremental para la Ingeniería de Requerimientos que se apoya en
definiciones de los autores Leite [LEITE, 1987], Loucopoulos [LOCOPOULOS
et all, 1995], Dorfman [DORFMAN, 1997], Peter Chekland [CHECKLAND,
1989], Burg [BURG, 1997] y en los problemas que aún siguen sin resolverse.
Este método conformado por cuatro etapas fundamentales, análogas a las
actividades de la ingeniería de requerimientos: Captura, Análisis,
Especificación y Validación de requerimientos, trata de salvar la brecha entre
las etapas iniciales del desarrollo de software y las fases posteriores,
permitiendo que las mismas continúen hacia la obtención de un software que
solucione y soporte los problemas y necesidades del usuario.
- 157 -
En cuanto a la no aplicabilidad general de los métodos investigados, unas

veces es consecuencia de las características particulares del proyecto,
problemas derivados de cuestiones económicas, otras de restricciones de
índole tecnológica, motivo por el cual se decide que el método propuesto debe
ser lo suficientemente flexible y centrado en el usuario como para permitir se
adecue a las organizaciones según su negocio y asuntos sociales, económicos,
tecnológicos y medioambientales. Para obtener buenos resultados de este
método se recomienda emplear a la par el plan de gestión de requerimientos
de la organización según la metodología de desarrollo de software que
implementen.
Antes de aplicar el método se requiere el establecimiento del equipo de trabajo.
Captura
Recolectar y clasificar requerimientos.
Priorizar los requerimientos.
Retroalimentación del cliente / usuario.
Análisis
Verificar la correspondencia de los requerimientos con las metas de la
organización y las necesidades de los clientes / usuarios.
Plantear modelos y diagramas lógicos.
Retroalimentación del cliente / usuario.
Especificación
Elegir la herramienta para la especificación de requerimientos.
Especificar los requerimientos de acuerdo a la herramienta
seleccionada.
Validación
Validar la correspondencia entre requerimientos y casos de uso.
- 158 -
Figura 122. Método propuesto para la obtención de requerimientos
Captura Análisis Especificación Validación
Recolectar y Verificar Elegir Validar

clasificar correspondencia herramienta correspondencia
requerimientos de entre
requerimientos requerimientos y
con metas y casos de uso
necesidades
Priorizar Plantear modelos Especificar

requerimientos y diagramas requerimientos
lógicos
Retroalimentac Retroalimentac
ión del cliente / ión del cliente /
usuario. usuario.
Figura 123. Etapas y sub-Etapas método propuesto para la obtención de requerimientos
- 159 -
Establecer el equipo de trabajo Es necesario contar con profesionales

expertos en las diferentes áreas de la organización en las cuales el sistema
vaya a tener alguna influencia o impacto, además de poseer talento humano
como analistas, consultores y modeladores.
4.3.1 Captura:
Recolectar y Clasificar requerimientos En esta sub-etapa se aplican las

técnicas preestablecidas, con el objetivo de capturar requerimientos, como el
método es iterativo e incremental se puede contar en cada ciclo con diferentes
requerimientos, requerimientos refinados, priorizados y / o cambios según el
plan de gestión de requerimientos establecido por la organización. Cada
requerimiento se va clasificando para su posterior tratamiento.
Priorizar requerimientos Se procede a priorizar los requerimientos para su

posterior desarrollo según las necesidades de los clientes / usuarios.
Retroalimentación del cliente / usuario Una vez estén clasificados y

priorizados los requerimientos recolectados anteriormente, se colocan a
disposición del cliente / usuario para que valore su pertinencia, aporte nuevas
ideas, acepte o rechace requerimientos y alimente el conocimiento del equipo.
4.3.2 Análisis:
Verificar la correspondencia de los requerimientos con las metas de la

organización y las necesidades de los clientes / usuarios En esta sub-
etapa se debe rastrear cada uno de los requerimientos con las metas de la
organización y el negocio como tal, para esto se recomienda analizar el modelo
del negocio, utilizar la Técnica DCO y la herramienta Cadena de valor, por
medio de las cuales se puede establecer la pertinencia, vigencia e importancia
de los requerimientos sometidos a estudio.
- 160 -
Plantear modelos y diagramas lógicos Para una mejor comprensión y

asociación de los requerimientos de software y el mundo real, se pueden
realizar modelos y diagramas lógicos, obteniendo de esta manera una
formalización de los requerimientos al lograr plasmarlos en una vista y lenguaje
técnico.
Retroalimentación del cliente / usuario Se utilizan las vistas lógicas y se

le explican a los clientes, los cuales podrán expresar sus aportes sobre el
procedimiento y secuencia de eventos, interacciones, flujos de información y
demás situaciones que sean relevantes.
4.3.3 Especificación:
Elegir la herramienta para la especificación de requerimientos La

herramienta software es decisión del equipo de trabajo, el cual puede
seleccionarla según las políticas y normas de la empresa, esta debe ser formal
o semiformal.
Especificar los requerimientos de acuerdo a la herramienta seleccionada

Representar el requerimiento según la base seleccionada en la sub-etapa
anterior.
4.3.4 Validación:
Validar la correspondencia entre requerimientos y casos de uso Cada

caso de uso debe ser una representación y solución a una necesidad, por lo
tanto es necesario llevar un control de los requerimientos, para garantizar su
relevancia y valor agregado al usuario, para de esta manera establecer la
trazabilidad requerimiento - caso de uso. (Se recomienda la utilización de la
herramienta QFD).
- 161 -
4.3.5 Prácticas:
Desarrollo iterativo e incremental: Este tipo de práctica permite centrar la

atención en una porción de los requerimientos, en cada iteración se adicionan
nuevos requerimientos hasta alcanzar la mayoría de ellos. Se realiza un diseño
inicial de acuerdo con los requerimientos claves. Luego se descubren los
defectos en los resultados de la iteración y estos se corrigen en la siguiente
iteración, en la cual se incorporan las cuatro etapas del método.
Desarrollo basado en casos de uso: El método recomienda organizar los

requerimientos funcionales en casos de uso. Esta práctica provee un mejor
entendimiento de la importancia de los requerimientos según las perspectivas
de los usuarios. Los casos de uso definidos para el sistema son las bases para
un completo proceso de desarrollo.
Modelamiento visual: Un modelo es una vista simplificada de un sistema.

Muestra lo esencial del sistema desde una perspectiva particular y oculta los
detalles no esenciales. Los modelos pueden ayudar en los siguientes casos:
• Ayudar a comprender sistemas complejos.

• Capturar requerimientos exactos.
• Comunicar decisiones no ambiguas.
• Permitir la buena comunicación entre el equipo de trabajo a nivel
interno y a nivel externo con el cliente.
Centrado en el Usuario: Permite obtener retroalimentación del usuario en

cada ciclo, centrarse en sus necesidades y garantizar que los requerimientos
se ajusten a su realidad organizacional.
- 162 -
4.4 APLICACIÓN DEL METODO A LA OBTENCION DE REQUERIMIENTOS
4.4.1. Captura
Recolectar y Clasificar Requerimientos

Ciclo Técnica Herramienta Descripción Requerimientos
Obtenidos
La entrevista se planeó con
anticipación, se estableció
fecha, lugar y hora. En ella Atención al cliente, Cita,
se utilizó un cuestionario Consultas, Enfermería,
elaborado previamente con Facturación, Historia
preguntas cerradas para clínica, RIPS,
1y2 Entrevista Cuestionario concretar necesidades y Hospitalización, Examen
algunas preguntas abiertas, de laboratorio,
en las cuales los clientes Programas de DI – DP –
expresaban con sus propias PE, Equipos e insumos,
palabras los problemas que Programas de atención,
consideran fundamentales Actividades de
resolver y las expectativas Promoción y Prevención,
que poseen con relación al Medicamentos.
sistema por desarrollar.
Se hizo uso de un manual de
usuario y la observación del
software actual de la
empresa, por medio de él se
complementaron
requerimientos que de otra Calidad, Contratos,
forma no hubiera sido Glosas, Informes,
1y2 Sistema Manual de posible obtener, además se Personal médico y
existente usuario verificaron las entradas y paramédico, Coves,
salidas de dicha aplicación. Farmacias satélites,
Debido a que esta aplicación Inventario, Bienes
ya pasó la curva de Mercancías.
estabilización y control del
dominio del problema los
requerimientos extraídos son
confiables y se pueden
moldear a la nueva
propuesta.
Se inició con la creación del
glosario para garantizar una
buena comunicación entre el
equipo de trabajo y los
clientes, reduciendo de esta
1y2 ESRE Glosario manera los riesgos de
ambigüedades y malas
interpretaciones. Luego se
procedió con la realización
del documento de
especificación de
requerimientos, en el cual se
incluyen sólo los
requerimientos del producto,
aquellos de tipo funcional.
- 163 -
Se clasifica cada uno de los

requerimientos en
funcionales y no-funcionales.
1y2 ESRE Casos de Uso Con los requerimientos
funcionales se establecen
unos casos de uso iniciales,
los cuales se describen para
posterior validación por el
usuario, en ellos se incluye
el flujo de actividades y
escenarios involucrados. Se
pueden utilizar algunos de
los procesos identificados en
el modelo del negocio
realizado con anterioridad.
Priorizar requerimientos
Ciclo Técnica Herramienta Descripción Requerimientos y
prioridad
1: Cita, Enfermería,
Facturación, Historia
clínica, RIPS.
2: Consultas,
Hospitalización, Examen
de laboratorio,
Se priorizan los Programas de DI – DP –
1y2 Lista de requerimientos según la PE, Programas de
requerimientos opinión de los usuarios atención, Actividades de
obtenida en la primera Promoción y Prevención.
entrevista. Prioridad de 1 a 3: Atención al cliente,
5, 1 es el más importante. Medicamentos, Informes,
Personal médico y
paramédico, Inventario.
4: Equipos e insumos,
Farmacias satélites,
Bienes, Mercancías.
5: Calidad, Contratos,
Glosas, Coves.
Retroalimentación
Ciclo Técnica Herramienta Descripción
Se presenta ante el usuario el glosario, ESRE y la lista
1y2 de requerimientos priorizada para su aceptación,
cambios o rechazo.
Tabla 14. Etapa de Captura de Requerimientos
4.4.2. Análisis
Verificar la correspondencia de los requerimientos con las metas de la organización y las

necesidades de los clientes / usuarios
Se aplica la técnica DCO por medio de la cual se realiza un
Cadena de análisis del entorno, del organigrama, la visión y misión de
1 y 2 DCO Valor la empresa, políticas de prestación de servicios y los
procesos del negocio. Se reutiliza información del modelo
- 164 -
del negocio.
Plantear modelos y diagramas lógicos
Se refinan y agregan nuevos términos al glosario, según
1y2 ESRE Glosario evolución del proyecto y opiniones de los clientes /
usuarios, estos términos provienen del modelo del negocio
y las etapas de este método.
Casos de uso Se desarrolla el modelo de casos de uso según el ESRE, el
Diagrama de cual se presentará al usuario para su aprobación,
1y2 ESRE Actividad. diagramas de actividades y modelo de clases (modelo de
Modelo de objetos del negocio) basados en la información del modelo
clase. del negocio.
Retroalimentación
Se presentan al usuario los diagramas y modelos
realizados, luego de explicarles dichos modelos visuales,
1y2 los clientes / usuarios aportan sus opiniones, inquietudes y
percepciones, permitiendo con esta información, mejorar y
asegurar la calidad de los requerimientos identificados.
Tabla 15. Etapa de Análisis de Requerimientos
4.4.3. Especificación
Elegir la herramienta para la especificación de requerimientos

Se elige una herramienta software para la especificación
de los requerimientos, esta herramienta depende de las
1 normas, políticas e inclinaciones de la organización. Para
este proyecto se escogió la herramienta Enterprise
Architect.
Especificar los requerimientos
Se refinan y agregan nuevos términos al glosario, según
1y2 ESRE Glosario evolución del proyecto y opiniones de los clientes /
usuarios. Los términos plasmados en el glosario facilitan
la especificación de los requerimientos.
Casos de uso Se traducen a un lenguaje visual y técnico todos los
Diagrama de requisitos extraídos y analizados hasta el momento,
1y2 Actividad. permitiendo mostrar las funcionalidades esenciales para el
Modelo de desarrollo del proyecto desde una perspectiva mucha más
clase. clara.
Tabla 16. Etapa de Especificación de Requerimientos
- 165 -
4.4.4. Validación
Validar la correspondencia entre requerimientos y casos de uso

Casos de Se toma como base los casos de uso y cada uno de los
uso. requerimientos, se plantea la matriz de QFD para poder
1y2 ESRE QFD establecer la trazabilidad entre cada requerimiento y su
implementación en un caso de uso.
Tabla 17. Etapa de Validación de Requerimientos
4.5 RESULTADOS OBTENIDOS DE LA APLICACIÓN DEL METODO
4.5.1 REQUERIMIENTOS OBTENIDOS
Los siguientes requerimientos se clasifican como Requerimientos Funcionales,

se puede observar que los requerimientos claves pertenecen a las cuatro
dependencias de Salud identificadas en el modelo del negocio, cada uno de los
requerimientos es análogo a los procesos fundamentales que se llevan a cabo
en dichas dependencias.
Atender al cliente Atender llamadas, Atender correspondencia.

Gestionar citas Asignar citas, Cancelar citas.
Gestionar Consultas Gestionar consulta general, Gestionar consulta médico
– especializada.
Prestar servicio de Enfermería
Gestionar Historia clínica Crear Historia Clínica, Registrar datos en Historia
Clínica.
Gestionar RIPS Crear RIPS, Modificar RIPS, Registrar servicios en RIPS.
Gestionar Hospitalización
Realizar Examen de laboratorio
Gestionar Programas de DI – DP – PE
Gestionar Equipos e insumos Solicitar equipos e insumos, Devolver equipos
e insumos.
- 166 -
Gestionar Programas de atención

Controlar Actividades de Promoción y Prevención
Gestionar Medicamentos Solicitar medicamentos, Despachar
medicamentos.
Controlar Calidad
Elaborar Contratos con ARS
Gestionar Glosas
Elaborar Informes
Gestionar Personal médico y paramédico
Realizar reuniones Coves
Controlar Farmacias satélites
Gestionar Inventario Crear inventario, Actualizar inventario.
Gestionar Bienes Recibir bienes, Despachar bienes.
Gestionar Mercancías Recibir mercancías, Despachar mercancías.
- 167 -
4.5.2 Diagrama de casos de uso
Diagrama general
ud Use Case View
Funcionario Comité de
Baj as
Regente de Farmacía
Auxiliar Operativ o
Jefe de Serv icios
Generales
Gestionar
Gestionar
procesos de
procesos de
Almacén
Farmacia
Jefe de Presupuesto y
Contabilidad
Jefe de Almacén
Base de Datos POS - S
Tesorero Jefe de Departamento

de Personal Gerente Auxiliar Administrativ o
Jefe PAI
Jefe de Oficina
Jefe de div isión de Jefe de Departamento

atención en salud de Promoción y
Prev ención
Odontólogo
Gestionar procesos de
Gestionar procesos del
la Div isión de Atención
Departamento de
en Salud
Promoción y Prev ención
Secretaria
Caj ero
Médico
Bacteriólogo
Promotor de Salud
Coordinador IPS Jurídico

Auxiliar Digitador Softw are PAIDSA
Figura 124. Diagrama de Casos de Uso general
- 168 -
Diagrama de Casos de Uso de Almacén
ud Procesos de Almacén
Almacén
Gestionar
Mercancías
Auxiliar Opertiv o de
Almacen
«include»
Gestionar
Inv entario
Jefe de Serv icios
Generales
Jefe de Almacén
«include»
Gestionar bienes Funcionario Comite de

baj as
Auxiliar «include»
Administrativ o de
Almacen
Gerente
Elaborar Informes
Auxiliar Administrativ o Jefe de Presupuesto y

Contabilidad
Figura 125. Diagrama de Casos de Uso de Almacén
- 169 -
Diagrama de Casos de Uso de Farmacia
ud procesos de farmacia
Farmacia
Gestionar
medicamentos
BD_POS-S
«include»
«include» Gestionar
inv entario
Auxiliar
Administrativ o de
Regente_Farmacia
farmacia
Elaborar informes
«include»
Controlar
farmacias satélites
Auxiliar Administrativ o
Figura 126. Diagrama de Casos de Uso de Farmacía
- 170 -
Diagrama de Casos de Uso de la División de Atención en Salud
ud Atención en salud
Atención en salud
Gestionar
facturación
Auxiliar Auxiliar
Caj ero administrativ o
Gestionar citas administrativ o
Gestionar
consultas
Auxiliar de citas
Gestionar
Jefe de enferemería
hospitalización
Jefe de Promoción y
Prev ención «include»
Gestionar
programas de DI -
Auxiliar de
DP - PE
«include» Enfermería
Auxiliar
«include»
Médico
«include»
Elaborar informes
Jefe de Atención en
salud
Médico
«include»
«include»
Bacteriólogo Médico Coordinador

Gestionar calidad
Gestionar historia
clínica y RIPS
«include»
Jefe de personal
Gestionar exámen
de laboratorio
Auxiliar de
laboratorio
Gestionar
personal médico y
paramédico
Coordinador IPS
Elaborar contratos
con ARS
Secretaria
Gestionar glosas
Tesorero
Gestionar Jurídico
atención al cliente
Gerente
Figura 127. Diagrama de Casos de Uso de La división de Atención en Salud
- 171 -
Diagrama de Casos de Uso del Departamento de Promoción y Prevención
ud Promoción y Prev ención
Promoción y Prevención
Seguir y Controlar
activ idades
PAIDSA
«include»
Enfermera
Jefe de Promoción y
Prev ención Elaborar informes
Auxliliar «include»
administrativ o
Auxiliar Auxiliar de Auxiliar

Gestionar odontología
administrativ o de P
programas de
yP
atención
«include»
Digitador
Gestionar historia
clinica y RIPS
Auxiliar de
Enferemería
Jefe PAI Gestionar

facturación
Promotor de salud
Gestionar equipos
Patólogo e insumos
Caj ero
Médico
Médico Gestionar cov es Odontólogo
Odontólogo
Médico Coordinador Higienista
Figura 128. Diagrama de Casos de Uso del Departamento de Promoción y Prevención
- 172 -
Los diagramas de actividad realizados en el Modelo del Negocio y que

corresponden a los requerimientos definidos en la Obtención de requerimientos
pueden ser reutilizados en este apartado.
4.5.3 Cadena de valor
La cadena de valor nos permite identificar los principales eslabones de la

empresa, en este caso se seleccionaron sólo las dependencias que tienen
relación directa con el área de salud. Se puede reutilizar la cadena de valor del
modelo del negocio.
Figura 129. Cadena de Valor
4.5.4 DCO (Documento de Concepto de Operaciones)
4.5.4.1 Descripción de la Empresa Social del Estado IMSALUD
Creación:
La E.S.E. "IMSALUD" fue creado por acuerdo 087 del 29 de Enero de 1999
emanado del honorable concejo Municipal de San José de Cúcuta.
Naturaleza Jurídica:
Es una entidad pública descentralizada de orden Municipal dotada de
personería jurídica, autonomía administrativa y patrimonio propio, adscrita a la
dirección local de salud, integrante del Sistema General de Seguridad Social en
Salud sometido al régimen jurídico previsto en la ley 100 y sus decretos
reglamentarios.
- 173 -
Jurisdicción:
La Empresa Social del Estado del Primer Nivel de Atención en Salud del
Municipio de San José de Cúcuta, tiene jurisdicción en todo el territorio del
Municipio de San José de Cúcuta, su domicilio y sede de sus organismos
administrativos en la Ciudad de Cúcuta.
Reseña histórica:
Dentro de las virtudes que ofrece la Ley 10 de 1.990 a los entes territoriales
una de las de mayor relevancia es la descentralización en la administración de
los servicios de salud y la declaratoria de los mismos como un servicio público
de obligatorio cumplimiento por parte del estado. Es así como se trabajó en el
cumplimiento de los requisitos de la Ley 60 de 1.993, y el Decreto 1770 de
1.994, necesarios para acreditar la certificación y asumir la descentralización,
cumpliéndolos en su totalidad , logrando así la certificación el 29 de Diciembre
de 1.999, mediante el Decreto 1906 expedido por el Señor Gobernador del
Departamento Norte de Santander. Esto implicó la necesidad de firmar con el
departamento un convenio ínter - administrativo que materializaba esta
certificación permitiéndole al Municipio de San José de Cúcuta, la asunción de
la dirección y la prestación de los servicios de salud del primer nivel de
atención, acto administrativo que fue firmado el 30 de Diciembre de 1.999 y que
incluía las actas de entrega del personal que estaba desarrollando labores del
primer nivel en el departamento a través del Hospital Erasmo Meoz,
financiados con situado fiscal y la de los bienes muebles e inmuebles
representado con los organismos de salud y sus dotaciones de la zona urbana
y rural del municipio. Para poder asumir estas competencias se implementó y
puso en marcha las dos entidades, el DEPARTAMENTO ADMINISTRATIVO
EN SEGURIDAD SOCIAL EN SALUD "DASSSACU" Y LA EMPRESA SOCIAL
DEL ESTADO E.S.E. IMSALUD, que por mandato del Honorable Concejo se
crearon desde el 29 de Enero de 1.999 y que a partir del 1° de Enero del 2000,
abrieron sus puertas al servicio de la comunidad, dando cumplimiento a lo
normado en el Acuerdo 087 del 29 de Enero de 1.999, por medio del cual se
crea la Empresa Social del Estado E.S.E. IMSALUD, constituida como entidad
- 174 -
pública descentralizada con autonomía administrativa y presupuestal,

personería jurídica y patrimonio propio, para que asuma la prestación de los
servicios de salud en el primer nivel de atención en el Municipio de San José
de Cúcuta. Es así como la Empresa Social del Estado E.S.E. IMSALUD inicia
sus actividades operativas a partir del 1° de Enero del 2000. De conformidad
con el artículo 6° del Decreto 1876 de 1.994, la Ju nta Directiva de la Empresa
Social del Estado E.S.E. IMSALUD, está integrada según lo establecido en el
artículo 98 del Decreto Ley 1298 de 1.994, así: Una tercera parte de sus
miembros serán representantes del sector político administrativa, otra tercera
representará al sector científico de la salud y la tercera parte restante será
designada por la comunidad.
Junta directiva del 2000:

• MANUEL GUILLERMO MORA JARAMILLO
Alcalde Municipal de San José de Cúcuta.
Presidente Junta Directiva.
• MIGUEL TONINO BOTTA FERNANDEZ
Director Departamento Administrativo de Seguridad Social en Salud.
"DASSSACU"
• GLADYS SANCHEZ VILLAMIZAR
Representante Asociación Científica de la Ciudad.
• OSCAR FERNANDO CORZO H.
Representante del estamento científico de la Entidad.
• PEDRO ENTRENA R
Representante del Gremio de la Producción.
• EDUAR NEIL SALAZAR CASTRO
Representante de la Asociación de Usuarios.
• GERMAN FRANCISCO SILVA BERMUDEZ
Gerente E.S.E. IMSALUD
Secretario Junta Directiva.
- 175 -
Objetivo:
Contribuir al desarrollo social del municipio mejorando la calidad de vida y
reduciendo la morbilidad, la mortalidad, la incapacidad, el dolor y la angustia
evitables en la población usuaria, en la medida en que esto este a su alcance.
Producir servicios de salud eficientes y efectivos, que cumplan con las normas
de calidad establecidas, de acuerdo con la reglamentación que se expida para
tal propósito.
4.5.4.2 Organigrama de la Empresa
Figura 130. Organigrama ESE IMSALUD
4.5.4.3 Misión
Prestar servicios de salud del primer nivel de atención tanto a los usuarios del
régimen subsidiado como particulares, vinculados y del régimen contributivo de
manera eficiente, eficaz y oportuna, contribuyendo, por ende al mejoramiento
continuo de la situación de salud y de la calidad de vida en el municipio de San
José de Cúcuta.
- 176 -
4.5.4.4 Visión
Convertirnos en la Empresa líder en la prestación de servicios de salud con un
alto índice de lucro social, financiero, calidad humana y técnica del servicio, en
el Municipio de San José de Cúcuta, mediante la conservación de los principios
corporativos de eficiencia, eficacia, valor humano y calidad en la atención en un
término de cinco (5) años.
4.5.4.5 Prestación de Servicios de Salud

La empresa social del estado IMSALUD en sus gestiones administrativas, se
enfoca en llevar los servicios de salud esenciales a toda la comunidad
cucuteña, su red prestadora de servicios de salud cubre toda la zona urbana y
rural de Cúcuta, hoy IMSALUD cuenta con puestos de salud y unidades
básicas en las cuales se prestan diferentes servicios de salud.
Figura 131. Distribución de IPS
- 177 -
En los puestos de salud se prestan los siguientes servicios:

Medicina general
Odontología general
Actividades de enfermería
Actividades de Demanda Inducida
Detección precoz y Protección específica
En las unidades básicas se prestan los siguientes servicios:

Medicina general
Odontología general
Actividades de enfermería
Actividades de demanda inducida
Detección precoz y Protección específica
Laboratorio clínico
Optometría
Radiología
Trabajo social
Servicio de información y atención al usuario
Ecografía
Urgencias 24 horas
Hospitalización
Transporte asistencial básico
Electrocardiograma
RX Odontológico
- 178 -
4.5.5 QFD
Casos de Uso
Atender al cliente Gestionar citas Gestionar Consultas Prestar
Gestionar Gestionar servicio de Gestionar
Requerimientos Atender Atender Asignar Cancelar consulta consulta Enfermería Facturación
llamadas correspondencia citas citas general médico –
especializada
Atención al
cliente X X
Cita X X
Consultas X X
Enfermería X X
Facturación
Gestionar Historia clínica Gestionar RIPS Realizar Gestionar
Crear Registrar datos Registrar Gestionar Examen de Programas
Historia en Historia Crear RIPS Modificar servicios en Hospitalización laboratorio de DI – DP –
Clínica Clínica RIPS RIPS PE
Historia clínica X X
RIPS X X X
Hospitalización X
Examen de
laboratorio X
Programas de DI
– DP – PE X
Gestionar Equipos e Gestionar Controlar Gestionar Medicamentos
insumos Programas Actividades Controlar Elaborar
Solicitar Devolver de de Solicitar Despachar Calidad Contratos
equipos e equipos e atención Promoción y medicamentos medicamentos con ARS
insumos insumos. Prevención
Equipos e
insumos X X
Programas de X
- 179 -
atención
Actividades de
Promoción y X
Prevención
Medicamentos X X
Calidad X
Contratos X
Gestionar
Gestionar Elaborar Controlar Realizar Personal Gestionar Inventario
Glosas Informes Farmacias reuniones médico y
satélites Coves paramédico
Crear inventario Actualizar inventario
Glosas X
Informes X
Personal médico X
y paramédico
Coves X
Farmacias X
satélites
Inventario X X
Gestionar Bienes Gestionar Mercancías
Recibir bienes Despachar bienes Recibir mercancías Despachar mercancías
Bienes X X
Mercancías X X
Tabla 18. Matriz QFD
- 180 -
4.6 RELACION ENTRE EL MODELADO DEL NEGOCIO Y EL METODO

PROPUESTO PARA LA OBTENCION DE REQUERIMIENTOS.
Para conseguir sus objetivos, una empresa organiza su actividad por medio de
un conjunto de procesos de negocio. Cada uno de ellos se caracteriza por una
colección de datos que son producidos y manipulados mediante un conjunto de
tareas, en las que ciertos agentes (por ejemplo, trabajadores o departamentos)
participan de acuerdo a un flujo de trabajo determinado. Además, estos
procesos se hallan sujetos a un conjunto de reglas de negocio, que determinan
la estructura de la información y las políticas de la empresa. Por tanto, la
finalidad del modelado del negocio es describir cada proceso del negocio,
especificando sus datos, actividades (o tareas), roles (o agentes) y reglas de
negocio.
A partir del modelo del negocio, es posible obtener de manera sistemática y

directa, tanto la colección inicial de casos de uso del sistema como el modelo
conceptual preliminar.
Las actividades del diagrama de proceso tienen el nivel de granularidad

adecuado para ser asociadas a un caso de uso del sistema. De esta manera,
se crea un caso de uso del sistema por cada actividad del diagrama de proceso
que deba ser soportada por el sistema software.
Los objetos de información que fluyen entre las actividades de un caso de uso
del negocio representan datos del dominio, por lo que suponen una buena base
para crear el modelo conceptual inicial. Este modelo incluirá los conceptos y
sus relaciones y se describirá mediante un diagrama de clases UML, en el que
los conceptos se representan mediante clases.
El método propuesto para la obtención de requerimientos aprovecha la

información identificada en el modelo del negocio y utiliza algunos de los
artefactos que se desarrollan durante su producción, razón por la cual facilita
- 181 -
el trabajo y ahorra tiempo de investigación permitiendo de esta manera

concentrarse en los requerimientos claves para el usuario y garantizar la
calidad de la obtención de requerimientos.
- 182 -
Modelo del producto Modelo

Actores – del Proceso de
Metas Procesos Unidades Tecnología Reglas Objetos Eventos equipo Modelado
Recolectar y Clasificar
Captura requerimientos X X X
Retroalimentación
Correspondencia entre los
requerimientos metas y X X
Análisis necesidades de la empresa
Plantear modelos y
diagramas X X X X
Retroalimentación
Elegir herramienta X
Especificación Especificar los
requerimientos según la
herramienta
Correspondencia entre
Validación cada requerimiento y los X X
casos de uso.
Tabla 19. Relación entre el modelamiento del negocio y la obtención de requerimientos
- 183 -
5. EL MODELO DEL NEGOCIO Y LA OBTENCION DE REQUERIMIENTOS

COMO SOLUCION A ALGUNAS DE LAS CAUSAS DE FRACASOS DE LOS
PROYECTOS DE SOFTWARE
5.1 FRACASO DE LOS PROYECTOS SOFTWARE
5.1.1 Por qué fracasan los proyectos?

[ZABALA, 2006]
Varias encuestas sostienen que sólo en el orden del 20% de los proyectos
finalizan obteniendo el objetivo planteado, en el tiempo y con los recursos
estimados. Esta problemática se da en todo tipo de proyectos, y está
particularmente acentuada en proyectos tecnológicos.
El 80 % de proyectos que no tuvieron la misma suerte - por diferentes motivos -

genera un aumento de costos directos (los proyectos finalizan con mas
recursos que los previstos) e indirectos por la NO disponibilidad de los
beneficios previstos que brindaría dicho proyecto si hubiera finalizado en
tiempo y forma.
Motivos que originan fracasos en el cumplimiento de los proyectos:
• 21 % Cambios o poca claridad en los objetivos definidos a nivel

estratégico.
• 31 % No utilización, o mala utilización de metodologías de trabajo.
• 48 % Problemas humanos, de conducción, comunicación y conflictos
entre la gente.
Los proyectos que no saben a donde van, normalmente van a terminar

perdiéndose. Prestarles la suficiente atención lleva a clarificar, comprender y a
- 184 -
relacionar objetivos, para que las expectativas sean claras y la estrategia

tenga sentido.
Los objetivos pueden ser imprecisos y generales al principio, pero no hay

excusa para permitirles que se queden así. Dejar los objetivos poco claros y sin
comprobar invita a un fracaso inevitable.
Los objetivos reales no son siempre evidentes al comienzo del proyecto.

Tienen que ser descubiertos y redefinidos con preguntas como:
- ¿Por qué se está realizando este proyecto?

- ¿Qué se está realmente tratando de llevar a cabo?
- ¿Qué objetivo a largo plazo contribuye a ello?
- ¿Qué es necesario dar?
- ¿Cómo se mide el éxito?
- ¿Qué condiciones tendrían que existir para hacer este proyecto innecesario?
Con respecto a la profesionalidad para diseñar y ejecutar un proyecto, el factor

crítico es la utilización de metodologías. En muchas organizaciones
pequeñas y medianas el factor brilla por su ausencia, y en muchas
organizaciones grandes el mismo existe y en general se trabaja bien, pero no
son pocos los casos en los cuales - en general por falta de tiempo - la
metodología termina siendo utilizada como una máscara formal para el
cumplimiento de normas y etapas y no como lo que verdaderamente es, el eje
del proyecto tomando el contenido de la metodología y no solo la forma.
Uno de los puntos en los cuales es muy débil la utilización de metodologías, es

en el diseño de la estructura de un proyecto y en la estimación de esfuerzos y
tiempos. Para tal efecto lo recomendable sería manejar una estructura
jerárquica basada en el concepto de costo por actividad, lo cual permite
construir el proyecto conceptualmente de arriba hacia abajo y costearlo
definiendo esfuerzos de abajo hacia arriba.
- 185 -
En relación al último punto que se refiere a problemas humanos, es crítico.

Las metodologías formales son de fundamental importancia, para la tarea de
los líderes de proyectos, pero no resultan suficientes para lograr el éxito en el
cumplimiento del objetivo previsto. Existen muchos otros factores informales,
subjetivos, de interrelación entre las personas, como ser la habilidad para
detectar conflictos ocultos, que son tan importantes como los métodos y
documentos que utiliza el líder para llevar adelante su tarea. Estas relaciones
están regladas por sensaciones, intuiciones, percepciones, sentimientos y
aceptación de intereses personales no manifiestos.
Factores de falla o cancelación en los proyectos:

[El papel fundamental de la industria del software en el crecimiento económico. Foco:
Colombia. Autor: Laura Sallstrom y Robert Damuth]
Factores de daño o cancelación %

Requerimientos incompletos 13.1
Deficiencia en la participación del usuario 12.4
Deficiencia de recursos 10.6
Expectativas no realistas 9.9
Deficiencia en soporte ejecutivo 9.3
Cambios en los requerimientos y especificaciones 8.7
Deficiencia en la planeación 8.1
Ya no es necesario 7.5
Deficiencia en administración de TI 6.2
Desconocimiento en tecnología 4.3
Otros 9.9
Tabla 20. Factores de daño o cancelación
- 186 -
Factores de falla o cancelación en los proyectos

Requerimientos incompletos
14
Deficiencia en el involucramiento del usuario
12
Deficiencia de recursos
10 Expectativas no realistas
8 Deficiencia en soporte ejecutivo

%
6 Cambios en los requerimientos y
especificaciones
4 Deficiencia en la planeación
Ya no es necesario
2
Deficiencia en administratición TI
0
1 Desconocimiento en tecnología
Areas Otros
Figura 132. Factores de daño o cancelación
Origen de los errores de proyectos software:
Fase %
Obtención y análisis de requerimientos 56
Diseño 10
Código 7
Otros 27
Tabla 21. Origen de los errores de proyectos software
- 187 -
Origen de los errores de proyectos software
Obtención y análisis de
requerimientos
Diseño
Código
Otros
Figura 133. Origen de los errores de proyectos software
Costo relativo de corregir un error de software:
Fase %
Obtención y análisis de requerimientos 82
Diseño 4
Código 1
Otros 13
Tabla 22. Costo relativo de corregir un error de software
Costo relativo de corregir un error de software
Obtención y análisis de
requerimientos
Diseño
Código
Otros
Figura 134. Costo relativo de corregir un error de software
- 188 -
Factores críticos de éxito de un proyecto de software:
Factores críticos de éxito de un proyecto

Misión del proyecto – Metas y direcciones generales definidas con claridad al inicio del
proyecto.
Soporte administrativo de alto nivel – Ayuda de la alta dirección para proveer los recursos
necesarios, autoridad y poder para el éxito del proyecto.
Auscultación del Cliente – Comunicación, auscultación y escucha activa de todas las partes
del equipo del proyecto.
Personal – Reclutamiento, selección y entrenamiento del personal necesario para el equipo del
proyecto.
Tareas técnicas – Disponibilidad de la tecnología y experiencia necesarias para el
cumplimiento de las acciones técnicas específicas.
Aceptación del cliente – El acto de “vender” el final del proyecto a los usuario finales.
Monitoreo y retroalimentación – Provisión a tiempo y de manera adecuada de información de
control en cada una de las etapas del proceso de implementación.
Comunicación – La provisión de una red apropiada y datos necesarios para todos los actores
clave en la implementación del proyecto.
Resolución de problemas – Habilidad de manejar crisis inesperadas y desviaciones del plan.
Tabla 23. Factores críticos de éxito de un proyecto
Gran parte de los enfoques que abordan la solución de la crisis del software
básicamente se circunscriben a los siguientes enfoques:
El producto que se enfoca en mejorar el nivel de la calidad de los entregables

del proyecto: modelos, documentos, código, etc. Tecnologías destacadas:
Unified Modeling Language [Lenguaje de Modelado Unificado], análisis y
diseño orientado a objetos, programación orientada a objetos, entre las más
importantes.
El proceso de desarrollo mediante la adopción de modelos de ciclo de

desarrollo y modelos de calidad que equivale a la administración de proyectos
mediante el aprendizaje de técnicas de gestión por parte de los
administradores, gestión de personal y el mejoramiento y predicibilidad de los
- 189 -
resultados. Tecnologías destacadas: Proceso Unificado, Capability Mature

Model, ciclo de vida evolutivo, administración de proyectos, entre otras.
El personal que se ha enfocado a desarrollar un modelo de equipo de trabajo y

procurar las técnicas, metodologías y herramientas de desarrollo necesarias
para manejar la complejidad del sistema a desarrollar. Tecnologías
destacadas: Team Software Process, Personal Software Process, organización
de equipo, liderazgo, motivación, etc.
5.1.2 Causas de los fracasos de los proyectos en Colombia

[ACIS, 2006]
Principales causas del fracaso de los proyectos TI en Colombia:
Experto Causas
El caso colombiano coincide con el general: 1: No se cumplen
los requerimientos (especificación de requerimientos
Orlando Cuevas
incompleta, ambigua, inconsistente). En general, no cumplir los
“Director de proyectos de requerimientos del proyecto conduce a un gran porcentaje del
Informática del CIFI. fracaso. 2. Pobre planeación del proyecto, poca precisión
Universidad de Los Andes” para estimar el tiempo y los recursos (no se cumplen los plazos
previstos ni los costos estipulados). Cuando los plazos se
desbordan se afecta el proyecto y esto puede llevarlo al
fracaso. 3. Se presentan dificultades para obtener productos
sin errores –productos razonablemente buenos en calidad-,
otro problema grave unido a que los grupos de trabajo registran
baja productividad.
Para establecer las principales causas de fracaso, primero
habría que definir cuándo se puede considerar que un proyecto
fracasó. Es posible obtener el producto final del proyecto, pero
Oscar Aldana aún así el proyecto pudo haber sido un desastre. Su realización
pudo lograrse al final con sobre-costos, multas, con desgaste
“Gerente de Proyectos.
de la relación cliente-proveedor, fuera de tiempo, etc. Así que
Getronics, Colombia”
pudo haberse logrado el objetivo más importante pero dañando
o afectando otros aspectos que lo pueden dar por fracasado.
Pero, específicamente sobre las causas de fracaso, existe una
muy importante y es la ausencia de un caso de negocio
(business case) inicial formal o la no fidelidad a ese caso de
negocio que dio vida a ese proyecto. Al final, se puede terminar
entregando un producto, pero durante el transcurso del
proyecto es posible que ocurra un desvío del objetivo inicial.
Otras causas son el mal manejo del cambio y la
subestimación de los riesgos.
La primera y definitiva causa es una mala definición del
alcance. No todos los proyectos inician con una adecuada
definición del alcance. Es más, esto es a lo que los clientes le
- 190 -
tienen más pereza porque ellos no quieren arrancar con todas

las variables de una vez, sino quieren definirlas por el camino.
Marco Antonio Jiménez
Esta mala definición del alcance no se da sólo aquí en
“Ejecutivo de Proyectos. Colombia, se refleja también afuera. La segunda y no menos
IBM Colombia” importante corresponde a los errores que se presentan en la
planeación del proyecto. Todos los cálculos de los estimados,
llámense recursos, tiempo o costos. Porque no hay duda de
que todos los clientes tienen presión: por la competencia, por
lanzar un producto, porque necesitan liberar algo demasiado
rápido y entonces la presión aumenta y en este sentido el costo
nunca es el suficiente, siempre hay que recortarle. El tiempo
nunca será el adecuado, hay que recortarle y en aras de un
negocio se dice precipitadamente sí, y esto el cliente lo cobra
después. Se está sacrificando porque quedar mal debido a que
se realizaron unos estimados errados. Y la tercera, es un
inadecuado procedimiento de cambios. No todas las
organizaciones lo tienen, no todas las organizaciones lo aplican
y las que lo hacen no lo aplican suficientemente bien. La
definición de un proyecto no se puede introducir en un
refrigerador y pretender que el entorno no cambia. Los
proyectos van cambiando y si no hay una adecuada planeación
de ese cambio, si no instruimos a la gente desde el comienzo a
que los proyectos los contemplan y a adoptar la metodología
adecuada para hacerlos, se hace un mal manejo de las
expectativas del cliente. En tal sentido, se puede cumplir con
los objetivos del cliente y, sin embargo, terminar insatisfechos
por no manejar en forma adecuada sus expectativas.
Son tres las causas principales: en primer lugar, la carencia de
una gerencia efectiva en el proyecto. Bien sea porque falla en
el plan de calidad, en la definición de los indicadores, en el
Sara Cristina Mantilla estimativo de costos y en la formación del grupo de trabajo. La
segunda: cambio de norte, de especificaciones, cambio de
“Gerente de proyectos para
entorno o un inadecuado manejo del control de cambios.
el área de América Latina.
Es claro que en el ciclo de vida de un proyecto hay cambios y
EFunds - Oasis Technology”
hay que ajustarse a ellos con el debido proceso. Y, tercera:
proyectos a veces, demasiado ambiciosos. El riesgo de un
proyecto es directamente proporcional a su costo y a su tiempo
de duración. Entonces, la mejor forma de evitar el fracaso en el
proyecto es desmembrarlo, dividirlo en subproyectos o en
componentes que permitan hacer entregas parciales de
resultados.
Tabla 24. Opiniones de expertos sobre los fracasos de proyectos TI en Colombia
5.2 EL MODELO DEL NEGOCIO Y LA OBTENCION DE REQUERIMIENTOS

COMO SOLUCION A LOS FRACASOS DE LOS PROYECTOS SOFTWARE
La mejor respuesta a las dificultades que se presentan en los proyectos de

software, es realizar un modelo del negocio y desarrollar una ingeniería de
requerimientos completa, real, precisa y coherente, por medio de la cual se
- 191 -
puede soslayar gran parte de los problemas que se presentan en dichos

proyectos.
El Proceso de ingeniería de requerimientos es un conjunto estructurado de

actividades, mediante las cuales se obtiene, valida y se mantiene el documento
de especificación de requerimientos (ESRE).
Las actividades del proceso incluyen la extracción de requerimientos, el

análisis, la negociación y la validación.
No existe un proceso único que sea válido de aplicar en todas las

organizaciones. Cada organización debe desarrollar su propio proceso de
acuerdo al tipo de producto que se esté desarrollando, a la cultura
organizacional, y al nivel de experiencia y habilidad de las personas
involucradas en la ingeniería de requerimientos. Hay muchas maneras de
organizar el proceso de ingeniería de requerimientos y según la relevancia y
complejidad del proyecto a desarrollar es necesario recurrir a un modelo del
negocio, el cual nos brinde la información necesaria de la realidad
organizacional y la gestión de los procesos que allí se llevan a cabo.
Cualquier tarea en donde el resultado sea importante, se puede realizar de

mejor manera al utilizar algún tipo de proceso ordenado. Para obtener este
orden, se diseñan los procesos con base en algún modelo que nos guíe a la
hora de diferenciar y secuenciar las actividades.
Además si se selecciona y aplica un método adecuado, tanto para el

modelamiento del negocio como para la obtención de requerimientos, la
mayoría de los artefactos obtenidos en el modelo del negocio se pueden refinar
y utilizar en la definición de requerimientos, ahorrando tiempo y costo en el
proyecto.
- 192 -
A continuación se presenta una tabla con las posibles soluciones a algunas de

las causas de los fracasos de los proyectos de TI:
Causas de fracasos en los

Proyectos de Software Solución
Para darle solución a este problema es necesario aplicar un
método de obtención de requerimientos efectivo, el cual
centre su atención en obtener, analizar, especificar y validar
requerimientos, evitando la ambigüedad en los mismos, los
cuales logren satisfacer las necesidades de los usuarios,
Especificación de requerimientos para un mejor resultado el método propuesto es iterativo, lo
incompleta, ambigua e cual garantiza cubrir al final de todas las iteraciones los
inconsistente. requerimientos más importantes y claves para el sistema
(evita la incompletitud), impidiendo el desarrollo de un
producto que no cumpla con las expectativas del usuario
final. Cada uno de los requerimientos tratados en las
diferentes etapas del método son comparados con las
metas, objetivos y realidad de la organización interesada,
de esta manera se evita la inconsistencia de los
requerimientos.
Pobre planeación del proyecto, El modelo del negocio ayuda a vislumbrar al inicio del
poca precisión para estimar el proyecto el tiempo y recursos a emplear, estas información
tiempo y los recursos (no se sirve como entrada para planear el proyecto, no ha ciegas
cumplen los plazos previstos ni como habitualmente sucede, sino con ciertas bases reales,
los costos estipulados). disminuyendo el riesgo realizar estimaciones incorrectas.
Se presentan dificultades para La retroalimentación del cliente / usuario y la validación que
obtener productos sin errores se realiza durante los ciclos del método propuesto, son
(productos razonablemente actividades fundamentales para definir requerimientos
buenos en calidad). reales y consistentes, aportando a la producción de un
sistema que cumpla con las estándares de calidad.
Es fundamental realizar un modelo del negocio en el cual
se identifiquen los principales procesos de la empresa,
Ausencia de un caso de negocio actores, eventos, objetos y reglas del negocio. Esta
(business case) información es la base para desarrollar una buena
obtención de requerimientos, al poder reutilizar ciertos
datos del modelo y poder validar los requerimientos,
ajustándolos a la realidad empresarial.
Desviación del objetivo inicial, En el modelado del negocio se identifican los objetivos y
cambio de norte, de metas de la organización, a la par se establece el ambiente
especificaciones o de entorno. y entorno en el cual actuará el nuevo sistema. Esta
información es guía para las demás etapas y fases del
desarrollo del producto software, además sirve como
referencia para evitar desviaciones e
Mala definición del alcance. En el modelo del negocio se define un alcance inicial del
proyecto, el cual se concreta y se refina en la obtención de
requerimientos, este alcance se perfila con la información
que aporta el cliente / usuario, al estar vinculado en estas
etapas de manera constante.
Tabla 25. Posibles soluciones a algunas causas de los fracasos de los proyectos de
Software
- 193 -
ANALISIS ECONOMICO Y ADMINISTRATIVO
Según el análisis realizado en el capítulo 4 de este documento, el desarrollo de

este proyecto y la aplicación del método propuesto para la obtención de
requerimientos es de gran importancia para las empresas dedicadas al
desarrollo de productos software, debido a que permite la reducción de errores
en los sistemas, trayendo consigo la disminución del tiempo requerido para
correcciones, el costo de dichas correcciones y mejorando la calidad y
producción de la empresa.
Las principales causas de fracaso de los proyectos son: Requerimientos

incompletos y deficiencia en la participación del usuario, los cuales suman
entre ellos el 25.5 %, trayendo consigo el 82 % del costo de corrección de los
errores de producción. Como se puede apreciar el modelado del negocio
realizado con BMM y la obtención de requerimientos desarrollada con el
método propuesto se enfocan en atacar estas causas, permitiendo, según las
políticas y metodología de desarrollo de la empresa, la reducción en costos,
tiempo y esfuerzos y el aumento en productividad, calidad y optimización de
procesos.
El desarrollo de este proyecto no generó mayores gastos, a continuación se

relacionan:
HARDWARE (Recursos Universidad)
• PC: Pentium IV, mínimo 2.6 GHz, 512 RAM. $ 2’000.000
SOFTWARE (Recursos Propios)
• Enterprise Architect Versión Trial de 30 días
- 194 -
PAPELERIA (Recursos Propios)
• Impresiones $ 500.000
• CD $ 20.000
• Libros, artículos, revistas, etc. $ 300.000
HONORARIOS PROFESIONALES (Recursos Universidad)
• Asesor Universidad de Pamplona (2 horas semanales) $ 1’500.000

• Asesor Plataforma (2 horas semanales) $ 1’500.000
• Desarrollador (SMMLV) $ 1’632.000
OTROS (Recursos Universidad)
• Internet $ 500.000
TOTAL: $ 7’952.000
- 195 -
ANALISIS DE LEGALIDAD
Para el desarrollo de este proyecto se utilizó información confidencial de la

Empresa Social del Estado IMSALUD, la cual autorizó su manipulación para
fines profesionales como lo es el desarrollo de un sistema para el soporte de la
prestación de los servicios de salud que allí se ofrecen.
A nivel de recursos software, se utilizó como herramienta para la realización de

los diferentes modelos y diagramas, Enterprise Architect la cual requiere la
compra de una licencia, debido a que pertenece al grupo de software
propietario, pero en este caso se hizo uso de una versión trial de 30 días.
- 196 -
CONCLUSIONES
• El modelado del negocio es una etapa fundamental y sirve como base para
las siguientes fases del desarrollo de software, la información que se
abstrae al realizar dicha etapa, es primordial para enmarcar el sistema a ser
construido, dentro del ambiente real del cliente, permitiendo de esta manera
definir el alcance del proyecto y contar con puntos de referencia básicos
para establecer y validar requerimientos adecuados, acordes a la situación
organizacional, social, técnica y ambiental de la empresa objetivo.
• El modelado del negocio se realizó empleando el método BMM, el cual está

basado en principios, procesos y conceptos tomados de la Ingeniería de
métodos, modelamiento empresarial y la Ingeniería del software orientada a
objetos. El BMM consta de tres modelos (producto, equipo, proceso de
modelado), cada uno de ellos permite obtener información relacionada con
el producto deseado, los recursos humanos necesarios para llevar a buen
término el proyecto y demás aspectos importantes del negocio de la
empresa, como valor agregado se obtiene que la mayoría de sus artefactos
pueden ser reutilizados en las fases posteriores de desarrollo.
• En la Obtención de requerimientos, denominada por algunos autores como

Ingeniería de Requerimientos, debido a que consta de algunas etapas, las
cuales deben desarrollarse en cierto orden para conseguir los objetivos
específicos de esta fase, conformando así un proceso repetible, requiere la
aplicación de técnicas y herramientas que respalden dicho proceso, con el
objetivo de extraer, analizar, especificar y validar requerimientos
consistentes, claros y apropiados.
• La Extracción de requerimientos también denominada captura, es una etapa

que representa el comienzo de la Obtención de Requerimientos. Extracción
- 197 -
es el nombre comúnmente dado a las actividades involucradas en el

descubrimiento de los requerimientos del sistema. En este punto los
analistas y el cliente deben trabajar juntos para poder definir el dominio del
problema, los servicios que el sistema debe prestar, restricciones y demás
características relevantes.
• Sobre la base de la extracción realizada previamente comienza el análisis

de los requerimientos, en la cual se apunta a descubrir problemas e
inconsistencias entre ellos. Se procede a leer, conceptuar e investigar
dichos requerimientos, se intercambian ideas con el equipo de trabajo, se
resaltan problemas, se buscan soluciones y alternativas para luego
presentar dicho estudio al cliente, buscando su aprobación.
• En la especificación se pasa de lenguaje natural (comprendido por el

cliente), a lenguaje formal y técnico, cada uno de los requerimientos
obtenidos y analizados, haciendo uso de lenguajes y herramientas de índole
formal o semi-formal, con el objetivo de facilitar la validación especializada
de los requerimientos.
• Para la Obtención de requerimientos se identificaron varias técnicas y

herramientas que ayudan y soportan el proceso de extracción, análisis,
especificación y validación de requerimientos, aportando facilidad de
aplicación del proceso, definición del dominio del problema, alcance y
requerimientos acordes al negocio. De estas técnicas y herramientas
fueron seleccionadas algunas de ellas para aplicarlas en la Obtención de
requerimientos de este proyecto, generando resultados positivos en estado
de aceptación.
• Se propuso un método para la Obtención de Requerimientos, el cual se

centra en el usuario, es iterativo e incremental, tiene como fundamento y
base los casos de uso, además de emplear el modelamiento visual como
lenguaje de comunicación entre los clientes / usuarios y el equipo de
- 198 -
desarrollo. Dicho método consta de cuatro etapas, en las cuales se

incluyen unas actividades orientadas en la definición de requerimientos
reales, útiles, consistentes, claros y adecuados, según las necesidades de
los clientes, que conformen soluciones efectivas a los problemas actuales
de la empresa interesada.
• La mayoría de los proyectos de Tecnologías de Información y

especialmente aquellos relacionados directamente con la producción de
soluciones software, no llegan a completarse con éxito, por causas tales
como mala definición de requerimientos, requerimientos irreales,
inconsistentes, dominio del problema desconocido o confuso y estimaciones
desfasadas en tiempo, espacio y recursos, entre otras que para este caso
no fueron tenidas en cuenta. Para aportar a la mitigación de errores en los
sistemas producidos por las diferentes organizaciones especializadas en
dicha área, se debe atacar cada una de las causas mencionadas
anteriormente, para este fin se encontró que un buen modelo del negocio y
una adecuada obtención de requerimientos son soluciones eficientes en
tales términos, las cuales deben ser desarrolladas basándose en métodos
que faciliten la consecución de sus objetivos.
- 199 -
RECOMENDACIONES
• Se recomienda continuar con el estudio y análisis de la pertinencia de un

modelo del negocio y la aplicación de un método óptimo para la obtención
de requerimientos, considerando que dichas fases son los cimientos
principales y fundamentales para un desarrollo adecuado de software.
• El método propuesto para la obtención de requerimientos puede ser

mejorado aplicando otras técnicas y herramientas y estudiando los
resultados obtenidos de dicha aplicación, para de esta manera considerar
diferentes formas de optimización, conformando así un método robusto y
flexible.
• Sería objeto de estudio la aplicación del método propuesto a más casos

reales de desarrollo de software y estimar su validez a lo largo de dicho
proceso.
- 200 -
ANALISIS BIBLIOGRAFICO
REFERENCIAS BIBLIOGRAFICAS
[BROOKS, 1987] BROOKS Frederick, (1987). No Silver Bullet. Essence and

Accident in Software Engineering. USA. IEEE Computer.
[VILLAMIZAR, 2006]. VILLAMIZAR E, Avilio (2006). Ideas del RUP. CosmoSoft,

parque tecnológico.
[BARRIOS et all, 2003] BARRIOS Judith y MONTILVA Jonás. (2003) “A

Methodological Framework for Business Modeling”.
[KOTONYA et all, 1997] Kotonya, G., Sommerville, P. (1997). Requirements

Engineering: Processes and Techniques. John Wiley & sons.
[LOCOPOULOS et all, 1995] Locopoulos, P., Karakostas V. (1995). System

Requirements Engineering. McGraw Hill Int.
[POHL, 1996] Pohl, K. (1996). Requirements Engineering: An Overview. En

“Encyclopedia of Computer Science and Technology”, Vol. 36, Marcel Dekker
Inc., New York.
[POHL, 1994] K. Pohl. (Junio 1994) Las Tres Dimensiones de Ingeniería de

Requerimientos: Un Armazón y su Aplicación. Los Sistemas de información,
3(19).
[SOMMERVILLE, 1997] Sommerville, I., Sawyer, P. (1997). Requirements

Engineering: A Good Practice Guide. John Wiley & sons.
- 201 -
[KOMER, 1993] KOMER, P. (1993). Dirección de la Mercadotecnia. Séptima

Edición. España. Prentice Hall.
[CRAIG, 1999] CRAIG, L. (1999). UML Y PATRONES. Introducción al análisis y

diseño orientado a objetos. España. Pearson.
[ROBERTSON, 1999] Robertson, S; Robertson J. (1999). Mastering the

Requeriments Process. Inglaterra. Pearson.
[CHECKLAND, 1989] Checkland, P. (1989) "An Application of Soft Systems

Methodology. Rational Analysis for a Problematic World", Chapter 5. New York:
John Wiley & Sons.
[BURG, 1997] Burg, J F M (1997). Linguistics Instruments in Requirements

Engineering. Tesis Doctoral, Vrije Universiteit, IOS Press.
[ACIS, 2006] Asociación Colombiana de Ingenieros de Sistemas, “La Gerencia

de Proyectos de TI en el país, vista por algunos expertos”, Noviembre 17 de
2006
[DORFMAN, 1997] Dorfman M. y Thayer, R. "Software Engineering", IEEE

Computer Society Press, Los Alamitos, CA, 1997.
[LEITE, 1987] Leite, J. C. S. P. "A Survey on Requirements Analysis",

Advancing Software Engineering Project Technical Report RTP-071, University
of California at Irvine, Department of Information and Computer Science, Jun.
1987.
REFERENCIAS WEB
[DELGADO, 2006] http://www.inf.udec.cl/revista/ediciones/edicion8/Rbc.pdf

Título: Definición del modelo del negocio y del dominio utilizando razonamiento
basado en casos.
- 202 -
Autora: Magíster Martha D. Delgado Dapena

Centro de estudios de Ingeniería de Sistemas
Fecha de consulta: 19 de Septiembre de 2006
[BAEZ et all, 2006] http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER01/

baez.pdf
Título: Metodología DoRCU para la Ingeniería de Requerimientos
Autora: M. Griselda Báez, Silvia I. Barba Brunner
Instituto Superior Politécnico "José Antonio Echeverría", La Habana, CU
[DAVILA, 2006] http://www.monografias.com/trabajos12/ingreq/ingreq.pdf

Título: Ingeniería de requerimientos: Una guía para extraer, analizar,
especificar y validar los requerimientos de un proyecto.
Autor: Nicolás Davyd Dávila
Universidad de Uruguay
[SUMANO, 2006] http://www.geocities.com/diegolp/ingsof/requerimientos.pdf

Título: Análisis de requerimientos de software
Autora: M.C.C María de los ángeles Sumano López
Fecha de consulta: Septiembre 13 de 2006
[THOMAS, 2006] http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER05/

pablo_thomas.pdf
Título: Elicitación de objetivos a partir de escenarios
Autor: Pablo Thomas
Instituto de investigación en informática LIDI
Fecha de consulta: 22 de Agosto de 2006
[GIL, 2006] http://postgrado.info.unlp.edu.ar/Carrera/Magister/Ingenieria%20de

%20Software/Tesis/Gil.pdf
- 203 -
Título: Herramienta para implementar LEL y escenarios

Autor: Gustavo Daniel Gil
Fecha de consulta: 22 de Agosto de 2006
[ZABALA, 2006] http://www.consol.org.mx/2004/material/63/por-que-fallan-los-

proy-de-soft.pdf
Título: ¿Por qué fracasan los proyectos de software? Un enfoque
organizacional.
Autor: J. Jesús María Zabala Ruiz
Universidad Autónoma Metropolitana-Iztapalapa. México, D.F.
Fecha de consulta: Septiembre 13 de 2006
[OCHOA, 2006] http://www.monografias.com/trabajos11/metods/metods.shtml

Título: Métodos
Autora: Ana Beatriz Ochoa G.
Fecha de consulta: Diciembre de 2006
- 204 -
Anexo 1. Análisis comparativo de Metodologías utilizadas en la Obtención

de Requerimientos.
Metodología Etapas Ventajas Desventajas

Metodología Se debe dedicar
centrada en el bastante tiempo para la
usuario, lo cual realización de los
permite satisfacer documentos, lo cual
las necesidades retrasa en parte el
DoRCU Captura de reales del cliente. desarrollo del proyecto.
(Documentación de requerimientos
Requerimientos Análisis de Documentación de Duplicidad de trabajo
Centrada en el requerimientos requerimientos de por la necesidad de
Usuario). Especificación de una manera técnica desarrollar documentos
requerimientos para el equipo de de manera formal para
Validación y desarrollo y en el equipo de trabajo y
Certificación de lenguaje natural para pasarlos a una manera
Requerimientos. la revisión del informal para el usuario.
usuario, facilitando
su comprensión.
Permite el desarrollo
en ciclos o
iteraciones para de
esta manera corregir
o adicionar
requerimientos.
Provee mecanismos Su enfoque en
de representación escenarios provee
adecuados, como lo flexibilidad para obtener
Identificar Metas y son los escenarios, los requerimientos, pero
Objetivos. para la comprensión a su vez, le resta
GBRAM (Goal- Organizar y Clasificar de los stakeholders. formalismo a su
Based Metas. especificación,
Requirements Refinar y Elaborar Se concentra en causando de esta
Analysis Method) Metas. establecer los manera conflictos en el
Operacionalizar fundamentos que equipo de desarrollo,
Metas en justifican los debido a posibles
Requerimientos. requerimientos de ambigüedades en los
software, debido a requerimientos.
que se basa en los
Objetivos de la No se definen
organización. actividades para la
especificación y
validación de
requerimientos.
Poner en claro la Se enfoca en el Es recomendable para
situación del modelamiento visual, la comprensión del
SSM (Soft System problema. lo que permite una ambiente del proyecto y
Methodology) Expresar la situación. mayor comprensión el dominio del problema,
Hacer la selección de de los pero no para utilizarla
como ver requerimientos. como metodología de

paulatinamente la Ingeniería de
situación de manera Está basado en la Requerimientos en un
que se pueda producir representación de proyecto formal, debido
percepciones que den actividades del a que no proporciona la
pié a definiciones raíz. mundo real. información necesaria
Construir modelos para el desarrollo de las
conceptuales. Permite obtener la actividades de dicha
Comparar los información inicial. fase.
modelos conceptuales
con el mundo real.
Identificar cambios
factibles y deseables.
Recomendaciones
para la toma de
acciones que mejoren
la percepción
problema.
Metodología basada Se debe contar con
en la lingüística personal calificado en
computacional y el modelos de Lenguaje
análisis orientado a Natural.
objetos, facilitando el
modelado de los No incluye la captura y
Color – X requerimientos. análisis de
(Conceptual requerimientos, por lo
Linguistically based Especificación de Es una herramienta tanto el equipo de
Object oriented requerimientos. automática o desarrollo debe aplicar
Representation Validación y semiautomática que otra metodología para la
language for verificación de reduce notablemente realización de estas
information and requerimientos. el tiempo de etapas.
communication desarrollo.
systems)
Se ejecuta de
manera iterativa
permitiendo la
participación del
usuario durante su
proceso.
Elaboración de Reusa Es necesario contar con
necesidades y requerimientos y información de
objetivos. artefactos proyectos anteriores
Rare-Idiom (Reuse- Obtención de asociados, para su aplicación.
Assisted requerimientos. incentivando el
Requirement Especificación de almacenamiento de
Engineering with requerimientos y conocimiento.
Informal Document modelado.
Interpreter Generación y Se basa en las
Organizer and evaluación de propiedades
Manager) alternativas. estructurales de los
Verificación y documentos de
validación de requerimientos y los
requerimientos. procesos realizados
para su producción.
Anexo 2. Glosario
Abstracción: Consiste en aislar un elemento de su contexto o del resto de los

elementos que lo acompañan. En programación, el término se refiere al énfasis
en el "¿qué hace?" más que en el "¿cómo lo hace?". El común denominador en
la evolución de los lenguajes de programación, desde los clásicos o
imperativos hasta los orientados a objetos, ha sido el nivel de abstracción del
que cada uno de ellos hace uso.
Acción: Una acción es la salida del sistema, relacionada con una entrada
sensorial. Cambia el entorno. La acción es la implementación (el hacer) de la
segunda parte de una regla de actuación.
Actividad: Agrupación de Tareas que hace parte de un Proceso.
Actor: Es una persona, máquina o sistema que se encarga de interactuar con

el sistema para desencadenar un flujo de eventos, actividades y acciones
dentro del mismo, con el objetivo de conseguir un resultado deseado.
Alcance: El alcance describe todo el trabajo que el proyecto debe incluir, y sólo
el trabajo requerido, para completar el proyecto de manera exitosa.
Ambiente: Entorno en el cual una organización opera. Condiciones externas

que afectan a un sistema.
Análisis: Acción de dividir una cosa o problema en tantas partes como sea
posible, para reconocer la naturaleza de las partes, las relaciones entre estas y
obtener conclusiones objetivas del todo. Fase de la ingeniería de
requerimientos, la cual se enfoca en descubrir problemas con los
requerimientos del sistema identificados.
Aplicación: En informática las aplicaciones son los programas con los cuales
el usuario final interactúa. Programa que efectúa una tarea definida.
Artefacto: Todo objeto hecho por el hombre de acuerdo con las normas que lo
rigen, en ingeniería del software se refiere a un resultado de un proceso, el cual
puede ser un documento, un modelo, entre otros.
Atributo: Información descriptiva asociada a un rasgo específico de un objeto.
Bosquejo: Es el primer trazo y no el definitivo de una obra "pre torica" o de

cualquier producción de ingenio, es una idea vaga de un concepto o plan.
Calidad: La calidad de un producto o servicio es la percepción que el cliente

tiene del mismo. Conjunto de propiedades inherentes a un objeto que permiten
apreciarlo como igual, mejor o peor que el resto de objetos de los de su
especie.
Caso de Uso: Es una forma visual o gráfica de representar la realidad, explica

la forma como interactúa el sistema y los actores.
Es una técnica efectiva y a la vez simple para modelar los requisitos del
sistema desde la perspectiva del usuario. Los Casos de Uso se utilizan para
modelar cómo un sistema o negocio funciona actualmente, o cómo los usuarios
desean que funcione.
Ciclo: Una secuencia de instrucciones que se ejecutan en forma repetitiva

hasta cumplir una condición particular.
Ciclo de vida del software: El proceso que se sigue para construir, entregar y
hacer evolucionar el software, desde la concepción de una idea hasta la
entrega y el retiro del sistema.
Cliente: Toda organización, entidad, comunidad o persona que requiera los

servicios o productos de una organización, consumidor final que utiliza el
servicio, benefactor.
Componente: Agrupación de elementos que hace parte de un subsistema.
Comportamiento: La palabra comportamiento generalmente se refiere a

acciones de un objeto u organismo, usualmente en relación con su entorno o
mundo de estímulos.
Concepto: Un concepto es el elemento básico del pensamiento. Es el

almacenamiento físico, material de información. Todos los conceptos de la
memoria están interrelacionados, forman una red.
Condición: Constituye el factor de toma de decisiones.
Contexto: Ambiente o entorno. Circunstancias de las cuales depende el

sentido y el valor de un objeto.
Costos: Son los gastos incurridos en la producción, administración y venta de

los productos o servicios vendidos.
Cualidad: Propiedad o modo de ser propio y distintivo de algo que, por lo

general, tiene un carácter positivo.
Declive: Inclinación, pendiente con orientación hacia abajo.
Demanda inducida: Hace referencia a la acción de organizar, incentivar y

orientar a la población hacia la utilización de los servicios de protección
específica y detección temprana y la adhesión a los programas de control.
Detección temprana: Hace referencia a los procedimientos que identifican en

forma oportuna y efectiva la enfermedad, facilitan su diagnóstico en estados
tempranos, el tratamiento oportuno, la reducción de su duración y el daño que
causa evitando secuelas, incapacidad y muerte.
Diagnóstico: Procedimiento con el que se identifica una enfermedad.
Diagrama: Es una forma de representar gráficamente un fenómeno, proceso u

organización determinado.
Dominio del problema: Es el área de conocimiento hacia la cual se orienta

determinada solución de software.
Efectividad: Consistente en alcanzar los resultados programados a través de

un uso óptimo de los recursos involucrados.
Eficiencia: Es la relación entre los recursos utilizados y los bienes o servicios

producidos. Logro de un objetivo al menor costo unitario posible. Se refiere al
uso óptimo de recursos en programas, subprogramas y proyectos.
Especificación: Una especificación puede ser un documento escrito, un

modelo gráfico, un modelo matemático formal, una colección de escenarios de
uso, un prototipo o una combinación de lo anteriormente citado.
Estimación: Proceso por el que se realizan inferencias inductivas sobre

parámetros de la población a partir de los datos de una muestra.
Entorno: El entorno de un sistema es aquella parte del universo que está en

comunicación con el sistema, pero que no es parte del sistema.
Entregable: Producto o resultado que debe ser entregado a la persona,

empresa u organización interesada.
Escenario: Un conjunto de variables que para esa situación poseen un nivel de

valor y un grado de ocurrencia. Combinación de secuencia de eventos o
fenómenos anticipados, generalmente situados los unos respecto a los otros.
Estructura: Es una parte formada por otras partes, las que tienen relaciones
espaciales fijas entre sí.
Eventos: acción de corta duración que ocurre dentro o fuera del sistema del
negocio.
Extracción: Nombre comúnmente dado a las actividades involucradas en el

descubrimiento de los requerimientos del sistema.
Flujo: La realización progresiva de las diferentes actividades que forman el

flujo de valor, de tal manera que el producto progresa del diseño a su
lanzamiento, de su orden de compra a su entrega y de materia prima a las
manos del cliente sin tener paros, desperdicios o retrabajos.
Función: Una función correspondería a un conjunto de actividades

coordinadas de distintos elementos de un sistema, contribuyendo a la
realización de un mismo objetivo. Sin embargo una función es una entidad
abstracta y teórica, extrapolada a ir de datos experimentales.
Funcionalidad: Característica o comportamiento esencial que debe soportar

un sistema de información.
Glosas: Son las observaciones de tipo administrativo y técnico realizadas a las

cuentas de salud, mediante las cuales se objetan determinados valores
cobrados.
Herramienta: Instrumento. Por ejemplo, un cronograma informal de entrevistas

o un cuestionario son herramientas para recopilar información. Una
herramienta se puede aplicar mediante distintos métodos o técnicas.
Historia clínica: La historia clínica es el conjunto de documentos surgidos de

la relación entre el médico y el paciente, y a partir de la segunda mitad del siglo
XX entre usuarios y el hospital o Atención Primaria. La historia clínica es el
único documento válido desde el punto de vista clínico y legal. En atención
primaria la historia clínica se llama historia de salud.
Impacto: Cambio logrado en la situación de la comunidad como resultado del

producto de un proceso. Es el nivel más elevado o la finalidad última del
proceso y donde se genera la totalidad de los beneficios previstos. Es
equivalente a Valor Agregado.
Incremental: Aumento gradualmente en grados o adiciones regulares.
Información: En sentido general, la información es un conjunto organizado de

datos, que constituyen un mensaje sobre un determinado ente o fenómeno.
Ingeniería del software: Es el conjunto de métodos, técnicas y herramientas

que controlan el proceso integral del desarrollo de software y suministra las
bases para construir software de calidad de forma eficiente en los plazos
adecuados.
Interfaz: Una interfaz es la parte de un programa informático que permite a

éste comunicarse con el usuario o con otras aplicaciones permitiendo el flujo de
información.
Iteración: Cada uno de los ciclos en los cuales se realizan ciertas actividades y
tareas planeadas previamente, de los cuales se obtiene un producto sujeto a
validación y modificación.
Jerarquía: Jerarquía es el orden de los elementos de una serie según su de

valor.
Kardex: Es uno de los principales proveedores mundiales de sistemas

automatizados de almacenamiento y clasificación
Lenguaje: Sistema de programación que permite crear programas y así

comunicar al usuario con la máquina a fin de que esta cumpla una tarea
determinada. Existen distintos niveles de lenguajes que se pueden clasificar
según su grado de abstracción y dificultad.
Meta: Resultado que se pretende alcanzar en un plazo determinado para

avanzar hacia el cumplimiento de un objetivo. Su medición debe hacerse en
términos de tiempo, cantidad y, si es posible, calidad.
Método: Modo ordenado de proceder para llegar a un resultado o fin

determinado. Aplicación de tipo particular.
Metodología: Metodología se refiere a los métodos de investigación en una

ciencia. Manera sistemática de hacer cierta cosa.
Modelo: Un modelo es una conceptualizacion de un evento, un proyecto, una

hipótesis, el estado de una cuestión, que se representa como un esquema con
símbolos descriptivos de características y relaciones más importantes con un
fin: ser sometido a modelización como un diseño flexible, que emerge y se
desarrolla durante el inicio de la investigación como una evaluación de su
relevancia.
Modelo del negocio: Un modelo de negocios es la "forma de hacer negocios",

valga la redundancia, mediante la cual una empresa genera ingresos con base
en su posicionamiento en la cadena de valor.
Morbilidad: La enfermedad, los efectos laterales y los síntomas de un

tratamiento o enfermedad.
Necesidad: Es una sensación de carencia de un producto básico.
Negocio: Toda actividad que se emprende con el objeto de obtener un

provecho económico.
Objetos: Pensamiento concreto o abstracto que es relevante para el sistema.
Obtención de requerimientos: Fase, etapa o disciplina, para algunas

metodologías de desarrollo, la cual se encarga de definir, analizar y especificar
los requerimientos que debe soportar el sistema a ser creado.
Operación: El método, acto, proceso, o efecto de utilizar un dispositivo o

sistema.
Organigrama: Es la representación gráfica de la estructura organizativa,

vertical u horizontal, de una empresa.
Paramédico: paramédico es un profesional que acude a las llamadas de

emergencia para proveer de un cuidado oportuno y eficiente a un paciente
traumatizado o con enfermedad súbita y lo transporta a una unidad médica
para su atención integral complementaria para la resolución de su problema.
Política: La política es un modo de actividad que intenta resolver conflictos y

promueve ajustes. Manera de tratar un asunto o los medios empleados para
conseguir un fin.
Proceso: Un proceso (del latín processus) es un conjunto de actividades o

eventos que se realizan o suceden con un determinado fin.
Producción: Conjunto de operaciones que sirven para mejorar e incrementar

la utilidad o el valor de los bienes.
Protección específica: Hace referencia a la aplicación de acciones y/o

tecnologías que permitan y logren evitar la aparición inicial de la enfermedad
mediante la protección frente al riesgo.
Prototipo: Un prototipo es un ejemplar original o primer molde en que se

fabrica una figura u otra cosa.
Proyecto: Una actividad de desarrollo socioeconómico planificada y orientada

a la consecución de objetivos, que requiere inversiones financieras o
participación humana en un tiempo dado.
Recurso: Cualquier parte componente de un sistema de información.

Elemento necesario para llevar a cabo una tarea.
Régimen Contributivo: El régimen contributivo es un conjunto de normas que

rigen la vinculación de los individuos y las familias al Sistema General de
Seguridad Social en Salud, cuando tal vinculación se hace a través del pago de
una cotización, individual y familiar, o un aporte económico previo financiado
directamente por el afiliado o en concurrencia entre éste y su empleador.
Régimen Subsidiado: El régimen subsidiado es un conjunto de normas que

rigen la vinculación de los individuos al Sistema General de Seguridad Social
en Salud, cuando tal vinculación se hace a través del pago de una cotización
subsidiada, total o parcialmente, con recursos fiscales o de solidaridad.
Regla: Es un conjunto de valores combinados que, al cumplirse determinadas

condiciones, lanza la ejecución de acciones establecidas previamente.
Requerimiento: Es una condición o necesidad de un usuario para resolver un

problema o alcanzar un objetivo.
Una condición o capacidad que debe estar presente en un sistema o
componentes de sistema para satisfacer un contrato, estándar, especificación u
otro documento formal.
Restricción: Limitación que debe soportar una aplicación software para hacer
cumplir las reglas establecidas anteriormente, con el objetivo de satisfacer los
requerimientos del usuario.
Retroalimentación: Comunicación entre el instructor o el sistema y el

aprendiz, como resultado de una acción o proceso.
Reusar: Reutilizar es la acción de volver a utilizar los bienes o productos. La

utilidad puede venir para el usuario mediante una acción de mejora o
restauración, o sin modificar el producto si es útil para un nuevo usuario.
Rol: Rol en sociología se refiera al conjunto de funciones, normas,

comportamientos y derechos definidos social y culturalmente que se esperan
de una persona (actor social) cumpla o ejerza de acuerdo a su estatus social
adquirido o atribuido.
Sistema: Un sistema es un conjunto de elementos organizados que interactúan

entre sí y con su ambiente, para lograr objetivos comunes, operando sobre
información, sobre energía o materia u organismos para producir como salida
información o energía o materia u organismos.
Sistematización: Es un proceso permanente y acumulativo de construcción de

conocimiento a partir de nuestra experiencia de acción/intervención en una
realidad específica. Es un primer nivel de teorización sobre la práctica. Por un
lado pretende mejorar la práctica y por el otro enriquecer las teorías existentes.
Software: También conocido como soporte lógico, compendia todo tipo de

programas, utilidades, aplicaciones, sistemas operativos, drivers que hacen
posible que el usuario pueda trabajar con la máquina.
Stakeholders: Son los grupos que tienen interés en que la empresa sobreviva.
Estos grupos de interés (personas u organizaciones) pueden afectar o verse
afectados por las decisiones de la empresa de la que están interesados.
Tarea: Una actividad definida que es cumplida por individuos y organizaciones.

Las tareas son actividades específicas que contribuyen al cumplimiento de la
misión general u otros requerimientos. Una tarea debe ser alcanzable, decisiva
y responder al QUE de la misión.
Técnica: La técnica es el procedimiento o el conjunto de procedimientos que

tienen como objetivo obtener un resultado determinado, ya sea en el campo de
la ciencia, de la tecnología, de las artesanías o en otra actividad.
Tecnología: Conjunto de las diferentes técnicas de producción que se pueden

aplicar en una actividad de producción determinada.
Traceabilidad: Una especificación de requisitos del software es detectable si

(i) el origen de cada uno de sus requisitos está claro y si (ii) facilita referirse de
cada requisito al desarrollo o al realce futuro documentación
Usuario: Sujeto o proceso autorizado para acceder a datos o recursos. El

usuario es la persona que consume o usa el producto, bien o servicio.
Validación: La validación es la etapa final de la Ingeniería de Requerimientos.

Su objetivo es verificar todos los requerimientos que aparecen en el
documento, 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, estén completos y que el resultado del
trabajo se ajuste a los estándares establecidos para el proceso, el proyecto y el

producto.
Anexo 3. Plantillas
1. Elicitación de Requerimientos:
Recolectar y Clasificar Requerimientos

Ciclo Técnica Herramienta Descripción Requerimientos Obtenidos
Ciclo Técnica Herramienta Descripción Requerimientos y prioridad
Retroalimentación
2. Análisis de Requerimientos:
Verificar la correspondencia de los requerimientos con las metas de la organización y las

necesidades de los clientes / usuarios
Plantear modelos y diagramas lógicos

Retroalimentación
3. Especificación de Requerimientos:
Elegir la herramienta para la especificación de requerimientos

Especificar los requerimientos

4. Validación de Requerimientos:
Validar la correspondencia entre requerimientos y casos de uso

5. Especificación de Casos de Uso:
NOMBRE DEL CASO DE USO QQQQQQQQQQ

ACTOR PARTICIPANTE
CONDICION INICIAL
FLUJO DE EVENTOS
CONDICION DE SALIDA
Anexo 4. Siglas
ARS: Administradora de Régimen Subsidiado

BMM: Business Modeling Method
CNSSS: Comisión Nacional de Seguridad Social en Salud
COLOR-X: Conceptual Linguistically based Object oriented Representation
language for information and communication systems
DA: Documento de Análisis
DASSSACU: Departamento Administrativo en Seguridad Social en Salud
DE: Documento de Elicitación
DCO: Documento de Concepto de Operaciones
DI: Demanda Inducida
DOFA: Debilidades – Oportunidades – Fortalezas - Amenazas
DoRCU: Documentación de Requerimientos Centrada en el Usuario
DP: Detección Precoz
DRT: Documento de Requerimientos Técnico
DRU: Documento de Requerimientos Orientado al Usuario
EA: Enterprise Architect
ESE: Empresa Social del Estado
ESRE: Documento de Especificación de Requerimientos
GBRAM: Goal-Based Requirements Analysis Method
IPS: Instituciones Prestadoras de Servicios de Salud
JAD: Desarrollo Conjunto de Aplicaciones
IMSALUD: Institución Municipal de Salud de San José de Cúcuta
LEL: Léxico Extendido del Lenguaje
PAI: Programa Ampliado de Inmunizaciones
PAIDSA: Base de datos Programa Ampliado de inmunizaciones
PE: Protección Específica
POS: Plan Obligatorio de Salud
QFD: Quality Function Deployment
RARE-IDIOM: Reuse-Assisted Requirement Engineering with Informal

Document Interpreter Organizer and Manager
RIPS: Registro Individual de Prestación de Servicios
RUP: Rational Unified Process
SISVAN: Sistema de Vigilancia Alimentaria y Nutricional
SRS: Especificación de Requerimientos Software
SSM: Soft System Methodology
UML: Unified Modeling Language

Analisis Comparativo 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

Analisis Comparativo PDF

Cargado por

Copyright:

Formatos disponibles

FACULTAD DE INGENIERÍAS Y ARQUITECTURA

PROGRAMA DE INGENIERÍA DE SISTEMAS

TRABAJO PRESENTADO PARA OPTAR POR EL TITULO DE

ANALISIS COMPARATIVO DE TECNICAS DE OBTENCION DE

El jurado calificador conformado por:

Terminadas las deliberaciones he llegado a las siguientes conclusiones:

PRIMERA CONCLUSIÓN: OTORGAR LA CALIFICACIÓN DE

Aprobado, Excelente, Incompleto

AL TRABAJO DE GRADO TITULADO:

“ANÁLISIS COMPARATIVO DE TÉCNICAS DE OBTENCIÓN DE REQUERIMIENTOS

De la autora: Adriana Milena Rangel Carrillo

SEGUNDA CONCLUSIÓN: RECOMENDAR

1. Recomendar para presentar en eventos científicos: ____________

TERCERA CONCLUSIÓN: OTORGAR

FIRMAS DEL JURADO

___________________ _________________ __________________

La esperanza es el sueño del hombre despierto… (Aristóteles)

Dedico este logro a su presencia…

Al refugio cálido de mi tía Yolanda,

"Solo es útil el conocimiento que nos hace mejores."

Agradezco a Dios y la virgen quienes iluminan y guían mis pensamientos.

Al profesor William Mauricio Rojas por su apoyo y dedicación, a la profesora Luz

Al Ingeniero Avilio Villamizar y demás personal de la Vicerrectoria de Gestión y

La base de un proyecto de desarrollo software lo constituyen los requerimientos

El Modelamiento del Negocio facilita la recolección de información necesaria

La Obtención de Requerimientos es la fase de la cual depende en gran medida

En este documento se presenta al Modelamiento del Negocio y la Obtención de

The basis of a Project of development / software is constituted by the requests

The Business Model facilitates the gathering of necessary information to

LISTA DE FIGURAS .......................................................................................... 7

LISTA DE TABLAS .......................................................................................... 12

LISTA DE ANEXOS ......................................................................................... 13

1. MARCO TEORICO ...................................................................................... 20

1.1 MODELO DEL NEGOCIO.......................................................................... 20

1.1.1 Escenarios .............................................................................................. 21

1.1.2 Método del Modelamiento del Negocio BMM.......................................... 23

1.1.2.1 Modelo del Producto de BMM.............................................................. 24

1.1.2.1.1 Metas del Negocio ............................................................................ 24

1.1.2.1.2 Procesos del Negocio ....................................................................... 24

1.1.2.1.3 Actores, Unidades y Estructura del Negocio..................................... 25

1.1.2.1.3.2 Unidades del Negocio .................................................................... 26

1.1.2.1.4 Tecnologías ...................................................................................... 26

1.1.2.1.5 Reglas del Negocio ........................................................................... 26

1.1.2.1.6 Objetos del Negocio.......................................................................... 26

1.1.2.1.7 Eventos ............................................................................................. 27

1.1.2.2 Modelo del Equipo ............................................................................... 27

1.1.2.3 El proceso de modelado del Negocio .................................................. 28

1.2 OBTENCION DE REQUERIMIENTOS ...................................................... 29

1.2.1 Proceso de la Ingeniería de Requerimientos .......................................... 31

1.2.1.1 Extración, Captura o Elicitación de Requerimientos ............................ 34

1.2.1.3 Especificación ...................................................................................... 37

1.2.1.4 Validación ............................................................................................ 37

1.2.2 Técnicas de Obtención de Requerimientos ............................................ 38

1.2.2.1 Entrevistas y cuestionarios .................................................................. 39

1.2.2.2 Sistemas existentes ............................................................................. 39

1.2.2.3 Grabaciones de video y de audio......................................................... 40

1.2.2.4 Tormenta de ideas (Brainstorming)...................................................... 40

1.2.2.5 Arqueología de Documentos................................................................ 41

1.2.2.10 DOFA ................................................................................................. 44

1.2.2.11 Cadena de valor................................................................................. 45

1.2.2.12 Modelo de clase conceptual............................................................... 45

1.2.2.13 Diagrama de Pescado........................................................................ 46

1.2.2.15 DCO ................................................................................................... 47

___________ _ __________