Analisis Comparativo PDF

FACULTAD DE INGENIERAS Y ARQUITECTURA
PROGRAMA DE INGENIERA DE SISTEMAS
TRABAJO PRESENTADO PARA OPTAR POR EL TITULO DE

INGENIERO DE SISTEMAS
TTULO
ANALISIS
COMPARATIVO
REQUERIMIENTOS
PARA
DE
EL
TECNICAS
MODULO
DE
DE
OBTENCION
FACTURACION
APLICATIVO GESTASOFT HOSPITALARIO PARA IMSALUD.
AUTORA
ADRIANA MILENA RANGEL CARRILLO
DIRECTOR
MS. C WILLIAM MAURICIO ROJAS
PAMPLONA COLOMBIA
ENERO DE 2007
DE
DEL
UNIVERSIDAD DE PAMPLONA
FACULTAD DE INGENIERAS Y ARQUITECTURA
DEPARTAMENTO DE INGENIERA ELCTRICA, ELECTRNICA, SISTEMAS Y
TELECOMUNICACIONES
PROGRAMA DE INGENIERA DE SISTEMAS
Siendo las ______ horas, del da _____ del mes ______ _del ao ________
El jurado calificador conformado por:
Presidente: C. Dr. Lus Alberto Esteban
Oponente: MS.c. Ailin Orjuela Duarte
Secretario: Ing. Jorge Omar Portilla
Terminadas las deliberaciones he llegado a las siguientes conclusiones:
PRIMERA CONCLUSIN: OTORGAR LA CALIFICACIN DE
_______________________________________________________________
Aprobado, Excelente, Incompleto
(Reg. Estudiantil Cap. VIII, Art. 90)
AL TRABAJO DE GRADO TITULADO:
ANLISIS COMPARATIVO DE TCNICAS DE OBTENCIN DE REQUERIMIENTOS
PARA EL MODULO DE FACTURACIN DEL APLICATIVO GESTASOFT
HOSPITALARIO PARA IMSALUD.
De la autora: Adriana Milena Rangel Carrillo
Director: MS.c. William Mauricio Rojas
SEGUNDA CONCLUSIN: RECOMENDAR
1. Recomendar para presentar en eventos cientficos: ____________
2. Recomendar para publicacin: ____________
3. Incluir en el fondo bibliogrfico de la Universidad de Pamplona: ____________
4. Recomendar para ser continuado en otros trabajos: ____________
5. Recomendar para patente: ____________
6. Recomendar continuar como trabajo de maestra: ____________
7. Recomendar continuar como trabajo de doctorado: ____________
8. Recomendar para categora de meritorio: ____________
9. Recomendar para categora de Laureado: ____________
10. Otras____________________________________________ ____________
TERCERA CONCLUSIN: OTORGAR
EL TITULO DE INGENIERO:
FIRMAS DEL JURADO
___________________ _________________ __________________
PRESIDENTE
OPONENTE
SECRETARIO
Dedicatoria
La esperanza es el sueo del hombre despierto (Aristteles)

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
acompaarme en mis silencios.
Dedico este logro a su presencia
Al refugio clido de mi ta Yolanda,
Al apoyo incondicional de mi ta Martha que trasciende fronteras,
A la palabra de nimo de mi ta Alix,
A la personita que acompaa mis sueos 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, Nstor
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 sueos se
hagan realidad, Dios.
Pensamiento
"Solo es til el conocimiento que nos hace mejores."

Scrates
Agradecimientos
Agradezco a Dios y la virgen quienes iluminan y guan mis pensamientos.
Al profesor William Mauricio Rojas por su apoyo y dedicacin, a la profesora Luz
Marina Santos que durante estos aos me ense a valorar cada gota de conocimiento,
al profesor Lus Alberto Esteban, Jorge Omar Portilla y dems docentes que ayudaron
a forjar este sueo.
A toda mi familia en la cual estn incluidos mis amigos y amigas que entre risas,
paciencia y colaboracin acompaaron la huella de cada paso.
Al Ingeniero Avilio Villamizar y dems personal de la Vicerrectoria de Gestin y
Desarrollo Tecnolgico 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 dinmica.
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 recoleccin de informacin necesaria

para desarrollar de manera iterativa los diferentes puntos visuales del entorno
de la organizacin objetivo.
Esta informacin constituye los cimientos
fundamentales de la Obtencin de Requerimientos.
La Obtencin de Requerimientos es la fase de la cual depende en gran medida

el grado de xito del proyecto, por tal razn es necesario aplicar un mtodo
flexible, iterativo y orientado en el usuario, el cual haga uso de un conjunto de
tcnicas y herramientas que faciliten la extraccin, anlisis, especificacin y
validacin de los requerimientos del producto.
En este documento se presenta al Modelamiento del Negocio y la Obtencin de

Requerimientos como solucin a algunas causas de los fracasos de los
proyectos de software, reduciendo gran parte de su sobrecosto, permitiendo la
estimacin de tiempo y esfuerzos acordes a la realidad, y facilitando la
elaboracin 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 projects success depends on the Request Obtaining phase for this reason,
its 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 products request.
In this document the Business Model and the Request Obtaining are shawn
as solution to some failures causes from the softwares projects reducing
overcost, allowing the estimation of time and efforts, according to the reality and
facilitating
the
elaboration
of
product
with
quality.
Modelo del Negocio y Obtencin 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 Mtodo 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 Tecnologas ...................................................................................... 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 Ingeniera de Requerimientos .......................................... 31
1.2.1.1 Extracin, Captura o Elicitacin de Requerimientos ............................ 34
1.2.1.2 Anlisis................................................................................................. 36
1.2.1.3 Especificacin ...................................................................................... 37
1.2.1.4 Validacin ............................................................................................ 37
1.2.2 Tcnicas de Obtencin 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 Arqueologa de Documentos................................................................ 41
1.2.2.6 Aprendiz............................................................................................... 41
1.2.2.7 Observacin......................................................................................... 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 Metodologa 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 Lxico 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. DISEO METODOLOGICO......................................................................... 69
2.1 METODO DE INVESTIGACION ................................................................ 69
2.1.1 Las diversas clases de mtodos de investigacin .................................. 69
2.1.1.1 Mtodos lgicos ................................................................................... 69
2.1.1.1.1 Mtodo lgico deductivo ................................................................... 69
2.1.1.1.2 Mtodo hipottico - deductivo ........................................................... 70
2.1.1.1.3 Mtodo lgico inductivo..................................................................... 71
2.1.1.1.4 Mtodo lgico: la analoga ................................................................ 71
2.1.1.1.5 El mtodo histrico ........................................................................... 72
2.1.1.1.6 Mtodo sinttico ................................................................................ 72
2.1.1.1.7 Mtodo analtico................................................................................ 72
2.1.1.1.8 Mtodo de la abstraccin .................................................................. 73
-3-
2.1.1.1.9 Mtodo de la concrecin ................................................................... 73

2.1.1.1.10 Mtodo gentico ............................................................................. 73
2.1.1.1.11 Mtodo de la modelacin ................................................................ 73
2.1.1.1.12 Mtodo sistmico ............................................................................ 74
2.1.1.1.13 Mtodo dialctico ............................................................................ 74
2.1.1.2 Mtodo empricos ................................................................................ 75
2.1.1.2.1Observacin cientfica........................................................................ 75
2.1.1.2.2 La experimentacin cientfica............................................................ 75
2.1.1.2.3 La medicin....................................................................................... 76
2.2 DISEO 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 Tecnologas ....................................................................................... 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 Anlisis.................................................................................................. 160
4.3.3 Especificacin ....................................................................................... 161
4.3.4 Validacin ............................................................................................. 161
4.3.5 Prcticas ............................................................................................... 162
4.4
APLICACIN
DEL
METODO
A
LA
OBTENCION
DE
REQUERIMIENTOS ...................................................................................... 163
4.4.1 Captura ................................................................................................. 163
4.4.2 Anlisis.................................................................................................. 164
4.4.3 Especificacin ....................................................................................... 165
4.4.4 Validacin ............................................................................................. 166
4.5 RESULTADOS OBTENIDOS DE LA APLICACIN 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 Descripcin de la Empresa Social del Estado IMSALUD................... 173
4.5.4.2 Organigrama de la Empresa .............................................................. 176
4.5.4.3 Misin................................................................................................. 176
4.5.4.4 Visin ................................................................................................. 177
4.5.4.5 Prestacin 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 OBTENCIN 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 BIBLIOGRFICO .......................................................................... 201
REFERENCIAS BIBLIOGRAFICAS......................................................... 201
REFERENCIAS WEB .............................................................................. 202
ANEXOS ........................................................................................................ 205
-6-
LISTA DE FIGURAS
Figura 1 Ubicacin del mtodo BMM en un modelo de procesos de sistemas

de informacin y Desarrollo de software.......................................................... 23
Figura 2 Diagrama de relacin entre actores - roles - unidades y procesos del
negocio ............................................................................................................ 25
Figura 3 Proceso de modelado del negocio.................................................... 29
Figura 4 Posible visin de la ingeniera de requerimientos [POHL, 1994] ...... 30
Figura 5 Proceso de la Ingeniera de Requerimientos [LOCOPOULOS et all,
1995]................................................................................................................ 31
Figura 6 Proceso de la Ingeniera de Requerimientos [KOTONYA et all, 1997]
.................................................................................................................. 31
Figura 7 Proceso de la Ingeniera de Requerimientos [KOTONYA et all, 1997],
un modelo en espiral........................................................................................ 32
Figura 8 Proceso de la Ingeniera de Requerimientos [POHL, 1996].............. 32
Figura 9 Modelo de madurez para la Ingeniera de Requerimientos
[SOMMERVILLE, 1997] .. ............................................................................ 33
Figura 10 Diagrama de actividad de la ingeniera de Requerimientos ............ 34
Figura 11 Diagrama de actividad de la Extraccin de Requerimientos ........... 35
Figura 12 Diagrama de actividad del Anlisis de Requerimientos .................. 36
Figura 13 Diagrama de pescado ..................................................................... 46
Figura 14 Metodologa DoRCU ....................................................................... 51
Figura 15 Diagrama Entidad - Relacin para el modelo del Lxico Extendico
del Lenguaje .................................................................................................... 58
Figura 16 Modelo del Lxico 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 Jerarqua de procesos de la Divisin de Atencin en Salud ........... 90
Figura 24 Jerarqua de procesos del Departamento de Promocin y Prevencin
.91
Figura 25 Jerarqua de procesos de Farmacia................................................ 92
Figura 26 Jerarqua de procesos de Almacn................................................. 93
Figura 27 Procesos Primarios y de Soporte de la Divisin de Atencin en
Salud) .............................................................................................................. 94
Figura 28 Procesos Primarios y de Soporte del Departamento de Promocin y
Prevencin)...................................................................................................... 95
Figura 29 Procesos Primarios y de Soporte de Farmacia............................... 95
Figura 30 Procesos Primarios y de Soporte de Almacn................................ 96
Figura 31 Diagrama del proceso: Gestionar atencin 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 - Facturacin y Servicio
de Enfermera .................................................................................................. 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 clnica y RIPS ............. 100
Figura 39 Diagrama del proceso:Gestionar hospitalizacin .......................... 100
Figura 40 Diagrama del proceso: Gestionar examen de laboratorio ............. 101
Figura 41 Diagrama del proceso: Gestionar personal mdico y paramdico 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 atencin ............ 103
Figura 46 Diagrama del proceso: Seguir y controlar actividades de Promocin y
Prevencin ..................................................................................................... 104
Figura 47 Diagrama del proceso: Controlar farmacias satlites.................... 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 mercancas .............................. 106
Figura 52 Diagrama Actor / Role: Gestionar atencin 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 facturacin............................... 116
Figura 59 Diagrama Actor / Role: Gestionar glosas ...................................... 116
Figura 60 Diagrama Actor / Role: Gestionar Historia clnica y RIPS ............. 117
Figura 61 Diagrama Actor / Role: Gestionar hospitalizacin ......................... 117
Figura 62 Diagrama Actor / Role: Elaborar informes..................................... 118
Figura 63 Diagrama Actor / Role: Gestionar personal mdico y paramdico 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 atencin............ 120
Figura 68 Diagrama Actor / Role: Seguir y Controlar actividades de Promocin
y Prevencin .................................................................................................. 121
Figura 69 Diagrama Actor / Role: Gestionar farmacias satlites................... 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 mercancas.............................. 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: Bacterilogo....................................... 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 Almacn ................................ 127
Figura 84 Diagrama Role / Actividad: Jefe del departamento de personal ... 127
Figura 85 Diagrama Role / Actividad: Jefe de divisin de atencin 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 promocin y prevencin ........ 129
Figura 89 Diagrama Role / Actividad: Jefe de servicios generales ............... 129
Figura 90 Diagrama Role / Actividad: Jurdico .............................................. 129
Figura 91 Diagrama Role / Actividad: Mdico ............................................... 130
Figura 92 Diagrama Role / Actividad: Odontlogo ........................................ 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 atencin 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 facturacin ............................ 148
Figura 106 Diagrama de actividad: Gestionar glosas.................................... 148
Figura 107 Diagrama de actividad: Gestionar Historia clnica y RIPS........... 148
Figura 108 Diagrama de actividad: Gestionar hospitalizacin ...................... 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
mdico
paramdico .................................................................................................... 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 atencin ......... 151
Figura 116 Diagrama de actividad: Seguir y controlar actividades de Promocin
y Prevencin .................................................................................................. 151
Figura 117 Diagrama de actividad: Gestionar farmacias satlites ................ 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 mercancas ........................... 153
Figura 122 Mtodo propuesto para la Obtencin de Requerimientos ........... 159
Figura 123 Etapas y Sub-Etapas del mtodo propuesto para la obtencin de
requerimientos ............................................................................................... 159
Figura 124 Diagrama de Casos de Uso general ........................................... 168
Figura 125 Diagrama de Casos de Uso de Almacn .................................... 169
Figura 126 Diagrama de Casos de Uso de Farmacia ................................... 170
Figura 127 Diagrama de Casos de Uso de la Divisin de Atencin en
Salud ..................................................................................................... 171
Figura 128 Diagrama de Casos de Uso del Departamento de Promocin y
Prevencin .................................................................................................... 172
Figura 129 Cadena de valor.......................................................................... 173
Figura 130 Organigrama ESE IMSALUD ...................................................... 176
Figura 131 Distribucin de IPS...................................................................... 177
Figura 132 Factores de dao o cancelacin ................................................. 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 Tcnicas y herramientas de Obtencin 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 Obtencin de
Requerimientos................................................................................................ 65
Tabla 5 Objetivos especficos 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 Lder del Proyecto ............................................................................ 144
Tabla 10 Usuarios expertos........................................................................... 144
Tabla 11 Analistas del Negocio ..................................................................... 145
Tabla 12 Anlisis de Tcnicas y Herramientas.............................................. 154
Tabla 13 Tcnicas y Herramientas seleccionadas ........................................ 157
Tabla 14 Etapa de captura de Requerimientos ............................................. 163
Tabla 15 Etapa de Anlisis de Requerimientos ............................................. 164
Tabla 16 Etapa de Especificacin de Requerimientos .................................. 165
Tabla 17 Etapa de Validacin de Requerimientos......................................... 166
Tabla 18 Matriz QFD ..................................................................................... 179
Tabla 19 Relacin entre el modelamiento del negocio y la obtencin de
requerimientos ............................................................................................... 183
Tabla 20 Factores de dao o cancelacin..................................................... 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 crticos 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. Anlisis comparativo de Metodologas utilizadas en la Obtencin de

Requerimientos.
Anexo 2. Glosario
Anexo 3. Plantillas
Anexo 4. Siglas
- 13 -
INTRODUCCION
Antes de empezar a disear 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 fcil
pues
intervienen
en
esta
labor
de
investigacin
factores
tcnicos,
administrativos, econmicos, sociales, y ambientales.
Es de vital importancia contar con informacin actual y real, la cual sea la base
para definir el alcance del sistema a realizar, por esta razn el desarrollo de un
Modelamiento del Negocio, como proyecto aparte o como parte del proyecto de
desarrollo de software, facilita la obtencin y anlisis de dicha informacin, de
esta manera el equipo de trabajo conoce la ejecucin de los procesos de la
organizacin objetivo, su cadena de valor, las fortalezas y oportunidades por
explotar, las debilidades y amenazas por corregir y mitigar, y dems datos de
inters 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
organizacin, 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 Obtencin de Requerimientos, con
esta informacin 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 Obtencin 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 informacin) 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 traduccin de los requerimientos a una

notacin clara para el diseador. En todo momento el analista se enfrenta a
problemas que van desde la definicin del alcance, dominio del problema,
estimaciones y planeacin del proyecto hasta la decisin de lo que realmente
es importante incluir en el software para considerarse exitoso, pasando por la
resolucin de conflictos y asignacin de prioridades a los requerimientos.
En este proyecto se realiz un modelo del negocio, utilizando el mtodo BMM

(Business Modeling Method), como base para las siguientes fases y etapas del
desarrollo de software, principalmente para la Obtencin de Requerimientos, la
cual se desarrolla con un mtodo propuesto, basado en las necesidades del
cliente, flexible, iterativo e incremental, en el cual se aplican ciertas tcnicas y
herramientas que facilitan la extraccin, anlisis, especificacin y validacin de
requerimientos, ajustndolos 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 Obtencin de Requerimientos constituyen
factores crticos para las dems etapas del desarrollo de proyectos software.
"La parte ms difcil de construir un sistema es precisamente saber qu

construir.
Ninguna otra parte del trabajo conceptual es tan difcil como
establecer los requerimientos tcnicos detallados, incluyendo todas las

interfaces con gente, mquinas y otros sistemas.
trabajo afecta tanto el sistema si es hecha mal.
Ninguna otra parte del

Ninguna es tan difcil de
corregir ms adelante... Entonces, la tarea ms importante que el ingeniero de

sistemas realiza para el cliente es la extraccin 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 disear 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 informacin de los procesos de la empresa cliente, se puede obtener gran
parte de las caractersticas, propiedades, forma de ejecucin y produccin, y
dems informacin relevante para la definicin del alcance y mbito de
aplicacin del sistema deseado. A partir del modelo del negocio, es posible
obtener de manera sistemtica y directa, tanto la coleccin 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 obtencin de

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

negocio se aplica un mtodo basado en principios, procesos y conceptos
tomados de la Ingeniera de mtodos, modelamiento empresarial e Ingeniera
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 construccin
iterativa del sistema y el refinamiento continuo de los requerimientos. Adems
para fortalecer la obtencin de requerimientos se hace necesario el anlisis,
seleccin y aplicacin de tcnicas 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 tecnologas de informacin y la

sistematizacin de la mayora de los procesos de las empresas requiere que se
desarrollen sistemas que suplan sus necesidades y permitan la optimizacin de
las actividades, para ello se necesita un enfoque sistemtico de desarrollo y
operacin, denominado Ingeniera del Software.
Dentro de la Ingeniera del Software la Obtencin de Requerimientos cumple
un papel primordial en el proceso de produccin de software, debido a que se
enfoca en un rea fundamental: la definicin de lo que se desea producir. Su
principal tarea consiste en la generacin de especificaciones correctas que
describan con claridad, sin ambigedades, 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
informacin necesaria para validar la claridad y realidad de los requerimientos.
En la mayora 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 situacin 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 informacin del negocio y definir una forma de
capturar
las
necesidades
del
cliente,
procurando
aplicar
tcnicas
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 slida para el desarrollo de las
siguientes fases del proyecto.
- 18 -
OBJETIVOS
OBJETIVO GENERAL
Realizar un anlisis comparativo de tcnicas de obtencin de requerimientos

para el mdulo de Facturacin del aplicativo Gestasoft Hospitalario para
IMSALUD (Institucin Municipal de Salud de San Jos de Ccuta).
OBJETIVOS ESPECIFICOS
Identificar las principales actividades de la obtencin de requerimientos.
Identificar y seleccionar las tcnicas y herramientas adecuadas para el
desarrollo de las actividades de la obtencin de requerimientos.
Desarrollar un anlisis comparativo de tcnicas y herramientas de obtencin
de requerimientos.
Aplicar en la obtencin de requerimientos las tcnicas y herramientas
previamente seleccionadas.
Extraer los requerimientos para el mdulo de Facturacin del aplicativo
Gestasoft Hospitalario.
Analizar y especificar los requerimientos identificados para el mdulo de
facturacin.
- 19 -
1. MARCO TEORICO
1.1 MODELO DEL NEGOCIO
Desde el surgimiento mismo de la computacin y a lo largo de toda su

evolucin 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 clculos que
podan definirse claramente como un conjunto de pasos que podan ser
interpretados por las mquinas 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 tcnicas y herramientas con la

experiencia de los especialistas para afrontar los nuevos retos que impone
disear sistemas eficientes y novedosos en las condiciones actuales,
sumamente cambiantes. Esta necesidad es an ms imperiosa cuando cada
individuo en una organizacin 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 descripcin del sitio donde quedar instalado el
software propuesto en la estructura de la organizacin y las actividades diarias
de la misma.
Puede tambin proporcionar la justificacin para construir el
sistema, capturando los procedimientos actuales de forma manual o

automatizada, los cuales sern cargados en un nuevo sistema, los beneficios
de costo asociados y permite que el analista rastree claramente cul 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
sern construidos realmente.
El modelo del negocio se desarrolla segn las consideraciones y necesidades

del proyecto, a continuacin se describen algunos de los posibles escenarios
de implementacin.
1.1.1 Escenarios
ESCENARIO 1 MAPA DE LA ORGANIZACIN
Se Construye un mapa de la organizacin y los procesos involucrados, para de

esta manera capturar y comprender de una forma ms rpida y sencilla los
requerimientos necesarios para la construccin del sistema. En este caso, el
modelamiento del negocio es parte del proyecto de ingeniera del software,
ejecutado principalmente en la fase inicial del desarrollo. [VILLAMIZAR, 2006].
ESCENARIO 2 MODELAMIENTO DE DOMINIO
Si se estn construyendo aplicaciones con el propsito principal de gestionar y

presentar informacin, se puede seleccionar construir un modelo de dicha
informacin a nivel de negocio, sin considerar los flujos de trabajo del negocio.
Esto se refiere al modelo de dominio. Tpicamente el modelo de dominio es
parte del proyecto de ingeniera 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 aplicacin que podra ser usada por varias
organizaciones por ejemplo, aplicacin de soporte de ventas o de facturacinpuede ser til realizar un esfuerzo de modelamiento del negocio para alinear
las organizaciones evitando requerimientos demasiado complejos (mejora del
negocio).
Si la alineacin de las organizaciones no es una opcin, 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 organizacin ha decidido comenzar una nueva lnea de negocios y

construir sistemas de informacin para soportarlos, se requiere un buen
modelado del negocio.
En este caso, el propsito del modelamiento del
negocio no es nicamente encontrar los requerimientos del sistema, sino

tambin determinar la viabilidad de la nueva lnea de negocios, de esta manera
el modelo del negocio es tratado como un proyecto en propiedad.
[VILLAMIZAR, 2006]
ESCENARIO 6 RENOVACION (MEJORA)
En la reingeniera de negocios, el modelamiento del negocio puede ser uno o

varios proyectos en propiedad. Tpicamente, la reingeniera de negocios es
realizada en varias etapas: previsin del nuevo negocio, ingeniera inversa del
negocio existente, ingeniera avanzada del nuevo negocio e instalacin del
nuevo negocio. [VILLAMIZAR, 2006].
- 22 -
1.1.2 Mtodo de Modelamiento del Negocio BMM.

[BARRIOS et all, 2003]
Proceso de Post Desarrollo

Modelo del
Negocio
Entrega de la
Aplicacin
Prueba de la
Aplicacin
Definicin y
Especificacin de
Requerimientos
Diseo de la
Arquitectura
Proceso
Directivo
Ensamble de
Componentes
Especificacin de
Componentes
Aprovisionamiento de
Componentes
Figura 1. Ubicacin del Mtodo BMM en un modelo de procesos de Sistemas de

Informacin y Desarrollo de Software
El modelamiento del negocio es realizado entre la Planificacin del Proyecto, la

cual es una de las actividades iniciales de la gestin de procesos, y la fase de
Definicin y Especificacin de Requerimientos. (Ver figura 1).
El BMM fue diseado basndose en principios, procesos y conceptos tomados

de la Ingeniera de mtodos, modelamiento empresarial y la Ingeniera del
software orientada a objetos.
Una prctica comn de este mtodo es estructurar un proyecto en 3

componentes:
- 23 -
1. Modelo del Producto Describe la estructura general, caractersticas

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 dinmica 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 estn

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

cuales describen en forma ms detallada los conceptos genricos 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: Visin, Misin y Objetivos.
1.1.2.1.2 Procesos del Negocio
Para alcanzar las metas de un sistema del negocio se debe disear, organizar
y realizar un conjunto de actividades llamadas procesos del negocio.
procesos del negocio estn constituidos por
actividades estructuradas y
diseadas jerrquicamente para alcanzar las metas del negocio.
- 24 -
Los
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 categoras asociadas a

la cadena de valor de una empresa. Los procesos del negocio deben ser
modelados como una jerarqua de procesos y actividades en diversos niveles
de abstraccin.
1.1.2.1.3 Actores, Unidades y Estructura del Negocio
Los actores pueden clasificarse en internos y externos segn el alcance del

sistema del negocio, por medio de ellos se pueden identificar los roles que
intervienen en el sistema del negocio.
Responsable
Rol
Hacen parte
Tarea
s
Proceso
del
negocio
Ejecuta
Actor
Es
asignado
Unidad de Negocio
Figura 2. Diagrama de relacin 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 mquina y estn definidos por tareas o acciones. Las tareas
son asignadas a actores humanos, ellas representan las unidades mnimas de
trabajo. Las acciones se les atribuyen a los actores automticos (componente
de software, aplicacin, 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
Estn organizadas en una estructura jerrquica, la cual representa, segn las

lneas de autoridad que gobiernan, las relaciones entre las unidades del
negocio.
1.1.2.1.4 Tecnologas
Los procesos del negocio utilizan tecnologas para realizar sus actividades ms
eficiente y efectivamente.
1.1.2.1.5 Reglas del negocio
Los procesos del negocio son delimitados por las tecnologas 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 polticas, planes y estndares
establecidos en la empresa a nivel interno.
Las reglas pueden ser compuestas por otras reglas formando una jerarqua, las
del nivel inferior son expresadas en trminos de condiciones y acciones.
1.1.2.1.6 Objetos del negocio
La ejecucin 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

accin de corta duracin que ocurre dentro o fuera del sistema del negocio, es
una seal 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 ms 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
cumpleaos, entre otros.
1.1.2.2. Modelo del equipo
Definir los roles de los miembros del equipo es una tarea importante para la
aplicacin del modelo de procesos, debido a que le facilita al lder del equipo la
seleccin de las personas y la asignacin de las actividades apropiadas.
Organizacin del equipo:
Lder 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 ejecucin del proceso de modelamiento: El proceso de modelado

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

un entregable, esto es, un submodelo o componente del modelo del negocio.
La produccin de un entregable en cada uno de los pasos intermedios es
verificado por el equipo antes de avanzar al siguiente paso.
El paso de verificacin y validacin 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 versin, la cual debe ser validada por el gestor del sistema del
negocio para posteriormente iniciar otro ciclo o concluir el proceso de
modelado.
- 28 -
Planificacin del
proyecto
Especificacin y definicin
de requerimientos
Definicin del sistema
del negocio
Entrega del modelo

del negocio
Modelado de
actores
Modelado de metas
Modelado de reglas
y tecnologas
Verificacin y
validacin
Modelado de
eventos
Modelado de procesos
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 identificacin de requisitos. La definicin 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 tcnica estandarizada y

estructurada que ofrezca un marco de desarrollo que garantice la calidad del
resultado. Existe en cambio un conjunto de tcnicas, cuyo uso proponen las
diferentes metodologas para el desarrollo de aplicaciones. Se debe tener en
cuenta que la seleccin de las tcnicas y el xito de los resultados que se
obtengan, depende en gran medida tanto del equipo de anlisis y desarrollo,
como de los propios clientes o usuarios que en ella participen.
Una posible visin de la ingeniera de requerimientos es considerarla como un

proceso de construccin de una especificacin 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 visin de la ingeniera de requerimientos [POHL, 1994]
La Ingeniera de Requerimientos se ocupa de los aspectos de la Ingeniera de

Software, relacionados con la comprensin y produccin de descripciones de
problemas para resolverlos a travs de la construccin de Sistemas de
Software. Los fundamentos del sistema (el por qu) estn abarcados por los
objetivos de la organizacin, 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,

anlisis, especificacin y validacin, estas actividades difieren segn el autor
que lo plantee, a continuacin se presentan algunas representaciones grficas
sobre el proceso de la Ingeniera de Requerimientos.
1.2.1 Proceso de la Ingeniera de Requerimientos
Figura 5. Proceso de la Ingeniera de requerimientos [LOCOPOULOS et all, 1995]
Figura 6. Proceso de la Ingeniera de requerimientos [KOTONYA et all, 1997]

- 31 -
Figura 7. Proceso de la Ingeniera de requerimientos [KOTONYA et all, 1997], un modelo

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

1997]
El proceso comienza con la realizacin de la captura de requisitos, el grupo de

tcnicos toma la informacin suministrada por los usuarios y clientes. Esta
informacin puede provenir de fuentes muy diversas: documentos, aplicaciones
existentes, a travs de entrevistas, etc. En base a esta informacin, el equipo
de desarrollo elabora la documentacin de los requisitos. Finalmente con la
validacin de requisitos se realiza la valoracin de los mismos, comprobando si
existen inconsistencias, errores o si faltan requisitos por definir. El proceso de
definicin-validacin es iterativo y en algunos proyectos complejos resulta
necesario ejecutarlo varias veces.
- 33 -

ad Ingenieria de requerimientos
Input
Actividad
Captura de
Requerimientos
Informacin
Actividad
Definicin de
Requerimientos
Actividad
Validacin de
Requisitos
Output
Documentacin de
Requerimientos
Input
Correcciones
Figura 10. Diagrama de actividad de la Ingeniera de Requerimientos
1.2.1.1 Extraccin, Captura o Elicitacin de Requerimientos
Extraccin es el nombre comnmente 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 fcil: muchas veces los clientes/usuarios no tienen una
idea clara de sus necesidades reales, diversas personas dentro de la
organizacin tienen necesidades encontradas, pueden existir limitaciones
tcnicas o tecnolgicas para cumplir con algunos requerimientos, etc. Pero, en
definitiva, descubrir los requerimientos del sistema no slo implica preguntar a
- 34 -
las personas qu quieren: es un proceso delicado que involucra comprender el

domino de aplicacin, 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 cmo es que este sistema interactuar, afectar a las partes del
negocio que estarn involucradas y cmo puede contribuir a lograr las metas
de la empresa.
Es importante, que la extraccin sea efectiva, ya que la aceptacin del sistema

depender de la satisfaccin de las necesidades del cliente y de la
sistematizacin del trabajo. [DAVILA, 2006].
Figura 11. Diagrama de actividad de la Extraccin de Requerimientos
- 35 -
1.2.1.2 Anlisis
Sobre la base de la extraccin 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 anlisis luego de
haber producido un bosquejo inicial del documento de requerimientos; aqu se

leen los requerimientos, se conceptan, 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 Anlisis
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 abstraccin
sub-actividad
Identificar si el requerimiento es
necesario o representa una caracterstica
aadida
Actividad
Realizar un anlisis inicial
de los requerimientos
obtenidos en la etapa
anterior
sub-actividad
Analizar si cada requerimiento est
delimitado y sin ambigedad
sub-actividad
Analizar si existe un origen conocido para
cada requerimiento
Actividad
Agrupar los
requerimientos por
categoras y organizarlos
en subconj untos
Actividad
Estudiar cada
requerimiento con
respecto al resto nde
requerimientos
sub-actividad
Identificar si existen incompatibilidades
entre requrimientos
sub-actividad
Analizar si se puede probar el
requerimiento una v ez implementado
Actividad
Examinar los
requerimientos en su
consistencia, completitud
y ambigedad
Actividad
Clasificacin final de los
requerimientos segn las
necesidades de los
usuarios
Figura 12. Diagrama de actividad del Anlisis de Requerimientos

- 36 -
1.2.1.3 Especificacin
En esta fase se documentan los requerimientos acordados con el cliente, en un
nivel apropiado de detalle.
Una especificacin puede ser un documento escrito, un modelo grfico, un

modelo matemtico formal, una coleccin de escenarios de uso, un prototipo o
una combinacin de lo anteriormente citado.
En la prctica, esta etapa se va realizando al mismo tiempo que el anlisis,

pero se podra decir que la Especificacin es el "pasar en limpio" el anlisis
realizado previamente aplicando tcnicas y/o estndares de documentacin,
como la notacin UML. [DAVILA, 2006]
1.2.1.4 Validacin
La validacin es la etapa final de la Ingeniera de Requerimientos. Su objetivo
es analizar todos los requerimientos que aparecen en el documento, para
asegurarse que representan una descripcin, por lo menos, aceptable del
sistema que se debe implementar.
Esto implica corroborar que los
requerimientos sean consistentes, estn completos y que el resultado del

trabajo se ajuste a los estndares establecidos para el proceso, el proyecto y el
producto.
Se prefiere que el documento de requerimientos obtenido en la etapa anterior

slo debe incluir los requerimientos que son aceptables para los usuarios.
Pero es inevitable que durante la validacin 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 Tcnicas de Obtencin de Requerimientos
Herramienta Instrumento.
Por ejemplo, un cronograma informal de
entrevistas o un cuestionario son herramientas para recopilar informacin. Una

herramienta se puede aplicar mediante distintos mtodos o tcnicas.
Tcnica La tcnica 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 tecnologa o en otra actividad.
Nombre
Entrevistas
Cuestionarios
Sistemas existentes
Grabaciones de video
y de audio
Brainstorming
(Tormenta de ideas)
Arqueologa
de
documentos
Aprendiz
Observacin
Run
Use
Case
Workshop (talleres)
Prototipo bosquejado
Prototipo tangible /
Usable
DOFA
Cadena de valor
Modelo
de
clase
conceptual
Diagrama de pescado
Glosario
DCO
Diagrama de actividad
ESRE
Casos de uso
Casa de calidad o
QSD
Checklist
Clasificacin
Tcnica
Herramienta
Tcnica
Herramienta
Extraccin
Anlisis
X
X
X
X
X
X
Herramienta
Herramienta
Tcnica
Tcnica
Herramienta
X
X
X
Herramienta
Herramienta
X
X
Herramienta
Herramienta
Herramienta
Herramienta
Herramienta
Tcnica
Herramienta
Tcnica
Herramienta
Herramienta
X
X
Herramienta
X
X
Especificacin
Validacin
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Tabla 1. Tcnicas y herramientas de Obtencin de Requerimientos
- 38 -
X
X
X
X
1.2.2.1 Entrevistas y cuestionarios
Las entrevistas son la tcnica de captura ms utilizada, y de hecho son

prcticamente inevitables en cualquier desarrollo debido a que es una de las
formas de comunicacin ms naturales entre personas. En las entrevistas se
pueden identificar tres fases: Preparacin, realizacin y anlisis.
Preparacin 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 planificacin (fecha, hora, lugar, duracin).
Realizacin Est fase a su vez se divide en tres actividades, como son:

Apertura (presentacin del entrevistador, objetivos, como se va a utilizar la
informacin, mecnica de las preguntas, explicar, si se va a utilizar, alguna
notacin grfica o matemtica), Desarrollo (la duracin de la entrevista no debe
ser mayor a 2 horas, aplicacin de los diferentes tipos de preguntas y anotar,
grabar o filmar las respuestas del entrevistado) y Finalizacin (recapitular para
confirmar que no ha habido confusiones en la informacin recogida).
Anlisis Una vez finalizada la entrevista es necesario leer las notas tomadas,
pasarlas a limpio, reorganizar la informacin, contrastarla con otras fuentes.
Una vez organizada la informacin se puede enviar al entrevistado para
confirmar los contenidos. [KOMER, 1993].
1.2.2.2 Sistemas existentes
Esta tcnica consiste en analizar distintos sistemas ya desarrollados que estn

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

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

comunicar.
Otra ventaja que presenta esta tcnica es que como estos sistemas ya estn
en produccin, 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 funcin de apoyo, es importante por cuanto permite centrar la

atencin en la entrevista en s en vez de distraerse tomando notas de todo lo
que se dice. Cuando se est grabando la conversacin, basta con "puntear" en
una libreta los temas tratados para despus tener una gua bsica de los temas
tratados y saber en qu lugar de la grabacin buscar.
Adems, permite
analizar los temas con ms detenimiento y con una visin ms global, pues ya
se ha conversado sobre todos los puntos necesarios.
Cuando se trata de analizar algn 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.
Adems 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 tcnica de reuniones en grupo cuyo objetivo es la generacin de ideas

en un ambiente libre de crticas o juicios. Las sesiones de brainstorming suelen
estar formadas por un nmero de 4 a 10 participantes, uno de los cuales es el
jefe de la sesin. 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 todava muy difusos. [DAVILA, 2006]
- 40 -
1.2.2.5 Arqueologa de documentos
Con la aplicacin de esta herramienta se tratan de determinar posibles

requerimientos sobre la base de inspeccionar la documentacin utilizada por la
empresa; por ejemplo, boletas, facturas, remitos, etc.
Esta herramienta sirve como complemento de las dems tcnicas, y nos ayuda
a obtener informacin que de otra manera sera sumamente difcil conseguir.
[DAVILA, 2006].
Para el anlisis de cada uno de estos documentos, se deben realizar algunas

preguntas, como:
Cul es el propsito de este documento?

Quin lo usa? Por qu? Para qu?
Cules son las tareas que realizan con este documento?
Se puede encontrar una relacin entre los documentos?
Cul es el proceso que realiza la conexin?
Cul es el documento que da ms problemas a los usuarios?
1.2.2.6 Aprendiz
Esta tcnica 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 observacin.

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 tambin puede bosquejar como se
conectan por medio de los distintos flujos de datos.
- 41 -
Su aplicacin es muy til, ya que a veces es difcil para el cliente/usuario el

explicar cmo 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 Observacin
Observar como se hacen las cosas es una buena manera de entender lo que
estas requieren. Conectarse ntimamente con la cultura de la organizacin,
vivirla, es una tcnica que debe ser tomada en cuenta.
Dentro de la estrategia de observacin 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 informacin 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 extraccin de requerimientos, puede ocurrir que

algunos de ellos no estn claros o que el equipo de anlisis 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 retroalimentacin en
cuanto a si el sistema diseado 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, slo se podrn 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 ms 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 dilogo hombre-mquina,
sobre todo si existe un requerimiento no funcional como el de usabilidad.
- 43 -
C - Prototipo Tangible/usable
Los trminos tangible y usable se refieren a desarrollar una aplicacin

(software) que el usuario pueda utilizar, es decir, con la cual pueda interactuar
como si fuera la aplicacin 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 tambin resulta de suma utilidad cuando se ha
planteado un requerimiento no funcional de usabilidad.
Entre las desventajas ms importantes de los prototipos, se encuentran:

Costo de entrenamiento/capacitacin en la herramienta
Costo de realizar el prototipo.
Problema de calendario.
Incompletitud (puede confundir a los usuarios, hacindolos pensar que el
producto final quedar como el prototipo, incompleto).
[KOTONYA et all, 1997]
1.2.2.10 DOFA
Con
este
anlisis
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 sealan ciertas estrategias cuya aplicacin podra
- 44 -
conducir al xito, mientras que las debilidades sealan aquello que la empresa
debe corregir. [KOMER, 1993]
1.2.2.11 Cadena de valor
Todas las empresas son una coleccin de actividades que se llevan a cabo
para disear, producir, distribuir, entregar y apoyar a su producto. La cadena
de valor divide las empresas en actividades estratgicas a fin de comprender el
comportamiento de los costos en determinado negocio o industria y en las
fuentes de diferenciacin presentes y futuras.
En este anlisis 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 representacin de conceptos del dominio del

problema.
Permite mostrar conceptos, asociaciones entre conceptos y
atributos de conceptos. La creacin del modelo tambin ayuda a comprender

la terminologa del dominio y comunica cules son los trminos importantes y
las relaciones existentes entre ellos.
Concepto: categora de idea o cosas.
La intencin del concepto es la
descripcin de sus atributos, operaciones y significado.

Para representar un concepto se puede emplear la metodologa 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 cmo funciona el
negocio (relaciones entre las clases/concepto), y capturar vocabulario y
- 45 -
conceptos (clase).
Tambin 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 cmo impacta la solucin planteada

para un requerimiento dado. Por ejemplo, cmo afecta al trabajo diario del
empleado.
otros
Tambin en el caso de que la solucin planteada interacte con
sistemas
existentes (modificando, consultando o
intercambiando
informacin) 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 trminos en donde se explica su significado.

En esta lista se incluyen y definen todos los trminos que requieren explicacin,
- 46 -
mejorando as la comunicacin intergrupal y la comunicacin con el cliente, y

mitigando el riesgo de malos entendidos.
Los trminos que se incluyen provienen de todas las reas del proyecto: casos
de uso, terminologa 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 relacin con el ambiente.
Los puntos tratados en el documento bsicamente son:
Anlisis del entorno, descripcin general, organigrama de la empresa,
misin/visin, polticas de desarrollo, de servicios, comercial, de personal, de
direccin, 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 (condicin de guarda), para luego pasar a la siguiente actividad o
estado (transicin). Este modelo tambin permite representar actividades que
ocurren en paralelo, o aquellos casos en los que una nica actividad
desencadena ms de una tarea (divisin de control), o cuando se unen dos o
ms actividades para formar una tercera (unin de control). [DAVILA, 2006]
1.2.2.17 Documento ESRE / Casos de Uso
El objetivo del documento ESRE (Documento de ESpecificacin 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
categoras, los no-funcionales y los funcionales.
Lista de requerimientos
La lista de requerimientos forma parte del documento de especificacin 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 diseada para especificar el comportamiento de
un sistema.
Este documento describe la posible secuencia de interacciones entre el

sistema y uno o ms actores, en respuesta a un estmulo inicial proveniente de
un actor. Constituye una descripcin 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 "cmo", es
decir, cmo 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

anlisis.
Las checklist son tiles porque brindan un recordatorio de lo que se debe

buscar y reducen las oportunidades de pasar por alto alguna verificacin
importante. Tambin se puede aplicar con los casos de uso. [DAVILA, 2006]
1.3 METODOLOGAS DE OBTENCIN DE REQUERIMIENTOS
1.3.1 Metodologa DoRCU
"La esencia de una metodologa -en forma opuesta a lo que ocurre en un

mtodo o tcnica- es que ofrece un conjunto de pautas o principios que en
cualquier instancia especfica pueden ser ajustadas tanto a las caractersticas
de la situacin en la cual debe ser aplicada como a las personas que usan el
enfoque. Es tal la variedad de situaciones problemticas humanas que no
habr ningn enfoque para solucin de problemas que pueda ser reducido a
una frmula estndar y manejar an toda la riqueza de las situaciones en
particular". (Diferencia entre mtodo y metodologa [CHECKLAND, 1989]).
Metodologa DoRCU
La metodologa DoRCU (Documentacin de Requerimientos Centrada en el

Usuario), consta de las siguientes etapas:
Captura de requerimientos
Anlisis de Requerimientos
- 49 -
Especificacin de Requerimientos
Validacin y Certificacin 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.
Anlisis de Requerimientos.
En esta etapa se estudian los requerimientos extrados 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 trminos
puede, en ms 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 tcnico.
Especificacin de Requerimientos
Partiendo de lo elaborado en la etapa anterior tales como funciones, datos,
requerimientos
no
funcionales,
objetivos,
restricciones
de
diseo/implementacin o costos, e independientemente de la forma en que se

realice, esta etapa es un proceso de descripcin del requerimiento.
Si se
presentan dificultades para especificar un requerimiento se debe volver a la

etapa anterior que se crea conveniente.
Validacin y Certificacin de los Requerimientos.

Esta etapa final se nutre de las anteriores y realiza la integracin y validacin
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 mnimo, existen dos que son isomrficos entre s: uno
destinado al cliente/usuario a los efectos de la certificacin de los Requisitos y
- 50 -
el otro tcnico, orientado a nutrir las restantes etapas de la Ingeniera de

Software; y, al igual que en el caso anterior, su resultado puede ser la
necesidad de retornar a la especificacin e incluso a la captura; iterando entre
etapas y sin perder contacto con el cliente/usuario.
Por consiguiente, la representacin grfica de la propuesta metodolgica que

se hace para la Ingeniera de Requerimientos es la que se puede ver en la
figura 14. [BAEZ et all, 2006].
Figura 14. Metodologa DoRCU
Considerando el tronco metodolgico planteado anteriormente, se detallan a

continuacin sus correspondientes subetapas.
A. Captura de Requerimientos.
- Formar el equipo multidisciplinario:

La recoleccin de requerimientos se debe efectuar con el asesoramiento de
profesionales especializados.
- Buscar hechos:
Declaracin del contexto del problema, de los objetivos globales, lmites 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
requerimientos
son
verificadas
comparndolas 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 valoracin del riesgo, para encaminar las inquietudes
tcnicas, de costos y de tiempo.
informacin
reunida
en
Debe examinarse la coherencia en la
subetapas
previas,
para
determinar
si
los
requerimientos verdaderos estn escondidos o expresados explcitamente.
- Dar prioridad:
En esta etapa, contando ya con requerimientos consistentes, se da un orden de
prioridades, esto permite una disminucin de los costos y ahorro de tiempo en
procesamiento de los inevitables cambios de los requerimientos.
Los requerimientos deben tener prioridades basndose 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 trminos del lenguaje del UdI, y la de sentencias de
los requerimientos obtenidos (DE).
- 52 -
B. Anlisis de Requerimientos
- Reducir ambigedades en los requerimientos:

En esta subetapa se realizan las tareas que permiten eliminar los trminos que
tienen ms de una acepcin (significado).
- Traducir a lenguaje tcnico los requerimientos:

Los requerimientos, ya con menos ambigedades, deben ser tratados a los
efectos de llevarlos a un lenguaje que se vaya aproximando al lenguaje tcnico.
Mediante esta traduccin se busca aproximar los trminos del usuario a los
trminos del sistema de software.
- Plantear un modelo lgico:

En la presente subetapa se debe construir un modelo del problema ya sea en
trminos de diagramas de flujo o cualquier otro tipo de representacin que se
considere conveniente para el modelado y que permita, adems, establecer un
vnculo con la Etapa de Especificacin.
Este documento, dado el caso, puede resumirse a la coleccin de los modelos
lgicos a que se ha arribado (DA)
C. Especificacin de Requerimientos
- Determinar el tipo de requerimiento:

Considerando que existen diferentes tipos de requerimientos, determinar
unvocamente a cual de ellos pertenece el que se est tratando.
- Elegir la herramienta de especificacin acorde al tipo de requerimiento:

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

Representar el requerimiento sobre la base de la eleccin realizada en la etapa
anterior.
Confeccionar el documento representativo de la etapa, incorporando al mismo
toda extensin que se considere de utilidad para la etapa de Validacin y
Certificacin de Requerimientos (DP).
D. Validacin y Certificacin de los Requerimientos
- Seleccionar las fuentes de informacin entre DE y DA a los fines de validar el

DP: En esta etapa se procede a validar el documento de especificacin DP a
partir de los documentos obtenidos de las etapas de captura (DE) y anlisis
(DA), seleccionando como fuente de informacin aquellos materiales que ms
aportan.
El documento de especificacin (DP) validado se llamar, en
adelante, documento de requerimientos tcnico (DRT).
- Elegir o disear el modelo de documento acorde al grado de detalle requerido

y al lector final.
- Elegir la herramienta de documentacin 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 estndares vigentes a la fecha de realizacin del

documento de requerimientos: Elaborar el documento de requerimientos
orientado al usuario (DRU) a partir del documento de requerimientos tcnico
(DRT).
- 54 -
- Verificar que el documento de requerimientos del usuario DRU sea isomrfico

con el documento tcnico DRT.
- Certificar el documento de requerimientos DRU a travs del conforme del

usuario: Proceder a la aprobacin del DRU por medio del conforme del cliente,
y de esta manera dar por aprobado el Documento de Requerimientos Tcnico
DRT, el que ser utilizado por las restantes etapas de la Ingeniera de
Software.
1.3.2 Goal-Based Requirements Analysis Method
Goal-Based Requirements Analysis Method (GBRAM) provee mecanismos de

representacin adecuados para la comprensin de los stakeholders, facilita la
comunicacin de los stakeholders con los analistas a travs de un lenguaje
entendible, y produce requerimientos relativamente fciles de validar. Como
mtodo basado en Objetivos, se concentra en establecer los fundamentos que
justifican los requerimientos de software.
El propsito de GBRAM es desarrollar, validar y afirmar un mtodo basado en
metas u objetivos, otorgando soporte procedural para la identificacin,
elaboracin, refinamiento, y organizacin de objetivos, en la especificacin de
Sistemas de Informacin basados en Software. En este enfoque los objetivos
se describen mediante un esquema particular de componentes (ver Tabla 2).
[THOMAS, 2006].
Componente
Nombre de Meta
Tipo
Descripcin
Accin
Descripcin
Es el identificador nico para cada
Objetivo.
Las metas son clasificadas de
acuerdo al comportamiento
requerido: obtener algn estado
(Achievement) o mantener alguna
condicin o estado (Maintenance).
Es un texto informal que describe
una meta u objetivo.
Es el nombre que se le otorga a la
operacionalizacin de una meta.
Representa el comportamiento
- 55 -

necesario para satisfacer el objetivo.
Agente
Es el responsable de completar o
cumplir un objetivo.
Son las personas interesadas en
que una meta u objetivo sea
cumplido.
Limitaciones bajo las cuales un
objetivo debe cumplirse. Una
restriccin especifica algn
requerimiento o condicin que debe
cumplirse para lograr un objetivo.
Circunstancias que puedan impedir
que un objetivo sea cumplido.
Condicin que debe existir para
posibilitar el logro de un objetivo.
Condicin a la que se arriba luego
de obtener o completar un objetivo.
Cada sub-meta debe mapear a una
accin. Si mapea a varias acciones,
debera ser descompuesta y
refinada.
Stakeholders
Restricciones
Obstculos
Precondiciones
Post-condiciones
Sub-Metas
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 especfico de la aplicacin. Los Escenarios
no son formales, y se los puede representar con una variedad de recursos.
Si bien cada Escenario es una descripcin parcial del comportamiento de la

aplicacin, ninguno es independiente del resto y cada uno tiene una relacin
semntica con los otros. En la siguiente tabla se reproduce el esquema de
representacin del enfoque de escenarios elegido.
- 56 -

Componente
Nombre
Objetivo
Contexto
Recursos
Actores
Set de episodios
Casos alternativos
Descripcin
Identifica al escenario
Establece la finalidad del escenario
Describe las acciones previas
necesarias para iniciar el escenario,
las precondiciones, la ubicacin
fsica y temporal.
Identifican los objetos pasivos con
los cuales los actores trabajan
Detalla las entidades que se
involucran activamente en el
escenario
Cada episodio representa una
accin realizada por un actor, donde
participan otros actores y se utilizan
recursos. Los episodios se ejecutan
secuencialmente. Un episodio
tambin puede referenciar a un
escenario. Se incluyen restricciones
del escenario o episodio segn
corresponda
Menciona los casos de excepcin,
que pueden corresponder a otros
escenarios
Tabla 3. Esquema de escenario de Leite
El Objetivo del Escenario es parte de la descripcin del Objetivo con formato

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

[GIL, 2006]
El Lxico Extendido del Lenguaje (LEL) es un conjunto de trminos

provenientes del lenguaje de la aplicacin, donde se identifica la semntica de
cada trmino, 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 smbolos que identifican el lenguaje

de la aplicacin. Los smbolos son, en general, las palabras o frases utilizadas
- 57 -
por el usuario y que repite con ms frecuencia. Tambin se incluyen aquellas

palabras o frases que son relevantes para el dominio del problema ms all de
su frecuencia de repeticin. Los smbolos se obtienen por ejemplo, mediante
entrevistas, observaciones directas e indirectas y lectura de documentos. Se
genera una lista con todos los smbolos reconocidos. Durante el proceso de
recoleccin, el ingeniero de software procura entender el significado de cada
smbolo.
La semntica de cada smbolo se representa con una o ms nociones y uno o

ms impactos.
El impacto puede no existir.
La nocin indica qu es el
smbolo y el impacto cmo repercute en el sistema. Ambos atributos se

formulan desde el punto de vista de la aplicacin. Por lo tanto, cada smbolo
tiene un nombre que lo identifica, una nocin y un impacto que lo
describen. El conjunto de smbolos 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-Relacin para el modelo del Lxico Extendido del Lenguaje
A continuacin se presenta el modelo utilizado para representar los smbolos

del LEL:
- 58 -
Figura 16. Modelo del Lxico Extendido del Lenguaje
Donde:
Sentencia est compuesto por Smbolos y No-Smbolos pertenecientes al
vocabulario mnimo, + significa composicin, {x} significa cero o ms
ocurrencias de x, ( ) es usado para agrupamiento, | significa or, y [x] significa
que x es opcional.
El proceso de construccin consta de 6 etapas dependientes entre s, y que, en

algunos casos, se desarrollan en forma simultnea.
Identificar las fuentes de informacin.
Identificar los smbolos.
Clasificar los smbolos.
Describir los smbolos.
Verificar el LEL.
- 59 -
Validar el LEL con los clientes-usuarios.
1.3.3 SSM Soft System Methodology.

[SUMANO, 2006]
Metodologa desarrollada en Inglaterra por Peter Chekland en la dcada de los

1970, cuyo enfoque orientado a la meta se ha venido perfeccionando
paulatinamente basndose en el Pensamiento de Sistemas y aceptando una
enorme influencia de las ciencias sociales.
Aunque la notacin es variada y flexible se hace hincapi en el uso de grficas

para lograr una rica imagen (rich picture) de situaciones. Entre los grficos
propuestos (sin limitarse a ellos) estn los que se muestran en la Figura 17 y
tienen el significado siguiente:
Una actividad determinada es una accin 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 repercutirn en un
grupo de personas y podrn 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 Anlisis de la situacin 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 situacin del problema. El propsito es identificar quienes

estn involucrados, cul es su percepcin de la situacin, cules son las
estructuras organizacionales y qu procesos se llevan a cabo.
Expresar la situacin. Se recomienda que se haga grficamente, 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
situacin actual.
Hacer la seleccin de como ver paulatinamente la situacin de manera que

se pueda producir percepciones que den pi a definiciones raz.
Lo
esencial en este punto es producir varias imgenes ricas en detalles de

cada punto de vista diferente o subsistemas.
relevante tendr su definicin raz.
As, cada punto de vista
Cada definicin raz en SSM es
construida para posteriormente determinar su relevancia en el sistema a

- 61 -
desarrollar.
Para determinar si la definicin raz est bien escrita debe
contener los elementos de la gua CATWOE mnemnico correspondiente a

las siglas que se explican en seguida:
o C (Customer). Se trata de la persona que ser beneficiara o vctima
del sistema.
o A (Actors).
Los actores, que llevarn 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 definicin raz; de tal manera que hay una
gran iteracin entre las actividades 3 y 4.
Comparar los modelos conceptuales con el mundo real.
Se hace una
comparacin 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 Cmo se realiza?
o Cmo 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 sistemticamente deseables.
Esto se
determina a travs de reuniones conjuntas con la gente involucrada para

recoger los diferentes puntos de vista y analizar la situacin actual.
Recomendaciones para la toma de acciones que mejoren la percepcin

problema.
- 62 -
1.3.4 Color-X.
Es una herramienta automtica y una metodologa basada en la lingstica

computacional y el anlisis orientado a objetos. Comprende varias etapas de la
Ingeniera de Requerimientos: especificacin, validacin y verificacin de
requerimientos. COLOR-X es un acrnimo de Conceptual Linguistically based
Object oriented Representation language for information and communication
systems, ms una X que agrega el autor J.F.M. Burg. La metodologa 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 automticos o semiautomticos, es decir, son en lnea con el
usuario. Se parte del hecho de que ya existe al menos una primera redaccin
de los requerimientos del sistema.
Figura 19. Forma de trabajar con COLOR-X.
Cada fase est representada en la Figura 19 por un crculo, 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 validacin y la verificacin.
Los usuarios pueden dar
informacin adicional en cualquier momento. [SUMANO, 2006]

1.3.5 Rare-Idiom.
Esta metodologa presenta el enfoque de reuso, el cual ha tomado fuerza en la

ltima dcada. Se basa en las propiedades estructurales de los documentos
de requerimientos y los procesos realizados para su produccin.
La
metodologa propone varias formas de reusar los requerimientos y sus

artefactos asociados, todo descrito en trminos 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 acrnimo 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.
Adems propone un nuevo ciclo de vida de Ingeniera de Requerimientos que

introduce el reuso y que quedara como se muestra en la Tabla 4. En la fase
tres de la Tabla 4 se propone la aplicacin de varios tipos de tcnicas:
- 64 -
analticas, de procesos y por productos. Para la Generacin y Evaluacin de

Alternativas RARE-IDIOM propone los siguientes pasos:
Clasificar los requerimientos y artefactos reutilizables del sistema actual en

trminos precisos para que tal clasificacin pueda ser usada al compararlos
con los artefactos reutilizables anteriores.
Precisar la bsqueda de artefactos candidatos mediante la seleccin de

categoras de requerimientos en trminos del dominio del problema, tipos
de requerimientos y su semntica.
Reducir el alcance de la bsqueda de artefactos al seleccionar categoras

de artefactos en trminos de la solucin del problema.
Comparar el texto de la descripcin del problema contra la coleccin

estructurada de artefactos reusables, aspecto por aspecto.
Comparar los beneficios y daos de seleccionar cada artefacto candidato

para refinar un enunciado de requerimiento actual.
Seleccionar la variante que mejor empate con el requerimiento actual.
Continuar
seleccionando
categoras
de
requerimientos
alternativas
mediante la generalizacin 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 obtencin de requerimientos.
- 65 -
1.3.6 RUP (Rational Unified Process)
Una disciplina es una coleccin de actividades relacionadas, las cuales se unen

a un rea mayor dentro del total del proyecto. La agrupacin de actividades en
disciplinas es principalmente una ayuda para comprender el proyecto de una
forma tradicional. La obtencin de requerimientos es una de las disciplinas
consideradas en el RUP.
El flujo de trabajo de la obtencin de requerimientos se muestra a continuacin:
Figura 21. Flujo de trabajo de la disciplina de Requerimientos.
Anlisis del problema
El propsito del flujo de trabajo de detalle es acordar la magnitud del problema

y la forma de resolverlo.
El anlisis del problema incluye identificar los
stakeholders, definir el lmite, e identificar las restricciones que debe tener el
- 66 -
sistema. El primer paso en el anlisis del problema es asegurarse de que

todas las partes involucradas estn de acuerdo en cual es el problema y las
necesidades por resolver con el sistema.
Comprender las necesidades de los stakeholders
El propsito de este flujo de trabajo detallado es comprender las necesidades

de los stakeholders para recopilar la informacin sobre el producto deseado o
considerado.
Definir el sistema
El propsito de este flujo de trabajo es definir el alcance y los requerimientos de

alto nivel para de esta manera detallar los requerimientos del sistema.
Gestin del alcance del sistema
Su propsito es hacer que el alcance del sistema sea lo ms explcito posible y

enfocarse en la gestin del cuerpo de requerimientos de trabajo de la iteracin.
Refinar la especificacin del sistema (SRS)

La especificacin de requerimientos software (SRS) captura los requerimientos
para todo el sistema, o una porcin de este.
Gestin de cambios de requerimientos
El propsito 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, visin, requerimientos de los stakeholders,

especificaciones suplementarias, plan de gestin de requerimientos, atributos
de requerimientos, Modelo de casos de uso, Casos de uso y glosario, plan de
iteracin, plan de desarrollo del software, cambios en los requerimientos
(aprobados) y un storyboard (descripcin lgica y conceptual de la
funcionalidad del sistema para un escenario especfico).
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 perodo de 2 a 4 das. En estas reuniones se
ayuda a los clientes a y usuarios a formular problemas y explorar posibles
soluciones, involucrndolos y hacindolos sentirse partcipes en el desarrollo
del proyecto.
Esta tcnica se basa en 4 principios: 1) Dinmica de grupo, 2) uso de ayudas

visuales para mejorar la comunicacin, 3) mantener un proceso organizado y
racional y 4) una filosofa de documentacin 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 diseo del
software. Debido a las necesidades de organizacin que requiere y a que no
suele adaptarse a los horarios de trabajos de los clientes y usuarios, est
tcnica no suele utilizarse con frecuencia, aunque cuando se aplica se suelen
obtener buenos resultados. [SUMANO, 2006].
- 68 -
2. DISEO METODOLGICO
2.1 MTODO DE INVESTIGACIN

[OCHOA, 2006]
Definicin: Es una especie de brjula en la que no se produce automticamente

el saber, pero que evita perderse en el caos aparente de los fenmenos,
aunque solo sea porque indica como no plantear los problemas y como no
sucumbir en el embrujo de ciertos prejuicios predilectos.
El mtodo
independiente del objeto al que se aplique, tiene como objetivo solucionar

problemas.
2.1.1 Las diversas clases de mtodos de investigacin
Se pueden establecer dos grandes clases de mtodos de investigacin: los

mtodos lgicos y los empricos.
Los primeros son todos aquellos que se
basan en la utilizacin del pensamiento en sus funciones de deduccin, anlisis

y sntesis, mientras que los mtodos empricos, se aproximan al conocimiento
del objeto mediante su conocimiento directo y el uso de la experiencia, entre
ellos se encuentra la observacin y la experimentacin.
2.1.1.1 Mtodos lgicos
2.1.1.1.1 Mtodo lgico deductivo
Mediante ella se aplican los principios descubiertos a casos particulares, a

partir de un enlace de juicios. El papel de la deduccin en la investigacin es
doble:
- 69 -
a. Primero consiste en encontrar principios desconocidos, a partir de los

conocidos. Una ley o principio puede reducirse a otra ms general que la
incluya.
b. Tambin 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 avin. La matemtica es la ciencia deductiva por
excelencia; parte de axiomas y definiciones.
- Mtodo deductivo directo inferencia o conclusin inmediata.
Se
obtiene el juicio de una sola premisa, es decir que se llega a una conclusin
directa sin intermediarios. Ejemplo: "Los libros son cultura", "En consecuencia,
algunas manifestaciones culturales son libros".
- Mtodo deductivo indirecto inferencia o conclusin mediata - formal.

Necesita de silogismos lgicos, en donde silogismo es un argumento que
consta de tres proposiciones, es decir se comparan dos extremos (premisas o
trminos) con un tercero para descubrir la relacin entre ellos. La premisa
mayor contiene la proposicin universal, la premisa menor contiene la
proposicin particular, de su comparacin resulta la conclusin. Ejemplo: "Los
ingleses son puntuales" - "William es ingles" - "Por tanto, William es puntual".
2.1.1.1.2 Mtodo hipottico-deductivo
Un investigador propone una hiptesis como consecuencia de sus inferencias

del conjunto de datos empricos o de principios y leyes ms generales. En el
primer caso arriba a la hiptesis mediante procedimientos inductivos y en
segundo caso mediante procedimientos deductivos.
Es la va primera de
inferencias lgico/deductivas para arribar a conclusiones particulares a partir de

la hiptesis y que despus se puedan comprobar experimentalmente.
- 70 -
2.1.1.1.3 Mtodo lgico inductivo
Es el razonamiento que, partiendo de casos particulares, se eleva a

conocimientos generales.
Este mtodo permite la formacin de hiptesis,
investigacin de leyes cientficas, y las demostraciones.
En el mtodo de induccin se hallan otros mtodos para encontrar causas a

partir de mtodos experimentales:
- Mtodo de concordancia: Compara entre si varios casos en que se presenta

un fenmeno natural y seala lo que en ellos se repite, como causa del
fenmeno.
- Mtodo de diferencia: Se renen varios casos y se observa que siempre

falta una circunstancia que no produce el efecto, permaneciendo siempre todas
las dems circunstancias, concluimos que lo que desaparece es la causa de lo
investigado.
- Mtodo de variaciones concomitantes: Si la variacin de un fenmeno se

acompaa de la variacin de otro fenmeno, concluimos que uno es la causa
de otro.
- Mtodo de los residuos: Consiste en ir eliminando de un fenmeno las

circunstancias cuyas causas son ya conocidas. La circunstancia que queda
como residuo se considera la causa del fenmeno.
2.1.1.1.4 Mtodo lgico: la analoga
Consiste en inferir de la semejanza de algunas caractersticas entre dos

objetos, la probabilidad de que las caractersticas restantes sean tambin
semejantes. Los razonamientos analgicos no son siempre validos.
- 71 -
2.1.1.1.5 El mtodo histrico
Est vinculado al conocimiento de las distintas etapas de los objetos en su

sucesin cronolgica, para conocer la evolucin y desarrollo del objeto o
fenmeno de investigacin se hace necesario revelar su historia, las etapas
principales de su desenvolvimiento y las conexiones histricas fundamentales.
Mediante el mtodo histrico se analiza la trayectoria concreta de la teora, su
condicionamiento a los diferentes perodos de la historia. Los mtodos lgicos
se basan en el estudio histrico poniendo de manifiesto la lgica interna de
desarrollo, de su teora y halla el conocimiento ms profundo de esta, de su
esencia. La estructura lgica del objeto implica su modelacin.
2.1.1.1.6 Mtodo sinttico
Es un proceso mediante el cual se relacionan hechos aparentemente aislados y

se formula una teora que unifica los diversos elementos.
Consiste en la
reunin racional de varios elementos dispersos en una nueva totalidad, este se

presenta ms en el planteamiento de la hiptesis. El investigador sintetiza las
superaciones en la imaginacin para establecer una explicacin tentativa que
someter a prueba.
2.1.1.1.7 Mtodo analtico
Se distinguen los elementos de un fenmeno y se procede a
revisar
ordenadamente cada uno de ellos por separado. La fsica, la qumica y la

biologa utilizan este mtodo; a partir de la experimentacin y el anlisis de
gran nmero de casos se establecen leyes universales.
Consiste en la
extraccin 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 anlisis de un

objeto se realiza a partir de la relacin que existe entre los elementos que
- 72 -
conforman dicho objeto como un todo; y a su vez, la sntesis se produce sobre

la base de los resultados previos del anlisis.
2.1.1.1.8 Mtodo de la abstraccin
Es un proceso importantsimo para la comprensin del objeto, mediante ella se

destaca la propiedad o relacin de las cosas y fenmenos. No se limita a
destacar y aislar alguna propiedad y relacin del objeto asequible a los
sentidos, sino que trata de descubrir el nexo esencial oculto e inasequible al
conocimiento emprico.
2.1.1.1.9 Mtodo de la concrecin
Mediante la integracin 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 terico.
Lo
concreto es la sntesis de muchos conceptos y por consiguiente de las partes.

Las definiciones abstractas conducen a la reproduccin de lo concreto por
medio del pensamiento. Lo concreto en el pensamiento es el conocimiento
ms profundo y de mayor contenido esencial.
2.1.1.1.10 Mtodo gentico
Implica la determinacin de cierto campo de accin elemental que se convierte

en clula del objeto, en dicha clula estn presentes todos los componentes del
objeto as como sus leyes ms trascendentes.
2.1.1.1.11 Mtodo de la modelacin
Es justamente el mtodo mediante el cual se crean abstracciones con vistas a

explicar la realidad. El modelo como sustituto del objeto de investigacin. En
el modelo se revela la unidad de lo objetivo y lo subjetivo.
- 73 -
La modelacin es el mtodo que opera en forma prctica o terica con un

objeto, no en forma directa, sino utilizando cierto sistema intermedio, auxiliar,
natural o artificial.
2.1.1.1.12 Mtodo sistmico
Est dirigido a modelar el objeto mediante la determinacin de sus

componentes, as como las relaciones entre ellos. Esas relaciones determinan
por un lado la estructura del objeto y por otro su dinmica.
2.1.1.1.13 Mtodo dialctico
La caracterstica esencial del mtodo dialctico es que considera los

fenmenos histricos y sociales en continuo movimiento.
Dio origen al
materialismo histrico, el cual explica las leyes que rigen las estructuras
econmicas y sociales, sus correspondientes superestructuras y el desarrollo
histrico de la humanidad. Aplicado a la investigacin, afirma que todos los
fenmenos se rigen por las leyes de la dialctica, es decir que la realidad no es
algo inmutable, sino que est sujeta a contradicciones y a una evolucin y
desarrollo perpetuo.
Por lo tanto propone que todos los fenmenos sean
estudiados en sus relaciones con otros y en su estado de continuo cambio, ya

que nada existe como un objeto aislado.
Este mtodo describe la historia de lo que nos rodea, de la sociedad y del

pensamiento, a travs de una concepcin de lucha de contrarios y no
puramente contemplativa, ms bien de transformacin. Estas concepciones
por su carcter dinmico exponen no solamente los cambios cuantitativos, sino
los radicales o cualitativos.
- 74 -
2.1.1.2 Mtodos empricos
Definidos de esa manera por cuanto su fundamento radica en la percepcin

directa del objeto de investigacin y del problema.
2.1.1.2.1 Observacin cientfica
El investigador conoce el problema y el objeto de investigacin, estudiando su

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

es el procedimiento emprico mas generalizado de conocimiento. Mario Bunge
reconoce en el proceso de observacin cinco elementos:
a. El objeto de la observacin
b. El sujeto u observador
c. Las circunstancias o el ambiente que rodean la observacin
d. Los medios de observacin
e. El cuerpo de conocimientos de que forma parte la observacin
2.1.1.2.2 La experimentacin cientfica
Implica alteracin controlada de las condiciones naturales, de tal forma que el

investigador crear modelos, reproducir condiciones, abstraer rasgos
distintivos del objeto o del problema. La experimentacin depende del grado
de conocimiento del investigador, a la naturaleza, a las circunstancias del
objeto y al problema de investigacin, es decir no siempre se podr realizar
experimentacin. La experimentacin debe seguir ciertas reglas:
a. El fenmeno 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 fenmeno.
d. El experimento debe durar el tiempo suficiente para que se produzca el
fenmeno deseado.
2.1.1.2.3 La medicin
Se desarrolla con el objetivo de obtener la informacin numrica acerca de una

propiedad o cualidad del objeto o fenmeno, donde se comparan magnitudes
medibles y conocidas. Es decir es la atribucin de valores numricos a las
propiedades de los objetos. En la medicin hay que tener en cuenta el objeto y
la propiedad que se va a medir, la unidad y el instrumento de medicin, el
sujeto que realiza la misma y los resultados que se pretenden alcanzar.
En las ciencias sociales, naturales y tcnicas no basta con la realizacin de las

mediciones, sino que es necesario la aplicacin de diferentes procedimientos
que permitan revelar las tendencias, regularidades y las relaciones en el
fenmeno objeto de estudio, uno de estos procedimientos son los estadsticos,
tanto los descriptivos como los inferenciales.
- 76 -
2.2 DISEO METODOLGICO

Objetivo General
Realizar un anlisis comparativo de tcnicas de obtencin de

requerimientos para el mdulo de Facturacin del aplicativo
Gestasoft Hospitalario para IMSALUD (Institucin Municipal de
Salud de San Jos de Ccuta).
Objetivos Especficos
1. Identificar las
principales
actividades de la
obtencin
de
requerimientos.
2. Identificar y seleccionar
las tcnicas y herramientas
adecuadas
para
el
desarrollo de las actividades
de
la
obtencin
de
requerimientos.
3. Desarrollar
anlisis
comparativo
tcnicas
herramientas
obtencin
requerimientos.
un
de
y
de
de
- 77 -
4. Aplicar en la
obtencin
de
requerimientos
las tcnicas y
herramientas
previamente
seleccionadas.
5. Extraer los
requerimientos
para el mdulo
de Facturacin
del
aplicativo
Gestasoft
Hospitalario.
6. Analizar y
especificar los
requerimientos
identificados
para el mdulo
de facturacin.
1.
Identificar
las
principales actividades
de la obtencin de
requerimientos.
Tareas
1.1 Investigar las actividades

propias de la obtencin de
requerimientos y las diversas
opiniones de los autores
respecto a ellas.
1.2 Analizar las actividades de

la obtencin de requerimientos
y los esquemas propuestos
por los autores para cada una
de ellas.
Resultado
Marco terico sobre las actividades de la

obtencin de requerimientos y dems temas
de inters tales como el Modelo del Negocio
y las Metodologas utilizadas en la obtencin
de Requerimientos. (Captulo 1)
Mtodos utilizados
Mtodo Histrico: Se analiz la

sucesin cronolgica de cada una
de las actividades que conforman
la obtencin de requerimientos,
sus caractersticas principales,
definiciones
y
concepciones
propuestas por algunos autores.
Mtodo analtico: Se extrae de la

Obtencin de Requerimientos, sus
partes, es decir, cada una de las
actividades de la obtencin de
requerimientos, con el objetivo de
estudiarlas
y
analizar
sus
caractersticas,
objetivos
y
principios.
- 78 -
2. Identificar y seleccionar las tcnicas y

herramientas adecuadas para el desarrollo
de las actividades de la obtencin de
requerimientos.
Tareas
2.1 Investigar tcnicas y

herramientas.
2.2 Ubicar las tcnicas y

herramientas segn su
aplicacin
en
las
actividades
de
la
obtencin
de
requerimientos
Resultado
2.3 Seleccionar tcnicas

y herramientas.
Resultado
Resultado
Marco terico sobre las

tcnicas y herramientas
existentes
para
la
obtencin de requeri mientos. (Captulo 1)
Cuadro
con
la
clasificacin
de
las
tcnicas y herramientas
segn las actividades de
la obtencin de requeri mientos. (Captulo 1)
Mtodo
Utilizado
Mtodo Histrico: Se
analiz
la
sucesin
cronolgica de cada una
de
las
tcnicas
y
herramientas utilizadas en
la
obtencin
de
requerimientos.
Cuadro con las Tcnicas

y
herramientas
seleccionadas. (Captulo 4)
Mtodo
Utilizado
Mtodo analtico: Se tom
cada una de las tcnicas y
herramientas con el objetivo
de analizarlas y clasificarlas
segn las actividades de la
obtencin
de
requerimientos.
- 79 -
3. Desarrollar un anlisis
comparativo de tcnicas y
herramientas de obtencin de
requerimientos.
Tarea
3.1 Realizacin de un cuadro

comparativo con ventajas y
desventajas de las tcnicas y
herramientas.
Resultado
Anlisis
tcnicas
comparativo
de
y
herramientas.
(Captulo 4).
Mtodo utilizado
Mtodo de la abstraccin: Se trata de

comprender cada una de las tcnicas y
herramientas utilizadas en la obtencin 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 obtencin de requerimientos las tcnicas y

herramientas previamente seleccionadas.
Tareas
4.1 Consulta y anlisis de

diferentes
metodologas
y
mtodos
empleados
en
la
obtencin de requerimientos como
base para proponer uno nuevo.
4.2 Propuesta de un
mtodo
para
la
obtencin
de
requerimientos.
4.3
Definicin
del
mtodo propuesto para
la
obtencin
de
requerimientos.
Resultado
Investigacin de algunas metodologas

utilizadas
en
la
obtencin
de
requerimientos las cuales se definen en el
marco terico. (Captulo 1)
4.4 Explicacin de
las
etapas
y
subetapas
del
mtodo.
4.5 Ubicacin de las

tcnicas y herramientas en
cada una de las etapas y
subetapas.
Resultados
Mtodo para la obtencin de

requerimientos. (Captulo 4)
Aplicacin del mtodo para la

obtencin de requerimientos.
(Captulo 4)
Mtodo utilizado
Mtodo Histrico: Se analizaron algunas
metodologas con el objetivo de conocer
su
desarrollo,
propiedades
y
caractersticas de aplicabilidad al proyecto.
Mtodos utilizados
- 81 -
Mtodo de la abstraccin: Se
destacan las relaciones entre cada
una de las actividades de la obtencin
de requerimientos facilitando de esta
manera su comprensin,
con el
objetivo de formular un mtodo
efectivo, enfocado en el usuario.
Mtodo
de
la
concrecin: Se reprodujo
el mtodo propuesto para
la
obtencin
de
requerimientos
en
un
plano terico donde se
especifican sus principios.
- 82 -
Mtodo sistmico: Se
determinaron las etapas
y subetapas del mtodo
para
facilitar
su
modelado, describiendo
y
la
estructura
y
dinmica del mismo.
Mtodo de Modelacin:
Representacin grfica y
visual del mtodo para
permitir su comprensin,
creando abstracciones con
el fin de explicar la
realidad.
5. Extraer los requerimientos para el mdulo de

Facturacin del aplicativo Gestasoft Hospitalario.
Tareas
5.1
Realizacin
del
modelo del negocio con el
objetivo
de
obtener
informacin real y actual
sobre la empresa objetivo.
5.2 Aplicacin del mtodo de la

obtencin
de
requerimientos
reutilizando
ciertos
artefactos
obtenidos durante el modelado del
negocio.
Resultado
Modelo
negocio.
(Captulo 3)
del
5.3
Extraccin
de
los
requerimientos en el rea de
salud utilizando el mtodo
propuesto.
Resultados
Requerimientos extrados al
aplicar el mtodo propuesto para
la obtencin de requerimientos.
(Captulo 4)
- 83 -
Relacin entre el modelamiento

del negocio y el mtodo
propuesto para la obtencin de
Mtodos utilizados
Mtodo utilizado
Mtodo
de
modelacin:
Representacin visual,
por medio de diagramas
y modelos, de los
requerimientos.
Mtodos utilizados
Mtodo
histrico:
Anlisis
cronolgico
sobre
los
diferentes
procesos de la
organizacin.
Mtodo
analtico:
Se
tomaron
cada
uno
de
los
procesos
y
subprocesos,
con los actores
y
dems
participantes
que
los
conforman, para
de esta manera
investigar
sus
propiedades
y
comprender su
modo ejecucin
y relacin.
Mtodo de la
abstraccin: Se
analiz
cada
uno
de
los
procesos
y
dems
entes
que
estos
incluyen,
sus
relaciones,
propiedades,
ambiente
y
modo
de
operacin, con
el
fin
de
comprender el
todo
que
conforman.
Mtodo de la
concrecin:
Tomando como
base
el
conocimiento
obtenido de la
abstraccin se
procede
a
organizar
la
informacin en
artefactos
tericos
para
facilitar
su
compresin.
- 84 -
Mtodo analtico: Se
analizan cada una de
las
etapas
del
modelado del negocio
y
del
mtodo
propuesto
para
establecer su relacin.
Mtodo
sistmico:
Segn
el
anlisis de las
partes de la
organizacin, en
el rea de salud,
se
pudo
describir
su
estructura
y
dinmica,
basados
en
informacin
actual y real.
Mtodo de la
concrecin: Se
plasma en un
plano terico la
relacin
entre
los
objetos
involucrados.
Mtodo
de
Modelacin:
Representacin
visual de los
anteriores
artefactos
tericos
y
anlisis
realizados
de
los procesos y
subprocesos de
la organizacin
(diagramas de
procesos,
actividad, entre
otros).
6. Analizar y especificar los

requerimientos identificados
para
el
mdulo
de
facturacin.
Tareas
6.1 Aplicacin del

mtodo propuesto
para la obtencin
de requerimientos
reutilizando ciertos
artefactos
obtenidos durante
el modelado del
negocio.
6.2
Anlisis
y
especificacin de los
requerimientos segn
el mtodo propuesto
haciendo uso de las
herramientas
y
tcnicas
seleccionadas
para
dicho fin.
Resultados
Anlisis y especificacin
de los requerimientos
obtenidos
con
la
aplicacin del mtodo
propuesto. (Captulo 4)
Relacin
entre
el
modelamiento del negocio
y el mtodo propuesto
para la obtencin de
Mtodo utilizado
Mtodo
de
modelacin:
Representacin
visual, por medio de
diagramas
y
modelos, de los
requerimientos.
Mtodos utilizados
Mtodo analtico: Se
analizan cada una de
las
etapas
del
modelado del negocio
y
del
mtodo
propuesto
para
establecer su relacin.
- 85 -
Mtodo
de
la
concrecin:
Se
plasma en un plano
terico la relacin
entre las etapas del
modelado
del
negocio y el mtodo
propuesto.
Valor agregado
(Objetivo adicional)
Apoyo y demostracin de
viabilidad.
Resultado
El modelo del negocio y la obtencin de

requerimientos como solucin a algunas de
las causas de fracasos de los proyectos de
software. (Captulo 5)
Mtodos utilizados
Mtodo
histrico:
Consulta [tomado de
ACIS,
17
de
Noviembre de 2006]
sobre algunas de las
causas de los fracasos
de los proyectos de
software
a
nivel
nacional
con
el
objetivo de identificar
sus
caractersticas,
propiedades
y
evolucin segn los
avances
empresariales
y
tecnolgicos.
Mtodo de concordancia
(lgico
inductivo):
Comparacin y anlisis de
varias opiniones o casos
dados
por
algunos
expertos nacionales e
internacionales
como
Orlando Cuevas (Director
de
proyectos
de
Informtica
del
CIFI,
Universidad de los Andes),
Oscar Aldana (Gerente de
proyectos de Getronics
Colombia), Marco Antonio
Jimnez (ejecutivo IBM
Colombia) y Sara Cristina
Mantilla
(Gerente
de
proyecto para el rea de
Amrica Latina), respecto
a las causas de los
fracasos de los proyectos
de software, para de esta
manera
identificar
su
incidencia
y
variacin
segn la empresa y el
proyecto.
- 86 -
Mtodo
de
variaciones
concomitantes
(lgico
inductivo):
Anlisis
de
las
variaciones de las
causas y sus efectos
en los fracasos de los
proyectos para as
proponer soluciones
efectivas a dichos
problemas e identificar
la importancia del
modelo del negocio y
la
obtencin
de
requerimientos en la
solucin.
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
Visin La Empresa Social del Estado (ESE) IMSALUD desea convertirse en
la Empresa lder en la prestacin de servicios de salud con un alto ndice de
lucro social, financiero, calidad humana y tcnica de servicio, en el Municipio de
San Jos de Ccuta, mediante la conservacin de los principios corporativos
de eficiencia, eficacia, valor humano y calidad en la atencin en un trmino de
cinco (5) aos.
Misin Prestar servicios de salud del primer nivel de atencin tanto a los
usuarios del rgimen subsidiado como particulares, vinculados y del rgimen
contributivo de manera eficiente, eficaz y oportuna, contribuyendo, por ende al
mejoramiento continuo de la situacin de salud y de la calidad de vida en el
municipio de San Jos de Ccuta.
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 poblacin 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 reglamentacin que se
expida para tal propsito.
Objetivo Especfico
Gestionar los procesos de la

divisin de atencin en salud.
Metas
Optimizar el proceso de atencin mdica al usuario, por
medio de la gestin de consultas.
Mejorar y controlar el servicio de hospitalizacin.
- 87 -
Obtener exmenes de laboratorio de una manera ms gil y

efectiva.
Controlar los programas de Demanda Inducida (DI)
Deteccin Precoz (DP) Proteccin Especfica (PE), con el
objeto de mejorar la calidad de vida de los usuarios.
Mejorar el proceso de atencin al cliente.
Controlar las observaciones de tipo administrativo y tcnico
(Glosas) con el fin de objetar los valores cobrados por la
prestacin de servicios de salud.
Gestionar el personal mdico y paramdico 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 divisin.
Formular y verificar contratos con ARS (Administradora del
Rgimen Subsidiado), permitiendo un mayor cubrimiento de
salud a nivel local.
Fortalecer la calidad del personal mdico y paramdico de la
institucin.
Facturar los servicios prestados a determinado usuario
teniendo en cuenta su rgimen y nivel de afiliacin.
Controlar el estado de salud de los pacientes mejorando la
gestin de sus historias clnicas y RIPS (Registro Individual
de Prestacin de Servicios).
Gestionar los procesos del

departamento de Promocin y
Prevencin.
Seguir y controlar las actividades de Promocin y Prevencin

con el fin de mejorar la calidad de vida de los usuarios.
Optimizar los programas de atencin.
Gestionar los equipos e insumos necesarios para la mejora
progresiva de los servicios de atencin.
Permitir un mejor cubrimiento del rea de influencia de la
institucin gestionando las reuniones de los comits de
vigilancia epidemiolgica de cada IPS (Institucin 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 rgimen y nivel de afiliacin.
Controlar el estado de salud de los pacientes mejorando la
gestin de sus historias clnicas y RIPS (Registro Individual
de Prestacin de Servicios).
- 88 -
Gestionar los
Farmacia.
procesos
de
Optimizar el proceso de requisicin y entrega de

medicamentos.
Controlar el inventario, para tener disponibles los
medicamentos requeridos por los usuarios.
Elaborar informes sobre el
devolucin de medicamentos.
suministro,
adquisicin
Mejorar el proceso de gestin de medicamentos ejerciendo

Control sobre las farmacias satlites.
Facturar los medicamentos entregados a los usuarios segn
su rgimen y nivel de afiliacin.
Gestionar los bienes y mercancas.
Gestionar aquellos procesos
de Almacn que tengan
relacin directa con el control
de Medicamentos.
Controlar el inventario, para tener disponibles

medicamentos requeridos por los usuarios.
los
Elaborar informes
medicamentos.
salida
de
salida
de
sobre
Facturar los procesos

medicamentos.
la
adquisicin
de
obtencin
Tabla 5. Objetivos especficos y Metas del negocio
3.1.1.2 Procesos del negocio
Cadena de valor:
Figura 22. Cadena de Valor
- 89 -
Jerarqua de procesos:
Gestionar Procesos de la Divisin de Atencin en Salud
Figura 23. Jerarqua de Procesos de la Divisin de Atencin en Salud

- 90 -
Gestionar Procesos del Departamento de Promocin y Prevencin
Figura 24. Jerarqua de Procesos del Departamento de promocin y prevencin

- 91 -
Gestionar Procesos de Farmacia
Figura 25. Jerarqua de Procesos de Farmacia

- 92 -
Gestionar Procesos de Almacn
Figura 26. Jerarqua de Procesos de Almacn

- 93 -
Procesos Primarios y de Soporte
Gestionar Procesos de la Divisin de Atencin en Salud.
Figura 27. Procesos Primarios y de Soporte (Divisin de Atencin en Salud)
- 94 -
Gestionar los procesos del Departamento de Promocin y Prevencin
Figura 28. Procesos Primarios y de Soporte (Departamento de Promocin y Prevencin)
Gestionar los procesos de Farmacia
Figura 29. Procesos Primarios y de Soporte (Farmacia)
- 95 -
Gestionar los procesos de Almacn
Figura 30. Procesos Primarios y de Soporte (Almacn)
Diagramas de Procesos
Gestionar Procesos de la Divisin de Atencin en Salud.
Gestionar Atencin al cliente
Figura 31. Diagrama del proceso: Gestionar atencin al cliente
- 96 -
Gestionar calidad
od Calidad
Datos de
Personal
Pruebas
Supply
Input
Gestionar calidad
Control de
calidad del
personal
Prueba resuelta
Output
Jefe de la Div isin
goal
goal
Fortalecer la calidad del personal
mdico y paramdico de la institucin.
Figura 32. Diagrama del proceso: Gestionar calidad
Gestionar cita
od Cita
Datos de Usuario
Supply
Asignar, eliminar
o modificar Citas
goal
Gestionar Cita
Cita
Asignar o
Modificar cita
Output
Auxiliar
Supply
Datos del
Mdico
Figura 33. Diagrama del proceso: Gestionar cita
- 97 -
Gestionar consultas
Figura 34. Diagrama de los proceso: Gestionar consultas Facturacin y Servicio de

Enfermera
Gestionar contrato con ARS
od Contratos con ARS
Solicitud
de
Contrato
Informacin para crear

Minuta Contractual
Formato
contractual
Input
Supply
Elaborar contrato con ARS

Contrato
Output
Jefe de
Div isin/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 segn el
informes a realizar
Supply
Elaborar Informes
Solicitud
de
Informe
Informe
Output
Secretaria/Auxiliar
Administrativ o
goal
goal
Elaborar informes de las
activ idades y procedimientos
que se realizan en la div isin
Figura 36. Diagrama del proceso: Elaborar informes
Gestionar Glosas
od Glosas
Factura Glosada
Input
Gestionar Glosas
Concepto
Recepcin
de glosas
Output
Jefe de Div isin de

Atencin en Salud
goal
goal
Controlar las observ aciones de tipo
administrativ o y tcnico (Glosas) con el
fin de obj etar los v alores cobrados por la
prestacin de serv icios de salud
Figura 37. Diagrama del proceso: Gestionar glosas
- 99 -
Gestionar historia clnica y RIPS
od HC y RIPS
goal
Formato de
RIPS
Supply
Datos de Usuario
Controlar el estado de salud de

los pacientes mej orando la
gestin de sus historias clnicas y
RIPS
Supply
goal
Gestionar Historia Clnica y RIPS

Registrar o
Actualizar
datos
Historia
Clnica/RIPS
diligenciado
Output
Enfermera/Mdico/Odontlogo
Input
Anamnesis/Procedimiento
aplicado
Figura 38. Diagrama del proceso: Gestionar Historia clnica y RIPS
Gestionar hospitalizacin
od Hospitalizacin
Prestar serv icio de
Hospitalizacin a
los usuarios
Datos de Usuario
Supply
goal
Historia Clinica
Mej orar y controlar el

serv icio de hospitalizacin
Supply
goal
goal
Historia Clinica
Orden de
Hospitalizacin
Output
Mdico
Uses
Input
Getionar Facturacin
Factura
Facturar
Servicios
Output
Caj ero
Supply
goal
Tarifa de
Prestacin de
Serv icios
Elaborar facturas
de prestacin de
serv icios
Figura 39. Diagrama del proceso: Gestionar Hospitalizacin
- 100 -
Gestionar examen de laboratorio
od Laboratorio
Datos de Usuario
Obtener exmenes
de laboratorio de una
manera ms gil y
efectiv a
Muestras
Supply
Input
goal
Gestionar Examen de Laboratorio

Resultado
Orden de
Laboratorio
Output
Mdico o Auxiliar de
Laboratorio
Uses
Input
Gestionar Facturacin
Factura
Facturar
Servicios
Output
Caj ero
goal
Supply
Elaborar Facturas de
Prestacin de
Serv icios
Tarifas de
Prestacin de
Serv icios
Figura 40. Diagrama del proceso: Gestionar examen de laboratorio
Gestionar personal mdico y paramdico
od Personal Mdico y Paramdico

Datos del
personal
Supply
Solicitud de
Personal
Gestionar Personal mdico y

paramdico
Output
Notificacin de
actos
administrativ os
Jefe de Div isin de

Atencin en Salud
goal
goal
Gestionar el personal mdico y
paramdico de la Empresa Social
del Estado, para de esta manera
fortalecer los procesos misionales
Figura 41. Diagrama del proceso: Gestionar Personal mdico y Paramdico
- 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
(estadsticas y correctiv os)
Solicitud
de Informe
Output
Jefe de Div isin de

Atencin 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 Promocin y Prevencin
Gestionar coves
od Cov es
Calendario
Epidemiolgico
Acta Cov e de
cada IPS
Supply
Input
Gestionar Cov es
Reunin segn
calendario
epidemiolgico
Acta de Reunin
Output
Medico Coordinador
goal
goal
Permitir un mej or cubrimiento del rea de
influencia de la institucin gestionando las
reuniones de los comits de v igilancia
epidemiolgica de cada IPS y del municipio
Figura 43. Diagrama del proceso: Gestionar Coves
- 102 -
Gestionar equipos e insumos
od Equipos e insumos
Solicitud de
Requisicin
Input
Gestionar Equipos e Insumos

Solicitud de
Equipos/Insumos
Output
Solicitud de orden de
compra de
equipos/insumos
Coordinador IPS
goal
goal
Gestionar los equipos e insumos
necesarios para la mej ora progresiv a
de los serv icios de atencin
Figura 44. Diagrama del proceso: Gestionar equipos e insumos
Gestionar programas de atencin
od Programas de Atencin
Datos de usuario
Supply
goal
Informacin de
Historia Clnica
Optimizar los
programas de atencin
Input
goal
Gestionar Programas de Atencin

Solicitud de
atencin
Output
Historia clnica y
RIPS
Usuario
Uses
Input
Factura
Facturar
servicios
Output
Caj ero
Supply
Tarifas de
Prestacin de
Serv icios
goal
Elaborar Facturas de
Prestacin de
Serv icios
Figura 45. Diagrama del proceso: Gestionar programas de atencin

- 103 -
Seguir y controlar actividades
od Seguir y Controlar Activ idades

Informe de Rendimiento en cada
IPS (segn el tipo de activ idad)
Input
Realizar un balance
sobre la prestacin de
servicios del
Departamento
Jefe del Departamento

de Promocin y
Prev encin
Seguir y Controlar Activ idades de Promocin y

Prev encin
Informe
consolidado de las
activ idades
Output
goal
goal
Seguir y controlar las activ idades de
Promocin y Prev encin con el fin de
mej orar la calidad de v ida de los
usuarios
Figura 46. Diagrama del proceso: Seguir y controlar actividades de promocin y

prevencin
Gestionar los procesos de Farmacia
Coordinar farmacias satlites
od Farmacias Satlites
Informe de cada
Faramcia
Input
Controlar Farmacias Satelites

Informe General
Control
Logstico
Output
Auxiliar
Administrativ o
goal
goal
Mej orar el proceso de gestin de
medicamentos ej erciendo Control
sobre las farmacias satlites.
Figura 47. Diagrama del proceso: Controlar farmacias satlites
- 104 -
Gestionar inventario
od Inv entario
Informe reciente
de inv entario
Input
Gestionar Inv entario

Nuev o inv entario
Actualizar
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
Medicamento
Acta de
Recibo/salida
Output
Regente de farmacia
goal
goal
Facturar los medicamentos entregados a
los usuarios segn su rgimen y niv el de
afiliacin.
Figura 49. Diagrama del proceso: Gestionar medicamentos
- 105 -
Gestionar los procesos de Almacn
Gestionar bienes
od Bienes
Informacin sobre el
estado de los bienes
Input
Gestionar Bienes
Revisin
de bienes
Acta y Actualizacin
del Kardex
Output
Jefe de Almacn
goal
goal
Gestionar bienes
Figura 50. Diagrama del proceso: Gestionar bienes
Gestionar mercancas
od Mercancas
Recibe
mercanca/Solicitud de
pedido
Input
Necesidad de
alguna
mercanca
Gestionar Mercancas
Output
Acta de
Recibo/Salida
Jefe de Almacn
goal
goal
Gestionar las mercancas
del almacn
Figura 51. Diagrama del proceso: Gestionar mercancas
- 106 -
3.1.1.3 Actores, Unidades y Estructura del Negocio
3.1.1.3.1 Actores
Internos
Auxiliar.
Auxiliar administrativo.
Auxiliar operativo.
Bacterilogo.
Cajero.
Coordinador IPS.
Digitador.
Funcionario comit de bajas.
Gerente.
Jefe de Almacn.
Jefe del Departamento de Personal.
Jefe de Divisin de Atencin en Salud.
Jefe PAI (Programa Ampliado de Inmunizaciones).
Jefe de Presupuesto y Contabilidad.
Jefe de Promocin y Prevencin.
Jefe de Servicios Generales.
Jurdico.
Mdico.
Odontlogo.
Promotor de salud.
Regente de Farmaca.
Secretaria.
Tesorero.
Externos
Base de Datos POS S.
Software PAIDSA.
- 107 -
Descripcin:
Auxiliar
Persona encargada de:
Asignar al paciente el turno para la cita.
Recibir y Verificar los datos de los usuarios.
Comprobar factura de cancelacin.
Diligenciar el RIPS.
Revisar rdenes mdicas (si se tienen).
Revisar y Registrar informacin en la Historia Clnica del paciente (signos
vitales, peso, talla, tensin, etc.).
Realizar tratamiento mdico (si es el caso).
Realizar notas de enfermera.
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 Clnica.
Entregar frmulas, remisiones y/o resultados al usuario.
Manejar programas de salud pblica.
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, adems
elabora informes sobre los medicamentos de control y organiza la informacin
proveniente de las farmacias satlites.
Auxiliar operativo
Se encarga de:
Comparar la cantidad, referencia, modelo, fecha de expedicin y
vencimiento, seriales, precios de los elementos, etc.
- 108 -
Con relacin a lo
descrito en el contrato de adquisicin de mercancas.

Ordena los elementos que ingresan a Almacn.
Procede a sacar el elemento del depsito para despacharlo al solicitante y
cerrar el proceso.
Bacterilogo
Recibir las muestras tomadas por la auxiliar de laboratorio.
Procesar y producir resultados de laboratorio.
Realizar estadsticas diarias.
Control de calidad interno y externo de los anlisis.
Base de Datos POS S
Retorna los medicamentos del POS S que son autorizados para los
diferentes usuarios segn el rgimen 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
afiliacin, para de esta manera tarifar dicho servicio.
Coordinador IPS
Coordina la elaboracin del informe sobre el diagnstico 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 almacn, los cuales se
encuentren corruptos.
- 109 -
Gerente
Firmar contratos con ARS para su legalizacin, adems se encarga de
gestionar la donacin, venta, destruccin o baja de los bienes existentes en
almacn.
Jefe de Almacn
Se encarga de gestionar la entrada y salida de mercancas, la donacin, venta,
baja y destruccin de bienes, adems 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
divisin de Atencin en salud, adems gestiona el personal mdico y
paramdico que se desempear en el rea de salud.
Jefe de Divisin de Atencin en Salud

Est encargado de supervisar las actividades y procesos que se desarrollan en
la divisin de atencin en salud, algunas de sus funciones involucra la gestin
de la elaboracin de informes, contratos y glosas, verificar y validar la calidad
de la prestacin de servicios de salud, la atencin 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 vacunacin y las
reuniones del comit de vigilancia epidemiolgica (Coves). El objetivo principal
de dicho programa es el de alcanzar la vacunacin de por lo menos 90% en los
menores de 6 aos con todos los antgenos del PAI, la erradicacin de la
poliomielitis, la eliminacin del ttanos neonatal, la eliminacin del sarampin y,
en las zonas de riesgo, el suministro de micronutrientes suplementarios
adecuados.
- 110 -
Es un programa que tiene alta prioridad poltica y las vacunas estn

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

Recibe el informe mensual proveniente de almacn.
Jefe de Promocin y Prevencin

Est encargado de supervisar las actividades de promocin y prevencin que
se ofrecen a los diferentes usuarios en esta dependencia, gestiona la
elaboracin de informes y coves, adems supervisa la existencia y buen uso de
los equipos e insumos que se requieren para la prestacin efectiva de los
servicios.
Jefe de Servicios Generales

Se encarga de gestionar la compra de mercancas cada vez que almacn
requiere algn elemento, gestiona la baja y avalo de bienes.
Jurdico
Se encarga de elaborar el concepto jurdico concerniente al contrato que se
realizar con determinada ARS.
Mdico
Realizar valoracin mdica.
Originar diagnstico.
Elaborar y/o aplicar tratamiento.
Elaborar frmula mdica.
Elaborar rdenes mdicas: hospitalizacin, laboratorio, remisin, salida,
entre otras. (si se requiere).
- 111 -
Obtener ayudas diagnsticas (si se requiere).

Diligenciar RIPS.
Odontlogo
Valorar al usuario.
Elaborar carta dental.
Aplicar procedimiento.
Realizar remisin (si se requiere).
Promotor de salud
Se encarga de la aplicacin de Biolgico (vacunas) y el diligenciamiento de
Registros. (Diario de vacunacin y los RIPS 2)
Regente de Farmaca
Se encarga de la recepcin y despachos de mercancas a las diferentes
dependencias, revisa y actualiza el inventario de la farmacia y elabora informes
sobre el despacho y recepcin de medicamentos de control.
Secretaria
Persona encargada de gestionar los documentos relacionados con los
contratos realizados con las ARS, la elaboracin de informes y la atencin al
cliente.
Software PAIDSA
Registra los datos sobre biolgico y jeringas utilizando el Software PAIDSA, el
cual genera el Informe Mensual de de dichas actividades.
Tesorero
Se encarga del envo de copias de las facturas glosadas solicitadas, de la
recepcin y anlisis del concepto emitido y gestiona la cancelacin total de las
facturas glosadas.
- 112 -
Diagrama Actor / Role (segn el Proceso del Negocio)
Figura 52. Diagrama Actor / Role: Gestionar atencin al cliente
Gestionar calidad
Figura 53. Diagrama Actor / Role: Gestionar calidad
- 113 -
Gestionar citas
Figura 54. Diagrama Actor / Role: Gestionar cltas
Gestionar consultas
cd Consultas
Business Process
Gestionar Consultas
Role
Role
Role
Role
Role
Auxiliar
Bacterilogo
Caj ero
Auxiliar
Administrativ o
Mdico
Responsable
Responsable
Responsable
Responsable
Responsable
Responsable
Responsable
Actor
Actor
Actor
Actor
Actor
Auxiliar de Citas
Actor
Actor
Auxiliar de
Laboratorio
Auxiliar de
Enfermera
Bacterilogo
Caj ero
Auxiliar
Administrativ o
Mdico
Figura 55. Diagrama Actor / Role: Gestionar consultas
- 114 -
Gestionar contratos con ARS

cd Gestionar Contratos con ARS
Business Process
Elaborar Contratos con
ARS
Role
Role
Jefe de la Div isin de

Atencin en Salud
Secretaria
Responsable
Responsable
Actor
Actor

Atencin en Salud
Secretaria
Figura 56. Diagrama Actor / Role: Elaborar contratos con ARS

cd Gestionar Examen de Laboratorio
Business Process
Gestionar Examen de
Laboratorio
Role
Role
Auxiliar
Bacterilogo
Actor
Actor
Auxiliar de
Laboratorio
Bacterilogo
Figura 57. Diagrama Actor / Role: Gestionar examen de laboratorio

- 115 -
Gestionar facturacin
cd Gestionar Facturacin
Business Process
Role
Caj ero
Responsable
Actor
Caj ero
Figura 58. Diagrama Actor / Role: Gestionar Facturacin
Gestionar glosas
cd Gestionar Glosas
Business Process
Gestionar Glosas
Role
Role
Jefa de la Div isin de

Atencin en Salud
Tesorero
Responsable
Responsable
Actor
Actor

Atencin 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 hospitalizacin
- 117 -
Elaborar informes
Figura 62. Diagrama Actor / Role: Elaborar informes
cd Gestionar Personal Mdico y Paramdico

Business Process
Gestionar Personal Mdico y
Paramdico
Role
Role
Role
Coordinar IPS

de Personal

Atencin en Salud
Responsable
Responsable
Responsable
Actor
Actor
Actor
Coordinador IPS
Jefe del Departamento de

Personal

Atencin en Salud
Figura 63. Diagrama Actor / Role: Gestionar Personal mdico y Paramdico
- 118 -
Gestionar programas de DI DP PE
cd Gestionar Programas DI - DP - PE
Business Process
Gestionar Programas DI - DP - PE
Role
Auxiliar
Responsable
Role
Role
Role

Atencin en Salud
Jefe de Promocin y
Prev encin
Mdico
Responsable
Responsable
Responsable
Responsable
Actor
Actor
Actor
Actor
Actor
Jefe de
Enfermera

Atencin en Salud
Jefe de Promocin y
Prev encin
Mdico
Mdico
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 Promocin y
Prev encin
Mdico
Responsable
Responsable
Responsable
Responsable
Responsable
Responsable
Actor
Actor
Actor
Actor
Actor
Actor
Auxiliar de
Enfermera
Jefe PAI
Jefe PAI
Jefe de Promocin y
Prev encin
Mdico
Mdico
Coordinador
Figura 65. Diagrama Actor / Role: Gestionar coves
- 119 -
cd Gestionar Equipos e Insumos

Business Process
Gestionar Equipos e
Insumos
Role
Role
Role
Auxiliar
Administrativ o
Digitador
Jefe de Promocin y
Prev encin
Actor
Auxiliar
Administrativ o
Actor
Actor
Digitador
Jefe de Promocin y
Prev encin
Figura 66. Diagrama Actor / Role: Gestionar Equipos e insumos
Figura 67. Diagrama Actor / Role: Gestionar programas de atencin
- 120 -
Seguir y controlar actividades
Figura 68. Diagrama Actor / Role: Seguir y Controlar actividades
Controlar farmacias satlites

cd Gestionar Farmacias Satlites
Business Process
Controlar Farmacias Sattlites
Role
Auxiliar
Administativ o
Responsable
Actor
Auxiliar
Administrativ o
Figura 69. Diagrama Actor / Role: Gestionar Farmacias satlites
- 121 -
cd Gestionar Inv entario
Business Process
Gestionar Inv entario
Rol e
Role
Role
Auxiliar
Administrativ o
Jefe de Almacn
Regente de
Farmacia
Responsable
Responsable
Responsable
Actor
Actor
Actor
Auxiliar
Administrativ o
Jefe de Almacn
Regente de
Farmacia
Figura 70. Diagrama Actor / Role: Gestionar inventario
cd Gestionar Medicamentos
Business Process
Role
Role
Actor Externo
Auxiliar
Administrativ o
Regente de
Farmacia
Base de Datos
POS - S
Actor
Auxiliar
Administrativ o
Actor
Regente de
Farmacia
Figura 71. Diagrama Actor / Role: Gestionar medicamentos

- 122 -
Gestionar bienes
Figura 72. Diagrama Actor / Role: Gestionar bienes
Gestionar mercancas
cd Gestionar Mercancas
Business Process
Gestionar Mercancas
Role
Role
Role
Jefe de Almacn
Auxiliar
Operativ o
Jefe de Serv icios

Generales
Responsable
Responsable
Responsable
Actor
Actor
Actor
Jefe de Almacn
Auxiliar
Operativ o
Jefe de Serv icios

Generales
Figura 73. Diagrama Actor / Role: Gestionar mercancas
- 123 -
Diagrama Role/Actividad
Auxiliar Administrativo
cd Auxiliar Administrativ o
Actividad
Actividad
Recibir y Codificar
RIPS (IPS)
Organizar informacin
de las farmacias satlites
Role
Auxiliar
Administrativ o
Actividad
Actividad
Controlar ingreso
de medicamentos
Elaborar informaes sobre

medicamentos de control
Actividad
Actividad
Controlar egreso de
medicamentos
Verificar y Organizar
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
Actividad
Recibir y Verificar
datos de los usuarios
Manej ar programas
de salud pblica
Actividad
Comprobar factura
de cancelacin
Role
Actividad
Auxiliar
Entregar frmulas remisiones y/o resultados
Actividad
Diligenciar RIPS
Actividad
Anexar resultados de
laboratorio a HC
Actividad
Opcional
Rev isar rdenes

mdicas
Actividad
Suministrar medicamentos y
elaborar tarj eta de drogas
Actividad
Actividad
Rev isar y Registrar

informacin en la Historia
Clnica del Paciente
Realizar notas
de enfermera
Actividad
Actividad
Actividad
Actividad
Realizar
Tratamiento mdico
Controlar
calidad
Tomar y rotular
muestras
Diligenciar hoj as de
resultados de laboratorio
Opcional
Opcional
Es necesario tener acceso al
rea de laboratoio clnico
Figura 75. Diagrama Role / Actividad: Auxiliar

- 124 -
Opcional
Auxiliar operativo
cd Auxiliar operativ o
Role
Auxiliar
Operativ o
Actividad
Comparar las
caractersticas de la
mercanca con el
contrato de adquisicin
Actividad
Actividad
Despachar elementos
de almacn
Ordenar elementos que

ingresan a almacn
Figura 76. Diagrama Role / Actividad: Auxiliar operativo
Bacterilogo
cd Bacterilogo
Actividad
Role
Actividad
Recibir muestras
Bacterilogo
Control de calidad interno

y externo de los anlisis
Actividad
Actividad
Procesar y producir
resultados de laboratorio
Realizar estadsticas
diarias
Figura 77. Diagrama Role / Actividad: Bacterilogo
Cajero
cd Caj ero
Role
Caj ero
Actividad
Actividad
Rev isar y v erificar datos
de los usuarios
Actividad
Rev isar tarifas preestablecidas
Facturar activ idades y

procedimientos practicados a los
usuarios
Figura 78. Diagrama Role / Actividad: Cajero
- 125 -
Coordinador IPS
cd Coordinador IPS
Role
Coordinador IPS
Actividad
Elaborar informe sobre el diagnstico situacional
de salud del rea de influencia
Figura 79. Diagrama Role / Actividad: Coordinador IPS
Digitador
cd Digitador
Role
Digitador
Actividad
Actividad
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 almacn
Figura 81. Diagrama Role / Actividad: Funcionario comit de bajas

- 126 -
Gerente
cd Gerente
Role
Gerente
Actividad
Actividad
Firmar contratos
con ARS
Gestionar destruccin de
bienes
Actividad
Gestionar donaciones de
bienes
Actividad
Actividad
Gestionar v entas de bienes
Gestionar baj a de bienes
Figura 82. Diagrama Role / Actividad: Gerente
Jefe de Almacn
cd Jefe de Almacn
Acti vi dad
Acti vi dad
Gestionar entrada de
mercancas
Gestionar baj a
de mercancas
Rol e
Jefe de Almacn
Acti vi dad
Acti vi dad
Gestionar salida
de mercancas
Gestionar destruccin
de bienes
Actividad
Acti vi dad
Gestionar Donacin
de bienes
Gestionar v enta
de bienes
Acti vi dad
Acti vi dad
Manej ar inv entario de las

diferentes dependencias
Elaborar informes para

contabilidad
Figura 83. Diagrama Role / Actividad: Jefe de Almacn
Jefe del Departamento de Personal

cd Jefe del Departamento de Personal
Rol e
de Personal
Acti vidad
Validar y v erificar la calidad de los
procesos realizados en la Div isin de
Atencin en Salud
Activi dad
Gestionar Personal
mdico y paramdico
Figura 84. Diagrama Role / Actividad: Jefe del Departamento de Personal
- 127 -
Jefe de Divisin de Atencin en Salud
cd Jefe de Div isin de Atencin en Salud

Actividad
Role
Actividad
Superv isar activ idades y

procesos que se desarrollan en
la div isin
Jefe de Div isin de Atencin en Salud
Actividad
Gestin de la
elaboracin de informes
Actividad
Actividad
Gestin de contratos con

ARS
Gestin de
glosas
Actividad
Verificar la calidad de la
prestacin de serv icios de salud
Figura 85. Diagrama Role / Actividad: Jefe de Divisin de Atencin en Salud
Jefe PAI (Programa Ampliado de Inmunizaciones)

cd Jefe PAI
Role
Jefe PAI
Actividad
Cumplir con los obj etiv os del
Programa Ampliado de
Inmunizaciones
Actividad
Actividades
Controlar las activ idades

relativ as a v acunacin
Participar y Controlar reuniones del

comit de v igilancia epidemiolgica
(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 almacn
Figura 87. Diagrama Role / Actividad: Jefe de Presupuesto y Contabilidad

- 128 -
Jefe de Promocin y Prevencin
cd Jefe de Promocin y Prev encin

Actividad
Role
Actividad
Superv isar las activ idades de

promocin y prev encin
Jefe de Promocin y
Prev encin
Superv isa la existencia y buen uso de

los equipos e insumos
Actividad
Actividad
Gestionar la elaboracin
de informes
Gestionar la elaboracin de
informes Cov es
Figura 88. Diagrama Role / Actividad: Jefe de Promocin y Prevencin
Jefe de Servicios Generales

cd Jefe de Serv icios Generales
Role
Jefe de Serv icios Generales
Actividad
Actividad
Gestionar la compra de
mercancas
Gestionar la baj a y
av alo de bienes
Figura 89. Diagrama Role / Actividad: Jefe de Servicios generales
Jurdico
cd Jurdico
Role
Jurdico
Actividad
Elaborar el concepto j urdico
concerniente al contrato que se realizar
con determinada ARS
Figura 90. Diagrama Role / Actividad: Jurdico
- 129 -
Mdico
cd Mdico
Actividad
Role
Activi dad
Realizar v aloracin
mdica
Mdico
Elaborar y/o aplicar

tratamiento
Actividad
Originar
diagnstico
Activi dad
Diligenciar RIPS
Activi dad
Elaborar
frmula mdica
Actividad
Activi dad
Elaborar rdenes
mdicas
Obtener ayudas
diagnsticas
Si se requi ere
Figura 91. Diagrama Role / Actividad: Mdico
Odontlogo
cd Odontlogo
Actividad
Odontlogo
Actividad
Acti vidad
Activi dad
Valorar al
usuario
Actividad
Elaborar carta
dental
Aplicar
procedimiento
Realizar
remisin
Si se requiere
Figura 92. Diagrama Role / Actividad: Odontlogo
- 130 -
Promotor de salud
cd Promotor de salud
Role
Promotor de
salud
Actividad
Actividad
Aplicar v acunas
Diligenciar
registros
Figura 93. Diagrama Role / Actividad: Promotor de salud
Regente de Farmaca
cd Regente de Farmaca
Role
Regente de
Farmaca
Actividad
Actividad
Actividad
Actividad
Recepcin de
medicamentos
Despacho de
medicamentos
Rev isar y Actualizar el

inv entario
Elaborar
informes
Figura 94. Diagrama Role / Actividad: Regente de farmacia
Secretaria
cd Secretaria
Role
Secretaria
Actividad
Elaborar
informes
Actividad
Actividad
Gestionar los documentos

relacionados con los contratos
realizados con las ARS
Gestioanr
atencin al
cliente
Figura 95. Diagrama Role / Actividad: Secretaria
- 131 -
Tesorero
cd Tesorero
Role
Tesorero
Actividad
Actividad
Actividad
Env iar copia de las

facturas glosadas
Recepcin y anlisis de
concepto emitido
Gestionar cancelacin total de

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 satlite
Agua clara.
La floresta.
- 132 -
Palmarito.
Guaramito.
San Faustino.
Guimaral.
San Martn.
Santa Ana.
San Lus.
San Mateo.
El Prtico.
El contento.
Cundinamarca.
Beln.
Los Alpes.
Loma Bolvar.
Nia CECI.
Policlnico J Atalaya.
Sevilla.
Claret.
Toledo Plata.
Aeropuerto.
Buena Esperanza.
Banco Arena.
Ospina Prez.
La Ermita.
Belisario.
Palmeras.
Antonia Santos.
El rodeo.
o Unidad bsica
La libertad.
- 133 -
Puente Banco Leones.
Comuneros.
Descripcin
IPS Satlite
Son 32 IPS (puestos de salud) distribuidas a nivel urbano y rural del municipio
de Ccuta. Se constituye como el mdulo ejecutor del Sistema General de
Seguridad Social en Salud a travs del cual se suministran los servicios de
salud en favor de los beneficiarios (pertenecientes al rgimen Contributivo,
subsidiado, particulares o vinculados).
Unidad Bsica
Son 4 Unidades bsicas ubicadas en la zona urbana del municipio de Ccuta,

en las cuales se prestan la mayora de los servicios de salud incluyen los
servicios de hospitalizacin y procedimientos quirrgicos.
Responsabilidades
IPS Satlite
o Se prestan los siguientes servicios:
o Medicina general
o Odontologa general
o Actividades de Enfermera
o Actividades de Demanda inducida
o Deteccin precoz y Proteccin especfica
Unidad Bsica
o Se prestan los siguientes servicios:
o Medicina general
o Odontologa general
o Actividades de Enfermera
- 134 -
o Actividades de Demanda inducida

o Deteccin precoz y Proteccin especfica
o Laboratorio clnico
o Optometra
o Radiologa
o Trabajo social
o Servicio de informacin y atencin al usuario
o Ecografa
o Urgencias 24 horas
o Hospitalizacin
o Transporte asistencial bsico
o Electrocardiograma
o RX odontolgico
3.1.1.4 Tecnologas
Recursos humanos y fsicos:
La ESE IMSALUD cuenta con equipos de computacin actualizados junto con

un grupo de personal capacitado para sacar adelante los proyectos de
modernizacin de los SISTEMAS DE INFORMACIN de las dependencias y
por ende de la empresa.
1- Ingeniero de Sistemas.
1- Ingeniero Electrnico.
1- Auxiliar de informacin en Salud.
1- Auxiliar de Oficina.
2- Codificadores.
1- Digitadores software SISVAN.
4- Digitadores RIPS.
Recursos software:
Software SISVAN
- 135 -
Software de Facturacin 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
Ley 100 de 1993
Ley 387 de 1997
Decreto 1750 de 2003
Decreto 1760 de 1990
Acuerdo 117 del CNSSS
Acuerdo 83 de 1920
Descripcin
La ley 100 establece el Sistema General de
Seguridad Social en Salud, desarrolla los
fundamentos que lo rigen, determina su
direccin, organizacin y funcionamiento, sus
normas administrativas, financieras y de
control y las obligaciones que se derivan de
su aplicacin.
Los objetivos del Sistema General de
Seguridad Social en Salud son regular el
servicio pblico esencial de salud y crear
condiciones de acceso en toda la poblacin al
servicio en todos los niveles de atencin.
Por la cual se adoptan medidas para la
prevencin del desplazamiento forzado; la
atencin,
proteccin,
consolidacin
y
estabilizacin
socioeconmica
de
los
desplazados internos por la violencia en la
Repblica de Colombia.
Las Empresas Sociales del Estado tienen por
objeto la prestacin de los servicios de salud,
como servicio pblico esencial a cargo del
Estado o como parte del servicio pblico de la
seguridad social
Para efectos de este Decreto se entiende por
nivel de atencin la responsabilidad del ente
territorial en la organizacin de los servicios
de salud a travs de una o varias entidades
para satisfacer las necesidades de salud de
su poblacin.
las entidades administradoras del Rgimen
Subsidiado y de las entidades territoriales, de
acuerdo con sus competencias, ejecutar
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 Rgimen Subsidiado
Definir los medicamentos esenciales y
alternativos segn 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 -
Resolucin 0412 de 2000
Aplicacin de procedimientos segn rangos

de edad pre-establecidos
ndices de rendimiento y calidad del ministerio

de salud.
Atencin segn el rgimen de salud al cual

pertenezca el usuario.
Prestacin de servicios segn especialidad de

los profesionales de salud.
Atencin de salud segn

complejidad del paciente.
Creacin
Naturaleza Jurdica
el
nivel
de
procedimientos e intervenciones de demanda

inducida y obligatorio cumplimiento y se
adoptan las normas tcnicas y guas de
atencin para el desarrollo de las acciones de
proteccin especfica y deteccin temprana y
la atencin de enfermedades de inters en
salud pblica.
Dentro de la empresa se definieron ciertos
rangos de edades, segn los cuales se puede
prestar la atencin necesaria a las personas
de acuerdo a su condicin y clasificacin.
Consulta externa 15 20 minutos de
atencin.
Consulta mdico-especializada 20 25
minutos de atencin.
Urgencias Sin restriccin. Disponible las 24
horas.
Hospitalizacin Duracin superior a 24
horas.
Rgimen subsidiado Tienen derecho al
Rgimen
Subsidiado
las
personas
pertenecientes a los niveles 1 y 2 del
SISBEN, quienes podrn acceder a travs de
un subsidio total y las personas del rea
urbana pertenecientes a los niveles 2 y 3 del
SISBEN, quienes podrn acceder a travs de
un subsidio parcial.
Rgimen contributivo pertenecen a este
rgimen todos los empleados, trabajadores
independientes (ms de 1 salario mnimo) y
pensionados.
Particular y Vinculado
La prestacin de los servicios de salud se
realiza segn la especialidad que requiera el
usuario y el programa al cual pertenezca.
Baja complejidad Atencin, estabilizacin y
resolucin.
Alta complejidad Se remite segn sistema
de referencia y contrarreferencia.
Por la cual se fijan algunos lineamientos en
relacin con el Registro Individual de
Prestacin de Servicios de Salud, RIPS.
por la cual se adopta la Primera Actualizacin
de la Clasificacin nica de Procedimientos
en Salud
Por la cual se reglamentan los datos bsicos
que deben reportar los prestadores de
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
087 del 29 de Enero de 1999 emanado del
honorable concejo Municipal de San Jos de
Ccuta
Es una entidad pblica descentralizada del
orden Municipal dotados personera jurdica,
autonoma administrativa y patrimonio propio
- 137 -
adscrita a la direccin local de salud,

integrante del Sistema General de Seguridad
Social en Salud sometido al rgimen jurdico
previsto en la ley 100 y sus decretos
reglamentarios.
La Empresa Social del Estado del Primer
Nivel de Atencin en Salud del Municipio de
San Jos de Ccuta, tiene jurisdiccin en
todo el territorio del Municipio de San Jos de
Ccuta, su domicilio y sede de sus
organismos administrativos en la Ciudad de
Ccuta.
Jurisdiccin
Tabla 6. Reglas del negocio
3.1.1.6 Objetos del negocio
Objeto
Actas de reuniones
COVE
Afiliacin
Centro de costos de
servicios
Cita
Contrato
Atributos
Identificacin del acta
Fecha
Descripcin
Nmero de carnet
Tipo de usuario (contributivo, subsidiado,
vinculado, particular, desplazado, otro).
Tipo de afiliacin (cotizante, beneficiario, otro
miembro, adicional)
Ficha sisben
Puntaje sisben
Zona (urbano, rural)
Identificacin de la entidad
Historia clnica (tiene si / no)
Discapacidad
Cdigo
Descripcin
Unidad funcional
Cuenta de ingresos
Concepto de cartera
Usuario
Identificacin del profesional
Observaciones
Tipo de asignacin
Fecha
Cantidad
Hora de inicio
Hora fin
Lugar de la cita
Forma de solicitud
Nmero de factura
Nmero
Fecha de inicio
Fecha de vencimiento
Descripcin
Tipo de contrato
Tipo de pago
- 138 -
Mtodos
Crear
Modificar
Eliminar
Consultar
Registrar
Modificar
Eliminar
Consultar
Crear
Modificar
Eliminar
Consultar
Crear
Registrar
Modificar
Eliminar
Cancelar
Consultar
Crear
Modificar
Eliminar
Consultar
Tipo de pliza
Valor total
Valor mximo mensual
Nmero de afiliados
Entidad
Tarifa POS
Tarifa no POS
Observaciones
Datos de integracin con otros mdulos
Departamento
Diagnstico
Disponibilidad del
Profesional
Entidad
Factura
Glosas
Historia Clnica
Cdigo
Descripcin
Identificacin del diagnstico
Tipo de diagnstico
Especialidad
Descripcin
Cdigo del profesional
Fecha inicial
Fecha final
Tiempo
Cupo
Cdigo
NIT
Razn social
Direccin
Telfono
Representante
Tipo de entidad
Municipio
Cdigo del concepto de cartera (integracin con
otros mdulos)
Nmero
Fecha
Hora
Tipo de factura
Estado (asentada)
Tipo de ingreso
Identificacin del cajero
Identificacin del usuario
Identificacin del contrato
Programa
Autorizacin
Fecha de autorizacin
Servicio prestado
Observaciones
Profesional que remisiona
Profesional que la elabora
Identificacin de la glosa
Fecha
Observaciones
Nmero de Historia Clnica
Fecha Hora
Identificacin de usuario
Identificacin de RIPS
Identificacin de Profesional de salud
- 139 -
Crear
Modificar
Eliminar
Consultar
Crear
Registrar
Modificar
Consultar
Crear
Registrar
Modificar
Actualizar
Eliminar
Consultar
Crear
Modificar
Eliminar
Consultar
Crear
Modificar
Eliminar
Consultar
Crear
Modificar
Eliminar
Consultar
Crear
Registrar
Modificar
Actualizar
Informes
Informes de IPS
Inventario
IPS Satlite
Kardex
Lugar de servicio
Manuales tarifarios
Medicamento
Municipio
Profesional de salud
Motivo de consulta
Datos de Enfermera (toma de signos vitales)
Antecedentes
Anamnesis
Examen general (procedimientos aplicados)
Diagnstico
Tratamiento
Identificacin del informe
Fecha
ttulo
Descripcin
Elaborado por
Recibido por
Identificacin del informe
Fecha
Ttulo
Descripcin
IPS
Recibido por
Identificacin del inventario
Fecha de actualizacin
Identificacin
Nombre
Direccin
Telfono
Identificacin del elemento (bien)
Nombre
Descripcin
Cdigo
Descripcin
Cdigo
Descripcin
Identificacin del servicio
Identificacin de la tarifa
Referencia
Nombre
Lote
Fecha de vencimiento
Fabricante
Clasificacin (legal)
Identificacin del inventario
Cdigo
Nombre
Cdigo del departamento
Cdigo
Cdula
Fecha
Nombre
Especialidad
Direccin
Telfono
Celular
Consultar
Crear
Modificar
Eliminar
Consultar
Crear
Modificar
Eliminar
Consultar
Crear
Modificar
Consultar
Crear
Modificar
Eliminar
Consultar
Crear
Modificar
Descargar
Consultar
Crear
Modificar
Eliminar
Consultar
Crear
Modificar
Eliminar
Consultar
Registrar
Modificar
Descargar
Consultar
Crear
Modificar
Eliminar
Consultar
Registrar
Modificar
Actualizar
Eliminar
Consultar
- 140 -
Programa de atencin
Pruebas de calidad
RIPS
RIPS de Consulta
RIPS de
Hospitalizacin
RIPS de medicamentos
RIPS de Procedimiento
RIPS Recin nacidos
RIPS de urgencias
Servicios de salud
Correo
Registro profesional
Tipo de persona
Estado
Porcentaje de pago
Cdigo
Descripcin
Sexo
Edad inicial
Edad final
Identificacin de la prueba
Fecha
Contenido
Identificacin del usuario
Identificacin de la factura
Fecha
Servicio
Finalidad
Causa externa
Fecha Hora ingreso
Autorizacin
Va ingreso
Causa externa
Estado de salida
Identificacin de diagnstico
Fecha
Identificacin del medicamento
Tipo (POS - no POS)
Fecha
Servicio
mbito (ambulatorio, hospitalario, urgencias)
Finalidad
Persona que atiende
Acto quirrgico
Fecha
Control prenatal
Edad gestasional
Sexo
Peso
Fecha de muerte
Fecha Hora de ingreso
Destino al salir
Estado (vivo - muerto)
Fecha Hora salida
Cdigo interno
Cdigo SOAT
Cdigo CUP
Cdigo ISS
Descripcin
Especialidad
POS (si / no)
- 141 -
Crear
Modificar
Eliminar
Consultar
Crear
Modificar
Eliminar
Consultar
Registrar
Modificar
Consultar
Registrar
Modificar
Consultar
Registrar
Modificar
Consultar
Registrar
Modificar
Consultar
Registrar
Modificar
Consultar
Registrar
Modificar
Consultar
Registrar
Modificar
Consultar
Crear
Modificar
Eliminar
Consultar
Tarifa
Unidad Bsica
Unidad funcional
Usuario
Factor (manual de tarifas)

Aplica a sexo
Edad
Tipo de RIPS
mbito
Identificacin del manual tarifario
Identificacin del servicio
Valor
Identificacin
Nombre
Direccin
Telfono
Cdigo
Descripcin
Identificacin
Tipo de documento
Nombres
Apellidos
Direccin
Telfono
Barrio
Ocupacin
Estado civil
Nombre del Padre
Nombre de la madre
Observaciones
Nmero del carnet
Tabla 7. Objetos del negocio
- 142 -
Crear
Modificar
Eliminar
Consultar
Crear
Modificar
Eliminar
Consultar
Crear
Modificar
Eliminar
Consultar
Registrar
Modificar
Actualizar
Eliminar
Consultar
cd Diagrama de obj etos

Profesional de salud
Disponibilidad del
Profesional
Prueba de calidad
Informe de IPS
IPS Satlite
Actas de reuniones
COVE
Kardex
Inv entario
Entidad
Departamento
Afiliacin
Municipio
Medicamento
Cita
Usuario
Historia Clnica
Figura 98. Parte del diagrama de objetos
- 143 -
3.1.1.7 Eventos
Evento
Clasificacin
Registrar o actualizar datos de usuario

Revisin de enfermera
Ejecutar consulta
Facturar servicio
Orden de hospitalizacin
Orden de laboratorio
Solicitud de informe
Solicitud de informacin o quejas
Recepcin de glosas
Solicitud de personal
Solicitud de contrato
Control de calidad del personal
Realizar un balance sobre la prestacin de servicios
Solicitud de atencin
Solicitud de equipos e insumos
Reunin segn calendario epidemiolgico
Solicitud de Medicamentos
Actualizar inventario
Control logstico de farmacias satlites
Solicitud de mercanca
Revisin de bienes
Asignar o modificar citas
Casual
Casual
Programado
Casual
Casual
Casual
Programado
Casual
Programado
Casual
Casual
Programado
Programado
Casual
Casual
Programado
Casual
Casual
Programado
Casual
Casual
Casual
interno
interno
interno
interno
interno
interno
interno
externo
interno
externo
externo
interno
interno
externo
interno
interno
interno
interno
interno
interno
Interno
interno
Tabla 8. Eventos del negocio
3.1.2. Modelo del equipo
Lder del Proyecto
Funciones:
Nombre
Cargo
Telfono
Mail
Planea, maneja y asigna recursos, asigna prioridades a los procesos as

como fijar metas al equipo del proyecto, interacciona con los clientes y
usuarios, establece un sistema de prcticas que aseguran la integridad y
la calidad de los artefactos del proyecto.
Holger Andrs Cceres Medina
Vicerrector de Gestin y Desarrollo Tecnolgico
(*7) 5682022
vicegdtec@unipamplona.edu.co
Tabla 9. Lder del Proyecto
Usuarios expertos
Funciones:
Es el personal de la ESE IMSALUD que apoya al lder y analistas para

obtener los criterios unificados durante el proyecto, este equipo de trabajo
esta conformado con personal tcnico y administrativo con conocimiento
- 144 -

de los procesos y procedimientos que realiza IMSALUD.
Miguel Tonino Botta

Nombre
Cargo
Telfono
Mail
(Interviene en el momento de tomar decisiones que involucren el riesgo del

desarrollo del convenio.)
Gerente
5843434-5843031 Ext. 209
eseimsalud@hotmail.com
Yolanda Snchez
Nombre
Cargo
(Quien expresa las necesidades de la institucin con criterio unificado

apoyado en su equipo de trabajo. Quien esta a cargo por la institucin de
llevar feliz termino el proyecto. Encargado de la coordinacin de las
actividades al interior de la institucin, y de la comunicacin con la
Universidad de Pamplona. Debe resolver asuntos del convenio y escalar
los asuntos dentro de la organizacin del Instituto Municipal de Salud
Ccuta, segn sea necesario.)
Profesional universitario informtica
Telfono
5843434 Ext. 102 - 103
Mail
yosanar@hotmail.com
Nombre
Luz ngela Diaquiz
Cargo
Tcnico financiero
Telfono
5843434
Mail
Tabla 10. Usuarios expertos
Analistas del negocio
Funciones:
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 informacin proporcionada por los
usuarios expertos.
Mantiene informado al lder del proyecto de todas las actividades
realizadas.
Nombre
Johana Garca Poveda
- 145 -

Cargo
Subdireccin de Producto
Telfono
Mail
(*7) 5686367 - 3133764884

producto.plataforma@unipamplona.edu.co
Nombre
Yesenia Barrera Rangel
Cargo
Analista de consultora
Telfono
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 atencin al cliente
Figura 99. Diagrama de actividad: Gestionar atencin al cliente
Gestionar calidad
Figura 100. Diagrama de actividad: Gestionar calidad
- 146 -
Gestionar cita
Figura 101. Diagrama de actividad: Gestionar cita
Gestionar consultas
Figura 102. Diagrama de actividad: Gestionar consultas
Elaborar contrato con ARS
ad Contrato con ARS
Actividad
Transcripcin de
contratos
Elaborar minuta
contractual
send
Enviar contratos
a divisin
encargada
Actividad
Elaborar concepto
receive
Recibir
concepto
Enviar contrato a ARS
para du legalizacin
Figura 103. Diagrama de actividad: Gestionar contrato con ARS
- 147 -
Gestionar servicio de enfermera
Figura 104. Diagrama de actividad: Gestionar servicio de enfermera
Figura 105. Diagrama de actividad: Gestionar facturacin
Gestionar glosas
Figura 106. Diagrama de actividad: Gestionar glosas
Figura 107. Diagrama de actividad: Gestionar Historia clnica y RIPS
- 148 -
Figura 108. Diagrama de actividad: Gestionar hospitalizacin
Elaborar informes
Figura 109. Diagrama de actividad: Elaborar informes
Figura 110. Diagrama de actividad: Gestionar examen de laboratorio
- 149 -

ad Personal
Solicitud de personal
Actividad
Coordinar oficios de
traslados o
asignacin
Realizar notificacin
de actos
administrativos
Figura 111. Diagrama de actividad: Gestionar Personal mdico y paramdico
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 atencin
Seguir y controlar actividades de promocin y prevencin
Figura 116. Diagrama de actividad: Seguir y controlar actividades de Promocin y

Prevencin
Gestionar farmacias satlites
Figura 117. Diagrama de actividad: Gestionar farmacias satlites
- 151 -
Figura 118. Diagrama de actividad: Gestionar medicamentos
Figura 119. Diagrama de actividad: Gestionar inventario
Gestionar bienes
Figura120. Diagrama de actividad: Gestionar bienes
- 152 -
Gestionar mercancas
Figura 121. Diagrama de actividad: Gestionar mercancas
- 153 -
4. METODO PROPUESTO PARA LA OBTENCION DE REQUERIMIENTOS
4.1 ANALISIS DE TECNICAS Y HERRAMIENTAS
Las tcnicas y herramientas seleccionadas para el desarrollo de la obtencin

de requerimientos estn clasificadas segn la actividad de la ingeniera de
requerimientos a la cual proporciona soporte, su utilidad, facilidad de aplicacin
y las ventajas que se derivan de sus resultados.
A continuacin se presenta una tabla con las principales caractersticas de las
tcnicas y herramientas empleadas en la ingeniera de requerimientos.
Nombre
Entrevistas
Clasificacin
Tcnica
Actividad(es)
Extraccin
Cuestionarios
Herramienta
Extraccin
Sistemas
existentes
Tcnica
Extraccin y
Anlisis
Grabaciones
de video y de
audio
Brainstorming
(Tormenta de
Herramienta
Herramienta
Extraccin y
Anlisis
Extraccin y
Anlisis
- 154 -
Ventajas
Tcnica conocida, fcil
de aplicar, permite
estudiar el dominio del
problema,
comunicacin
y
retroalimentacin con
el usuario / cliente.
Herramienta fcil de
aplicar, comprensible,
vara segn el tipo de
preguntas aplicadas y
su enfoque objetivo.
til para analizar las
salidas de los sistemas
actuales
de
la
organizacin, permite
descubrir
requerimientos
importantes,
son
sistemas
que
presentan estabilidad
en el dominio del
problema.
Permite
centrar
la
atencin
en
la
entrevista, analizar los
temas
con
ms
detenimiento, captura
el proceso de trabajo.
Genera ideas, permite

obtener varias vistas
Desventajas
Requiere
disposicin
cliente.
del
Estn
limitados
por el tipo de
preguntas y el
objetivo que se
busca.
Diferencia en el
enfoque
y
concepcin
del
sistema,
necesidad
(expresada por el
usuario)
de
mejorar
la
aplicacin actual.
Autorizacin
cliente.
del
Generacin
de
mltiples
ideas
inconexas,
inversin
de

ideas)
del problema.
Arqueologa
de
documentos
Herramienta
Extraccin y
Anlisis
Aprendiz
Tcnica
Extraccin
Observacin
Tcnica
Extraccin
Herramienta
Extraccin
Run
Use
Case
Workshop
(talleres)
Prototipo
bosquejado
Prototipo
tangible
Usable
Herramienta
DOFA
Cadena
valor
de
Modelo
de
Ayuda a determinar
posibles
requerimientos
implcitos
en
los
resultados o salidas de
los sistemas de uso
actual.
Permite observar el
trabajo en tiempo real,
realizar bosquejos para
cada
actividad
a
sistematizar, obtener la
informacin que est
en la cabeza del
cliente.
Comprensin de los
procesos y su entorno,
permite
identificar
estructuras y patrones,
facilita la abstraccin.
Definir
actores,
escenarios, secuencia
de
actividades,
eventos,
retroalimentacin
continua del cliente.
Retroalimentacin por
parte del cliente /
usuario, poco tiempo y
esfuerzo
en
la
aplicacin de cambios.
Extraccin
Anlisis y
Especificacin
Herramienta
Extraccin
Especificacin
y Validacin
Herramienta
Anlisis
Herramienta
Anlisis
Anlisis
- 155 -
Permite visualizar los

requerimientos
no
funcionales,
retroalimentacin,
validacin de entradas
y salidas.
Permite identificar las
debilidades,
oportunidades,
fortalezas y amenazas
del sistema.
Identificar
las
actividades
estratgicas
de
la
empresa, anlisis de
costos
y
funcionamiento
de
cada actividad.
Identificar
conceptos
del
dominio
del
tiempo
en
clasificacin
y
eliminacin
de
ideas.
Bases
incorrectas,
las
cuales se quieren
mejorar
y
posiblemente no
se
tenga
en
cuenta este factor
Requiere mucho
tiempo,
disposicin
del
cliente.
Inversin grande
de tiempo por
parte del analista.
Se necesita tener
un
bosquejo
inicial de casos de
uso.
El usuario no
alcanza
a
visualizar
el
dilogo hombremquina
(requerimiento no
funcional)
Costo
de
realizacin,
entrenamiento,
confusin de los
usuarios
por
incompletitud.
Es
contar
necesario
con un

clase
conceptual
Diagrama
pescado
de
Herramienta
Especificacin
Herramienta
Extraccin
Anlisis y
Especificacin
Glosario
Herramienta
DCO
Tcnica
Diagrama
actividad
de
ESRE
Herramienta
Tcnica
Extraccin
Anlisis
Especificacin
y Validacin
Anlisis y
Especificacin
Anlisis y
Especificacin
Extraccin
Anlisis
Especificacin
y Validacin
Extraccin
Anlisis
Especificacin
y Validacin
Casos de uso
Herramienta
Casa
de
calidad o QFD
Herramienta
Validacin
Checklist
Herramienta
Especificacin
y Validacin
problema, comprensin
de la terminologa,
facilita la construccin
del glosario.
Impacto
de
las
soluciones planteadas
en
la
empresa,
organizacin de ideas.
Mejora
la
comunicacin
intergrupal,
con
el
cliente, mitiga el riesgo
de malos entendidos.
Comprensin
del
entorno del negocio,
funcionamiento
e
interaccin
con
el
ambiente,
permite
modelar
recursivamente
la
empresa
en
sus
diferentes niveles.
Permite representar las
actividades, flujos de
informacin,
condiciones
y
restricciones.
Especificar
requerimientos
sistema.
los
del
Especifica
el
funcionamiento
del
sistema, describe la
secuencia
de
interacciones entre el
sistema y los actores,
descripcin
de
un
conjunto
de
escenarios.
Representa la relacin
de qu (requerimiento)
con el cmo (casos de
uso),
control
de
calidad.
Evaluar
cada
requerimiento,
recuerdan que se debe
buscar y ajustar.
Tabla 12. Anlisis de Tcnicas y Herramientas
- 156 -
glosario
dominio
problema
del
del
Dependiente del
caso de estudio,
interpretacin
sesgada.
Requiere continua
actualizacin.
Herramienta
no
apta
para
la
comprensin del
usuario,
este
requiere
cierta
capacitacin.
Slo
incluye
requerimientos
del producto.
4.2 TECNICAS Y HERRAMIENTAS SELECCIONADAS
Las herramientas y tcnicas que fueron seleccionadas para este proyecto se

describen a continuacin. El criterio de seleccin se bas en: facilidad de uso,
utilidad, resultados, tiempo, recursos y personal (equipo de trabajo).
Actividad
Tcnica
Entrevista
Sistemas existentes
ESRE
Captura
Anlisis
DCO
ESRE
Especificacin
ESRE
Validacin
ESRE
Herramienta
Cuestionario
Glosario
Casos de uso
Lista de requerimientos
Cadena de Valor
Glosario
Casos de uso
Modelo de clase conceptual
Modelo de clase conceptual
Glosario
Casos de uso
Casos de uso
QFD
Tabla 13. Tcnicas y Herramientas seleccionadas
4.3 METODO PARA LA OBTENCION DE REQUERIMIENTOS
Luego de haber estudiado y analizado la informacin y materiales a los cuales

se pudo acceder, en el presente trabajo se propone la definicin de un mtodo
iterativo e incremental para la Ingeniera 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 an siguen sin resolverse.
Este mtodo conformado por cuatro etapas fundamentales, anlogas a las
actividades
de
la
ingeniera
de
requerimientos:
Captura,
Anlisis,
Especificacin y Validacin de requerimientos, trata de salvar la brecha entre

las etapas iniciales del desarrollo de software y las fases posteriores,
permitiendo que las mismas continen hacia la obtencin de un software que
solucione y soporte los problemas y necesidades del usuario.
- 157 -
En cuanto a la no aplicabilidad general de los mtodos investigados, unas

veces es consecuencia de las caractersticas particulares del proyecto,
problemas derivados de cuestiones econmicas, otras de restricciones de
ndole tecnolgica, motivo por el cual se decide que el mtodo propuesto debe
ser lo suficientemente flexible y centrado en el usuario como para permitir se
adecue a las organizaciones segn su negocio y asuntos sociales, econmicos,
tecnolgicos y medioambientales.
Para obtener buenos resultados de este
mtodo se recomienda emplear a la par el plan de gestin de requerimientos

de la organizacin segn la metodologa de desarrollo de software que
implementen.
Antes de aplicar el mtodo se requiere el establecimiento del equipo de trabajo.
Captura
Recolectar y clasificar requerimientos.
Priorizar los requerimientos.
Retroalimentacin del cliente / usuario.
Anlisis
Verificar la correspondencia de los requerimientos con las metas de la
organizacin y las necesidades de los clientes / usuarios.
Plantear modelos y diagramas lgicos.
Retroalimentacin del cliente / usuario.
Especificacin
Elegir la herramienta para la especificacin de requerimientos.
Especificar
los
requerimientos
de
acuerdo
la
herramienta
seleccionada.
Validacin
Validar la correspondencia entre requerimientos y casos de uso.
- 158 -
Figura 122. Mtodo propuesto para la obtencin de requerimientos
Captura
Anlisis
Especificacin
Recolectar y
clasificar
requerimientos
Verificar
correspondencia
de
requerimientos
con metas y
necesidades
Elegir
herramienta
Priorizar
requerimientos
Plantear modelos
y diagramas
lgicos
Especificar
requerimientos
Retroalimentac
in del cliente /
usuario.
Retroalimentac
in del cliente /
usuario.
Validacin
Validar
correspondencia
entre
requerimientos y
casos de uso
Figura 123. Etapas y sub-Etapas mtodo propuesto para la obtencin de requerimientos
- 159 -
Establecer el equipo de trabajo Es necesario contar con profesionales

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

tcnicas preestablecidas, con el objetivo de capturar requerimientos, como el
mtodo es iterativo e incremental se puede contar en cada ciclo con diferentes
requerimientos, requerimientos refinados, priorizados y / o cambios segn el
plan de gestin de requerimientos establecido por la organizacin.
Cada
requerimiento se va clasificando para su posterior tratamiento.
Priorizar requerimientos Se procede a priorizar los requerimientos para su

posterior desarrollo segn las necesidades de los clientes / usuarios.
Retroalimentacin del cliente / usuario Una vez estn clasificados y

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

organizacin y las necesidades de los clientes / usuarios En esta subetapa se debe rastrear cada uno de los requerimientos con las metas de la
organizacin y el negocio como tal, para esto se recomienda analizar el modelo
del negocio, utilizar la Tcnica 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 lgicos Para una mejor comprensin y

asociacin de los requerimientos de software y el mundo real, se pueden
realizar modelos y diagramas lgicos, obteniendo de esta manera una
formalizacin de los requerimientos al lograr plasmarlos en una vista y lenguaje
tcnico.
Retroalimentacin del cliente / usuario Se utilizan las vistas lgicas y se

le explican a los clientes, los cuales podrn expresar sus aportes sobre el
procedimiento y secuencia de eventos, interacciones, flujos de informacin y
dems situaciones que sean relevantes.
4.3.3 Especificacin:
Elegir la herramienta para la especificacin de requerimientos La

herramienta software es decisin del equipo de trabajo, el cual puede
seleccionarla segn las polticas y normas de la empresa, esta debe ser formal
o semiformal.
Especificar los requerimientos de acuerdo a la herramienta seleccionada

Representar el requerimiento segn la base seleccionada en la sub-etapa
anterior.
4.3.4 Validacin:
Validar la correspondencia entre requerimientos y casos de uso Cada

caso de uso debe ser una representacin y solucin 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 utilizacin de la
herramienta QFD).
- 161 -
4.3.5 Prcticas:
Desarrollo iterativo e incremental: Este tipo de prctica permite centrar la

atencin en una porcin de los requerimientos, en cada iteracin se adicionan
nuevos requerimientos hasta alcanzar la mayora de ellos. Se realiza un diseo
inicial de acuerdo con los requerimientos claves.
Luego se descubren los
defectos en los resultados de la iteracin y estos se corrigen en la siguiente

iteracin, en la cual se incorporan las cuatro etapas del mtodo.
Desarrollo basado en casos de uso: El mtodo recomienda organizar los

requerimientos funcionales en casos de uso. Esta prctica provee un mejor
entendimiento de la importancia de los requerimientos segn 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 comunicacin entre el equipo de trabajo a nivel

interno y a nivel externo con el cliente.
Centrado en el Usuario: Permite obtener retroalimentacin del usuario en

cada ciclo, centrarse en sus necesidades y garantizar que los requerimientos
se ajusten a su realidad organizacional.
- 162 -
4.4 APLICACIN DEL METODO A LA OBTENCION DE REQUERIMIENTOS
4.4.1. Captura
Ciclo
1y2
Tcnica
Entrevista
Recolectar y Clasificar Requerimientos

Herramienta
Descripcin
Cuestionario
1y2
Sistema
existente
Manual
usuario
1y2
ESRE
Glosario
de
La entrevista se plane con

anticipacin, se estableci
fecha, lugar y hora. En ella
se utiliz un cuestionario
elaborado previamente con
preguntas cerradas para
concretar necesidades y
algunas preguntas abiertas,
en las cuales los clientes
expresaban con sus propias
palabras los problemas que
consideran
fundamentales
resolver y las expectativas
que poseen con relacin al
sistema por desarrollar.
Se hizo uso de un manual de
usuario y la observacin del
software
actual
de
la
empresa, por medio de l se
complementaron
requerimientos que de otra
forma no hubiera sido
posible obtener, adems se
verificaron las entradas y
salidas de dicha aplicacin.
Debido a que esta aplicacin
ya pas la curva de
estabilizacin y control del
dominio del problema los
requerimientos extrados son
confiables y se pueden
moldear
a
la
nueva
propuesta.
Se inici con la creacin del
glosario para garantizar una
buena comunicacin entre el
equipo de trabajo y los
clientes, reduciendo de esta
manera los riesgos de
ambigedades
y
malas
interpretaciones. Luego se
procedi con la realizacin
del
documento
de
especificacin
de
requerimientos, en el cual se
incluyen
slo
los
requerimientos del producto,
aquellos de tipo funcional.
- 163 -
Requerimientos
Obtenidos
Atencin al cliente, Cita,

Consultas,
Enfermera,
Facturacin,
Historia
clnica,
RIPS,
Hospitalizacin, Examen
de
laboratorio,
Programas de DI DP
PE, Equipos e insumos,
Programas de atencin,
Actividades
de
Promocin y Prevencin,
Medicamentos.
Calidad,
Contratos,
Glosas,
Informes,
Personal
mdico
y
paramdico,
Coves,
Farmacias
satlites,
Inventario,
Bienes
Mercancas.
1y2
Ciclo
ESRE
Tcnica
1y2
Se clasifica cada uno de los

requerimientos
en
funcionales y no-funcionales.
Casos de Uso
Con
los
requerimientos
funcionales se establecen
unos casos de uso iniciales,
los cuales se describen para
posterior validacin 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
Herramienta
Descripcin
Lista
de
requerimientos
Se
priorizan
los
requerimientos segn la
opinin de los usuarios
obtenida en la primera
entrevista. Prioridad de 1 a
5, 1 es el ms importante.
Requerimientos y
prioridad
1: Cita,
Enfermera,
Facturacin,
Historia
clnica, RIPS.
2: Consultas,
Hospitalizacin, Examen
de
laboratorio,
Programas de DI DP
PE,
Programas de
atencin, Actividades de
Promocin y Prevencin.
3: Atencin al cliente,
Medicamentos, Informes,
Personal
mdico
y
paramdico, Inventario.
4: Equipos e insumos,
Farmacias
satlites,
Bienes, Mercancas.
5: Calidad, Contratos,
Glosas, Coves.
Retroalimentacin
Ciclo
Tcnica
1y2
Herramienta
Descripcin
Se presenta ante el usuario el glosario, ESRE y la lista
de requerimientos priorizada para su aceptacin,
cambios o rechazo.
Tabla 14. Etapa de Captura de Requerimientos
4.4.2. Anlisis
Verificar la correspondencia de los requerimientos con las metas de la organizacin y las

necesidades de los clientes / usuarios
Ciclo Tcnica Herramienta
Descripcin
Se aplica la tcnica DCO por medio de la cual se realiza un
Cadena
de anlisis del entorno, del organigrama, la visin y misin de
1 y 2 DCO
Valor
la empresa, polticas de prestacin de servicios y los
procesos del negocio. Se reutiliza informacin del modelo
- 164 -
Ciclo
Tcnica
1y2
ESRE
1y2
ESRE
Ciclo
Tcnica
1y2
del negocio.
Plantear modelos y diagramas lgicos
Herramienta
Descripcin
Se refinan y agregan nuevos trminos al glosario, segn
Glosario
evolucin del proyecto y opiniones de los clientes /
usuarios, estos trminos provienen del modelo del negocio
y las etapas de este mtodo.
Casos de uso
Se desarrolla el modelo de casos de uso segn el ESRE, el
Diagrama de cual se presentar al usuario para su aprobacin,
Actividad.
diagramas de actividades y modelo de clases (modelo de
Modelo
de objetos del negocio) basados en la informacin del modelo
clase.
del negocio.
Retroalimentacin
Herramienta
Descripcin
Se presentan al usuario los diagramas y modelos
realizados, luego de explicarles dichos modelos visuales,
los clientes / usuarios aportan sus opiniones, inquietudes y
percepciones, permitiendo con esta informacin, mejorar y
asegurar la calidad de los requerimientos identificados.
Tabla 15. Etapa de Anlisis de Requerimientos
4.4.3. Especificacin
Ciclo
Ciclo
1y2
1y2
Elegir la herramienta para la especificacin de requerimientos

Tcnica
Herramienta
Descripcin
Se elige una herramienta software para la especificacin
de los requerimientos, esta herramienta depende de las
normas, polticas e inclinaciones de la organizacin. Para
este proyecto se escogi la herramienta Enterprise
Architect.
Especificar los requerimientos
Tcnica
Herramienta
Descripcin
Se refinan y agregan nuevos trminos al glosario, segn
ESRE
Glosario
evolucin del proyecto y opiniones de los clientes /
usuarios. Los trminos plasmados en el glosario facilitan
la especificacin de los requerimientos.
Casos de uso
Se traducen a un lenguaje visual y tcnico todos los
Diagrama de requisitos extrados y analizados hasta el momento,
Actividad.
permitiendo mostrar las funcionalidades esenciales para el
Modelo
de desarrollo del proyecto desde una perspectiva mucha ms
clase.
clara.
Tabla 16. Etapa de Especificacin de Requerimientos
- 165 -
4.4.4. Validacin
Ciclo
1y2
Validar la correspondencia entre requerimientos y casos de uso

Tcnica Herramienta
Descripcin
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
ESRE
QFD
establecer la trazabilidad entre cada requerimiento y su
implementacin en un caso de uso.
Tabla 17. Etapa de Validacin de Requerimientos
4.5 RESULTADOS OBTENIDOS DE LA APLICACIN 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 anlogo 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 mdico
especializada.
Prestar servicio de Enfermera
Gestionar Historia clnica Crear Historia Clnica, Registrar datos en Historia
Clnica.
Gestionar RIPS Crear RIPS, Modificar RIPS, Registrar servicios en RIPS.
Gestionar Hospitalizacin
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 atencin

Controlar Actividades de Promocin y Prevencin
Gestionar
Medicamentos
Solicitar
medicamentos,
Despachar
medicamentos.
Controlar Calidad
Elaborar Contratos con ARS
Gestionar Glosas
Elaborar Informes
Gestionar Personal mdico y paramdico
Realizar reuniones Coves
Controlar Farmacias satlites
Gestionar Inventario Crear inventario, Actualizar inventario.
Gestionar Bienes Recibir bienes, Despachar bienes.
Gestionar Mercancas Recibir mercancas, Despachar mercancas.
- 167 -
4.5.2 Diagrama de casos de uso
Diagrama general
ud Use Case View
Funcionario Comit de
Baj as
Regente de Farmaca
Auxiliar Operativ o
Jefe de Serv icios

Generales
Gestionar
procesos de
Almacn
Gestionar
procesos de
Farmacia
Contabilidad
Jefe de Almacn
Base de Datos POS - S
Tesorero
Jefe de Departamento
de Personal
Gerente
Auxiliar Administrativ o
Jefe PAI
Jefe de Oficina
Jefe de div isin de

atencin en salud
Jefe de Departamento
de Promocin y
Prev encin
Gestionar procesos de
la Div isin de Atencin
en Salud
Odontlogo
Gestionar procesos del

Departamento de
Promocin y Prev encin
Secretaria
Caj ero
Mdico
Bacterilogo
Promotor de Salud
Coordinador IPS
Jurdico
Auxiliar
Digitador
Figura 124. Diagrama de Casos de Uso general
- 168 -
Softw are PAIDSA
Diagrama de Casos de Uso de Almacn
ud Procesos de Almacn
Almacn
Gestionar
Mercancas
Auxiliar Opertiv o de
Almacen
include
Gestionar
Inv entario
Jefe de Serv icios
Generales
Jefe de Almacn
include
Gestionar bienes
Auxiliar
Administrativ o de
Almacen
Funcionario Comite de
baj as
include
Gerente
Elaborar Informes
Contabilidad
Figura 125. Diagrama de Casos de Uso de Almacn
- 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
farmacia
Regente_Farmacia
Elaborar informes
include
Controlar
farmacias satlites
Figura 126. Diagrama de Casos de Uso de Farmaca
- 170 -
Diagrama de Casos de Uso de la Divisin de Atencin en Salud
ud Atencin en salud
Atencin en salud
Gestionar
facturacin
Caj ero
Gestionar citas
Auxiliar
administrativ o
Auxiliar
administrativ o
Gestionar
consultas
Auxiliar de citas
Gestionar
hospitalizacin
Jefe de Promocin y
Prev encin
Jefe de enferemera
include
Gestionar
programas de DI DP - PE
Auxiliar de
Enfermera
include
Auxiliar
include
Mdico
include
Elaborar informes
Jefe de Atencin en
salud
Mdico
include
include
Bacterilogo
Mdico Coordinador
Gestionar calidad
Gestionar historia
clnica y RIPS
include
Jefe de personal
Gestionar exmen
de laboratorio
Auxiliar de
laboratorio
Gestionar
personal mdico y
paramdico
Coordinador IPS
Elaborar contratos
con ARS
Tesorero
Secretaria
Gestionar glosas
Jurdico
Gestionar
atencin al cliente
Gerente
Figura 127. Diagrama de Casos de Uso de La divisin de Atencin en Salud
- 171 -
Diagrama de Casos de Uso del Departamento de Promocin y Prevencin
ud Promocin y Prev encin

Promocin y Prevencin
Seguir y Controlar
activ idades
PAIDSA
include
Enfermera
Jefe de Promocin y
Prev encin
Elaborar informes
include
Auxliliar
administrativ o
Auxiliar
administrativ o de P
yP
Gestionar
programas de
atencin
Auxiliar de
odontologa
Auxiliar
include
Digitador
Gestionar historia
clinica y RIPS
Jefe PAI
Auxiliar de
Enferemera
Gestionar
facturacin
Promotor de salud
Patlogo
Gestionar equipos
e insumos
Caj ero
Mdico
Mdico
Gestionar cov es
Odontlogo
Odontlogo
Mdico Coordinador
Higienista
Figura 128. Diagrama de Casos de Uso del Departamento de Promocin y Prevencin
- 172 -
Los diagramas de actividad realizados en el Modelo del Negocio y que

corresponden a los requerimientos definidos en la Obtencin 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 slo las dependencias que tienen
relacin 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 Descripcin de la Empresa Social del Estado IMSALUD
Creacin:
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 Ccuta.
Naturaleza Jurdica:
Es una entidad pblica descentralizada de orden Municipal dotada de
personera jurdica, autonoma administrativa y patrimonio propio, adscrita a la
direccin local de salud, integrante del Sistema General de Seguridad Social en
Salud sometido al rgimen jurdico previsto en la ley 100 y sus decretos
reglamentarios.
- 173 -
Jurisdiccin:
La Empresa Social del Estado del Primer Nivel de Atencin en Salud del
Municipio de San Jos de Ccuta, tiene jurisdiccin en todo el territorio del
Municipio de San Jos de Ccuta, su domicilio y sede de sus organismos
administrativos en la Ciudad de Ccuta.
Resea histrica:
Dentro de las virtudes que ofrece la Ley 10 de 1.990 a los entes territoriales
una de las de mayor relevancia es la descentralizacin en la administracin de
los servicios de salud y la declaratoria de los mismos como un servicio pblico
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 certificacin y asumir la descentralizacin,
cumplindolos en su totalidad , logrando as la certificacin el 29 de Diciembre
de 1.999, mediante el Decreto 1906 expedido por el Seor Gobernador del
Departamento Norte de Santander. Esto implic la necesidad de firmar con el
departamento un convenio nter - administrativo que materializaba esta
certificacin permitindole al Municipio de San Jos de Ccuta, la asuncin de
la direccin y la prestacin de los servicios de salud del primer nivel de
atencin, acto administrativo que fue firmado el 30 de Diciembre de 1.999 y que
inclua las actas de entrega del personal que estaba desarrollando labores del
primer nivel en el departamento a travs 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 -
pblica
descentralizada
con
autonoma
administrativa
presupuestal,
personera jurdica y patrimonio propio, para que asuma la prestacin de los

servicios de salud en el primer nivel de atencin en el Municipio de San Jos
de Ccuta. 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 artculo 6 del Decreto 1876 de 1.994, la Ju nta Directiva de la Empresa
Social del Estado E.S.E. IMSALUD, est integrada segn lo establecido en el
artculo 98 del Decreto Ley 1298 de 1.994, as: Una tercera parte de sus
miembros sern representantes del sector poltico administrativa, otra tercera
representar al sector cientfico 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 Ccuta.
Presidente Junta Directiva.
MIGUEL TONINO BOTTA FERNANDEZ

Director Departamento Administrativo de Seguridad Social en Salud.
"DASSSACU"
GLADYS SANCHEZ VILLAMIZAR

Representante Asociacin Cientfica de la Ciudad.
OSCAR FERNANDO CORZO H.

Representante del estamento cientfico de la Entidad.
PEDRO ENTRENA R
Representante del Gremio de la Produccin.
EDUAR NEIL SALAZAR CASTRO

Representante de la Asociacin 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 poblacin 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 reglamentacin que se expida para
tal propsito.
4.5.4.2 Organigrama de la Empresa
Figura 130. Organigrama ESE IMSALUD
4.5.4.3 Misin
Prestar servicios de salud del primer nivel de atencin tanto a los usuarios del
rgimen subsidiado como particulares, vinculados y del rgimen contributivo de
manera eficiente, eficaz y oportuna, contribuyendo, por ende al mejoramiento
continuo de la situacin de salud y de la calidad de vida en el municipio de San
Jos de Ccuta.
- 176 -
4.5.4.4 Visin
Convertirnos en la Empresa lder en la prestacin de servicios de salud con un
alto ndice de lucro social, financiero, calidad humana y tcnica del servicio, en
el Municipio de San Jos de Ccuta, mediante la conservacin de los principios
corporativos de eficiencia, eficacia, valor humano y calidad en la atencin en un
trmino de cinco (5) aos.
4.5.4.5 Prestacin 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
cucutea, su red prestadora de servicios de salud cubre toda la zona urbana y
rural de Ccuta, hoy IMSALUD cuenta con puestos de salud y unidades
bsicas en las cuales se prestan diferentes servicios de salud.
Figura 131. Distribucin de IPS
- 177 -
En los puestos de salud se prestan los siguientes servicios:

Medicina general
Odontologa general
Actividades de enfermera
Actividades de Demanda Inducida
Deteccin precoz y Proteccin especfica
En las unidades bsicas se prestan los siguientes servicios:

Medicina general
Odontologa general
Actividades de enfermera
Actividades de demanda inducida
Deteccin precoz y Proteccin especfica
Laboratorio clnico
Optometra
Radiologa
Trabajo social
Servicio de informacin y atencin al usuario
Ecografa
Urgencias 24 horas
Hospitalizacin
Transporte asistencial bsico
Electrocardiograma
RX Odontolgico
- 178 -
4.5.5 QFD
Atender al cliente
Requerimientos
Atencin
cliente
Cita
Consultas
Enfermera
Facturacin
Atender
llamadas
Atender
correspondencia
Asignar
citas
Prestar
servicio de
Enfermera
Gestionar
Facturacin
Realizar
Examen de
laboratorio
Gestionar
Programas
de DI DP
PE
al
X
X
X
Historia clnica
RIPS
Hospitalizacin
Examen
de
laboratorio
Programas de DI
DP PE
Gestionar Historia clnica

Crear
Registrar datos
Historia
en Historia
Clnica
Clnica
X
X
Gestionar RIPS
Crear RIPS
Modificar
RIPS
Registrar
servicios en
RIPS
Gestionar
Hospitalizacin
X
X
Gestionar
Programas
de
atencin
Controlar
Actividades
de
Promocin y
Prevencin
e
X
de
Gestionar Equipos e
insumos
Solicitar
Devolver
equipos e
equipos e
insumos
insumos.
Equipos
insumos
Programas
Casos de Uso
Gestionar Consultas
Gestionar
Gestionar
Cancelar
consulta
consulta
citas
general
mdico
especializada
Gestionar citas
X
X
- 179 -
Solicitar
medicamentos
Despachar
medicamentos
Controlar
Calidad
Elaborar
Contratos
con ARS
atencin
Actividades
de
Promocin
y
Prevencin
Medicamentos
Calidad
Contratos
X
X
X
X
Gestionar
Glosas
Glosas
Informes
Personal mdico
y paramdico
Coves
Farmacias
satlites
Inventario
Bienes
Mercancas
Elaborar
Informes
Controlar
Farmacias
satlites
Realizar
reuniones
Coves
Gestionar
Personal
mdico y
paramdico
Gestionar Inventario
Crear inventario
Actualizar inventario
X
X
X
X
X
Gestionar Bienes
Recibir bienes
Despachar bienes
X
X
X
X
Gestionar Mercancas
Recibir mercancas
Despachar mercancas
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
coleccin 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.
Adems, estos
procesos se hallan sujetos a un conjunto de reglas de negocio, que determinan

la estructura de la informacin y las polticas 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 sistemtica y

directa, tanto la coleccin 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 informacin 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 mtodo propuesto para la obtencin de requerimientos aprovecha la

informacin identificada en el modelo del negocio y utiliza algunos de los
artefactos que se desarrollan durante su produccin, razn por la cual facilita
- 181 -
el trabajo y ahorra tiempo de investigacin permitiendo de esta manera

concentrarse en los requerimientos claves para el usuario y garantizar la
calidad de la obtencin de requerimientos.
- 182 -
Metas
Captura
Anlisis
Especificacin
Validacin
Recolectar y Clasificar
requerimientos
Retroalimentacin
Correspondencia entre los
requerimientos metas y
necesidades de la empresa
Plantear modelos y
diagramas
Retroalimentacin
Elegir herramienta
Especificar los
requerimientos segn la
herramienta
Correspondencia entre
cada requerimiento y los
casos de uso.
Procesos
X
Modelo del producto

Actores
Unidades Tecnologa Reglas
Objetos
Eventos
Modelo
del
equipo
Proceso de
Modelado
X
X
Tabla 19. Relacin entre el modelamiento del negocio y la obtencin 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 slo en el orden del 20% de los proyectos
finalizan obteniendo el objetivo planteado, en el tiempo y con los recursos
estimados.
Esta problemtica se da en todo tipo de proyectos, y est
particularmente acentuada en proyectos tecnolgicos.
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 brindara 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

estratgico.
31 % No utilizacin, o mala utilizacin de metodologas de trabajo.
48 % Problemas humanos, de conduccin, comunicacin y conflictos

entre la gente.
Los proyectos que no saben a donde van, normalmente van a terminar

perdindose. Prestarles la suficiente atencin 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?
- Cmo se mide el xito?
- Qu condiciones tendran que existir para hacer este proyecto innecesario?
Con respecto a la profesionalidad para disear y ejecutar un proyecto, el factor

crtico es la utilizacin de metodologas.
En muchas organizaciones
pequeas 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
metodologa termina siendo utilizada como una mscara formal para el
cumplimiento de normas y etapas y no como lo que verdaderamente es, el eje
del proyecto tomando el contenido de la metodologa y no solo la forma.
Uno de los puntos en los cuales es muy dbil la utilizacin de metodologas, es
en el diseo de la estructura de un proyecto y en la estimacin de esfuerzos y
tiempos.
Para tal efecto lo recomendable sera manejar una estructura
jerrquica 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 relacin al ltimo punto que se refiere a problemas humanos, es crtico.

Las metodologas formales son de fundamental importancia, para la tarea de
los lderes de proyectos, pero no resultan suficientes para lograr el xito en el
cumplimiento del objetivo previsto. Existen muchos otros factores informales,
subjetivos, de interrelacin entre las personas, como ser la habilidad para
detectar conflictos ocultos, que son tan importantes como los mtodos y
documentos que utiliza el lder para llevar adelante su tarea. Estas relaciones
estn regladas por sensaciones, intuiciones, percepciones, sentimientos y
aceptacin de intereses personales no manifiestos.
Factores de falla o cancelacin en los proyectos:

[El papel fundamental de la industria del software en el crecimiento econmico. Foco:
Colombia. Autor: Laura Sallstrom y Robert Damuth]
Factores de dao o cancelacin
Requerimientos incompletos
13.1
Deficiencia en la participacin 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 planeacin
8.1
Ya no es necesario
7.5
Deficiencia en administracin de TI
6.2
Desconocimiento en tecnologa
4.3
Otros
9.9
Tabla 20. Factores de dao o cancelacin
- 186 -
Factores de falla o cancelacin en los proyectos

Requerimientos incompletos
14
Deficiencia en el involucramiento del usuario
12
Deficiencia de recursos
10
%
Expectativas no realistas
Deficiencia en soporte ejecutivo
Cambios en los requerimientos y

especificaciones
Deficiencia en la planeacin
4
2
Ya no es necesario
Deficiencia en administraticin TI
Desconocimiento en tecnologa
Areas
Otros
Figura 132. Factores de dao o cancelacin
Origen de los errores de proyectos software:
Fase
Obtencin y anlisis de requerimientos
56
Diseo
10
Cdigo
Otros
27
Tabla 21. Origen de los errores de proyectos software
- 187 -
Origen de los errores de proyectos software
Obtencin y anlisis de
requerimientos
Diseo
Cdigo
Otros
Figura 133. Origen de los errores de proyectos software
Costo relativo de corregir un error de software:
Fase
Obtencin y anlisis de requerimientos
82
Diseo
Cdigo
Otros
13
Tabla 22. Costo relativo de corregir un error de software
Costo relativo de corregir un error de software
Obtencin y anlisis de
requerimientos
Diseo
Cdigo
Otros
Figura 134. Costo relativo de corregir un error de software
- 188 -
Factores crticos de xito de un proyecto de software:
Factores crticos de xito de un proyecto

Misin del proyecto Metas y direcciones generales definidas con claridad al inicio del
proyecto.
Soporte administrativo de alto nivel Ayuda de la alta direccin para proveer los recursos
necesarios, autoridad y poder para el xito del proyecto.
Auscultacin del Cliente Comunicacin, auscultacin y escucha activa de todas las partes
del equipo del proyecto.
Personal Reclutamiento, seleccin y entrenamiento del personal necesario para el equipo del
proyecto.
Tareas tcnicas Disponibilidad de la tecnologa y experiencia necesarias para el
cumplimiento de las acciones tcnicas especficas.
Aceptacin del cliente El acto de vender el final del proyecto a los usuario finales.
Monitoreo y retroalimentacin Provisin a tiempo y de manera adecuada de informacin de
control en cada una de las etapas del proceso de implementacin.
Comunicacin La provisin de una red apropiada y datos necesarios para todos los actores
clave en la implementacin del proyecto.
Resolucin de problemas Habilidad de manejar crisis inesperadas y desviaciones del plan.
Tabla 23. Factores crticos de xito de un proyecto
Gran parte de los enfoques que abordan la solucin de la crisis del software
bsicamente 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, cdigo, etc.
Tecnologas destacadas:
Unified Modeling Language [Lenguaje de Modelado Unificado], anlisis y

diseo orientado a objetos, programacin orientada a objetos, entre las ms
importantes.
El proceso de desarrollo mediante la adopcin de modelos de ciclo de
desarrollo y modelos de calidad que equivale a la administracin de proyectos

mediante
el
aprendizaje
de
tcnicas
de
gestin
por
parte
de
los
administradores, gestin de personal y el mejoramiento y predicibilidad de los
- 189 -
resultados.
Tecnologas destacadas: Proceso Unificado, Capability Mature
Model, ciclo de vida evolutivo, administracin de proyectos, entre otras.
El personal que se ha enfocado a desarrollar un modelo de equipo de trabajo y
procurar las tcnicas, metodologas y herramientas de desarrollo necesarias

para manejar la complejidad del sistema a desarrollar.
Tecnologas
destacadas: Team Software Process, Personal Software Process, organizacin

de equipo, liderazgo, motivacin, 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
Orlando Cuevas
Director de proyectos de
Informtica del CIFI.
Universidad de Los Andes
Oscar Aldana
Gerente de Proyectos.
Getronics, Colombia
Causas
El caso colombiano coincide con el general: 1: No se cumplen
los requerimientos (especificacin de requerimientos
incompleta, ambigua, inconsistente). En general, no cumplir los
requerimientos del proyecto conduce a un gran porcentaje del
fracaso. 2. Pobre planeacin del proyecto, poca precisin
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
habra que definir cundo se puede considerar que un proyecto
fracas. Es posible obtener el producto final del proyecto, pero
an as el proyecto pudo haber sido un desastre. Su realizacin
pudo lograrse al final con sobre-costos, multas, con desgaste
de la relacin cliente-proveedor, fuera de tiempo, etc. As que
pudo haberse logrado el objetivo ms importante pero daando
o afectando otros aspectos que lo pueden dar por fracasado.
Pero, especficamente 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 desvo del objetivo inicial.
Otras causas son el mal manejo del cambio y la
subestimacin de los riesgos.
La primera y definitiva causa es una mala definicin del
alcance. No todos los proyectos inician con una adecuada
definicin del alcance. Es ms, esto es a lo que los clientes le
- 190 -
Marco Antonio Jimnez

Ejecutivo de Proyectos.
IBM Colombia
Sara Cristina Mantilla

Gerente de proyectos para
el rea de Amrica Latina.
EFunds - Oasis Technology
tienen ms pereza porque ellos no quieren arrancar con todas

las variables de una vez, sino quieren definirlas por el camino.
Esta mala definicin del alcance no se da slo aqu en
Colombia, se refleja tambin afuera. La segunda y no menos
importante corresponde a los errores que se presentan en la
planeacin del proyecto. Todos los clculos de los estimados,
llmense recursos, tiempo o costos. Porque no hay duda de
que todos los clientes tienen presin: por la competencia, por
lanzar un producto, porque necesitan liberar algo demasiado
rpido y entonces la presin 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
despus. 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
definicin 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 planeacin
de ese cambio, si no instruimos a la gente desde el comienzo a
que los proyectos los contemplan y a adoptar la metodologa
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 definicin de los indicadores, en el
estimativo de costos y en la formacin del grupo de trabajo. La
segunda: cambio de norte, de especificaciones, cambio de
entorno o un inadecuado manejo del control de cambios.
Es claro que en el ciclo de vida de un proyecto hay cambios y
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 duracin. 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 ingeniera 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 ingeniera de requerimientos es un conjunto estructurado de

actividades, mediante las cuales se obtiene, valida y se mantiene el documento
de especificacin de requerimientos (ESRE).
Las actividades del proceso incluyen la extraccin de requerimientos, el
anlisis, la negociacin y la validacin.
No existe un proceso nico que sea vlido de aplicar en todas las

organizaciones.
Cada organizacin 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 ingeniera de requerimientos.
Hay muchas maneras de
organizar el proceso de ingeniera de requerimientos y segn la relevancia y

complejidad del proyecto a desarrollar es necesario recurrir a un modelo del
negocio, el cual nos brinde la informacin necesaria de la realidad
organizacional y la gestin 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 algn tipo de proceso ordenado. Para obtener este
orden, se disean los procesos con base en algn modelo que nos gue a la
hora de diferenciar y secuenciar las actividades.
Adems si se selecciona y aplica un mtodo adecuado, tanto para el

modelamiento del negocio como para la obtencin de requerimientos, la
mayora de los artefactos obtenidos en el modelo del negocio se pueden refinar
y utilizar en la definicin de requerimientos, ahorrando tiempo y costo en el
proyecto.
- 192 -
A continuacin 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
Especificacin de requerimientos
incompleta,
ambigua
e
inconsistente.
Pobre planeacin del proyecto,

poca precisin para estimar el
tiempo y los recursos (no se
cumplen los plazos previstos ni
los costos estipulados).
Se presentan dificultades para
obtener productos sin errores
(productos
razonablemente
buenos en calidad).
Ausencia de un caso de negocio

(business case)
Desviacin del objetivo inicial,

cambio
de
norte,
de
especificaciones o de entorno.
Mala definicin del alcance.
Solucin
Para darle solucin a este problema es necesario aplicar un
mtodo de obtencin de requerimientos efectivo, el cual
centre su atencin en obtener, analizar, especificar y validar
requerimientos, evitando la ambigedad en los mismos, los
cuales logren satisfacer las necesidades de los usuarios,
para un mejor resultado el mtodo propuesto es iterativo, lo
cual garantiza cubrir al final de todas las iteraciones los
requerimientos ms 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 mtodo son comparados con las
metas, objetivos y realidad de la organizacin interesada,
de esta manera se evita la inconsistencia de los
requerimientos.
El modelo del negocio ayuda a vislumbrar al inicio del
proyecto el tiempo y recursos a emplear, estas informacin
sirve como entrada para planear el proyecto, no ha ciegas
como habitualmente sucede, sino con ciertas bases reales,
disminuyendo el riesgo realizar estimaciones incorrectas.
La retroalimentacin del cliente / usuario y la validacin que
se realiza durante los ciclos del mtodo propuesto, son
actividades fundamentales para definir requerimientos
reales y consistentes, aportando a la produccin de un
sistema que cumpla con las estndares de calidad.
Es fundamental realizar un modelo del negocio en el cual
se identifiquen los principales procesos de la empresa,
actores, eventos, objetos y reglas del negocio. Esta
informacin es la base para desarrollar una buena
obtencin de requerimientos, al poder reutilizar ciertos
datos del modelo y poder validar los requerimientos,
ajustndolos a la realidad empresarial.
En el modelado del negocio se identifican los objetivos y
metas de la organizacin, a la par se establece el ambiente
y entorno en el cual actuar el nuevo sistema. Esta
informacin es gua para las dems etapas y fases del
desarrollo del producto software, adems sirve como
referencia para evitar desviaciones e
En el modelo del negocio se define un alcance inicial del
proyecto, el cual se concreta y se refina en la obtencin de
requerimientos, este alcance se perfila con la informacin
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
Segn el anlisis realizado en el captulo 4 de este documento, el desarrollo de

este proyecto y la aplicacin del mtodo propuesto para la obtencin de
requerimientos es de gran importancia para las empresas dedicadas al
desarrollo de productos software, debido a que permite la reduccin de errores
en los sistemas, trayendo consigo la disminucin del tiempo requerido para
correcciones, el costo de dichas correcciones y mejorando la calidad y
produccin de la empresa.
Las principales causas de fracaso de los proyectos son: Requerimientos

incompletos y deficiencia en la participacin del usuario, los cuales suman
entre ellos el 25.5 %, trayendo consigo el 82 % del costo de correccin de los
errores de produccin.
Como se puede apreciar el modelado del negocio
realizado con BMM y la obtencin de requerimientos desarrollada con el

mtodo propuesto se enfocan en atacar estas causas, permitiendo, segn las
polticas y metodologa de desarrollo de la empresa, la reduccin en costos,
tiempo y esfuerzos y el aumento en productividad, calidad y optimizacin de
procesos.
El desarrollo de este proyecto no gener mayores gastos, a continuacin se

relacionan:
HARDWARE (Recursos Universidad)
PC: Pentium IV, mnimo 2.6 GHz, 512 RAM.
$ 2000.000
SOFTWARE (Recursos Propios)
Enterprise Architect
Versin Trial de 30 das
- 194 -
PAPELERIA (Recursos Propios)
Impresiones
CD
Libros, artculos, revistas, etc.
$ 500.000
$ 20.000
$ 300.000
HONORARIOS PROFESIONALES (Recursos Universidad)
Asesor Universidad de Pamplona (2 horas semanales) $ 1500.000
Asesor Plataforma (2 horas semanales)
$ 1500.000
Desarrollador (SMMLV)
$ 1632.000
OTROS (Recursos Universidad)
Internet
$ 500.000
TOTAL: $ 7952.000
- 195 -
ANALISIS DE LEGALIDAD
Para el desarrollo de este proyecto se utiliz informacin confidencial de la

Empresa Social del Estado IMSALUD, la cual autoriz su manipulacin para
fines profesionales como lo es el desarrollo de un sistema para el soporte de la
prestacin de los servicios de salud que all se ofrecen.
A nivel de recursos software, se utiliz como herramienta para la realizacin 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 versin trial de 30 das.
- 196 -
CONCLUSIONES
El modelado del negocio es una etapa fundamental y sirve como base para
las siguientes fases del desarrollo de software, la informacin 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 bsicos
para establecer y validar requerimientos adecuados, acordes a la situacin
organizacional, social, tcnica y ambiental de la empresa objetivo.
El modelado del negocio se realiz empleando el mtodo BMM, el cual est

basado en principios, procesos y conceptos tomados de la Ingeniera de
mtodos, modelamiento empresarial y la Ingeniera del software orientada a
objetos. El BMM consta de tres modelos (producto, equipo, proceso de
modelado), cada uno de ellos permite obtener informacin relacionada con
el producto deseado, los recursos humanos necesarios para llevar a buen
trmino el proyecto y dems aspectos importantes del negocio de la
empresa, como valor agregado se obtiene que la mayora de sus artefactos
pueden ser reutilizados en las fases posteriores de desarrollo.
En la Obtencin de requerimientos, denominada por algunos autores como

Ingeniera de Requerimientos, debido a que consta de algunas etapas, las
cuales deben desarrollarse en cierto orden para conseguir los objetivos
especficos de esta fase, conformando as un proceso repetible, requiere la
aplicacin de tcnicas y herramientas que respalden dicho proceso, con el
objetivo
de
extraer,
analizar,
especificar
validar
requerimientos
consistentes, claros y apropiados.
La Extraccin de requerimientos tambin denominada captura, es una etapa

que representa el comienzo de la Obtencin de Requerimientos. Extraccin
- 197 -
es el nombre comnmente 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 dems
caractersticas relevantes.
Sobre la base de la extraccin realizada previamente comienza el anlisis

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 aprobacin.
En la especificacin se pasa de lenguaje natural (comprendido por el

cliente), a lenguaje formal y tcnico, 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 validacin especializada
de los requerimientos.
Para la Obtencin de requerimientos se identificaron varias tcnicas y

herramientas que ayudan y soportan el proceso de extraccin, anlisis,
especificacin y validacin de requerimientos, aportando facilidad de
aplicacin del proceso, definicin del dominio del problema, alcance y
requerimientos acordes al negocio.
De estas tcnicas y herramientas
fueron seleccionadas algunas de ellas para aplicarlas en la Obtencin de

requerimientos de este proyecto, generando resultados positivos en estado
de aceptacin.
Se propuso un mtodo para la Obtencin de Requerimientos, el cual se

centra en el usuario, es iterativo e incremental, tiene como fundamento y
base los casos de uso, adems de emplear el modelamiento visual como
lenguaje de comunicacin entre los clientes / usuarios y el equipo de
- 198 -
desarrollo.
Dicho mtodo consta de cuatro etapas, en las cuales se
incluyen unas actividades orientadas en la definicin de requerimientos

reales, tiles, consistentes, claros y adecuados, segn las necesidades de
los clientes, que conformen soluciones efectivas a los problemas actuales
de la empresa interesada.
La
mayora
de
los
proyectos
de
Tecnologas
de
Informacin
especialmente aquellos relacionados directamente con la produccin de

soluciones software, no llegan a completarse con xito, por causas tales
como
mala
definicin
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 mitigacin 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 obtencin de requerimientos son soluciones eficientes en
tales trminos, las cuales deben ser desarrolladas basndose en mtodos
que faciliten la consecucin de sus objetivos.
- 199 -
RECOMENDACIONES
Se recomienda continuar con el estudio y anlisis de la pertinencia de un

modelo del negocio y la aplicacin de un mtodo ptimo para la obtencin
de requerimientos, considerando que dichas fases son los cimientos
principales y fundamentales para un desarrollo adecuado de software.
El mtodo propuesto para la obtencin de requerimientos puede ser

mejorado aplicando otras tcnicas y herramientas y estudiando los
resultados obtenidos de dicha aplicacin, para de esta manera considerar
diferentes formas de optimizacin, conformando as un mtodo robusto y
flexible.
Sera objeto de estudio la aplicacin del mtodo propuesto a ms 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 tecnolgico.
[BARRIOS et all, 2003] BARRIOS Judith y MONTILVA Jons.
(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 Ingeniera de

Requerimientos: Un Armazn y su Aplicacin. Los Sistemas de informacin,
3(19).
[SOMMERVILLE, 1997] Sommerville, I., Sawyer, P. (1997). Requirements

Engineering: A Good Practice Guide. John Wiley & sons.
- 201 -
[KOMER, 1993] KOMER, P. (1993). Direccin de la Mercadotecnia. Sptima

Edicin. Espaa. Prentice Hall.
[CRAIG, 1999] CRAIG, L. (1999). UML Y PATRONES. Introduccin al anlisis y

diseo orientado a objetos. Espaa. 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] Asociacin Colombiana de Ingenieros de Sistemas, La Gerencia

de Proyectos de TI en el pas, 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

Ttulo: Definicin del modelo del negocio y del dominio utilizando razonamiento
basado en casos.
- 202 -
Autora: Magster Martha D. Delgado Dapena

Centro de estudios de Ingeniera 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
Ttulo: Metodologa DoRCU para la Ingeniera de Requerimientos
Autora: M. Griselda Bez, Silvia I. Barba Brunner
Instituto Superior Politcnico "Jos Antonio Echeverra", La Habana, CU
[DAVILA, 2006] http://www.monografias.com/trabajos12/ingreq/ingreq.pdf

Ttulo: Ingeniera de requerimientos: Una gua para extraer, analizar,
especificar y validar los requerimientos de un proyecto.
Autor: Nicols Davyd Dvila
Universidad de Uruguay
[SUMANO, 2006] http://www.geocities.com/diegolp/ingsof/requerimientos.pdf

Ttulo: Anlisis de requerimientos de software
Autora: M.C.C Mara de los ngeles Sumano Lpez
Fecha de consulta: Septiembre 13 de 2006
[THOMAS, 2006] http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER05/

pablo_thomas.pdf
Ttulo: Elicitacin de objetivos a partir de escenarios
Autor: Pablo Thomas
Instituto de investigacin en informtica 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 -
Ttulo: 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-losproy-de-soft.pdf

Ttulo:
Por qu fracasan
los
proyectos
de
software? Un
enfoque
organizacional.
Autor: J. Jess Mara Zabala Ruiz
Universidad Autnoma Metropolitana-Iztapalapa. Mxico, D.F.
Fecha de consulta: Septiembre 13 de 2006
[OCHOA, 2006] http://www.monografias.com/trabajos11/metods/metods.shtml

Ttulo: Mtodos
Autora: Ana Beatriz Ochoa G.
Fecha de consulta: Diciembre de 2006
- 204 -
Anexo 1. Anlisis comparativo de Metodologas utilizadas en la Obtencin

de Requerimientos.
Metodologa
DoRCU
(Documentacin de
Requerimientos
Centrada en el
Usuario).
GBRAM
(GoalBased
Requirements
Analysis Method)
SSM (Soft System

Methodology)
Etapas
Captura
requerimientos
Anlisis
requerimientos
Especificacin
requerimientos
Validacin
Certificacin
Requerimientos.
de
de
de
y
de
Identificar Metas y
Objetivos.
Organizar y Clasificar
Metas.
Refinar y Elaborar
Metas.
Operacionalizar
Metas
en
Requerimientos.
Poner en claro la
situacin
del
problema.
Expresar la situacin.
Hacer la seleccin de
Ventajas
Desventajas
Metodologa
centrada
en
el
usuario,
lo
cual
permite
satisfacer
las
necesidades
reales del cliente.
Se
debe
dedicar
bastante tiempo para la
realizacin
de
los
documentos, lo cual
retrasa en parte el
desarrollo del proyecto.
Documentacin de
requerimientos
de
una manera tcnica
para el equipo de
desarrollo
y
en
lenguaje natural para
la
revisin
del
usuario, facilitando
su comprensin.
Duplicidad de trabajo
por la necesidad de
desarrollar documentos
de manera formal para
el equipo de trabajo y
pasarlos a una manera
informal para el usuario.
Permite el desarrollo
en
ciclos
o
iteraciones para de
esta manera corregir
o
adicionar
requerimientos.
Provee mecanismos
de
representacin
adecuados, como lo
son los escenarios,
para la comprensin
de los stakeholders.
Se concentra en
establecer
los
fundamentos
que
justifican
los
requerimientos
de
software, debido a
que se basa en los
Objetivos
de
la
organizacin.
Se enfoca en el
modelamiento visual,
lo que permite una
mayor comprensin
de
los
Su
enfoque
en
escenarios
provee
flexibilidad para obtener
los requerimientos, pero
a su vez, le resta
formalismo
a
su
especificacin,
causando
de
esta
manera conflictos en el
equipo de desarrollo,
debido
a
posibles
ambigedades en los
requerimientos.
No
se
definen
actividades
para
la
especificacin
y
validacin
de
requerimientos.
Es recomendable para
la
comprensin
del
ambiente del proyecto y
el dominio del problema,
pero no para utilizarla

como
ver
paulatinamente
la
situacin de manera
que se pueda producir
percepciones que den
pi a definiciones raz.
Construir
modelos
conceptuales.
Comparar
los
modelos conceptuales
con el mundo real.
Identificar
cambios
factibles y deseables.
Recomendaciones
para la toma de
acciones que mejoren
la
percepcin
problema.
Color
X
(Conceptual
Linguistically based
Object
oriented
Representation
language
for
information
and
communication
systems)
Rare-Idiom (ReuseAssisted
Requirement
Engineering
with
Informal Document
Interpreter
Organizer
and
Manager)
requerimientos.
Est basado en la
representacin
de
actividades
del
mundo real.
Permite obtener la
informacin inicial.
Metodologa basada
en
la
lingstica
computacional y el
anlisis orientado a
objetos, facilitando el
modelado de los
requerimientos.
Especificacin
requerimientos.
Validacin
verificacin
requerimientos.
Elaboracin
necesidades
objetivos.
Obtencin
requerimientos.
Especificacin
requerimientos
modelado.
Generacin
evaluacin
alternativas.
Verificacin
validacin
requerimientos.
de
y
de
de
y
de
de
y
y
de
y
de
Es una herramienta
automtica
o
semiautomtica que
reduce notablemente
el
tiempo
de
desarrollo.
Se
ejecuta
de
manera
iterativa
permitiendo
la
participacin
del
usuario durante su
proceso.
Reusa
requerimientos
y
artefactos
asociados,
incentivando
el
almacenamiento de
conocimiento.
Se basa en las
propiedades
estructurales de los
documentos
de
requerimientos y los
procesos realizados
para su produccin.
como metodologa de
Ingeniera
de
Requerimientos en un
proyecto formal, debido
a que no proporciona la
informacin necesaria
para el desarrollo de las
actividades de dicha
fase.
Se debe contar con

personal calificado en
modelos de Lenguaje
Natural.
No incluye la captura y
anlisis
de
requerimientos, por lo
tanto el equipo de
desarrollo debe aplicar
otra metodologa para la
realizacin de estas
etapas.
Es necesario contar con

informacin
de
proyectos
anteriores
para su aplicacin.
Anexo 2. Glosario
Abstraccin: Consiste en aislar un elemento de su contexto o del resto de los
elementos que lo acompaan. En programacin, el trmino se refiere al nfasis

en el "qu hace?" ms que en el "cmo lo hace?". El comn denominador en
la evolucin de los lenguajes de programacin, desde los clsicos o
imperativos hasta los orientados a objetos, ha sido el nivel de abstraccin del
que cada uno de ellos hace uso.
Accin: Una accin es la salida del sistema, relacionada con una entrada
sensorial. Cambia el entorno. La accin es la implementacin (el hacer) de la

segunda parte de una regla de actuacin.
Actividad: Agrupacin de Tareas que hace parte de un Proceso.
Actor: Es una persona, mquina 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 slo
el trabajo requerido, para completar el proyecto de manera exitosa.
Ambiente: Entorno en el cual una organizacin opera. Condiciones externas
que afectan a un sistema.
Anlisis: Accin 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.
requerimientos,
la
cual
se
enfoca
requerimientos del sistema identificados.
en
Fase de la ingeniera de
descubrir
problemas
con
los
Aplicacin: En informtica las aplicaciones son los programas con los cuales
el usuario final interacta. Programa que efecta una tarea definida.
Artefacto: Todo objeto hecho por el hombre de acuerdo con las normas que lo
rigen, en ingeniera del software se refiere a un resultado de un proceso, el cual

puede ser un documento, un modelo, entre otros.
Atributo: Informacin descriptiva asociada a un rasgo especfico de un objeto.
Bosquejo: Es el primer trazo y no el definitivo de una obra "pre torica" o de
cualquier produccin de ingenio, es una idea vaga de un concepto o plan.
Calidad: La calidad de un producto o servicio es la percepcin 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 grfica de representar la realidad, explica
la forma como interacta el sistema y los actores.

Es una tcnica 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 cmo un sistema o negocio funciona actualmente, o cmo los usuarios
desean que funcione.
Ciclo: Una secuencia de instrucciones que se ejecutan en forma repetitiva
hasta cumplir una condicin particular.
Ciclo de vida del software: El proceso que se sigue para construir, entregar y
hacer evolucionar el software, desde la concepcin de una idea hasta la

entrega y el retiro del sistema.
Cliente: Toda organizacin, entidad, comunidad o persona que requiera los
servicios o productos de una organizacin, consumidor final que utiliza el

servicio, benefactor.
Componente: Agrupacin de elementos que hace parte de un subsistema.
Comportamiento: La palabra comportamiento generalmente se refiere a
acciones de un objeto u organismo, usualmente en relacin con su entorno o

mundo de estmulos.
Concepto: Un concepto es el elemento bsico del pensamiento. Es el
almacenamiento fsico, material de informacin. Todos los conceptos de la

memoria estn interrelacionados, forman una red.
Condicin: 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 produccin, administracin 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 carcter positivo.
Declive: Inclinacin, pendiente con orientacin hacia abajo.
Demanda inducida: Hace referencia a la accin de organizar, incentivar y
orientar a la poblacin hacia la utilizacin de los servicios de proteccin

especfica y deteccin temprana y la adhesin a los programas de control.
Deteccin temprana: Hace referencia a los procedimientos que identifican en
forma oportuna y efectiva la enfermedad, facilitan su diagnstico en estados

tempranos, el tratamiento oportuno, la reduccin de su duracin y el dao que
causa evitando secuelas, incapacidad y muerte.
Diagnstico: Procedimiento con el que se identifica una enfermedad.
Diagrama: Es una forma de representar grficamente un fenmeno, proceso u
organizacin determinado.
Dominio del problema: Es el rea de conocimiento hacia la cual se orienta
determinada solucin de software.

Efectividad: Consistente en alcanzar los resultados programados a travs de
un uso ptimo de los recursos involucrados.
Eficiencia: Es la relacin 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.
Especificacin: Una especificacin puede ser un documento escrito, un
modelo grfico, un modelo matemtico formal, una coleccin de escenarios de

uso, un prototipo o una combinacin de lo anteriormente citado.
Estimacin: Proceso por el que se realizan inferencias inductivas sobre
parmetros de la poblacin a partir de los datos de una muestra.
Entorno: El entorno de un sistema es aquella parte del universo que est en
comunicacin con el sistema, pero que no es parte del sistema.
Entregable: Producto o resultado que debe ser entregado a la persona,
empresa u organizacin interesada.
Escenario: Un conjunto de variables que para esa situacin poseen un nivel de
valor y un grado de ocurrencia.
Combinacin de secuencia de eventos o
fenmenos 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: accin de corta duracin que ocurre dentro o fuera del sistema del
negocio.
Extraccin: Nombre comnmente dado a las actividades involucradas en el
descubrimiento de los requerimientos del sistema.
Flujo: La realizacin progresiva de las diferentes actividades que forman el
flujo de valor, de tal manera que el producto progresa del diseo 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.
Funcin: Una funcin correspondera a un conjunto de actividades
coordinadas de distintos elementos de un sistema, contribuyendo a la

realizacin de un mismo objetivo. Sin embargo una funcin es una entidad
abstracta y terica, extrapolada a ir de datos experimentales.
Funcionalidad: Caracterstica o comportamiento esencial que debe soportar
un sistema de informacin.
Glosas: Son las observaciones de tipo administrativo y tcnico 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 informacin. Una

herramienta se puede aplicar mediante distintos mtodos o tcnicas.
Historia clnica: La historia clnica es el conjunto de documentos surgidos de
la relacin entre el mdico y el paciente, y a partir de la segunda mitad del siglo

XX entre usuarios y el hospital o Atencin Primaria. La historia clnica es el
nico documento vlido desde el punto de vista clnico y legal. En atencin
primaria la historia clnica se llama historia de salud.
Impacto: Cambio logrado en la situacin de la comunidad como resultado del
producto de un proceso. Es el nivel ms 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.
Informacin: En sentido general, la informacin es un conjunto organizado de
datos, que constituyen un mensaje sobre un determinado ente o fenmeno.
Ingeniera del software: Es el conjunto de mtodos, tcnicas 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 informtico que permite a
ste comunicarse con el usuario o con otras aplicaciones permitiendo el flujo de

informacin.
Iteracin: 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

validacin y modificacin.
Jerarqua: Jerarqua es el orden de los elementos de una serie segn su de
valor.
Kardex: Es uno de los principales proveedores mundiales de sistemas
automatizados de almacenamiento y clasificacin
Lenguaje: Sistema de programacin que permite crear programas y as
comunicar al usuario con la mquina a fin de que esta cumpla una tarea
determinada. Existen distintos niveles de lenguajes que se pueden clasificar
segn su grado de abstraccin y dificultad.
Meta: Resultado que se pretende alcanzar en un plazo determinado para
avanzar hacia el cumplimiento de un objetivo. Su medicin debe hacerse en

trminos de tiempo, cantidad y, si es posible, calidad.
Mtodo: Modo ordenado de proceder para llegar a un resultado o fin
determinado. Aplicacin de tipo particular.
Metodologa: Metodologa se refiere a los mtodos de investigacin en una
ciencia. Manera sistemtica de hacer cierta cosa.
Modelo: Un modelo es una conceptualizacion de un evento, un proyecto, una
hiptesis, el estado de una cuestin, que se representa como un esquema con

smbolos descriptivos de caractersticas y relaciones ms importantes con un
fin: ser sometido a modelizacin como un diseo flexible, que emerge y se
desarrolla durante el inicio de la investigacin como una evaluacin 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 sntomas de un
tratamiento o enfermedad.
Necesidad: Es una sensacin de carencia de un producto bsico.
Negocio: Toda actividad que se emprende con el objeto de obtener un
provecho econmico.
Objetos: Pensamiento concreto o abstracto que es relevante para el sistema.
Obtencin de requerimientos: Fase, etapa o disciplina, para algunas
metodologas de desarrollo, la cual se encarga de definir, analizar y especificar

los requerimientos que debe soportar el sistema a ser creado.
Operacin: El mtodo, acto, proceso, o efecto de utilizar un dispositivo o
sistema.
Organigrama: Es la representacin grfica de la estructura organizativa,
vertical u horizontal, de una empresa.
Paramdico: paramdico 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 sbita y lo transporta a una unidad mdica
para su atencin integral complementaria para la resolucin de su problema.
Poltica: La poltica 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 latn processus) es un conjunto de actividades o
eventos que se realizan o suceden con un determinado fin.
Produccin: Conjunto de operaciones que sirven para mejorar e incrementar
la utilidad o el valor de los bienes.
Proteccin especfica: Hace referencia a la aplicacin de acciones y/o
tecnologas que permitan y logren evitar la aparicin inicial de la enfermedad

mediante la proteccin 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 socioeconmico planificada y orientada
a la consecucin de objetivos, que requiere inversiones financieras o

participacin humana en un tiempo dado.
Recurso: Cualquier parte componente de un sistema de informacin.
Elemento necesario para llevar a cabo una tarea.
Rgimen Contributivo: El rgimen contributivo es un conjunto de normas que
rigen la vinculacin de los individuos y las familias al Sistema General de

Seguridad Social en Salud, cuando tal vinculacin se hace a travs del pago de
una cotizacin, individual y familiar, o un aporte econmico previo financiado
directamente por el afiliado o en concurrencia entre ste y su empleador.
Rgimen Subsidiado: El rgimen subsidiado es un conjunto de normas que
rigen la vinculacin de los individuos al Sistema General de Seguridad Social

en Salud, cuando tal vinculacin se hace a travs del pago de una cotizacin
subsidiada, total o parcialmente, con recursos fiscales o de solidaridad.
Regla: Es un conjunto de valores combinados que, al cumplirse determinadas
condiciones, lanza la ejecucin de acciones establecidas previamente.
Requerimiento: Es una condicin o necesidad de un usuario para resolver un
problema o alcanzar un objetivo.

Una condicin o capacidad que debe estar presente en un sistema o
componentes de sistema para satisfacer un contrato, estndar, especificacin u
otro documento formal.
Restriccin: Limitacin que debe soportar una aplicacin software para hacer
cumplir las reglas establecidas anteriormente, con el objetivo de satisfacer los

requerimientos del usuario.
Retroalimentacin: Comunicacin entre el instructor o el sistema y el
aprendiz, como resultado de una accin o proceso.
Reusar: Reutilizar es la accin de volver a utilizar los bienes o productos. La
utilidad puede venir para el usuario mediante una accin de mejora o

restauracin, o sin modificar el producto si es til para un nuevo usuario.
Rol: Rol en sociologa 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 interactan
entre s y con su ambiente, para lograr objetivos comunes, operando sobre

informacin, sobre energa o materia u organismos para producir como salida
informacin o energa o materia u organismos.
Sistematizacin: Es un proceso permanente y acumulativo de construccin de
conocimiento a partir de nuestra experiencia de accin/intervencin en una

realidad especfica. Es un primer nivel de teorizacin sobre la prctica. Por un
lado pretende mejorar la prctica y por el otro enriquecer las teoras existentes.
Software: Tambin conocido como soporte lgico, compendia todo tipo de
programas, utilidades, aplicaciones, sistemas operativos, drivers que hacen

posible que el usuario pueda trabajar con la mquina.
Stakeholders: Son los grupos que tienen inters en que la empresa sobreviva.
Estos grupos de inters (personas u organizaciones) pueden afectar o verse

afectados por las decisiones de la empresa de la que estn interesados.
Tarea: Una actividad definida que es cumplida por individuos y organizaciones.
Las tareas son actividades especficas que contribuyen al cumplimiento de la

misin general u otros requerimientos. Una tarea debe ser alcanzable, decisiva
y responder al QUE de la misin.
Tcnica: La tcnica 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 tecnologa, de las artesanas o en otra actividad.
Tecnologa: Conjunto de las diferentes tcnicas de produccin que se pueden
aplicar en una actividad de produccin determinada.
Traceabilidad: Una especificacin 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 documentacin
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.
Validacin: La validacin es la etapa final de la Ingeniera de Requerimientos.
Su objetivo es verificar todos los requerimientos que aparecen en el

documento, para asegurarse que representan una descripcin, por lo menos,
aceptable del sistema que se debe implementar. Esto implica verificar que los
requerimientos sean consistentes, estn completos y que el resultado del
trabajo se ajuste a los estndares establecidos para el proceso, el proyecto y el

producto.
Anexo 3. Plantillas
1. Elicitacin de Requerimientos:
Ciclo
Tcnica
Recolectar y Clasificar Requerimientos

Herramienta Descripcin Requerimientos Obtenidos
Ciclo
Tcnica
Herramienta Descripcin Requerimientos y prioridad
Ciclo
Tcnica
Retroalimentacin
Herramienta
Descripcin
2. Anlisis de Requerimientos:
Verificar la correspondencia de los requerimientos con las metas de la organizacin y las

necesidades de los clientes / usuarios
Ciclo
Tcnica
Herramienta
Descripcin
Ciclo
Plantear modelos y diagramas lgicos

Tcnica
Herramienta
Ciclo
Tcnica
Retroalimentacin
Herramienta
Descripcin
Descripcin
3. Especificacin de Requerimientos:
Elegir la herramienta para la especificacin de requerimientos

Ciclo
Tcnica
Herramienta
Descripcin
Ciclo
Especificar los requerimientos

Tcnica
Herramienta
Descripcin
4. Validacin de Requerimientos:
Validar la correspondencia entre requerimientos y casos de uso

Ciclo
Tcnica
Herramienta
Descripcin
5. Especificacin de Casos de Uso:
NOMBRE DEL CASO DE USO

ACTOR PARTICIPANTE
CONDICION INICIAL
FLUJO DE EVENTOS
CONDICION DE SALIDA
QQQQQQQQQQ
Anexo 4. Siglas
ARS: Administradora de Rgimen Subsidiado

BMM: Business Modeling Method
CNSSS: Comisin Nacional de Seguridad Social en Salud
COLOR-X: Conceptual Linguistically based Object oriented Representation
language for information and communication systems

DA: Documento de Anlisis
DASSSACU: Departamento Administrativo en Seguridad Social en Salud
DE: Documento de Elicitacin
DCO: Documento de Concepto de Operaciones
DI: Demanda Inducida
DOFA: Debilidades Oportunidades Fortalezas - Amenazas
DoRCU: Documentacin de Requerimientos Centrada en el Usuario
DP: Deteccin Precoz
DRT: Documento de Requerimientos Tcnico
DRU: Documento de Requerimientos Orientado al Usuario
EA: Enterprise Architect
ESE: Empresa Social del Estado
ESRE: Documento de Especificacin de Requerimientos
GBRAM: Goal-Based Requirements Analysis Method
IPS: Instituciones Prestadoras de Servicios de Salud
JAD: Desarrollo Conjunto de Aplicaciones
IMSALUD: Institucin Municipal de Salud de San Jos de Ccuta
LEL: Lxico Extendido del Lenguaje
PAI: Programa Ampliado de Inmunizaciones
PAIDSA: Base de datos Programa Ampliado de inmunizaciones
PE: Proteccin Especfica
POS: Plan Obligatorio de Salud
QFD: Quality Function Deployment
RARE-IDIOM:
Reuse-Assisted
Requirement
Engineering
Document Interpreter Organizer and Manager

RIPS: Registro Individual de Prestacin de Servicios
RUP: Rational Unified Process
SISVAN: Sistema de Vigilancia Alimentaria y Nutricional
SRS: Especificacin de Requerimientos Software
SSM: Soft System Methodology
UML: Unified Modeling Language
with
Informal

Analisis Comparativo PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Analisis Comparativo PDF

Enviado por

Direitos autorais:

Formatos disponíveis

FACULTAD DE INGENIERAS Y ARQUITECTURA

PROGRAMA DE INGENIERA DE SISTEMAS

TRABAJO PRESENTADO PARA OPTAR POR EL TITULO DE

APLICATIVO GESTASOFT HOSPITALARIO PARA IMSALUD.

La esperanza es el sueo del hombre despierto (Aristteles)

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

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

Para garantizar que el

producto final satisfaga las necesidades y expectativas de los usuarios, se

El Modelamiento del Negocio facilita la recoleccin de informacin necesaria

Esta informacin constituye los cimientos

fundamentales de la Obtencin de Requerimientos.

La Obtencin de Requerimientos es la fase de la cual depende en gran medida

En este documento se presenta al Modelamiento del Negocio y la Obtencin de

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

The Business Model facilitates the gathering of necessary information to

This information represents the principal foundation of the

Modelo del Negocio y Obtencin de Requerimientos

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

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

Modelo del Negocio y Obtencin de Requerimientos

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

Modelo del Negocio y Obtencin de Requerimientos

1.2.2.17 Documento ESRE / Casos de Uso .................................................... 47

Modelo del Negocio y Obtencin de Requerimientos

2.1.1.1.9 Mtodo de la concrecin ................................................................... 73

3. MODELO DEL NEGOCIO............................................................................ 87

Modelo del Negocio y Obtencin de Requerimientos

Modelo del Negocio y Obtencin de Requerimientos

4.6 RELACION ENTRE EL MODELADO DEL NEGOCIO Y EL METODO

5. EL MODELO DEL NEGOCIO Y LA OBTENCION DE REQUERIMIENTOS

ANALISIS ECONOMICO Y ADMINISTRATIVO............................................. 194

Modelo del Negocio y Obtencin de Requerimientos

Figura 1 Ubicacin del mtodo BMM en un modelo de procesos de sistemas

Modelo del Negocio y Obtencin de Requerimientos

Figura 22 Cadena de valor.............................................................................. 89

Modelo del Negocio y Obtencin de Requerimientos

Figura 49 Diagrama del proceso: Gestionar medicamentos ......................... 105

Modelo del Negocio y Obtencin de Requerimientos

Figura 80 Diagrama Role / Actividad: Digitador ............................................ 126

Modelo del Negocio y Obtencin de Requerimientos

Figura 111 Diagrama de actividad: Gestionar

paramdico .................................................................................................... 150

Modelo del Negocio y Obtencin de Requerimientos

Tabla 1 Tcnicas y herramientas de Obtencin de Requerimientos ............... 38

Modelo del Negocio y Obtencin de Requerimientos

Anexo 1. Anlisis comparativo de Metodologas utilizadas en la Obtencin de

Modelo del Negocio y Obtencin de Requerimientos

Antes de empezar a disear un software, es necesario saber qu se quiere

administrativos, econmicos, sociales, y ambientales.

El modelo del negocio provee una amalgama de artefactos (tales como

primera se encuentran los aspectos humanos, que es donde el analista o

Modelo del Negocio y Obtencin de Requerimientos

tercera, el analista debe contemplar la traduccin de los requerimientos a una

En este proyecto se realiz un modelo del negocio, utilizando el mtodo BMM

Modelo del Negocio y Obtencin de Requerimientos

El resultado final de un proyecto de software es un producto que toma forma a

La calidad del producto final, est

estrechamente ligada a la calidad del proceso de desarrollo de software, en el

"La parte ms difcil de construir un sistema es precisamente saber qu

Ninguna otra parte del trabajo conceptual es tan difcil como

establecer los requerimientos tcnicos detallados, incluyendo todas las

Ninguna otra parte del