Sistema de Informacion para El Control, Seguimiento y Mantenimiento Del Equipamiento Hospitalario

UNIVERSIDAD RICARDO PALMA
FACULTAD DE INGENIERIA
E
E.. A
A.. P
P.. D
DEE IIN
NGGE
ENNIIE
ERRIIA
A IIN
NFFO
ORRM
MAAT
TIIC
CAA
SISTEMA DE INFORMACION PARA EL

CONTROL, SEGUIMIENTO Y
MANTENIMIENTO DEL EQUIPAMIENTO
HOSPITALARIO
PROYECTO DE TESIS
PARA OPTAR EL TITULO PROFESIONAL DE
INGENIERO INFORMATICO
PRESENTADO POR:
VICTOR HUGO CHVEZ GMEZ
LIMA PER
2010
Titulo del Proyecto:
SISTEMA DE INFORMACION PARA EL
CONTROL, SEGUIMIENTO Y MANTENIMIENTO
DEL EQUIPAMIENTO HOSPITALARIO
Hospital Central de la Fuerza Area del Per
Departamento de Ingeniera
AUTOR:
VICTOR HUGO CHAVEZ GOMEZ
ii
DEDICATORIA:
Hago un reconocimiento muy especial y

dedico este trabajo a mis Padres Victor
y Anglica, con la mayor gratitud y
admiracin por los esfuerzos realizados
para lograr concretar mi carrera
profesional, siendo para m la mayor
ilusin y mejor herencia.
iii
AGRADECIMIENTOS
Al trmino de este Proyecto de Tesis que representa la culminacin

satisfactoria de mi carrera profesional de Ingeniera Informtica, quiero
agradecer a las siguientes personas que han ayudado a que esta tarea llegue a
su fin.
En primer lugar a Dios, por haberme permitido llegar al final de esta etapa.
A mis padres Victor y Anglica, por su incesante trabajo y esfuerzo por

brindarme una mejor educacin.
Al profesor asesor Ing. Miguel Tamayo Zumaeta, quien me orient con tanto
profesionalismo y paciencia para el desarrollo de esta tesis.
A mis amigos y dems familiares, quienes me brindaron su apoyo, ayuda y

entusiasmo en todo momento y confiaron siempre que concluira el presente
trabajo.
Por ltimo, quiero agradecer al Dr. Silverio Bustos Daz y a la Escuela de

Ingeniera Informtica de la Universidad Ricardo Palma, por haberme
brindado la oportunidad de incrementar mis conocimientos y habilidades en
el campo de la Ingeniera Informtica.
iv
RESUMEN
SISTEMA DE INFORMACION PARA EL CONTROL,

SEGUIMIENTO Y MANTENIMIENTO DEL
EQUIPAMIENTO HOSPITALARIO

e-mail: vhugochavez@gmail.com
Febrero - 2010
Profesor Asesor : Ing. Miguel Tamayo Zumaeta

Titulo a Obtener : Ingeniero Informtico
El presente trabajo de investigacin tiene como propsito fundamental

presentar una solucin que permita administrar de forma eficiente y confiable
toda la informacin respecto al control, seguimiento y mantenimiento del
equipamiento hospitalario. Para ello se tom como objeto de estudio al
Departamento de Ingeniera del Hospital Central de la Fuerza Area del Per,
el cual presenta muchas deficiencias de carcter administrativo en sus
procesos internos de recepcin, registro y cierre de rdenes de Trabajo as
como el mantenimiento preventivo y correctivo de los equipos hospitalarios del
HCFAP. La solucin contemplada abarca desde el anlisis y diseo hasta el
desarrollo de algunos casos de uso ms significativos de la aplicacin.
PALABRAS CLAVES: Equipos Hospitalarios

HCFAP
Mantenimiento Correctivo
Mantenimiento Predictivo
Mantenimiento Preventivo
Orden de Trabajo
v
ABSTRACT
INFORMATION SYSTEM FOR THE CONTROL,

MONITORING AND MAINTENANCE OF THE HOSPITAL
EQUIPMENT

e-mail: vhugochavez@gmail.com
February - 2010
Professor : E. Miguel Tamayo Zumaeta

Professional Title : Systems Engineering
The main purpose of this research is to present a solution that enable to

manage efficient and reliable way, all of the information in relation to control,
tracking and the hospital equipment maintenance. So, was taken as an object of
study of Engineering Department of the Central Hospital of the Air Force of
Peru, which presents a lot of administrative deficiencies character in its internal
processes of reception, record and closing of Work Orders as well as the
preventive and corrective maintenance of the hospital equipment of the HCFAP.
The contemplated solution comprises from analysis and design to the
development of some use cases more significant of the application.
KEYWORDS: Hospital Equipment

HCFAP
Corrective Maintenance
Predictive Maintenance
Preventive Maintenance
Work Order
vi
INDICE DE CONTENIDOS
Dedicatoria iii
Agradecimientos iv
Resumen v
Abstract vi
ndice de Contenidos vii
ndice de Figuras xiii
ndice de Tablas xvii
Introduccin xix
1. CAPITULO I: PLANTEAMIENTO DEL PROBLEMA 1

1.1 Planteamiento del Problema de Investigacin 2
1.2 Delimitacin del Problema 3
1.2.1 Limite Espacial 3
1.2.2 Lmite Temporal 3
1.3 Formulacin del Problema 3
1.4 Objetivos 3
1.4.1 Objetivo General 3
1.4.2 Objetivos Especficos 3
1.5 Formulacin de la Hiptesis 4
1.5.1 Hiptesis General 4
1.6 Seleccin de Variables 4
1.6.1 Variable Dependiente 4
1.6.2 Variable Independiente 4
1.7 Lnea de Investigacin 4
1.8 Justificacin e Importancia de la Investigacin 4
1.9 Alcances de la Investigacin 5
2. CAPITULO II: MARCO TEORICO CONCEPTUAL 7

2.1 Antecedentes de la Investigacin 8
2.1.1 Historia del Mantenimiento 8
2.1.2 Evolucin del Mantenimiento 9
vii
2.1.3 Crisis del Mantenimiento Hospitalario en el Mundo 11
2.2 Bases Tericas 12
2.2.1 El Hospital 12
2.2.1.1 Definicin de Hospital 12
2.2.1.2 Origen 12
2.2.1.3 Estructura 14
2.2.1.4 Clasificacin 16
2.2.2 El Mantenimiento 16
2.2.2.1 Definicin de Mantenimiento 16
2.2.2.2 Tipos de Mantenimiento 18
2.2.2.3 Etapas del Mantenimiento 23
2.2.2.4 Actividades en el Mantenimiento 25
2.2.2.5 Clasificacin de las Fallas del Equipamiento 28
2.2.2.6 Gestin del Mantenimiento 29
2.2.2.7 Situacin Actual del Mantenimiento 33
2.3 Diagnstico de la Situacin Actual de los Establecimientos del Sector
Salud en el Per 35
2.3.1 Organizacin de la Oferta de Servicios de Salud 35
2.3.2 Demanda 36
2.3.3 Oferta de Servicios de Salud 36
2.3.4 Complejidad de los Establecimientos de Salud 38
2.3.5 Nivel de Complejidad 38
2.3.6 Nivel de Atencin 39
2.3.7 Categorizacin 40
2.3.8 Categoras 41
2.4 Diagnstico de la Situacin Actual del Hospital Central de la Fuerza
Area del Per 45
2.4.1 Resea Histrica del Hospital Central FAP 45
2.4.2 Aspectos Generales del Hospital Central FAP 47
2.4.2.1 Visin del HCFAP 47
2.4.2.2 Misin del HCFAP 48
2.4.2.3 Valores Corporativos del HCFAP 48
2.4.2.4 Infraestructura 48
2.4.2.5 Equipamiento 50
viii
2.4.2.6 Recursos Humanos 52
2.4.2.7 Personal Afiliado al HCFAP 53
2.4.2.8 Servicios Asistenciales 54
2.4.2.9 Organizacin del Hospital Central FAP 55
2.4.3 Aspectos Generales del Departamento de Ingeniera del HCFAP 58
2.4.3.1 Visin 58
2.4.3.2 Tarea 58
2.4.3.3 Organizacin del Departamento de Ingeniera del HCFAP 58
2.5 Marco Legal 64
2.5.1 Del Estado Peruano 64
2.5.2 Del Sector Salud 64
2.5.3 Del Sector Defensa 65
2.5.4 De la Fuerza Area del Per 66
3. CAPITULO III: ESTADO DEL ARTE 68

3.1 Taxonoma 69
3.2 Revisin de Mtodos y Metodologas 70
3.2.1 Metodologas de Desarrollo de Software 70
3.2.1.1 Historia 71
3.2.1.2 Modelos de Desarrollo de Software 71
3.2.1.3 Mtodos Heterodoxos en Desarrollo de Software 79
3.2.2 Metodologas Propuestas para el Proyecto de Tesis 85
3.2.2.1 Rational Unified Process (RUP) 85
3.2.2.2 Extreme Programming (XP) 114
3.2.2.3 Feature Driven Development (FDD) 128
3.2.3 Metodologa Elegida para el Proyecto de Tesis 136
3.3 Software o Sistemas Existentes 137
3.3.1 Software Terema CMMS 137
3.3.1.1 Principales Caractersticas 138
3.3.1.2 Caractersticas importantes a tomar en cuenta 143
3.3.2 Software Bigfoot CMMS 144
3.3.2.2 Principales Beneficios 146
ix
3.3.3 Software AMPRO CMMS 148
3.3.3.2 Mdulos Adicionales de AMPRO 150
4. CAPITULO IV: METODOLOGIA DE LA INVESTIGACIN 154

4.1 Tipo de Investigacin 155
4.2 Diseo de la Investigacin 155
4.3 Poblacin 155
4.4 Muestra de Estudio 155
4.5 Muestreo 155
4.6 Criterios de Seleccin 156
4.7 Tcnicas e Instrumentos de Recoleccin de Datos 156
4.7.1 Tcnicas de Recoleccin de Datos 156
4.7.2 Instrumentos o Equipo Auxiliar a Utilizar 157
4.7.3 Procesamiento y Presentacin de Datos 158
5. CAPITULO V: CONTRIBUCIN 159

5.1 Estudio de Factibilidad 160
5.1.1 Factibilidad Operativa 160
5.1.2 Factibilidad Tcnica 161
5.1.3 Factibilidad Econmica 163
5.1.3.1 Puntos de Caso de Uso 163
5.1.3.2 COSYSMO 171
5.2 Generalidades de la Aplicacin 177
5.2.1 Posicionamiento del Producto 177
5.2.1.1 Oportunidad de Negocio 177
5.2.1.2 Declaracin del Problema a Resolver 178
5.2.1.3 Declaracin del Posicionamiento del Producto 179
5.2.2 Vista Global del Producto 180
5.2.2.1 Perspectiva del Producto 180
5.2.2.2 Sumario de Capacidades 180
5.2.2.3 Suposiciones y Dependencias 180
5.2.2.4 Licencias e Instalacin 181
x
5.3 Anlisis Comparativo Benchmarking 181
5.4 Modelado de la Aplicacin 184
5.4.1 Actores del Sistema 184
5.4.2 Mdulos del Sistema 184
5.4.3 Diagramas de Casos de Uso del Sistema 185
5.4.4 Diagramas de Secuencia de los Casos de Uso 193
5.4.5 Modelo de Datos 201
5.4.6 Diagrama de Componentes 202
5.4.7 Diagrama de Despliegue 204
5.4.8 Diagrama de Arquitectura de Capas 205
5.4.9 Interfases del Sistema 206
5.5 Estndares Utilizados 225
5.5.1 Estndares de Documentos 225
5.5.2 Estndares de Anlisis 226
5.5.3 Estndares de Diseo 228
5.5.4 Estndares de Programacin 229
5.5.5 Estndares de Base de Datos 232
6. CAPITULO VI: ADMINISTRACIN DEL PROYECTO 235

6.1 Estructura Detallada del Trabajo (EDT) 236
6.2 Cronograma de Actividades 238
6.3 Anlisis de Riesgos 244
6.4 Descripcin de los Recursos 246
6.5 Presupuesto de Inversin 248
7. CAPITULO VII: CONCLUSIONES Y RECOMENDACIONES 249

7.1 Conclusiones 250
7.2 Recomendaciones 252
8. GLOSARIO DE TERMINOS 253
9. SIGLARIO 259
10. REFERENCIAS BIBLIOGRAFICAS 264
xi
10.1 Libros y Revistas 264
10.2 Pginas Web 266
10.3 Tesis 268
11. ANEXOS 269

11.1 Anexo A 270
11.2 Anexo B 279
11.3 Anexo C 284
11.4 Anexo D 289
11.5 Anexo E 295
11.6 Anexo F 300
xii
INDICE DE FIGURAS
Figura 1. Proceso de calibracin a un equipo electromecnico. 26

Figura 2. Realizacin del proceso de limpieza. 27
Figura 3. Realizacin del proceso de lubricacin a una parte mecnica. 28
Figura 4. Tipos de fallas en el equipamiento. 29
Figura 5. Sistema Tpico de Mantenimiento 30
Figura 6. Caractersticas de la Demanda y su Relacin con las Caractersticas
de la Oferta 38
Figura 7. Hospital Central de la Fuerza Aerea del Per 47
Figura 8. Instituto de Salud Oral y Atenciones Geritricas (ISOFAP) 49
Figura 9. Equipos Biomdicos de ltima generacin 50
Figura 10. Plantel de Profesionales Mdicos del Hospital Central FAP 52
Figura 11. Total de Trabajadores del Hospital Central FAP 53
Figura 12. Total de Titulares y Familiares de la FAP 54
Figura 13. Organigrama del Hospital Central FAP 57
Figura 14. Organigrama del Departamento de Ingeniera del Hospital Central FAP 63
Figura 15. Pagina Web del Sistema de Clasificacin Informtica de la ACM 69
Figura 16. Tres modelos bsicos en las metodologas de desarrollo de software 72
Figura 17. El Modelo original en Cascada 73
Figura 18. El Modelo Espiral de 6 Actividades 74
Figura 19. Modelo de Prototipos 75
Figura 20. Modelo Incremental 76
Figura 21. RAD vs. Metodologa Tradicional 78
Figura 22. Historia de RUP 85
Figura 23. Los Casos de Uso integran el trabajo 87
Figura 24. Trazabilidad a partir de los Casos de Uso 87
Figura 25. Evolucin de la arquitectura del sistema 89
Figura 26. Los modelos se completan, la arquitectura no cambia drsticamente 90
Figura 27. Una iteracin RUP 91
Figura 28. Esfuerzo en actividades segn fase del proyecto 92
Figura 29. Estructura de RUP 96
xiii
Figura 30. Ciclos, releases, baseline 96
Figura 31. Fases e hitos en RUP 97
Figura 32. Distribucin tpica de recursos humanos 98
Figura 33. Relacin entre roles, actividades, artefactos 104
Figura 34. Detalle de un workflow mediante roles, actividades y artefactos 104
Figura 35. Practicas de XP 116
Figura 36. Ciclo de vida de eXtreme Programming 120
Figura 37. Roles Principales de FDD 131
Figura 38. Proceso FDD 133
Figura 39. Ciclo de FDD 134
Figura 40. Mdulos del Software TeReMa 138
Figura 41. Modulo de Orden de Trabajo del Software TeReMa 139
Figura 42. Generador de reportes del Software TeReMa 140
Figura 43. Pantalla de Requerimiento de Trabajo del Software TeReMa 142
Figura 44. Contacto del fabricante del Software TeReMa 143
Figura 45. Pantalla Principal del Software Bigfoot 144
Figura 46. Calendario de Mantenimiento Preventivo del Software Bigfoot 145
Figura 47. Compaas que usan el Software Bigfoot 146
Figura 48. Gestin de las rdenes de Trabajo del Software Bigfoot 147
Figura 49. Principales beneficios del software AMPRO 148
Figura 50. Pantalla principal del software AMPRO 149
Figura 51. Detalles de una Solicitud de Trabajo del software AMPRO 151
Figura 52. Men Principal de AMPRO Portable Edition en una PDA 152
Figura 53. Detalles de una Solicitud de Trabajo de AMPRO PE 152
Figura 54. Detalles de un Equipo Compresor de Aire 153
Figura 55. Ventana de Informacin de versin de SystemStar 172
Figura 56. Ingreso de las configuraciones de tamao por Componente 173
Figura 57. Ingreso de los Factores de Costo por Componente 174
Figura 58. Tamao Entregado del Proyecto 175
Figura 59. Ingreso de los Costos por Componente 175
Figura 60. Ingreso de nombres y tarifas de los tipos de trabajo 176
Figura 61. Ingreso del tiempo de duracin del Proyecto 177
Figura 62. Actores del Sistema 184
Figura 63. Mdulos del Sistema 184
xiv
Figura 64. Diagrama de Casos de Uso del Modulo Seguridad 185
Figura 65. Diagrama de Casos de Uso del Modulo Mantenimiento 186
Figura 66. Diagrama de Casos de Uso del Modulo Ordenes de Trabajo 188
Figura 67. Diagrama de Casos de Uso del Modulo Equipos Hospitalarios 190
Figura 68. Diagrama de Casos de Uso del Modulo Preventivo 191
Figura 69. Diagrama de Secuencia: Caso de Uso Iniciar Sesin 193
Figura 70. Diagrama de Secuencia: Caso de Uso Administrar Perfil 193
Figura 71. Diagrama de Secuencia: Caso de Uso Administrar Usuario 194
Figura 72. Diagrama de Secuencia: Caso de Uso Administrar Privilegios 195
Figura 73. Diagrama de Secuencia: Caso de Uso Solicitar Orden de Trabajo 196
Figura 74. Diagrama de Secuencia: Caso de Uso Consultar Estado de Reparacin 197
Figura 75. Diagrama de Secuencia: Caso de Uso Cerrar Orden de Trabajo 198
Figura 76. Diagrama de Secuencia: Caso de Uso Delegar Orden de Trabajo 199
Figura 77. Diagrama de Secuencia: Caso de Uso Administrar Proveedor 199
Figura 78. Diagrama de Secuencia: Caso de Uso Administrar Personal por Divisin200
Figura 79. Diagrama de Secuencia: Caso de Uso Consultar Inventario de Equipos 200
Figura 80. Diagrama de Secuencia: Caso de Uso Administrar Ficha Tcnica 201
Figura 81. Modelo de Datos del Sistema 202
Figura 82. Diagrama de Componentes del Sistema 203
Figura 83. Diagrama de Despliegue del Sistema 204
Figura 84. Diagrama de Arquitectura de 03 Capas 206
Figura 85. Ventana de Inicio de Sesin 206
Figura 86. Men Principal del Sistema de Gestin del Equipamiento Hospitalario 207
Figura 87. Administrar Equipamiento Hospitalario 207
Figura 88. Modificar Equipamiento Hospitalario 208
Figura 89. Administrar Departamentos 208
Figura 90. Administrar Secciones de los Departamentos 209
Figura 91. Administrar Divisiones del Departamento de Ingeniera 209
Figura 92. Administrar Personal del Departamento de Ingeniera 210
Figura 93. Administrar Proveedores 210
Figura 94. Administrar Ficha Tcnica 211
Figura 95. Registrar Ficha Tcnica de un equipo 211
Figura 96. Consultar Inventario de Equipos Hospitalarios 212
Figura 97. Reporte de Inventario de Equipos Hospitalarios 212
xv
Figura 98. Consultar Registro Histrico del Equipamiento 213
Figura 99. Detalle de Registro Histrico de un Equipo Hospitalario 213
Figura 100. Registrar Tarea de Mantenimiento Preventivo 214
Figura 101. Registrar Actividad de la Tarea de Mantenimiento 214
Figura 102. Agregar Repuesto y Material que se utilizar en la Tarea 214
Figura 103. Administrar Programacin de Mantenimiento Preventivo 215
Figura 104. Registrar Programacin de Mantenimiento Preventivo 215
Figura 105. Administrar Genricos 216
Figura 106. Registrar Genrico 216
Figura 107. Administrar Repuestos, Accesorios y Materiales 217
Figura 108. Registrar Repuestos, Accesorios y Materiales 217
Figura 109. Administrar Orden de Trabajo Pendiente 218
Figura 110. Registrar Orden de Trabajo Pendiente 218
Figura 111. Administrar Orden de Trabajo Realizada 219
Figura 112. Registrar Orden de Trabajo Realizada 219
Figura 113. Consultar Ordenes de Trabajo 220
Figura 114. Consultar Responsables por Orden de Trabajo 220
Figura 115. Administrar Informe Tcnico 221
Figura 116. Registrar Informe Tcnico 222
Figura 117. Administrar Usuarios del Sistema 222
Figura 118. Registrar Usuario del Sistema 223
Figura 119. Administrar Perfiles del Sistema 223
Figura 120. Administrar Opciones 224
Figura 121. Administrar Opciones por Perfiles 224
xvi
INDICE DE TABLAS
Tabla 1. Generaciones del Mantenimiento 10

Tabla 2. Niveles de atencin, Niveles de complejidad y Categoras de
Establecimientos del Sector Salud 40
Tabla 3. Categoras de los Establecimientos de Salud de acuerdo a las
Instituciones del Sector Salud 43
Tabla 4. Cuadro Comparativo de los Tipos de Categoras de los
Establecimientos de Salud en Latinoamrica 44
Tabla 5. Cuadro Comparativo Nacional 45
Tabla 6. Ficha Tcnica del Hospital Central FAP 48
Tabla 7. Numero de Habitaciones y Camas del HCFAP 49
Tabla 8. Ficha Tcnica del Instituto de Salud Oral y Atenciones Geritricas 49
Tabla 9. Total del Equipamiento Hospitalario del Hospital Central FAP 50
Tabla 10. Antigedad de los Equipos e Instalaciones del HCFAP 52
Tabla 11. Total de Titulares y Familiares de la FAP 53
Tabla 12. Total de Titulares FAP en Actividad y en Retiro 54
Tabla 13. Redes Hospitalarias del Hospital Central FAP 61
Tabla 14. Sistemas Electromecnicos Hospitalarios 62
Tabla 15. Historia de las Metodologas de Desarrollo de Software 71
Tabla 16. Mtodos giles ms utilizados 81
Tabla 17. Diferencias entre metodologas giles y no giles 84
Tabla 18. Distribuciones tpicas de esfuerzo y tiempo 97
Tabla 19. Modelo propuesto para una historia de usuario 124
Tabla 20. Modelo propuesto para una prueba de aceptacin 125
Tabla 21. Modelo propuesto para una tarea de ingeniera 126
Tabla 22. Modelo de tarjeta CRC 126
Tabla 23. Plan de rasgo - Implementacin 135
Tabla 24. Tcnicas de Recoleccin de Datos con sus respectivos Instrumentos 158
Tabla 25. Peso de los actores sin ajustar 164
Tabla 26. Identificacin de los Actores del Sistema 164
Tabla 27. Peso de las Transacciones 165
xvii
Tabla 28. Identificacin de los Casos de Uso del Sistema 166
Tabla 29. Calculo de los Casos de Uso Desajustados 167
Tabla 30. Calculo del Factor de Complejidad Tcnica 168
Tabla 31. Tabla de Niveles y Factores Ambientales 168
Tabla 32. Calculo del Factor de Ambiente 169
Tabla 33. Distribucin porcentual de las Actividades 171
Tabla 34. Distribucin porcentual del Esfuerzo total del Proyecto 171
Tabla 35. Declaracin del Problema a Resolver 178
Tabla 36. Declaracin del Posicionamiento del Producto 179
Tabla 37. Especificaciones de Casos de Uso del Modulo Seguridad 186
Tabla 38. Especificaciones de Casos de Uso del Modulo Mantenimiento 187
Tabla 39. Especificaciones de Casos de Uso del Modulo rdenes de Trabajo 189
Tabla 40. Especificaciones de Casos de Uso del Modulo Equipos Hospitalarios 191
Tabla 41. Especificaciones de Casos de Uso del Modulo Preventivo 192
Tabla 42. Formato de Documentos para el Informe de Tesis 225
Tabla 43. Formato de Espacios para el Informe de Tesis 225
Tabla 44. Formato de Pgina para el Informe de Tesis 226
Tabla 45. Prefijos de Variables para los elementos de Programacin 230
Tabla 46. Prefijos de Controles para los elementos de Programacin 231
Tabla 47. Prefijos de Variables para Objetos de Base de Datos 231
Tabla 48. Prefijos de Instancias de Clase 231
Tabla 49. Prefijos de Nombre de Funciones 232
Tabla 50. Identificacin de los principales riesgos del proyecto 246
Tabla 51. Identificacin de los gastos durante el desarrollo del proyecto 248
xviii
INTRODUCCION
La ciencia y la tecnologa han influido mucho en la forma de ejercer la medicina. Los

equipos para el diagnstico y tratamiento de las diversas patologas son cada vez ms
necesarios y sofisticados. Los equipos deben funcionar en forma precisa y eficiente, de
otra forma podran generar desde gastos intiles hasta la muerte de los pacientes. El
deterioro de los equipos significa una descapitalizacin y un incremento de los costos,
adems los pacientes tienen derecho a ser atendidos eficientemente.
El funcionamiento de los equipos hospitalarios, desde los ms modestos hasta los que
cuentan con amplios recursos en su administracin, se caracterizan por una
interrelacin de servicios o departamentos que procuran en primera instancia el
objetivo de proporcionar, mantener o devolver la salud a las personas que a ellos
acuden.
El hecho de que todos los servicios en general y cada uno en particular tengan relacin
con el servicio de mantenimiento, coloca a este en un plano de gran importancia no
solamente porque en mayor o menor grado dependan de el para su adecuado
funcionamiento, sino por la responsabilidad que tal dependencia implica. El grado de
desarrollo que en trminos generales haba tenido el mantenimiento hospitalario, en
comparacin con otros servicios de las unidades medicas, en forma realista podemos
calificarlos de pobre.
Ha sido en los ltimos aos, quizs en el ltimo decenio, cuando ha surgido una
conciencia institucional para promover el desarrollo y una administracin ms moderna
y efectiva del mantenimiento de las unidades medicas. Tal conciencia es consecuencia
lgica y natural de una necesidad, necesidad que siempre ha existido, pero que en la
actualidad no puede ya soslayarse: Conservar mejor las unidades mdicas a un costo
razonable.
xix
Por ello es tan importante el mantenimiento de los equipos hospitalarios, tanto el
MANTENIMIENTO PREVENTIVO para evitar posibles fallas o accidentes como el
MANTENIMIENTO CORRECTIVO para dar solucin a las averas al ms corto plazo.
Cualquier accin correctiva o preventiva que se tome debe garantizar la completa
funcionalidad del equipo para evitar perjudicar a los pacientes, los trabajadores y la
institucin.
El Autor
xx
CAPITULO I:
PLANTEAMIENTO DEL PROBLEMA
1|Pgina
1.1. Planteamiento del Problema de Investigacin
El Servicio de Mantenimiento Hospitalario se est convirtiendo en un dilema para
todos los gestores del pas. Todo Gerente o Ejecutivo Hospitalario estar
consciente de que una de las reas ms determinantes de su Hospital, tanto
desde el punto de vista de servicio como en lo relacionado al control de gastos,
es el Departamento de Ingeniera o Mantenimiento. Sin embargo y a pesar de
esta realidad innegable, hoy en da los procesos de esta importante rea son
operados bsicamente de forma manual, con las faltas de productividad y
eficiencia que esto representa, siendo sumamente escasos los Hospitales que
tienen sus procesos debidamente automatizados.
En la mayora de Hospitales de nuestro pas, no existe un Sistema Informtico

para la gestin del Mantenimiento Preventivo y Correctivo del Equipamiento
Hospitalario, que permita brindar informacin clara y oportuna acerca de las
operaciones de mantenimiento y reparacin de equipos hospitalarios que se
realizan durante el da a da.
Dentro del presupuesto asignado para el Sector Salud que se recibe del
Presupuesto General Anual de la Repblica, la asignacin destinada para el re-
equipamiento de equipos mdicos, biomdicos y electromecnicos en los
hospitales nacionales es cada vez ms exigua. La implicancia de este reducido
presupuesto son los inadecuados diagnsticos y falta de certeza en la
operatividad e inoperatividad de los equipos hospitalarios por parte de los
Hospitales y Centros Mdicos.
Debido a ello, en el Hospital Central de la Fuerza Area del Per no existe un

adecuado control, seguimiento y mantenimiento automatizado del equipamiento
hospitalario biomdico, medico y electromecnico; en consecuencia no se
cuenta con una informacin real de la situacin de operatividad e inoperatividad
de los equipos hospitalarios, imprecisin de los costos de mantenimiento as
como la falta de informacin conjunta y ordenada de los recursos humanos de
los servicios de mantenimiento, impidiendo as la planificacin correcta de las
actividades propias de mantenimiento.
2|Pgina
1.2. Delimitacin del Problema
1.2.1. Limite Espacial
La presente investigacin se realiz en el Departamento de Ingeniera
del Hospital Central de la Fuerza Area del Per, ubicado en la Avenida
Aramburu cdra. 2 s/n, en el distrito de Miraflores Lima, Per.
1.2.2. Lmite Temporal

La investigacin abarc el periodo Marzo 2008 - Diciembre 2009.
1.3. Formulacin del Problema

De qu manera el anlisis, diseo, desarrollo e implementacin de un Sistema
de Informacin para el Control, Seguimiento y Mantenimiento del Equipamiento
Hospitalario, mediante el uso de una metodologa gil, influyen en el adecuado
servicio de calidad del Departamento de Ingeniera en el Hospital Central de la
Fuerza Area del Per?.
1.4. Objetivos
1.4.1. Objetivo General
Analizar, disear, desarrollar e implementar un Sistema de Informacin
para el Control, Seguimiento y Mantenimiento del Equipamiento
Hospitalario en el Hospital Central de la Fuerza Area del Per.
1.4.2. Objetivos Especficos

Servir como Herramienta de Gestin para el Departamento de
Ingeniera del Hospital Central FAP y facilitar la toma de decisiones.
Conseguir la mxima disponibilidad, fiabilidad y seguridad de las

instalaciones y equipos hospitalarios, con ndices de eficacia,
eficiencia y calidad apropiados, conociendo en todo momento el
estado de adecuacin y conservacin del inventario, para elaborar y
3|Pgina
ejecutar las polticas tanto de mantenimiento como de reposicin ms
adecuadas.
Planificacin, control y seguimiento de todas las actividades de

mantenimiento, tanto correctivo como preventivo.
1.5. Formulacin de la Hiptesis

1.5.1. Hiptesis General
El anlisis, diseo, desarrollo e implementacin de un Sistema de
Informacin para el Control, Seguimiento y Mantenimiento del
Equipamiento Hospitalario, mediante el uso de una metodologa gil,
influyen en el adecuado servicio de calidad del Departamento de
Ingeniera en el Hospital Central de la Fuerza Area del Per.
1.6. Seleccin de Variables

1.6.1. Variable Dependiente
Servicio de Calidad.
1.6.2. Variable Independiente

Sistema de Informacin para el Mantenimiento del Equipamiento
Hospitalario.
1.7. Lnea de Investigacin

Este trabajo de tesis pertenece al rea temtica de Sistemas de Informacin
Empresarial.
1.8. Justificacin e Importancia de la Investigacin

Proporcionar un Sistema de Informacin que le permita a los usuarios obtener de
manera rpida y confiable la informacin acerca de las rdenes de Trabajo que
han solicitado, Inventarios, Registros Histricos e Informes Tcnicos de equipos
hospitalarios as como otras consultas de vital importancia; es decir contar con la
4|Pgina
planificacin, control y seguimiento de todas las actividades de mantenimiento,
tanto correctivo como preventivo.
El sistema de informacin cubrir el control y seguimiento de las tareas de

mantenimiento y/o reparacin del equipamiento, en este caso las rdenes de
Trabajo y Solicitudes de Servicio, con requerimientos solicitados por los distintos
Departamentos y Secciones del Hospital. Tambin cubrir el control y
seguimiento del Mantenimiento Preventivo as como el Inventario e Historial del
equipamiento hospitalario. Con esto se evitar las demoras y cuellos de botella
que se originan en la recepcin, registro y asignacin de las rdenes de trabajo
al personal especialista, as como otros trmites importantes que se realizan en
forma manual. De esta forma se evitara el malestar en los usuarios del hospital
que no tienen una respuesta rpida a sus rdenes de trabajo solicitadas en su
tiempo adecuado.
1.9. Alcances de la Investigacin

En la presente tesis se tiene pensado plantear una solucin para la gestin del
equipamiento hospitalario del Hospital Central FAP, contemplando para ello un
Inventario de Equipos Hospitalarios en donde se van a mostrar todos los equipos
biomdicos, mdicos y electromecnicos con los que cuenta el hospital, de una
forma clara, precisa y ordenada. Se podr distinguir los equipos operativos,
inoperativos y de baja que tiene una determinada rea usuaria, seccin o
departamento mediante un reporte por estado de operatividad.
El desarrollo de dicha solucin est conformado por cinco mdulos integrados

en un solo software. El primer modulo del software llamado Mantenimiento,
comprender el control y registro de las principales tablas que suministran la
informacin bsica al Sistema. El segundo modulo llamado Equipos
Hospitalarios estar conformado por la Ficha Tcnica y las consultas del
Inventario y del Registro Histrico, los cuales contemplan toda la informacin
referente a los equipos del Hospital Central FAP. El tercer modulo llamado
Preventivo realizar los Mantenimientos Preventivos a los Equipos
Hospitalarios, considerando los parmetros de tiempo de ejecucin, personal
que se encargara de dicha ejecucin y el costo que implica. El cuarto modulo
5|Pgina
llamado rdenes de Trabajo registrar las Ordenes de Trabajo y Solicitudes de
Servicio para Equipos Hospitalarios e Instalaciones. Por ltimo, el quinto modulo
se encargar de la Seguridad, creando los usuarios del sistema y la creacin de
perfiles de acceso al sistema.
En resumen, se implementar un Sistema de Informacin para el Control,

Seguimiento y Mantenimiento del Equipamiento Hospitalario, que
gestionar de manera ptima el flujo del proceso de reparacin y mantenimiento
de un equipo hospitalario en el Hospital Central de la Fuerza Area del Per.
6|Pgina
CAPITULO II:
MARCO TERICO CONCEPTUAL
7|Pgina
2.1. Antecedentes de la Investigacin
2.1.1. Historia del Mantenimiento
La historia de mantenimiento acompaa el desarrollo Tcnico-Industrial
de la humanidad. Al final del siglo XIX, con la mecanizacin de las
industrias, surgi la necesidad de las primeras reparaciones.
Hasta 1914, el mantenimiento tena importancia secundaria y era

ejecutado por el mismo personal de operacin o produccin.
Con el advenimiento de la primera guerra mundial y la implantacin de la

produccin en serie, el mantenimiento fue instituida por la
compaa Ford-Motor Company, fabricante de vehculos; las fabricas
pasaron a establecer programas mnimos de produccin y, en
consecuencia, sentir la necesidad de crear equipos que pudieran
efectuar el mantenimiento de las maquinas de la lnea de produccin en
el menor tiempo posible.
As surgi un rgano subordinado a la operacin, cuyo objetivo bsico

era la ejecucin del mantenimiento, hoy conocida como mantenimiento
correctivo. Esa situacin se mantuvo hasta la dcada de los aos 30,
cuando en funcin de la segunda guerra mundial y de la necesidad de
aumentar la rapidez de la produccin, la alta administracin industrial se
preocup no solo en corregir fallas, sino evitar que estas ocurriesen, y el
personal tcnico de mantenimiento pas a desarrollar el proceso del
mantenimiento preventivo de las averas que, juntamente con la
corrosin, completaban el cuadro general de mantenimiento como de la
operacin o produccin.
Por el ao 1950, con el desarrollo de la industria para atender a los

esfuerzos de la post-guerra, la evolucin de la aviacin comercial y de la
industria electrnica; los gerentes de mantenimiento observaron que en
muchos casos el tiempo de para de la produccin para diagnosticar las
fallas era mayor que la ejecucin de la reparacin; el da lugar a
seleccionar un equipo de especialistas para componer un rgano de
8|Pgina
asesoramiento a la produccin que se llam Ingeniera de
Mantenimiento y recibi los cargos de planear y controlar el
mantenimiento preventivo y analizar causas y efectos de las averas.
A partir de 1966, con el fortalecimiento de las asociaciones nacionales

de mantenimiento creadas al final del periodo anterior y la sofisticacin
de los instrumentos de proteccin y medicin, la ingeniera de
mantenimiento pasa a desarrollar criterios de prediccin o previsin de
fallas, visando la optimizacin de la actuacin de los equipos de
ejecucin de mantenimiento.
Esos criterios conocidos como mantenimiento PREDICTIVO O

PREVISIVO, fueron asociados a mtodos de planeamiento y control de
mantenimiento. As tambin hay otros tipos de mantenimiento como de
precisin, de clase mundial (pro activo) y mejora continua.
2.1.2. Evolucin del Mantenimiento

En toda actividad hospitalaria o de servicio, debe existir un objetivo bien
determinado; obtener el mximo de rentabilidad para una inversin
efectuada. Es indiscutible que despus de la construccin y montaje de
la estructura de produccin, tanto para entidades de carcter tcnico
como administrativo, asume preponderancia de las atenciones de los
niveles estratgicos y ejecutivo; bajo ese enfoque, los responsables por
las funciones de administracin y desarrollo del personal, suministro de
materiales y repuestos, provisin y el acompaamiento presupuestario,
Bio-seguridad fsica e industrial, bienestar social, conservacin y
limpieza, deben estar concientes de la importancia de prestar un apoyo
integral.
9|Pgina
Generacin del Mantenimiento Evolucin
El mantenimiento tena importancia
Antes de 1914
secundaria.
Iniciacin Surgi la necesidad de las primeras
1914 hasta 1930 reparaciones.
Primera Generacin Gestin de mantenimiento hacia la
Entre 1930 - 1950 maquina.
Segunda Generacin Gestin de mantenimiento hacia la
Entre 1950 - 1960 (aprox.) produccin.
Tercera Generacin Gestin de mantenimiento hacia la
Entre 1960 - 1980 productividad.
Cuarta Generacin Gestin de mantenimiento hacia la
Entre 1980 - 1999 competitividad.
Gestin de mantenimiento hacia la
Quinta Generacin
organizacin e innovacin tecnologa
Entre 2000 - 20xx
industrial (terotecnologa).
Sexta Generacin Gestin del mantenimiento en busca de la
Entre 2003 - mejora contnua.
Tabla 1. Generaciones del Mantenimiento. Fuente: Curso de Ingeniera de Mantenimiento Hospitalario

(www.mailxmail.com) Elaboracin Propia
La evolucin del mantenimiento de maquinaria ha progresado desde:
El Mantenimiento Correctivo (intervenir cuando falle) al
Mantenimiento preventivo (intervencin por intervalos) a
Mantenimiento predictivo o monitoreo de condicin
Mantenimiento Integral (predictivo, preventivo, correctivo) Luego
Mantenimiento de precisin, hasta
El mantenimiento & mejora continua
10 | P g i n a
2.1.3. Crisis del Mantenimiento Hospitalario en el Mundo
El problema de las Oficinas de Ingenieras de Mantenimiento
Hospitalario de nuestro pas es de vital importancia como en todos los
pases del mundo, este problema se agudiza en todas las regiones o
ciudades.
Para mantener una poblacin sana, es indispensable tener programas

eficientes y perfectamente estructurados en el campo del saneamiento,
medicina preventiva y medicina predictiva, pero por excelentes que sean
estos programas, no se puede evitar que un porcentaje de la poblacin
pierda la salud y se hace imprescindible su atencin en el Hospital de la
localidad.
Las construcciones hospitalarias generalmente son del siglo XIX o XX y

tambin lo son su equipamiento, siendo por lo general un hospital
sumamente costoso. Sin embargo, no se pone mucho nfasis en su
MANTENIMIENTO, y lo que es ms grave an, es muy escaso el
personal especializado en este campo laboral.
El personal de Mantenimiento Hospitalario casi nunca asiste a cursos,

conferencias, seminarios y congresos relacionados con la Gestin de
Mantenimiento; hay poca o nula preocupacin para que se de la
oportunidad de asistir a estos eventos, porque siempre se encuentra
oposicin o falta de un presupuesto para el trabajador de Mantenimiento,
esto es realmente preocupante. En algunos pases desarrollados se
preocupan por capacitar al personal de Mantenimiento porque hay una
realidad, sin mantenimiento hospitalario no hay funcionamiento, las
Oficinas de Ingeniera de Mantenimiento Hospitalario son el guardin de
los costos que significan las instalaciones de un hospital, costo que da el
pueblo con los impuestos que pagan; por esta y dems razones es
incomprensible que la Administracin de un Hospital est sometiendo
en una crisis a la Oficina de Ingeniera de Mantenimiento.
11 | P g i n a
2.2. Bases Tericas
2.2.1. El Hospital
2.2.1.1. Definicin de Hospital
Un hospital es una compleja institucin con una plantilla mdica y de

enfermera organizada, y con instalaciones permanentes, que ofrece
gran variedad de servicios mdicos, incluyendo ciruga, para quienes
requieran un tratamiento u observacin ms intensivos. Tambin incluye
instalaciones para atender las urgencias, a los recin nacidos y
lactantes, as como diversas consultas ambulatorias y el llamado
"hospital de da", donde se realizan curas y atenciones sin
hospitalizacin permanente del paciente.
Un hospital es un lugar donde se atienden a los enfermos, para

proporcionar el diagnstico y tratamiento que necesitan. Existen
diferentes tipos de hospitales, segn el tipo de patologas que atienden:
hospitales generales, hospitales psiquitricos, geritricos, materno-
infantiles, etc.
2.2.1.2. Origen
La palabra hospital viene del latn hospes, "husped" o "visita". De
hospes se deriv hospitalia, "casa para visitas forneas". Posteriormente
hospitalia se transform en hospital para designar el lugar de auxilio a
los ancianos y enfermos.
Ciertos historiadores afirman que ya en el ao 4000 A.C. los templos de

los antiguos dioses fueron utilizados como casa de refugio para los
enfermos e invlidos, y como escuelas de aprendizaje para los mdicos.
Ms tarde, los templos de Esculapio (Asclepio), el dios griego de la
medicina, fueron utilizados con el mismo propsito. Los documentos
histricos tambin demuestran que ya en la India en el siglo III a.C. bajo
el dominio budista existan hospitales. Su nmero creci en los primeros
12 | P g i n a
siglos de la era cristiana. En el siglo IV d.C. se fundaron hospitales en
Cesrea y en Roma.
Durante el siglo XVIII, se crearon los primeros hospitales municipales

dirigidos por autoridades civiles, en especial en Inglaterra. En muchas
partes ciertos pequeos hospitales privados fueron regentados por
religiosos y por mdicos particulares, pero hasta muy tarde no se fund
el primer hospital pblico.
A partir de la mitad del siglo XIX, el nmero de hospitales creci mucho,

debido sobre todo al descubrimiento de la anestesia y de las tcnicas
quirrgicas aspticas. Durante el siglo XX la demanda de hospitales ha
aumentado a la par que el progreso.
Los primeros hospitales agrupaban a todos los pacientes en una nica

sala, con independencia de su enfermedad. Excepciones notables eran
los asilos mentales, los centros de cuarentena y los sanatorios para
tuberculosos que se establecieron a finales del siglo XIX. Aunque los
avances en los tratamientos han hecho que la mayora de estas
instituciones especiales sean innecesarias, han aparecido otras
dedicadas a tratar ciertos tipos de pacientes o enfermedades. Gracias a
las ventajas que aportan las tcnicas y los equipos especializados, hay
hospitales independientes para las mujeres y los nios y para el
tratamiento de enfermedades oculares y trastornos como el cncer. Este
tipo de hospitales suelen estar asociados a instituciones dedicadas a la
investigacin y la enseanza.
Durante el siglo XX el cuidado de pacientes crnicos e invlidos

incurables ha sido llevado a cabo en su mayor parte en hogares de
acogida. Los hospitales se centran en la atencin de pacientes con
enfermedades y lesiones agudas y en servicios ambulatorios. Un
hospital general moderno, incluso de tamao mediano, es una institucin
compleja. Adems de las funciones propiamente mdicas, el hospital
debe proporcionar tambin a sus pacientes y personal alojamiento,
alimento y otros servicios. Una zona importante del edificio del hospital
13 | P g i n a
se debe reservar a la sala de calderas, lavandera, cocina, cafeteras,
ropa y almacn. Los servicios mdicos requieren espacio para
laboratorios, rayos X y otros equipos de diagnstico, farmacia, sala de
urgencias, quirfanos, salas de partos, laboratorio de anatoma
patolgica, controles de enfermera, depsito de cadveres y salas para
diversos tipos de tratamientos como fisioterapia y terapia ocupacional. El
alojamiento de los pacientes consiste en salas, habitaciones
semiprivadas (dos a seis camas) y habitaciones privadas, salas de
aislamiento, salas de recin nacidos y salas especiales para prematuros,
salas para enfermos y salas de espera. La administracin del hospital
debe contar con oficinas y archivos. Muchos hospitales grandes incluyen
escuela de enfermera que requiere la asignacin de aulas y laboratorios
para los estudiantes.
2.2.1.3. Estructura
La estructura de un hospital est especialmente diseada para cumplir

las funciones de prevencin, diagnstico y tratamiento de
enfermedades.
Sin embargo muchos hospitales modernos poseen la modalidad y

estructura denominada Cuidados Progresivos. En este tipo de
hospitales, no hay salas divididas por especialidades mdicas como en
los hospitales clsicos, sino que el cuidado del enfermo se logra en
forma progresiva, segn su gravedad y complejidad. En este tipo de
hospitales suelen diferenciarse las siguientes reas: una rea de
Cuidados Crticos, otra de Cuidados Intermedios, y por ltimo Cuidados
Mnimos y Autocuidados. El paciente ingresa a una u otra rea segn su
gravedad. Un paciente gravemente enfermo y con riesgo de perder la
vida, ingresar seguramente a Cuidados Crticos, y luego al mejorar
(salir de su estado crtico), se trasladar a Cuidados Intermedios, luego a
Mnimos y as sucesivamente hasta dar el alta mdica.
14 | P g i n a
Si consideramos a un hospital en su conjunto como un sistema, ste
est compuesto por varios sub-sistemas que interactan entre s en
forma dinmica. Para nombrar los ms importantes:
a) Sistema Asistencial: Engloba a todas las reas del hospital que

tienen una funcin asistencial, es decir atencin directa del paciente
por parte de profesionales del equipo de salud. Hay dos reas
primordiales en la asistencia directa del paciente: los consultorios
externos para atender pacientes con problemas ambulatorios (que
no requieren internacin) y las reas de internacin, para cuidado de
problemas que s requieren hospitalizacin.
b) Sistema Administrativo Contable: Este sistema tiene que ver con

las tareas administrativas de un hospital. En l se encuentran reas
como admisin y egreso de pacientes, otorgamiento de turnos para
consultorios externos, departamento de recursos humanos, oficinas
de auditoria, farmacia, entre otras. En s toda oficina que trabaja con
el pblico en algn proceso o trmite con documentacin, es una
oficina administrativa. El rea contable del hospital se encarga
primariamente de la facturacin de las prestaciones dadas a las
entidades de cobertura correspondientes.
c) Sistema Gerencial: Est compuesto segn los hospitales por

gerencias o Direcciones. La ms destacada es la Gerencia Mdica,
que organiza o dirige el funcionamiento global del hospital, sus
polticas de prevencin, diagnstico y tratamiento, y el presupuesto,
entre otros temas.
d) Sistemas de Informacin: Se refiere al sistema informtico que

tiene el hospital y que soporta su funcionamiento en redes de
computadoras y programas diseados especialmente para el
correcto funcionamiento de todas las reas. Es manejada
generalmente por un Departamento o gerencia de Sistemas de
Informacin.
15 | P g i n a
e) Sistema Tcnico: Engloba a todas las dependencias que proveen
soporte, mantenimiento preventivo y Bioingeniera en una institucin.
f) Sistema de Docencia e Investigacin: La docencia en un hospital

es un punto clave en la formacin de profesionales. La docencia y la
investigacin estn ligadas en varios aspectos. Muchos hospitales
poseen sistemas de capacitacin y formacin de nuevos
profesionales como visitancias, concurrencias, residencias o
fellowships, con programas bien organizados para que el nuevo
profesional del equipo de salud obtenga la mejor formacin posible.
2.2.1.4. Clasificacin
En algunos pases, como en Espaa y Mxico, se diferencian grados de
cualificacin entre hospitales:
Hospital de primer nivel.

Hospital de segundo nivel.
Hospital de tercer nivel.
En otros pases se dividen a los hospitales segn su complejidad, en

baja y alta complejidad. Algunos pases pueden aplicar sistemas de
calificacin ms rigurosos y extensos, divididos en varios niveles de
complejidad.
2.2.2. El Mantenimiento
2.2.2.1. Definicin de Mantenimiento
Es un servicio que agrupa una serie de actividades cuya ejecucin

permite alcanzar un mayor grado de confiabilidad en los equipos,
mquinas, construcciones civiles e instalaciones.
El mantenimiento es un proceso mediante el cual se asegura que un

activo (equipo) contine desempeando las funciones deseadas.
Entre los objetivos fundamentales del Mantenimiento tenemos:
16 | P g i n a
Garantizar la disponibilidad y confiabilidad planeadas de la funcin
deseada.
Satisfacer todos los requisitos del sistema de calidad de la

institucin.
Cumplir todas las normas de seguridad y medio ambiente.
Maximizar el beneficio global.
Evitar riesgos laborales.
El mantenimiento de equipos mdicos prolonga la vida til de los

mismos.
Permite estar preparados para atender las situaciones de

emergencia.
Evitar resultados errneos por descalibracin de los equipos.
Proteger a los pacientes y al personal, especialmente por cuanto, los

mismos puedan generar situaciones de riesgos de accidente u otros
daos para la salud.
El mantenimiento adecuado, tiende a prolongar la vida til de los bienes,

a obtener un rendimiento aceptable de los mismos durante ms tiempo y
a reducir el nmero de fallas.
Decimos que algo falla cuando deja de brindarnos el servicio que deba
darnos o cuando aparecen efectos indeseables, segn las
especificaciones de diseo con las que fue construido o instalado el bien
en cuestin.
La utilizacin, el almacenamiento, el mantenimiento, la limpieza, la

desinfeccin cuando proceda, y la reparacin de los equipos de
17 | P g i n a
proteccin individual deber efectuarse de acuerdo con las instrucciones
de los fabricantes.
Hay que tener en cuenta que la propia actividad de mantenimiento con

sus correspondientes registros ha de permitir extraer y validar datos
propios sobre fiabilidad de los componentes de los equipos contrastando
lo aportado por los suministradores de los mismos. De esta manera, el
programa de mantenimiento se ir ajustando paulatinamente a partir de
la propia informacin que el mismo genera.
2.2.2.2. Tipos de Mantenimiento

a) Mantenimiento Correctivo
Definicin
Conjunto de procedimientos utilizados para reparar una mquina ya

deteriorada, en otras palabras es la ejecucin de acciones para reparar
elementos defectuosos por el mal funcionamiento o rendimiento o
imperativo de los equipos. Realizar seguimiento de intervenciones
ordinarias y urgentes realiza recepciones de aviso, llevar a cabo anlisis
modos de fallo y efectos para la deteccin precoz de averas
potenciales.
Historia
A finales del siglo XVIII y comienzo del siglo XIXI durante la revolucin
industrial, con las primeras mquinas se iniciaron los trabajos de
reparacin, el inicio de los conceptos de competitividad de costos,
planteo en las grandes empresas, las primeras preocupaciones hacia las
fallas o paro que se producan en la produccin. Hacia los aos 20 ya
aparecen las primeras estadsticas sobre tasas de falla en motores y
equipos de aviacin.
18 | P g i n a
Ventajas
Si el equipo esta preparado la intervencin en el fallo es rpida y la

reposicin en la mayora de los casos ser con el mnimo tiempo.
No se necesita una infraestructura excesiva, un grupo de operarios

competentes ser suficiente, por lo tanto el costo de mano de obra
ser mnimo, ser ms prioritaria la experiencia y la pericia de los
operarios, que la capacidad de anlisis o de estudio del tipo de
problema que se produzca.
Es rentable en equipos que no intervienen de manera instantnea en

la produccin, donde la implantacin de otro sistema resultara poco
econmico.
Desventajas
Se producen paradas y daos imprevisibles en la produccin que

afectan a la planificacin de manera incontrolada.
Se suele producir una baja calidad en las reparaciones debido a la

rapidez en la intervencin y a la prioridad de reponer antes que
reparar definitivamente, por lo que produce un hbito a trabajar
defectuosamente, sensacin de insatisfaccin e impotencia, ya que
este tipo de intervenciones a menudo generan otras al cabo del
tiempo por mala reparacin por lo tanto ser muy difcil romper con
esta inercia.
b) Mantenimiento Preventivo
Definicin
Inspeccin peridica de mquinas y equipos, para evaluar su estado de

funcionamiento e identificar fallas, es la ejecucin de acciones
programadas que tienden a prevenir disfunciones y averas, para
asegurar el rendimiento ptimo de los equipos y garantizar la seguridad
y proteger el medio ambiente.
19 | P g i n a
Su propsito es prever las fallas manteniendo los sistemas de
infraestructura, equipos e instalaciones productivas en completa
operacin a los niveles y eficiencia ptimos.
La caracterstica principal de este tipo de Mantenimiento es la de

inspeccionar los equipos y detectar las fallas en su fase inicial, y
corregirlas en el momento oportuno.
Con un buen Mantenimiento Preventivo, se obtiene experiencias en la

determinacin de causas de las fallas repetitivas o del tiempo de
operacin seguro de un equipo, as como a definir puntos dbiles de
instalaciones, mquinas, etc.
Historia
Durante la segunda guerra mundial, el mantenimiento tiene un desarrollo

importante debido a las aplicaciones militares, en esta evolucin el
mantenimiento preventivo consiste en la inspeccin de los aviones antes
de cada vuelo y en el cambio de algunos componentes en funcin del
nmero de horas de funcionamiento.
Caractersticas
Bsicamente consiste en programar revisiones de los equipos,

apoyndose en el conocimiento de la mquina en base a la experiencia
y los histricos obtenidos de las mismas. Se confecciona un plan de
mantenimiento para cada mquina, donde se realizaran las acciones
necesarias, engrasan, cambian correas, desmontaje, limpieza, etc.
Ventajas
Confiabilidad, los equipos operan en mejores condiciones de

seguridad, ya que se conoce su estado, y sus condiciones de
funcionamiento.
20 | P g i n a
Disminucin del tiempo muerto, tiempo de parada de equipos. Mayor
duracin, de los equipos e instalaciones.
Disminucin de existencias en Almacn y, por lo tanto sus costos,

puesto que se ajustan los repuestos de mayor y menor consumo.
Uniformidad en la carga de trabajo para el personal de

Mantenimiento debido a una programacin de actividades.
Menor costo de las reparaciones.
Desventajas
Representa una inversin inicial en infraestructura y mano de obra.

El desarrollo de planes de mantenimiento se debe realizar por
tcnicos especializados.
Si no se hace un correcto anlisis del nivel de mantenimiento

preventivo, se puede sobrecargar el costo de mantenimiento sin
mejoras sustanciales en la disponibilidad.
Los trabajos rutinarios cuando se prolongan en el tiempo, producen

falta de motivacin en el personal, por lo que se debern crear
sistemas imaginativos para convertir un trabajo repetitivo en un
trabajo que genere satisfaccin y compromiso, la implicacin de los
operarios de preventivo es indispensable para el xito del plan.
Fases
Inventario tcnico, con manuales, planos, caractersticas de cada

equipo.
Procedimientos tcnicos, listados de trabajos a efectuar

peridicamente.
Control de frecuencias, indicacin exacta de la fecha a efectuar el

trabajo.
21 | P g i n a
Registro de reparaciones, repuestos y costos que ayuden a
planificar.
c) Mantenimiento Predictivo
Definicin
Mantenimiento basado fundamentalmente en detectar la posibilidad de

falla antes de que suceda, para dar tiempo a corregirla sin perjuicios al
servicio, ni detencin de la produccin, etc. Estos controles pueden
llevarse a cabo de forma peridica o continua, en funcin de tipos de
equipo, sistema productivo, etc.
Para ello, se usan para ello instrumentos de diagnstico, aparatos y

pruebas no destructivas, como anlisis de lubricantes, comprobaciones
de temperatura de equipos elctricos, etc.
Historia
Durante los aos 60 se inician tcnicas de verificacin mecnica a travs

del anlisis de vibraciones y ruidos si los primeros equipos analizadores
de espectro de vibraciones mediante la FFT (Transformada rpida de
Fouries), fueron creados por Bruel Kjaer.
Ventajas
Reduce los tiempos de parada.
Permite seguir la evolucin de un defecto en el tiempo.
Optimiza la gestin del personal de mantenimiento.
La verificacin del estado de la maquinaria, tanto realizada de forma

peridica como de forma accidental, permite confeccionar un archivo
histrico del comportamiento mecnico.
22 | P g i n a
Conocer con exactitud el tiempo lmite de actuacin que no implique
el desarrollo de un fallo imprevisto.
Toma de decisiones sobre la parada de una lnea de mquinas en

momentos crticos.
Confeccin de formas internas de funcionamiento o compra de

nuevos equipos.
Permitir el conocimiento del historial de actuaciones, para ser

utilizada por el mantenimiento correctivo.
Facilita el anlisis de las averas.
Permite el anlisis estadstico del sistema.
Desventajas
La implantacin de un sistema de este tipo requiere una inversin

inicial importante, los equipos y los analizadores de vibraciones
tienen un costo elevado. De la misma manera se debe destinar un
personal a realizar la lectura peridica de datos.
Se debe tener un personal que sea capaz de interpretar los datos

que generan los equipos y tomar conclusiones en base a ellos,
trabajo que requiere un conocimiento tcnico elevado de la
aplicacin.
Por todo ello la implantacin de este sistema se justifica en mquina

o instalaciones donde los paros intempestivos ocasionan grandes
prdidas, donde las paradas innecesarias ocasionen grandes costos.
2.2.2.3. Etapas del Mantenimiento
Para elaborar y aplicar correctamente los procedimientos y actividades

de mantenimiento, se deben tener en cuenta las siguientes etapas.
23 | P g i n a
a) Anlisis y Planificacin
Se debern definir los lmites, frecuencia, cobertura y la ruta de la

revisin.
Elegir a las personas que van a llevar a cabo la revisin. Estas

debern poseer un nivel suficiente de formacin para entender el
funcionamiento de lo que deba analizarse y saber aplicar la tcnica
de revisin adecuada.
Disponer antes de la visita de la mayor cantidad posible de

informacin respecto a las caractersticas tcnicas de los equipos,
as como un conocimiento previo de los posibles riesgos a travs de
un anlisis documental o estadstico.
Deben determinarse los elementos o partes crticas de los equipos

que se van a revisar. Para ello es conveniente clasificar e identificar
cada elemento mediante cdigos y ubicarlos en un plano fsico. Con
ello se puede elaborar un inventario codificado de los componentes
que ofrecen mayores probabilidades de ocasionar algn problema
cuando se gastan, daan o se utilizan de forma incorrecta. Adems
se deben revisar los aspectos especficos que causaron problemas
en revisiones previas, las medidas correctoras que se adoptaron as
como los riesgos comunicados mediante el procedimiento de
comunicacin de riesgos.
Determinar los recursos necesarios, materiales, vestuario, equipos,

documentos e instrumentos de medicin necesarios.
En la elaboracin o revisin del procedimiento deberan participar

tcnicos, mandos intermedios y operarios cualificados de los equipos
en cuestin, con el asesoramiento del Servicio de Prevencin
siempre que se precise. En la elaboracin y posteriores revisiones
del procedimiento sern consultados los representantes de los
trabajadores.
24 | P g i n a
Es importante que se elaboren por mquinas o por familias de mquinas
de iguales caractersticas.
b) Ejecucin
Esta es la fase en la que se practican efectivamente las revisiones

registrando los datos en las hojas de registro correspondientes para su
posterior estudio. Durante la ejecucin de las revisiones es muy
conveniente estar acompaados del responsable o responsables de las
respectivas reas y de los operarios de los equipos. Las revisiones
deben ser exhaustivas, no obviando lugares recnditos, de difcil acceso,
ni mquinas o equipos similares. No basta con detectar aspectos
deficientes e inseguros y determinar las causas, sino que tambin se
deberan proponer medidas correctoras y aplicarlas. En este sentido el
dilogo con el propio personal afectado puede aportar informacin de
gran inters y ayuda.
c) Control
La aplicacin de las medidas correctivas requiere siempre un

seguimiento y control de su aplicacin y eficacia.
d) Registros Documentales
Los procedimientos y formularios de registros de las revisiones deben

ser codificados para su posterior identificacin. Los documentos estarn
recogidos en un archivo centralizado que debe estar disponible en
aquellos lugares de la empresa donde sea necesaria su utilizacin es
decir, prximo al mbito de trabajo.
2.2.2.4. Actividades en el Mantenimiento

a) Calibracin
La calibracin consiste en realizar los correctivos de funcionamiento y

poner a los equipos en las condiciones iniciales de operacin, mediante
el anlisis de sus partes o componentes, actividad que se hace a travs
de equipos, instrumentos, patrones o estndares.
25 | P g i n a
Figura 1. Proceso de calibracin a un equipo electromecnico. Fuente: Imagen Propia
b) Inspeccin
Consiste en hacer un examen minucioso en forma visual y mediante

elementos de medicin de cada una de las partes y componentes del
equipo, con el fin de comprobar que el estado de funcionamiento es el
ptimo dadas y que est de acuerdo con las caractersticas y
condiciones de construccin y operacin dadas por los fabricantes de los
equipos. La inspeccin puede clasificarse en tres tipos:
Evaluacin
Cada uno de los equipos debe ser evaluado en su estado fsico y

funcional por el servicio de mantenimiento, antes de ser sometido a
cualquier accin de mantenimiento.
Apariencia
Los equipos con rasguos menores, hendiduras, decoloracin, o

cualquier otro defecto que no afecte el funcionamiento, no puede ser
considerado como inservible. Sin embargo tales defectos debern
ser programados para la debida correccin, dependiendo de la
disponibilidad del mismo.
Integridad
Se considera un equipo completo cuando posee todos los elementos

elctricos, mecnicos y dems accesorios originales ensamblados
26 | P g i n a
en fbrica y que son indispensables para el perfecto funcionamiento
del mismo.
La placa de identificacin del equipo es un componente especial de

este y deber permanecer adherida al mismo. Todo equipo contiene
accesorios que son indispensables para su funcionamiento, los
cuales deben relacionarse como parte del equipo.
c) Prueba de Aceptacin
Las pruebas de aceptacin consisten en efectuar inspecciones visuales

y de funcionamiento, siguiendo normas y procedimientos emitidos por
Institutos, Organismos o asociaciones dedicados a la reglamentacin de
la construccin y calidad de los equipos mdicos con el fin de verificar la
eficiencia y seguridad de estos. Los estndares de calidad y
funcionamiento son dados por los mismos fabricantes o por
organizaciones dedicadas a dar los lineamientos sobre la calidad uso y
seguridad de los equipos mdicos, en especial sobre la seguridad
elctrica el paciente y al mismo equipo.
d) Limpieza
Consiste en la remocin de elementos extraos o nocivos a la

estructura de los equipos.
Figura 2. Realizacin del proceso de limpieza. Fuente: Imgenes de google
27 | P g i n a
e) Lubricacin
Es la accin por medio de la cual se aplica un elemento viscoso entre

cuerpos rgidos y mviles, con el fin de reducir la friccin y el desgaste
de las partes.
Figura 3. Realizacin del proceso de lubricacin a una parte mecnica. Fuente: Imagen Propia
f) Pruebas de Funcionamiento
Son pruebas que se efectan a cada equipo, para determinar si el

funcionamiento de este, est de acuerdo con las caractersticas de
rendimiento y seguridad establecidas en el diseo y fabricacin de estos.
Los equipos que no renen estas exigencias se consideran no aptos
para la prestacin del servicio. Las pruebas deben realizarlas el personal
tcnico capacitado en cada uno de los diferentes equipos.
2.2.2.5. Clasificacin de las Fallas del Equipamiento

a) Fallas Tempranas
Ocurren al principio de la vida til y constituyen un porcentaje pequeo

del total de fallas. Pueden ser causadas por problemas de materiales, de
diseo o de montaje.
28 | P g i n a
b) Fallas Adultas
Son las fallas que presentan mayor frecuencia durante la vida til. Son
derivadas de las condiciones de operacin y se presentan ms
lentamente que las anteriores (suciedad en un filtro de aire, cambios de
rodamientos de una mquina, etc.).
c) Fallas Tardas
Representan una pequea fraccin de las fallas totales, aparecen en

forma lenta y ocurren en la etapa final de la vida del bien (envejecimiento
de la aislacin de un pequeo motor elctrico, perdida de flujo luminoso
de una lmpara, etc.
TEMPRANAS
FALLAS ADULTAS
TARDIAS
Figura 4. Tipos de fallas en el equipamiento. Fuente: Elaboracin Propia
2.2.2.6. Gestin del Mantenimiento
La Gestin del Mantenimiento es una disciplina integradora que

garantiza la disponibilidad, funcionalidad y conservacin de los equipos,
siempre que se aplique correctamente, a un costo competitivo. Esto
significa un incremento importante de la vida til de los equipos y sus
prestaciones con el fin de garantizar la calidad de los productos y
utilizarse como una estrategia para una competencia exitosa. Para
producir con un alto nivel de calidad, el equipo de produccin debe
operar dentro de las especificaciones, las cuales pueden alcanzarse
mediante acciones oportunas de mantenimiento.
29 | P g i n a
El mantenimiento puede ser considerado como un sistema con un
conjunto de actividades que se realizan en paralelo con los sistemas de
produccin. Los mismos generalmente se ocupan en convertir entradas
o insumos, como materias primas, mano de obra y procesos, en
productos que satisfacen las necesidades de los clientes. La principal
salida de los sistemas de produccin son los productos terminados; una
salida secundaria son las fallas en equipos. Esta salida secundaria
genera una demanda de mantenimiento. El sistema de mantenimiento
toma esto como entrada y le entrega conocimiento experto, mano de
obra y refacciones, y produce un equipo en buenas condiciones que
ofrece una capacidad de produccin.
Un sistema de mantenimiento puede verse como un modelo sencillo de

entrada - salida. Las entradas de dicho modelo son mano de obra,
administracin, herramientas, refacciones, equipo, etc., y la salida es el
equipo en funcionamiento, confiable y bien configurado para lograr la
operacin planeada de la planta. Esto permite organizar los recursos
para aumentar el mximo de salidas del sistema.
Figura 5. Sistema Tpico de Mantenimiento. Fuente: Sistemas de Mantenimiento Planeacin y

Control, Duffuaa S. (2002)
30 | P g i n a
Por lo tanto, para que la gestin del mantenimiento sea la efectiva y
eficiente utilizacin de los recursos materiales, econmicos, humanos y
de tiempo para alcanzar los objetivos de mantenimiento, se deben
interrelacionar los siguientes tres componentes:
a) Recursos
Comprende personal, repuestos y herramientas, con un tamao,

composicin, localizacin y movimiento determinados.
b) Administracin
Una estructura jerrquica con autoridad y responsabilidad que

decida que trabajo se har y cuando y como debe llevarse a cabo.
c) Planificacin del Trabajo y Sistema de Control
Un mecanismo para planificar y programar el trabajo y garantizar la

recuperacin de la informacin necesaria para que el esfuerzo de
mantenimiento se dirija correctamente hacia el objetivo definido.
El personal como recurso de mantenimiento, puede clasificarse segn el

rea tcnica en la que se emplee: mecnica, elctrica, de instrumentos,
de construccin. La calidad del personal disponible depende
principalmente del entorno en el que opera la compaa. La gestin de
repuestos es alcanzar el equilibrio ptimo entre el costo de posesin
(depreciacin, intereses, rentas, etc.) y el costo de la ruptura de stock
(falta de disponibilidad). La principal dificultad de esta accin, tan
simplemente expresada, surge de la variedad y complejidad de los miles
de artculos distintos (de costos y tasa de utilizacin tan diversos)
necesarios para llevar a cabo una operacin determinada. En cierto
sentido, cada repuesto presenta un problema individual de control. Para
facilitar ese control as como la catalogacin, identificacin y
almacenamiento, se pueden clasificar los repuestos segn su tasa de
uso y otras caractersticas asociadas. Por ltimo, el objetivo de la
31 | P g i n a
organizacin de herramientas es similar al de la organizacin de los
repuestos, pero el problema de control es aqu diferente, porque las
herramientas no son consumibles en el mismo sentido. El problema
principal con las herramientas retornables es el desarrollo de un sistema
para controlar su prstamo y para efectuar el necesario mantenimiento
(incluyendo su sustitucin si es necesario) cuando son devueltas.
La administracin puede ser considerada como un sistema de toma de

decisiones, cuyo objetivo es dirigir los recursos disponibles hacia la
realizacin del objetivo de la organizacin. Los niveles superiores se
centran ms en la decisin que en la ejecucin, mientras que los niveles
inferiores de taller, pueden tener poderes mnimos de decisin. Lo ms
alto de la estructura jerrquica se dedica a determinar el objetivo y la
poltica de la compaa y se centra principalmente en los asuntos no
recurrentes de inversin de capital, muchos de los cuales, son en el caso
mejor no cuantificables y en el peor, estn fuera del control de la
organizacin.
Segn esto, los trabajos de mantenimiento programado ascienden por el

sistema hasta el punto designado para la toma de decisiones y despus
retroceden al nivel de taller para su ejecucin. Por otro lado, los trabajos
no programados y de proyecto arrancan en algn lugar de la parte de
arriba del sistema y se desplazan hacia abajo. En cada caso, y debido a
la naturaleza interdisciplinaria del trabajo, se necesita una comunicacin
a travs de las lneas de autoridad para transmitir las mltiples
informaciones (tcnicas especializadas de planificacin) necesarias para
la eficaz planificacin, asignacin y ejecucin de trabajos. Cuando los
costos de mantenimiento son una parte importante del costo de
produccin, la funcin de mantenimiento debe estar directamente
representada en los altos niveles de la administracin. Esto asegura que
el mantenimiento sea adecuadamente contemplado junto con la
produccin al tomar decisiones operativas y, aun de ms importancia, al
considerar la adquisicin de un sistema nuevo o que reemplace al
existente.
32 | P g i n a
La funcin principal del servicio de planificacin de trabajos es la
planificacin y programacin, a medio y largo plazo, de la carga de
trabajo de mantenimiento para los encargados de las reas. Por tanto, el
horizonte de planificacin puede extenderse desde tan solo 48 horas
hasta un ao, y abarcar todos los trabajos, aparte de los aplazados de
alta prioridad y del mantenimiento de emergencia.
El servicio es responsable de suministrar a los encargados de

mantenimiento la carga de trabajo a mediano plazo a realizar en el
prximo periodo de produccin, por ejemplo, de una semana, y que debe
distribuirse cierto tiempo antes de la fecha de comienzo del periodo. En
esta responsabilidad se incluyen la coordinacin inicial del trabajo
multidisciplinario, el suministro de informacin de mantenimiento, como
planos o manuales, la comprobacin de la disponibilidad de los
repuestos ms importantes y la comprobacin de la disponibilidad de los
sistemas crticos.
Considerando que el planeamiento y la programacin del mantenimiento

es parte fundamental para la implementacin de un buen sistema de
gestin de mantenimiento se estudiar el mantenimiento preventivo con
ms detalle.
2.2.2.7. Situacin Actual del Mantenimiento
En el Ministerio de Salud existe el Programa Nacional de Infraestructura,

Equipamiento y Mantenimiento (PRONIEM), que es el organismo rector
de los procesos de mantenimiento tanto de infraestructura como de
equipamiento.
A nivel Latinoamericano se tiene el Comit Andino de Autoridades en

Seguridad y Salud en el Trabajo (CAASST) de la Comunidad Andina,
como ente encargado de asesorar al Consejo Andino de Ministros de
Relaciones Exteriores, a la Comisin, al Consejo Asesor de Ministros de
33 | P g i n a
Trabajo y a la Secretara General de la Comunidad Andina, en los temas
vinculados a la seguridad y salud en el espacio comunitario.
Aprueban las normas fundamentales en materia de seguridad y salud en

el trabajo, que sirva de base para las leyes y los reglamentos que
regulen las situaciones particulares de las actividades laborales que se
desarrollan en cada uno de los pases miembros, entre sus normas se
establece lo siguiente:
a) Que los pases miembros velen porque las mquinas, equipos,

sustancias, productos o tiles de trabajo no constituyan una fuente
de peligro ni pongan en riesgo la seguridad y salud de los
trabajadores.
b) Cumplan con proporcionar informacin y capacitacin sobre la

instalacin, as como sobre la adecuada utilizacin y mantenimiento
preventivo de la maquinaria y los equipos; el apropiado uso de
sustancias, materiales, agentes y productos fsicos, qumicos o
biolgicos, a fin de prevenir los peligros inherentes a los mismos, y
la informacin necesaria para monitorizar los riesgos.
c) Traduzcan al idioma oficial y en un lenguaje sencillo y preciso, las

instrucciones, manuales, avisos de peligro u otras medidas de
precaucin colocadas en los equipos y maquinarias, as como
cualquier otra informacin vinculada a sus productos que permita
reducir los riesgos laborales.
d) Velen porque las informaciones relativas a las mquinas, equipos,

productos, sustancias o tiles de trabajo sean facilitadas a los
trabajadores en trminos que resulten comprensibles para los
mismos.
34 | P g i n a
2.3. Diagnstico de la Situacin Actual de los
Establecimientos del Sector Salud en el Per
El Ministerio de Salud, en el marco de los Lineamientos de Poltica de Salud,
promueve la organizacin de la oferta de los servicios en torno al Modelo de
Atencin Integral de Salud de la persona, familia y comunidad, facilitando el
acceso oportuno y adecuado principalmente de las poblaciones ms
vulnerables.
A pesar de los esfuerzos realizados, aun persiste una inadecuada organizacin

en la oferta de servicios, la cual se expresa con un crecimiento desordenado de
la oferta en cada realidad local sanitaria del pas, coexistencia de diferentes
denominaciones de establecimientos de salud de similar complejidad, creando
una confusin en la articulacin de servicios e ineficacia del sistema de
referencia y contrarreferencia, desorden administrativo prestacional de los
servicios de salud en el pas, originando ineficiencia del sistema.
Siendo una necesidad perentoria en todos los niveles de gestin iniciar el

proceso de ordenamiento de la oferta, se debe contar con la normatividad
correspondiente que permita identificar los tipos o categoras de
establecimientos de salud con la finalidad de garantizar la continuidad de la
atencin en los respectivos mbitos de intervencin, mejorando la organizacin
de la atencin segn los niveles de complejidad.
2.3.1. Organizacin de la Oferta de Servicios de Salud

La organizacin de la oferta de servicios de salud es un proceso que se
configura a partir del anlisis de las necesidades de salud de la persona,
familia y comunidad, para facilitar la gestin, la prestacin y la calidad de
los servicios de salud.
El inicio de este proceso implica analizar las caractersticas de la

poblacin en general, identificar las necesidades de salud de las
personas y familias (percibidos o no), reconocer a los que demandan (de
forma espontnea o inducida) y a los que obtienen o no atencin en la
oferta de servicios de salud.
35 | P g i n a
2.3.2. Demanda
Es la expresin de las necesidades de salud en una poblacin, de
acuerdo al Modelo de Atencin Integral de Salud.
Respecto a la forma de cmo se expresa en un determinado mbito, la

demanda puede ser espontnea, cuando surge a raz de necesidades
percibidas, o inducida, cuando resulta de necesidades no
necesariamente percibidas por la poblacin.
Ambos tipos de demanda presentan dos elementos, que para efectos del
anlisis se presentan divididas, pero que en realidad se dan
simultneamente: (Ver figura 6).
a) La Demanda Cuantitativa: Est referida al volumen de la misma, es

decir, al nmero de personas que en un determinado tiempo y
espacio tienen necesidades de salud, requiriendo la prestacin de
servicios sanitarios.
b) La Demanda Cualitativa: Est referida a las necesidades de salud

que motivaron la demanda por servicios de salud (diagnsticos) y la
severidad de esas necesidades (mnima/alta).
La severidad, es una caracterstica cualitativa de las necesidades de

salud a partir de la cual se debe determinar el grado de complejidad
(capacidad resolutiva cualitativa y nivel tecnolgico de los recursos
humanos, fsicos y tecnolgicos) de la oferta de servicios, necesarios
para brindar siempre la respuesta adecuada que ella requiere.
2.3.3. Oferta de Servicios de Salud

La oferta de servicios de salud est constituida por los recursos
humanos, de infraestructura, equipamiento, tecnolgicos y financieros
que organizados adecuadamente, deben solucionar las necesidades de
salud de la poblacin.
36 | P g i n a
Los criterios para la existencia, crecimiento y/o desarrollo de la oferta
deben surgir de las necesidades de salud y deben satisfacerla cualitativa
y cuantitativamente. Para ello se consideran los siguientes elementos:
a) Capacidad Resolutiva
Es la capacidad que tiene la oferta de servicios, para satisfacer las

necesidades de salud de la poblacin en trminos:
Cuantitativa: Es la capacidad que tienen los recursos de un

establecimiento para producir la cantidad de servicios suficientes
para satisfacer el volumen de necesidades existentes en la
poblacin (Depende de la cantidad de sus recursos disponibles).
Cualitativa: Es la capacidad que tienen los recursos del

establecimiento para producir el tipo de servicios necesarios
para solucionar la severidad de las necesidades de la poblacin
(Depende de la especializacin y tecnificacin de sus recursos).
b) Estructura
Constituida por los recursos humanos, fsicos y tecnolgicos que

determinan la capacidad resolutiva de la oferta de servicios y que se
organizan en las llamadas Unidades Productoras de Servicios de
Salud, en trminos de:
Tamao: Referido a la cantidad de los recursos necesarios para

producir servicios de salud en funcin del volumen de las
necesidades de salud de la poblacin (Determina la capacidad
resolutiva cuantitativa).
Nivel Tecnolgico: Referido al grado de especializacin y

tecnificacin de los recursos necesarios para producir servicios
de salud en funcin de la severidad de las necesidades de salud
de la poblacin (Determina la capacidad resolutiva cualitativa).
37 | P g i n a
2.3.4. Complejidad de los Establecimientos de Salud
La complejidad est determinada solo por los aspectos cualitativos de la
oferta de servicios de salud, es decir la Capacidad Resolutiva Cualitativa
y el Nivel Tecnolgico de los recursos (Ver Figura 6).
Figura 6. Caractersticas de la Demanda y su Relacin con las Caractersticas de la Oferta. Fuente:

Ministerio de Salud
2.3.5. Nivel de Complejidad

Es el grado de diferenciacin y desarrollo de los servicios de salud,
alcanzando merced a la especializacin y tecnificacin de sus recursos.
El nivel de complejidad guarda una relacin directa con las categoras de

establecimientos de salud (Ver Tabla 2).
38 | P g i n a
2.3.6. Nivel de Atencin
Conjunto de Establecimientos de Salud con niveles de complejidad
necesaria para resolver con eficacia y eficiencia necesidades de salud
de diferente magnitud y severidad.
Constituye una de las formas de organizacin de los servicios de salud,

en la cual se relacionan la magnitud y severidad de las necesidades de
salud de la poblacin con la capacidad resolutiva cualitativa y
cuantitativa de la oferta.
Este tipo de organizacin se sustenta en la comprobacin emprica de

que los problemas de salud de menor severidad tienen mayor frecuencia
relativa que los ms severos, y viceversa. Es as que de acuerdo al
comportamiento de la demanda, se reconocen tres niveles de
atencin:
a) Primer Nivel:
Donde se atiende el 70-80% de la demanda del sistema. Aqu la

severidad de los problemas de salud plantea una atencin de baja
complejidad con una oferta de gran tamao y con menor
especializacin y tecnificacin de sus recursos. En este nivel, se
desarrollan principalmente actividades de promocin y proteccin
especfica, diagnostico precoz y tratamiento oportuno de las
necesidades de salud ms frecuentes.
b) Segundo Nivel:
Donde se atiende del 12 al 22% de la demanda, portadora de

necesidades de salud que requieren atencin de complejidad
intermedia.
c) Tercer Nivel:
39 | P g i n a
Donde se atiende del 5 al 10% de la demanda, la cual requiere de
una atencin de salud de alta complejidad con una oferta de menor
tamao, pero de alta especializacin y tecnificacin.
CATEGORIAS DE
NIVELES DE
NIVELES DE COMPLEJIDAD ESTABLECIMIENTOS DE
ATENCION
SALUD
1 Nivel de Complejidad I-1
Primer Nivel de 2 Nivel de Complejidad I-2
Atencin 3 Nivel de Complejidad I-3
4 Nivel de Complejidad I-4
Segundo Nivel 5 Nivel de Complejidad II - 1
de
Atencin 6 Nivel de Complejidad II - 2
Tercer Nivel de 7 Nivel de Complejidad III - 1

Atencin 8 Nivel de Complejidad III - 2
Tabla 2. Niveles de atencin, Niveles de complejidad y Categoras de Establecimientos del Sector Salud.
Fuente: Ministerio de Salud Elaboracin Propia
2.3.7. Categorizacin
Es el proceso que conduce a homogenizar los diferentes
establecimientos de salud, en base a niveles de complejidad y a
caractersticas funcionales, que deben responder a las necesidades de
salud de la poblacin que atiende.
En este proceso no se deben considerar los elementos que indiquen

tamao, ya que estos dependen del volumen de las necesidades de
salud de la poblacin, lo que es variable segn la realidad sanitaria local.
Es importante distinguir este proceso de otros, como el de Acreditacin,

ya que en la Categorizacin se hace una valoracin de la capacidad
resolutiva cualitativa de los establecimientos frente a las necesidades de
salud y no una evaluacin de la estructura, procesos, ni de los
resultados obtenidos y menos aun de la calidad de los mismos
(Acreditacin).
40 | P g i n a
2.3.8. Categoras
Las Categoras consideradas para los Establecimientos del Sector Salud
son:
Categora I - 1
Es el tipo de Categora del primer nivel de atencin, responsable de

satisfacer las necesidades de salud de la poblacin de su mbito
jurisdiccional, a travs de una atencin integral ambulatoria con
nfasis en la promocin de la salud, prevencin de los riesgos y
daos y fomentando la participacin ciudadana.
Categora I - 2
Es el tipo de Categora del primer nivel de atencin, responsable de

satisfacer las necesidades de salud de la poblacin de su mbito
jurisdiccional, a travs de una atencin medica integral
ambulatoria con nfasis en la promocin de la salud, prevencin de
los riesgos y daos y fomentando la participacin ciudadana.
Categora I - 3
Es el tipo de Categora que pertenece al primer nivel de atencin,

responsable de satisfacer las necesidades de salud de la poblacin
de su mbito jurisdiccional, brindando atencin medica integral
ambulatoria con acciones de promocin de la salud, prevencin de
riesgos y daos, y recuperacin de problemas de salud ms
frecuentes a travs de unidades productoras de servicios bsicos de
salud de complejidad inmediata superior a la categora I-2.
Categora I - 4
Es el establecimiento de salud del primer nivel de atencin,

de su mbito jurisdiccional, brindando atencin medica integral
ambulatoria y con Internamiento de corta estancia
41 | P g i n a
principalmente enfocada al rea Materno-Perinatal e Infantil, con
acciones de promocin de la salud, prevencin de riesgos y daos, y
recuperacin de problemas de salud ms frecuentes a travs de
unidades productoras de servicios bsicos y especializados de salud
de complejidad inmediata superior a la categora I-3.
Categora II - 1
Establecimiento de Salud del segundo nivel de atencin,
de su mbito jurisdiccional, a travs de una atencin integral
ambulatoria y hospitalaria en cuatro especialidades bsicas que
puede ser medicina interna, ginecologa, ciruga general, pediatra,
anestesiologa, con acciones de promocin de la salud, prevencin
de riesgos y daos, recuperacin y rehabilitacin de problemas de
salud
Categora II - 2
Establecimiento de Salud del segundo nivel de atencin,

de su mbito referencial, brindando atencin integral ambulatoria
y hospitalaria especializada, con nfasis en la recuperacin y
rehabilitacin de problemas de salud.
Categora III - 1
Establecimiento de Salud que pertenece al tercer nivel de atencin,

de su mbito referencial, brindando atencin integral ambulatoria
y hospitalaria altamente especializada, con nfasis en la
recuperacin y rehabilitacin de problemas de salud a travs de
unidades productoras de servicios de salud medico quirrgicos de
alta complejidad.
42 | P g i n a
Categora III - 2
Establecimiento de Salud del tercer nivel de atencin de mbito
nacional que propone normas, estrategias e innovacin
cientfico tecnolgico en un rea de la salud o etapa de vida a
travs de la investigacin, docencia y prestacin de servicios
de salud altamente especializados que contribuye a resolver los
problemas prioritarios de salud.
El Ministerio de Salud adems administra otros tipos de establecimientos

tales como comedores, albergues entre otros, los cuales no requieren
una tipificacin especial toda vez que realizan actividades especficas
dirigidas a segmentos de la poblacin.
En la Tabla 3, se muestra las categoras en relacin al tipo de

Establecimientos de Salud correspondientes al Ministerio de Salud.
La presente norma es el instrumento del Sector Salud a la que las

instituciones; como el Ministerio de Salud, ESSALUD, Fuerzas Armadas,
Policiales y el subsector privado debern adecuarse.
CATEGORIAS DEL SECTOR SALUD MINISTERIO DE SALUD
I-1 Puesto de Salud
I-2 Puesto de Salud con Medico
I-3 Centro de Salud sin Internamiento
I-4 Centro de Salud con Internamiento
II - 1 Hospital I
II - 2 Hospital II
III - 1 Hospital III
III - 2 Instituto Especializado
Tabla 3. Categoras de los Establecimientos de Salud de acuerdo a las Instituciones del Sector Salud.
Fuente: Ministerio de Salud Elaboracin Propia
43 | P g i n a
Las otras instituciones se adaptaran a las Categoras propuestas y a su
nivel de Resolucin.
Niveles
de PERU PANAMA BOLIVIA MEXICO CHILE
Atencin
Puestos de Puestos de Puestos de Promocin y Postas rurales

Salud Salud Salud atencin (enfermeras)
ambulatoria
Centros de Centros de Centros de Consultorios

I Salud Salud Salud Generales
urbanos y
rurales
C.S. Con Centros

Internamiento Materno Infantiles
Hospital I Hospital del rea Hospitales Hospitales Hospitales

de salud Distritales Generales con Bsicos
especialidades
II bsicas
Hospital II
Hospital III Hospitales Hospitales Hospitales de Hospitales

Regionales Regionales o Alta Generales
Departamentales Complejidad
III Institutos Hospitales Hospitales Institutos

Especializado Nacionales Nacionales
Hospitales Institutos
Especializados
Tabla 4. Cuadro Comparativo de los Tipos de Categoras de los Establecimientos de Salud en

Latinoamrica. Fuente: OPS/OMS Sistema Regional de datos bsicos de salud, Perfiles de Pases
Elaboracin Propia
44 | P g i n a
CATEGORAS MINSA ESSALUD PNP FAP NAVAL PRIVADO
Enfermera
Puesto de Puesto
I-1 Salud Sanitario
Servicios de Consultorio
Sanidad
Puesto de Departamento
Posta Posta Consultorios
I-2 Salud con
Medica Medica
Posta Medica de Sanidad
Mdicos
Medico Posta Naval
Centro de
Centro Policlnico Departamento
I-3 Salud sin
Medico B Sanitario
Policlnicos
Internamiento
Centro de
Policlnico Centros
I-4 Salud con Policlnico
Naval Mdicos
Internamiento
Policlnico
II - 1 Hospital I Hospital I
A
Hospital Zonal Clnica Naval Clnicas
Hospital Hospital
II - 2 Hospital II Hospital II
Regional Regional
Clnicas
Hospital Naval
Hospital III y Hospital Hospital
III - 1 Hospital III
IV Nacional Central FAP
- Buque Clnicas
Hospital
Instituto
III - 2 Especializado
Instituto Institutos
Tabla 5. Cuadro Comparativo Nacional. Fuente: Ministerio de Salud Elaboracin Propia
2.4. Diagnstico de la Situacin Actual del Hospital

Central de la Fuerza Area del Per
2.4.1. Resea Histrica del Hospital Central FAP
En el ao 1960, se crea el Instituto de Salud de Aeronutica (ISA), que
funcionaba en las actuales instalaciones del Hospital Central FAP desde
1950 a 1959 se nombraron varias Comisiones para estudiar la
factibilidad de construccin de un Hospital FAP y adquisicin de un
terreno en el Distrito de Surquillo.
Con Decreto Supremo N 019 de Enero de 1962, se licitan las obras de

construccin del Hospital Central FAP.
45 | P g i n a
El 16 de Julio de 1965 se coloca la primera piedra del futuro Hospital
FAP en los terrenos del ISA, oficializada mediante R.M. N 1056 del 03-
09-65 y el 30 de Abril de 1970, en acto pblico se inaugura el Hospital
Central FAP, fecha considerada, inicialmente, como su Aniversario, y
que cont con la presencia del Seor Presidente de la Repblica,
General de Divisin Don Juan Velasco Alvarado, y el Ministro de
Aeronutica y Comandante General de la FAP, Teniente General
Rolando Giraldo Rodrguez.
Desde ese entonces el Hospital Central constaba de 02 pabellones; uno

para consultorios externos y el otro para hospitalizacin; y un
helipuerto ubicado en el 5to. Piso.
En el ao 1970 el Mayor General FAP Hernn de Souza Peixoto fue

designado como primer Director del Hospital Central FAP, desde
entonces hasta la actualidad han pasado por este Nosocomio 26
distinguidos Directores, siendo su actual Director el Mayor General FAP
Zdenko Teply Batagelj.
De conformidad con el Decreto Supremo N 010-70/AE, de fecha 08 de

Julio de 1970, se regulariza la creacin del Hospital Central FAP y con
Ordenanza FAP 20-18 del 13 de Enero de 1971 se establece su
Organizacin.
Aos ms tarde, mediante Resolucin Ministerial N 194-82/AE de

fecha 09 de Febrero de 1982, se aprueba que el Hospital Central FAP
lleve el nombre de Comandante FAP Mdico JUAN BENAVIDES
DORICH, en homenaje al eminente profesional cado en la selva
peruana en acto de servicio, el 10 de Octubre de 1947.
46 | P g i n a
Figura 7. Hospital Central de la Fuerza Area del Per. Fuente: Imagen Propia
Actualmente, el Hospital Central de la Fuerza Area del Per, se

encuentra a la vanguardia de los mejores Centros Hospitalarios de
Latinoamrica, permitiendo, sin lugar a duda, una atencin eficiente y de
la ms alta calidad profesional.
El Hospital Central FAP funciona con Personal Militar, Civil Profesional y

Administrativo en una conjuncin armoniosa de diferentes
especialidades en provecho de la familia FAP y de la comunidad en
general.
2.4.2. Aspectos Generales del Hospital Central FAP

2.4.2.1. Visin del HCFAP
Alcanzar la excelencia en la prestacin de salud, docencia e

investigacin.
47 | P g i n a
2.4.2.2. Misin del HCFAP
Brindar atencin integral de salud y de alta complejidad al personal

militar FAP, para optimizar su capacidad operativa y calidad de vida,
extendiendo su accionar a los familiares directos y la comunidad; as
como, brindar el soporte administrativo necesario para tal propsito.
2.4.2.3. Valores Corporativos del HCFAP
Atencin con calidad y eficiencia.

Servir con responsabilidad.
Trabajo en equipo.
2.4.2.4. Infraestructura
El Hospital Central de la Fuerza Area del Per fue inaugurado el 30 de

Abril de 1970. Tiene un terreno de 7726 m 2 y un rea construida de
29953 m2. Est ubicado en la cuadra 2 de la Avenida Arambur en el
distrito de Miraflores.
FICHA TCNICA HCFAP

Terreno 7,726 m2
rea construida 29,953 m2
Obras iniciadas 16-Jul-1965
Inaugurado 30-Abr-1970
Antigedad 39 aos
Tabla 6. Ficha Tcnica del Hospital Central FAP. Fuente: Departamento de Ingeniera del HCFAP
Cuenta con un rea de Consultorios Externos distribuido en un edificio

de 05 pisos; asimismo cuenta con un rea de Hospitalizacin
distribuido en otro edificio de 10 pisos, en las cuales existen
aproximadamente 120 habitaciones as como diversos equipos mdicos,
biomdicos y electromecnicos.
48 | P g i n a
HOSPITAL ESPECIALIZADO III
N Habitaciones 120
N camas 287
N camas S.O.P. 6
N camas UTI 8
N camas emergencia 23
Tabla 7. Numero de Habitaciones y Camas del HCFAP. Fuente: Departamento de Ingeniera del HCFAP
El Hospital Central FAP desde el ao 1995 cuenta con un local anexo

para las atenciones Odontolgicas y Geritricas llamado Instituto de
Salud Oral y Atenciones Geritricas (ISOFAP), el mismo que est
ubicado entre las calles Las Tiendas y Los Paujiles en el distrito de
Surquillo.
FICHA TCNICA ANEXO AL HOSPI

Terreno 2,304 m2
rea construida 3,081 m2
Antigedad 25 aos
Tabla 8. Ficha Tcnica del Instituto de Salud Oral y Atenciones Geritricas. Fuente: Departamento de
Ingeniera del HCFAP
Figura 8. Instituto de Salud Oral y Atenciones Geritricas (ISOFAP). Fuente: Imagen Propia
49 | P g i n a
El hospital dispone de un Helipuerto, para garantizar la atencin
oportuna, que hace del servicio la unidad operativa ms eficaz y singular
del pas.
2.4.2.5. Equipamiento
El Hospital Central FAP, es un moderno centro asistencial especializado

con Equipos Biomdicos, Mdicos y Electromecnicos de ltima
generacin y de alta especializacin, a fin de cubrir las necesidades del
paciente, dndoles seguridad y confianza, por lo que en este ltimo ao
se ha continuado con la renovacin de los equipos hospitalarios.
Figura 9. Equipos Biomdicos de ltima generacin. Fuente: Imgenes de google
A continuacin se detalla la cantidad de equipos hospitalarios con los

que cuenta el Hospital actualmente, clasificados segn el grupo de
equipamiento.
Tabla 9. Total del Equipamiento Hospitalario del Hospital Central FAP. Fuente: Departamento de
Ingeniera del HCFAP
50 | P g i n a
Dentro del equipamiento hospitalario ms importantes tenemos:
Equipo para Video Colposcopia.

Equipo de Esterilizacin de Vapor.
Equipo de Esterilizacin de Oxido de Etileno.
Equipo de Laparoscopia para Ciruga General.
Equipo Arco en C Intensificador de Imgenes Digitales.
Equipo de Cineangiografia Coronaria.
Equipo Ecocardigrafo.
Equipo Electrocardigrafo.
Equipo Mapa Holter.
Equipo de Tomografa Computarizada Helicoidal.
Equipo de Resonancia Magntica Nuclear.
Equipo de Cateterismo Cardiovascular.
Equipo de Maquinas de Dilisis.
Equipo de Broncofibroscopia Respiratoria.
Equipo de Artroscopia.
Equipo de Densitometra sea.
Equipo para Mamografas.
Equipo Cmara Gamma.
Equipo de Rayos X.
Equipo Ecgrafo Doppler.
Equipo de Ultrasonido
Equipo Detector de Latidos Fetales.
Uno de los principales problemas que afronta el Hospital y el

Departamento de Ingeniera es la antigedad del equipamiento
hospitalario y de las instalaciones. Una gran parte de estos equipos
promedian una antigedad de 25 aos, lo que en muchos casos dificulta
su reparacin y/o mantenimiento, por tener un periodo muy alto de
funcionamiento y por sus constantes fallas y reparaciones.
51 | P g i n a
DETALLE ANTIGEDAD
EQ. ELECTROMECANICO 26 AOS
EQ. MEDICO 26 AOS
EQ. BIOMEDICO 23 AOS
INSTRUMENTAL QUIRURGICO 11/26 AOS
INSTALACIONES EN HOSPI 39 AOS
INSTALACIONES EN ISOFAP 25 AOS
Tabla 10. Antigedad de los Equipos e Instalaciones del HCFAP. Fuente: Departamento de Ingeniera
del HCFAP
2.4.2.6. Recursos Humanos
El Hospital Central FAP cuenta con un plantel de profesionales

altamente capacitados en todas las especialidades, orientados a la
bsqueda permanente de la excelencia en cada una de las actividades
que desarrollan, existiendo para ello un continuo programa de
perfeccionamiento en el pas y en el extranjero.
Figura 10. Plantel de Profesionales Mdicos del Hospital Central FAP. Fuente: Imagen Propia
52 | P g i n a
Actualmente en el Hospital Central FAP laboran un total de 1680
trabajadores entre personal militar, mdico, paramdico, residente,
interno y administrativo. En el siguiente grfico estadstico se muestra el
total del personal que labora en el Hospital, divididos en Personal Militar,
Personal Civil y Personal Prestacin de Servicios.
Total Ao 2009: 1680 trabajadores
Figura 11. Total de Trabajadores del Hospital Central FAP. Fuente: Departamento de Personal del
HCFAP
2.4.2.7. Personal Afiliado al HCFAP
El Hospital brinda sus servicios asistenciales y hospitalarios a todo

personal militar FAP (en retiro o actividad) y sus familiares (padres,
conyugues e hijos) que se encuentren afiliados al Fondo de Salud FAP
y al Hospital Central FAP. Segn fuente del Fondo de Salud FAP
(FOSFAP), la poblacin FAP (Total de Titulares y Familiares) al 2008
era de 48,602 personas. Actualmente se estima una poblacin de
62,065 personas. Otro dato importante es que la poblacin infantil
asciende a 11,825 nios.
Tabla 11. Total de Titulares y Familiares de la FAP. Fuente: Departamento de Fondo de Salud
53 | P g i n a
13,040
27%
35,562
73% TOTAL TITULARES
TOTAL FAMILIARES
Figura 12. Total de Titulares y Familiares de la FAP. Fuente: Departamento de Fondo de Salud del
HCFAP
En cuanto al personal militar en actividad (personal superior y

subalterno), la suma equivale a 7,584 militares, mientras que el
personal militar en retiro asciende a 5,456 militares retirados.
Tabla 12. Total de Titulares FAP en Actividad y en Retiro. Fuente: Departamento de Fondo de Salud del
HCFAP
Estos datos numricos y estadsticos anteriormente presentados son

importantes, ya que definimos el alcance y la cobertura que presenta el
Hospital para sus asegurados o afiliados. Debido a la gran cantidad de la
Poblacin FAP (62,065 personas) y por ende a la elevada cantidad de
personal que concurre diariamente al Hospital Central FAP, se promedia
un total de 1,200 atenciones medicas diarias en los consultorios
externos as como en Hospitalizacin.
2.4.2.8. Servicios Asistenciales
El hospital cuenta con las siguientes Especialidades Mdicas:
54 | P g i n a
Cardiologa
Ciruga General
Ciruga Trax y Cardiovascular
Dental
Dermatologa
Emergencia
Endocrinologa
Gastroenterologa
Geriatra
Ginecologa Obstetricia
Medicina Interna
Neonatologa
Neumologa
Neurociruga
Neurologa
Odontopediatria
Oftalmologa
Onco-Hematologia
Otorrinolaringologa
Pediatra
Psicologa
Psiquiatra
Reumatologa
Terapia Fsica
Traumatologa
Urologa
2.4.2.9. Organizacin del Hospital Central FAP

Segn la Ordenanza FAP 20-18 del 01 de junio de 2007, el Hospital
Central FAP presenta la siguiente estructura orgnica:
55 | P g i n a
a) rgano de Direccin
1. Direccin
Subdireccin.
b) Grupo Personal
1. Ayudanta.
2. Oficina de Informacin y Relaciones Pblicas.
c) rganos Consultivos y de Asesora
1. Oficina de Prevencin de Accidentes.
2. Asesora legal.
3. Oficina de Mejoramiento de la Calidad.
d) rgano de Planeamiento
1. Departamento de Planes.
e) rgano de Control
1. Oficina de Inspectora.
f) rganos de Apoyo
1. Departamento de Comercializacin.
2. Departamento de Economa y Finanzas.
3. Departamento de Educacin.
g) rgano de Ejecucin
1. Direccin Ejecutiva de Salud.
2. Direccin Ejecutiva de Administracin.
Departamento de Abastecimiento.
Departamento de Informtica.
Departamento de Ingeniera.
Departamento de Personal.
56 | P g i n a
Departamento de Seguridad.
Departamento de Servicios.
Segn fuente del Departamento de Planes del HCFAP, actualmente en

el Hospital existen 38 Departamentos, ya sean de Salud, de
Administracin, de Apoyo y de Planeamiento.
A continuacin se mostrar el Organigrama General del Hospital Central

de la Fuerza Area del Per.
Figura 13. Organigrama del Hospital Central FAP. Fuente: Departamento de Planes del HCFAP
57 | P g i n a
2.4.3. Aspectos Generales del Departamento de
Ingeniera del HCFAP
El Departamento de Ingeniera del HCFAP es el rea responsable de
programar, ejecutar, supervisar y controlar el mantenimiento preventivo y
correctivo de las instalaciones y de los equipos mdicos, biomdicos y
electromecnicos del Hospital Central FAP.
2.4.3.1. Visin
Ser un servicio eficiente, seguro, de calidad y confiable en el
mantenimiento del equipamiento e infraestructura del HCFAP, para su
disponibilidad en todo momento y al mximo de sus prestaciones,
logrando la satisfaccin de los usuarios a bajo costo, con eficiencia
energtica e integridad ambiental.
2.4.3.2. Tarea
Mantener operativos todos los equipos, instalaciones e infraestructura
del Hospital de manera eficiente para la ptima atencin al paciente y al
personal del Hospital.
2.4.3.3. Organizacin del Departamento de Ingeniera del

HCFAP
Segn el Departamento de Ingeniera del Hospital Central FAP, la

organizacin que presenta el departamento se conforma de la siguiente
estructura orgnica:
a) Jefatura
Dirige, coordina, supervisa y controla las acciones dispuestas a las

secciones a su cargo para lograr mayor eficiencia en los servicios
que se presta. Verifica y controla el mantenimiento que se requiera
para el funcionamiento de la infraestructura y del equipamiento del
hospital.
58 | P g i n a
b) Secretaria
Confecciona, registra, tramita y archiva segn sea el caso, la

documentacin de la Jefatura de Ingeniera.
c) Oficina de Programacin y Control
Programa y controla el cumplimiento del Mantenimiento Correctivo y

Preventivo de los equipos hospitalarios, solicitados mediante
rdenes de Trabajo. Formula el Plan de Mantenimiento Preventivo
de todos los equipos e instalaciones del Hospital que se encuentren
bajo responsabilidad del Departamento, para velar por su buen
funcionamiento.
d) Oficina de Control de Calidad y Seguridad Industrial
Realiza tareas de asesoramiento a la Jefatura en el rea de Control

de Calidad a los trabajos realizados por las divisiones del
Departamento de Ingeniera; certificando la operatividad de los
equipos y/o instalaciones reparadas, registrando la certificacin en la
orden de trabajo que corresponda as como en el tema de Seguridad
Industrial Especializada, verificando adems que los trabajos
realizados por terceros estn de acuerdo al contrato y propuesta
tcnica correspondiente.
e) Seccin Electrnica
La principal tarea de esta seccin es mantener la operatividad de los

Equipos Mdicos, Biomdicos y de Comunicaciones existentes en el
Hospital para su debido funcionamiento. Esta seccin se compone
de las siguientes divisiones:
1. Divisin de Equipos Biomdicos

Ejecuta el plan de Mantenimiento Preventivo y realiza las
reparaciones de los Equipos Biomdicos para su correcto
funcionamiento.
59 | P g i n a
2. Divisin de Equipos Mdicos
Ejecuta el plan de Mantenimiento Preventivo y realiza las
reparaciones de los Equipos Mdicos para su correcto
funcionamiento.
3. Divisin Comunicaciones
Mantiene la operatividad y el buen estado de conservacin de
los equipos de comunicaciones tales como: televisores, VHS,
DVD, telfonos fijos y mviles, intercomunicadores, equipos de
sonido, cmaras de vdeo y sistemas de perifoneo del Hospital.
4. Divisin Central Telefnica

Provee un eficiente servicio de operador de Central Telefnica
en todo el Hospital Central FAP.
f) Seccin Electromecnica
La principal tarea de esta seccin es mantener la operatividad de las

redes, instalaciones y Equipos Electromecnicos y Mecnicos del
Hospital para su debido funcionamiento. Esta seccin se compone
de las siguientes divisiones:
1. Divisin Casa de Fuerza

Mantiene un sistema de control eficiente y efectivo de la
situacin de las redes hospitalarias y de los equipos existentes
en Casa de Fuerza, los cuales son los siguientes:
Electrobombas de agua.
Calderos.
Electrobombas de sumidero (Desage)
Ablandadores de agua dura
Central de Oxgeno
Bombas de condensado.
Incineradores de Desechos.
60 | P g i n a
DESCRIPCION
01 VAPOR Y CONDENSADOS
02 AGUA DURA
03 AGUA BLANDA
04 OXIGENO
05 GAS PROPANO
06 VACIO
07 AGUA PARA CONTRAINCENDIO
08 AGUA CALIENTE
09 ENERGIA ELEC. EMERGENCIA
10 ELECTRICA
11 DESAGUE COCINA
12 AIRE COMPRIMIDO MEDICINAL
13 AIRE COMPRIMIDO INDUSTRIAL
Tabla 13. Redes Hospitalarias del Hospital Central FAP. Fuente: Departamento de Ingeniera del
HCFAP
2. Divisin Mecnica
Realiza el mantenimiento y reparacin del material de enseres
metlicos y accesorios del Hospital. Ejecuta las obras de
carpintera metlica y de aluminio. Realiza trabajos de soldadura
y fabricacin de piezas.
3. Divisin Mecnica Fina

Realiza el mantenimiento y reparacin de las chapas de puertas,
cajones, armarios, vitrinas, muebles y confeccin de llaves.
4. Divisin Mecnica Elctrica

Realiza el mantenimiento y reparacin de los Equipos
Electromecnicos del Hospital que incluyen: Lavadoras, cocinas,
electrobombas, grupos electrgenos, compresoras, ventiladores,
estufas, licuadoras, lustradoras, etc.
5. Divisin Refrigeracin
Realiza el mantenimiento y reparacin de los Equipos
Electromecnicos del Hospital que incluyen: Aire Acondicionado,
extractores de aire, refrigeradoras, congeladoras, cmaras
frigorficas de la Cocina, etc.
61 | P g i n a
Tabla 14. Sistemas Electromecnicos Hospitalarios. Fuente: Departamento de Ingeniera del HCFAP
g) Seccin Instalaciones
La principal tarea de esta seccin es mantener operativas las redes,

sistemas, instalaciones e infraestructura del Hospital Central FAP
para su debido funcionamiento. Esta seccin se compone de las
siguientes divisiones:
1. Divisin Albailera
Mantiene en buen estado de conservacin la Infraestructura y
Edificacin del Hospital para su ptimo funcionamiento.
2. Divisin Carpintera
Confecciona, repara y/o remodela el mobiliario, closets, puertas
y tabiquera de madera del Hospital.
3. Divisin Electricidad
Realiza el mantenimiento y reparacin de las redes, sistemas e
instalaciones elctricas del Hospital.
4. Divisin Gasfitera
Mantiene en ptimo estado el sistema de distribucin de agua y
desage, as como las instalaciones sanitarias y equipos afines
62 | P g i n a
del Hospital para su debido funcionamiento.
5. Divisin Pintura
Efecta los trabajos de mantenimiento y conservacin de la
pintura de la infraestructura y del mobiliario y equipos del
Hospital para su adecuada presentacin.
6. Divisin Tapicera
Realiza el mantenimiento, reparacin y/o modificacin del tapiz
de los muebles instalados en las salas del Hospital.
A continuacin se mostrar el Organigrama General del Departamento

de Ingeniera del Hospital Central FAP.
Figura 14. Organigrama del Departamento de Ingeniera del Hospital Central FAP. Fuente:
Departamento de Ingeniera del HCFAP
63 | P g i n a
2.5. Marco Legal
2.5.1. Del Estado Peruano
1) Constitucin Poltica del Per de 1993.
2) Ley N 27293, Ley del Sistema Nacional de inversin Pblica creado

con la finalidad de optimizar el uso de los recursos pblicos destinados
a la inversin.
3) Resolucin Ministerial N 001-B-2004 del 15 de enero del 2004

Objetivos y Polticas del Estado para la Seguridad y Defensa
Nacional.
2.5.2. Del Sector Salud
1) Ley N 26842 Ley General de Salud.
2) Ley N 27657, dispone que los reglamentos de organizacin y

funciones de los Hospitales del sector pblico se formularn segn los
modelos establecidos por el MINSA.
3) Decreto Supremo N 005-90-SA, Reglamento General de Hospitales

que establece la estructura orgnica y las funciones de los cargos
orgnicos de los Hospitales pblicos del pas.
4) Decreto Supremo N 002-2003-SA que autoriza la importacin de

equipos mdicos que tienen la condicin de usados-repotenciados o de
usados que no requieren ser repotenciados, buen estado de
funcionamiento y solo para uso profesional.
5) Decreto Supremo N 013-2006-SA del 25 de junio de 2006, aprueba el

Reglamento de los Establecimientos de Salud y Servicios Mdicos de
Apoyo; asimismo, establece los requisitos y condiciones para la
operacin y funcionamiento de los establecimientos de salud y
servicios mdicos de apoyo.
64 | P g i n a
6) Resolucin Suprema N 054-97-SA que aprueba la donacin del
Gobierno de Japn para el mejoramiento de equipos mdicos de
hospitales nacionales.
7) Resolucin Suprema N 014-2002-SA que aprueba los Lineamientos

de Poltica Sectorial para el perodo 2002 - 2012, donde se establece
como objetivo estratgico la REESTRUCTURACIN INTEGRAL DE
LOS SISTEMAS ADMINISTRATIVOS Y OPERATIVOS para la
modernizacin de su organizacin y desarrollo del Sistema de Salud.
8) Resolucin Ministerial N 016-98-SA/DM que aprueban las normas

tcnicas para el Mantenimiento Preventivo y Conservacin de la
Infraestructura Fsica de Hospitales.
9) Resolucin Ministerial N 616-2003-SA/DM del 30 de mayo de 2003

que establece el modelo de Reglamento de Organizacin y Funciones
de los hospitales de alta, mediana y baja complejidad en atencin de la
salud. Asimismo, establece la estructura orgnica de los hospitales de
alta complejidad comprendiendo hasta tres niveles organizacionales
definiendo especficamente los rganos de direccin, control, asesora,
apoyo y de lnea.
10) Resolucin Ministerial N 769-2004/MINSA del 26 de Julio de 2004 que

establece las categoras de los establecimientos de salud en base a los
niveles de atencin, complejidad, caractersticas funcionales de
acuerdo con las necesidades de salud que atiende. Por tal motivo, al
HCFAP le corresponde el tercer nivel de atencin, siendo su categora
de establecimiento de salud III-1.
2.5.3. Del Sector Defensa
1) Ley N 27860 del 12 de Noviembre de 2002 Ley del Ministerio de

Defensa.
65 | P g i n a
2) Decreto Legislativo N 439 del 27 de Setiembre de 1987 Ley Orgnica
de la Fuerza Area.
3) Decreto Supremo N 004-DE/SG del 20 de Febrero de 2003,

Reglamento de la Ley del Ministerio de Defensa.
2.5.4. De la Fuerza Area del Per
1) Decreto Supremo N 010-70/AE del 08 de julio de 1970, crea dentro de

la estructura orgnica de la FAP el Hospital Central de la Fuerza Area
del Per, como unidad altamente especializada, destinada a mantener
en el mas alto nivel de condiciones psicofsicas al personal FAP.
2) Ordenanza FAP 20-18 del 01 de Junio de 2007 ORGANIZACIN -

HOSPITAL CENTRAL FAP vigente.
3) Ordenanza FAP 20-25 vigente, establece la organizacin de la

Direccin de Sanidad (DISAN), considerando dentro de sus rganos de
ejecucin al HCFAP, como Unidad Dependiente.
4) Ordenanza FAP 160-10 vigente, establece el Sistema de Sanidad FAP

(SISAN), considerando a la DISAN como su rgano Rector, la misma
que est encargada de emitir las normas necesarias para optimizar los
procesos de atencin de salud individual y colectiva.
5) Directiva FAP 17-2 PLANEAMIENTO Y PROGRAMACIN -

PROGRAMAS DIRECTORES DE LA FAP, del 14 de diciembre de
2004.
6) Directiva FAP 17-3 PLANEAMIENTO Y PROGRAMACIN -

FORMULACIN DEL PLAN OPERATIVO INSTITUCIONAL (POI),
PRESUPUESTO INSTITUCIONAL DE APERTURA (PIA) Y EL PLAN
ANUAL DE ADQUISICIONES Y CONTRATACIONES (PAAC), PARA
66 | P g i n a
EL AF-2006 DE LA FUERZA AREA DEL PER, del 03 de junio de
2005.
7) Directiva DISAN 160-30 del 24-01-05 SANIDAD Normas para el

Planeamiento a corto plazo de la Atencin de la Salud en los
organismos de Sanidad
67 | P g i n a
CAPITULO III:
ESTADO DEL ARTE
68 | P g i n a
3.1. Taxonoma
El tema del proyecto de tesis que estoy desarrollando, segn la clasificacin de
la ACM (Association for Computing Machinery) es la siguiente:
H. Sistemas de Informacin
o H.4 Aplicaciones de Sistemas de Informacin
H.4.0 General
Esto quiere decir que en el rea de la Ingeniera Informtica, el tema de tesis

Sistema de Informacin para el Control, Seguimiento y Mantenimiento del
Equipamiento Hospitalario est clasificado dentro del rea Sistemas de
Informacin y subarea Aplicaciones de Sistemas de Informacin General.
Figura 15. Pagina Web del Sistema de Clasificacin Informtica de la ACM. Fuente: Association for
Computing Machinery (www.acm.org)
69 | P g i n a
3.2. Revisin de Mtodos y Metodologas
Para el anlisis, diseo, desarrollo e implementacin de este proyecto
informtico, se ha estudiado y comparado las diferentes Metodologas de
Desarrollo de Software actualmente existentes. A continuacin se brindar toda
la informacin de los mtodos y/o metodologas que se han estudiado, as como
la eleccin de la metodologa ms conveniente a utilizar para el desarrollo de
este proyecto informtico.
3.2.1. Metodologas de Desarrollo de Software

Las Metodologas de Desarrollo de Software son un conjunto de
pasos y procedimientos que deben seguirse para el desarrollo de
software. Se puede definir tambin como un conjunto de
procedimientos, tcnicas, herramientas y un soporte documental que
ayuda a los desarrolladores a producir nuevo software.
Una Metodologa de Desarrollo de Software se refiere a un

framework que es usado para estructurar, planear y controlar el proceso
de desarrollo en sistemas de informacin. A lo largo del tiempo, una gran
cantidad de mtodos han sido desarrollados diferencindose por su
fortaleza y debilidad.
Un framework para la metodologa de desarrollo de software consiste

en:
Una filosofa de desarrollo de software, con el enfoque del proceso

de desarrollo de software.
Herramientas, modelos y mtodos para asistir al proceso de

desarrollo de software.
Estos frameworks son a menudo vinculados a algn tipo de

organizacin que desarrolla, apoya el uso y promueve la metodologa.
70 | P g i n a
La metodologa es a menudo documentadas en algn tipo de
documentacin formal.
3.2.1.1. Historia
El desarrollo de los Sistemas Tradicionales de ciclo de vida se origin en
la dcada de 1960 para desarrollar a gran escala funcional sistemas de
negocio, en una poca de grandes conglomerados empresariales. La
idea principal era continuar el desarrollo de los sistemas de informacin
en una muy deliberada, estructurada y metdica forma, reiterando cada
una de las etapas del ciclo de vida. Los sistemas de informacin en torno
a las actividades resueltas eran muy pesados para el procesamiento de
datos y rutinas de clculo.
Programacin estructurada desde 1969.

1970s Programacin estructurada Jackson desde 1975.
Structured Systems Analysis and Design Methodology (SSADM) desde 1980.

Structured Analysis and Design Technique (SADT) desde 1980.
1980s Ingeniera de la informacin (IE/IEM) desde 1981.
Rapid application development (RAD) desde 1991.

Programacin orientada a objetos (OOP) a lo largo de la dcada de los 90's.
Virtual finite state machine (VFSM) desde 1990s.
1990s Dynamic Systems Development Method desarrollado en UK desde 1995.
Scrum (desarrollo), en la ltima parte de los 90's.
Programacin extrema desde 1999.

Enterprise Unified Process (EUP) extensiones RUP desde 2002.
Rational Unified Process (RUP) desde 2003.
Nuevo Constructionist design methodology (CDM) desde 2004 por Kristinn R.
Milenio Thrisson.
Agile Unified Process (AUP) desde 2005 por Scott Ambler.
Tabla 15. Historia de las Metodologas de Desarrollo de Software. Fuente: Wikipedia - Elaboracin
Propia
3.2.1.2. Modelos de Desarrollo de Software
La Ingeniera de Software tiene modelos, paradigmas o filosofas de

desarrollo en los cuales se puede apoyar para la realizacin de
software, de los cuales podemos destacar a los siguientes modelos por
ser los ms utilizados y los ms completos:
71 | P g i n a
Modelo en Cascada o Clsico: Framework lineal.
Modelo en Espiral: Combinacin de framework lineal e iterativo.
Modelo Basado en Prototipos: Framework iterativo.
Modelo Incremental: Combinacin de framework lineal e iterativo.
RAD (Rapid Application Development): Framework iterativo.
Otros Modelos de Desarrollo de Software.
Figura 16. Tres modelos bsicos en las metodologas de desarrollo de software. Fuente: Metodologas
de Desarrollo de Software, Wikipedia
a) Modelo en Cascada
Es un proceso secuencial de desarrollo en el que los pasos de

desarrollo son vistos hacia abajo (como en una cascada de agua) a
travs de las fases de anlisis de las necesidades, el diseo,
implementacin, pruebas (validacin), integracin, y mantenimiento. La
primera descripcin formal del modelo de cascada se cita a menudo a un
artculo publicado por Winston Royce W. en 1970, aunque Royce no
utiliza el trmino "cascada" de este artculo.
Los principios bsicos del modelo de cascada son los siguientes:
72 | P g i n a
El proyecto est dividido en fases secuenciales, con cierta
superposicin y splashback aceptable entre fases.
Se hace hincapi en la planificacin, los horarios, fechas,

presupuestos y ejecucin de todo un sistema de una sola vez.
Un estricto control se mantiene durante la vida del proyecto a

travs de la utilizacin de una amplia documentacin escrita, as
como a travs de comentarios y aprobacin / signoff por el usuario y
la tecnologa de la informacin de gestin al final de la mayora de las
fases antes de comenzar la prxima fase.
Figura 17. El Modelo original en Cascada. Fuente: Lean Software Development: An Agile Toolkit for
Software Development Managers. Addison-Wesley, 2003
b) Modelo en Espiral
El desarrollo en espiral es un modelo de ciclo de vida del software

definido por primera vez por Barry Boehm en 1988, utilizado
generalmente en la Ingeniera de software. Las actividades de este
modelo se conforman en una espiral, en la que cada bucle o iteracin
73 | P g i n a
representa un conjunto de actividades. Las actividades no estn fijadas a
priori, sino que las siguientes se eligen en funcin del anlisis de riesgo,
comenzando por el bucle interior.
Los principios bsicos del modelo espiral son los siguientes:
La atencin se centra en la evaluacin y reduccin del riesgo del

proyecto dividiendo el proyecto en segmentos ms pequeos y
proporcionar ms facilidad de cambio durante el proceso de
desarrollo, as como ofrecer la oportunidad de evaluar los riesgos y
con un peso de la consideracin de la continuacin del proyecto
durante todo el ciclo de vida.
Cada viaje alrededor de la espiral atraviesa cuatro cuadrantes

bsicos: (1) Determinar objetivos, alternativas, y desencadenantes
de la iteracin; (2) Evaluar alternativas; Identificar y resolver los
riesgos; (3) Desarrollar y verificar los resultados de la iteracin, y (4)
Plan de la prxima iteracin.
Cada ciclo comienza con la identificacin de los interesados y sus

condiciones de ganancia, y termina con la revisin y examinacin.
Figura 18. El Modelo Espiral de 6 Actividades. Fuente: Metodologas de Desarrollo de Software,

Universidad Manuela Beltrn, Bogot
74 | P g i n a
c) Modelo de Prototipos
El desarrollo con prototipacin, tambin llamado modelo de prototipos

que pertenece a los modelos de desarrollo evolutivo, se inicia con la
definicin de los objetivos globales para el software, luego se
identifican los requisitos conocidos y las reas del esquema en donde es
necesaria ms definicin. Entonces se plantea con rapidez una iteracin
de construccin de prototipos y se presenta el modelado (en forma de un
diseo rpido).
El diseo rpido se centra en una representacin de aquellos aspectos

del software que sern visibles para el cliente o el usuario final (por
ejemplo, la configuracin de la interfaz con el usuario y el formato de los
despliegues de salida). El diseo rpido conduce a la construccin de un
prototipo, el cual es evaluado por el cliente o el usuario para una
retroalimentacin; gracias a sta se refinan los requisitos del software
que se desarrollar. La iteracin ocurre cuando el prototipo se ajusta
para satisfacer las necesidades del cliente. Esto permite que al mismo
tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente
vea resultados a corto plazo.
Figura 19. Modelo de Prototipos. Fuente: Metodologas de Desarrollo de Software, Universidad Manuela
Beltrn, Bogot
75 | P g i n a
d) Modelo Incremental
Provee una estrategia para controlar la complejidad y los riesgos,

desarrollando una parte del producto software, reservando el resto de
aspectos para el futuro.
Los principios bsicos del modelo incremental son los siguientes:
Una serie de mini-Cascadas se llevan a cabo, donde todas las

fases de la cascada modelo de desarrollo se han completado para
una pequea parte de los sistemas, antes de proceder a la prxima
incremental.
Se definen los requisitos antes de proceder con la evolutivo, se

realiza una mini-Cascada de desarrollo de cada uno de los
incrementos del sistema.
El concepto inicial de software, anlisis de las necesidades, y el

diseo de la arquitectura y colectiva bsicas se definen utilizando el
enfoque de cascada, seguida por iterativo de prototipos, que
culmina en la instalacin del prototipo final.
Figura 20. Modelo Incremental. Fuente: Metodologas de Desarrollo de Software, Universidad Manuela
Beltrn, Bogot
76 | P g i n a
e) Rapid Application Development (RAD)
El Desarrollo Rpido de Aplicaciones (RAD) es una metodologa de

desarrollo de software, que implica el desarrollo iterativo y la
construccin de prototipos. El desarrollo rpido de aplicaciones es un
trmino originalmente utilizado para describir un proceso de desarrollo
de software introducido por James Martin en 1991.
Los principios bsicos de RAD son los siguientes:
Objetivo clave es para un rpido desarrollo y entrega de una alta

calidad en un sistema de relativamente bajo coste de inversin.
Intenta reducir el riesgo inherente del proyecto partindolo en

segmentos ms pequeos y proporcionar ms facilidad de cambio
durante el proceso de desarrollo.
Orientacin dedicada a producir sistemas de alta calidad con rapidez,

principalmente mediante el uso de iteracin por prototipos (en
cualquier etapa de desarrollo), promueve la participacin de los
usuarios y el uso de herramientas de desarrollo computarizadas.
Estas herramientas pueden incluir constructores de Interfaz grfica
de usuario (GUI), Computer Aided Software Engineering (CASE) las
herramientas, los sistemas de gestin de bases de datos (DBMS),
lenguajes de programacin de cuarta generacin, generadores de
cdigo, y tcnicas orientada a objetos.
Hace especial hincapi en el cumplimiento de la necesidad

comercial, mientras que la ingeniera tecnolgica o la excelencia es
de menor importancia.
Control de proyecto implica el desarrollo de prioridades y la definicin

de los plazos de entrega. Si el proyecto empieza a aplazarse, se
hace hincapi en la reduccin de requisitos para el ajuste, no en el
aumento de la fecha lmite.
77 | P g i n a
En general incluye Joint Application Development (JAD), donde
los usuarios estn intensamente participando en el diseo del
sistema, ya sea a travs de la creacin de consenso estructurado en
talleres, o por va electrnica.
La participacin activa de los usuarios es imprescindible.
Iterativamente realiza la produccin de software, en lugar de colgarse

de un prototipo.
Produce la documentacin necesaria para facilitar el futuro desarrollo

y mantenimiento.
Figura 21. RAD vs. Metodologa Tradicional. Fuente: Rapid Application Development,
http://www.etondigital.com/services/ Elaboracin Propia
78 | P g i n a
f) Otros Modelos de Desarrollo de Software
Metodologas de Desarrollo Orientado a Objetos, Diseo

Orientado a Objetos (DOO) de Grady Booch, tambin conocido
como Anlisis y Diseo Orientado a Objetos (ADOO). El modelo
incluye seis diagramas: de clase, objeto, estado de transicin, la
interaccin, mdulo, y el proceso.
Top-down Programming, evolucionado en la dcada de 1970 por el

investigador de IBM Harlan Mills (y Niklaus Wirth) en Desarrollo
Estructurado.
Proceso Unificado, es una metodologa de desarrollo de software,

basado en UML. Organiza el desarrollo de software en cuatro fases,
cada una de ellas con la ejecucin de una o ms iteraciones de
desarrollo de software: creacin, elaboracin, construccin, y las
directrices. Hay una serie de herramientas y productos diseados
para facilitar la aplicacin. Es una de las versiones ms populares de
la de Rational Unified Process.
3.2.1.3. Mtodos Heterodoxos en Desarrollo de Software
A finales de la dcada de 1990, dos grandes temas irrumpieron en las

prcticas de la Ingeniera de Software y en los mtodos de desarrollo.
Estos temas fueron: El diseo basado en Patrones y los Mtodos
giles.
Los Mtodos giles constituyen un movimiento heterodoxo que

confronta con las metodologas consagradas, acordadas en organismos
y apreciadas por consultores, analistas de industria y corporaciones.
79 | P g i n a
3.2.1.3.1. Mtodos giles (MA)
El trmino gil aplicado al desarrollo de software nace en febrero de

2001, tras una reunin celebrada en Utah-EEUU. En esta reunin
participaron un grupo de 17 expertos de la industria del software,
incluyendo algunos de los creadores o impulsores de metodologas de
software. Su objetivo fue esbozar los valores y principios que
deberan permitir a los equipos desarrollar software rpidamente y
respondiendo a los cambios que puedan surgir a lo largo del proyecto.
Se pretenda ofrecer una alternativa a los procesos de desarrollo de
software tradicionales, caracterizados por ser rgidos y dirigidos por la
documentacin que se genera en cada una de las actividades
desarrolladas.
Los mtodos giles enfatizan las comunicaciones cara a cara en vez

de la documentacin. La mayora de los equipos giles estn localizados
en una simple oficina abierta, a veces llamadas "plataformas de
lanzamiento" (bullpen en ingls). La oficina debe incluir revisores,
escritores de documentacin y ayuda, diseadores de iteracin y
directores de proyecto. Los mtodos giles tambin enfatizan que el
software funcional es la primera medida del progreso. Combinado con la
preferencia por las comunicaciones cara a cara, generalmente los
mtodos giles son criticados y tratados como "indisciplinados" por la
falta de documentacin tcnica.
Existen unos cuantos Mtodos giles reconocidos por los especialistas.

A continuacin se nombrarn los diez Mtodos giles mas utilizados
en la industria del software:
80 | P g i n a
1 Extreme Programming (XP)
2 Scrum
3 Evolutionary Project Management (EVO)
4 Crystal Methods
5 Feature Driven Development (FDD)
6 Rational Unified Process (RUP)
7 Dynamic Systems Development Method (DSDM)
8 Adaptive Software Development (ASD)
9 Agile Modeling (AM)
10 Lean Development (LD)
Tabla 16. Mtodos giles ms utilizados. Fuente: Elaboracin Propia
Tras la reunin anteriormente descrita, se cre la Alianza gil (The

Agile Alliance), una organizacin sin nimo de lucro, dedicada a
promover los conceptos relacionados con el desarrollo gil de software y
ayudar a las organizaciones para que adopten dichos conceptos. El
punto de partida fue el Manifiesto gil, un documento que resume la
filosofa gil.
El Manifiesto gil
En marzo de 2001, diecisiete crticos de los modelos de mejora del

desarrollo de software basado en procesos, convocado por Kent Beck,
se reunieron en Salt Lake City para tratar sobre tcnicas y procesos para
desarrollar software. En la reunin se acu el trmino Mtodos
giles para definir a los mtodos que estaban surgiendo como
alternativa a las metodologas formales (CMMI, SPICE) a las que
consideraban excesivamente pesadas y rgidas por su carcter
normativo y fuerte dependencia de planificaciones detalladas previas al
desarrollo.
81 | P g i n a
Los integrantes de la reunin resumieron los principios sobre los que se
basan los mtodos alternativos en cuatro postulados, lo que ha quedado
denominado como Manifiesto gil.
Valores del Manifiesto gil
Segn el Manifiesto se valora:
Al individuo y las interacciones del equipo de desarrollo sobre el

proceso y las herramientas. La gente es el principal factor de xito
de un proyecto software. Es ms importante construir un buen equipo
que construir el entorno. Muchas veces se comete el error de
construir primero el entorno y esperar que el equipo se adapte
automticamente. Es mejor crear el equipo y que ste configure su
propio entorno de desarrollo en base a sus necesidades.
Desarrollar software que funciona ms que conseguir una buena

documentacin. La regla a seguir es no producir documentos a
menos que sean necesarios de forma inmediata para tomar una
decisin importante. Estos documentos deben ser cortos y centrarse
en lo fundamental.
La colaboracin con el cliente ms que la negociacin de un

contrato. Se propone que exista una interaccin constante entre el
cliente y el equipo de desarrollo. Esta colaboracin entre ambos ser
la que marque la marcha del proyecto y asegure su xito.
Responder a los cambios ms que seguir estrictamente un plan.

La habilidad de responder a los cambios que puedan surgir a lo largo
del proyecto (cambios en los requisitos, en la tecnologa, en el
equipo, etc.) determina tambin el xito o fracaso del mismo. Por lo
tanto, la planificacin no debe ser estricta sino flexible y abierta.
82 | P g i n a
Principios del Manifiesto gil
Los valores anteriores inspiran los doce principios del manifiesto. Son
caractersticas que diferencian un proceso gil de uno tradicional. Los
dos primeros principios son generales y resumen gran parte del espritu
gil. El resto tienen que ver con el proceso a seguir y con el equipo de
desarrollo, en cuanto metas a seguir y organizacin del mismo. Los
principios son:
1) La prioridad es satisfacer al cliente mediante tempranas y continuas

entregas de software que le aporte un valor.
2) Dar la bienvenida a los cambios. Se capturan los cambios para que

el cliente tenga una ventaja competitiva.
3) Entregar frecuentemente software que funcione desde un par de

semanas a un par de meses, con el menor intervalo de tiempo
posible entre entregas.
4) La gente del negocio y los desarrolladores deben trabajar juntos a lo

largo del proyecto.
5) Construir el proyecto en torno a individuos motivados. Darles el

entorno y el apoyo que necesitan y confiar en ellos para conseguir
finalizar el trabajo.
6) El dilogo cara a cara es el mtodo ms eficiente y efectivo para

comunicar informacin dentro de un equipo de desarrollo.
7) El software que funciona es la medida principal de progreso.
8) Los procesos giles promueven un desarrollo sostenible. Los

promotores, desarrolladores y usuarios deberan ser capaces de
mantener una paz constante.
83 | P g i n a
9) La atencin continua a la calidad tcnica y al buen diseo mejora la
agilidad.
10) La simplicidad es esencial.
11) Las mejores arquitecturas, requisitos y diseos surgen de los

equipos organizados por s mismos.
12) En intervalos regulares, el equipo reflexiona respecto a cmo llegar a

ser ms efectivo, y segn esto ajusta su comportamiento.
Comparaciones entre Metodologas
La Tabla 17 recoge esquemticamente las principales diferencias de las

metodologas giles con respecto a las tradicionales (no giles). Estas
diferencias que afectan no slo al proceso en s, sino tambin al
contexto del equipo as como a su organizacin.
Tabla 17. Diferencias entre metodologas giles y no giles. Fuente: Metodologas giles en el
Desarrollo de Software, Cans Jos, Universidad Politcnica de Valencia
84 | P g i n a
3.2.2. Metodologas Propuestas para el Proyecto de
Tesis
En esta presente tesis se analizarn tres metodologas giles y se

escoger la ms adecuada. Estas son: Rational Unified Process
(RUP), Extreme Programming (XP) y Feature Driven Development
(FDD).
A continuacin se describirn los posibles mtodos giles que se

utilizarn para el anlisis, diseo, desarrollo y posterior implementacin
de la solucin propuesta.
3.2.2.1. Rational Unified Process (RUP)

3.2.2.1.1. Historia
La Figura 22 ilustra la historia de RUP. El antecedente ms importante

se ubica en 1967 con la Metodologa Ericsson (Ericsson Approach)
elaborada por Ivar Jacobson, una aproximacin de desarrollo basada
en componentes, que introdujo el concepto de Caso de Uso. Entre los
aos de 1987 a 1995 Jacobson fund la compaa Objectory AB y lanza
el proceso de desarrollo Objectory (abreviacin de Object Factory).
Figura 22. Historia de RUP. Fuente: El Proceso Unificado de Desarrollo de Software, Addison Wesley,
2000
85 | P g i n a
Posteriormente en 1995, Rational Software Corporation adquiere
Objectory AB y entre 1995 y 1997 se desarrolla Rational Objectory
Process (ROP) a partir de Objectory 3.8 y del Enfoque Rational (Rational
Approach) adoptando UML como lenguaje de modelado.
Desde ese entonces y a la cabeza de Grady Booch, Ivar Jacobson y

James Rumbaugh, Rational Software desarroll e incorpor diversos
elementos para expandir ROP, destacndose especialmente el flujo de
trabajo conocido como modelado del negocio. En junio del 1998 se
lanza Rational Unified Process.
3.2.2.1.2. Caractersticas Esenciales
Los autores de RUP destacan que el proceso de software propuesto por

RUP tiene tres caractersticas esenciales: est dirigido por los Casos
de Uso, est centrado en la arquitectura, y es iterativo e incremental.
a) Proceso Dirigido por Casos de Uso
Los Casos de Uso son una tcnica de captura de requisitos que fuerza a
pensar en trminos de importancia para el usuario y no slo en trminos
de funciones que seria bueno contemplar. Se define un Caso de Uso
como un fragmento de funcionalidad del sistema que proporciona al
usuario un valor aadido. Los Casos de Uso representan los requisitos
funcionales del sistema.
En RUP los Casos de Uso no son slo una herramienta para especificar
los requisitos del sistema. Tambin guan su diseo, implementacin y
prueba. Los Casos de Uso constituyen un elemento integrador y una
gua del trabajo como se muestra en la Figura 23.
86 | P g i n a
Figura 23. Los Casos de Uso integran el trabajo. Fuente: El Proceso Unificado de Desarrollo de
Software, Addison Wesley, 2000
Los Casos de Uso no slo inician el proceso de desarrollo sino que

proporcionan un hilo conductor, permitiendo establecer trazabilidad entre
los artefactos que son generados en las diferentes actividades del
proceso de desarrollo.
Como se muestra en la Figura 24, basndose en los Casos de Uso se

crean los modelos de anlisis y diseo, luego la implementacin que los
lleva a cabo, y se verifica que efectivamente el producto implemente
adecuadamente cada Caso de Uso. Todos los modelos deben estar
sincronizados con el modelo de Casos de Uso.
Figura 24. Trazabilidad a partir de los Casos de Uso. Fuente: El Proceso Unificado de Desarrollo de
87 | P g i n a
b) Proceso Centrado en la Arquitectura
La arquitectura de un sistema es la organizacin o estructura de sus

partes ms relevantes, lo que permite tener una visin comn entre
todos los involucrados (desarrolladores y usuarios) y una perspectiva
clara del sistema completo, necesaria para controlar el desarrollo.
La arquitectura involucra los aspectos estticos y dinmicos ms

significativos del sistema, est relacionada con la toma de decisiones
que indican cmo tiene que ser construido el sistema y ayuda a
determinar en qu orden. Adems la definicin de la arquitectura debe
tomar en consideracin elementos de calidad del sistema, rendimiento,
reutilizacin y capacidad de evolucin por lo que debe ser flexible
durante todo el proceso de desarrollo. La arquitectura se ve influenciada
por la plataforma software, sistema operativo, gestor de bases de datos,
protocolos, consideraciones de desarrollo como sistemas heredados.
Muchas de estas restricciones constituyen requisitos no funcionales del
sistema.
En el caso de RUP adems de utilizar los Casos de Uso para guiar el

proceso se presta especial atencin al establecimiento temprano de una
buena arquitectura que no se vea fuertemente impactada ante cambios
posteriores durante la construccin y el mantenimiento.
Cada producto tiene tanto una funcin como una forma. La funcin
corresponde a la funcionalidad reflejada en los Casos de Uso y la forma
la proporciona la arquitectura. Existe una interaccin entre los Casos de
Uso y la arquitectura, los Casos de Uso deben encajar en la arquitectura
cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de
todos los Casos de Uso requeridos, actualmente y en el futuro. Esto
provoca que tanto arquitectura como Casos de Uso deban evolucionar
en paralelo durante todo el proceso de desarrollo de software.
88 | P g i n a
En la Figura 25 se ilustra la evolucin de la arquitectura durante las
fases de RUP. Se tiene una arquitectura ms robusta en las fases finales
del proyecto. En las fases iniciales lo que se hace es ir consolidando la
arquitectura por medio de baselines y se va modificando dependiendo de
las necesidades del proyecto.
Inicio Elaboracin Construccin Transicin
Arquitectura
Figura 25. Evolucin de la arquitectura del sistema. Fuente: El Proceso Unificado de Desarrollo de
Es conveniente ver el sistema desde diferentes perspectivas para

comprender mejor el diseo por lo que la arquitectura se representa
mediante varias vistas que se centran en aspectos concretos del
sistema, abstrayndose de los dems. Para RUP, todas las vistas juntas
forman el llamado modelo 4+1 de la arquitectura, el cual recibe este
nombre porque lo forman las vistas lgica, de implementacin, de
proceso y de despliegue, ms la de Casos de Uso que es la que da
cohesin a todas.
89 | P g i n a
Figura 26. Los modelos se completan, la arquitectura no cambia drsticamente. Fuente: El Proceso
Unificado de Desarrollo de Software, Addison Wesley, 2000
Al final de la fase de elaboracin se obtiene una baseline de la

arquitectura donde fueron seleccionados una serie de Casos de Uso
arquitectnicamente relevantes (aquellos que ayudan a mitigar los
riesgos ms importantes, aquellos que son los ms importantes para el
usuario y aquellos que cubran las funcionalidades significativas).
Como se observa en la Figura 26, durante la construccin los diversos

modelos van desarrollndose hasta completarse (segn se muestra con
las formas rellenas en la esquina superior derecha). La descripcin de la
arquitectura sin embargo, no debera cambiar significativamente (abajo a
la derecha) debido a que la mayor parte de la arquitectura se decidi
durante la elaboracin. Se incorporan pocos cambios a la arquitectura
(indicados con mayor densidad de puntos en la figura inferior derecha).
90 | P g i n a
c) Proceso Iterativo e Incremental
El equilibrio correcto entre los Casos de Uso y la arquitectura es algo

muy parecido al equilibrio de la forma y la funcin en el desarrollo del
producto, lo cual se consigue con el tiempo. Para esto, la estrategia que
se propone en RUP es tener un proceso iterativo e incremental en donde
el trabajo se divide en partes ms pequeas o mini proyectos.
Permitiendo que el equilibrio entre Casos de Uso y arquitectura se vaya
logrando durante cada mini proyecto, as durante todo el proceso de
desarrollo. Cada mini proyecto se puede ver como una iteracin (un
recorrido ms o menos completo a lo largo de todos los flujos de trabajo
fundamentales) del cual se obtiene un incremento que produce un
crecimiento en el producto.
Una iteracin puede realizarse por medio de una cascada como se

muestra en la Figura 27. Se pasa por los flujos fundamentales
(Requisitos, Anlisis, Diseo, Implementacin y Pruebas), tambin existe
una planificacin de la iteracin, un anlisis de la iteracin y algunas
actividades especficas de la iteracin. Al finalizar se realiza una
integracin de los resultados con lo obtenido de las iteraciones
anteriores.
Figura 27. Una iteracin RUP. Fuente: El Proceso Unificado de Desarrollo de Software, Addison
Wesley, 2000
91 | P g i n a
El proceso iterativo e incremental consta de una secuencia de
iteraciones. Cada iteracin aborda una parte de la funcionalidad total,
pasando por todos los flujos de trabajo relevantes y refinando la
arquitectura. Cada iteracin se analiza cuando termina. Se puede
determinar si han aparecido nuevos requisitos o han cambiado los
existentes, afectando a las iteraciones siguientes. Durante la
planificacin de los detalles de la siguiente iteracin, el equipo tambin
examina cmo afectarn los riesgos que an quedan al trabajo en curso.
Toda la retroalimentacin de la iteracin pasada permite reajustar los
objetivos para las siguientes iteraciones. Se contina con esta dinmica
hasta que se haya finalizado por completo con la versin actual del
producto.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan

varias iteraciones en nmero variable segn el proyecto y en las que se
hace un mayor o menor hincapi en los distintas actividades. En la
Figura 28 se muestra cmo vara el esfuerzo asociado a las disciplinas
segn la fase en la que se encuentre el proyecto RUP.
Figura 28. Esfuerzo en actividades segn fase del proyecto. Fuente: El Proceso Unificado de Desarrollo
de Software, Addison Wesley, 2000
92 | P g i n a
Las primeras iteraciones (en las fases de Inicio y Elaboracin) se
enfocan hacia la comprensin del problema y la tecnologa, la
delimitacin del mbito del proyecto, la eliminacin de los riesgos
crticos, y al establecimiento de una baseline de la arquitectura.
Durante la fase de inicio las iteraciones hacen ponen mayor nfasis en

actividades modelado del negocio y de requisitos.
En la fase de elaboracin, las iteraciones se orientan al desarrollo de la

baseline de la arquitectura, abarcan ms los flujos de trabajo de
requerimientos, modelo de negocios (refinamiento), anlisis, diseo y
una parte de implementacin orientado a la baseline de la arquitectura.
En la fase de construccin, se lleva a cabo la construccin del producto

por medio de una serie de iteraciones.
Para cada iteracin se selecciona algunos Casos de Uso, se refina su

anlisis y diseo y se procede a su implementacin y pruebas. Se realiza
una pequea cascada para cada ciclo. Se realizan tantas iteraciones
hasta que se termine la implementacin de la nueva versin del
producto.
En la fase de transicin se pretende garantizar que se tiene un producto

preparado para su entrega a la comunidad de usuarios.
Como se puede observar en cada fase participan todas las disciplinas,

pero que dependiendo de la fase el esfuerzo dedicado a una disciplina
vara.
3.2.2.1.3. Otras Prcticas
RUP identifica 6 best practices con las que define una forma efectiva de
trabajar para los equipos de desarrollo de software.
93 | P g i n a
1) Gestin de requisitos
RUP brinda una gua para encontrar, organizar, documentar, y

seguir los cambios de los requisitos funcionales y restricciones.
Utiliza una notacin de Caso de Uso y escenarios para representar
los requisitos.
2) Desarrollo de software iterativo
Desarrollo del producto mediante iteraciones con hitos bien

definidos, en las cuales se repiten las actividades pero con distinto
nfasis, segn la fase del proyecto.
3) Desarrollo basado en componentes
La creacin de sistemas intensivos en software requiere dividir el

sistema en componentes con interfaces bien definidas, que
posteriormente sern ensamblados para generar el sistema. Esta
caracterstica en un proceso de desarrollo permite que el sistema se
vaya creando a medida que se obtienen o se desarrollan sus
componentes.
4) Modelado visual (usando UML)
UML es un lenguaje para visualizar, especificar, construir y

documentar los artefactos de un sistema software. Es un estndar
de la OMG (http://www.omg.org). Utilizar herramientas de modelado
visual facilita la gestin de dichos modelos, permitiendo ocultar o
exponer detalles cuando sea necesario. El modelado visual tambin
ayuda a mantener la consistencia entre los artefactos del sistema:
requisitos, diseos e implementaciones. En resumen, el modelado
visual ayuda a mejorar la capacidad del equipo para gestionar la
complejidad del software.
5) Verificacin continua de la calidad
Es importante que la calidad de todos los artefactos se evale en

varios puntos durante el proceso de desarrollo, especialmente al
final de cada iteracin. En esta verificacin las pruebas juegan un
94 | P g i n a
papel fundamental y se integran a lo largo de todo el proceso. Para
todos los artefactos no ejecutables las revisiones e inspecciones
tambin deben ser continuas.
6) Gestin de los cambios
El cambio es un factor de riesgo crtico en los proyectos de software.

Los artefactos software cambian no slo debido a acciones de
mantenimiento posteriores a la entrega del producto, sino que
durante el proceso de desarrollo, especialmente importantes por su
posible impacto son los cambios en los requisitos. Por otra parte,
otro gran desafo que debe abordarse es la construccin de software
con la participacin de mltiples desarrolladores, posiblemente
distribuidos geogrficamente, trabajando a la vez en una release, y
quizs en distintas plataformas. La ausencia de disciplina
rpidamente conducira al caos. La Gestin de Cambios y de
Configuracin es la disciplina de RUP encargada de este aspecto.
3.2.2.1.4. Estructura del Proceso
El proceso puede ser descrito en dos dimensiones o ejes:
1) Eje Horizontal: Representa el tiempo y es considerado el eje de los

aspectos dinmicos del proceso. Indica las caractersticas del ciclo
de vida del proceso expresado en trminos de fases, iteraciones e
hitos. Se puede observar en la Figura 29 que RUP consta de cuatro
fases: Inicio, Elaboracin, Construccin y Transicin. Como se
mencion anteriormente cada fase se subdivide a la vez en
iteraciones.
2) Eje Vertical: Representa los aspectos estticos del proceso.

Describe el proceso en trminos de componentes de proceso,
disciplinas, flujos de trabajo, actividades, artefactos y roles.
95 | P g i n a
Figura 29. Estructura de RUP. Fuente: RUP. Mejores Prcticas para el Desarrollo de Software, Rational
Software Corporation, 1998
Estructura Dinmica del Proceso. Fases e iteraciones
RUP se repite a lo largo de una serie de ciclos que constituyen la vida de

un producto. Cada ciclo concluye con una generacin del producto para
los clientes. Cada ciclo consta de cuatro fases: Inicio, Elaboracin,
Construccin y Transicin. Cada fase se subdivide a la vez en
iteraciones, el nmero de iteraciones en cada fase es variable.
ciclodedesarrollo ciclodeevolucin
release baseline generacin

(productoal final de (releaseasociada (releasefinal de
unaiteracin) aunhito) unciclodedesarrollo)
Figura 30. Ciclos, releases, baseline. Fuente: RUP. Mejores Prcticas para el Desarrollo de Software,
Rational Software Corporation, 1998
96 | P g i n a
Cada fase se concluye con un hito bien definido, un punto en el tiempo
en el cual se deben tomar ciertas decisiones crticas y alcanzar las
metas clave antes de pasar a la siguiente fase, ese hito principal de cada
fase se compone de hitos menores que podran ser los criterios
aplicables a cada iteracin. Los hitos para cada una de las fases son:
Inicio - Lifecycle Objectives, Elaboracin - Lifecycle Architecture,
Construccin - Initial Operational Capability, Transicin - Product
Release. Las fases y sus respectivos hitos se ilustran en la Figura 31.
Inception Elaboration Construction Transition
Objetivos Arquitectura Capacidad Release

(Vision) Operacional del Producto
Inicial
tiempo
Figura 31. Fases e hitos en RUP. Fuente: RUP. Mejores Prcticas para el Desarrollo de Software,
Rational Software Corporation, 1998
La duracin y esfuerzo dedicado en cada fase es variable dependiendo

de las caractersticas del proyecto. Sin embargo, la Tabla 18 ilustra
porcentajes frecuentes al respecto. Consecuente con el esfuerzo
sealado, la Figura 32 ilustra una distribucin tpica de recursos
humanos necesarios a lo largo del proyecto.
Inicio Elaboracin Construccin Transicin
Esfuerzo 5% 20 % 65 % 10%
Tiempo
10 % 30 % 50 % 10%
Dedicado
Tabla 18. Distribuciones tpicas de esfuerzo y tiempo. Fuente: RUP. Mejores Prcticas para el
Desarrollo de Software, Rational Software Corporation, 1998
97 | P g i n a
Figura 32. Distribucin tpica de recursos humanos. Fuente: RUP. Mejores Prcticas para el Desarrollo
de Software, Rational Software Corporation, 1998
I. Inicio
Durante la fase de inicio se define el modelo del negocio y el alcance del

proyecto. Se identifican todos los actores y Casos de Uso, y se disean
los Casos de Uso ms esenciales (aproximadamente el 20% del modelo
completo). Se desarrolla, un plan de negocio para determinar que
recursos deben ser asignados al proyecto.
Los objetivos de esta fase son:
Establecer el mbito del proyecto y sus lmites.

Encontrar los Casos de Uso crticos del sistema, los escenarios
bsicos que definen la funcionalidad.
Mostrar al menos una arquitectura candidata para los escenarios
principales.
Estimar el coste en recursos y tiempo de todo el proyecto.
Estimar los riesgos, las fuentes de incertidumbre.
Los resultados de la fase de inicio deben ser:
Un documento de visin: Una visin general de los requerimientos

del proyecto, caractersticas clave y restricciones principales.
Modelo inicial de Casos de Uso (10-20% completado).
Un glosario inicial: Terminologa clave del dominio.
El caso de negocio.
98 | P g i n a
Lista de riesgos y plan de contingencia.
Plan del proyecto, mostrando fases e iteraciones.
Modelo de negocio, si es necesario.
Prototipos exploratorios para probar conceptos o la arquitectura
candidata.
Al terminar la fase de inicio se deben comprobar los criterios de

evaluacin para continuar:
Todos los interesados en el proyecto coinciden en la definicin del

mbito del sistema y las estimaciones de agenda.
Entendimiento de los requisitos, como evidencia de la fidelidad de los
Casos de Uso principales.
Las estimaciones de tiempo, coste y riesgo son crebles.
Comprensin total de cualquier prototipo de la arquitectura
desarrollado.
Los gastos hasta el momento se asemejan a los planeados.
Si el proyecto no pasa estos criterios hay que plantearse abandonarlo o

repensarlo profundamente.
II. Elaboracin
El propsito de la fase de elaboracin es analizar el dominio del

problema, establecer los cimientos de la arquitectura, desarrollar el plan
del proyecto y eliminar los mayores riesgos.
En esta fase se construye un prototipo de la arquitectura, que debe

evolucionar en iteraciones sucesivas hasta convertirse en el sistema
final. Este prototipo debe contener los Casos de Uso crticos
identificados en la fase de inicio. Tambin debe demostrarse que se han
evitado los riesgos ms graves.
Los objetivos de esta fase son:
99 | P g i n a
Definir, validar y cimentar la arquitectura.
Completar la visin.
Crear un plan fiable para la fase de construccin. Este plan puede
evolucionar en sucesivas iteraciones. Debe incluir los costes si
procede.
Demostrar que la arquitectura propuesta soportar la visin con un
coste razonable y en un tiempo razonable.
Al terminar deben obtenerse los siguientes resultados:
Un modelo de Casos de Uso completa al menos hasta el 80%: todos

los casos y actores identificados, la mayora de los casos
desarrollados.
Requisitos adicionales que capturan los requisitos no funcionales y
cualquier requisito no asociado con un Caso de Uso especfico.
Descripcin de la arquitectura software.
Un prototipo ejecutable de la arquitectura.
Lista de riesgos y caso de negocio revisados.
Plan de desarrollo para el proyecto.
Un caso de desarrollo actualizado que especifica el proceso a seguir.
Un manual de usuario preliminar (opcional).
En esta fase se debe tratar de abarcar todo el proyecto con la

profundidad mnima. Slo se profundiza en los puntos crticos de la
arquitectura o riesgos importantes.
En la fase de elaboracin se actualizan todos los productos de la fase de

inicio.
Los criterios de evaluacin de esta fase son los siguientes:
La visin del producto es estable.
100 | P g i n a
La arquitectura es estable.
Se ha demostrado mediante la ejecucin del prototipo que los
principales elementos de riesgo han sido abordados y resueltos.
El plan para la fase de construccin es detallado y preciso. Las
estimaciones son crebles.
Todos los interesados coinciden en que la visin actual ser
alcanzada si se siguen los planes actuales en el contexto de la
arquitectura actual.
Los gastos hasta ahora son aceptables, comparados con los
previstos.
Si no se superan los criterios de evaluacin quiz sea necesario

abandonar el proyecto o replanterselo considerablemente.
III. Construccin
La finalidad principal de esta fase es alcanzar la capacidad operacional

del producto de forma incremental a travs de las sucesivas iteraciones.
Durante esta fase todos los componentes, caractersticas y requisitos
deben ser implementados, integrados y probados en su totalidad,
obteniendo una versin aceptable del producto.
Los objetivos concretos incluyen:
Minimizar los costes de desarrollo mediante la optimizacin de

recursos y evitando el tener que rehacer un trabajo o incluso
desecharlo.
Conseguir una calidad adecuada tan rpido como sea prctico.
Conseguir versiones funcionales (alfa, beta, y otras versiones de
prueba) tan rpido como sea prctico.
Los resultados de la fase de construccin deben ser:
101 | P g i n a
Modelos Completos (Casos de Uso, Anlisis, Diseo, Despliegue e
Implementacin).
Arquitectura ntegra (mantenida y mnimamente actualizada).
Riesgos Presentados Mitigados.
Plan del Proyecto para la fase de Transicin.
Manual Inicial de Usuario (con suficiente detalle).
Prototipo Operacional beta.
Caso del Negocio Actualizado.
El producto es estable y maduro como para ser entregado a la

comunidad de usuario para ser probado.
Todos los usuarios expertos estn listos para la transicin en la
comunidad de usuarios.
Son aceptables los gastos actuales versus los gastos planeados.
IV. Transicin
La finalidad de la fase de transicin es poner el producto en manos de

los usuarios finales, para lo que se requiere desarrollar nuevas versiones
actualizadas del producto, completar la documentacin, entrenar al
usuario en el manejo del producto, y en general tareas relacionadas con
el ajuste, configuracin, instalacin y facilidad de uso del producto.
Se citan algunas de las cosas que puede incluir esta fase:
Prueba de la versin Beta para validar el nuevo sistema frente a las

expectativas de los usuarios.
Funcionamiento paralelo con los sistemas legados que estn siendo
sustituidos por nuestro proyecto.
Conversin de las bases de datos operacionales.
Entrenamiento de los usuarios y tcnicos de mantenimiento.
102 | P g i n a
Traspaso del producto a los equipos de marketing, distribucin y
venta.
Los principales objetivos de esta fase son:
Conseguir que el usuario se valga por si mismo.

Un producto final que cumpla los requisitos esperados, que funcione
y satisfaga suficientemente al usuario.
Los resultados de la fase de transicin son:
Prototipo Operacional.
Documentos Legales.
Caso del Negocio Completo.
Lnea de Base del Producto completa y corregida que incluye todos
los modelos del sistema.
Descripcin de la Arquitectura completa y corregida.
Las iteraciones de esta fase irn dirigidas normalmente a conseguir
una nueva versin.
El usuario se encuentra satisfecho.

Son aceptables los gastos actuales versus los gastos planificados.
Estructura Esttica del proceso. Roles, Actividades, Artefactos y

Flujos de Trabajo
Un proceso de desarrollo de software define quin hace qu, cmo y

cundo. RUP define cuatro elementos los roles, que responden a la
pregunta Quin?, las actividades que responden a la pregunta
Cmo?, los productos, que responden a la pregunta Qu? y los flujos
103 | P g i n a
de trabajo de las disciplinas que responde a la pregunta Cundo? (ver
Figura 33 y 34).
Figura 33. Relacin entre roles, actividades, artefactos. Fuente: RUP. Mejores Prcticas para el
Desarrollo de Software, Rational Software Corporation, 1998
Figura 34. Detalle de un workflow mediante roles, actividades y artefactos. Fuente: RUP. Mejores
Prcticas para el Desarrollo de Software, Rational Software Corporation, 1998
I. Roles
Un rol define el comportamiento y responsabilidades de un individuo, o

de un grupo de individuos trabajando juntos como un equipo. Una
104 | P g i n a
persona puede desempear diversos roles, as como un mismo rol
puede ser representado por varias personas.
Las responsabilidades de un rol son tanto el llevar a cabo un conjunto de

actividades como el ser el dueo de un conjunto de artefactos.
RUP define grupos de roles, agrupados por participacin en actividades

relacionadas. Estos grupos son:
Analistas:
Analista de procesos de negocio.
Diseador del negocio.
Analista de sistema.
Especificador de requisitos.
Desarrolladores:
Arquitecto de software.
Diseador.
Diseador de interfaz de usuario.
Diseador de cpsulas.
Diseador de base de datos.
Implementador.
Integrador.
Gestores:
Jefe de proyecto.
Jefe de control de cambios.
Jefe de configuracin.
Jefe de pruebas.
Jefe de despliegue.
Ingeniero de procesos.
Revisor de gestin del proyecto.
Gestor de pruebas.
105 | P g i n a
Apoyo:
Documentador tcnico.
Administrador de sistema.
Especialista en herramientas.
Desarrollador de cursos.
Artista grfico.
Especialista en pruebas:
Especialista en Pruebas (tester).
Analista de pruebas.
Diseador de pruebas.
Otros roles:
Stakeholders.
Revisor.
Coordinacin de revisiones.
Revisor tcnico.
Cualquier rol.
II. Actividades
Una actividad en concreto es una unidad de trabajo que una persona

que desempee un rol puede ser solicitado a que realice. Las
actividades tienen un objetivo concreto, normalmente expresado en
trminos de crear o actualizar algn producto.
III. Artefactos
Un producto o artefacto es un trozo de informacin que es producido,

modificado o usado durante el proceso de desarrollo de software. Los
productos son los resultados tangibles del proyecto, las cosas que va
creando y usando hasta obtener el producto final.
Un artefacto puede ser cualquiera de los siguientes:
106 | P g i n a
Un documento, como el documento de la arquitectura del software.
Un modelo, como el modelo de Casos de Uso o el modelo de diseo.
Un elemento del modelo, un elemento que pertenece a un modelo
como una clase, un Caso de Uso o un subsistema.
IV. Flujos de trabajo
Con la enumeracin de roles, actividades y artefactos no se define un

proceso, necesitamos contar con una secuencia de actividades
realizadas por los diferentes roles, as como la relacin entre los
mismos. Un flujo de trabajo es una relacin de actividades que nos
producen unos resultados observables. A continuacin se dar una
explicacin de cada flujo de trabajo.
a) Modelado del Negocio
Con este flujo de trabajo pretendemos llegar a un mejor entendimiento

de la organizacin donde se va a implantar el producto.
Los objetivos del modelado de negocio son:
Entender la estructura y la dinmica de la organizacin para la cual el

sistema va ser desarrollado (organizacin objetivo).
Entender el problema actual en la organizacin objetivo e identificar
potenciales mejoras.
Asegurar que clientes, usuarios finales y desarrolladores tengan un
entendimiento comn de la organizacin objetivo.
Derivar los requisitos del sistema necesarios para apoyar a la
organizacin objetivo.
Para lograr estos objetivos, el modelo de negocio describe como

desarrollar una visin de la nueva organizacin, basado en esta visin se
definen procesos, roles y responsabilidades de la organizacin por
medio de un modelo de Casos de Uso del negocio y un Modelo de
107 | P g i n a
Objetos del Negocio. Complementario a estos modelos, se desarrollan
otras especificaciones tales como un Glosario.
b) Requisitos
Este es uno de los flujos de trabajo ms importantes, porque en l se

establece qu tiene que hacer exactamente el sistema que
construyamos. En esta lnea los requisitos son el contrato que se debe
cumplir, de modo que los usuarios finales tienen que comprender y
aceptar los requisitos que especifiquemos.
Los objetivos del flujo de datos Requisitos son:
Establecer y mantener un acuerdo entre clientes y otros stakeholders

sobre lo que el sistema podra hacer.
Proveer a los desarrolladores un mejor entendimiento de los
requisitos del sistema.
Definir el mbito del sistema.
Proveer una base para la planeacin de los contenidos tcnicos de
las iteraciones.
Proveer una base para estimar costos y tiempo de desarrollo del
sistema.
Definir una interfaz de usuarios para el sistema, enfocada a las
necesidades y metas del usuario.
Los requisitos se dividen en dos grupos. Los requisitos funcionales

representan la funcionalidad del sistema. Se modelan mediante
diagramas de Casos de Uso. Los requisitos no funcionales representan
aquellos atributos que debe exhibir el sistema, pero que no son una
funcionalidad especfica. Por ejemplo requisitos de facilidad de uso,
fiabilidad, eficiencia, portabilidad, etc.
108 | P g i n a
Para capturar los requisitos es preciso entrevistar a todos los
interesados en el proyecto, no slo a los usuarios finales, y anotar todas
sus peticiones. A partir de ellas hay que descubrir lo que necesitan y
expresarlo en forma de requisitos.
En este flujo de trabajo, y como parte de los requisitos de facilidad de

uso, se disea la interfaz grfica de usuario. Para ello habitualmente se
construyen prototipos de la interfaz grfica de usuario que se contrastan
con el usuario final.
c) Anlisis y Diseo
El objetivo de este flujo de trabajo es traducir los requisitos a una

especificacin que describe cmo implementar el sistema.
Los objetivos del anlisis y diseo son:
Transformar los requisitos al diseo del futuro sistema.

Desarrollar una arquitectura para el sistema.
Adaptar el diseo para que sea consistente con el entorno de
implementacin, diseando para el rendimiento.
El anlisis consiste en obtener una visin del sistema que se preocupa

de ver qu hace, de modo que slo se interesa por los requisitos
funcionales. Por otro lado el diseo es un refinamiento del anlisis que
tiene en cuenta los requisitos no funcionales, en definitiva cmo cumple
el sistema sus objetivos.
Al principio de la fase de elaboracin hay que definir una arquitectura

candidata: crear un esquema inicial de la arquitectura del sistema,
identificar clases de anlisis y actualizar las realizaciones de los Casos
de Uso con las interacciones de las clases de anlisis. Durante la fase
de elaboracin se va refinando esta arquitectura hasta llegar a su forma
definitiva. En cada iteracin hay que analizar el comportamiento para
109 | P g i n a
disear componentes. Adems si el sistema usar una base de datos,
habr que disearla tambin, obteniendo un modelo de datos.
El resultado final ms importante de este flujo de trabajo ser el modelo

de diseo. Consiste en colaboraciones de clases, que pueden ser
agregadas en paquetes y subsistemas.
Otro producto importante de este flujo es la documentacin de la

arquitectura de software, que captura varias vistas arquitectnicas del
sistema.
d) Implementacin
En este flujo de trabajo se implementan las clases y objetos en ficheros

fuente, binarios, ejecutables y dems. Adems se deben hacer las
pruebas de unidad: cada implementador es responsable de probar las
unidades que produzca. El resultado final de este flujo de trabajo es un
sistema ejecutable.
En cada iteracin habr que hacer lo siguiente:
Planificar qu subsistemas deben ser implementados y en que orden

deben ser integrados, formando el Plan de Integracin.
Cada implementador decide en que orden implementa los elementos
del subsistema.
Si encuentra errores de diseo, los notifica.
Se prueban los subsistemas individualmente.
Se integra el sistema siguiendo el plan.
La estructura de todos los elementos implementados forma el modelo de

implementacin. La integracin debe ser incremental, es decir, en cada
momento slo se aade un elemento. De este modo es ms fcil
localizar fallos y los componentes se prueban ms a fondo. En fases
110 | P g i n a
tempranas del proceso se pueden implementar prototipos para reducir el
riesgo. Su utilidad puede ir desde ver si el sistema es viable desde el
principio, probar tecnologas o disear la interfaz de usuario. Los
prototipos pueden ser exploratorios (desechables) o evolutivos. Estos
ltimos llegan a transformarse en el sistema final.
e) Pruebas
Este flujo de trabajo es el encargado de evaluar la calidad del producto

que estamos desarrollando, pero no para aceptar o rechazar el producto
al final del proceso de desarrollo, sino que debe ir integrado en todo el
ciclo de vida.
Esta disciplina brinda soporte a las otras disciplinas. Sus objetivos son:
Encontrar y documentar defectos en la calidad del software.

Generalmente asesora sobre la calidad del software percibida.
Provee la validacin de los supuestos realizados en el diseo y
especificacin de requisitos por medio de demostraciones concretas.
Verificar las funciones del producto de software segn lo diseado.
Verificar que los requisitos tengan su apropiada implementacin.
Las actividades de este flujo comienzan pronto en el proyecto con el plan

de prueba (el cual contiene informacin sobre los objetivos generales y
especficos de las prueba en el proyecto, as como las estrategias y
recursos con que se dotar a esta tarea), o incluso antes con alguna
evaluacin durante la fase de inicio, y continuar durante todo el
proyecto.
El desarrollo del flujo de trabajo consistir en planificar que es lo que hay

que probar, disear cmo se va a hacer, implementar lo necesario para
llevarlos a cabo, ejecutarlos en los niveles necesarios y obtener los
111 | P g i n a
resultados, de forma que la informacin obtenida nos sirva para ir
refinando el producto a desarrollar.
f) Despliegue
El objetivo de este flujo de trabajo es producir con xito distribuciones

del producto y distribuirlo a los usuarios. Las actividades implicadas
incluyen:
Probar el producto en su entorno de ejecucin final.

Empaquetar el software para su distribucin.
Distribuir el software.
Instalar el software.
Proveer asistencia y ayuda a los usuarios.
Formar a los usuarios y al cuerpo de ventas.
Migrar el software existente o convertir bases de datos.
Este flujo de trabajo se desarrolla con mayor intensidad en la fase de

transicin, ya que el propsito del flujo es asegurar una aceptacin y
adaptacin sin complicaciones del software por parte de los usuarios. Su
ejecucin inicia en fases anteriores, para preparar el camino, sobre todo
con actividades de planificacin, en la elaboracin del manual de usuario
y tutoriales.
g) Gestin del proyecto
La Gestin del proyecto es el arte de lograr un balance al gestionar

objetivos, riesgos y restricciones para desarrollar un producto que sea
acorde a los requisitos de los clientes y los usuarios.
Los objetivos de este flujo de trabajo son:
112 | P g i n a
Proveer un marco de trabajo para la gestin de proyectos de software
intensivos.
Proveer guas prcticas realizar planeacin, contratar personal,
ejecutar y monitorear el proyecto.
Proveer un marco de trabajo para gestionar riesgos.
La planeacin de un proyecto posee dos niveles de abstraccin: un plan

para las fases y un plan para cada iteracin.
h) Configuracin y control de cambios
La finalidad de este flujo de trabajo es mantener la integridad de todos

los artefactos que se crean en el proceso, as como de mantener
informacin del proceso evolutivo que han seguido.
i) Entorno
La finalidad de este flujo de trabajo es dar soporte al proyecto con las

adecuadas herramientas, procesos y mtodos. Brinda una especificacin
de las herramientas que se van a necesitar en cada momento, as como
definir la instancia concreta del proceso que se va a seguir.
En concreto las responsabilidades de este flujo de trabajo incluyen:
Seleccin y adquisicin de herramientas

Establecer y configurar las herramientas para que se ajusten a la
organizacin.
Configuracin del proceso.
Mejora del proceso.
Servicios tcnicos.
El principal artefacto que se usa en este flujo de trabajo es el caso de

desarrollo que especifica para el proyecto actual en concreto, como se
113 | P g i n a
aplicar el proceso, que productos se van a utilizar y como van a ser
utilizados. Adems se tendrn que definir las guas para los distintos
aspectos del proceso, como pueden ser el modelado del negocio y los
Casos de Uso, para la interfaz de usuario, el diseo, la programacin, el
manual de usuario.
3.2.2.2. Extreme Programming (XP)
Metodologa gil basada en cuatro principios: simplicidad, comunicacin,

retroalimentacin y valor. Adems, orientada por pruebas y
refactorizacin, se disea e implementan las pruebas antes de
programar la funcionalidad, el programador crea sus propios tests de
unidad.
Este mtodo es tpicamente atribuido a Kent Beck, Ron Jeffries y Ward

Cinningham. El objetivo de XP son grupos pequeos y medianos de
construccin de software en donde los requisitos an son muy
ambiguos, cambian rpidamente o son de alto riesgo. XP busca la
satisfaccin del cliente tratando de mantener durante todo el tiempo su
confianza en el producto. Adems, sugiere que el lugar de trabajo sea
una sala amplia, si es posible sin divisiones (en el centro los
programadores, en la periferia los equipos individuales). Una ventaja
del espacio abierto es el incremento en la comunicacin y el
proporcionar una agenda dinmica en el entorno de cada proyecto.
3.2.2.2.1. Actividades de XP
1) Codificar
Es necesario codificar y plasmar nuestras ideas a travs del cdigo. En

programacin, el cdigo expresa la interpretacin del problema, as
podemos utilizar el cdigo para comunicar, para hacer comunes las
ideas, y por tanto para aprender y mejorar.
114 | P g i n a
2) Hacer Pruebas
Las caractersticas del software que no pueden ser demostradas

mediante pruebas simplemente no existen. Las pruebas dan la
oportunidad de saber si lo implementado es lo que en realidad se tena
en mente. Las pruebas nos indican que nuestro trabajo funciona, cuando
no podemos pensar en ninguna prueba que pudiese originar un fallo en
nuestro sistema, entonces habremos acabado por completo.
3) Escuchar
Hay en una frase, Los programadores no lo conocemos todo, y sobre

todo muchas cosas que las personas de negocios piensan que son
interesantes. Si ellos pudieran programarse su propio software para
qu nos querran?.
Si vamos a hacer pruebas tenemos que preguntar si lo obtenido es lo

deseado, y tenemos que preguntar a quien necesita la informacin.
Tenemos que escuchar a nuestros clientes cules son los problemas de
su negocio, debemos de tener una escucha activa explicando lo que es
fcil y difcil de obtener, y la realimentacin entre ambos nos ayudan a
todos a entender los problemas.
4) Disear
El diseo crea una estructura que organiza la lgica del sistema, un

buen diseo permite que el sistema crezca con cambios en un solo
lugar. Los diseos deben de ser sencillos, si alguna parte del sistema es
de desarrollo complejo, lo apropiado es dividirla en varias. Si hay fallos
en el diseo o malos diseos, estos deben de ser corregidos cuanto
antes.
Resumiendo las actividades de XP: Tenemos que codificar porque sin

cdigo no hay programas, tenemos que hacer pruebas por que sin
115 | P g i n a
pruebas no sabemos si hemos acabado de codificar, tenemos que
escuchar, porque si no escuchamos no sabemos que codificar ni probar,
y tenemos que disear para poder codificar, probar y escuchar
indefinidamente.
3.2.2.2.2. Practicas Bsicas de XP
De forma aislada, cualquier prctica individual de XP tiene poco sentido,

pero en conjunto, unas compensan las carencias que las otras puedan
tener.
Para evaluar XP hay que mirar la gran foto, es decir, todo el conjunto de
prcticas:
Figura 35. Practicas de XP. Fuente: Mtodos giles en Desarrollo de Software, Introduccin a la
Arquitectura de Software, Universidad de Buenos Aires Elaboracin Propia
1) El juego de la Planificacin - (Planning Game)
El alcance de la siguiente versin esta definido por las consideraciones

de negocios (prioridad de los mdulos, fechas de entrega) y
estimaciones tcnicas (estimaciones de funciones, consecuencias).
116 | P g i n a
El objetivo del juego es maximizar el valor del software producido, La
estrategia es poner en produccin las caractersticas ms importantes lo
antes posible, Las Piezas clave son las Story Cards, Los Jugadores son
los desarrolladores y el cliente y las Movidas son Exploracin, Seleccin
y Actualizacin.
2) Versiones Pequeas (Short Releases)
Un sistema simple se pone rpidamente en produccin. Peridicamente,

se producen nuevas versiones agregando en cada iteracin aquellas
funciones consideradas valiosas para el cliente
3) Metfora del Sistema (Metaphor)
Cada Proyecto es guiado por una historia simple de cmo funciona el

sistema en general, reemplaza a la arquitectura y debe estar en lenguaje
comn, entendible para todos (Cliente y Desarrolladores), esta puede
cambiar permanentemente.
4) Diseo Simple (Simple Designs)
El sistema se disea con la mxima simplicidad posible (YAGNY - No

vas a necesitarlo), Se plasma el diseo en tarjetas CRC (Clase
Responsabilidad - Colaboracin), no se implementan caractersticas que
no son necesarias, con esta tcnica, las clases descubiertas durante el
anlisis pueden ser filtradas para determinar qu clases son realmente
necesarias para el sistema.
5) Pruebas Continuas (Testing)
Los casos de prueba se escriben antes que el cdigo. Los

desarrolladores escriben pruebas unitarias y los clientes especifican
pruebas funcionales.
117 | P g i n a
6) Refactorizacin (Refactoring)
Es posible reestructurar el sistema sin cambiar su comportamiento, por

ejemplo eliminando cdigo duplicado, simplificando funciones,
Mejorando el cdigo constantemente, si el cdigo se esta volviendo
complicado se debera modificar el diseo y volver a uno ms simple.
Refactoring (Modificar la forma del cdigo sin cambiar su
funcionamiento).
7) Programacin por parejas (Pair Programming)
El cdigo es escrito por dos personas trabajando en el mismo

computador. Una sola maquina con un teclado y un mouse
8) Posesin Colectiva del Cdigo (Collective Code Ownership)
Nadie es dueo de un modulo. Cualquier programador puede cambiar

cualquier parte del sistema en cualquier momento, siempre se utilizan
estndares y se excluyen los comentarios, Los test siempre deben
funcionar al 100% para realizar integraciones con todo el cdigo
permanentemente.
9) Integracin continua (Continuous Integration)
Los cambios se integran en el cdigo base varias veces por da. Todos
lo casos de prueba se deben pasar antes y despus de la integracin, se
dispone de una maquina para la integracin y se realizan test
funcionales en donde participa el cliente.
10) Semana laboral de 40 horas (40-Hour Week)
Tambin llamado Paso Sostenible. Cada Trabajador trabaja no ms de

40 Horas por semana. Si fuera necesario hacer horas extra, esto no
debera hacerse dos semanas consecutivas. Sin hroes, esto hace que
se reduzca la rotacin del personal y mejora la calidad del producto.
118 | P g i n a
11) Cliente en el Sitio (On Site Customer)
El equipo de desarrollo tiene acceso todo el tiempo al cliente, el cual

esta disponible para responder preguntas, fijar prioridades, etc. Esto no
siempre se consigue; Un cliente muy Junior no sirve y un cliente muy
Snior no es disponible. Lo ideal es un cliente Analista.
12) Estndares de Codificacin (Coding Standard)
Todo el cdigo debe estar escrito de acuerdo a un estndar de

codificacin
3.2.2.2.3. Ciclo de Vida
El ciclo de vida de XP se enfatiza en el carcter interactivo e incremental

del desarrollo. Una iteracin de desarrollo es un perodo de tiempo en el
que se realiza un conjunto de funcionalidades determinadas que en el
caso de XP corresponden a un conjunto de historias de usuarios.
Las iteraciones son relativamente cortas ya que se piensa que entre ms

rpido se le entreguen desarrollos al cliente, ms retroalimentacin se va
a obtener y esto va a representar una mejor calidad del producto a largo
plazo. Existe una fase de anlisis inicial orientada a programar las
iteraciones de desarrollo y cada iteracin incluye diseo, codificacin y
pruebas, fases superpuestas de tal manera que no se separen en el
tiempo.
La siguiente figura muestra las fases en las que se subdivide el ciclo de

vida XP:
119 | P g i n a
Figura 36. Ciclo de vida de eXtreme Programming. Fuente: Modelo de Procesos, Calidad y
Mejoramiento. Proyecto SIMEP-SW. Hurtado, Julio y Bastiarrica Cecilia
A continuacin se van a describir cada una de las fases en las que se

subdivide el ciclo de vida de eXtreme Programming:
1) Fase de Exploracin
En esta fase, los clientes plantean a grandes rasgos las historias de

usuario que son de inters para la primera entrega del producto. Al
mismo tiempo el equipo de desarrollo se familiariza con las
herramientas, tecnologas y prcticas que se utilizarn en el proyecto.
Se prueba la tecnologa y se exploran las posibilidades de la arquitectura

del sistema construyendo un prototipo. La fase de exploracin toma de
pocas semanas a pocos meses, dependiendo del tamao y familiaridad
que tengan los programadores con la tecnologa.
2) Fase de Planeamiento
Se priorizan las historias de usuario y se acuerda el alcance del release.

Los programadores estiman cunto esfuerzo requiere cada historia y a
partir de all se define el cronograma. La duracin del cronograma del
primer release no excede normalmente dos meses. La fase de
120 | P g i n a
planeamiento toma un par de das. Se deben incluir varias iteraciones
para lograr un release. El cronograma fijado en la etapa de planeamiento
se realiza a un nmero de iteraciones, cada una toma de una a cuatro
semanas en ejecucin. La primera iteracin crea un sistema con la
arquitectura del sistema completo. Esto es alcanzado seleccionando las
historias que harn cumplir la construccin de la estructura para el
sistema completo. El cliente decide las historias que se seleccionarn
para cada iteracin. Las pruebas funcionales creadas por el cliente se
ejecutan al final de cada iteracin. Al final de la ltima iteracin el
sistema esta listo para produccin.
3) Fase de Produccin
Requiere prueba y comprobacin extra del funcionamiento del sistema

antes de que ste se pueda liberar al cliente. En esta fase, los nuevos
cambios pueden todava ser encontrados y debe tomarse la decisin de
si se incluyen o no en el release actual. Durante esta fase, las
iteraciones pueden ser aceleradas de una a tres semanas. Las ideas y
las sugerencias pospuestas se documentan para una puesta en prctica
posterior por ejemplo en la fase de mantenimiento. Despus de que se
realice el primer release productivo para uso del cliente, el proyecto de
XP debe mantener el funcionamiento del sistema mientras que realiza
nuevas iteraciones.
4) Fase de Mantenimiento
Requiere de un mayor esfuerzo para satisfacer tambin las tareas del

cliente. As, la velocidad del desarrollo puede desacelerar despus de
que el sistema est en la produccin. La fase de mantenimiento puede
requerir la incorporacin de nueva gente y cambiar la estructura del
equipo.
121 | P g i n a
5) Fase de Muerte
Es cuando el cliente no tiene ms historias para ser incluidas en el

sistema. Esto requiere que se satisfagan las necesidades del cliente en
otros aspectos como rendimiento y confiabilidad del sistema. Se genera
la documentacin final del sistema y no se realizan ms cambios en la
arquitectura. La muerte del proyecto tambin ocurre cuando el sistema
no genera los beneficios esperados por el cliente o cuando no hay
presupuesto para mantenerlo.
3.2.2.2.4. Actores y Responsabilidades de XP
Existen diferentes roles (actores) y responsabilidades en XP para

diferentes tareas y propsitos durante el proceso:
1) Programador (Programmer)
Responsable de decisiones tcnicas.

Responsable de construir el sistema.
Sin distincin entre analistas, diseadores o codificadores.
En XP, los programadores disean, programan y realizan las
pruebas.
2) Cliente (Customer)
Es parte del equipo.

Determina qu construir y cundo.
Escribe tests funcionales para determinar cundo est completo un
determinado aspecto.
3) Entrenador (Coach)
El lder del equipo - toma las decisiones importantes.

Principal responsable del proceso.
122 | P g i n a
Tiende a estar en un segundo plano a medida que el equipo madura.
4) Rastreador (Tracker)
Metric Man.
Observa sin molestar.
Conserva datos histricos.
5) Probador (Tester)
Ayuda al cliente con las pruebas funcionales.

Se asegura de que los tests funcionales se ejecutan.
3.2.2.2.5. Artefactos XP
A continuacin describimos los artefactos de XP, entre los que se

encuentran: Historias de Usuario, Tareas de Ingeniera y Tarjetas
CRC.
1) Historias de Usuario
Representan una breve descripcin del comportamiento del sistema,

emplea terminologa del cliente sin lenguaje tcnico, se realiza una por
cada caracterstica principal del sistema, se emplean para hacer
estimaciones de tiempo y para el plan de lanzamientos, reemplazan un
gran documento de requisitos y presiden la creacin de las pruebas de
aceptacin.
123 | P g i n a
Historia de Usuario
Nmero: Nombre Historia de Usuario:
Modificacin (o extensin) de Historia de Usuario (Nro. y Nombre):
Usuario: Iteracin Asignada:
Prioridad en Negocio:
Puntos Estimados:
(Alta / Media / Baja)
Riesgo en Desarrollo:
Puntos Reales:
(Alto / Medio / Bajo)
Descripcin:
Observaciones:
Tabla 19. Modelo propuesto para una historia de usuario. Fuente: Metodologas giles para el
Desarrollo de Software, Universidad Politcnica de Valencia
Estas deben proporcionar slo el detalle suficiente como para poder

hacer razonable la estimacin de cunto tiempo requiere la
implementacin de la historia, difiere de los casos de uso porque son
escritos por el cliente, no por los programadores, empleando
terminologa del cliente. Las historias de usuario son ms amigables
que los casos de uso formales.
Las Historias de Usuario tienen tres aspectos:
a) Tarjeta: En ella se almacena suficiente informacin para identificar y

detallar la historia.
124 | P g i n a
b) Conversacin: Cliente y programadores discuten la historia para
ampliar los detalles (verbalmente cuando sea posible, pero
documentada cuando se requiera confirmacin).
c) Pruebas de Aceptacin: Permite confirmar que la historia ha sido

implementada correctamente.
Caso de Prueba de Aceptacin

Cdigo: Historia de Usuario (Nro. y Nombre):
Nombre:
Descripcin:
Condiciones de Ejecucin:
Entrada / Pasos de ejecucin:
Resultado Esperado:
Evaluacin de la Prueba:
Tabla 20. Modelo propuesto para una prueba de aceptacin. Fuente: Metodologas giles para el
125 | P g i n a
2) Tareas de Ingeniera
Tarea de Ingeniera
Nmero Tarea: Historia de Usuario (Nro. y Nombre):
Nombre Tarea:
Tipo de Tarea :
Desarrollo / Correccin / Mejora / Otra Puntos Estimados:
(especificar)
Fecha Inicio: Fecha Fin:
Programador Responsable:
Descripcin:
Tabla 21. Modelo propuesto para una tarea de ingeniera. Fuente: Metodologas giles para el
3) Tarjetas CRC (Clase - Responsabilidad Colaborador)
Estas tarjetas se dividen en tres secciones que contienen la informacin

del nombre de la clase, sus responsabilidades y sus colaboradores. En
la siguiente figura se muestra cmo se distribuye esta informacin.
Tabla 22. Modelo de tarjeta CRC. Fuente: Mtodos giles en Desarrollo de Software, Introduccin a la
Arquitectura de Software, Universidad de Buenos Aires
126 | P g i n a
Una clase es cualquier persona, cosa, evento, concepto, pantalla o
reporte. Las responsabilidades de una clase son las cosas que conoce y
las que realizan, sus atributos y mtodos. Los colaboradores de una
clase son las dems clases con las que trabaja en conjunto para llevar a
cabo sus responsabilidades.
En la prctica conviene tener pequeas tarjetas de cartn, que se

llenarn y que son mostradas al cliente, de manera que se pueda llegar
a un acuerdo sobre la validez de las abstracciones propuestas.
Los pasos a seguir para llenar las tarjetas son los siguientes:
Encontrar clases.
Encontrar responsabilidades.
Definir colaboradores.
Disponer las tarjetas.
Para encontrar las clases debemos pensar qu cosas interactan con el

sistema (en nuestro caso el usuario), y qu cosas son parte del sistema,
as como las pantallas tiles a la aplicacin (un despliegue de datos, una
entrada de parmetros y una pantalla general, entre otros). Una vez que
las clases principales han sido encontradas se procede a buscar los
atributos y las responsabilidades, para esto se puede formular la
pregunta Qu sabe la clase? y Qu hace la clase? Finalmente se
buscan los colaboradores dentro de la lista de clases que se tenga.
3.2.2.2.6. Crticas a XP
Algunas de las crticas recopiladas de XP son:
XP tiene muchas crticas especialmente contra la programacin por

parejas por parte de muchos programadores con gran sentimiento de
posesin del cdigo, piensan que ellos son los mejores conocedores
127 | P g i n a
de las herramientas y lenguajes que utilizan y que si alguien no lo
entiende es por que no sabe lo suficiente.
Tambin se critica el mito de las 40 horas semanales ya que es un

lujo para las exigencias del mercado.
Tambin hay crticas hacia XP que dicen que solo puede funcionar
con programadores muy buenos, como Kent Beck, que son capaces
de hacer un buen diseo, sencillo y fcilmente extensible.
XP es mas una filosofa de trabajo que una metodologa. Por otro lado
ninguna de las practicas defendidas por XP son invencin de este
mtodo, XP lo que hace es ponerlas todas juntas.
XP esta diseado para grupos de pequeos programadores, ms de 10

ya seria muy complicado, y mas aun para que estn en el mismo centro
de trabajo.
3.2.2.3. Feature Driven Development (FDD)
El Desarrollo Manejado por Rasgos (FDD por sus siglas en ingls) es

un proceso diseado por Peter Coad, Erich Lefebvre y Jeff De Luca.
FDD es un mtodo gil, iterativo y adaptativo. Como las otras
metodologas adaptables, FDD se enfoca en iteraciones cortas que
entregan funcionalidad tangible. En el caso del FDD las iteraciones
duran dos semanas.
A diferencia de otros mtodos giles, FDD no cubre todo el ciclo de vida

sino slo las fases de diseo y construccin y se considera adecuado
para proyectos mayores y de misin critica. FDD es adems, marca
registrada de una empresa, Nebulon Pty.
128 | P g i n a
FDD no requiere un modelo especfico de proceso y se complementa
con otras metodologas. Enfatiza cuestiones de calidad y define
claramente entregas tangibles y formas de evaluacin del progreso.
Los principios de FDD son pocos y simples:
Se requiere un sistema para construir sistemas si se pretende escalar

a proyectos grandes.
Un proceso simple y bien definido trabaja mejor.
Los pasos de un proceso deben ser lgicos y su merito
inmediatamente obvio para cada miembro del equipo.
Vanagloriarse del proceso puede impedir el trabajo real.
Los buenos procesos van hasta el fondo del asunto, de modo que los
miembros del equipo se puedan concentrar en los resultados.
Los ciclos cortos, iterativos, orientados por rasgos (features) son
mejores.
3.2.2.3.1. Categoras de Roles
Hay tres categoras de roles en FDD que son: Roles Claves, Roles de
Soporte y Roles Adicionales.
a) Roles Claves: Los seis roles claves de un proyecto son:
1. Administrador del Proyecto: Quien tiene la ultima palabra en

materia de visin, cronograma y asignacin del personal.
2. Arquitecto Jefe: Puede dividirse en arquitecto de dominio y
arquitecto tcnico.
3. Manager de Desarrollo: Que puede combinarse con arquitecto
jefe o manager de proyecto.
4. Programador Jefe: Que participa en el anlisis del requerimiento
y selecciona rasgos del conjunto a desarrollar en la siguiente
iteracin.
129 | P g i n a
5. Propietarios de Clases: Que trabajan bajo la gua del
programador jefe en diseo, codificacin, prueba y
documentacin, repartidos por rasgos.
6. Experto de Dominio: Que puede ser un cliente, patrocinador,
analista de negocios o una mezcla de todo eso.
b) Roles de Soporte: Los cinco roles de soporte comprenden:
1. Administrador de Entrega: Que controla el progreso del proceso

revisando los reportes del programador jefe y manteniendo
reuniones breves con el; reporta al manager del proyecto.
2. Abogado/Guru de Lenguaje: Que conoce a la perfeccin el
lenguaje y la tecnologa.
3. Ingeniero de Construccin: Que se encarga del control de
versiones de los builds y publica la documentacin.
4. Herramentista (toolsmith): Que construye herramientas ad hoc
o mantiene bases de datos y sitios web.
5. Administrador del Sistema: Que controla el ambiente de trabajo
o productiza el sistema cuando se lo entrega.
c) Roles Adicionales: Los tres roles adicionales de un proyecto son:
1. Verificadores.
2. Encargados del Despliegue.
3. Escritores Tcnicos.
Un miembro de un equipo puede tener otros roles o cargos, y un solo rol

puede ser compartido por varias personas.
130 | P g i n a
Figura 37. Roles Principales de FDD. Fuente: Agile Software Development Methods, Universidad de
Oulu, Suecia, 2002
3.2.2.3.2. Procesos de FDD
1) Desarrollo de un modelo general
Cuando comienza este desarrollo, los expertos de dominio ya estn

al tanto de la visin, el contexto y los requerimientos del sistema a
construir. A esta altura se espera que existan requerimientos tales
como casos de uso o especificaciones funcionales. FDD, sin
embargo, no cubre este aspecto. Los expertos de dominio presentan
un ensayo (walkthrough) en el que los miembros del equipo y el
arquitecto principal se informan de la descripcin de alto nivel del
sistema. El dominio general se subdivide en reas mas especificas y
se define un ensayo mas detallado para cada uno de los miembros
del dominio. Luego de cada ensayo, un equipo de desarrollo trabaja
en pequeos grupos para producir modelos de objeto de cada rea
de dominio. Simultneamente, se construye un gran modelo general
para todo el sistema.
131 | P g i n a
2) Construccin de la lista de rasgos
Los ensayos, modelos de objeto y documentacin de requerimientos

proporcionan la base para construir una amplia lista de rasgos. Los
rasgos son pequeos tems tiles a los ojos del cliente. Son similares
a las tarjetas de historias de XP y se escriben en un lenguaje que
todas las partes puedan entender. Las funciones se agrupan
conforme a diversas actividades en reas de dominio especficas. La
lista de rasgos es revisada por los usuarios y patrocinadores para
asegurar su validez y exhaustividad. Los rasgos que requieran ms
de diez das se descomponen en otros ms pequeos.
3) Planeamiento por rasgo
Incluye la creacin de un plan de alto nivel, en el que los conjuntos

de rasgos se ponen en secuencia conforme a su prioridad y
dependencia, y se asigna a los programadores jefes. Las listas se
priorizan en secciones que se llaman paquetes de diseo. Luego se
asignan las clases definidas en la seleccin del modelo general a
programadores individuales, o sea propietarios de clases. Se pone
fecha para los conjuntos de rasgos.
4) Diseo por rasgo y Construccin por rasgo
Se selecciona un pequeo conjunto de rasgos del conjunto y los

propietarios de clases seleccionan los correspondientes equipos
dispuestos por rasgos. Se procede luego iterativamente hasta que se
producen los rasgos seleccionados. Una iteracin puede tomar de
unos das a un mximo de dos semanas. Puede haber varios grupos
trabajando en paralelo. El proceso iterativo incluye inspeccin de
diseo, codificacin, prueba de unidad, integracin e inspeccin de
cdigo. Luego de una iteracin exitosa, los rasgos completos se
promueven al build principal. Este proceso puede demorar una o dos
semanas en implementarse.
132 | P g i n a
Figura 38. Proceso FDD. Fuente: Agile Software Development Methods, Universidad de Oulu, Suecia,
2002
3.2.2.3.3. Practicas Cannicas
FDD consiste en un conjunto de mejores prcticas que distan de ser

nuevas pero se combinan de manera original. Las prcticas cannicas
son:
Modelado de objetos del dominio, resultante en un framework cuando

se agregan los rasgos. Esta forma de modelado descompone un
problema mayor en otros menores; el diseo y la implementacin de
cada clase u objeto es un problema pequeo a resolver. Cuando se
combinan las clases completas, constituyen la solucin al problema
mayor. Una forma particular de la tcnica es el modelado en colores,
que agrega una dimensin adicional de visualizacin. Si bien se
puede modelar en blanco y negro, en FDD el modelado basado en
objetos es imperativo.
Desarrollo por rasgo. Hacer simplemente que las clases y objetos

funcionen, no refleja lo que el cliente pide. El seguimiento del
progreso se realiza mediante examen de pequeas funcionalidades
descompuestas y funciones valoradas por el cliente.
133 | P g i n a
Propiedad individual de clases (cdigo). Cada clase tiene una sola
persona nominada como responsable por su consistencia,
performance e integridad conceptual.
Equipo de rasgos, pequeos y dinmicamente formados. La
existencia de un equipo garantiza que un conjunto de mentes se
apliquen a cada decisin y se tomen en cuenta mltiples alternativas.
Inspeccin. Se refiere al uso de los mejores mecanismos de

deteccin conocidos. FDD es tan escrupuloso en materia de
inspeccin como lo es el mtodo gil Evo.
Builds regulares. Siempre se tiene un sistema disponible. Los builds

forman la base a partir del cual se van agregando nuevos rasgos.
Administracin de configuracin. Permite realizar seguimiento

histrico de las ltimas versiones completas de cdigo fuente.
Reporte de progreso. Se comunica a todos los niveles

organizacionales necesarios.
Figura 39. Ciclo de FDD. Fuente: Agile Software Development Methods, Universidad de Oulu, Suecia,
2002
134 | P g i n a
3.2.2.3.4. Artefactos
FDD suministra un rico conjunto de artefactos para la planificacin y

control de los proyectos. En la pgina web de la empresa Nebulon, se
encuentran diversos formularios y tablas con informacin real de
implementaciones de FDD, como por ejemplo vistas de desarrollo, vistas
de planificacin, reportes de progreso, reportes de tendencia, vista de
plan, etc. Se han desarrollado tambin algunas herramientas que
generan vistas combinadas o especificas.
Tabla 23. Plan de rasgo Implementacin. Fuente: www.nebulon.com/articles/fdd/planview.html
La matriz muestra un ejemplo de vista de un plan de rasgo, con la tpica

codificacin en colores.
En sntesis, FDD es un mtodo de desarrollo de ciclos cortos que se

concentra en la fase de diseo y construccin. En la primera fase, el
modelo global de dominio es elaborado por expertos del dominio y
desarrolladores; el modelo de dominio consiste en diagramas de clases
con clases, relaciones, mtodos y atributos. Los mtodos no reflejan
conveniencias de programacin sino rasgos funcionales.
Algunos agilistas sienten que FDD es demasiado jerrquico para ser un

mtodo gil, porque demanda un programador jefe, quien dirige a los
135 | P g i n a
propietarios de clases, quienes dirigen equipos de rasgos. Otros crticos
sienten que la ausencia de procedimientos detallados de prueba en FDD
es llamativa e impropia. Los promotores del mtodo aducen que las
empresas ya tienen implementadas sus herramientas de prueba, pero
subsiste el problema de su adecuacin a FDD. Un rasgo llamativo de
FDD es que no exige la presencia del cliente.
FDD se utiliz por primera vez en grandes aplicaciones bancarias a fines

de la dcada de 1990. Los autores sugieren su uso para proyectos
nuevos o actualizaciones de sistemas existentes, y recomiendan
adoptarlo en forma gradual. Se asegura que aunque no hay evidencia
amplia que documente sus xitos, las grandes consultoras suelen
recomendarlo incluso para delicados proyectos de misin crtica.
3.2.3. Metodologa Elegida para el Proyecto de Tesis

Una vez que se ha estudiado las 03 metodologas propuestas (RUP, XP
y FDD), la metodologa elegida para el presente proyecto de tesis es
RUP (Rational Unified Process).
Una de las principales razones por la que escog RUP es porque ya

cuento con varios aos de experiencia utilizando esta metodologa, tanto
en proyectos que tuve en la Universidad as como en mi centro de
labores. Debido a esto, ya me encuentro muy familiarizado con este
marco de trabajo al igual que con el lenguaje unificado de modelado
(UML).
Tambin hubieron otras principales razones y criterios por el cual escog

dicha metodologa. A continuacin las voy a nombrar:
RUP esta dirigido por casos de uso. Ello facilita las tareas de diseo
y programacin.
La metodologa RUP reduce riesgos ya que su ciclo de vida es
iterativo.
136 | P g i n a
RUP utiliza un lenguaje de modelado visual comn como lo es UML.
Este lenguaje de modelado de sistemas de software es el mas
conocido y utilizado en la actualidad.
RUP posee un enfoque estructurado para realizar tareas y
responsabilidades en una organizacin de desarrollo.
Facilita la reutilizacin del cdigo teniendo en cuenta que se
realizan revisiones en las primeras iteraciones lo cual adems
permite que se aprecien oportunidades de mejoras en el diseo.
Es una metodologa muy organizativa.
RUP provee un fcil acceso a una base de conocimiento con guas,
plantillas y herramientas para todas las actividades crticas del
desarrollo de software.
3.3. Software o Sistemas Existentes

En el mercado actual existen una serie de aplicaciones y sistemas informticos
dedicados a la gestin del mantenimiento. A continuacin presentar 03
sistemas muy utilizados actualmente en el mercado mundial del mantenimiento.
3.3.1. Software TeReMa CMMS (Sistema de Gestin de

Mantenimiento Computarizado)
TeReMa es un completo Sistema de Gestin de Mantenimiento
Computarizado (CMMS por sus siglas en ingles). Fue desarrollado por
profesionales de mantenimiento altamente capacitados en los procesos
de la industria. Por lo tanto este software es muy prctico y
exclusivamente centrado en la gestin del mantenimiento.
El software puede ser adquirido con una versin para servidor o una
versin stand-alone para computadoras personales que utilizan
Windows.
TeReMa utiliza un men emergente para moverse entre los diferentes

mdulos. Est organizado en 10 diferentes mdulos. En el siguiente
grfico se muestran todos los mdulos que conforman TeReMa.
137 | P g i n a
Administrador Documentos
del Sistema
Historial Ordenes de
Trabajo
PLANTA
Reportes Mantenimiento
Preventivo
Compras Almacn
Figura 40. Mdulos del Software TeReMa. Fuente: Migalon AB - Elaboracin Propia
3.3.1.1. Principales Caractersticas
Entre sus principales caractersticas de TeReMa, tenemos las

siguientes:
Interfaz Grafica de Usuario
La interfaz grfica de TeReMa es completamente basada en Windows,

lo que ayuda al usuario a encontrar las funcionalidades fcilmente. La
funcin Administrador permite personalizar todas las pantallas
disponibles para cada usuario. Por lo tanto, un usuario Administrador
deber tener acceso a todas las funcionalidades de TeReMa, mientras
que otro tipo de usuario solo podr ver y tener acceso a algunas
funcionalidades.
138 | P g i n a
Figura 41. Modulo de Orden de Trabajo del Software TeReMa. Fuente: Migalon AB
Bsqueda de Informacin
Los datos almacenados en el software TeReMa son muy fciles de

encontrar, ordenar y usar para los reportes. Todos los campos son
enumerados en el generador de reportes. Muchos de estos datos estn
tambin disponibles para exportar a otras bases de datos como Excel y
Access. La funcin de programacin tiene un vnculo directo hacia
Microsoft Project.
139 | P g i n a
Figura 42. Generador de reportes del Software TeReMa. Fuente: Migalon AB
Para todas las Industrias
El Software TeReMa puede ser utilizado en casi todo tipo de industrias,

empresas y organizaciones existentes. Entre lo que se destaca, tenemos
los siguientes:
Industria de Alimentos.
Industria de la Energa.
Industria de los Procesos.
Industria de la Minera.
Industria de la Medicina.
Industria de la Ingeniera.
140 | P g i n a
Industria de los Servicios.
Gestin de la Propiedad.
Municipios.
Compatible con Handhelds y Cdigo de Barras
TeReMa tiene la opcin de usar computadoras de mano (Handhelds)

para rondas de inspeccin, pedidos de rdenes de trabajo y control de
almacenes. Si las computadoras de mano no son usadas en la
organizacin, se puede imprimir la lista o reporte en lugar de la
inspeccin. Los cdigos de barras y las etiquetas pueden ser impresos
directamente desde la funcin de etiquetado de TeReMa. Ejemplos
donde los cdigos de barra pueden ser usados:
Tiempo de trabajo por Orden de Trabajo.

Balances.
Inspecciones de Mantenimiento Preventivo y colecciones de datos.
Lubricacin.
Entrada de Datos Eficiente
TeReMa tiene una documentacin completa del Sistema de Gestin. Se

puede vincular documentos adjuntos como imgenes, hojas de Excel,
documentos Word y ms especficamente nmeros de equipos con sus
respectivas ubicaciones.
141 | P g i n a
Figura 43. Pantalla de Requerimiento de Trabajo del Software TeReMa. Fuente: Migalon AB
Soporte
El sistema de mantenimiento y soporte son proporcionados en su mayor

parte por va telefnica. El soporte on-site es disponible cuando sea
necesario. El soporte para la implementacin y los cursos de formacin
son normalmente dados en el local del cliente y siempre estn
dispuestos a satisfacer las necesidades individuales de cada cliente.
Fabricante
El fabricante del software es Migalon AB. Esta compaa trabaja en el

rea de la Gestin del Mantenimiento y cuentan con 25 aos de
experiencia en el mercado de la Gestin del Mantenimiento Industrial.
Ofrecen los siguientes servicios:
Sistemas Computarizados para la Gestin del Mantenimiento.

Cursos de Gestin del Mantenimiento.
142 | P g i n a
Servicios de Consultora en el campo de la Gestin del
Mantenimiento.
Pas
Este software fue desarrollado en Suecia.
Figura 44. Contacto del fabricante del Software TeReMa. Fuente: Migalon AB
Plataforma
El software opera bajo Windows 2000, 2003, XP y Vista.
3.3.1.2. Caractersticas importantes a tomar en cuenta
En este software TeReMa he encontrado algunas caractersticas

importantes que inclu en el sistema que estoy desarrollando. A
continuacin nombrar las ms importantes:
Practicidad y rapidez del sistema.

Presenta mdulos importantes para la gestin del mantenimiento
como por ejemplo: Historial, rdenes de Trabajo, Mantenimiento
Preventivo, Almacn y Reportes. Estos mdulos los tome muy en
cuenta para el sistema.
143 | P g i n a
Dispone de los perfiles de Administrador y Usuarios. El Administrador
tendr acceso a todas las funcionalidades del sistema. Los usuarios
solo podrn tener acceso a algunas funcionalidades.
Los reportes del sistema se pueden exportar como archivos (.xls y
.pdf).
Este sistema se puede utilizar en cualquier hospital o clnica del pas.
3.3.2. Software Bigfoot CMMS

Bigfoot CMMS es un potente software de mantenimiento para la
programacin, gestin, anlisis y presentacin de informes sobre todos
los aspectos del mantenimiento, incluido el mantenimiento preventivo,
rdenes de trabajo, solicitudes de mantenimiento, inventarios, cdigos
de barra y mantenimiento predictivo.
Bigfoot CMMS posee una pantalla simple, fcil de usar y de entender. Al

lado izquierdo de la pantalla principal se muestra una lista de las
opciones ms comunes que son necesarias en el control de los procesos
del mantenimiento.
Figura 45. Pantalla Principal del Software Bigfoot. Fuente: Smartware Group
144 | P g i n a
Entre sus principales caractersticas, tenemos las siguientes:
Bigfoot CMMS programa ilimitadamente tareas de mantenimiento

preventivo y los procedimientos con notificacin automtica.
Organiza, gestiona y realiza seguimientos a las rdenes de trabajo.
Seguimiento y anlisis de la informacin e historia del equipamiento.
Realiza solicitudes de mantenimiento desde cualquier lugar de la
Empresa.
Gestiona y realiza un seguimiento de inventarios de activos.
Analiza las cuestiones del historial del mantenimiento y ayuda a
predecir eventos futuros.
Usa el sistema de correo electrnico para notificar eventos de
mantenimiento.
Transfiere los datos actuales. La conversin de datos de un sistema
actual es generalmente posible.
Figura 46. Calendario de Mantenimiento Preventivo del Software Bigfoot. Fuente: Smartware Group
145 | P g i n a
Algunas Compaas que usan Bigfoot
Du Pont.
Fuji Film Processing.
Intel.
Kimberly-Clark.
Lear Corp.
Nike.
Sharp Electronics.
Sherwin-Williams.
Volkswagen.
Yahoo.
Figura 47. Compaas que usan el Software Bigfoot. Fuente: Smartware Group
Fabricante
El fabricante del software es Smartware Group.
Pais
Este software fue desarrollado en Estados Unidos.
Plataforma
El software opera bajo Windows 2000 o XP.
3.3.2.2. Principales Beneficios
Entre sus principales beneficios, tenemos los siguientes:
Minimiza los costos de reparacin y mantenimiento del equipamiento.

Reduce el tiempo de inactividad del equipamiento.
146 | P g i n a
Maximiza la fiabilidad del equipamiento.
Incrementa la eficiencia del equipamiento.
Prolonga el ciclo de vida del equipamiento.
Incrementa la productividad laboral.
Mejora el despliegue de activos y de personal.
Optimiza la eficiencia global del mantenimiento.
Figura 48. Gestin de las rdenes de Trabajo del Software Bigfoot. Fuente: Smartware Group
En este software Bigfoot he encontrado algunas caractersticas

Programacin ilimitada de tareas de mantenimiento preventivo de

equipamiento hospitalario.
Gestin, organizacin y seguimiento de las rdenes de trabajo y
equipamiento hospitalario.
Seguimiento y anlisis del registro histrico del equipamiento.
147 | P g i n a
Seguimiento y anlisis del inventario de equipos hospitalarios.
Posibilidad de solicitar ordenes de trabajo desde cualquier lugar del
Hospital.
3.3.3. Software AMPRO CMMS

El software de mantenimiento AMPRO es un excelente sistema que usa
una interfaz muy parecida a la de Microsoft Outlook. Al igual que
Outlook, las carpetas son mostradas en la columna izquierda de la
ventana principal. En el nivel superior de la pantalla principal se tienen
enlaces a todas las principales caractersticas de un sistema de gestin
de mantenimiento como recursos, inventarios, rdenes de compra,
requerimientos de trabajo, etc.
Uso de Mano
de Obra
Ahorro de Ahorro de
Costos Tiempo
AMPRO
Anlisis de Control de Piezas
Datos de Repuesto
Control
Presupuestario
Figura 49. Principales beneficios del software AMPRO. Fuente: Third City Solutions Pty Ltd -
Elaboracin Propia
Todas las funciones y mdulos de AMPRO estn disponibles en una

sola pantalla, como se muestra en el siguiente grafico:
148 | P g i n a
Figura 50. Pantalla principal del software AMPRO. Fuente: Third City Solutions Pty Ltd
Estilo de interfaz familiar al de Microsoft Outlook.

Los Mdulos estn perfectamente integrados entre si.
AMPRO muestra mensajes de alerta al pblico para que todos los
usuarios lo puedan ver.
Perfiles de usuario mviles. Se puede iniciar la sesin en AMPRO
utilizando el nombre de usuario en cualquier computadora y la
configuracin personal de AMPRO se restablecer.
Reportes y Grficos: Se podr crear reportes en Crystal Reports o en
Microsoft Access y ser vistos en AMPRO. Esto le da la capacidad de
exportar los reportes en diferentes formatos, incluidos PDF, Microsoft
Excel, Microsoft Word y texto. Cada usuario puede tener su propia
carpeta favorita para que frecuentemente ejecute reportes y grficos.
149 | P g i n a
Permisos de seguridad a nivel de usuario para los mdulos y
funciones.
Ayuda en lnea completa y fcil de entender y Gua de Usuario.
Fabricante
El fabricante del software es Third City Solutions Pty Ltd.
Pais
Este software fue desarrollado en Austrlia.
Plataforma
AMPRO es un software de mantenimiento Cliente/Servidor basado en

Microsoft Windows que utiliza metodologas para incrementar el
rendimiento y la eficiencia del sistema.
AMPRO est disponible con una seleccin de motores de base de datos

como Microsoft SQL Server 2000 Desktop Engine, un motor de datos
basada en el ncleo de la tecnologa SQL Server o Microsoft Access
2000/XP.
3.3.3.2. Mdulos Adicionales de AMPRO
Solicitudes de Trabajo
Las Solicitudes de Trabajo es un modulo adicional de AMPRO, que

permite a los departamentos de una compaa solicitar un trabajo
directamente desde AMPRO, donde el Departamento de Ingeniera o
Mantenimiento crear los trabajos si son necesarios.
150 | P g i n a
Figura 51. Detalles de una Solicitud de Trabajo del software AMPRO. Fuente: Third City Solutions
Pty Ltd
Las solicitudes de trabajo son rpidas y directas. Siga el estado de

todas las solicitudes de trabajo desde la misma interfaz.
Se pueden realizar notas o comentarios acerca de las solicitudes de
trabajo.
Es fcil de usar.
AMPRO PE (Edicin Portable)
AMPRO PE es una aplicacin que se ejecuta en un PDA (Asistente

Personal Digital) para realizar varias tareas referidas al mantenimiento
de activos.
AMPRO PE est formado por un numero de mdulos fciles de usar,

que se ejecutan sobre Windows Mobile y Palm OS basado en PDAs.
Los mdulos incluidos para esta versin son: Activos, inspecciones,
trabajos, inventarios y solicitudes de trabajo.
151 | P g i n a
Figura 52. Men Principal de AMPRO Portable Edition en una PDA. Fuente: Third City Solutions Pty Ltd
Figura 53. Detalles de una Solicitud de Trabajo de AMPRO PE. Fuente: Third City Solutions Pty Ltd
152 | P g i n a
Figura 54. Detalles de un Equipo Compresor de Aire. Fuente: Third City Solutions Pty Ltd

En este software AMPRO he encontrado algunas caractersticas
Integracin de todos los mdulos del sistema.

Muestra mensajes o avisos de mantenimiento preventivo para los
usuarios del sistema.
El registro de rdenes de trabajo es rpido y directo. Se puede
consultar el estado de reparacin o mantenimiento de las rdenes de
trabajo solicitadas.
Posibilidad de iniciar sesin en el sistema desde cualquier
computadora conectada a la red LAN del hospital.
Permisos de seguridad a nivel usuario para los mdulos y funciones.
153 | P g i n a
CAPITULO IV:
METODOLOGIA DE LA
INVESTIGACIN
154 | P g i n a
4.1. Tipo de Investigacin
La presente tesis es una Investigacin CUANTITATIVA, ya que se describe,
analiza o experimenta las variables de estudio.
De acuerdo al Tiempo de Ocurrencia, la investigacin ser RETROSPECTIVA,

debido a que se tomaron los registros de datos obtenidos de la seccin
Programacin y Control del Departamento de Ingeniera del HCFAP.
Segn el Anlisis y el Alcance de los resultados, la investigacin se realizar

a travs de un estudio DESCRIPTIVO, ya que se busca denotar caractersticas
importantes, resaltantes o diferentes del objeto de estudio, muestra o poblacin
observada.
4.2. Diseo de la Investigacin

El diseo que se utilizar en esta investigacin ser SIN INTERVENCIN, a
travs de un DISEO DE UN ESTUDIO DESCRIPTIVO. Se tendr en cuenta el
estudio de varias de las caractersticas de la variable estudiada.
4.3. Poblacin
La poblacin en estudio esta constituido por la totalidad de equipos hospitalarios
del Hospital Central de la Fuerza Aerea del Per. La cantidad de equipos a la
fecha asciende a 5019, entre equipos biomdicos, mdicos y
electromecnicos.
4.4. Muestra de Estudio

La muestra de estudio ser de 50 equipos hospitalarios.
4.5. Muestreo
Se aplicar el MUESTREO PROBABILSTICO evaluando aproximadamente al
50% del equipamiento hospitalario.
155 | P g i n a
4.6. Criterios de Seleccin
Equipos hospitalarios biomdicos de ltima generacin y de alto costo.
4.7. Tcnicas e Instrumentos de Recoleccin de Datos

4.7.1. Tcnicas de Recoleccin de Datos
La recoleccin de datos es la tcnica mediante la cual se obtienen los
datos necesarios para elaborar la informacin requerida, que me permita
conocer la realidad que pretendo investigar, evaluar, medir y predecir.
Para ello, seleccionar algunos de los instrumentos de medicin

confiables y vlidos que me permitan conocer y medir la realidad que
pretendo investigar. Luego aplicar el instrumento elegido, controlando
todas las condiciones que me permitan recoger informacin con el
mnimo de errores de medicin.
En el proceso de recoleccin de datos del presente trabajo de

investigacin, se aplicarn algunas de las siguientes tcnicas:
4.7.1.1. Encuesta
Es una tcnica que permite obtener informacin de una muestra

representativa de una determinada poblacin. Es un proceso a travs del
cual se consiguen datos de primera mano y todos aquellos que permitan
explicar mejor el problema.
La forma de obtener informacin mediante la encuesta ser a travs de

los Cuestionarios.
Para este trabajo de investigacin no se utilizar esta tcnica, debido a

que esta no aplica para el desarrollo del proyecto.
156 | P g i n a
4.7.1.2. Entrevista
Es la comunicacin interpersonal establecida entre el investigador y el

sujeto de estudio a fin de obtener las respuestas verbales a las
interrogantes planteadas sobre el problema propuesto.
Existen dos tipos de entrevistas, una entrevista de tipo Estructurada y

otra de tipo no Estructurada. Para este trabajo de investigacin se
utiliz la entrevista de tipo no estructurada.
Las entrevistas se realizaron a los usuarios del Departamento de

Ingeniera as como el personal que labora en las diferentes secciones
y departamentos del Hospital.
Los instrumentos que se requieren para una entrevista son:

Cuestionarios para las entrevistas estructuradas y Guas para las
entrevistas no estructuradas. Para este trabajo de investigacin se utiliz
guas, aunque en la mayora de las entrevistas no fue necesario.
4.7.1.3. Observacin
Es el registro visual de lo que ocurre en una situacin real, clasificando y
consignando los acontecimientos pertinentes de acuerdo con algn
esquema previsto y segn el problema que se estudia.
El tipo de observacin que se utiliz en este trabajo de investigacin es

el de la Observacin Participante, debido a que en el momento del
proceso de observacin se interactu con los sujetos observados, en
muchos casos con el personal que labora en el Departamento de
Ingeniera del Hospital Central FAP.
4.7.2. Instrumentos o Equipo Auxiliar a Utilizar

Los instrumentos o equipo auxiliar a utilizar se clasifican segn las
tcnicas de recoleccin de datos. En la siguiente tabla se especifican las
tcnicas de recoleccin de datos as como los instrumentos a utilizar.
157 | P g i n a
Tcnicas de Recoleccin
Instrumentos
de Datos
Encuesta Cuestionarios
Cuestionarios
Entrevista
Guas
Listas de Chequeo
Observacin
Escalas de Puntuacin
Tabla 24. Tcnicas de Recoleccin de Datos con sus respectivos Instrumentos. Fuente: Elaboracin
Propia
En cuanto al trabajo de investigacin de tesis, solo se utilizaron las

guas como instrumento para las entrevistas realizadas.
4.7.3. Procesamiento y Presentacin de Datos

El procesamiento de datos obedecer a identificar mediante las
tcnicas utilizadas los campos a usar.
La aplicacin del instrumento de medicin va a producir un conjunto

de datos (base de datos); pero, tal como son recolectados (datos
crudos) sern poco informativos y difcilmente interpretables.
Entonces, antes de reportar los resultados del estudio se necesitarn
organizarlos usando las tcnicas estadsticas. Esta etapa es
importante porque va a dar una visin de las caractersticas
generales del conjunto de observaciones.
Se recolectarn tambin grficos y cuadros estadsticos del Hospital

FAP as como del Departamento de Ingeniera, lo cual facilitar la
identificacin de indicadores.
158 | P g i n a
CAPITULO V:
CONTRIBUCIN
159 | P g i n a
5.1. Estudio de Factibilidad
La Factibilidad se refiere a la disponibilidad de los recursos necesarios para
llevar a cabo los objetivos o metas sealados. La factibilidad se apoya en 3
aspectos bsicos, y estos son:
Operativo.
Tcnico.
Econmico.
El xito de un proyecto est determinado por el grado de factibilidad que se

presente en cada una de los tres aspectos anteriores.
El Estudio de Factibilidad sirve para recopilar datos relevantes sobre el

desarrollo de un proyecto y en base a ello tomar la mejor decisin, si procede su
estudio, desarrollo o implementacin.
A continuacin se desarrollar el anlisis y estudio de factibilidad

correspondiente a este trabajo de investigacin.
5.1.1. Factibilidad Operativa

La Factibilidad Operativa se refiere a todos aquellos recursos donde
interviene algn tipo de actividad (Procesos), depende de los recursos
humanos que participen durante la operacin del proyecto. Durante esta
etapa se identifican todas aquellas actividades que son necesarias para
lograr el objetivo y se evala y determina todo lo necesario para llevarla
a cabo.
El proyecto propuesto es asequible de ser respaldado por los

beneficios que se obtendran como consecuencia de su implementacin.
Pero podra generarse inquietud entre los usuarios que lo utilizaran por
ser algo completamente nuevo, por ello es importante la capacitacin
de los usuarios que serian concurrentes con el sistema y capturar todas
las sugerencias que estos puedan hacer con referente al mismo.
160 | P g i n a
Asimismo, se deber contratar a una persona con conocimientos en
informtica y sistemas que le permita administrar el sistema y realizar el
mantenimiento de las bases de datos entre otras cosas; adems de
habilitar un rea en donde se colocar el servidor que tendr los
requerimientos de Hardware y en donde el usuario realizar sus tareas
diariamente, junto al personal de soporte.
Sobre el personal, se considerar que tengan los siguientes atributos:
Capacidad de anlisis y experiencia en aplicaciones

Capacidad de programacin
Experiencia en lenguajes y herramientas de software.
5.1.2. Factibilidad Tcnica

La Factibilidad Tcnica se refiere a los recursos necesarios como
herramientas (software y hardware), conocimientos, habilidades,
experiencia, etc., que son necesarios para efectuar las actividades o
procesos que requiere el proyecto. Generalmente se refiere a elementos
tangibles (medibles). El proyecto de tesis debe considerar si los recursos
tcnicos actuales son suficientes o deben complementarse.
Requerimientos de Software
Anlisis de Requerimientos:
o Requisite Pro.
Anlisis y Diseo del Sistema:

o Rational Rose Enterprise Edition (modelado del sistema).
o Platinum Erwin (modelado de la base de datos).
o SQL Navigator 4.3 (modelado y consulta de la base de datos).
Desarrollo:
o Oracle Forms Developer 6i (desarrollo del sistema).
161 | P g i n a
Lenguaje de Programacin:
o PL/SQL.
Base de Datos:
o Oracle Database Enterprise Edition 10g.
Cronograma de Actividades:
o Microsoft Project 2007.
Documentacin del Proyecto:

o Microsoft Office 2007 (Word, Excel, Power Point, Visio).
Plataforma o Sistema Operativo:

o Windows 2003 o superior (Servidor), Windows XP o superior
(Usuarios).
Requerimientos de Hardware
Computadora Personal
o Procesador : Pentium IV de 2.53 Ghz.
o Memoria RAM : DDR de 512 Mb. (Recomendada de 1 Gb.)
o Disco Duro : 80 Gb.
o Monitor : LCD de 15, con una resolucin mnima de
800x600 pixeles (Recomendada de 1024x768
pixeles).
Impresora
o Impresora tipo Matricial marca Epson, modelo FX-1180.
Servidor de Aplicaciones
o Procesador : 2.8 Ghz. como mnimo
o Memoria RAM : 4 Gb. como mnimo
o Disco Duro : 160 Gb. mnimo
o Tarjeta de Red : 10/100 Mbps
162 | P g i n a
NOTA:
Debido a que se requiere un Servidor de Aplicaciones donde se va a

alojar el aplicativo, es necesario contar con un servidor redundante o
espejo, caso contrario se requiere que los componentes principales del
hardware del servidor sean redundantes.
5.1.3. Factibilidad Econmica
La estimacin de esfuerzo y la justificacin econmica de este

proyecto de software se harn utilizando las tcnicas de Puntos de
Caso de Uso y COSYSMO (Constructive Systems Engineering Cost
Model) respectivamente. La factibilidad econmica estar orientada al
nivel intermedio y en modo orgnico dadas las caractersticas del
proyecto.
5.1.3.1. Puntos de Caso de Uso
Es un mtodo de estimacin de esfuerzo de un proyecto de desarrollo

de software a partir de los casos de uso.
El mtodo utiliza los actores y casos de uso identificados para calcular el

esfuerzo que costar desarrollarlos. A los casos de uso se les asigna
una complejidad basada en transacciones, que son pares de pasos
accin-usuario -> respuesta-sistema de los escenarios de los casos de
uso. A los actores se les asigna una complejidad basada en el tipo de
actor, es decir, si son interfaces con usuarios o si son interfaces con
otros sistemas (api o protocolo). Tambin se utilizan factores de entorno
y de complejidad tcnica para afinar el resultado.
Una vez asignada complejidad a actores y casos de uso y establecidos

los factores tcnicos y de entorno, se calculan los puntos de caso de uso
no ajustados o UUCP, el TCF (factor de complejidad tcnica) y el EF
(factor del entorno). Con ellos, se calculan los puntos de caso de uso o
163 | P g i n a
UCP, que finalmente se traducen a esfuerzo en horas-hombre con un
sencillo clculo.
5.1.3.1.1. Factor de Peso de los Actores sin Ajustar (UAW)
Consiste en la evaluacin de la complejidad de los actores con los que

tendr que interactuar el sistema. Este puntaje se calcula determinando
si cada actor es una persona u otro sistema, adems evala la forma en
la que este interacta con el caso de uso, y la cantidad de actores de
cada tipo.
Tipo de Actor Cdigo Descripcin Factor

Otro sistema que interacta con el sistema a desarrollar
Simple S mediante una interfaz de programacin (API, Application 1
Programming Interface)
Otro sistema que interacta con el sistema a desarrollar
Medio M 2
mediante un protocolo o una interfaz basada en texto
Una persona que interacta con el sistema mediante

Complejo C 3
una interfaz grfica
Tabla 25. Peso de los Actores sin ajustar. Fuente: Elaboracin Propia
Nombre del Actor Identificacin

Solicitante C
Tcnico Especialista C
Jefe de Departamento C
Jefe Seccin Electrnica C
Jefe Seccin Electromecnica C
Jefe Seccin Instalaciones C
Administrador del Sistema C
Tabla 26. Identificacin de los Actores del Sistema. Fuente: Elaboracin Propia
La frmula sera:
UAW = Suma (cantidadDeUnTipoDeActor * Factor)
Para realizar esta operacin sera necesario contar cuntos actores de

cada tipo existen en el sistema, este representara el valor
164 | P g i n a
cantidadDeUnTipoDeActor en la frmula y se tiene que multiplicar por
el valor que tenga su factor correspondiente, para obtener el resultado
por cada tipo de actor. Una vez terminado esto se procede a sumar cada
producto para obtener el UAW.
Para este sistema de software, el Factor de Peso de los Actores sin

Ajustar (UAW) sera el siguiente:
UAW = (0x1) + (0x2) + (7x3)
UAW = 21
5.1.3.1.2. Factor de Peso de los Casos de Uso sin ajustar (UUCW)
Este punto funciona muy similar al anterior, pero para determinar el nivel
de complejidad se puede realizar mediante dos mtodos: basado en
transacciones o basado en clases de anlisis. Para este proyecto de
desarrollo de software se usar el mtodo basado en transacciones.
La complejidad de los Casos de Uso se establece teniendo en cuenta la

cantidad de transacciones efectuadas en el mismo. Se toma en cuenta el
nmero de transacciones que se pueden realizar en un caso de uso y lo
evala segn la siguiente tabla:
Tipo de Caso de Uso Cdigo Descripcin

Simple S El Caso de Uso contiene de 1 a 3 transacciones
Medio M El Caso de Uso contiene de 4 a 7 transacciones
Complejo C El Caso de Uso contiene ms de 8 transacciones
Tabla 27. Peso de las Transacciones. Fuente: Elaboracin Propia
A continuacin se identificarn todos los casos de uso del sistema segn

el nmero de transacciones que tuviera; ya sean simples, medias o
complejas.
165 | P g i n a
Nombre del Caso de Uso Identificacin
Administrar Departamento y Seccin M
Administrar Divisin M
Administrar Estado de Funcionamiento S
Administrar Ficha Tcnica C
Administrar Grupo Equipamiento Hospitalario S
Administrar Opciones S
Administrar Perfil S
Administrar Personal por Divisin M
Administrar Privilegios M
Administrar Programacin de Mantenimiento C
Administrar Proveedor S
Administrar Tarea de Mantenimiento C
Administrar Usuario M
Aprobar Termino de Orden de Trabajo S
Asignar Responsable de Tarea S
Asignar Tarea de Mantenimiento S
Cerrar Orden de Trabajo S
Consultar Aviso de Mantenimiento S
Consultar Estado de Reparacin S
Consultar Historial de Equipos S
Consultar Inventario de Equipos S
Consultar Ordenes de Trabajo Delegadas S
Consultar Ordenes de Trabajo Solicitadas S
Delegar Orden de Trabajo S
Imprimir Orden de Trabajo S
Iniciar Sesin S
Registrar Actividades de Mantenimiento S
Registrar Detalle Estado de Funcionamiento M
Registrar Equipamiento Hospitalario M
Registrar Informe Tcnico M
Registrar Repuestos, Accesorios y Materiales M
Registrar Termino de Orden de Trabajo C
Seleccionar Equipo Hospitalario S
Solicitar Orden de Trabajo M
Tabla 28. Identificacin de los Casos de Uso del Sistema. Fuente: Elaboracin Propia
La formula sera:
UUCW = Suma (CantidadDeUnTipoDeCasoUso * Factor)
Para realizar esta operacin se debe contar cuntos casos de uso de

cada tipo hay en el sistema y esta cantidad se sustituira en el campo
nombrado como CantidadDeUnTipoDeCasoUso y se multiplica por el
valor que tenga su factor correspondiente, para obtener el resultado por
166 | P g i n a
cada tipo de caso de uso. Una vez hecho esto se suma cada producto
para obtener el factor de peso de los casos de uso sin ajustar (UUCW).
UUCW = (20x5) + (10x10) + (4x15)
UUCW = 260
5.1.3.1.3. Calculo de los Casos de Uso Desajustados (UUCP)
El calculo de los Casos de Uso Desajustados (UUCP) esta dado por la

suma de los valores del Factor de Peso de los Actores sin Ajustar (UAW)
mas el Factor de Peso de los Casos de Uso sin ajustar (UUCW).
Cuenta Factor de ponderacin

PUNTOS
ELEMENTOS DE INFORMACIN SIMPLE MEDIO COMPLEJO SIMPLE MEDIO COMPLEJO
De actores - - 7 1 2 3 21
De casos de uso 20 10 4 5 10 15 260
Casos de Uso Desajustados 281
Tabla 29. Calculo de los Casos de Uso Desajustados. Fuente: Elaboracin Propia
UUCP = UAW + UUCW

UUCP = 21 + 260
UUCP = 281
5.1.3.1.4. Factor de Complejidad Tcnica (TCF)
Este se compone de 13 puntos que evalan la complejidad de los

mdulos del sistema que se desarrolla, cada uno de estos factores
tienen un peso definido con los cuales se obtendr puntos ponderados
por cada uno de ellos, segn la valoracin que se le asigne. Para una
mejor comprensin, a continuacin se mostrar una tabla con los tems:
167 | P g i n a
Relevancia
Factor Nombre del factor Peso (0 irrelevante,..., Producto
5 esencial)
1. Sistema distribuido 2 4 8
2. Objetivos de performance o tiempo de respuesta 1 5 5
3. Eficiencia del usuario final 1 5 5
4. Procesamiento interno complejo 1 3 3
5. Cdigo debe ser reutilizable 1 5 5
6. Facilidad de instalacin 0.5 2 1
7. Facilidad de uso 0.5 4 2
8. Portabilidad 2 3 6
9. Facilidad de cambio 1 4 4
10. Concurrencia 1 4 4
11. Incluye caractersticas especiales de seguridad 1 4 4
12. Proporciona acceso directo a terceras partes 1 3 3
13. Requiere facilidades de entrenamiento especial a usuario 1 4 4
TCF 1.14
Tabla 30. Calculo del Factor de Complejidad Tcnica. Fuente: Elaboracin Propia
5.1.3.1.5. Factor de Ambiente (EF)
Los Factores de Ambiente sobre los cuales se realiza la evaluacin son

8 puntos, que estn relacionados con las habilidades y experiencia del
grupo de personas involucradas con el desarrollo del proyecto. Estos
factores se muestran a continuacin:
Factor
Nivel
Ambiental
Del 1 al 4 0: No experiencia 5: Experto
5 0: No motivacin por el proyecto. 5: Alta motivacin
6 0: Requerimientos extremadamente inestables. 5: Requerimientos estables.
7 0: Nadie del staff tcnico a tiempo parcial. 5: Todo el staff tcnico a tiempo parcial.
8 0: Lenguaje de programacin de fcil uso. 5: Lenguaje de programacin de mucha dificultad.
Tabla 31. Tabla de Niveles y Factores Ambientales. Fuente: Elaboracin Propia
Con los valores anteriormente descritos, se calcula el Factor de

Ambiente, multiplicando el peso de cada punto por el valor asignado,
despus se multiplica por -0.03 y se le suma el 1.4. As, se obtiene el
peso de los factores ambientales (EF).
168 | P g i n a
Nivel
Factor Descripcin del factor Peso Producto
(ver tabla)
1. Familiaridad con la metodologa RUP 1.5 5 7.5
2. Experiencia en la aplicacin 0.5 5 2.5
3. Experiencia en Orientacin a Objetos 1 4 4
4. Capacidad del analista lder 0.5 5 2.5
5. Motivacin 1 5 5
6. Estabilidad de los Requerimientos 2 3 6
7. Trabajadores a tiempo parcial. -1 4 -4
8. Dificultad con el lenguaje de programacin -1 1 -1
EF 0.725
Tabla 32. Calculo del Factor de Ambiente. Fuente: Elaboracin Propia
5.1.3.1.6. Calculo de los Casos de Uso Ajustados (UCP)
Para esto se utilizan las siglas UCP y se obtiene al multiplicar el UUCP,

el TCF y el EF quedando la operacin de la siguiente forma:
UCP = UUCP x TCF x EF
Estas siglas significan:
UCP : Puntos de casos de uso ajustados.

UUCP : Puntos de casos de uso sin ajustar.
TCF : Factores tcnicos.
EF : Factores ambientales.
Como ya tenemos calculados los valores anteriormente descritos,

procedemos a calcular los Casos de Uso Ajustados.
UCP = 281 x 1.14 x 0.725
UCP = 232.2465
5.1.3.1.7. Estimacin del Esfuerzo
Este clculo se realiza con el fin de tener una aproximacin del esfuerzo,
pensando solo en el desarrollo segn las funcionalidades de los casos
de uso. Anteriormente, se sugera utilizar 20 horas persona por UCP,
169 | P g i n a
pero a travs del tiempo se ha ido mejorando. Est basado en los
factores ambientales y se calcula de la siguiente manera:
Contar cantidad de factores del 1 al 6 con Nivel por debajo de 3 (CF1-6).

Contar cantidad de factores del 7 al 8 con Nivel por encima de 3 (CF7-8).
Total = CF 1-6 + CF 7-8
CF 1-6 = 0
CF 7-8 = 1
Total = 1
Si el total es:
[0-2] : Usar 20 hombres-horas por UCP;

CF = 20 horas/hombre
[3-4] : Usar 28 hombres-horas por UCP;
CF = 28 horas/hombre
[5-8] : Tratar de hacer cambios al proyecto,
pues el riesgo de fallar es muy alto.
El esfuerzo en horas-persona viene dado por:
E = UCP x CF
UCP = 232.2465
CF = 20
E = 4,644.93 horas/persona
Al realizar la multiplicacin del UCP por las horas-persona, se consigue

un esfuerzo estimado, que representa una parte del total del esfuerzo de
todo el proyecto, generalmente un 40%. Este 40% se refiere al esfuerzo
170 | P g i n a
total para el desarrollo de las funcionalidades especificadas en los Casos
de Uso.
En la siguiente tabla se detallan la distribucin en porcentaje, para el

esfuerzo total en el desarrollo del proyecto:
Actividad Porcentaje
Anlisis 10%
Diseo 20%
Programacin 40%
Pruebas 15%
Sobrecarga (OA) 15%
Tabla 33. Distribucin porcentual de las Actividades. Fuente: Elaboracin Propia
Si adems se considera que este esfuerzo representa un porcentaje del

esfuerzo total del proyecto, de acuerdo a los valores porcentuales de la
tabla anterior, se obtiene:
Actividad Porcentaje Esfuerzo

Anlisis 10% 1,161.23
Diseo 20% 2,322.47
Programacin 40% 4,644.93
Pruebas 15% 1,741.85
Sobrecarga (OA) 15% 1,741.85
100% 11,612.33
Tabla 34. Distribucin porcentual del Esfuerzo total del Proyecto. Fuente: Elaboracin Propia
5.1.3.2. COSYSMO
Para la estimacin del costo de desarrollo del sistema se utilizar la

tcnica COSYSMO (Modelo Constructivo del Costo de la Ingeniera de
Sistemas).
El propsito del modelo COSYSMO es el de estimar el esfuerzo para

sistemas de gran escala (software y hardware).
171 | P g i n a
COSYSMO soporta el estndar ANSI/EIA 632 como una gua para
identificar las tareas de Ingeniera de Sistemas y tambin soporta el
estndar ISO/IEC 15288 para identificar las fases de los ciclos de vida
de los sistemas.
Similar a su predecesor COCOMO, COSYSMO computa esfuerzo y

costo como una funcin de tamao funcional del sistema y lo ajusta
sobre la base de una serie de factores ambientales relacionados con la
Ingeniera de Sistemas.
Para calcular el esfuerzo y el costo de desarrollo del sistema, se usar

la aplicacin SystemStar (versin 1.02 Trial). Esta aplicacin soporta el
modelo COSYSMO.
Figura 55. Ventana de Informacin de versin de SystemStar. Fuente: SystemStar
A continuacin calcularemos el costo de desarrollo del software

segn los parmetros que utiliza COSYSMO y la aplicacin SystemStar.
5.1.3.2.1. Tamao
En este campo ingresaremos las configuraciones de tamao por cada

componente. Entre los componentes podemos destacar los
Requerimientos, Interfases, Algoritmos y Escenarios.
172 | P g i n a
Figura 56. Ingreso de las configuraciones de tamao por Componente. Fuente: SystemStar
5.1.3.2.2. Factores de Costo
En este campo ingresamos los datos de:
Personal:
Cohesin de Equipo (Team).

Capacidad de Equipo (Pcap).
Personal de Experiencia (Pexp).
Capacidad de Proceso (Proc).
Operaciones:
Nmero y Diversidad de Instalacin (Inst)

Complejidad de Migracin (Migr)
Entorno:
Coordinacin de Multsite (Site).

Apoyo de Instrumento (Tool).
173 | P g i n a
Comprensin:
Entendimiento de Exigencias (Rqmt).

Entendimiento de Arquitectura (Arch).
Complejidad:
Riesgo de Tecnologa (Trsk).

Nivel de Exigencias de Servicio (Lscv).
Nmero de Niveles Recurrentes en el Diseo (Recu).
Documentacin (Docu).
Figura 57. Ingreso de los Factores de Costo por Componente. Fuente: SystemStar
5.1.3.2.3. Requerimientos de Evolucin y Volatilidad
Los requerimientos de evolucin y volatilidad describen la cantidad de

trabajo que se descarta debido a los cambios en los requisitos.
El tamao entregado antes de dichos requerimientos es del 100%. Para

ello ingresamos el valor de 100 en el campo REVL.
174 | P g i n a
Figura 58. Tamao Entregado del Proyecto. Fuente: SystemStar
5.1.3.2.4. Costos por Componente
En este campo ingresaremos los costos por persona para la

Concepcin, Desarrollo, Pruebas y Transicin.
Figura 59. Ingreso de los Costos por Componente. Fuente: SystemStar
175 | P g i n a
5.1.3.2.5. Tarifas de Trabajo para Estimacin
Este cuadro es alternativo al de Costos por Componente. Se definen los

nombres y tarifas de las tipos de trabajo que existen en el proyecto.
Figura 60. Ingreso de nombres y tarifas de los tipos de trabajo. Fuente: SystemStar
5.1.3.2.6. Calendario para la Estimacin
En este campo ingresaremos el tiempo de duracin total del proyecto.

Para el proyecto que estoy desarrollando la duracin total es de 24
meses.
176 | P g i n a
Figura 61. Ingreso del tiempo de duracin del Proyecto. Fuente: SystemStar
Por ltimo, el aplicativo SystemStar nos brinda toda la informacin

acerca del esfuerzo, costo y duracin del proyecto.
Por lo tanto, el costo de desarrollo del Sistema de Informacin para el

Control, Seguimiento y Mantenimiento del Equipamiento Hospitalario es
de:
Costo : $ 4,285.3 USD
5.2. Generalidades de la Aplicacin

5.2.1. Posicionamiento del Producto
5.2.1.1. Oportunidad de Negocio
El Hospital Central de la FAP es un moderno centro asistencial

especializado con equipos mdicos y biomdicos de ltima generacin
recientemente adquiridos, que lo ubican como uno de los hospitales de
177 | P g i n a
mayor tecnologa del pas. Debido a la cantidad de equipos que existen
en el Hospital, es necesario el control, seguimiento y mantenimiento
correctivo y preventivo de dichos equipos para evitar futuros
desperfectos que atenten contra el normal proceso de atencin a los
pacientes que concurren a este centro mdico.
Se espera obtener los siguientes beneficios:
Brindar soluciones a los procesos tediosos (buscar ordenes de

trabajo en archivadores, etc.)
Rpida atencin a las rdenes de trabajo solicitadas.
Inventario de equipos hospitalarios totalmente actualizados.
5.2.1.2. Declaracin del Problema a Resolver
No contar con un control y seguimiento

de las rdenes de Trabajo y Solicitudes
El problema de de Servicio que recepciona la seccin
Programacin y Control del
Departamento de Ingeniera.
A los trabajadores del Departamento y a

Afecta
los usuarios del Hospital Central FAP.
La recepcin y registro manual de una

El impacto de la orden de trabajo y/o solicitud de servicio
cual es ocasiona demora en la atencin y
mantenimiento de un equipo hospitalario.
Contar con una aplicacin que permita

que desde cualquier lugar del Hospital
Una solucin Central FAP, el usuario genere rdenes
adecuada seria de trabajo y solicitudes de servicio, a su
vez tenga un control y seguimiento de las
mismas.
Tabla 35. Declaracin del Problema a Resolver. Fuente: Elaboracin Propia
178 | P g i n a
5.2.1.3. Declaracin del Posicionamiento del Producto
El Departamento de Ingeniera del

Para
HCFAP.
Necesita tener una buena Gestin de

Quien Ordenes de Trabajo y Solicitudes de
Servicio.
Sistema de Informacin para el Control,

El producto Seguimiento y Mantenimiento del
Equipamiento Hospitalario.
Permitir al personal del Departamento

de Ingeniera llevar un adecuado control
y seguimiento de las rdenes de trabajo y
solicitudes de servicio de los equipos
Que
hospitalarios y no hospitalarios, as como
contar con un inventario de equipos
biomdicos, mdicos y electromecnicos
actualizado.
Otros Hospitales y clnicas del pas que

realizan su registro de rdenes de trabajo
A diferencia de e inventario manualmente, ocasionando
cuellos de botella en sus procesos de
recepcin, distribucin y control.
Automatizar todos los procesos del

negocio involucrados que cubran las
Nuestro Producto
necesidades del Departamento de
Ingeniera.
Tabla 36. Declaracin del Posicionamiento del Producto. Fuente: Elaboracin Propia
179 | P g i n a
5.2.2. Vista Global del Producto
5.2.2.1. Perspectiva del Producto
El desarrollo del presente producto va a permitir al Departamento de
Ingeniera poder concretar ms oportunidades de negocio, esto por
razones de que los procesos que actualmente se vienen desarrollando
en el Departamento llevan muchas horas de trabajo e incurren en mucha
demora y costos.
5.2.2.2. Sumario de Capacidades
El desarrollo de la presente aplicacin va a permitir que el Hospital

obtenga los siguientes beneficios:
El usuario podr tener un control y seguimiento de sus rdenes de

trabajo que gener, en cualquier lugar y en el momento que lo
desee.
El Departamento de Ingeniera podr tener un manejo adecuado

durante la atencin de rdenes de trabajo, facilitando el trabajo y
control de las rdenes al contar con un proceso automatizado.
La manera rpida y sencilla del registro de las ordenes de trabajo

permite que los usuarios cuenten con los servicios solicitados lo ms
pronto posible ya que todos los procesos que involucran el registro y
la atencin de las ordenes de trabajo se realizan de manera
automatizada.
Una mejor calidad de atencin hacia el usuario final.
5.2.2.3. Suposiciones y Dependencias
La aplicacin requiere de un correcto funcionamiento de la red, la

velocidad de acceso as como la concurrencia que depender del tipo de
red que utilice el Hospital.
180 | P g i n a
Es necesario que las sugerencias presentadas por parte del grupo
encargado del proyecto se tomen en cuenta, con todo lo relacionado a
los planes de contingencia y los requerimientos en cuanto Hardware y
Software requeridos para el correcto funcionamiento de la aplicacin.
5.2.2.4. Licencias e Instalacin
La instalacin ser realizada por el grupo de trabajo a cargo del

proyecto.
La licencia le ser otorgada a la empresa a quien va dirigido el proyecto,

sin dejar de pertenecer a los integrantes del grupo de trabajo del
sistema.
Se requiere las siguientes licencias:
Oracle Enterprise Manager 10g, como manejador de Base de Datos.
Oracle Forms Developer 6i, para el desarrollo de la aplicacin.
Windows 2003 Server o superior como Sistema Operativo donde va

a correr el servidor.
Erwin 3.5 o Superior para el diseo de la Base de Datos.
Licencias para el Uso de Rational Rose Enterprise Edition.
Licencias para Microsoft Project 2003 o Superior.
Licencias para el Sistema Operativo Windows Xp o superior.
5.3. Anlisis Comparativo Benchmarking

El Benchmarking es una tcnica utilizada para medir el rendimiento de un
sistema o componente, frecuentemente en comparacin con el cual se refiere
especficamente a la accin de ejecutar un benchmark.
181 | P g i n a
El Benchmark es tambin un proceso continuo de medir productos, servicios y
prcticas contra competidores ms duros o aquellas compaas reconocidas
como lderes en la industria.
Los benchmark tienen las siguientes funcionalidades:
Comprobar si las especificaciones de los componentes estn dentro del

margen propio del mismo.
Maximizar el rendimiento con un presupuesto dado.
Minimizar costes manteniendo un nivel mnimo de rendimiento.
Obtener la mejor relacin costo/beneficio (con un presupuesto o unas
exigencias dadas).
Con ayuda a lograr una posicin ms competitiva.
Tambin puede realizarse un "benchmark de software", es decir comparar el

rendimiento de un software contra otro o de parte del mismo, por ejemplo,
comparar distintas consultas a una base de datos para saber cul es la ms
rpida o directamente partes de cdigo.
Este anlisis de benchmarking tiene la finalidad de comparar algunos de los

sistemas de informacin ms importantes que estn en el mercado del rubro de
salud, sealando las diferencias como tambin las similitudes.
Aqu encontraremos en forma minuciosa las principales caractersticas de los

sistemas de informacin de los principales hospitales y centros de salud del pas.
182 | P g i n a
BENCHMARKING
Sistema de Informacin para el Control, Seguimiento y Mantenimiento del Equipamiento Hospitalario
Anlisis Comparativo INEN ESSALUD HNDAC HCFAP
Aspectos Funcionales
Administrar Equipamiento Hospitalario x x
Administrar Departamentos y Secciones Hospitalarias x x x x
Administrar Personal Especialista de Mantenimiento x x x
Administrar Proveedores x
Administrar Ficha Tcnica de Equipos Hospitalarios x x x
Consultar Inventario de Equipos Hospitalarios x
Consultar Registro Histrico de Equipos Hospitalarios x
Registrar Tareas de Mantenimiento Preventivo x
Administrar Programacin de Mantenimiento Preventivo x x
Administrar Repuestos, Accesorios y Materiales x
Registrar Ordenes de Trabajo x x x x
Registrar Solicitudes de Servicios x
Consultar Ordenes de Trabajo x x x x
Consultar Responsable por Orden de Trabajo x
Administrar Informe Tcnico x x x
Parametrizacin
Identificacin de Usuarios x x x x
Administrar Usuarios x x x
Administrar Perfiles x
Administrar Opciones por Perfiles x
Software Base
Sistema Operativo Windows 2000, XP Windows 2000, XP Multiplataforma Multiplataforma
Servidor de Base de Datos SyBase MS SQL Server 2000 MySQL Oracle Enterprise Edition 10g
Lenguaje de Programacin Power Builder 9.0 Visual Basic 6.0 Java PL/SQL
Configuracin
Procesador Pentium IV o Superior Pentium III, IV o Superior Celeron Pentium IV o Superior
Memoria RAM RAM 512 MB RAM 256 MB RAM 128 MB RAM 512 MB
183 | P g i n a
5.4. Modelado de la Aplicacin
5.4.1. Actores del Sistema
El Sistema de Informacin para el Control, Seguimiento y Mantenimiento
del Equipamiento Hospitalario cuenta con los siguientes actores:
Usuario
S_Solicitante S_T ecnico Especialista S_Jefe de Seccion S_Jefe Departamento S_Administrador de

Sistema
S_Jefe Seccion Electronica S_Jefe Seccion S_Jefe Seccion

Electromecanica Instalaciones
Figura 62. Actores del Sistema. Fuente: Elaboracin Propia
5.4.2. Mdulos del Sistema
Equipos
Hospitalarios
Preventivo Ordenes de
Trabajo
Matenimiento Seguridad
Figura 63. Mdulos del Sistema. Fuente: Elaboracin Propia
184 | P g i n a
5.4.3. Diagramas de Casos de Uso del Sistema
Modulo Seguridad
Administrar Usuario
(f rom Administrar Usuario)
Administrar Perfil
S_Administrador de
Sistema (f rom Administrar Perf il)
(from Actores del Sistema)
Administrar Privilegios
Administrar Opciones
(f rom Administrar Priv ilegios)
(f rom Administrar Opciones)
Usuario Iniciar Sesion

(from Actores del Sistema) (f rom Iniciar Sesion)
Figura 64. Diagrama de Casos de Uso del Modulo Seguridad. Fuente: Elaboracin Propia
Caso de Uso Actor Meta

Permite a los usuarios
Iniciar Sesin Usuario identificarse para poder tener
acceso al sistema.
Permite registrar, modificar o
Administrador eliminar a los usuarios que harn
Administrar Usuario
de Sistema
uso del sistema.
Permite crear, modificar o eliminar
Administrador perfiles para asignarlos a los
Administrar Perfil
de Sistema diferentes usuarios de acuerdo a
sus cargos.
El Administrador asignar a cada
Administrar Administrador perfil ciertos privilegios para el
Privilegios de Sistema
manejo del sistema.
185 | P g i n a
Permite crear, modificar o eliminar
Administrador opciones de acuerdo al grado de
Administrar Opciones
de Sistema responsabilidad que tiene el
usuario para con el sistema.
Tabla 37. Especificaciones de Casos de Uso del Modulo Seguridad. Fuente: Elaboracin Propia
Modulo Mantenimiento
Registrar Equipamiento
Hospitalario
<<extend>>
Administrar Departamento y
Seccion
Administrar Grupo Equipamiento

Hospitalario Administrar Division
S_Administrador de
Sistema
(f rom Actores del Sistema)
Administrar Personal por Division
Administrar Proveedor (from Administrar Personal por Division)
(from Administrar Proveedor)
<<extend>>
Administrar Estado de
Funcionamiento
Registrar Detalle Estado de

Funcionamiento
Figura 65. Diagrama de Casos de Uso del Modulo Mantenimiento. Fuente: Elaboracin Propia

Permite crear, modificar o
Administrar Grupo eliminar los grupos en los cuales
Administrador
Equipamiento
de Sistema estn clasificados los equipos
Hospitalario
hospitalarios.
Registrar Permite registrar la descripcin
Administrador
Equipamiento
de Sistema del equipamiento hospitalario de
Hospitalario
186 | P g i n a
acuerdo al grupo a la cual
pertenece.
Administrar eliminar la descripcin de los
Administrador
Departamento y
de Sistema diferentes departamentos y
Seccin
secciones que cuenta el Hospital.
Administrador eliminar la descripcin de las
Administrar Divisin
de Sistema Divisiones del Departamento de
Ingeniera.
eliminar la informacin personal y
Administrar Personal Administrador laboral de los tcnicos
por Divisin de Sistema
especialistas del Departamento
de Ingeniera.
Administrar Administrador eliminar la informacin necesaria
Proveedor de Sistema
de los proveedores del Hospital.
Administrar Estado de Administrador eliminar los estados de
Funcionamiento de Sistema funcionamiento que va a tener la
orden de trabajo.
Permite registrar el detalle del
Registrar Detalle
Administrador estado de funcionamiento que va
Estado de
de Sistema
Funcionamiento a tener la orden de trabajo.
Tabla 38. Especificaciones de Casos de Uso del Modulo Mantenimiento. Fuente: Elaboracin Propia
187 | P g i n a
Modulo rdenes de Trabajo
S_T ecnico Especialista

S_Solicitante Consultar Ordenes de T rabajo Registrar Termino de Orden de Trabajo

(from Actores del Sistema) Delegadas
(f rom Registrar Termino de Orden de Trab...
(f rom Consultar Ordenes de Trabajo Delegadas)
<<include>> <<extend>>
Consultar Estado de Reparacion

(f rom Consultar Estado de Reparacion)
Aprobar Termino de Orden de Trabajo Registrar Informe T ecnico
Solicitar Orden de T rabajo (f rom Aprobar Termino de Orden de Trab... (f rom Registrar Inf orme Tecnico)
(f rom Solicitar Orden Trabajo)
<<include>>
Consultar Ordenes de T rabajo Solicitadas Delegar Orden de T rabajo

(f rom Consultar Ordenes de Trabajo Solicitadas) (f rom Delegar Orden de Trabajo)
S_Jefe Seccion S_Jefe Seccion Electronica S_Jefe Seccion

Electromecanica Instalaciones
(from Actores del Sistema) (from Actores del Sistema)
<<include>>
Imprimir Orden de T rabajo Cerrar Orden Trabajo

(f rom Imprimir Orden de Trabajo) (f rom Cerrar Orden Trabajo)
Figura 66. Diagrama de Casos de Uso del Modulo Ordenes de Trabajo. Fuente: Elaboracin Propia

Permite al solicitante registrar
Solicitar Orden de una orden de trabajo cuando un
Solicitante
Trabajo equipo o instalacin tiene una
falla de funcionamiento.
Permite al solicitante conocer el
estado de reparacin de su
Consultar Estado de equipo o instalacin una vez que
Solicitante
Reparacin
haya solicitado su orden de
trabajo.
Solicitante Permite al solicitante dar
Aprobar Termino de conformidad a la orden de trabajo
Orden de Trabajo Tcnico
Especialista una vez que el tcnico
188 | P g i n a
especialista repar el equipo.
Permite al tcnico especialista

hacer una revisin de las
Consultar Ordenes de Tcnico rdenes de trabajo que le han
Trabajo Delegadas Especialista
asignado para la reparacin o
mantenimiento de un equipo.
Permite al tcnico especialista
Registrar Termino de Tcnico registrar una orden de trabajo
Orden de Trabajo Especialista
como atendida o realizada.
Permite registrar el Informe
Tcnico cuando un equipo
Registrar Informe Tcnico necesita reparacin de una
Tcnico Especialista
compaa especializada o
cuando se solicita su baja.
Jefe Seccin
Electromecnica Permite a los jefes de seccin
consultar las rdenes de trabajo
Consultar Ordenes de Jefe Seccin que han sido solicitadas por el
Trabajo Solicitadas Electrnica
personal que labora en el
Jefe Seccin Hospital.
Instalaciones
Jefe Seccin
asignar rdenes de trabajo
Delegar Orden de Jefe Seccin pendientes a su personal tcnico
Trabajo Electrnica
especialista para la reparacin o
Jefe Seccin mantenimiento.
Instalaciones
Jefe Seccin
Electromecnica Permite a los jefes de seccin,
una vez reparado el equipo, dar
Jefe Seccin su aprobacin a la orden de
Cerrar Orden Trabajo
Electrnica
trabajo realizada y cerrar dicha
Jefe Seccin orden.
Instalaciones
Jefe Seccin
Imprimir Orden de Jefe Seccin imprimir las rdenes de trabajo

Trabajo Electrnica realizadas para su posterior
archivo.
Jefe Seccin
Instalaciones
Tabla 39. Especificaciones de CUS del Modulo rdenes de Trabajo. Fuente: Elaboracin Propia
189 | P g i n a
Modulo Equipos Hospitalarios
S_Jefe Seccion
Electromecanica
Consultar Historial de Equipos
Administrar Ficha Tecnica

S_Jefe Seccion
(f rom Administrar Ficha Tecnica) Electronica
S_Tecnico Especialista
Consultar Inventario de Equipos

S_Solicitante
(f rom Consultar Inv entario de Equipos)
Figura 67. Diagrama de Casos de Uso del Modulo Equipos Hospitalarios. Fuente: Elaboracin Propia

Permite a los jefes de seccin
Jefe de Seccin
crear, modificar o eliminar la
Electromecnica
Administrar Ficha informacin tcnica de los
Tcnica
Jefe Seccin equipos hospitalarios con los
Electrnica
que cuenta el Hospital.
Permite consultar el inventario
Jefe de Seccin
de equipos hospitalarios de una
Electromecnica
seccin o departamento del
Jefe Seccin hospital. Tambin se podr
Consultar Inventario Electrnica imprimir el reporte del inventario
de Equipos
Tcnico especificando las
Especialista caractersticas tcnicas as
como su estado de
Solicitante
funcionamiento.
190 | P g i n a
Jefe de Seccin Permite consultar el historial de
Electromecnica reparaciones o mantenimientos
que ha tenido un equipo
Jefe Seccin
Consultar Historial de Electrnica hospitalario. Tambin se podr
Equipos imprimir el reporte del historial
Tcnico de equipos especificando las
Especialista
fechas de reparaciones as
Solicitante como las rdenes de trabajo.
Tabla 40. Especificaciones de Casos de Uso del Modulo Equipos Hospitalarios. Fuente: Elaboracin
Propia
Modulo Preventivo
<<include>> Registrar Actividades de

Mantenimiento
Administrar Tarea de Mantenimiento
<<include>>
Registrar Repuestos, Accesorios y

Materiales
S_Jefe Seccion S_Jefe Seccion

Electromecanica Electronica
(f rom Actores del Sistema) (f rom Actores del Sistema)
Seleccionar Equipo Hospitalario

<<include>>
<<include>>
Administrar Programacion de Asignar Tarea de Mantenimiento

Mantenimiento
<<include>>
Asignar Responsable de Tarea
Consultar Aviso de Mantenimiento

S_Tecnico Especialista
(f rom Actores del Sistema)
Figura 68. Diagrama de Casos de Uso del Modulo Preventivo. Fuente: Elaboracin Propia
191 | P g i n a
Jefe de Seccin Permite crear, modificar o
Electromecnica eliminar las tareas de
Administrar Tarea de
Mantenimiento mantenimiento asociadas al
Jefe de Seccin
Electrnica equipamiento hospitalario.
Jefe de Seccin
Se va a registrar las diversas
Electromecnica
Registrar Actividades actividades para una tarea
de Mantenimiento
Jefe de Seccin especfica de mantenimiento.
Electrnica
Jefe de Seccin Se va a registrar los repuestos,
Registrar Repuestos, Electromecnica accesorios y/o materiales que
Accesorios y
se van a utilizar en una tarea de
Materiales Jefe de Seccin
Electrnica mantenimiento.
Jefe de Seccin
Administrar eliminar la programacin de
Electromecnica
Programacin de mantenimiento preventivo
Mantenimiento Jefe de Seccin asociadas al equipamiento
Electrnica
hospitalario.
Jefe de Seccin Se va a seleccionar el equipo
Electromecnica hospitalario a la cual se va
Seleccionar Equipo
Hospitalario programar su mantenimiento
Jefe de Seccin
Electrnica preventivo.
Jefe de Seccin
Se va a asignar una o varias
Electromecnica
Asignar Tarea de tareas de mantenimiento a un
Mantenimiento
Jefe de Seccin equipo hospitalario.
Electrnica
Jefe de Seccin Se va a asignar un responsable
Electromecnica que se har cargo del
Asignar Responsable
de Tarea mantenimiento preventivo del
Jefe de Seccin
Electrnica equipo hospitalario.
El responsable podr consultar
Consultar Aviso de Tcnico que equipos les toca su
Mantenimiento Especialista
mantenimiento preventivo.
Tabla 41. Especificaciones de Casos de Uso del Modulo Preventivo. Fuente: Elaboracin Propia
192 | P g i n a
5.4.4. Diagramas de Secuencia de los Casos de Uso
Diagrama de Secuencia: Caso de Uso Iniciar Sesin
: S_Administrador : frmLogin : frmMainGeneral : Login : E_Usuario

de Sistema
1: Ingresa datos(usuario y contrasea)
2: Enviar datos
3: Busca datos
4: Valida datos
5: Si los datos incorrectos MSG "Contrasea Incorrecta"
6: Si datos correcto muestra interfaz
Figura 69. Diagrama de Secuencia: Caso de Uso Iniciar Sesin. Fuente: Elaboracin Propia
Diagrama de Secuencia: Caso de Uso Administrar Perfil
: S_Administrador 4: Muestra nombre perfil : : Manejador de Perfiles : E_Perfil

de Sistema frmRegistraPerfil
1: Ingresa nombre perfil y presiona "guardar"
2: Guarda datos de perfil
3: Registra datos
4: Envia MSG"Perfil Registrado"
Figura 70. Diagrama de Secuencia: Caso de Uso Administrar Perfil. Fuente: Elaboracin Propia
193 | P g i n a
Diagrama de Secuencia: Caso de Uso Administrar Usuario
: S_Administrador
de Sistema : frmRegistraUsuario : Buscador de : Manejador de Perfiles : E_Personal : E_Usuario
: Manejador de Usuarios : E_Perfil
Trabajadores
1: Seleciona personal
2: Selecionar nombre personal
3: Busca nombre personal
4: Envia nombre personal
5: Muestra nombre personal
6: Seleciona perfil
7: Selecionar nombre perfil
8: Busca nombre perfil
9: Envia nombre perfil
10: Muestra nombre perfil
11: Seleciona grupo de usuario
12: Selecionar grupo usuario
13: Busca grupo de usuario
14: Envia grupo de usuario
13: Muestra grupo de usuario
14: Ingresa usuario , pass, correo y presiona "OK"
15: Guarda datos de usuario
16: Registra datos de usuario
17: Envia MSG "Registro Usuario"
Figura 71. Diagrama de Secuencia: Caso de Uso Administrar Usuario. Fuente: Elaboracin Propia
194 | P g i n a
Diagrama de Secuencia: Caso de Uso Administrar Privilegios
: S_Administrador : frmAsignaPrivilegio : ManejadorOpciones : Manejador de Perfiles : E_Perfil : E_Privilegios : E_OpcionesPorPerfil

de Sistema
1: Seleciona opcion Perfil
2: Solicita perfil
3: Busca perfil
4: Envia perfil
5: Muestra lista perfil
6: Seleciona un perfil especifico
7: Solicitar opciones
8: Busca opciones por perfil
9: Envia Opciones por perfil
10: Muestra opciones por perfil
11: Dar visto "Habilitar" y seleciona "Guardar"
12: Guarda privilegio
13:Registra privilegio
Figura 72. Diagrama de Secuencia: Caso de Uso Administrar Privilegios. Fuente: Elaboracin Propia
195 | P g i n a
Diagrama de Secuencia: Caso de Uso Solicitar Orden de Trabajo
: S_Solicitante : Gestor de Ordenes de : E_Division : E_Seccion : E_OrdenDeTrabajo

: frmRegistraOT : E_EquiposHospitalario
Trabajo
1. Selecciona Seccion (Dpto)
2. Seleccionar Seccion (Dpto)
3. Selecciona Seccion (Dpto)
4. Muestra Seccion (Dpto)
5. Mostrar Seccion (Dpto)
6. Selecciona Ubicacion (Servicio/Seccion)
7. Seleccionar Ubicacion (Servicio/Seccion)
8. Seleccionar Ubicacion (Servicio/Seccion)
9. Seleccionar Ubicacion ((Servicio/Seccion))
10. Mostrar Ubicacion (Piso , Zona)
11. Mostrar Ubicacion (Cod Hospital)
12. Mostrar Ubicacion (Piso, Zona, Cod Hospital)
13. Seleccionar Equipo (Equipo)
14. Seleciona Equipo (Equipo)
15 Selecionar Equipo ()
16. Mostrar Equipo(Marca, Serie)
17. Mostrar Equipo (Marca, Serie)
18. Registrar Orden de Trabajo(Dpto, Serie/Seccion, Piso, zona, Telefono, Cod Hospital, Marca Equipo, serie, Descripcion, Fecha Emicion, Solicitante)
19. Registra Orden Trabajo (Dpto, Serie/Seccion, Piso, zona, Telefono, Cod Hospital, Marca Equipo, serie, Descripcion, Fecha Emicion, Solicitante)
20. Registrar Orden de Trabajo (Dpto, Serie/Seccion, Piso, zona, Telefono, Cod Hospital, Marca Equipo, serie, Descripcion, Fecha Emicion, Solicitante)
21. Mostrar Orden de Trabajo (Dpto, Serie/Seccion, Piso, zona, Telefono, Cod Hospital, Marca Equipo, serie, Descripcion, Fecha Emicion, Solicitante)
22. MSJ "Datos enviados con exito"
Figura 73. Diagrama de Secuencia: Caso de Uso Solicitar Orden de Trabajo. Fuente: Elaboracin
Propia
196 | P g i n a
Diagrama de Secuencia: Caso de Uso Consultar Estado de Reparacin
: S_Solicitante : frmConsultaEstadoReparacion : Gestor de Ordenes de : Gestor de Ordenes de : E_OrdenDeTrabajo

Servicio Trabajo
1: Ingresa opcion Consultar Estado De Reparacion
2: Pide Estado de Reparacion
3: Pide Estado de Reparacion
4: Busca Estado de Repracion
5: Envia Estado de Reparacion
6: Busca Estado de Reparacion
7: Envia Estado de Reparacion
7: Muestra Orden Trabajo(Tipo de reparacion,Fecha emision,Estado reparacion,Tecnico Responsable,Division)
8: Muestra Orden Servicio(Tipo de reparacion,Fecha emision,Estado reparacion,Tecnico Responsable,Division)
Figura 74. Diagrama de Secuencia: Caso de Uso Consultar Estado de Reparacin. Fuente:
Elaboracin Propia
197 | P g i n a
Diagrama de Secuencia: Caso de Uso Cerrar Orden de Trabajo
: S_Jefe Seccion : S_Jefe Seccion : frmCerrarOrdenTrabajo : Gestor de Ordenes de : E_InformeTecnico :

: S_Jefe Seccion
Electromecanica Electronica Trabajo E_EstadoFuncionamiento
Instalaciones
1. Revisa Confirmacion del Solicitante
2. Confirma Trabajo terminado Satisfactoriamente
3. Envia Datos de Confirmacion
4. Actualiza el Informe Tecnico del Equipo
6. Envia Mensaje
7. MSJ "Aprobacion de Orden Correcta"
9. Confirma Trabajo Terminado Satisfactoriamente
11. Actualiza El informe Tecnico del Equipo
12. Envia Mensaje
15. Confirma Trabajo Terminado Satisfactoriamente
17. Actualiza El informe tecnico del Equipo
18 Envia Mensaje
Figura 75. Diagrama de Secuencia: Caso de Uso Cerrar Orden de Trabajo. Fuente: Elaboracin
Propia
198 | P g i n a
Diagrama de Secuencia: Caso de Uso Delegar Orden de Trabajo
: S_Jefe Seccion : S_Jefe Seccion : frmConsultaOT : frmDelegaTrabajo : Planificador de Trabajos

Electromecanica Electronica : E_Personal
1. Visualiza la lista de Ordenes Pendientes y clic en una orden
2. Visualiza con detalles la Orden y selecciona trabajador
3. Selecciona Trabajador
5. Envia Datos Del trabajador
6. Muestra Trabajador
7. Visualiza la lista de Ordenes Pendientes y clic en una orden
8. Visualiza con detalles la Orden Y selecciona trabajo
11. Envia Datos Del Trabajador
12. Muestra Trabajador
Figura 76. Diagrama de Secuencia: Caso de Uso Delegar Orden de Trabajo. Fuente: Elaboracin
Propia
Diagrama de Secuencia: Caso de Uso Administrar Proveedor
199 | P g i n a
: S_Administrador : frmRegistroProveedor : Planificador de : E_Proveedor
de Sistema Proveedores
1. Ingresa Datos (Proveedor, Tipo Proveedor, Direccion,Telf, Mail, Pag Web, RUC)
2. Envia Datos (Proveedor, Tipo Proveedor, Direccion,Telf, Mail, Pag Web, RUC)
3. Guarda Datos
4. Envia Mensaje
5. MSJ "Datos de Proveedor Enviados con exito"
Figura 77. Diagrama de Secuencia: Caso de Uso Administrar Proveedor. Fuente: Elaboracin Propia
Diagrama de Secuencia: Caso de Uso Administrar Personal por Divisin
: S_Administrador : frmRegistroPersonal : frmConsultaPersonal : Buscador de : E_Personal :

de Sistema Trabajadores E_ClasificacionPersonal
1. Ingresa Datos del Personal (IdPersonal, Nombre, Apellidos, Telefono, Cargo, correo, grado)
2. Ingreso datos de Personal ()
3. Datos ingresados de personal ()
4. Clasificacion de Personal Usuario del Sistema
4. Envia mensaje de confirmacion
5. MSJ "Datos Enviados Correctamente"
6. Ingresa Codigo de Personal (Personal ID, Apellido)
7. Valida Datos()
8. Busca Datos()
9. Envia Datos
10. Envia Datos Seleccionado
Figura 78. Diagrama de Secuencia: Caso de Uso Administrar Personal por Divisin. Fuente:
Elaboracin Propia
Diagrama de Secuencia: Caso de Uso Consultar Inventario de Equipos
200 | P g i n a
: Usuario : frmConsEquipHosp : Buscador de Divisiones : Manejador de EquiposH : E_Division : E_EquiposHospitalario
1: Seleciona la opcion busqueda Equipo
2: Solicita por division
3: Busca Division
4: Envia Division
5: Muestra division de equipo
7: Solicita Equipos
8: Busca Equipos Hospitalarios
9: Envia Equipos Hospitalario
10: Muestra Lista de Equips Hospitalarios
Figura 79. Diagrama de Secuencia: Caso de Uso Consultar Inventario de Equipos. Fuente:
Elaboracin Propia
Diagrama de Secuencia: Caso de Uso Administrar Ficha Tcnica
: S_Jefe Seccion : S_Jefe Seccion :

: frmConsultaFichaTecnica : E_FichaTecnica
Electromecanica Electronica AdministradorFichaTecnica
1: Ingresa a la opcion ficha tecnica
2: Ingresa a la opcion Ficha Tecnica
3:Solicita ficha tecnica
4.Busca Ficha Tecnica
5: Envia la Ficha Tecnica
6: Muestra ficha tecnica detallada
Figura 80. Diagrama de Secuencia: Caso de Uso Administrar Ficha Tcnica. Fuente: Elaboracin
Propia
5.4.5. Modelo de Datos

Para el desarrollo del Sistema de Informacin para el Control,
Seguimiento y Mantenimiento del Equipamiento Hospitalario se tienen
las siguientes tablas, las cuales forman el Modelo de Datos del Sistema.
201 | P g i n a
Figura 81. Modelo de Datos del Sistema. Fuente: Elaboracin Propia
5.4.6. Diagrama de Componentes

Muestra el funcionamiento de los componentes creados por el sistema y
a la vez los componentes externos que ste va a utilizar.
Para el desarrollo del Sistema de Informacin para el Control,

Seguimiento y Mantenimiento del Equipamiento Hospitalario se tienen
los siguientes componentes los cuales forman la estructura del Sistema.
202 | P g i n a
Consultar Inv entario
de Equipos
Consultar Historial de
Administrar Equipos
Usuario
Aprobar Termino de
Orden de Trabaj o
Administrar Consultar Estado
Perfil de Reparacion
Administrar Ficha
Tecnica Equipos Hospitalarios
Solicitar Orden de Consultar Ordenes de Trabaj o
Trabajo Delegadas
Seguridad
Administrar
Priv ilegios
Registrar Termino de
Orden de Trabaj o
Ordenes de Trabajo
Administrar
Opciones
Registrar Informe
Iniciar Tecnico
Seccion SISTEMA
Consultar Ordenes de
Administrar Grupo Trabajo Solicitadas
Equipamiento Hospitalario
Delegar Orden
Registrar Equipamiento de Trabaj o
Hospitalario
Mantenimiento
Imprimir Orden
de Trabaj o
Cerrar Orden de
Administrar Departamento y
trabajo
Seccion Base de Datos
Preventivo
Consultar Av iso de
Administrar Mantenimiento
Div ision
Administrar
Prov eedor Administrar Tarea de
Mantenimento
Administrar Personal
por Div ision
Asignar Responsable
de Tarea
Administrar Estado de
Funcionamiento
Registrar Activ idades de
Mantenimiento
Registrar Detalle Estado de

Funcionamiento
Asignar Tarea de
Mantenimiento
Registrar Repuestos,
Figura 82. Diagrama de Componentes del Sistema. Fuente: Elaboracin Propia

Accesorios y Materiales
Administrar Programacion Seleccionar Equipo

de Mantenimiento Hospitalario
203 | P g i n a
5.4.7. Diagrama de Despliegue
Para concretar fsicamente el despliegue del sistema ser necesaria la
participacin de tres elementos en la red:
La PC del Usuario:
Este elemento representa al equipo de cmputo PC o Laptop en la

cual el usuario del hospital acceder a la aplicacin. La PC del
usuario debe estar conectada a la red LAN del Hospital.
El Servidor de Aplicaciones:
Equipo informtico en donde se encuentra alojado el sistema, en la

cual se encuentran adems las clases controladoras para la
ejecucin de las transacciones e interaccin entre la base de datos y
el usuario.
El Servidor de Base de Datos:
Equipo informtico en donde se encuentra almacenada la Base de

Datos.
Servidor de
Aplicaciones
Red de
Area Local
Servidor de Base de
PC Usuario Datos
Red TCP/IP
Figura 83. Diagrama de Despliegue del Sistema. Fuente: Elaboracin Propia
204 | P g i n a
5.4.8. Diagrama de Arquitectura de Capas
Este diagrama muestra como fluye la informacin que ingresa el usuario,
as como tambin la informacin que enva el sistema para l, la cual
recorre una serie de procesos de control para una mayor integridad en la
informacin. Para este proyecto de desarrollo de software se utiliz la
Arquitectura en 03 Capas.
5.4.8.1. Capa de Presentacin
En esta capa se programa las interfaces que el usuario utilizar para

interactuar con el sistema.
5.4.8.2. Capa de Negocio (Lgica)

En esta capa se distinguen dos proyectos:
Lgica del Negocio:
Hace referencia al conjunto de clases de control que cumplirn

funciones de validacin de datos, operaciones matemticas y
algoritmos concernientes al negocio y procesos, que debern
realizarse antes de poner a disposicin del usuario cualquier tipo de
informacin o respuesta.
Entidades del Negocio:
En este proyecto se programan las clases que tendrn como funcin

de encapsular los datos que van a viajar entre las capas, esta clases
son representaciones de las tablas de la base de datos y de otras
clases que se necesitarn la ejecucin del programa.
5.4.8.3. Capa de Acceso a Datos (Fsica)
Esta capa controla todo lo referente al acceso a datos: Base de Datos y

archivos en general; aqu se programan las clases que se encargarn de
los accesos y toma de datos de los archivos.
205 | P g i n a
Figura 84. Diagrama de Arquitectura de 03 Capas. Fuente: Wikimedia Commons
5.4.9. Interfases del Sistema

A continuacin se presentarn las principales interfases del Sistema de
Informacin para el Control, Seguimiento y Mantenimiento del
Equipamiento Hospitalario. Estas interfases estarn divididas por los
Mdulos del Sistema que se han desarrollado.
Figura 85. Ventana de Inicio de Sesin. Fuente: Elaboracin Propia
206 | P g i n a
Figura 86. Men Principal del Sistema de Gestin del Equipamiento Hospitalario. Fuente: Elaboracin
Propia
5.4.9.1. Modulo Mantenimiento
Equipamiento Hospitalario
Figura 87. Administrar Equipamiento Hospitalario. Fuente: Elaboracin Propia
207 | P g i n a
Figura 88. Modificar Equipamiento Hospitalario. Fuente: Elaboracin Propia
Departamento y Seccin de los Servicios Hospitalarios
Figura 89. Administrar Departamentos. Fuente: Elaboracin Propia
208 | P g i n a
Figura 90. Administrar Secciones de los Departamentos. Fuente: Elaboracin Propia
Divisin y Personal del Departamento de Ingeniera
Figura 91. Administrar Divisiones del Departamento de Ingeniera. Fuente: Elaboracin Propia
209 | P g i n a
Figura 92. Administrar Personal del Departamento de Ingeniera. Fuente: Elaboracin Propia
Proveedores
Figura 93. Administrar Proveedores. Fuente: Elaboracin Propia
210 | P g i n a
5.4.9.2. Modulo Equipo
Ficha Tcnica
Figura 94. Administrar Ficha Tcnica. Fuente: Elaboracin Propia
Figura 95. Registrar Ficha Tcnica de un equipo. Fuente: Elaboracin Propia
211 | P g i n a
Inventario del Equipamiento Hospitalario
Figura 96. Consultar Inventario de Equipos Hospitalarios. Fuente: Elaboracin Propia
Figura 97. Reporte de Inventario de Equipos Hospitalarios. Fuente: Elaboracin Propia
212 | P g i n a
Registro Histrico
Figura 98. Consultar Registro Histrico del Equipamiento. Fuente: Elaboracin Propia
Figura 99. Detalle de Registro Histrico de un Equipo Hospitalario. Fuente: Elaboracin Propia
213 | P g i n a
5.4.9.3. Modulo Preventivo
Tareas de Mantenimiento Preventivo
Figura 100. Registrar Tarea de Mantenimiento Preventivo. Fuente: Elaboracin Propia
Figura 101. Registrar Actividad de la Tarea de Mantenimiento. Fuente: Elaboracin Propia
Figura 102. Agregar Repuesto y Material que se utilizar en la Tarea. Fuente: Elaboracin Propia
214 | P g i n a
Programacin de Mantenimiento Preventivo
Figura 103. Administrar Programacin de Mantenimiento Preventivo. Fuente: Elaboracin Propia
Figura 104. Registrar Programacin de Mantenimiento Preventivo. Fuente: Elaboracin Propia
215 | P g i n a
5.4.9.4. Modulo Almacn
Genricos
Figura 105. Administrar Genricos. Fuente: Elaboracin Propia
Figura 106. Registrar Genrico. Fuente: Elaboracin Propia
216 | P g i n a
Stock o Comerciales
Figura 107. Administrar Repuestos, Accesorios y Materiales. Fuente: Elaboracin Propia
Figura 108. Registrar Repuestos, Accesorios y Materiales. Fuente: Elaboracin Propia
217 | P g i n a
5.4.9.5. Modulo Orden de Trabajo
Orden de Trabajo Pendiente
Figura 109. Administrar Orden de Trabajo Pendiente. Fuente: Elaboracin Propia
Figura 110. Registrar Orden de Trabajo Pendiente. Fuente: Elaboracin Propia
218 | P g i n a
Orden de Trabajo Realizada
Figura 111. Administrar Orden de Trabajo Realizada. Fuente: Elaboracin Propia
Figura 112. Registrar Orden de Trabajo Realizada. Fuente: Elaboracin Propia
219 | P g i n a
Consultas de Ordenes de Trabajo
Figura 113. Consultar Ordenes de Trabajo. Fuente: Elaboracin Propia
Figura 114. Consultar Responsables por Orden de Trabajo. Fuente: Elaboracin Propia
220 | P g i n a
5.4.9.6. Modulo Informe Tcnico
Figura 115. Administrar Informe Tcnico. Fuente: Elaboracin Propia
221 | P g i n a
Figura 116. Registrar Informe Tcnico. Fuente: Elaboracin Propia
5.4.9.7. Modulo Seguridad
Figura 117. Administrar Usuarios del Sistema. Fuente: Elaboracin Propia
222 | P g i n a
Figura 118. Registrar Usuario del Sistema. Fuente: Elaboracin Propia
Figura 119. Administrar Perfiles del Sistema. Fuente: Elaboracin Propia
223 | P g i n a
Figura 120. Administrar Opciones. Fuente: Elaboracin Propia
Figura 121. Administrar Opciones por Perfiles. Fuente: Elaboracin Propia.
224 | P g i n a
5.5. Estndares Utilizados
5.5.1. Estndares de Documentos
5.5.1.1. Informe de Tesis
El informe debe estar escrito con correcta redaccin, ortografa y un
adecuado uso del vocabulario cientfico tcnico referente a la
informtica. Las palabras utilizadas deben representar en forma clara y
precisa lo que se desea expresar. En caso de utilizarse trminos cuya
interpretacin necesita una definicin especial para su correcto
entendimiento, deben aparecer en el Glosario De Trminos.
5.5.1.2. Formato de Documentos
N Clasificacin Tipo de Letra Tamao Otros Interlineado
1 Contenido Arial 12 1.5

2 Ttulos Arial 18 Negrita 1.5
3 Subttulos Arial 16, 14, 12 Negrita 1.5
4 Encabezado/Pie pgina Arial 12 1.5
5 Ttulo de Cuadros Arial 10 Cursiva 1.5
6 Texto dentro de cuadros Arial 10
Tabla 42. Formato de Documentos para el Informe de Tesis. Fuente: Elaboracin Propia
5.5.1.3. Formato de Espacios
Clasificacin entre N Espacios
Ttulo 1 Cuadros 1(Tam 18)
Titulo 1 Subttulos 1(Tam 12)
Subttulos Prrafos 1(Tam 12)
Subttulos Cuadros 1(Tam 12)
Prrafo Prrafo 1(Tam 12)
Tabla 43. Formato de Espacios para el Informe de Tesis. Fuente: Elaboracin Propia
225 | P g i n a
5.5.1.4. Formato de Pgina
Mrgenes Izquierdo Derecho Inferior Superior
2.5 cm. 2 cm. 2.5 cm. 2.5 cm.
Tabla 44. Formato de Pgina para el Informe de Tesis. Fuente: Elaboracin Propia
5.5.2. Estndares de Anlisis

Estandarizacin de los paquetes utilizados en el software Rational Rose.
Directorio Use Case View
Carpeta Principal llamada Modelo del Negocio.

Sub-Carpeta Actores del Negocio. Deben comenzar BA_<Nombre>.
Sub-Carpeta Casos de Uso del Negocio. Dentro de esta sub-
carpeta se encuentran los casos de uso del negocio.
Carpeta Principal llamada Modelo del Sistema.

Sub-Carpeta Actores del sistema. Se describen todos los actores
participantes.
Sub-Carpeta Casos de Uso del Sistema. Dentro de esta sub-
carpeta se encuentran los casos de uso del sistema.
Sub-Carpeta Paquetes del Sistema. Dentro de esta sub-carpeta
se encuentran cinco paquetes del sistema: Equipos Hospitalarios,
Ordenes de Trabajo, Mantenimiento, Preventivo y Seguridad.
Directorio Logical View
Carpeta Principal llamada Analysis Model.

Sub-Carpeta Controles. Todos los nombres deben comenzar con
CTRL_<Nombre>.
Sub-Carpeta Interfaces. Todos los nombres deben comenzar con
GUI_<Nombre>.
Sub Carpeta Entidades. Deben comenzar BE_<Nombre>.
226 | P g i n a
Sub-Carpeta Modelo de Dominio.
Sub-Carpeta Modelo Conceptual.
Carpeta Principal llamada Modelo de Diseo.

Sub-Carpeta Capas. Deben comenzar MDC_<Nombre>.
Sub-Carpeta Paquetes. Deben comenzar MDP_<Nombre>.
Sub-Carpeta Sub-Sistemas. Deben comenzar MDS_<Nombre>.
Sub-Carpeta Casos Uso Realizacin. Deben comenzar con
CUR_<Nombre>.
Los Diagramas de Secuencia deben comenzar con DS_<Nombre> y
los Diagramas de Colaboracin deben comenzar con DC_<Nombre>.
Directorio Component View
Carpeta Principal Modelo de Implementacin.

Aqui va el Diagrama de Componentes, ejemplo: DLL, .EXE, ActiveX.
El nombre debe comenzar con MIDC_<Nombre>.
Directorio Deployment View
Aqui va el Diagrama de Despliegue, detallando los nodos requeridos

por el Sistema. El nombre debe comenzar con DVDD_<Nombre>.
Otras Asignaciones de Nombre
Diagrama General del Caso de uso del Negocio

DG_<Nombre>
Diagrama del Caso de uso del Negocio

BUCD_<Nombre>
Caso de uso del Negocio
227 | P g i n a
BUC_<Nombre>
Diagrama de Objetos del Negocio

Se describen los objetos del negocio. Deben comenzar con
BE_<Nombre>.
5.5.3. Estndares de Diseo

Etiquetas:
Letra: Microsoft Sans Serif.
Tamao de Letra: 8.
Color de letra: Negro.
Dimensiones: Por determinar.
Botones:
Letra: Microsoft Sans Serif.
Tamao de Letra: 8.25.
Color de letra: negro.
Grficos: Por determinar y el grafico de acuerdo al nombre del botn.
Fondo: Por determinar.
Dimensiones: Por determinar.
Text Box:
Tipo de Letra: Microsoft Sans Serif.
Tamao de letra: 8.
Fondo: Blanco.
Tamao: de acuerdo al dato a ingresar.
Combo Box:
Tipo de Letra: Microsoft Sans Serif.
Tamao de letra: 10.
Fondo: Blanco.
228 | P g i n a
Tamao: de acuerdo al dato a seleccionar.
Check Box:
Tipo de Letra: Verdana.
Tamao de letra: 10.
Fondo: Blanco.
Radio Button:
Tamao de letra: 10.
Calendar:
Tamao de letra: 10.
Grilla de datos:
Tamao de letra: 10.
Fondo: Por determinar.
Tamao: de acuerdo al dato a seleccionar.
5.5.4. Estndares de Programacin

5.5.4.1. Prefijos de Variables
Tipo de Dato Prefijo Ejemplo

Bolean bln blnIsValid
Byte byt bytValue
Char chr chrLetter
Date dte dteStart
Decimal dec decValue
229 | P g i n a
Tipo de Dato Prefijo Ejemplo
Double dbl dblValue
Float flt fltValue
Int int intLoop
Long lng lngValue
Object obj objValue
Short srt srtValue
String str strName
Tabla 45. Prefijos de Variables para los elementos de Programacin. Fuente: Elaboracin Propia
5.5.4.2. Prefijos de Controles
Control Prefijo
Label lbl
TextBox txt
Button btn
LinkButton lnk
ImageButton img
HyperLink hyp
DropDownList ddl
ListBox lst
DataGrid dgr
DataList dlst
Repeater rep
CheckBox chk
CheckBoxList cbl
RadioButtonList rbl
RadioButton rdo
Image img
Panel pnl
PlaceHolder plc
Calendar cal
AdRotator ad
Table tbl
RequiredFieldValidator reqv
CompareValidator cmpv
RangeValidator rngv
RegularExpressionValidator rexpv
230 | P g i n a
Control Prefijo
CustomValidator custv
ValidationSummary vsum
Xml xml
Literal lit
CrystalReportViewer crv
Tabla 46. Prefijos de Controles para los elementos de Programacin. Fuente: Elaboracin Propia
5.5.4.3. Prefijos de Variables para Objetos de Base de

Datos
Objeto Prefijo
DataSet ds
DataTable dt
DataView dv
DataRow drw
DataColumn dcm
Connection cnn
Command cmd
DataAdapter da
CommandBuilder bld
Parameter prm
DataReader dr
Tabla 47. Prefijos de Variables para Objetos de Base de Datos. Fuente: Elaboracin Propia
5.5.4.4. Prefijos de Instancias de Clase
Nombre Prefijo Ejemplo

Collection Col colCliente
Control Ctr ctrInsertar
Formulario Frm Frm_Logeo
Objeto de Clase O oNombreClase
Tabla 48. Prefijos de Instancias de Clase. Fuente: Elaboracin Propia
5.5.4.5. Prefijos de Nombre de Funciones

Nombre = accin + Elemento involucrado
Nombre de la accin Prefijo Ejemplo

Insertar_Dato (Logica
Insertar Insertar
del Negocio)
231 | P g i n a
InsertarDato (Acceso a
Insertar Insertar
Datos)
Actualizar_Inventario
Actualizar Actualizar
(Logica del Negocio)
ActualizarInventario
Actualizar Actualizar
(Acceso a Datos)
Eliminar_Repuesto
Eliminar Eliminar
(Logica del Negocio)
EliminarRepuesto
Eliminar Eliminar
(Acceso a Datos)
Tabla 49. Prefijos de Nombre de Funciones. Fuente: Elaboracin Propia
5.5.5. Estndares de Base de Datos

Se usar estndares especficos para nombrar las tablas y columnas de
la base de datos, el conjunto de dichos estndares ser llamado
nomenclatura. De esta forma lograremos identificar rpidamente el
contenido de las tablas y columnas, as como tambin lograremos
recordar fcilmente sus nombres.
5.5.5.1. Estndares para Nombrar Objetos de la Base de

Datos
El estndar general radica en que los nombres de los objetos solo

podrn contener letras maysculas y el smbolo _ como conector.
Nomenclatura:
El nombre de un objeto de la base de datos seguir la siguiente

estructura:
<PP><SP>_<NO>
Donde:
PP : Primer Prefijo.
SP : Segundo Prefijo.
_ : Separador.
NO : Nombre del objeto de la base de datos.
Primer Prefijo: Identificar el tipo del objeto de la base de datos, estar

conformada por una una letra y sern las siguientes:
232 | P g i n a
V : Vista.
P : Procedimiento Almacenado.
T : Trigger.
Segundo Prefijo: Identificar el subtipo del objeto de la base de datos,

estar conformada por dos letras que en el caso de ser una sola palabra
(por ejemplo: Maestro) tomar las dos primeras letras y en el caso de
que el nombre sea una palabra compuesta (por ejemplo: Sub Detalle)
tomar la letra inicial de cada palabra.
Los objetos tipo procedimiento no tendrn segundo prefijo.
Los prefijos identificados son:
MA : Maestro. Objeto con informacin especifica.

CA : Cabecera. Objeto con informacin que necesariamente va a
tener detalle.
DE : Detalle. Objeto con informacin de detalle de un objeto tipo
cabecera.
SD : SubDetalle. Objeto con informacin de detalle de un objeto
tipo detalle.
VI : Vnculo. Objeto de informacin que contiene datos de dos o
ms objetos. Es la que permite romper una relacin de
muchos a muchos.
CT : Contenedor. Objeto que contiene datos que sern
explotados.
CO : Control. Objeto de informacin que contiene datos que sern
accesados continuamente para controlar la serializacin.
PA : Parmetro. Objeto con informacin de Parmetros que
configuren el sistema.
TR : Transaccin. Objeto con informacin procesada de otros
objetos. Transacciones o movimientos.
HI : Histrico. Objeto con informacin histrica.
IN : Objeto que define una insercin.
AC : Objeto que define una actualizacin.
233 | P g i n a
EL : Objeto que define una eliminacin.
Nombre del Objeto: Sern sustantivos en singular y verbos no

conjugados en infinitivo.
Un objeto tipo Tabla o V (Vista) puede tener los siguientes subtipos: CO,
CT, MA, DE, SD, VI, PA, TR, HI.
Un objeto tipo T (Trigger) puede tener los siguientes subtipos: IN, AC,
EL.
El nombre de una Tabla (T) ser un sustantivo en singular.
El nombre de un Procedimiento (P) estar compuesto por verbos y

sustantivos evitando el uso de enlaces.
234 | P g i n a
CAPITULO VI:
ADMINISTRACIN DEL PROYECTO
235 | P g i n a
6.1. Estructura Detallada del Trabajo (EDT)
Un EDT es la agrupacin orientada a entregables de los elementos del proyecto
que organiza y define el total de los alcances del proyecto. Cada nivel
descendiente representa una definicin mas detallada del trabajo del proyecto.
La EDT es una herramienta muy comn y crtica en la gestin de proyectos.
El propsito de una EDT es documentar el alcance del proyecto. Su forma

jerrquica permite una fcil identificacin de los elementos finales. Siendo un
elemento exhaustivo en cuanto al alcance del proyecto, la EDT sirve como la
base para la planificacin del proyecto. Todo trabajo a ser hecho en el proyecto
debe poder rastrear su origen en una o ms entradas de la EDT.
A continuacin presentar el EDT en forma tabular que utilic en la gestin del

proyecto:
Id Cdigo EDT EDT

14 abr '08 21
D L
0
0 TESIS: SISTEMA DE INFORMACIN PARA EL CONTROL, SEGUIMIENTO Y MA
1 1 INICIO DEL DESARROLLO DEL PLAN DE TESIS
2 1.1 Recepcin de Informacin en la Oficina de Grados y Titulos con respecto a las modalidades de Tesis
3 1.2 Planteamiento del Tema de Tesis a desarrollar
4 1.3 Definicin del Titulo de la Tesis
5 1.4 Coordinacion con el Asesor de la Tesis y con el Director de la Escuela de Ingeniera Informtica
6 1.5 Levantam iento de la Inform acin necesaria para el Desarrollo de la Tesis
7 1.5.1 Investigacin Bibliografica
8 1.5.2 Recoleccin de la Informacin Terica
9 1.5.3 Recoleccin de la Informacin Tcnica
10 1.5.4 Organizacin de la Informacin
11 1.5.5 Anlisis y Procesamiento de la Informacin
12 1.5.6 Finalizacin del Levantamiento de la Informacin
13 1.6 Elaboracin del Inform e del Plan de Tesis
14 1.6.1 Elaboracin y Redaccin del Esquema de Tesis a Desarrollar
15 1.6.2 Redaccin del Informe del Plan de Tesis
16 1.6.3 Impresin y Anillado del Informe del Plan de Tesis
17 1.6.4 Finalizacin del Informe del Plan de Tesis
18 1.7 Revision del Plan de Tesis por parte del Asesor
19 1.8 Entrega del Plan de Tesis a la Oficina de Grados y Titulos de la Facultad
20 1.9 Aprobacion del Plan de Tesis Propuesto
236 | P g i n a
d Cdigo EDT EDT
14 abr '08
D
1 2 INICIO DEL DESARROLLO DEL PROYECTO DE TESIS
2 2.1 Revisin y Adaptacin del Esquema de Tesis a aplicar
3 2.2 Elaboracin de la Caratula del Informe de Tesis
4 2.3 Elaboracin de la Dedicatoria y Agradecimientos
5 2.4 Elaboracin y Redaccin del Resumen y Abstract
6 2.5 Redaccin del Indice de Contenidos, de Figuras y de Tablas
7 2.6 Elaboracin y Redaccin de la Introduccin
8 2.7 Desarrollo del Capitulo 1 - Planteamiento del Problema
9 2.7.1 Elaboracin del Planteamiento del Problema de Investigacin
0 2.7.2 Delim itacion del Problem a de Investigacin
3 2.7.3 Formulacin del Problema de Investigacion
4 2.7.4 Definicion de los Objetivos de la Tesis
7 2.7.5 Form ulacin de la Hiptesis
9 2.7.6 Seleccin de Variables
2 2.7.7 Definicion de la Lnea de Investigacin a la cual pertenece la Tesis
3 2.7.8 Justificacin e Importancia de la Investigacin
4 2.7.9 Definicion de los Alcances de la Investigacin
5 2.7.10 Revision Final del Desarrollo del Capitulo 1
6 2.8 Desarrollo del Capitulo 2 - Marco Teorico Conceptual
7 2.8.1 Busqueda y Revision de Informacin
8 2.8.2 Planteamiento y Redaccion de Antecedentes de la Investigacin
9 2.8.3 Elaboracion de las Bases Tericas
0 2.8.4 Redaccion del Diagnstico de la Situacin Actual de los Establecimientos del Sector Salud en el Peru
1 2.8.5 Redaccion del Diagnstico de la Situacin Actual del Hospital Central de la Fuerza Area del Peru
5 2.8.6 Busqueda y Redaccion del Marco Legal
7 2.9 Desarrollo del Capitulo 3 - Estado del Arte
8 2.9.1 Elaboracion de la Taxonoma
9 2.9.2 Revision de Mtodos y Metodologas
3 2.9.3 Revision de Softw are o Sistemas Existentes
8 2.10 Desarrollo del Capitulo 4 - Metodologa de la Investigacin
9 2.10.1 Definicion del Tipo de Investigacin
0 2.10.2 Definicion del Diseo de la Investigacin
1 2.10.3 Estimacion de la Poblacin
2 2.10.4 Definicion de la Muestra de Estudio
3 2.10.5 Definicion del Muestreo
4 2.10.6 Definicion de los Criterios de Seleccin
5 2.10.7 Revision de las Tcnicas e Instrumentos de Recoleccin de Datos
7 2.11 Desarrollo del Capitulo 5 - Contribucin (Concepcin, Anlisis, Diseo y Construccin del Sistema)
8 2.11.1 Concepcin
9 2.11.1.1 Desarrollo del Estudio de Factibilidad
3 2.11.1.2 Generalidades de la Aplicacin
6 2.11.1.3 Anlisis Comparativo Benchmarking
7 2.11.1.4 Elaboracin de los Estndares a utilizar
3 2.11.1.5 Fin de la Concepcin
237 | P g i n a
d Cdigo EDT EDT
14 abr '08 2
D L
94 2.11.2 Anlisis y Diseo
95 2.11.2.1 Elaboracin del Diagrama de los Actores del Sistema
96 2.11.2.2 Elaboracion del Diagrama de los Mdulos del Sistema
97 2.11.2.3 Elaboracin y Especificacin de los Casos de Uso del Sistema
98 2.11.2.4 Elaboracin de los Diagramas de Secuencia de los Casos de Uso
99 2.11.2.5 Diseo de la Base de Datos
00 2.11.2.6 Elaboracin del Diagrama de Componentes
01 2.11.2.7 Elaboracin del Diagrama de Despliegue
02 2.11.2.8 Elaboracin del Diagrama de Arquitectura de Capas
03 2.11.2.9 Elaboracin de las Interfases del Sistema (Prototipos)
04 2.11.2.10 Fin de Anlisis y Diseo
05 2.11.3 Construccin
06 2.11.3.1 Desarrollo del Sistem a por Mdulos
13 2.11.3.2 Implementacin de la Base de Datos
14 2.11.3.3 Fin de la Construccin
16 2.12 Desarrollo del Capitulo 6 - Administracin del Proyecto
17 2.12.1 Elaboracin de la Estructura Detallada del Trabajo
18 2.12.2 Elaboracin del Cronograma de Actividades
19 2.12.3 Anlisis de Riesgos del Proyecto
20 2.12.4 Descripcin de los Recursos
21 2.12.5 Descripcin del Presupuesto de Inversin del Proyecto
23 2.13 Desarrollo del Capitulo 7 - Conclusiones y Recomendaciones
24 2.13.1 Definicin y Redaccin de las Conclusiones
25 2.13.2 Definicin y Redaccin de las Recomendaciones
27 2.14 Elaboracin del Glosario de Trm inos
28 2.15 Elaboracin del Siglario
29 2.16 Redaccin de las Referencias Bibliogrficas
30 2.17 Incorporacin y Redaccin de Anexos
31 2.18 Finalizacin del Informe de Tesis
32 2.19 Impresin y Espiralado del Informe de Tesis (03 juegos o copias)
33 2.20 Entrega del Informe de Tesis al Director de Escuela y a los miembros del Jurado
34 2.21 Recepcion de Informes con las observaciones encontradas por los miembros del Jurado
35 2.22 Levantamiento de las observaciones encontradas por los miembros del Jurado
36 2.23 Impresin y Empastado del Informe Final de Tesis (04 juegos o copias)
37 2.24 Entrega del Informe Final de Tesis a la Oficina de Grados y Titulos de la Facultad
38 2.25 Elaboracion de la Presentacin Final para la Sustentacin de la Tesis
39 2.26 SUSTENTACIN FINAL DE LA TESIS
6.2. Cronograma de Actividades

Tambin se le conoce como Calendario de Actividades o Plan de Trabajo.
Se recomienda usar el Diagrama de Gantt, muy difundido en los ltimos aos.

Este diagrama es una cuadricula en las que se especifica grficamente el orden
de las actividades y la duracin de cada una de ellas.
238 | P g i n a
239 | P g i n a
240 | P g i n a
241 | P g i n a
242 | P g i n a
243 | P g i n a
6.3. Anlisis de Riesgos
El riesgo es un evento o condicin incierta, que si ocurre, tiene un efecto
positivo o negativo en por lo menos un objetivo del proyecto.
La identificacin de los riesgos en el proyecto involucra determinar lo que puede

afectar al desarrollo del proyecto, documentando sus caractersticas, de manera
que se pueda prevenir y disminuir el grado o nivel de riesgo.
El propsito de este anlisis es de controlar los riesgos que pueden afectar al

buen desarrollo del proyecto a lo largo de su periodo de vida.
A continuacin se identificarn los principales riesgos que pueden afectar el

desarrollo del proyecto:
Riesgos Categora Probabilidad Impacto Amortiguacin del Impacto
La estimacin del tamao del

1 software puede ser TP 35% 3 Definir alcances posibles de realizar.
significativamente alta.
La estimacin del software en

Tratar de que el nmero de
nmeros de programas, archivos y
2 TP 40% 3 programas, archivos y transacciones
transacciones puede ser
sea bajo.
significativamente alta.
Verificar si se ha realizado un
El tamao de la base de datos
correcto anlisis del diseo de las
3 creada o empleada por el software TP 45% 2
tablas y que cumpla con todas las
puede ser significativamente alto.
expectativas del software.
Realizar entrevistas y explicarle

Nivel de satisfaccin del usuario detalladamente al usuario final que
4 IN 35% 3
final. el sistema no perjudicar su labor
sino que le traer beneficios.
Tener una comunicacin directa con

Cambios significativos en los los usuarios finales para as
5 RC 40% 2
requerimientos. disminuir el riesgo de cambios en
los requerimientos.
Tratar de que los usuarios finales

Ausencia de participacin de los
6 RC 35% 3 participen durante el desarrollo del
usuarios.
software.
Riesgos del medio ambiente (Ej. Solicitar a los Departamentos y

7 PS 10% 3
Falta de informacin sobre polticas Secciones toda la informacin
244 | P g i n a
internas). concerniente a las polticas y
procedimientos internos del
Hospital.
Evaluar y probar la interconectividad
Riesgos de interconexin en la red
8 TC 10% 4 entre la arquitectura de red local y
LAN.
las PCs de los usuarios.
Falta de conocimiento de las Tener manuales sobre las

9 herramientas de programacin o ED 10% 3 herramientas usadas durante el
uso de nuevas tecnologas. proyecto.
Falta de disponibilidad de Tener un backup de los instaladores

10 herramientas de anlisis, diseo y ED 15% 3 de herramientas que se van a usar
programacin. durante el desarrollo del proyecto.
Realizar un cronograma adecuado

Capacitacin deficiente de los
11 PP 10% 4 de capacitacin del sistema para los
usuarios finales.
usuarios finales.
En las entrevistas, tomar apuntes de

todos los detalles requeridos por los
12 Poca recoleccin de informacin. RC 15% 3
usuarios sin omitir nada. Realizar
dichas entrevistas peridicamente.
El costo del proyecto supere el Elaborar bien el presupuesto para la

13 IN 45% 2
presupuesto. implementacin del sistema.
El sistema puede tener fallas Realizar las pruebas necesarias

14 durante su operacin y PP 20% 3 antes de que el sistema salga a
funcionamiento. produccin.
Configurar y realizar pruebas de
Problemas en la integracin de la
15 TC 25% 2 conexin entre la base de datos y el
Base de Datos y el Sistema.
sistema.
Se deber realizar el control y

seguimiento a los estndares
No tener un buen control de
16 PS 20% 3 empleados para la documentacin,
estndares.
anlisis, diseo y desarrollo del
proyecto.
Notificar a los Departamentos y

No contar con el apoyo de los Jefes
Secciones del Hospital que si no se
17 de Departamentos y Secciones del RC 20% 3
cuenta con el apoyo de ellos, el
HCFAP.
proyecto podra fracasar.
Coordinar previamente con la
Jefatura del Departamento, la
18 Falta de licencias de software. ED 45% 2 adquisicin de licencias de software
a utilizar para el desarrollo del
proyecto.
Escoger un servidor con las
caractersticas adecuadas para la
Servidor de aplicaciones
19 TC 35% 2 implantacin del sistema y adems
defectuoso.
que se encuentre en perfecto
estado.
245 | P g i n a
Contar con una capacitacin
Mala configuracin del Servidor
20 TC 30% 3 adecuada para una configuracin
Central.
ptima del servidor.
Tabla 50. Identificacin de los principales riesgos del proyecto. Fuente: Elaboracin Propia
Categoras de Riesgos:
1. Del Tamao del Producto (TP).
2. Del Impacto en el Negocio (IN).
3. Relacionados con el Cliente (RC).
4. Del Proceso (PS).
5. Tecnolgicos (TC).
6. Del Entorno de Desarrollo (ED).
7. Asociados con el Tamao de la Plantilla de Personal y su Experiencia (PP).
Valores de Impacto:
1. Catastrfico.
2. Crtica.
3. Marginal.
4. Despreciable.
6.4. Descripcin de los Recursos

Gerente de Proyecto
Un gerente de proyecto (tambin llamado director de proyecto o encargado de

proyecto) es la persona que tiene la responsabilidad total del planeamiento y la
ejecucin acertados de cualquier proyecto. Este ttulo se utiliza en la industria de
la construccin, la arquitectura, el desarrollo de software y diversas ocupaciones
que se basan en la generacin o manutencin de un producto.
El gerente de proyecto administra a los miembros del equipo, construye las

relaciones con los stakeholders, coordina las interacciones con los stakeholders,
planifica, administra y localiza recursos, formula prioridades y mantiene al equipo
enfocado.
246 | P g i n a
Administrador de Base de Datos
Es la persona responsable de los aspectos ambientales de la Base de Datos

(Recuperabilidad, Integridad, Seguridad, Disponibilidad, Desempeo, Desarrollo
y soporte de las pruebas).
Los deberes de un administrador de bases de datos dependen de la descripcin

del puesto, corporacin y polticas de Tecnologas de Informacin (TI). Por lo
general se incluye recuperacin de desastres (respaldos y pruebas de
respaldos), anlisis de desempeo y optimizacin, y algo de asistencia en el
diseo de la base de datos.
Desarrollador o Programador
Es aquel individuo que ejerce la programacin, es decir, que escribe programas

de computadora. Los desarrolladores de software tambin reciben el nombre de
programadores.
Esta persona puede contribuir a la visin general del proyecto ms a nivel de

aplicacin que a nivel de componentes o en las tareas de programacin
individuales.
Analista Diseador
Es aquel individuo que ejerce las tareas de anlisis y diseo de los sistemas
informticos, con el fin de automatizarlos.
Encargado de crear y evolucionar los modelos; provee el diseo del sistema a

construir.
Documentador
Es la persona encargada de realizar todo tipo de documentacin concerniente al

proyecto que se est realizando.
Entre los documentos que realiza, se encuentran: Acta del Proyecto,

Especificaciones de los Casos de Uso, Manuales del Sistema, entre otros.
247 | P g i n a
6.5. Presupuesto de Inversin
En este punto se muestra la totalidad de gastos que se generaron durante el
desarrollo del proyecto de investigacin.
El presupuesto que se estima comprender la elaboracin, digitacin, desarrollo

del software, reproduccin y presentacin de la Tesis, incluyendo el pago de
derechos administrativos establecidos por la Universidad Ricardo Palma. Se
calcula que ascender a un monto de S/. 15,000.00
CONCEPTOS COSTO (S/.)

a) Desarrollo del Software:
Concepcin, Anlisis, Diseo y Construccin del 12,427.00
Software (Segn tcnica COSYSMO).
b) Bienes:
Material Bibliogrfico 200.00
Material de Escritorio 150.00
c) Servicios:
Fotocopias 120.00
Impresiones 400.00
Empastado y Espiralado 150.00
Movilidad local y otros 300.00
d) Gastos Acadmicos:
Solicitud Simple 5.00
Concepto de Titulo Profesional 1,230.00
Concepto de Caligrafiado 21.00
Copia Legalizada del Diploma de Bachiller 12.00
Fotos tamao pasaporte 5.00
Partida de Nacimiento Original 15.00
INVERSION TOTAL DEL PROYECTO S/. 15,035.00

Tabla 51. Identificacin de los gastos durante el desarrollo del proyecto. Fuente: Elaboracin Propia
248 | P g i n a
CAPITULO VII:
CONCLUSIONES Y
RECOMENDACIONES
249 | P g i n a
7.1. Conclusiones
El mantenimiento es considerado hoy en da un factor estratgico, por ello
que el Hospital Central de la FAP aspira a ser mas competitivo y eficiente,
adoptando tcnicas y sistemas que le permitan tener organizada y
actualizada esa gran cantidad de informacin para llevar a cabo una buena
gestin del mismo.
La aplicacin de un Programa de Mantenimiento Preventivo y/o Correctivo,

tiene un impacto directo en la ptima utilizacin de la vida til de los equipos,
en la continuidad de los procesos, en alcanzar los ms altos niveles de
seguridad y confiabilidad y por lo tanto en la reduccin de los gastos de
operacin.
Las herramientas de los sistemas informticos son de gran ayuda para el

seguimiento y programacin de las actividades a realizarse, a la vez permite
desarrollar cada historial del equipamiento. Con la informacin recabada se
pueden tener una serie de resultados e indicadores que permitan evaluar la
gestin del mantenimiento.
La implementacin de un sistema de informacin para la planificacin de los

trabajos de mantenimiento, as como para el control de los inventarios del
equipamiento hospitalario, permitir mejorar la gestin de inventarios con el
consiguiente beneficio del aumento en el cumplimiento de la programacin
de tareas de mantenimiento, lo que permitir evitar reparaciones costosas y
perdidas de tiempo por la falta de disponibilidad de equipos.
El sistema va a permitir a los departamentos y secciones del Hospital Central

de la FAP gestionar sus solicitudes de rdenes de trabajo de manera directa
a travs del sistema, as de esta manera se agilizar y reducir el tiempo de
atencin de dichas rdenes, se llevar una mejor administracin de los
inventarios de los equipos hospitalarios y tambin permitir llevar un mejor
control del estado en la que se encuentran las rdenes de trabajo generadas
por los usuarios.
250 | P g i n a
El sistema se convertir en una herramienta de mejora continua para el
Departamento, debido a las oportunidades de identificar y revelar problemas
en la gestin de inventarios as como identificar las irregularidades de los
componentes y la prevencin del deterioro de los equipos hospitalarios antes
que estos fallen interrumpiendo su normal funcionamiento con los pacientes.
El sistema crear un ambiente de trabajo en el que interactuarn las reas

administrativas y hospitalarias del HCFAP, as como las secciones y
divisiones del Departamento de Ingeniera, facilitando el intercambio de
informacin, orientado a beneficiar a todos los usuarios del Hospital.
El sistema de informacin de mantenimiento se encargar de informar

oportunamente sobre las operaciones de mantenimiento que deben
realizarse al da, generando historiales y midiendo el desempeo de las
operaciones de mantenimiento y tomar acciones para mejorarlas.
251 | P g i n a
7.2. Recomendaciones
Las Recomendaciones que se muestran a continuacin son de suma
importancia para el xito en el desarrollo y la implementacin de un sistema para
el control, seguimiento y mantenimiento del equipamiento hospitalario. Por esto
se recomienda a cualquier Hospital que quiera implementar un sistema de
gestin de mantenimiento hospitalario seguir las siguientes recomendaciones:
La primera presentacin del sistema, por parte de los altos mandos, debe
estar dirigida a la concientizacin del personal involucrado en su
implementacin; mostrndoles los beneficios pero sin dejar de solicitar el
compromiso para el cambio.
El xito de la implementacin del sistema de mantenimiento estar en manos

del personal operario, por lo tanto se recomienda realizar las reuniones que
se considere necesarias ya sea para capacitarlos o para disipar cualquier
duda que se le pueda presentar durante la implementacin.
Se debern codificar los equipos de la manera ms simple para facilitar el

entendimiento de cdigos y facilidad en la bsqueda de los equipos por
cdigo.
La exactitud de los datos, as como la actualizacin constante de los mismos

por todas y cada una de las reas, deber ser una obligacin para el xito del
sistema.
Continuar con las actualizaciones del presente sistema de informacin una

vez implementado, principalmente para optimizar aun ms dichos procesos.
Asimismo el aplicativo debera, en una siguiente etapa, no solamente pueda

accederse a travs de la red interna del Hospital; sino, pueda tambin
accederse va web por el personal y por los proveedores del Hospital.
252 | P g i n a
8. GLOSARIO DE TERMINOS
1. Caso de Uso
Tcnica para la captura de requisitos potenciales de un nuevo sistema o una
actualizacin de software. Cada caso de uso proporciona uno o ms
escenarios que indican cmo debera interactuar el sistema con el usuario o
con otro sistema para conseguir un objetivo especfico.
2. Categora
Tipo de establecimientos de salud que comparten funciones, caractersticas y
niveles de complejidad comunes, los cuales responden a realidades socio-
sanitarias similares y estn diseados para enfrentar demandas
equivalentes.
Es un atributo de la oferta, que debe considerar el tamao, nivel tecnolgico

y la capacidad resolutiva cualitativa y cuantitativa de la oferta.
3. Concurrencia
Es la propiedad de los sistemas que permiten que mltiples procesos sean
ejecutados al mismo tiempo, y que potencialmente puedan interactuar entre
s.
4. Equipos Biomdicos
Son equipos hospitalarios electrnicos de alto costo que conforman el mayor
bien tangible dentro de un hospital o clnica. El equipamiento biomdico se
ha convertido en uno de los pilares de los sistemas de salud pues contribuye
con los profesionales de la salud en la prevencin, diagnostico, tratamiento y
rehabilitacin de las enfermedades, ayudando de esta manera a brindar a la
poblacin una atencin de salud con calidad, eficacia y seguridad. Ejemplos
de algunos equipos biomdicos: Ecgrafos Doppler, Maquinas de Anestesia,
Cmaras Gamma, Equipos de Rayos X, Electrocardigrafos, Esterilizadoras,
Incubadoras, Mamgrafos, Equipos de Resonancia Magntica, etc.
253 | P g i n a
5. Equipos Electromecnicos
Este tipo de equipamiento de naturaleza elctrica-mecnica forma parte de la
familia de equipos hospitalarios, ya que de alguna u otra manera se
encuentran instaladas en cualquier local, infraestructura y/o instalacin
hospitalaria. La mayor parte de estos equipos tienen como funcin principal
mantener de una manera adecuada las diferentes instalaciones de un
hospital. Ejemplos de algunos equipos electromecnicos: Calderos,
Lustradoras, Aspiradoras, Marmitas, Estufas Elctricas, Equipos de Aire
Acondicionado, Extractores de Aire, etc.
6. Equipos Hospitalarios
Son todos aquellos equipos electrnicos, mecnicos y electromecnicos que
forman parte de un hospital, clnica o centro medico y se utilizan
directamente en la atencin mdica del paciente.
Este tipo de equipos requiere de un mantenimiento especializado debido a

que son de estructura interna compleja y a su vez son equipos de alto costo
de reparacin y/o mantenimiento.
7. Equipos Mdicos
Son equipos hospitalarios de naturaleza electrnica-mecnica que a
diferencia de los equipos biomdicos, estos son de menor costo en la
mayora de los casos. Algunos de estos equipos suelen tener corto periodo
de vida, tanto as que algunos de ellos son desechables. Ejemplos de
algunos equipos mdicos: Estetoscopios, Tensiometros, Aspiradores
porttiles y empotrados, Balanzas, Resucitadores, etc.
8. Establecimiento de Salud
Constituye la Unidad Operativa de la oferta de servicios de salud, clasificada
en una categora e implementada con recursos humanos, materiales y
equipos, encargada de realizar actividades asistenciales y administrativas
que permiten brindar atenciones sanitarias ya sean preventivas,
254 | P g i n a
promocionales, recuperativas o de rehabilitacin tanto intramural como
extramural, de acuerdo a su capacidad resolutiva y nivel de complejidad.
9. Ficha Tcnica (Hojas de Vida de los Equipos)

La Ficha Tcnica de Equipos es un documento oficial de importancia dentro
de la Administracin del Hospital Central FAP, permite identificar las
caractersticas y datos ms importantes del equipo y de sus componentes, a
la vez proporciona conocimientos sobre informacin de su origen,
fabricacin, vida til, ubicacin, controles de operacin y proteccin para
apoyar las acciones de mantenimiento y reparacin.
Las Fichas Tcnicas u Hojas de Vida de los equipos garantizarn un

adecuado inventario de los diferentes elementos, lo cual facilitar el manejo
de los mismos y su mantenimiento.
10. Informe Tcnico

El Informe Tcnico, es el documento de importancia en la labor diaria del
departamento de ingeniera siendo empleado en:
Primer lugar, cuando dada la solicitud de una orden de trabajo, la reparacin

del equipo hospitalario supera el 50% del valor real del mismo de acuerdo
con lo indicado en el inventario de bienes patrimoniales del hospital.
Segundo lugar, cuando la reparacin del equipo hospitalario, dado su

antigedad resulta reparable pero con recomendaciones en su empleo.
Tercer lugar cuando el solicitante, solicita la baja del equipo del inventario
respectivo, describiendo las apreciaciones para tal caso.
11. Instalaciones
Son el conjunto de elementos que integran la infraestructura fsica del
hospital, determinados por las Estructuras, Instalaciones Elctricas,
Instalaciones Sanitarias e Instalaciones Mecnicas y Especiales (vapor,
255 | P g i n a
oxigeno, gases especiales y equipos de apoyo: grupos electrgenos,
motobombas, etc.).
12. Instrumental Mdico

Se denomina instrumental medico a todo suministro o accesorio que forma
parte del grupo de instrumentos que el profesional de la salud utiliza de
manera continua en una intervencin quirrgica. Ejemplos de instrumentales
mdicos: Pinzas, bisturs, vlvulas, esptulas, jeringas, cubetas, tijeras
quirrgicas, etc.
13. Mantenimiento de Precisin

Este tipo mantenimiento procura realizar bien un trabajo desde la primera vez
que se efectu, para evitar problemas posteriores, a lo cual se le llama
trabajar segn la filosofa de la precisin en el trabajo (Mantenimiento de
Precisin); que segn los ejemplos anteriores no solo equivaldra a
monitorear un rodaje, sino desde el momento que se hace el cambio, el
montaje debe ser preciso en cuando al mtodo de montaje, colocacin de las
tolerancias adecuadas, etc. Y todo lo que involucre "un buen montaje" del
rodamiento.
Segn esta filosofa de trabajo, que exige un poco ms del personal de

mantenimiento; lo cual tambin implica una mejor capacitacin. Los costos
de mantenimiento se pueden bajar considerablemente.
14. Mantenimiento de Mejora Continua

Tal como hemos expuesto en los apartados anteriores, la evolucin lleva al
cambio. Todo est cambiando permanentemente, nada permanece igual. No
es fcil de percibir el cambio y menos cuando nos encontramos satisfechos
con nuestra situacin actual, de ah que la percepcin y direccin del cambio,
constituya una de las principales habilidades directivas y a la que cada vez
se da valor con mayor intensidad.
256 | P g i n a
Pero no es suficiente percibir el cambio, hay que prepararse adecuadamente
en todos los aspectos, para aceptar el reto que origina el mismo.
15. Modelo de Atencin de Salud (MAIS)

Es el marco conceptual de referencia que define el conjunto de polticas,
componentes, sistemas, procesos e instrumentos que operando
coherentemente garantizan la atencin a la persona, familia y comunidad,
para satisfacer sus necesidades de salud (Necesidades reales percibidas o
no por la poblacin).
16. rdenes de Trabajo

La Orden de Trabajo es el documento fuente de gestin de las operaciones
de mantenimiento y reparacin de equipos e instalaciones, mediante la cual
se solicita, autoriza y registra su ejecucin; a su vez, sirve de requerimiento
de equipos e instalaciones hospitalarias y servicios del mantenimiento
respectivo.
17. Ordenes de Trabajo para Terceros

La Orden de Trabajo para Terceros es el documento de gestin de las
operaciones de mantenimiento y reparacin de equipos e instalaciones
realizados por una Empresa o Compaa Especializada.
18. Portabilidad
Caracterstica que posee un software para ejecutarse en diferentes
plataformas, el cdigo fuente del software es capaz de reutilizarse en vez de
crearse un nuevo cdigo cuando el software pasa de una plataforma a otra.
19. Procedimientos de Aplicacin

Son las acciones que se utilizan para ejecutar los procedimientos de
mantenimiento preventivo.
257 | P g i n a
20. Programa de Mantenimiento Preventivo
Es la relacin de acciones que se deben ejecutar cronolgicamente para
evitar el deterioro y paralizacin del bien
21. Registro Histrico de Equipos

El Registro Histrico de Equipos es un formato creado para almacenar la
informacin de las actividades de mantenimiento y reparacin de los equipos
hospitalarios; para posteriormente seleccionar y reportar esa informacin fcil
y ordenada.
22. Sistema de Informacin

Se denomina Sistema de Informacin al conjunto de procedimientos
manuales y/o automatizados que estn orientados a proporcionar
informacin para la toma de decisiones.
Conjunto de programas, procedimientos, reglas y documentos asociados

necesarios para hacer funcionar un sistema de tratamiento de la informacin.
Utilizase tambin el trmino ingls original software.
23. Transaccin
Es una interaccin con una estructura de datos compleja, compuesta por
varios procesos que se han de aplicar uno despus del otro. La transaccin
debe ser equivalente a una interaccin atmica.
24. Unidad Productora de Servicios de Salud

Es la unidad bsica de la oferta constituida por el conjunto de recursos
humanos, fsicos y tecnolgicos, organizados para desarrollar funciones
homogneas y producir determinados servicios de salud, en relacin directa
con su complejidad.
La existencia de Unidades Productoras de Salud es uno de los factores ms

importantes para la determinacin de la categora de los establecimientos de
salud.
258 | P g i n a
9. SIGLARIO
ACM : Association for Computing Machinery (www.acm.org).
ADOO : Anlisis y Diseo Orientado a Objetos.
AM : Agile Modeling (Modelado gil).
ASD : Adaptive Software Development (Desarrollo de Software Adaptado).
AUP : Agile Unified Process (Proceso Unificado gil).
CAASST : Comit Andino de Autoridades en Seguridad y Salud en el Trabajo.
CASE : Computer Aided Software Engineering (Ingeniera de Software

Asistida por Ordenador).
CDM : Constructionist design methodology (Metodologa de Diseo

Construccionista).
CMMS : Computerized Maintenance Management System (Sistema de

Gestin de Mantenimiento Computarizado).
COCOMO : Constructive Cost Model (Modelo Constructivo de Costos).
COSYSMO : Constructive Systems Engineering Cost Model (Modelo Constructivo

del Costo de la Ingeniera de Sistemas).
CRC : Tarjetas Clase-Responsabilidad-Colaboracin. Son una

metodologa para el diseo de software orientado por objetos.
CUS : Casos de Uso del Sistema.
259 | P g i n a
DBMS : Database Management System (Sistema de Gestin de Base de
Datos).
DISAN : Direccin de Sanidad de la Fuerza Area del Per.
DLL : Dynamic Link Library (Biblioteca de Enlace Dinmico).
DM : Decreto Ministerial.
DOO : Diseo Orientado a Objetos.
DSDM : Dynamic Systems Development Method (Mtodo de Desarrollo de

Sistemas Dinmicos).
DVD : Digital Versatile Disc (Disco Digital Verstil).
E : Effort (Esfuerzo Horas-Persona).
EDT : Estructura Detallada del Trabajo.
EF : Environment Factor (Factor de Ambiente).
EUP : Enterprise Unified Process (Proceso Unificado Empresarial).
EVO : Evolutionary Project Management (Gestin de Proyectos

Evolutivos).
FAP : Fuerza Area del Per.
FDD : Feature Driven Development (Desarrollo manejado por rasgos).
FFT : Fast Fourier Transform (Transformada rpida de Fourier).
FOSFAP : Fondo de Salud de la Fuerza Area del Per.
260 | P g i n a
GUI : Graphical User Interface (Interfaz Grfica de Usuario).
HCFAP : Hospital Central de la Fuerza Area del Per.
HNDAC : Hospital Nacional Daniel Alcides Carrin.
IBM : International Business Machines.
INEN : Instituto Nacional de Enfermedades Neoplsicas.
ISA : Instituto de Salud de Aeronutica.
ISOFAP : Instituto de Salud Oral de la Fuerza Area del Per.
IT : Informe Tcnico.
JAD : Joint Application Development (Desarrollo Conjunto de

Aplicaciones).
LAN : Local Area Network (Red de rea Local).
LSD : Lean Software Development (Desarrollo de Software Lean).
MA : Mtodos Agiles.
Mbps : Megabit por segundo.
MINSA : MInisterio de Salud del Per.
OMG : Object Management Group (Grupo de Gestin de Objetos).
OOP : Object Oriented Programming (Programacin Orientada a Objetos).
261 | P g i n a
OS : Operating System (Sistema Operativo).
OT : Orden de Trabajo.
PAAC : Plan Anual de Adquisiciones y Contrataciones.
PC : Personal Computer (Computadora Personal).
PDA : Personal Digital Assistant (Asistente Personal Digital).
PIA : Presupuesto Institucional de Apertura
PNP : Polica Nacional del Per.
POI : Plan Operativo Institucional.
PRONIEM : Programa Nacional de Infraestructura, Equipamiento y

Mantenimiento.
RAD : Rapid Application Development (Desarrollo Rpido de

Aplicaciones).
RAM : Random Access Memory (Memoria de Acceso Aleatorio).
RM : Resolucin Ministerial.
ROP : Rational Objectory Process.
RUP : Rational Unified Process (Proceso Unificado Racional).
SADT : Structured Analysis and Design Technique (Tcnica de Anlisis y

Diseo Estructurado).
SISAN : Sistema de Sanidad de la Fuerza Area del Per.
262 | P g i n a
SOP : Sala de Operaciones del HCFAP.
SSADM : Structured Systems Analysis and Design Methodology (Metodologa

de Anlisis y Diseo de Sistemas Estructurados).
TCF : Technical Complexity Factor (Factor de Complejidad Tcnica).
TCP/IP : Protocol / Internet Protocol.
TI : Tecnologas de la Informacin.
UAW : Unadjusted Actor Weights (Peso de los Actores sin Ajustar).
UCI : Unidad de Cuidados Intermedios del HCFAP.
UCP : Use Case Point (Puntos de Casos de Uso Ajustados).
UML : Unified Modeling Language (Lenguaje Unificado de Modelado).
UTI : Unidad de Tratamientos Intensivos del HCFAP.
UUCP : Unadjusted Use Case Points (Puntos de Casos de Uso sin Ajustar).
UUCW : Unadjusted Use Case Weight (Peso de los Casos de Uso sin
Ajustar).
VFSM : Virtual Finite State Machine (Mquina de Estado Finito Virtual).
VHS : Video Home System. Sistema de grabacin y reproduccin

analgica de audio y video.
XP : Extreme Programming (Programacin Extrema).
263 | P g i n a
10. REFERENCIAS BIBLIOGRAFICAS
10.1. Libros y Revistas
[1] ABRAHAMSSON P., SALO O., RONKAINEN J., WARSTA J. Agile

software development methods Review and analysis. VTT Publications
2002.
[2] BARDRAM J. E. y BOSSEN C. A web of coordinative

artifacts: collaborative work at a hospital ward. Conference on Supporting
Group Work. Journal of ACM, pp. 168-176, Sanibel Island, Florida, USA,
2005.
[3] BECK K. Extreme Programming Explained. Embrace Change. Pearson

Education, 1999.
[4] BECK K. Extreme Programming. Addison Wesley, 2000.
[5] BENGU G. y ORTIZ J. A systems simulation approach to integrate

maintenance operations. Winter Simulation Conference. Journal of ACM,
pp. 677-687, Phoenix, Arizona, United States, 1991.
[6] BENNETT K. y RAJLICH V. Software maintenance and evolution: a

roadmap. International Conference on Software Engineering. Journal of
ACM, pp. 73-87, Limerick, Ireland, 2000.
[7] BRYAN CONSULTORIA HOSPITLARIA, CONTROL LOGISTICS SYSTEM.

Sistema Integrado de Gestin de Ingeniera y Mantenimiento Hospitalario,
pp. 55. Espaa. 1996.
[8] COAD P., LEFEBVRE E., DE LUCA J. Java Modeling in Color with UML:
Enterprise Components and Process. Prentice Hall. 1999.
[9] COCKBUN A. Agile Software Development. Addison-Wesley. 2001.
[10] CONTRERAS, L., MODI, C. y PENNATHUR A. Warehousing and

inventory management: integrating simulation modeling and equipment
condition diagnostics for predictive maintenance strategies -a case study.
Winter Simulation Conference. Journal of ACM, pp. 1289-1296, San Diego,
California, 2002.
[11] HOLLAND R. A simulation study of a multi-channel queueing system in the

hospital environment. Winter Simulation Conference. Journal of ACM, pp.
279-290, Los Angeles, California, United States, 1969.
[12] HOPKINS D., WESTBROOK T. y HENCKELL M. Web-based work order

system for tracking, reporting, and solving it issues. User Services
Conference. Journal of ACM, pp. 173-174, Orlando, Florida, USA, 2007.
264 | P g i n a
[13] JEFFRIES R., ANDERSON A., HENDRICKSON C. Extreme Programming
Installed. Addison-Wesley. 2001.
[14] KRUCHTEN P. The Rational Unified Process: An introduction. Addison

Wesley, 2000.
[15] LIEBERHERR, Karl J. y ORLEANS, Doug. Preventive program

maintenance in Demeter/Java. International Conference on Software
Engineering. Journal of ACM, pp. 604-605, Boston, Massachusetts, United
States, 1997.
[16] LIENTZ B. P., SWANSON E.B. y TOMPKINS G. E. Characteristics of

application software maintenance. Communications of the ACM, Vol. 21,
No. 6, pp. 466-471, 1978.
[17] MANIVANNAN S. y BANKS J. Towards a realtime knowledge-based

simulation system for diagnosing machine tool failure. Winter Simulation
Conference. Journal of ACM, pp. 603-608, New Orleans, Louisiana, United
States, 1990.
[18] MC CONNELL STEVE. Desarrollo y Gestin de Proyectos Informticos.

Ed. Mc Graw Hill, pp. 691. Espaa. 1997.
[19] MSPAS GTZ. Manual de Procedimientos Estandarizados para

Mantenimiento. Proyecto de Mantenimiento Hospitalario (PMH). EL
SALVADOR, 1998.
[20] MSPAS GTZ. Manual de Inventario Tcnico. 3a Edicin. Proyecto de

Mantenimiento Hospitalario (PMH), 1998.
[21] MSPAS GTZ. Gua Prctica para Elaboracin del Presupuesto de los
Departamentos de Mantenimiento de Hospitales Nacionales. Proyecto de
Mantenimiento Hospitalario (PMH). 1999.
[22] MSPAS GTZ. Manual de Mantenimiento Preventivo Planificado (MPP).

3 Edicin. Proyecto de Mantenimiento Hospitalario (PMH). 1998.
[23] MSPAS GTZ. Gua para el Diseo Ejecucin y Evaluacin de la

Capacitacin en un Departamento de Mantenimiento de los Servicios de
Salud. Proyecto de Mantenimiento Hospitalario (PMH), 1998.
[24] MULLER D., JACKMAN J. K. y FITZWATER C. A simulation-based work

order release mechanism for a flexible manufacturing system. Winter
Simulation Conference. Journal of ACM, pp. 599-602, New Orleans,
Louisiana, United States, 1990.
[25] PALMER S., FELSING M. A Practical Guide to Feature-Driven

Development. Prentice Hall, 2002.
265 | P g i n a
[26] Programa de Garanta de Calidad y Acreditacin. Manual de Estndares e
Indicadores de Servicios de Salud. Ed. Multiplicidades. Uruguay. 1996.
[27] RAY A. K. y MURTY M. S. S. N. Artificial intelligence techniques applied to

maintenance management. International conference on Industrial and
engineering applications of artificial intelligence and expert systems. Journal
of ACM, Vol. 1, pp. 112-118, Tullahoma, Tennessee, United States, 1989.
[28] Sistema de Garanta de Calidad de los Servicios de Salud. Gerencia

Central de Produccin de Servicios de Salud del IPSS. Per. 1998.
10.2. Pginas Web
[1] http://biomedica.webcindario.com/Mantenimiento.htm
[2] http://ciencias.nexo-virtual.com/course/info.php?id=109
[3] Software Terema CMMS, http://www.migalon.se/index.htm
[4] AMPRO CMMS, http://www.pemms.co.uk/ampro_cmms.html
[5] AMPRO CMMS, http://www.thirdcitysolutions.com/
[6] Bigfoot CMMS, http://www.pemms.co.uk/bigfoot_cmms.html
[7] Bigfoot CMMS, http://www.bigfootcmms.com/landing.asp
[8] Estructura de Descomposicin del trabajo,

http://es.wikipedia.org/wiki/Estructura_de_Descomposici%C3%B3n_del_Tr
abajo
[9] ndice de reas del motor de bsqueda de la ACM,

http://www.acm.org/about/class/
[10] Portal del Hospital Central FAP, http://hospi.fap.mil.pe/
[11] Puntos de Casos de Uso,

http://es.wikipedia.org/wiki/Puntos_de_caso_de_uso
[12] Ingeniera de Mantenimiento Hospitalario, http://www.mailxmail.com/curso-

ingenieria-mantenimiento-hospitalario
[13] El Hospital, http://es.wikipedia.org/wiki/Hospital
[14] Metodologa de Desarrollo de Software,

http://es.wikipedia.org/wiki/Metodologia_de_desarrollo_de_software
266 | P g i n a
[15] Mtricas y modelos en la Ingeniera del Software,
http://www.sc.ehu.es/jiwdocoj/mmis/cocomo.htm
[16] Estudio de Factibilidad de un Proyecto Informtico,

http://notasprisma.tripod.com/Proyectos.htm
[17] Factibilidad de una Investigacin,

http://www.mitecnologico.com/Main/FactibilidadInvestigacion
[18] La Nueva Metodologa. Martin Fowler, Chief Scientist, ThoughtWorks,

http://www.programacionextrema.org/articulos/newMethodology.es.html
[19] Metodologas de Desarrollo de Software,

http://latecladeescape.com/w0/ingenieria-del-software/metodologias-de-
desarrollo-del-software.html
[20] http://users.dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/ -
[21] Metodologas de Desarrollo de Software, http://www.pdf-search-

engine.com/metodologias-de-desarrollo-de-software-pdf.html
[22] Web oficial de RUP, http://www.rational.com/products/rup/
[23] Web oficial de UML, http://www.omg.org/uml/
[24] Extreme Programming, http://www.extremeprogramming.org
[25] http://www.xprogramming.com
[26] XP Roadmap, http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap
[27] Descarga del PDF descriptivo, http://thecoadletter.com/download/#fddguide
[28] ltimos avances de FDD, http://www.nebulon.com/articles/fdd/latestfdd.html
[29] http://www.featuredrivendevelopment.com/
[30] Enlaces sobre metodologas giles, http://www.agileprogramming.com
[31] Manifiesto gil, http://es.wikipedia.org/wiki/Manifiesto_gil
[32] Procesos de Desarrollo: RUP, XP Y FDD. Alberto Molpeceres,

www.javahispano.org
[33] Definicin de COSYSMO, http://cosysmo.mit.edu/
[34] COSYSMO, http://en.wikipedia.org/wiki/COSYSMO
267 | P g i n a
10.3. Tesis
Propuesta de un Sistema de Gestin de Mantenimiento en una Empresa

Productora de Alimentos de Consumo Masivo. Universidad Peruana de
Ciencias Aplicadas, Facultad de Ingeniera, Carrera de Ingeniera Industrial.
Autor: Mario Alvites Garca, Lima, Peru 2007.
Propuesta de un Sistema de Mantenimiento Preventivo y de Logstica para

Firth Industries Peru S.A. Universidad Peruana de Ciencias Aplicadas,
Escuela de Postgrado, Programa de Maestra en Gestin de Operaciones.
Autores: lvaro Mauricio Blancas Castro, Jorge Luis Rodrguez Gutirrez,
Lima, Per 2005.
Hospital Especializado Materno Infantil. Universidad Peruana de Ciencias

Aplicadas, Facultad de Arquitectura, Carrera de Arquitectura. Autor: Zuleika
Barreda Razuri. Lima, Per 2006
La Ingeniera Electrnica en los Equipos de Rayos X Hospitalarios.

Universidad Ricardo Palma, Facultad de Ingeniera. Autor: Alfredo
Hinostroza Perez. Lima, Per 2008
Tomografa Axial Computarizada. Universidad Ricardo Palma, Facultad de

Ingeniera, Escuela Profesional de Ingeniera Electrnica. Autor: Carlos
Almenara Daz. Lima, Per 2007
268 | P g i n a
ANEXOS
Anexo A: DESCRIPCIN DEL FORMATO DE ORDEN DE

TRABAJO
Anexo B: DESCRIPCIN DEL FORMATO DE SOLICITUD DE

SERVICIO
Anexo C: DESCRIPCIN DEL FORMATO DE INFORME

TCNICO
Anexo D: DESCRIPCIN DEL FORMATO DE FICHA TCNICA
Anexo E: DESCRIPCIN DEL FORMATO DE REGISTRO

HISTRICO
Anexo F: FORMATO DE ENCUESTA DE OPINION REALIZADA
269 | P g i n a
Anexo A
DESCRIPCIN DEL FORMATO DE ORDEN DE TRABAJO
1. Definicin de Orden de Trabajo (OT)

La Orden de Trabajo (OT) es el documento principal por donde empieza todas las
operaciones de mantenimiento y reparacin de equipos hospitalarios mdicos,
biomdicos y electromecnicos; mediante la cual se solicita, autoriza y registra su
ejecucin. Tambin sirve de requerimiento de equipos e instalaciones hospitalarias
y servicios del mantenimiento respectivo.
2. Llenado de la Orden de Trabajo

La Orden de Trabajo (OT) ser llenado segn numeracin en cada una de las
partes del documento citado, de la siguiente manera:
2.1 PARA SER LLENADO POR LA SECCION DE PROGRAMACION Y

CONTROL
(1) SECCION DE PROGRAMACION Y CONTROL

Para indicar el nmero correlativo que le corresponde como la fecha de
recepcin de la Orden de Trabajo en los registros de la oficina de
Programacin y Control.
2.2 PARA SER LLENADO POR EL DEPARTAMENTO Y/O SERVICIO

SOLICITANTE
(2) RAMA Y/O DEPARTAMENTO SOLICITANTE

Para indicar el nombre del Rama Mdica o Rama Administrativa y/o
Departamento del Hospital que solicita la Orden de Trabajo.
(3) AREA USUARIA: SECCION Y/O SERVICIO ASISTENCIAL

Para indicar el nombre del rea de la Rama y/o Departamento que es
responsable del uso o administracin directa del equipo o instalacin
materia de mantenimiento y reparacin.
270 | P g i n a
(4) UBICACIN FISICA (PISO)
Para indicar el lugar de uso o de ubicacin fsica (piso) donde se encuentra
el bien para el cumplimiento del servicio solicitado.
(5) ZONA
Indicado el piso anotar la zona en que se encuentra, es decir mencionar el
punto cardinal a que pertenece, ya sea: norte, sur, este y oeste.
(6) TELEFONO
Para indicar el nmero de telfono o anexo del departamento y/o servicio
solicitante, en caso se requiera informacin adicional de la falla del bien.
(7) CODIGO HOSPI

Para anotar el cdigo correspondiente del equipo o componente materia de
mantenimiento o reparacin.
(8) ITEM
Para indicar el nmero de item del equipo o del componente del mismo por
el cual solicitan el servicio de mantenimiento.
(9) DENOMINACIN DEL EQUIPO O INSTALACION

Para indicar el nombre del equipo o del componente del mismo, el cual
solicita el servicio de mantenimiento.
(10)MARCA
Para indicar el nombre de la marca del equipo o del componente del mismo
por el cual solicitan el servicio de mantenimiento.
(11)SERIE
Para indicar el nmero de serie del equipo o del componente del mismo por
el cual solicitan el servicio de mantenimiento.
(12)DESCRIPCION DE LA FALLA DE FUNCIONAMIENTO O PROBLEMA DE

PRODUCCION
Para indicar de manera clara, simple y concreta la falla o defecto que
presenta el equipo o componente para la realizacin del mantenimiento o
reparacin.
271 | P g i n a
(13)HORAS PROMEDIO DE PRODUCCION DIARIA DEL EQUIPO
Para anotar cuantas horas promedio est en funcionamiento el equipo o
componente a reparar, durante el da.
(14)NUMERO DE DIAS DE PRODUCCION DEL EQUIPO POR SEMANA

Para anotar cuantos das promedio est en funcionamiento el equipo o
componente a reparar durante la semana.
(15)FIRMA Y SELLO DE SOLICITANTE

Para la firma y sello de la Orden de Trabajo del jefe del departamento y/o
servicio que solicita el requerimiento de labores de mantenimiento o
reparacin de equipos o instalaciones hospitalarias.
(16)FECHA DE SOLICITUD
Para indicar la fecha en que realiza la solicitud de trabajo de
mantenimiento o reparacin de equipos.
(17)FIRMA Y SELLO DE CONFORMIDAD

Para que el jefe del departamento y/o servicio responsable del uso,
administracin o recepcin de equipo o instalacin, firme y selle dando su
visto bueno que la presentacin, funcionamiento y produccin del equipo o
instalacin es el indicado.
(18)FECHA DE CONFORMIDAD
Para indicar la fecha de ingreso del bien a uso y administracin del rea
usuaria, dando la conformidad del caso.
(19)CALIFICACIN DEL TRABAJO POR EL SOLICITANTE

Para indicar el nivel del trabajo realizado por el taller de Ingeniera, el cual
tiene 4 niveles: Optimo, Bueno, Regular y Malo.

CONTROL
ORDEN DE TRABAJO ASIGNADO AL TALLER DE:

Para indicar la designacin del Taller de Mantenimiento correspondiente, de
272 | P g i n a
acuerdo con el tipo de equipo o componente a realizar el trabajo de
2.4 PARA SER LLENADO POR EL TALLER DE MANTENIMIENTO
(20)DIAGNOSTICO TECNICO
Para indicar de manera tcnica la falla en el funcionamiento del bien
hospitalario, esto tiene por objeto determinar el motivo de las deficiencias
en el funcionamiento y/o recomendar su reposicin por estar descontinuado
o porque el mantenimiento o reparacin superan su valor en el mercado.
(21)PRIORIDAD
Para indicar la orden de atencin de los servicios de mantenimiento y
reparacin. Para este efecto el Taller de Mantenimiento deber tener en
cuenta los niveles de prioridad siguiente:
a) MUY URGENTE
Equipos e instalaciones que tienen la mayor y ms alta responsabilidad
en el servicio de atencin inmediata a pacientes; cuya demora o falta de
atencin inmediata puede poner en riesgo la vida.
b) URGENTE
Equipos e instalaciones que tienen la alta responsabilidad del
funcionamiento de otros equipos prioritarios; y los de funcionamiento
independiente que pertenecen a los dems servicios mdicos cuya
atencin de mantenimiento debe efectuarse por unidad fsica dentro de
un corto plazo.
c) PROGRAMABLE
Equipos e instalaciones en general cuya atencin de mantenimiento
puede ejecutarse dentro de un conjunto de actividades programadas o
de manera independiente en un mayor plazo de lo antes indicado.
(22)TECNICO A CARGO DEL TRABAJO

Para indicar el nombre del tcnico responsable de la accin de
273 | P g i n a
(23)FECHA MANTENIMIENTO
Para indicar la fecha a partir de la cual el taller asume la responsabilidad de
efectuar el mantenimiento o reparacin.
(24)DESCRIPCION DEL TRABAJO DE MANTENIMIENTO

Para indicar de manera clara, simple y precisa la labor de mantenimiento o
reparacin ejecutada por el taller de mantenimiento o servicios contratados,
Si el mantenimiento o reparacin sea efectuada por servicios contratados
se anexar a la Orden de Trabajo, el informe tcnico correspondiente.
(25)ESTADO DEL EQUIPO (RESULTADO)

Para indicar el resultado del trabajo de mantenimiento o reparacin del
equipo. Se tendr en cuenta los siguientes niveles:
a) OPERATIVO
El trabajo de mantenimiento o reparacin efectuado al equipo est en
perfecto estado de funcionamiento y productividad.
b) OPERATIVO CON RESTRICCIONES

El trabajo de mantenimiento o reparacin efectuado al equipo est en
funcionamiento pero con ciertas restricciones que afectan la
productividad del mismo.
c) INOPERATIVO
El trabajo de mantenimiento o reparacin efectuado al equipo a
determinado su para definitiva segn sea el caso.
(26)FUNDAMENTO DEL ESTADO (RESULTADO)

Despus de indicar el estado del equipo (resultado), se har una breve
descripcin para fundamentar lo anterior expuesto. En El caso de ser
INOPERATIVO, se argumentar con una de estas opciones:
1. Falta de repuesto.
2. No se determina el origen de la falla tcnica del equipo.
3. Reprogramacin por priorizacin.
274 | P g i n a
4. Generalizacin de daos.
5. Dado de baja.
(27)FECHA DE INICIO
Para indicar la fecha de inicio efectivo de las operaciones de
mantenimiento en las instalaciones del Hospital o del servicio contratado,
iniciando las horas de Para del Equipo.
(28)FECHA DE TRMINO
Para indicar la fecha de culminacin de las operaciones de mantenimiento
o reparacin, finalizando las horas de Para del Equipo.
(29)NOMBRE DE TERCEROS
Para indicar el nombre de la empresa que realiz la reparacin por servicio
contratado (terceros).
(30)NUMERO DE OT DE TERCEROS
Para indicar el nmero de Orden de Trabajo con la cual la empresa realiz
el trabajo, la cual es cargada en el sistema como un documento en el
mdulo de Orden de Trabajo
2.5 PARA SER LLENADO POR LA OFICINA DE PROGRAMACION Y CONTROL

CON DATOS PROPORCIONADOS POR EL TALLER DE MANTENIMIENTO
(31)REPUESTOS ACCESORIOS Y MATERIALES

Para indicar la cantidad, unidad de medida, descripcin o denominacin,
marca, valor unitario y valor total de los repuestos, accesorios y materiales
utilizados en la labor de mantenimiento o reparacin.
(32)MANO DE OBRA - RESPONSABLE(S)

Para indicar el nivel, especialidad, horas trabajadas por cada personal
empleado y el costo por mano de obra utilizada en la labor de
IMPORTE TOTAL: Para indicar los resultados de los totales de los rubros
correspondientes al aspecto material (31) y mano de obra (32) utilizada en
el servicio de mantenimiento o reparacin, de ser servicio contratado lo
275 | P g i n a
relativo al I.G.V. correspondiente.
(33)NOMBRE Y FIRMA SUPERVISOR CONTROL DE CALIDAD

Para la firma del Supervisor de los trabajos de mantenimiento o reparacin
realizados con recursos propios o contratados, en vista de ser responsable
de la supervisin e inspeccin de los trabajos realizados a los equipos e
instalaciones del Hospital.
(34)FECHA DE SUPERVISION
Para indicar la fecha en que el Supervisor realiz el control de calidad al
trabajo realizado.
(35)CALIFICACIN DEL TRABAJO POR EL SUPERVISOR - CC

Para indicar el nivel del trabajo realizado por el taller de Ingeniera, el cual
tiene 4 niveles: Optimo, Bueno, Regular y Malo.
(36)OBSERVACION DEL TRABAJO DEL SUPERVISOR - CC

Para indicar algn comentario sobre la calificacin dada en el item (35).
(37)VB PROCESAMIENTO (PROGRAMACION Y CONTROL)

Para la firma del Jefe de la Seccin de Programacin y Control para dar la
conformidad del servicio de mantenimiento o reparacin de equipos e
instalaciones hospitalarias, verificando que el servicio cumpla con los
requerimientos solicitados.
(38)FECHA DE VB
Para indicar la fecha en que el jefe de la Seccin de Programacin y
Control dio el visto bueno a la orden de Trabajo.
276 | P g i n a
(Lado 1)
DPTO.DEINGENIERIA
Seccin Prog. yControl
(LlenadoporProg. yControl)
1. N Da Mes Ao
2.Ramay/oDepartamentosolicitante:
ORDENDETRABAJO
(Paraserllenadoporladependenciasolicitante)
3.AREAUSUARIA:SECCIONY/OSERVICIOASISTENCIAL4.UBICACINFISICA(PISO) 5.ZONA 6.TELEFONO
7. CODIGOHOSPI 8. ITEM 9. DENOMINACIONDELEQUIPOOINSTALACIO

10
N. MARCA 11. SERIE
12. DESCRIPCIONDELAFALLADE FUNCIONEAMIENTOOPROBLEMADEPRODUCCION
13. HORASPROMEDIODEPRODUCCIONDIARIADELEQUIPO
14. NUMERODEDIASDEPRODUCCIONDELEQUIPOPORSEMANA
15. FIRMAYSELLOSOLICITANTE 16.FECHA 19. CALIFICACIONDELTRABAJOPORELSOLICITANTE

OPTIMO
CONFORMIDAD BUENO
17. FIRMAYSELLOSOLICITANTE 18.FECHA REGULAR
MALO
(ParaserllenadoporlaSeccindeProgramacinyControl)
OrdendeTrabajoASIGNADOALTALLERDE:
(Paraserllenadoporel TallerdeMantenimiento)
20. DIAGNOSTICOTECNICO 21. PRIORIDAD
MUYURGENTE
URGENTE
22.TECNICOACARGODELTRABAJO-RESPONSABLE 23. FECHAMANTENIM.
PROGRAMABLE
24. DESCRIPCIONDELTRABAJODEMANTENIMIENTO
25. ESTADODELEQUIPO(RESULTADO) 26. FUNDAMENTODELESTADO(RESULTADO)

a)OPERATIVO
b)OPERATIVOCONRESTRICCION
c)PENDIENTE
27. FECHADEINICIO 28.FECHATERMINO 29. NOMBREDETERCEROS 30. NUMERODEOTDETERCEROS
277 | P g i n a
(Lado 2)
COSTODELSERVICIO
(ParaserllenadoporlaSeccindeProgramacinyControl condatosproporcionados
porel TallerdeMantenimiento)
31. REPUESTOACCESORIOSYMATERIALES
CANTIDAD UNIDAD NOMBRE MARCA VALORUNIT.
TOTAL:
32. MANODEOBRA-RESPONSABLE(ES)
NIVEL NOMBREDELTECNICOYESPECIALIDAD HORASHOMBRE VALOR/HORA COSTOHOMBRE
TOTAL:
IMPORTETOTAL
TOTALREPUESTOACCESORIOS
TOTALMANODEOBRA
OTROS(TRANS.,VIATICOS,ETC)
TOTAL
33. NOMBREYFIRMASUPERVISOR-CONTROLDECALIDAD 34. FECHADESUPERVISION
CONTROLDECALIDAD
35. CALIFICACIONDELTRABAJOPORELSUPERVISOR-CC 36. OBSERVACIONDELTRABAJODELSUPERVISOR-CC
OPTIMO REGULAR
BUENO MALO
37. VBPROCESAMIENTO(PROGRAMACIONYCONTROL) 38. FECHADEVB
278 | P g i n a
Anexo B
DESCRIPCIN DEL FORMATO DE SOLICITUD DE SERVICIO
1. Definicin de Solicitud de Servicio

La Solicitud de Servicio es el documento por donde empieza todas las operaciones
de mantenimiento y reparacin de instalaciones y/o bienes patrimoniales, mediante
la cual se solicita, autoriza y registra su ejecucin.
2. Llenado de la Solicitud de Servicio

La Solicitud de Servicio ser llenada segn numeracin en cada una de las partes
del documento citado, de la siguiente manera:

CONTROL
(1) SECCION DE PROGRAMACION Y CONTROL

Para indicar el nmero correlativo que le corresponde como la fecha de
recepcin de la Orden de Trabajo en los registros de la oficina de
Programacin y Control.
2.2 PARA SER LLENADO POR EL DEPARTAMENTO Y/O SERVICIO

SOLICITANTE

Para indicar el nombre del Rama Mdica o Rama Administrativa y/o
Departamento del Hospital que solicita la Orden de Trabajo.
(3) AREA USUARIA: SECCION Y/O SERVICIO ASISTENCIAL

responsable del uso o administracin directa del equipo o instalacin
materia de mantenimiento y reparacin.
(4) UBICACIN FISICA (PISO)

279 | P g i n a
el bien para el cumplimiento del servicio solicitado.
(5) ZONA
(6) ANEXO
solicitante, en caso se requiera informacin adicional de la falla del bien.
(7) DESCRIPCION DEL TRABAJO SOLICITADO

Para indicar de manera clara, simple y concreta la falla o defecto que
presenta la instalacin o el bien patrimonial para la realizacin del
(8) FIRMA Y SELLO DE SOLICITANTE

Para la firma y sello de la Solicitud de Servicio por el Jefe del
Departamento y/o Seccin que solicita el requerimiento de labores de
mantenimiento o reparacin de instalaciones hospitalarias.
(9) FECHA DE SOLICITUD DE SERVICIO

Para indicar la fecha en que realiza la Solicitud de Servicio de
mantenimiento o reparacin de instalaciones hospitalarias.
(10)FIRMA Y SELLO DE CONFORMIDAD

Para que el Jefe del Departamento y/o Seccin responsable del uso,
administracin o recepcin de la instalacin, firme y selle dando su visto
bueno que la presentacin, funcionamiento y produccin de la instalacin
es el indicado.
Para indicar la fecha de ingreso del bien a uso y administracin del rea
usuaria, dando la conformidad del caso.
280 | P g i n a
CONTROL
SOLICITUD DE SERVICIO ASIGNADO AL TALLER DE:

Para indicar la designacin del Taller de Instalaciones correspondiente, de
acuerdo con el tipo de instalacin o bien patrimonial a realizar el trabajo de
2.4 PARA SER LLENADO POR EL TALLER DE INSTALACIONES
(12)ESPECIALISTA A CARGO DEL TRABAJO - RESPONSABLE

Para indicar el nombre del tcnico responsable de la accin de
(13)HORAS HOMBRE
Para indicar la cantidad de horas hombre que se utiliz en la reparacin y/o
mantenimiento del bien o instalacin hospitalaria.
(14)FECHA DE INICIO
Para indicar la fecha de inicio efectivo de las operaciones de reparacin y/o
mantenimiento en las instalaciones del Hospital.
(15)FECHA DE TERMINO
Para indicar la fecha de culminacin de las operaciones de reparacin y/o
mantenimiento en las instalaciones del Hospital.
(16)DESCRIPCION DEL TRABAJO REALIZADO

Para indicar de manera clara, simple y precisa la labor de mantenimiento o
reparacin ejecutada por el taller de instalaciones.
(17)MATERIAL E INSUMOS A REQUERIRSE

Para indicar la cantidad, unidad de medida, descripcin y cdigo comercial
de los materiales utilizados en la labor de mantenimiento o reparacin.
(18)NOMBRE Y FIRMA DEL JEFE DE INSTALACIONES

Para la firma del Jefe de la Seccin de Instalaciones, en vista de ser
responsable de la supervisin e inspeccin de los trabajos realizados a las
281 | P g i n a
instalaciones y bienes patrimoniales del Hospital.
(19)FECHA
Para indicar la fecha en que el Jefe de la Seccin de Instalaciones firm y
dio conformidad al trabajo realizado.
282 | P g i n a
DPTO.DEINGENIERIA
Seccin Prog. yControl
(LlenadoporProg. yControl)
1. N Dia Mes Ao
2. Ramay/oDepartamentosolicitante:
SOLICITUDDESERVICIO
(Paraserllenadoporladependenciasolicitante)
3. AREAUSUARIA:SECCIONY/OSERVICIOASISTENC 4IA
.U
LBICACINFISICA(PISO) 5. ZONA 6. ANEXO
7. DESCRIPCIONDELTRABAJOSOLICITADO
SOLICITANTE CONFORMIDAD
8. FIRMAYSELLOSOLICITANTE 9. FECHA 10. FIRMAYSELLOSOLICITANTE 11. FECHA
SolicituddeServicioASIGNADOALTALLERDE:
(Paraserllenadoporel TallerdeInstalaciones)
12. ESPECIALISTAACARGODELTRABAJO-RESPONSABLE13. HRS/HOMBRE 14. FECHADEINICIO 15. FECHADETERMINO
16. DESCRIPCIONDELTRABAJOREALIZADO
17. MATERIAL/ INSUMOSAREQUERIRSE

CANTIDAD MEDIDA NOMBRE CODIGOCOMERCIAL
18. NOMBREYFIRMADELJEFEDEINSTALACIONES 19. FECHA
283 | P g i n a
Anexo C
DESCRIPCIN DEL FORMATO DE INFORME TCNICO
1. Definicin de Informe Tcnico (IT)
Informe Tcnico es el documento que se emplea en primer lugar, cuando dada la

solicitud de una Orden de Trabajo, la reparacin del equipo hospitalario supera el
50% del valor real del mismo de acuerdo con lo indicado en el Inventario de Bienes
del Hospital Central FAP, en segundo lugar, cuando la reparacin del equipo
hospitalario, dado su antigedad, resulta reparable pero con restricciones en su
empleo, y en tercer lugar, cuando el solicitante requiere la baja del equipo del
Inventario de Bienes, sustentando el requerimiento de baja.
2. Llenado del Informe Tcnico
El Informe Tcnico ser llenado segn numeracin en cada una de las partes del
documento citado, de la siguiente manera:

CONTROL
(1) NUMERO Y FECHA

Se anotar el nmero correlativo y la fecha de recepcin que le
corresponde al Informe Tcnico.
(2) NOMBRE DEL EQUIPO

Para indicar el nombre especfico del equipo o instalacin, segn
nomenclatura del Inventario de Bienes del Hospital.

Para indicar el nombre de la Rama Mdica o Rama Administrativa y/o
Departamento del Hospital que pertenece el equipo o instalacin al cual se
est haciendo el Informe Tcnico.
284 | P g i n a
(4) AREA USUARIO: SECCION Y/O SERVICIO ASISTENCIAL
responsable del uso o administracin directa del equipo o instalacin el
cual se le est haciendo el Informe Tcnico.
(5) UBICACION FISICA (PISO)

el equipo o instalacin el cual se le est haciendo el Informe Tcnico.
(6) ZONA
(7) TELEFONO
del Hospital.
(8) ITEM - CODIGO INVENTARIO FAP

Para indicar el cdigo del equipo o instalacin en el cual est registrado de
acuerdo con el Inventario de Bienes Patrimoniales de toda la Fuerza Area
del Per.
(9) CODIGO HOSPI

Para indicar el nuevo cdigo del equipo o instalacin en el cual est
registrado de acuerdo con el Inventario de Bienes Patrimoniales solamente
del Hospital.
(10)NUMERO DE LA ORDEN DE TRABAJO

Para indicar el nmero de la Orden de Trabajo por lo cual ha generado el
Informe Tcnico.
2.2 PARA SER LLENADO POR EL TALLER DE MANTENIMIENTO O LA

EMPRESA ESPECIALIZADA PARA EL TRABAJO DE REPARACION Y/O
MANTENIMIENTO
285 | P g i n a
(11)TALLER RESPONSABLE DEL INFORME TECNICO
Para indicar el nombre del Taller de Mantenimiento responsable del
Informe Tcnico, si la reparacin o mantenimiento fuese con los recursos
del Hospital; o en todo caso el nombre de la empresa especializada para el
trabajo de reparacin y/o mantenimiento del equipo o instalacin.
(12)TECNICO RESPONSABLE DEL INFORME TECNICO

Se indicar el nombre del tcnico responsable de la reparacin y/o
mantenimiento del equipo o instalacin.
(13)DESCRIPCION DEL ORIGEN DE LA FALLA

Para anotar, despus de la revisin tcnica del equipo o instalacin, la
razn y el motivo que origin que el bien disminuya su productividad o se
encuentre totalmente paralizado.
(14)DIAGNOSTICO TECNICO
Para indicar la determinacin de la posible falla y los cambios de
componentes y accesorios que habran de realizar para la reparacin y/o
(15)ACCIONES REALIZADAS
Para detallar los trabajos que se hizo al equipo o instalacin para su
reparacin o mantenimiento.
(16)ESTIMADO COSTO POSIBLE DE REPARACION

Para indicar el costo estimado referencial de la posible reparacin y/o
(17)RECOMENDACIONES TECNICAS
Para anotar en forma tcnica, las recomendaciones que se deben tener en
cuenta para poder determinar cuantitativamente y cualitativamente la
magnitud del trabajo de reparacin y/o mantenimiento del equipo o
instalacin.
286 | P g i n a
(18)NOMBRE, FIRMA Y FECHA DEL TCNICO RESPONSABLE DEL
MANTENIMIENTO.
Para indicar el nombre, la firma y fecha del tcnico responsable del trabajo
de mantenimiento o reparacin realizados con recursos propios o
contratados, dando conformidad al Informe Tcnico.
(19)NOMBRE, FIRMA Y FECHA DEL JEFE DE TALLER DE

MANTENIMIENTO.
Para indicar el nombre, la firma y fecha del jefe de taller de mantenimiento,
dando conformidad al Informe Tcnico.
(20)NOMBRE, FIRMA Y FECHA DEL JEFE DEL DEPARTAMENTO DE

INGENIERIA.
Para indicar el nombre, la firma y fecha del jefe del departamento de
Ingeniera, dando conformidad al Informe Tcnico.
287 | P g i n a
SECCIONDEPROGRAMACION
YCONTROL
1. N Da Mes Ao
INFORMETECNICO
2 NOMBREDELEQUIPO 3 RAMAY/ODEPARTAMENTOSOLICITANTE
4 AREAUSUARIO:SECCIONY/OSERVICIOASISTENCIAL 5 UBICACINFISICA(PISO)
6 ZONA 7 TELEFONO
8 ITEM 9 CODIGOHOSPI 10 NO/T
11TALLERRESPONSABLEDELINFORMETECNICO :
12TECNICORESPONSABLEDELINFORMETECNICO:
13 DESCRIPCIONDELORIGENDELAFALLA
14 DIAGNOSTICOTECNICO
15 ACCIONESREALIZADAS
16 ESTIMADOCOSTOPOSIBLEDEREPARACION
17 RECOMENDACIONESTECNICAS
18 NOMBREYFIRMADELTECNICORESPONSABLEDELMANTENIMIENTO FECHA
19 NOMBREYFIRMADELJEFEDETALLERDEMANTENIMIENTO FECHA
20 NOMBREYFIRMADELJEFEDELDEPARTAMENTODEINGENIERIA FECHA
288 | P g i n a
Anexo D
DESCRIPCIN DEL FORMATO DE FICHA TCNICA
1. Definicin de Ficha Tcnica
La Ficha Tcnica es un formato creado para identificar las caractersticas y datos

ms importantes del equipo y sus componentes, permite conocer informacin sobre
su origen, fabricacin, vida til, ubicacin y controles de operacin y proteccin para
apoyar las acciones de mantenimiento y reparacin.
2. Llenado de la Ficha Tcnica
La Ficha Tcnica ser llenada segn numeracin en cada una de las partes del
citado documento, de la siguiente manera:

CONTROL
(1) NUMERO
Para indicar el nmero correlativo de registro que corresponde a la Ficha
Tcnica en los archivos de la Seccin de Programacin y Control

Para indicar el nombre especfico de identificacin del equipo, esto se
realizar segn nomenclatura en el Inventario de Bienes del Hospital; o por
el nombre tcnico o comercial que se encuentra en la factura de compra o
en la placa de registro del equipo.
(3) CODIGO HOSPI

Para indicar el nuevo cdigo del equipo en el cual est registrado de
acuerdo con el Inventario de Bienes Patrimoniales solamente del Hospital.

Para indicar el cdigo del equipo en el cual est registrado de acuerdo con
el Inventario de Bienes Patrimoniales de toda la Fuerza Area del Per.
289 | P g i n a
(5) TITULO DEL LIBRO
Para indicar el nombre del catlogo, manual de operacin o algn otro
documento de informacin tcnica del equipo.
(6) NUMERO DE EJEMPLARES

Para indicar cuantos ejemplares existen de los documento del equipo
hospitalario.
(7) MARCA
Para indicar el nombre de la marca del equipo o componentes
hospitalarios.
(8) FABRICANTE
Para indicar el nombre de la empresa fabricante del equipo hospitalario.
(9) MODELO O TIPO

Para indicar el nombre o registro del modelo del equipo hospitalario.
(10)NUMERO DE SERIE
Para indicar el nmero de fabricacin o de serie del equipo materia de
identificacin.
(11)FECHA DE FABRICACION
Para indicar la fecha en que se fabric el equipo segn inventario, factura o
dato de placa del bien.
(12)FECHA PUESTA EN MARCHA

Para indicar la fecha en la cual el equipo se instal y se puso en operacin
en su ambiente fsico correspondiente.
(13)FECHA DE GARANTIA
Para indicar la fecha lmite dentro de la cual el equipo cuenta con la
garanta de fabricacin.
290 | P g i n a
(14)VIDA UTIL
Para indicar el tiempo estimado por el fabricante o proveedor durante el
cual el equipo mantendr ptimas condiciones de funcionamiento y
produccin.
(15)PROVEEDOR
Para indicar el nombre o razn social del proveedor del equipo hospitalario
materia del registro de identificacin.
(16)CODIGO DEL PROVEEDOR

Para indicar el cdigo de registro que corresponde a la empresa
proveedora del bien o servicio, segn registro de proveedores existentes.
(17)DIRECCION
Para indicar la direccin de la empresa proveedora del bien o servicio,
segn registro de proveedores.
(18)TELEFONO
Para indicar el nmero telefnico de la empresa proveedora del bien o
servicio, segn registro de proveedores.
(19)RAMA Y/O DEPARTAMENTO SOLICITANTE

Para indicar el nombre de la Rama y/o Departamento del Hospital
responsable del uso o administracin directa del equipo materia de la
identificacin.
(20)AREA USUARIA: SECCION Y/O SERVICIO ASISTENCIAL
Para indicar el lugar de ubicacin de uso del equipo materia de la
identificacin.
(21)UBICACION FISICA (PISO)

el equipo el cual es materia de la identificacin.
291 | P g i n a
(22)ZONA
Para indicar la zona en que se encuentra el equipo, es decir mencionar el
(23)CARACTERISTICAS TECNICAS DEL EQUIPO

Para indicar las caractersticas ms importantes del equipo de acuerdo a su
tipo y generacin de funcionamiento.
(24)NUMERO ORDEN
Para indicar el nmero correlativo de las unidades que componen el equipo
principal de un equipamiento en general.
(25)UNIDADES DEL EQUIPO

Para indicar la descripcin de los componentes que conforman la unidad
principal, deber consignarse adems el cdigo patrimonial de cada
componente para identificacin y control.
(26)MARCA
Para indicar la marca del componente del equipo.
(27)NUMERO DE SERIE
Para indicar el nmero de fabricacin o de serie de los componentes del
equipo materia de identificacin.
(28)APARATOS DE PROTECCION Y CONTROL

Para indicar los aparatos de proteccin y control del equipo principal y las
unidades componentes, mencionando entre otros termmetros, medidores
de nivel, medidores de presin, etc.
(29)INSUMOS INDUSTRIALES
Se indicar los tipos de combustibles, lubricantes, aceites, aditivos u otros
consumibles que requieren el equipo y sus componentes para su adecuado
funcionamiento.
292 | P g i n a
(30)GAL/HORA
Para indicar la cantidad de galones por hora de combustible u otro insumo
considerable que consume el equipo.
(31)MEDIDAS DE SEGURIDAD
Se indicar las condiciones de operacin y recomendaciones de uso del
equipo para garantizar la seguridad en su uso y funcionamiento. Adems,
deber indicarse el instrumental e indumentaria necesaria para evitar al
mnimo las posibilidades de accidentes con la prevencin de peligros y
seguridad en el operador o usuario de los equipos.
293 | P g i n a
FICHA TECNICA DEL EQUIPO
1.Nro.
2.NOMBRE DEL EQUIPO: 3. CODIGO HOSPI 5. TITULO DEL LIBRO :
4. ITEM 6. N DE EJEMPLARES:
DATOS DE FABRICACION 11. FECHA FABRIC. : 15. PROVEEDOR :

7. MARCA : 12. FECHA PUESTA 16. CODIGO DEL PROVEEDOR :
8. FABRICANTE : EN MARCHA : 17. DIRECCION :
9. MODELO TIPO: 13. FECHA GARANTIA :
10.NRO. SERIE: 14. VIDA UTIL : 18. TELEFONO :
19. RAMA Y/O DEPARTAMENTO SOLICITANTE : 20. AREA USUARIA: SECCION Y/O SERVICIO ASISTENCIAL:
21. UBICACION FISICA (PISO) : 22. ZONA :
23. CARACTERISTICAS TECNICAS DEL EQUIPO :
24. N 27. N 28. APARATOS DE PROTECCION 29. INSUMOS

25. UNIDADES DEL EQUIPO 26. MARCA
ORD. SERIE Y CONTROL INDUSTRIALES
30. GAL/HORA : 31. MEDIDAS DE SEGURIDAD :
294 | P g i n a
Anexo E
DESCRIPCIN DEL FORMATO DE REGISTRO HISTRICO
1. Definicin del Registro Histrico
El Registro Histrico es un informe generado por el sistema creado para dar

informacin de las actividades de mantenimiento y reparacin de los equipos
hospitalarios.
2. Llenado del Registro Histrico del Equipo
El Registro Histrico se presentar segn numeracin en cada una de las partes del
informe citado, de la siguiente manera:
2.2 LLENADO EN SU TOTALIDAD POR EL SISTEMA PROPUESTO
(1) RAMA Y/O DEPARTAMENTO

Para indicar el nombre de la Rama Mdica o Rama Administrativa y/o
Departamento del Hospital, responsable del uso o administracin directa
del equipo materia del registro de actividades de mantenimiento o
reparacin.

Para indicar el nombre especfico de identificacin del equipo, esto se
realizar segn nomenclatura en el Inventario de Bienes del Hospital; o por
el nombre tcnico o comercial que se encuentra en la factura de compra o
en la placa de registro del equipo.
(3) CODIGO HOSPI

Para indicar el nuevo cdigo del equipo en el cual est registrado de
acuerdo con el Inventario de Bienes Patrimoniales solamente del Hospital.

Para indicar el cdigo del equipo en el cual est registrado de acuerdo con
295 | P g i n a
el Inventario de Bienes Patrimoniales de toda la Fuerza Aerea del Per.
(5) FICHA TECNICA NUMERO

Indica el nmero correlativo de registro de la Ficha Tcnica
correspondiente al equipo materia del almacenamiento de informacin de
las actividades de mantenimiento.
(6) COSTO DE ADQUISICION

Para indicar el monto en soles correspondiente a la compra del equipo,
segn factura u orden de compra valorizada para la adquisicin del equipo.
(7) FECHA DE ADQUISICION

Para indicar la fecha en que se adquiri el equipo, segn factura u orden de
compra valorizada.
(8) FECHA PUESTA EN MARCHA

Para indicar la fecha en la cual el equipo se instal y se puso en operacin
en su ambiente fsico de ubicacin.
(9) FECHA
Para indicar la fecha en que se llev a cabo la actividad de mantenimiento,
segn numeral (23) de la Orden de Trabajo correspondiente al
mantenimiento o reparacin del equipo.
(10)NUMERO DE LA ORDEN DE TRABAJO (OT)

Para indicar el nmero correlativo que pertenece al numeral (1) de la Orden
de Trabajo correspondiente al mantenimiento o reparacin del equipo.
(11)NUMERO DE INFORME TCNICO (IT)

Para indicar el nmero correlativo a que corresponde el Informe Tcnico de
la Orden de Trabajo correspondiente al mantenimiento o reparacin del
equipo.
(12)NUMERO DE ORDEN TRABAJO TERCERO (OTT)

Para indicar el nmero correlativo a que corresponde la Orden de Trabajo
296 | P g i n a
de Terceros correspondiente al mantenimiento o reparacin del equipo con
recursos de fuera.
(13)DESCRIPCION DE LAS ACTIVIDADES

Para indicar la labor de mantenimiento o reparacin ejecutada por el Taller
de Mantenimiento o empresas especializadas en el equipo o instalacin,
segn aparece en el numeral (24) de la Orden de Trabajo correspondiente.
(14)SERVICIOS Y/O MATERIALES

Para indicar los servicios contratados necesarios para llevar a cabo las
actividades de mantenimiento y reparacin, como los materiales,
repuestos, accesorios y otros; segn la cantidad, unidad de medida,
descripcin o denominacin, marca, etc; segn aparece en el numeral (34)
de la Orden de Trabajo correspondiente.
(15)HORAS
a) OPERACION
Para indicar las horas de funcionamiento, desde su puesta en marcha
hasta su para por mantenimiento o reparacin, del equipo o instalacin.
b) PARADA
Para indicar el tiempo en horas durante el cual el equipo dej de
funcionar, segn aparece en los numerales (27) y (28) de la Orden de
Trabajo correspondiente.
c) MANTENIMIENTO
Para indicar el tiempo en horas efectivas durante el cual el equipo ha
sido atendido en las actividades relacionadas a su mantenimiento o
reparacin, segn aparece en el numeral (35) de la Orden de Trabajo
Correspondiente.
(16)COSTOS (S/.)
297 | P g i n a
a) PARCIAL
Para indicar los montos en soles de lo gastado en la actividad de
mantenimiento o reparacin ejecutada, segn aparece en el Importa
Total de la Orden de Trabajo correspondiente.
b) ACUMULADO
Para indicar los montos en soles correspondiente a la sumatoria de los
costos anteriormente gastados (PARCIAL) por las actividades
desarrolladas hasta el momento.
(17)ESTADO DE FUNCIONAMIENTO
Para indicar el estado de funcionamiento en que se encuentra el equipo o
instalacin, despus de haberse efectuado el mantenimiento o reparacin
de los mismos, segn aparece en el numeral (25) de la Orden de Trabajo
correspondiente.
Para indicar la fecha de ingreso en el cual el equipo o instalacin, despus
de haberse efectuado el mantenimiento o reparacin de los mismos, entr
en uso o administracin del rea usuaria, segn aparece en el numeral (18)
de la Orden de Trabajo correspondiente.
298 | P g i n a
REGISTRO HISTORICO
1. RAMA Y/O DEPARTAMENTO : 5. FICHA TECNICA N :

2. NOMBRE DEL EQUIPO : 6. COSTO DE ADQUISICION : S/. US$
3. CODIGO HOSPI : 7. FECHA DE ADQUISICION :
4. ITEM : 8. FECHA PUESTA MARCHA :
13. DESCRIPCION DE 14. SERVICIOS Y/O 15. HORAS 16. COSTOS (S/.) 17. EST. 18. FECHA
9 . FECHA 10. NOTM 11. N IT 12.N OTT
LAS ACTIVIDADES MATERIALES A) OPER. B) PARA C) MANT. A) PARC. B) ACUM. FUNCIONAM. CONFORMIDAD
299 | P g i n a
Anexo F
FORMATO DE ENCUESTA DE OPINION REALIZADA
HOSPITAL CENTRAL FAP DPTO DE INGENIERIA
ENCUESTA DE OPINION
NOMBRE Y APELLIDOS : ......................................................................................
CARGO : .......................................................................................
Agradecer se sirva dar respuesta a las siguientes preguntas de la presente Encuesta

de Opinin, elaborada por el Departamento de Ingeniera del Hospital Central FAP:
1.- EN QUE BENEFICIAR AL HOSPITAL CENTRAL FAP, LA UTILIZACIN

DEL SISTEMA DE GESTION DE MANTENIMIENTO?
.................................................................................................................................
.................................................................................................................................
.................................................................................................................................
2.- QU APRECIACION LE MERECE LA DIRECCION Y ORGANIZACION DEL

TRABAJO EN EL DEPARTAMENTO DE INGENIERIA?
.................................................................................................................................
.................................................................................................................................
.................................................................................................................................
3.- CMO JUZGA EN BASE A SU EXPERIENCIA LA OPERATIVIDAD DE LOS

EQUIPOS?
.................................................................................................................................
.................................................................................................................................
.................................................................................................................................
4.- CMO APRECIA EL EMPLEO DEL FORMATO ORDEN DE TRABAJO PARA

LA SOLICITUD DE MANTENIMIENTO EN EL HCFAP?
300 | P g i n a
.................................................................................................................................
.................................................................................................................................
.................................................................................................................................
5.- EN CUANTO AL TRABAJO SOLICITADO, SE REALIZA CON MAYOR

RAPIDEZ?
.................................................................................................................................
.................................................................................................................................
.................................................................................................................................
6.- CREE UD. QUE EL HCFAP TENDRIA UNA MEJOR ADMINISTRACION EN

LA GESTION DE MANTENIMIENTO? PORQUE?
.................................................................................................................................
.................................................................................................................................
.................................................................................................................................
GRACIAS POR SU PARTICIPACION
301 | P g i n a

Sistema de Informacion para El Control, Seguimiento y Mantenimiento Del Equipamiento Hospitalario

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sistema de Informacion para El Control, Seguimiento y Mantenimiento Del Equipamiento Hospitalario

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD RICARDO PALMA

SISTEMA DE INFORMACION PARA EL

Hospital Central de la Fuerza Area del Per

Hago un reconocimiento muy especial y

Al trmino de este Proyecto de Tesis que representa la culminacin

A mis padres Victor y Anglica, por su incesante trabajo y esfuerzo por

A mis amigos y dems familiares, quienes me brindaron su apoyo, ayuda y

Por ltimo, quiero agradecer al Dr. Silverio Bustos Daz y a la Escuela de

SISTEMA DE INFORMACION PARA EL CONTROL,

VICTOR HUGO CHAVEZ GOMEZ

Profesor Asesor : Ing. Miguel Tamayo Zumaeta

El presente trabajo de investigacin tiene como propsito fundamental

PALABRAS CLAVES: Equipos Hospitalarios

INFORMATION SYSTEM FOR THE CONTROL,

VICTOR HUGO CHAVEZ GOMEZ

Professor : E. Miguel Tamayo Zumaeta

The main purpose of this research is to present a solution that enable to

KEYWORDS: Hospital Equipment

1. CAPITULO I: PLANTEAMIENTO DEL PROBLEMA 1

2. CAPITULO II: MARCO TEORICO CONCEPTUAL 7

3. CAPITULO III: ESTADO DEL ARTE 68

4. CAPITULO IV: METODOLOGIA DE LA INVESTIGACIN 154

5. CAPITULO V: CONTRIBUCIN 159

6. CAPITULO VI: ADMINISTRACIN DEL PROYECTO 235

7. CAPITULO VII: CONCLUSIONES Y RECOMENDACIONES 249

8. GLOSARIO DE TERMINOS 253

10. REFERENCIAS BIBLIOGRAFICAS 264

11. ANEXOS 269

Figura 1. Proceso de calibracin a un equipo electromecnico. 26

Tabla 1. Generaciones del Mantenimiento 10

La ciencia y la tecnologa han influido mucho en la forma de ejercer la medicina. Los

PLANTEAMIENTO DEL PROBLEMA

En la mayora de Hospitales de nuestro pas, no existe un Sistema Informtico

Debido a ello, en el Hospital Central de la Fuerza Area del Per no existe un

1.2.2. Lmite Temporal

1.3. Formulacin del Problema

1.4.2. Objetivos Especficos

Conseguir la mxima disponibilidad, fiabilidad y seguridad de las

Planificacin, control y seguimiento de todas las actividades de

1.5. Formulacin de la Hiptesis

1.6. Seleccin de Variables

1.6.2. Variable Independiente

1.7. Lnea de Investigacin

1.8. Justificacin e Importancia de la Investigacin

El sistema de informacin cubrir el control y seguimiento de las tareas de

1.9. Alcances de la Investigacin

El desarrollo de dicha solucin est conformado por cinco mdulos integrados

En resumen, se implementar un Sistema de Informacin para el Control,

MARCO TERICO CONCEPTUAL

Hasta 1914, el mantenimiento tena importancia secundaria y era

Con el advenimiento de la primera guerra mundial y la implantacin de la

As surgi un rgano subordinado a la operacin, cuyo objetivo bsico

Por el ao 1950, con el desarrollo de la industria para atender a los

A partir de 1966, con el fortalecimiento de las asociaciones nacionales

Esos criterios conocidos como mantenimiento PREDICTIVO O

2.1.2. Evolucin del Mantenimiento

Tabla 1. Generaciones del Mantenimiento. Fuente: Curso de Ingeniera de Mantenimiento Hospitalario

El Mantenimiento Correctivo (intervenir cuando falle) al

Mantenimiento preventivo (intervencin por intervalos) a

Mantenimiento predictivo o monitoreo de condicin

Mantenimiento Integral (predictivo, preventivo, correctivo) Luego

Mantenimiento de precisin, hasta

El mantenimiento & mejora continua