Tesis formato pdf

UNIVERSIDAD TÉCNICA DEL NORTE
FACULTAD DE INGENIERÍA EN CIENCIAS APLICADAS
CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES
TEMA
“SISTEMA WEB DE GESTIÓN Y CONTROL DE PROCESOS PARA LA DIRECCIÓN
PROVINCIAL DEL IESS DE IMBABURA”
APLICATIVO
“MÓDULO DE GESTIÓN Y CONTROL DE INVENTARIOS DE SUMINISTROS”
Autor: Rubén Luis González Tayo
Director: Ing. Xavier Mauricio Rea Peñafiel
Ibarra – Ecuador
2013

ii
CERTIFICACIÓN DEL DIRECTOR DE TRABAJO DE GRADO
Certifico que la Tesis “SISTEMA WEB DE GESTIÓN Y CONTROL DE PROCESOS
PARA LA DIRECCIÓN PROVINCIAL DEL IESS DE IMBABURA” con el aplicativo
" MÓDULO DE GESTIÓN Y CONTROL DE INVENTARIOS DE SUMINISTROS” ha
sido realizada en su totalidad por el señor: Ruben Luis Gonzalez Tayo portador de la cédula de
identidad número: 1002612115.
Ing. Xavier Mauricio Rea Peñafiel
Director de la Tesis

Sistema Web de Gestión y Control de Procesos para la Dirección Provincial del IESS de Imbabura
Módulo de Gestión y Control de Inventarios de Suministros
iii
CERTIFICACIÓN
Ibarra, 28 de Febrero del 2013
Señores
Presente
De mis consideraciones.-
Siendo auspiciantes del proyecto de tesis del Egresado RUBEN LUIS GONZALEZ TAYO
con CI: 1002612115 quien desarrolló su trabajo con el tema “SISTEMA WEB DE GESTIÓN
Y CONTROL DE PROCESOS PARA LA DIRECCIÓN PROVINCIAL DEL IESS DE
IMBABURA” con el aplicativo "MÓDULO DE GESTIÓN Y CONTROL DE
INVENTARIOS DE SUMINISTROS", me es grato informar que se han superado con
satisfacción las pruebas técnicas y la revisión de cumplimiento de los requerimientos
funcionales, por lo que se recibe el proyecto como culminado y realizado por parte del
egresado RUBEN LUIS GONZALEZ TAYO. Una vez que hemos recibido la capacitación y
documentación respectiva, nos comprometemos a continuar utilizando el mencionado
aplicativo en beneficio de nuestra institución.
El egresado RUBEN LUIS GONZALEZ TAYO puede hacer uso de este documento para los
fines pertinentes en la Universidad Técnica del Norte.
_____________________________________
Ing. Mario Medina
Departamento de Sistemas del IESS Imbabura
I.E.S.S.

iv
CESIÓN DE DERECHOS DE AUTOR DEL TRABAJO DE GRADO
A FAVOR DE LA UNIVERSIDAD TÉCNICA DEL NORTE
Yo, RUBEN LUIS GONZALEZ TAYO, con cédula de identidad Nro. 1002612115,
manifiesto mi voluntad de ceder a la Universidad Técnica del Norte los derechos
patrimoniales consagrados en la Ley de Propiedad Intelectual del Ecuador, articulo 4, 5 y 6, en
calidad de autor del trabajo de grado denominado: “SISTEMA WEB DE GESTIÓN Y
CONTROL DE PROCESOS PARA LA DIRECCIÓN PROVINCIAL DEL IESS DE
IMBABURA” con el aplicativo "MÓDULO DE GESTIÓN Y CONTROL DE
INVENTARIOS DE SUMINISTROS”, que ha sido desarrollada para optar por el título de
Ingeniería en Sistemas Computacionales, quedando la Universidad facultada para ejercer
plenamente los derechos cedidos anteriormente.
En mi condición de autor me reservo los derechos morales de la obra antes mencionada,
aclarando que el trabajo aquí descrito es de mi autoría y que no ha sido previamente
presentado para ningún grado o calificación profesional.
En concordancia suscribo este documento en el momento que hago entrega del trabajo final en
formato impreso y digital a la biblioteca de la Universidad Técnica del Norte.
Firma
Nombre: RUBEN LUIS GONZALEZ TAYO
Cédula: 1002612115
Ibarra a los 28 días del mes de Febrero del 2013

v
BIBLIOTECA UNIVERSITARIA
AUTORIZACIÓN DE USO Y PUBLICACIÓN
A FAVOR DE LA UNIVERSIDAD TÉCNICA DEL NORTE
1. IDENTIFICACIÓN DE LA OBRA
La Universidad Técnica del Norte dentro del proyecto Repositorio Digital Institucional, determinó la
necesidad de disponer los textos completos en formato digital con la finalidad de apoyar los procesos
de investigación, docencia y extensión de la Universidad.
Por medio del presente documento dejo sentada mi voluntad de participar en este proyecto, para lo cual
pongo a disposición la siguiente información:
DATOS DE CONTACTO
CÉDULA DE IDENTIDAD: 1002612115
APELLIDOS Y NOMBRES: GONZALEZ TAYO RUBEN LUIS
DIRECCIÓN: NATABUELA-CALLE VELASCO IBARRA Y NICOLÁS
PALACIOS
EMAIL: rubenrlgt@hotmail.com
TELÉFONO FIJO: 062933450 TELÉFONO MÓVIL: 0998307139
2. AUTORIZACIÓN DE USO A FAVOR DE LA UNIVERSIDAD
Yo, RUBEN LUIS GONZALEZ TAYO, con cédula de identidad Nro. 1002612115, en calidad de
autor y titular de los derechos patrimoniales de la obra o trabajo de grado descrito anteriormente, hago
entrega del ejemplar respectivo en forma digital y autorizo a la Universidad Técnica del Norte, la
publicación de la obra en el Repositorio Digital Institucional y uso del archivo digital en la Biblioteca
de la Universidad con fines académicos, para ampliar la disponibilidad del material y como apoyo a la
educación, investigación y extensión; en concordancia con la Ley de Educación Superior Artículo 144.
Firma
Nombre: RUBEN LUIS GONZALEZ TAYO
Cédula: 1002612115
Ibarra a los 28 días del mes de Febrero del 2013
DATOS DE LA OBRA
TÍTULO: ”MÓDULO DE GESTIÓN Y CONTROL DE INVENTARIOS DE
SUMINISTROS”
AUTOR: RUBEN LUIS GONZALEZ TAYO
FECHA: 2013-02-28
PROGRAMA: PREGRADO
TITULO POR EL QUE OPTA: INGENIERÍA EN SISTEMAS COMPUTACIONALES
DIRECTOR: ING. MAURICIO REA

vi
CONSTANCIAS
El autor (es) manifiesta (n) que la obra objeto de la presente autorización es original y se la
desarrolló, sin violar derechos de autor de terceros, por lo tanto la obra es original y que es
(son) el (los) titular (es) de los derechos patrimoniales, por lo que asume (n) la responsabilidad
sobre el contenido de la misma y saldrá (n) en defensa de la universidad en caso de
reclamación por parte de terceros.
Ibarra, a los 28 días del mes de Febrero del 2013
Nombre: GONZÁLEZ TAYO RUBEN LUIS Nombre: ING. BETHY CHÁVEZ
C.C...1002612115 Cargo: JEFE DE BIBLIOTECA
Facultado por resolución de Consejo Universitario___________________________________

vii
DEDICATORIA
Considero a este proyecto como la culminación de otra etapa de mi vida, lo dedico
principalmente a mi madre Patricia Tayo por su apoyo, cariño, dedicación, constancia y sobre
todo por estar siempre pendiente de mí, ya que fue quien me impulsó a lograr escalar un
peldaño más en el cumplimiento de mis metas.

viii
AGRADECIMIENTO
Con estas palabras doy gracias a dios por haberme dado a una madre incondicional que me ha
apoyado a lo largo de mi vida. Le agradezco por creer en mí, y darme su apoyo.
Un agradecimiento especial a los Ingenieros: Mario Medina, Mauricio Rea y John Cevallos
ya que con su asesoramiento e intervención me guiaron en el desarrollo de mi tesis.
Agradezco al Director de la Dirección Provincial del IESS Imbabura Dr. Vicente Muñoz y a la
Jefa del Departamento Provincial del Sistema de Pensiones Imbabura Lic. Guadalupe Aguirre
por la autorización para el desarrollo de mi proyecto de tesis en sus instalaciones.
Un agradecimiento al Departamento de Vinculación, a su director Lic. Germán Gualoto, y a
los coordinadores Juan Carlos Jaramillo y Mauricio Heredia quienes facilitaron sus espacios
contribuyendo en gran parte a la elaboración de mi tesis.

ix
TABLA DE CONTENIDOS
CERTIFICACIÓN DEL DIRECTOR DE TRABAJO DE GRADO...................................................... ii
CERTIFICACIÓN ................................................................................................................................. iii
CESIÓN DE DERECHOS DE AUTOR DEL TRABAJO DE GRADO................................................iv
AUTORIZACIÓN DE USO Y PUBLICACIÓN.....................................................................................v
CONSTANCIAS.....................................................................................................................................vi
DEDICATORIA ................................................................................................................................... vii
AGRADECIMIENTO.......................................................................................................................... viii
RESUMEN............................................................................................................................................xix
SUMMARY ...........................................................................................................................................xx
1. Capítulo I: Introducción .................................................................................................................22
1.1. Antecedentes.........................................................................................................................22
1.2. Problema...............................................................................................................................22
1.3. Objetivos...............................................................................................................................22
1.3.1 Objetivo General...................................................................................................................22
1.3.2 Objetivos Específicos ...........................................................................................................22
1.4. Justificación ..........................................................................................................................23
1.5. Alcance .................................................................................................................................24
1.6. Beneficios .............................................................................................................................25
2. Capítulo II: Marco Teórico ............................................................................................................27
2.1. Lenguaje Java .......................................................................................................................27
2.2. Plataforma Java.....................................................................................................................27
2.3. Plataforma Java EE 6............................................................................................................27
2.3.1 Componentes de la arquitectura Java EE..............................................................................28
2.4. Subversión (SVN Server) .....................................................................................................29
2.4.1 TTB, La Estructura Habitual Subversion..............................................................................30
2.4.2 Ventajas ................................................................................................................................31
2.4.3 Carencias...............................................................................................................................31
2.5. Patrones de diseño MVC ......................................................................................................32
2.5.1 Definición .............................................................................................................................32
2.5.2 Ciclo de Vida MVC ..............................................................................................................33
2.5.3 Ventajas y Desventajas de MVC ..........................................................................................34
2.6. Base de datos Oracle 11g......................................................................................................35

x
2.6.1 Introducción..........................................................................................................................35
2.6.2 Características de Oracle 11g ...............................................................................................36
2.6.3 Importancia de Oracle 11g....................................................................................................36
2.7. Servidor de aplicaciones Weblogic.......................................................................................37
2.7.1 Definición de Servidor de Aplicaciones ...............................................................................37
2.7.2 Definición de WebLogic Server ...........................................................................................37
2.7.3 Características de WebLogic ................................................................................................38
2.8. IDE de desarrollo JDeveloper...............................................................................................39
2.8.1 Introducción..........................................................................................................................39
2.8.2 Características.......................................................................................................................40
2.8.3 Visual y declarativa ..............................................................................................................42
2.8.4 Licencia.................................................................................................................................43
2.9. Enterprise Java Bean (EJB) ..................................................................................................43
2.9.1 Definición de Enterprise Java Bean (EJB): ..........................................................................43
2.9.2 Cuándo Utilizar EjBs............................................................................................................43
2.9.3 Funcionamiento de componentes EJB..................................................................................44
2.9.4 Tipos de Beans......................................................................................................................44
2.9.5 Beans de sesión sin estado o stateless:..................................................................................44
2.9.6 Beans de sesión con estado o stateful: ..................................................................................45
2.10. Java Persistence API (JPA)...................................................................................................46
2.10.1 Funcionamiento de JPA ...............................................................................................47
2.11. Framework JSF.....................................................................................................................47
2.11.1 Ciclo de Vida JSF: .......................................................................................................48
2.11.2 Fases del ciclo JSF:......................................................................................................48
2.12. RichFaces..............................................................................................................................49
2.12.1 Definición de RichFaces ..............................................................................................49
2.12.2 Funcionamiento de RichFaces: ....................................................................................49
2.12.3 Características de RichFaces:.......................................................................................49
2.13. JasperReport con iRepot .......................................................................................................50
2.13.1 Definición de JasperReports ........................................................................................50
2.13.2 Funcionamiento de JasperReports................................................................................50
2.13.3 IReport: ........................................................................................................................51
2.13.4 Funcionamiento de IReport..........................................................................................51

xi
2.14. Inventario..............................................................................................................................51
2.14.1 Concepto ......................................................................................................................51
2.14.2 Objetivos del Inventario...............................................................................................51
2.15. Administración de Inventarios..............................................................................................52
2.15.1 Concepto ......................................................................................................................52
2.15.2 Importancia ..................................................................................................................52
2.16. Suministros de bodega..........................................................................................................52
2.17. Control del Inventario...........................................................................................................53
2.17.1 Planeamiento................................................................................................................53
2.17.2 Compra u Obtención ....................................................................................................53
2.17.3 Recepción.....................................................................................................................53
2.17.4 Almacenaje...................................................................................................................54
2.18. Inventario Permanente ..........................................................................................................54
2.19. Valorización de Inventarios de Mercaderías.........................................................................55
2.19.1 Costo Primeras entradas, primeras salidas(PEPS) .......................................................55
2.19.2 Costo de Últimas entradas, primeras salidas (UEPS) ..................................................55
2.19.3 Método Promedio.........................................................................................................55
2.19.4 Precio de Mercado........................................................................................................55
3. Capítulo III: Funcionamiento del Sistema......................................................................................57
3.1. Esquema de la Aplicación integrada con los otros Módulos ................................................57
3.2. Esquema General del Funcionamiento del Sistema..............................................................58
3.3. Definición de los Módulos del Sistema ................................................................................58
3.3.1 Módulo de Bodega................................................................................................................58
3.3.2 Módulo de Compras de Suministros.....................................................................................59
3.3.3 Módulo de Pedidos de Suministros.......................................................................................59
3.3.4 Módulo de Entregas de Suministros .....................................................................................59
3.3.5 Módulo de Reportes..............................................................................................................60
4. Capítulo IV: Desarrollo del Proyecto.............................................................................................62
4.1. Aplicación Metodología RUP...............................................................................................62
4.2. Fase de Inicio........................................................................................................................62
4.2.1 Planificación inicial ..............................................................................................................62
4.2.2 Análisis de requerimientos inicial (actas de trabajo) ............................................................63
4.2.3 Recolección de información (documentos) ..........................................................................64

xii
4.2.4 Lista de Riegos .....................................................................................................................70
4.2.5 Visión....................................................................................................................................72
4.2.5.1 Introducción .................................................................................................................72
4.2.5.1.1 Propósito ......................................................................................................................72
4.2.5.1.2 Alcance.........................................................................................................................72
4.2.5.1.3 Definiciones, Siglas y Abreviaturas.............................................................................72
4.2.5.1.4 Referencias...................................................................................................................72
4.2.5.2 Posicionamiento...........................................................................................................73
4.2.5.2.1 Oportunidad de negocio...............................................................................................73
4.2.5.2.2 Definición del problema...............................................................................................73
4.2.5.2.3 Definición de la posición del Producto ........................................................................74
4.2.5.3 Descripción de los interesados y usuarios....................................................................75
4.2.5.3.1 Resumen de los interesados .........................................................................................75
4.2.5.3.2 Resumen de los usuarios..............................................................................................77
4.2.5.3.3 Entorno de usuario .......................................................................................................77
4.2.5.3.4 Perfiles de los interesados ............................................................................................78
4.2.5.3.4.1 Coordinador y responsable del proyecto......................................................................78
4.2.5.3.4.2 Jefe del proyecto ..........................................................................................................79
4.2.5.3.4.3 Responsable del proyecto.............................................................................................79
4.2.5.3.4.4 Responsable funcional .................................................................................................80
4.2.5.3.5 Perfiles de usuario........................................................................................................81
4.2.5.3.5.1 Administrador del sistema............................................................................................81
4.2.5.3.5.2 Administrador funcional del sistema ...........................................................................81
4.2.5.3.5.3 Usuario del Sistema .....................................................................................................82
4.2.5.3.6 Necesidades de los interesados y usuarios ...................................................................83
4.2.5.3.7 Alternativas y competencia..........................................................................................84
4.2.5.4 Vista general del producto ...........................................................................................84
4.2.5.4.1 Perspectiva del producto ..............................................................................................84
4.2.5.4.2 Resumen de capacidades..............................................................................................85
4.2.5.4.3 Suposiciones y dependencias .......................................................................................86
4.2.5.4.4 Costos y precios ...........................................................................................................86
4.2.5.4.5 Licenciamiento e instalación........................................................................................88
4.2.5.5 Características del producto .........................................................................................88

xiii
4.2.5.5.1 Autentificación de usuarios..........................................................................................88
4.2.5.5.2 Gestión de los roles......................................................................................................88
4.2.5.5.3 Facilidad de acceso y uso.............................................................................................88
4.2.5.5.4 Módulo de Proceso de Bodega.....................................................................................88
4.2.5.5.5 Módulo de Compras de Suministros............................................................................89
4.2.5.5.6 Módulo de Pedidos de Suministros..............................................................................89
4.2.5.5.7 Módulo de Entrega de Suministros..............................................................................89
4.2.5.5.8 Reportes. ......................................................................................................................90
4.2.5.6 Restricciones ................................................................................................................90
4.2.5.7 Rangos de calidad ........................................................................................................90
4.2.5.8 Precedencia y Prioridad................................................................................................90
4.2.5.9 Otros requerimientos del producto...............................................................................91
4.3. Plan de Desarrollo de Software ............................................................................................91
4.3.1 Propósito...............................................................................................................................91
4.3.2 Alcance .................................................................................................................................92
4.3.3 Resumen ...............................................................................................................................92
4.3.4 Vista General del Proyecto ...................................................................................................92
4.3.4.1 Propósito, Alcance y Objetivos....................................................................................92
4.3.4.2 Suposiciones y Restricciones .......................................................................................94
4.3.5 Organización del Proyecto....................................................................................................95
4.3.5.1 Participantes en el Proyecto .........................................................................................95
4.3.6 Interfaces Externas................................................................................................................95
4.3.7 Roles y Responsabilidades....................................................................................................96
4.3.8 Gestión del Proceso ..............................................................................................................97
4.3.8.1 Estimaciones del Proyecto ...........................................................................................97
4.3.8.2 Plan del Proyecto .........................................................................................................97
4.3.8.3 Seguimiento y Control del Proyecto ..........................................................................104
4.4. Fase Elaboración.................................................................................................................105
4.4.1 Arquitectura ........................................................................................................................105
4.4.1.1 Introducción ...............................................................................................................105
4.4.1.2 Representación de la Arquitectura .............................................................................105
4.4.1.3 Objetivos y Restricciones de la Arquitectura.............................................................105
4.4.1.4 Vista de Casos de Uso................................................................................................106

xiv
4.4.1.4.1 Modelo de casos de Uso.............................................................................................106
4.4.1.4.2 Prioridad de Casos de Uso .........................................................................................106
4.4.1.4.3 Modelo de Caso de Uso Módulo de Compras de Suministros...................................108
4.4.1.4.4 Modelo de Caso de Uso Módulo de Bodega..............................................................108
4.4.1.4.5 Modelo de Caso de Uso Módulo de Pedidos de Suministros.....................................109
4.4.1.4.6 Modelo de Caso de Uso Módulo de Entregas de Suministros ...................................109
4.4.1.4.7 Modelo de Casos de Uso Módulo de Reportes ..........................................................110
4.4.1.5 Descripción de los Casos de Uso más relevantes.......................................................110
4.4.1.5.1 Módulo de Compras de Suministros..........................................................................110
4.4.1.5.1.2 Consultar Catálogo de Suministros............................................................................110
4.4.1.5.2 Módulo de Bodega.....................................................................................................110
4.4.1.5.2.1 Administrar Suministros ............................................................................................110
4.4.1.5.2.2 Administrar Unidades de Medida ..............................................................................110
4.4.1.5.2.3 Consultar Kardex de Suministros...............................................................................110
4.4.1.5.3 Módulo de Pedidos de Suministros............................................................................110
4.4.1.5.3.1 Elaborar Pedido..........................................................................................................110
4.4.1.5.3.2 Cancelar Pedido .........................................................................................................110
4.4.1.5.4 Módulo de Entregas de Suministros ..........................................................................111
4.4.1.5.4.1 Entregar Pedidos ........................................................................................................111
4.4.1.5.4.2 Consultar Pedidos Entregados....................................................................................111
4.4.1.5.4.3 Entregar Bienes Sujetos a Control .............................................................................111
4.4.1.5.4.4 Consultar Estadísticas de Consumo ...........................................................................111
4.4.1.5.5 Módulo de Reportes...................................................................................................111
4.4.1.5.5.1 Generar Reportes........................................................................................................111
4.4.2 Especificación de Casos De Uso ........................................................................................116
4.4.3 Vista Lógica........................................................................................................................137
4.4.3.1 Modelo Entidad Relación...........................................................................................138
4.4.3.2 Modelo Físico ............................................................................................................139
4.5. Fase Construcción...............................................................................................................141
4.5.1 Prototipo Inicial ..................................................................................................................141
4.5.2 Ventajas en el uso del Prototipo .........................................................................................141
4.5.3 Herramientas utilizadas.......................................................................................................142
4.5.4 Diagramas de Flujo.............................................................................................................143

xv
4.5.4.1 Diagrama de Flujo Proceso de Bodega ......................................................................143
4.5.4.2 Diagrama de Flujo Proceso de Compras....................................................................144
4.5.4.3 Diagrama de Flujo Proceso de Pedidos......................................................................145
4.5.4.4 Diagrama de Flujo Proceso de Entregas ....................................................................146
4.5.4.5 Diagrama de Flujo Reportes.......................................................................................147
4.5.4.6 Prototipo de Pantalla: Compras de Suministros.........................................................148
4.5.4.7 Prototipo de Pantalla: Entregas de Pedidos por Requerimiento.................................148
4.5.5 Plan de Pruebas...................................................................................................................149
4.6. Fase de Transición ..............................................................................................................156
4.6.1 Descripción Proyecto Final.................................................................................................156
4.6.2 Implementación del Aplicativo...........................................................................................156
5. Capítulo V: Conclusiones , Recomendaciones y Análisis de Impacto.........................................159
5.1. Conclusiones.......................................................................................................................159
5.2. Recomendaciones: ..............................................................................................................159
5.3. Análisis de Impacto ............................................................................................................160
6. Glosario de Términos...................................................................................................................165
7. Bibliografía ..................................................................................................................................169
8. Anexos..........................................................................................................................................171

xvi
Índice de Figuras
Figura 1: MÓDULOS del SGCP........................................................................................................... 24
Figura 2: Plataforma Java...................................................................................................................... 27
Figura 3: Esquema General Java EE..................................................................................................... 28
Figura 4: Arquitectura Java EE ............................................................................................................. 29
Figura 5: La Estructura Habitual Subversion........................................................................................ 30
Figura 6: Modelo Vista Controlador ..................................................................................................... 33
Figura 7: Ciclo de Vida MVC............................................................................................................... 33
Figura 8: Jdeveloper 11g R2 ................................................................................................................. 39
Figura 9: Beans de sesión sin estado..................................................................................................... 45
Figura 10: Beans de sesión con estado.................................................................................................. 46
Figura 11: Esquema de la Aplicación integrada con los otros Módulos ............................................... 57
Figura 12: Esquema General del Funcionamiento de la Aplicación ..................................................... 58
Figura 13: Boletín de Compra de Suministros de Oficina .................................................................... 64
Figura 14: Factura de Compra de Suministros de oficina #1 ................................................................ 65
Figura 17: Factura de Compra de Suministros de impresión ................................................................ 68
Figura 18: Reporte de Inventario de Suministros de Oficina................................................................ 69
Figura 19: Tarjeta kardex de Suministros de Oficina............................................................................ 70
Figura 20: Perspectiva del Producto...................................................................................................... 85
Figura 21: Fases y Flujos de Trabajo en Metodología Rational Unified Process (RUP).................... 100
Figura 22: Modelo de Casos de Uso ................................................................................................... 106
Figura 23: Caso de Uso Módulo de Adquisición de Suministros ....................................................... 108
Figura 24: Caso de Uso Módulo de Bodega........................................................................................ 108
Figura 25: Caso de Uso Módulo de Pedidos de Suministros .............................................................. 109
Figura 26: Caso de Uso Módulo de Entregas de Suministros............................................................. 109
Figura 27: Caso de Uso Módulo de Reportes..................................................................................... 110
Figura 28: Caso de Uso Generar Reportes.......................................................................................... 111
Figura 29: Patrón de diseño MVC....................................................................................................... 114
Figura 30: Interfaz de Usuario ............................................................................................................ 115
Figura 31: Vista de Despliegue. .......................................................................................................... 116
Figura 32: Caso de Uso: Compras de Suministros.............................................................................. 116
Figura 33: Nueva Compra Suministros............................................................................................... 117
Figura 34: Ingreso Suministro............................................................................................................. 118
Figura 35: Nueva Compra con datos................................................................................................... 118
Figura 36: Pantalla Tablas Proceso Adquisición Suministros............................................................. 119
Figura 37: Pantalla Tablas Kardex –Inventario................................................................................... 120
Figura 38: Pantalla Catálogo de Suministros ...................................................................................... 121
Figura 39: Caso de Uso: Proceso de Bodega ...................................................................................... 122
Figura 40: Pantalla Inventario de Suministros .................................................................................... 123
Figura 41: Pantalla Nuevo Suministro ................................................................................................ 123
Figura 42: Pantalla Tablas Proceso Inventario.................................................................................... 125

xvii
Figura 43: Pantalla Tabla SUM_UNIDAD_MEDIDAS..................................................................... 125
Figura 44: Pantalla Tabla SUM_TIPO_MOVIMIENTOS ................................................................. 126
Figura 45: Pantalla kardex Suministro................................................................................................ 127
Figura 46: Caso de uso: Pedidos de Suministros ................................................................................ 128
Figura 47: Pantalla Tablas Proceso de Elaboración de Pedidos.......................................................... 129
Figura 48: Caso de uso: Entregas de Suministros ............................................................................... 131
Figura 49: Pantalla Entrega de Suministros ........................................................................................ 132
Figura 50: Pantalla Confirmar realizar entrega ................................................................................... 132
Figura 51: Pantalla Tabla ACT_BIENES ........................................................................................... 134
Figura 52: Pantalla Ver Pedido Entregado.......................................................................................... 136
Figura 53: Caso de Uso: Reportes....................................................................................................... 136
Figura 54: Oracle SQL Developer DataModeler ................................................................................ 137
Figura 55: Modelo Entidad Relación .................................................................................................. 138
Figura 56: Modelo Físico.................................................................................................................... 139
Figura 57: Modelo de Datos................................................................................................................ 140
Figura 58: JDeveloper 11g R2 ............................................................................................................ 142
Figura 59: Oracle SQL Developer ...................................................................................................... 142
Figura 60: Richfaces 4.1...................................................................................................................... 142
Figura 61: Diagrama de Flujo Proceso de Bodega.............................................................................. 143
Figura 62: Diagrama de Flujo Proceso de Compras............................................................................ 144
Figura 63: Diagrama de Flujo Proceso de Pedidos ............................................................................. 145
Figura 64: Diagrama de Flujo Proceso de Entrega de Pedidos ........................................................... 146
Figura 65: Diagrama de Flujo de Reportes ......................................................................................... 147
Figura 66: Prototipo Pantalla Principal ............................................................................................... 147
Figura 67: Prototipo Compras de Suministros .................................................................................... 148
Figura 68: Prototipo Pedido por Requerimiento ................................................................................. 148
Figura 69: Prototipo Proceso de Bodega............................................................................................. 149
Figura 70: Pantalla Tablas del sistema en ORACLE SQL DEVELOPER ........................................ 157

xviii
Índice de Tablas
Tabla 1: Acta de Trabajo Nro. 1............................................................................................................. 63
Tabla 2: Lista de Riesgos ....................................................................................................................... 71
Tabla 3: Definición del Problema .......................................................................................................... 74
Tabla 4: Definición de la Posición del Producto.................................................................................... 75
Tabla 5: Resumen de Interesados........................................................................................................... 76
Tabla 6: Resumen de los Usuarios ......................................................................................................... 77
Tabla 7: Perfil de Coordinador del Proyecto.......................................................................................... 78
Tabla 8: Perfil del jefe del proyecto....................................................................................................... 79
Tabla 9: Perfil Responsable del Proyecto............................................................................................... 80
Tabla 10: Perfil de responsable funcional.............................................................................................. 80
Tabla 11: Perfil del administrador del proyecto..................................................................................... 81
Tabla 12: Perfil del administrador funcional del sistema....................................................................... 82
Tabla 13: Perfil del usuario del sistema ................................................................................................. 82
Tabla 14: Necesidades de los interesados y usuarios............................................................................. 83
Tabla 15: Resumen de capacidades........................................................................................................ 86
Tabla 16: Costos del Proyecto................................................................................................................ 88
Tabla 17: Roles y Responsabilidades..................................................................................................... 96
Tabla 18: Plan de Fases.......................................................................................................................... 97
Tabla 19: Plan de Fases: Hitos .............................................................................................................. 99
Tabla 20: Calendario de Actividades Fase de Inicio............................................................................ 102
Tabla 21: Calendario de Actividades Fase de Elaboración.................................................................. 104
Tabla 22: Prioridad de Casos de Uso ................................................................................................... 107
Tabla 23: Tecnología............................................................................................................................ 113
Tabla 24: Pruebas de Integridad de Datos............................................................................................ 150
Tabla 25: Pruebas del Ciclo de Negocio .............................................................................................. 151
Tabla 26: Pruebas de Interfaz de Usuario ............................................................................................ 152
Tabla 27: Pruebas de Desempeño ........................................................................................................ 153
Tabla 28: Pruebas de Seguridad y Control de Acceso ......................................................................... 154
Tabla 29: Herramientas........................................................................................................................ 155
Tabla 30: Recursos............................................................................................................................... 155
Tabla 31: Entregables........................................................................................................................... 156
Tabla 32: Herramientas Utilizadas....................................................................................................... 156

xix
RESUMEN
La Dirección Provincial del IESS de Imbabura no cuenta en la actualidad con un sistema
informático que le facilite la información necesaria para la gestión y el control del inventario
de Suministros.
El Módulo de Gestión y Control de Inventarios de Suministros (MGCIS) se refiere al control y
manejo de los diferentes suministros que tiene la bodega de la Dirección Provincial del IESS
de Imbabura.
Este sistema constituye una de las alternativas más convenientes en el esfuerzo por reducir el
tiempo de ejecución en los diferentes procesos y de esa manera optimizar la forma como se
lleva el inventario de suministros haciéndolo de una manera más eficiente y que sirva para
minimizar los gastos que tiene la Dirección Provincial del IESS de Imbabura.
Finalmente se presentará una solución, para mejorar el manejo de información, omitiendo la
utilización de archivos físicos y cálculos manuales, y en su lugar el “Módulo de Gestión y
Control de Inventarios de Suministros para la Dirección Provincial del IESS de Imbabura se
encargará de acelerar los procesos y brindar seguridad en el manejo de la información.

xx
SUMMARY
The Provincial Direction of the IESS of Imbabura doesn't have a computer system that
facilitates him the necessary information for the administration and the control of the
inventory of Supplies at the present time.
The Module of Administration and Control of Inventories of Supplies (MGCIS) he/she refers
to the control and handling of the different supplies that he/she has the cellar of the Provincial
Direction of the IESS of Imbabura.
This system constitutes one of the most convenient alternatives in the effort to reduce the run-
time in the different processes and in that way to optimize the form like the inventory of
supplies is taken making it in a more efficient way and that it is good to minimize the expenses
that he/she has the Provincial Direction of the IESS of Imbabura.
Finally a solution will be presented, to improve the handling of information, omitting the use
of physical files and manual calculations, and in its place the “Module of Administration and
Control of Inventories of Supplies for the Provincial Direction of the IESS of Imbabura will
take charge of accelerating the processes.

22
1. Capítulo I: Introducción
1.1. Antecedentes
El Instituto Ecuatoriano de Seguridad Social es una institución que cuenta con infraestructura propia,
con bienes muebles, bodegas de almacenamiento de suministros los que no han sido controlados
debidamente con un orden desde su existencia, ya que no se cuenta con un sistema que controle el
patrimonio que está bajo su administración y la gestión de necesidades internas de cada uno de los
departamentos.
El departamento de Servicios Generales es el encargado de proveer de suministros a los diferentes
departamentos mediante actas de pedidos y actas de entrega recepción.
Esta información se encuentra desorganizada por tanto implica costos y tiempo para la verificación de
existencias en la bodega de suministros.
1.2. Problema
“La Dirección Provincial del IESS de Imbabura actualmente no cuenta con una herramienta de
gestión y control de procesos para Activos Fijos, Inventario de Suministros, Elaboración del Plan
Anual de Compras y Manejo de Partidas Presupuestarias de Adquisiciones, ya que el manejo de la
información se realiza de una forma manual y poco eficiente.”
“La Dirección Provincial del IESS de Imbabura no cuenta con un sistema informático que le facilite la
información necesaria para la gestión y el control de inventarios de Suministros.”
1.3. Objetivos
1.3.1 Objetivo General
Implementar un sistema informático que mejore la gestión y control del inventario de Suministros para
la Dirección Provincial del IESS de Imbabura que permita el control de stock en bodega y agilite el
proceso de entrega de suministros.
1.3.2 Objetivos Específicos
 Estudiar las herramientas apropiadas a utilizar en el desarrollo del proyecto con la creación
previa de un demo de la aplicación para la posterior revisión de fallas, y sus respetivos
manuales, para el correcto uso de la aplicación tanto para el administrador como para los
demás usuarios.

23
 Realizar la integración correcta de los módulos de Gestión y Control de Activos Fijos Bienes
Muebles, Inventario de Suministros y de Elaboración del PAC y Manejo de Partidas
Presupuestarias de Adquisiciones.
 Solicitar apoyo y autorización para tener acceso a la información requerida para el diseño e
implementación del Módulo de Gestión y Control de Inventarios de Suministros para la
Dirección provincial del IESS de Imbabura.
 Permitir la reducción de tiempos de operación y mantener la información bien organizada y
segura para la Dirección Provincial del IESS de Imbabura.
 Registrar las facturas de compra de las adquisiciones de suministros.
 Facilitar la identificación precisa de un suministro, permitiendo su ubicación, estado actual y el
número de existencias en el menor tiempo.
1.4. Justificación
Ya que la institución se encuentra actualmente en una constante transformación con la adquisición de
nuevos bienes se realizó una reunión con el Dr. Vicente Muñoz Director General del IESS de Imbabura
y el Ing. Mario Medina Jefe del Departamento de Sistemas donde se hizo la exposición sobre el
problema planteado anteriormente y se sugirió la sistematización de información del proceso de
inventario de suministros brindando el apoyo y aprobación de parte de la institución.
También se ha visto la necesidad de implementar un sistema que integre los procesos de la Institución,
con herramientas que ayuden a mejorar la gestión logística y administrativa, permitiendo al personal de
la institución contar con información confiable, segura y en tiempo real.
La institución actualmente no cuenta con la información actualizada, sobre todo la herramienta que le
proporcione esta información, por tanto se ha visto la necesidad de implementar un sistema Web, con
herramientas que ayuden a mejorar la gestión , permitiendo al personal de la institución contar con
información confiable, segura y en tiempo real.
Mediante el manejo de estas herramientas permitirá registrar en forma sistematizada y oportuna los
movimientos de suministros para obtener la información de forma inmediata y segura.

24
Para implementar el sistema Web se utilizara herramientas Oracle, Framework JSF, patrón de diseño
MVC, para brindar seguridad en los datos que son registrados, obtener un buen rendimiento, que sea
estable, escalable entre otras características.
1.5. Alcance
Esta aplicación será parametrizable y posteriormente implementada en las demás unidades del Instituto
Ecuatoriano de Seguridad Social como son: Seguro Campesino, Seguro de Pensiones, Seguro de
Riesgos de Trabajo, Seguro General de Salud Individual y Familiar.
La aplicación tiene como finalidad sistematizar y administrar eficientemente la información que será
utilizada por todo el personal involucrado de las diferentes áreas de la institución como son:
Sistemas: realiza un seguimiento del desarrollo del proyecto, aprueba requisitos y funcionalidades.
Funcionarios: elaboración de pedidos internos de suministros.
Responsable de Suministros: ingreso de suministros por compra y entrega de suministros bajo pedido
interno.
El Módulo de Gestión y Control de Inventarios de Suministros se integrará con: El Módulo de
Elaboración del PAC y Manejo de Partidas Presupuestarias de Adquisiciones y el Módulo de Activos
Fijos de Bienes Muebles.
Figura 1: MÓDULOS del SGCP
Fuente: Propia

25
1.6. Beneficios
Con la implementación del Módulo de Gestión y Control de Inventarios de Suministros para la
Dirección Provincial del IESS de Imbabura, basado en la tecnología J2EE y utilizando las herramientas
Oracle permitirá al responsable de suministros tener un mejor control del ingreso y egreso de
suministros a bodega, los funcionarios de las diferentes áreas de trabajo podrán realizar pedidos en
base a los requerimientos de suministros, el sistema se integrará con el módulo de Elaboración del
PAC y Manejo de Partidas Presupuestarias de Adquisiciones y con el módulo de Gestión y Control de
Activos Fijos de Bienes Muebles permitiendo interactuar de una forma dinámica y que los procesos
relacionados se integren de una manera eficiente en el sistema web de Gestión y Control de Procesos
para la Dirección Provincial del IESS de Imbabura.

27
2. Capítulo II: Marco Teórico
2.1. Lenguaje Java
Java es un lenguaje de programación orientado a objetos desarrollado por Sun Microsystems a
principio de los años 90´s.
Figura 2: Plataforma Java
2.2. Plataforma Java
Se entiende por plataforma1
al entorno de hardware y software en el cual se ejecutan programas.
JAVA2
, está basado solo en software que puede ser usado sobre varios sistemas operativos y hardware.
Consta de tres componentes
El Lenguaje: es un lenguaje de propósito general, de alto nivel que utiliza el paradigma de orientación
a objetos.
La Maquina Virtual: Los programas escritos en Java son compilados como archivos ejecutables de
una maquina virtual llamada Java Virtual Machine (JVM), esto nos permite que los programas
ejecutables puedan ejecutarse en distintas arquitecturas.
Las Bibliotecas: El conjunto de bibliotecas del lenguaje es conocido como la Java Aplication
Programming Interface (Java API) y es un conjunto de componentes que proporcionan diferentes
herramientas para el desarrollo.
2.3. Plataforma Java EE 63
Conjunto de especificaciones y prácticas coordinadas que juntas permiten soluciones para el
desarrollo, despliegue y gestión de aplicaciones multicapa centradas en servidor.
1
Plataforma: Específica, capaz de interpretar y ejecutar instrucciones expresadas en un código binario especial.
http://es.wikipedia.org/
2
Java: Es un lenguaje de programación de alto nivel, orientado a objetos.
Fuente: http://es.wikipedia.org/wiki/Java
3
Fuente: http://www.hoysoftware.com/nuevo-java-ee-6/

28
La principal novedad es su mayor flexibilidad, algo que posibilita un campo de acción más amplio
para las empresas desarrolladoras.
Java EE 6 puede trabajar sobre perfiles concretos en determinados escenarios. Ya existe uno diseñado
para funcionar como perfil web, que permite efectuar el despliegue de distintas aplicaciones web sin
necesitar el empleo de funcionalidades empresariales complejas. De esta manera, se obtiene un
interesante ahorro de recursos, por ejemplo al funcionar asociado al Enterprise Java Beans 3.1 Lite, que
se agrega en la flamante versión.
La nueva plataforma Java EE 6 también cuenta con la posibilidad de reutilizar código en los archivos
de aplicaciones web, además de incorporar anotaciones mediante la plataforma para facilitar el
desarrollo de aplicaciones.
Lo cierto es que Java es una aplicación que ha superado la barrera del mundo de los desarrolladores, ya
que interviene en acciones tan simples y cotidianas en la web como jugar en línea, participar en
sesiones de chat, realizar cálculos y efectuar simulaciones en una página web, disfrutar imágenes en
tres dimensiones o desarrollar las aplicaciones básicas que se utilizan en el e-commerce. Por lo tanto, la
nueva versión Java EE 6 puede ser la llave para ingresar a nuevas funciones y utilidades.
Esquema General Java EE
Figura 3: Esquema General Java EE
2.3.1 Componentes de la arquitectura Java EE
Las Aplicaciones Java EE se componen de componentes. Un componente Java EE es una unidad
autónoma de software funcional que se ensambla en una aplicación Java EE con sus clases y archivos
relacionados y que se comunica con otros componentes.

29
La especificación Java EE se define los siguientes componentes Java EE:
 Los clientes de aplicaciones y applets son componentes que se ejecutan en el cliente.
 Java Servlets, Java Server Faces y Java Server Pages (JSP) componentes de la tecnología son
componentes Web que se ejecutan en el servidor.
 Enterprise Java Beans (EJB) (enterprise beans) son componentes de negocio que se ejecutan en
el servidor.
El gráfico se describe a continuación:
Figura 4: Arquitectura Java EE
2.4. Subversión (SVN Server)4
Subversion es un sistema de control de versiones. ¿Qué es esto? .Recordamos cuando hacíamos
trabajos del colegio en grupo. Nos encontrábamos en que era muy difícil coordinarse. Si el grupo era
de 3 personas, se repartía el trabajo que cada uno hiciera una sección independiente del trabajo,
siguiendo las mismas pautas comunes, pero sin tocar directamente el trabajo de los demás. Esto, hacía
que en su casa (donde cada alumno trabajaba), hubiera una copia totalmente diferente del trabajo, hasta
que un día, todo el grupo se reunía, para mezclarlos todo y darle un sentido pleno.
4
Fuente: http://piposerver.com/joomla157/index.php?option=com_content&view=article&id=50:howto-subversion-svn-
espanol&catid=20:manuals-howto&Itemid=43

30
Utiliza el concepto de revisión para guardar los cambios producidos en el repositorio. Entre dos
revisiones sólo guarda el conjunto de modificaciones (delta), optimizando así al máximo el uso de
espacio en disco.
SVN permite al usuario crear, copiar y borrar carpetas con la misma flexibilidad con la que lo haría si
estuviese en su disco duro local. Dada su flexibilidad, es necesaria la aplicación de buenas prácticas
para llevar a cabo una correcta gestión de las versiones del software generado.
2.4.1 TTB, La Estructura Habitual Subversion5
La estructura TTB se ha convertido en el estándar de facto en los repositorios SVN. TTB son las
iniciales de las tres carpetas que compondrán el primer nivel de directorios del repositorio: Trunk, Tags
y Branches. Cada carpeta tiene su funcionalidad específica, pero Subversion, al igual que un disco
duro, las tratará por igual y no limitará las operaciones a realizar sobre ellos, por tanto conocer y
aplicar las buenas prácticas ayudará a los usuarios a darles un uso correcto.
A continuación se listan las funcionalidades que se le debería dar a cada rama del repositorio:
 Trunk: Rama de desarrollo principal.
 Tags: Rama de gestión de versiones. Reservado para versiones cerradas, por tanto no se
desarrollará sobre esta rama.
 Branches: Rama con evoluciones paralelas al Trunk.
Figura 5: La Estructura Habitual Subversion
5
Fuente: http://blogs.tecsisa.com/articulos-tecnicos/buenas-practicas-de-gestion-de-versiones-con-subversion/

31
Los conceptos de desarrollo principal, evolución y congelación se explican a continuación.
Operaciones Habituales con Subversion
A continuación se presentan las operaciones más habituales con las que nos encontramos trabajando
con Subversion.
Trabajo en Equipo
SVN permite al menos que dos personas puedan modificar el código.
Una característica importante de Subversion es que, a diferencia de CVS, los demás archivos con
versionamiento no tienen cada uno un número de revisión independiente, en cambio, todo el
repositorio tiene un único número de versión que identifica un estado común de todos los archivos del
repositorio en un instante determinado del repositorio que se está trabajando.
Subversion puede acceder al repositorio a través de redes, lo que le permite ser usado por personas que
se encuentran en distintas computadoras. A cierto nivel, la posibilidad de que varias personas puedan
modificar y administrar el mismo conjunto de datos desde sus respectivas ubicaciones fomenta la
colaboración. Se puede progresar más rápidamente sin un único conducto por el cual deban pasar todas
las modificaciones. Y puesto que el trabajo se encuentra bajo el control de versiones, no hay razón para
temer por que la calidad del mismo vaya a verse afectada si se ha hecho un cambio incorrecto a los
datos, simplemente deshaga ese cambio.
2.4.2 Ventajas
Se sigue la historia de los archivos y directorios a través de copias y renombrados.
Las modificaciones (incluyendo cambios a varios archivos) son atómicas.
Se envían sólo las diferencias en ambas direcciones.
Permite selectivamente el bloqueo de archivos. Se usa en archivos binarios que, al no poder fusionarse
fácilmente, conviene que no sean editados por más de una persona a la vez.
2.4.3 Carencias
El manejo de cambio de nombres de archivos no es completo. Lo maneja como la suma de una
operación de copia y una de borrado.

32
No resuelve el problema de aplicar repetidamente parches entre ramas, no facilita llevar la cuenta de
qué cambios se han realizado. Esto se resuelve siendo cuidadoso con los mensajes de commit.
La manera de utilizar SVN es:
1. Para comenzar con la resolución de una tarea, se deberá asegurar la sincronización con el
repositorio, bien con un Update o bien con un Checkout dependiendo de si se dispone previamente del
código en el entorno local o no.
2. Se deberá hacer el Commit para hacer público al resto del equipo el código desarrollado. El
alcance del Commit deberá limitarse al código relevante a la resolución de la tarea, y no mezclar
desarrollos de distintas tareas en un mismo Commit.
2.5. Patrones de diseño MVC
2.5.1 Definición
El Modelo Vista Controlador (MVC) es un patrón de diseño6
de software, el cual divide la interfaz
de usuario y la lógica de negocio en tres componentes distintos. Este patrón se utiliza frecuentemente
en aplicaciones web donde la vista es la página HTML y el código que provee de datos dinámicos a la
página. El modelo estaría compuesto por el Sistema de Gestión de Base de Datos y la lógica de
negocio. Y el controlador es el que se encarga de recibir y procesar los eventos de entrada desde la
vista.
Entrando un poco más en detalle podemos definir cada uno de los componentes de la siguiente manera:
 Modelo: Es la representación específica de la información con la que se trabaja en el sistema.
Es decir, el modelo se limita a la vista y su controlador facilitando las presentaciones visuales
complejas. También es posible que el modelo opere con más datos no relativos a la presentación,
integrando de este modo el uso de otras lógicas de negocio y datos afines al sistema modelado.
 Vista: Es la presentación del modelo en un formato adecuado para la interacción con el mismo,
típicamente una interfaz de usuario.
 Controlador: Responde a eventos, normalmente acciones realizadas por el usuario y realiza
peticiones al modelo y a la vista.7
6
Patrón de diseño: Es una solución probada para un problema en un contexto.
http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/rivera_l_a/capitulo2.pdf
7
Fuente: http://www.comunicacionweb.com/los-patrones-de-diseno-mvc/

33
8
Figura 6: Modelo Vista Controlador
2.5.2 Ciclo de Vida MVC
El ciclo de vida de MVC es normalmente representado por las 3 capas presentadas anteriormente y el
cliente (también conocido como usuario).
El siguiente diagrama representa el ciclo de vida de manera sencilla:
Figura 7: Ciclo de Vida MVC
El primer paso en el ciclo de vida empieza cuando el usuario hace una solicitud al controlador con
información sobre lo que el usuario desea realizar. Entonces el controlador decide a quién debe delegar
la tarea y es aquí donde el Modelo empieza su trabajo. En esta etapa, el Modelo se encarga de realizar
operaciones sobre la información que maneja para cumplir con lo que le solicita el Controlador. Una
8
Fuente: http://www.sicuma.uma.es/sicuma/Formacion/documentacion/JSF.pdf

34
vez que termina su labor, le regresa al Controlador la información resultante de sus operaciones, el cual
a su vez redirige a la Vista.
La Vista se encarga de transformar los datos en información visualmente entendible para el usuario.
Finalmente, la representación gráfica es transmitida de regreso al Controlador y éste se encarga de
transmitírsela al usuario.
El ciclo entero puede empezar nuevamente si el usuario lo requiere.
2.5.3 Ventajas y Desventajas de MVC
2.5.3.1 Ventajas MVC
Las principales ventajas de hacer uso del patrón MVC son:
1-La separación del Modelo de la Vista, es decir, separar los datos de la representación visual de los
mismos.
2-Es mucho más sencillo agregar múltiples representaciones de los mismos datos o información.
3-Facilita agregar nuevos tipos de datos según sea requerido por la aplicación ya que son
independientes del funcionamiento de las otras capas.
4-Crea independencia de funcionamiento.
5-Facilita el mantenimiento en caso de errores.
6-Ofrece maneras más sencillas para probar el correcto funcionamiento del sistema.
7-Permite el escalamiento de la aplicación en caso de ser requerido.
2.5.3.2 Desventajas de MVC
Las desventajas de seguir el planteamiento de MVC son:
1-La separación de conceptos en capas agrega complejidad al sistema.
2-La cantidad de archivos a mantener y desarrollarse incrementa considerablemente.
3-La curva de aprendizaje del patrón de diseño es más alta que usando otros modelos más sencillos.9
9
Fuente: http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/rivera_l_a/capitulo2.pdf

35
2.6. Base de datos Oracle 11g
2.6.1 Introducción
Oracle Database 11 g ofrece un rendimiento líder en la industria, escalabilidad, seguridad y fiabilidad
en la elección de un solo clúster o servidores que ejecutan Windows, Linux y UNIX. Proporciona
funciones completas para gestionar fácilmente el procesamiento de transacciones más exigente,
inteligencia empresarial y aplicaciones de gestión de contenidos.Cuenta con administración de usuarios
así como la administración de roles, además soporta triggers y procedimientos almacenados, cuenta
con conectividad JDBC y ODBC, siempre y cuando se tengan los drivers adecuados para la misma. Es
un DBMS seguro ya que cuenta con un proceso de sistema de respaldo y recuperación de información.
Soporta Data Warehouse por lo que facilita el acceso a la información y da mayor versatilidad. La
mayor parte de las empresas de telecomunicaciones en Latinoamérica utilizan Oracle, por lo que se
puede decir que es un DBMS confiable, seguro para ser utilizado en una empresa y sobre todo permite
reducir costos por su accesibilidad en el mercado.
Oracle es un sistema de gestión de base de datos relacional (o RDBMS por el acrónimo en inglés de
Relational Data Base Management System), desarrollado por Oracle Corporation. Se considera a
Oracle como uno de los sistemas de bases de datos más completos, destacando su:
 Soporte de transacciones.
 Estabilidad.10
 Escalabilidad.11
 Soporte multiplataforma12
.
La base de datos Oracle en Windows ha evolucionado desde un nivel básico de integración del sistema
operativo hasta utilizar servicios más avanzados en la plataforma Windows, con inclusión de los
sistemas Itanium y AMD64/EM64T. Como siempre, Oracle continúa innovando y aprovechando las
10
Estabilidad: Se dice que un sistema es estable cuando su nivel de fallos disminuye.
Fuente: http://es.wikipedia.org/wiki/Estabilidad
11
Escalabilidad: es la propiedad deseable de un sistema, una red o un proceso, que indica su habilidad para extender el
margen de operaciones sin perder calidad, o bien manejar el crecimiento continuo de trabajo de manera fluida, o bien para
estar preparado para hacerse más grande sin perder calidad en los servicios ofrecidos.
Fuente: http://es.wikipedia.org/wiki/Escalabilidad.
12
Multiplataforma: es un término usado para referirse a los programas, sistemas operativos, lenguajes de programación, u
otra clase de software, que puedan funcionar en diversas plataformas, es decir es una combinación de hardware y software
usada para ejecutar aplicaciones; en su forma más simple consiste únicamente de un sistema operativo, una arquitectura, o una
combinación de ambos.

36
nuevas tecnologías de Windows. Este proyecto ofrece información general sobre las principales
características de la versión más reciente de Oracle, la versión Oracle Database 11g.
Hay dos formas de licenciarse, por usuario y por procesador, es decir, que se puede pagar por el
número de usuarios o por el número de procesadores.
Los Tipos de datos generales que soporta son:
VARCHAR2, NVARCHAR2, CHAR RAW, NUMBER FLOAT, INTEGER, DATE, TIMESTAMP,
WITH, TIMEZONE, As TIMES,TAMPCLOB,NCLOB,BLOB,BFILE,LONG,LONG RAW
2.6.2 Características de Oracle 11g
Oracle Database -Es un sistema de gestión de base de datos relacional (RDBMS Relational Data Base
Management System), desarrollado por Oracle Corporation. Oracle se destaca por:
 Soporte de transacciones: una transacción13
en un sistema de gestión de bases de datos
(SGBD), es un conjunto de órdenes que se ejecutan formando una unidad de trabajo, es decir, en forma
indivisible. Un SGBD se dice transaccional si es capaz de mantener la integridad de los datos, haciendo
que estas transacciones no puedan finalizar en un estado intermedio. Cuando por alguna causa el
sistema debe cancelar la transacción, empieza a deshacer las órdenes ejecutadas hasta dejar la base de
datos en su estado inicial (llamado punto de integridad), como si la orden de la transacción nunca se
hubiese realizado.
 Estabilidad: con una tasa de errores mínima.
 Escalabilidad: capacidad del sistema informático de cambiar su tamaño o configuración para
adaptarse a las circunstancias cambiantes.
 Soporte multiplataforma: se puede instalar en Linux, Unix, Windows, Solaris (SPARC).14
2.6.3 Importancia de Oracle 11g
 Oracle es básicamente una herramienta cliente/servidor para la gestión de Bases de Datos.
 Para desarrollar aplicaciones en Oracle se necesita PL/SQL, store procedures y SQL para crear
el formulario.
13
Transacción: Una transacción es una interacción con una estructura de datos compleja, compuesta por varios procesos que
se han de aplicar uno después del otro. La transacción debe realizarse de una sola vez y sin que la estructura a medio
manipular pueda ser alcanzada por el resto del sistema hasta que se hayan finalizado todos sus procesos.
http://es.wikipedia.org/wiki/Transacción_(informática)
14
Fuente: http://es.wikipedia.org/wiki/Oracle_11g

37
 PL/SQL es un lenguaje de programación incrustado en Oracle, el mismo que soporta consultas
y manipulación de datos que se usan en SQL (lenguaje declarativo, que permite realizar ciertas
operaciones en las bases de datos).
 Existen dos formas de licenciarse en Oracle, una es por el número de procesadores y la otra el
por el número de usuarios.
 El preferible licenciarse por número de usuarios ya que los costos son significativamente más
baratos que por procesador.
 Oracle es portable porque se puede instalar en la gran mayoría de los sistemas operativos y
también tiene una gran capacidad de almacenamiento.
2.7. Servidor de aplicaciones Weblogic
2.7.1 Definición de Servidor de Aplicaciones
Un servidor de aplicaciones es un servidor que proporciona aplicaciones de software con servicios tales
como seguridad, servicios de datos, soporte de transacciones, balanceo de carga, y la gestión de
grandes sistemas distribuidos. El término se utiliza a menudo para los servidores web que soportan
la plataforma Java, Enterprise Edition , sin embargo su uso no se limita a Java.
2.7.2 Definición de WebLogic Server
Es un popular servidor de aplicaciones J2EE de BEA y es bueno para la construcción de SOA (Service
Oriented Architecture), es un servidor de aplicaciones Java y servicios web que se encarga de la lógica
empresarial de los programas de aplicación.
La línea de productos Oracle WebLogic 11g Application Server es una plataforma Java que permite
desarrollar, implementar e integrar aplicaciones empresariales.
Oracle WebLogic: Es un servidor de aplicaciones de Java EE y también un servidor Web HTTP
desarrollado por BEA Systems posteriormente adquirida por Oracle Corporation. Se ejecuta en Linux,
Microsoft Windows y otras plataformas15
.
15 Plataforma: Es una combinación de hardware y software usada para ejecutar aplicaciones; en su forma más simple
consiste únicamente de un sistema operativo, una arquitectura, o una combinación de ambos.
Fuente: http://es.wikipedia.org/wiki/Multiplataforma

38
2.7.3 Características de WebLogic
Las principales características de WebLogic Server incluye conectores que hacen posible que
cualquier aplicación heredada en cualquier cliente pueda operar con aplicaciones de servidor, los
componentes de Enterprise JavaBean (EJB)16
,la puesta en común de recursos y el uso compartido de
conexión hace que las aplicaciones sean muy escalables. Una consola de administración con una
interfaz de usuario17
hace que las tareas de gestión sean más eficientes y características tales como
Secure Sockets Layer (SSL) para el cifrado de las transmisiones de datos, así como autenticación y
autorización de los mecanismos, que las aplicaciones y transacciones sean seguras.
Oracle WebLogic Server es una solución escalable, lista para la empresa de Java Plataform, Enterprise
Edition (Java EE) para servidor de aplicaciones. La infraestructura de WebLogic Server soporta el
despliegue de muchos tipos de aplicaciones distribuidas y es una base ideal para la creación de
aplicaciones basadas en Arquitecturas Orientadas a Servicios (SOA). SOA es una metodología de
diseño orientado a maximizar la reutilización de servicios de aplicación.
Las tecnologías de componentes J2EE incluyen servlets, páginas JSP, y JavaBeans Enterprise. Los
servicios J2EE incluyen el acceso a protocolos de red, a sistemas de base de datos, y a sistemas
estándares de mensajería. Para construir una aplicación de servidor WebLogic, debemos crear y
ensamblar componentes, usando los APIs de servicio cuando sea necesario. Los componentes se
ejecutan en contenedor Web del servidor WebLogic o el contenedor de EJB. Los componentes Web
proporcionan la lógica de presentación para las aplicaciones J2EE basadas en navegador. Los
componentes EJB encapsulan objetos y procesos del negocio. Las aplicaciones Web y los EJBs se
construyen sobre servicios de aplicación de J2EE, como JDBC, JMS (servicio de mensajería de Java),
y JTA (API de Transacciones de Java).
WebLogic puede utilizar Oracle, DB2, Microsoft SQL Server, y otras bases de datos que se ajusten al
estándar JDBC. El servidor WebLogic es compatible con WS-Security y cumple con los estándares de
16 EJB: El objetivo de los EJB es dotar al programador de un modelo que le permita abstraerse de los problemas generales de
una aplicación empresarial (concurrencia, transacciones, persistencia, seguridad, etc.) para centrarse en el desarrollo de la
lógica de negocio en sí.
Fuente: http://es.wikipedia.org/wiki/EJB
17 Interfaz de usuario: es el medio con que el usuario puede comunicarse con una máquina, un equipo o una computadora, y
comprende todos los puntos de contacto entre el usuario y el equipo.
Fuente: http://es.wikipedia.org/wiki/Interfaz_de_usuario

39
J2EE 1.3 desde su versión 7 y con la J2EE 1.4 desde su versión 9 y Java EE para las versiones 9.2 y
10.x.
Oracle 18
WebLogic Server es parte de Oracle WebLogic Plataform. Los demás componentes de esta
plataforma son:
 Portal que incluye el servidor de comercio y el servidor de personalización(construido sobre un
motor de reglas producido también por Bea)
 WebLogic Integration
 WebLogic Workshop, una IDE para Java
WebLogic Server incluye interoperabilidad .NET y admite las siguientes capacidades integración
nativa:
Oracle WebLogic Server Process Edition también incluye Business Process Management y
funcionalidad de mapeo de datos.
WebLogic admite políticas de seguridad administradas por Security Administrators. El modelo de
seguridad de WebLogic Server incluye:
 Separar la lógica de aplicaciones de negocio del código de seguridad
2.8. IDE19
de desarrollo JDeveloper
2.8.1 Introducción
Figura 8: Jdeveloper 11g R2
Fuente: Propia
Oracle JDeveloper es un entorno integrado de desarrollo que simplifica el desarrollo de Java basada en
SOA y las aplicaciones Java EE.
18
J2EE: Es una plataforma de programación—parte de la Plataforma Java—para desarrollar y ejecutar software de
aplicaciones en el lenguaje de programación Java con arquitectura de N capas distribuidas y que se apoya ampliamente en
componentes de software modulares ejecutándose sobre un servidor de aplicaciones.
Fuente: http://es.wikipedia.org/wiki/J2EE
19
IDE: Es un entorno de programación que ha sido empaquetado como un programa de aplicación, es decir, consiste en un
editor de código, un compilador, un depurador y un constructor de interfaz gráfica (GUI).

40
Ofrece completo desarrollo en: Java, XML ,SQL y PL/SQL , HTML , JavaScript , BPEL y PHP .
JDeveloper cubre el ciclo de desarrollo completo desde el diseño hasta la codificación, depuración,
optimización y creación de perfiles de implementar.
Con JDeveloper, Oracle ha tratado de simplificar el desarrollo de aplicaciones, centrándose en
proporcionar un enfoque visual y declarativo para el desarrollo de aplicaciones, además de la
construcción de una avanzada codificación y el medio ambiente.
Oracle JDeveloper integra con el Oracle Application Development Framework20
( Oracle ADF ) - en el
marco que simplifica aún más el desarrollo de aplicaciones.
El IDE principal expone una API que otros equipos en Oracle utilizan para crear extensiones de
JDeveloper. La misma plataforma de IDE también sirve como la base de otro producto de Oracle, SQL
Developer , el cual Oracle Corporation promueve específicamente para los desarrolladores de bases de
datos y PL/SQL-.
JDeveloper ofrece el desarrollo de Oracle Fusion Middleware y Oracle Fusion Applications con
soporte para el ciclo de vida completo.
2.8.2 Características
Antes de JDeveloper 11g, Oracle JDeveloper se produjo en tres ediciones: Edición Java, J2EE Edition
y la edición Studio. Cada uno ofrece más características en la parte superior de los otros, y todos ellos
vinieron de forma gratuita. JDeveloper 11g sólo tiene dos ediciones: Studio Edition y Java. En
JDeveloper 11g, J2EE características de la edición se rodó en el Studio Edition.
Una lista de alto nivel de características incluye:
Java Edition
 Editor de código
 Código de la Navegación
 Refactoring
20
Framework: Es una estructura conceptual y tecnológica de soporte definido, normalmente con artefactos o módulos de
software concretos, con base a la cual otro proyecto de software puede ser más fácilmente organizado y desarrollado.
http://es.wikipedia.org/wiki/Framework
http://www.oracle.com/technetwork/developer-tools/jdev/overview/index.html

41
 Java SE 5 de Apoyo
 Balancearse
 Unidad de Prueba
 Control de versiones
 Auditoría y Métrica
 Depuración
 API abierta y extensiones
 Perfilado
 Hormiga de Apoyo
 Maven Apoyo
 Compatibilidad21
con XML
 Asistencia al usuario
J2EE Edition
 JSP, Struts
 JSF
 JSF 2.0
 Facelets
 EJB
 TopLink
 Servicios Web
 REST Web Services
21
Compatibilidad: Es la condición que hace que un programa y un sistema, arquitectura o aplicación logren comprenderse
correctamente tanto directamente o indirectamente (mediante un algoritmo).
http://es.wikipedia.org/wiki/Compatibilidad_(informática)

42
 UML
 Base de datos para el Desarrollo
 Despliegue y gestión
 Hudson
Studio Edition
 ADF enlace de datos
 ADF Faces
 ADF Faces Skin Editor
 ADF Mobile
 ADF Business Components
 Alimentador automático de documentos de giro
 Alimentador automático de documentos de implementación de
 Diseñador de BPEL
 Diseñador de ESB
 El desarrollo de portlets
 Portlet / JSF Puente
2.8.3 Visual y declarativa
El editor de código JDeveloper ofrece un rico conjunto de características de codificación, visuales y no
visuales de servicios públicos que ofrecen diferentes puntos de vista del código. El software
proporciona diálogos que guían el uso de componentes Java EE.
Por ejemplo, JDeveloper proporciona una representación visual WYSIWYG editor
de HTML , JSP, JSF . El editor visual permite a los desarrolladores modificar el diseño y las
propiedades de los componentes visuales: la herramienta de re-genera el código. Cualquier cambio en

43
el código se refleja inmediatamente en el punto de vista visual. JDeveloper proporciona una función
similar para la generación de flujos de JSF y páginas Struts.
JDeveloper 11g el es el primero de los productos pertenecientes al Fusion Middleware que sale en esa
versión. Uno de los principales cambios en JDeveloper11g a diferencia de cualquier versión previa de
JDeveloper es que a partir de esta, y tras la adquisición de BEA, el contenedor embebido que viene con
la herramienta y naturalmente que está en producción es WebLogic Server 10.3.
2.8.4 Licencia
JDeveloper es el software propietario gratuito para el desarrollo y despliegue.
Oracle ADF tiene una licencia de tiempo de ejecución cuando se despliega fuera de un servidor de
aplicaciones Oracle.22
2.9. Enterprise Java Bean (EJB)
2.9.1 Definición de Enterprise Java Bean (EJB):
Son componentes Java EE que implementan la tecnología Enterprise JavaBeans (EJB).
Un EJB se ejecuta en un contenedor de EJB que es un entorno de ejecución dentro un servidor de
aplicaciones. Aunque transparente para la aplicación, el contenedor de EJB provee una serie de
servicios a nivel de sistema entre los que se incluyen las transacciones y la seguridad de los EJBs.
Estos servicios permiten la construcción rápida y el despliegue de EJBs los cuáles forman el núcleo
transaccional de las aplicaciones JEE.
2.9.2 Cuándo Utilizar EjBs
 La aplicación debe ser escalable.
 Las transacciones tienen que asegurar la integridad de los datos
 La aplicación puede tener varios tipos de clientes incluso en diferentes plataformas
La idea de EJB es mover la lógica de negocio fuera de la capa web y en una capa independiente que se
centra exclusivamente en la modelización del dominio del negocio y las operaciones vinculadas.
22
Fuente:http://translate.google.com.ec/translate?hl=es&langpair=en%7Ces&u=http://en.wikipedia.org/wiki/JDeveloper
http://jmaw.blogspot.com/2011/04/introduccion-la-arquitectura.html

44
Un Java Bean es un componente hecho en software que se puede reutilizar y que puede ser manipulado
visualmente por una herramienta de programación en lenguaje Java.23
Un EJB son componentes del lado del servidor que encapsulan la lógica del negocio de una aplicación.
Los EJB simplifican el desarrollo de aplicaciones de gran porte que deben ser distribuidas, esto se
logra gracias a que los servicios de transacciones, seguridad y distribución son administrados por el
contenedor y no por el programador, logrando así facilitar la administración de los EJB.24
2.9.3 Funcionamiento de componentes EJB
Su funcionamiento se basa fundamentalmente en el trabajo del contenedor EJB. El contenedor es un
programa Java que corre en el servidor y que contiene todas las clases y objetos necesarios para el
correcto funcionamiento de los Enterprise beans.
2.9.4 Tipos de Beans
La tecnología EJB define tres tipos de Beans:
 Beans de sesión
 Beans de entidad
 Beans dirigidos por mensajes
2.9.4.1 Beans de sesión:
Las variables de instancia de la clase del bean guardan sus valores (estado conversacional)
manteniéndolo mientras dure la sesión. Si el cliente termina o elimina el bean, este estado desaparece.
Como su nombre indica, un bean de sesión no se comparte. Sólo puede tener un cliente a la vez.
Un bean de sesión no es persistente.
2.9.5 Beans de sesión sin estado o stateless:
No mantiene un estado conversacional con el cliente: los valores de sus variables de instancia solo se
mantienen durante la invocación de un método. Excepto durante la invocación de un método, todas las
instancias de los beans sin estado son equivalentes, permitiendo al contenedor de EJB asignar una
instancia a cualquier cliente. Ofrecen mejor escalabilidad para aplicaciones que soportan un gran
número de clientes y son los únicos que soportan la implementación de servicios web.
23
Fuente: http://www.sc.ehu.es/sbweb/fisica/cursoJava/applets/javaBeans/fundamento.htm
24
Fuente: http://www.epidataconsulting.com/tikiwiki/tiki-pagehistory.php?page=EJB&preview=14#Que_es_un_EJB

45
Figura 9: Beans de sesión sin estado
Los beans de sesión sin estado se usan en general para encapsular procesos de negocio, más que datos
de negocio.
Es apropiado usar beans de sesión sin estado cuando una tarea no está ligada a un cliente específico.
Los EJB de sesión sin estado no retienen el estado de cada cliente entre múltiples requerimientos.
2.9.6 Beans de sesión con estado o stateful:
El estado se mantiene durante la sesión del cliente con el bean.
La instancia es reservada para el cliente y cada una almacena la información del cliente.
La sesión finaliza si el cliente remueve el bean o finaliza su sesión.25
Los EJB de sesión con estado retienen el estado de cada cliente individual entre múltiples
requerimientos.
Si el estado del bean cambia cuando se invoca a un método, dicho estado estará disponible para el
mismo cliente en la siguiente invocación.
25
Fuente: http://www2.elo.utfsm.cl/~elo326/presentaciones/Ronda2/SesionBeans.pdf

46
Figura 10: Beans de sesión con estado
2.9.6.1 Beans de entidad:
Los beans de entidad modelan conceptos o datos de negocio que puede expresarse como nombres. Esto
es una regla sencilla más que un requisito formal, pero ayuda a determinar cuándo un concepto de
negocio puede ser implementado como un bean de entidad.
2.9.6.2 Beans dirigidos por mensajes:
Permiten que las aplicaciones J2EE reciban mensajes JMS de forma asíncrona. Así, el hilo de
ejecución de un cliente no se bloquea cuando está esperando que se complete algún método de negocio
de otro Enterprise bean. Los mensajes pueden enviarse desde cualquier componente J2EE (una
aplicación cliente, otro Enterprise bean, o un componente Web) o por una aplicación o sistema JMS
que no use la tecnología J2EE. 26
2.10. Java Persistence API (JPA)
Proporciona un estándar para gestionar datos en aplicaciones Java SE o Java EE, de forma que además
se simplifique el desarrollo de la persistencia de datos.
26
Fuente: http://www.jtech.ua.es/j2ee/2003-2004/abierto-j2ee-2003-2004/ejb/sesion01-apuntes.htm

47
Es una API de persistencia de POJOS (Plain Old Java Object). Es decir, objetos simples que no
heredan ni implementan otras clases como los EJBs. 27
2.10.1 Funcionamiento de JPA
En Java se solucionan problemas de negocio a través de objetos. Sin embargo, las bases de datos
relacionales almacenan la información mediante tablas, filas, y columnas, de manera que para
almacenar un objeto hay que realizar una correlación entre el sistema orientado a objetos de Java y el
sistema relacional de la base de datos.
JPA es una abstracción sobre JDBC que permite realizar dicha correlación de forma sencilla,
realizando toda la conversión entre nuestros objetos y las tablas de una base de datos. Esta conversión
se llama ORM (Object Relational Mapping - Mapeo Relacional de Objetos), y puede configurarse a
través de metadatos (mediante XML o anotaciones). También permite seguir el sentido inverso,
creando objetos a partir de las tablas de una base de datos. A estos objetos se los conoce como
entidades (entities).
2.11. Framework JSF
Java Server Faces (JSF): Es una tecnología y framework para aplicaciones Java basadas en web que
simplifica el desarrollo de interfaces de usuario en aplicaciones Java EE.28
Basado en componentes y eventos del lado del servidor, mantiene del lado del servidor una
representación del interfaz de usuario presentado en el cliente.29
JSF nos ofrece una serie de ventajas:
 El código JSF con el que creamos las vistas (etiquetas jsp) es muy parecido al HTML estándar.
JSF se integra dentro de la página JSP y se encarga de la recogida y generación de los valores
 JSF es extensible, por lo que se pueden desarrollar nuevos componentes a medida, También se
puede modificar el comportamiento del framework mediante APIs que controlan su
funcionamiento.
28
Fuente: http://www.desarrolloweb.com/articulos/2380.php
29
Fuente: http://ccia.ei.uvigo.es/docencia/SCS/1011/transparencias/Tema5-3.JSF.pdf
http://es.wikipedia.org/wiki/JavaServer_Faces

48
- Un modelo de eventos en el lado del servidor.
- Administración de estados.
- Beans administrados.30
2.11.1 Ciclo de Vida JSF:
El ciclo de vida de JSF comienza cuando un usuario hace una petición HTTP a través de su navegador
y termina cuando el servidor le responde con la página correspondiente. Como HTTP es un protocolo
sin estado, no es capaz de “recordar” las transacciones anteriores que se han llevado a cabo entre el
usuario y el servidor.
JSF soluciona esta “falta de memoria” manteniendo vistas en el lado del servidor.
Una vista es un árbol de componentes que representa la UI del usuario. Así, mientras que nosotros nos
centramos en desarrollar los componentes, el ciclo de vida de JSF se preocupa de sincronizar estas
vistas del lado del servidor y lo que se le muestra al usuario.
2.11.2 Fases del ciclo JSF:
2.11.2.1 Restore View
Se crea o restaura el árbol de componentes (la vista) en memoria. Cuando la vista se crea por primera
vez, se almacena en un contenedor padre conocido como Faces Context, y se pasa directamente a la
última fase (Render Response), ya que la petición no tendrá valores que estudiar.
2.11.2.2 Apply Request Values
Se itera sobre los componentes del árbol, comprobando qué valor de la petición pertenece a qué
componente, y los van guardando. Dichos valores se los llama ‘valores locales’.
2.11.2.3 Process Validations
Se realizan las validaciones y conversiones necesarias de los valores locales. Si ocurre algún error en
esta fase, se pasa a la fase Render Response, mostrándole al usuario otra vez la página actual y dándole
así una nueva oportunidad para que pueda introducir los datos correctos.
2.11.2.4 Update Model Values
Se modifican los valores de los beans asociados a los componentes de la vista con los valores locales.
30
Fuente: http://code.google.com/p/fap-devel/wiki/JavaServerFaces
http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=IntroduccionJSFJava

49
2.11.2.5 Invoke Application
Se invoca el método asociado al action del botón o link que pinchó el usuario que permite que se active
el ciclo de vida de la petición. Estos métodos devuelven un String que le indica al gestor de navegación
qué página tiene que devolverle al usuario.31
2.11.2.6 Render Response
El servidor devuelve la página de respuesta al navegador del usuario y guarda el estado actual de la
vista para poder restaurarla en una petición posterior.
2.12. RichFaces
2.12.1 Definición de RichFaces
RichFaces es una fuente abierta Ajax -enabled biblioteca de componentes para Java Server Faces ,
organizado por JBoss. Permite una fácil integración de las capacidades de Ajax en aplicaciones
empresariales de desarrollo.
RichFaces es algo más que una biblioteca de componentes de JavaServer Faces.32
RichFaces es un marco muy útil de código abierto que le permite añadir capacidades de Ajax a sus
aplicaciones JSF (usando los componentes estándar JSF), sin la necesidad de escribir código JavaScript
y administrar la compatibilidad de JavaScript entre navegadores. Se integra con el ciclo de vida de JSF
y otras características de JSF estándar como la validación, la conversión y administración de recursos.33
2.12.2 Funcionamiento de RichFaces:
Mediante sus propias etiquetas se generan eventos que envían peticiones al contenedor Ajax. Estos
eventos se pueden ejecutar por pulsar un botón, un enlace, una región específica de la pantalla, un
cambio de estado de un componente, etc. Esto significa que el programador no debe preocuparse de
crear el código Javascript y el objeto XML Http Request para que se envíe la petición al servidor ya
que el framework lo hará. 34
2.12.3 Características de RichFaces:
Se integra perfectamente en el ciclo de vida de JSF.
RichFaces: Permite definir (por medio de etiquetas JSF) diferentes partes de una página JSF que desea
actualizar con una petición Ajax, y ofrece algunas opciones para enviar las peticiones Ajax al
31
Fuente: http://anadreamy.wordpress.com/2012/02/29/jsf-2-0-el-ciclo-de-vida/
32
Fuente: http://en.wikipedia.org/wiki/RichFaces
33
Fuente: http://es.scribd.com/doc/26352343/JBoss-RichFaces-Capitulo-1-%C2%BFQue-es-RichFaces
34
Fuente: http://code.google.com/p/fap-devel/wiki/RichFaces

50
servidor. Asimismo, la página JSF no cambia de un "regular" de la página JSF y no es necesario
escribir ningún código JavaScript a mano. Mediante el control de todo, desde el lado del servidor, casi
no se necesita JavaScript y el estado de la página se puede mantener fácilmente en el servidor.
Es un proyecto open source, activo y con una comunidad también activa.35
2.13. JasperReport con iRepot
2.13.1 Definición de JasperReports
JasperReports: Es una fuente abierta de Java de informes herramienta que puede escribir en una
variedad de objetivos, tales como: pantalla, una impresora, en PDF , HTML , Microsoft
Excel , RTF , ODT , valores separados por comas o XML archivos. Está completamente escrita en Java
y se puede utilizar en una gran variedad de aplicaciones de Java, incluyendo J2EE o aplicaciones Web,
para generar contenido dinámico.
2.13.2 Funcionamiento de JasperReports
JasperReports trabaja en forma similar a un compilador y a un intérprete. El usuario diseña el reporte
codificándolo en XML de acuerdo a las etiquetas y atributos definidos en un archivo llamado
jasperreports.dtd (parte de JasperReports). Usando XML el usuario define completamente el reporte,
describiendo donde colocar texto, imágenes, líneas, rectángulos, cómo adquirir los datos, como realizar
ciertos cálculos para mostrar totales, etc.
Este archivo fuente XML debe ser compilado para obtener un reporte real. La versión compilada del
fuente es nombrada "archivo jasper" (este termina con .jasper). Un Archivo jasper es el compilado de
un código fuente. Cuando tenemos un archivo jasper, necesitamos otra cosa para producir un reporte:
necesitamos datos. Esto no siempre es cierto. En algunos casos para generar un reporte que no muestre
datos dinámicos, solo texto estático por ejemplo, pero esto puede simplificarse a un reporte que tiene
solamente un registro vacío.
En JasperReports el archivo Jrxml es considerado el "código fuente" para su informe.
Antes de poder ejecutar el informe, debe compilar el archivo en un archivo que tiene una extensión
.Jasper.
35
Fuente: http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=richFacesJsfIntro
http://en.wikipedia.org/wiki/RichFaces.
http://en.wikipedia.org/wiki/JasperReports

51
2.13.3 IReport:
IReport: Es la herramienta visual de diseño más popular para la biblioteca JasperReports y Server
(Business Intelligence). Soporta todos los formatos de salida más importantes y prácticamente
cualquier fuente de datos.
2.13.4 Funcionamiento de IReport
IReport provee a los usuarios de JasperReports una interfaz visual para construir reportes, generar
archivos “jasper” y “print” de prueba. IReport nació como una herramienta de desarrollo, pero puede
utilizarse como una herramienta de oficina para adquirir datos almacenados en una base de datos, sin
pasar a través de alguna otra aplicación. IReport puede leer y modificar ambos tipos de archivo, XML
y jasper. A través de JasperReports, es capaz de compilar XML a archivos jasper y “ejecutar reportes”
para llenarlos usando varios tipos de fuentes de datos (JRDataSource) y exportar el resultado a PDF,
HTML, XLS, CSV.36
2.14. Inventario
2.14.1 Concepto
Los Inventarios son bienes tangibles que se tienen para la venta en el curso ordinario del negocio o
para ser consumidos en la producción de bienes o servicios para su posterior comercialización. Los
inventarios comprenden, además de las materias primas, productos en proceso y productos terminados
o mercancías para la venta, los materiales, repuestos y accesorios para ser consumidos en la producción
de bienes fabricados para la venta o en la prestación de servicios; empaques y envases y los inventarios
en tránsito.
2.14.2 Objetivos del Inventario
Proveer o distribuir adecuadamente los materiales necesarios a la empresa. Colocándolos a disposición
en el momento indicado, para así evitar aumentos de costos perdidas de los mismos. Permitiendo
satisfacer correctamente las necesidades reales de la empresa, a las cuales debe permanecer
constantemente adaptado. Por lo tanto la gestión de inventarios37
debe ser atentamente controlada y
vigilada.
36
Fuente: http://www.mygnet.net/articulos/java/301/
http://wiki.pentaho.com/display/ServerDoc1x/1.+JasperReports+Report+Definition.
http://en.wikipedia.org/wiki/JasperReports
37
Gestión de inventarios: regula el flujo entre las entradas de existencias y las salidas.
Fuente: http://es.wikipedia.org/wiki/Gestión_de_inventarios
Fuente: http://es.wikipedia.org/wiki/Valuación_de_inventarios

52
2.15. Administración de Inventarios
2.15.1 Concepto
Es la eficiencia en el manejo adecuado del registro, de la rotación y evaluación del inventario de
acuerdo a como se clasifique y qué tipo de inventario tenga la empresa, ya que a través de todo esto
determinaremos los resultados (utilidades o pérdidas) de una manera razonable, pudiendo establecer la
situación financiera de la empresa y las medidas necesarias para mejorar o mantener dicha situación.
2.15.2 Importancia
La importancia de ejercer un control eficaz de los inventarios se basa en que al tener un buen manejo se
puede dar un mejor servicio al funcionario porque se logra controlar pedidos de suministros para la
entrega.38.
Su éxito va estar enmarcado dentro de la política de la administración de inventario:
1. Establecer relaciones exactas entre las necesidades probables y los abastecimientos de los
diferentes productos.
2. Definir categorías para los inventarios y clasificar cada mercancía en la categoría adecuada.
3. Mantener los costos de abastecimiento al más bajo nivel posible.
4. Mantener un nivel adecuado de inventario.
5. Satisfacer rápidamente la demanda.
6. Recurrir a la informática.
En conclusión la meta de la administración de inventario es proporcionar los inventarios necesarios
para sostener las operaciones en el más bajo costo posible. En tal sentido el primer paso que debe
seguirse para determinar el nivel óptimo de inventario son, los costos que intervienen en su compra y
su mantenimiento, y que posteriormente, en qué punto se podrían minimizar estos costos.
2.16. Suministros de bodega
Son aquellos de uso o consumo permanente o habitual, que se tienen en el depósito o bodega central y
que normalmente están disponibles para entrega inmediata.
38
Materia prima: Se conoce como materia prima a la materia extraída de la naturaleza y que se transforma para elaborar
materiales que más tarde se convertirán en bienes de consumo.
Fuente: http://es.wikipedia.org/wiki/Materia_prima

53
Las existencias de suministros de bodega deberán mantenerse dentro de los límites máximos y
mínimos establecidos para cada material, elemento o producto y de acuerdo con los niveles de
consumo establecidos en el Plan Anual de Compras.
2.17. Control del Inventario
Los diversos aspectos de la responsabilidad sobre los inventarios afectan a muchos departamentos y
cada uno de éstos ejerce cierto grado de control sobre los productos, a medida que los mismos se
mueven a través de los distintos procesos de inventarios. Todos estos controles que abarcan, desde el
procedimiento39
para desarrollar presupuestos y pronósticos de ventas y producción hasta la operación
de un sistema de costo para el departamento de contabilidad para la determinación de costos de los
inventarios, constituye el sistema del control interno de los inventarios, las funciones generales son:
Planeamiento40
, compra u obtención, recepción, almacenaje, producción.
2.17.1 Planeamiento
Es el proceso metódico diseñado para obtener un objetivo determinado. En el sentido más universal,
implica tener uno o varios objetivos a realizar junto con las acciones requeridas para concluirse
exitosamente.
La base para planear la producción y estimar las necesidades en cuanto a inventarios, la constituye
el presupuesto41
o pronostico de ventas. Este debe ser desarrollado por el departamento de ventas.
2.17.2 Compra u Obtención
En la función de compra u obtención se distinguen normalmente dos responsabilidades separadas:
Control de producción, que consiste en determinar los tipos y cantidades de materiales que se quieren.
Compras, que consiste en colocar la orden de compra y mantener la vigilancia necesaria sobre la
entrega oportuna del material.
2.17.3 Recepción
Debe ser responsable de lo siguiente:
39
Procedimiento: Es el cauce formal de la serie de actos en que se concreta la actuación administrativa para la realización de
un fin. El procedimiento tiene por finalidad esencial la emisión de un acto administrativo.
Fuente: http://es.wikipedia.org/wiki/Procedimiento_administrativo
40
Planeamiento: La planificación es un proceso de toma de decisiones para alcanzar un futuro deseado, teniendo en cuenta la
situación actual y los factores internos y externos que pueden influir en el logro de los objetivos.
Fuente: http://es.wikipedia.org/wiki/Planeamiento
41
Presupuesto: Es el cálculo anticipado de los ingresos y gastos de una actividad económica (personal, familiar, un negocio,
una empresa, una oficina, un gobierno) durante un período, por lo general en forma anual.

54
 La aceptación de los materiales recibidos, después que estos hayan sido debidamente contados,
inspeccionados en cuanto a su calidad y comparados con una copia aprobada de la orden de compra.
 La prelación de informes de recepción para registrar y notificar la recepción y aceptación.
 La entrega o envío de las partidas recibidas, a los almacenes42
(depósitos) u otros lugares
determinados. Como precaución contra la apropiación indebida de activos.
2.17.4 Almacenaje
Las materias primas disponibles para ser procesadas o armadas (ensambladas), así como los productos
terminados, etc., pueden encontrarse bajo la custodia de un departamento de almacenes. La
responsabilidad sobre los inventarios en los almacenes incluye lo siguiente:
a. Comprobación de las cantidades que se reciben para determinar que son correctas.
b. Facilitar almacenaje adecuado, como medida de protección contra los elementos y las
extracciones no autorizadas.
c. Extracción de materiales contra la presentación de autorizaciones de salida para producción o
embarque.
2.18. Inventario Permanente
El sistema de inventarios permanente, o también llamado perpetuo, permite un control constante de los
inventaros, al llevar el registro de cada unidad que ingresa y sale del inventario. Este control se lleva
mediante tarjetas llamada kardex, en donde se lleva el registro de cada unidad, su valor de compra, la
fecha de adquisición, el valor de la salida de cada unidad y la fecha en que se retira del inventario.
De esta forma, en todo momento se puede conocer el saldo exacto de los inventarios y el valor del
costo de venta.
Además del control permanente de los inventarios, este sistema permite la determinación del costo al
momento de hacer la venta, debido a que en cada salida de un producto, es registra su cantidad y costo.
42
almacenes: Es un lugar o espacio físico para el almacenaje de bienes.
Fuente: http://es.wikipedia.org/wiki/Almacenes

55
2.19. Valorización de Inventarios de Mercaderías
Las mercaderías en las empresas se valoran:
 Las compras, al precio de costo de adquisición.
 Las ventas o (entregas), de acuerdo a los diferentes métodos que se apliquen.
El movimiento de las mercaderías (por suministro) se controla en tarjetas kardex, las que se detallan a
continuación.
2.19.1 Costo Primeras entradas, primeras salidas(PEPS)
Por este método, las mercaderías salen de la empresa al costo de la primera adquisición, luego al costo
de la siguiente y así sucesivamente hasta llegar al costo de la última adquisición.
2.19.2 Costo de Últimas entradas, primeras salidas (UEPS)
Por este método, las mercaderías salen de la empresa al costo de la última mercadería ingresada, luego
al costo de la anterior y así sucesivamente hasta llegar al costo de la más antigua.
2.19.3 Método Promedio
Básicamente se suma los valores correspondientes al saldo del inventario inicial y de todas las compras
realizadas hasta el momento de efectuar el cálculo; y, este valor se divide para el número total de
unidades que consta en la columna de saldo o existencia de la tarjeta, para así aplicar en las siguientes
salidas de mercaderías.
2.19.4 Precio de Mercado
Por este método, las mercaderías salen a un costo estimado igual al precio de mercado al momento en
que se realiza la venta o entrega; considerando que en ese mismo instante en que se realiza dicha venta
o entrega; debe reponerse las existencias, en función del último precio de mercado; más todos los
gastos adicionales hasta que el artículo o suministro esté en el lugar de venta o entrega. (Este método
sería el más recomendable).

CAPÍTULO III
Funcionamiento del Sistema

57
3. Capítulo III: Funcionamiento del Sistema
El Módulo de Gestión y Control de Inventarios de Suministros se integrará con los Módulos de
Elaboración del PAC y manejo de Partidas Presupuestarias de Adquisiciones y con el Módulo de
Gestión y Control de Activos Fijos de Bienes Muebles en un sistema integrador denominado: Sistema
Web de Gestión y Control de Procesos para la Dirección Provincial del IESS de Imbabura.
3.1. Esquema de la Aplicación integrada con los otros Módulos
Figura 11: Esquema de la Aplicación integrada con los otros Módulos
El Módulo de Gestión y Control de Inventarios de Suministros obtiene información referente a los
requerimientos que los funcionarios realizan en el módulo de Elaboración y Manejo de Partidas
Presupuestarias, comparte información referente a las estadísticas de consumo de los funcionarios de
una dependencia, comparte información referente a las entregas realizadas de bienes sujetos a control
con el Módulo de Gestión y Control de Activos Fijos de Bienes Muebles.

58
3.2. Esquema General del Funcionamiento del Sistema
Figura 12: Esquema General del Funcionamiento de la Aplicación
3.3. Definición de los Módulos del Sistema
3.3.1 Módulo de Bodega
 Creación, Modificación y Eliminación de Suministros.
 Filtro de campos (id, nombre, marca, unidad de medida, sujeto a control, stock>=) en la tabla
de suministros
 Búsqueda de suministros por Partida y por campo.
 Generar el kardex de suministros.

59
3.3.2 Módulo de Compras de Suministros
Este módulo se encargará de Registrar las Facturas por orden de compra y a los proveedores a los que
se les hayan comprado.
 Permite consultar plan anual de compras de suministros
 Listar las compras de suministros
 Realizar compras de acuerdo a las partidas de suministros: Material de oficina, Material de
Aseo, Material de Impresión y Material informático.
 Cuando se guarda una compra en la base de datos se realiza una distribución de ese suministro
para el número de funcionarios que tiene aprobado el requerimiento de ese suministro.
 Registrar la compra en el kardex de ese suministro
 Ejecutar reportes como: reporte individual de compra, reporte del plan anual de compras de
suministros, reporte detallado de compras de suministros.
3.3.3 Módulo de Pedidos de Suministros
Este módulo se encargará de:
 Gestionar los pedidos de suministros por parte de los funcionarios.
 Permite consultar el requerimiento aprobado según el PAC-Suministros que el funcionario
tiene, en donde se detalla: cantidad de suministro aprobada, cantidad pedida, cantidad por
pedir, cantidad entregada.
 Se asigna el stock funcionario de acuerdo a la siguiente cálculo:
 Generará un acta de pedido por parte del funcionario que detallará los artículos o suministros
pedidos y la cantidad pedida.
3.3.4 Módulo de Entregas de Suministros
 Controlar el flujo de salida de suministros en cada orden de pedido de un funcionario de un
respectivo departamento.
 Registrar la entrega en el kardex de ese suministro
 Generará un acta de entrega recepción

60
3.3.5 Módulo de Reportes
 Consultas y Reportes de acuerdo a los requerimientos de los usuarios de los distintos
Departamentos.
 Reportes de Compras de suministros
 Reportes de Pedidos de suministros
 Reportes de Entregas de suministros
 Reportes de Existencias
 Reportes de inventarios
 Reporte de Kardex

CAPÍTULO IV
Desarrollo del Proyecto
Aplicación Metodología Rup
 Fase de Inicio
 Fase de Elaboración
 Fase de Construcción
 Fase de Transición

62
4. Capítulo IV: Desarrollo del Proyecto
4.1. Aplicación Metodología RUP
El Proceso Unificado Racional, sus siglas RUP, es un proceso de desarrollo de software y junto con el
Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el
análisis, implementación y documentación de sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino que trata de un conjunto de
metodologías adaptables al contexto y necesidades de cada organización, donde el software es
organizado como una colección de unidades atómicas llamados objetos, constituidos por datos y
funciones, que interactúan entre sí.
- Fase de Inicio:
Durante la fase de inicio las iteraciones hacen poner mayor énfasis en actividades modelado del
negocio y de requisitos.
- Fase de Elaboración:
En esta fase las iteraciones se orientan al desarrollo de la arquitectura, que incluye los flujos de trabajo
de requerimientos modelo de negocios (refinamiento), análisis, diseño y una parte de implementación
orientado a la arquitectura.
- Fase de Construcción:
Se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y demás. El resultado final
es un sistema ejecutable.
- Fase de Transición:
Se realiza la instalación del producto en el cliente y se procede al entrenamiento de los usuarios.
Realizar la transición del producto a los usuarios, lo cual incluye: manufactura, envío, entrenamiento,
soporte y mantenimiento del producto, hasta que el cliente quede satisfecho, por tanto en esta fase
suelen ocurrir cambios.43
4.2. Fase de Inicio
4.2.1 Planificación inicial
Para la elaboración del proyecto se realizó una planificación inicial con reuniones con las partes
interesadas, el proyecto nace con la necesidad de crear un sistema que se encargue del control y la
gestión de los procesos de la institución, y así mantener un registro de la información manejada en la
institución.
43
http://es.scribd.com/doc/31440864/Metodologia-RUP

63
4.2.2 Análisis de requerimientos inicial (actas de trabajo)
Tabla 1: Acta de Trabajo Nro. 1

64
4.2.3 Recolección de información (documentos)
4.2.3.1 Boletín de Compra de Suministros de Oficina
Este boletín es emitido por el departamento de Contabilidad cuando se realiza una compra de
Suministros de oficina. Facilitado por el Dpto. de Contabilidad.
Figura 13: Boletín de Compra de Suministros de Oficina
Fuente: Dirección Provincial del IESS de Imbabura

65
4.2.3.2 Facturas de Compras de Suministros de Oficina
La factura es un documento que respalda la compra realizada, se adjunta con el boletín de egreso.
Documento facilitado por Sr. Carlos Sánchez responsable de Presupuesto.
Figura 14: Factura de Compra de Suministros de oficina #1
Fuente: Dirección Provincial del IESS de Imbabura

66

67

68
Figura 17: Factura de Compra de Suministros de impresión
Fuente: Dpto. Provincial del Sistema de Pensiones Imbabura

69
4.2.3.3 Inventario de Suministros de Oficina
Figura 18: Reporte de Inventario de Suministros de Oficina

70
4.2.3.4 Kardex de Suministros de Oficina
Figura 19: Tarjeta kardex de Suministros de Oficina
4.2.4 Lista de Riegos
4.2.4.1 Propósito
El propósito es dar soporte al desarrollo del sistema SGCP44
, mediante la documentación de
potenciales riegos, sus magnitudes y las estrategias a seguir para su mitigación.
4.2.4.2 Alcance
El alcance de la lista de riesgos se aplica al SGCP.
4.2.4.3 Riesgos
Los riesgos conocidos son expuestos en la siguiente tabla, junto con estrategias de mitigación para cada
riesgo.
44
SGCP: Sistema de Gestión y Control de Procesos

71
Ranking Descripción del Riesgo e Impacto Estrategia de reducción del riesgo
7 El Módulo de Gestión y Control de
Inventarios de Suministros no podría estar
listo para el mes en que se planifica realizar
las pruebas.
Incrementar el esfuerzo en el
desarrollo del sistema.
7 Demora para entrega de los requisitos de las
partes interesadas.
Podrían surgir requerimientos.
Recordar el compromiso de la
institución para el desarrollo del
sistema.
5 Sobrecarga de trabajo para los
desarrolladores, varias responsabilidades
pueden afectar el cumplimiento de
cronograma.
Definir correctamente las
responsabilidades.
5 Infraestructura de hardware y
comunicaciones no adecuada.
Realizar el correcto análisis de
funcionalidad de la red de datos.
3 Incompatibilidad del navegador de internet
de los usuarios.
Instalar el navegador compatible con
el sistema.
3 Modificación de los requerimientos puestos
en marcha.
Realizar actas de trabajo, definir
bien los requerimientos.
Tabla 2: Lista de Riesgos
Fuente: Metodología RUP

72
4.2.5 Visión
4.2.5.1 Introducción
4.2.5.1.1 Propósito
El propósito de este documento es recoger, analizar, definir las necesidades de alto nivel y las
características del Módulo de Gestión y Control de Inventarios de Suministros y su integración al
Sistema de Gestión y Control de Procesos para la Dirección Provincial del IESS de Imbabura.
El documento se centra en la funcionalidad requerida por los participantes en el proyecto y los
usuarios finales.
Esta funcionalidad se basa principalmente en que permitirá al responsable de suministros tener un
mejor control de los suministros, ingreso de suministros por compra, entrega de pedidos a bodega,
entrega de pedidos por requerimiento y los funcionarios podrán elaborar pedidos a bodega, elaborar
pedidos por requerimiento.
Los detalles de cómo el sistema cubre los requerimientos se pueden observar en la especificación de
los casos de uso y otros documentos adicionales.
4.2.5.1.2 Alcance
Con la implementación del Sistema Web de Control y Gestión de Inventarios de Suministros, basado
en la tecnología J2EE y utilizando las herramientas Oracle permitirá a los funcionarios tener un mejor
control de los suministros, agilitar el proceso de gestión de inventarios de suministros, precautelar los
bienes de consumo, controlar el nivel de stock de los suministros del Dirección Provincial del IESS
de Imbabura.
Esta aplicación será parametrizable y posteriormente implementada en los demás seguros que
componen el Instituto Ecuatoriano de Seguridad Social de la provincia de Imbabura.
4.2.5.1.3 Definiciones, Siglas y Abreviaturas
La información se expondrá en el documento glosario.
4.2.5.1.4 Referencias
a) Glosario.
b) Plan de desarrollo de software.
c) RUP (Rational Unified Process).
d) Diagrama de casos de uso.

73
4.2.5.2 Posicionamiento
4.2.5.2.1 Oportunidad de negocio
Este sistema permitirá a la Dirección Provincial del IESS de Imbabura automatizar el control
de las actividades relacionadas al manejo de Inventario de suministros lo cual supondrá un
acceso rápido y sencillo a los datos, gracias a interfaces gráficas y amigables. Además, los
datos accedidos estarán siempre actualizados, lo cual es un factor muy importante para poder
llevar un control centralizado de los suministros de la Dirección Provincial del IESS de
Imbabura.
4.2.5.2.2 Definición del problema
El problema de La Dirección Provincial del IESS de Imbabura no
cuenta con un sistema informático que le facilite la
información necesaria para la gestión y el control del
inventario de Suministros.
Existen procesos que se hacen manualmente.
Controlar el stock existente en la bodega de
suministros.
Gestionar y controlar las entradas de suministros a la
bodega y los pedidos realizados por los funcionarios.
Gestionar las entregas de los suministros.
Que afecta a Funcionarios de las Áreas de Trabajo de la Dirección
Provincial del IESS de Imbabura.
Bodega de Suministros.
El impacto de asociado es Almacenar toda la información referente a las bodegas,
pedidos y facturas de compra recibidas, y que esta
información esté al instante accesible.
Una solución exitosa sería Implementar una solución informática de calidad
soportada por una metodología eficiente de desarrollo
de software. Permitir la gestión y control de los

74
suministros con interfaces amigables y sencillas.
Integrar el sistema con otros módulos del Sistema Web
de Gestión y Control de Procesos para la Dirección
Provincial del IESS de Imbabura – SGCP.
Tabla 3: Definición del Problema
4.2.5.2.3 Definición de la posición del Producto
Para Los funcionarios de las diferentes áreas de trabajo de la
Dirección Provincial del IESS de Imbabura.
Bodega de Suministros.
Quienes Funcionarios de la Dirección Provincial del IESS de
Imbabura que solicitan suministros.
Responsable de Suministros quién controlará las órdenes
de pedidos de los funcionarios, las existencias de
suministros en las bodegas (stock), los ingresos de
compras de suministros mediante factura y las entregas de
suministros.
El nombre del producto Módulo de Gestión y Control de Inventarios de
Suministros (MGCIS).
Que Almacena la información necesaria para gestionar y
controlar el inventario de los suministros.
Debido a que Debido a que en las condiciones actuales la información
se maneja en un formato desactualizado y poco eficiente,
la información se maneja de una manera aislada que puede
afectar su integridad y credibilidad.
Nuestro producto El producto se integrará con los otros módulos del
Sistema Web de Gestión y Control de Procesos para la
Dirección Provincial del IESS de Imbabura

75
Tabla 4: Definición de la Posición del Producto
4.2.5.3 Descripción de los interesados y usuarios
Para el desarrollo de un producto de software que se ajuste a las necesidades de los usuarios, es
necesario identificar e involucrar a todas las personas en el proyecto como parte del proceso de
modelado de requerimientos. También surge la necesidad de identificar a los futuros usuarios del
sistema, asegurándose que el conjunto de participantes los representen adecuadamente.
En esta sección se pretende mostrar el perfil de los participantes y de los usuarios, además de los
problemas más importantes que estos tienen actualmente, esto con el fin de enfocar la solución hacia
ellos.
4.2.5.3.1 Resumen de los interesados
Los interesados son todas aquellas personas directamente involucradas en la definición y alcance de
este proyecto.
(SGCP).Permite gestionar las distintas actividades de la
Institución mediante una interfaz gráfica sencilla y
amigable. Además proporciona un acceso rápido y
actualizado a la información desde cualquier punto que
tenga acceso a la base de datos.
Nombre Descripción Responsabilidades
Coordinador y
responsable del proyecto
Jefe del Departamento
de Sistemas de la
Dirección Provincial del
IESS de Imbabura
Representa a todos los usuarios posibles
del sistema.
Responsable de organizar, planificar,
coordinar y evaluar el desarrollo del
proyecto.
Aprueba requisitos y funcionalidades.

76
Tabla 5: Resumen de Interesados
Jefe del proyecto Director de tesis Responsable del análisis y diseño del
Proyecto.
Gestiona el correcto desarrollo del
Proyecto en lo referente a la construcción
e implantación
Responsable del proyecto Analista de sistemas Encargado de gestión de requisitos,
configuración, documentación y diseño
de datos.
Responsable del desarrollo del proyecto,
con conocimiento del entorno de
desarrollo.
Responsable funcional Responsable de los
Inventarios de
Suministros
Resguarda los suministros que están en la
bodega y gestiona las incidencias de los
pedidos, ingresos y entregas de
suministros.
Usuarios del sistema Funcionarios Realizan pedidos de suministros, a través
del sistema de Gestión y Control del
inventario de Suministros.

77
4.2.5.3.2 Resumen de los usuarios
Los usuarios son todas aquellas personas involucradas directamente en el uso del “Módulo de Gestión
y Control de Inventarios de Suministros (MGCIS) que forma parte del Sistema Web de Gestión y
Control de Procesos para la Dirección Provincial del IESS de Imbabura - SGCP”. A continuación se
presenta una lista de los usuarios:
Nombre Descripción Responsabilidad
Administrador del
Sistema
Persona del
departamento de
sistemas que administra
el Sistema.
Administrar funcionalmente el
sistema (gestionar acceso a
usuarios, dar mantenimiento al
sistema frente a nuevos
requerimientos).
Administrador funcional
del sistema
Responsable de los
Inventarios de
Suministros
Resguarda los suministros que
están en la bodega y gestiona las
incidencias de los pedidos, ingresos
y entregas de suministros.
Administrar funcionalmente el
sistema: creación de nuevos
suministros, definir los tipos de
movimientos, etc.
Usuarios del Sistema Funcionarios de la
institución.
Realizan pedidos de suministros, a
través del sistema de Gestión y
Control del inventario de
Suministros.
Tabla 6: Resumen de los Usuarios
4.2.5.3.3 Entorno de usuario
Actualmente se lleva un registro manual del kardex de los suministros que entran y salen de bodega.
Los usuarios podrán acceder al sistema a través del Intranet con cuentas de usuarios validadas por el
sistema. Cada usuario tendrá su propio entorno de trabajo según las funcionalidades asignadas al grupo
de usuario al que pertenezca.

78
El Módulo de Gestión y Control de Inventarios de Suministros (MGCIS) tendrá que integrarse con los
módulos de: Activos Fijos-Bienes Muebles, Pac y Presupuesto en el sistema web de Gestión y Control
de Procesos para el Departamento Provincial del IESS de Imbabura (SGCP).
Cada usuario tendrá su propio entorno de trabajo según las funcionalidades asignadas al grupo de
usuario al que pertenezca.
El SGCP se desarrollará con las herramientas de Oracle, JDeveloper y Jasper/iReports, con un servidor
de Base de datos Oracle 11g, los Reportes serán generados en formato PDF lo cual resultará familiar
al usuario.
4.2.5.3.4 Perfiles de los interesados
4.2.5.3.4.1 Coordinador y responsable del proyecto
Representante Ing. Mario Medina
Descripción Jefe del departamento de Sistemas de la Dirección Provincial del IESS de
Imbabura.
Tipo Jefe Departamental
Responsabilidades  Establecer los lineamientos generales para el desarrollo del proyecto.
 Coordinar a nivel directivo los diferentes requerimientos que surjan
en el desarrollo del sistema.
Criterio de Éxito - Mantener una funcionalidad integral en los sistemas.
- Mantener activa la aplicación luego de ser implantada.
Grado de
Participación
Revisiónde la administración
Comentarios N/A
Tabla 7: Perfil de Coordinador del Proyecto

79
4.2.5.3.4.2 Jefe del proyecto
Representante Ing. Mauricio Rea
Descripción Asesor del proyecto
Tipo Analista de sistemas
Responsabilidades - Responsable del análisis y diseño del proyecto.
- Gestiona el correcto desarrollo del proyecto en lo referente a la
construcción e implantación.
Criterios de éxito - Obtener un sistema de calidad que cumpla con los requerimientos
funcionales establecidos.
Implicación Jefe de proyecto
Entregables - Documento de visión
- Glosario
- Lista de riesgos
- Resumen del modelo de casos de uso
- Especificaciones del modelo de casos de uso
- Especificaciones complementarias
Comentarios N / A
Tabla 8: Perfil del jefe del proyecto
4.2.5.3.4.3 Responsable del proyecto
Representante Rubén González
Descripción Responsables del proyecto.
Tipo Analistas de sistemas, Desarrolladores
Responsabilidades Responsables del análisis, diseño e implementación del proyecto.
Gestionar el correcto desarrollo del proyecto.
Criterios de éxito Verificar el cumplimiento de los requerimientos establecidos para el
desarrollo del sistema.
Cumplir con el cronograma determinado.
Implicación Jefe de proyecto (Project Manager)
Entregables Documento de visión

80
Resumen del modelo de casos de uso
Especificaciones del modelo de casos de uso
Diseño ER de la base de datos y el diccionario de datos.
Especificaciones complementarias
Tabla 9: Perfil Responsable del Proyecto
4.2.5.3.4.4 Responsable funcional
Representante Lic. Miriam Miño.
Descripción Responsable de Suministros del departamento Provincial del Sistema de
Pensiones Imbabura que administra el sistema MGCIS.
Tipo Experto en el tema
Responsabilidades - Administrar funcionalmente el sistema: Responsable de los inventarios
de suministros.
Incidencias de los pedidos, ingresos y entregas de suministros.
Criterios de éxito Obtener un sistema de calidad que cumpla con los requerimientos
funcionales establecidos.
Implicación Aprueba las especificaciones funcionales y las pruebas realizadas.
Entregables - Documento de revisión de las especificaciones funcionales.
- Documento de revisión de las pruebas funcionales
Comentarios N / A
Tabla 10: Perfil de responsable funcional

81
4.2.5.3.5 Perfiles de usuario
4.2.5.3.5.1 Administrador del sistema
Representante Ing. Mario Medina.
Descripción Persona del Departamento de Sistemas que administra el sistema.
Tipo Operador, Analista de Sistemas
Responsabilidades Administrar funcionalmente el sistema
Gestionar acceso a usuarios.
Realizar el mantenimiento al sistema frente a nuevos requerimientos.
Criterios de éxito N/A
Implicación N/A
Entregables Bitácora de control de nuevos requerimientos.
Comentarios N/A
Tabla 11: Perfil del administrador del proyecto
4.2.5.3.5.2 Administrador funcional del sistema
Representante Lic. Miriam Miño
Descripción Responsable de Suministros del departamento Provincial del Sistema de
Pensiones Imbabura que administra el sistema MGCIS.
Tipo Experto en el tema
Responsabilidades Administrar funcionalmente el sistema:
- Coordinar las pruebas de validación del nuevo sistema.
-Responsable de coordinar con los diferentes usuarios la correcta
determinación del inventario de suministros.
-Ingresos y egresos de suministros en bodega.

82
Coordinar las pruebas de validación del nuevo sistema.
Implicación N/A
Entregables N/A
Comentarios N/A
Tabla 12: Perfil del administrador funcional del sistema
4.2.5.3.5.3 Usuario del Sistema
Representante Funcionarios del Departamento Provincial del Sistema de Pensiones
Imbabura.
Descripción Personal de las diferentes áreas de trabajo del departamento Provincial
del Sistema de Pensiones Imbabura que harán uso del MGCIS.
Tipo Funcionario
Responsabilidades Realizan pedidos de suministros, a través del sistema de Gestión y
Control del inventario de Suministros.
Implicación N/A
Entregables N/A
Comentarios N/A
Tabla 13: Perfil del usuario del sistema

83
4.2.5.3.6 Necesidades de los interesados y usuarios
Necesidades Prioridad Inquietudes Solución
Actual
Solución
propuesta
El Departamento
Provincial del Sistema
de Pensiones Imbabura
no cuenta en la
actualidad con un
sistema informático que
agilite y haga eficiente
el control de los
inventarios de
suministros.
Alta No existen
herramientas.
N/A Desarrollar el
“MGCIS”
Implementar este
sistema en el menor
tiempo posible con el
fin de ponerlo en
producción.
Alta No es posible
saber el tiempo
para la
investigación.
N/A Implementación del
Sistema.
Desarrollar el sistema
utilizando herramientas
que facilite y agilice su
desarrollo.
Alta Se debe utilizar las
herramientas.
N/A Desarrollar el
Sistema utilizando
la Herramienta
JDeveloper 11g.
La interfaz del sistema
debe ser fácil de
manejar, cumpliendo
con todos los
requerimientos
establecidos.
Alta Cumplir con todos
los requerimientos
de los usuarios.
N/A Desarrollo con la
ayuda de los
expertos en el
tema.
Tabla 14: Necesidades de los interesados y usuarios

84
4.2.5.3.7 Alternativas y competencia
Existen soluciones que no son viables.
4.2.5.4 Vista general del producto
Esta sección provee información a alto nivel de las funciones del sistema a implantar y de las interfaces
con otras aplicaciones existentes.
4.2.5.4.1 Perspectiva del producto
El Sistema de Gestión y Control del Inventario de Suministros (MGCIS) comprende a todos los
suministros que tiene la Dirección Provincial del IESS de Imbabura para aprovisionar los
requerimientos de los funcionarios de los diferentes departamentos.
Esta aplicación será parametrizable y posteriormente implementada en las demás unidades del
Instituto Ecuatoriano de Seguridad Social como son: Seguro Campesino, Seguro de Pensiones, Seguro
de Riesgos del Trabajo, Seguro General de Salud Individual y Familiar a nivel de la provincia de
Imbabura.
La aplicación tiene como finalidad sistematizar y administrar eficientemente la información que será
utilizada por el personal involucrado de las diferentes áreas de la Institución como son:
Bodega de Suministros: Provisión de suministros y administración del inventario.
Sistemas: Representa a todos los usuarios posibles del sistema y realiza un seguimiento del desarrollo
del proyecto, aprueba requisitos y funcionalidades.

85
Figura 20: Perspectiva del Producto
Fuente: Propia
4.2.5.4.2 Resumen de capacidades
A continuación se mostrará un listado con los beneficios que obtendrá el cliente a partir del producto:
Beneficio del cliente Características que lo apoyan
Mayor agilidad en los ingresos,
pedidos y entregas de suministros
dando la posibilidad de hacerlo vía
web utilizando el sistema de Gestión
y Control del Inventario de
Suministros (MGCIS).
Aplicación web desde la cual poder realizar los ingresos,
pedidos y entregas de suministros.
Gestión automatizada del stock de la
bodega de suministros.
Sistema de optimización del stock en la bodega de
suministros.
Optimización de tiempos Este sistema alcanzará una reducción notable en el tiempo de
ejecución de los procesos que realiza la bodega de
Suministros mejorando así la atención a los usuarios.

86
Manejo de información real y
confiable
Fácil y rápido acceso a la información desde la Base de
Datos central que nos garantizara integridad y confiabilidad
en la información.
Se tendrá alta disponibilidad. El acceso al sistema a través de la Web permitirá a los
usuarios un acceso inmediato desde cualquier punto de la
intranet del Departamento Provincial del Sistema de
Pensiones Imbabura.
Se evitará el cálculo de una forma
manual del manejo y control del
inventario de suministros.
Este sistema contará con un módulo para el manejo y
control del inventario de suministros (Módulo de Proceso de
Inventario), el cual lo calculará automáticamente.
Tabla 15: Resumen de capacidades
4.2.5.4.3 Suposiciones y dependencias
N/A
4.2.5.4.4 Costos y precios
Costos de Hardware
Descripción Costo IESS $ Costo Tesista $ Costo Real $
Computador Portátil 0.00 1000.00 1000.00
Computador Escritorio 1100.00 0.00 0.00
Impresora Multifunción Xerox 500.00 0.00 0.00
Impresora HP LaserJet 1055 0.00 100.00 0.00
Total de Hardware 1600.00 1100.00 1000.00
Costos de Software
Internet 0.00 200.00 250.00

87
Motor de Base de Datos
ORACLE 11g
5000.00 0.00 0.00
Servidor de Aplicaciones
WebLogic
5000.00 0.00 0.00
IDE de desarrollo 0.00 0.00 0.00
Total de Software 10000.00 200.00 250.00
Materiales de oficina
Resmas hojas de papel bond 20.00 80.00 100.00
Copias (documentos y libros) 0.00 30.00 30.00
DVD’s, esferos 0.00 50.00 50.00
Libros 00.00 100.00 100.00
Memoria flash 0.00 0.00 0.00
Total de Materiales de
oficina
0.00 280.00 280.00
Varios
Movilización 0.00 50.00 50.00
Capacitación 0.00 80.00 40.00
Imprevistos 0.00 50.00 50.00
Empastado y Anillado 0.00 200.00 200.00

88
Infraestructura Física 0.00 0.00 0.00
Total de Varios 0.00 380.00 380.00
Total Costos 11600.00 1960.00 1870.00
Tabla 16: Costos del Proyecto
Fuente: Propia
4.2.5.4.5 Licenciamiento e instalación
Actualmente ya se cuenta con la licencia del motor de base de Datos Oracle 11g.
4.2.5.5 Características del producto
4.2.5.5.1 Autentificación de usuarios
Para acceder al sistema cada usuario se identifica mediante:
- Nombre de Usuario
- Contraseña
4.2.5.5.2 Gestión de los roles
El administrador puede crear, modificar, eliminar en el sistema la lista de roles que pueden desempeñar
los usuarios.
4.2.5.5.3 Facilidad de acceso y uso
El MGCIS será desarrollado utilizando tecnología Web y las facilidades que ofrece la herramienta
JDeveloper 11g, el framework RichFaces, lo que permitirá a los usuarios un fácil acceso y uso.
4.2.5.5.4 Módulo de Proceso de Bodega
Se encargará de:
 Filtro de campos (id, nombre, marca, unidad de medida, sujeto a control, stock<=) en la tabla
de suministros

89
4.2.5.5.5 Módulo de Compras de Suministros
Este módulo se encargará de Registrar las Facturas por orden de compra y a los proveedores a los que
se les hayan comprado.
4.2.5.5.6 Módulo de Pedidos de Suministros
4.2.5.5.7 Módulo de Entrega de Suministros

90
 Permite ejecutar reporte de entregas de suministros por: Funcionario, por Área de Trabajo, por
suministro.
suministro.
4.2.5.5.8 Reportes.
 Consultas y Reportes de acuerdo a los requerimientos de los usuarios de las distintas áreas de
trabajo.
 Reportes de compras de suministros
 Reportes de Pedidos por parte de los Funcionarios
4.2.5.6 Restricciones
Debido a limitaciones con el licenciamiento de Oracle 11g, se debe contemplar un número pequeño de
usuarios finales.
Algunas limitaciones técnicas podrían presentar, desconexiones inesperadas, tiempos largos de
respuesta de conexión, indisponibilidad de los servidores.
El Sistema será implementado y comprobado en el Departamento Provincial de Pensiones de
Imbabura.
El módulo de adquisición de suministros registrará las facturas de suministros para el ingreso en
bodega, no se centrará en el proceso de compras.
4.2.5.7 Rangos de calidad
El desarrollo del MGCIS se ajustará a la Metodología de Desarrollo de Software RUP, contemplando
los parámetros de calidad que la metodología define.
4.2.5.8 Precedencia y Prioridad
N/A

91
4.2.5.9 Otros requerimientos del producto
El sistema se desarrollará con las siguientes herramientas:
Lenguaje de Programación: Java
Framework JSF
IDE de desarrollo: JDeveloper 11g
Gestor de Base de Datos: ORACLE 11g
Servidor de Aplicaciones: Weblogic
Reportes
Jasper/iReports
4.3. Plan de Desarrollo de Software
El Plan de Desarrollo del Software es una versión preliminar preparada para ser incluida en la
propuesta elaborada como respuesta al proyecto del Sistema Web de Gestión y Control de Procesos
Para la Dirección Provincial del IESS de Imbabura, Módulo de Gestión y Control de Inventarios de
Suministros. Este documento provee una visión global del enfoque de desarrollo propuesto.
El proyecto ha sido basado en una metodología de Rational Unified Process con el fin de implantar un
esquema inicial de ésta metodología para futuros desarrollos.
El enfoque de desarrollo propuesto constituye una configuración del proceso RUP de acuerdo a las
características del proyecto, seleccionando los roles de los participantes, las actividades a realizar y los
artefactos (entregables) que serán generados. Este documento es a su vez uno de los artefactos de RUP.
4.3.1 Propósito
El propósito del Plan de Desarrollo de Software es proporcionar la información necesaria para
controlar el proyecto. En él se describe el enfoque de desarrollo del software.
Los usuarios del Plan de Desarrollo del Software son:

92
 El jefe del proyecto lo utiliza para organizar la agenda y necesidades de recursos, y
para realizar su seguimiento.
 Los miembros del equipo de desarrollo lo usan para entender lo qué deben hacer,
cuándo deben hacerlo y qué otras actividades dependen de ello.
4.3.2 Alcance
El Plan de Desarrollo del Software describe el plan global usado para el desarrollo del “Sistema Web
de Gestión y Control de Procesos Para la Dirección Provincial del IESS de Imbabura, Módulo de
Gestión y Control de Inventarios de Suministros”. El detalle de las iteraciones individuales se describe
en los planes de cada iteración, documentos que se aportan en forma separada. Durante el proceso de
desarrollo en el artefacto “Visión” se definen las características del producto a desarrollar, lo cual
constituye la base para la planificación de las iteraciones, nos hemos basado en la captura de requisitos
por medio de los interesados de la Institución para hacer una estimación aproximada, una vez
comenzado el proyecto y durante la fase de Inicio se generará la primera versión del artefacto “Visión”,
el cual se utilizará para refinar este documento. Posteriormente, el avance del proyecto y el
seguimiento en cada una de las iteraciones ocasionará el ajuste de este documento produciendo nuevas
versiones actualizadas.
4.3.3 Resumen
Este documento se encuentra organizado de la siguiente manera:
Vista General del Proyecto — proporciona una descripción del propósito, alcance y objetivos del
proyecto, estableciendo los artefactos que serán producidos y utilizados durante el proyecto.
Organización del Proyecto — describe la estructura organizacional del equipo de desarrollo.
Gestión del Proceso — explica los costos y planificación estimada, define las fases e hitos del proyecto
y describe cómo se realizará su seguimiento.
Planes y Guías de aplicación — proporciona una vista global del proceso de desarrollo de software,
incluyendo métodos, herramientas y técnicas que serán utilizadas.
4.3.4 Vista General del Proyecto
4.3.4.1 Propósito, Alcance y Objetivos
Por ello se considera necesario el desarrollo de la implementación de un Sistema Web de Gestión y
Control de Procesos Módulo de Gestión y Control de Inventarios de Suministros, para Dirección
Provincial del IESS de Imbabura como parte del proceso de automatización de todas sus áreas

93
institucionales.
El proyecto debe proporcionar una propuesta para el desarrollo del sistema implicados en la
planificación y gestión de la evaluación y calificación. Los módulos identificados son los siguientes:
a) Módulo de Bodega
 Filtro de campos (id, nombre, marca, unidad de medida, sujeto a control, stock<=) en la tabla
de suministros
b) Módulo de Compras de Suministros
 Este módulo se encargará de Registrar las Facturas por orden de compra y a los proveedores a
los que se les hayan comprado.
c) Módulo de Pedidos de Suministros

94
d) Módulo de Entregas de Suministros
suministro.
e) Módulo de Reportes
 Consultas y Reportes de acuerdo a los requerimientos de los usuarios de los distintos
Departamentos.
 Reportes de Pedidos de suministros
f) Integración con los Sistemas: Elaboración del PAC y Manejo de Partidas Presupuestarias de
Adquisiciones y Activos Fijos de Bienes muebles.
 Integración con el Módulo de Elaboración del Pac y Manejo de Partidas presupuestarias
(Estadísticas de Consumo de Suministros de funcionarios).
 Integración con el Módulo de Gestión y Control de Activos Fijos Bienes Muebles (Entregas de
bienes sujetos a control a funcionarios).
4.3.4.2 Suposiciones y Restricciones
Las suposiciones y restricciones respecto del sistema, y que se derivan directamente de las entrevistas
con el interesado de la Institución son:
a) El módulo será para la Gestión y Control de Inventarios de Suministros.
b) El módulo registrará las facturas por orden de compra y no se centrará en el proceso de
compras.

95
c) El sistema será diseñado sobre plataforma WEB y cumplirá con los estándares de calidad
para el desarrollo de software. Esto se conseguirá usando la metodología RUP para el
proceso de ingeniería de software y herramientas Oracle 11g para la construcción de las
aplicaciones.
d) El Sistema será puesto a prueba en el Departamento Provincial del IESS de Imbabura.
e) Esta aplicación será parametrizable y posteriormente implementada en las demás unidades
del Instituto Ecuatoriano de Seguridad Social como son: Seguro Campesino, Seguro de
Pensiones, Seguro de Riesgos del Trabajo, Seguro General de Salud Individual y Familiar
a nivel de la provincia de Imbabura.
Como es natural, la lista de suposiciones y restricciones se incrementará durante el desarrollo del
proyecto.
4.3.5 Organización del Proyecto
4.3.5.1 Participantes en el Proyecto
De momento no se incluye el personal que designará el IESS Imbabura como Responsable del
Proyecto, Comité de Control y Seguimiento, otros participantes que se estimen convenientes para
proporcionar los requisitos y validar el sistema.
El resto del personal del proyecto (por la parte de la empresa adjudicataria), considerando las fases de
Inicio, Elaboración, Construcción y estará formado por los siguientes puestos de trabajo y personal
asociado:
Jefe de Proyecto. Labor asignada a Ing. Mauricio Rea, quien se encargará de organizar, planificar,
coordinar y evaluar el desarrollo del proyecto.
Analistas - Programadores. Con conocimientos en el entorno de desarrollo del proyecto, con el fin de
que los prototipos puedan ser lo más cercanos posibles al producto final, realizarán labores de gestión
de requisitos, gestión de configuración, documentación y diseño de datos. Este trabajo ha sido
encomendado a Rubén González.
4.3.6 Interfaces Externas
El responsable del Proyecto definirá los participantes del proyecto que proporcionarán los requisitos
del sistema, y entre ellos quiénes serán los encargados de evaluar los artefactos de acuerdo a cada
subsistema y según el plan establecido.
El equipo de desarrollo interactuará activamente con los participantes para especificación y validación

96
de los artefactos generados.
4.3.7 Roles y Responsabilidades
A continuación se describen las principales responsabilidades de cada uno de los puestos en el
equipo de desarrollo durante las fases de Inicio y Elaboración, de acuerdo con los roles que
desempeñan en RUP.
Puesto Responsabilidad
Jefe de Proyecto
El jefe de proyecto asigna los recursos, gestiona las prioridades,
coordina las interacciones con los clientes y usuarios, y mantiene
al equipo del proyecto enfocado en los objetivos. El jefe de
proyecto también establece un conjunto de prácticas que
aseguran la integridad y calidad de los artefactos del proyecto.
Además, el jefe de proyecto se encargará de supervisar el
establecimiento de la arquitectura del sistema. Gestión de
riesgos. Planificación y control del proyecto.
Analista de Sistemas
Captura, especificación y validación de requisitos, interactuando
con el cliente y los usuarios mediante entrevistas. Elaboración
del Modelo de Análisis y Diseño. Colaboración en la elaboración
de las pruebas funcionales y el modelo de datos.
Programador
Construcción de prototipos. Colaboración en la elaboración de
las pruebas funcionales, modelo de datos y en las validaciones
con el usuario
Ingeniero de
Software
Gestión de requisitos, gestión de configuración y cambios,
elaboración del modelo de datos, preparación de las pruebas
funcionales, elaboración de la documentación. Elaborar modelos
de implementación y despliegue.
Tabla 17: Roles y Responsabilidades
Fuente: Metodología Rup

97
4.3.8 Gestión del Proceso
4.3.8.1 Estimaciones del Proyecto
El presupuesto del proyecto y los recursos involucrados se adjuntan en un documento
separado.
4.3.8.2 Plan del Proyecto
En esta sección se presenta la organización en fases e iteraciones y el calendario del proyecto
en un documento adjunto.
Plan de las Fases
El desarrollo se efectuará en base a fases con una o más iteraciones en cada una de ellas. La
siguiente tabla muestra una la distribución de tiempos y el número de iteraciones de cada fase (para
las fases de Construcción y Transición es sólo una aproximación muy preliminar)
Fase
Nro.
Iteraciones
Duración
Fase de Inicio 1 6 semanas
Fase de
Elaboración
2 7 semanas
Fase de
Construcción
2 19 semanas
Fase de Transición 1 4 semanas
Tabla 18: Plan de Fases

98
Los hitos que marcan el final de cada fase se describen en la siguiente tabla.
Descripción Hito
Fase de Inicio En esta fase desarrollará los requisitos del producto desde la
perspectiva del usuario, los cuales serán establecidos en el
artefacto Visión. Los principales casos de uso serán
identificados y se hará un refinamiento del Plan de Desarrollo
del Proyecto. La aceptación del cliente / usuario del artefacto
Visión y el Plan de Desarrollo marcan el final de esta fase.
Fase de
Elaboración
En esta fase se analizan los requisitos y se desarrolla un
prototipo de arquitectura (incluyendo las partes más relevantes y
/ o críticas del sistema). Al final de esta fase, todos los casos de
uso correspondientes a requisitos que serán implementados en la
primera release de la fase de Construcción deben estar
analizados y diseñados (en el Modelo de Análisis / Diseño). La
revisión y aceptación del prototipo de la arquitectura del sistema
marca el final de esta fase. En nuestro caso particular, por no
incluirse las fases siguientes, la revisión y entrega de todos los
artefactos hasta este punto de desarrollo también se incluye
como hito. La primera iteración tendrá como objetivo la
identificación y especificación de los principales casos de uso,
así como su realización preliminar en el Modelo de Análisis /
Diseño, también permitirá hacer una revisión general del estado
de los artefactos hasta este punto y ajustar si es necesario la
planificación para asegurar el cumplimiento de los objetivos.
Ambas iteraciones tendrán una duración de una semana.
Fase de
Construcción
Durante la fase de construcción se terminan de analizar y
diseñar todos los casos de uso, refinando el Modelo de Análisis

99
/ Diseño. El producto se construye en base a 2 iteraciones, cada
una produciendo una release a la cual se le aplican las pruebas
y se valida con el cliente / usuario. Se comienza la elaboración
de material de apoyo al usuario. El hito que marca el fin de esta
fase es la versión de la release 3.0, con la capacidad
operacional parcial del producto que se haya considerado como
crítica, lista para ser entregada a los usuarios para pruebas beta.
Fase de
Transición
En esta fase se prepararán dos releases para distribución,
asegurando una implantación y cambio del sistema previo de
manera adecuada, incluyendo el entrenamiento de los usuarios.
El hito que marca el fin de esta fase incluye, la entrega de toda
la documentación del proyecto con los manuales de instalación
y todo el material de apoyo al usuario, la finalización del
entrenamiento de los usuarios y el empaquetamiento del
producto.
Tabla 19: Plan de Fases: Hitos
Calendario del Proyecto
A continuación se presenta un calendario de las principales tareas del proyecto incluyendo sólo las
fases de Inicio y Elaboración. Como se ha comentado, el proceso iterativo e incremental de RUP
está caracterizado por la realización en paralelo de todas las disciplinas de desarrollo a lo largo del
proyecto, con lo cual la mayoría de los artefactos son generados muy tempranamente en el proyecto
pero van desarrollándose en mayor o menor grado de acuerdo a la fase e iteración del proyecto. La
siguiente figura ilustra este enfoque, en ella lo ensombrecido marca el énfasis de cada disciplina
(workflow) en un momento determinado del desarrollo.

100
Figura 21: Fases y Flujos de Trabajo en Metodología Rational Unified Process (RUP)
Fuente: Metodología Rup45
Para este proyecto se ha establecido el siguiente calendario. La fecha de aprobación indica
cuándo el artefacto en cuestión tiene un estado de completitud suficiente para someterse a
revisión y aprobación, pero esto no quita la posibilidad de su posterior refinamiento y cambios.
Disciplinas / Artefactos generados o modificados
durante la Fase de Inicio
Comienzo Aprobación
Modelado del Negocio
Modelo de Casos de Uso del Negocio y
Modelo de Objetos del Negocio
Semana 1
26/07 – 30/07
Semana 3
09/08 – 13/08
Requisitos
Glosario Semana 1
26/07 – 30/07
Semana 3
09/08 – 13/08
45
RUP Ciclo de Vida. Recuperado de http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational

101
Visión Semana 2
02/08 – 06/08
Semana 3
09/08 – 13/08
Modelo de Casos de Uso Semana 3
09/08 – 13/08
siguiente fase
Especificación de Casos de Uso Semana 3
09/08 – 13/08
siguiente fase
Especificaciones Adicionales Semana 3
09/08 – 13/08
siguiente fase
Análisis / Diseño
Modelo de Análisis / Diseño Semana 2
02/08 – 06/08
siguiente fase
Modelo de Datos Semana 2
02/08 – 06/08
siguiente fase
Implementación
Prototipos de Interfaces de Usuario Semana 3
09/08 – 13/08
siguiente fase
Modelo de Implementación Semana 3
09/08 – 13/08
siguiente fase
Pruebas
Casos de Pruebas Funcionales Semana 3
09/08 – 13/08
siguiente fase
Despliegue

102
Modelo de Despliegue Semana 3
09/08 – 13/08
siguiente fase
Gestión de Cambios y Configuración Durante todo el proyecto
Gestión del proyecto
Plan de Desarrollo del Software en su
versión 1.0 y planes de las Iteraciones
Semana 1
24/11 – 28/11
Semana 3
09/08 – 13/08
Ambiente Durante todo el proyecto
Tabla 20: Calendario de Actividades Fase de Inicio
Fuente: Propia
Disciplinas / Artefactos
generados o modificados durante la
Fase de Elaboración
Comienzo Aprobación
Modelado del Negocio
Modelo de Casos de Uso del Negocio y
Modelo de Objetos del Negocio
Semana 1
24/07 – 28/07
aprobado
Requisitos
Glosario Semana 1
24/07 – 28/07
aprobado
Visión Semana 2
02/07 – 06/07
aprobado
Modelo de Casos de Uso Semana 3
09/08 – 13/08
Semana 5
23/08/11 –

103
27/08/11
Especificación de Casos de Uso Semana 3
09/08 – 13/08
Semana 5
23/08/11 –
27/08/11
Especificaciones Adicionales Semana 3
09/08 – 13/08
Semana 5
23/08/11 –
27/08/11
Análisis / Diseño
Modelo de Análisis / Diseño Semana 2
02/07 – 06/07
Revisar en cada
iteración
Modelo de Datos Semana 2
02/07 – 06/07
Revisar en cada
iteración
Implementación
Prototipos de Interfaces de Usuario Semana 3
09/08 – 13/08
Revisar en cada
iteración
Modelo de Implementación Semana 3
09/08 – 13/08
Revisar en cada
iteración
Pruebas
Casos de Pruebas Funcionales Semana 3
09/08 – 13/08
Revisar en cada
iteración
Despliegue
Modelo de Despliegue Semana 3 Revisar en cada
iteración

104
09/08 – 13/08
Gestión de Cambios y Configuración Durante todo el proyecto
Gestión del proyecto
Plan de Desarrollo del Software en su
versión 2.0 y planes de las Iteraciones
Semana 4
16/08/10 –
20/08/10
Revisar en cada
iteración
Ambiente Durante todo el proyecto
Tabla 21: Calendario de Actividades Fase de Elaboración
Fuente: Propia
4.3.8.3 Seguimiento y Control del Proyecto
Gestión de Requisitos
Los requisitos del sistema son especificados en el artefacto Visión. Cada requisito tendrá una serie de
atributos tales como importancia, estado, iteración donde se implementa, etc. Estos atributos permitirán
realizar un efectivo seguimiento de cada requisito. Los cambios en los requisitos serán gestionados
mediante una Solicitud de Cambio, las cuales serán evaluadas y distribuidas para asegurar la integridad
del sistema y el correcto proceso de gestión de configuración y cambios.
Control de Plazos
El calendario del proyecto tendrá un seguimiento y evaluación semanal por el jefe de proyecto y por el
Comité de Seguimiento y Control.
Control de Calidad
Los defectos detectados en las revisiones y formalizados también en una Solicitud de Cambio tendrán
un seguimiento para asegurar la conformidad respecto de la solución de dichas deficiencias Para la
revisión de cada artefacto y su correspondiente garantía de calidad se utilizarán las guías de revisión y
checklist (listas de verificación) incluidas en RUP.
Gestión de Riesgos
A partir de la fase de Inicio se mantendrá una lista de riesgos asociados al proyecto y de las acciones
establecidas como estrategia para mitigarlos o acciones de contingencia. Esta lista será evaluada al
menos una vez en cada iteración.

105
Gestión de Configuración
Se realizará una gestión de configuración para llevar un registro de los artefactos generados y sus
versiones. También se incluirá la gestión de las solicitudes de cambio y de las modificaciones que éstas
produzcan, informando y publicando dichos cambios para que sean accesibles a todo los participantes
en el proyecto. Al final de cada iteración se establecerá una baseline (un registro del estado de cada
artefacto, estableciendo una versión), la cual podrá ser modificada sólo por una solicitud de cambio
aprobada.
4.4. Fase Elaboración
El objetivo de esta fase es el de analizar el dominio del problema, establecer una arquitectura sólida a
implementar y realizar los casos de uso con su respectiva descripción.
4.4.1 Arquitectura
La arquitectura del software el diseño de más alto nivel de la estructura de un sistema.
Una arquitectura de Software, también denominada arquitectura lógica, consiste en un conjunto de
patrones y abstracciones coherentes que proporcionan el marco.
Una arquitectura de software se selecciona y diseña con base en objetivos y restricciones. Los objetivos
son aquellos prefijados para el sistema de información, pero no solamente los de tipo funcional,
también otros objetivos como la mantenibilidad, adaptabilidad, flexibilidad, e interacción con otros
sistemas de información.
4.4.1.1 Introducción
El presente documento presenta una vista de alto nivel de la arquitectura del sistema, objetivos,
restricciones, los casos de uso más relevantes, la arquitectura y las principales decisiones sobre el
diseño del sistema.
4.4.1.2 Representación de la Arquitectura
El presente documento presenta la arquitectura como una serie de vistas; vista de casos de uso, vista de
procesos, vista de despliegue y vista de implementación.
Los modelos han sido desarrollados usando el IDE JDeveloper 11g, MS Visio y el lenguaje UML.
4.4.1.3 Objetivos y Restricciones de la Arquitectura
Objetivos:
 Cumplir con todos los requisitos recopilados en el documento de Visión.

106
 Realizar un correcto seguimiento de cada requisito.
Restricciones:
 Diseñar una arquitectura flexible que permita la incorporación de nuevos módulos en el futuro.
Implementar una arquitectura escalable con el patrón de diseño MVC.
4.4.1.4 Vista de Casos de Uso
4.4.1.4.1 Modelo de casos de Uso
Figura 22: Modelo de Casos de Uso
Fuente: Propia
4.4.1.4.2 Prioridad de Casos de Uso
Caso de Uso Prioridad para el
Negocio
Prioridad Técnica
Módulo de Compras de Suministros
Ingresar Suministro por Compra Alta Alta
Consultar Catálogo de Suministros Alta Media

107
Módulo de Bodega
Administrar Suministros Alta Alta
Administrar Unidades de Medida Alta Alta
Consultar Kardex de Suministros Alta Alta
Módulo Pedidos de Suministros
Elaborar Pedido Alta Alta
Consultar Catálogo de Suministros Alta Alta
Cancelar Pedido Alta Alta
Ver Requerimiento Aprobado Alta Alta
Módulo Entregas de Suministros
Entregar Pedidos Alta Alta
Consultar Pedidos Entregados Alta Alta
Entregar Bienes Sujetos a Control Alta Alta
Consultar Estadísticas de Consumo Alta Alta
Módulo de Reportes Alta Alta
Generar Reportes Alta Alta
Tabla 22: Prioridad de Casos de Uso
Fuente: Propia

108
4.4.1.4.3 Modelo de Caso de Uso Módulo de Compras de Suministros
Figura 23: Caso de Uso Módulo de Adquisición de Suministros
Fuente: Propia
4.4.1.4.4 Modelo de Caso de Uso Módulo de Bodega
Figura 24: Caso de Uso Módulo de Bodega
Fuente: Propia

109
4.4.1.4.5 Modelo de Caso de Uso Módulo de Pedidos de Suministros
Figura 25: Caso de Uso Módulo de Pedidos de Suministros
Fuente: Propia
4.4.1.4.6 Modelo de Caso de Uso Módulo de Entregas de Suministros
Figura 26: Caso de Uso Módulo de Entregas de Suministros
Fuente: Propia

110
4.4.1.4.7 Modelo de Casos de Uso Módulo de Reportes
Figura 27: Caso de Uso Módulo de Reportes
4.4.1.5 Descripción de los Casos de Uso más relevantes
4.4.1.5.1 Módulo de Compras de Suministros
4.4.1.5.1.1 Ingresar Suministro por Compra
Este caso de uso se produce cuando el responsable de suministros ingresa un suministro por compra.
4.4.1.5.1.2 Consultar Catálogo de Suministros
Se puede consultar un suministro por: partida cuando se va realizar una nueva compra.
4.4.1.5.2 Módulo de Bodega
4.4.1.5.2.1 Administrar Suministros
El responsable de suministros puede administrar los suministros, es decir: crear, modificar y eliminar.
4.4.1.5.2.2 Administrar Unidades de Medida
El administrador del sistema puede administrar las marcas es decir: crear, modificar, eliminar.
4.4.1.5.2.3 Consultar Kardex de Suministros
Permite consultar los movimientos de kardex de un suministro en el periodo actual
4.4.1.5.3 Módulo de Pedidos de Suministros
4.4.1.5.3.1 Elaborar Pedido
Los funcionarios pueden realizar pedidos de acuerdo al requerimiento aprobado de suministros.
(Módulo de Elaboración del Pac y Manejo de Partidas presupuestarias).
4.4.1.5.3.2 Cancelar Pedido
Este caso uso se ejecuta cuando un funcionario perteneciente a una unidad de trabajo cancela un pedido
de suministros. Cuando se cancela el pedido se vacía el carro de pedidos.

111
4.4.1.5.4 Módulo de Entregas de Suministros
4.4.1.5.4.1 Entregar Pedidos
Permite que el usuario decida si entrega individualmente un detalle de pedido o entregar todo el pedido
4.4.1.5.4.2 Consultar Pedidos Entregados
Este caso permite consultar pedidos pendientes que los funcionarios de las diferentes áreas de trabajo
del IESS-Imbabura han realizado.
El responsable de suministros puede optar por entregar todo el pedido.
Si el responsable de suministros decide entregar todo el pedido, el sistema le pedirá que confirme que
entregue todo el pedido.
4.4.1.5.4.3 Entregar Bienes Sujetos a Control
Este caso de uso permite al usuario responsable de suministro hacer la entrega de un bien sujeto a
control a un funcionario responsable de ese bien.
4.4.1.5.4.4 Consultar Estadísticas de Consumo
Este caso de uso permite al usuario responsable de suministro consultar las estadísticas de consumo de
un funcionario, de un Área de trabajo y de un suministro.
4.4.1.5.5 Módulo de Reportes
Figura 28: Caso de Uso Generar Reportes
4.4.1.5.5.1 Generar Reportes
Este caso se genera cuando el responsable de suministros desea obtener un reporte de: compra
individual, reporte del plan de compras de suministros, reporte detallado de compras, Pedidos,
entregas, kardex y existencias de suministros.

112
4.4.1.6 Vista de Restricciones
En esta vista se presentan las restricciones normativas, de estándares y tecnología, a las cuales está
sujeto tanto el proceso de desarrollo como el producto desarrollado, incluidas en las categorías soporte,
implementación e interfaces.
4.4.1.6.1 Normativas
Existen restricciones y normativas, dictadas por organizaciones gubernamentales, que determinan
algunas decisiones del producto desarrollado.
4.4.1.6.2 Licenciamiento
El Sistema a desarrollar utiliza varias herramientas, estándares y tecnologías, ya que algunas de estas
herramientas necesitan de una licencia se procederá a la adquisición de las respectivas licencias de la
herramienta que lo requiera.
4.4.1.6.3 Estándares
UML
Todo artefacto utilizado para comunicación y documentación, tanto entre miembros del equipo de
desarrollo como con los usuarios, está basado en UML.
Interfaz Web
La interfaz debe estar orientada a la web, se podrá visualizar el contenido utilizando cualquier
navegador.
4.4.1.6.4 Tecnología
El desarrollo del Sistema debe realizarse bajo los siguientes parámetros tecnológicos:
Elemento Tecnología
(Frameworks)
Observaciones
Base de Datos Oracle 11g Se utiliza Oracle ya que el IESS cuenta con
sus respectivas licencias.
Servidor de Aplicaciones WebLogic 10.3 Servidor de aplicaciones compatible con
WS-Security y cumple con los estándares
de JEE 5.

113
IDE de Desarrollo JDeveloper Entorno de desarrollo integrado,
principalmente para el desarrollo de
aplicaciones en lenguaje Java.
Framework JSF Tecnología y Framework para aplicaciones
java de entornos web, con un modelo de
programación de capas, potente por su fácil
desarrollo, desempeño, adopción.
RichFaces Es una librería de código abierto basada en
Java para componentes visuales en JSF, que
permite crear aplicaciones web con Ajax.
Patrón de Diseño MVC Patrón de arquitectura de software que
separa los datos de una aplicación,
la interfaz de usuario, y la lógica de
control en tres componentes distintos
Herramienta de Reportes JasperReports Herramienta escrita en Java para la creación
de informes con contenido enriquecido.
Metodología de desarrollo RUP Metodología estándar utilizada para el
análisis, implementación y documentación
de sistemas orientados a objetos.
Control de Versiones SVN Mantiene el registro de todo el trabajo y los
cambios en los ficheros que forman parte de
un proyecto, permitiendo que distintos
desarrolladores colaboren.
Tabla 23: Tecnología
Fuente: Propia
4.4.1.6.5 Sistemas Existentes
Ninguno.
La Dirección Provincial del IESS de Imbabura actualmente no tiene un sistema que gestione y controle
el inventario de suministros.

114
4.4.1.7 Vista Lógica
A continuación se presenta el patrón de arquitectura para el sistema SGCP el cual está organizado
utilizando el patrón de diseño en capas y se conforma de tres capas Modelo, Vista y Controlador.
4.4.1.7.1 Arquitectura del Sistema
Se indica la arquitectura de desarrollo y se define claramente su funcionalidad en tres capas donde se
muestra el funcionamiento del sistema.
La arquitectura para el desarrollo del sistema es el patrón de diseño MVC (Modelo Vista Controlador).
Figura 29: Patrón de diseño MVC.
Fuente: Propia
4.4.1.7.2 Arquitectura Lógica
Como refinamiento de la arquitectura del sistema, la arquitectura lógica del sistema.

115
4.4.1.7.3 Interfaz de Usuario
Figura 30: Interfaz de Usuario
Fuente: Propia
4.4.1.7.4 Servicios del sistema
El sistema ofrece los servicios de sistematizar y administrar eficientemente la información que será
utilizada para los procesos que involucran todo el personal de las diferentes áreas de la institución, la
validación de los datos de entrada, permite que la información se guarde adecuadamente.
4.4.1.7.5 Infraestructura
La infraestructura necesaria para el correcto funcionamiento del sistema se muestra a continuación.
4.4.1.7.5.1 Aplicación
Servidor de aplicaciones WebLogic Server donde se desplegará la aplicación.
4.4.1.7.5.2 Datos
La base de datos Oracle 11g es la que proporciona la persistencia de la información estable y
confiable.
4.4.1.8 Vista de Despliegue
El siguiente diagrama de despliegue muestra las relaciones físicas de los distintos nodos que componen
el sistema y el reparto de los componentes sobre dichos nodos.

116
Figura 31: Vista de Despliegue.
Fuente: Propia
4.4.2 Especificación de Casos De Uso
4.4.2.1 Modelo de Caso de Uso: Compras de Suministros
Figura 32: Caso de Uso: Compras de Suministros
Fuente: Propia

117
4.4.2.1.1 Especificación Caso de Uso: Ingresar Suministros por Compra
Descripción Breve
Este caso de uso se genera cuando el usuario con el rol de suministros ingresa al sistema para registrar
una factura de compra de suministros que puede ser de: oficina, impresión, eléctrico y aseo para lo
cual realiza las siguientes acciones.
Flujo Básico de Eventos
1. El usuario que va a ingresar al sistema debe tener asignado el rol de suministros.
2. Dentro de la pantalla principal seleccione el MENÚ SUMINISTROS escoger el submenú
COMPRAS elegir la opción LISTA DE COMPRAS.
3. Aparecerá un listado de compras de suministros los cuales se podrá filtrar por Número de factura o
por Número de Boletín.
4. Seleccione NUEVA COMPRA si desea realizar el ingreso de suministros a bodega por compra.
5. Se muestra un listado de las partidas de suministros que han sido aprobadas según el Plan anual de
contrataciones de Suministros, como por ejemplo: Material de Oficina, Material de Aseo, Material
de Impresión, Material Informático y Material Eléctrico.
6. Después de seleccionar la partida de suministros aparecerá un formulario en donde se ingresará
información referente a una factura de compra.
Figura 33: Nueva Compra Suministros
Fuente: Propia
7. Se ingresará información del encabezado de la factura como: Número de Factura, Número de
Boletín, razón social y se podrá seleccionar un proveedor, una fecha de compra, fecha de boletín
además el sistema establece la fecha de ingreso como fecha actual del sistema y el periodo
correspondiente al periodo anual abierto.

118
8. Al presionar el botón Nuevo Detalle aparecerá una pantalla de ingreso de Suministros en donde se
podrá consultar un catálogo de suministros.
a. Aparecerá el botón Guardar deshabilitado para que el usuario busque primero un
suministro y no pueda ingresar un suministro vacío en el carro de compras.
b. Al presionar el usuario en el botón cancelar podrá retornar al formulario de ingreso de
factura.
c. El usuario deberá seleccionar el suministro que está buscando.
d. Aparecerá en la pantalla el idSuministro, suministro, precio unitario y cantidad a
ingresar del suministro seleccionado.
e. El responsable de suministros podrá ingresar la cantidad.
Figura 34: Ingreso Suministro
Fuente: Propia
9. Completado los pasos anteriores mencionados procedemos a guardar.
10. El usuario podrá visualizar el detalle de la compra, editar la cantidad y el precio unitario o eliminar
el detalle de la compra si lo cree conveniente.
Figura 35: Nueva Compra con datos

119
11. Repetir pasos 7 y 8 en el caso que se requiera hasta completar los ítems de la factura.
12. Revisar si toda la información ingresada esta correcta.
13. Guardamos la información que van a ser validados y se registraran en las tablas
ACT_COMPRAS y SUM_ DETALLE_COMPRAS de la base de datos y además se incrementará
el stock en la tabla SUM_SUMINISTROS.
La estructura de las tablas mencionadas se muestra a continuación.
Figura 36: Pantalla Tablas Proceso Adquisición Suministros
Fuente: Propia
Flujos Alternativos
-El sistema comprueba la validez de los datos.
-Si los datos son correctos guarda la compra de suministros y aparece un mensaje indicando que la
compra se ha guardado exitosamente.
-Si los datos ingresados son incorrectos se envía un mensaje al usuario indicando el error.
-El sistema validará que la cantidad y precio unitario del suministro sean mayores que 0.
Precondiciones
- El Usuario debe estar dado de alta en el sistema y tener el rol de suministros para acceder al menú
SUMINISTROS y acceder al submenú COMPRAS.

120
-El usuario debe tener la factura de compra de suministros y el Boletín de Egreso.
-Se debe tener datos ingresados anteriormente en las tablas: SUM_SUMINISTROS y
ACT_PROVEEDORES.
Poscondiciones
El sistema actualiza el stock y el precio unitario de los suministros que se ingresaron en la factura de
compra en la tabla: SUM_SUMINISTROS, en la tabla SUM_KARDEX_SUMINISTROS se actualiza
el campo STOCK_COMPRAS y PRECIO_COMPRAS permitiendo además insertar un registro en la
tabla SUM_KARDEX_DETALLES con tipo de movimiento: ingreso por compra.
Figura 37: Pantalla Tablas Kardex –Inventario
Fuente: Propia
4.4.2.1.2 Especificación Caso de Uso: Consultar Catálogo de Suministros
Descripción Breve
Este caso de uso lo ejecuta el Usuario con el rol de suministros. Presenta el catálogo de suministros por
pantalla de la dependencia a la que pertenece el usuario. Se muestra una descripción del producto, y el
precio unitario. Puede seleccionarse cualquiera e introducirlo en el registro de la factura de compra de
suministros si se desea.

121
1. El Usuario con el rol de suministros accede al catálogo de suministros.
2. Se muestra por pantalla una clasificación de los suministros con los siguientes campos: Partida,
idItem, Suministro, cantidad por comprar, valor suministro, iva 0%.
Figura 38: Pantalla Catálogo de Suministros
Fuente: Propia
3. El usuario puede seleccionar uno e introducirlo en el detalle de la compra de suministros.
4. El catálogo desaparece y se muestra en el detalle de la compra el suministro que se ha
seleccionado.
Flujos Alternativos
Ninguno
Precondiciones
La tabla SUM_SUMINISTROS debe tener datos.
El Usuario responsable de suministros debe estar dado de alta en el sistema.
Poscondiciones
Ninguno.

122
4.4.2.2 Modelo de Caso de Uso: Proceso de Bodega
Figura 39: Caso de Uso: Proceso de Bodega
Fuente: Propia
4.4.2.2.1 Especificación Caso de Uso: Administrar Suministros
Descripción Breve
Este caso de uso permite al responsable de suministros la creación modificación y eliminación de
suministros.
BODEGA elegir la opción INVENTARIO.
3. Aparecerá un listado de suministros los cuales se podrá filtrar por: id, Suministro >=, stock,
Presentación, Sujeto Control, iva 0%.

123
Figura 40: Pantalla Inventario de Suministros
Fuente: Propia
4. El sistema mostrará la pantalla de administración del catálogo de suministros, donde el
usuario podrá seleccionar la opción requerida para realizar su tarea.
5. El usuario selecciona una opción: puede ser Nuevo, Editar o Eliminar.
6. El sistema ejecuta la opción seleccionada.
Subflujos
-Nuevo Suministro
En el punto 5 cuando el usuario selecciona la opción NUEVO SUMINISTRO sucede lo siguiente:
-El sistema muestra un formulario para registrar información del nuevo suministro.
Figura 41: Pantalla Nuevo Suministro
Fuente: Propia
-El usuario introduce los datos del nuevo suministro: Partida, Item, Presentación, sujeto a
control, Iva 0%.
-El sistema guarda la información proporcionada por el usuario.

124
-El usuario puede cancelar y retornar a la página donde se listan todos los suministros.
-El sistema regresa al punto 3 del flujo básico.
-Modificar Suministros
-En el punto 5 cuando el usuario selecciona la opción EDITAR sucede lo siguiente:
-Una vez seleccionado el suministro a modificar, el sistema muestra un formulario con los
datos actuales del suministro.
-El usuario modifica los campos necesarios.
-Al finalizar el usuario presiona el botón guardar.
-El sistema regresa al punto 3 del flujo básico.
Flujos Alternativos
-El sistema comprueba la validez de los datos
-Si los datos son correctos guarda el nuevo suministro.
-Si son incorrectos los datos se envía un mensaje al usuario con el error.
Precondiciones
Las tablas PAC_PARTIDAS, PAC_DETALLE_PARTIDAS y SUM_UNIDAD_MEDIDAS deben
tener datos.
Poscondiciones
-Aparece un mensaje indicando que el suministro fue guardado exitosamente.
-Se crea automáticamente el ID_SUMINISRO del nuevo suministro.
-Finalmente se creará un registro de kardex para cada producto existente. Esta creación se realizará
utilizando las tablas: KARDEX_CABECERA y KARDEX_DETALLE. Se muestran sus estructuras a
continuación:

125
Figura 42: Pantalla Tablas Proceso Inventario
Fuente: Propia
4.4.2.2.2 Especificación Caso de Uso: Administrar Unidades de Medida
Descripción Breve
Este caso de uso describe el proceso de administrar Unidades de Medida que corresponde acciones
que realiza el administrador del sistema como: insertar, modificar, eliminar Unidades de Medida de
suministros.
1. Antes de que los usuarios puedan registrar una Unidad de Medida en la tabla
SUM_SUMINISTROS, deben estar definidas las Unidades de Medida permitidas.
La estructura necesaria es la tabla SUM_UNIDAD_MEDIDAS.
Figura 43: Pantalla Tabla SUM_UNIDAD_MEDIDAS

126
2. El sistema deberá tener la pantalla que permita el manejo de esta información: creación de nuevos
registros, actualización y eliminación de Unidades de Medida.
Flujos Alternativos
1. Duplicidad de Datos
El sistema no debe permitir la existencia de varias Unidades de medida con el mismo ID_UNIDAD.
Igualmente, no puede eliminarse una Unidad de Medida que ya conste en la tabla
SUM_SUMINISTROS.
4.4.2.2.3 Especificación Caso de Uso: Administrar Tipo Movimientos
Descripción Breve
Este caso de uso describe el proceso de administrar Tipo Movimientos que corresponde acciones que
realiza el administrador del sistema como: insertar, modificar, eliminar Tipo Movimientos.
 Antes de que los usuarios puedan registrar un tipo movimiento en la tabla
SUM_KARDEX_DETALLES, deben estar definidos los tipos de movimientos permitidos como:
 Saldo inicial, ingreso por compra, egreso por entrega esto a nivel de base de datos.
La estructura necesaria es la tabla SUM_TIPO_MOVIMIENTOS
Figura 44: Pantalla Tabla SUM_TIPO_MOVIMIENTOS
Fuente: Propia

127
Flujos Alternativos
1. Duplicidad de Datos
El sistema no debe permitir la existencia de varios tipos de movimiento con el mismo
ID_MOVIMIENTO. Igualmente, no puede eliminarse un tipo de movimiento que ya conste en el
kardex de algún suministro.
4.4.2.2.4 Especificación Caso de Uso: Consultar Kardex de Suministros
Descripción Breve
Es caso de uso se genera cuando el usuario responsable de suministros desea consultar el kardex de un
suministro y ver los movimientos de compra y entrega de es suministro.
BODEGA elegir la opción KARDEX.
3. Se desplegará una pantalla donde se muestra todos los movimientos de todos los suministros en
el periodo anual abierto.
4. Se puede filtrar los kardex de acuerdo a la partida y seleccionar el suministro que se esté
buscando.
Figura 45: Pantalla kardex Suministro
Fuente: Propia

128
Precondiciones
La tabla SUM_SUMINISTROS debe tener datos.
Poscondiciones
-Se podrá consultar el kardex de un suministro para mostrar las compras y entregas que se han hecho
de ese suministro.
4.4.2.3 Modelo de Caso de Uso: Pedidos de Suministros
Figura 46: Caso de uso: Pedidos de Suministros
Fuente: Propia
4.4.2.3.1 Especificación Caso de Uso: Elaborar Pedido
Descripción Breve
El usuario con rol funcionario, después de registrarse en el sistema mediante el usuario y la contraseña
pueden invocar el caso de uso elaborar pedido de suministros el cual permite que realice un pedido por
requerimiento.
1. El usuario que va a ingresar al sistema debe tener asignado el rol de funcionario.
a. Dentro de la pantalla principal seleccione el MENÚ FUNCIONARIO escoger el
submenú SUMINISTROS elegir la opción PEDIDOS POR REQUERIMIENTO

129
2. Se le presentará una pantalla donde podrá visualizar los ítems aprobados en el requerimiento de
suministros hechos anteriormente.
3. El usuario podrá elegir uno o varios suministros y añadirlos al carro de pedidos.
4. El usuario podrá editar la cantidad del pedido y eliminar el detalle del pedido si lo desea
5. Guardar Pedido.
Flujos Alternativos
El sistema comprueba la validez de los datos
-Si los datos son correctos guarda el nuevo pedido.
-Si son incorrectos los datos se envía un mensaje al usuario con el error.
Precondiciones
-Para el caso de Pedidos por Requerimiento: el funcionario debe tener requerimientos de suministros
aprobados.
Poscondiciones
-Aparece un mensaje indicando que el pedido fue guardado exitosamente y se inserta el pedido en las
tablas SUM_PEDIDOS Y SUM_DETALLE_PEDIDOS.
Figura 47: Pantalla Tablas Proceso de Elaboración de Pedidos
Fuente: Propia

130
4.4.2.3.2 Especificación Caso de Uso: Cancelar Pedido
Descripción Breve
El usuario con rol de funcionario cancela un pedido.
1. El usuario con rol de funcionario pulsa el botón “cancelar pedido”
2. El sistema muestra un mensaje de aviso de eliminación del pedido.
3. Si el usuario con rol de funcionario pulsa el botón de “aceptar” se elimina el
pedido, mientras que si pulsa el botón “cancelar”, no se modificará el pedido.
Flujos Alternativos
Ninguno
Precondiciones
-El usuario con rol de funcionario está dado de alta en el sistema.
Poscondiciones
-El pedido es eliminado del sistema.
4.4.2.3.3 Ver Requerimiento Aprobado
Descripción Breve
El usuario con rol de funcionario puede ver el requerimiento aprobado de suministros.
El usuario con rol de funcionario pulsa el botón “ver requerimiento aprobado”
1. El sistema muestra los suministros que han sido aprobados indicando la cantidad
de requerimiento aprobada, distribución compra, cantidad pedida, cantidad
por pedir, cantidad entregada.
2. Si el usuario con rol de funcionario pulsa el botón de “aceptar” se elimina el
pedido, mientras que si pulsa el botón “cancelar”, no se modificará el pedido.
Flujos Alternativos
El usuario puede imprimir el requerimiento aprobado de suministros.

131
Precondiciones
-El usuario con rol de funcionario está dado de alta en el sistema.
-El usuario con rol de funcionario debe tener requerimientos aprobados de suministros.
Poscondiciones
-ninguno.
4.4.2.4 Modelo de Caso de Uso: Entregas de Suministros
Figura 48: Caso de uso: Entregas de Suministros
Fuente: Propia
4.4.2.4.1 Especificación Caso de Uso: Entregar Pedidos
Descripción Breve
El usuario con rol de suministros es el encargado de entregar pedidos de suministros.

132
ENTREGAS elegir la opción LISTA DE ENTREGAS DE PEDIDOS POR
REQUERIMIENTO.
3. El usuario con rol de suministros podrá consultar los pedidos pendientes y consultar las
entregas realizadas.
4. Presionar el botón Entregar.
Figura 49: Pantalla Entrega de Suministros
Fuente: Propia
5. El usuario responsable de suministros deberá confirmar realizar la entrega
Figura 50: Pantalla Confirmar realizar entrega
Fuente: Propia
6. Si el usuario presiona el botón aceptar el pedido cambia de estado pendiente a estado entregado
y la entrega se registra en la base de datos.

133
7. El stock de ese suministro es actualizado automáticamente por el sistema, restando al stock la
cantidad entregada.
Flujos Alternativos
El sistema valida que no se realice una entrega con stock insuficiente o mayor a la cantidad pedida.
Precondiciones
El pedido tiene estado pendiente.
Para realizar una entrega debe existir un pedido pendiente.
El usuario con rol de suministros está dado de alta en el sistema y ha realizado correctamente el
registro en el mismo mediante su nombre de usuario y su contraseña.
Poscondiciones
-Disminuye la cantidad de stock en bodega de ese suministro entregado.
4.4.2.4.2 Especificación Caso de Uso: Entregar Bienes Sujetos a Control
Descripción Breve
Este caso de uso permite conocer las entregas que se han hecho a los funcionarios de aquellos bienes
sujetos a control (Integración con el módulo de Gestión y control de Activos Fijos de Bienes Muebles).
Cuando el usuario con rol de suministros realiza un entrega de pedido de suministros en los que se
detalle bienes sujetos a control como lo es la grapadora, perforadora, etc.
Se realiza las siguientes acciones:
1. Se insertará en la tabla ACT_BIENES ese bien sujeto a control.

134
Figura 51: Pantalla Tabla ACT_BIENES
Fuente: Propia
2. Consultar entregas de bienes sujetos a control al seleccionar el menú funcionario y el submenú
consulta de bienes, escoger la opción bienes.
3. Se puede filtrar el tipo de bien como por ejemplo: grapadora, perforadora.
Precondiciones
El usuario con rol de suministros está dado de alta en el sistema y ha realizado correctamente el
registro en el mismo mediante su nombre de usuario y su contraseña.
Poscondiciones
Insertar en la tabla ACT_BIENES.
4.4.2.4.3 Especificación Caso de Uso: Consultar Estadísticas de Consumo
Descripción Breve
Este caso de uso permite al usuario con rol de jefe de departamento consultar las estadísticas de
consumo de un funcionario con respecto a los suministros entregados.

135
1. El usuario con rol de jefe de departamento selecciona el menú consolidar y el submenú consumo
funcionario periodo anterior.
2. Aparece una lista de funcionarios de la dependencia del usuario que está en sesión.
3. El usuario podrá filtrar los campos cédula, funcionario y área de trabajo.
4. El sistema mostrará las estadísticas de consumo de ese funcionario.
Flujos Alternativos
-La consulta de funcionarios se la hace para los funcionarios pertenecientes a la dependencia a la cual
pertenece el usuario con rol de jefe de departamento que está en sesión.
Precondiciones
El usuario con rol de jefe de departamento está dado de alta en el sistema y ha realizado correctamente
el registro en el mismo mediante su nombre de usuario y su contraseña.
Para ver el consumo de un funcionario en el periodo anual anterior el funcionario consultado debe
tener entregas, si no las tiene el sistema mostrará un mensaje de advertencia como el siguiente:
El funcionario no tiene consumo de suministros en el periodo anterior al actual.
Poscondiciones
Mostrar estadísticas de consumo de un funcionario.
4.4.2.4.4 Especificación Caso de Uso: Consultar Pedidos Entregados
Descripción Breve
Este caso de uso permite al usuario con rol de suministros consultar los pedidos entregados.
1. El usuario con rol de suministros presiona el botón VER PEDIDOS ENTREGADOS
2. Le aparecerá una lista de pedidos entregados en donde aparece los siguientes campos:
IdEntrega, idPedido, Funcionario, FechaEntrega, Área de Trabajo y un botón
VerPedidoEntregado.

136
3. Al presionar el botón VerPedidoEntregado nos aparecerá un formulario como el siguiente:
Figura 52: Pantalla Ver Pedido Entregado
4. El usuario podrá imprimir el acta de entrega en formato pdf.
Flujos Alternativos
-ninguno
Precondiciones
Para consultar los pedidos entregados debe existir por lo menos un pedido entregado.
Poscondiciones
Le permite al usuario imprimir un acta de entrega en formato pdf.
4.4.2.5 Modelo de Caso de Uso: Reportes
Figura 53: Caso de Uso: Reportes
Fuente: Propia

137
4.4.2.5.1 Especificación Caso de Uso: Generar Reportes
Descripción Breve
Este caso de uso permite al usuario con rol de suministros visualizar los diferentes reportes que se
pueden dar como son:
 Reportes de Existencias de suministros
 Reporte de Kardex de suministros.
1. El usuario ingresa al sistema para generar reportes.
2. El usuario escoge el tipo de reporte
3. El sistema visualizará el reporte solicitado.
Precondiciones
-Las tablas: SUM_SUMINISTROS, SUM_KARDEX_SUMINISTROS,
SUM_KARDEX_DETALLES, SUM_ENTREGAS_PEDIDOS deben tener datos.
Poscondiciones
-Se mostrarán los reportes de acuerdo a las necesidades de la empresa.
4.4.3 Vista Lógica
Los diagramas de la base de datos para el desarrollo los módulos del sistema se presentan a
continuación.
Para el diseño del Modelo Entidad relación y el Modelo Físico se utilizó Oracle SQL Datamodeler:
Figura 54: Oracle SQL Developer DataModeler

138
4.4.3.1 Modelo Entidad Relación
Figura 55: Modelo Entidad Relación
Fuente: Propia

139
4.4.3.2 Modelo Físico
Figura 56: Modelo Físico
Fuente: Propia

Sistema Web de Gestión y Control de Procesos para la Dirección Provincial del IESS de Imbabura.
140
4.4.3.3 Diagrama de Base de datos
Figura 57: Modelo de Datos
Fuente: Propia

141
4.5. Fase Construcción
Esta fase comprende el desarrollo del sistema se implementan las clases, los objetos de tal forma que
cumplan los requerimientos de los usuarios finales.
En esta fase suelen aparecer errores de diseño ya sea porque no se los había tenido en cuenta o se
planificó alguna actividad de manera errónea.
Los documentos generados en este documento son el modelo de datos, plan de pruebas y la lista de
riegos como se muestran a continuación.
4.5.1 Prototipo Inicial
Un Prototipo46 es una visión preliminar del modelo futuro, es un modelo operable, fácilmente
ampliable y modificable, que tiene todas las características propuestas, pero realmente es un modelo
básico que tiene que ser mejorado.
Los prototipos ayudan a identificar, comunicar y probar un producto antes de crearlo.
4.5.2 Ventajas en el uso del Prototipo
Modificación del Sistema en Etapas tempranas de su desarrollo: El éxito del uso del prototipo depende
de qué tan pronto y con qué frecuencia se reciba la retroalimentación del usuario para hacer cambios y
adecuarlos a las necesidades actuales. Los cambios iniciales durante el desarrollo de un proyecto son
menos costosos que si se realizan en etapas tardías, como el prototipo puede cambiar varias veces la
flexibilidad y adaptabilidad son su esencia, la pauta del cambio la da la retroalimentación, la cual nos
permite conocer la opinión del usuario sobre cambios a la entrada o salida de un proceso, que al
evaluarla nos permite obtener los requerimientos y mejorar el sistema.47
El desarrollo de prototipos implica una inversión en tiempo y en dinero, siempre pero siempre es
menor a la del sistema completo. Los problemas y descuidos de sistemas son más fáciles de detectar en
un prototipo.
Eliminación de sistemas indeseables: Por permitir recopilar información nos permite eliminar un
sistema que no llegó a ser lo que esperaban de él los usuarios. La inversión de tiempo y dinero se
destaca pero es menor que la del sistema completo. Se toma esta decisión cuando el sistema no es útil o
no satisface los objetivos que se propuso el equipo de desarrollo, es una decisión difícil pero evita
seguir gastando dinero y tiempo en un proyecto inservible.
46
Fuente: http://www.albertolacalle.com/hci/prototipos.htm
47
Fuente: http://www.monografias.com/trabajos12/proto/proto.shtml

142
Diseño de Sistemas acorde a las necesidades y expectativas de los usuarios: El uso del prototipo hace
que los sistemas se ajusten a las necesidades de los usuarios. Se reduce el intervalo de tiempo desde
que se relevan los requerimientos y el sistema concluido. Permite que los usuarios se involucren desde
el principio y lo hace participar en forma activa, de esta forma hacen suyo el proyecto, siendo los
principales promotores del éxito.
4.5.3 Herramientas utilizadas
Las herramientas que se utilizó para el desarrollo del prototipo inicial son las siguientes:
 JDeveloper 11g R2: Es un entorno de desarrollo integrado desarrollado por Oracle Corporation.
Figura 58: JDeveloper 11g R2
 Oracle SQL Developer: Es un entorno integrado de desarrollo que simplifica el desarrollo y
gestión de base de datos Oracle. SQL Developer ofrece completa de extremo a extremo el desarrollo de
sus aplicaciones PL / SQL, una hoja de trabajo para ejecutar consultas y secuencias de comandos, una
consola DBA para la gestión de la base de datos, una interfaz de informes, una solución completa de
modelado de datos.

Figura 59: Oracle SQL Developer
RichFaces4: Se basa en el innovador soporte para Ajax, que comenzó con RichFaces 3 y está
estandarizado en JSF 2. Además de la ampliación de estas capacidades AJAX, RichFaces también
mejora otras áreas de JSF 2, incluyendo el ajuste de rendimiento la facilidad de uso, los recursos
dinámicos, desuello, y el desarrollo de los componentes. Esto permite a los usuarios sacar el máximo
provecho de todas las mejoras de productividad de JSF 2.
Figura 60: Richfaces 4.1

143
4.5.4 Diagramas de Flujo
4.5.4.1 Diagrama de Flujo Proceso de Bodega
Este diagrama explica el funcionamiento del proceso de bodega al cual tiene acceso el usuario con rol
de suministros.
Inicio
Fin
Ingresar al Sistema
Seleccionar Menú
Inventario
Nuevo Suministro
Ingresar
Datos del
Suministro
Presionar botón
Guardar
Validar datos
Requeridos
Mostrar mensaje
de Error
Crear Kardex de
Suministros
Si
No
Proceso de Bodega
Mostrar lista de
suministros
Editar o Eliminar
Suministro
Suministro no tiene
movimientos de
compras o entregas
Si
Figura 61: Diagrama de Flujo Proceso de Bodega
Fuente: Propia

144
4.5.4.2 Diagrama de Flujo Proceso de Compras
Este diagrama explica el funcionamiento del proceso de compras de suministros al que tiene acceso el
usuario con rol de suministros.
El usuario deberá considerar que para registrar una compra debe haber un plan anual de contrataciones
aprobado y que los suministros que consten en la factura de compra deben estar registrados en el
inventario. El sistema al registrar la compra en la base de datos internamente realiza un cálculo que
permite distribuir la cantidad comprada de todos los detalles de la factura de compra para el número de
funcionarios que tienen aprobado esa cantidad de suministro según el PAC.
Inicio
Ingresar al sistema
Seleccionar Menú
Lista de Compras
Proceso de Compras
Nueva Compra
Presionar botón
Guardar
Fin
Partida de Suministros
esta habilitada según PAC
aprobado
Seleccionar Partida
de Suministros
No
Ingresar
Datos de la
Cabecera de
la Compra
Si
Presionar botón +
Buscar Suministro
Mostrar Detalles de la Compra
Botón
Seleccionar está
habilitado
No
Ingresar Cantidad
Validar Cantidad
>a 0 y <=cantidad del
Requerimiento de
suministro Aprobado
Presionar botón
Aceptar
Si
Mostrar Mensaje
de Error
No
Editar o Eliminar detalle
de la compra
Figura 62: Diagrama de Flujo Proceso de Compras
Fuente: Propia

145
4.5.4.3 Diagrama de Flujo Proceso de Pedidos
Este diagrama explica el funcionamiento del proceso de pedidos al que tiene acceso el usuario con rol
de funcionario.
El funcionario debe tener un requerimiento de suministros aprobados para poder realizar un pedido, en
el caso de que no lo tuviera el sistema mostrará un mensaje diciendo que no tiene requerimientos
aprobados.
El sistema permite al funcionario que tiene un stock mayor a cero podrá seleccionar el suministro y
agregarlo al carro de pedidos.
Existe la opción para que el funcionario pueda consultar los requerimientos aprobados de suministros
en donde se muestra la cantidad aprobada, cantidad pedida, cantidad por pedir y cantidad por entregar
esta información es importante ya que el funcionario podrá hacer un seguimiento de sus pedidos.
Proceso de Pedidos
Inicio
Elaborar Pedido Cancelar Pedido
Fin
Ingresar al
sistema
Seleccionar
Suministros
Stock
Funcionario >
a 0
Agregar suministro al
carro de pedidos
Mostrar carro
de pedidos
Editar o Eliminar
cantidad del
detalle del carro de
Pedidos
Guardar Pedido
Validar cantidad
Que sea > a 0 y <=
stockFuncionario
Si
Si
Mostrar
Mensaje de
Error
No
No
Inicio
Fin
Ingresar al
sistema
Ver Requerimiento
PAC-Suministros
Aprobado
Mostrar Lista
de Pedidos
Carro de
Pedidos tiene
elementos
Vaciar carro de
pedidos
Seleccionar
Suministros
Figura 63: Diagrama de Flujo Proceso de Pedidos
Fuente: Propia

146
4.5.4.4 Diagrama de Flujo Proceso de Entregas
Este diagrama explica el funcionamiento del proceso de entregas al que tiene acceso el usuario con rol
de suministros.
Inicio
Proceso de Entregas de Pedidos
Fin
Ingresar al
sistema
Presionar botón
Entregar pedido
Mostrar detalle
de pedido
Presionar botón
Entregar
Bien Sujeto a
control
Listar Pedidos
Entregados
Guardar bien
en tabla
ACT_BIenes
Si
No
Figura 64: Diagrama de Flujo Proceso de Entrega de Pedidos
Fuente: Propia

147
4.5.4.5 Diagrama de Flujo Reportes
Reportes
Reportes de
Suministros
Reportes de
Compras
Reportes de
Pedidos
Reportes de
Entregas
Reportes de
Kardex
Figura 65: Diagrama de Flujo de Reportes
Fuente: Propia
Página Principal después de haber ingresado al sistema de web de Gestión y Control de Procesos para
la Dirección Provincial del IESS de Imbabura.
Figura 66: Prototipo Pantalla Principal
Fuente: Propia

148
4.5.4.6 Prototipo de Pantalla: Compras de Suministros.
Este es el prototipo de pantalla Compras de Suministros.
Figura 67: Prototipo Compras de Suministros
Fuente: Propia
4.5.4.7 Prototipo de Pantalla: Entregas de Pedidos por Requerimiento.
Este es el prototipo de pantalla para lo que respecta a las Entregas de Pedidos por Requerimiento.
Figura 68: Prototipo Pedido por Requerimiento
Fuente: Propia

149
4.5.4.8 Prototipo de Pantalla: Proceso de Bodega
Este es el prototipo de pantalla para lo que respecta a Proceso de Bodega
Figura 69: Prototipo Proceso de Bodega
Fuente: Propia
4.5.5 Plan de Pruebas
4.5.5.1 Propósito
El propósito del Plan de Pruebas es generar un documento para la planificación y el control de las
pruebas, realizar el seguimiento de los requerimientos para implementar las pruebas e identificar
posibles errores e inconsistencias.
4.5.5.2 Alcance
Este plan de pruebas describe las pruebas de integración de los componentes del sistema SGCP
encaminados a evaluar la funcional y desempeño.
4.5.5.3 Estrategia de Pruebas
Las estrategias de prueba especifican las técnicas consideradas a ser usadas y el criterio de aceptación
para determinar cuándo una prueba está cumplida.

150
4.5.5.3.1 Tipos de Pruebas
4.5.5.3.1.1 Pruebas funcionales
Objetivo: Verificar las funcionalidades del sistema.
Técnica: Emitir resultados esperados con procesos válidos.
Emitir mensajes de error o advertencia cuando se realice un
proceso inválido.
Criterio de completitud: Todas las pruebas planeadas han sido realizadas.
Todos los defectos encontrados han sido registrados.
Consideraciones Especiales: Especificar elementos internos o externos que impactan la
correcta ejecución de las pruebas del Sistema.
4.5.5.3.1.2 Pruebas de Integridad de Datos
Objetivo: Asegurar la integridad de datos
Técnica:
Registrar los datos con valores válidos.
Registrar los datos de las en tablas relacionadas.
Verificar la base de datos para asegurarse que los datos guardados
están de acuerdo a los estándares definidos.
Criterio de completitud:
Todos los procesos de la Base de datos funcionan como fueron
diseñados.
Consideraciones especiales:
Se debe utilizar un conjunto pequeño de datos para incrementar la
visibilidad de cualquier evento anormal o inesperado.
Los datos de pruebas deberían ser reales y de uso común.
Las pruebas de integridad pueden requerir un ambiente para
ingresar o modificar datos directamente en la Base de datos.
Tabla 24: Pruebas de Integridad de Datos

151
4.5.5.3.1.3 Pruebas del Ciclo del negocio
Objetivo:
Asegurar que el sistema funciona de acuerdo con el modelo de
negocios emulando todos los eventos en el tiempo y en función
del tiempo.
Descripción de la prueba:
Las pruebas del ciclo de negocio deberían emular las actividades
ejecutadas en él a través del tiempo.
Se deberá identificar un periodo y las transacciones y actividades
que podrían ocurrir durante ese periodo deberían ejecutarse.
Incluyendo todos los ciclos y eventos diarios, semanales y
mensuales.
Técnicas:
Ejecute cada caso de uso, flujo básico o función utilizando datos
válidos e inválidos, para verificar que:
Incremente el número de veces en que una función es ejecutada
para simular diferentes usuarios sobre un periodo especificado.
Todas las fechas, funciones que involucren tiempos serán
probadas con datos válidos e inválidos o periodos de tiempo.
Todas las funciones ocurren en un periodo de tiempo serán
ejecutadas en dicho tiempo.
Los resultados esperados ocurren cuando los datos válidos son
usados.
Los mensajes de error o de advertencia aparecen en el momento
adecuado, cuando se utiliza un dato inválido.
Cada regla de negocios es aplicada adecuadamente.
Todas las pruebas planeadas han sido ejecutadas.
Todos los defectos que se identificaron han sido tenidos en
cuenta.
Consideraciones especiales:
Las fechas y eventos del sistema pueden requerir actividades
especiales de soporte.
Se requiere un modelo de negocios para identificar requisitos y
procedimientos de prueba apropiados.
Tabla 25: Pruebas del Ciclo de Negocio

152
4.5.5.3.2 Pruebas de Interfaz de Usuario
Objetivo:
Verificar la correcta navegación reflejando las funcionalidades de
las páginas.
Se realiza una navegación de cada funcionalidad a través de todos
los menús y de cada submenú.
Todos los elementos de las páginas deben tener una misma
estructura y característica.
Las pruebas verifican la adecuada interacción del usuario con el
software encargándose de la verificación de cada interfaz, la
correcta acción que realiza y que cumpla con los objetivos
planteados.
Técnicas:
Se utilizara la ayuda de los usuarios para que trabajen con el
sistema en un ambiente real produciendo salidas normales del
sistema.
Los usuarios del sistema son reales y trabajan en su área de
trabajo normal.
Los usuarios realizan pruebas al sistema a su criterio.
Se establece un periodo de pruebas, en el que los errores
detectados no sean clasificados como críticos para el sistema.
Tiempo prudente para la aplicación de la prueba.
Consideraciones especiales: Coordinación entre los usuarios y los desarrolladores para que los
errores que se detecten puedan ser solucionados.
Tabla 26: Pruebas de Interfaz de Usuario
4.5.5.3.3 Pruebas de Desempeño
Objetivo:
Validar y comprobar el tiempo de respuesta para las transacciones
o procesos bajo las siguientes condiciones:
Concurrencia normal anticipada.

153
Concurrencia máximo anticipada.
Las pruebas miden los tiempos de respuesta que tiene el sistema.
Por lo general las pruebas se realizan varias veces, combinando
entre una y otra cargas diferentes.
La primera prueba debe ejecutarse con una carga similar a la
esperada, y la segunda prueba final se ejecuta utilizando una carga
máxima esperada.
Estas pruebas se pueden utilizar para medir el desempeño del
sistema en función de condiciones como el hardware.
Algunas características que pueden afectar el desempeño son:
Cuellos de botella en el disco o CPU.
Capacidades de almacenamiento y físicas del hardware donde está
alojado el sistema.
Congestión en la red de datos.
Técnicas:
Se utilizara la ayuda de los usuarios para que trabajen con el
sistema en un ambiente real produciendo salidas normales del
sistema.
Los usuarios del sistema son reales y trabajan en su área de
trabajo normal.
Los usuarios realizan pruebas al sistema a su criterio.
Criterio de completitud
Se establece un periodo de pruebas, en el que los errores
detectados no sean clasificados como críticos.
Tiempo prudente para la aplicación de la prueba
Consideraciones especiales
Coordinación entre los usuarios y los desarrolladores para que los
errores que se detecten puedan ser solucionados.
Tabla 27: Pruebas de Desempeño

154
4.5.5.4 Pruebas de Seguridad y Control de Acceso
Objetivo:
Seguridad en la funcionalidad y Datos: verificar que los usuarios
puedan acceder solo aquellas funciones y datos otorgados en los
permisos al momento de crear su perfil de usuario.
Seguridad del Sistema: Verificar que solo aquellos usuarios con
roles y permisos de privilegio puedan acceder las opciones del
sistema.
Se realizará en base a dos criterios principales:
- Seguridad en la aplicación incluyendo el acceso a la
información y funciones del negocio.
- Seguridad del sistema realizando registro de accesos de
usuarios al sistema.
Técnicas:
- Seguridad de Datos y Funciones, identificar los usuarios
y asignar funciones a las que tiene acceso.
- Efectuar pruebas para cada tipo de usuario y verificar los
permisos creando transacciones para cada usuario.
- Modificar los tipos de usuario y verificar si los permisos
han cambiado para el usuario.
Criterio de completitud
Para cada usuario se puede asignar funciones y datos apropiados
para su desempeño.
Consideraciones especiales
El acceso al sistema debe ser revisado con el administrador de la
red y de la base de datos.
Tabla 28: Pruebas de Seguridad y Control de Acceso

155
4.5.5.5 Herramientas
Tarea Herramientas
Registro de Defectos Microsoft Word
Otras Herramientas de
Prueba
SQLDeveloper
Gestión de Proyecto JDeveloper, Microsoft Project, Microsoft Word
Herramientas DBMS SQL Developer, JDeveloper, Navicat
Tabla 29: Herramientas
4.5.5.6 Recursos
La siguiente tabla muestra los colaboradores que se encargarán de la realización de las pruebas:
Rol
Recurso
Requerido
Responsabilidad Específica
Administrador de
Pruebas
Rubén González
Pablo Toapanta
Proveer las directrices de las pruebas.
Adquirir los recursos Necesarios.
Diseñador de Pruebas
Rubén González
Pablo Toapanta
Identificar y priorizar las pruebas.
Generar Plan de Pruebas
Evaluar la efectividad del esfuerzo en las pruebas
Evaluador del Sistema Rubén González
Pablo Toapanta
Responsables de ejecutar las pruebas y registro de
resultados.
Administrador de BDD
Rubén González
Pablo Toapanta
Asegurar los datos de pruebas.
Tabla 30: Recursos

156
4.5.5.7 Entregables
Entregable Propietario Revisión/Distribución
Plan de Pruebas
Rubén González
Eddy Uvidia
Pablo Toapanta
Coordinadores del proyecto
Tabla 31: Entregables
4.6. Fase de Transición
En esta fase se traslada el sistema a la comunidad del usuario y se realizan las correcciones necesarias,
generando la versión final del sistema.
El sistema debe estar completo, en un nivel aceptable de calidad y debe estar disponible la
documentación necesaria para que al ser llevado al entorno del usuario produzca resultados positivos
para el usuario.
4.6.1 Descripción Proyecto Final
El sistema web de Gestión y Control de inventario de Suministros registrará los procesos de
adquisición de suministros, proceso de inventario, pedidos de suministros, entregas de suministros,
consultar kardex de suministros.
4.6.2 Implementación del Aplicativo
Para realizar la implementación del sistema se utilizaron las siguientes herramientas:
Lenguaje de Programación: Java
Framework: JSF2
IDE de desarrollo: JDeveloper 11g R2
Gestor de Base de Datos: ORACLE 11g R2
Servidor de Aplicaciones: Weblogic Server 10.3.5
Reportes: JasperReports/iReports
Framework RIA: RichFaces 4
Tabla 32: Herramientas Utilizadas
Fuente: Propia

157
La plataforma utilizada es JEE en su versión 5, la versión del servidor de aplicaciones WebLogic
Server es la 10.3, como IDE de desarrollo se utiliza JDeveloper 11g R2. Las figuras que se utilizan en
el sistema fueron diseñadas en Paint.
Para realizar la implementación de la base de datos, se realizó un análisis previo del problema, en este
caso se realizaron las tablas correspondientes, quedando como se muestra en la figura.
Figura 70: Pantalla Tablas del sistema en ORACLE SQL DEVELOPER
Fuente: Propia

CAPÍTULO V
Conclusiones
Recomendaciones
Análisis de Impacto

159
5. Capítulo V: Conclusiones , Recomendaciones y Análisis de Impacto
5.1. Conclusiones
 Con la Implementación de un sistema informático mejorará la gestión y control del
inventario de Suministros para la Dirección Provincial del IESS de Imbabura permitiendo
conocer ágilmente el stock de los suministros y que las entregas de suministros sean más
rápidas.
 La implementación del Sistema de Gestión y Control de Inventarios de Suministros,
permitió mejorar la calidad para la gestión de la información, ya que se simplificó
procesos manuales que llevaban mucho tiempo y no eran exactos ni fiables.
 El Módulo de Gestión y Control de Inventarios de Suministros se integró correctamente
con los demás módulos: Módulo de Gestión y Control de Activos Fijos de Bienes Muebles
y con el módulo de Elaboración del PAC y manejo de Partidas Presupuestarias de
adquisiciones en un sola aplicación denominada Sistema web de Gestión y Control de
Procesos para la Dirección Provincial del IESS de Imbabura.
 Apliqué los conocimientos adquiridos de jsf2, Ejb3 y Richfaces 4.1 para una
implementación más rápida del sistema de Gestión y Control de inventarios de
Suministros.
5.2. Recomendaciones:
 Se recomienda una participación muy activa de los usuarios involucrados para cumplir
los objetivos planteados.
 Colaborar de gran manera a los funcionarios en lo que respecta a la definición del
sistema, mostrando interés por sus inquietudes y futuros requisitos.
 Se debe realizar un seguimiento al uso del sistema de Gestión y Control de Inventarios
de Suministros y buscar posibles mejoras al sistema.
 Se recomienda el registro adecuado de la información para tener información real y
confiable en el momento que se necesite.

160
5.3. Análisis de Impacto
El análisis de impacto se sustenta con información estadística, cambios y mejoras de: procesos,
procedimientos, tiempos, rendimientos, etc.
El análisis del impacto permite determinar los beneficios y el grado de aceptación que la propuesta
genera en la institución.
Algunos de los resultados inmediatos que tendrá la implementación del sistema sobre las personas
implicadas son: reducción de tiempo en la ejecución de las tareas debido a la integración y
automatización de funciones, consistencia e integridad de la información.
De las entrevistas informales llevadas a cabo con el personal de la institución, se notaron varios puntos
importantes.
Para la valorización se utilizó una escala del 1 al 10 en la cual se asignará un valor dependiendo del
grado de eficiencia de cada uno de los de los aspectos a tomar en cuenta los mismos se describen a
continuación.
Análisis (cambios
y mejoras) en:
Evaluación
Anterior
Evaluación
Actual
Explicación(Evaluación Actual)
Procesos 5 10  Tomando en cuenta que es un sistema nuevo se
automatizaron los procesos del sistema de gestión y
control de inventarios de suministros permitiendo integrar
los procesos como: Bodega, Compras, Pedidos, Entregas
y Reportes mejorando la gestión y el control de la
información de los inventarios de suministros.
Procedimientos 5 10  Se mejoraron los procedimientos que tienen que ver con
la gestión y control de los inventarios de suministros.
 Se cambiaron los procedimientos relacionados con:
compras (el responsable de suministros podrá consultar
el plan anual de contrataciones de suministros y dando un
seguimiento de las cantidades compradas y cantidades por
comprar). Con respecto a los pedidos los funcionarios
podrán dar seguimiento de sus pedidos (sabiendo la
cantidad aprobada, cantidad pedida, cantidad por pedir y
cantidad entregada de suministros). El responsable de
suministros hará las entregas en base a los pedidos. El

161
responsable de suministros podrá consultar las existencias
de los suministros y ver los movimientos de compras y
entregas de una manera rápida.
Tiempos 7 10  El sistema de gestión y control de inventarios de
suministros permitirá mejorar el tiempo de acceso a la
información en tiempo real y actualizada, permitiendo a
los funcionarios realizar pedidos y al responsable de
suministros realizar entregas de una manera rápida y
eficiente.
 Con información actualizada se ve reducidos los tiempos
de respuesta de la toma de decisiones.
Rendimiento 7 10
 Al usar el sistema se mejorará el rendimiento de las
tareas en comendadas al responsable de suministros ya
que el sistema le ayudará a procesar la información más
rápido.
 Se podrá generar reportes inmediatamente
 Facilidad de acceso a la información, en cualquier
momento.
 Información confiable y segura.
Procesos Procedimiento Tiempos Rendimiento
10 10 10 10
5 5
7 7
Evaluación Actual Evaluación Anterior
Se hace una descripción de los principales puntos de cambio y mejora.

162
Descripción
/Escala
0 1 2 3 4 5 6 7 8 9 10 Uso del
Sistema
(Puntuación) Razón
Tiempo en
acceso a la
información
x Antes (3) Porque antes se lo realizaba
manualmente.
x Después (10) Ahora se va a utilizar un sistema
que realiza la automatización de la
información lo que permite que el
acceso a la información sea rápida y
confiable.
Presentación
de
información
x Antes (3) porque al llevar el registro de los
movimientos de los inventarios en
forma manual. Difícilmente se podrá
obtener reportes de inventarios en
menor tiempo.
x Después (10) porque al utilizar una herramienta
informática nos da la posibilidad de
generar reportes de inventarios de
suministros en menor tiempo y de
manera personalizada.
Tiempo de
Elaboración
y Entrega
de pedidos
x Antes (5) porque los funcionarios hacían el
pedido sin saber lo que realmente existe
en bodega, lo que en la mayor parte de
las veces hacía que los funcionarios
pidan cosas que no estaban planificadas
o no existen en bodega.
x Después (10) porque los funcionarios al utilizar
un sistema web pueden elaborar sus
pedidos de manera rápida en base a la
planificación de sus requerimientos.

163
Beneficios
Los beneficios que el sistema presente son claramente identificados y se puede decir que se ha logrado
satisfactoriamente cumplir con el objetivo de brindar una herramienta para lograr mejorar la gestión y
control de los inventarios de suministros.
Los usuarios podrán hacer uso del sistema que les permita tener acceso a información confiable,
precisa y oportuna, optimizar los procesos de la institución y la posibilidad de compartir información
entre diferentes áreas para tener un mayor control sobre ellas.

165
6. Glosario de Términos
 SGCP: Sistema Web de Gestión y Control de Procesos para la Dirección Provincial del IESS
de Imbabura.
 MGCIS: Módulo de Gestión y Control de Inventarios de Suministros
 Stock: Es una voz inglesa que se usa en español con el sentido de existencias.
 Suministro: Puede referirse a: abastecimiento que es la actividad económica encaminada a
cubrir las necesidades de consumo de una unidad económica en tiempo, forma y calidad,
como puede ser una familia, una empresa.
 Demo: En informática las demos o versiones demo son prototipos, versiones incompletas o de
evaluación de un determinado programa informático con el fin de mostrar la idea de
funcionamiento y demostrar sus funcionalidades. Se utilizan para que los usuarios o
potenciales clientes puedan probar el software antes de comenzar a utilizarlo en un ambiente
real.
 Inventario: Por inventario se define al registro total de los bienes y demás cosas
pertenecientes a una persona o comunidad, hecho con orden y precisión.
 Tarjeta Kardex: Permite un control permanente y actualizado de los suministros al precio de
costo.
 Java EE: Java Plataform, Enterprise Edition o Java EE es una plataforma de programación
parte de la Plataforma Java para desarrollar y ejecutar software de aplicaciones en el lenguaje
de programación Java con arquitectura de N capas distribuidas y que se apoya ampliamente en
componentes de software modulares ejecutándose sobre un servidor de aplicaciones.
 EJB: Los EJB proporcionan un modelo de componentes distribuido estándar del lado
del servidor. El objetivo de los EJB es dotar al programador de un modelo que le permita
abstraerse de los problemas generales de una aplicación empresarial (concurrencia,
transacciones, persistencia, seguridad, etc.) para centrarse en el desarrollo de la lógica de
negocio en sí. El hecho de estar basado en componentes permite que éstos sean flexibles y
sobre todo reutilizables.

166
 Subversion (SVN): Utiliza el concepto de revisión para guardar los cambios producidos en el
repositorio. Entre dos revisiones sólo guarda el conjunto de modificaciones (delta),
optimizando así al máximo el uso de espacio en disco.
 MVC: Modelo Vista Controlador (MVC) es un patrón de arquitectura de software que separa
los datos de una aplicación, la interfaz de usuario, y la lógica de negocio en
tres componentes distintos. El patrón de llamada y retorno MVC (según CMU), se ve
frecuentemente en aplicaciones web, donde la vista es la página HTML y el código que provee
de datos dinámicos a la página. El modelo es el Sistema de Gestión de Base de Datos y
la Lógica de negocio, y el controlador es el responsable de recibir los eventos de entrada desde
la vista.
 Weblogic: Oracle WebLogic es un servidor de aplicaciones Java EE y también un servidor
web HTTP desarrollado por BEA Systems posteriormente adquirida por Oracle Corporation.
Se ejecuta en Unix, Linux, Microsoft Windows, y otras plataformas.
 IDE: Es un entorno de desarrollo integrado, Un IDE es un entorno de programación que ha
sido empaquetado como un programa de aplicación, es decir, consiste en un editor de código,
un compilador, un depurador y un constructor de interfaz gráfica (GUI).
 JDeveloper : Es un entorno de desarrollo integrado desarrollado por Oracle Corporation para
los lenguajes Java, HTML, XML, SQL, PL/SQL, Javascript, PHP, Oracle ADF, UML y otros.
Es un software propietario pero gratuito desde 2005.
 Framework: Es una estructura conceptual y tecnológica de soporte definido, normalmente con
artefactos o módulos de software concretos, con base a la cual otro proyecto de software puede
ser más fácilmente organizado y desarrollado. Típicamente, puede incluir soporte
de programas, bibliotecas, y un lenguaje interpretado, entre otras herramientas, para así ayudar
a desarrollar y unir los diferentes componentes de un proyecto.
 JSF: Java Server Faces (JSF) es una tecnología y framework para aplicaciones Java basadas en
web que simplifica el desarrollo de interfaces de usuario en aplicaciones Java EE.
 API: Interfaz de programación de aplicaciones es el conjunto de funciones y
procedimientos (o métodos, en la programación orientada a objetos) que ofrece
cierta biblioteca para ser utilizado por otro software como una capa de abstracción. Son usadas
generalmente en las bibliotecas (también denominadas vulgarmente "librerías").

167
 UML: Lenguaje Unificado de Modelado, es un lenguaje gráfico para visualizar, especificar,
construir y documentar un sistema.
 Java: Es un lenguaje de programación orientado a objetos desarrollado por Sun Microsystems
 Richfaces: Es una biblioteca de código abierto basada en Java que permite crear aplicaciones
web con Ajax.
 JasperReport: Es una herramienta de creación de informes que tiene la habilidad de entregar
contenido enriquecido al monitor, a la impresora o a ficheros PDF, HTML, XLS, CSV y XML.
 IReport: Es un diseñador visual de código libre para JasperReports escrito en Java.
Es un programa que ayuda a los usuarios y desarrolladores que usan la librería JasperReports
para diseñar reportes visualmente.
 Prototipo: Puede ser un modelo del ciclo de vida del software
 RUP: Es un proceso de desarrollo de software y junto con el Lenguaje Unificado de
Modelado UML, constituye la metodología estándar más utilizada para el análisis,
implementación y documentación de sistemas orientados a objetos.

Módulo de Gestión y Control del Inventario de Suministros
169
7. Bibliografía
LIBROS
Sarmiento, Rubén, R. (2001). Contabilidad General (Sexta Edición). Quito-Ecuador: Publingraph.
PUBLICACIONES EN LINEA
Gaither, Norman; Frazier, Greg (2000). Administración de producción y operaciones. Editorial
Thomsom. p. 355.1.Recuperado de: http://es.wikipedia.org/wiki/Inventario
Java Server Faces 1. (1). Recuperado:http://www.oracle.com/technetwork/java/javaee/javaserverfaces-
139869.html
Ing. Germán Pereyra General Paz s/n, 2568 Mórrison Provincia de Córdoba, Argentina.1
Recuperado de: http://www.monografias.com/trabajos12/proto/proto.shtml
Nielsen, J. (2003) Paper Prototyping: Getting User Data Before You Code. 1. Recuperado de
http://www.albertolacalle.com/hci/prototipos.htm
Gaither, Norman; Frazier, Greg (2000). Administración de producción y operaciones.Editorial
Thomsom.p.355.
Monson-Haefel de Richard. (2004) .Enterprise JavaBeans, 4th edition, [O'Reilly, ISBN 0-596-00530-
X] Recuperado de: http://es.wikipedia.org/wiki/Enterprise_JavaBeans
Mkyong (2012) JSF 2.0 hello world example.1. Recuperado de http://www.mkyong.com/jsf2/jsf-2-0-
hello-world-example/
Marcos jara, 2010-03-06 Anotaciones en EJB 3.0.1 (1). Recuperado de:
http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=AnotacionesEJB3
Ángel, F. G. (2001). Introducción a los JavaBeans. Programación en lenguaje Java. Recuperado de
http://www.sc.ehu.es/sbweb/fisica/cursoJava/applets/javaBeans/fundamento.htm
Matías, C. (27 de febrero). Beans de Sesión. Seminario de Computadores II, 12-13-14. Recuperado de
http://www2.elo.utfsm.cl/~elo326/presentaciones/Ronda2/SesionBeans.pdf
Alejandro, P. G. (2006). Introducción a JSF (Java Server Faces). Ayudas Técnicas, JSF - Java Server
Faces, 1-1. Recuperado de http://www.desarrolloweb.com/articulos/2380.php

171
8. Anexos
Los archivos estarán ubicados en la carpeta de anexos, del DVD de este proyecto.
Anexo A: Manual Técnico
Anexo B: Manual de Usuario
Anexo C: Manual de Instalación

Tesis formato pdf

Más contenido relacionado

Destacado (20)

Tesis formato pdf