Tesis Luis Farias - Comedor

UNIVERSIDAD DE ORIENTE
NCLEO DE MONAGAS
INGENIERIA DE SISTEMAS
COMISIN DE TRABAJO DE GRADO
MATURN / MONAGAS / VENEZUELA
SISTEMA WEB PARA LA PLANIFICACION Y CONTROL DEL SERVICIO

DE ALIMENTACION PRESTADO POR EL COMEDOR UNIVERSITARIO
DE LA UNIVERSIDAD DE ORIENTE NUCLEO DE MONAGAS.
Informe de Pasantas de Grado presentado ante la Comisin de Trabajos de Grado,

como requisito para optar al ttulo de Ingeniero en Sistemas.
Br. Luis F. Farias A.

C.I: 17.243.047
Tutor Acadmico: Ing. Rosngela Garca
Tutor Laboral: Ing. Jess Chaparro
Maturn, Enero de 2010

NCLEO DE MONAGAS
INGENIERA DE SISTEMAS
COMISIN DE TRABAJOS DE GRADO
ACTA DE EVALUACIN
En mi carcter de Asesor Laboral del trabajo presentado por el Bachiller

FARIAS AGUILARTE LUIS FERNANDO portador de la cdula de identidad
nmero: 17.243.047, para optar al grado acadmico de Ingeniero de Sistemas,
Titulado: SISTEMA WEB PARA LA PLANIFICACION Y CONTROL DEL
SERVICIO DE ALIMENTACION PRESTADO POR EL COMEDOR
UNIVERSITARIO DE LA UNIVERSIDAD DE ORIENTE NUCLEO DE
MONAGAS, considero que dicho trabajo rene los requerimientos y mritos
suficientes para ser sometido a la evaluacin por parte del jurado examinador.
En la ciudad de Maturn a los veintinueve das del mes de Julio de dos mil
nueve.
Ing. Jess Chaparro

C.I. 4.526.369
ii
NCLEO DE MONAGAS
ACTA DE EVALUACIN
En mi carcter de Asesor Acadmico del trabajo presentado por el Bachiller

FARIAS AGUILARTE. LUIS FERNANDO portador de la cdula de identidad
nmero: 17.243.047, para optar al grado acadmico de Ingeniero de Sistemas,
Titulado: SISTEMA WEB PARA LA PLANIFICACION Y CONTROL DEL
SERVICIO DE ALIMENTACION PRESTADO POR EL COMEDOR
UNIVERSITARIO DE LA UNIVERSIDAD DE ORIENTE NUCLEO DE
MONAGAS, considero que dicho trabajo rene los requerimientos y mritos
suficientes para ser sometido a la evaluacin por parte del jurado examinador.
En la ciudad de Maturn a los veintinueve das del mes de Julio de dos mil
nueve.
Ing. Rosngela Garca

C.I. 8.977.359
iii
NCLEO DE MONAGAS
APROBACIN
Quienes suscriben, Miembros del jurado evaluador designados por la

comisin de Trabajos de Grado de la Escuela de Ingeniera de Sistemas de la
Universidad de Oriente Ncleo Monagas, para examinar el Trabajo de Grado
modalidad pasanta presentado por el Bachiller: FARIAS AGUILARTE. LUIS
FERNANDO, portador de la cdula de identidad nmero: 17.243.047 Titulado:
DE LA UNIVERSIDAD DE ORIENTE NUCLEO DE MONAGAS, el cual es
presentado para optar al grado acadmico de Ingeniero de Sistemas, consideramos
que dicho trabajo cumple con los requisitos exigidos para tal efecto y por tanto lo
declaramos: _____________
En la ciudad de Maturn a los veintinueve das del mes de Julio del dos mil
nueve.
_______________________ ______________________
Ing. Beatriz Prez Ing. Cristhian Ronceros
C.I. C.I.
iv
DEDICATORIA
Este Trabajo de Grado se lo dedico a mis padres Susana Aguilarte y Vicente

Farias, por estar siempre all, por apoyarme y preocuparse por mi, y guiarme por el
buen camino. Tambin se lo dedico a mis hermanos, Fernando y Daniel.
Luis F. Farias A.
v
AGRADECIMIENTOS
A DIOS, por darme tanta fortaleza y paciencia para llegar hasta el final de esta
meta propuesta.
A mis padres, por darme todo lo que tengo en la vida.
A la Universidad de Oriente y a sus profesores, por impartirme conocimientos
para mi formacin profesional.
A mi asesora acadmica, Ing. Rosngela Garca, por brindarme su apoyo,
conocimientos y orientacin a lo largo del desarrollo del proyecto.
Al Ing. Jess Chaparro (Asesor Laboral), por guiarme y por su colaboracin
en la realizacin de este proyecto.
A todo el personal del Centro de Computacin, y en especial a Ennio
Villaroel, Yhuanailys Nuez y a Luis Figueroa, por ser tan excelentes personas, por
aconsejarme, motivarme, ayudarme e instruirme en muchos aspectos importantes del
proyecto.
A mis compaeros de pasanta, por animarnos mutuamente y por apoyarnos
para alcanzar esta meta tan anhelada.
Al personal del Comedor Universitario, por brindar toda la colaboracin
necesaria para el desarrollo de este proyecto.
A mis compaeros de la UDO, quienes durante toda la carrera compartimos
gratos y duros momentos juntos.
A mis buenos amigos, por brindarme su confianza y apoyo. Gracias por ser
tan atentos conmigo.
Luis F. Farias A.
vi
NCLEO DE MONAGAS
INGENIERIA DE SISTEMAS
COMISIN DE TRABAJO DE GRADO

Autor: Farias A. Luis F. CI: 17.243.047
RESUMEN
El presente trabajo de investigacin tiene como propsito principal el desarrollar

un sistema Web para la Planificacin y Control del servicio de alimentacin prestado por
el comedor universitario de la Universidad de Oriente Ncleo de Monagas. Para ello fue
necesario estudiar el funcionamiento actual de dicha rea, y determinar la problemtica
que presentaba en la prestacin del servicio de alimentacin; para luego, definir los
requerimientos de informacin del sistema en base a dicha problemtica y a las
necesidades del personal que labora en dicho comedor universitario; procedindose
despus a disear una arquitectura slida que cumpliera con todos los requerimientos
establecidos, hasta finalmente obtener un prototipo inicial de la aplicacin, de acuerdo a
esa arquitectura diseada. Dicho trabajo sigui un tipo de investigacin proyectiva, con
un nivel comprensivo y un diseo de campo; emplendose como tcnicas de recoleccin
de los datos la revisin documental, la entrevista no estructurada y la observacin directa,
con el fin de extraer la informacin del lugar objeto de estudio; mientras que la tcnica de
anlisis de datos utilizada fue la de anlisis de contenido. Para el logro de los objetivos
planteados, se sigui como gua de desarrollo de software la metodologa RUP con la
ayuda de la herramienta de modelado UML. De igual manera, se pudo concluir que con
el desarrollo y futura implantacin del sistema se agilizar el proceso de planificacin
alimentaria, pudiendo considerar al momento de su elaboracin la demanda estimada
promedio; permitir controlar el acceso de comensales al rea de servicio y la
entrada/salida de insumos del almacn; y adems, traer consigo ahorro significativo de
tiempo en la generacin de reportes de costos.
Palabras Claves: Ingeniera, Desarrollo, Sistema, Web, Comedor Universitario.
vii
INDICE GENERAL
ACTA DE EVALUACIN ..........................................................................................ii
ACTA DE EVALUACIN .........................................................................................iii
APROBACIN............................................................................................................iv
DEDICATORIA ........................................................................................................... v
AGRADECIMIENTOS ...............................................................................................vi
RESUMEN..................................................................................................................vii
INDICE GENERAL...................................................................................................viii
LISTA DE FIGURAS ..................................................................................................xi
LISTA DE CUADROS ...............................................................................................xii
LISTA DE DIAGRAMAS.........................................................................................xiii
LISTA DE PANTALLAS........................................................................................... xv
LISTA DE FORMULAS ...........................................................................................xvi
LISTA DE ANEXOS................................................................................................xvii
INTRODUCCIN ........................................................................................................ 1
CAPITULO I................................................................................................................. 3
CONTEXTO ORGANIZACIONAL ............................................................................ 3

1.1 Breve resea histrica de la Universidad de Oriente ........................................ 3
1.2 Universidad de Oriente Ncleo de Monagas ................................................... 4
1.2.1 Resea histrica ........................................................................................... 4
1.2.2 Visin ........................................................................................................... 7
1.2.3 Misin .......................................................................................................... 7
1.2.4 Objetivos ...................................................................................................... 8
1.2.5 Estructura Organizativa................................................................................ 8
1.3 Centro de Computacin Ncleo de Monagas................................................. 10
viii
1.3.1 Visin ......................................................................................................... 10
1.3.2 Misin ........................................................................................................ 10
1.3.3 Objetivos .................................................................................................... 10
1.3.4 Funciones ................................................................................................... 11
1.3.5 Estructura Organizativa.............................................................................. 12
1.3.6 Seccin de Programas y Proyectos ............................................................ 13
1.4 Comedor Universitario de la UDO-Ncleo de Monagas .................................. 13
1.4.1 Estructura Organizativa.............................................................................. 14
1.4.2 Actividades del Personal ............................................................................ 15
CAPITULO II ............................................................................................................. 19
EL PROBLEMA Y SUS GENERALIDADES........................................................... 19

2.1 Planteamiento del Problema............................................................................ 19
2.2 Objetivos de la Investigacin ............................................................................ 24
2.2.1 Objetivo General ........................................................................................ 24
2.2.2 Objetivos Especficos................................................................................. 24
2.3 Justificacin de la Investigacin ....................................................................... 24
2.4 Alcance de la Investigacin .............................................................................. 27
CAPITULO III ............................................................................................................ 28
MARCO REFERENCIAL.......................................................................................... 28
3.1 Antecedentes de la Investigacin ...................................................................... 28
3.2 Bases Tericas................................................................................................... 30
3.2.1 Metodologa RUP ...................................................................................... 30
3.2.2 Lenguaje Unificado de Modelado.............................................................. 43
3.2.3 Tarjetas CRC (clase, responsabilidad y colaboracin) .............................. 66
3.2.4 Entregables de RUP ................................................................................... 68
3.2.5 Sistema de Inventario Permanente ............................................................. 74
3.2.6 Pronsticos de demanda............................................................................. 79
3.2.7 Sistemas de informacin ............................................................................ 81
3.2.8 Aplicacin WEB ........................................................................................ 83
3.2.9 HTML ........................................................................................................ 85
3.2.10 Tecnologas de Programacin del lado del cliente................................... 87
3.2.11 Tecnologas de Programacin del lado del servidor ................................ 88
3.2.12 Servidor Web Apache .............................................................................. 90
3.2.13 AJAX ....................................................................................................... 90
3.2.14 Base de Datos........................................................................................... 91
3.2.15 ORACLE.................................................................................................. 94
3.2.16 Sybase Powerdesigner.............................................................................. 95
3.2.17 Macromedia Dreamweaver 8 ................................................................... 96
ix
3.2.18 XAMPP .................................................................................................... 97
3.2.19 Software Libre.......................................................................................... 97
3.3 Bases Legales .................................................................................................... 98
3.3.1 Decreto 3390 sobre el uso del software libre. ............................................ 98
3.4 Definicin de Trminos..................................................................................... 99
CAPITULO IV.......................................................................................................... 101
MARCO METODOLGICO................................................................................... 101

4.1 Tipo y Nivel de la Investigacin. .................................................................... 101
4.2 Diseo de la Investigacin .............................................................................. 102
4.3 Poblacin y Muestra........................................................................................ 103
4.4 Tcnicas e Instrumentos de Recoleccin de Datos. ........................................ 104
4.5 Tcnicas de Anlisis de Datos. ....................................................................... 105
4.6 Diseo Operativo. ........................................................................................... 106
CAPITULO V ........................................................................................................... 112
RESULTADOS......................................................................................................... 112
5.1 Etapa I. Estudio del Negocio........................................................................... 114
5.2 Etapa II. Diseo de la Arquitectura................................................................. 188
5.3 Etapa III. Construccin del Software. ............................................................. 316
5.4 Anlisis Costo Beneficio.............................................................................. 342
5.4.1 Costos....................................................................................................... 342
5.4.2 Beneficios................................................................................................. 344
CONCLUSIONES .................................................................................................... 347
RECOMENDACIONES ........................................................................................... 349
BIBLIOGRAFA ...................................................................................................... 351
ANEXOS .................................................................................................................. 357
x
LISTA DE FIGURAS
Figura 1. Estructura Organizativa de la Universidad de Oriente Ncleo Monagas. ..... 9

Figura 2. Estructura Organizativa del Centro de Computacin. ................................. 12
Figura 3. Estructura Organizativa del Comedor de la UDO Ncleo Monagas........... 15
Figura 4. Los casos de uso integran el trabajo. ........................................................... 33
Figura 5. Evolucin de la arquitectura del sistema. .................................................... 35
Figura 6. Una iteracin RUP....................................................................................... 36
Figura 7. Estructura de RUP. ...................................................................................... 37
Figura 8. La vida de un proceso conformado por ciclos ............................................. 38
Figura 9. Fases e hitos en RUP. .................................................................................. 38
Figura 10. Relacin entre roles, actividades, artefactos.............................................. 41
Figura 11. Vista general de los elementos de UML.................................................... 46
Figura 12. Representacin de una dependencia. ......................................................... 48
Figura 13. Representacin de una asociacin. ............................................................ 48
Figura 14. Representacin de una generalizacin....................................................... 49
Figura 15. Representacin de una generalizacin....................................................... 49
Figura 16. Arquitectura de un sistema software (UML 2.0). ...................................... 53
Figura 17. Clasificacin de diagramas UML. ............................................................. 54
Figura 18. Representacin de una clase. ..................................................................... 55
Figura 19. Relacin entre clases.................................................................................. 56
Figura 20. Ejemplo Diagrama de despliegue. ............................................................. 58
Figura 21. Elementos Diagrama de casos de uso........................................................ 61
Figura 22. Lnea de vida de un objeto......................................................................... 65
Figura 23. Activacin de un objeto. ............................................................................ 66
Figura 24. Mensaje entre objetos. ............................................................................... 66
Figura 25. Tarjeta CRC. .............................................................................................. 67
Figura 26. Datos de Articulo 127B ............................................................................. 77
Figura 27. Asientos y cuenta inventario perpetuo (PEPS).......................................... 78
Figura 28. Estructura Bsica de un documento HTML. ............................................. 86
Figura 29. Arquitectura del Producto........................................................................ 136
Figura 30. Representacin de Equipos...................................................................... 300
Figura 31. Tarjeta CRC AccesoComensal. ............................................................... 308
Figura 32. Tarjeta CRC SolicitudServicio. ............................................................... 309
Figura 33. Tarjeta CRC Insumo. ............................................................................... 309
Figura 34. Tarjeta CRC Men................................................................................... 309
Figura 35. Tarjeta CRC Planificacin....................................................................... 310
Figura 36. Tarjeta CRC ExistenciaArticulo. ............................................................. 310
xi
LISTA DE CUADROS
Cuadro 1. Tipo de Relaciones entre Clases................................................................. 57

Cuadro 2. Elementos Diagrama de Actividad............................................................. 60
Cuadro 3. Tabla Documentacin de Riesgos. ............................................................. 71
Cuadro 4. Cuadro Operativo ..................................................................................... 110
Cuadro 5. Plan General ............................................................................................. 117
Cuadro 6. Cronograma de Reuniones ....................................................................... 124
Cuadro 7. Planteamiento del problema. .................................................................... 128
Cuadro 8. Posicin del Producto............................................................................... 130
Cuadro 9. Roles y Responsabilidades. ...................................................................... 131
Cuadro 10. Participantes y Rol.................................................................................. 132
Cuadro 11. Necesidades de participantes a nivel de Trabajo.................................... 132
Cuadro 12. Necesidades de participantes a nivel de Sistemas. ................................. 133
Cuadro 13. Necesidades de los usuarios. .................................................................. 134
Cuadro 14. Sistema para el Comedor Universitario.................................................. 137
Cuadro 15. Requerimientos de Software. ................................................................. 139
Cuadro 16. Requerimientos de Hardware. ................................................................ 139
Cuadro 17. Requerimientos de Materiales. ............................................................... 139
Cuadro 18. Requerimientos de Servicios. ................................................................. 140
Cuadro 19. Identificador 001 .................................................................................... 143
Cuadro 20. Identificador 002. ................................................................................... 143
Cuadro 27. Identificador: 009. .................................................................................. 147
Cuadro 30. Actor-Actividad...................................................................................... 154
Cuadro 31. Diagrama de Actividad Solicitar Insumos.............................................. 177
Cuadro 32. Reglas del Dominio ................................................................................ 301
Cuadro 33. Resumen de Costos ................................................................................ 344
Cuadro 34. Disminucin de tiempo en la generacin del plan alimentario. ............. 345
Cuadro 35. Reduccin de tiempo en la generacin del Resumen de Costos. ........... 346
xii
LISTA DE DIAGRAMAS
Diagrama 1. Plan de Fase.......................................................................................... 118

Diagrama 2. Segunda Iteracin. ................................................................................ 119
Diagrama 3. Tercera Iteracin................................................................................... 119
Diagrama 4. Cuarta Iteracin. ................................................................................... 120
Diagrama 5. Quita Iteracin...................................................................................... 120
Diagrama 6. Sexta Iteracin...................................................................................... 121
Diagrama 7. Sptima Iteracin.................................................................................. 121
Diagrama 8. Octava Iteracin. .................................................................................. 122
Diagrama 9. Novena Iteracin. ................................................................................. 122
Diagrama 10. Dcima Iteracin. ............................................................................... 123
Diagrama 11. Caso de uso General del Negocio....................................................... 151
Diagrama 12. Modelo de Dominio del Negocio. ...................................................... 153
Diagrama 13. Casos de Uso Planificar Mens.......................................................... 157
Diagrama 14. Diagrama de Actividad Planificar Mens. ......................................... 161
Diagrama 15. Casos de Uso Realizar Pedido de Insumos. ....................................... 163
Diagrama 16. Diagrama de Actividad Realizar Pedido de insumos ......................... 167
Diagrama 17. Casos de Uso Registrar Entrada de Insumos...................................... 169
Diagrama 18. Diagrama de Actividad Registrar Entrada de Insumos. ..................... 172
Diagrama 19. Casos de Uso Solicitar Insumos. ........................................................ 174
Diagrama 20. Casos de Uso Registrar Comensales. ................................................. 179
Diagrama 21. Diagrama de Actividad Registrar Comensales................................... 182
Diagrama 22. Casos de Uso Realizar Resumen Mensual de Costos......................... 184
Diagrama 23. Diagrama de Actividad Realizar Resumen Mensual de Costos. ........ 187
Diagrama 24. Caso de Uso General del Sistema....................................................... 190
Diagrama 25. Casos de Uso Autenticar Usuario....................................................... 191
Diagrama 26. Diagrama de Secuencia Autenticar Usuario....................................... 193
Diagrama 27. Casos de Uso Administrar Usuarios del Sistema. .............................. 199
Diagrama 28. Diagrama de Secuencia Administrar Usuarios del Sistema. .............. 202
Diagrama 29. Casos de Uso Registrar Insumos. ....................................................... 205
Diagrama 30. Diagrama de Secuencia Registrar Insumos. ....................................... 210
Diagrama 31. Casos de Uso Conformar Mens Alimentarios.................................. 214
Diagrama 32. Diagrama de Secuencia Conformar Mens Alimentarios.................. 219
Diagrama 33. Casos de Uso Elaborar Planificacin Alimentaria. ............................ 223
Diagrama 34. Diagrama de Secuencia Elaborar Planificacin Alimentaria. ............ 232
Diagrama 35. Casos de Uso Generar Hoja de Pedido............................................... 238
Diagrama 36. Diagrama de Secuencia Generar Hoja de Pedido............................... 241
Diagrama 37. Casos de Uso Controlar Acceso de Comensales. ............................... 244
Diagrama 38. Diagrama de Secuencia Controlar Acceso de Comensales. ............... 247
xiii
Diagrama 39. Casos de Uso Elaborar Solicitud de Servicio del Comedor. .............. 250
Diagrama 40. Diagrama de Secuencia Elaborar Solicitud Servicio del comedor..... 252
Diagrama 41. Caso de Uso Consultar Solicitud de Servicio del Comedor............... 255
Diagrama 42. Diagrama de Secuencia Consultar Solicitud Servicio del comedor. .. 258
Diagrama 43. Casos de Uso Registrar Existencia de Articulo.................................. 261
Diagrama 44.Diagrama de Secuencia Registrar Existencia de Articulo................... 265
Diagrama 45. Casos de Uso Registrar Entrada de Artculos en Almacn. ............... 268
Diagrama 46. Diagrama de Secuencia Registrar Entrada de Artculos en Almacn.272
Diagrama 47. Casos de Uso Registrar Salida de Artculos de Almacn................... 276
Diagrama 48. Diagrama de Secuencia Registrar Salida de Artculos de Almacn... 281
Diagrama 49. Casos de Uso Generar Resumen de Costos........................................ 284
Diagrama 50. Diagrama de Secuencia Generar Resumen de Costos........................ 289
Diagrama 51. Modelo de Clases. .............................................................................. 307
Diagrama 52. Modelo Conceptual. ........................................................................... 312
Diagrama 53. Modelo Fsico..................................................................................... 313
Diagrama 54. Modelo de Base de Datos Relacional del Sistema. ............................ 314
Diagrama 55. Modelo de Despliegue........................................................................ 315
xiv
LISTA DE PANTALLAS
Pantalla 1. Autenticar Usuario. ................................................................................. 194

Pantalla 2. Men Principal Usuario Administrador del Sistema............................... 194
Pantalla 3. Men Principal Usuario Nutricionista..................................................... 195
Pantalla 4. Men Principal Usuario Administrador del Comedor. ........................... 195
Pantalla 5. Men Principal Usuario Almacenista. .................................................... 196
Pantalla 6. Men Principal Usuario Ayudante del Comedor. ................................... 196
Pantalla 7. Men Principal Usuario Solicitante. ....................................................... 197
Pantalla 8. Administrar Usuarios del Sistema........................................................... 203
Pantalla 9. Detalles de Usuario del Sistema.............................................................. 203
Pantalla 10. Listado de Insumos Registrados............................................................ 211
Pantalla 11. Ventana para Agregar Nuevo Insumo................................................... 211
Pantalla 12. Pantalla para editar datos de Insumo..................................................... 212
Pantalla 13. Listado de Mens Alimentarios Registrados. ....................................... 220
Pantalla 14. Ventana para Agregar Nuevo Men...................................................... 220
Pantalla 15. Pantalla para editar datos de Men. ...................................................... 221
Pantalla 16. Vista de Planificaciones Alimentarias por Semana............................... 233
Pantalla 17. Pantalla para editar datos de Planificacin Alimentaria Semanal......... 234
Pantalla 18. Ventana para Estimacin de Comensales.............................................. 235
Pantalla 19. Ventana para Modificar Men de la Planificacin Alimentaria. .......... 235
Pantalla 20. Ventana para Incluir Insumos a la Planificacin Alimentaria............... 236
Pantalla 21. Listado de Insumos Requeridos de la Planificacin Alimentaria. ........ 242
Pantalla 22. Pantalla para Registro de Acceso Comensales...................................... 248
Pantalla 23. Pantalla para Consultar Historial de Comensales. ................................ 248
Pantalla 24. Pantalla para elaborar solicitud de servicio del comedor...................... 253
Pantalla 25. Listado de Solicitudes de Servicio Recibidas. ...................................... 259
Pantalla 26. Pantalla para cambiar status de la solicitud de servicio del comedor. .. 259
Pantalla 27. Lista de Stock de Artculos en Almacn. .............................................. 266
Pantalla 28. Detalles de la Existencia de un Articulo en Almacn. .......................... 266
Pantalla 29. Bandeja de Registro de Entradas........................................................... 273
Pantalla 30. Registro de Entrada de Artculos al Almacn. ...................................... 274
Pantalla 31. Registro de Salida de Artculos de Almacn......................................... 282
Pantalla 32. Ventana de Ajuste de Existencia de Articulo........................................ 282
Pantalla 33. Reporte Control Diario de Costo........................................................... 290
Pantalla 34. Reporte Relacin por Servicio y Nmero de Comensales. ................... 290
Pantalla 35. Reporte Relac. de alimentos., bebidas y otros recibidos por almacn. . 291
Pantalla 36. Reporte Relacin de alimentos y conexos entregados por almacn...... 291
Pantalla 37. Reporte Resumen Mensual de Costo. ................................................... 292
xv
LISTA DE FORMULAS
Frmula 1. Frmula de Promedio Mvil. ................................................................. 230
xvi
LISTA DE ANEXOS
Anexo 1. Forma Men y Alimentos Requeridos. ..................................................... 358

Anexo 2. Forma Mercancas Despachadas Por Despensa. ....................................... 359
Anexo 3. Forma Comprobante de Entrega de Materiales. ........................................ 360
Anexo 4. Forma Control de Existencias. .................................................................. 361
Anexo 5. Forma Control Diario de Costo. ................................................................ 362
Anexo 6. Forma Resumen Mensual de Costo........................................................... 363
Anexo 7. Forma Diario de Almacn. ........................................................................ 364
xvii
INTRODUCCIN
En la actualidad, el uso de los sistemas de informacin para la administracin,

procesamiento y distribucin de la informacin en una organizacin, se hace cada vez
ms indispensable. Pues estos sistemas permiten lograr ahorros significativos en
tiempo y mano de obra, debido a que automatizan tareas operativas de la
organizacin y ofrecen un gran apoyo en el proceso de toma de decisiones que
permiten, entre otras cosas, lograr ventajas competitivas en el momento de la
implantacin y uso del sistema de informacin.
Adems se producen muchos otros beneficios por utilizar este tipo de sistemas
en la organizacin. Estos tienen impacto directo en la calidad de decisin, mejora la
comunicacin, produce reduccin de los costos, incrementa la productividad, permite
el manejo eficiente de la informacin e integridad de la misma, entre otros.
Dentro de las universidades, y especficamente en la Universidad de Oriente,

estos sistemas juegan un papel fundamental, debido que permiten automatizar y
agilizar muchos de los procesos que all se realizan. Es por ello, que en esta
investigacin se plantea el desarrollo de un sistema de informacin para el rea del
comedor universitario, que permita la planificacin y el control del servicio de
alimentacin ofrecido por la UDO-Monagas, con el fin de proveer informacin veraz,
rpida y actualizada de los procesos que all se manejan para garantizar una efectiva
toma de decisiones.
Para la realizacin de este proyecto se utilizaron ciertos mtodos y tcnicas de

la Ingeniera de Software, que sirvieron de apoyo y permitieron llevar a cabo de
manera eficiente y ordenada el desarrollo del nuevo sistema informtico. Como
1
mtodo de desarrollo, se aplic la Metodologa RUP (Rational Unified Process) y
como herramienta el Lenguaje Unificado de Modelado UML.
El presente trabajo de grado est estructurado en cinco captulos, los cuales

contemplan lo siguiente:
Captulo I, contiene informacin de la empresa donde fue desarrollada la

investigacin, es decir el contexto organizacional, detallando su misin, visin,
objetivos, estructura organizativa, etc.
Captulo II, contempla el planteamiento del problema, los objetivos de la

investigacin, la justificacin y el alcance.
Captulo III, constituido por los antecedentes que apoyan la presente investigacin y
las bases tericas que le dan sustento al trabajo investigativo.
Captulo IV, presenta el marco metodolgico y en ella se describe la metodologa de

la investigacin y la metodologa de rea aplicada para el desarrollo del trabajo.
Contiene tipo y nivel de investigacin, poblacin y muestra, tcnicas e instrumentos
de recoleccin de datos, tcnicas de anlisis de datos y diseo Operativo.
En el Capitulo V, se muestran los resultados obtenidos, luego de haber aplicado la

metodologa, siguiendo el diseo operativo planteado.
Finalmente, se presentan las conclusiones y recomendaciones obtenidas de la

investigacin, as como la bibliografa consultada y los anexos que complementan el
trabajo.
2
CAPITULO I
CONTEXTO ORGANIZACIONAL
1.1 Breve resea histrica de la Universidad de Oriente
La Universidad de Oriente (UDO) fue creada el 21 de noviembre de 1958,

mediante el Decreto Ley No. 459 dictado por la junta de Gobierno presidida por el
Dr. Edgard Sanabria, siendo Ministro de Educacin el Dr. Rafael Pizani, bajo la
conduccin de su Rector fundador el Dr. Luis Manuel Pealver.
Inicia sus actividades en Cuman el 12 de febrero de 1960 con 120 bachilleres

en la Unidad de Cursos Bsicos y a la vez, se programan las carreras de Matemtica,
Fsica, Qumica y Biologa. Posteriormente, el 29 de mayo de ese mismo ao, la
UDO es inaugurada oficialmente por el Presidente de la Repblica Rmulo
Betancourt, en un acto solemne donde tambin pronunciaron discursos el escritor
Rmulo Gallegos; el Ministro de Educacin para ese entonces Rafael Pizani y el
Presidente de la Comisin Organizadora Luis Manuel Pealver.
En Octubre de 1961, se instala el Ncleo de Monagas con la Escuela de

Ingeniera Agronmica y Petrleo. En el Ncleo de Bolvar se iniciaron las
actividades en Enero de 1962 con la Escuela de Medicina y la Escuela de Geologa y
Minas, en el Ncleo de Anzotegui comenzaron el 9 de enero de 1963 con la Escuela
de Ingeniera y Qumica, y en el Ncleo de Nueva Esparta se iniciaron los Cursos
Bsicos el 21 de Enero de 1969.
En su concepcin la Universidad de Oriente se define como un sistema de

educacin Superior al servicio del pas con objetivos comunes a las dems
3
universidades venezolanas y del mundo. No obstante, es nica en su gnero,
experimental y autnoma, innovadora en la creacin de la unidad profesional de
Cursos Bsicos, la departamentalizacin, los lapsos semestrales, el sistema de
unidades de crditos, los cursos intensivos, etc., desarrollando investigacin
cientfica, docencia y extensin en todos los aspectos del conocimiento, que
contempla sus programas educativos de pre y postgrado.
La sede principal de la UDO est situada en la ciudad de Cuman, Estado

Sucre y cuenta con ncleos universitarios ubicados en los Estados Anzotegui,
Bolvar, Monagas, Nueva Esparta, y Sucre; asumiendo as la responsabilidad de la
educacin universitaria y ser el motor fundamental del desarrollo integral en toda la
regin insular, nororiental y sur del pas, en funcin de las condiciones, posibilidades
y tendencias de desarrollo de cada uno de los estados orientales donde funcionan.
Administrativamente la autoridad mxima es el Consejo Universitario,

formado por las autoridades rectorales, los Decanos de los cinco ncleos, cinco
representantes de los profesores, un representante estudiantil de cursos bsicos, dos
representantes estudiantiles de los cursos profesionales, un representante del
Ministerio de Educacin y un representante de los egresados, quienes tienen la
responsabilidad de asumir colegiadamente la orientacin y gestin de la Universidad.
1.2 Universidad de Oriente Ncleo de Monagas
1.2.1 Resea histrica
El Ncleo de Monagas inicia sus actividades el 12 de febrero de 1962, cuando

ingresa a sus aulas el primer contingente de estudiantes, conformado por 31 alumnos
de Ingeniera Agronmica y trece de Ingeniera de Petrleo, quienes haban
completado el curso bsico en Cuman. Las instalaciones del antiguo campo
petrolero de Jusepn, adquirido por la Universidad, mediante venta simblica
4
realizada por la Creole Petroleum Corporation, sirven de asiento al proyecto
acadmico que comenzaba a echar races en el oriente venezolano, marcando el hito
ms trascendental en el acontecer de la educacin superior en la zona.
En febrero de 1968, la Escuela de Ingeniera de Petrleo fue trasladada al

Ncleo de Anzotegui, en Puerto La Cruz, y en su lugar se crea, en 1966, la Escuela
de Zootecnia (la primera de esta especialidad que se funda en Venezuela y la segunda
en toda Amrica latina), cuya creacin haba sido aprobada por el Consejo Directivo
Universitario, en abril de 1966. As se consolida la ms slida estructura acadmica
regional en el campo de las ciencias agrcolas, respondiendo acertadamente a los
objetivos originarios que alentaron la creacin del Ncleo de Monagas.
En enero de 1974, se establece la Unidad de Estudios Bsicos, en las

edificaciones de lo que fue un colegio de religiosos, ubicadas en la Urb. Juanico, en
Maturn. Con la apertura de esta unidad, puede decirse que comienza la consolidacin
acadmica del Ncleo, pero, al mismo tiempo, se inicia el proceso de masificacin,
pues hasta esa fecha todos los estudiantes deban realizar sus cursos bsicos en el
Ncleo de Sucre, en Cuman.
La dinmica del desarrollo regional, que haba determinado una creciente

demanda de profesionales, especialmente en el campo de la administracin y la
gerencia, por el resurgimiento de la explotacin petrolera, obligaron a redisear
estrategias en funcin de esa nueva realidad. As, se despliega el abanico acadmico,
abriendo especialidades en estas reas, pero sin descuidar a las tradicionales carreras
del agro, que responden a una necesidad imperiosa del desarrollo y a la verdadera
vocacin de la tierra monaguense.
De esta manera, en sintona con la dinmica del desarrollo regional, el 21 de

julio de 1990 el Consejo Universitario aprueba la carrera de Gerencia de Recursos
Humanos y, en 1992, el CNU autoriza el otorgamiento del ttulo respectivo.
5
Posteriormente, se abren las carreras de Administracin Industrial y Contadura
Pblica. Estas tres disciplinas estn hoy adscritas, como departamentos, a la Escuela
de Ciencias Sociales y Administrativas, establecida en el Ncleo el 23 de junio de
1998.
Asimismo, en 1993, se abre la licenciatura de Tecnologa de los Alimentos,

adscrita a la Escuela de Zootecnia, y se restablece la Escuela de Ingeniera de
Petrleo, en diciembre de 1994. Ms recientemente, en el primer semestre de 2002, se
apertura la carrera de Ingeniera de Sistemas, en respuesta a la demanda profesional
en esta especialidad, como consecuencia del desarrollo inusitado en el campo de la
informtica y atendiendo a la creciente necesidad de servicios de asesora en sistemas
administrativos y mejoramiento de procesos, tanto en el sector pblico como privado.
La infraestructura fsica del Ncleo de Monagas tiene su sede principal en el

campus Los Guaritos, en Maturn, cuya primera etapa fue inaugurada el 21 de agosto
de 1990. Posteriormente, se construyeron dos nuevas edificaciones que aportan otras
54 aulas y el edificio de Recursos de la Escuela de Ciencias Sociales y
Administrativas. En este campus estn concentrados los Cursos Bsicos y las escuelas
profesionales que adscriben a las ocho carreras que conforman la oferta acadmica
del Ncleo; as como los diferentes servicios estudiantiles que dispensa la
Universidad.
En las edificaciones de Juanico, antigua sede de los Cursos Bsicos, funcionan

el decanato, las coordinaciones acadmica y administrativa, dependencias
administrativas y dems oficinas regionales; as como el Centro de Estudios de
Postgrado, el Instituto de Investigaciones Agrcolas y Pecuarias, la Comisin de
Investigaciones, la Coordinacin de Relaciones Interinstitucionales, la Delegacin de
Informacin y Comunicacin Corporativa, el Centro de Computacin, la
Coordinacin de Publicaciones y dems dependencias de asesora y apoyo de la
institucin.
6
1.2.2 Visin
La Universidad de Oriente reafirmar su compromiso de ser el centro de

estudio, anlisis y produccin de ideas necesarias para el desarrollo social, econmico
y poltico del Oriente del Pas, capaz de desarrollar mtodos y tecnologa
innovadoras, de asegurar la calidad por medio de los sistemas eficientes de
planificacin, evaluacin y motivacin.
La Universidad ser una Institucin cuyo ambiente estimule la creatividad y

productividad de todos sus miembros. As mismo deber ocupar una posicin de
liderazgo en investigacin y logros acadmicos. Con intencin de situarse en un lugar
privilegiado en los sueos de cada miembro de la Comunidad Universitaria.
1.2.3 Misin
Formar profesionales del ms alto nivel de calidad, profesionales que atiendan

problemas de su particular formacin y competencia, bajo un alto espritu de
solidaridad y compromiso social. Se trata de formar profesionales creativos, capaces
de destacarse en un mercado cada vez ms competitivo con el mejoramiento de la
calidad de vida y con el desarrollo.
Mantener una permanente vinculacin con sus egresados para su actualizacin

constante. As mismo, permanecer en contacto con los sectores sociales y
productivos.
Brindar a sus trabajadores tanto, en la parte acadmica, administrativa y

estudiantil las mejores condiciones para que estos encuentren el xito en el
desempeo de sus funciones. Mantener un clima de respeto mutuo, de libertad de
expresin, organizacin, de pluralidad de todas las corrientes de pensamiento, dentro
7
de un ambiente de responsabilidad y tolerancia a todas las ideas e igualmente estar
vinculada con su entorno.
1.2.4 Objetivos
1. Impartir Educacin Superior Universitaria de la ms alta calidad, con el fin de

obtener profesionales de excelencia.
2. Promover y desarrollar labores de investigacin cientfico, humanstica y
tecnolgica, en las reas y disciplinas en las que considere necesaria su
participacin en relacin a los problemas regionales y nacionales.
3. Desarrollar actividades de proyeccin social y extensin Universitaria.
4. Hacia la obtencin de estos objetivos deben orientarse las actividades bsicas
de la Universidad: Docencia, Investigacin y Extensin.
1.2.5 Estructura Organizativa
Para el desempeo de sus funciones y para el logro de sus objetivos la

Universidad de Oriente Ncleo de Monagas se encuentra dividida tal como se
muestra en la Figura 1, p.9.
8
Consejo de Ncleo
Decano
Delegacin de Bienestar y Coordinacin Delegacin de

Coordinacin Acadmica Planificacin
Desarrollo Estudiantil Administrativa
Delegacin de
Extensin y
Actividades Coordinacin Cultura
Servicio Coordinacin Coordinacin
Extra- Servicio Delegacin de Delegacin de
Social de Postgrado de Servicios
Acadmicas Comunitario Presupuesto Personal Formacin y
Generales Desarrollo de
Recursos
Humanos
Servicio Comisin de Divulgacin y
Orientacin
Mdico-Dental Curicula Publicaciones Delegacin de
Nmina Almacn Vigilancia
Finanzas Delegacin de
Deporte
Control de Bienestar Archivo y

Seccin Mantenimiento
Estudios Social Correspondencia Delegacin de
Contabilidad
Planta Fsica
Transporte Aseo y
Comedor Centro de Limpieza Asesora
Universitario Computacin Jurdica
Talleres Biblioteca
Bienes
Seccin de Central
Nacionales
Compras
Oficina
Informacin y
Clnica Relaciones
Universitaria Pblicas
Tecnologa
Educativa
Escuela de Ing. Escuela de Escuela de Instituto de

Escuela de Ciencias Unidad de Cursos
Investigaciones
De Petrleo Zootecnia Agronoma Sociales y Administrativas Bsicos
Agropecuarias
Departamento de
Departamento de Departamento de
Biologa y Departamento de Departamento de Departamento de
Produccin e Invest. Sector
Saneamiento Agronoma Humanidades Ciencias
Industria Animal Agrcola
Animal
Programa Departamento de Departamento de

Departamento de Invest. Sector
Tecnolgico de Nutricin Animal Seccin de
Ing. Agrcola Ambiente y
los Alimentos y Forraje Ingles Programa de
Recursos Naturales
Ingeniera de
Sistemas
Departamento de Departamento Seccin de
Economa Administrativo Castellano
Agrcola Agro-Industrial Seccin de
Fsica
Seccin de
Ciencias Sociales
Seccin de
Matemtica
Departamento de Departamento de Departamento de Seccin de

Gerencia de Administracin Contadura Quimica
Recursos Humanos Industrial Pblica
Seccin de Seccin de
Seccin de Seccin de Seccin de Seccin de Seccin de
Recursos Seccin de Seccin de Administracin
Humanos y Investigacin Coordinacin Administracin Contabilidad y Economa y Contabilidad Investigacin Economa y
Informtica Administrativa y Derecho Finanzas Mercadeo
Psicologa Legislacin
Figura 1. Estructura Organizativa de la Universidad de Oriente Ncleo Monagas.

Fuente: Delegacin de Personal. (2009).
9
1.3 Centro de Computacin Ncleo de Monagas
El Centro de Computacin, es una dependencia adscrita a la Coordinacin

Administrativa del Ncleo Monagas de la Universidad de Oriente, proyectada en
materia de polticas que sustenten la promocin de una cultura de comunicacin
electrnica y de servicios informticos en el rea acadmico-administrativa.
1.3.1 Visin
Ser un centro de Computacin competitivo, lder a nivel nacional en todas las

reas de nuestro inters, contando con el apoyo de un personal altamente capacitado
y estableciendo una plataforma tecnolgica til que satisfaga las necesidades del
sector docente, estudiantil y administrativo de la Universidad de Oriente Ncleo
Monagas.
1.3.2 Misin
Coordinar y mantener una estructura integral ptima en las reas, de

comunicacin electrnica y servicios informticos, mediante el diseo y desarrollo de
servicios de redes, software y soporte tcnico, para fortalecer las actividades
acadmico - administrativa y contribuir al desarrollo tecnolgico de la Universidad de
Oriente - Ncleo Monagas.
1.3.3 Objetivos
1. Disear y desarrollar aplicaciones con fines didcticos y administrativos.

2. Asesorar a las autoridades universitarias del ncleo sobre las innovaciones
tecnolgicas relacionadas con la computacin e informtica y su impacto en
la organizacin.
10
3. Generar conocimientos en las diversas reas de la computacin y sistemas
mediante proyectos de investigacin.
4. Ofrecer servicios a la comunidad local y regional en los rubros de anlisis,
diseo y auditoria de sistemas de informacin, redes y adiestramiento de
personal.
5. Coordinar la aplicacin de servicios informticos a otras unidades
organizativas de la Universidad de Oriente.
6. Desarrollar los sistemas de informacin que permitan la automatizacin de la
gestin administrativa de la Universidad de Oriente Ncleo Monagas.
7. Capacitar el recurso humano de la institucin con la finalidad de asegurar el
manejo eficiente de los equipos computacionales disponibles en diferentes
unidades de la organizacin.
8. Evaluar y controlar la plataforma operativa del Centro de Computacin.
1.3.4 Funciones
1. Desarrollar y mantener los sistemas de informacin orientados al proceso de

automatizacin de la gestin administrativa de la Institucin.
2. Coordinar y supervisar el funcionamiento de las unidades que integren el
Centro de Computacin.
3. Distribuir, segn la capacidad productiva, las tareas del personal adscrito al
Centro de Computacin.
4. Procesar lo relacionado con la nmina de pago, el rea de contabilidad y
presupuesto.
5. Brindar de forma permanente soporte tcnico a las unidades administrativas
del ncleo Monagas de la Universidad de Oriente.
6. Capacitar al personal de la Institucin en el manejo eficiente de los equipos de
computacin, a travs de cursos, charlas y seminarios de actualizacin y
charlas.
11
7. Prestar asesora en el rea de computacin y Teleinformtica a aquellas
unidades que integran la estructura administrativa y acadmica de la
Universidad de Oriente.
8. Procesa toda la informacin necesaria para el departamento de Admisin y
Control de Estudio. As mismo presta todos los servicios necesarios en los
procesos de inscripcin, informes al CNU y estadsticas acadmicas.
9. El Centro puede atender solicitudes de aplicaciones para el anlisis estadstico
de datos generados por las investigaciones que se realizan en el ncleo.
El Centro de Computacin, para el ejercicio de sus funciones y el logro de sus

objetivos, se encuentra organizado tal como se muestra en la siguiente figura:
Jefatura
Secretaria
Seccin de Programas Seccin de

y Proyectos Soporte Tcnico
Valor Soporte
Desarrollo Redes Seguridad
Agregado Tcnico
Figura 2. Estructura Organizativa del Centro de Computacin.

Fuente: Centro de Computacin. (2009).
12
1.3.6 Seccin de Programas y Proyectos
En la Figura 2, p.12 se puede apreciar que el Centro de Computacin se

encuentra dividido en varias secciones, entre las cuales se encuentra la seccin de
programas y proyectos. Esta, es la encargada de desarrollar e implementar sistemas
de informacin que permitan la automatizacin de los procesos relacionados con las
reas administrativa, acadmica y de personal. Asistir a las distintas dependencias del
Ncleo Monagas, en la realizacin de proyectos informticos. Mantener actualizadas
las herramientas de hardware y software relacionadas con el diseo, desarrollo e
implementacin de sistemas informticos en el Ncleo. Se encarga de adiestrar al
personal sobre las herramientas de desarrollo que utiliza, desarrolla aplicaciones
Web, realiza mantenimiento y depura las aplicaciones implementadas, entre otros.
1.4 Comedor Universitario de la UDO-Ncleo de Monagas
El comedor universitario de la Universidad de Oriente Ncleo de Monagas es

una unidad de trabajo, cuyo objetivo fundamental es proveer una alimentacin sana y
balanceada a los estudiantes y trabajadores de la institucin. Su funcin es obtener los
mejores resultados en la prestacin de los servicios de alimentacin, a travs del
cuidadoso manejo de los fondos destinados a ese fin.
Esta dependencia comienza sus actividades en el aos de 1965 en las

instalaciones de Jusepn, prestando el servicio de alimentacin a la comunidad
universitaria de dicho ncleo que para esa poca comprenda las escuelas de
Agronoma y Zootecnia. Luego, de acuerdo con el desarrollo del ncleo en 1968 se
puso en funcionamiento, junto con el establecimiento de la Unidad de Estudios
Bsicos, una segunda rea operativa en la sede del ncleo ubicada en la urbanizacin
Juanico de la ciudad de Maturn. Para el ao de 1990 se fusionaron las dos reas en su
actual infraestructura ubicada en el edificio Centro Comunal Estudiantil en el campus
Los Guaritos del ncleo en referencia.
13
En dicha infraestructura fsica, especficamente en el nivel planta baja del
mencionado edificio, se desarrollan las actividades operativas y de prestacin de
servicio, contando con el mobiliario, equipamiento, utensilios, instrumentos de cocina
y toda la amplia gama de alimentos, insumos y recursos requeridos para brindar el
servicio de alimentacin. Mientras que, en el primer piso del mismo edificio, se
encuentran las instalaciones desde las cuales el personal del comedor universitario
ejecuta todas las actividades necesarias para la administracin del servicio.
De acuerdo al manual de procedimientos y organizacin (1976), el comedor

universitario estar bajo la direccin de un Administrador, quien tendr a su cargo el
personal siguiente: un dietista, una secretaria, un cajero, un despensero o almacenista,
un jefe de cocina, y el personal necesario de cocineros, ayudantes de cocina y
aseadores de acuerdo a los turnos y al volumen de trabajo. Esto se puede apreciar en
el organigrama del Comedor de la Universidad de Oriente Ncleo de Monagas
(Figura 3, p.15).
14
Consejo de
Ncleo Decano
Coordinacin
Administrativa
Delegacin de
Finanzas
Administracin
del Comedor
Cajero Secretaria
Dietista Almacenista Jefe de Cocina Personal
Figura 3. Estructura Organizativa del Comedor de la UDO Ncleo Monagas.

Fuente: Archivo del comedor en estudio. (2008).
1.4.2 Actividades del Personal
Las actividades ejecutadas por el personal del comedor, en aras del

cumplimiento de las funciones son las siguientes:
Administrador del Comedor:
1. Dirigir, coordinar y supervisar todas las actividades del comedor y el trabajo

del personal a su cargo.
15
2. Velar por el buen funcionamiento del comedor y sugerir nuevos
procedimientos y normas de trabajo para un mejor desarrollo de las
actividades.
3. Instruir al personal a su cargo en la aplicacin de las disposiciones relativas al
trabajo que les concierne.
4. Llevar el control de compras de equipos y reparacin de los existentes.
5. Realizar todas las compras necesarias para el funcionamiento del comedor.
6. Revisar las facturas del comedor y solicitar su pago ante la Delegacin de
Finanzas.
7. Llevar el control presupuestario de su unidad.
8. Solucionar imprevistos producidos en el rea operativa.
9. Atender y solucionar los problemas y reclamos que se presenten.
10. Aprobar o modificar las minutas presentadas por el dietista en cuanto a la
calidad y cantidad.
11. Preparar anualmente el presupuesto de materiales, bienes y personal del
comedor a su cargo.
12. Elaborar las solicitudes de pago por reembolso de caja chica.
13. Maneja todo lo relacionado con la administracin de su personal.
Dietista:
1. Coordinar y supervisar las actividades del servicio a su cargo.

2. Elaborar listas de mens considerando las facilidades de adquisicin de los
alimentos y su valor nutritivo.
3. Controlar cantidad y calidad de los alimentos.
4. Colaborar con el Administrador en todo lo relacionado con su cargo.
5. Planificar los mens alimentarios ofrecidos diariamente, cumpliendo con los
requerimientos nutricionales preestablecidos.
6. Calcular las cantidades y costos de los mens, de acuerdo con la estimacin
del nmero de comensales.
16
7. Asesorar al jefe de cocina en cuanto al valor alimenticio de los materiales
usados.
8. Preparar una relacin semanal, quincenal o mensual, segn sea requerida por
el Administrador, de la cantidad y calidad de vveres necesarios para la
preparacin de las comidas
9. Relacionar las minutas y archivarlas siguiendo un orden establecido.
10. Colaborar con la administradora en todo lo relacionado con su cargo.
Secretaria:
1. Atender el telfono y los visitantes.

2. Mecanografiar las correspondencias, los informes y dems trabajos que se le
asignen.
3. Atender el archivo del comedor.
4. Las dems tareas normalmente a cargo de una secretaria.
Cajero:
1. Vender tickets durante el horario establecido para tal fin.

2. Elaborar una relacin de ingresos diarios.
3. Depositar diariamente el producto de las ventas.
4. Llevar el control y archivo provisional de las rdenes de comida.
Despensero o almacenista:
1. Recibir y revisar, en calidad y cantidad, los materiales que llegan al almacn.

2. Relacionar diariamente todas las entradas y salidas, especificando cantidad y
valor de los artculos.
3. Levantar un inventario peridico de las existencias del almacn.
17
4. Asesorar al administrador en materia de precios y calidad de los artculos,
proveedores, etc.
5. Entregar las minutas aprobadas al jefe de cocina al momento de solicitarlas.
Jefe de Cocina:
1. Aprobar o modificar, junto con el nutricionista los aspectos presentados en las

minutas en cuanto a la calidad, cantidad y mtodos de preparacin de los
alimentos.
2. Asignar tareas a los ayudantes de cocina.
3. Supervisar las tareas que deben cumplir los ayudantes de cocina.
4. Asesorar a los ayudantes de cocina en la preparacin de los alimentos y dems
actividades que le conciernan.
5. Asesorar al administrador en cuanto a calidad y cantidad en compras de
vveres.
6. Responder por los bienes entregados a su custodia y cuidado.
7. Responder, por la buena marcha de la cocina, preparacin de alimentos y
agilidad en el servicio prestado.
Ayudantes de cocina:
1. Cumplir las tareas asignadas por el supervisor de cocina.
18
CAPITULO II
EL PROBLEMA Y SUS GENERALIDADES
2.1 Planteamiento del Problema
En los ltimos aos, la informacin se ha convertido en uno de los principales

recursos con que cuentan las organizaciones, pues esta sirve de soporte o apoyo a las
actividades operativas de la empresa. De ella dependen muchas de las decisiones que
deben ser tomadas en el entorno empresarial, lo que permite tener bases ms
sustentables para determinar qu hacer y qu rumbo tomar para el logro de los
objetivos que se planearon.
Con el manejo de la informacin se puede alcanzar un alto nivel competitivo

dentro del mercado en el cual se desenvuelven las empresas y obtener mayores
niveles de capacidad de desarrollo. En consecuencia, la informacin pasa a hacer un
elemento de vital importancia para el funcionamiento de toda la organizacin, y el
buen manejo de esta puede significar la diferencia entre el xito o el fracaso de la
empresa.
Es por ello que hoy en da, las organizaciones para poder competir y no
quedarse en el pasado, deben poseer una fuerte infraestructura tecnolgica, en cuyo
centro se site la tecnologa de la informacin, que contribuyan a tomar decisiones
rpidas y a resolver los retos de la actualidad. Esto, con la ayuda de los sistemas
informticos, que servirn de herramienta til para el desarrollo, uso y administracin
de la mencionada tecnologa dentro de la organizacin.
Bajo este contexto, los sistemas y las tecnologas de informacin han cambia-
19
do la forma en que las organizaciones realizan sus operaciones. Pues a travs de su
uso se logran importantes mejoras, automatizan los procesos operativos, proporcionan
informacin que sirva de apoyo para la toma de decisiones, y su implantacin logra
ventajas competitivas frente a sus competidores.
En el caso de las universidades, el impacto de las tecnologas de informacin

y la comunicacin ha sido considerable ya que se han introducido cambios
significativos en su organizacin. Adems han venido emergiendo nuevas tecnologas
que constituyen un reto para los mtodos de enseanza y aprendizaje, la docencia e
investigacin, los medios de organizacin y el funcionamiento interno e, incluso, la
definicin misma de la universidad y del rol que esta desempea en la sociedad.
Ahora bien, los procesos de transformacin que viven actualmente las

instituciones universitarias y las organizaciones en general, tambin son
experimentados por las universidades venezolanas. Estas han venido adaptando e
incorporando dentro de su organizacin las tecnologas de informacin y actualizando
de manera creciente su plataforma tecnolgica para realizar de manera ms eficiente
y efectiva las actividades acadmico-administrativas y los procesos en general que
all se realicen, con el fin de lograr una prestacin de servicio de calidad que satisfaga
las necesidades de la comunidad.
Por su parte, la Universidad de Oriente como ente de educacin superior

encargado de formar profesionales de excelencia para cooperar con el desarrollo de la
sociedad venezolana, no escapa de este proceso de cambio que viven hoy en da las
organizaciones. Esto debido a que se ha venido modernizando su estructura
universitaria y los procesos generados en las diferentes reas y departamentos en las
que se encuentra estructurada, esto con el fin de ofrecer un excelente servicio a toda
la comunidad universitaria.
20
En la Universidad de Oriente Ncleo de Monagas se prestan una gran
variedad de servicios para satisfacer las necesidades de los estudiantes en el
transcurso de su proceso de formacin profesional y desarrollo personal. Dentro de
estos servicios se encuentra el ofrecido por el comedor universitario, que garantiza al
estudiante y a su organismo el aporte de los requerimientos nutricionales y
energticos diarios que propician un mejor rendimiento en el desempeo de sus
actividades acadmicas.
Este servicio de alimentacin constituye uno de los ms demandados por la

comunidad del ncleo, pues con este se benefician 4.000 estudiantes
aproximadamente, segn informacin suministrada por la administracin del comedor
universitario. Hay que tomar en cuenta, que la mayora de estos beneficiados
provienen de familias de bajos ingresos econmicos y/o residen en otras localidades
no pertenecientes a la ciudad de Maturn, los cuales acuden al comedor para reducir
en cierto modo los gastos universitarios y no incurrir en costos adicionales.
Considerando que al comedor universitario se le asignan los recursos

materiales, financieros y humanos necesarios para llevar a cabo la prestacin del
servicio, ste debe ser eficiente brindando una alimentacin sana, balanceada, variada
y atractiva para el comensal, con productos de calidad, con una excelente preparacin
y presentacin de los alimentos con las mejores condiciones higinicas, acorde al
presupuesto establecido.
Estos recursos asignados al comedor universitario, deben ser administrados

con la mxima eficacia y eficiencia posible para lograr una calidad en el servicio
ofrecido a los estudiantes y a eventos especiales, que requiera de la colaboracin del
comedor para la preparacin de las comidas que deben ser entregadas a los
participantes de dicho evento. Como se denota, este estudio de ingeniera est
orientado tanto a la poblacin estudiantil como al resto de la comunidad universitaria
21
en general, entre los cuales se encuentran: el personal obrero, administrativo, docente,
etc.
De acuerdo a lo expuesto anteriormente, el comedor para prestar el servicio

debe realizar la planificacin alimentaria de los mens que sern preparados. Para
esto, se estima el nmero de estudiantes que asistirn al comedor, y en base a esta
informacin se calculan las cantidades de insumos necesarias para la preparacin de
las comidas. A partir de ese momento, se elaboran los pedidos que deben entregarse a
los proveedores para la adquisicin de los mismos. Luego, de llevar a cabo los
aspectos anteriores, se debe controlar las existencias de insumos en almacn; para ello
se lleva un registro, tanto de los artculos adquiridos a travs de los pedidos realizados
a los proveedores como de su salida de la despensa para preparar el men del da. Por
ltimo, para justificar los gastos ante la universidad este realiza un anlisis de los
costos incurridos al prestarse dicho servicio.
Actualmente, la delegacin de comedor realiza la mayora de los procesos

antes mencionados de manera semi-manual, utilizando formatos llenados a travs de
una computadora (formatos para realizar reportes de costos por ejemplo), donde la
informacin es manejada en archivos de Microsoft Excel; aplicacin que a pesar de
ser muy potente y de tener mltiples ventajas, no es la apropiada para llevar a cabo
todos los procedimientos realizados en el rea de comedor. Pues, produce operaciones
tediosas y repetitivas, retardo en la generacin de informes y errores en los clculos,
por la manipulacin constante de las frmulas cada vez que estos se elaboran.
Corriendo adems el riesgo de que los datos y la informacin sean manipulados y
corrompidos.
Por otra parte, la administracin del comedor elabora la planificacin de los

mens alimentarios calculando, el nmero aproximado de estudiantes que acudirn al
comedor, apoyndose en la experiencia, en las circunstancias de cada da (por
ejemplo realizando el conteo manual de las bandejas de comidas utilizadas por los
22
estudiantes) y en las estadsticas del comedor. Esto ltimo, con la ayuda de una
pequea aplicacin en Microsoft Access, que se encarga de registrar el nmero de
comensales que asisten al lugar para aprovechar el servicio. Sin embargo, ste
funciona de manera aislada, al igual que la aplicacin mencionada anteriormente (La
hoja de Excel), sin que sea posible utilizar en red la informacin generada por l
mismo en el proceso de planificacin.
Por el contrario, el control del inventario de insumos se realiza sin utilizar una
herramienta informtica de apoyo. nicamente, se lleva un registro manual de las
entradas y salidas de los insumos, lo que pudiera ocasionar errores en los datos de las
existencias de los mismos en la bodega; esto debido a equivocaciones al momento de
asentar una cantidad especfica de insumos.
Hay que destacar en este apartado, que el comedor universitario realiza una
planificacin semanal de los insumos que se van a adquirir y depositar en la despensa
para su posterior utilizacin. De igual manera, los pedidos hechos a los proveedores
se hacen cada semana, debido principalmente a que el sitio de almacenamiento cuenta
con un espacio muy limitado, donde prcticamente slo pueden depositarse aquellos
insumos que son necesarios para preparar los mens alimentarios de los das
correspondientes a una semana. Adems, en el almacn la seguridad es precaria,
donde los insumos no pueden permanecer todo un fin de semana, debido a que se
veran expuestos a prdidas o extravi por personas ajenas a la institucin. Y aparte
de esto, existen insumos que son perecederos, es decir, que pueden deteriorarse en un
corto periodo de tiempo.
Por todo lo descrito anteriormente, surge la necesidad de desarrollar un

sistema para la automatizacin de los procesos de planificacin y control de los
insumos necesarios para prestar el servicio de alimentacin por el comedor
universitario de la Universidad de Oriente Ncleo de Monagas. Con el cual se pueda
realizar la programacin alimentaria de manera gil y ms aproximada a la realidad; y
23
que permita controlar los insumos adquiridos para asegurar el cumplimiento de lo
establecido en la planificacin.
2.2 Objetivos de la Investigacin
2.2.1 Objetivo General
Desarrollar un sistema Web para la planificacin y control del servicio de

alimentacin prestado por el comedor universitario de la Universidad de Oriente
Ncleo de Monagas.
2.2.2 Objetivos Especficos
1. Describir el funcionamiento actual de los procesos llevados a cabo dentro del

servicio de alimentacin prestado por la Universidad de Oriente Ncleo de
Monagas.
2. Determinar los problemas y necesidades actuales relacionados con la
planificacin y control del servicio prestado por el comedor universitario.
3. Definir los requerimientos de informacin del sistema, a travs del estudio
realizado al comedor universitario y considerando las necesidades de los
usuarios del rea administrativa del mismo.
4. Disear una arquitectura slida para el sistema, que cumpla con los
requerimientos definidos.
5. Construir un prototipo inicial, de acuerdo a la arquitectura diseada y a los
requisitos especificados del sistema.
2.3 Justificacin de la Investigacin
La necesidad de proponer el desarrollo de un sistema Web para la

planificacin y control del servicio prestado por el comedor universitario de la
Universidad de Oriente Ncleo de Monagas, traer consigo numerosos beneficios,
24
reflejados generalmente en el mejoramiento del servicio del comedor universitario
por la incorporacin de la tecnologa de informacin en esta rea, contribuyendo por
ende al avance tecnolgico de la institucin y al bienestar de la comunidad
universitaria que demanda dicho servicio. Entre otros beneficios, se podr realizar de
manera gil las actividades y procedimientos administrativos llevados a cabo por el
comedor universitario, permitiendo as la optimizacin de los mismos; lo que traer
consigo, una reduccin de tiempo y un control ms efectivo de los recursos
adquiridos para la prestacin del servicio de alimentacin.
Asimismo, con el desarrollo del sistema se podr llevar un mayor manejo y

control de la informacin, habiendo a su vez mejor disponibilidad de la misma para
los usuarios en tiempo real. Adems, se evitar la duplicidad y prdida de datos,
debido a que toda la informacin estar almacenada en una base de datos confiable,
que podr ser accedida en todo momento para recuperar y utilizar dicha informacin
en los diferentes procesos administrativos que lo requieran, sirviendo as de
herramienta til y fiable para la toma de decisiones.
Por su parte, con la automatizacin de los procesos relacionados con la

planificacin y control del servicio de alimentacin, se podr realizar la programacin
alimentaria de manera rpida y sencilla, pudiendo tambin elaborar los mens con su
respectiva informacin nutricional para cumplir con los requerimientos alimenticios
necesarios para el buen desempeo de la comunidad universitaria en sus actividades
diarias.
Adems, permitir controlar el acceso de los comensales al comedor para

tener un registro del nmero de personas atendidas, generando estadsticas que
puedan ser utilizadas por la administracin para realizar estimaciones ms certeras de
la cantidad de mens que se deben servir para satisfacer la demanda del servicio en
las prximas semanas. Lo que servir de ayuda para obtener una planificacin
alimentaria ms aproximada a la realidad.
25
Para determinar el estimado de personas que harn uso del servicio del
comedor en cada turno de la semana que se est planificando, se utilizar el modelo
de series de tiempo para pronstico de demanda, denominado promedio mvil. Este
mtodo, utilizar los datos histricos del nmero de comensales que asistieron al
comedor universitario en periodos anteriores para calcular la demanda promedio, y
obtener as el pronstico de la siguiente semana.
Por otro lado, el sistema contar con un mdulo que permitir controlar las
existencias de insumo en la despensa, llevando un registro constante de las unidades
entrantes y salientes del mismo; manteniendo as siempre actualizado el inventario
con informacin veraz y confiable de las cantidades de artculos existentes. Por lo
tanto, se podr corroborar en todo momento que estn siendo utilizados
correctamente los insumos de acuerdo a lo programado en la planificacin
alimentaria. Tambin, con el sistema se agilizar la generacin de reportes e informes
para mejorar la capacidad de respuesta ante las autoridades universitarias.
Con la futura implantacin y uso del sistema desarrollado se beneficiarn de

manera directa los estudiantes, obreros, personal administrativo y docente que hacen
uso del servicio de alimentacin. Pero principalmente aquellas personas que laboran
en el rea administrativa del comedor universitario, pues ellas sern las que
manejarn directamente el sistema, para as aprovechar al mximo las ventajas de
utilizar una tecnologa informtica en la optimizacin de sus actividades diarias.
Entre las ventajas que le puede brindar el sistema al personal administrativo

del comedor se pueden mencionar: disminucin de la carga de trabajo, ahorro
significativo de tiempo, celeridad en la elaboracin de informes o reportes para
garantizar la entrega a tiempo de los mismos. Igualmente, el sistema automatizado
ofrece la ventaja de suministrar informacin de calidad, puesto que minimiza la
posibilidad de cometer errores al momento de realizar clculos y operaciones.
26
Adems dicha aplicacin presenta una interfaz cmoda y sencilla para el usuario,
proporcionndole una interaccin amigable y facilitndole as su uso y aprendizaje.
El sistema Web para la planificacin y control del servicio de alimentacin

prestado por el comedor universitario del ncleo de Monagas, podr ser adaptado a
las necesidades de los otros ncleos de la Universidad de Oriente, puesto que para su
desarrollo se tomaron en consideracin un conjunto de normas y reglamentos que son
propias de la institucin y por las cuales deben regirse todos los comedores
universitarios de la UDO.
2.4 Alcance de la Investigacin
Con este proyecto de investigacin se pretende desarrollar un sistema

automatizado para la planificacin y el control de los insumos necesarios para prestar
el servicio de alimentacin por el comedor universitario de la Universidad de Oriente
Ncleo de Monagas. Para el desarrollo de dicho proyecto se emplearon las fases de
inicio, elaboracin y construccin de la metodologa de desarrollo de software RUP;
abarcando el anlisis y diseo de todo el sistema, y llevndose a cabo la construccin
de un prototipo inicial en el que se incluyeron los mdulos ms esenciales para el
funcionamiento del servicio del comedor universitario.
El sistema desarrollado, se caracteriza por ser una aplicacin bajo entorno

Web, donde las operaciones y los clculos son transparentes para el usuario, pudiendo
garantizar rapidez y confiabilidad en los datos generados, y la reduccin de errores.
Dicha aplicacin, podr ser utilizada por los usuarios, accediendo a un servidor a
travs de una red mediante un navegador Web (como Mozilla Firefox, Internet
Explorer, entre otros) que estar instalado en cada una de las computadoras clientes.
Bsicamente, para establecer la comunicacin, el cliente enviar una peticin al
servidor, y luego este efectuar un proceso y le responder con el contenido que le
solicit (devolviendo una pgina Web al cliente).
27
CAPITULO III
MARCO REFERENCIAL
3.1 Antecedentes de la Investigacin
Barrios, D. (2009). Modelo de sistema viable para el comedor de la Universidad de

Oriente Ncleo Monagas. Trabajo de grado presentado en la Universidad de Oriente
Ncleo de Monagas para optar al ttulo de Ingeniero de Sistemas. Este trabajo tuvo
como objetivo principal la aplicacin terica del Modelo de Sistema Viable a la realidad
del comedor de la Universidad de Oriente ncleo Monagas, permitiendo definir un
modelo organizacional con enfoque funcional para dicho comedor, el cual toma en
cuenta el entorno, visualizndolo hacia el logro de una organizacin que cumpla con
la adaptacin, regulacin y control necesarios en un entorno tan cambiante y
complejo. Este trabajo de grado est vinculado directamente con el rea objeto de
estudio de la presente investigacin, por lo que aport conocimientos sobre aspectos
importantes de la realidad del comedor universitario de la Universidad de Oriente
Ncleo de Monagas.
Briceo, G. (2008). Sistema automatizado para la gestin de los procesos

administrativos de la delegacin de planificacin de la Universidad de Oriente
Ncleo Monagas. Trabajo de grado realizado para obtener el ttulo de Ingeniero de
Sistemas en la Universidad de Oriente Ncleo de Monagas. Este consisti en el
desarrollo de un sistema automatizado para la gestin de los procesos de recepcin,
seguimiento y control de los proyectos que las dependencias del ncleo elaboran con
la finalidad de ser incluidos en el Plan Operativo Anual de la universidad. Tal
investigacin, sirvi de referencia para comprender el uso de la metodologa RUP en
28
el proceso de desarrollo de software, as como tambin la utilizacin de los diferentes
diagramas de la herramienta UML para el modelado de sistemas.
Fonseca, R. (2008). Sistema de Gestin en Ambiente Web para Salas Situacionales en

Instituciones Pblicas Adscritas a Entes Gubernamentales. Caso de Estudio: Centro
Internacional Miranda Caracas. Proyecto de Grado presentado ante la Universidad
Nacional Experimental del Tchira para optar al ttulo de Ingeniero en Informtica. El
propsito de esta investigacin fue desarrollar un sistema bajo entorno Web para
automatizar los procesos de manejo de los entornos de Actores (personal que labora
en el Centro Internacional Miranda Caracas o de la institucin donde se aplique),
medios de comunicacin social y consejos comunales; adems de generar una
herramienta de fcil uso para su personal y que permitiera brindar un mejor servicio a
los usuarios de cada entidad. Este trabajo sirvi de base para el estudio de la
metodologa de desarrollo de software RUP, y tambin como referencia para la
diagramacin con UML.
Rojas, J. (2005). Sistema de Informacin Web para la Gestin y Control de Contratos

e Inventario de la Direccin de Ingeniera y Mantenimiento de la Universidad de Los
Andes. Proyecto de Grado presentado ante la ilustre Universidad de Los Andes para
optar al ttulo de Ingeniero de Sistemas. Este trabajo tuvo la finalidad de desarrollar
un sistema de informacin para la automatizacin de los procesos de control de
inventario del almacn y de las obras contratadas realizadas por la Direccin de
Ingeniera y Mantenimiento de la ULA, de manera que se pudiera suministrar con el
menor retardo posible los materiales necesarios para la ejecucin de obras bajo su
cargo y vigilar el desempeo de los contratistas a cargo de tales obras. Dicha
investigacin, contribuy a comprender el desarrollo de un software aplicando la
metodologa RUP, conjuntamente con la herramienta UML.
29
3.2 Bases Tericas
3.2.1 Metodologa RUP
La metodologa RUP, llamada as por sus siglas en ingls Rational Unified

Process, es un proceso para llevar a cabo el desarrollo de un software, la cual define
quien, como, cuando y que debe hacerse en el proyecto. Su propsito es asegurar la
produccin de software de alta calidad que satisfaga las necesidades de los usuarios
finales, ajustndose a un presupuesto y tiempo establecidos.
Jacobson, Booch y Rumbaug (2000) establecen que un proceso de desarrollo

de software:
Es el conjunto de actividades necesarias para transformar los requisitos de un

usuario en un sistema software. Sin embargo, el Proceso Unificado es ms que
un simple proceso; es un marco de trabajo genrico que puede especializarse
para una gran variedad de sistemas de software, para diferentes reas de
aplicacin, diferentes tipos de organizaciones, diferentes niveles de aptitud y
diferentes tamaos de proyectos.(p.04)
El proceso unificado de desarrollo es el resultado de ms de 30 aos de

experiencia, con la unificacin de tcnicas de desarrollo y del trabajo de muchos
metodologstas. El antecedente ms importante de esta metodologa se ubica en 1967
con la Metodologa Ericsson (Ericsson Approach) elaborada por Ivar Jacobson, que
fue una aproximacin de desarrollo basada en componentes, y que introdujo el
concepto de Caso de Uso. Entre los aos de 1987 a 1995 Jacobson fund la compaa
Objectory AB y lanza el proceso de desarrollo Objectory (abreviacin de Object
Factory).
Posteriormente en 1995 Rational Software Corporation adquiere Objectory

AB y entre 1995 y 1997 se desarrolla Rational Objectory Process (ROP) fruto del
encuentro y fusin de Objectory 3.8 y del Enfoque Rational (Rational Approach)
30
adoptando UML como lenguaje de modelado. Desde ese entonces y a la cabeza de
Ivar Jacobson, Grady Booch, y James Rumbaugh, Rational Software desarroll e
incorpor diversos elementos para expandir ROP, destacndose especialmente el
flujo de trabajo conocido como modelado del negocio. Es as como en junio del 1998
se lanza Rational Unified Process.
RUP proporciona un enfoque disciplinado para asignar tareas y

responsabilidades dentro de una organizacin del desarrollo, e intenta integrar todos
los aspectos que deben tenerse en cuenta durante todo el ciclo de vida del software,
con el fin de que pueda ser aplicable tanto en pequeos como en grandes proyectos de
software.
Esta metodologa de desarrollo tambin ofrece una forma coordinada de

trabajar; proporciona una gua para ordenar las actividades que deben realizar el
equipo de proyecto, dirige las tareas de cada desarrollador por separado y del equipo
como un todo, especifica los artefactos que deben desarrollarse y ofrece criterios para
el control y la medicin de los productos y actividades del proyecto.
Adicionalmente, el Proceso Unificado describe los diversos pasos

involucrados en la captura de los requerimientos y en el establecimiento de una gua
arquitectnica, para disear y probar el sistema de acuerdo a los requerimientos y a la
arquitectura realizada del mismo. Adems, provee patrones, y describe qu
entregables producir y cmo desarrollarlos. RUP es soportado por herramientas que
automatizan entre otras cosas, el modelado visual, la administracin de cambios y las
pruebas.
3.2.1.1 Caractersticas principales de RUP
Las caractersticas esenciales de RUP son las siguientes:
31
a) Proceso dirigido por casos de usos
Los casos de uso son una tcnica de captura de requisitos potenciales de un

nuevo sistema o la actualizacin de un software ya existente. Cada caso de uso
proporciona uno o ms escenarios que indican cmo debera interactuar el sistema
con el usuario o con otro sistema para conseguir un objetivo especfico. En otras
palabras, un caso de uso es una secuencia de interacciones que se desarrollarn entre
un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre
el propio sistema.
Segn Jacobson, Booch y Rumbaug (2000):
Los casos de uso son fragmentos de funcionalidad que el sistema ofrece para
aportar un resultado de valor para sus actores. De manera ms precisa, un caso
de uso especifica una secuencia de acciones que el sistema puede llevar a cabo
interactuando con sus actores, incluyendo alternativas dentro de la secuencia.
(p.129)
En RUP los Casos de Uso no son slo una herramienta para especificar los
requisitos funcionales del sistema. Tambin guan su diseo, implementacin y
prueba, es decir, guan el proceso de desarrollo del sistema. Por lo tanto dirigido por
casos de uso significa que el proceso de desarrollo sigue un hilo conductor que
permite establecer trazabilidad entre los artefactos que son generados en las diferentes
actividades de dicho proceso.
32
Figura 4. Los casos de uso integran el trabajo.
Fuente: Autor (2009)
Como se muestra en la Figura 4, los casos de uso actan como un elemento

integrador y guan el trabajo realizado durante el proceso de desarrollo. Pues, en base
a estos, se crean los modelos de anlisis y diseo; luego la implementacin los lleva a
cabo, y por ltimo, se verifica que efectivamente el producto implemente
adecuadamente cada caso de uso.
b) Proceso centrado en la arquitectura
El papel de la arquitectura software es similar al papel que juega la

arquitectura en la construccin de edificios. El edificio se mira desde diferentes
puntos de vista: estructura, servicios, plomera, electricidad, etc. Esto permite al
constructor ver una imagen completa antes de que comience la construccin.
Similarmente, la arquitectura en un sistema software se describe mediante diferentes
vistas del sistema en construccin.
La arquitectura de un sistema es la organizacin o estructura de sus partes ms

relevantes, que permite tener una visin comn entre todos los involucrados
(desarrolladores y usuarios) y una perspectiva clara del sistema completo, necesaria
para controlar el desarrollo.
33
La metodologa RUP adems de utilizar los casos de uso para guiar el
proceso, presta especial atencin al establecimiento temprano de una buena
arquitectura que no se vea fuertemente impactada ante cambios posteriores durante la
construccin y el mantenimiento. RUP asume que no existe un modelo nico que
cubra todos los aspectos del sistema. Por tal motivo existen mltiples modelos y
vistas que definen la arquitectura de software de un sistema.
La arquitectura involucra los aspectos estticos y dinmicos ms significativos

del sistema. Esta surge de las necesidades de la empresa, como las perciben los
usuarios y los inversores, y se refleja en los casos de uso. Sin embargo, tambin est
influenciada por muchos otros factores, tales como la plataforma en la que tiene que
funcionar el software (arquitectura hardware, sistema operativo, sistema de gestin de
base de datos, protocolo para comunicaciones en red), la disponibilidad de
componentes reutilizables, consideraciones de instalacin, sistemas heredados y
requisitos no funcionales (por ejemplo rendimiento y confiabilidad).
Cada producto software tiene una funcin y una forma. La funcin

corresponde a los casos de uso y la forma a la arquitectura. Existe una interaccin
entre los casos de uso y la arquitectura; los casos de uso deben encajar en la
arquitectura cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de
todos los casos de uso requeridos, actualmente y en el futuro. Esto provoca que tanto
la arquitectura como los casos de uso deban evolucionar en paralelo durante todo el
proceso de desarrollo de software.
En la Figura 5, p.35 se ilustra la evolucin de la arquitectura durante las fases

de RUP. En las fases iniciales lo que se hace es ir consolidando la arquitectura por
medio de baselines e ir modificndola dependiendo de las necesidades del proyecto.
En las fases finales lo que se tiene es una arquitectura ms robusta del sistema.
34
Figura 5. Evolucin de la arquitectura del sistema.
Fuente: (https://pid.dsic.upv.es)
c) Proceso iterativo e incremental
El desarrollo de un producto software supone un gran esfuerzo que puede

durar desde varios meses hasta ms de un ao. Por lo tanto, una solucin prctica para
esto, es tener un proceso iterativo e incremental, en donde el trabajo se divida en
partes ms pequeas o mini proyectos. Cada mini proyecto se puede ver como una
iteracin (un recorrido ms o menos completo a lo largo de todos los flujos de trabajo
fundamentales) del cual se obtiene un incremento que produce un crecimiento en el
producto.
Igualmente, RUP lleva a cabo el desarrollo de un proyecto de software a

travs de un proceso iterativo e incremental. En el cual se plantea la implementacin
del proyecto a realizar en Iteraciones, con lo cual se pueden definir objetivos por
cumplir en cada iteracin y as poder ir completando todo el proyecto iteracin por
iteracin; con lo cual se tienen varias ventajas, entre ellas se puede mencionar la de
tener pequeos avances del proyecto, que son entregables al cliente el cual podra
probar mientras se est desarrollando otra iteracin del proyecto, con lo cual el
proyecto va creciendo hasta completarlo en su totalidad.
Ahora bien, se puede observar en la Figura 6, p.36 que una iteracin puede
realizarse por medio de una cascada, pasando por los flujos fundamentales
(Requisitos, Anlisis, Diseo, Implementacin y Pruebas), tambin existe una
35
planificacin de la iteracin, un anlisis de la iteracin y algunas actividades
especficas de la iteracin. Al finalizar se realiza una integracin de los resultados con
lo obtenido de las iteraciones anteriores.
Figura 6. Una iteracin RUP.

Fuente: (https://pid.dsic.upv.es)
Como se mencion anteriormente un proceso iterativo e incremental consta de

una secuencia de iteraciones. Cada iteracin aborda una parte de la funcionalidad
total, pasando por todos los flujos de trabajo relevantes y refinando la arquitectura. Al
finalizar cada iteracin, esta se analiza; tambin se puede determinar si han aparecido
nuevos requisitos o han cambiado los existentes, afectando a las iteraciones
siguientes. Durante la planificacin de la siguiente iteracin, el equipo tambin
examina cmo afectarn los riesgos que an quedan al trabajo en curso. Toda la
retroalimentacin de la iteracin pasada permite reajustar los objetivos para las
siguientes iteraciones. Se contina con esta dinmica hasta finalizar por completo con
la versin actual del producto.
3.2.1.2 Estructura de RUP
La estructura de RUP puede ser descrita a travs de dos dimensiones o ejes:
36
1. Eje horizontal: Representa el tiempo y es considerado el eje de los aspectos
dinmicos del proceso. Esta dimensin muestra las caractersticas del ciclo de
vida del proceso, expresado en trminos de fases, iteraciones e hitos.
2. Eje vertical: Representa los aspectos estticos del proceso. Esta dimensin
describe el proceso en trminos de componentes de proceso, disciplinas, flujos
de trabajo, actividades, artefactos y roles.
Figura 7. Estructura de RUP.

Fuente: Rueda, J. (2006).
En la Figura 7 se puede apreciar la estructura de RUP, tanto la parte dinmica

como esttica. A continuacin, se detalla cada una de ellas:
a) Estructura Dinmica de RUP
RUP se repite a lo largo de una serie de ciclos que constituyen la vida de un

sistema, como se muestra en la Figura 8, p.38. Cada ciclo concluye con una versin
del producto para los clientes. Cada ciclo consta de cuatro fases: Inicio, Elaboracin,
37
Construccin y Transicin. Cada fase se subdivide a la vez en iteraciones, el nmero
de iteraciones en cada fase es variable.
Figura 8. La vida de un proceso conformado por ciclos

Fuente: Jacobson, I., Booch, G. y Rumbaug, J. (2000).
La duracin y esfuerzo dedicado en cada fase es variable dependiendo de las

caractersticas del proyecto. Cada fase se termina con un hito bien definido (un punto
en el tiempo en el cual se deben tomar ciertas decisiones crticas y alcanzar las metas
clave antes de pasar a la siguiente fase). Los hitos para cada una de las fases se
muestran en la Figura 9.
Figura 9. Fases e hitos en RUP.

Fuente: (https://pid.dsic.upv.es).
Como se mencion anteriormente la metodologa RUP divide el proceso de

desarrollo de software en cuatro (4) fases:
38
1. Fase de Inicio
En esta fase se define el modelo del negocio y el alcance del proyecto. Permite
establecer una visin sobre el lmite del sistema, el costo en recursos y tiempo.
Tambin, se evala la viabilidad del proyecto, sobre todo cuando est en juego una
gran inversin de recursos; se estiman los riesgos asociados al proyecto y se
identifican los casos de uso crticos del sistema y los escenarios bsicos que definen
la funcionalidad del sistema.
En esta fase inicial la actividad se concentra en los flujos trabajo de modelado

del negocio y de requisitos, realizndose poco trabajo en los flujos de trabajo de
anlisis y de diseo. Esta fase raramente realiza trabajo en los flujos de trabajo de
implementacin y de prueba.
2. Fase de Elaboracin
En esta fase se estudia a profundidad tanto la funcionalidad como el dominio

del problema, se construye un prototipo de la arquitectura y se eliminan los mayores
riesgos para lograr una culminacin exitosa. El prototipo de la arquitectura, debe
evolucionar en iteraciones sucesivas hasta convertirse en el sistema final. Este
prototipo debe contener los casos de uso crticos identificados en la fase de inicio.
Tambin debe demostrarse que se han evitado los riesgos ms graves. Con esta fase
se busca definir, validar y cimentar la arquitectura, completar la visin y crear un plan
fiable el cual puede variar con las iteraciones.
En la fase de elaboracin, mientras continua una cierta actividad dedicada a

completar los requisitos, los flujos de trabajo de anlisis y de diseo reciben una gran
parte de la actividad, ya que son la base de la creacin de la arquitectura. Para
alcanzar la arquitectura base slida hay alguna actividad en los ltimos flujos de
trabajo (implementacin y pruebas).
39
3. Fase de Construccin
Lo que se busca en esta fase, es alcanzar la capacidad operacional del

producto de forma incremental a travs de sucesivas iteraciones. Durante esta fase se
debe describir los requisitos restantes, refinar el diseo, e implementar, integrar y
probar en su totalidad, todos los componentes, caractersticas y requisitos, obteniendo
una versin aceptable del producto. En esta fase, por tanto, los distintos modelos del
sistema van creciendo hasta completarse. La descripcin de la arquitectura, sin
embargo, no crece significativamente debido a que la mayor parte de esta arquitectura
se defini durante la fase de elaboracin.
El propsito primordial de esta fase es dejar listo un producto software en su

versin inicial, a veces llamada versin beta. El producto debera tener la
calidad adecuada para su aplicacin y asegurarse de cumplir los requisitos. La
construccin debera tener lugar dentro de los lmites del plan de negocio.
(Jacobson, Booch y Rumbaug, 2000, p. 367).
En la fase de construccin el flujo de trabajo de los requisitos disminuye, el

anlisis se aligera y los flujos de trabajo de diseo, de implementacin y de pruebas
representan el grueso de la actividad.
4. Fase de Transicin
La finalidad de esta fase es poner el producto en manos de los usuarios finales,

y entrenarlos en el manejo del mismo, y en general realizar tareas relacionadas con el
ajuste, configuracin, instalacin y facilidad de uso del producto.
Una vez que el sistema se ha puesto en manos de los usuarios finales, a

menudo aparecen cuestiones que requieren un desarrollo adicional para ajustar el
sistema, corregir algunos problemas no detectados o finalizar algunas caractersticas
que haban sido propuestas. Esta fase comienza normalmente con una versin beta del
sistema, que luego ser reemplazada por la versin definitiva del producto.
40
En esta fase de transicin la actividad de los distintos flujos de trabajo
depende de los resultados de las pruebas de aceptacin y de las versiones beta del
sistema. Por ejemplo, si las pruebas de las versiones beta descubren algn defecto en
la implementacin habr una actividad considerable en los flujos de implementacin
y prueba.
b) Estructura Esttica de RUP
Est representada por cuatro elementos, que responden a las preguntas

Quin?, Cmo?, Qu? y Cundo? definidas en un proceso de desarrollo de
software: los roles, responden a la pregunta Quin?, las actividades responden a la
pregunta Cmo?, los productos, responden a la pregunta Qu? y los flujos de
trabajo de las disciplinas responde a la pregunta Cundo? En la Figura 10 se
muestran algunos elementos de la estructura esttica de RUP.
Figura 10. Relacin entre roles, actividades, artefactos.

Fuente: (https://pid.dsic.upv.es).
41
1. Roles
Un rol define el comportamiento y responsabilidades de un individuo, o de un

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

actividades como el ser el dueo de un conjunto de artefactos. RUP define grupos de
roles, agrupados por participacin en actividades relacionadas.
2. Actividades
Una actividad en concreto es una unidad de trabajo que se le asigna a una

persona que desempea un rol. Las actividades tienen un objetivo concreto,
normalmente expresado en trminos de crear o actualizar algn producto, tales como
un modelo, una clase, un cdigo fuente o un plan.
3. Artefactos
Los productos o artefactos son los resultados tangibles del proyecto, las cosas
que se van creando, modificando y usando hasta obtener el producto final durante el
proceso de desarrollo de software. Son las entradas y salidas de las actividades,
realizadas por las personas que desempean roles, las cuales utilizan y van
produciendo estos artefactos para tener guas.
Un artefacto puede ser cualquiera de los siguientes:
- Un documento, como el documento de la arquitectura del software.

- Un modelo, como el modelo de Casos de Uso o el modelo de diseo.
42
- Un elemento del modelo, un elemento que pertenece a un modelo como una
clase, un Caso de Uso o un subsistema.
De acuerdo a la filosofa de RUP (y de todo proceso iterativo e incremental),

todos los artefactos son objeto de modificaciones a lo largo del proceso de desarrollo,
con lo cual, slo al trmino del proceso se podra tener una versin definitiva y
completa de cada uno de ellos. Sin embargo, el resultado de cada iteracin y los hitos
del proyecto estn enfocados a conseguir un cierto grado de completitud y estabilidad
de los artefactos.
4. Flujos de trabajo (Disciplinas)
Con simplemente la enumeracin de roles, actividades y artefactos no se

define un proceso, se necesita contar con una secuencia de actividades realizadas por
los diferentes roles, as como la relacin entre los mismos. Un flujo de trabajo es una
relacin de actividades que producen unos resultados observables.
Las disciplinas conllevan los flujos de trabajo, los cuales son una secuencia de
pasos para la culminacin de cada disciplina, estas disciplinas se dividen en dos
grupos, como se apreci en la Figura 7, p.37: las de proceso, y las de apoyo. Las de
proceso son las necesarias para la realizacin de un proyecto de software; entre ellas
se tienen: modelado del negocio, requerimientos, anlisis y diseo, implementacin,
pruebas y despliegue. Las de apoyo son las que como su nombre lo indica sirven de
apoyo a las de proceso y especifican otras caractersticas en la realizacin de un
proyecto de software; entre estas se tienen: entorno, gestin del proyecto, gestin de
configuracin y cambios.
3.2.2 Lenguaje Unificado de Modelado
El Lenguaje Unificado de Modelado (UML, por sus siglas en ingls, Unified

Modeling Language) es el lenguaje de modelado de sistemas de software ms
43
conocido y utilizado en la actualidad; est respaldado por el OMG (Object
Management Group). Este lenguaje se ha convertido en un estndar, debido a que ha
sido impulsado por los autores de los tres mtodos ms usados de orientacin a
objetos: Grady Booch, Ivar Jacobson y Jim Rumbaugh.
Jacobson, Booch y Rumbaugh (2000), expresa respecto a esta herramienta lo

siguiente:
El UML es un lenguaje estndar para el modelado de software - lenguaje para

visualizar, especificar, construir y documentar los artefactos de un sistema con
gran cantidad de software. Lenguaje utilizado por el Proceso Unificado.
Lenguaje que permite a los desarrolladores visualizar el producto de su trabajo
(artefactos) en esquemas o diagramas estandarizados. (p. 430)
UML es un lenguaje porque proporciona un vocabulario y las reglas para

utilizarlo; adems, es un lenguaje de modelado lo que significa que el vocabulario y
las reglas del que est compuesto se utilizan para la representacin conceptual y fsica
del sistema. Es decir ofrece una notacin estndar y semnticas esenciales para
describir un modelo o plano del sistema, incluyendo aspectos conceptuales tales
como procesos de negocios y funciones del sistema, y aspectos concretos como
expresiones de lenguajes de programacin, esquemas de bases de datos y
componentes de software reutilizables.
Este lenguaje comenz a gestarse en el ao de 1994, cuando Rumbaugh se

uni a la compaa Rational fundada por Booch (dos reputados investigadores en el
rea de la metodologa del software). El objetivo de ambos era unificar dos mtodos
que haban desarrollado: el mtodo Booch y el OMT (Object Modelling Tool),
obteniendo como resultado una primera propuesta en 1995. En esa misma poca otro
reputado investigador, Jacobson, se uni a Racional, y se incluyeron ideas suyas.
Estas tres personas son conocidas como los tres amigos. Su trabajo conjunto fue
llamado Lenguaje Unificado de Modelado (UML). Adems, este lenguaje se abri a
la colaboracin de otras empresas para que aportaran sus ideas.
44
Todas estas colaboraciones condujeron a la definicin de la primera versin de
UML. Esta primera versin se ofreci a la OMG para convertirlo en un estndar. Este
grupo, llamado OMG, que gestiona estndares relacionados con la tecnologa
orientada a objetos (metodologas, bases de datos objetuales, CORBA, etc.), propuso
una serie de modificaciones y una nueva versin de UML (la 1.1), que fue adoptada
por el OMG como estndar en noviembre de 1997. Desde ese entonces, UML
atraves varias revisiones y refinamientos hasta llegar a la versin actual: UML 2.0.
Las funciones del UML son:
- Visualizar: UML permite expresar de una forma grfica un sistema de

manera que otro lo pueda entender.
- Especificar: UML permite especificar cules son las caractersticas de un
sistema antes de su construccin.
- Construir: A partir de los modelos especificados se pueden construir los
sistemas diseados.
- Documentar: Los propios elementos grficos sirven como documentacin del
sistema desarrollado que pueden servir para su futura revisin.
UML puede usarse para modelar desde sistemas de informacin hasta

aplicaciones distribuidas basadas en Web, pasando por sistemas empotrados de
tiempo real. Sin embargo, UML es solamente un lenguaje por lo que es slo una parte
de un mtodo de desarrollo software, es independiente del proceso aunque para que
sea optimo debe usarse en un proceso dirigido por casos de uso, centrado en la
arquitectura, iterativo e incremental, como lo es RUP.
Por otro lado esta herramienta provee beneficios significativos para los
ingenieros de software y las organizaciones al ayudarles a construir modelos
rigurosos, trazables y mantenibles, que soporten el ciclo de vida de desarrollo de
45
software completo. Este les permite capturar sus ideas en una forma convencional y
fcil de comprender para comunicarlas a otras personas.
Cabe agregar que UML capta la informacin sobre la estructura esttica y el

comportamiento dinmico de un sistema. La estructura esttica define los tipos de
objetos importantes para un sistema y su implementacin, as como las relaciones
entre los objetos. El comportamiento dinmico define la historia de los objetos en el
tiempo y la comunicacin entre ellos para cumplir sus objetivos. El modelar un
sistema desde varios puntos de vista, separados pero relacionados, permite entenderlo
para diferentes propsitos.
3.2.2.1 Estructura de UML
Para conocer la estructura de UML, en la Figura 11 se muestra una vista

general de todos sus componentes:
Figura 11. Vista general de los elementos de UML

Fuente: (http://monjes.org/tutoriales-y-manuales/3069-diseno-orientado-objetos-con-uml-
raul-alarcon-grupo-eidos.html)
46
Como se puede apreciar, el lenguaje UML se compone de tres elementos
principales, los bloques bsicos de construccin, las reglas de combinacin de los
bloques bsicos y algunos mecanismos comunes.
1. Bloques de construccin
Los bloques de construccin se dividen en tres partes: elementos, relaciones y

diagramas. Los elementos son abstracciones de cosas reales o ficticias (objetos,
acciones, etc.), las relaciones relacionan los elementos entre s, y los diagramas son
agrupaciones de elementos con sus relaciones.
a) Elementos
Existen cuatro tipos de elementos en UML, dependiendo del uso que se haga
de ellos: elementos estructurales (Casos de uso, clases, clases activas, interfaces,
componentes, colaboraciones y nodos), elementos de comportamiento (interacciones
y mquinas de estado), elementos de agrupacin (paquetes) y elementos de anotacin
(notas).
b) Relaciones
Para construir un plano de software que tenga sentido, lo que se hace es

combinar los elementos estructurales con sus respectivas relaciones, segn sea el
caso, obteniendo como resultado uno de los diagramas que existen en UML.
Existen cuatro tipos de relaciones entre los elementos de un modelo UML:

dependencia, asociacin, generalizacin y realizacin; estas se describen a
continuacin:
47
Dependencia
Es una relacin semntica entre dos elementos, en la cual un cambio a un

elemento (el elemento independiente) puede afectar a la semntica del otro elemento
(el dependiente). Las dependencias generalmente representan relaciones de uso que
declara que un cambio en la especificacin de un elemento puede afectar a otro
elemento que la utiliza, pero no necesariamente a la inversa. La mayora de las veces
se utilizan en el contexto de las clases o paquetes, aunque tambin son habituales en
la vinculacin de notas.
Figura 12. Representacin de una dependencia.

Asociacin
Es una relacin estructural que describe un conjunto de enlaces, los cuales son
conexiones entre objetos. La agregacin es un tipo especial de asociacin y representa
una relacin estructural entre un todo y sus partes. La asociacin se representa con
una lnea continua, posiblemente dirigida, que a veces incluye una etiqueta. A
menudo se incluyen otros adornos para indicar la multiplicidad y roles de los objetos
involucrados, como se puede observar en la Figura 13.
Figura 13. Representacin de una asociacin.

48
Generalizacin
Es una relacin de especializacin/generalizacin en la cual los objetos del

elemento especializado (el hijo) pueden sustituir a los objetos del elemento general
(el padre). De esta forma, el hijo comparte la estructura y el comportamiento del
padre. Grficamente, la generalizacin se representa con una lnea con punta de
flecha vaca (Figura 14).
Figura 14. Representacin de una generalizacin.

Realizacin
Es una relacin semntica entre clasificadores, en la que un clasificador

especifica un contrato que otro clasificador garantiza llevar a cabo. Se pueden
encontrar relaciones de realizacin en dos sitios: entre interfaces y las clases y
componentes que las realizan, y entre los casos de uso y las colaboraciones que los
realizan. La realizacin se representa como una mezcla entre la generalizacin
(Figura 14) y la dependencia (Figura 12, p.48), esto es, una lnea discontinua con una
punta de flecha vaca (Figura 15).
Figura 15. Representacin de una generalizacin

49
c) Diagramas
Un diagrama es la representacin grfica de un conjunto de elementos con sus

relaciones. En concreto, un diagrama ofrece una vista del sistema a modelar. Para
poder representar correctamente un sistema, UML ofrece una amplia variedad de
diagramas para visualizar el sistema desde varias perspectivas. En la seccin 3.2.2.2
se detallan algunos de los diagramas UML que se utilizan ms comnmente.
2. Reglas
Los bloques de construccin de UML no pueden combinarse de cualquier

manera. Como cualquier lenguaje, UML tiene un conjunto de reglas que dictan las
pautas a la hora de realizar asociaciones entre objetos para poder obtener modelos
bien formados. Un modelo bien formado es aquel que es semnticamente auto
consistente y est en armona con todos sus modelos relacionados.
UML tiene reglas semnticas para:
Nombres: Cmo llamar a los elementos, relaciones y diagramas.

Alcance: El contexto que da significado especfico a un nombre.
Visibilidad: Cmo se pueden ver y utilizar esos nombres por otros.
Integridad: Cmo se relacionan apropiada y consistentemente unos elementos con
otros.
Ejecucin: Qu significa ejecutar o simular un modelo dinmico.
3. Mecanismos comunes
UML proporciona una serie de mecanismos comunes que sirven para que cada
persona o entidad adapte el lenguaje a sus necesidades, pero dentro de un marco
ordenado y siguiendo ciertas reglas para que en el trasfondo de la adaptacin no se
pierda la semntica propia de UML.
50
Existen cuatro mecanismos comunes que se aplican de forma consistente a
travs de todo el lenguaje:
Especificaciones
Proporcionan la explicacin textual de la sintaxis y semntica de los bloques

de construccin. Por ejemplo, detrs del smbolo o icono de una clase hay una
especificacin que proporciona informacin de sus atributos, operaciones, signaturas
y comportamiento de la clase (visualmente el icono de la clase puede mostrar slo
parte de la especificacin). La notacin grfica de UML se utiliza para visualizar el
sistema, la especificacin se utiliza para enunciar los detalles de dicho sistema.
Adornos
La mayora de los elementos UML tienen una nica y clara notacin grfica
que proporciona una representacin visual de los aspectos ms importantes del
elemento. Pero la especificacin puede incluir otros detalles algunos de los cuales se
pueden incluir como adornos grficos en la notacin base. Los adornos son elementos
secundarios ya que proporcionan ms nivel de detalle, que quiz en un primer
momento no sea conveniente descubrir. Por ejemplo se pueden incluir adornos en el
icono de una clase indicando la visibilidad de las operaciones.
Divisiones comunes
Permiten que los modelos se dividan al menos en un par de formas diferentes

para facilitar la comprensin desde distintos puntos de vista, en primer lugar se tiene
la divisin entre clase y objeto (clase es una abstraccin y objeto es una
manifestacin de esa abstraccin), en segundo lugar se tiene la divisin interfaz /
implementacin donde la interfaz presenta un contrato (algo que se va a cumplir de
51
una determinada manera) mientras que la implementacin es la manera en que se
cumple dicho contrato.
Mecanismos de extensibilidad
UML proporciona un lenguaje estndar para escribir planos software, pero no

es posible que un lenguaje cerrado sea siempre suficiente para expresar todos los
matices posibles de todos los modelos en todos los dominios y en todos los
momentos. Por esta razn UML es abierto-cerrado, siendo posible extender el
lenguaje de manera controlada.
UML proporciona mecanismos de extensibilidad, los cuales permiten a sus

usuarios refinar su sintaxis y su semntica. Esta herramienta, por lo tanto, puede
ajustarse a un sistema, proyecto o proceso de desarrollo especfico si es
necesario. Los mecanismos de extensibilidad, incluyen estereotipos, valores
etiquetados y restricciones. Los estereotipos proporcionan una forma de definir
nuevos elementos extendiendo y refinando la semntica de elementos como
elementos y relaciones ya existentes. Los valores etiquetados proporcionan una
forma de definir nuevas propiedades de elementos ya existentes. Finalmente, las
restricciones proporcionan una forma de imponer reglas (como reglas de
consistencia o reglas de negocio) sobre elementos y sus propiedades. (Jacobson,
Booch y Rumbaugh, 2000, p. 408)
3.2.2.2 Vistas en UML
Las vistas muestran diferentes aspectos del sistema modelado. Cada vista es
una abstraccin que consiste en un nmero de diagramas; y todos esos diagramas
juntos muestran una "fotografa" completa del sistema.
Los diagramas son de gran utilidad para trabajar en los requisitos, en el

anlisis del sistema, en la construccin del mismo y en su posterior implementacin.
Permiten determinar la arquitectura del sistema, la cual es el resultado de agrupar los
diferentes diagramas en las ya mencionadas vistas. Las diferentes vistas que UML
tiene se muestran en la Figura 16.
52
Figura 16. Arquitectura de un sistema software (UML 2.0).
Fuente: (http://www.que-informatica.com/index.php/software/uml-lenguaje-unificado-de-
modelado/)
Cada una de las vistas resalta aspectos especficos del sistema. La vista de
Casos de uso provee informacin sobre el comportamiento y funcionalidad del
sistema. La vista de diseo: proporciona informacin del vocabulario y la
funcionalidad del sistema. Por otro lado la vista de interaccin: muestra informacin
sobre el rendimiento del sistema, la escalabilidad del mismo y la capacidad de
procesamiento necesaria. La vista de implementacin establece el ensamblado del
sistema y la gestin de la configuracin. Y por ltimo, la vista de despliegue permite
establecer la topologa del sistema, su distribucin y las pautas para su instalacin.
1. Diagramas de UML
En la versin 2.0 de UML existen 13 tipos diferentes de diagramas. La Figura

17, p.54 muestra una clasificacin de los distintos tipos de diagramas.
53
Figura 17. Clasificacin de diagramas UML.
Fuente: (http://www.que-informatica.com/index.php/software/uml-lenguaje-unificado-de-
modelado/)
a) Diagramas Estructurales
Estos diagramas enfatizan en los elementos que deben existir en el sistema

modelado.
a.1) Diagrama de Clases
Un diagrama de clases muestra el conjunto de clases que participan o forman

parte de un sistema, junto con las relaciones que existen entre dichas clases. Muestra
de una manera esttica la estructura de la informacin que maneja el sistema y la
visibilidad que tiene cada una de las clases, dada por sus relaciones con los dems en
el modelo
54
Un diagrama de clases est compuesto por clases y relaciones. En el lenguaje
UML, se define una clase como un conjunto de objetos que tiene un nombre
especfico, atributos y operaciones. Una clase se representa por un rectngulo en el
cual se inscriben tres secciones: en la seccin superior se coloca el nombre de la
clase; en la intermedia, se presentan los atributos que caracterizan a la clase y en la
seccin inferior se listan sus mtodos u operaciones. En la Figura 18 se muestra un
ejemplo de representacin de una clase.
Figura 18. Representacin de una clase.

Los atributos o caractersticas de una Clase pueden ser de tres tipos, los que
definen el grado de comunicacin y visibilidad de ellos con el entorno, estos son:
Privado (-): Indica que el atributo slo ser accesible desde dentro de la clase (slo
sus mtodos lo pueden accesar).
Publico (+): Indica que el atributo ser visible tanto dentro como fuera de la clase, es
decir, es accesible desde todos lados.
Protegido (#): Indica que el atributo no ser accesible desde fuera de la clase, pero si
podr ser accesado por mtodos de la clase adems de las subclases que se deriven.
Los mtodos u operaciones de una clase son la forma en cmo sta interacta
con su entorno, stos pueden tener las caractersticas:
55
Privado (-): Indica que el mtodo slo ser accesible desde dentro de la clase (slo
otros mtodos de la clase lo pueden accesar).
Publico (+): Indica que el mtodo ser visible tanto dentro como fuera de la clase, es
decir, es accesible desde todos lados.
Protegido (#): Indica que el mtodo no ser accesible desde fuera de la clase, pero si
podr ser accesado por mtodos de la clase adems de mtodos de las subclases que
se deriven.
En un diagrama de clases, las relaciones entre clases se representan por lneas,

a las que se les da diferentes caractersticas, dependiendo del tipo de vinculacin. En
los extremos de esas lneas que representan las relaciones puede colocarse tanto la
descripcin del rol que asume cada clase en esa relacin como la cardinalidad, que
describe cuntos objetos de cada clase pueden participar en la relacin. En la Figura
19 se muestra un ejemplo de la relacin entre dos clases.
Figura 19. Relacin entre clases.

Existen diferentes tipos de relaciones entre clases: asociacin, agregacin,

composicin, dependencias y generalizacin. A continuacin en el Cuadro 1 se
muestran cada una de estas relaciones con sus respectivos detalles.
56
Cuadro 1. Tipo de Relaciones entre Clases
Fuente: Autor (2009).
a.2) Diagrama de Despliegue
Un diagrama de despliegue es un grafo de nodos unidos por enlaces de

comunicacin, que muestra la configuracin en funcionamiento del sistema,
incluyendo su hardware y su software. Estos diagramas muestran la vista de
despliegue esttica de una arquitectura y se relacionan con los componentes ya que,
por lo comn, los nodos contienen uno o ms componentes. En la Figura 20, p.58 se
puede observar un ejemplo de este tipo de diagrama UML.
Cabe agregar que un diagrama de despliegue modela la arquitectura en tiempo

de ejecucin de un sistema, y muestra la configuracin de los elementos de hardware.
Tambin muestra cmo los elementos y artefactos del software se trazan en esos
elementos hardware. Las instancias de componentes software pueden estar unidas por
relaciones de dependencia, posiblemente a travs de interfaces.
57
Figura 20. Ejemplo Diagrama de despliegue.
En la Figura 20 se puede apreciar los elementos que componen un diagrama

de despliegue. Dentro de estos elementos, se encuentra el nodo, que es un objeto
fsico en tiempo de ejecucin que representa un recurso computacional, generalmente
con memoria y capacidad de procesamiento. Se utiliza para identificar cualquier
servidor, terminal de trabajo u otro hardware host que se emplea para desplegar
componentes en el ambiente de produccin. Otro de los elementos son los
componentes, que representan todos los tipos de elementos software que entran en la
fabricacin de aplicaciones informticas. Por ltimo, se tiene la interfaz que se utiliza
como lazo de unin entre unos componentes y otros.
b) Diagramas de Comportamiento
Enfatizan en lo que debe suceder en el sistema modelado. Estos diagramas

representan las caractersticas de comportamiento de un sistema o proceso de
negocios.
58
b.1) Diagrama de Actividad
En UML un diagrama de actividad es un diagrama que se usa para modelar el

comportamiento del sistema, pues describe la secuencia de acciones o actividades en
dicho sistema. Este tipo de diagrama, bsicamente muestra el flujo de trabajo desde el
punto de inicio hasta el punto final detallando muchas de las rutas de decisiones que
existen en el progreso de eventos contenidos en la actividad.
Los diagramas de actividad se pueden usar para modelar un caso de uso, o una
clase, o un mtodo complicado. Este diagrama es parecido a un diagrama de flujo; la
diferencia clave es que los diagramas de actividad pueden mostrar procesado
paralelo. Esto es importante cuando se usan diagramas de actividad para modelar
procesos de negocio, algunos de los cuales pueden actuar en paralelo, y para modelar
varios hilos en los programas concurrentes.
Cabe decir, que este tipo de diagrama cuenta con una herramienta grfica para
modelar el proceso de un caso de uso especfico. Por lo que sirve como un aadido a
una descripcin textual del caso de uso, o para mostrar en forma grafica, los pasos del
caso de uso.
Grficamente un diagrama de actividad es una coleccin de nodos y arcos. En

el Cuadro 2, p. 60 se observan algunos de los elementos que componen a este tipo de
diagrama.
59
Cuadro 2. Elementos Diagrama de Actividad
b.2) Diagrama de Casos de uso
Un Diagrama de Casos de Uso muestra la relacin entre los actores y los casos
de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se
refiere a su interaccin externa. En el diagrama de casos de uso tambin se puede
representar el sistema como una caja rectangular con el nombre en su interior.
Mientras que los casos de uso estn en el interior de la caja del sistema, y los actores
fuera, y cada actor est unido a los casos de uso en los que participa mediante una
lnea.
Un diagrama de casos de uso muestra, por tanto, los distintos requisitos

funcionales que se esperan de una aplicacin o sistema y cmo se relaciona con su
entorno (usuarios u otras aplicaciones). Estos, cubren la vista esttica de los casos de
uso y son especialmente importantes para el modelado y organizacin del
comportamiento.
60
Es importante resaltar que los diagramas de casos de uso no estn pensados
para representar el diseo y no puede describir los elementos internos de un sistema.
Estos diagramas sirven para facilitar la comunicacin con los futuros usuarios del
sistema, y con el cliente, y resultan especialmente tiles para determinar las
caractersticas necesarias que tendr el sistema. En otras palabras, los diagramas de
casos de uso describen qu es lo que debe hacer el sistema, pero no cmo.
En la siguiente figura se muestran los elementos bsicos que conforman al

diagrama de casos de uso:
Figura 21. Elementos Diagrama de casos de uso.

1. Actor:
Un actor es un rol que un usuario juega con respecto al sistema. Es algo con
comportamiento, como una persona (identificada por un rol), un sistema
informatizado u organizacin, y que realiza algn tipo de interaccin con el sistema.
Se representa mediante una figura humana dibujada con palotes. Esta representacin
sirve tanto para actores que son personas como para otro tipo de actores.
Los actores no representan a personas fsicas o a sistemas, sino su papel. Esto

significa que cuando una persona interacciona con el sistema de diferentes maneras
61
(asumiendo diferentes papeles), estar representado por varios actores. Por ejemplo,
una persona que proporciona servicios de atencin al cliente telefnicamente y realiza
pedidos para los clientes estara representada por un actor equipo de soporte y por
otro actor representante de ventas.
2. Caso de uso:
Un caso de uso es una descripcin de la secuencia de interacciones que se

producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo
una tarea especfica. Expresa una unidad coherente de funcionalidad, y se representa
en el diagrama de casos de uso mediante una elipse con el nombre del caso de uso en
su interior. El nombre del caso de uso debe reflejar la tarea especfica que el actor
desea llevar a cabo usando el sistema.
3. Limite de un sistema
Resulta til dibujar los lmites del sistema cuando se pretende hacer un
diagrama de casos de uso para parte del sistema. Usualmente se usa para mostrar
casos de uso dentro del sistema y actores fuera del sistema.
4. Relacin
Entre los elementos de un diagrama de casos de uso se pueden presentar

cuatro tipos de relaciones, representadas por lneas dirigidas entre ellos. Estas son:
a) Relacin de comunicacin
Relacin entre un actor y un caso de uso, denota la participacin del actor en

el caso de uso determinado. Este tipo de relaciones no son obligatorias. Si en un
62
diagrama de casos de uso aparece una relacin entre un actor y un caso de uso, indica
que puede que ese actor interacte con el sistema en ese caso de uso.
b) Generalizacin
En un diagrama de casos de uso tambin pueden mostrarse generalizaciones

(relaciones de herencia) para mostrar que diferentes elementos estn relacionados
como tipos de otros. Son aplicables a actores o casos de uso, pero para estos ltimos
la semntica es muy similar a las relaciones extend.
c) Inclusin
Relacin entre casos de uso, que especifica una situacin en la que un caso de
uso tiene lugar dentro de otro caso de uso. Los casos de uso pueden contener la
funcionalidad de otro caso de uso como parte de su proceso normal. En general se
asume que cualquier caso de uso incluido se llamar cada vez que se ejecute una ruta
bsica.
Los casos de uso se pueden incluir por uno o ms casos de uso, ayudando a
reducir el nivel de duplicacin de la funcionalidad realizando un factoreo del
comportamiento comn en casos de uso que se usan muchas veces. Un caso de uso
incluido es bsicamente un paso del caso de uso base, que se decide extraer aparte
para mejorar la comprensin, por la importancia que tiene el paso por s mismo, o
para factorizar comportamiento comn que se repite en varios casos de uso.
d) Extensin
Se puede incluir una relacin entre dos casos de uso de tipo extends si se
desea especificar diferentes variantes del mismo caso de uso. Es decir, esta relacin
implica que el comportamiento de un caso de uso es diferente dependiendo de ciertas
63
circunstancias. En principio esas variaciones pueden tambin mostrarse como
diferentes descripciones de escenarios asociadas al mismo caso de uso.
Este tipo de relacin se utiliza cuando un caso de uso base tiene ciertos puntos
(puntos de extensin) en los cuales, dependiendo de ciertos criterios, se va a realizar
una interaccin adicional. El caso de uso que extiende describe un comportamiento
opcional del sistema.
c) Diagramas de Interaccin
Estos diagramas son un subtipo de diagramas de comportamiento, que enfatiza

sobre el flujo de control y de datos entre los elementos del sistema modelado.
c.1) Diagrama de Secuencia
El diagrama de secuencia de un sistema es una representacin que muestra, en

determinado escenario de un caso de uso, los eventos generados por actores externos,
su orden y los eventos internos del sistema. Es uno de los diagramas ms efectivos
para modelar interaccin entre objetos en un sistema. Este muestra la interaccin de
un conjunto de objetos en una aplicacin a travs del tiempo y se modela para cada
mtodo de la clase.
Este tipo de diagrama muestra una interaccin ordenada segn la secuencia

temporal de eventos y el intercambio de mensajes. En particular, muestra los objetos
participantes en la interaccin y los mensajes que intercambian ordenados segn su
secuencia en el tiempo. El eje vertical representa el tiempo, y en el eje horizontal se
colocan los objetos y actores participantes en la interaccin, sin un orden prefijado.
Cada objeto o actor tiene una lnea vertical, y los mensajes se representan mediante
flechas entre los distintos objetos. El tiempo fluye de arriba abajo. Se pueden colocar
64
etiquetas (como restricciones de tiempo, descripciones de acciones, etc.) bien en el
margen izquierdo o bien junto a las transiciones o activaciones a las que se refieren.
Los smbolos bsicos de este tipo de diagramas son los siguientes:
a) Lnea de vida
La lnea de vida de un objeto representa la vida del objeto durante la

interaccin. En un diagrama de secuencia un objeto se representa como una lnea
vertical punteada. Algunas veces un diagrama de secuencia tendr una lnea de vida
con un smbolo del elemento actor en la parte superior. Este usualmente sera el caso
si un diagrama de secuencia es contenido por un caso de uso.
Figura 22. Lnea de vida de un objeto.

b) Activacin
Muestra el perodo de tiempo en el cual el objeto se encuentra desarrollando

alguna operacin, bien sea por s mismo o por medio de delegacin a alguno de sus
atributos. Se denota como un rectngulo delgado sobre la lnea de vida del objeto.
65
Figura 23. Activacin de un objeto.
c) Mensaje
El envo de mensajes entre objetos se denota mediante una lnea slida

dirigida, desde el objeto que emite el mensaje hacia el objeto que lo ejecuta.
Figura 24. Mensaje entre objetos.

3.2.3 Tarjetas CRC (clase, responsabilidad y colaboracin)
Las tarjetas CRC son una metodologa para el diseo de software orientado
por objetos creada por Kent Beck y Ward Cunningham. Es una tcnica utilizada para
descubrir informacin acerca de las clases que luego es colocada dentro de los
diagramas de clases UML. Esta tcnica se puede usar para guiar el sistema a travs de
66
anlisis guiados por la responsabilidad. Las clases se examinan, se filtran y se refinan
en base a sus responsabilidades con respecto al sistema, y las clases con las que
necesitan colaborar para completar sus responsabilidades.
Una tarjeta CRC se caracteriza por ser una tarjeta indexada de 3 x 5. La

naturaleza fsica de estas tarjetas enfatiza la divisin de responsabilidades a travs de
los objetos. El tamao fsico de las tarjetas tambin ayuda a establecer lmites para el
tamao y complejidad de las clases. Estas tarjetas se dividen en tres secciones que
contienen informacin del nombre de la clase, sus responsabilidades y sus
colaboradores. A continuacin se muestra cmo se distribuye esta informacin.
Figura 25. Tarjeta CRC.

Una clase es cualquier persona, cosa, evento, concepto, pantalla o reporte. Las
responsabilidades de una clase representan una descripcin de alto nivel del propsito
de una clase. Los colaboradores de una clase son las dems clases con las que trabaja
en conjunto para llevar a cabo sus responsabilidades.
La tcnica de las tarjetas CRC son especialmente eficaces cuando se est en

medio de un caso de uso para ver cmo lo van a implementar las clases. Se escogen
tarjetas a medida que cada clase colabora en el caso de uso, y conforme se van
formando ideas sobre las responsabilidades, estas se pueden escribir en las tarjetas. Es
67
importante pensar en las responsabilidades, ya que evita pensar en las clases como
simples depositarias de datos, y ayuda a centrarse en comprender el comportamiento
de alto nivel de cada clase.
3.2.4 Entregables de RUP
Estn constituidos por los artefactos. Estos son generados durante el proceso
de desarrollo de software. RUP en cada una de sus fases realiza una serie de
artefactos que sirven, entre otras cosas, para comprender mejor tanto el anlisis como
el diseo del sistema. Estos artefactos son los siguientes:
1. Documento Visin
Define la visin del producto desde la perspectiva de los participantes y

usuarios, especificando las necesidades y caractersticas del producto a ser
desarrollado. Este documento es un artefacto de alto nivel, donde se define el alcance
total del sistema a desarrollar y los requerimientos de ms alto nivel enfocados en el
cliente, con la finalidad de proporcionar una visin general y de lograr un lineamiento
y un acuerdo comn entre los involucrados.
Ms detalladamente, este artefacto contiene la declaracin del problema, una

descripcin de los participantes y usuarios, las necesidades particulares de los
diferentes grupos de usuarios, una descripcin de la solucin a proponer y el listado
de caractersticas. Tambin en este documento se determinan las necesidades y
requerimientos a nivel de participantes, de hardware y de software.
2. Plan de Iteracin General
Este artefacto presenta el plan general del proyecto, incluyendo el conjunto de

actividades y tareas que sern realizadas para desarrollar el proyecto y la dependencia
68
entre ellas. Adems se muestra el conjunto de actividades que se realizan en las
iteraciones de cada fase.
3. Plan de Administracin de Riesgos
Un riesgo, es la oportunidad de que algo ocurra, y que puede tener un impacto

sobre los objetivos. Cada riesgo est medido en trminos de consecuencia y
posibilidad.
El Plan de Administracin de Riesgos tiene como propsito determinar las

estrategias para deteccin, anlisis y jerarquizacin de riesgos. Este artefacto contiene
una lista de riesgos que pueden afectar el correcto desarrollo del proyecto, ordenados
en orden decreciente de importancia y con acciones especficas de contingencia o
para su mitigacin.
La lista de riesgos no es un instrumento esttico, sta se mantiene a lo largo

del desarrollo del proyecto. Se crea a comienzos de la fase inicial, y se actualiza
continuamente ya que pueden ser descubiertos nuevos riesgos u otros existentes
pueden ser atenuados o eliminados.
Los criterios para la escogencia de los riesgos se centran en los siguientes

aspectos:
- Riesgos de Dependencia.
- Riesgos de Requerimientos.
- Riesgos de Administracin.
- Riesgos de Conocimiento.
69
Cada riesgo ser ponderado a fin de darle un lugar en la jerarqua. Sin
embargo hay que aclarar que la ponderacin es dinmica y puede aumentar o
disminuir con el devenir del proyecto que se est realizando.
Tareas de Administracin de Riesgos
La gestin de riesgos se realiza cumpliendo con las siguientes actividades:
- Mediante entrevistas con los involucrados (usuarios y equipo de proyecto)

- Anlisis de los requerimientos verificando las variables que atentaran contra
la salud del proyecto.
- Deduccin de los riesgos para cada uno de los requerimientos en el contexto
del sistema.
- Categorizacin de los riesgos en cuanto a probabilidad de ocurrencia y
expectativas de prdida en caso de ocurrencia.
- Establecimiento de las estrategias de administracin de los riesgos
(mitigacin, esquivamiento o prevencin) para cada uno de los riesgos ms
importantes.
- Ponderacin de los riesgos con fines de jerarquizacin.
- Seguimiento de mtricas asociadas a riesgos con el propsito de monitorear su
posible ocurrencia. Esto implica la revisin por iteracin de las variables
involucradas y la evaluacin del estado del proyecto en general en contraste
con los requerimientos principales.
Las tareas antes mencionadas deben ser llevadas principalmente por el Lder
del Proyecto. En caso de materializarse alguno de los riesgos el Lder del Proyecto
invoca los planes de gestin para el riesgo o grupo de riesgos con la finalidad de
incluir las tareas de tratamiento dentro de las actividades de los equipos.
70
Herramientas y Tcnicas.
Para la elaboracin de la lista de riesgos se puede utilizar la Tabla de

Documentacin de Riesgos, la cual permite visualizar cada uno de los riesgos con sus
aspectos involucrados. Esta tabla puede ser observada a continuacin:
Cuadro 3. Tabla Documentacin de Riesgos.

Identificador: (Nmero Secuencial)
Descripcin: (Lista de cada riesgo mayor al cual se enfrenta el proyecto. Se describe cada riesgo en
la forma condicin consecuencia.
Probabilidad: (Cul es la Prdida: (Cul es el dao si Grado de Exposicin:
probabilidad de que el riesgo se el riesgo se convierte en un (Multiplicacin de la
convierta en un problema?) problema?) probabilidad por la prdida)
Primer Indicador: (Describe el indicador ms temprano o condicin de disparo que podra indicar
que el riesgo se est convirtiendo en un problema)
Estrategia de Mitigacin: (Ponderacin de uno o ms enfoques para controlar, evitar, minimizar, o
en ltima instancia mitigar el riesgo.
Propietario: (Asignacin de cada accin de Fecha Prevista: (Determinar una fecha
mitigacin de riesgos a un individuo para su mediante la cual la estrategia de mitigacin
resolucin.) ser implementada)
En la medida en que las iteraciones vayan avanzando, entonces, el Lder de

Proyectos ir reevaluando la probabilidad de ocurrencia con el fin de modificar, si es
necesario, el grado de exposicin y como consecuencia la jerarquizacin de los
riesgos.
4. Modelado del Negocio
El modelado del negocio tiene la finalidad de comprender y describir los

procesos de negocio de la organizacin bajo estudio, especificando sus datos,
71
actividades, tareas y los roles desempeados. Este artefacto abarca el modelo del
negocio y el modelo del dominio de UML.
El modelo del negocio describe a travs del modelo de casos de uso del
negocio las funciones o procesos de negocio de la empresa u organizacin en
trminos de casos de uso y actores del negocio, con el fin de comprender cules sern
los procesos que soportar el sistema. Este modelo de casos de uso del negocio
permite situar al sistema en el contexto institucional haciendo nfasis en los objetivos
en este mbito y se representa mediante un diagrama de casos de uso general usando
estereotipos especficos para este modelo.
Por otro lado el modelo del dominio del negocio captura los objetos ms
importantes en el contexto del sistema. Este modelo se describe mediante diagramas
de clases de UML, que carecen de algunos de los detalles tcnicos y estn
compuestos por las clases que se han interpretado y descubierto en el anlisis del
negocio. Estos diagramas muestran los objetos del dominio o clases conceptuales y
las relaciones entre ellas a travs de asociaciones.
5. Especificacin de Casos de Uso del Negocio
Es un documento donde se especifican y describen de manera detallada cada

uno de los casos de uso que conforman el caso de uso general, representado en el
modelado del negocio. Adems, en estas especificaciones se muestran los actores que
intervienen en cada uno de los casos de uso, los flujos bsicos o normales, los
posibles flujos alternativos de eventos; tambin incluye su diagrama de actividad.
6. Documento Glosario
Es un documento que define los principales trminos usados en el proyecto de

desarrollo de software. Este glosario es muy til para alcanzar un consenso entre las
72
personas involucradas en el desarrollo del proyecto en cuanto a la definicin de los
diversos conceptos y nociones, y para reducir en general riesgo de confusiones. Dicho
glosario se comienza desde el inicio del desarrollo del proyecto con el objetivo de
recopilar aquellos trminos que no estn claros, que sean ambiguos o que requieran
alguna elaboracin relevante.
7. Especificacin de Casos de Uso del Sistema
Artefacto donde estn definidos los requisitos funcionales del sistema. En este
se describen cada uno de los casos de uso que conforman el caso de uso general del
sistema. Cada artefacto contiene las precondiciones, post-condiciones, flujo normal
de eventos, flujos alternativos, condiciones especiales de cada caso de uso, adems se
incluye su diagrama de secuencia y los prototipos de interfaz de usuarios.
8. Especificaciones Complementarias
Este documento captura todos los requisitos que no han sido incluidos como
parte de los casos de uso y se refiere a requisitos adicionales y restricciones. Este
documento abarca los requisitos del sistema clasificados segn el modelo FURPS+;
el cual es un modelo que permite clasificar las cualidades de la calidad del software.
Los requisitos adicionales son fundamentalmente requisitos no funcionales

que no pueden asociarse a ningn caso de uso en concreto. Sin embargo cada uno de
estos requisitos puede tener impacto en varios casos de uso o en ninguno. Algunos
ejemplos son el rendimiento, las interfaces y los requisitos de diseo fsico, as como
las restricciones arquitectnicas, de diseo y de implementacin. (Jacobson, Booch y
Rumbaugh, 2000, p. 121)
73
9. Arquitectura del Sistema
Este documento proporciona una descripcin de la arquitectura del software a

desarrollar a travs de diferentes modelos o vistas. Cada vista muestra aspectos
diferentes de la arquitectura del sistema, y todas ellas deben ser coherentes entre s,
pues describen la misma arquitectura. Estas vistas son: lgica, de datos y de
despliegue.
10. Documento de Casos de Prueba
Este artefacto especifica una forma de probar el sistema, incluyendo

condiciones de ejecucin, entradas de la prueba, resultados esperados y la evaluacin
de la prueba. Adems, el artefacto llevar asociado un procedimiento de prueba con
las instrucciones para realizar dicha prueba.
3.2.5 Sistema de Inventario Permanente
El sistema de inventario permanente, o tambin llamado perpetuo, consiste en

aplicar un procedimiento administrativo en el que se controlan tanto las entradas
como las salidas de los almacenes, y se valoran siguiendo un criterio nico: el de su
costo, lo que proporciona un control continuo de las salidas y la discriminacin hacia
cada uno de los productos. Esta persistencia en los valores de los movimientos de
almacn permite, en definitiva, controlar los consumos de cada producto en el
momento en que se adquieren o producen, y obtener el saldo continuo o permanente
de cada material, lo que a su vez permite conocer en todo momento el costo de las
unidades que se consumen, el costo de las unidades que se venden, as como el costo
de las unidades que existen en su almacn, y evitar rupturas de stocks y paradas
innecesarias en la fbrica o empresa.
74
Para llevar este control es necesario contar, para cada bien del almacn, con
una ficha que recoja sus movimientos (denominada ficha de almacn o tarjeta de
existencia). En dicha tarjeta, se registra cada unidad, su valor de compra, la fecha de
adquisicin, el valor de salida de cada unidad, y la fecha en que se retira del
inventario, permitiendo conocer en todo momento el saldo exacto y actualizado de los
inventarios.
El inventario perpetuo fue diseado para proporcionar a los gerentes

informacin til al momento de fijar los precios o hacer los pedidos. En un principio,
era extremadamente engorroso y costoso conservar registros constantes, pero los
sistemas computarizados y el equipo de exploracin ptica en las cajas registradoras
han abaratado mucho la implementacin de estos sistemas en muchas industrias.
Este sistema de inventario, como mantiene un registro continuo que deduce

diariamente las existencias y el costo de los bienes vendidos, tambin le sirve a los
gerentes para controlar los niveles del inventario y preparar estados financieros
provisionales. Sin embargo, este sistema no elimina las necesidades de un conteo
fsico y una valuacin del inventario. El conteo fsico debe efectuarse al menos una
vez al ao, para verificar la exactitud de los registros continuos.
Asimismo, el sistema de inventario permanente permite identificar o detectar

prdidas y mermas de existencias en almacenes, al comparar el valor controlado de
las existencias finales (inventario registrado), con el valor real obtenido mediante
recuento fsico. Las causas de dichas mermas pueden ser extravos, robos, prdidas en
manipulacin, errores en registro, entre otros. Si la merma de inventario es
inusualmente grande, los directivos pueden investigar y tomar las medidas necesarias
para corregirla.
Otras ventajas derivadas del mantenimiento de un sistema de inventario

permanente son las siguientes:
75
- Evita las prdidas de tiempo de personal y el cierre de instalaciones que se
producen durante el proceso de recuento del inventario fsico peridico. En el
sistema de inventario permanente se realizan recuentos fijos realizados por
personal cualificado de almacn en tiempos en que no tienen otras
actividades, lo cual asegura, adems una mayor exactitud en el recuento.
- Mejora el rendimiento de la entrega de productos y reduce los costos de
transporte, ya que la exactitud en el registro de las existencias permite
comprometer expediciones a clientes con mayor confianza.
- Permite tomar decisiones informadas con respecto a la reduccin de
existencias en almacn, con la consiguiente reduccin de costos asociados a
su mantenimiento (personal de almacn, seguros, necesidades de financiacin,
entre otros).
3.2.5.1 Valuacin de los inventarios en el sistema permanente
La valuacin de los inventarios y la determinacin del costo de venta por el

sistema permanente, tiene el inconveniente con los valores de las mercancas, puesto
que stas se adquieren en fechas diferentes con precios diferentes, por lo que es
imposible tener una homogeneidad en los valores de las mercancas compradas. Para
evitar este problema, la valuacin de los inventarios se realiza mediante diferentes
mtodos que buscan determinar el costo de la forma ms real, dependiendo del tipo
de empresa.
Entre los mtodos de valuacin existentes se encuentran: Mtodo PEPS,

Mtodo UEPS, Mtodo del promedio ponderado, entre otros.
Determinacin del Costo del Inventario por mtodo PEPS
Muchas empresas tratan de vender los artculos en el orden en que los

compran. Ello resulta especialmente vlido en el caso de los bienes perecederos y
76
otros cuyos estilos o modelos cambian con frecuencia. Por ejemplo, los abastos
colocan en sus estantes los productos lcteos por fecha de caducidad. De igual
manera, las tiendas de ropa para dama y caballero exhiben las prendas por temporada.
Al final de cada temporada, muchas veces ponen rebajas para sacar de la tienda la
ropa de la temporada que termina o que ya est pasada de moda. Por ende, el mtodo
de primeras entradas, primeras salidas suele ser compatible con el movimiento o flujo
fsico de las mercancas. Siendo ste el caso, el mtodo PEPS genera resultados casi
iguales a los obtenidos identificando los costos especficos de cada artculo vendido y
existente en el inventario.
El mtodo PEPS, consiste bsicamente en darle salida del inventario a

aquellos productos que se adquirieron primero, por lo que en los inventarios quedarn
aquellos productos comprados ms recientemente. Es decir, cada vez que se realiza
una venta o salida de artculo, se descargan las unidades salientes del inventario con
el costo de las primeras unidades adquiridas. A esto, es a lo que hace referencia las
siglas PEPS, que significa Primeras en Entrar, Primeras en Salir. Este mtodo de
determinacin de costo es tambin conocido como FIFO, por sus siglas en ingles.
A continuacin se ilustra un ejemplo de esta metodologa, con los datos del

artculo 127B, mostrados en la siguiente figura:
Figura 26. Datos de Articulo 127B

Fuente: Warren, C., Reeve, J. y Fess P. (2005).
En la Figura 27, p.78 se muestran los asientos de libro diario de compras y

ventas, as como la cuenta del libro mayor auxiliar de inventario del articulo 127B.
77
En la cuenta puede verse el nmero de unidades en existencia despus de cada
transaccin, junto con los costos totales y unitarios. Se supone que las unidades se
venden en $30 cada una, a crdito o a cuenta.
Figura 27. Asientos y cuenta inventario perpetuo (PEPS)

Fuente: Warren, C., Reeve, J. y Fess P. (2005).
En el ejemplo (Figura 27), se puede observar que despus de vender 7

unidades el 04 de Enero se tenan en inventario 3 unidades, a $20 cada una. Las 8
unidades compradas el 10 de Enero se adquirieron con costo unitario de $21, no de
$20. Por lo tanto, el inventario despus de la compra del 10 de Enero se presenta en
dos lneas, 3 unidades a $20 cada una y 8 a $21. Luego, se nota que el costo de $81 de
las 4 unidades vendidas el 22 de Enero se conforma de las 3 unidades estantes a $20
cada una y una ms a $21. En este punto, hay 7 unidades en el inventario, con costo
de $21 por unidad. El resto de la ilustracin se explica de manera similar.
En cualquiera de los mtodos de determinacin de costos de inventarios, las

compras no tienen gran importancia, puesto que estas ingresan al inventario por el
valor de compra y no requiere procedimiento especial alguno. De igual manera,
sucede en el caso de existir devoluciones de compras, pues esta se hace por el valor
que se compr al momento de la operacin, es decir se le da salida del inventario por
78
el valor pagado en la compra. Por el contrario, si lo que se devuelve es un producto
vendido a un cliente, este se ingresa al inventario nuevamente por el valor en que se
vendi, pues se supone que cuando se hizo la venta, a esos productos se les asign un
costo de salida segn el mtodo de valuacin de inventarios manejado por la empresa.
3.2.6 Pronsticos de demanda
Pronosticar es el arte y la ciencia de predecir los eventos futuros. Puede

implicar el uso de datos histricos y su proyeccin hacia el futuro mediante algn tipo
de modelo matemtico. Puede ser una prediccin subjetiva o intuitiva, o puede ser
una combinacin de ambos, es decir, un modelo matemtico ajustado por el buen
juicio del administrador.
Existen dos enfoques generales al pronosticar, uno es el anlisis cuantitativo y

el otro el enfoque cualitativo. Los pronsticos cuantitativos utilizan una variedad de
modelos matemticos que se apoyan en datos histricos o en variables causales para
pronosticar la demanda. Los pronsticos cualitativos o subjetivos incorporan aquellos
factores como la intuicin, las emociones, las experiencias personales y el sistema de
valores de quien toma la decisin para llegar al pronstico. Las empresas emplean
uno u otro enfoque, pero en la prctica la combinacin de ambos es casi siempre ms
efectiva.
Dentro de los mtodos cuantitativos para pronstico de demanda se encuentra

el anlisis de series de tiempo. Una serie de tiempo es un conjunto de observaciones
de una variable medida en puntos o periodos sucesivos en el tiempo (semanas, meses,
trimestres, etctera).
El anlisis de serie de tiempo es un mtodo estadstico que depende en alto

grado de datos histricos de la demanda, con los que proyecta la magnitud futura de
la misma y reconoce las tendencias y patrones estacionales. Este mtodo se emplea
79
ms frecuentemente para elaborar pronsticos a corto plazo (0 a 3 meses), y es una
forma relativamente econmica y precisa de generar el gran nmero de pronsticos
requeridos.
Ahora bien, dentro de este tipo de pronstico, se encuentra el mtodo de

promedio mvil simple; el cual se usa para estimar el promedio de una serie de
tiempo de demanda y, por lo tanto, para suprimir los efectos de las fluctuaciones al
azar. La aplicacin de un modelo de promedio mvil implica simplemente calcular la
demanda promedio para los n periodos ms recientes, con el fin de usarla como
pronstico para el siguiente periodo. Para el periodo siguiente, una vez que se conoce
la demanda real, la demanda ms antigua incluida en el promedio anterior se sustituye
por la demanda ms reciente y luego se vuelve a calcular el promedio. De esta
manera se usan las n demandas ms recientes, por lo cual el promedio se mueve de
uno a otro periodo.
En el mtodo de promedio mvil pueden incluirse todos los periodos

pretritos de demanda que se desee. Generalmente, la estabilidad de la serie
correspondiente a la demanda determina cuntos periodos ser necesario incluir (es
decir, el valor de n). Las series de demanda estables son aquellas para las cuales el
promedio (que habr de calcularse mediante el mtodo de pronstico) cambia
solamente en forma infrecuente. Debern utilizarse valores grandes de n para las
series de demanda que sean estables, y valores pequeos de n para las que sean
susceptibles de cambios en el promedio fundamental.
No hay una regla exacta para seleccionar n, la base del promedio mvil. Si las
variaciones de la variable permanecen razonablemente constantes al paso del tiempo,
se recomienda una n grande. En caso contrario, si los datos tienen pautas cambiantes,
se aconseja un valor pequeo de n. En la prctica ese valor va de 2 a 10.
80
3.2.7 Sistemas de informacin
Segn Jons Montilva (1992), un sistema de informacin es un

conjunto organizado de hombres, mquinas, programas y procedimientos para
llevar a cabo unas funciones que cumplan unos objetivos deseados. (p.17)
Tambin establece que un sistema de informacin procesa datos a fin de
registrar los detalles originados por las transacciones que ocurren y las
entidades que forman una organizacin y proporcionar informacin que facilite
la ejecucin de actividades, operaciones y funciones en una organizacin
(p.18)
De acuerdo a lo establecido anteriormente, los sistemas de informacin se

encuentran dentro de un sistema mayor, denominado organizacin; y adems estn
compuestos de elementos que interactan entre s para brindar a quienes adoptan
decisiones, la informacin que requieren para desarrollar sus respectivas funciones y
as apoyar a las actividades de la empresa u organizacin.
Esta informacin que necesita la organizacin se obtiene a travs de las cuatro

actividades bsicas que realizan los sistemas de informacin. A continuacin se
detallan cada una de ellas:
1. Entrada de Informacin
Es un proceso que consiste en capturar los datos en bruto tanto del interior de
la organizacin como de su entorno externo. Las entradas pueden ser manuales o
automticas. Las manuales son aquellas que se proporcionan en forma directa por el
usuario (a travs del teclado, el mouse, la voz, los monitores sensibles al tacto, cdigo
de barras, entre otros), mientras que las automticas son datos o informacin que
provienen o son tomados de otros sistemas.
81
2. Almacenamiento de la informacin
Es una de las actividades ms importantes que tiene una computadora, ya que

a travs de esta propiedad el sistema puede recordar la informacin guardada en el
proceso de entrada de informacin. Esta informacin suele ser almacenada en
estructuras de informacin denominadas archivos. La unidad tpica de
almacenamiento son los discos magnticos o discos duros, diskettes, los discos
compactos (CDs), discos verstiles digitales (DVDs), entre otros.
3. Procesamiento de la informacin
Es la capacidad del Sistema de Informacin para efectuar clculos de acuerdo

con una secuencia de operaciones preestablecida. Estos clculos pueden efectuarse
con datos introducidos recientemente en el sistema o bien con datos que estn
almacenados. Esta caracterstica de los sistemas permite la transformacin de datos
fuente en informacin que puede ser utilizada para la toma de decisiones.
4. Salida de informacin
Es la capacidad de un sistema de informacin para sacar los datos procesados

al exterior. Esta actividad implica producir informacin til, por lo general en forma
de documentos y/o reportes. En algunos casos, la salida de un sistema de informacin
puede constituir la entrada a otro sistema o mdulo. La salida puede producirse por
diversos medios. En referente a las computadoras entre los dispositivos de salida ms
comunes estn las impresoras y la pantalla. Sin embargo, la salida tambin puede ser
un proceso manual, pues a menudo supone informes y documentos manuscritos
En la actualidad, los sistemas de informacin cumplen tres objetivos bsicos

dentro de las organizaciones: automatizar procesos, proporcionar informacin que
sirva de apoyo para la toma de decisiones y alcanzar ventajas competitivas.
82
Con frecuencia, los sistemas de informacin que logran la automatizacin de
procesos operativos dentro de una organizacin son llamados Sistemas
Transaccionales, ya que su funcin principal consiste en procesar transacciones tales
como pagos, planillas, entradas, salidas, entre otros. Por otra parte, los sistemas de
informacin que apoyan el proceso de toma de decisiones son los sistemas de apoyo a
la toma de decisiones. El tercer tipo de sistemas, de acuerdo con su uso u objetivos
que cumplen, son los sistemas estratgicos, los cuales se desarrollan en las
organizaciones con el fin de lograr ventajas competitivas, a travs del uso de la
Tecnologa de Informacin (TI).
3.2.8 Aplicacin WEB
En la ingeniera software, una aplicacin Web es aquella aplicacin que puede

ser utilizada accediendo a un servidor Web a travs de Internet o de una intranet
mediante un navegador. En otras palabras, es una aplicacin software que se codifica
en un lenguaje soportado por los navegadores Web (como HTML, JavaScript, Java,
etc.) en la que se confa la ejecucin al navegador.
Berzal y Cubero (2005) definen a los sistemas Web como: aquellas

aplicaciones cuya interfaz se construye a partir de pginas Web. Las pginas
Web no son ms que ficheros de texto en un formato estndar denominado
HTML (Hipertext Markup Language). Estos ficheros se almacenan en un
servidor Web al cual se accede utilizando el protocolo HTTP (Hypertext
Transfer Protocol), uno de los protocolos de Internet. Para utilizar una
aplicacin Web desde una maquina concreta basta con tener instalado un
navegador Web en esa mquina, ya sea este el Internet Explorer de Microsoft,
el Netscape Navigator o cualquier otro navegador. (p.187).
La mayora de las aplicaciones Web reales utilizan tecnologas tanto del lado
del cliente como del lado del servidor. Utilizar unas u otras es una cuestin de diseo
que habr de resolverse en funcin de lo que resulte ms adecuado para satisfacer las
necesidades particulares de cada aplicacin.
83
Las aplicaciones Web ofrecen grandes ventajas que pueden ser aprovechadas
por muchas organizaciones, sobre todo ahora que la globalizacin es una realidad.
Entre estas ventajas se encuentran:
Son fciles de usar, no requieren conocimientos avanzados de computacin.
Compatibilidad multiplataforma: Las aplicaciones Web tienen un camino mucho

ms sencillo para la compatibilidad multiplataforma que las aplicaciones de
escritorio. Utilizan tecnologas como PHP, Java, Flash, ASP y AJAX que permiten un
desarrollo efectivo de programas soportando todos los sistemas operativos
principales.
Actualizacin: Pueden existir miles de clientes pero una nica aplicacin instalada en
un servidor, por lo tanto se puede actualizar y mantener una nica aplicacin y todos
sus clientes vern los resultados inmediatamente.
Inmediatez de acceso: Este tipo de aplicaciones no necesitan ser descargadas,

instaladas y configuradas, pues usan tecnologa Web. Cualquier usuario puede
acceder a su cuenta online y estar listo para trabajar sin importar cual es su
configuracin o su hardware (no necesita tener un ordenador de grandes prestaciones
para trabajar con la aplicacin Web).
Alta disponibilidad, ya que se puede realizar consultas en cualquier parte del mundo
donde tenga acceso a Internet y a cualquier hora.
Mltiples usuarios concurrentes: Los sistemas Web pueden ser utilizados por
mltiples usuarios al mismo tiempo. No hay ms necesidad de compartir pantallas o
enviar instantneas cuando mltiples usuarios pueden ver e incluso editar el mismo
documento de manera conjunta.
84
3.2.9 HTML
HTML, acrnimo ingls de HyperText Markup Language (Lenguaje de

Marcas de Hipertexto), es el lenguaje de marcado predominante para la creacin de
pginas web. Se basa en el metalenguaje SGML (Standard Generalized Markup
Language) y es el formato de los documentos de la World Wide Web. Este lenguaje
es un estndar reconocido en todo el mundo y cuyas normas las define una
organizacin sin nimo de lucro llamado World Wide Web Consortium, ms
conocido como W3C. Este organismo desarrolla los estndares para normalizar el
desarrollo y la expansin de la Web y publica las especificaciones relativas al
lenguaje HTML.
Cabe destacar, que HTML es un lenguaje de descripcin de hipertexto

compuesto por una serie de comandos, marcas, o etiquetas, tambin denominadas
Tags que permiten definir la estructura lgica de un documento Web y establecer
los atributos del mismo (color del texto, contenidos multimedia, hipervnculos, etc.).
(Cobo y Gmez, 2005, p.57).
Ahora bien, un documento HTML es un archivo de texto plano (tambin

conocido como ASCII) que puede ser editado con cualquier editor de texto (como el
Gedit en Linux o el Bloc de Notas de Windows o cualquier otro editor que admita
texto sin formato). Sin embargo, existen programas que pueden facilitar el trabajo de
creacin de sitios Web o edicin de cdigo HTML, como por ejemplo Microsoft
FrontPage o el famoso software de Macromedia llamado Dreamweaver. Estos
programas se les conoce como editores WYSIWYG o What You See Is What You
Get (lo que ves es lo que obtienes), lo que significa que son editores en los que se
puede ver el resultado de lo que se est editando en tiempo real a medida que se va
desarrollando el documento.
85
En cuanto al nombre de los archivos escritos en lenguaje HTML, estos deben
tener la extensin html o htm, para que puedan ser visualizados en los navegadores.
Estos son los encargados de interpretar el cdigo HTML de los documentos, y de
mostrar a los usuarios las pginas Web resultantes del cdigo interpretado.
Como se mencion anteriormente, HTML utiliza etiquetas o marcas. Estas

consisten en breves instrucciones de comienzo y final, mediante las cuales se define
la estructura lgica del documento HTML y se pueden aplicar distintos estilos al texto
(negrita, cursiva,...). Con ellas tambin se puede incluir imgenes, archivos
multimedia (grficos, vdeo, audio) e hiperenlaces, que permitirn acceder a otros
documentos relacionados al actual. Toda etiqueta se identifica porque est encerrada
entre los signos menor que y mayor que (<>), y algunas tienen atributos o parmetros
que pueden tomar algn valor. Las etiquetas, que muestran la estructura bsica de un
documento HTML se representan en la siguiente figura:
Figura 28. Estructura Bsica de un documento HTML.

Ninguno de estos elementos es obligatorio, pudiendo crear documentos

HTML sin incluir estas etiquetas de identificacin. No obstante es altamente
recomendable la construccin de pginas HTML siguiendo esta estructura, para una
buena estructuracin y legibilidad del cdigo.
86
3.2.10 Tecnologas de Programacin del lado del cliente
En la programacin del lado del cliente, los programas residen junto a las
pginas Web en el servidor, pero son transferidos al cliente para que ste los ejecute.
Dentro de los lenguajes de programacin del lado del cliente se pueden mencionar:
java, JavaScript, VBScript.
3.2.10.1 JavaScript
JavaScript es un lenguaje de scripts, interpretado, multiplataforma y

parcialmente orientado a objetos desarrollado por Netscape para incrementar las
funcionalidades del lenguaje HTML. Dicho lenguaje fue declarado como estndar del
European Computer Manufacturers Association (ECMA) en 1997, y poco despus
tambin fue estandarizado por la Internacional Organization for Standardization
(ISO). Sin embargo, la estructura de objetos que implementaban los diferentes
navegadores (Netscape y Explorer en aquellos momentos) no se ajustaba al estndar,
lo que provocaba numerosos problemas de compatibilidad. Por lo que la W3C para
solventar dichos problemas public un nuevo modelo de objetos, DOM (Document
Object Model), el cual ha sido incorporado por la mayora de los navegadores
actuales como Explorer o Firefox.
Este lenguaje es utilizado principalmente para crear pginas Web dinmicas;

presenta una sintaxis semejante a la del lenguaje Java y el lenguaje C. Dentro de sus
caractersticas ms importantes se pueden mencionar las siguientes:
Es un lenguaje interpretado, es decir, no requiere compilacin. Este lenguaje

funciona del lado del cliente; es el navegador del usuario el que se encarga de
interpretar el codigo JavaScript contenido en una pgina HTML y ejecutarlo
adecuadamente.
87
JavaScript es un lenguaje basado en objetos. El modelo de objetos de JavaScript
est reducido y simplificado, pero incluye los elementos necesarios para que los
scripts puedan acceder a la informacin de una pgina y puedan actuar sobre la
interfaz del navegador.
Es un lenguaje orientado a eventos. Cuando un usuario presiona una tecla, pulsa

sobre un enlace o mueve el puntero del mouse sobre una imagen se produce un
evento. Mediante JavaScript se pueden desarrollar scripts que ejecuten acciones en
respuesta a estos eventos que pueden producirse sobre la pgina Web.
El cdigo JavaScript puede enlazarse o aadirse a las pginas Web

proporcionando un control total y dinmico sobre ellas. Tambin permite controlar,
hasta cierto punto, las aplicaciones que lo ejecutan, habitualmente los navegadores. El
cdigo de este lenguaje se encierra entre etiquetas <script> y se incluye en cualquier
parte del documento. Aunque es correcto incluir cualquier bloque de cdigo en
cualquier zona de la pgina, es recomendable definir el cdigo JavaScript dentro de la
cabecera del documento (dentro de la etiqueta <head>). Tambin las instrucciones
JavaScript se pueden incluir en un archivo externo de tipo JavaScript, que los
documentos HTML enlazan mediante la etiqueta <script>.
3.2.11 Tecnologas de Programacin del lado del servidor
En la programacin del lado del servidor, los programas son ejecutados por el
servidor y lo que enva al cliente es la respuesta o resultado de dicha ejecucin.
Lenguajes como PHP o Perl pertenecen a esta categora.
3.2.11.1 PHP
PHP (PHP Hypertext Preprocessor) es un lenguaje de programacin que fue

creado por Rasmus Lerdorf en 1994 para la creacin de contenidos Web dinmicos,
88
orientados principalmente a la conexin con bases de datos. Este es un lenguaje
interpretado que se ejecuta del lado del servidor, y que se caracteriza por su potencia,
versatilidad, robustez y modularidad. Al ser este un lenguaje que se ejecuta en el
servidor no es necesario que su navegador lo soporte, es independiente del navegador,
sin embargo, para que sus pginas PHP funcionen, el servidor donde estn alojadas
debe soportar PHP.
Los programas escritos en PHP son embebidos o incrustados directamente en

el cdigo HTML y ejecutados por un servidor Web a travs de un intrprete antes de
transferir al cliente que lo ha solicitado un resultado en forma de cdigo HTML puro.
PHP puede trabajar con la totalidad de los servidores Web conocidos, pero lo ms
habitual es encontrar PHP sobre un servidor apache.
El lenguaje PHP presenta las siguientes caractersticas:
a. Es un lenguaje multiplataforma; los programas funcionan bien sobre

diferentes plataformas, trabajando sobre la mayora de servidores Web
y estando preparado para interactuar con muchos tipos de bases de
datos.
b. Es libre, por lo que se presenta como una alternativa de fcil acceso
para todos.
c. Integracin con varias bibliotecas externas, permite generar
documentos en PDF, tambin analizar cdigo XML.
d. Capacidad de conexin con la mayora de los manejadores de base de
datos existentes, principalmente con MySQL.
e. No requiere la definicin de tipos de variables.
f. Permite las tcnicas de programacin orientada a objetos.
g. Es Soportado por una gran comunidad de desarrolladores; como
producto de cdigo abierto. PHP goza de la ayuda de un gran grupo de
89
programadores, permitiendo que los fallos de funcionamiento se
encuentren y reparen rpidamente.
3.2.12 Servidor Web Apache
El servidor Apache es un servidor Web HTTP de cdigo abierto y de

distribucin libre desarrollado por la Apache Software Foundation cuyo objetivo es
servir o suministrar pginas Web a los clientes o navegadores Web que las solicitan.
Es el servidor Web ms utilizado en el mundo y esto debido a sus caractersticas:
robustez, rapidez, multiplataforma (con versiones para Linux, Windows, Macintosh,
etc.), modularizable, dispone de mdulos para ejecutar PHP, Perl, entre otros.
3.2.13 AJAX
Con el surgimiento de lenguajes como PHP del lado del servidor y Javascript
del lado del cliente, surgi AJAX, que es el acrnimo de Asynchronous JavaScript
and XML (JavaScript Asncrono y XML). Este es una tcnica de desarrollo Web, por
la cual se pueden crear aplicaciones Web ms rpidas y cmodas para el usuario.
AJAX engloba a un conjunto de tecnologas que trabajan conjuntamente.

Estas son:
XHTML (o HTML) y hojas de estilos en cascada CSS, para la presentacin de la

informacin, basada en estndares.
Document Object Model (DOM), para la interaccin y manipulacin dinmica de la
informacin presentada. Se accede a este con un lenguaje de script por parte del
usuario,
XML, XSLT y JSON, para el intercambio y la manipulacin de la informacin
solicitada al servidor.
90
El objeto XMLHttpRequest, para intercambiar informacin asncronamente con el
servidor Web.
Y JavaScript, para unir todas las dems tecnologas.
En las aplicaciones construidas con AJAX se elimina la recarga constante de

paginas mediante la creacin de un elemento intermedio entre el usuario y el servidor.
Estas aplicaciones se ejecutan en el cliente o navegador de los usuarios mientras se
mantiene una comunicacin asncrona con el servidor en segundo plano. De esta
forma es posible realizar cambios sobre las pginas sin necesidad de recargarlas, lo
que significa aumentar la interactividad, velocidad y usabilidad en las aplicaciones.
Por ejemplo, al rellenar un formulario de una pgina Web, con AJAX se puede
actualizar la parte en la que se elige el pas de residencia sin tener que actualizar toda
la pgina Web completa.
3.2.14 Base de Datos
Una base de datos es un conjunto de datos estructurados, pertenecientes a un

mismo contexto y almacenados sistemticamente para su posterior uso. En la
actualidad, estas son esenciales para la supervivencia de cualquier organizacin, pues
los datos estructurados constituyen un recurso bsico para todas las organizaciones.
Tambin, stas juegan un papel esencial en el desarrollo de aplicaciones Web debido
a que muchas de las pginas Web a las que se acceden habitualmente, a travs de
internet, se generan como resultado de una consulta a una base de datos, poniendo de
manifiesto su carcter dinmico. Algunas razones que justifican su uso son su
capacidad para almacenar grandes volmenes de informacin, la optimizacin de su
gestin, la facilidad para realizar consultas y la exactitud, rapidez y fiabilidad en su
administracin.
91
3.2.14.1 Arquitectura de la Base de datos
El comit de planeacin y requisitos de estndares del Instituto Nacional

Norteamericano de Estndares (ANSI/SPARC) ha establecido una arquitectura de tres
niveles para un DBMS: interno, conceptual y externo.
Nivel interno: el nivel interno determina dnde se almacenan realmente los datos en
el dispositivo de almacenamiento. Este nivel trata con mtodos de acceso de bajo
nivel y cmo se transfieren los bytes hacia y desde el dispositivo de almacenamiento.
En otras palabras, el nivel interno interacta directamente con el hardware.
Nivel Conceptual: el nivel conceptual, o comunitario, define el punto de vista lgico

de los datos y los diagramas de esquemas. Las funciones principales del DBMS estn
en este nivel. El DBMS cambia la vista interna de los datos a la vista externa de los
mismos que el usuario necesita ver. El nivel conceptual es un intermediario y libera a
los usuarios del manejo del nivel interno.
Nivel Externo: el nivel externo interacta directamente con el usuario (usuarios

finales o programas de aplicacin). Cambia los datos que llegan del nivel conceptual
a un formato y vista que son conocidos por el usuario. (Forouzan, 2003, p.272).
3.2.14.2 Base de datos relacional
Para describir los niveles lgico y de vistas de una base de datos es necesario
hacer uso de un modelo de datos. Un modelo de datos no es ms que un conjunto de
herramientas conceptuales que sirven para describir los datos, sus relaciones, su
semntica y sus limitaciones. El modelo de datos que ha tenido mayor aceptacin es
el Modelo Relacional.
92
El modelo Relacional de datos fue propuesto por E.F. Codd del IBM San Jos
Research Laboratory en 1969. Este modelo es el que siguen las llamadas bases de
datos relacionales y se basa en las siguientes caractersticas:
a. Los datos se conciben agrupados en forma de tablas que tienen

asignado un nombre nico. Cada fila de una de esas tablas establece
una relacin entre un conjunto de valores.
b. Los operadores que se utilizan para tratar los datos generan nuevas
tablas a partir de las existentes.
c. Toda tabla debe disponer de una columna o conjunto de columnas que
permitan identificar inequvocamente cada una de sus filas; estas
componen la llamada clave principal de la tabla. Los valores de la
clave principal de una tabla no se pueden repetir en esa tabla.
d. Las tablas de una base de datos relacional no se presentan aisladas,
sino que unas se refieren a otras mediante la definicin de vnculos de
tipo jerrquico entre ellas. El vnculo de referencia entre dos tablas se
establece mediante columnas de idnticos tipos de datos en las dos
tablas y la referencia de una fila de una tabla, a otra de la otra tabla, se
produce cuando se tiene el mismo valor para ambas. (Mora y Zorrilla,
2003. pp. 8-10)
Como caracterstica importante conviene observar que es la propia

informacin de la base de datos la que se usa para establecer las conexiones entre
tablas.
3.2.14.3 Sistema Gestor de Bases de Datos
Un Sistema Gestor de Bases de Datos (SGBD) es un conjunto de programas,

procedimientos y lenguajes que proporcionan a los usuarios las herramientas
necesarias para operar con una base de datos. Por tanto, el SGBD acta como un
93
intermediario entre los usuarios y los datos. Este, se compone de un lenguaje de
definicin de datos, de un lenguaje de manipulacin de datos y de un lenguaje de
consulta.
Un SGBD realiza varias funciones importantes que garantizan la integridad y

la consistencia de los datos de una base de datos. La mayora de estas funciones son
transparentes para los usuarios finales, y casi todas pueden realizarse slo mediante
un SGBD. Estas funciones incluyen la administracin de un diccionario de datos, la
administracin del almacenamiento de datos, transformacin y presentacin de los
datos, administracin de la seguridad, control de acceso a usuarios mltiples,
administracin de respaldos y recuperacin, administracin de la integridad de los
datos, lenguajes de acceso a base de datos e interfaces de programacin de
aplicaciones e interfaces de comunicacin con base de datos. (Rob y Coronel, 2004,
p. 21).
Existe una gran variedad de herramientas para manejo de bases de datos y

prcticamente la totalidad de ellas trabajan con SQL (Structured Query Language o
Lenguaje Estructurado de Consultas), que es el lenguaje de programacin de las bases
de datos, y es el ms utilizado para construir las consultas a bases de datos
relacionales. Los distintos gestores se valen de SQL para realizar las distintas
operaciones de bsqueda, interrelacin, presentacin, etc. As pues se puede trabajar
directamente con las bases de datos mediante SQL, aunque resulta mucho ms fcil e
intuitivo realizar este trabajo a travs de un gestor, como Microsoft Access, MySQL,
ORACLE, etc.
3.2.15 ORACLE
Oracle es un sistema gestor de base de datos relacional, fabricado por Oracle

Corporation. Es considerado como uno de los sistemas de bases de datos ms
94
completos, destacando su soporte de transacciones, estabilidad, escalabilidad y
soporte multiplataforma.
Dentro de las versiones de Oracle, se encuentra Oracle 10g. Este es un potente

sistema de gestin de bases de datos relacionales (RDBMS) que proporciona, adems
de un motor de base de datos, numerosas herramientas para el usuario, el
desarrollador y el administrador. Estas herramientas emplean un lenguaje comn:
SQL.
Oracle permite gestionar los datos de una aplicacin basndose en una lgica
que se ha convertido en un estndar: el modelo relacional. Con Oracle, se puede
asociar al SQL un lenguaje procedimental, el PL/SQL, que aade numerosas
posibilidades para la manipulacin de los datos.
Desde la versin 8i, el sistema de gestin de bases de datos de Oracle

propone, como opcin, un nuevo mtodo de gestin de la informacin en la empresa
a travs de la implementacin del modelo objeto-relacional. El objetivo de este
mtodo es simplificar el modelado de los datos permitiendo el almacenamiento y la
manipulacin de nuevos tipos de datos. Estos objetivos reutilizables, propios de cada
sector de actividad o de cada empresa, deben permitir un modelado ms eficiente.
La implantacin de este modelo a travs de las extensiones del lenguaje SQL

permite una migracin flexible entre el modelo relacional puro de las versiones
anteriores y este nuevo modelo objeto-relacional. (Gabillaud, 2005. pp. 5-6).
3.2.16 Sybase Powerdesigner
Es una herramienta que combina distintas tcnicas estndar (modelado de

aplicacin a travs de UML, tcnicas de modelado de procesos empresariales y
tcnicas tradicionales de modelado de base de datos) junto con las herramientas lder
95
de desarrollo (como .NET, Sybase WorkSpace, Sybase Powerbuilder, Java y Eclipse),
con el fin de ofrecer soluciones de anlisis de negocio y diseo de bases de datos
formales al ciclo de vida tradicional para el desarrollo de software. Y adems
funciona con la mayora de los sistemas manejadores de bases de datos relacionales
de hoy en da.
Entre otras caractersticas, esta herramienta permite generar de manera rpida

los diagramas UML (diagramas de casos de uso, de actividades, de clases, de
secuencia, de paquetes, etc.) para representar los requisitos y el diseo de la
arquitectura del sistema. Tambin, permite disear y generar el esquema de la base de
datos a travs del modelamiento conceptual y fsico de las bases de datos
relacionales.
3.2.17 Macromedia Dreamweaver 8
Dreamweaver 8 es un editor de HTML, diseado para desarrolladores

profesionales, para disear, codificar y desarrollar sitios, pginas y aplicaciones Web.
Esta herramienta permite crear sitios de forma totalmente grfica, a travs de un
entorno de edicin visual; y dispone de funciones para acceder al cdigo HTML
generado.
Las funciones de edicin visual de Dreamweaver permiten crear pginas de

forma rpida, sin escribir una sola lnea de cdigo, ya que se pueden visualizar todos
los elementos del sitio y se pueden arrastrar desde un panel fcil de usar directamente
hasta un documento. Dreamweaver tambin ofrece un entorno de codificacin con
todas las funciones, que incluye herramientas para la edicin de cdigo (tales como
coloreado de cdigo y terminacin automtica de etiquetas) y material de referencia
de lenguajes sobre hojas de estilos en cascada (CSS), JavaScript, y ColdFusion
Markup Language (CFML), entre otros.
96
Adems del cdigo HTML, Dremweaver puede administrar hojas de estilos
CSS y darle dinamismo a las pginas con JavaScripts. Tambin integra un cliente
FTP (File Tranfer Protocol) para descargar los sitios Web en un servidor y permite
integrar todas las funciones para crear sitios dinmicos, basados en bases de datos y
empleando tecnologas de servidor como CFML, ASP.NET, ASP, JSP y PHP.
3.2.18 XAMPP
XAMPP es software libre y es el acrnimo de X (para cualquiera de los

sistemas operativos), Apache, MySql, PHP, Perl. Consiste principalmente en un
paquete que contiene el servidor Web Apache, la base de datos MySql y los
intrpretes para los lenguajes PHP y Perl. Tambin incluye otros mdulos como
OpenSSL y phpMyAdmin. Este programa es independiente de la plataforma en la
cual se est ejecutando y est liberado bajo la licencia GNU. Adems, acta como un
servidor Web libre, fcil de usar y capaz de interpretar pginas Web dinmicas.
Existen versiones para GNU/Linux (testeado para SuSE, RedHat, Mandrake y
Debian), Windows (Windows 98, NT, 2000, XP y Vista), MacOS X y Solaris
(desarrollada y probada con Solaris 8, probada con Solaris 9).
3.2.19 Software Libre
Es aquel software, producto o desarrollo a medida, que se distribuye bajo una

licencia, segn la cual el autor cede una serie de libertades bsicas al usuario en el
marco de un acuerdo de concesin. Estas libertades de los usuarios del software,
recogidas en la filosofa de la Fundacin para el Software Libre (Free Software
Foundation), son: la libertad de usar el programa con cualquier propsito; la libertad
de estudiar cmo funciona el programa y adaptarlo a sus necesidades; la libertad de
distribuir copias; y la libertad de mejorar el programa y hacer pblicas las mejoras a
los dems, de modo que toda la comunidad se beneficie. (Martnez, J, 2007, pp. 15-
16).
97
Estas libertades del software libre tienen como consecuencia que la persona
que utilice este tipo de programas informticos estar a salvo de ser controlado por
otros a travs de esos programas. Ya que podr utilizar los programas para lo que
quiera, de forma legal y libremente. As como tambin estudiar cmo est construido,
para tener la seguridad e independencia que le proporciona conocer exactamente lo
que hace; e incluso podr modificar el programa para mejorarlo o adaptarlo a sus
necesidades particulares. Adems, podr distribuir esos programas informticos a los
dems de forma legal y, por lo tanto, no se ver inmerso en dilemas morales entre la
ley y su propio espritu de colaboracin. Y por ltimo, podr compartir las mejoras
que l mismo haya introducido y beneficiarse a su vez de las mejoras que otros hayan
hecho y distribuido.
3.3 Bases Legales
3.3.1 Decreto 3390 sobre el uso del software libre.
El decreto N 3390 publicado en Gaceta Oficial N 38.095, de fecha

28/12/2004, establece el uso de Software Libre para la Administracin Pblica
Nacional Venezolana. Ms especficamente en su primer artculo:
Artculo 1. La Administracin Pblica Nacional emplear prioritariamente

Software Libre desarrollado con Estndares Abiertos, en sus sistemas,
proyectos y servicios informticos. A tales fines, todos los rganos y entes de la
Administracin Pblica Nacional iniciarn los procesos de migracin gradual y
progresiva de stos hacia el Software Libre desarrollado con Estndares
Abiertos.
De esta manera, el Ejecutivo nacional establece que es prioridad del Estado

incentivar y fomentar la produccin de bienes y servicios para satisfacer las
necesidades de la poblacin, mediante el uso de estas herramientas desarrolladas con
estndares abiertos para robustecer la industria nacional, aumentando y aprovechando
sus capacidades y fortaleciendo la soberana del pas.
98
3.4 Definicin de Trminos
Arquitectura: Estructura organizativa que incluye su descomposicin en partes,

conectividad, mecanismos de interaccin y principios de gua que proporcionan
informacin sobre el diseo del mismo. (Jacobson, Booch y Rumbaugh, 2000, p.
130).
Artefacto: Pieza de informacin utilizada o producida por un proceso de desarrollo

de software, como un documento externo o el producto de un trabajo. Un artefacto
puede ser un modelo, una descripcin o un software. (Jacobson, Booch y Rumbaugh,
2000, p. 131).
Base de Datos: Coleccin de datos interrelacionados que son almacenados en un

soporte informtico. (Cobo y Gmez, 2005, p.316).
Sistema gestor de base de datos: Paquete de software para la gestin de las bases de
datos; en particular, para almacenar, manipular y recuperar datos de un computador.
(Batini y Navathe, 2005, p.4).
SQL: Es un lenguaje de definicin y manipulacin de datos para bases de datos

relacionales. Es un lenguaje de definicin porque permite definir la estructura de las
tablas que componen la base de datos, y de manipulacin porque permite efectuar
consultas y realizar operaciones como insercin, borrado, y actualizacin de los datos
que contiene. (Cobo y Gmez, 2005, p.316).
Caso de uso: Es una secuencia de acciones que el sistema lleva a cabo para ofrecer
algn resultado de valor para un actor. Un actor puede ser una persona humana, un
dispositivo de hardware, u otro sistema. Los actores utilizan el sistema interactuando
con los casos de uso. (Jacobson., 2000, p.54).
99
Cliente: Equipo que los usuarios individuales utilizan para conectarse a la red y
solicitar servicio a los servidores. (Cobo y Gmez, 2005, p.6).
Navegador Web: Programa informtico que permite la comunicacin con un

servidor para acceder a los recursos de internet e interpretar las etiquetas de los
documentos HTML. (Lpez y Alonso, 2007, p. 105).
Servidor Web: Mquina equipada con el software servidor que utiliza el protocolo
de internet HTTP para responder a las peticiones de los clientes Web en una red
TCP/IP. (Laporta y Miralles, 2005, p. 286).
100
CAPITULO IV
MARCO METODOLGICO
En este captulo se detalla la metodologa que permiti llevar a cabo el

desarrollo de la investigacin. Es decir, en esta seccin se describe la manera como se
realiz el estudio para responder al problema planteado, incluyendo aspectos como el
tipo, nivel y diseo de la investigacin, la poblacin y muestra objeto de estudio, y las
tcnicas empleadas para recolectar y analizar los datos.
4.1 Tipo y Nivel de la Investigacin.
El tipo de investigacin queda definido en correspondencia con el objetivo

general del trabajo investigativo, por tal razn se puede afirmar que el trabajo
desarrollado es de tipo proyectivo, dicha valoracin se hace teniendo presente la
definicin dada por Hurtado (2000) la cual expresa que esta es:
la elaboracin de una propuesta o de un modelo como solucin a un

problema o necesidad de tipo prctico a partir de un diagnstico preciso de
las necesidades del momento, los procesos explicativos o generadores
involucrados y las tendencias futuras. (p. 325).
Por otra parte tambin seala la autora citada que La investigacin proyectiva
se ocupa de disear o crear propuestas dirigidas a resolver determinadas
situaciones (p. 49). Se puede inferir de las citas realizadas que una investigacin
proyectiva busca dar una alternativa de solucin a los estados problemticos que se
plantean.
En correspondencia con el tipo, el nivel al cual pertenece la investigacin es el

Nivel Comprensivo, debido a que sta busca los orgenes de la problemtica, sus
101
efectos y lo compara con otros hechos ocurridos para determinar los factores
causantes de la situacin. Segn Hurtado (2000) el nivel comprensivo alude a la
explicacin de las situaciones o causas que generan eventos (p.71).
4.2 Diseo de la Investigacin
El diseo de investigacin constituye el plan general del investigador para

obtener respuestas a sus interrogantes o comprobar la hiptesis de investigacin. Para
Namakforoosh (1995) citado por Hurtado, el diseo de la investigacin es un arreglo
de condiciones para recopilar la informacin de modo que permita alcanzar el
objetivo de la investigacin a travs de un procedimiento econmico (p. 149) El
diseo de investigacin desglosa las estrategias bsicas que el investigador adopta
para generar informacin exacta e interpretable. Hurtado (Ob.Cit.) seala que:
corresponde a la estructura de la investigacin, a la forma como la

investigacin va a ser desarrollada, a la manera como la indagacin es
concebida a fin de obtener respuestas a las interrogantes...adems le seala al
investigador lo que tiene que hacer y cmo hacerlo.... (p.407).
En correspondencia con la definicin antes citada el diseo de la presente

investigacin corresponde a una investigacin de campo. La cual es definida por
Arias, F. (2006) como:
Aquella que consiste en la recoleccin de datos directamente de los sujetos

investigados, o de la realidad donde ocurren los hechos (datos primarios),
sin manipular o controlar variable alguna, es decir, el investigador obtiene,
la informacin pero no altera las condiciones existentes. (p.31).
Para este proyecto, los datos fueron recogidos directamente del comedor
universitario; es decir, la informacin fue suministrada principalmente por el personal
que labora en el rea administrativa del comedor universitario de la Universidad de
Oriente Ncleo de Monagas. Pues ellos son los encargados de realizar todos los
102
procedimientos para la prestacin del servicio de alimentacin y por lo tanto conocen
a detalle el funcionamiento del rea bajo estudio.
Adems, la informacin pudo ser recabada de material impreso y electrnico, y

de registros provenientes de las actividades cotidianas realizadas por el comedor
universitario, es decir de datos procedentes de fuentes secundarias. Respecto a esto,
Arias, F. (2006) afirma que:
En una investigacin de campo tambin se emplean datos secundarios,

sobre todo los provenientes de fuentes bibliogrficas a partir de los cuales
se construye el marco terico. No obstante, son los datos primarios
obtenidos a travs del diseo de campo, los esenciales para el logro de los
objetivos y la solucin del problema planteado. (p.31).
4.3 Poblacin y Muestra.
La poblacin, segn Arnau, J. (1981) se refiere al conjunto de elementos,

seres o eventos, concordantes entre s en cuanto a una serie de caractersticas, de los
cuales se desea obtener alguna informacin. (p.248). En efecto, la poblacin objeto
de estudio en esta investigacin es finita, conocida y est representada por cinco (5)
individuos que laboran en la rea administrativa del comedor universitario de la UDO
ncleo de Monagas. Este conjunto de personas son las encargadas de llevar a cabo las
actividades y procedimientos administrativos para prestar el servicio de alimentacin
y conocen la realidad del rea bajo estudio; por lo tanto son las ms idneas para ser
seleccionadas con el fin de estudiarlas y obtener de ellas la informacin necesaria
para el desarrollo del nuevo sistema de informacin automatizado.
Una vez determinada con precisin las unidades de estudio que conforman a
la poblacin o universo de investigacin, se procede a delimitar la muestra. Moreno,
M. (1993) expresa que la muestra es una parte de la poblacin en estudio,
seleccionada de manera que en ella queden representadas las caractersticas que
distinguen a la poblacin de la que fue tomada (p. 9). Sin embargo, Arias, F. (2006)
103
comenta lo siguiente: Si la poblacin, por el nmero de unidades que la integran,
resulta accesible, en su totalidad, no ser necesario extraer una muestra. En
consecuencia, se podr investigar u obtener datos de toda la poblacin objetivo. (pp.
82-83).
En tal sentido, por ser la poblacin objeto de estudio finita y pequea, se

tomaron como unidades de estudio a todo el conjunto que la conforma. Lo que se
traduce que la muestra vendr a ser igual que la poblacin, es decir, la muestra tendr
un tamao de cinco (5) individuos o empleados del rea administrativa del comedor
universitario de la Universidad de Oriente ncleo de Monagas, entre los cuales se
mencionan: el administrador del rea, el nutricionista, la secretaria y los encargados
del almacn o despensa.
4.4 Tcnicas e Instrumentos de Recoleccin de Datos.
Las tcnicas de recoleccin de datos son las distintas formas o maneras de

obtener la informacin que ser de utilidad para un estudio en particular. En el caso,
de la investigacin realizada para llevar a cabo el desarrollo de un sistema Web para
la Planificacin y el control del servicio de alimentacin de la Universidad de Oriente
Ncleo de Monagas se emplearon distintas tcnicas para recabar informacin, como
la observacin directa, la entrevista no estructurada, la revisin documental; con el fin
de estudiar los distintos aspectos del problema y alcanzar los objetivos propuestos.
Con respecto a la tcnica de observacin directa, Tamayo y Tamayo (2003)

establecen que es aquella en la cual el investigador puede observar y recoger datos
mediante su propia observacin. (p.183). En esta investigacin se realiz
observacin directa en el rea de trabajo para obtener algn tipo de informacin sobre
el funcionamiento de los procesos administrativos llevados a cabo para la prestacin
del servicio de alimentacin de la Universidad de Oriente Ncleo de Monagas.
104
Tambin, para obtener informacin del lugar objeto de estudio, se aplicaron
entrevistas no estructuradas al personal y a empleados que laboran en el rea
administrativa del comedor universitario. Arias, F. expresa que en este tipo de
entrevista no se dispone de una gua de preguntas elaboradas previamente. Sin
embargo, se orienta por unos objetivos preestablecidos, lo que permite definir el tema
de la entrevista. (p. 74). Para esta investigacin, el entrevistador prepar
previamente una especie de gua con los puntos bsicos sobre los cules necesitaba
recabar informacin. A medida que iba transcurriendo la entrevista se iban realizando
ciertas anotaciones en una libreta, sobre las respuestas emitidas por los entrevistados.
Adicional a las tcnicas ya mencionadas se utiliz la revisin documental o

anlisis de fuentes documentales, para complementar el trabajo de recoleccin y
ayudar a asegurar una investigacin completa. Para Hurtado, J. (2007) esta tcnica
es un proceso mediante el cual el investigador recopila, analiza, selecciona y extrae
informacin de diversas fuentes, acerca de un tema en particular, con el propsito de
llegar al conocimiento y comprensin ms profundo del mismo. (p. 89). En lo que
respecta a esta investigacin, se consultaron fuentes bibliogrficas, tesis, internet y
otros documentos relacionados con los procedimientos ejecutados en el rea bajo
estudio, como manuales de normas y procedimientos, reglamentos, formatos y
reportes impresos, con el fin de recabar informacin que aportara los conocimientos
necesarios para llevar a cabo el desarrollo de este proyecto.
4.5 Tcnicas de Anlisis de Datos.
Para el anlisis e interpretacin de la informacin recolectada fue necesario

emplear el Anlisis de Contenido. Esta tcnica, segn Hurtado, J. (2007) puede ser
utilizada en investigaciones descriptivas, cuando se pretende hacer un diagnstico y
agrupar contenidos significativos de una serie de entrevistas, conversaciones u
observaciones (p. 57). Esto sirvi para organizar la informacin extrada, y as
105
describir aspectos importantes para dar respuesta a algunos de los objetivos
planteados.
4.6 Diseo Operativo.
Para llevar a cabo la investigacin y lograr los objetivos planteados, se utiliz

la metodologa RUP como gua de desarrollo. Esta genera una serie de documentos o
artefactos a lo largo del proyecto para utilizarlos hasta obtener el producto final o
sistema. Con dicha metodologa se busca desarrollar de manera ordenada y eficiente
un sistema Web para la planificacin y control del servicio de alimentacin prestado
por el comedor universitario de la Universidad de Oriente Ncleo de Monagas.
Cabe agregar, que junto a la metodologa RUP se emple la herramienta

UML, para realizar el modelado del sistema a travs de los diferentes diagramas que
este ofrece. Adems, para desarrollar el sistema se siguieron las tres primeras fases en
la que la metodologa RUP divide el proceso de desarrollo de software, abarcando
solo tres (3) iteraciones de la tercera fase (fase de construccin), por lo que a pesar de
llegar hasta esta fase no se realiz la codificacin completa del sistema.
A continuacin se presenta la descripcin de las etapas en las que se ha

dividido el proyecto para llevar a cabo el desarrollo del sistema. Lo que incluye las
diferentes actividades realizadas en cada una de ellas:
Etapa I. Estudio del Negocio
En esta primera etapa se realiza el modelado del negocio con el fin de conocer
y entender los procesos que se llevan a cabo en el comedor universitario, comprender
la estructura y la dinmica de la organizacin bajo estudio, y tambin entender los
problemas actuales e identificar posibles mejoras. Para esto se visit el lugar,
pudiendo observar directamente las actividades cotidianas que all se realizan. Y
106
aplicando, adems, entrevistas no estructuradas al personal que labora en el rea
administrativa del comedor, quienes conocen a detalle todos los procedimientos que
se ejecutan en el negocio.
El modelado del negocio utiliza el modelo de casos de uso del negocio, para
describir los procesos llevados a cabo en la organizacin y los actores involucrados.
Tambin abarca el modelo del dominio que captura los objetos ms importantes en el
contexto del sistema; y emplea los diagramas de actividad y de clases de la
herramienta UML.
Adems, en esta etapa se define el alcance del proyecto, se realiza una

estimacin del tiempo para realizar el proyecto y una lista de riesgos que pudieran
obstaculizar el desarrollo del nuevo sistema. Tambin, se define el prototipo de
interfaz de usuarios, que es el medio a travs del cual los usuarios podrn interactuar
con el nuevo sistema.
El conjunto de artefactos de RUP que se elaboraron en esta primera etapa, y

que fueron utilizados durante todo el proyecto son los siguientes:
- Plan de iteracin.
- Un documento visin, donde estn definidas las caractersticas del producto a
desarrollar.
- Modelo del negocio.
- Especificacin de casos de uso del negocio.
- Documento plan de riesgos.
La consecucin de las actividades descritas anteriormente permiti alcanzar

los objetivos uno, y dos del proyecto. Lo que dio a conocer cmo funciona
actualmente el rea bajo estudio, determinando su problemtica actual y
estableciendo as el alcance del proyecto.
107
Etapa II. Diseo de la Arquitectura
En esta etapa se define y analiza los requerimientos funcionales del nuevo

sistema, empleando los diagramas de casos de usos de la herramienta UML y se
especifican adems los requisitos de calidad del software. Tambin se disea la
arquitectura del sistema a travs de la elaboracin de modelos de diseos en UML,
como los diagramas de clases y diagramas de despliegue.
En esta etapa se obtienen los siguientes resultados o artefactos:
- Especificacin de casos de uso del sistema.

- Especificaciones complementarias.
- Arquitectura del sistema.
Con la realizacin de las actividades descritas anteriormente se logr alcanzar

los objetivos tres y cuatro. Por lo que al final de esta etapa se tienen definidos tanto
los requerimientos funcionales como los no funcionales, y la arquitectura del sistema.
Etapa III. Construccin del Software
En esta ltima etapa se lleva a cabo, de forma iterativa, la codificacin del

sistema de acuerdo al diseo realizado del mismo, de tal manera que cumpla con los
requisitos establecidos. Tambin, se refinan los casos de uso y se realizan pruebas a
los mdulos del sistema que fueron codificados, para comprobar el buen
funcionamiento de los mismos.
Con la realizacin de las actividades anteriores se logr alcanzar el ltimo

objetivo del proyecto. Obteniendo los siguientes resultados:
- Un prototipo inicial del sistema.
108
- Documento de casos de prueba
- Documento glosario.
A continuacin se muestra en el Cuadro 4 un resumen de las etapas para llevar

a cabo el desarrollo del proyecto con sus respectivas actividades, y as cumplir con
los objetivos especficos establecidos:
109
Cuadro 4. Cuadro Operativo
Metodologa
Etapas Objetivos Especficos Actividades Asociadas
RUP
- Realizar entrevistas no
- Describir el
estructuradas al personal del
funcionamiento actual de
rea administrativa de
los procesos llevados a cabo
comedor.
dentro del servicio de
- Observacin directa del
alimentacin prestado por la
rea bajo estudio.
Universidad de Oriente
- Revisin de documentos.
Etapa I: Ncleo de Monagas.
- Realizar el modelado del
Estudio del Inicio
negocio y las
Negocio - Determinar los problemas
especificaciones de casos de
y necesidades actuales
uso del negocio.
relacionados con la
- Elaborar los documentos
planificacin y control del
visin, plan de riesgos y plan
servicio prestado por el
de iteracin.
comedor universitario.
- Realizar prototipos de
interfaces de usuario.
- Definir los requerimientos
de informacin del sistema,
a travs del estudio
realizado al comedor - Elaborar las
universitario y especificaciones de casos de
considerando las uso del sistema.
Etapa II:
necesidades de los usuarios
Diseo de la Elaboracin
del rea administrativa del - Especificaciones
Arquitectura
mismo. complementarias.
- Disear una arquitectura - Arquitectura del software.

slida para el sistema, que
cumpla con los
requerimientos definidos.
110
Cuadro 4. Cuadro Operativo (Continuacin)
Metodologa
Etapas Objetivos Especficos Actividades Asociadas
RUP
- Refinamiento de casos de
- Construir un prototipo
uso del sistema.
Etapa III: inicial, de acuerdo a la
- Prototipo inicial del
Construccin arquitectura diseada y a Construccin
sistema.
del Software los requisitos especificados
- Elaborar casos de prueba.
del sistema.
- Documento glosario.
111
CAPITULO V
RESULTADOS
En este captulo se contemplan los resultados obtenidos, luego de haber

aplicado la metodologa RUP como proceso de desarrollo de software para el logro de
los objetivos propuestos en el presente trabajo de investigacin. Antes de presentar en
detalle estos resultados, se muestra un resumen de estos por cada uno de los objetivos
especficos establecidos:
- Para describir el funcionamiento actual del comedor universitario, fue

necesario aplicar una serie de tcnicas de recoleccin de datos, como la
entrevista no estructura, la observacin directa y revisin documental. Con
dicha informacin recabada, fue realizado el documento modelado del
negocio, donde se describi de manera general, a travs de diagramas UML
(Diagramas de casos de uso, de actividad y de clases), los procedimientos
llevados a cabo en el comedor universitario y el conjunto de actores que
intervienen en dichos procesos. Adems, cada uno de los procesos
identificados fueron descritos de manera detallada en el artefacto
especificacin de casos de uso del negocio; entre estos procesos se
encuentran: planificar mens alimentarios, realizar pedidos de insumos,
registrar las entradas de insumos en almacn, solicitar los insumos requeridos
en la despensa para preparar el men del da, registrar el acceso de
comensales al rea de servicio y realizar reportes mensuales de costos.
- Tambin con el estudio realizado al negocio se identificaron los problemas y
las necesidades actuales del grupo de usuarios del rea administrativa del
comedor universitario relacionadas con los procesos de planificacin y control
del servicio de alimentacin. Para esto se realiz el artefacto denominado
112
documento visin, en el que adems de exponerse la problemtica presentada
en el rea objeto de estudio, se fij una visin del producto, especificando las
necesidades y caractersticas del mismo. Adems se crearon los artefactos
plan de iteracin general y plan de administracin de riesgos, donde se
estableci la planificacin del conjunto de actividades involucradas para el
desarrollo del proyecto de software y la gestin de los riesgos que pudieron
afectar la correcta realizacin del mismo.
- La definicin de los requisitos de informacin del sistema, se logr a travs de
la elaboracin de los artefactos de especificacin de casos de uso del sistema;
los cuales permitieron capturar y analizar los requisitos funcionales, a travs
de los diagramas de casos de uso y de secuencias de la herramienta UML y de
las interfaces de usuarios. Entre las funcionalidades capturadas se mencionan:
registrar insumos, conformar mens alimentarios, elaborar planificacin
alimentaria, generar hoja de pedido, registrar existencia de artculo, registrar
entrada y salida de artculos de almacn, generar resumen de costos, elaborar
y consultar solicitudes del servicio del comedor, controlar acceso de
comensales, administrar usuarios del sistema y autenticar usuario. Adems de
estos, fueron definidos otros requisitos adicionales (principalmente, requisitos
no funcionales) en el documento de especificaciones suplementarias, los
cuales fueron clasificados segn el modelo FURPS+ (funcionalidad,
usabilidad, confiabilidad, desempeo, capacidad de soporte, entre otros).
- Por su parte, el diseo arquitectnico del software qued plasmado en el
artefacto Arquitectura del sistema. Dicho diseo se realiz empleando
diferentes vistas o modelos que muestran diferentes aspectos de la
arquitectura del sistema; entre los que se mencionan: la vista lgica que
muestra las clases, sus relaciones, operaciones y atributos ms importantes y
el cual est representado fundamentalmente por el modelo de clases; la vista
de datos, que describe los elementos principales del modelo de datos como
tablas, vistas e ndices, y est representado por los modelos conceptual, fsico
113
y de base de datos relacional; y por ltimo, la vista de despliegue, que muestra
la parte fsica de la arquitectura.
- Luego, a partir de la arquitectura diseada, se procedi a la codificacin de
algunas de las funcionalidades del sistema empleando ciertas herramientas de
programacin y desarrollo WEB, como el lenguaje HTML, JavaScript, PHP,
AJAX, la aplicacin Macromedia Dreamweaver, servidor Web Apache, el
manejador de base de datos ORACLE, entre otros. Y seguidamente, se
realizaron pruebas a los mdulos programados del software para comprobar el
correcto funcionamiento de los mismos. Todo esto con el fin, de cumplir con
el ltimo objetivo de la investigacin, es decir, el de construir un prototipo
inicial del sistema.
Ahora se describen en detalle, los resultados obtenidos en cada una de las

etapas descritas en el cuadro operativo, que permitieron alcanzar el desarrollo de un
sistema WEB para la planificacin y control del servicio de alimentacin prestado por
el comedor universitario de la Universidad de Oriente Ncleo de Monagas:
5.1 Etapa I. Estudio del Negocio.
Esta etapa estuvo enfocada a conocer y entender el funcionamiento del

comedor universitario y a establecer los requisitos de negocio que cubrir el sistema,
identificando todas las entidades que interactan con el mismo (personas, sistemas,
etc.). Para esto, se emplearon las tcnicas de recoleccin de datos, como las
entrevistas no estructuradas, la observacin directa y la revisin documental.
Con ayuda de las entrevistas no estructuras se pudo conocer directamente de

los empleados y trabajadores del comedor universitario la situacin actual de dicha
rea, detectando adems la problemtica y las necesidades que se presentan al prestar
el servicio de alimentacin a la comunidad universitaria. En combinacin con esta
tcnica se utiliz la observacin directa, la cual permiti visualizar como el personal
114
del comedor universitario realizaba sus labores cotidianas, con la finalidad de
entender su funcionamiento. Adems, se realiz la revisin documental del manual de
organizacin y procedimientos, donde se encuentran las actividades que deben
realizar el personal y los formatos de los documentos utilizados en los procesos que se
llevan a cabo en el rea administrativa del comedor.
Toda esta informacin obtenida a travs de la combinacin de las tcnicas

antes mencionadas, sirvi para elaborar el documento modelado del negocio y sus
respectivas especificaciones de casos de uso; y el documento visin, donde se
establece el alcance y por ende los requerimientos del sistema. Adems de estos, se
pudieron generar otros documentos o artefactos de la metodologa RUP, los cuales
son detallados a continuacin:
115
UDO - DIRECCIN DE COMPUTACIN
PROYECTO:
Plan de Iteracin General

Versin 1.0
116
UDO - DIRECCION DE COMPUTACION
PROYECTO: Sistema Web para la Planificacin y VERSIN: 1.0

Control del Servicio de Alimentacin Prestado por el
Comedor Universitario de la Universidad de Oriente
Ncleo de Monagas.
FECHA: Marzo 2009
NOMBRE DEL DOCUMENTO: Plan de Iteracin General.
Plan de Iteracin
1. Plan
1.1 Plan General
Cuadro 5. Plan General
PROYECTO: Desarrollo de un sistema Web para la planificacin y control del servicio
de alimentacin prestado por el comedor universitario de la universidad
de oriente ncleo de Monagas.
Fecha Inicio: 24/03/2008
Fecha Final: 19/06/2009
ITERACIN PROCESO FECHA FECHA
INICIO FINAL
ITERACIN 1 Documento Visin, Lista de Riesgos y Plan de 21/04/08 27/05/08
Iteracin General.
ITERACION 2 Administrar insumos. Administrar mens 28/05/08 09/07/08
alimentarios.
ITERACIN 3 Planificacin alimentaria. 10/07/08 25/09/08
ITERACIN 4 Elaborar y consultar solicitudes de servicio del 26/09/08 06/11/08
comedor universitario. Controlar acceso de
comensales, Registrar Stock de artculos en
almacn.
ITERACIN 5 Registrar Entrada de artculos en almacn. 07/11/08 18/12/08
ITERACIN 6 Registrar Salida de artculos en almacn. 19/12/08 13/02/09
ITERACIN 7 Generar Resumen de Costos. Administrar 16/02/09 27/03/09
usuarios. Autenticar usuario.
ITERACIN 8 Mantenimientos y configuracin de semanas. 30/03/09 24/04/09
Administrar insumos. Administrar mens
alimentarios.
ITERACIN 9 Planificacin alimentaria. Elaborar y consultar 27/04/09 22/05/09
solicitudes de servicio del comedor universitario.
ITERACIN Controlar acceso de comensales. Administrar 25/05/09 19/06/09
10 usuarios. Autenticar usuario.
Confidencial UDO - Centro de Computacin Pg. 117


Ncleo de Monagas.
FECHA: Marzo 2009
1.2 Plan fase
Diagrama 1. Plan de Fase.



Ncleo de Monagas.
FECHA: Marzo 2009
1.3 Plan fase por Iteraciones
Diagrama 2. Segunda Iteracin.

Diagrama 3. Tercera Iteracin.



Ncleo de Monagas.
FECHA: Marzo 2009
Diagrama 4. Cuarta Iteracin.

Diagrama 5. Quita Iteracin.



Ncleo de Monagas.
FECHA: Marzo 2009
Diagrama 6. Sexta Iteracin.

Diagrama 7. Sptima Iteracin.



Ncleo de Monagas.
FECHA: Marzo 2009
Diagrama 8. Octava Iteracin.

Diagrama 9. Novena Iteracin.



Ncleo de Monagas.
FECHA: Marzo 2009
Diagrama 10. Dcima Iteracin.



Ncleo de Monagas.
FECHA: Marzo 2009
1.4 Plan de Reuniones

Cuadro 6. Cronograma de Reuniones
CRONOGRAMA DE REUNIONES
PROYECTO: Desarrollo de un sistema Web para la planificacin y control del servicio de

alimentacin prestado por el comedor universitario de la universidad de oriente
ncleo de Monagas.
ITERACION PROCESO FECHA FECHA
INICIO FINAL
ITERACIN 1 Documento Visin, Lista de Riesgos y Plan de 26/05/08 27/05/08
Iteracin General.
ITERACION 2 Administrar insumos. Administrar mens 27/06/08 27/06/08
alimentarios.
ITERACIN 3 Planificacin alimentaria. 11/08/08 11/08/08
ITERACIN 4 Elaborar y consultar solicitudes de servicio del 27/10/08 27/10/08
comedor universitario. Controlar acceso de
comensales, Registrar Stock de artculos en
almacn.
ITERACIN 5 Registrar Entrada de artculos en almacn. 08/12/08 08/12/08
ITERACIN 6 Registrar Salida de artculos en almacn. 03/02/09 03/02/09
ITERACIN 7 Generar Resumen de Costos. Administrar usuarios. 17/03/09 17/03/09
Autenticar usuario.
ITERACIN 8 Mantenimientos y configuracin de semanas. 07/04/09 07/04/09
Administrar insumos. Administrar mens
alimentarios.
ITERACIN 9 Planificacin alimentaria. Elaborar y consultar 05/05/09 05/05/09
solicitudes de servicio del comedor universitario.
ITERACIN 10 Controlar acceso de comensales. Administrar 02/06/09 02/06/09
usuarios. Autenticar usuario
2 Recursos
Se necesita realizar reuniones con los clientes y responsables del proyecto
para definir las bases de desarrollo del proyecto.
3 Criterio de Evaluacin
Se evaluar el lapso de tiempo que abarcar el sistema Web para la
Planificacin y Control del Servicio de Alimentacin prestado por el comedor
Universitario.
PROYECTO:
Documento Visin
Versin 1.0
125

Ncleo de Monagas.
FECHA: Noviembre 2008
NOMBRE DEL DOCUMENTO: Documento Visin.
Visin
1. Introduccin
1.1 Propsito
El propsito de este documento es la recoleccin, anlisis y definicin de las
caractersticas y necesidades para el desarrollo de un Sistema Web para la
Planificacin y Control del Servicio de Alimentacin Prestado por el Comedor
Universitario de la Universidad de Oriente Ncleo de Monagas. Con esto, el presente
documento servir de soporte para la ejecucin de dicho proyecto.
1.2 Alcance
Este documento se ocupa del sistema automatizado para la Planificacin y
Control del Servicio de Alimentacin Prestado por el Comedor Universitario de la
Universidad de Oriente Ncleo de Monagas. Dicho sistema ser desarrollado
utilizando herramientas tanto de Software Libre como propietario. Al utilizar
herramientas de Software Libre se estar cumpliendo con el Decreto Presidencial
3390.
El sistema abarcar a nivel general las siguientes funcionalidades:
Permitir la creacin y mantenimiento de los insumos y mens alimentarios;
considerando la informacin nutricional de los alimentos. Se podr realizar la
planificacin alimentaria de cada semana y generar la lista de los insumos requeridos
para la preparacin de los mens planificados. Tambin, permitir el registro de
comensales que acceden al comedor para aprovechar el servicio de alimentacin,
elaborar solicitudes de servicio del comedor en caso de eventos especiales, y adems
controlar las entradas y salidas de insumos del almacn o despensa.


Ncleo de Monagas.
2. Posicionamiento
2.1 Oportunidades de Negocio:
Las oportunidades que se presentan con el desarrollo de este proyecto son:
1. Agilizar el proceso de planificacin alimentaria. En ste se podr programar
mens variados, considerando los valores nutricionales requeridos para el
buen desempeo de los estudiantes en sus actividades acadmicas.
2. Controlar el acceso de comensales al rea de comedor, a travs de un registro
automatizado de cada estudiante que ingresa al mismo para el
aprovechamiento del servicio de alimentacin.
3. Contar con estimaciones ms certeras del nmero de estudiantes que asistirn
al comedor para realizar una planificacin de comidas ms aproximada a la
realidad.
4. Mayor disponibilidad y seguridad de la informacin manejada.
5. Mantener actualizado, el inventario de insumos del almacn o despensa.
6. Contar con datos ms confiables y certeros para la generacin de informes.
7. Mejorar la capacidad de respuesta ante las autoridades, logrando un mejor
desempeo en la entrega de informes por parte de la administracin del
8. Acceso rpido y sencillo a los datos, gracias a interfaces grficas sencillas y
amigables.
9. Fiabilidad de los datos permitiendo credibilidad por parte de la comunidad
universitaria, trabajadores y el gobierno central.
10. Actualizar las herramientas tecnolgicas, que permitan estar acorde a las
nuevas exigencias.


Ncleo de Monagas.
11. Generar estndares corporativos que permitan a la Universidad adaptarse al

cumplimiento del Decreto Presidencial 3390, el cual establece la utilizacin
prioritaria de software libre en las empresas pblicas.
2.2 Planteamiento del problema:

Cuadro 7. Planteamiento del problema.
El problema de - Planificar los mens alimentarios de manera semi-
manual.
- No contar con un medio para hacer una estimacin del
nmero de estudiantes que asistirn al comedor.
- Llevar un registro manual de las entradas de insumos en
almacn.
- No llevar un control de los insumos que salen del
almacn.
- Manejo de los datos de forma semi-manual produciendo
lentitud en cuanto a clculos y elaboracin y generacin
de informes o reportes de costos.
- La inexistencia de un sistema de informacin que posea
una base de datos nica y que permita la comunicacin
en red del rea administrativa del comedor con las reas
de almacn para monitorear el inventario de insumos.
Afecta a La comunidad universitaria, a los trabajadores de la UDO y a la
institucin ante el gobierno nacional.


Ncleo de Monagas.
Cuadro 6. Planteamiento del problema. (Continuacin)

Cuyo impacto es - Lentitud en la Generacin de la planificacin
alimentaria y que adems esta no est acorde con las
exigencias de las demandas actuales. Se estima por
comensal una cantidad de insumos por muy encima de
lo normal; pero sin embargo, en algunas oportunidades,
ciertos comensales quedan insatisfechos porque las
proporciones de platos de comidas no alcanzan para
todos los que asisten al comedor o en otras ocasiones las
comidas pueden exceder en cantidad al nmero de
comensales que fueron atendidos, generando gastos
innecesarios con desperdicios de alimentos, tiempo y/o
recursos.
- No tener actualizada las existencias de insumos en
almacn.
- Generacin de informacin no fiable.
- Retardo en la generacin y entrega de reportes a las
autoridades competentes.
Una adecuada solucin El desarrollo de un sistema automatizado que permita gestionar
sera los procesos administrativos que se llevan a cabo en el comedor
universitario, a fin de agilizar dichos procesos, para realizar una
planificacin alimentaria ms aproximada a la realidad, tomando
en cuenta la informacin nutricional de los alimentos. As como
tambin, un mejor control de los insumos adquiridos para
prestar el servicio de alimentacin.


Ncleo de Monagas.
2.3 Declaracin de Posicin del Producto:

Cuadro 8. Posicin del Producto.
Para Los trabajadores del rea del comedor universitario.
Quienes Llevan a cabo los procedimientos y actividades de planificacin
y administracin del servicio de alimentacin.
El Software Es una aplicacin WEB bajo el enfoque de Software Libre.
Que Permitir almacenar la informacin necesaria para realizar los
procesos que se llevan cabo en el rea de comedor, de manera
automatizada, permitiendo generar datos ms confiables,
agilizar la entrega y obtencin de resultados rpidamente.
No como Los procesos actuales que se llevan a cabo de manera manual,
haciendo tedioso los clculos y la obtencin de resultados.
Nuestro producto Permitir contribuir con el proceso de migracin hacia el
software libre establecido en el Decreto Presidencial 3390.
Adems de agilizar los procesos de planificacin y control que
se llevan a cabo en el rea administrativa del Comedor
Universitario.
3. Descripcin de participantes y usuarios

Para entregar un producto que se ajuste a las necesidades de los usuarios, se
requiere identificar e involucrar a todos los participantes en el proyecto como parte
del proceso de modelado de requerimientos. Tambin es necesario identificar a los
usuarios del sistema y asegurarse de que el conjunto de participantes en el proyecto
los representa adecuadamente.
En este apartado se muestra los roles y responsabilidades de los participantes
involucrados en el proyecto, as como las necesidades que se perciben tanto para ellos
como para los usuarios del sistema.


Ncleo de Monagas.
3.1. Roles y Responsabilidades de los Participantes

A continuacin se muestra los roles y responsabilidades de los participantes
involucrados en el proyecto.
Cuadro 9. Roles y Responsabilidades.
Rol Responsabilidad
Lder del Proyecto El Lder 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 Lder de proyecto
tambin establece un conjunto de prcticas que aseguran la
integridad y calidad de los artefactos del proyecto. Adems, el
Lder de proyecto se encargar de supervisar el establecimiento de
la arquitectura del sistema. Gestin de riesgos. Planificacin y
control del proyecto.
Analista de Sistemas Captura, especfica y valida requisitos, interactuando con el cliente
y los usuarios mediante entrevistas. Elabora el Modelo de Anlisis
y Diseo. Colabora en la elaboracin de las pruebas funcionales y
el modelo de datos.
Analista de procesos Es responsable de definir la arquitectura, definir los casos de uso y
de negocio. actores y la interaccin entre ellos.
Integrador Es el responsable de planear y realizar la integracin de elementos
de la Aplicacin.
Programador Construccin del Software. Colaboracin en la elaboracin de las
pruebas funcionales, modelo de datos y en las validaciones con el
usuario.
Especialista en Es responsable de realizar las pruebas del software cada vez que se
Pruebas (tester) realice una iteracin y las pruebas finales anotando los resultados
de esa comprobacin.


Ncleo de Monagas.
A nivel de los sistemas administrativos:

Cuadro 10. Participantes y Rol
Nombre Rol
Ing. Jess Chaparro Responsable General del Proyecto
Ing. Rosngela Garca Lder del Proyecto e Integrador
Br. Farias Luis Analista de Procesos de Negocio y de Sistemas, Programador
Br. Farias Luis Especialista en Pruebas (tester)
Usuarios
3.2 Necesidades Clave de Participantes o Usuarios

3.2.1 Necesidades de participantes a nivel de Trabajo:
Cuadro 11. Necesidades de participantes a nivel de Trabajo.
Necesidad Prioridad Soluciones Propuestas
Taller de RUP Taller de Metodologa RUP dictado por la
Alta
Lic. Nohemi Pinto.
Curso de UML Curso de Herramienta UML dictado por la

Alta
Lic. Nohemi Pinto.
Curso de Macromedia Curso de Macromedia Dreamweaver

Alta
dictado por el TSU Francisco Oliveros.
Curso de PHP Curso de PHP dictado por el Ing. Rodolfo

Alta
Rodrguez.
Curso de Javascript Curso de Fundamentos de Javascript

Alta
dictado por Lic. Arturo Marcano.
Curso de Desarrollo Web Seleccionar una empresa que dicte cursos de

Alta
Desarrollo Web.


Ncleo de Monagas.
3.2.2 Necesidades de participantes a nivel de Sistemas:

Cuadro 12. Necesidades de participantes a nivel de Sistemas.
Capturar los requerimientos de los Implementar aplicacin WEB bajo
Alta
usuarios. estndares abiertos.
Registrar los requerimientos de los Implementar aplicacin WEB bajo

usuarios a travs de la creacin de Alta estndares abiertos.
casos de uso.
Documentar en forma incremental Implementar aplicacin WEB bajo

Media-alta
la evolucin de los casos de uso. estndares abiertos, mejorando la interfaz
Asignar los nuevos casos de uso a Implementar aplicacin WEB bajo

la cartelera correspondiente. Alta estndares abiertos con una interfaz
amigable.
Ordenar los casos de uso segn Mejorar el mecanismo para priorizar los
Alta
estado, prioridad, tipo. casos.
Migrar y estandarizar las Desarrollo de una aplicacin WEB bajo el

Alta
aplicaciones, segn el decreto 3390. enfoque de software libre y el decreto 3390.
Permitir control de forma remota Implementar una aplicacin libre,

Alta
del equipo del cliente. multiplataforma y de alto desempeo.


Ncleo de Monagas.
3.2.3 Necesidades de los usuarios:

Cuadro 13. Necesidades de los usuarios.
Elaborar la planificacin alimentaria de manera Desarrollar mdulo de

Alta
sencilla y dinmica. Planificacin Alimentaria.
Controlar el acceso de comensales al comedor Desarrollar modulo Acceso

Alta
universitario. de Comensales.
Realizar estimaciones ms certeras del nmero de Desarrollar mdulo de

estudiantes que acudirn al comedor universitario Alta Planificacin Alimentaria
para aprovechar el servicio.
Controlar las entradas y salidas de insumos en Desarrollar modulo de

Alta
almacn. Almacn
Mantener actualizado el inventario del almacn de Desarrollar Modulo de

Alta
insumos. Almacn
Realizar el resumen mensual de de costos de manera Desarrollar modulo de

Alta
rpida y fcil. reportes
4. Descripcin Global del Producto

4.1 Perspectiva del producto
El producto a desarrollar es un Sistema Web para la Planificacin y Control
del Servicio de Alimentacin Prestado por el Comedor Universitario de la
Universidad de Oriente Ncleo de Monagas., a fin de agilizar dichos procesos,
utilizando herramientas de Software Libre que permita cumplir con el Decreto
Presidencial 3390.


Ncleo de Monagas.
Este software estar conformado por distintos mdulos, los cuales tendrn sus
respectivas funcionalidades:
Modulo de insumos y mens alimentarios: estos mdulos permitirn la creacin y
mantenimientos de los mens alimentarios y de los insumos de los que podrn estar
conformados dichos mens.
Modulo Planificacin: permitir realizar la planificacin alimentara de todos los
mens a ser preparados, semanalmente, por el comedor universitario. Adems,
generar la lista de todos los insumos requeridos para la preparacin de los mens
planificados para la semana. Tambin este modulo permitir realizar una estimacin
del nmero de comensales que asistirn al comedor universitario y as poder realizar
mejores planificaciones para las semanas posteriores.
Modulo Acceso de Comensales: permitir registrar y controlar el nmero de
estudiantes que asisten al rea de comedor para el aprovechamiento del servicio de
alimentacin.
Modulo Planificacin Especial: Modulo que permitir elaborar solicitudes de
servicio del comedor universitario cuando se realicen eventos especiales en la
Universidad y sean requeridos dichos servicios. Estas solicitudes podrn ser
consultadas por la administracin del comedor para realizar la planificacin
alimentaria del evento.
Modulo Almacn: permite controlar las existencias de insumos del almacn. Para
llevar este control se emplear el sistema de inventario permanente o perpetuo, ya que
se llevar un registro constante de las unidades que entran y salen del almacn,
permitiendo conocer en todo momento el saldo exacto de los inventarios.
Mdulo Reportes: permite la visualizacin e impresin de reportes como el resumen
mensual de los costos incurridos al prestar el servicio de alimentacin.


Ncleo de Monagas.
4.2 Arquitectura del producto

El producto a desarrollar est definido bajo la siguiente arquitectura:
Figura 29. Arquitectura del Producto.

4.3 Resumen de Capacidades

A continuacin se mostrar un listado de las capacidades que ofrecer el
producto:


Ncleo de Monagas.
Cuadro 14. Sistema para el Comedor Universitario.

Beneficios Funcionalidades
Capacidad para parametrizar y El sistema contar con un mdulo de administracin que
configurar el sistema. permitir configurar los usuarios y las semanas en las que
se planificar el servicio.
Validacin de la informacin de El sistema realizar validaciones, lo que permitir reducir
manera permanente. la duplicacin de trabajo.
Elaborar los mens alimentarios El sistema tendr un modulo de creacin y mantenimientos
considerando la informacin de insumos y mens alimentarios.
nutricional de los alimentos.
Mayor agilidad para elaborar la El sistema contar con un modulo que permitir elaborar la
planificacin de mens Planificacin Alimentaria de acuerdo al nmero de
alimentarios. comensales.
Generar de manera rpida la lista El sistema contar con un modulo que facilitar la
de insumos necesarios para generacin de las lista de insumos requeridos para utilizarlas
preparar las comidas de toda la al momento de realizar los pedidos.
semana.
Controlar el acceso de comensales El sistema contendr un modulo que permitir registrar el
al comedor. nmero de comensales que asisten al comedor para disfrutar
del servicio.
Estimacin ms acertada del El sistema poseer un modulo que permitir estimar la
nmero de personas que asistirn cantidad de personas que acudirn al comedor universitario
al comedor universitario. para aprovechar el servicio, de acuerdo al historial de
registros de comensales.
Llevar un control de los insumos El sistema contendr un modulo que permitir controlar la
que se encuentran en almacn. entrada y salida de insumos del almacn.
Mayor agilidad para generar los El sistema permitir la visualizacin e impresin de
informes y reportes. reportes.


Ncleo de Monagas.
4.4 Presunciones y Dependencias

Se asume que el alcance expresado en primer trmino para este documento no
va a ser ampliado. En caso de que ocurriera una ampliacin del alcance habra que
realizar modificaciones en las funcionalidades. En trminos de implementacin, se
asume que la plataforma donde se va a instalar el sistema est en cumplimiento del
Decreto Presidencial 3390 (Software Libre) y que los usuarios utilizan plataformas
heterogneas en cuanto a sistemas operativos y herramientas de productividad.
4.5 Licenciamiento e Instalacin

El sistema se est realizando exclusivamente para la UDO. La instalacin se
realizar en los equipos que la UDO disponga segn las especificaciones deseadas y
sern administrados por el Centro de Computacin del Ncleo, bajo la supervisin de
la Direccin de Computacin del Rectorado.
En cuanto a la licencia, se utilizar Oracle, siendo ste el manejador de base
de datos que utilizar el nuevo software.
5. Precedencia y Prioridad
1. Subsistema de Compra.
2. Subsistema de Control de Estudios.
3. Subsistema de Comedor.


Ncleo de Monagas.
6. Requerimientos Mnimos del Proyecto

6.1 Requerimientos de Software
Cuadro 15. Requerimientos de Software.
Licencia Tipo de licencia
Oracle Propietario
Apache GNU
PHP GNU
Editor de Texto GNU
Navegador Web GNU
6.2 Requerimientos de Hardware
Cuadro 16. Requerimientos de Hardware.
Equipo Requerimientos Mnimos
Servidor Sun Fire X 2100 y 2 Procesadores de 80Gb
Clientes Pentium IV
6.3 Requerimientos de Materiales
Cuadro 17. Requerimientos de Materiales.
Material Cantidad
Papel Bond Tipo Carta 6
Papel Bond Tipo Oficio 2
USB 2
Block de Notas 2
Lpiz y lapiceros 5
CD-ROM 4
Tonner 4


Ncleo de Monagas.
6.4 Requerimientos de Servicios

Cuadro 18. Requerimientos de Servicios.
Material Cantidad
Sistema de cableado estructurado del Edificio Centro Comunal Puntos de
Estudiantil donde se encuentra ubicado el rea administrativa del conexin de red
comedor, la entrada del comedor y el almacn de insumos. (10)
Interconexin del edificio Centro Comunal Estudiantil con la red
interna del campus.
6.5 Otros Requerimientos

Proporcionar cursos de actualizacin en las siguientes herramientas: Anlisis y
Diseo de Desarrollo de software utilizando RUP y UML, Macromedia, Oracle, PHP,
Javascript, Apache, Web, Editor de Texto, con la finalidad de obtener capacitacin
para el desarrollo del sistema; y as lograr la culminacin del proyecto en el tiempo
establecido.

PROYECTO:
Plan de Administracin de Riesgos

Versin 1.0
141

Ncleo de Monagas.
FECHA: Febrero 2009
NOMBRE DEL DOCUMENTO: Plan de Administracin de Riesgo.
Plan de Administracin de Riesgos

1. Introduccin
Se requiere establecer un Plan de Administracin de Riesgos que garantice un
tratamiento adecuado para aquellos riesgos que se puedan materializar y atenten
contra el xito del proyecto de desarrollo de un Sistema Web para la Planificacin y
Control del Servicio de Alimentacin Prestado por el Comedor Universitario de la
Universidad de Oriente Ncleo de Monagas, por lo tanto se realizar un anlisis de
los riesgos globales inherentes al proyecto.
2. Elementos de Riesgo a Administrar

A continuacin se incluye en este documento el contenido del artefacto Lista
de Riesgos, el cual presentar en forma jerrquica cada uno de los riesgos con las
descripciones establecidas mediante la Tabla de Documentacin de Riesgos (Cuadro
3, p.89)
Nota: La especificacin de cada riesgo en la mencionada tabla de documentacin de

riesgos, fue realizada basndose en el trabajo hecho por otros autores en la
administracin de riesgos que fueron similares al del presente proyecto, debido a que
las valoraciones hechas a cada uno de los riesgos, en cuanto a probabilidad y
consecuencias, debe realizarse de manera subjetiva y por lo tanto estos poseen la
experiencia suficiente en la gestin de proyectos como para darle un ponderacin ms
aproximada a la realidad.


Ncleo de Monagas.
FECHA: Febrero 2009
Cuadro 19. Identificador 001

Identificador: 001
Descripcin: Comunicacin no fluida entre el cliente e involucrados - Reduccin de la
retroalimentacin y desviacin en el cumplimiento de los requerimientos.
Probabilidad: 0,9 Prdida: 9 Grado de Exposicin: 8,1
Primer Indicador: Disminucin de la frecuencia de reuniones con fines de revisin de
artefactos entre los participantes del proyecto y los involucrados.
Estrategia de Mitigacin: Para evitar la disminucin en el flujo de la comunicacin se
requiere hacer reuniones peridicas (diaria y semanalmente para el rea de servicio de
comedor y mensualmente para el centro de computacin) referentes al proyecto, con el fin
de incrementar al mximo la retroalimentacin.
Propietario: Lder del Proyecto Fecha Prevista: Marzo - Junio de 2008.
Cuadro 20. Identificador 002.

Identificador: 002
Descripcin: Incumplimiento de entrega de artefactos, debido a asignaciones a los
participantes de responsabilidades con carga de trabajo fuerte, no relativas al proyecto.
Probabilidad: : 0,9 Prdida: 9 Grado de Exposicin: 8,1
Primer Indicador: estn sujeto al cumplimiento de estas actividades por ser parte de sus
funciones.
Estrategia de Mitigacin: Para evitar el incumplimiento de las asignaciones, el
participante debe dar a conocer con anticipacin la no participacin en alguna iteracin y
por consiguiente exponer con aval dicha solicitud.
Propietario: Lder del proyecto Fecha Prevista: Marzo - Mayo de 2008


Ncleo de Monagas.
FECHA: Febrero 2009

Identificador: 003
Descripcin: Prdida de tiempo ocasionada por la jornada de 120 horas de Trabajo
Comunitario Incumplimiento en la entrega de artefactos
Probabilidad: 0,6 Prdida: 6 Grado de Exposicin: 3.6
Primer Indicador: Prestar Servicio Comunitario, por ser parte de sus funciones.
Estrategia de Mitigacin: Para evitar el incumplimiento de las asignaciones, el
participante debe dar a conocer con anticipacin la no participacin en alguna iteracin y
por consiguiente exponer con aval dicha solicitud.
Propietario: Lder del Proyecto Fecha Prevista: Enero Abril 2009.

Identificador: 004
Descripcin: Proyecto no se puede implantar por alta resistencia al cambio Proyecto
Cancelado
Primer Indicador: Rechazo constante de los artefactos ejecutables durante la fase de
construccin y transicin.
Estrategia de Mitigacin: Coordinar una estrategia de comunicacin interna que involucre
a los usuarios en las ventajas del nuevo sistema y establecer reuniones, foros y conferencias
con la doble finalidad de transmitir el proyecto a los usuarios y recibir la retroalimentacin
que permita incorporar cambios que reduzcan la resistencia natural al cambio.
Propietario: Lder del Proyecto Fecha Prevista: A partir Junio de 2008.


Ncleo de Monagas.
FECHA: Febrero 2009

Identificador: 005
Descripcin: Resistencia al cambio de paradigma de desarrollo de software -
Incumplimiento del alcance del proyecto.
Primer Indicador: Pocos integrantes en cada rea del proyecto, ya que el trabajo est
distribuido paralelamente, distribucin de trabajo de manera estructurada y no cumpliendo
con los lineamientos de la metodologa de desarrollo de software.
Estrategia de Mitigacin: Adaptarse al nuevo paradigma de trabajo en la parte de
desarrollo de software.
Propietario: Lder y Responsable del Fecha Prevista: A partir de Abril 2008
proyecto.

Identificador: 006
Descripcin: Requerimientos no capturados en forma clara y concisa - Determinacin
errnea de funcionalidades y proceso con alto nmero de incrementos por correccin, lo
que genera un estiramiento no deseado del calendario.
Primer Indicador: Los primeros ejecutables no estn ajustados a los requerimientos y
necesitan iteraciones por incremento que incluyen cambios drsticos.
Estrategia de Mitigacin: Para evitar el problema, se deben establecer mecanismos de
supervisin de requerimientos por parte de los Analistas y expertos del negocio, cuyas
funciones se centraran en ejecutar pruebas de desempeo funcional y aceptacin. Mientras
ms grande sea el contacto cliente equipo de desarrollo mayor ser la garanta de capturar
requerimientos reales y realizar la menor cantidad de incrementos por correccin.
Propietario: Analistas De Sistemas Fecha Prevista: Abril - Junio de 2008.


Ncleo de Monagas.
FECHA: Febrero 2009

Identificador: 007
Descripcin: Crecimiento no controlado de requerimientos y alcance - Proyecto fuera de
calendario y requerimientos.
Primer Indicador: Inclusin muy frecuente de nuevos requerimientos asociados a los
casos de uso principales o la creacin de nuevos casos de uso que reflejen requerimientos
de mayor alcance.
Estrategia de Mitigacin: El alcance del proyecto debe ser definido previo a la etapa de
operacin. Cualquier nuevo requerimiento que se constituya en un subsistema no
indispensable para los ya previstos, debe considerarse para un nuevo proyecto.
Propietario: lder del Proyecto Fecha Prevista: A partir de Abril de
2008.

Identificador: 008
Descripcin: Datos de los sistemas actuales no migrados eficientemente - Software con
datos no reales que inciden en su desempeo funcional.
Primer Indicador: Los datos bsicos incorporados de sistemas no fueron incorporados de
acuerdo a las especificaciones del nuevo software.
Estrategia de Mitigacin: Para evitar que esto ocurra, se debe prever la incorporacin
paulatina de data bsica real en la base de datos.
Propietario: Lder del Proyecto Fecha Prevista: A partir de Marzo de
2009.


Ncleo de Monagas.
FECHA: Febrero 2009
Cuadro 27. Identificador: 009.

Identificador: 009
Descripcin: No adecuacin de las normas y procedimientos a las funciones nuevas (no
previstas en el sistema anterior) del nuevo software - Resistencia al cambio.
Primer Indicador: Durante las pruebas del sistema, los usuarios no estn informados de
las situaciones en las cuales operar las diferentes opciones del sistema.
Estrategia de Mitigacin: Definicin de manuales de normas y procedimientos de las
funciones del sistema en general y su respectiva induccin a los usuarios.
Propietario: Lder del Proyecto Fecha Prevista: A partir Junio de 2008.

Identificador: 010
Descripcin: Poco conocimientos de las herramientas de desarrollo por parte de los
participantes.
Primer Indicador: Falta de conocimientos en las herramientas de modelado y mtodos
(UML y RUP) y en las herramientas software a utilizar (como PHP, Power Designer,
Oracle)
Estrategia de Mitigacin: Adiestramiento inmediato a los participantes del proyecto, con
el fin de prepararlos y as puedan cumplir con sus asignaciones.
2008.


Ncleo de Monagas.
FECHA: Febrero 2009

Identificador: 011
Descripcin: Suspensin de actividades administrativas por causas externas a la misma
Retardo en la finalizacin de proyecto.
Primer Indicador: Problemtica existente en los ncleos tanto a nivel docente,
administrativo y estudiantil.
Estrategia de Mitigacin: Tratar de llevar la planificacin del proyecto para poder mitigar
el efecto de retraso que pudiera ser causado por la situacin descrita.
2008.

PROYECTO:
Modelado del Negocio

Versin 1.0
149

Ncleo de Monagas.
FECHA: Julio 2008
NOMBRE DEL DOCUMENTO: Modelado del Negocio.
1. Introduccin
1.1 Propsito
Identificar los procesos que se llevan a cabo en el comedor universitario, la
relacin entre ellos y los actores involucrados en dicho sistema, a fin de comprender
el funcionamiento actual del negocio.
1.2 Alcance
Representar mediante casos de uso y modelo de dominio el funcionamiento
general del negocio bajo estudio, detallando tanto los procesos llevados a cabo como
los objetos ms importantes en el contexto del sistema, incluyendo los actores
internos y externos que participan en l.
2. Representacin del Modelo del Negocio

El modelo del negocio se simbolizar mediante los casos de uso, los cuales
representan los procesos que se llevan a cabo en el rea del servicio del comedor
universitario de la Universidad de Oriente Ncleo de Monagas.
A continuacin se presenta el diagrama de caso de uso general del comedor
universitario:


Ncleo de Monagas.
FECHA: Julio 2008
Devolver Planificacion de menus

Condicion {Planificacion de menus `Requiere cambio}
Punto de extension: Verificar Disponibilidad Insumos
Requeridos
<<extend>>
Planificar menus
Verificar Disponibilidad Insumos
Requeridos
Nutricionista
Administrador de comedor
Realizar Resumen Mensual de Costos
Elaborar Orden de pago
<<include>>
Realizar pedido de insumos
Secretaria
<<include>>
Registrar entrada de insumos
Almacenista
Solicitar Insumos Supervisor de Cocina

Chequear Cantidad de Insumos
<<extend>>
Modificar Planificacion de Menus

Condicion {cantidad de insumos=requiere cambios}
Punto de Extension: Chequear cantidad de insumos
Registrar Comensales
Ayudante de Comedor Estudiante
Diagrama 11. Caso de uso General del Negocio.



Ncleo de Monagas.
FECHA: Julio 2008
3. Descripcin del Modelo del Negocio

3.1 El curso de eventos inicia cuando el nutricionista elabora una planificacin
alimentaria, la cual contiene los mens alimentarios que van a ser servidos en la
semana; as como los insumos requeridos para sus preparaciones.
3.2 El nutricionista entrega a final de semana (normalmente los das jueves) la
planificacin al administrador del comedor universitario. Este la revisa y realiza los
pedidos de los insumos necesarios para preparar los platos de comidas. Para esto, el
administrador primero tiene que analizar las cotizaciones entregadas por los
proveedores y luego elaborar las solicitudes de compras.
3.2.1 Luego que los proveedores entregan la mercanca, la secretaria elabora las
rdenes de pago, que a su vez son llevadas a presupuesto por el administrador, para
que los proveedores retiren de caja el correspondiente cheque por la venta hecha a la
universidad.
3.3 A comienzos de semana, una vez realizados los pedidos, los proveedores
trasladan los insumos hasta el almacn del comedor. El almacenista recibe dichos
insumos y los registra manualmente en un cuaderno.
3.4 Diariamente el supervisor de cocina se dirige al almacn o despensa y solicita los
insumos que van a ser utilizados para preparar el men indicado en la planificacin.
Este los recibe y los traslada al rea de cocina para que los cocineros y auxiliares de
cocina preparen la comida, bajo su supervisin.
3.5 Al momento de prestar el servicio de alimentacin, se debe registrar el nmero de
comensales (estudiantes) que asisten al comedor. Esto a travs de una pequea
aplicacin en Microsoft Access.
3.6 Por cada mes de servicio prestado por el comedor universitario, el administrador
debe elaborar un reporte del resumen mensual de costos para entregarlo a las


Ncleo de Monagas.
FECHA: Julio 2008
autoridades universitarias, para esto utiliza una aplicacin en Excel. Dicha aplicacin
le servir de ayuda para realizar los clculos de costos en cada mes.
4. Vista del Modelo del Dominio del Negocio

AutoridadUniversitaria
Recibe Resumen de Costos

1
1..*
Planificacion Alimentaria 1..*
Nutricionista Elabora
1 1..*
1..* Elabora
Recibe
1 Cotizacion
Recibe
1..* 1
1
1..*
1
AdministradorDeComedor
Entrega
Analisis de Cotizacion
1
Realiza
1
1..* 1
1
Proveedor Elabora
1..*
Solicitud de Compra
Puede 1 1
Recibe Recibe
Consultar
1..*
Entrega
Orden de Pago
1..* 1..*
Elabora
Insumos Secretaria
1..*
1
1..* 1..*
Registra
Comensal
Almacenista
1..* Solicita 1
Registra 1
1
Ayudante de Comedor Supervisor de Cocina
Diagrama 12. Modelo de Dominio del Negocio.



Ncleo de Monagas.
FECHA: Julio 2008
5. Lista de Actor-Actividad
Cuadro 30. Actor-Actividad
Actor Actividades
Administrador de - Dirigir, coordinar y supervisar todas las actividades del
Comedor comedor.
- Velar por el buen funcionamiento del comedor.
- Aprobar la planificacin de mens presentada por el
Nutricionista.
- Llevar el control de compras de equipos y reparacin del
existente.
- Llevar el control presupuestario de su unidad.
- Realizar todas las compras necesarias para el
funcionamiento del comedor.
- Recibir cotizaciones.
- Analizar las cotizaciones entregadas por los proveedores.
- Elaborar Solicitudes de compra.
- Realizar Resumen de costos en cada mes.
Secretaria - Mecanografiar la correspondencia, los informes y dems
trabajos que se le asignen.
- Elaborar orden de pago para los proveedores.
- Archivar notas de entregas, facturas.
Nutricionista - Elaborar listas de mens considerando las facilidades de
adquisicin de los alimentos y su valor nutritivo.
- Controlar cantidad y calidad de los insumos necesarios
para preparar los mens.
- Calcular las cantidades y costos de los mens, de acuerdo
con la estimacin del nmero de comensales.
- Preparar una relacin semanal, quincenal o mensual, segn
sea requerida por el administrador, de la cantidad y calidad
de vveres necesarios para la preparacin de las comidas.
- Realizar la planificacin alimentaria.
- Asesorar al jefe de cocina en cuanto al valor alimenticio de
los materiales usados.
- Colaborar con el administrador en todo lo relacionado a su
cargo.


Ncleo de Monagas.
FECHA: Julio 2008
Cuadro 30. Actor-Actividad (Continuacin)

Actor Actividades
Almacenista - Recibir y revisar los materiales que llegan al almacn.
- Registrar diariamente todas las entradas y salidas
especificando cantidad y valor de los artculos.
- Realizar peridicamente un conteo fsico de las
existencias del almacn.
- Entregar las planificaciones de mens solicitadas por el
supervisor de cocina.
- Entregar la cantidad de insumos solicitadas por el
supervisor de cocina para la preparacin de los mens.
Supervisor de Cocina - Solicitar la Planificacin alimentaria para verificar el
men a ser preparado.
- Solicitar la cantidad de insumos necesarios para la
preparacin del men.
- Asignar tareas a los cocineros y auxiliares de cocina.
- Supervisar las tareas que deben cumplir los cocineros y
ayudantes de cocina.
- Responder por los bienes entregados a su custodia y
cuidado.
- Responder por la buena marcha de la cocina,
preparacin de las comidas y agilidad en el servicio
prestado.
Proveedor - Enva cotizaciones.
- Recibe orden de compra.
- Entrega mercancas de insumos en almacn.
Ayudante del Comedor - Registra comensales que acceden al comedor
universitario.

PROYECTO:
Especificacin de Casos de Uso del Negocio:

Planificar mens
Versin 1.0
156

Ncleo de Monagas.
FECHA: Julio 2008
NOMBRE DEL DOCUMENTO: Especificacin de Casos de Uso del Negocio: Planificar
Mens.
1. Introduccin
1.1 Propsito
Generar el informe de planificacin de mens alimentarios para realizar los
pedidos de los insumos necesarios.
1.2 Alcance
Elaborar la planificacin alimentaria semanal de acuerdo a la estimacin del
nmero de comensales, donde se especifican los mens, y la calidad y cantidad de
insumos a utilizar.
2. Nombre del Caso de Uso

2.1 Cdigo de Caso de Uso
CCU_PM01.
2.2 Descripcin del Caso de Uso
Planificar Mens Alimentarios.
3. Diagrama de Casos de Uso
Condicion {Planificacion de menus `requiere cambio'}

Punto de extension: Verificar Disponibilidad Insumos Devolver Planificacion de menus
Requeridos
<<extend>>
Planificar menus
Verificar Disponibilidad Insumos
Nutricionista Requeridos Administrador de comedor
Diagrama 13. Casos de Uso Planificar Mens



Ncleo de Monagas.
FECHA: Julio 2008
Mens.
4. Flujo de Eventos
4.1 Curso Tpico de Eventos
Para prestar el servicio, el comedor universitario realiza, semanalmente, una
planificacin alimentaria, en la que se especifican la variedad de mens que sern
servidos en el transcurso de la semana, as como la calidad y cantidad de insumos o
alimentos requeridos para la preparacin de los mismos. El informe de la
Planificacin Alimentaria contiene la planificacin de los mens a ser preparados en
el transcurso de la semana, la hoja de pedido donde se encuentran las cantidades
totales de insumos a utilizar en la semana. As como tambin, las hojas de pedidos
por tipo de men y da de la semana; en donde se especifican las cantidades de
insumos a utilizar en cada men.
4.1.1 Para elaborar la planificacin alimentaria, el nutricionista primero debe
seleccionar para cada turno y da de la semana, el men que va a ser preparado.
4.1.2 Luego identifica todos los insumos que se utilizarn para la preparacin de los
mens seleccionados en la semana.
4.1.3 Calcula la cantidad de cada insumo a utilizar por comensal en cada men
seleccionado.
4.1.4 Estima la cantidad de comensales que asistirn al comedor en cada turno y da
de la semana que se est planificando.
4.1.5 Determina la cantidad total de insumos a utilizar en cada men a ser servido
en los turnos y das de la semana, de acuerdo a la cantidad estimada de comensales.
4.1.6 Tambin, determina la cantidad TOTAL de insumos necesarios para preparar
todos los mens de la semana.
4.1.7 Luego, con toda la informacin obtenida, elabora el informe de la
Planificacin Alimentaria de la semana.


Ncleo de Monagas.
FECHA: Julio 2008
Mens.
4.1.8 Una vez realizado el informe de la Planificacin de Mens semanal el

nutricionista se lo entrega al administrador del comedor.
4.1.9 El administrador recibe la Planificacin Alimentaria semanal y la revisa.
4.1.10 Luego examina y verifica la disponibilidad de los insumos requeridos para
preparar los mens programados en la planificacin alimentaria.
4.1.11 Por ltimo, El Administrador del comedor aprueba y firma el informe de
Planificacin de mens semanal.
4.2 Cursos Alternativos

En la lnea 4.1.10:
4.1.10.1 El Administrador del comedor al momento de revisar la Planificacin
alimentaria semanal y, examinar y verificar la disponibilidad de los insumos
requeridos puede considerar que dicha Planificacin requiere cambios. Una de las
razones puede ser, por ejemplo, la escasez de ciertos insumos en los inventarios de las
empresas proveedores. Tambin puede darse el caso de que el administrador estima
conveniente modificar la Planificacin de mens semanal para incluir un alimento de
fcil adquisicin e indispensable para la alimentacin de los estudiantes.
4.1.10.2 El administrador le comunica y le entrega el informe al nutricionista
para que este realice los cambios indicados.
5. Actores
5.1 Internos
Nutricionista y Administrador del Comedor.
5.2 Externos
No existen actores externos.


Ncleo de Monagas.
FECHA: Julio 2008
Mens.
6. Precondiciones
Necesidad de ofrecer el servicio de alimentacin a la comunidad estudiantil.
Haber elaborado el listado de mens alimentarios, considerando las
facilidades de adquisicin de los alimentos y los nutrientes necesarios para la
adecuada alimentacin de los estudiantes y comensales en general, que utilizan el
servicio.
7. Postcondiciones
Lograr la aprobacin del informe de la Planificacin Alimentaria para realizar
los pedidos de los insumos requeridos.


Ncleo de Monagas.
FECHA: Julio 2008
Mens.
8. Diagrama de Actividad
Nutricionista Administrador de Comedor
Selecciona Menu por tipo y dia
Identifica Insumos por menu
Determina cantidad de insumo por comensal en cada menu
Estima Cantidad de comensales por menu
Calcula la cantidad total de insumo a utilizar por tipo de men y dia
Calcula cantidad total de insumo a utilizar por semana
Elabora el informe de la Planificacion de menus
Entrega informe de Planificacion de menus Recibe informe de planificacion de menus
Revisa Planificacion de menus
Verifica Disponibilidad de Insumos Requeridos
[Si] Planificacin Requiere Cambios
[No]
Recibe Informe de Planificacion Devuelve informe de Planificacion de menus
Firma informe de Planificacion de menus
Replanifica Menus
Diagrama 14. Diagrama de Actividad Planificar Mens.


PROYECTO:

Realizar Pedido de Insumos
Versin 1.0
162

Ncleo de Monagas.
FECHA: Julio 2008
NOMBRE DEL DOCUMENTO: Especificacin de Casos de Uso del Negocio: Realizar
Pedido de Insumos.
1. Introduccin
1.1 Propsito
Lograr la adquisicin de los insumos necesarios para prestar el servicio de
alimentacin.
1.2 Alcance
Hacer, cada semana, los pedidos de los insumos necesarios para la preparacin
de los mens alimentarios de la siguiente semana.

CCU_RP02.
Realizar Pedido de insumos.
Realizar pedido de insumos
Administrador de comedor <<include>>
Elaborar Orden de pago
Secretaria
Diagrama 15. Casos de Uso Realizar Pedido de Insumos.


Ncleo de Monagas.
FECHA: Julio 2008
Pedido de Insumos.
4. Flujo de Eventos
4.1.1 El curso normal de eventos inicia cuando el Administrador, cada semana,
examina la Planificacin del siguiente periodo (semana) para verificar los insumos
que van a ser necesarios en la preparacin de los mens alimentarios.
4.1.2 El Administrador del comedor realiza un anlisis de las cotizaciones entregadas
por los proveedores para seleccionar a quienes de ellos se les harn los pedidos.
4.1.3 Luego elabora las solicitudes de compra correspondientes a cada proveedor.
4.1.4 Seguidamente, el administrador enva por FAX las solicitudes de compras a los
distintos proveedores. Para acelerar el proceso el administrador puede realizar los
pedidos por telfono y luego ms adelante enva las solicitudes de compra a los
proveedores.
4.1.5 El proveedor recibe e inspecciona la solicitud de compra. Si cuenta con todos
los insumos solicitados, este prepara la mercanca de insumos y la enva al almacn
del comedor universitario.
4.1.6 El administrador entrega a la Secretaria las solicitudes de compras, las
cotizaciones y el anlisis de las mismas para archivarlas para su posterior utilizacin
en la elaboracin de la orden de pago.
4.1.7 Una vez que se han realizado los pedidos y los proveedores, en la semana
siguiente, hacen entrega de los insumos al encargado del almacn, la secretaria debe
elaborar la orden de pago para que el proveedor pueda recibir en caja el cheque
correspondiente por la venta hecha a la universidad.


Ncleo de Monagas.
FECHA: Julio 2008
Pedido de Insumos.

En la lnea 4.1.5:
4.1.5.1 Si el proveedor no cuenta con ciertos insumos en sus almacenes, este
lo comunica a la administracin del comedor.
4.1.5.2 El administrador del comedor recibe la notificacin de escasez y
realiza el pedido a otro proveedor.
4.1.5.3 En caso de que ningn proveedor cuente con alguno de los insumos
necesarios para la prestacin del servicio de la semana, el administrador notifica y
entrega al nutricionista la planificacin alimentaria para que realice los cambios
pertinentes.
5. Actores
5.1 Internos
Administrador del Comedor y Secretaria.
5.2 Externos
Proveedor.
6. Precondiciones
6.1 Precondicin 1
Los proveedores deben entregar al administrador del comedor las cotizaciones
o listado de precios de todos los productos que ofrecen (La seccin de compra es la
que se encarga a comienzos de semestre de buscar los proveedores, esto a travs de
una licitacin por prensa. Una vez seleccionados los proveedores la seccin de
compras solicita las cotizaciones de los productos que ofrecen y le notifica al
administrador de las cotizaciones a ser entregadas por los proveedores seleccionados.
Cada proveedor hace entrega de un original de cotizacin tanto a la seccin de


Ncleo de Monagas.
FECHA: Julio 2008
Pedido de Insumos.
compra como al Administrador del comedor. Los proveedores volvern a hacer

entrega de nuevas cotizaciones cuando haya variaciones en los precios de los
productos que ofrecen).
6.2 Precondicin 2
Que el administrador haya recibido y aprobado el informe de la Planificacin
de Mens.
7. Postcondiciones
Pedidos realizados a los proveedores para adquirir los insumos necesarios para
la preparacin de los mens alimentarios planificados para la siguiente semana.


Ncleo de Monagas.
FECHA: Julio 2008
Pedido de Insumos.
Proveedor Administradora
Entrega Cotizacion
Recibe cotizacion
Examina Planificacion de Menus
Analiza Cotizaciones
Elabora Solicitudes de Compra
Recibe Solicitud de Compra Envia Solicitudes de Compra por FAX
Inspecciona Solicitud de Compra
Cuenta con todos los insumos

[No]
[Si] Comunica escacez de insumo Recibe Comunicacion de escacez
Elabora Pedido
Diagrama 16. Diagrama de Actividad Realizar Pedido de insumos


PROYECTO:

Registrar Entrada de insumos
Versin 1.0
168

Ncleo de Monagas.
FECHA: Julio 2008
NOMBRE DEL DOCUMENTO: Especificacin de Casos de Uso del Negocio: Registrar
Entrada de Insumos.
1. Introduccin
1.1 Propsito
Tener registrados los insumos que ingresan al almacn.
1.2 Alcance
Registrar en un cuaderno todos aquellos insumos que ingresan al almacn.

CCU_RE03.
Registrar entrada de insumos.
3. Diagrama de Caso de Uso
Realizar Pedido de Insumos
<<include>>
Registrar entrada de insumos
Almacenista
Diagrama 17. Casos de Uso Registrar Entrada de Insumos.

4. Flujo de Eventos
4.1.1 El curso normal de evento inicia cuando los proveedores, al comienzo de cada
semana, trasladan la mercanca al almacn o despensa y la entregan al almacenista.
4.1.2 El almacenista recibe los insumos y una nota de entrega.


Ncleo de Monagas.
FECHA: Julio 2008
Entrada de Insumos.
4.1.3 El almacenista mide o pesa las cantidades de insumos recibidas y las registra o
anota en un cuaderno. Luego, firma la nota de entrega para dar constancia de que
recibi la mercanca correctamente.
4.1.4 Despus de haber registrado todos los insumos, el despensero o almacenista se
dirige al rea administrativa del comedor y le suministra las notas de entrega al
Administrador.
4.1.5 El administrador las revisa y si todo est en orden se las entrega a la Secretaria
para que esta las archive y puedan ser utilizadas posteriormente. En el transcurso de
la semana, tambin los proveedores deben hacer entrega al Administrador de todas las
facturas para que sean archivadas y utilizadas por la secretaria para la elaboracin de
las rdenes de pagos.

En la lnea 4.1.5 Si alguna nota de entrega no cumple con las cantidades
insumos solicitadas, el administrador devuelve la mercanca.
5. Actores
5.1 Internos
Almacenista, Administrador del comedor, Secretaria.
5.2 Externos
Proveedor.
6. Precondiciones
Haber realizado los pedidos de insumos


Ncleo de Monagas.
FECHA: Julio 2008
Entrada de Insumos.
7. Postcondiciones
Insumos registrados en un cuaderno.


Ncleo de Monagas.
FECHA: Julio 2008
Entrada de Insumos.
Proveedor Almacenista Administrador de comedor Secretaria
Entrega mercancia de insumos y nota de entrega
Recibe mercancia de insumos y nota de entrega
Mide cantidad de insumos recibidos
Registrar Insumos recibidos
Firma Nota de entrega
Entrega Notas de entregas Recibe notas de entrega
Revisa notas de entregas
Mercancia correcta
[No]
[Si]
Devolver mercancia
Entregar notas de entrega Recibe Notas de entrega
Archiva Notas de entrega
Diagrama 18. Diagrama de Actividad Registrar Entrada de Insumos.


PROYECTO:

Solicitar Insumos
Versin 1.0
173

Ncleo de Monagas.
FECHA: Julio 2008
NOMBRE DEL DOCUMENTO: Especificacin de Casos de Uso del Negocio: Solicitar
Insumos.
1. Introduccin
1.1 Propsito
Retirar de almacn los insumos necesarios para que los cocineros y auxiliares
de cocina preparen el men del turno que corresponda.
1.2 Alcance
Realizar la solicitud en almacn de aquellos insumos requeridos para preparar
el men alimentario del turno que corresponda.

CCU_SI04.
Solicitar insumos.
Solicitar insumos
Chequear Cantidad de insumos

Supervisor de Cocina
<<extend>>
Condicion {cantidad de insumos=requiere cambios}

Punto de Extension: Chequear cantidad de insumos
Modificar Planificacion de Menus
Diagrama 19. Casos de Uso Solicitar Insumos.



Ncleo de Monagas.
FECHA: Julio 2008
Insumos.
4. Flujo de Eventos
4.1.1 El curso normal de eventos inicia cuando el almacenista examina la
Planificacin alimentaria para verificar el men a ser preparado y las cantidades de
insumos necesarias.
4.1.2 Luego mide y pesa las cantidades de insumos requeridas, dejndolas listas para
el momento de su utilizacin.
4.1.3 Despus, el supervisor de cocina se dirige al almacn y solicita al almacenista el
plan alimentario para chequear el men que va a ser preparado y la cantidad de
insumos necesarios.
4.1.4 El supervisor de cocina solicita al almacenista las cantidades de insumos a ser
utilizadas para la preparacin de las comidas.
4.1.5 El almacenista entrega los insumos al supervisor de cocina.
4.1.6 Luego el supervisor de cocina traslada los insumos solicitados al rea de cocina
dando las indicaciones pertinentes y asignando tareas a los cocineros y auxiliares de
cocina para lograr la preparacin de todos los platos de comida.

En la lnea 4.1.3 debido a su experiencia el supervisor de cocina puede
necesitar menos o ms cantidad de cierto insumo para preparar el men. Dependiendo
del caso el almacenista retira o adiciona la cantidad de insumo correspondiente. Estos
cambios realizados, el almacenista se los notifica al nutricionista para que haga los
cambios en el informe de Planificacin de mens que posee. Luego el nutricionista le
comunica y le entrega al Administrador del comedor la Planificacin de mens
semanal modificada para que sea archivada.


Ncleo de Monagas.
FECHA: Julio 2008
Insumos.
En la lnea 4.1.4 Si al momento del Supervisor de cocina solicitar los insumos

al almacenista, para preparar el men planificado para esa fecha, estos todava no se
encuentran en almacn (debido a que algn proveedor no ha entregado la mercanca),
entonces el supervisor de cocina utiliza los insumos de un men que estaba
planificado para otro da. Esto se lo participa el almacenista al nutricionista y este
hace anotaciones manuales a la Planificacin de mens semanal por el cambio hecho.
Luego el nutricionista le comunica y le entrega al administrador de comedor la
Planificacin de mens semanal modificada para que sea archivada.
5. Actores
5.1 Internos
Almacenista, supervisor de cocina, nutricionista y administrador del comedor.
5.2 Externos
No intervienen actores externos en este proceso.
6. Precondiciones
Que el almacenista haya solicitado al Nutricionista la planificacin alimentaria
para saber que insumos se van a retirar del almacn.
7. Postcondiciones
Contar con los insumos requeridos para utilizarlos en la preparacin de las
comidas o mens alimentarios.


Ncleo de Monagas.
FECHA: Julio 2008
Insumos.
Administrador Nutricionista Almacenista Supervisor de Cocina
Examina Planificacin Alimentaria
Verifica menu a ser preparado
Verifica la cantidad de insumos a utilizar
Mide o pesa las cantidades de insumos necesarias
Entrega planificacion semanal Solicita planificacion semanal
Recibe planificacion semanal
Chequea menu a preparar
Chequea cantidad de insumos a utilizar
[Si]
cantidad de insumos requiere cambios
Hace cambios a las cantidades medidas comunica cambios de cantidad de insumos
[No]
Entrega cantidades de insumos Solicita cantidades de insumos a utilizar
Recibe notificacion Notifica cambio de cantidades utilizadas Recibe Insumos
Modifica Planificacion de menus

Traslada insumos al area de cocina
Recibe Planificacion modificado Entrega Planificacion modificado
Cuadro 31. Diagrama de Actividad Solicitar Insumos.


PROYECTO:

Versin 1.0
178

Ncleo de Monagas.
FECHA: Julio 2008
Comensales.
1. Introduccin
1.1 Propsito
Controlar el acceso de estudiantes al comedor universitario.
1.2 Alcance
Registrar el nmero de estudiantes que acceden al comedor para aprovechar el
servicio de alimentacin.

CCU_RC05.
Registrar Comensales.
Estudiante Ayudante de Comedor
Diagrama 20. Casos de Uso Registrar Comensales.

4. Flujo de Eventos
4.1.1 El curso normal de evento inicia cuando el estudiante se identifica en la entrada
del comedor, pasando el cdigo de barra de su carnet estudiantil por el escner de
cdigo de barra que se encuentra junto al sistema.


Ncleo de Monagas.
FECHA: Julio 2008
Comensales.
4.1.2 La persona encargada de registrar a los comensales, busca los datos del
estudiante en la aplicacin hecha en Access, de acuerdo a la cdula capturada por el
escner.
4.1.3 Si los datos son encontrados y se pueden visualizar en pantalla, el ayudante de
comedor registra al estudiante o comensal.
4.1.4 Luego, el ayudante de comedor permite el acceso del comensal al rea del
comedor para que retire su plato de comida y aproveche as el servicio de
alimentacin.
4.1.5 El comensal accede al comedor universitario.

En la lnea 4.1.1:
4.1.1.1 Si el estudiante no posee el carnet que lo identifica como estudiante de
la universidad, este presenta su cedula de identidad.
4.1.1.2 El ayudante de comedor, introduce por teclado el nmero de la cedula
de identidad.
En la lnea 4.1.2:
4.1.2.1 Si los datos de la persona no son encontrados en el sistema, quiere
decir que no es un estudiante activo y por lo tanto no se le registra como comensal.
4.1.2.2 El ayudante de comedor restringe el acceso de la persona al rea de
comedor.
4.1.2.3 La persona debe retirarse de la cola.


Ncleo de Monagas.
FECHA: Julio 2008
Comensales.
5. Actores
5.1 Internos
Ayudante de Comedor.
5.2 Externos
Estudiante.
6. Precondiciones
El estudiante debe acudir a la entrada del comedor con su respectiva
identificacin o distincin (Carnet estudiantil).
7. Postcondiciones
Lograr el registro de todos los estudiantes que asistieron al comedor para el
aprovechamiento del servicio de alimentacin.


Ncleo de Monagas.
FECHA: Julio 2008
Comensales.
Estudiante Ayudante de Comedor
Identificarse en la Entrada
Buscar datos del estudiante
[No]
Datos encontrados
Restringir Acceso
[Si]
Registrar Comensal
Permitir acceso al comensal
Accede al comedor
Diagrama 21. Diagrama de Actividad Registrar Comensales.


PROYECTO:

Versin 1.0
183

Ncleo de Monagas.
FECHA: Julio 2008
Resumen Mensual de Costos.
1. Introduccin
1.1 Propsito
Generar un Resumen mensual de costos para entregarlo a las autoridades
Universitarias.
1.2 Alcance
Hacer todos los clculos necesarios para generar el resumen mensual de
costos, el cual contendr todos los gastos generados por prestar el servidor de
alimentacin.

CCU_RC06.
2.2. Descripcin del Caso de Uso
Administrador del comedor
Diagrama 22. Casos de Uso Realizar Resumen Mensual de Costos.



Ncleo de Monagas.
FECHA: Julio 2008
4. Flujo de Eventos
4.1.1 El curso normal de evento comienza cuando el administrador examina todas las
planificaciones de mens y facturas archivadas del ltimo mes en el que se prest el
servicio.
4.1.2 De la examinacin hecha a los planes y a las facturas obtiene los datos
requeridos para calcular los costos correspondientes a ese mes.
4.1.3 Con la ayuda de una aplicacin en Excel, el administrador calcula los costos
totales de insumos que fueron entregados por almacn, esto de acuerdo a los planes
de mens. Tambin calcula el total de comensales a quien se les prest el servicio.
Adems se determina el monto total de insumos recibidos por almacn, esto de
acuerdo a las facturas. El administrador tambin calcula el costo unitario por el
servicio prestado a cada comensal, diariamente.
4.1.4 Con la informacin obtenida el administrador finalmente elabora el Resumen
Mensual de costos, lo firma y luego lo entrega a las autoridades universitarias.

No existen cursos alternativos.
5. Actores
5.1 Internos
Administrador del comedor.
5.2 Externos
Autoridades Universitarias.


Ncleo de Monagas.
FECHA: Julio 2008
6. Precondiciones
Tener disponible todas las planificaciones alimentarias y facturas archivadas
de las compras realizadas en todo el mes.
7. Postcondiciones
Lograr la generacin del resumen mensual de costos para entregarlo a las


Ncleo de Monagas.
FECHA: Julio 2008
Administrador del Comedor Autoridad Universitaria
Examina las Planificaciones de Menus
Examina Facturas Archivadas
Obtiene Datos
Calcula costos totales de insumos entregados por almacen
Calcula total de comensales a quienes se les presto el servicio
Determina el monto total de insumos recibidos por almacen
Calcula costo unitario por servicio prestado a cada comensal
Elabora Resumen Mensual de Costos
Firma Resumen Mensual de Costos
Entrega Resumen Mensual de Costos Recibe Resumen Mensual de Costos
Diagrama 23. Diagrama de Actividad Realizar Resumen Mensual de Costos.


5.2 Etapa II. Diseo de la Arquitectura
Esta etapa abarca la segunda fase de RUP y tiene por finalidad establecer una
base slida de la arquitectura del software. Esto a travs del anlisis y diseo de los
requerimientos funcionales del sistema determinados en la etapa anterior, empezando
por aquellos que son crticos para establecer su arquitectura. Adems, en esta etapa se
eliminan los elementos de mayor riesgo para el desarrollo exitoso del proyecto y se
obtiene el modelo de requisitos del sistema empleando los diagramas de casos de uso
especificados en el lenguaje UML y los estndares de calidad que se han de seguir en
el proyecto.
En esta etapa se generaron los siguientes artefactos de la metodologa RUP:

Especificacin de Casos de Uso del Sistema, Especificaciones Complementarias y la
Arquitectura del Sistema.
188
PROYECTO:
Especificacin de Casos de Uso del Sistema:

Autenticar Usuario.
Versin 1.0
189

Ncleo de Monagas.
FECHA: Junio 2009
NOMBRE DEL DOCUMENTO: Especificacin de casos de uso del Sistema: Autenticar
Usuario.
1. INTRODUCCIN
En el documento de especificaciones se describen cada uno de los casos de
uso que conforman el caso de uso general del sistema, los cuales representan los
requisitos funcionales del mismo. A continuacin se muestra el diagrama general de
casos de uso del sistema:
Registrar Insumos
Conformar Mens Alimentarios
Nutricionista
Elaborar Planificacin Alimentaria
<<include>>
Generar Hoja de Pedido

<<include>>
<<include>>
Registrar Existencia de Articulo

<<include>>
Almacenista
<<include>>
Registrar Entrada de Articulos en Almacen
<<include>>
Autenticar Usuario
<<include>>
Registrar Salida de Articulos de Almacen
<<include>>
Generar Resumen de Costos <<include>>
<<include>>
Administrador del Comedor
<<include>>
Consultar Solicitud del Servicio del Comedor
<<include>>
Controlar Acceso de Comensales

Ayundante del Comedor
Elaborar Solicitud de Servicio del Comedor

Usuario Solicitante
Administrar Usuarios del Sistema
Administrador del Sistema
Diagrama 24. Caso de Uso General del Sistema.



Ncleo de Monagas.
FECHA: Junio 2009
Usuario.
2. BREVE DESCRIPCIN
El siguiente caso de uso describe el proceso para autenticar al usuario que est
accediendo al sistema.
3. DIAGRAMA DE CASOS DE USO
Nutricionista
Almacenista
Administrador del Comedor

Autenticar Usuario
Usuario del Sistema
Ayudante del Comedor
Usuario Solicitante
Diagrama 25. Casos de Uso Autenticar Usuario

4. DESCRIPCION TEXTUAL DE CASOS DE USO

4.1 Caso de uso
Autenticar Usuario.
4.2 Actores Principales
Nutricionista, Administrador del comedor, Almacenista, Ayudante del
Comedor, Usuario Solicitante y Administrador del Sistema.


Ncleo de Monagas.
FECHA: Junio 2009
Usuario.
4.3 Precondiciones
El usuario registrado ha accedido a la pantalla inicial del sistema.
4.4 Flujo de Eventos
1. El usuario escribe su nombre de usuario y clave.
2. Luego presiona el botn Ingresar.
3. El sistema valida si los datos introducidos son de un usuario registrado.
4. El sistema busca las opciones a las que puede acceder el usuario.
5. Finalmente, el sistema muestra el men principal.
4.5 Postcondiciones
El usuario registrado ha ingresado al sistema de acuerdo a su rol.
4.6 Flujos Alternativos
En la lnea 3 en caso de que los datos introducidos no coincidan con un
usuario registrado, el sistema emite un mensaje de usuario invlido.


Ncleo de Monagas.
FECHA: Junio 2009
Usuario.
5. DIAGRAMA DE SECUENCIA
W:AutenticacionUsuario Usuario TipoUsuario
Usuario del Sistema
1.Escribe Nombre de Usuario y Clave
2.Presiona boton "Ingresar"

3.Procesa
Si resp=false 4.resp=validarUsuario(usuario,clave)
5.Usuario No Valido
Si resp=true 6.cargarOpciones()
7.Busca Opciones del usuario

8.buscarOpciones()
9.Muestra Men Principal del usuario
Diagrama 26. Diagrama de Secuencia Autenticar Usuario.



Ncleo de Monagas.
FECHA: Junio 2009
Usuario.
6. PROTOTIPO DE INTERFAZ DE USUARIO.
Pantalla 1. Autenticar Usuario.

Pantalla 2. Men Principal Usuario Administrador del Sistema.



Ncleo de Monagas.
FECHA: Junio 2009
Usuario.
Pantalla 3. Men Principal Usuario Nutricionista.

Pantalla 4. Men Principal Usuario Administrador del Comedor.



Ncleo de Monagas.
FECHA: Junio 2009
Usuario.
Pantalla 5. Men Principal Usuario Almacenista.

Pantalla 6. Men Principal Usuario Ayudante del Comedor.



Ncleo de Monagas.
FECHA: Junio 2009
Usuario.
Pantalla 7. Men Principal Usuario Solicitante.


PROYECTO:

Administrar Usuarios del Sistema.
Versin 1.0
198

Ncleo de Monagas.
FECHA: Junio 2009
NOMBRE DEL DOCUMENTO: Especificacin de casos de uso del Sistema:
1. BREVE DESCRIPCIN
El siguiente caso de uso describe el proceso para administrar los usuarios que
tendrn acceso al sistema del comedor.
Autenticar Usuario
<<include>>
Administrar Usuarios
Diagrama 27. Casos de Uso Administrar Usuarios del Sistema.


3.1 Caso de uso
Administrador del Sistema.
3.3 Precondiciones
El usuario ha sido autenticado correctamente en el sistema (Ver
Especificacin de Casos de uso Autenticar Usuario).
1. Este caso de uso inicia cuando el administrador del sistema selecciona del
men principal la opcin Administrar Usuarios.


Ncleo de Monagas.
FECHA: Junio 2009
2. El sistema abre nueva ventana y muestra las opciones de administracin

(Nuevo, Modificar, Eliminar, Salir). Tambin, busca los usuarios que han
sido creados y los muestra en pantalla.
3. Crear Nuevo Usuario.
3.1 El administrador del sistema presiona el botn Nuevo para crear un nuevo
usuario.
3.2 El sistema abre ventana, busca los tipos de usuarios y muestra en pantalla el
formulario para editar los datos del nuevo usuario.
3.3 El administrador introduce los datos del nuevo usuario y presiona botn
Agregar.
3.4 El sistema valida los datos introducidos.
3.5 El sistema registra nuevo usuario.
3.6 El sistema muestra un mensaje en pantalla avisando que el usuario se ha
creado correctamente.
4. Buscar Usuario.
4.1 El usuario llena campo de bsqueda y presiona botn Filtrar.
4.2 El sistema busca usuarios de acuerdo a los caracteres tecleados y los muestra
en pantalla.
5. Editar Usuario.
5.1 El usuario administrador selecciona un usuario de la lista y presiona el botn
Modificar.
5.2 El sistema abre ventana, busca el usuario seleccionado, busca los tipos de
usuarios y muestra en pantalla el formulario con la informacin del usuario
seleccionado.
5.3 El administrador edita los datos del usuario y presiona el botn Modificar.
5.4 El sistema actualiza los datos del usuario.


Ncleo de Monagas.
FECHA: Junio 2009
5.5 El sistema muestra en pantalla un mensaje indicando que los datos han sido
actualizados exitosamente.
6. Eliminar Usuario.
6.1 El Administrador selecciona un usuario de la lista y presiona el botn
Eliminar.
6.2 El sistema muestra un mensaje de confirmacin para eliminar el usuario.
6.3 El usuario confirma eliminacin.
6.4 El sistema elimina el usuario seleccionado.
6.5 El sistema enva un mensaje indicando que el usuario ha sido eliminado
exitosamente.
7. Salir.
7.1 El usuario administrador presiona el botn Salir.
7.2 Para terminar con el proceso, el sistema abre y muestra el men principal.
3.5 Postcondiciones
Se realizaron cambios en las cuentas de los diferentes usuarios del sistema.
En la lnea 3.3
3.3.1 En caso de que el administrador quiera volver a la pantalla anterior sin
guardar los datos del usuario, entonces presiona el botn Retornar.
3.3.2 El sistema abre y muestra la pantalla anterior de administrar usuarios.
En la lnea 3.4 en caso de que los datos introducidos del usuario sean invlidos o que
el nombre de usuario introducido ya exista, el sistema enva un mensaje para que el
usuario verifique la informacin.


Ncleo de Monagas.
FECHA: Junio 2009
(Ver Pgina 365)
Diagrama 28. Diagrama de Secuencia Administrar Usuarios del Sistema.



Ncleo de Monagas.
FECHA: Junio 2009
5. PROTOTIPO DE INTERFAZ DE USUARIO
Pantalla 8. Administrar Usuarios del Sistema.

Pantalla 9. Detalles de Usuario del Sistema.


PROYECTO:

Registrar Insumos.
Versin 1.0
204

Ncleo de Monagas.
FECHA: Abril 2009
NOMBRE DEL DOCUMENTO: Especificacin de casos de uso del Sistema: Registrar
Insumos.
1. BREVE DESCRIPCIN
El siguiente caso de uso describe el proceso para la creacin y mantenimiento
de los insumos que sern utilizados para conformar los mens y planificar el servicio
de alimentacin.
Autenticar Usuario
<<include>>
Registrar Insumos
Usuario del Sistema
Diagrama 29. Casos de Uso Registrar Insumos.

3. DESCRIPCION TEXTUAL DE CASOS DE USOS

3.1 Caso de uso
Registrar Insumos.
3.2 Actores principales
Nutricionista.
3.3 Precondiciones


Ncleo de Monagas.
FECHA: Abril 2009
Insumos.
1. Este caso de uso inicia cuando el Usuario selecciona la opcin Cargar Insumos
del Men Principal.
2. El sistema abre nueva ventana y muestra opciones de Nuevo, Modificar,
Salir. Tambin, busca los tipos de insumos y los insumos que han sido creados y
los muestra en pantalla.
3. Crear Nuevo Insumo.
3.1 El usuario presiona el botn Nuevo para crear un nuevo insumo.
3.2 El sistema despliega ventana para agregar nuevo insumo.
3.3 El usuario introduce los datos del nuevo insumo y presiona el icono Agregar
Nuevo Insumo.
3.5 El sistema registra el insumo.
3.6 El sistema enva mensaje a pantalla indicando que el insumo ha sido creado.
4. Buscar Insumo
4.1 Buscar Insumos por tipo.
4.1.1 El usuario selecciona un tipo de insumos.
4.1.2 El sistema busca insumos de acuerdo al tipo de insumos seleccionado y los
muestra en pantalla.
4.2 Buscar Insumo llenando campo de bsqueda.
4.2.1 El usuario llena campo de bsqueda y presiona el botn Filtrar.
4.2.2 El sistema busca los insumos que coincidan con los caracteres tecleados y filtra
la lista de insumos de acuerdo a esa cadena de caracteres.
5. Modificar Insumo.
5.1 El usuario selecciona un insumo de la lista y presiona el botn Modificar.
5.2 El sistema abre nueva ventana; busca datos del insumo seleccionado; busca
unidades de medida, tipos de insumos, tipos de mens, grupos de alimentos, tipos de


Ncleo de Monagas.
FECHA: Abril 2009
Insumos.
nutrientes y los nutrientes de acuerdo al tipo que este seleccionado. Por ltimo,
muestra en pantalla el formulario con la informacin del insumo escogido.
5.3 El usuario edita los datos del insumo.
5.3.1 Agregar Insumo en Tipo de Men.
1. El usuario marca la casilla del tipo de men (Turno) donde se podr utilizar el
insumo.
2. El sistema activa el insumo para poder utilizarlo en el turno indicado por el tipo de
men marcado.
5.3.2Quitar Insumo en Tipo de Men.
1. El usuario desmarca la casilla del tipo de men para no poder utilizar el insumo en
ese turno.
2. El sistema desactiva el insumo en el tipo de men desmarcado.
5.3.3 Activar Propiedades de Alimento.
1. El usuario marca casilla Propiedades de Alimento.
2. El sistema habilita y muestra en pantalla el formulario para editar las propiedades
de alimento del insumo.
5.3.4 Desactivar propiedades de alimento.
1. El usuario desmarca casilla Propiedades de Alimento.
2. El sistema deshabilita y oculta el formulario para edicin de propiedades de
alimento.
5.3.5 Agregar Nutrientes del Insumo.
1. El usuario selecciona un tipo de nutriente.
2. El sistema busca nutrientes de acuerdo al tipo seleccionado y los muestra en
pantalla.
3. El usuario selecciona un nutriente de la lista.


Ncleo de Monagas.
FECHA: Abril 2009
Insumos.
4. El sistema agrega el nutriente seleccionado a la lista de valores nutricionales del

insumo alimenticio que se est editando.
5.3.6 Editar Nutriente del Insumo.
1. El usuario edita la cantidad o el valor del nutriente.
2. El sistema actualiza el valor del nutriente.
5.3.7 Eliminar Nutriente del Insumo.
1. El usuario presiona el icono Eliminar del nutriente a borrar del insumo.
2. El sistema quita el nutriente de la lista de Nutrientes del Insumo Alimenticio.
5.4 El usuario presiona botn Actualizar.
5.5 El sistema actualiza los datos del insumo.
5.6 El sistema muestra en pantalla un mensaje indicando que el insumo ha sido
actualizado.
6. Retornar.
6.1 El usuario presiona botn Retornar.
6.2 El sistema abre y muestra la pantalla anterior.
7. Eliminar Insumo.
7.1 El usuario presiona el botn Eliminar.
7.2 El sistema muestra un mensaje de confirmacin para eliminar el insumo.
7.4 El sistema comprueba que el insumo no esta siendo utilizado en otros procesos.
7.5 El sistema elimina el insumo.
7.6 El sistema enva un mensaje indicando que el insumo se ha eliminado.
8. Salir.
8.1 El usuario presiona el botn Salir.


Ncleo de Monagas.
FECHA: Abril 2009
Insumos.
3.5 Postcondiciones
Insumos registrados para utilizarlos al momento de crear los mens
alimentarios y realizar la planificacin alimentaria.
En la lnea 3.2
3.2.1 En caso de que el usuario ya no quiera agregar un nuevo insumo,
presiona cerrar de la ventana desplegada.
3.2.2 El sistema cierra la ventana de Agregar Insumo.
En la lnea 3.4 en caso de que los datos introducidos del insumo sean invlidos o que
la descripcin ingresada ya exista, el sistema enva un mensaje para que el usuario
verifique la informacin.
En la lnea 7.4 en caso de que el insumo est siendo utilizado en otros procesos, el
sistema emite un mensaje indicando que no se puede eliminar dicho insumo.


Ncleo de Monagas.
FECHA: Abril 2009
Insumos.
(Ver Pgina 366)
Diagrama 30. Diagrama de Secuencia Registrar Insumos.



Ncleo de Monagas.
FECHA: Abril 2009
Insumos.
Pantalla 10. Listado de Insumos Registrados.

Pantalla 11. Ventana para Agregar Nuevo Insumo.



Ncleo de Monagas.
FECHA: Abril 2009
Insumos.
Pantalla 12. Pantalla para editar datos de Insumo.


PROYECTO:

Conformar Mens Alimentarios.
Versin 1.0
213

Ncleo de Monagas.
FECHA: Abril 2009
NOMBRE DEL DOCUMENTO: Especificacin de casos de uso del Sistema: Conformar
Mens Alimentarios.
1. BREVE DESCRIPCIN
El siguiente caso de uso describe el proceso para conformar los mens que
sern utilizados en la planificacin alimentaria.
2. DIAGRAMA DE CASOS DE USOS
Autenticar Usuario
<<include>>
Conformar Mens Alimentarios
Usuario del Sistema
Diagrama 31. Casos de Uso Conformar Mens Alimentarios.


3.1 Caso de uso
Conformar Mens Alimentarios.
Nutricionista
3.3 Precondiciones
Haber cargado los insumos necesarios para conformar los mens alimentarios.
(Ver Especificacin de Casos de uso Registrar Insumos).


Ncleo de Monagas.
FECHA: Abril 2009
Mens Alimentarios.

1. Este caso de uso comienza cuando el usuario selecciona la opcin Conformar
Men del Men Principal.
Salir. Tambin, busca los tipos de mens y los mens que han sido creados y los
3. Crear Nuevo Men Alimentario.
3.1 El usuario presiona el botn Nuevo para crear un nuevo men alimentario.
3.2 El sistema despliega ventana para agregar nuevo men.
3.3 El usuario introduce los datos del nuevo men y presiona el icono Agregar
Nuevo Men.
3.5 El sistema registra el men alimentario.
3.6 El sistema enva mensaje a pantalla indicando que el men alimentario ha sido
creado.
4. Buscar Men Alimentario.
4.1 Buscar Mens Alimentarios por tipo.
4.1.1 El usuario selecciona un tipo de men.
4.1.2 El sistema busca mens de acuerdo al tipo de mens seleccionado y los muestra
en pantalla.
4.2 Busca Men Alimentario llenando campo de bsqueda.
4.2.2 El sistema busca los mens que coincidan con los caracteres tecleados y filtra la
lista de mens de acuerdo a esa cadena de caracteres.
5. Modificar Men Alimentario.


Ncleo de Monagas.
FECHA: Abril 2009
Mens Alimentarios.
5.1 El usuario selecciona un men alimentario de la lista y presiona el botn

Modificar.
5.2 El sistema abre nueva ventana; busca datos del men seleccionado, busca tipo de
men, tipos de nutriente y los insumos requeridos para preparar el men alimentario
seleccionado. Por ltimo, muestra en pantalla el formulario con la informacin del
men escogido.
5.3 El usuario edita la informacin del men alimentario.
5.3.1 Incluir Insumo al Men Alimentario.
1. El usuario presiona icono Buscar.
2. El sistema abre nueva ventana, busca y muestra en pantalla los tipos de insumos,
los grupos de alimentos y los insumos de acuerdo al tipo de men, al tipo de insumos
y al grupo de alimentos que estn seleccionados.
3. El usuario selecciona un tipo de insumo.
4. El sistema busca insumos de acuerdo al tipo seleccionado y los muestra en
pantalla.
5 El usuario llena campo de bsqueda y presiona botn Filtrar.
6. El sistema busca insumos de acuerdo a caracteres tecleados y los muestra en
pantalla.
7. El usuario selecciona un grupo de alimento.
8. El sistema busca insumos de acuerdo al grupo de alimento seleccionado y los
9. Luego de realizar la bsqueda, el usuario selecciona un insumo de la lista.
10. El sistema cierra ventana y carga los datos del insumo seleccionado en el
formulario.
11. El usuario ajusta cantidad del insumo y presiona icono Incluir.


Ncleo de Monagas.
FECHA: Abril 2009
Mens Alimentarios.
12. El sistema agrega el insumo a la lista de insumos requeridos del men alimentario
que se est editando.
13. El sistema emite mensaje indicando que se ha agregado el insumo requerido.
5.3.2 Editar Insumo Requerido.
1. El usuario edita la cantidad del insumo requerido.
2. El sistema actualiza la cantidad del insumo requerido.
5.3.3 Quitar Insumo Requerido.
1. El usuario presiona el icono Eliminar del insumo requerido a borrar.
2. El sistema quita el insumo requerido de la lista de insumos requeridos del Men
Alimentario.
5.3.4 Ver Composicin Nutricional del Men Alimentario.
1. El usuario selecciona un tipo de nutriente y un alimento requerido.
2. El sistema busca insumos alimenticios requeridos, propiedades de los alimentos y
nutrientes.
3. El sistema calcula y muestra en pantalla los valores nutricionales tanto del alimento
requerido seleccionado como del men.
5.4 El usuario presiona el botn Actualizar.
5.5 El sistema actualiza los datos del men alimentario.
5.6 El sistema muestra en pantalla un mensaje indicando que el men ha sido
actualizado.
6. Retornar.
7. Eliminar Men Alimentario.
7.1 El usuario presiona el botn Eliminar.


Ncleo de Monagas.
FECHA: Abril 2009
Mens Alimentarios.
7.2 El sistema muestra un mensaje de confirmacin para eliminar el men

alimentario.
7.3 El nutricionista confirma eliminacin.
7.4 El sistema comprueba que el men alimentario no est siendo utilizado en otros
procesos.
7.5 El sistema elimina el men alimentario con sus respectivos insumos requeridos.
7.6 El sistema enva un mensaje indicando que el men se ha eliminado.
8. Salir.
3.5 Postcondiciones
Lograr la creacin de las variedades de mens alimentarios para luego
utilizarlas en la planificacin alimentaria.
En la lnea 3.2
3.2.1 En caso de que el usuario ya no quiera agregar un nuevo men, presiona
cerrar de la ventana desplegada.
3.2.2 El sistema cierra la ventana de Agregar Men.
En la lnea 3.4 en caso de que los datos introducidos del men sean invlidos o que la
descripcin ingresada ya exista, el sistema enva un mensaje para que el usuario
En la lnea 7.4 en caso de que el insumo est siendo utilizado en otros procesos, el
sistema emite un mensaje indicando que no se puede eliminar dicho insumo.


Ncleo de Monagas.
FECHA: Abril 2009
Mens Alimentarios.
(Ver Pgina 367)
Diagrama 32. Diagrama de Secuencia Conformar Mens Alimentarios.



Ncleo de Monagas.
FECHA: Abril 2009
Mens Alimentarios.
Pantalla 13. Listado de Mens Alimentarios Registrados.

Pantalla 14. Ventana para Agregar Nuevo Men.



Ncleo de Monagas.
FECHA: Abril 2009
Mens Alimentarios.
Pantalla 15. Pantalla para editar datos de Men.


PROYECTO:

Elaborar Planificacin Alimentaria.
Versin 1.0
222

Ncleo de Monagas.
FECHA: Mayo 2009
NOMBRE DEL DOCUMENTO: Especificacin de casos de uso del Sistema: Elaborar
Planificacin Alimentaria.
1. BREVE DESCRIPCIN
El siguiente caso de uso describe el proceso para realizar la planificacin
semanal de los mens que van a ser preparados por el comedor universitario para la
prestacin del servicio de alimentacin.
Autenticar Usuario
<<include>>
Elaborar Planificacin Alimentaria
Usuario del Sistema
Diagrama 33. Casos de Uso Elaborar Planificacin Alimentaria.


3.1 Caso de uso
Elaborar Planificacin Alimentaria.
Nutricionista
3.3 Precondiciones


Ncleo de Monagas.
FECHA: Mayo 2009
Haber cargado los insumos. (Ver Especificacin de Casos de uso Registrar

Insumos).
Para realizar la planificacin alimentaria es necesario conformar los mens
alimentarios, los cuales son los platos de comida que sern servidos en el da a da en
el que el comedor universitario presta el servicio. (Ver Especificacin de Casos de
uso Conformar Mens Alimentarios).
1. Este caso de uso inicia cuando el usuario selecciona la opcin Planificar Servicio
del men principal.
2. El sistema abre nueva ventana y muestra opciones de creacin, modificacin,
eliminacin e impresin de planificaciones. Adems muestra la opcin de consultar
los insumos que son necesarios para preparar los mens programados en las
planificaciones. Tambin, busca las semanas en las que ya se ha planificado el
servicio y las planificaciones alimentarias planeadas para la ltima semana.
3. Crear Nueva Planificacin Alimentaria Semanal.
3.1 El usuario presiona el botn Nuevo para crear una nueva planificacin
semanal.
3.2 El sistema abre ventana, busca las semanas en las que aun no se ha planificado y
los tipos de men o turnos disponibles. Muestra en pantalla el formulario para editar
los datos de la nueva planificacin semanal.
3.3 En caso de que se vaya a planificar para una semana normal de servicio, el
usuario selecciona una semana de lista.
3.4 El sistema crea fechas que estn dentro del rango de la semana seleccionada y las
3.5 Agregar una Planificacin de Men a la Planificacin Semanal.
3.5.1 El usuario selecciona una fecha de la lista.


Ncleo de Monagas.
FECHA: Mayo 2009
3.5.2 El sistema muestra da de la fecha seleccionada.

3.5.3 El usuario selecciona tipo de men.
3.5.4 Incluir Men a la Planificacin Alimentaria.
1. El usuario presiona icono Buscar Men Alimentario.
2. El sistema abre nueva ventana, busca y muestra en pantalla los mens de acuerdo
al tipo seleccionado en la pantalla anterior.
3. El usuario llena campo de bsqueda y presiona el botn Filtrar.
4. El sistema busca mens de acuerdo a caracteres tecleados y los muestra en
pantalla.
5. El usuario selecciona un men alimentario de la lista.
6. El sistema cierra ventana y carga la informacin del men seleccionado en el
formulario.
3.5.5 Estimar nmero de comensales.
1. El usuario pulsa icono Estimar Nmero de comensales.
2. El sistema abre nueva ventana, busca informacin de las planificaciones anteriores
e historial de comensales de acuerdo al da y turno seleccionados. Luego, muestra en
pantalla los mens servidos y el nmero de comensales atendidos en las fechas
anteriores de acuerdo al da y turno que se est planificando.
3. El usuario presiona botn Estimar.
4. El sistema calcula el estimado de comensales y lo muestra en pantalla.
5. El usuario presiona botn Aceptar.
6. El sistema cierra ventana y carga el estimado de comensales en el formulario.
3.5.6 El usuario presiona botn Agregar.
3.5.7 El sistema valida los datos introducidos.
3.5.8 El sistema agrega la planificacin de men a la semana que se est planificando.
3.5.9 Incluir insumo a la Planificacin de Men.


Ncleo de Monagas.
FECHA: Mayo 2009
1. El usuario selecciona una planificacin de men y presiona icono Incluir Otros

insumos a la Planificacin.
2. El sistema abre nueva ventana, busca y muestra los tipos de insumos y los insumos
sin propiedades alimenticias de acuerdo al tipo que este seleccionado.
3. El usuario selecciona tipo de insumo.
pantalla.
5. El usuario llena campo de bsqueda y presiona botn Filtrar.
pantalla.
7. El usuario selecciona un insumo de la lista.
8. El sistema agrega el insumo seleccionado a la lista de Insumos Requeridos Para la
Planificacin.
3.5.10 Editar Insumo Requerido para la Planificacin.
1. El usuario edita cantidad del insumo requerido.
2. El sistema actualiza la cantidad del insumo requerido.
3.5.11 Quitar Insumo Requerido de la Planificacin.
1. El usuario presiona el icono Eliminar del insumo requerido a borrar.
2. El sistema quita el insumo de la lista de insumos requeridos para la planificacin.
3.6 Quitar una Planificacin de Men de la Planificacin Semanal.
3.6.1 El usuario presiona el icono Eliminar de la planificacin de men a borrar.
3.6.2 El sistema elimina la planificacin de men y los insumos requeridos de dicha
planificacin.
3.7 Guardar Planificacin Alimentaria Semanal.
3.7.1 El usuario presiona botn Guardar.
3.7.2 El sistema cambia estado de la semana a activo (La semana ha sido planificada).


Ncleo de Monagas.
FECHA: Mayo 2009
3.7.3 El sistema muestra en pantalla un mensaje indicando que la Planificacin

Semanal ha sido guardada.
4. Retornar.
4.1 El usuario Presiona botn Retornar.
5. Buscar Planificacin Alimentaria Por Semana.
5.1 El usuario selecciona una semana.
5.2 El sistema busca las planificaciones de men programadas en la semana
seleccionada y las muestra en pantalla.
6. Modificar Planificacin Alimentaria Semanal.
6.1 El usuario marca casilla Seleccionar Planificacin Alimentaria Semanal y
presiona botn Modificar.
6.2 El sistema abre nueva ventana; busca los tipos de mens o turnos; busca
informacin de la semana y las planificaciones de men programadas en esa semana.
Luego, muestra formulario con datos de la planificacin alimentaria semanal
seleccionada.
6.3 El usuario edita los datos de las planificaciones alimentarias de la semana
seleccionada.
6.4 Cambiar Men Planificado de acuerdo a disponibilidad en almacn.
6.4.1 El usuario selecciona una planificacin alimentaria y presiona icono "Buscar
Men de Planificaciones Anteriores".
6.4.2 El sistema abre nueva ventana, busca Informacin de planificaciones anteriores
de acuerdo al turno de la planificacin seleccionada. Tambin, busca informacin de
los mens planificados y los insumos requeridos tanto para preparar los mens como
para prestar el servicio en general.
6.4.3 El sistema busca las existencias de artculos en almacn.


Ncleo de Monagas.
FECHA: Mayo 2009
6.4.4 El Sistema comprueba la existencia en almacn de los insumos requeridos para

prestar el servicio de alimentacin segn lo indicado en las planificaciones.
6.4.5 El sistema solo muestra las planificaciones donde los mens alimentarios
pueden prepararse con los insumos existentes en almacn.
6.4.6 El usuario selecciona el men alimentario de una Planificacin Anterior
Disponible.
6.4.7 El sistema actualiza informacin de la planificacin alimentaria que se est
modificando.
6.4.8 El sistema muestra en pantalla la planificacin alimentaria con el men y
estimado de comensales actualizados.
6.5 Luego, el usuario presiona el botn Guardar (Ver lnea 3.7).
7. Eliminar Planificacin Alimentaria Semanal.
7.1 El usuario marca casilla Seleccionar Planificacin Alimentaria Semanal y
presiona botn Eliminar.
7.2 El sistema elimina las planificaciones de mens programadas en la semana
seleccionada y sus respectivos insumos requeridos.
7.3 El sistema desactiva semana (Ya no est planificada la semana).
7.4 El sistema muestra en pantalla un mensaje indicando que la planificacin
alimentaria ha sido eliminada.
8. Imprimir Planificacin Alimentaria Semanal.
El usuario marca casilla Seleccionar Planificacin Alimentaria Semanal y presiona
botn Imprimir.
8.2 El sistema genera reporte de la Planificacin Alimentaria Semanal seleccionada y
lo enva a la impresora en formato imprimible para que realice la impresin del
mismo.
9. Salir.


Ncleo de Monagas.
FECHA: Mayo 2009

9.2 Para terminar con el proceso, el sistema abre y muestra el men principal de
opciones.
3.5 Postcondiciones
Lograr la programacin de los mens alimentarios que van a ser preparados en
cada da y turno de las semanas posteriores, con las respetivas cantidades de
comensales que posiblemente asistirn al comedor a aprovechar el servicio.
En la lnea 3.3
3.3.1 En caso de que se vaya a planificar para un evento especial, el usuario
marca o activa la casilla Evento Especial.
3.3.2 El sistema muestra campo para crear semana de evento especial.
3.3.3 El usuario escribe nombre del evento y presiona el botn OK.
3.3.4 El sistema crea semana para evento especial y enva un mensaje
indicando que el evento ha sido creado.
En la lnea 3.5.1 en caso de que se est planificando para un evento especial el
usuario escribe la fecha.
En la lnea 3.5.5 en caso de que se est planificando para un evento especial el
usuario simplemente escribe el nmero de comensales sealado en la solicitud de
servicio recibida. Es decir, no podr estimar el nmero de comensales, debido a que
el sistema deshabilitar el icono para estimacin cuando se trate de eventos
especiales.
En la lnea 3.5.7 en caso de que los introducidos sean invlidos o que ya exista una
planificacin de men con los datos introducidos, el sistema enva un mensaje para
que el usuario verifique la informacin.


Ncleo de Monagas.
FECHA: Mayo 2009
En la lnea 7.3 en caso de que las planificaciones eliminadas sean de un evento

especial, el sistema elimina la semana.
4. REQUISITOS ESPECIALES
Para realizar la planificacin del servicio de alimentacin, es necesario estimar
el nmero de comensales. Esto para saber aproximadamente cual ser la demanda
futura del servicio y as poder determinar qu cantidades de insumos sern necesarias
adquirir para la preparacin de las comidas. Para estimar el nmero de comensales se
emplear el modelo de series de tiempo para pronstico de demanda llamado
Promedio mvil. Este mtodo emplea la siguiente frmula matemtica para calcular
el pronstico de la demanda del siguiente periodo t+1:
Frmula 1. Frmula de Promedio Mvil.

Suma de las n ltimas demandas D t + D t 1 + D t 2 + ... + D t n +1
Ft +1 = =
n n
Demanda D t = demanda real en el periodo t
n = nmero total de periodos incluidos en el promedio

Ft +1 = pronstico para el periodo t + 1
Fuente: Krajewski, L. y Ritzman, Larry. (2000).
Para el caso de la estimacin del nmero de comensales que acudirn al

comedor universitario, se tomara n=3; es decir, para pronosticar la demanda de
comensales para un periodo futuro se tomarn como datos histricos el nmero real
de comensales que asistieron al comedor en los tres (3) periodos ms recientes
anteriores al que se est pronosticando. Los periodos anteriores quedarn definidos en
base al da de la semana (lunes, martes, mircoles,) y turno (desayuno, almuerzo,


Ncleo de Monagas.
FECHA: Mayo 2009
cena,) del periodo futuro en el que se desea estimar la demanda de comensales. Por
ejemplo, si se va a pronosticar el nmero de comensales para el turno del desayuno
del da lunes de la siguiente semana, se tomar como n periodos los 3 ltimos lunes
en los que se sirvi el desayuno en el comedor universitario.


Ncleo de Monagas.
FECHA: Mayo 2009
(Ver Pgina 368)
Diagrama 34. Diagrama de Secuencia Elaborar Planificacin Alimentaria.



Ncleo de Monagas.
FECHA: Mayo 2009
Pantalla 16. Vista de Planificaciones Alimentarias por Semana.



Ncleo de Monagas.
FECHA: Mayo 2009
Pantalla 17. Pantalla para editar datos de Planificacin Alimentaria Semanal.



Ncleo de Monagas.
FECHA: Mayo 2009
Pantalla 18. Ventana para Estimacin de Comensales.

Pantalla 19. Ventana para Modificar Men de la Planificacin Alimentaria.



Ncleo de Monagas.
FECHA: Mayo 2009
Pantalla 20. Ventana para Incluir Insumos a la Planificacin Alimentaria.


PROYECTO:

Generar Hoja de Pedido.
Versin 1.0
237

Ncleo de Monagas.
FECHA: Mayo 2009
NOMBRE DEL DOCUMENTO: Especificacin de casos de uso del Sistema: Generar
Hoja de Pedido.
1. BREVE DESCRIPCIN
El siguiente caso de uso describe el proceso para generar la lista de los
insumos necesarios para preparar los mens programados en la planificacin
alimentaria, y as poder realizar los pedidos de los mismos.
Autenticar Usuario
<<include>>
Generar Hoja de Pedido
Usuario del Sistema <<include>>
Elaborar Planificacion Alimentaria
Diagrama 35. Casos de Uso Generar Hoja de Pedido.


3.1 Caso de uso
Nutricionista
3.3 Precondiciones


Ncleo de Monagas.
FECHA: Mayo 2009
Hoja de Pedido.
Haber realizado la planificacin alimentaria. (Ver Especificacin de Casos de

uso Elaborar Planificacin Alimentaria).
1. Este caso de uso inicia cuando el usuario selecciona la opcin Planificar Servicio
del Men Principal.
2. El sistema abre nueva ventana y muestra opciones de creacin, modificacin,
eliminacin e impresin de planificaciones. Adems muestra la opcin de consultar
los insumos que son necesarios para preparar los mens programados en las
planificaciones. Tambin, busca las semanas en las que ya se ha planificado el
servicio y las planificaciones alimentarias planeadas para la ltima semana.
3. Consultar Insumos Requeridos de una Planificacin Alimentaria.
3.1 El usuario selecciona una planificacin alimentaria y presiona botn Insumos.
3.2 El sistema abre nueva ventana; busca informacin de la planificacin selecciona;
busca los insumos requeridos del men planificado y los otros insumos necesarios
para prestar el servicio en la planificacin seleccionada.
3.3 El sistema, calcula las cantidades totales de los insumos requeridos para prestar el
3.4 El sistema busca las existencias de los insumos requeridos en almacn.
3.5 Luego, el sistema muestra en pantalla el formulario con las cantidades
planificadas de insumos requeridos y sus existencias en almacn.
3.6 El usuario edita las cantidades a comprar de los insumos requeridos.
3.7 El usuario presiona botn Guardar.
3.8 El sistema guarda las cantidades a comprar de insumos requeridos para prestar el
3.9 El sistema muestra un mensaje en pantalla indicando que la lista de pedido ha
sido guardada.


Ncleo de Monagas.
FECHA: Mayo 2009
Hoja de Pedido.
3.10 Imprimir Hoja de Pedido.

3.10.1 El usuario presiona botn Imprimir.
3.10.2 El sistema genera reporte de Hoja de Pedido y lo enva a la impresora en
formato imprimible para que realice la impresin del mismo.
3.5 Postcondiciones
Lograr generar la hoja de pedido, la cual contiene las cantidades de insumos
que van a ser necesarios para preparar los mens programados en la planificacin
alimentaria y prestar el servicio.
En la lnea 3.7
3.7.1 En caso de que el usuario quiera volver a la pantalla anterior sin guardar
los datos, entonces presiona el botn Retornar.
3.7.2 El sistema abre y muestra la pantalla anterior.


Ncleo de Monagas.
FECHA: Mayo 2009
Hoja de Pedido.
(Ver Pgina 369)
Diagrama 36. Diagrama de Secuencia Generar Hoja de Pedido.



Ncleo de Monagas.
FECHA: Mayo 2009
Hoja de Pedido.
Pantalla 21. Listado de Insumos Requeridos de la Planificacin Alimentaria.


PROYECTO:

Controlar Acceso de Comensales.
Versin 1.0
243

Ncleo de Monagas.
FECHA: Junio 2009
NOMBRE DEL DOCUMENTO: Especificacin de casos de uso del Sistema: Controlar
Acceso de Comensales
1. BREVE DESCRIPCIN
El siguiente caso de uso describe el proceso para registrar los estudiantes que
acceden al comedor universitario para aprovechar el servicio de alimentacin.
Autenticar Usuario
<<include>>
Controlar Acceso de Comensales
Usuario del Sistema
Diagrama 37. Casos de Uso Controlar Acceso de Comensales.


3.1 Caso de uso
Controlar Acceso de Comensales.
Ayudante asignado, Estudiantes.
3.3 Precondiciones


Ncleo de Monagas.
FECHA: Junio 2009

1. Este caso de uso comienza cuando el usuario selecciona la opcin Registrar
Acceso Comensales del men principal.
2. El sistema abre nueva ventana, busca los tipos de mens, genera la fecha actual y
muestra esta informacin en pantalla.
3. Buscar Men alimentario a servir.
3.1 El usuario selecciona un tipo de men de acuerdo al turno que corresponda en el
da.
3.2 El sistema busca informacin del men alimentario planificado para la fecha
actual y de acuerdo al tipo de men seleccionado, y la muestra en pantalla.
4. Registrar Comensales.
4.1 El estudiante pasa cdigo de barra de su carnet estudiantil por el escner de
cdigo de barra que se encuentra conectado al sistema.
4.2 El sistema (o escner de cdigo de barra) captura cdula de identidad.
4.3 El sistema busca datos del estudiante de acuerdo a la cdula capturada y los
4.4 El usuario presiona botn Registrar.
4.5 El sistema comprueba si el estudiante ya accedi al comedor a aprovechar el
servicio.
4.6 El sistema registra el acceso del comensal al comedor universitario.
4.7 El sistema enva un mensaje indicando que el acceso del estudiante ha sido
registrado.
5. Salir.
5.1 El usuario presiona botn Salir.
5.2 El sistema abre y muestra el men principal.
6. Consultar Historial de comensales.


Ncleo de Monagas.
FECHA: Junio 2009
6.1 El usuario selecciona Consultar Historial de Comensales.

6.2 El sistema abre nueva ventana y muestra los tipos de bsquedas que se pueden
realizar.
6.3 El usuario selecciona un tipo de bsqueda y presiona botn Aceptar.
6.4 El sistema busca comensales registrados de acuerdo al tipo de bsqueda
seleccionado y los muestra en pantalla.
6.5 Imprimir informacin consultada.
6.5.1 El usuario presiona botn Imprimir.
6.5.2 El sistema genera reporte de la informacin consultada y lo enva a la impresora
en formato imprimible para que realice la impresin del mismo.
3.5 Postcondiciones
Realizar con xito el registro del nmero de comensales que asistieron al
comedor universitario para el aprovechamiento del servicio.
En la lnea 3.2 en caso de que el sistema no encuentre informacin de men
alimentario, este enva un mensaje indicando que no se realiz planificacin
alimentaria para el da y turno seleccionado.
En la lnea 4.3 en caso de que el sistema no encuentre datos de estudiante, este
emite un mensaje indicando que el estudiante no se encuentra activo en el presente
semestre.
En la lnea 4.5 en caso de que el estudiante ya haya accedido al comedor a
aprovechar el servicio, el sistema enva un mensaje a pantalla indicando que el
estudiante ya se encuentra registrado y pregunta si se desea volver a registrarlo.


Ncleo de Monagas.
FECHA: Junio 2009
(Ver Pgina 370)
Diagrama 38. Diagrama de Secuencia Controlar Acceso de Comensales.



Ncleo de Monagas.
FECHA: Junio 2009
Pantalla 22. Pantalla para Registro de Acceso Comensales.

Pantalla 23. Pantalla para Consultar Historial de Comensales.


PROYECTO:

Elaborar Solicitud de Servicio del Comedor.
Versin 1.0
249

Ncleo de Monagas.
FECHA: Mayo 2009
Solicitud de Servicio del Comedor.
1. BREVE DESCRIPCIN
El siguiente caso de uso describe el proceso para la elaboracin de solicitud de
servicio del comedor, para que ste facilite las comidas en caso de realizarse eventos
especiales en la universidad.
Autenticar Usuario
<<include>>
Elaborar Solicitud de Servicio del Comedor
Usuario Solicitante
Diagrama 39. Casos de Uso Elaborar Solicitud de Servicio del Comedor.


3.1 Caso de uso
Elaborar Solicitud de Servicio del Comedor.
3.3 Precondiciones
1. Este caso de uso comienza cuando el usuario selecciona la opcin Elaborar
Solicitud de Servicio del Men Principal.


Ncleo de Monagas.
FECHA: Mayo 2009
2. El sistema abre nueva ventana, genera fecha y nmero de solicitud, busca datos de
usuario y los tipos de mens o turnos; y muestra formulario en pantalla con toda esta
informacin.
3. El usuario llena datos de la solicitud y presiona botn Enviar.
4. El sistema valida datos introducidos de la solicitud.
5. El sistema enva la solicitud al comedor universitario.
6. El sistema enva mensaje a pantalla indicando que la solicitud ha sido enviada.
7. Salir.
3.5 Postcondiciones
Solicitud de servicio realizada y enviada al comedor universitario para su
posterior revisin por la administracin del comedor.
En la lnea 4 en caso de que los datos introducidos de la solicitud sean
invlidos, el sistema enva un mensaje para que el usuario verifique la informacin.


Ncleo de Monagas.
FECHA: Mayo 2009
W:SolicituddServicio SolicitudServicio Usuario TipoMenu DetalleSolicitud
Usuario
1.Selecciona Elaborar Solicitud de Servicio
2.abreVentana()
3.Carga Informacin
4.generarFecha()
5.generarNumSolicitud()
6.cargarUsuario()
7.Busca datos del usuario solicitante
buscarUsuario(CodUsuario)
9.cargarTipoMenu()
10.Busca Tipos de Menu
11.buscarT ipoMenu()
12.cargarFormulario()
13.Muestra formulario
14.Llena datos de solicitud

15.Presiona boton "Enviar"
16.Procesa
Si Resp=false 17.Resp=validar()
18.Datos Invalidos
19.enviarSolicitud()
Si Resp=true
20.Guarda detalles de la solicitud
21.agregarDetalle()
22.Solicitud Enviada
23.Presiona boton "Salir"

SALIR
24.abreVentana()
25.Muestra pantalla del menu principal
Diagrama 40. Diagrama de Secuencia Elaborar Solicitud Servicio del comedor.



Ncleo de Monagas.
FECHA: Mayo 2009
Pantalla 24. Pantalla para elaborar solicitud de servicio del comedor.


PROYECTO:

Consultar Solicitud de Servicio del Comedor.
Versin 1.0
254

Ncleo de Monagas.
FECHA: Mayo 2009
NOMBRE DEL DOCUMENTO: Especificacin de casos de uso del Sistema: Consultar
1. BREVE DESCRIPCIN
El siguiente caso de uso describe el proceso para consultar solicitudes de
servicio del comedor elaboradas.
Autenticar Usuario
<<include>>
Consultar Solicitud de Servicio del Comedor
Usuario del Sistema
Diagrama 41. Caso de Uso Consultar Solicitud de Servicio del Comedor.


3.1 Caso de uso
Consultar Solicitud de Servicio del Comedor.
Administrador del Comedor.
3.3 Precondiciones
1. Este caso de uso comienza cuando el usuario selecciona la opcin Consultar
Solicitudes de Servicio del Men Principal.


Ncleo de Monagas.
FECHA: Mayo 2009
2. El sistema abre nueva ventana, busca los diferentes status y las solicitudes de
servicio recibidas y los muestra en pantalla.
3. Buscar Solicitud de Servicio de Comedor.
3.1 Buscar Solicitudes por Status.
3.1.1 El usuario selecciona un status de solicitud.
3.1.2 El sistema busca solicitudes de acuerdo al status seleccionado y las muestra en
pantalla.
3.2 Buscar Solicitud llenando campo de bsqueda.
3.2.2 El sistema busca solicitudes que coincidan con los caracteres tecleados y filtra
lista de solicitudes de acuerdo a esa cadena de caracteres.
4. Consultar Solicitud de Servicio.
4.1 El usuario selecciona una solicitud de la lista y presiona el botn Consultar.
4.2 El sistema abre nueva ventana; busca toda la informacin de la solicitud
seleccionada; busca los status de solicitudes. Y por ltimo, muestra en pantalla la
informacin de la solicitud seleccionada para revisarla y cambiar su status.
4.3 El usuario selecciona status de la solicitud.
4.4 El sistema actualiza status de la solicitud.
4.5 El sistema muestra en pantalla un mensaje indicando que la solicitud ha sido
actualizada.
5. Imprimir Solicitud.
5.1 El usuario presiona botn Imprimir.
5.2 El sistema genera reporte de la solicitud consultada y lo enva a la impresora en
6. Retornar.


Ncleo de Monagas.
FECHA: Mayo 2009

7. Salir.
3.5 Postcondiciones
Solicitudes Revisadas.


Ncleo de Monagas.
FECHA: Mayo 2009
W:ConsultaSolicitudes W:SolicitudServicio SolicitudServicio StatusSolicitud DetalleSolicitud
Usuario Impresora
1.Selecciona Consultar Solicitudes de Servicio
2.abreVentana()
3.Busca Solicitudes de Servicio
4.cargarStatusSolicitud()
5.Busca los diferentes status de solicitudes
6.buscarStatusSolicitud()
7.buscarSolicitudes()
8.Muestra los diferentes status y la lista de solicitudes de servicio
BUSCAR 9.Selecciona Status Solicitud

SOLICIT UD 10.Busca Solicitudes
12.Muestra solicitudes de acuerdo al status seleccionado
13.Llena campo de busqueda
14.Presiona boton "Filtrar"

15.Busca solicitudes de acuerdo a caracteres tecleados
17.Filtra solicitudes de acuerdo a la cadena tecleada
18.Selecciona solicitud de la lista

CONSULT AR
SOLICITUD 19.Presion boton "Consultar"
20abreVentana()
21.Cambia Ventana
22.Carga informacion de la solicitud
23.buscarSolicitud(NumSolicitud)
24.cargarStatusSolicitud()
25,Busca los diferentes status de solicitudes
26.buscarStatusSolicitud()
27.cargarDetalleSolicitud()
28.Busca detalles de la solicitud seleccionada
29.buscarDetalleSolicitud()
30.cargarFormulario()
31.Muestra informacion de la solicitud
32.Cambia Status de la solicitud

33.Procesa
34.actualizarStatus()
35.Solicitud Actualizada
36.Presiona boton "Imprimir"

IMPRIMIR 37.Procesa
SOLICITUD
38.generarReporte()
39.Envia Solicitud en formato imprimible
40.Solicitud Impresa
41.Presiona boton "Retornar"

RET ORNAR
42.abreVentana()
43.Muestra pantalla anterior
SALIR 44.Presiona boton "Salir"

45.abreVentana()
46.Muestra pantalla del menu principal
Diagrama 42. Diagrama de Secuencia Consultar Solicitud Servicio del comedor.



Ncleo de Monagas.
FECHA: Mayo 2009
Pantalla 25. Listado de Solicitudes de Servicio Recibidas.

Pantalla 26. Pantalla para cambiar status de la solicitud de servicio del comedor.

PROYECTO:

Registrar Existencia de Articulo.
Versin 1.0
260

Ncleo de Monagas.
Existencia de Articulo.
1. BREVE DESCRIPCIN
El siguiente caso de uso describe el proceso para registrar las existencias de
insumos en almacn.
Autenticar Usuario
<<include>>
Registrar Existencia de Articulo
Usuario del Sistema

Diagrama 43. Casos de Uso Registrar Existencia de Articulo.

3.1 Caso de uso
Registrar Existencia de Articulo.
Almacenista.
3.3 Precondiciones
Insumos).


Ncleo de Monagas.

1. Este caso de uso inicia cuando el usuario selecciona la opcin Registrar Insumos
en Almacn del Men Principal.
Eliminar, Imprimir, Salir. Tambin, busca las existencias de artculos en
almacn y los muestra en pantalla.
3. Registrar Nuevo Insumo en Almacn.
3.1 El usuario presiona el botn Nuevo para agregar un nuevo artculo en almacn.
3.2 El sistema abre ventana y busca las ubicaciones en almacn creadas. Muestra en
pantalla el formulario para llenar los datos del nuevo artculo.
3.3 El usuario llena datos de existencia.
3.3.1 Buscar Insumo a registrar.
1. El usuario presiona icono Buscar Insumos.
2. El sistema abre nueva ventana, busca y muestra los tipos de insumos e insumos de
acuerdo al tipo que este seleccionado.
3. El usuario selecciona tipo de insumo.
pantalla.
5. El usuario llena campo de bsqueda y presiona el botn Filtrar.
pantalla.
7. Luego de realizar la bsqueda, el usuario selecciona un insumo de la lista.
8. El sistema cierra ventana y carga los datos del insumo seleccionado en el
formulario.
3.4 Guardar Existencia de Insumo en Almacn.


Ncleo de Monagas.

3.4.3 El sistema registra la existencia del insumo en el almacn.
3.4.4 El sistema enva mensaje a pantalla indicando que el artculo ha sido registrado.
4. Buscar Artculo Registrado.
4.1 El usuario llena campo de bsqueda y presiona botn Filtrar.
4.2 El sistema busca existencias de artculos que coincidan con los caracteres
tecleados y los muestra en pantalla.
5. Modificar Registro de Insumo en Almacn.
5.1 El usuario selecciona un artculo de la lista y presiona botn Modificar.
5.2 El sistema abre nueva ventana; busca datos del artculo seleccionado y las
ubicaciones en almacn. Luego, muestra en pantalla el formulario con la informacin
del artculo escogido.
5.3 El usuario edita datos del artculo existente en almacn y presiona botn
Guardar.
5.4 El sistema actualiza los datos del artculo existente en almacn.
5.5 El sistema enva un mensaje a pantalla indicando que el artculo ha sido
actualizado.
6. Eliminar Registro de Insumo en Almacn.
6.1 El usuario selecciona un artculo de la lista y presiona botn Eliminar.
6.2 El sistema muestra un mensaje de confirmacin para eliminar el artculo
seleccionado.
6.4 El sistema elimina el artculo seleccionado.
6.5 El sistema enva un mensaje indicando que el artculo ha sido eliminado
exitosamente.
7. Imprimir.


Ncleo de Monagas.
7.1 El usuario presiona el botn Imprimir.

7.2 El sistema genera reporte de existencias de artculos y lo enva a la impresora en
8. Salir.
3.5 Postcondiciones
Registro realizado de la existencia de insumo en almacn.
En la lnea 3.3
3.3.1 En caso de que el usuario quiera volver a la pantalla anterior sin guardar
los datos, entonces presiona el botn Retornar.
3.3.2 El sistema abre y muestra la pantalla anterior.
En la lnea 3.4.2 en caso de que los datos introducidos sean invlidos o que el insumo
ya este registrado en almacn, el sistema enva un mensaje para que el usuario


Ncleo de Monagas.
(Ver Pgina 371)
Diagrama 44.Diagrama de Secuencia Registrar Existencia de Articulo.



Ncleo de Monagas.
Pantalla 27. Lista de Stock de Artculos en Almacn.

Pantalla 28. Detalles de la Existencia de un Articulo en Almacn.


PROYECTO:

Registrar Entrada de Artculos en Almacn.
Versin 1.0
267

Ncleo de Monagas.
FECHA: Diciembre 2008
Entrada de Artculos en Almacn.
1. BREVE DESCRIPCIN
El siguiente caso de uso describe el proceso para registrar la entrada en
almacn de la mercanca de insumos pedida a los proveedores.
Autenticar Usuario
<<include>>
Registrar Entrada de Articulos en Almacen
Usuario del Sistema
Diagrama 45. Casos de Uso Registrar Entrada de Artculos en Almacn.


3.1 Caso de uso
Registrar Entrada de Artculos en Almacn.
Almacenista, Administrador del Comedor.
3.3 Precondiciones
Insumos).


Ncleo de Monagas.

1. Este caso de uso inicia cuando el usuario selecciona la opcin Registrar Entradas
del Men Principal.
2. El sistema abre nueva ventana; busca informacin de las rdenes de compra del
comedor universitario y los proveedores respectivos. Tambin, busca registros de
entradas y en caso de nuevas rdenes de compra realizadas a los proveedores se crean
nuevos registros de entradas con status Pendiente de Recibir. Por ltimo, busca los
status de entrada y muestra en pantalla la informacin de los registros de entradas de
artculos.
3. Buscar Registros de Entradas de Artculos.
3.1 Buscar Por Status.
3.1.1 El usuario selecciona un Status de Entrada.
3.1.2 El sistema busca registros de entrada de acuerdo al status seleccionado y los
3.2 Buscar registros llenando campo de bsqueda.
3.2.1 El usuario llena campo de bsqueda y presiona botn Filtrar.
3.2.2 El usuario busca registros de entrada de acuerdo a caracteres tecleados y los
4. Registrar Entrada de Artculos.
4.1 El usuario selecciona un registro de entrada de la lista y presiona botn
Registrar.
4.2 El sistema abre nueva ventana; busca datos del registro de entrada seleccionado y
los diferentes status de entrada. Luego, muestra en pantalla el formulario con la
informacin de registro de entrada seleccionado.
4.3 El usuario llena datos generales del registro de entrada de artculos.
4.4 Registrar detalle de insumo o artculo entrante.


Ncleo de Monagas.
4.4.1 El usuario presiona icono Buscar Insumos.

4.4.2 El sistema abre nueva ventana, busca y muestra los tipos de insumos e insumos
de acuerdo al tipo que est seleccionado.
4.4.3 El usuario selecciona tipo de insumo.
4.4.4 El sistema busca insumos de acuerdo al tipo seleccionado y los muestra en
pantalla.
4.4.6 El sistema busca insumos de acuerdo a caracteres tecleados y los muestra en
pantalla.
4.4.7 Luego de realizar la bsqueda, el usuario selecciona un insumo de la lista.
4.4.8 El sistema cierra ventana y carga los datos del insumo seleccionado en el
formulario.
4.4.9 El usuario escribe cantidad entrante del artculo y presiona botn Registrar.
4.4.10 El sistema agrega detalle de la entrada del artculo.
4.4.11 El sistema comprueba la existencia del artculo entrante en el almacn.
4.4.12 Si el artculo esta registrado, el sistema calcula la existencia actual de dicho
artculo.
4.4.13 El sistema muestra un mensaje en pantalla indicando que la entrada del
artculo ha sido registrada.
4.5 Modificar detalle de Insumo o Artculo Entrante.
4.5.1 El usuario edita datos de entrada de artculo.
4.5.2 El usuario edita precio unitario del artculo entrante.
4.5.3 El sistema actualiza detalle del artculo entrante y calcula el precio total de la
cantidad entrante de dicho artculo. Muestra el precio total calculado y enva un
mensaje en pantalla indicando que la entrada del artculo ha sido actualizada.
4.6 Guardar el registro de la entrada de Artculos.


Ncleo de Monagas.

4.6.3 El sistema actualiza el registro de la entrada de artculos.
4.6.4 El sistema muestra un mensaje en pantalla indicando que el registro de entrada
de artculos ha sido actualizada.
5. Imprimir
5.2 El sistema genera reporte de registro de entrada de artculos y lo enva a la
impresora en formato imprimible para que realice la impresin del mismo.
6. Retornar
7. Salir
3.5 Postcondiciones
Registro realizado de la entrada de artculos en almacn.
En la lnea 4.4.11 si el artculo no est registrado en almacn, el sistema
registra la nueva existencia del artculo en la despensa.
En la lnea 4.6.2 en caso de que los datos introducidos sean invlidos, el
sistema enva un mensaje para que el usuario verifique la informacin.


Ncleo de Monagas.
(Ver Pgina 372)
Diagrama 46. Diagrama de Secuencia Registrar Entrada de Artculos en Almacn.



Ncleo de Monagas.
Pantalla 29. Bandeja de Registro de Entradas.



Ncleo de Monagas.
Pantalla 30. Registro de Entrada de Artculos al Almacn.


PROYECTO:

Registrar Salida de Artculos de Almacn.
Versin 1.0
275

Ncleo de Monagas.
FECHA: Febrero 2009
Salida de Artculos de Almacn.
1. BREVE DESCRIPCIN
El siguiente caso de uso describe el proceso para registrar las salidas de
artculos de almacn.
Autenticar Usuario
<<include>>
Registrar Salida de Articulos de Almacen
Usuario del Sistema

Diagrama 47. Casos de Uso Registrar Salida de Artculos de Almacn.

3.1 Caso de uso
Registrar Salida de Artculos de Almacn.
Almacenista.
3.3 Precondiciones
Haber planificado los mens alimentarios que van a ser preparados en la
semana. (Ver Especificacin de Casos de uso Elaborar Planificacin Alimentaria).


Ncleo de Monagas.
FECHA: Febrero 2009

1. Este caso de uso comienza cuando el usuario selecciona la opcin Registrar
Salidas del Men Principal.
2. El sistema abre nueva ventana; genera fecha y nmero de salida y busca los tipos
de mens o turnos. Luego muestra en pantalla el formulario para realizar el registro
de la salida de artculos del almacn.
3. Buscar Men Planificado para saber que artculos van a salir del almacn.
3.1 El usuario selecciona un tipo de men de acuerdo al turno del da que corresponda
servir.
3.2 El sistema busca informacin de la planificacin alimentaria programada para la
fecha y turno seleccionado. Tambin, busca informacin del men planificado y los
insumos requeridos tanto para preparar dicho men como para prestar el servicio en
general.
3.3 El sistema busca las existencias registradas en almacn de aquellos insumos que
son necesarios para prestar el servicio de alimentacin.
3.4 El sistema verifica que las cantidades de insumos a utilizar se encuentran
disponibles.
3.5 El sistema muestra informacin para realizar el registro de la salida de artculos
de almacn.
4. Registrar Salida de Artculos del Almacn.
4.1 El usuario llena datos generales de salida.
4.2 Registrar Cantidad Saliente de Artculo del Almacn.
4.2.1 El usuario ingresa cantidad saliente del artculo.
4.2.2 El sistema verifica la cantidad saliente ingresada.
4.2.3 El sistema agrega el detalle de la salida del artculo y calcula el precio total de la
salida.


Ncleo de Monagas.
FECHA: Febrero 2009
4.2.4 El sistema calcula la existencia actual del artculo en almacn.

4.2.5 El sistema muestra en pantalla el precio total de la salida del artculo del
almacn.
4.3 Ajustar Existencia de Articulo en almacn.
4.3.1 El usuario selecciona artculo de la lista y presiona icono Ajustar Existencia de
Articulo.
4.3.2 El sistema abre nueva ventana, busca artculo y los tipos de ajustes.
4.3.3 El sistema muestra en pantalla el formulario para realizar el ajuste de existencia
de artculo.
4.3.4 El usuario llena formulario y presiona botn Guardar.
4.3.5 El sistema crea y realiza el ajuste de la existencia del artculo.
4.3.6 El sistema cierra ventana y enva un mensaje indicando que el ajuste ha sido
realizado.
4.5 El sistema crea registro de salida.
4.6 El sistema enva un mensaje a pantalla indicando que el registro de salida de
artculos ha sido registrado.
5. Modificar registro de salida de artculos del almacn.
5.1 El usuario edita cantidad saliente del artculo.
5.2 Modificar Cantidad Saliente de Artculo del Almacn.
5.2.1 El usuario edita cantidad saliente del artculo.
5.2.2 El sistema modifica el detalle de la salida del artculo y calcula el precio total de
la salida.
5.2.3 El sistema calcula la existencia actual del artculo en almacn.
5.2.4 El sistema muestra en pantalla el precio total de la salida del artculo del
almacn.


Ncleo de Monagas.
FECHA: Febrero 2009
5.3 Modificar Ajuste de Existencia de artculo de almacn.

5.3.1 El usuario presiona icono de Ajuste realizado a la existencia del artculo
seleccionado.
5.3.2 El sistema abre nueva ventana, busca los tipos de ajustes y el ajuste realizado a
la existencia del artculo seleccionado.
5.3.3 El sistema muestra en pantalla el formulario con informacin del ajuste del
artculo seleccionado
5.3.4 El usuario edita formulario y presiona botn Guardar.
5.3.5 El sistema modifica ajuste.
5.3.6 El sistema realiza ajuste a la existencia del artculo en almacn.
5.3.7 El sistema cierra ventana y enva un mensaje indicando que el ajuste ha sido
realizado.
5.5 El sistema modifica registro de salida.
5.6 El sistema enva un mensaje indicando que el registro de Salida de artculos ha
sido actualizado.
6. Imprimir.
6.2 El sistema genera reporte de registro de salida de artculos y lo enva a la
impresora en formato imprimible para que realice la impresin del mismo.
7. Salir.
3.5 Postcondiciones
Registro realizado de la salida de artculos de almacn.


Ncleo de Monagas.
FECHA: Febrero 2009

En la lnea 3.4
3.4.1 En caso de que en almacn no existan suficientes cantidades de insumos
para preparar el men planificado, el sistema enva un mensaje advirtiendo de dicha
escasez.
3.4.2 El usuario debe realizar cambios en la planificacin para programar otro
men de acuerdo a las existencias de insumos disponibles en el almacn. (Ver
Especificacin de Casos de uso Elaborar Planificacin Alimentaria).
En la lnea 4.2.2 en caso de que la cantidad ingresada no coincida con lo planificado o
que no exista dicha cantidad en almacn, el sistema enva mensajes indicando que la
cantidad saliente ingresada no coincide con lo planificado o que no existente en
almacn la cantidad ingresada del articulo.


Ncleo de Monagas.
FECHA: Febrero 2009
(Ver Pgina 373)
Diagrama 48. Diagrama de Secuencia Registrar Salida de Artculos de Almacn.



Ncleo de Monagas.
FECHA: Febrero 2009
Pantalla 31. Registro de Salida de Artculos de Almacn.

Pantalla 32. Ventana de Ajuste de Existencia de Articulo.


PROYECTO:
Especificacin de Casos de Uso de Sistema:

Generar Resumen de Costos.
Versin 1.0
283

Ncleo de Monagas.
FECHA: Marzo 2009
Resumen de Costos.
1. BREVE DESCRIPCIN
El siguiente caso de uso describe el proceso para generar reportes de los
costos implicados al prestar el servicio y el nmero de comensales atendidos, tanto
diaria como mensualmente.
Autenticar Usuario
<<include>>
Generar Resumen de Costos
Usuario del Sistema
Diagrama 49. Casos de Uso Generar Resumen de Costos.


3.1 Caso de uso
Generar Resumen de Costos.
Administrador del Comedor Universitario.
3.3 Precondiciones


Ncleo de Monagas.
FECHA: Marzo 2009
Resumen de Costos.

1. Este caso de uso inicia cuando el usuario selecciona Generar Resumen de Costos
de Men Principal.
2. El sistema abre nueva ventana y muestra lista de los tipos de reportes.
3. Generar Reporte Control Diario de Costos.
3.1 El usuario selecciona Control Diario de Costos de la lista de reportes.
3.2 El sistema muestra campo fecha.
3.3 El usuario introduce fecha y presiona el botn Aceptar.
3.4 El sistema busca planificaciones alimentarias de acuerdo a la fecha ingresada y
los mens programados para esas planificaciones.
3.5 El sistema busca la salida de artculos de almacn con sus respectivos detalles de
acuerdo a lo planificado para la fecha ingresada.
3.6 El sistema calcula el costo del servicio ofrecido tanto por turnos individuales
como del total del da de la fecha ingresada.
3.7 El sistema busca el nmero de comensales que acudieron al comedor universitario
en el da y turnos de la fecha ingresada.
3.8 El sistema calcula el costo unitario del servicio, por turno y del total del da.
3.9 Luego de realizar los clculos automticos, el sistema muestra en pantalla el
reporte del control diario de costos.
3.10 El usuario escribe observacin.
4. Generar Reporte Relacin Por Servicio y Nmero de Comensales.
4.1 El usuario selecciona Relacin Por Servicio y Numero de Comensales de la
lista de reportes.
4.2 El sistema muestra lista de meses y aos.
4.3 El usuario selecciona mes y ao.
4.4 El usuario presiona botn Aceptar.


Ncleo de Monagas.
FECHA: Marzo 2009
Resumen de Costos.
4.5 El sistema busca planificaciones alimentarias de acuerdo al mes y ao ingresado.

4.6 El sistema busca el nmero de comensales de acuerdo a los das y turnos
planificados en el mes y ao seleccionados.
4.7 El sistema calcula el total de comensales por turno y por da y el total de
comensales atendidos en todo el mes del ao seleccionado.
4.8 Luego de realizar los clculos, el sistema muestra en pantalla el reporte relacin
por servicio y nmero de comensales.
5. Generar Reporte Relacin de Alimentos, Bebidas y Otros Recibidas por
Almacn.
5.1 El usuario selecciona Relacin de Alimentos, Bebidas y Otros Recibidas por
Almacn de la lista de reportes.
5.2 El sistema busca los proveedores inscritos en la universidad destinados al
comedor universitario; y muestra en pantalla la lista de dichos proveedores, los meses
y los aos.
5.3 El usuario selecciona un mes, un ao y un proveedor.
5.4 Luego, este presiona el botn Aceptar.
5.5 El sistema busca las entradas de artculos en almacn de acuerdo al mes, ao y
proveedor seleccionados. Tambin busca informacin de las rdenes de compra y del
proveedor que entreg en almacn la mercanca de insumos.
5.6 El sistema calcula el costo total de la entrada de artculos en almacn.
5.7 El sistema muestra en pantalla el reporte relacin de alimentos, bebidas y otros
recibida por almacn.
6. Generar Reporte Relacin De Alimentos y Conexos Entregados Por Almacn.
6.1 El usuario selecciona Relacin de Alimentos y Conexos Entregados Por
Almacn de la lista de reportes.


Ncleo de Monagas.
FECHA: Marzo 2009
Resumen de Costos.
6.3 El usuario selecciona mes y ao.

6.5 El sistema busca registros de salidas de artculos de almacn con sus respectivos
detalles, de acuerdo al mes y ao seleccionados.
6.6 El sistema calcula el costo total de salidas de artculos de almacn por da y de
todo el mes del ao seleccionado.
6.7 El sistema muestra en pantalla el reporte relacin de alimentos y conexos
entregados por almacn.
7. Generar Reporte Resumen Mensual de Costos.
7.1 El usuario selecciona Resumen Mensual de Costos de la lista de reportes.
7.4 El sistema busca planificaciones de acuerdo al ao seleccionado.
7.5 Luego, busca las salidas de artculos de almacn de acuerdo a los das y turnos
planificados en el ao seleccionado.
7.6 El sistema calcula costo total de salida de artculos de almacn en el mes y aos
seleccionados.
7.7 El sistema calcula el Costo Total del Mes.
7.8 El sistema calcula el costo total acumulado hasta el mes anterior.
7.9 El sistema calcula el costo total acumulado a la fecha.
7.10 Despus, el sistema busca el nmero de comensales atendidos en los das y
turnos planificados en el ao seleccionado.
7.11 El sistema calcula el total de comensales atendidos en el mes seleccionado.
7.12 El sistema calcula el total de comensales atendidos hasta el mes anterior.
7.13 El sistema calcula el total de comensales a la fecha.
7.14 Luego, el sistema calcula el costo unitario del servicio prestado en el mes.


Ncleo de Monagas.
FECHA: Marzo 2009
Resumen de Costos.
7.15 El sistema calcula el costo unitario del servicio a la fecha.

7.16 Finalmente, el sistema muestra reporte resumen mensual de costos.
7.17 El usuario edita reporte.
8. Imprimir Reporte.
8.2 El sistema genera reporte y lo enva a la impresora en formato imprimible para
que realice la impresin del mismo.
9 Salir.
3.5 Postcondiciones
Lograr generar los reportes de costos y del nmero de servicio atendidos por
el comedor universitario.


Ncleo de Monagas.
FECHA: Marzo 2009
Resumen de Costos.
(Ver Pgina 374)
Diagrama 50. Diagrama de Secuencia Generar Resumen de Costos.



Ncleo de Monagas.
FECHA: Marzo 2009
Resumen de Costos.
Pantalla 33. Reporte Control Diario de Costo.

Pantalla 34. Reporte Relacin por Servicio y Nmero de Comensales.



Ncleo de Monagas.
FECHA: Marzo 2009
Resumen de Costos.
Pantalla 35. Reporte Relac. de alimentos., bebidas y otros recibidos por almacn.
Pantalla 36. Reporte Relacin de alimentos y conexos entregados por almacn.



Ncleo de Monagas.
FECHA: Marzo 2009
Resumen de Costos.
Pantalla 37. Reporte Resumen Mensual de Costo.


PROYECTO:
Especificaciones Suplementarias
Versin 1.0
293

Ncleo de Monagas.
NOMBRE DEL DOCUMENTO: Especificaciones Suplementarias.
1. Introduccin
1.1 Propsito
En este documento se identifican los requisitos que no fueron capturados en
los casos de uso. Los cuales complementan el desarrollo del Sistema Web para la
Planificacin y Control del Servicio de Alimentacin Prestado por el Comedor
Universitario de la Universidad de Oriente Ncleo de Monagas.
1.2 Alcance
Este documento abarca los requisitos del sistema clasificados segn el modelo
FURPS+.
1.3 Definiciones, Siglas y Abreviaturas
FURPS+: modelo de calidad desarrollado por Robert B. Grady de Hewlett-Packard
en 1992 y extendido por Rational Software a FURPS+; que permiten clasificar las
cualidades de la calidad de software. FURPS+ es el acrnimo en ingles de las
diferentes categoras: funcionalidad (Functionality), usabilidad (Usability),
confiabilidad (Reliability), desempeo (Performance) y capacidad de soporte
(Supportability). El + en FURPS+ indica requisitos adicionales, tales como:
implementacin, interfaz, diseo, operaciones, licencias, restricciones fsicas, etc.
1.4 Apreciacin Global
En este documento se describen los requisitos funcionales y no funcionales del
sistema, adems de requerimientos mnimos para el correcto funcionamiento del
software, tomando en cuenta los requisitos de calidad FURPS+.
2. Requisitos de calidad FURPS+

2.1 Funcionalidad
Describen qu es lo que un usuario debe ser capaz de hacer a travs del
sistema de software. Las funcionalidades se refieren a las funciones que el sistema


Ncleo de Monagas.
ejecutar, es decir, un conjunto de caractersticas requeridas del sistema que expresan

una capacidad de accin del mismo. Estos requisitos son capturados a travs de los
casos de uso del sistema, los cuales describen el comportamiento del sistema, y la
manera en que los actores interactan con este.
Las funcionalidades o requisitos funcionales se valoran evaluando el conjunto
de caractersticas y capacidades del sistema y la generalidad de las funciones
entregadas.
2.2 Usabilidad
La facilidad de uso o usabilidad incluye todos aquellos atributos que facilitan
la interaccin del usuario con el sistema, como por ejemplo: la esttica, la
consistencia de la interfaz de usuario, ayuda en lnea, entre otros. Esta se refiere a la
capacidad de un software de ser comprendido, aprendido, usado y ser atractivo para el
usuario, en condiciones especficas de uso.
Esta ltima definicin hace nfasis en los atributos internos y externos del
producto, los cuales contribuyen a su usabilidad, funcionalidad y eficiencia. La
usabilidad depende no slo del producto sino tambin del usuario. Por ello un
producto no es en ningn caso intrnsecamente usable, slo tendr la capacidad de ser
usado en un contexto particular y por usuarios particulares. La usabilidad no puede
ser valorada estudiando un producto de manera aislada, por tal motivo la usabilidad o
facilidad de uso est ntimamente ligada al usuario.
El sistema desarrollado posee una interfaz grfica cmoda y sencilla para que
as el usuario aprenda fcilmente a utilizar el software y se sienta familiarizado con el
mismo. Dicha interfaz fue elaborada tomando en cuenta el estilo corporativo de
portales establecido por la universidad, en cuanto a colores, disposicin de la
informacin, logos, etc., as como tambin el encabezado tpico establecido para los


Ncleo de Monagas.
sistemas de informacin de la universidad y una serie de botones, que por su diseo y

caractersticas le indican al usuario las acciones que pueden realizar (como guardar la
informacin, actualizar, eliminar, generar reportes, salir de un proceso, entre otros).
2.3 Fiabilidad
Este requisito tiene que ver con la probabilidad de que el sistema funcione o
desarrolle una determinada funcin, bajo ciertas condiciones y durante un perodo de
tiempo determinado. En otras palabras, es la habilidad de un sistema para
comportarse correctamente sobre su entorno de ejecucin real. Se evala midiendo la
disponibilidad del sistema, la exactitud de las salidas, frecuencia y gravedad de los
fallos, el tiempo medio entre fallos, la capacidad de recuperacin ante un fallo y la
capacidad de prediccin del programa.
Dentro de los problemas que podran presentarse y que podran causar fallas
en el sistema, se encuentran: problemas con el servidor, problemas con el cliente
(navegador), fallos de electricidad, problemas con la base de datos, etc. Pero, en
algunos casos, antes de que alguno de ellos ocurran se irn haciendo respaldos o
copias de seguridad en medios extrables de toda la informacin almacenada en la
base de datos del sistema constantemente, esto para garantizar la recuperacin de la
informacin. Y adems para garantizar el efectivo funcionamiento del sistema se
harn revisiones y pruebas peridicas.
2.4 Rendimiento
El rendimiento es la medida o cuantificacin de la velocidad o resultado con
que un sistema realiza una tarea o proceso y se mide por la velocidad de
procesamiento, el tiempo de respuesta, consumo de recursos, rendimiento efectivo
total y eficacia.


Ncleo de Monagas.
En el caso actual, el sistema posee un alto nivel de rendimiento ya que es una

aplicacin Web liviana, de rpido acceso; que no necesita de tantos recursos para
funcionar en las computadoras clientes. En cuanto al hardware del servidor el nivel de
rendimiento tambin es elevado puesto que el sistema cuenta con un servidor SUM
FIRE X2100, uno de los servidores con mayor rendimiento en el mercado, fcil de
gestionar y con una plataforma ideal para dar servicios Web, contando adems con
dos procesadores AMD cuyo consumo energtico es bajo. Por lo que el servidor,
entonces, estar aportando las prestaciones necesarias para responder de manera
fluida a todas las computadoras clientes que utilicen la aplicacin de forma
concurrente.
2.5 Soporte
a) Requisitos de instalacin. El sistema es una aplicacin Web que se cargar en el
servidor SUM FIRE X2100 del centro de computacin de la Universidad de Oriente
Ncleo Monagas, al cual se le instalar previamente el sistema operativo CentOS
(acrnimo de Community ENTerprise Operating System), el administrador Web
Apache, PHP, los cuales son de libre distribucin, luego el manejador de base de
datos Oracle 10G, el cual es licenciado.
b) Requisitos de configuracin. Instalar producto Oracle en cliente que permitir la
comunicacin con el servidor. Habilitar direccin IP (protocolo de Internet) y puertos
para levantar ambiente Web y base de datos.
c) Requisitos de adaptabilidad. El uso del software no necesita de una preparacin
previa para que el usuario pueda acceder a l para realizar sus actividades. Este est
adaptado de acuerdo a las necesidades del usuario.
d). Requisitos de compatibilidad. Sistema operativo Linux y Oracle 10G.


Ncleo de Monagas.
2.6 Restricciones de Implementacin

El sistema est siendo desarrollado en la Universidad de Oriente ncleo
Monagas, haciendo uso de la tecnologa de esta casa de estudio, basndose en los
lenguajes de programacin HTML, PHP 5, JavaScript, SAJAX.
2.7 Restricciones de Diseo

El diseo del software est sustentado en las normas y estndares que han sido
establecidas a nivel de rectorado; por lo que la codificacin se realiz trabajando con
clases, es decir, una programacin orientada a objetos. En cuanto al hardware se
utilizaron los equipos con los que cuenta el centro de computacin de la UDO-
Monagas para el desarrollo de los sistemas informticos. Por seguridad de la
informacin utilizada en el sistema se crearn perfiles para cada uno de los usuarios
que acceden a este.
2.8 Requisitos de Interfaces

De manera general, una interfaz es un punto o una zona de interconexin entre
dos entidades, elementos, sistemas, equipos, conceptos, etc. que les permite trabajar
juntos. Con respecto, a la interaccin entre usuario y software, la interfaz viene a ser
el medio con que el usuario puede comunicarse con el sistema y comprende todos los
puntos de contacto entre ellos. La interfaz de usuario es lo que el usuario ve y con la
cual interacta, incluyendo pantallas, ventanas, mens, formularios, etc. Entre los
principios generales que cumple el diseo de la interfaz del sistema se encuentran los
siguientes:
a) Interfaz accesible e intuitiva: la interfaz ha de ser lo ms simple posible. Se debe
dar al usuario el ambiente flexible para que pueda aprender rpidamente a usar la
aplicacin.


Ncleo de Monagas.
b) Consistencia del portal entre los distintos navegadores: el portal Web debe
visualizarse y manejarse de una forma igual o, en caso de que sea imposible, de la
forma ms parecida posible en los navegadores mayoritarios (Firefox, Internet
Explorer, Opera, Google Chrome, etc.), prioritariamente para las ltimas versiones y
a ser posible para versiones anteriores.
c) Diseo ergonmico: hacer usos de mens, iconos, etc. para la comodidad del
usuario.
d) Alto grado de usabilidad y sencillez.
2.8.1 Interfaz del Usuario

El sistema mostrar alguna de las siguientes pantallas:
- Planificacin Alimentaria.
- Registro de comensales.
- Elaborar Solicitud de Servicio de Comedor.
- Registrar existencia de Insumos o artculos en almacn.
- Registrar Entradas de Insumos en almacn.
- Registrar Salidas de Insumos de almacn.
- Identificacin de usuarios del sistema.
- Administrar Usuarios del Sistema, entre otras.
2.8.2 Interfaz del Hardware
- La Pantalla.
- La Impresora.
2.8.3 Interfaz de Software
El sistema debe interactuar con el sistema de compras para obtener
informacin sobre las rdenes de compra, las cuales son necesarias para realizar los
procesos de registro de entradas de insumos. Tambin, el sistema debe comunicarse


Ncleo de Monagas.
con el sistema de control de estudio, el cual servir de colaboracin externa para

llevar a cabo el proceso de control de acceso de comensales.
2.8.4 Interfaz de Comunicacin
La interfaz de comunicacin sirve de enlace entre los aparatos y la
computadora en el que reside el software. Dicha interfaz tiene por funcin adaptar el
protocolo y el enlace fsico. La conexin puede ser realizada por el Centro de
Computacin de diversas formas, a travs de cable de trenzado, por red inalmbrica o
por fibra ptica, dependiendo cul de ellos sea el ms conveniente de utilizar.
2.9 Requisitos mnimos de Hardware destacables para una buena interaccin

software, hardware y usuario.
- Monitores de 14 pulgadas, de resolucin 800x600.
- Pentium 4, procesador de 2.4 GHz, 512 en memoria RAM, 40 Gb en disco
duro.
- Impresora Lser.
- Tarjeta de Red PCI (10-100)
Centro de Computacin
Internet
Comedor
Universitario
Figura 30. Representacin de Equipos.


Ncleo de Monagas.
3. Reglas del Dominio

Cuadro 32. Reglas del Dominio
Grado de
ID Regla Fuente
Variacin
Los servicios del comedor solo
podrn ser utilizados por los
Manual del Comedor
Regla 1 usuarios naturales, o sea estudiantes, Bajo.
Universitario.
trabajadores y profesores de la
UDO.
El administrador, de acuerdo y con
el apoyo de las autoridades del
ncleo, tomar las medidas Manual del Comedor
Regla 2 Bajo.
restrictivas y de control necesario Universitario.
para el cumplimiento de la norma
anterior.
Los funcionarios del comedor, en
los actos de preparacin y entrega
de las comidas, deben ceirse a las
normas de higiene establecidas por
Manual del Comedor
Regla 3 el Ministerio de Sanidad; Bajo.
Universitario.
igualmente deben mantener un
aspecto limpio, especialmente los
que estn en contacto con los
usuarios.
Los usuarios y los trabajadores
Manual del Comedor
Regla 4 deben guardar el debido respeto en Bajo.
Universitario.
sus obligadas relaciones.


Ncleo de Monagas.
Cuadro 32. Reglas del Dominio (Continuacin).

En la elaboracin de los mens se
tendr en cuenta tanto el valor Manual del Comedor
Regla 5 Bajo.
nutritivo de los alimentos, como su Universitario.
costo y oportunidad de adquisicin.
En la elaboracin de los platos
deben considerarse la presentacin,
el sabor y la cantidad per capita, de Manual del Comedor
Regla 6 Bajo.
manera que los usuarios se sientan Universitario.
satisfechos, aunque no
necesariamente hartos.
No se servir comida a los usuarios
que no entreguen el correspondiente
Manual del Comedor
Regla 7 ticket o que entreguen uno que no Bajo.
Universitario.
est de acuerdo con su categora de
trabajador o profesor.
Los horarios deben ser respetados, a
cuyo efecto el Administrador tomar Manual del Comedor
Regla 8 Bajo.
las medidas que considere Universitario.
convenientes.
El Administrador deber procurar,
con los medios de que dispone, Manual del Comedor
Regla 9 Bajo.
adquirir los mejores materiales en Universitario.
plaza.
El comedor procurar ofrecer
comida variada y balanceada, a cuyo Manual del Comedor
Regla 10 Bajo.
efecto podr asesorarse con el Universitario.
Instituto Nacional de Nutricin.


Ncleo de Monagas.
4. Cuestiones Legales
Se recomienda seguir los procedimientos establecidos en los manuales de
organizacin y procedimientos del comedor universitario de la Universidad de
Oriente.

PROYECTO:
Arquitectura del Sistema

Versin 1.0
304

Ncleo de Monagas.
FECHA: Marzo 2009
NOMBRE DEL DOCUMENTO: Arquitectura del Sistema.
1. Introduccin
1.1 Propsito
El presente documento contiene el diseo arquitectnico del sistema Web para
la Planificacin y Control del Servicio de Alimentacin Prestado por el Comedor
Universitario de la Universidad de Oriente Ncleo de Monagas, el cual es producto
de un anlisis minucioso de los requisitos del sistema.
1.2 Alcance
Abarca la vista lgica, de datos y de implementacin de la arquitectura del
sistema.
1.3 Descripcin General
La arquitectura del software consiste en un conjunto de patrones y
abstracciones coherentes que proporcionan el marco de referencia necesario para
guiar la construccin del software. Dicha arquitectura es una vista del sistema, que
comprende los principales componentes del software, las propiedades visibles de esos
componentes y las relaciones entre ellos.
El diseo arquitectnico ha de ajustarse a las necesidades y requisitos del
proyecto. Esta seccin describe en trminos generales, las ideas principales detrs de
la arquitectura escogida para el mismo.
2. Vistas y Planos
Este documento contiene varias vistas que muestran aspectos distintos del
sistema. A continuacin se detallan las vistas utilizadas en este proyecto para
describir la arquitectura del sistema.
2.1 Vista Lgica
Representa los elementos de diseo ms importantes para la arquitectura del
sistema, ya que soporta los requisitos funcionales del sistema, presenta las clases


Ncleo de Monagas.
FECHA: Marzo 2009
significativas desde el punto de vista de la arquitectura y describe sus

responsabilidades, as como algunas relaciones, operaciones y atributos de gran
importancia. Se encuentra representado por el modelo de clases y por las tarjetas
CRC.
Modelo de Clases
Un diagrama de clases es un tipo de diagrama esttico que describe la
estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos.
Estos diagramas son el pilar bsico del modelado con UML, siendo utilizados tanto
para mostrar lo que el sistema puede hacer, como para mostrar cmo puede ser
construido. A continuacin se puede visualizar el modelo de clases del sistema:


Ncleo de Monagas.
FECHA: Marzo 2009
(Ver Pgina 375)
Diagrama 51. Modelo de Clases.



Ncleo de Monagas.
FECHA: Marzo 2009
Tarjetas CRC
Las tarjetas CRC son muy tiles para observar la relacin entre cada una de
las clases que conforman el modelo de clases y las responsabilidades de cada una de
ellas.
Como una extensin informal a UML, la tcnica de las tarjetas CRC se puede
usar para guiar el sistema a travs de anlisis guiados por la responsabilidad. Esta
tcnica define las responsabilidades y colaboraciones de cada clase a travs de todos
los escenarios. Las clases se examinan, se filtran y se refinan en base a sus
responsabilidades con respecto al sistema, y las clases con las que necesitan colaborar
para completar sus responsabilidades.
A continuacin se muestran las tarjetas CRC de las clases principales del
modelo de Clases:
Nombre de la Clase AccesoComensal

Responsabilidades Clases Colaboradoras
Cargar Datos de Estudiante. Estudiante
Comprobar acceso de comensales. Planificacin
Registrar el acceso de los
comensales.
Buscar comensales registrados.
Generar reporte de comensales
registrados.
Figura 31. Tarjeta CRC AccesoComensal.



Ncleo de Monagas.
FECHA: Marzo 2009
Nombre de la Clase SolicitudServicio

Cargar datos de usuario Usuario
Cargar status de solicitudes StatusSolicitud
Generar fecha de envo de solicitud
Generar numero de solicitud
Buscar solicitudes
Cambiar status de solicitud
Figura 32. Tarjeta CRC SolicitudServicio.
Nombre de la Clase Insumo

Cargar tipos de insumos. TipoInsumo
Cargar unidades de medida. Um
Cargar grupos de alimentos. Alimento
Cargar tipos de nutrientes.
Cargar nutrientes.
Buscar insumos.
Comprobar utilizacin de insumos
Figura 33. Tarjeta CRC Insumo.
Nombre de la Clase Men

Cargar Tipos de Mens TipoMenu
Cargar Insumos Requeridos del InsumoRequeridoMenu
Men.
Cargar Nutrientes de los Alimentos.
Calcular Nutrientes del Men.
Buscar Mens.
Comprobar Utilizacin de Men.
Figura 34. Tarjeta CRC Men.


Ncleo de Monagas.
FECHA: Marzo 2009
Nombre de la Clase Planificacin

Cargar Semanas Men
Crear Fechas de la Semana. TipoMen
Cargar Tipos de Mens Semana
Cargar nmero de comensales InsumoRequeridoPlanificacion
registrados AccesoComensal
Estimar Nmero de Comensales.
Cargar insumos requeridos de la
planificacin
Cargar el Men planificado
Calcular Cantidad Total de Insumos
Requeridos a utilizar.
Cargar Existencias de Artculos en
Almacn
Comprobar Existencias de insumos
requeridos.
Generar Reporte de Planificacin.
Buscar Planificaciones Alimentarias.
Figura 35. Tarjeta CRC Planificacin.
Nombre de la Clase ExistenciaArticulo

Cargar ubicaciones de almacn. Insumo
Buscar existencias de artculos en Ubicacin
almacn. DetalleEntradaArticulo
Comprobar existencia de artculo DetalleSalidaArticulo
en almacn. AjusteExistencia
Calcular existencia actual de
artculo.
Ajustar existencia de artculo en
almacn.
Generar reporte de existencias de
artculos en almacn.
Figura 36. Tarjeta CRC ExistenciaArticulo.


Ncleo de Monagas.
FECHA: Marzo 2009
2.2 Vista de Datos

Esta vista especifica arquitectnicamente los elementos constantes en el
modelo de datos. Describe una apreciacin global del modelo de los datos y su
organizacin por lo que se refiere a las tablas, vistas, ndices, etc. Tambin describe la
cartografa de clases constantes de la Vista Lgica a la estructura de los datos de la
base de datos.
La vista de datos refleja la perspectiva del almacenamiento de datos
constantes en el sistema y est representado por el modelo conceptual, el modelo
fsico y modelo de base de datos relacional. A continuacin se presentan cada uno de
estos modelos.


Ncleo de Monagas.
FECHA: Marzo 2009
Modelo Conceptual
(Ver Pgina 376)
Diagrama 52. Modelo Conceptual.



Ncleo de Monagas.
FECHA: Marzo 2009
Modelo Fsico
(Ver Pgina 377)
Diagrama 53. Modelo Fsico.



Ncleo de Monagas.
FECHA: Marzo 2009
Modelo de base de datos relacional del sistema
(Ver Pgina 378)
Diagrama 54. Modelo de Base de Datos Relacional del Sistema.



Ncleo de Monagas.
FECHA: Marzo 2009
2.3 Vista de Despliegue

Esta vista se representa mediante el modelo de despliegue y define la
arquitectura fsica del sistema por medio de nodos interconectados. Estos nodos son
elementos hardware sobre los cuales pueden ejecutarse los elementos software. El
sistema estar distribuido como se muestra en el Diagrama 55.
El protocolo de comunicacin utilizado para relacionar los distintos nodos fue
el protocolo de seguridad HTTPS (Hypertext Transfer Protocol Secure), el cual
utiliza un cifrado basado en el SSL (Secure Socket Layers), creando un canal cifrado
para enviar/recibir informacin.
<HTTPS> Sistema Web

<HTTPS>
Usuarios Comedor Universitario
Aplicacion Web
Explorador Web
Servidor Web
<HTTPS>
Servidor de Base de Datos Oracle 10G
Manejador de Base de Datos Oracle 10G
Base de Datos
Diagrama 55. Modelo de Despliegue.


5.3 Etapa III. Construccin del Software.
El objetivo de esta etapa es llegar a obtener la capacidad operacional inicial

del sistema. Ac se profundiza en el diseo de los componentes y de manera iterativa
se van aadiendo las funcionalidades al software a medida que se construyen y
prueban, permitiendo a la vez que se puedan ir incorporando cambios.
Ms detalladamente, a travs de diferentes iteraciones se fueron aadiendo

funcionalidades al sistema, hasta llegar a la construccin de un prototipo inicial. En
esta etapa, se realiz la codificacin de los mdulos de administracin del sistema
como la configuracin y su mantenimiento, incluyendo los procesos de validar y
administrar usuarios. Tambin, se llev a cabo la programacin de los procesos de
creacin de insumos y mens alimentarios, planificacin alimentaria, elaboracin y
consulta de solicitudes para eventos especiales; adems del registro de acceso de
comensales al comedor universitario. Todos estos mdulos se tomaron como
prioridad debido a que influyen en la realizacin de la planificacin alimentaria, que
es uno de los procesos ms indispensables para prestar el servicio de alimentacin a
la comunidad universitaria.
En esta etapa se obtuvieron los siguientes resultados: los documentos de casos

de prueba, un documento glosario y un prototipo inicial del sistema.
316
PROYECTO:
Especificacin de Caso de Prueba

Tipo de Men
Versin 1.0
317

Ncleo de Monagas.
FECHA: Abril 2009
NOMBRE DEL DOCUMENTO: Especificacin de Caso de Prueba: Tipo de Men.
1. Descripcin
El presente artefacto cubre el conjunto de pruebas realizadas sobre el
mantenimiento Tipo de Men. Dicho mantenimiento es utilizado para actualizar, a
travs de una interfaz de usuario, la informacin del sistema, relacionada con los
diferentes tipos de mens o turnos en los que pueden ser servidos los mens
alimentarios. Las pruebas realizadas a este caso de uso son: agregar, editar y eliminar
tipo de men y buscar tipos de men creados.
La prueba se realizar partiendo del formulario de entrada de la aplicacin.
2. Agregar Tipo de Men

2.1 Descripcin
Se ingresa al sistema como usuario administrador para acceder al
mantenimiento de Tipos de Men, con el fin de crear un nuevo tipo con su
informacin respectiva para que quede guardado en el sistema para su posterior
utilizacin.
2.2 Condiciones de Ejecucin
La nica condicin es que el usuario est registrado como administrador, para
poder acceder al sistema.
2.3 Entrada
1. Se introduce administrador en el campo usuario.
2. Se introduce UDO en el campo contrasea.
3. Se pulsa el botn Ingresar.
4. El sistema permite el acceso al sistema y muestra el men principal del
administrador.
5. Se posiciona el cursor del Mouse en la opcin Mantenimientos Planificacin del
men principal.


Ncleo de Monagas.
FECHA: Abril 2009
6. El sistema despliega la lista de mantenimientos disponibles.

7. Se selecciona Tipo de Men de la lista.
8. El sistema muestra una interfaz con la lista de tipos de mens registrados y las
opciones permitidas (Nuevo, Modificar, Eliminar, Bsqueda por filtro).
9. Se hace clic en el botn Nuevo.
10. El sistema muestra en pantalla unos campos vacos para ingresar el cdigo y
descripcin del nuevo tipo de men.
11. Se ingresa 03 en el campo para el cdigo.
12. Se ingresa CENA en el campo para la descripcin.
13. Se pulsa el botn Agregar.
14. El sistema enva un mensaje preguntando si se desea agregar el registro.
15. Se pulsa OK.
16. El sistema regresa a la pantalla anterior y muestra en la lista el nuevo tipo de
men registrado.
2.4 Resultado Esperado
El sistema crea un nuevo tipo de men.
2.5 Evaluacin de la Prueba
Prueba realizada satisfactoriamente.
3. Editar Tipo de Men

3.1 Descripcin
mantenimiento de Tipos de Men, con el fin de modificar la informacin de un tipo
de men registrado.


Ncleo de Monagas.
FECHA: Abril 2009

3.3 Entrada
administrador.
men principal.
9. Se selecciona el tipo de men CENA de la lista y se hace clic en el icono
Modificar.
10. El sistema enva un mensaje preguntando si se desea modificar el item
seleccionado.
11. Se pulsa el botn OK.
12. El sistema muestra en pantalla unos campos llenos con informacin del tipo de
men seleccionado.
13. Se modifica el campo descripcin introduciendo MERIENDA.
14. Se pulsa el icono Modificar.
15. El sistema enva un mensaje preguntando si se desea modificar el registro.
16. Se pulsa OK.


Ncleo de Monagas.
FECHA: Abril 2009
17. El sistema regresa a la pantalla anterior y muestra en la lista el tipo de men

modificado.
El sistema modifica la informacin del tipo de men seleccionado.
Prueba superada con xito.
4. Eliminar Tipo de Men

4.1 Descripcin
mantenimiento de Tipos de Men, con el fin de eliminar la informacin de un tipo
especfico.
4.3 Entrada
administrador.
men principal.


Ncleo de Monagas.
FECHA: Abril 2009
9. Se selecciona el tipo de men MERIENDA de la lista y se hace clic en el icono
Eliminar.
10. El sistema enva un mensaje preguntando si se desea eliminar el item
seleccionado.
11. Se pulsa OK.
12. El sistema muestra en pantalla unos campos llenos con informacin del tipo de
men seleccionado.
13. Se pulsa Eliminar.
14. El sistema enva un mensaje preguntando si se desea eliminar el registro.
15. Se pulsa OK.
16. El sistema regresa a la pantalla anterior y el tipo de men ya no aparece en la
lista.
El sistema elimina el tipo de men que fue seleccionado.
5. Buscar Tipo de Men

5.1 Descripcin
mantenimiento de Tipos de Men, con el fin de buscar la informacin de un tipo
especfico.


Ncleo de Monagas.
FECHA: Abril 2009

5.3 Entrada
administrador.
men principal.
9. Se introduce DESAYUNO en el filtro de bsqueda.
10. Se presiona el botn Filtrar.
11. El sistema muestra la informacin del tipo de men solicitado.
El sistema busca el tipo de men consultado.

PROYECTO:

Nutrientes
Versin 1.0
324

Ncleo de Monagas.
FECHA: Abril 2009
NOMBRE DEL DOCUMENTO: Especificacin de Caso de Prueba: Nutrientes
1. Descripcin
El presente artefacto cubre el conjunto de pruebas realizadas sobre el
mantenimiento Nutrientes. Dicho mantenimiento es utilizado para actualizar, a
travs de una interfaz de usuario, la informacin del sistema, relacionada con los
diferentes valores nutricionales que pueden contener los insumos alimenticios. Las
pruebas realizadas a este caso de uso son: agregar nutriente, editar nutriente, eliminar
nutriente y buscar nutrientes creados.
2. Agregar Nutriente
2.1 Descripcin
mantenimiento de Nutrientes, con el fin de crear un nuevo nutriente con su
informacin respectiva para que quede guardado en el sistema para su posterior
utilizacin.
2.3 Entrada
administrador.
men principal.


Ncleo de Monagas.
FECHA: Abril 2009

7. Se selecciona Nutrientes de la lista.
8. El sistema muestra una interfaz con la lista de nutrientes registrados y las opciones
permitidas (Nuevo, Modificar, Eliminar, Bsqueda por filtro).
10. El sistema muestra en pantalla unos campos para ingresar el cdigo, descripcin,
unidad de medida y el tipo al que pertenece el nuevo nutriente.
11. Se ingresa 000008 en el campo para el cdigo.
12. Se ingresa NIACINA en el campo para la descripcin.
13. Se selecciona la unidad de medida Gr de la lista de seleccin.
14. Se selecciona el tipo de nutriente Vitaminas de la lista de seleccin.
15. Se presiona el botn Agregar.
16. El sistema enva un mensaje preguntando si se desea agregar el registro.
17. Se pulsa OK.
18. El sistema regresa a la pantalla anterior y actualiza la lista de nutrientes
registrados, incorporando el nuevo nutriente.
El sistema crea un nuevo nutriente.
3. Editar Nutriente
3.1 Descripcin
mantenimiento de Nutrientes, con el fin de modificar la informacin de un nutriente
registrado.


Ncleo de Monagas.
FECHA: Abril 2009

3.3 Entrada
administrador.
men principal.
9. Se selecciona el nutriente ENERGIA de la lista y se hace clic en el icono
Modificar.
seleccionado.
12. El sistema muestra en pantalla unos campos llenos con informacin del nutriente
seleccionado.
13. Se modifica el campo unidad de medida seleccionando de la lista la opcin Cal.
14. Se pulsa el icono Modificar.
15. El sistema enva un mensaje preguntando si se desea modificar el registro.
16. Se pulsa OK.


Ncleo de Monagas.
FECHA: Abril 2009
17. El sistema regresa a la pantalla anterior y muestra en la lista el nutriente

modificado.
El sistema modifica la informacin del nutriente seleccionado.
4. Eliminar Nutriente
4.1 Descripcin
mantenimiento de Nutrientes, con el fin de eliminar la informacin de un nutriente
especfico.
4.3 Entrada
administrador.
men principal.


Ncleo de Monagas.
FECHA: Abril 2009
9. Se selecciona el nutriente ENERGIA de la lista y se hace clic en el icono
Eliminar.
10. El sistema enva un mensaje preguntando si se desea eliminar el item
seleccionado.
11. Se pulsa OK.
12. El sistema muestra en pantalla unos campos llenos con informacin del nutriente
seleccionado.
13. Se pulsa Eliminar.
14. El sistema enva un mensaje preguntando si se desea eliminar el registro.
15. Se pulsa OK.
16. El sistema regresa a la pantalla anterior y el tipo de men ya no aparece en la
lista.
El sistema elimina el nutriente que fue seleccionado.
5. Buscar Nutriente
5.1 Descripcin
mantenimiento de Nutrientes, con el fin de buscar la informacin de un nutriente
especfico.


Ncleo de Monagas.
FECHA: Abril 2009

5.3 Entrada
administrador.
men principal.
9. Se selecciona el tipo de nutriente MINERALES de la lista de seleccin.
10. El sistema muestra una nueva lista con los nutrientes pertenecientes a ese tipo de
nutriente.
11. Se introduce SODIO en el filtro de bsqueda.
13. El sistema muestra la informacin del nutriente solicitado.
El sistema busca el nutriente consultado.

PROYECTO:

Insumos
Versin 1.0
331

Ncleo de Monagas.
FECHA: Abril 2009
NOMBRE DEL DOCUMENTO: Especificacin de Caso de Prueba: Insumos
1. Descripcin
Este artefacto cubre el conjunto de pruebas realizadas sobre el Caso de Uso
Registrar Insumos. Las pruebas realizadas a este caso de uso son:
- Agregar Insumo.
- Editar Insumo.
- Buscar Insumo.
2. Agregar Insumo
2.1 Descripcin
Se ingresa al sistema como usuario nutricionista para acceder a la seccin de
insumos, con el fin de crear uno nuevo con su informacin respectiva para que quede
guardado en el sistema para su posterior utilizacin.
El usuario debe estar registrado como Nutricionista, para poder acceder al
sistema.
2.3 Entrada
1. Se introduce nutricionista en el campo usuario.
2. Se introduce NUTR en el campo contrasea.
nutricionista.
5. Se posiciona el cursor del Mouse en la opcin Insumos del men principal.
6. El sistema despliega la lista disponible en esta opcin.
7. Se selecciona Cargar Insumos de la lista.


Ncleo de Monagas.
FECHA: Abril 2009
8. El sistema muestra una interfaz con la lista de insumos registrados y las opciones
permitidas (Nuevo, Modificar, Bsqueda por filtro).
10. El sistema muestra en pantalla unos campos para ingresar la descripcin y el tipo
al que pertenece el nuevo insumo.
11. Se ingresa CARNE DE RES en el campo para la descripcin.
12. Se selecciona el tipo de insumo ALIMENTOS de la lista de seleccin.
13. Se presiona el icono Agregar Nuevo Insumo.
14. El sistema muestra un mensaje avisando que insumo ha sido creado.
15. Se pulsa OK.
16. El sistema actualiza la lista de insumos registrados, e incorpora el nuevo insumo.
El sistema crea un nuevo insumo.
3. Editar Insumo
3.1 Descripcin
insumos, con el fin de modificar la informacin de un insumo registrado.
La nica condicin es que el usuario est registrado como nutricionista, para
3.3 Entrada


Ncleo de Monagas.
FECHA: Abril 2009

nutricionista.
9. Se selecciona el insumo CARNE DE RES de la lista y se hace clic en el icono
Modificar.
seleccionado.
12. El sistema muestra en pantalla unos campos vacos para llenar la informacin del
insumo seleccionado.
13. Se selecciona la unidad de medida Kg de la lista de seleccin.
14. Se selecciona los tipos de mens ALMUERZO y CENA en los que el insumo
podr ser utilizado para la creacin de mens alimentarios de esos tipos.
15. Se marca la opcin Propiedades de Alimentos (para darle a los insumos
caractersticas de alimentos, incluyendo su informacin nutricional).
16. El sistema muestra campos adicionales para llenar informacin del insumo
alimenticio.
17. Se ingresa 1 en el campo peso o cantidad.
18. Se selecciona el grupo de alimentos CARNES de la lista de seleccin.
19. Se selecciona el tipo de nutrientes MINERALES de la lista de seleccin.
20. El sistema muestra la lista de nutrientes que pertenecen al tipo seleccionado.


Ncleo de Monagas.
FECHA: Abril 2009
21. Se selecciona el nutriente SODIO para agregarlo a la composicin nutricional

del insumo seleccionado.
22. El sistema enva un mensaje preguntando si se desea insertar el nutriente.
23. Se presiona OK.
24. El sistema incluye el nutriente en la lista de nutrientes del insumo alimenticio
seleccionado.
25. Se ingresa la cantidad 0.1 del nutriente SODIO que est contenido en la
composicin del insumo alimenticio seleccionado.
26. Se pulsa el icono Actualizar.
27. El sistema muestra un mensaje avisando que el insumo ha sido actualizado.
28. Se pulsa OK.
29. El sistema muestra la informacin del insumo actualizada.
El sistema actualiza la informacin del insumo seleccionado.
4. Buscar Insumo
4.1 Descripcin
insumos, con el fin de buscar la informacin de un insumo registrado.
4.3 Entrada


Ncleo de Monagas.
FECHA: Abril 2009

nutricionista.
9. Se selecciona el tipo de insumos OTROS de la lista de seleccin.
10. El sistema muestra una nueva lista con los insumos pertenecientes a ese tipo de
insumos.
11. Se introduce VASOS en el filtro de bsqueda.
13. El sistema muestra la informacin del insumos solicitado.
El sistema busca el insumo consultado.

PROYECTO:
Documento Glosario
Versin 1.0
337

Ncleo de Monagas.
FECHA: Abril 2009
NOMBRE DEL DOCUMENTO: Glosario.
Glosario
1. Organizacin del Glosario
El presente documento est organizado por definiciones de trminos
ordenados de forma ascendente segn la ordenacin alfabtica tradicional del
espaol.
2. Definiciones
A continuacin se presentan todos los trminos manejados a lo largo de todo
el proyecto de desarrollo de sistema para la automatizacin de los procesos de
planificacin y control llevados a cabo en el comedor universitario de la Universidad
de Oriente Ncleo de Monagas, as como sus respectivas definiciones:
2.1 Actor: conjunto de roles que los usuarios desempean con respecto al sistema.
2.2 Almacn: Es el espacio fsico donde se guardan las mercancas de insumos.
2.3 Anlisis de Cotizaciones: es el proceso en el cual se analizan las cotizaciones
recibidas por los diferentes proveedores para elegir el que presente una buena calidad
y economa.
2.4 Automatizacin: Aplicacin de procedimientos automticos en la realizacin de
un proceso. Es la sustitucin de procedimientos manuales por sistemas de cmputo.
2.5 Caso de uso: Es una tcnica para capturar requisitos potenciales de un nuevo
sistema o una actualizacin de software. Cada caso de uso proporciona uno o ms
escenarios que indican cmo debera interactuar el sistema con el usuario o con otro
sistema para conseguir un objetivo especfico.
2.6 Comedor: Habitacin de un establecimiento que dispone de lo necesario para
servir comidas.


Ncleo de Monagas.
FECHA: Abril 2009
2.7 Comensal: Persona que hace uso del servicio de alimentacin ofrecido por el
2.8 Cotizacin: Informacin suministrada por los proveedores acerca del producto o
servicio solicitado por el rea administrativa de comedor.
2.9 Comedor universitario: es un departamento encargado de suministrar una
alimentacin balanceada y variada a la poblacin universitaria, ofreciendo una
excelente preparacin y presentacin de los alimentos, con las mejores condiciones
higinicas y en un ambiente adecuado, de acuerdo al presupuesto establecido y
cumpliendo con las normas y procedimientos.
2.10 Factura: es un documento que refleja la entrega de un producto o la provisin
de un servicio, junto a la fecha de devengo, adems de indicar la cantidad a pagar
como contraprestacin. En la factura se encuentran los datos del expedidor y del
destinatario, el detalle de los productos y servicios suministrados, los precios
unitarios, los precios totales, los descuentos y los impuestos.
2.11 Inventario: Cantidad de cada producto existente en un momento dado, y lista
ordenada en la que se detalla.
2.12 Insumo: Es un bien consumible utilizado en la produccin de los mens
alimentarios.
2.13 Men alimentario: Conjunto de alimentos que conforman los platos de comida
y que se sirven en el comedor universitario.
2.14 Mercanca: Objeto apto para satisfacer necesidades humanas, de cualquier tipo
que ellas sean.
2.15 Modulo: es un componente auto controlado de un sistema, el cual posee una
interfaz bien definida hacia otros componentes. Algo es modular si es construido de
manera tal que se facilite su ensamblaje, acomodamiento flexible y reparacin de sus
componentes.


Ncleo de Monagas.
FECHA: Abril 2009
2.16 Nota de entrega: documento mercantil que acredita la entrega de un pedido. El

receptor de la mercanca debe firmarlo para dar constancia de que la ha recibido
correctamente.
2.17 Orden de compra: es el comprobante que emite el comprador para pedir
mercancas al vendedor, indicando cantidad, detalle, precio, condiciones de pago y
forma de entrega.
2.18 Orden de pago: Documento mediante el cual existe un compromiso de cancelar
una deuda por la compra hecha a un proveedor.
2.19 Pedido: Lista de encargos hecha a un vendedor o proveedor.
2.20 Planificacin Alimentaria: documento que contempla la programacin de una
serie de mens alimentarios con sus respectivos insumos requeridos.
2.21 Postcondicin: Una restriccin que debe ser verdad tras terminar una operacin.
2.22 Precondicin: Una restriccin que debe ser verdad antes de que se solicite una
operacin.
2.23 Proveedor: Persona o empresa que provee o abastece de todo lo necesario para
un fin a grandes grupos, asociaciones, comunidades, etc.
2.24 Proceso: es un conjunto de actividades o eventos que se realizan o suceden con
un determinado fin.
2.25 Resumen de costos: es un reporte que contiene todos los gastos realizados por
el comedor universitario.
2.26 Servicio de Alimentacin: Servicio bsico que presta la universidad a la
comunidad universitaria donde se le suministra a travs de los mens alimentarios o
platos de comida una alimentacin sana y balanceada.
2.27 Sistema: Conjunto de partes o elementos organizados y relacionados que
interactan entre s para lograr un objetivo. Los sistemas reciben (entrada) datos,
energa o materia del ambiente y proveen (salida) informacin, energa o materia.


Ncleo de Monagas.
FECHA: Abril 2009
2.28 Software: Conjunto de programas, documentos, procesamientos y rutinas

asociadas con la operacin de un sistema de computadoras, es decir, la parte
intangible o lgica de una computadora.
2.29 Solicitud de compra: en esta se especifican, de manera detallada, lo insumos
necesarios para la prestacin del servicio de alimentacin.
2.30 Tipo de Men: indica el turno en el que ser servido un men alimentario.
Ejemplo: desayuno, almuerzo, cena, merienda.

5.4 Anlisis Costo Beneficio.
El anlisis costo-beneficio es una tcnica que pretende determinar la

conveniencia de un proyecto mediante la enumeracin y valoracin en trminos
monetarios de todos los costos y beneficios derivados de dicho proyecto. En otras
palabras, esta tcnica proporciona una medida de la rentabilidad del proyecto, a travs
de la comparacin de los costos en que se incurren por la realizacin del proyecto con
los beneficios que se esperan obtener del mismo.
Este anlisis se lleva a cabo para justificar econmicamente el desarrollo de

este proyecto, adems de determinar los beneficios tangibles e intangibles que se
generan.
5.4.1 Costos
A continuacin se detallan los costos que fueron necesarios para llevar a cabo
el desarrollo del proyecto y lograr la construccin del sistema Web para la
planificacin y control del servicio de alimentacin prestado por el comedor
universitario de la Universidad de Oriente Ncleo Monagas.
Costos de Personal
En estos costos se incorporan los salarios devengados por el personal

involucrado en el desarrollo del proyecto. En el caso del desarrollo del sistema para el
comedor universitario, la persona que participa en su realizacin es el autor en
calidad de pasante, por lo que la Universidad de Oriente Ncleo Monagas no incurre
en ningn gasto de este tipo.
342
Costos de Equipos y Herramientas
Son los costos relacionados con la adquisicin de los equipos hardware y

software necesarios para llevar a cabo el desarrollo del sistema. En este caso no fue
necesario realizar este tipo de gasto ya que el Centro de Computacin de la
Universidad de Oriente Ncleo de Monagas contaba con los equipos y herramientas
de trabajo requeridos.
Costos de Adiestramiento
Costos generados por la capacitacin del personal involucrado en el proyecto

a travs de cursos, talleres, adiestramientos, entre otros, con la finalidad de
proporcionar a los participantes los conocimientos necesarios para llevar a cabo el
desarrollo del sistema. Dentro de los talleres y cursos realizados se encuentran la
metodologa RUP, la herramienta UML, Power Designer, Lenguaje PHP y
Macromedia Dreamweaver que fueron dictados por el personal del Centro de
Computacin de la Universidad de Oriente Ncleo de Monagas y por el personal que
labora en el Rectorado, incurrindose solo en costos de viticos. Por otra parte, fue
realizado un curso del lenguaje JavaScript, dictado por el Instituto Gala en la ciudad
de Caracas; el cual gener gastos por adiestramientos que fueron costeados por la
Universidad de Oriente.
Costos de Materiales utilizados
Representan los costos relacionados con la adquisicin de materiales como

resmas de papel necesarias para la documentacin, carpetas, ganchos, cartuchos de
tinta para impresora, tner, libreta de anotaciones, lpices, lapiceros, entre otros. Cabe
mencionar, que estos materiales fueron suministrados en su mayora por el Centro de
Computacin.
343
En el siguiente cuadro se presenta un resumen de los costos del proyecto,
detallando cada uno de ellos con sus respectivos valores en bolvares fuertes.
Cuadro 33. Resumen de Costos

CONCEPTO COSTO (Bs.F)
Costo de Personal
Analista de Sistemas 0 Bs.F
Costos de Equipos y Herramientas
Software 0 Bs.F
Hardware 0 Bs.F
Costos de Adiestramiento
Taller RUP 800 Bs.F
Curso UML 800 Bs.F
Curso PHP 800 Bs.F
Curso de Macromedia Dreamweaver 800 Bs.F
Curso de JavaScript 2.560 Bs.F

Costos de Materiales utilizados
Resma de Papel (6 resmas x 30 Bs.F) 180 Bs.F
CD-ROM (7 unidades x 3 Bs.F) 21 Bs.F
Cartuchos de tinta de impresin (5 x 100 Bs.F) 500 Bs.F
Lapiceros (8 unidades x 1.5 Bs.F) 12 Bs. F
Carpetas (10 unidades x 2 Bs.F) 20 Bs.F
Otros 80 Bs.F
TOTAL COSTOS 6.573 Bs.F
5.4.2 Beneficios
Los beneficios tienen que ver con las ventajas obtenidas con el sistema
desarrollado, destacando que los mismos pueden ser de naturaleza tangible o
intangible.
344
Beneficios Tangibles
Los beneficios tangibles son aquellas ventajas u oportunidades que se pueden

cuantificar, y que se obtienen al hacer uso del sistema informtico desarrollado. Son
fcilmente cuantificables y medibles en unidades monetarias. Entre estos beneficios
se encuentran:
- Disminucin de tiempo en la generacin de la planificacin alimentaria.

Con la utilizacin del sistema automatizado se reduce el tiempo en el que el
personal tarda en generar la lista de los mens que van a ser preparados en la
semana y la hoja de pedido que contiene todos los insumos necesarios para
realizar dichos mens en el turno y da indicados en la planificacin.
Actualmente la delegacin del comedor universitario tarda en elaborar este
documento (que incluye la planificacin de los mens alimentarios y las hojas
de pedidos tanto de la semana como de cada da y turno de esa semana) en un
total de 24 horas hombres (h/h). En cambio, con el sistema propuesto solo se
requieren de 0.75 h/h para elaborar y generar estos informes, logrndose por
lo tanto mayor agilidad en la materializacin de los mismos. A continuacin
se muestra en el siguiente cuadro la diferencia existente entre implementar o
no el sistema que se propone.
Cuadro 34. Disminucin de tiempo en la generacin del plan alimentario.

Tarea Horas Hombres empleadas
Sistema Actual Sistema Propuesto Beneficios
Generar Planificacin
24 h/h 0.75 h/h 23.25 h/h
Alimentaria de la Semana
- Reduccin de tiempo en el anlisis de costos y generacin del resumen

mensual de costos. Actualmente, el personal administrativo del comedor
universitario utiliza aproximadamente 40 h/h para elaborar el reporte mensual
345
de costos de la prestacin del servicio de alimentacin. En cambio, con el uso
del sistema solo se empleara 0.5 h/h para generar este tipo de reporte. Esta
diferencia se puede apreciar claramente en el siguiente cuadro.
Cuadro 35. Reduccin de tiempo en la generacin del Resumen de Costos.

Tarea Horas Hombres empleadas
Sistema Actual Sistema Propuesto Beneficios
Generar Resumen de Costos. 40 h/h 0.5 h/h 39.5 h/h
- Aumento en la velocidad de procesamiento.

- Integracin de la informacin manejada en el rea administrativa con la del
almacn y la de los registros de acceso de comensales, teniendo los datos
centralizados en una base de datos nica.
- Poder recuperar informacin de forma rpida.
Beneficios Intangibles
Los beneficios intangibles son aquellos beneficios asociados a una mejora que
por su naturaleza son muy difciles de cuantificar, pero de los que, indiscutiblemente,
la organizacin se ve beneficiada al llevar a cabo el desarrollo del proyecto. Estos
beneficios son los siguientes:
- Manejo de informacin ms confiable.

- Mejor control de las existencias de insumos en almacn.
- Mayor facilidad en la elaboracin de informes y reportes.
- Aumento en la calidad de servicio del comedor universitario.
- Motivacin del personal al utilizar herramientas modernas que le permitan
eliminar tareas rutinarias o tediosas.
- Mejor imagen de la universidad al implementar nuevas tecnologas.
346
CONCLUSIONES
- Del anlisis realizado al negocio, se pudo diagnosticar que la planificacin

alimentaria, resulta un proceso de gran importancia para lograr la prestacin
del servicio, pues de ella depende cuales insumos necesitan adquirirse para
preparar los mens alimentarios y controlar su existencia en el almacn del
- El estudio del funcionamiento actual del comedor universitario, tambin

permiti determinar la problemtica presentada en dicha seccin. Entre ellas:
la demora en la elaboracin de la planificacin alimentaria e informes de
costos, carencia de un medio que permita estimar el nmero de personas que
acudirn al comedor para el aprovechamiento del servicio y falta de control en
cuanto a entradas, salidas y existencias de insumos en almacn.
- El estudio y descripcin del funcionamiento del comedor universitario,

permiti determinar que el sistema actual presenta fallas, por lo que surgi la
necesidad de desarrollar un sistema capaz de lograr mejoras para dicha
seccin.
- El estudio de la situacin actual empleando el modelado del negocio y las

especificaciones de casos de uso, facilit el establecimiento de los
requerimientos; los cuales posteriormente, permitieron identificar y definir los
verdaderos requisitos para llevar a cabo el desarrollo del nuevo sistema,
centrndose en el usuario y sus necesidades.
- El diseo del sistema empleando el lenguaje UML, permiti obtener una

visualizacin ms detallada de su estructura, ya que dicha herramienta
347
proporciona diferentes diagramas para describir la arquitectura del sistema.
- La metodologa RUP, result ser una gua conveniente para el desarrollo del
sistema, ya que cuenta con una serie de flujos de trabajo que ayudaron a
cumplir con los objetivos establecidos.
- Con el desarrollo del nuevo sistema el personal del comedor universitario

podr realizar de manera rpida y sencilla la planificacin alimentaria,
considerando la informacin nutricional de los mens y la demanda promedio
del servicio; le permitir controlar el acceso de comensales al rea de servicio
y la entrada/salida de insumos del almacn. Tambin, traer consigo ahorro
significativo de tiempo en la generacin de reportes de costos, lo que
garantizar la entrega a tiempo de los mismos a las autoridades universitarias.
- El desarrollo de un sistema software es ms que escribir cdigo, incluye

aspectos como el modelado del negocio y las tareas de anlisis y diseo del
sistema.
348
RECOMENDACIONES
- Incorporar en un futuro la funcionalidad de planificacin va Web por parte

del estudiante, para determinar los das de asistencia y su preferencia en
cuanto a mens alimentarios; y as tomar en cuenta su opinin al momento de
realizar las planificaciones alimentarias.
- Mejorar la seguridad en el acceso de comensales, a travs de la incorporacin

de un sistema o medio de identificacin ms efectivo que permita autenticar al
estudiante que est accediendo a las instalaciones del comedor universitario.
- Implementar el sistema desarrollado en la seccin del comedor universitario,

para que los usuarios puedan desempear sus funciones en un ambiente de
trabajo automatizado y organizado.
- Elaborar un plan de adiestramiento dirigido al personal del comedor que har

uso del sistema, con el fin de aprender a manejarlo y poder sacarle el mximo
provecho a cada una de sus funcionalidades.
- Fortalecer la plataforma tecnolgica del ncleo para que todas las reas
involucradas tengan acceso a la red, dado que el sistema propuesto es una
aplicacin Web.
- Realizar la conexin del sistema del comedor universitario del ncleo de

Monagas con el sub-sistema de control de estudios para realizar la validacin
de los estudiantes que acceden al rea de servicio del comedor.
349
- Vincular el sistema desarrollado con el subsistema de compra para utilizar
informacin requerida de las rdenes de compra en los procesos de registro de
entrada de artculos en almacn.
- Ampliar el espacio fsico del almacn y dotarlo del mobiliario adecuado para
el resguardo de los insumos tanto perecederos como no perecederos; adems
contar con un mayor nivel de seguridad en el rea. Luego de lograr este
mejoramiento en las instalaciones del almacn, se recomienda, aplicar un
modelo de inventario en el comedor universitario, que le sirva de herramienta
til para generar una poltica de inventario ptima, respecto a la cantidad y el
momento en el que deben realizarse los pedidos para reabastecer su almacn
con nuevos lotes de artculos, y lograr as un equilibrio entre no tener un
excesivo inventario y quedarse con cero insumos en almacn que provoquen
la paralizacin del servicio.
350
BIBLIOGRAFA
Alcarria, J. Contabilidad financiera I. Editor Universitat Jaume I. ISBN 8469118099.
Anderson, D. y Sweeney, D. (2004). Principios de Administracin de Operaciones.

Editorial Internacional Thomson, Mxico.
Arias, F. (2006). El Proyecto de Investigacin (3era Edicin). Editorial Episteme.

Caracas. 143 p. ISBN 9800785299.
Aubry, C. y Wittmer, J. (2006). Dreamweaver 8. Ediciones ENI. 384 p.
Barrios, D. (2009). Modelo de sistema viable para el comedor de la Universidad de

Oriente Ncleo Monagas. Universidad de Oriente, ncleo Monagas, Venezuela.
Batini, C. y Navathe, S. (2004). Diseo conceptual de bases de datos. Ediciones Daz

de Santos. 574 p. ISBN 0201601206.
Berzal, F y Cubero, J. (2005). Desarrollo Profesional de Aplicaciones Web con

ASP.NET. Editorial iKor Consulting.
Briceo, G. (2008). Sistema automatizado para la gestin de los procesos

administrativos de la delegacin de planificacin de la Universidad de Oriente Ncleo
Monagas. Universidad de Oriente, ncleo Monagas, Venezuela.
Cobo, A.y Gmez, P. (2005).PHP y MySQL - Tecnologas para el desarrollo de

aplicaciones Web. Ediciones Daz de Santos.
351
DECRETO N 3.090 DE LA PRESIDENCIA DE LA REPBLICA
BOLIVARIANA DE VENEZUELA. Gaceta 38.095 del 28/12/2004, sobre uso del
Software Libre.
Fonseca, R. (2008). Sistema de Gestin en Ambiente Web para Salas Situacionales

en Instituciones Pblicas Adscritas a Entes Gubernamentales. Caso de Estudio:
Centro Internacional Miranda Caracas. Universidad Nacional Experimental del
Tchira, Venezuela.
Forouzan, B. (2003). Introduccin a la ciencia de la Computacin. Cengage Learning

Editores. 406 p. ISBN 9706862854.
Fullana, C. y Paredes J. (2006). Manual de Contabilidad de Costes. Editor Delta

Publicaciones, Madrid. 539 p. ISBN 8496477916.
Gabillaud, J. (2005). Oracle 10g: SQL, PL/SQL, SQL*plus. Ediciones ENI. 496 p.
ISBN 2746028395.
Horngren, C., Sundem, G. y Elliott J. (2000). Introduccin a la Contabilidad

Financiera. Editorial Pearson Educacin, Mxico. 704 p. ISBN 9701703863.
Hurtado, J. (2007). El Proyecto de Investigacin. Metodologa de la Investigacin

Holstica. Caracas: Quirn.
Hurtado, J. (2000). El proyecto de investigacin. Editorial Sypal, Caracas, Venezuela.
JACOBSON, Ivar , BOOCH, Grady y RUMBAUGH, James. El Proceso Unificado

de Desarrollo de Software. Madrid: Pearson Educacin S.A., 2000. 464 p. ISBN: 84-
7829-036-2
352
JACOBSON, I., BOOCH, G. y RUMBAUGH, J. El Lenguaje Unificado de
Modelado. Manual de Referencia. Madrid: Pearson Educacin S.A., 2000. 552 p.
ISBN: 84-7829-037-0.
JACOBSON, I. (2000) El Proceso Unificado de Desarrollo de Software. Editorial

Pearson Educacin, S.A., Madrid.
Krajewski, L. y Ritzman, Larry. (2000). Administracin de Operaciones. Editorial

Pearson Educacin, Mxico.
Laporta, J. y Miralles M. (2005). Fundamentos de Telemtica. Ed. Univ. Politc.

Valencia. 408 p. ISBN 8497059131.
Lpez, C. y Alonso J. (2007). La Tercera Revolucin. Editorial Netbiblo, Madrid.

165 p. ISBN 8497452143.
Martnez, J. y Lara, P. (2007). La Produccin de Contenidos Web. Editorial: UOC.

75 p. ISBN 8497886739
Mata (1976). Manual de Procedimiento y Organizacin. Servicio de Comedores.

Universidad de Oriente, Venezuela.
Montilva, J. (1992). Desarrollo de sistemas de informacin. Mrida, Venezuela:

Universidad de Los Andes.
Mora, E. y Zorrilla, M. (2003). Iniciacin a las Bases de Datos con Access 2002.
Ediciones Daz de Santos. 272 p. ISBN 8479785926.
Moreno, M. (1993). Introduccin a la Metodologa de la Investigacin Educativa.

Editorial Progreso. ISBN 9684368682.
353
Rodriguez, N. y Martinez, W. Planificacin y Evaluacin de Proyectos Informticos.
Editor EUNED.
Rojas, J. (2005). Sistema de Informacin Web para la Gestin y Control de

Contratos e Inventario de la Direccin de Ingeniera y Mantenimiento de la
Universidad de Los Andes. Universidad de Los Andes, Venezuela.
Rueda, J. (2006). Aplicacin de la metodologa RUP para el desarrollo rpido de

aplicaciones basado en el estndar j2ee. Universidad de San Carlos, Guatemala.
Render, B. y Heizer, J. (2004). Principios de Administracin de Operaciones.

Editorial Pearson Educacin, Mxico.
Rob, P. y Coronel, C. (2004). Sistemas de bases de datos: Diseo, implementacin y

administracin. Cengage Learning Editores. 838 p. ISBN 9706862862.
Tamayo y Tamayo, M. (2003). El Proceso de la Investigacin Cientfica. Editorial

Limusa, Mxico.
Taha, H. (2004). Investigacin de Operaciones. Editorial Prentice Hall, Mxico.
Warren, C., Reeve, J. y Fess P. (2005). Contabilidad Financiera. International

Thomson Editores, Mxico, D.F.
ALARCON, R. Diseo Orientado a objetos con UML. [Documento en Lnea].

Disponible: http://monjes.org/tutoriales-y-manuales/3069-diseno-orientado-objetos-
con-uml-raul-alarcon-grupo-eidos.html [Consulta: 2009, Abril 20].
354
Departamento de Sistemas Informticos y Computacin. Universidad Politcnica de
Valencia. Rational Unified Process (RUP). . [Documento en lnea]. Disponible:
http://www.pid.dsic.upv.es [Consulta: 2009, Marzo 07]
Eguluz, J. Introduccin a AJAX. [Documento en Lnea]. Disponible:

http://www.librosweb.es/ajax/index.html [Consulta: 2009, Mayo 07].
Quirn (2005). Introduccin a UML 2.0. [Documento en Lnea]. Disponible:

http://www.epidataconsulting.com/tikiwiki/tiki-
read_article.php?articleId=15#_Introducci_n [Consulta: 2009, Abril 20].
Sybase PowerDesigner. MTBase Sybase de Colombia. ]. Disponible:

http://www.mtbase.com/contenido/documento?id=4,00009 [Consulta: 2009, Mayo
07].
Tarjetas CRC. [Pgina en Lnea]. Disponible:

http://jms32.eresmas.net/tacticos/UML/UML04/UML0402.html [Consulta: 2009,
Abril 23]
UDO. [Pagina Web en Lnea]. Disponible: http://www.udo.edu.ve/ [Consulta: 2008,

Diciembre 04].
Universidad De Oriente Ncleo Monagas. (s.f.). Instructivo del Informe

Preliminar [Documento en lnea]. Disponible en:
http://150.186.84.19/monagas/mod/resource/ view.php?id=1462. [Consulta: 2008,
Junio 05].
Universidad De Oriente Ncleo Monagas. (s.f.). reas Temticas de

Investigacin [Documento en lnea]. Disponible en:
355
http://150.186.84.19/monagas/mod/resource/ view.php?id=2678. [Consulta: 2008,
Junio 05].
Wikipedia La Enciclopedia Libre. Universidad de Oriente. [Documento en lnea].

Disponible: http://es.wikipedia.org/wiki/Universidad_de_Oriente [Consulta: 2008,
Noviembre 16]
Wikipedia, La Enciclopedia Libre. Aplicacin WEB. [Documento en Lnea].

Disponible: http://es.wikipedia.org/wiki/Aplicaci%C3%B3n_web [Consulta: 2008,
Julio 04].
Wikipedia, La Enciclopedia Libre. PHP. [Documento en Lnea]. Disponible:

http://es.wikipedia.org/wiki/PHP [Consulta: 2009, Mayo 07].
Wikipedia, La Enciclopedia Libre. AJAX. [Documento en Lnea]. Disponible:

http://es.wikipedia.org/wiki/AJAX [Consulta: 2009, Mayo 07].
Wikipedia, La Enciclopedia Libre. XAMPP. [Documento en Lnea]. Disponible:

http://es.wikipedia.org/wiki/XAMPP [Consulta: 2008, Julio 04].
356
ANEXOS
357
FORMAS DE REGISTROS INDICADAS EN EL MANUAL DEL COMEDOR
UNIVERSITARIO.
Anexo 1. Forma Men y Alimentos Requeridos.
358
Anexo 2. Forma Mercancas Despachadas Por Despensa.
359
Anexo 3. Forma Comprobante de Entrega de Materiales.
360
Anexo 4. Forma Control de Existencias.
361
Anexo 5. Forma Control Diario de Costo.
362
Anexo 6. Forma Resumen Mensual de Costo.
363
Anexo 7. Forma Diario de Almacn.
364
W : A d m i n U su a ri o s W : U su a ri o U su a ri o T i p o U su a ri o
U su a ri o A d m i n i st ra d o r
1 . S e l e c c i o n a A d m i n i st ra r U su a ri o s
2 . a b re V e n t a n a ()
3 . B u sc a U su a ri o s
4 . b u sc a rU su a ri o s()
5 . M u e st ra l i st a d e u su a ri o s
CREAR NUEVO 6 . P re si o n a b o t o n " N u e v o "

U S U A R IO
8 .C a m b i a v e n ta n a
9 . C a rg a F o rm u l a ri o
1 0 . c a rg a rT i p o U su a ri o ()
1 1 . B u sc a T i p o s d e U su a ri o s
1 2 . b u sc a rT i p o U su a ri o ()
1 3 . c a rg a rF o rm u l a ri o ()
1 4 . M u e st ra F o rm u l a ri o
1 5 . L l e n a d a t o s d e u su a ri o a c re a r
1 6 . P re si o n a b o t o n " A g re g a r"
1 7 . P ro c e sa
S i R e sp = f a l se 1 8 . R e sp = v a l i d a r()
1 9 . D a t o s i n v a l i d o s o y a e x i st e e l n o m b re d e u su a ri o
2 0 . i n se rt a r()
S i R e sp = t ru e
2 1 . U su a ri o C re a d o E x i t o sa m e n t e
2 2 . a b re V e n t a n a ()
2 3 . M u e st ra P a n t a l l a A n t e ri o r
2 4 . P re si o n a b o t o n " R e t o rn a r"
RE T O RNA R
2 5 . a b re V e n t a n a ()
2 6 . M u e st ra P a n t a l l a A n t e ri o r
B US CA R 2 7 . L l e n a c a m p o d e b sq u e d a
U S U A R IO
2 8 . P re si o n a b o t o n " F i l t ra r"
2 9 . B u sc a u su a ri o s d e a c u e rd o a c a d e n a d e c a ra c t e re s t e c l e a d o s
3 0 . b u sc a rU su a ri o s()
3 1 . M u e st ra l i st a d e u su a ri o s d e a c u e rd o a l a c a d e n a t e c l e a d a
E D IT A R 3 2 . S e l e c c i o n a u su a ri o d e l a l i st a
U S U A R IO
3 3 . P re si o n a b o t o n " M o d i f i c a r"
3 4 . a b re V e n t a n a ()
3 5 .C a m b i a V e n ta n a
3 6 . C a rg a F o rm u l a ri o c o n d a t o s d e u su a ri o
3 7 . b u sc a rU su a ri o (C o d U su a ri o )
3 8 . c a rg a rT i p o U su a ri o ()
3 9 . B u sc a T i p o s d e U su a ri o
4 0 . b u sc a rT i p o U su a ri o ()
4 2 . M u e st ra f o rm u l a ri o c o n d a t o s d e u su a ri o
4 3 . E d i t a D a t o s d e l u su a ri o
4 5 . P ro c e sa
4 6 . a c t u a l i z a r()
4 7 . U su a ri o A c t u a l i z a d o E x i t o sa m e n t e
4 8 . a b re V e n t a n a ()
4 9 . M u e st ra P a n t a l l a a n t e ri o r
E L IM IN A R 5 0 . S e l e c c i o n a U su a ri o d e l a l i st a
U S U A R IO
5 1 . P re si o n a b o t o n " E l i m i n a r"
5 2 . P ro c e sa
5 3 . e l i m i n a r()
5 4 . U su a ri o E l i m i n a d o E x i t o sa m e n t e
5 5 . P re si o n a b o t o n " S a l i r"
S A L IR
5 6 . a b re V e n t a n a ()
5 7 . M u e st ra P a n t a l l a d e l M e n u P ri n c i p a l
365
W : R e g i st ro I n su m o s W : E d i c i o n In su m o In su m o T i p o I n su m o U M T ip o M e n u G ru p o A l i m e n t o T i p o N u t ri e n t e N u t ri e n t e T i p o M e n u I n su m o A lim e n to N u trie n te A lim e n to
U su a ri o
1 . S e l e c i o n a " C a rg a r I n su m o "
3 . B u s c a I n su m o s
4 . c a r g a rT i p o I n su m o ()
5 . B u sc a ti p o s
6 . b u s c a rT i p o I n su m o ()
7 . b u s c a rI n su m o s ()
8 . M u e st r a t i p o s y l i st a d e i n s u m o s e n c o n t ra d o s
CR E A R
N U E V O 9 . P re si o n a b o t o n " N u e v o "
IN S U M O
1 0 . a b re V e n t a n a D e A g r e g a rI n su m o ( )
1 1 .L l e n a d a to s d e In su m o
1 2 . P re si o n a I c o n o " A g r e g a r N u e v o I n s u m o "
1 3 . P ro c e sa
S i R e s p = f a l se 1 4 . R e sp = v a l i d a r()
1 5 . L o s d a t o s i n g re sa d o s so n i n v a l i d o s
S i R e sp = t ru e 1 6 . i n se r t a r ()
1 7 . I n su m o C re a d o
1 8 . S e l e c c i o n a T i p o d e I n su m o
B U S C A R
1 9 . B u sc a i n su m o s
IN S U M O
2 0 . b u sc a rI n su m o s ()
2 1 . M u e st ra l i s t a d e i n su m o s d e a c u e rd o a l t i p o s e l e c c i o n a d o
2 2 . L l e n a c a m p o d e b sq u e d a
2 3 . P re si o n a b o t o n " F i l t r a r" 2 4 . B u sc a i n su m o s d e a c u e rd o c a d e n a d e c a ra c t e r e s t e c l e a d o s
2 5 . b u sc a rI n su m o s ()
2 6 . F i l t ra L i st a d e I n s u m o s d e a c u e r d o a l a c a d e n a t e c l e a d a
M O D IF IC A R 2 7 .S e le c c io n a I n s u m o d e l a l i st a
IN S U M O
2 9 . a b re V e n t a n a ()
3 0 . C a m b ia V e n ta n a
3 1 . C a r g a f o rm u l a ri o c o n d a t o s d e i n su m o
3 2 . b u s c a r I n s u m o (C o d I n su m o )
3 3 . c a rg a r U M ( )
3 4 .b u sc a u n i d a d e s d e m e d i d a
3 5 . b u sc a rU M ( )
3 6 . c a r g a rT i p o I n su m o ()
3 7 .B u sc a ti p o s
3 8 . b u sc a rT i p o I n s u m o ( )
3 9 . c a rg a r T i p o M e n u ()
4 0 . B u sc a t i p o s d e M e n u
4 1 . b u sc a rT i p o M e n u ()
4 2 . c a rg a r G ru p o A l i m e n t o ()
4 3 . B u sc a G ru p o s d e a l i m e n t o s
4 4 . b u sc a rG ru p o A l i m e n t o ( )
4 5 . c a r g a rT i p o N u t ri e n t e ()
4 6 . B u sc a T i p o s d e N u tri e n te s
4 7 . b u sc a rT i p o N u t ri e n t e ( )
4 8 . c a r g a rN u t ri e n t e ()
4 9 . B u sc a N u t ri e n t e s d e a c u e rd o a l t i p o d e n u t ri e n t e se l e c c i o n a d o
5 0 . b u sc a r N u t r i e n t e (C o d T i p o N u t r i e n t e )
5 1 . C a rg a rF o rm u l a r i o ( )
5 2 . M u e st ra f o r m u l a ri o c o n d a t o s d e i n su m o
5 3 . E d i t a d a t o s d e l I n su m o
A g re g a r I n su m o 5 4 . M a rc a e l t i p o d e m e n u d o n d e se u t i l i z a r e l i n su m o
e n T ip o M e n u 5 5 . P r o c e sa
5 6 . i n s e rt a r(C o d I n su m o , C o d T i p o M e n u )
Q u i ta r I n su m o 5 7 . D e sm a rc a e l t i p o d e m e n u d o n d e se u t i l i z a r e l i n su m o
e n T ip o M e n u 5 8 . P r o c e sa
5 9 . e l i m i n a r(C o d I n su m o , C o d T i p o M e n u )
A c ti v a r 6 0 . M a rc a C a si l l a " P ro p i e d a d e s d e A l i m e n t o "
P ro p i e d a d e s d e 6 1 . P ro c e sa
A lim e n to
6 3 . M u e st ra f o rm u l a r i o p a ra e d i c i o n d e p ro p i e d a d e s d e a l i m e n t o 6 2 . i n se rt a r( )
D e sa c ti v a r 6 4 . D e sm a rc a C a si l l a " P ro p i e d a d e s d e A l i m e n t o "
P ro p ie d a d e s d e 6 5 . P ro c e sa
A l im e n to
6 7 . O c u l t a f o rm u l a ri o p a r a e d i c i o n d e p ro p i e d a d e s d e a l i m e n t o 6 6 . e l i m i n a r ()
A g re g a r 6 8 . S e l e c c i o n a t i p o d e n u t ri e n t e
N u t ri e n t e s d e l 6 9 . P r o c e sa
In su m o
7 0 . c a rg a rN u t ri e n t e ()
7 1 . B u sc a N u t ri e n t e s d e a c u e rd o a l t i p o d e n u t ri e n t e se l e c c i o n a d o
7 2 . b u sc a r N u t r i e n t e (C o d T i p o N u t r i e n t e )
7 3 . M u e s t ra N u t ri e n t e s d e a c u e rd o a l t i p o se l e c c i o n a d o
7 4 . S e le c c io n a u n n u trie n te
7 5 . P ro c e sa
7 6 . i n se rt a rN u t ri e n t e ( C o d I n su m o , C o d N u t r i e n t e )
E d i t a r N u t ri e n t e 7 7 . E d i t a c a n t i d a d d e l n u t ri e n t e
d e l In su m o 7 8 . P ro c e sa
7 9 . m o d i f i c a rN u t ri e n t e ()
E lim in a r 8 0 . P re s i o n a I c o n o " E l i m i n a r" d e l n u t ri e n t e d e l i n su m o a b o rra r

N u t ri e n t e d e l 8 1 . P ro c e sa
In su m o
8 2 . e l i m i n a rN u t ri e n t e ( )
8 3 . P re si o n a b o t o n " A c t u a l i z a r"
8 4 . P r o c e sa
8 5 . a c t u a l i z a r()
8 6 . A c t u a l i z a P ro p i e d a d e s d e a l i m e n t o
8 8 .In su m o A c t u a l i z a d o 8 7 . a c t u a l i z a r()
R E T O R N A R
9 0 . a b re V e n t a n a ()
9 1 . M u e st ra p a n t a l l a a n t e ri o r
E L IM IN A R 9 2 . P re si o n a b o to n " E l i m i n a r"
9 3 . P r o c e sa
IN S U M O
S i R e sp = fa l se 9 4 . R e sp = c o m p ro b a r()
9 5 . N o p u e d e e l i m i n a rse e st a si e n d o u t i l i z a d o
S i R e sp = t ru e
9 6 . e l i m i n a r()
9 7 .I n su m o E l i m i n a d o
9 9 . M u e st r a p a n t a l l a a n t e ri o r 9 8 . a b re V e n t a n a ()
1 0 0 . P r e si o n a b o t o n " S a l i r"
S A L IR
1 0 1 . a b re V e n t a n a ()
1 0 2 . M u e st ra p a n t a l l a d e l M e n u P r i n c i p a l
366
W :C o n fo rm a c i o n M e n u W :E d i c i o n M e n u W :B u sc a d o rI n su m o M enu T ipo M e n u T i p o N u tri e n t e I n su m o R e q u e ri d o M e n u G ru p o A l i m e n to In su m o Al im e nto N u tri e n te A l i m e n to
U su a ri o
1 .S e l e c c i o n a " C o n f o rm a r M e n u "
2 .a b re V e n ta n a ()
3 . B u sc a M e n u s A l i m e n t a ri o s
4 . c a rg a rT i p o M e n u ()
5 . B u sc a t i p o d e m e n u
6 .b u sc a rT i p o M e n u ()
8 .M u e st ra ti p o y l i sta d e m e n u s e n c o n tra d o s 7 .b u sc a rM e n u s()
CR E A R N U E V O 9 .P re si o n b o to n " N u e v o "
M ENU
A L I M E N T A R IO 1 0 . a b re V e n t a n a D e A g re g a rM e n u ()
1 1 .L l e n a d a to s d e M e n u
1 2 .P re si o n a I c o n o " A g re g a r N u e v o M e n u "
1 3 .P ro c e sa
S i R e sp = fa l se 1 4 . R e sp = v a l i d a r()
1 5 . L o s d a to s i n tro d u c i d o s so n i n v a l i d o s
S i R e sp = tru e
1 6 .i n se rta r()
1 7 .M e n u C re a d o
B U S C A R M E NU 1 8 . S e l e c ci o n a T i p o d e M e n u
1 9 . B u sc a M e n u s
A L I M E N T A R IO
2 0 .b u sc a rM e n u s()
2 1 .M u e stra l i sta d e M e n u s d e a c u e rd o a l ti p o se l e c c i o n a d o
2 2 .L l e n a c a m p o d e b u sq u e d a
2 3 .P re si o n a b o to n " F i l tra r"

2 4 .B u sc a M e n u s d e a c u e rd o a c a ra c t e re s t e c l e a d o s
2 5 .b u sc a rM e n u s()
2 6 .F i l tra L i sta d e M e n u s d e a c u e rd o a c a d e n a te c l e a d a
2 7 .S e l e c c i o n a M e n u d e l a l i st a
M O D IF IC A R M E N U
A L IM E N T A R I O 2 8 .P re si o n a b o to n " M o d i f i c a r"
2 9 .a b re V e n ta n a ()
3 0 .C a m b i a v e n ta n a
3 1 .C a rg a F o rm u l a ri o c o n d a to s d e M e n u
3 2 .b u sc a rM e n u (C o d M e n u )
3 3 . c a rg a rT i p o M e n u ()
3 4 . B u sc a T i p o s d e M e n u
3 5 .b u sc a rT i p o M e n u ()
3 6 .c a rg a rT i p o N u tri e n te ()
3 7 .B u sc a T i p o s d e n u tri e n te
3 8 . b u sc a rT i p o N u t ri e n te ()
3 9 .c a rg a rIn su m o R e q u e ri d o M e n u ()
4 0 .B u sc a In su m o s re q u e ri d o s d e l M e n u a l i m e n ta ri o
4 1 .b u sc a rIn su m o R e q u e ri d o M e n u ()
4 3 .M u e stra fo rm u l a ri o c o n i n fo rm a c i n d e l m e n u
4 4 . E d i t a D a t o s d e l M e n A l i m e n ta ri o
4 5 .P re si o n a I c o n o " B u sc a r"
In c l u i r In su m o a l
M en 4 6 .a b re V e n ta n a ()
4 7 . C a m b i a V e n ta n a 4 8 .C a rg a i n fo rm a c i n
4 9 . c a rg a rT i p o M e n u ()
5 0 .B u sc a T i p o s d e M e n u
5 1 .b u sc a rT i p o M e n u ()
5 2 .c a rg a rG ru p o A l i m e n to ()
5 3 .B u sc a G ru p o s d e A l i m e n to s
5 4 .b u sc a rG ru p o A l i m e n t o ()
5 5 . b u sc a rIn su m o s()
5 6 . M u e stra l i sta d e In su m o s
5 7 .S e l e c c i o n a T i p o d e In su m o
5 8 .B u sc a In su m o s
5 9 . b u sc a rIn su m o s()
6 0 .M u st ra l i st a d e i n su m o s d e a c u e rd o a l ti p o se l e c c i o n a d o
6 1 .L l e n a C a m p o d e B sq u e d a
6 2 . P re si o n a b o t o n F i l tra r
6 3 . B u sc a I n su m o s d e a c u e rd o a c a ra c te re s te c l e a d o s
6 4 .b u sc a rIn su m o s()
6 5 .F i l t ra l i st a d e i n su m o s d e a c u e rd o a c a d e n a t e c l e a d a
6 6 .S e l e c c i o n a G ru p o d e A l i m e n to
6 7 .B u sc a In su m o s
6 8 .b u sc a rIn su m o s()
6 9 .M u e st ra l i st a d e i n su m o s d e a c u e rd o a l g ru p o d e a l i m e n to s se l e c c i o n a d o
7 0 . S e l e c c i o n a In su m o d e l a l i sta
7 1 .P ro c e sa
7 2 .c a rg a rI n su m o ()
7 3 .M u e stra i n fo rm a c i n d e i n su m o e n fo rm u l a ri o
7 4 . A j u sta c a n t i d a d d e I n su m o
7 5 .P re si o n a Ic o n o " I n c l u i r"
7 6 . P ro c e sa
7 7 . i n se rt a r()
7 8 .In su m o R e q u e ri d o A g re g a d o
E d i ta r I n su m o 7 9 . E d i t a C a n ti d a d d e l I n su m o R e q u e ri d o
R e q u e ri d o 8 0 . P ro c e sa
8 1 .a c t u a l i z a r()
Q u i t a r In su m o 8 2 . P re si o n a Ic o n o " E l i m i n a r" d e l i n su m o re q u e ri d o a b o rra r

8 3 . P ro c e sa
R e q u e ri d o
8 4 . e l i m i n a r()
8 5 . S e l e c c i o n a T i p o d e n u t ri e n te
V e r C o m p o si c i o n
N u tri c i o n a l d e l M e n u
8 6 .S e l e c c i o n a In su m o A l i m e n ti c i o R e q u e ri d o
8 7 .P ro c e sa
8 8 . c a rg a rIn su m o R e q u e ri d o M e n u ()
8 9 . B u sc a I n su m o s R e q u e ri d o s d e l m e n u a l i m e n t a ri o
9 0 .b u sc a rIn su m o R e q u e ri d o M e n u ()
9 1 . c a rg a rA l i m e n to ()
9 2 . B u sc a p ro p i e d a d e s d e a l i m e n to s
9 3 .b u sc a rA l i m e n t o s()
9 4 .c a rg a rN u t ri e n te A l i m e n to ()
9 5 . B u sc a N u tri e n t e s d e l o s a l i m e n to s
9 6 .b u sc a rN u t ri e n te A l i m e n to ()
9 8 . M u e stra V a l o re s N u t ri c i o n a l e s d e l m e n u y a l i m e n to se l e c c i o n a d o 9 7 .c a l c u l a rN u tri e n t e M e n u ()
9 9 .P re si o n a b o to n " A c tu a l i z a r"
1 0 0 . P ro c e sa
1 0 1 .a c t u a l i z a r()
1 0 2 . M e n u A c tu a l i z a d o
1 0 3 .P re si o n a b o to n " R e to rn a r"
RETO RNAR
1 0 4 . a b re V e n t a n a ()
1 0 5 .M u e stra P a n ta l l a a n t e ri o r
1 0 6 .P re si o n a b o to n " E l i m i n a r"
E L I M IN A R M E N U 1 0 7 . P ro c e sa
A L IM E N T A R IO
1 0 8 .R e sp = c o m p ro b a r()
S i R e sp = fa l se
1 0 9 .N o p u e d e e l i m i n a r e l m e n u e sta si e n d o u ti l i z a d o
S i R e sp = tru e
1 1 0 .e l i m i n a r(C o d M e n u )
1 1 1 .E l i m i n a i n su m o s re q u e ri d o s d e l m e n a l i m e n ta ri o
1 1 2 .e l i m i n a r()
1 13 .M en u E li m in ad o
1 1 5 .M u e st ra p a n t a l l a a n t e ri o r 1 1 4 . a b re V e n t a n a ()
1 1 6 .P re si o n a b o to n " S a l i r"
S A LIR
1 1 7 .a b re V e n ta n a ()
1 1 8 .M u e st ra p a n ta l l a d e l m e n u P ri n c i p a l
367
W:Vi staPlani fi caci ones W:EdicionPl ani fi caci on W:BuscadorMenu W.EstimarComensa les W:Buscad orInsumo W:BuscadorMenu Pl ani fi cado Plani fi caci on Semana Ti poMenu Menu Acce soComensal es Insumo TipoInsumo InsumoRequeridoPl ani fi caci on Insu moRequerid oMenu Existenci aArti culo
Usuari o Impre sora
1.Sel ecci ona Plani fi car Servi cio
2.abreVen tana()
3.Bu scas Pl anificacio nes Creadas por Semana
4.cargarSemana()
5.Busca Semanas Pl anificadas
6.buscarSemanas()
7.busca rPl anificacione s()

8.Muestra Semanas y Plani fi caci ones de acuerdo a la ul ti ma semana plan ificad a
CREAR NUEVA 9.Presiona boton "Nuevo"

PLANIFICACION
SEMANAL 10.a breVentana()
11.Cambia Venta na
12.Carga formul ari o
13 .cargarSemana()
14.Busca Semanas no pl ani fi cadas
15.buscarSemanas()
16 .cargarTipoMenu()
17.busca tipos de menu
18.buscarTipoMenu()
19.Mu estra formul ario
Plan ificar p ara 20.Marca casi ll a "Evento Especia l"

eve ntos especia les 21.Muestra camp o para crear evento esp ecial
22.Escribe nombre del evento
23.Presion boton "Ok"

25.Pro cesa 26.Crea semana para evento especi al
28.Evento Cread o 27.cre arSemana()
Plani fi car para u na 28.Seleccio na una semana

semana normal de 29.Pro cesa
servi ci o
30.crearFechasSemana()
31.Muestra fecha s d e l a semana
Agre gar una Pl ani fi caci on 32.Seleccion a o escrib e fecha

de Menu a l a Pl anificacin
Se manal 33.Mue stra dia
34.Sel ecciona Tipo de menu
35.Pre sio na i cono "Buscar Me nu"
Incl ui r Men a la
Pl anifi caci n Al imentari a 36.abre Ve ntana()
37 .Cambia Ventana
3 8.Busca menus de acuerdo a l ti po de menu seleccio nado en l a ven tana anteri or
39.buscarMenus()
40 .Muestra li sta de Menus
41.Llena campo de busqueda
42 .Presi ona boton "Fi ltrar"

43.Busca menus de acuerdo a caracte res tecle ados
44.buscarMe nus()
45.Fil tra l ista de menus de acuerdo a cadena tecl eada
46 .Sel ecci ona Menu de l a li sta

47.Procesa
49.Mu estra informaci n de menu en formul ari o 4 8.cargarMenu()
Esti ma r 50.Presiona i cono "Estimar Numero de Co mensales"

comensal es
51.abreVen tana()
52.Camb ia Ventana
53.Carga plani ficaciones anteriores e hi stori al de comensales de acuerdo al dia y turno
54.buscarPl ani fi caci ones()
55.cargarComensales()
56.Busca histori al de comensales de acue rdo a di a y turn o
5 7.buscarCo mensales()
58.Muestra l os menus servid os y co mensales atentidos en las fechas anteriores de acuerdo al di a y turno que se esta pl ani fi cando
59.Presiona boton "Esti mar"

60.Procesa
61 .esti marCome nsal es()

62.Muestra Esti mad o de Comen sal es
63.Presi on b oton "Acep tar"

64.Procesa
65.cargarEsti mado Co mensales()

66.Muestra cantidad estimada de comen sal es en formul ari o
6 7.Presi ona boton "Agregar"

68.Pro cesa
69.Resp=val idar()
Si Resp =fal se 71.Los datos i ngresados son i nval idos
Si Resp =true
72.i nsertar()
73.Pl anificaci n Al imenta ri a Agregada
73.Sel ecci ona una Pl anifi caci on Al imentari a

Incl uir Insumo a l a
Pl anificaci n 75.Presi ona icon o "Incl uir otros insumos a Plan ificacion"
76.abre Ve ntana()
77.Cambia Ventan a
78.Ca rga Informaci n
79.cargarTipoInsumo()
80.Busca Tipos de Insumo
81.buscarTipoInsumo()
82.buscarInsumos()
83.Muestra l ista de insumos sin prop iedades al imenticias de acuerdo al ti po que este sel ecci onado
84.Seleccio na Ti po de Insumo
85 .Busca Insumos
86.busca rInsumos()
87.Muestra l ista de insumos de acuerdo al ti po sel ecci onado
88.Llena campo d e busqueda
8 9.Presi ona boton "Fi ltrar"

90.Busca Insumos de acuerdo a caracte res tecle ados
92.Fi ltra li sta d e i nsumos de a cuerd o a cadena tecleada 91.busca rInsumos()
93.Sel ecciona Insumo de la li sta

94.Procesa
95.i nsertar()
Editar Insumo 96.Ed ita Cantidad del Insumo Requeri do

97.Procesa
Re queri do
98.a ctual i zar()
99.Pre sio na Icono "El iminar" del i nsumo requerido a borrar

Qui tar Insumo 100.Pro cesa
Requeri do
101.el i mi nar()
Qui tar una Pl ani fi caci on de 102.Presion a Icono "Eli minar" de l a plani fi caci on a borrar
Menu de la Plan ificacin 103.Procesa
Semanal
104 .el imina r()
104.Eli mi na i nsu mos requeridos de la pl anificacion
105.el i mi nar()
106.Presiona boton "Guardar"
Guardar Pla nifica cion 107.Procesa
108.Acti va Semana
Ali mentaria Semanal
110.Plani fi caci n Semanal Guardada 109.actua li zarSemana()
111.abreVentana()
112.Muestra Pan tal la Anteri or
113.Pre sio na boton "Retornar"

RETORNAR
114.abreVentana()
1 15.Muestra Pantall a Anterior
BUSCAR PLANIFICACION
AL IMENTARIA POR 1 16.Sel ecci ona una seman a
SEMANA 1 17.Busca Pl ani fi caci ones de Menu de acuerdo a la semana sel ecci onada
118.buscarPlan ificaciones()
119.Muestra Plani ficaciones de acuerdo a l a sema na selecciona
MODIFICAR
PLANIFICACION 120.Marca casi ll a "Seleccion ar Plani fi caci on Ali mentaria Semana l"
ALIMENTARIA SEMANAL 12 1.Presi ona bo ton "Modificar"
122.abreVentana ()
123.Cambi a Ventana
124.Carga formul ari o con i nformacion de las pl ani fi caci ones que estan den tro de la pl anificacio n semanal sele cci onada
125.carg arSemana()
126.Busca Seman a Pl anificada
127.bu scarSeman a(CodSemana)
128.cargarTi poMenu()
129.Busca ti pos de menu
130 .buscarTi poMenu()
1 31.buscarPlani fi caci ones()

13 2.Muestra formulario con datos de l as pl anifica cione s a li mentarias que estan d entro de l a pl anifi caci on seman al sel ecci onada
133.Edita datos de las pl ani fi caci ones ali mentarias de l a semana sel eccionada
134.Selecciona una Plani fi cacion Ali men taria

Cambi ar Menu Pl anificado
d e acu erdo a di spo nibi li dad 135.Presi ona Icon o "Bu scar Men de Pl anifi caci ones Anteriores"
e n al macen
136.abreVentana()
137.Cambia Ventan a
138.Busca Informa cin de plani ficaciones anteriores de acuerdo al turno de la pla nificacion sel ecci onada
139.buscarPl anifi caci ones()
140.cargarInsumoRequerido Pl ani fi caci on()
1 41.Busca Insumos Requerido s Para Prestar el Servi cio
142.buscarInsumoRequerid oPl ani fi caci on()
143.carg arMenu()
144.carg arInsumosReque ri doMenu ()
145.Busca Informaci on de menu de cada una de las pl anificacio nes encontradas

146.buscarMenu(codMen u)
14 7.Busca i nsumos requeri dos del menu

148.buscarInsumoRequeridoMenu()
149.cargarExistenci aArticulo()
150.Busca Existencia de Arti cul os en Al macen
151.buscarExi stencia Articul os()
152.comproba rExi stenci aInsumosRequeridos()

153.Muestra Pl anifi caci ones donde los menus ali mentario s p ueden preparse con los i nsumos exi stentes en al macen
154.Se lecciona el Menu Al imentari o d e una Plani ficacion Anterio r Disp onibl e
155.Procesa
157.Muestra Pl ani fi caci on Al imentari a con e l Menu y Estimado d e Comensal es Actuali zados 156.actuali zar()
159.Marca casi ll a "Seleccion ar Plani fi caci on Ali mentaria Semana l"

ELIMINAR PLANIFICACION
ALIMENTARIA SEMANAL 160.Presiona boton "Eli mi nar"
161.Procesa
162.el imi narPl anificaci on(CodPl anificaci on)
163.El imin a i nsumos req ueri dos de p lani fi caci on ali mentaria
164.el i mi nar()
Si tipo_ semana!=evento esp ecial
1 65.Desacti va semana
166.actuali zarSemana()
Si ti po_semana=evento especial
167.Eli mina Semana
168.el iminarSema na()

169.Pla nifica cion Ali mentaria Eli minada
IMPRIMIR PLANIFICACION 170.Marca casi ll a "Seleccion ar Plani fi caci on Ali mentaria Semana l"
ALIMENTARIA SEMANAL
171.Presiona boton "Impri mir"
172.Procesa
1 73.gene rarReporte()
174 .Envi a reporte en formato impri mi bl e
175.Re porte Impreso
SALIR 176.Presi ona boton "Sal ir"
177.abreVentana ()
178.Muestra Pantal l a del Menu pri nci pal
368
W:VistaPlanificaciones W:InsumosRequeridos Planificacion Semana InsumoRequeridoMenu InsumoRequeridoPlanificacion ExistenciaArticulo PedidoInsumo
Usuario Impresora
1.Selecciona Planificar Servicio
2.abreVentana()
3.Busca Planificaciones creadas por semana
4.cargarSemana()
5.Busca Semanas Planificadas
6.buscarSemanas()
8.Muestra Semanas y las planificaciones de acuerdo a la ultima semana planificada 7.buscarPlanificaciones()
CONSULTAR INSUMOS
REQUERIDOS DE UNA 9.Selecciona Planificacion alimentaria
PLANIFICACION
ALIMENTARIA 10.Presiona boton "Insumos"
11.abreVentana()
12.Cambia Ventana
13.Busca informacion de la Planificacion seleccionada
14.cargarInsumoRequeridoMenu()
15.Busca Insumos requeridos para los menus programados en la planificacion seleccionada
16.buscarInsumoRequeridoMenu()
17.cargarInsumoRequeridoPlanificacion()
18.Buscar Insumos requeridos para prestar el servicio en la planificacion seleccionada
19.buscarInsumoRequeridoPlanificacion()
20.buscarPlanificaciones()
21.calcularCantidadTotalInsumoRequerido()
22.cargarExistenciaArticulo()
23.Busca cantidades existentes de los insumos requeridos en almacen
24.buscarExistenciaArticulo()
25.Muestra las cantidades planificadas de insumos requeridos y sus existencias en almacen
26.Edita cantidades a comprar de insumos requeridos

28.Procesa
29.Guarda las cantidades a comprar de insumos requeridos para prestar el servicio de alimentacion Si no ha sido creado
el pedido
30.Insertar()
Si ya ha sido creado
el pedido
31.actualizar()
32.Lista de Pedido Guardada
IMPRIMIR HOJA 33.Presion boton "Imprimir"

DE PEDIDO 34.Procesa
35.generarHojaPedido()
36.Envia Reporte Hoja de Pedido en formato imprimible
37.Reporte de Hoja de Pedido Impreso
38.Presiona boton "Retornar"

RETORNAR
39.abreVentana()
40.Muestra pantalla anterior
369
W:Regi stroComensal es W:Histori alComensal es AccesoCom ensal T i poM enu M enu Estudiante
Estudiante Escaner de Codi go Barra Ayudante de Comedor Impresora
1.Sel ecciona Regi strar Acceso de comensal es
2.abreVentana()
3.Carga informaci n
4.cargarT ipoMenu()
5.Busca ti pos de m enu
6.buscarT i poM enu()
7.generarFecha()
8.Muestra ti pos de m enu y fecha actual
9.Sel ecciona T i po de Menu

BUSCAR M ENU
A SERVIR 10.Procesa
11.cargarMenuAl imentario()
12.Busca M enu de acuerdo a ti po y fecha actual
13.buscarMenu(codMenu)
14.M uestra Menu Al im entario de acuerdo a l a fecha actual y ti po de menu selecci onado
15.Pasa codigo de barra de carnet estudiantil por escaner

REGIST RAR
COMENSALES 16.capturaCedul a()
17.Procesa
18.Busca Datos de Estudi ante
19.cargarDatosEstudi ante()
20.Busca estudiante por cedula
22.Muestra Datos del Estudi ante 21.buscarEstudiante()
23.Presiona boton "Registrar"

24.Procesa
Si Resp=false 25.Resp=comprobar()
26.Estudi ante ya ha si do registrado
Si Resp=true
28.Estudi ante Registrado 27.regi strarCom ensal()
SALIR 29.Presiona boton "Sal ir"
30.abreVentana()
31.M uestra Pantal la del Men Principal
CONSULT AR 32.Selecci ona Consultar Histori al Com ensales

HIST ORIAL DE
33.abreVentana()
COM ENSALES
34.Muestra tipos de busqueda
35.Sel ecciona T ipo de bsqueda
36.Presi on boton "Aceptar"

37.Procesa
38.buscarComensales()
39.M uestra l ista de comensales registrados de acuerdo al tipo de bsqueda
Imprimi r
i nform aci n 40.Presiona boton "Impri mi r"
41.Procesa
consultada
42.generarReporte()
43.Envia Reporte en form ato i mpri mibl e
44.Reporte Impreso
370
W:E xi sten ci a s W:E di ci o n Reg i stro Exi ste n cia W:B u scad o rIn su m o E xiste n ci a Arti cu l o Ub i ca cio n In su m o T i p o Insu m o
Usua ri o Im p re so ra
1 .Re gi stra r Insu m o s en A l m ace n

2 .a b reV e n ta na ()
3 .B usca E xiste n ci a s d e a rti cu l o s e n a l m a cen
4.b u sca rE xi ste nci a A rti cu l o s()

5 .M ue stra E xi ste n ci as d e a rti cu l o s en a l m a ce n
RE GIS T RA R
6 .Pre si o n a b o to n "Nu e vo"
INS UM O E N
A L M A CE N 7 .a b reV e n ta na ()
8.Ca m b i a V e n tan a
9 .Ca rga Fo rm u l a ri o
1 0 .ca rga rUb i caci o n ()
11 .B u sca u b i ca ci o n e s en a l m ace n
1 2 .b u sca rUb i caci o n ()
1 4 .M ue stra Form u l a ri o 13 .ca rg arFo rm ul a ri o ()
1 5 .L l en a d a tos d e e xi ste n ci a d e i n sum o e n al m a ce n
B u sca r In su m o a 1 6 .P resi o n a Ico n o "Bu sca r Insu m o s"

re g i strar
1 7 .ab re V e nta n a ()
18 .Ca m bi a V e n ta n a
1 9 .Ca rga In fo rm a ci o n
2 0 .ca rga rT i p o In su m o ()
2 1 .B u sca T i p o s d e In su m o
2 2 .b usca rT i po In su m o()
2 3 .b u sca rIn su m o s()

2 4 .M u e stra L i sta de In su m o s
2 5 .Se l e cci on a T i p o d e In su m o
2 6 .b usca In sum o s
2 7 .b u sca rIn su m o s()

2 8 .M u e stra l i sta d e In su m os d e a cue rd o a l ti p o sel e cci o n ad o
2 9 .L l e n a ca m p o de b u sq ue d a
30 .P re si on a b o ton "Fi l trar"

31 .B u sca i n su m o s d e acu e rd o a ca ra cte re s te cl e a d o s
3 3.Fi l tra li sta d e i n su m o s d e a cue rd o a ca d e n a te cl e a da 3 2 .b u sca rIn su m o s()
3 4 .Se l e cci o na In su m o d e l a l i sta

3 5.P ro ce sa
3 6 .ca rga In su m o ()
3 7 .M ue stra i nfo rm a cio n d e in su m o en fo rm ul a ri o
G u a rd ar E xi sten ci a 3 8.P re si o na b o to n "G u a rda r"

39 .P ro cesa
d e Insu m o en
Al m a ce n 4 0 .Re sp =va l i da r()
S i Re sp =fa l se
4 2 .Dato s i n val i d o s
S i Re sp =tru e 4 1 .a gre g a r()

4 3 .A rticu l o Reg i stra d o
4 5 .M ue stra P an ta l l a an te ri o r 4 4 .a b re V en ta n a ()
4 6 .P re si o na b o to n "Re to rna r"

RE T O RNA R
4 7 .a b re V en ta n a ()
4 7 .M ue stra p an ta l l a an te ri o r
B USCA R ART ICULO 4 9 .Ll e n a cam p o d e b sq u ed a

RE G IS T RA DO 5 0 .P resi o n a "Fi l tra r"
51 .B u sca E xi ste nci a s d e a rti cu l os d e a cu e rd o a ca ra ctere s te cle a d o s
5 2 .b u sca rE xi sten ci a A rti cu l o s()

5 3.M u e stra L i sta d e a rti cu l o s e xiste n te s e n a l m ace n d e a cu e rdo a l a cad e n a te cl e a d a
5 4 .S el e cci o na a rti cul o d e l a l i sta

M O DIFICA R REG IS T RO DE
INS UM O E N A L M A CE N 5 5 .Pre si o n a b o to n "M o d i fi ca r"
5 6 .a bre V e n tan a ()
5 7 .Ca m b i a V e n ta na ()
5 8.Ca rg a fo rm u l ari o co n d a to s de l a rti cul o
5 9 .b u sca rA rti cu l o ()
6 0 .ca rga rUb i caci o n ()
61 .B u sca u b i ca ci o n e s en a l m ace n
6 2 .b u sca rUb i caci o n ()
6 4.M u e stra fo rm ul a ri o con i n fo rm a ci n de l a rti cu l o e xi ste n te e n a l m a ce n 6 3 .ca rga rFo rm u l a ri o ()
6 5 .Ed i ta d ato s d e l arti cu l o e xi ste n te e n a l m a ce n
6 6.P re si o na b o to n "G u a rda r"

67 .P ro cesa
69 .A rti cul o A ctua l i za d o 6 8 .a ctua l i za r()
7 0 .ab re V e nta n a ()
7 1 .M ue stra p an ta l l a an te ri o r
E L IM INA R REG IS T RO DE 7 2 .S e l ecci o n a u n a rti cu l o d e la l i sta

INS UM O E N A L M A CE N
7 3 .Pre si o n a b o to n "E l i m i na r"
7 4 .P ro ce sa
7 5 .e li m i n a r()
76 .A rti cul o E l i m i n a d o
7 7 .Pre si o n a b o to n "Im p ri m i r"

IM P RIM IR 7 8 .P ro ce sa
7 9 .g e ne ra rRe po rte ()
8 0.E n vi a Re p o rte d e e xi ste n ci a s d e a rti cu l o s e n fo rm a to i m p ri m i b l e
8 1 .Rep o rte d e e xi ste nci a s d e a rti cu l os i m p reso
8 2.P re si on a b o ton "S a l i r"

S A L IR
8 3 .a bre V e n tan a ()
8 4 .M ue stra P an ta l l a de l M e nu p ri n cip a l
371
W : V i st a R e g i s t r o sE n t r a d a W : R e g i st r o E n t r a d a W : B u sc a d o rI n su m o E n t ra d a A rt i c u l o sA l m a c e n O rd e n C o m p ra P ro v e e d o r S t a t u sE n t ra d a D e t a l l e E n t ra d a A rt i c u l o I n su m o T i p o In su m o E x i st e n c i a A rt i c u l o
U su a ri o I m p re so ra
1 . S e l e c c i o n a R e g i st r a r E n t r a d a s
3 . C a rg a i n f o rm a c i o n
4 . c a r g a r O r d e n e sC o m p r a ( )
5 . B u sc a o r d e n e s d e c o m p r a d e l c o m e d o r u n i v e r si t a r i o
6 . b u s c a r O r d e n e sC o m p r a ( )
7 . B u sc a p r o v e e d o r e s
8 . b u sc a r P r o v e e d o r e s( )
9 . b u sc a r R e g i s t r o s E n t r a d a ( )
1 0 . c r e a r R e g i st r o E n t r a d a ( )
1 1 . c a r g a r S t a t u sE n t r a d a ( )
1 2 . B u sc a l o s s t a t u s d e e n t r a d a
1 3 . b u s c a r S t a t u sE n t r a d a ( )
1 4 . M u e st ra st a t u s d e e n t r a d a e i n f o rm a c i n d e re g i st ro s d e e n t ra d a d e a rt i c u l o s
B U S C A R R E G IS T R O S
D E E N T R A D A S D E 1 5 . S e l e c c i o n a u n S t a t u s d e E n t ra d a
A R T IC U L O S 1 6 . B u s c a r e g i s t r o s d e e n t r a d a d e a c u e r d o a l s t a t u s se l e c c i o n a d o
1 7 . b u s c a r R e g i st r o s E n t r a d a ( )
1 8 . M u e st r a r e g i s t r o s d e e n t r a d a d e a r t i c u l o s s e g u n st a t u s s e l e c c i o n a d o
1 9 .L l e n a c a m p o d e B u sq u e d a
2 0 . P re si o n a b o t o n " F i l t ra r"
2 1 . B u sc a r e g i s t r o s d e e n t r a d a d e a c u e r d o a c a r a c t e r e s t e c l e a d o s
2 3 . F i l t ra re g i st ro s d e e n t ra d a d e a rt i c u l o s d e a c u e rd o a c a d e n a t e c l e a d a 2 2 . b u s c a r R e g i st r o s E n t r a d a ( )
R E G IS T R A R E N T R A D A 2 4 . S e l e c c i o n a u n r e g i st r o d e e n t r a d a d e l a l i st a
D E A R T IC U L O S
2 5 . P re si o n b o t o n " R e g i st ra r"
2 6 . a b re V e n t a n a ()
2 7 .C a m b ia V e n ta n a
2 8 . C a rg a F o rm u l a ri o c o n i n f o rm a c i o n d e l re g i st ro d e e n t ra d a se l e c c i o n a d o
2 9 . b u s c a r R e g i st r o E n t r a d a ( n u m E n t r a d a )
3 0 . c a rg a rS t a t u sE n t ra d a ()
3 1 . B u sc a l o s d i f e re n t e s st a t u s d e e n t ra d a
3 2 . b u s c a r S t a t u sE n t r a d a ( )
3 3 . c a rg a rD e t a l l e E n t ra d a A rt i c u l o ()
3 4 . B u sc a d e t a l l e s d e l re g i st ro d e e n t ra d a d e a rt i c u l o s
3 5 . b u sc a rD e t a l l e ()
3 7 . M u e s t r a F o r m u l a r i o c o n i n f o r m a c i o n d e l r e g i st r o d e e n t r a d a
3 8 . E d i t a D a t o s g e n e ra l e s d e l R e g i st ro d e E n t ra d a d e A rt i c u l o s
R e g i st r a r d e t a l l e d e
I n su m o o A rt i c u l o 3 9 . P r e si o n I c o n o " B u s c a r I n s u m o s "
E n t ra n t e
4 0 . a b re V e n t a n a ()
4 2 . C a rg a I n f o rm a c i n
4 3 . c a r g a r T i p o I n su m o ( )
4 4 . B u sc a t i p o s d e I n s u m o
4 5 . b u sc a r T i p o I n s u m o ( )
4 6 . b u s c a r I n s u m o s( )
4 7 . M u e s t r a L i s t a d e I n su m o s
4 8 . S e l e c c i o n a T i p o d e I n su m o
4 9 .b u sc a In su m o s
5 1 . M u e s t r a l i s t a d e I n su m o s d e a c u e r d o a l t i p o s e l e c c i o n a d o 5 0 . b u s c a r I n s u m o s( )
5 2 .L l e n a c a m p o d e b u sq u e d a
5 3 . P r e si o n a b o t o n " F i l t r a r "
5 4 . B u sc a i n su m o s d e a c u e rd o a c a ra c t e re s t e c l e a d o s
5 5 . b u s c a r I n s u m o s( )
5 6 . F i l t r a l i s t a d e i n su m o s d e a c u e r d o a c a d e n a t e c l e a d a
5 7 .S e l e c c i o n a In su m o d e l a l i sta
5 8 . P r o c e sa
6 0 . M u e s t r a i n f o r m a c i o n d e i n su m o e n f o r m u l a r i o 5 9 . c a rg a rI n su m o ()
6 1 . E sc ri b e c a n t i d a d e n t ra n t e d e l a rt i c u l o
6 2 . P r e si o n b o t o n " R e g i s t r a r "
6 3 . P ro c e sa
6 4 . A g re g a
6 5 . a g re g a r()
6 6 . A c t u a l i z a e x i st e n c i a d e a rt i c u l o
6 7 . R e sp = c o m p r o b a r E x i s t e n c i a ( )
S i R e sp = t ru e
6 8 . c a l c u l a rE x i st e n c i a A c t u a l ()
S i R e s p = f a l se
6 9 . a g re g a r()
7 0 . E n t ra d a d e A rt i c u l o R e g i st ra d a
M o d ific a r d e ta lle d e 7 1 . E d i t a d a t o s d e e n t ra d a d e a rt i c u l o
I n su m o o A rt i c u l o
E n t ra n t e 7 2 . E d i t a P re c i o U n i t a ri o d e l A rt i c u l o E n t ra n t e
7 3 . P ro c e sa
7 4 . A c t u a l i z a D e t a l l e d e l A rt i c u l o E n t ra n t e
7 5 . a c t u a l i z a r()
7 7 . A rt i c u l o E n t ra n t e a c t u a l i z a d o 7 6 . c a l c u l a rP re c i o T o t a l ()
7 8 . P r e si o n b o t o n " G u a r d a r "
G u a rd a r 7 9 . P ro c e sa
S i R e s p = f a l se 8 0 . R e sp = v a l i d a r ( )
8 1 .D a to s In v a lid o s
S i R e sp = t ru e
8 2 . a c t u a l i z a r R e g i st r o E n t r a d a ( )
8 3 . R e g i st r o A c t u a l i z a d o
8 4 . P re si o n a b o t o n " I m p ri m i r"
IM P R IM IR 8 5 . P ro c e sa
8 6 . g e n e ra rR e p o rt e R e g i st ro E n t ra d a ()
8 7 . E n v i a R e p o rt e d e R e g i st ro d e E n t ra d a e n f o rm a t o i m p ri m i b l e
8 8 . R e p o r t e d e R e g i s t r o E n t r a d a I m p r e so
R E T O R N A R
9 0 . a b re V e n t a n a ()
9 1 . M u e st r a P a n t a l l a A n t e r i o r
9 2 . P r e si o n a b o t o n " S a l i r "
S A L IR
9 3 . a b re V e n t a n a ()
9 4 . M u e st ra P a n t a l l a d e l m e n u p ri n c i p a l
372
W : R e g i stro S a l i d a W : A j u st e E x i st e n c i a S a l i d a A rt i c u l o sA l m a c e n T ip o M e n u P l a n i fic a ci o n M en u I n su m o R e q u e ri d o M e n u I n su m o R e q u e ri d o P l a n i f i c a c i o n E x i st e n c i a A rt i c u l o D e t a l l e S a l i d a A rt i c u l o A j u st e E x i st e n c i a T i p o A j u st e
1 . S e l e c c i o n a R e g i stra r S a l i d a s
3 . C a rg a i n f o rm a c i o n
4 . g e n e ra rF e c h a ()
5 . g e n e ra rN u m S a l i d a ()
6 . c a rg a rT i p o M e n u ()
7 .B u sc a T i p o s d e M e n u
8 .b u sc a rT i p o M e n u ()
9 .c a rg a rF o rm u l a ri o ()
1 0 .M u e st ra F o rm u l a ri o
B USCAR M E NU 1 1 .S e l e c ci o n a T ip o d e M e n u
1 2 . P ro c e sa
P L A N IF IC A D O
1 3 . c a rg a rP l a n i f i c a c i o n ()
1 4 . c a rg a rM e n u ()
1 5 .c a rg a rI n su m o R e q u e ri d o M e n u ()
1 6 . c a rg a rIn su m o R e q u e ri d o P l a n i fi c a c i o n ()
1 7 .B u sc a In fo rm a c i o n d e l a P l a n i fi c a c i o n d e a c u e rd o a f e c h a y ti p o d e m e n u se l e c c i o n a d o
1 8 . b u sc a rP l a n i f i c a c i o n ()
1 9 .B u sc a m e n u p l a n i f i c a d o
2 0 . b u sc a rM e n u (c o d M e n u )
2 1 . b u sc a i n su m o s re q u e ri d o s d e l m e n u
2 2 .b u sc a rI n su m o R e q u e ri d o M e n u ()
2 3 .B u sc a r I n su m o s re q u e ri d o s p a ra p re st a r e l se rv i c i o
2 4 . b u sc a rI n su m o R e q u e ri d o P l a n i f i c a c i o n ()
2 5 . c a l c u l a rC a n ti d a d T o t a l I n su m o R e q u e ri d o ()
2 6 .c a rg a rE x i st e n c i a A rti c u l o ()
2 7 . B u sc a E x i st e n c i a e n a l m a c e n d e l o s i n su m o s re q u e ri d o s
2 8 . b u sc a rA rti c u l o ()
S i R e sp = fa l se 2 9 . R e sp = v e ri fi c a rD i sp o n i b i l i d a d I n su m o A l m a c e n ()
3 0 . N o e x i st e e n A l m a c e n S u f i c i e n te s In su m o s p a ra p re p a ra r e l m e n p l a n i fi c a d o
S i R e sp = t ru e
3 1 . M u e st ra i n f o rm a c i o n p a ra re a l i z a r e l re g i st ro d e sa l i d a d e a rti c u l o s d e a l m a c e n
3 2 . L l e n a d a t o s g e n e ra l e s d e sa l i d a
3 3 . L l e n a c a n ti d a d sa l i e n te d e l a rt i c u l o
R E G IS T R A R S A L ID A D E
R e g i st ra r c a n t i d a d sa l i e n t e 3 4 . P ro c e sa
A R T IC U L O S D E L
ALM A CEN. d e a rt i c u l o
3 5 . v e ri fi c a rC a n t i d a d S a l i e n t e ()
3 6 .N o E x i ste C a n t i d a d I n g re sa d a d e l i n su m o e n a l m a c e n
3 7 .A g re g a
3 8 .a g re g a r()
3 9 . c a l c u l a rP re c i o T o t a l ()
4 0 . A c tu a l i z a E x i ste n c i a d e l a rt i c u l o e n A l m a c e n
4 2 .M u e stra P re c i o T o t a l d e l a c a n t i d a d sa l i e n t e d e l a rt i c u l o
4 3 . S e l e c c i o n a a rt i c u l o d e l a l i st a
A j u sta r E x i st e n c i a d e a rti c u l o
d e a l m a ce n 4 4 .P re si o n a i c o n o A j u st a r E x i st e n c i a d e A rt i c u l o
4 5 .a b re V e n t a n a ()
4 7 . C a rg a f o rm u l a ri o
4 8 .c a rg a rE x i st e n c i a A rti c u l o ()
4 9 . B u sc a
5 0 . b u sc a rA rt i c u l o ()
5 1 . c a rg a rT i p o A j u st e ()
5 2 . B u sc a
5 4 .M u e stra f o rm u l a ri o p a ra re a l i z a r e l a j u st e d e e x i st e n c i a d e a rt i c u l o 5 3 .b u sc a rT i p o A j u st e ()
5 5 . L l e n a fo rm u l a ri o
5 6 .P re si o n a b o t o n " G u a rd a r"
5 7 . P ro c e sa
5 8 .c re a rA j u ste ()
5 9 . R e a l i z a A j u st e
6 0 .a j u st a rE x i st e n c i a ()
6 1 . A j u ste R e a l i z a d o
6 2 . a b re V e n t a n a ()
6 3 . M u e st ra P a n ta l l a A n t e ri o r
G u a rd a r 6 5 . P ro c e sa
6 6 .c re a rR e g i st ro S a l i d a ()
6 7 .R e g i st ro d e sa l i d a d e a rt i c u l o s re g i st ra d o s
M O D I F I C A R R E G IS T R O D E 6 8 . E d i t a D a to s G e n e ra l e s d e sa l i d a
S A L ID A D E A R T I C U L O S M o d i fi c a r re g i stro d e l a 6 9 .E d i t a C a n t i d a d S a l i e n te d e l A rt i c u l o
D EL ALM A CEN. c a n ti d a d sa l i e n te d e 7 0 .P ro c e sa
a rt i c u l o
7 1 . m o d i f i c a r()
7 2 . c a l c u l a rP re c i o T o ta l ()
7 3 . A c tu a l i z a E x i ste n c i a d e l a rt i c u l o e n A l m a c e n
7 5 .M u e stra P re c i o T o t a l d e l a c a n t i d a d sa l i e n t e d e l a rt i c u l o
7 6 .P re si o n a i c o n o d e A j u ste re a l i z a d o a l a e x i ste n c i a d e l a rt i c u l o se l e c c i o n a d o
M o d i f i c a r A j u st e d e E x i st e n c i a
d e a rt i c u l o d e a l m a c e n 7 6 .a b re V e n t a n a ()
7 8 . C a rg a F o rm u l a ri o c o n i n f o rm a c i o n d e a j u ste d e l a rt i c u l o se l e c c i o n a d o
7 9 . b u sc a r()
8 0 . c a rg a rT i p o A j u st e ()
8 1 . B u sc a
8 3 . M u e st ra F o rm u l a ri o c o n i n f o rm a c i o n d e a j u ste d e l a rt i c u l o se l e c c i o n a d o 8 2 .b u sc a rT i p o A j u st e ()
8 4 . E d i t a F o rm u l a ri o
8 6 . P ro c e sa
8 7 . m o d i f i c a r()
8 8 . R e a l i z a r A j u st e
8 9 . a j u st a rE x i ste n c i a ()
9 0 . A j u ste R e a l i z a d o
9 1 . a b re V e n t a n a ()
9 2 . M u e st ra P a n ta l l a A n t e ri o r
9 4 . P ro c e sa
9 5 . m o d i f i c a rR e g i st ro S a l i d a ()
9 6 . R e g i st ro d e S a l i d a d e A rt i c u l o s A c t u a l i z a d o
IM P R IM I R 9 7 .P re si o n a b o t o n " I m p ri m i r"
9 8 . P ro c e sa
9 9 . g e n e ra rR e p o rt e R e g i st ro S a l i d a ()
1 0 1 . E n v i a R e p o rte d e R e g i st ro d e S a l i d a e n f o rm a t o i m p ri m i b l e
1 0 2 . R e p o rt e d e R e g i st ro S a l i d a Im p re so
1 0 3 .P re si o n a b o t o n " S a l i r"
S A L IR
1 0 4 . a b re V e n ta n a ()
1 0 5 . M u e st ra P a n t a l l a d e l M e n u p ri n c i p a l
373
W : R e p o rt e C o st o s T ip o R e p o rte R e p o rt e C o st o s P la n ific a c io n M e n u S a l i d a A rt i c u l o sA l m a c e n D e t a l l e S a l i d a A rt i c u l o A c c e so C o m e n s a l P ro v e e d o r E n t ra d a A rt i c u l o sA l m a c e n O rd e n C o m p ra
1 . S e l e c c i o n a G e n e ra r R e su m e n d e C o st o s
3 . B u sc a T i p o s d e R e p o rt e
4 . b u sc a r()
5 . M u e st ra T i p o s d e R e p o rt e s
G E N E R A R R E P O R T E 6 . S e l e c c i o n a C o n t ro l D i a ri o d e C o sto s
C O N T R O L D IA R IO D E
C O S T O S 7 . M u e st ra c a m p o F e c h a
8 . I n t ro d u c e F e c h a
9 . P re si o n b o t o n " A c e p t a r "
1 0 . P ro c e sa
1 1 . c a rg a r P l a n i f i c a c i o n ()
1 2 . c a r g a rM e n u ()
1 3 . B u sc a P l a n i f i c a c i o n e s d e a c u e rd o a fe c h a
1 5 .B u sc a M e n u P la n i fic a d o
1 6 . b u sc a rM e n u (c o d M e n u )
1 7 . c a rg a r S a l i d a A rt i c u l o s()
1 8 . B u sc a s a l i d a d e a rt i c u l o s d e a c u e rd o a l o p l a n i f i c a d o p a ra e sa fe c h a
1 9 . b u sc a r R e g i st ro S a l i d a ()
2 0 .B u sc a d e ta ll e s d e a c u e rd o a n u m e ro d e sa l i d a
2 1 . b u sc a r D e t a l l e ()
2 2 . c a l c u l a rC o st o S e rv i c i o ()
2 3 . c a rg a rN u m C o m e n s a l e s()
2 4 . B u sc a N u m e r o d e C o m e n s a l e s d e a c u e rd o a l d i a y t u rn o s p l a n i f i c a d o s
2 5 . b u sc a rC o m e n s a l e s()
2 6 . c a l c u l a rC o st o U n i t a ri o S e rv i c i o ()
2 7 . M u e st ra R e p o rt e C o n t ro l D i a ri o d e C o st o s
2 8 . E sc ri b e O b s e rv a c i o n
G E N E R A R R E P O R T E 2 9 . S e l e c c i o n a R e l a c i o n p o r S e rv i c i o y N u m e ro d e C o m e n sa l e s
R E L A C IO N P O R
S E R V IC IO Y N U M E R O 3 0 . M u e s t ra l i s t a d e M e se s y A o s
D E C O M E N S A L E S
3 1 .S e le c c io n a m e s y a o
3 2 . P re si o n a b o t o n " A c e p t a r"
3 3 . P ro c e sa
3 4 . c a rg a r P l a n i f i c a c i o n ()
3 5 .B u sc a P l a n i f i c a c i o n e s d e a c u e rd o a m e s y a o
3 7 . c a rg a rN u m C o m e n s a l e s()
3 8 . B u sc a N u m e ro d e C o m e n sa l e s d e a c u e rd o a l o s d i a s y t u rn o s p l a n i f i c a d o s e n e l m e s y a o se l e c c i o n a d o s
3 9 . b u s c a rC o m e n sa l e s()
4 0 . c a l c u l a rT o t a l C o m e n s a l e s M e s( )
4 1 . M u e s t ra R e p o rt e R e l a c i o n p o r se r v i c i o y n u m e ro d e c o m e n sa le s
G E N E R A R R E P O R T E
4 2 .S e le c c io n a R e l a c i o n d e A l i m e n t o s, B e b i d a s y O t ro s R e c i b i d a s P o r A l m a c e n
R E L A C IO N D E 4 3 . B u sc a
A L IM E N T O S , B E B ID A S Y
O T R O S R E C I B ID A S P O R 4 4 . c a rg a rP ro v e e d o re s()
A L M A C E N 4 5 . B u sc a P ro v e e d o re s d e l C o m e d o r U n i v e rsi t a ri o
4 6 . b u sc a rP ro v e e d o re s()
4 7 . M u e st ra l i st a d e m e s e s, a o s y p ro v e e d o re s
4 8 . S e l e c c i o n a A o y P ro v e e d o rM e s
4 9 . P re si o n a B o t o n " A c e p t a r"
5 0 . P ro c e sa
5 1 . c a rg a r R e g i st ro sE n t ra d a ()
5 2 . B u sc a e n t ra d a d e a rt i c u l o s d e a c u e rd o a l o se l e c c i o n a d o
5 3 . b u s c a rR e g i st ro s E n t r a d a ()
5 4 . b u sc a
5 5 . b u sc a rO rd e n C o m p ra (n u m O r d e n )
5 6 .b u sc a
5 7 . b u sc a rP ro v e e d o r(c o d P ro v e e d o r)
5 8 . c a l c u l a rC o st o T o t a l E n t ra d a ()
5 9 . M u e st r a R e p o rt e R e l a c i o n d e a l i m e n t o s, b e b i d a s y o t ro s re c i b i d a s p o r a l m a c e n
G E N E R A R R E P O R T E
R E L A C IO N D E 6 0 . S e l e c c i o n a R e l a c i o n d e A l i m e n t o s y C o n e x o s E n t re g a d o s P o r A l m a c e n
A L IM E N T O S Y C O N E X O S
E N T R E G A D O S P O R 6 1 . M u e s t ra L i s t a d e M e se s y A o s
A L M A C E N
6 4 . P ro c e sa
6 5 . c a rg a rS a l i d a A r t i c u l o s()
6 6 . B u sc a sa l i d a s d e a rt i c u l o s d e a c u e rd o a m e s y a o s e l e c c i o n a d o s
6 7 . b u s c a rR e g i st ro S a l i d a ( )
6 8 .B u sc a d e ta ll e s d e a c u e rd o a n u m e ro d e sa l i d a
6 9 . b u sc a rD e t a l l e ( )
7 0 . c a l c u l a rC o st o T o t a l S a l i d a (m e s, a o )
7 1 . M u e st ra R e p o rt e R e l a c i o n d e A l i m e n t o s y C o n e x o s E n t re g a d o s P o r A l m a c e n
G E N E R A R R E P O R T E 7 2 . S e l e c c i o n a R e su m e n M e n s u a l d e C o sto s
R E S U M E N M E N S U A L D E
C O S T O S 7 3 . M u e s t ra L i s t a d e M e se s y A o s
7 6 . P ro c e sa
7 7 . c a rg a rP l a n i f i c a c i o n ()
7 8 . B u sc a P l a n i f i c a c i o n e s d e a c u e rd o a l a o se le c c io n a d o
8 0 . c a rg a rS a l i d a A rt i c u l o s()
8 1 . B u s c a sa l i d a s d e a rt i c u l o s d e a c u e rd o a l o s d i a s y t u rn o s p l a n i f i c a d o s e n e l a o se l e c c i o n a d o
8 2 . b u s c a rR e g i st ro S a l i d a ( )
8 3 . c a l c u l a rC o st o T o t a l S a l i d a (m e s, a o )
8 4 . c a l c u l a rC o st o T o t a l M e s()
8 5 . c a l c u l a rC o st o T o t a l A c u m u l a d o H a s t a M e s A n t e ri o r()
8 6 . c a l c u l a rC o st o T o t a l A c u m u l a d o A L a f e c h a ()
8 7 . c a rg a r N u m C o m e n sa l e s ()
8 8 . B u sc a N u m e ro d e C o m e n sa l e s d e a c u e rd o a l o s d i a s y t u rn o s p l a n i f i c a d o s e n e l a o se l e c c i o n a d o
8 9 . b u sc a rC o m e n s a l e s()
9 0 . c a l c u l a rT o t a l C o m e n sa l e sM e s ()
9 1 . c a l c u l a T o t a l C o m e n sa l e s H a s t a M e s A n t e ri o r()
9 2 . c a l c u l a rT o t a l C o m e n sa l e s A L a F e c h a ()
9 3 . c a l c u l a rC o st o U n i t a ri o S e rv i c i o M e s()
9 4 . c a l c u l a rC o st o U n i t a ri o S e rv i c i o A L a F e c h a ()
9 5 . M u e st ra R e p o rt e R e s u m e n M e n su a l d e C o st o s
9 6 .E d ita R e p o rt e
9 7 . P re si o n B o t o n " I m p ri m i r"
IM P R IM IR R E P O R T E
9 8 . g e n e ra rR e p o rt e ()
9 9 .E n v ia R e p o r t e e n F o r m a t o I m p ri m i b l e
1 0 0 . R e p o r t e I m p re so
1 0 1 . P re si o n a B o t o n " S a l i r"
S A L IR
1 0 2 . a b re V e n t a n a ()
1 0 3 . M u e st ra P a n t a l l a d e l M e n u P ri n c i p a l
374
Semana
- codigoSemana : String
- numeroSemana : String AccesoComensal
- descripcion : String
- numeroAcceso : String
- control : String
- cedula : String 1..*
+ crearSemana () : void - codPlanificacion : String Corresponde
+ actualizarSemana () : void
+ cargarTipoMenu () : void
+ eliminarSemana () : void
+ generarFecha () : void
+ buscarSemanas () : void
+ cargarMenuAlimentario () : void
+ buscarSemana (String codSemana) : void
+ cargarDatosEstudiante () : void
1..1 + comprobar () : void
ReporteCostos Agrupa + registrarComensal () : void
+ buscarComensales () : void
- fecha : String + generarReporte () : void 1..1
- mes : String 1..* Estudiante
Tiene
- anio : String Corresponde
1..* - cedula : String
- codTipo : String - nombres : String
EsUtilizadoEn
+ cargarPlanificacion () : void - apellidos : String
+ cargarMenu () : void 1..1
1..* + buscarEstudiante () : void
+ cargarSalidaArticulos () : void Utiliza
Pertenece
+ calcularCostoServicio () : void
+ cargarNumComensales () : void Planificacion
+ calcularCostoUnitarioServicio () : void 1..*
- codPlanificacion : String
+ calcularTotalComensalesMes () : void Genera
- fecha : String DetalleSolicitud
+ cargarProveedores () : void
1..* - estimadoComensales : String
+ cargarRegistrosEntrada () : void - codDetalle : String
Pertenece - codMenu : String 1..*
+ calcularCostoTotalEntrada () : void - numSolicitud : String
- codTipoMenu : String Posee
+ calcularCostoTotalSalida (String mes, String anio) : void - fechaEvento : String
- codigoSemana : String 1..1
+ calcularCostoTotalMes () : void - codTipoMenu : String
- especial : String TipoMenu EsTurnoDe
+ cacularCostoTotalAcumuladoHastaMesAnterior () : void 1..* - numComensales : int
+ calcularCostoTotalAcumuladoALaFecha () : void + cargarSemana () : void Tiene
1..1 1..1 - codTipoMenu : String + agregarDetalle () : void
TipoReporte + calcularTotalComensalesHastaMesAnterior () : void + buscarPlanificaciones () : void Contiene EsTurnoDe - descripcionTipoMenu : String + buscarDetalleSolicitud () : void
1..1 + calcularTotalComensalesALaFecha () : void + cargarTipoMenu () : void
- codTipo : String Agrupa + creaFechasSemana () : void + insertar () : void
+ calcularCostoUnitarioServicioMes () : void
- descripcion : String + cargarComensales () : void + actualizar () : void 1..*
+ calcularCostoUnitarioServicioALaFecha () : void
+ buscar () : void + estimarComensales () : void + eliminar () : void Compone
+ cargarEstimadoComensales () : void + buscarTipoMenu () : void
1..1 1..1
+ validar () : void + buscar (String codTipo) : void
Conforma Agrupa
+ insertar () : void Menu
+ eliminar () : void 1..1
- codMenu : String Representa
+ cargarInsumoRequeridoPlanificacion () : void
- descripcionMenu : String
+ cargarMenu () : void 1..1 - codTipoMenu : String
1..1 + cargarInsumoRequeridoMenu () : void Consta
Solicita + cargarExistenciaArticulo () : void + cargarTipoMenu () : void
+ comprobarExistenciaInsumosRequeridos () : void + buscarMenus () : void
+ validar () : void 1..1
SalidaArticulosAlmacen + actualizar () : void 1..* Contiene
+ eliminarPlanificacion (String codPlanificacion) : void + insertar () : void Pertenece
- numSalida : String + buscarMenu (String codMenu) : void
+ generarReporte () : void
- fechaSalida : String + cargarTipoNutriente () : void
+ calcularCantidadTotalInsumoRequerido () : void
- responsable : String 1..1 + cargarInsumoRequeridoMenu () : void SolicitudServicio
+ generarHojaPedido () : void InsumoRequeridoMenu
- codPlanificacion : String Corresponde + cargarFormulario () : void
+ buscarPlanificacion () : void - numSolicitud : String
+ generarFecha () : void - id : int 1..* + cargarAlimento () : void - fechaSolicitud : String
- codInsumo : String Compone
+ generarNumSalida () : void 1..1 + cargarNutrienteAlimento () : void - codStatus : String
1..1 - codMenu : String
+ cargarTipoMenu () : void Genera + calcularNutrienteMenu () : void - idSolicitante : String
Consta - cantidadAjustada : Double
+ cargarFormulario () : void + actualizar () : void - descripcionEvento : String 1..*
+ cargarPlanificacion () : void + buscarInsumoRequeridoMenu () : void + comprobar () : void - observacion : String Tiene
+ cargarMenu () : void + insertar () : void + eliminar (String codMenu) : void
+ generarFecha () : void
+ cargarInsumoRequeridoMenu () : void 1..1 + actualizar () : void + cargarMenu () : void
+ generarNumSolicitud () : void
+ cargarInsumoRequeridoPlanificacion () : void EsGeneradoDe + eliminar () : void + cargarUsuario () : void
+ cargarExistenciaArticulo () : void
+ cargarTipoMenu () : void StatusSolicitud
+ verificarDisponibilidadInsumoAlmacen () : void PedidoInsumo 1..* + cargarFormulario () : void 1..1
+ verificarCantdadSaliente () : void EsRepresentadoPor - codStatus : String
1..* + validar () : void EsEstadoDe
+ crearRegistroSalida () : void - id : int - descripcion : String
EsRepresentadoPor + enviarSolicitud () : void
+ modificarRegistroSalida () : void - codInsumo : String
+ cargarStatusSolicitud () : void + buscarStatusSolicitud () : void
+ generarReporteRegistroSalida () : void - codPlanificacion : String
1..1 1..1 TipoMenuInsumo + buscarSolicitudes () : void
+ buscarRegistroSalida () : void Contiene - cantidad : Double
Contiene + buscarSolicitud (String numSolicitud) : void
- codInsumo : String
+ insertar () : void + cargarDetalleSolicitud () : void
- codTipoMenu : String
1..1 + actualizar () : void + actualizarStatus () : void
+ buscar () : void + insertar (String codInsumo, String codTipoMenu) : void
Tiene 1..* + generarReporte () : void
+ eliminar (String codInsumo, String codTipoMenu) : void
Utiliza
+ eliminar (String codInsumo) : void
0..*
1..1 EsElaboradoPor
1..*
Existe Representa
1..* 1..*
Compone
Conforma Insumo 1..1
EsUtilizadoEn
InsumoRequeridoPlanificacion - codInsumo : String
DetalleSalidaArticulo
1..1 - descripcion : String 1..1
- codDetalle : String - id : int - codUm : String
Representa Elabora
- numSalida : String - codInsumo : String - codTipoInsumo : String
- codExistencia : String - codPlanificacion : String 1..1 TipoInsumo
- alimento : String Usuario
- cantidadSaliente : Double 1..1 - cantidad : Double Agrupa
+ cargarTipoInsumo () : void - codTipoInsumo : String
- precioSalida : Double ContieneSalidaDe - id : int
+ insertar () : void + buscarInsumos () : void - descripcion : String
- clave : String
+ agregar () : void + actualizar () : void 1..* + validar () : void 1..* + insertar () : void
0..1 - usuario : String 1..1
+ calcularPrecioTotal () : void + eliminar () : void EsRepresentadoPor + insertar () : void Pertenece + actualizar () : void TipoUsuario
SeRealizanEn - codUsuario : String Agrupa
+ modificar () : void + buscarInsumoRequeridoPlanificacion () : void + buscarInsumo (String codInsumo) : void + eliminar () : void - nombres : String 1..* - codUsuario : String
+ buscarDetalle () : void + cargarUm () : void + buscarTipoInsumo () : void Pertenece - descripcion : String
AjusteExistencia - apellidos : String
+ cargarTipoMenu () : void + buscar (String codTipo) : void - cargo : String - pagina : String
- numAjuste : String + cargarGrupoAlimento () : void - email : String + buscarOpciones () : void
- numSalida : String + cargarTipoNutriente () : void 1..* + validarUsuario (String usuario, String clave) : void + buscarTipoUsuario () : void
- codExistencia : String + cargarNutriente () : void Tiene
- cantidadAjustada : Double 1..1 + cargarOpciones () : void
1..1 + cargarFormulario () : void
- codTipoAjuste : String Cambia + buscarUsuarios () : void
SeEncuentraEn + actualizar () : void
- observacion : String 1..1 + cargarTipoUsuario () : void
+ comprobar () : void
EsAjustadaPor + cargarFormulario () : void
1..* + cargarExistenciaArticulo () : void ExistenciaArticulo + eliminar () : void
1..1 + validar () : void
Agrupa Pertenece + cargarTipoAjuste () : void + cargarInsumo () : void
- codExistencia : String Um + insertar () : void
+ crearAjuste () : void 1..1 1..1
TipoAjuste - codInsumo : String + buscarUsuario (String codUsuario) : void
+ buscar () : void Tiene Corresponde - codUm : String
- codUbicacion : String 1..* + actualizar () : void
- codTipoAjuste : String + modificar () : void
- existenciaMaxima : Double TienePropiedadDe - descripcionUm : String 1..1 + eliminar () : void
- descripcion : String DetalleEntradaArticulo Corresponde
1..1 - existenciaActual : Double + insertar () : void
+ buscarTipoAjuste () : void - codDetalle : String SeEncuentraEn - precioUnitario : Double + actualizar () : void
- numEntrada : String + eliminar () : void
+ buscarExistenciaArticulos () : void
- codExistencia : String + buscarUm () : void
1..1 + cargarUbicacion () : void
- cantidadEntrante : Double 1..1 + buscar (String codUm) : void
ContieneEntradaDe + cargarFormulario () : void 1..*
- precioEntrada : Double EsPropiedadDe
+ validar () : void Correponde
+ buscarDetalle () : void + agregar () : void
+ agregar () : void Alimento
+ buscarArticulo () : void
StatusEntrada + actualizar () : void + actualizar () : void - codInsumo : String 1..1
+ calcularPrecioTotal () : void + eliminar () : void - peso : Double EstaCompuestoDe 1..*
- codStatusEntrada : String 1..1
+ generarReporte () : void - codGrupo : String Tiene
- descripcion : String EsEstadoDe 1..* + comprobarExistencia () : void + insertar () : void
+ buscarStatusEntrada () : void Conforma + calcularExistenciaActual () : void + eliminar () : void Nutriente
+ ajustarExistencia () : void + actualizar () : void NutrienteAlimento - codNutriente : String
+ buscarAlimentos () : void TipoNutriente
- id : int 1..1 - descripcion : String
1..1 + buscar (String codInsumo) : void
- codInsumo : String Representa - codUm : String - codTipoNutriente : String
1..1 EstaSituadoEn 1..1
1..* - codNutriente : String - codTipoNutriente : String - descripcionTipoNutriente : String
1..* Contiene 1..* Agrupa
Pertenece EsComposicionDe - cantidad : Double + insertar () : void + insertar () : int
Posee 1..*
EntradaArticulosAlmacen + insertarNutriente (String codInsumo, String codNutriente) : void 1..* + actualizar () : void + actualizar () : int
Pertenece
+ modificarNutriente () : void EsRepresentadoPor + eliminar () : void + eliminar () : int
- numEntrada : String
+ eliminarNutriente () : void + buscarNutrientes () : void + buscarTipoNutriente () : int
1..1 - codStatus : String
+ buscarNutrienteAlimento () : void + buscarNutriente (String codTipoNutriente) : void + buscar (String codTipo) : int
ContieneDatosDe - numOrden : String
- numNotaEntrega : String 1..1
Situa
- fechaNotaEntrega : String 1..1
- numFactura : String Agrupa
Ubicacion
- fechaFactura : String
- totalFactura : Double - codUbicacion : String GrupoAlimento
1..1 - descripcion : String
Proveedor + cargarOrdenesCompra () : void - codGrupo : String
Pertenece OrdenCompra
1..1 + buscarRegistrosEntrada () : void + insertar () : int - descripcionGrupo : String
- codProveedor : String - numOrden : String EstaContenidaEn + crearRegistroEntrada () : void + actualizar () : int
- nombre : String + insertar () : void
- fechaOrden : String + cargarStatusEntrada () : void + eliminar () : int
+ actualizar () : void
+ buscarProveedores () : void - montoTotal : Double + buscarRegistroEntrada (String numEntrada) : void + buscarUbicacion () : int
- codProveedor : String + eliminar () : void
+ buscarProveedor (String codProveedor) : void 1..1 + cargarDetalleEntradaArticulo () : void + buscar (String codUbicacion) : int
+ buscarGrupoAlimento () : void
Contiene + buscarOrdenesCompra () : void + cargarFormulario () : void
+ buscar (String codGrupo) : void
+ buscarOrdenCompra (String numOrden) : void + validar () : void
+ actualizarRegistroEntrada () : void
+ generarReporteRegistroEntrada () : void
375
Semana
codigoSemana Variable characters (254)
numeroSemana Variable characters (254)
descripcion Variable characters (254)
AccesoComensal
control Variable characters (254)
numeroAcceso Variable characters (254)
cedula Variable characters (254)
codPlanificacion Variable characters (254) Corresponde
Agrupa
Association_26
EsUtilizadoEn
Tiene
Estudiante
cedula Variable characters (254)
ReporteCostos
nombres Variable characters (254)
fecha Variable characters (254) apellidos Variable characters (254)
mes Variable characters (254) DetalleSolicitud
anio Variable characters (254) Corresponde
codDetalle Variable characters (254)
codTipo Variable characters (254) numSolicitud Variable characters (254)
Association_45 Association_27
Tiene fechaEvento Variable characters (254)
Pertenece codTipoMenu Variable characters (254)
numComensales Integer
EsTurnoDe
Association_46 Compone
Pertenece
Utiliza TipoMenu
Genera EsTurnoDe
Association_22 codTipoMenu Variable characters (254)
Planificacion Posee
descripcionTipoMenu Variable characters (254)
codPlanificacion Variable characters (254)
TipoReporte Agrupa fecha Variable characters (254)
estimadoComensales Variable characters (254) Agrupa
codTipo Variable characters (254) Representa
codMenu Variable characters (254) Contiene
codTipoMenu Variable characters (254)
codigoSemana Variable characters (254)
especial Variable characters (254) Association_10
Association_21
Conforma
(D) Association_29
Solicita Consta
Genera Menu
(D)
(D) codMenu Variable characters (254) Pertenece
descripcionMenu Variable characters (254)
Association_49 codTipoMenu Variable characters (254)
Consta
Corresponde Association_16
Association_24 StatusSolicitud
InsumoRequeridoMenu Compone EsEstadoDe
Contiene
codStatus Variable characters (254)
SalidaArticulosAlmacen id Integer
codInsumo Variable characters (254)
numSalida Variable characters (254)
codMenu Variable characters (254)
fechaSalida Variable characters (254) Association_17 SolicitudServicio Association_30
cantidadAjustada Number
responsable Variable characters (254)
numSolicitud Variable characters (254)
fechaSolicitud Variable characters (254)
Tiene
Association_23 codStatus Variable characters (254)
EsRepresentadoPor idSolicitante Variable characters (254)
EsGeneradoDe
Tiene descripcionEvento Variable characters (254)
Contiene
(D)
PedidoInsumo observacion Variable characters (254)
id Integer
codInsumo Variable characters (254) EsRepresentadoPor
EsElaboradoPor
TipoMenuInsumo
cantidad Number
Contiene codTipoMenu Variable characters (254)
Utiliza
Association_20
Association_15
TipoUsuario
Conforma Agrupa codUsuario Variable characters (254)

Compone
Representa descripcion Variable characters (254)
DetalleSalidaArticulo Existe EsUtilizadoEn pagina Variable characters (254)
codDetalle Variable characters (254) InsumoRequeridoPlanificacion
numSalida Variable characters (254) Insumo
id Integer Elabora
codExistencia Variable characters (254) TipoInsumo Association_32
ContieneSalidaDe codInsumo Variable characters (254) EsRepresentadoPor Representa codInsumo Variable characters (254) Association_8 Agrupa
cantidadSaliente Number
codPlanificacion Variable characters (254) descripcion Variable characters (254) codTipoInsumo Variable characters (254)
precioSalida Number Pertenece Usuario
cantidad Number codUm Variable characters (254) descripcion Variable characters (254)
Association_19
codTipoInsumo Variable characters (254) id Integer
alimento Variable characters (254) clave Variable characters (254) Pertenece
SeRealizanEn usuario Variable characters (254)
codUsuario Variable characters (254)
AjusteExistencia nombres Variable characters (254)
Tiene
Tiene
numAjuste Variable characters (254) Cambia apellidos Variable characters (254)
Association_40
numSalida Variable characters (254) TienePropiedadDe Association_9 cargo Variable characters (254)
Pertenece codExistencia Variable characters (254) email Variable characters (254)
cantidadAjustada Number
codTipoAjuste Variable characters (254)
Association_44 observacion Variable characters (254) Association_43 Association_33 Corresponde
SeEncuentraEn
(D)
Um
TipoAjuste EsAjustadaPor
Agrupa (D) codUm Variable characters (254) Corresponde
codTipoAjuste Variable characters (254) ExistenciaArticulo Association_6
descripcionUm Variable characters (254)
descripcion Variable characters (254) codExistencia Variable characters (254) Correponde
SeEncuentraEn codUbicacion Variable characters (254)
DetalleEntradaArticulo (D) existenciaMaxima Number
ContieneEntradaDe
existenciaActual Number
codDetalle Variable characters (254) EsPropiedadDe
precioUnitario Number
numEntrada Variable characters (254) Association_14
Association_35
codExistencia Variable characters (254)
cantidadEntrante Number Alimento
precioEntrada Number EstaSituadoEn
StatusEntrada codInsumo Variable characters (254) EstaCompuestoDe
codStatusEntrada Variable characters (254) peso Number TipoNutriente
Tiene
descripcion Variable characters (254) codGrupo Variable characters (254)
codTipoNutriente Variable characters (254)
Conforma Association_11
EsEstadoDe descripcionTipoNutriente Variable characters (254)
Agrupa
Nutriente
Pertenece NutrienteAlimento
codNutriente Variable characters (254) Association_13
Association_34 EsComposicionDe id Integer descripcion Variable characters (254)
Association_12
Association_36 codInsumo Variable characters (254) codUm Variable characters (254) Pertenece
codNutriente Variable characters (254)
Association_37 EsRepresentadoPor Representa codTipoNutriente Variable characters (254)
cantidad Number
Proveedor Association_7
Pertenece Contiene
codProveedor Variable characters (254) (D)
nombre Variable characters (254) EntradaArticulosAlmacen
Posee Situa
numEntrada Variable characters (254)
Association_38 (D)
codStatus Variable characters (254)
numOrden Variable characters (254)
numNotaEntrega Variable characters (254) Ubicacion Agrupa
Contiene ContieneDatosDe fechaNotaEntrega Variable characters (254)
codUbicacion Variable characters (254)
numFactura Variable characters (254) GrupoAlimento
fechaFactura Variable characters (254)
OrdenCompra EstaContenidaEn totalFactura Number codGrupo Variable characters (254)
numOrden Variable characters (254) (D) descripcionGrupo Variable characters (254)
fechaOrden Variable characters (254) Association_39
montoTotal Number
codProveedor Variable characters (254)
376
Semana
codigoSemana varchar(254)
numeroSemana varchar(254)
descripcion varchar(254)
AccesoComensal
control varchar(254)
numeroAcceso varchar(254)
Agrupa cedula varchar(254) Corresponde
codPlanificacion varchar(254)
EsUtilizadoEn
FK_ACCESOCO_ASSOCIATI_ESTUDIAN
Estudiante
Tiene cedula varchar(254)
FK_ACCESOCO_ASSOCIATI_PLANIFIC nombres varchar(254)
FK_PLANIFIC_ASSOCIATI_SEMANA
apellidos varchar(254)
DetalleSolicitud
ReporteCostos Corresponde Tiene codDetalle varchar(254)
Pertenece fecha varchar(254) numSolicitud varchar(254)
mes varchar(254) fechaEvento varchar(254)
FK_DETALLES_ASSOCIATI_TIPOMENU
anio varchar(254) codTipoMenu varchar(254)
codTipo varchar(254) TipoMenu numComensales integer
FK_REPORTEC_ASSOCIATI_PLANIFIC EsTurnoDe
Utiliza codTipoMenu varchar(254) EsTurnoDe
FK_REPORTEC_ASSOCIATI_TIPOREPO Pertenece Compone
FK_PLANIFIC_ASSOCIATI_TIPOMENU descripcionTipoMenu varchar(254)
Planificacion
Posee
codPlanificacion varchar(254) Agrupa Representa
Genera
TipoReporte fecha varchar(254)
Agrupa
codTipo varchar(254) estimadoComensales varchar(254)
descripcion varchar(254) codMenu varchar(254) Contiene
codTipoMenu varchar(254) FK_MENU_ASSOCIATI_TIPOMENU
codigoSemana varchar(254)
Solicita
especial varchar(254) FK_PLANIFIC_ASSOCIATI_MENU
Genera Menu FK_DETALLES_ASSOCIATI_SOLICITU

Conforma
Consta Pertenece
codMenu varchar(254)
descripcionMenu varchar(254)
FK_SALIDAAR_ASSOCIATI_PLANIFIC codTipoMenu varchar(254)
Consta
FK_TIPOMENU_ASSOCIATI_TIPOMENU StatusSolicitud
FK_PEDIDOIN_ASSOCIATI_PLANIFIC codStatus varchar(254)
EsEstadoDe descripcion varchar(254)
Corresponde Compone
InsumoRequeridoMenu
SalidaArticulosAlmacen id integer FK_INSUMORE_ASSOCIATI_MENU
Contiene
codInsumo varchar(254)
numSalida varchar(254)
codMenu varchar(254) FK_SOLICITU_ASSOCIATI_STATUSSO
fechaSalida varchar(254) SolicitudServicio
cantidadAjustada numeric
responsable varchar(254) numSolicitud varchar(254)
codPlanificacion varchar(254)
EsRepresentadoPor fechaSolicitud varchar(254)
FK_INSUMORE_ASSOCIATI_PLANIFIC codStatus varchar(254)
Tiene Contiene EsGeneradoDe Tiene
EsRepresentadoPor idSolicitante varchar(254)
PedidoInsumo descripcionEvento varchar(254)
id integer TipoMenuInsumo observacion varchar(254)
codInsumo varchar(254) codInsumo varchar(254)
codPlanificacion varchar(254) EsElaboradoPor
codTipoMenu varchar(254)
cantidad numeric
Contiene Utiliza
FK_DETALLES_ASSOCIATI_SALIDAAR
FK_INSUMORE_ASSOCIATI_INSUMO
FK_INSUMO_ASSOCIATI_PEDIDOIN FK_TIPOMENU_ASSOCIATI_INSUMO
FK_AJUSTEEX_ASSOCIATI_SALIDAAR FK_SOLICITU_ASSOCIATI_USUARIO
Agrupa TipoUsuario
Conforma codUsuario varchar(254)
descripcion varchar(254)
DetalleSalidaArticulo
Representa pagina varchar(254)
Compone EsUtilizadoEn
codDetalle varchar(254) Existe
numSalida varchar(254) InsumoRequeridoPlanificacion
ContieneSalidaDe Agrupa
codExistencia varchar(254) Insumo TipoInsumo FK_USUARIO_ASSOCIATI_TIPOUSUA
cantidadSaliente numeric id integer FK_INSUMORE_ASSOCIATI_INSUMO
codInsumo varchar(254) Pertenece codTipoInsumo varchar(254) Elabora
precioSalida numeric codInsumo varchar(254)
codPlanificacion varchar(254) EsRepresentadoPor descripcion varchar(254) FK_INSUMO_ASSOCIATI_TIPOINSU descripcion varchar(254)
Representa Usuario
cantidad numeric codUm varchar(254)
codTipoInsumo varchar(254) id integer
alimento varchar(254) Tiene Pertenece
clave varchar(254)
SeRealizanEn usuario varchar(254)
Tiene
codUsuario varchar(254)
Cambia TienePropiedadDe nombres varchar(254)
AjusteExistencia FK_DETALLES_ASSOCIATI_EXISTENC
apellidos varchar(254)
numAjuste varchar(254) FK_INSUMO_ASSOCIATI_UM
cargo varchar(254)
Pertenece numSalida varchar(254)
email varchar(254)
codExistencia varchar(254)
cantidadAjustada numeric
FK_EXISTENC_ASSOCIATI_INSUMO
FK_AJUSTEEX_ASSOCIATI_TIPOAJUS codTipoAjuste varchar(254) FK_AJUSTEEX_ASSOCIATI_EXISTENC
observacion varchar(254) Corresponde
TipoAjuste SeEncuentraEn Um
FK_INSUMO_ASSOCIATI_ALIMENTO Corresponde
codTipoAjuste varchar(254) Agrupa EsAjustadaPor codUm varchar(254)
ExistenciaArticulo
descripcion varchar(254) descripcionUm varchar(254)
codUbicacion varchar(254)
SeEncuentraEn existenciaMaxima numeric
existenciaActual numeric Correponde
EsPropiedadDe
precioUnitario numeric FK_NUTRIENT_ASSOCIATI_UM
FK_DETALLEE_ASSOCIATI_EXISTENC
Alimento
EstaSituadoEn
DetalleEntradaArticulo EstaCompuestoDe
codDetalle varchar(254) peso numeric
ContieneEntradaDe Tiene
numEntrada varchar(254) codGrupo varchar(254)
cantidadEntrante numeric Pertenece FK_NUTRIENT_ASSOCIATI_ALIMENTO Nutriente
precioEntrada numeric NutrienteAlimento codNutriente varchar(254)
Representa descripcion varchar(254) Pertenece
Conforma FK_EXISTENC_ASSOCIATI_UBICACIO id integer EsRepresentadoPor
EsComposicionDe codUm varchar(254)
codNutriente varchar(254) codTipoNutriente varchar(254)
FK_NUTRIENT_ASSOCIATI_NUTRIENT FK_NUTRIENT_ASSOCIATI_TIPONUTR
StatusEntrada cantidad numeric
EsEstadoDe TipoNutriente
codStatusEntrada varchar(254) FK_ALIMENTO_ASSOCIATI_GRUPOALI
descripcion varchar(254) Agrupa codTipoNutriente varchar(254)
FK_DETALLEE_ASSOCIATI_ENTRADAA descripcionTipoNutriente varchar(254)
Situa
FK_ENTRADAA_ASSOCIATI_STATUSEN
Agrupa
Ubicacion
Proveedor
codUbicacion varchar(254) GrupoAlimento
codProveedor varchar(254) Posee Contiene descripcion varchar(254)
Pertenece codGrupo varchar(254)
nombre varchar(254)
EntradaArticulosAlmacen descripcionGrupo varchar(254)
numEntrada varchar(254)
codStatus varchar(254)
FK_ORDENCOM_ASSOCIATI_PROVEEDO numOrden varchar(254)
ContieneDatosDe numNotaEntrega varchar(254)
fechaNotaEntrega varchar(254)
FK_ENTRADAA_ASSOCIATI_ORDENCOM numFactura varchar(254)
OrdenCompra
fechaFactura varchar(254)
Contiene numOrden varchar(254) totalFactura numeric
fechaOrden varchar(254) EstaContenidaEn
montoTotal numeric
codProveedor varchar(254)
377
378

Tesis Luis Farias - Comedor

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Tesis Luis Farias - Comedor

Hochgeladen von

Copyright:

Verfügbare Formate

UNIVERSIDAD DE ORIENTE

SISTEMA WEB PARA LA PLANIFICACION Y CONTROL DEL SERVICIO

Informe de Pasantas de Grado presentado ante la Comisin de Trabajos de Grado,

Br. Luis F. Farias A.

Maturn, Enero de 2010

En mi carcter de Asesor Laboral del trabajo presentado por el Bachiller

Ing. Jess Chaparro

En mi carcter de Asesor Acadmico del trabajo presentado por el Bachiller

Ing. Rosngela Garca

Quienes suscriben, Miembros del jurado evaluador designados por la

Este Trabajo de Grado se lo dedico a mis padres Susana Aguilarte y Vicente

SISTEMA WEB PARA LA PLANIFICACION Y CONTROL DEL SERVICIO

Autor: Farias A. Luis F. CI: 17.243.047

El presente trabajo de investigacin tiene como propsito principal el desarrollar

ACTA DE EVALUACIN ..........................................................................................ii

ACTA DE EVALUACIN .........................................................................................iii

LISTA DE FIGURAS ..................................................................................................xi

LISTA DE CUADROS ...............................................................................................xii

LISTA DE FORMULAS ...........................................................................................xvi

CONTEXTO ORGANIZACIONAL ............................................................................ 3

EL PROBLEMA Y SUS GENERALIDADES........................................................... 19

CAPITULO III ............................................................................................................ 28

CAPITULO IV.......................................................................................................... 101

MARCO METODOLGICO................................................................................... 101

CAPITULO V ........................................................................................................... 112

CONCLUSIONES .................................................................................................... 347

RECOMENDACIONES ........................................................................................... 349

BIBLIOGRAFA ...................................................................................................... 351

ANEXOS .................................................................................................................. 357

Figura 1. Estructura Organizativa de la Universidad de Oriente Ncleo Monagas. ..... 9

Cuadro 1. Tipo de Relaciones entre Clases................................................................. 57

Diagrama 1. Plan de Fase.......................................................................................... 118

Pantalla 1. Autenticar Usuario. ................................................................................. 194

Frmula 1. Frmula de Promedio Mvil. ................................................................. 230

Anexo 1. Forma Men y Alimentos Requeridos. ..................................................... 358

En la actualidad, el uso de los sistemas de informacin para la administracin,

Dentro de las universidades, y especficamente en la Universidad de Oriente,

Para la realizacin de este proyecto se utilizaron ciertos mtodos y tcnicas de

El presente trabajo de grado est estructurado en cinco captulos, los cuales

Captulo I, contiene informacin de la empresa donde fue desarrollada la

Captulo II, contempla el planteamiento del problema, los objetivos de la

Captulo IV, presenta el marco metodolgico y en ella se describe la metodologa de

En el Capitulo V, se muestran los resultados obtenidos, luego de haber aplicado la

Finalmente, se presentan las conclusiones y recomendaciones obtenidas de la

1.1 Breve resea histrica de la Universidad de Oriente

La Universidad de Oriente (UDO) fue creada el 21 de noviembre de 1958,

Inicia sus actividades en Cuman el 12 de febrero de 1960 con 120 bachilleres

En Octubre de 1961, se instala el Ncleo de Monagas con la Escuela de

En su concepcin la Universidad de Oriente se define como un sistema de

La sede principal de la UDO est situada en la ciudad de Cuman, Estado

Administrativamente la autoridad mxima es el Consejo Universitario,

1.2 Universidad de Oriente Ncleo de Monagas

1.2.1 Resea histrica

El Ncleo de Monagas inicia sus actividades el 12 de febrero de 1962, cuando

En febrero de 1968, la Escuela de Ingeniera de Petrleo fue trasladada al

En enero de 1974, se establece la Unidad de Estudios Bsicos, en las

La dinmica del desarrollo regional, que haba determinado una creciente

De esta manera, en sintona con la dinmica del desarrollo regional, el 21 de

Asimismo, en 1993, se abre la licenciatura de Tecnologa de los Alimentos,

La infraestructura fsica del Ncleo de Monagas tiene su sede principal en el

En las edificaciones de Juanico, antigua sede de los Cursos Bsicos, funcionan

La Universidad de Oriente reafirmar su compromiso de ser el centro de