TesisLuisfarias

UNIVERSIDAD DE ORIENTE NÚCLEO DE MONAGAS

INGENIERIA DE SISTEMAS COMISIÓN DE TRABAJO DE GRADO MATURÍN / MONAGAS / VENEZUELA

SISTEMA WEB PARA LA PLANIFICACION Y CONTROL DEL SER VICIO DE ALIMENTACION PRESTADO POR EL COMEDOR UNIVERSITAR IO

DE LA UNIVERSIDAD DE ORIENTE NUCLEO DE MONAGAS.

Informe de Pasantías de Grado presentado ante la Comisión de Trabajos de Grado, como requisito para optar al título de Ingeniero en Sistemas.

Maturín, Enero de 2010

Br. Luis F. Farias A.

C.I: 17.243.047

Tutor Académico: Ing. Rosángela García

Tutor Laboral: Ing. Jesús Chaparro

ii


INGENIERÍA DE SISTEMAS COMISIÓN DE TRABAJOS DE GRADO MATURÍN / MONAGAS / VENEZUELA

ACTA DE EVALUACIÓN

En mi carácter de Asesor Laboral del trabajo presentado por el Bachiller

FARIAS AGUILARTE LUIS FERNANDO portador de la cédula de identidad

número: 17.243.047, para optar al grado académico 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 D E

MONAGAS , considero que dicho trabajo reúne los requerimientos y méritos

suficientes para ser sometido a la evaluación por parte del jurado examinador.

En la ciudad de Maturín a los veintinueve días del mes de Julio de dos mil

nueve.

Ing. Jesús Chaparro

C.I. 4.526.369

iii


INGENIERÍA DE SISTEMAS COMISIÓN DE TRABAJOS DE GRADO MATURÍN / MONAGAS / VENEZUELA

ACTA DE EVALUACIÓN

En mi carácter de Asesor Académico del trabajo presentado por el Bachiller

FARIAS AGUILARTE. LUIS FERNANDO portador de la cédula de identidad

número: 17.243.047, para optar al grado académico 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 D E

MONAGAS , considero que dicho trabajo reúne los requerimientos y méritos

suficientes para ser sometido a la evaluación por parte del jurado examinador.

En la ciudad de Maturín a los veintinueve días del mes de Julio de dos mil

nueve.

Ing. Rosángela García

C.I. 8.977.359

iv

UNIVERSIDAD DE ORIENTE

NÚCLEO DE MONAGAS INGENIERÍA DE SISTEMAS

COMISIÓN DE TRABAJOS DE GRADO MATURÍN / MONAGAS / VENEZUELA

APROBACIÓN

Quienes suscriben, Miembros del jurado evaluador designados por la

comisión de Trabajos de Grado de la Escuela de Ingeniería de Sistemas de la

Universidad de Oriente Núcleo Monagas, para examinar el Trabajo de Grado

modalidad pasantía presentado por el Bachiller: FARIAS AGUILARTE. LUIS

FERNANDO, portador de la cédula de identidad número: 17.243.047 Titulado:

SISTEMA WEB PARA LA PLANIFICACION Y CONTROL DEL SER VICIO

DE ALIMENTACION PRESTADO POR EL COMEDOR UNIVERSITAR IO

DE LA UNIVERSIDAD DE ORIENTE NUCLEO DE MONAGAS , el cual es

presentado para optar al grado académico 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 Maturín a los veintinueve días del mes de Julio del dos mil

nueve.

_______________________ ______________________ Ing. Beatriz Pérez Ing. Cristhian Ronceros C.I. C.I.

v

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. También se lo dedico a mis hermanos, Fernando y Daniel.

Luis F. Farias A.

vi

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 formación profesional.

A mi asesora académica, Ing. Rosángela García, por brindarme su apoyo,

conocimientos y orientación a lo largo del desarrollo del proyecto.

Al Ing. Jesús Chaparro (Asesor Laboral), por guiarme y por su colaboración

en la realización de este proyecto.

A todo el personal del Centro de Computación, y en especial a Ennio

Villaroel, Yhuanailys Nuñez y a Luis Figueroa, por ser tan excelentes personas, por

aconsejarme, motivarme, ayudarme e instruirme en muchos aspectos importantes del

proyecto.

A mis compañeros de pasantía, por animarnos mutuamente y por apoyarnos

para alcanzar esta meta tan anhelada.

Al personal del Comedor Universitario, por brindar toda la colaboración

necesaria para el desarrollo de este proyecto.

A mis compañeros 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.

vii

UNIVERSIDAD DE ORIENTE

NÚCLEO DE MONAGAS INGENIERIA DE SISTEMAS

COMISIÓN DE TRABAJO DE GRADO MATURÍN / MONAGAS / VENEZUELA

SISTEMA WEB PARA LA PLANIFICACION Y CONTROL DEL SER VICIO DE ALIMENTACION PRESTADO POR EL COMEDOR UNIVERSITAR IO


Autor: Farias A. Luis F. CI: 17.243.047

RESUMEN

El presente trabajo de investigación tiene como propósito principal el desarrollar un sistema Web para la Planificación y Control del servicio de alimentación prestado por el comedor universitario de la Universidad de Oriente Núcleo de Monagas. Para ello fue necesario estudiar el funcionamiento actual de dicha área, y determinar la problemática que presentaba en la prestación del servicio de alimentación; para luego, definir los requerimientos de información del sistema en base a dicha problemática y a las necesidades del personal que labora en dicho comedor universitario; procediéndose después a diseñar una arquitectura sólida que cumpliera con todos los requerimientos establecidos, hasta finalmente obtener un prototipo inicial de la aplicación, de acuerdo a esa arquitectura diseñada. Dicho trabajo siguió un tipo de investigación proyectiva, con un nivel comprensivo y un diseño de campo; empleándose como técnicas de recolección de los datos la revisión documental, la entrevista no estructurada y la observación directa, con el fin de extraer la información del lugar objeto de estudio; mientras que la técnica de análisis de datos utilizada fue la de análisis de contenido. Para el logro de los objetivos planteados, se siguió como guía de desarrollo de software la metodología RUP con la ayuda de la herramienta de modelado UML. De igual manera, se pudo concluir que con el desarrollo y futura implantación del sistema se agilizará el proceso de planificación alimentaria, pudiendo considerar al momento de su elaboración la demanda estimada promedio; permitirá controlar el acceso de comensales al área de servicio y la entrada/salida de insumos del almacén; y además, traerá consigo ahorro significativo de tiempo en la generación de reportes de costos. Palabras Claves: Ingeniería, Desarrollo, Sistema, Web, Comedor Universitario.

viii

INDICE GENERAL

ACTA DE EVALUACIÓN .......................................................................................... ii

ACTA DE EVALUACIÓN .........................................................................................iii

APROBACIÓN............................................................................................................ 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

INTRODUCCIÓN ........................................................................................................ 1

CAPITULO I................................................................................................................. 3

CONTEXTO ORGANIZACIONAL ............................................................................ 3

1.1 Breve reseña histórica de la Universidad de Oriente ........................................ 3

1.2 Universidad de Oriente – Núcleo de Monagas ................................................... 4 1.2.1 Reseña histórica ........................................................................................... 4 1.2.2 Visión ........................................................................................................... 7 1.2.3 Misión .......................................................................................................... 7 1.2.4 Objetivos ...................................................................................................... 8 1.2.5 Estructura Organizativa................................................................................ 8

1.3 Centro de Computación – Núcleo de Monagas................................................. 10

ix

1.3.1 Visión ......................................................................................................... 10 1.3.2 Misión ........................................................................................................ 10 1.3.3 Objetivos .................................................................................................... 10 1.3.4 Funciones ................................................................................................... 11 1.3.5 Estructura Organizativa.............................................................................. 12 1.3.6 Sección de Programas y Proyectos ............................................................ 13

1.4 Comedor Universitario de la UDO-Núcleo 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 Investigación ............................................................................ 24 2.2.1 Objetivo General ........................................................................................ 24 2.2.2 Objetivos Específicos................................................................................. 24

2.3 Justificación de la Investigación ....................................................................... 24

2.4 Alcance de la Investigación .............................................................................. 27

CAPITULO III ............................................................................................................ 28

MARCO REFERENCIAL.......................................................................................... 28

3.1 Antecedentes de la Investigación...................................................................... 28

3.2 Bases Teóricas................................................................................................... 30 3.2.1 Metodología RUP ...................................................................................... 30 3.2.2 Lenguaje Unificado de Modelado.............................................................. 43 3.2.3 Tarjetas CRC (clase, responsabilidad y colaboración) .............................. 66 3.2.4 Entregables de RUP ................................................................................... 68 3.2.5 Sistema de Inventario Permanente ............................................................. 74 3.2.6 Pronósticos de demanda............................................................................. 79 3.2.7 Sistemas de información ............................................................................ 81 3.2.8 Aplicación WEB ........................................................................................ 83 3.2.9 HTML ........................................................................................................ 85 3.2.10 Tecnologías de Programación del lado del cliente................................... 87 3.2.11 Tecnologías de Programación 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

x

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 Definición de Términos..................................................................................... 99

CAPITULO IV.......................................................................................................... 101

MARCO METODOLÓGICO................................................................................... 101

4.1 Tipo y Nivel de la Investigación. .................................................................... 101

4.2 Diseño de la Investigación .............................................................................. 102

4.3 Población y Muestra........................................................................................ 103

4.4 Técnicas e Instrumentos de Recolección de Datos. ........................................ 104

4.5 Técnicas de Análisis de Datos. ....................................................................... 105

4.6 Diseño Operativo. ........................................................................................... 106

CAPITULO V ........................................................................................................... 112

RESULTADOS......................................................................................................... 112

5.1 Etapa I. Estudio del Negocio........................................................................... 114

5.2 Etapa II. Diseño de la Arquitectura................................................................. 188

5.3 Etapa III. Construcción del Software. .............................................................316

5.4 Análisis Costo – Beneficio.............................................................................. 342 5.4.1 Costos....................................................................................................... 342 5.4.2 Beneficios................................................................................................. 344

CONCLUSIONES .................................................................................................... 347

RECOMENDACIONES........................................................................................... 349

BIBLIOGRAFÍA ...................................................................................................... 351

ANEXOS .................................................................................................................. 357

xi

LISTA DE FIGURAS

Figura 1. Estructura Organizativa de la Universidad de Oriente Núcleo Monagas. ..... 9

Figura 2. Estructura Organizativa del Centro de Computación. ................................. 12

Figura 3. Estructura Organizativa del Comedor de la UDO Núcleo Monagas........... 15

Figura 4. Los casos de uso integran el trabajo. ........................................................... 33

Figura 5. Evolución de la arquitectura del sistema..................................................... 35

Figura 6. Una iteración 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. Relación entre roles, actividades, artefactos..............................................41

Figura 11. Vista general de los elementos de UML.................................................... 46

Figura 12. Representación de una dependencia. .........................................................48

Figura 13. Representación de una asociación. ............................................................ 48

Figura 14. Representación de una generalización.......................................................49

Figura 15. Representación de una generalización.......................................................49

Figura 16. Arquitectura de un sistema software (UML 2.0). ...................................... 53

Figura 17. Clasificación de diagramas UML. ............................................................. 54

Figura 18. Representación de una clase. ..................................................................... 55 Figura 19. Relación entre clases.................................................................................. 56 Figura 20. Ejemplo Diagrama de despliegue. ............................................................. 58

Figura 21. Elementos Diagrama de casos de uso........................................................ 61

Figura 22. Línea de vida de un objeto......................................................................... 65 Figura 23. Activación 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 Básica de un documento HTML. ............................................. 86

Figura 29. Arquitectura del Producto........................................................................ 136 Figura 30. Representación 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 Planificación....................................................................... 310 Figura 36. Tarjeta CRC ExistenciaArticulo. ............................................................. 310

xii

LISTA DE CUADROS

Cuadro 1. Tipo de Relaciones entre Clases................................................................. 57

Cuadro 2. Elementos Diagrama de Actividad.............................................................60

Cuadro 3. Tabla Documentación 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. Posición 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 21. Identificador 003. ................................................................................... 144 Cuadro 22. Identificador 004. ................................................................................... 144 Cuadro 23. Identificador 005. ................................................................................... 145 Cuadro 24. Identificador 006. ................................................................................... 145 Cuadro 25. Identificador 007 .................................................................................... 146 Cuadro 26. Identificador 008. ................................................................................... 146 Cuadro 27. Identificador: 009. .................................................................................. 147 Cuadro 28. Identificador 010 .................................................................................... 147 Cuadro 29. Identificador 011 .................................................................................... 148 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. Disminución de tiempo en la generación del plan alimentario. ............. 345

Cuadro 35. Reducción de tiempo en la generación del Resumen de Costos. ........... 346

xiii

LISTA DE DIAGRAMAS

Diagrama 1. Plan de Fase.......................................................................................... 118 Diagrama 2. Segunda Iteración. ................................................................................ 119 Diagrama 3. Tercera Iteración................................................................................... 119 Diagrama 4. Cuarta Iteración. ................................................................................... 120 Diagrama 5. Quita Iteración...................................................................................... 120 Diagrama 6. Sexta Iteración...................................................................................... 121 Diagrama 7. Séptima Iteración.................................................................................. 121 Diagrama 8. Octava Iteración. .................................................................................. 122 Diagrama 9. Novena Iteración. ................................................................................. 122 Diagrama 10. Décima Iteración. ............................................................................... 123 Diagrama 11. Caso de uso General del Negocio....................................................... 151

Diagrama 12. Modelo de Dominio del Negocio. ...................................................... 153

Diagrama 13. Casos de Uso Planificar Menús.......................................................... 157

Diagrama 14. Diagrama de Actividad Planificar Menús. ......................................... 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 Menús Alimentarios.................................. 214

Diagrama 32. Diagrama de Secuencia Conformar Menús Alimentarios.................. 219

Diagrama 33. Casos de Uso Elaborar Planificación Alimentaria. ............................ 223

Diagrama 34. Diagrama de Secuencia Elaborar Planificación 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

xiv

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 Artículos en Almacén. ............... 268

Diagrama 46. Diagrama de Secuencia Registrar Entrada de Artículos en Almacén.272

Diagrama 47. Casos de Uso Registrar Salida de Artículos de Almacén................... 276

Diagrama 48. Diagrama de Secuencia Registrar Salida de Artículos de Almacén... 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 Físico..................................................................................... 313 Diagrama 54. Modelo de Base de Datos Relacional del Sistema. ............................ 314

Diagrama 55. Modelo de Despliegue........................................................................ 315

xv

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 Menús 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 Planificación Alimentaria Semanal......... 234

Pantalla 18. Ventana para Estimación de Comensales.............................................. 235

Pantalla 19. Ventana para Modificar Menú de la Planificación Alimentaria. .......... 235 Pantalla 20. Ventana para Incluir Insumos a la Planificación Alimentaria............... 236

Pantalla 21. Listado de Insumos Requeridos de la Planificación 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 Artículos en Almacén. .............................................. 266

Pantalla 28. Detalles de la Existencia de un Articulo en Almacén. .......................... 266

Pantalla 29. Bandeja de Registro de Entradas........................................................... 273

Pantalla 30. Registro de Entrada de Artículos al Almacén. ...................................... 274

Pantalla 31. Registro de Salida de Artículos de Almacén......................................... 282

Pantalla 32. Ventana de Ajuste de Existencia de Articulo........................................ 282

Pantalla 33. Reporte Control Diario de Costo........................................................... 290

Pantalla 34. Reporte Relación por Servicio y Número de Comensales. ................... 290

Pantalla 35. Reporte Relac. de alimentos., bebidas y otros recibidos por almacén. .291

Pantalla 36. Reporte Relación de alimentos y conexos entregados por almacén...... 291

Pantalla 37. Reporte Resumen Mensual de Costo. ................................................... 292

xvi

LISTA DE FORMULAS

Fórmula 1. Fórmula de Promedio Móvil. .................................................................230

xvii

LISTA DE ANEXOS

Anexo 1. Forma Menú y Alimentos Requeridos. ..................................................... 358 Anexo 2. Forma Mercancías 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 Almacén. ........................................................................ 364

1

INTRODUCCIÓN

En la actualidad, el uso de los sistemas de información para la administración,

procesamiento y distribución de la información en una organización, se hace cada vez

más indispensable. Pues estos sistemas permiten lograr ahorros significativos en

tiempo y mano de obra, debido a que automatizan tareas operativas de la

organización 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

implantación y uso del sistema de información.

Además se producen muchos otros beneficios por utilizar este tipo de sistemas

en la organización. Estos tienen impacto directo en la calidad de decisión, mejora la

comunicación, produce reducción de los costos, incrementa la productividad, permite

el manejo eficiente de la información e integridad de la misma, entre otros.

Dentro de las universidades, y específicamente 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

investigación se plantea el desarrollo de un sistema de información para el área del

comedor universitario, que permita la planificación y el control del servicio de

alimentación ofrecido por la UDO-Monagas, con el fin de proveer información veraz,

rápida y actualizada de los procesos que allí se manejan para garantizar una efectiva

toma de decisiones.

Para la realización de este proyecto se utilizaron ciertos métodos y técnicas de

la Ingeniería de Software, que sirvieron de apoyo y permitieron llevar a cabo de

manera eficiente y ordenada el desarrollo del nuevo sistema informático. Como

2

método de desarrollo, se aplicó la Metodología RUP (Rational Unified Process) y

como herramienta el Lenguaje Unificado de Modelado UML.

El presente trabajo de grado está estructurado en cinco capítulos, los cuales

contemplan lo siguiente:

Capítulo I, contiene información de la empresa donde fue desarrollada la

investigación, es decir el contexto organizacional, detallando su misión, visión,

objetivos, estructura organizativa, etc.

Capítulo II, contempla el planteamiento del problema, los objetivos de la

investigación, la justificación y el alcance.

Capítulo III, constituido por los antecedentes que apoyan la presente investigación y

las bases teóricas que le dan sustento al trabajo investigativo.

Capítulo IV, presenta el marco metodológico y en ella se describe la metodología de

la investigación y la metodología de área aplicada para el desarrollo del trabajo.

Contiene tipo y nivel de investigación, población y muestra, técnicas e instrumentos

de recolección de datos, técnicas de análisis de datos y diseño Operativo.

En el Capitulo V, se muestran los resultados obtenidos, luego de haber aplicado la

metodología, siguiendo el diseño operativo planteado.

Finalmente, se presentan las conclusiones y recomendaciones obtenidas de la

investigación, así como la bibliografía consultada y los anexos que complementan el

trabajo.

3

CAPITULO I

CONTEXTO ORGANIZACIONAL

1.1 Breve reseña histórica 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 Educación el Dr. Rafael Pizani, bajo la

conducción de su Rector fundador el Dr. Luis Manuel Peñalver.

Inicia sus actividades en Cumaná el 12 de febrero de 1960 con 120 bachilleres

en la Unidad de Cursos Básicos y a la vez, se programan las carreras de Matemática,

Física, Química y Biología. Posteriormente, el 29 de mayo de ese mismo año, la

UDO es inaugurada oficialmente por el Presidente de la República Rómulo

Betancourt, en un acto solemne donde también pronunciaron discursos el escritor

Rómulo Gallegos; el Ministro de Educación para ese entonces Rafael Pizani y el

Presidente de la Comisión Organizadora Luis Manuel Peñalver.

En Octubre de 1961, se instala el Núcleo de Monagas con la Escuela de

Ingeniería Agronómica y Petróleo. En el Núcleo de Bolívar se iniciaron las

actividades en Enero de 1962 con la Escuela de Medicina y la Escuela de Geología y

Minas, en el Núcleo de Anzoátegui comenzaron el 9 de enero de 1963 con la Escuela

de Ingeniería y Química, y en el Núcleo de Nueva Esparta se iniciaron los Cursos

Básicos el 21 de Enero de 1969.

En su concepción la Universidad de Oriente se define como un sistema de

educación Superior al servicio del país con objetivos comunes a las demás

4

universidades venezolanas y del mundo. No obstante, es única en su género,

experimental y autónoma, innovadora en la creación de la unidad profesional de

Cursos Básicos, la departamentalización, los lapsos semestrales, el sistema de

unidades de créditos, los cursos intensivos, etc., desarrollando investigación

científica, docencia y extensión 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 núcleos universitarios ubicados en los Estados Anzoátegui,

Bolívar, Monagas, Nueva Esparta, y Sucre; asumiendo así la responsabilidad de la

educación universitaria y ser el motor fundamental del desarrollo integral en toda la

región insular, nororiental y sur del país, en función de las condiciones, posibilidades

y tendencias de desarrollo de cada uno de los estados orientales donde funcionan.

Administrativamente la autoridad máxima es el Consejo Universitario,

formado por las autoridades rectorales, los Decanos de los cinco núcleos, cinco

representantes de los profesores, un representante estudiantil de cursos básicos, dos

representantes estudiantiles de los cursos profesionales, un representante del

Ministerio de Educación y un representante de los egresados, quienes tienen la

responsabilidad de asumir colegiadamente la orientación y gestión de la Universidad.

1.2 Universidad de Oriente – Núcleo de Monagas

1.2.1 Reseña histórica

El Núcleo 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 Ingeniería Agronómica y trece de Ingeniería de Petróleo, quienes habían

completado el curso básico en Cumaná. Las instalaciones del antiguo campo

petrolero de Jusepín, adquirido por la Universidad, mediante venta simbólica

5

realizada por la Creole Petroleum Corporation, sirven de asiento al proyecto

académico que comenzaba a echar raíces en el oriente venezolano, marcando el hito

más trascendental en el acontecer de la educación superior en la zona.

En febrero de 1968, la Escuela de Ingeniería de Petróleo fue trasladada al

Núcleo de Anzoátegui, 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 América latina), cuya creación había sido aprobada por el Consejo Directivo

Universitario, en abril de 1966. Así se consolida la más sólida estructura académica

regional en el campo de las ciencias agrícolas, respondiendo acertadamente a los

objetivos originarios que alentaron la creación del Núcleo de Monagas.

En enero de 1974, se establece la Unidad de Estudios Básicos, en las

edificaciones de lo que fue un colegio de religiosos, ubicadas en la Urb. Juanico, en

Maturín. Con la apertura de esta unidad, puede decirse que comienza la consolidación

académica del Núcleo, pero, al mismo tiempo, se inicia el proceso de masificación,

pues hasta esa fecha todos los estudiantes debían realizar sus cursos básicos en el

Núcleo de Sucre, en Cumaná.

La dinámica del desarrollo regional, que había determinado una creciente

demanda de profesionales, especialmente en el campo de la administración y la

gerencia, por el resurgimiento de la explotación petrolera, obligaron a rediseñar

estrategias en función de esa nueva realidad. Así, se despliega el abanico académico,

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

vocación de la tierra monaguense.

De esta manera, en sintonía con la dinámica 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 título respectivo.

6

Posteriormente, se abren las carreras de Administración Industrial y Contaduría

Pública. Estas tres disciplinas están hoy adscritas, como departamentos, a la Escuela

de Ciencias Sociales y Administrativas, establecida en el Núcleo el 23 de junio de

1998.

Asimismo, en 1993, se abre la licenciatura de Tecnología de los Alimentos,

adscrita a la Escuela de Zootecnia, y se restablece la Escuela de Ingeniería de

Petróleo, en diciembre de 1994. Más recientemente, en el primer semestre de 2002, se

apertura la carrera de Ingeniería de Sistemas, en respuesta a la demanda profesional

en esta especialidad, como consecuencia del desarrollo inusitado en el campo de la

informática y atendiendo a la creciente necesidad de servicios de asesoría en sistemas

administrativos y mejoramiento de procesos, tanto en el sector público como privado.

La infraestructura física del Núcleo de Monagas tiene su sede principal en el

campus Los Guaritos, en Maturín, 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 están concentrados los Cursos Básicos y las escuelas

profesionales que adscriben a las ocho carreras que conforman la oferta académica

del Núcleo; así como los diferentes servicios estudiantiles que dispensa la

Universidad.

En las edificaciones de Juanico, antigua sede de los Cursos Básicos, funcionan

el decanato, las coordinaciones académica y administrativa, dependencias

administrativas y demás oficinas regionales; así como el Centro de Estudios de

Postgrado, el Instituto de Investigaciones Agrícolas y Pecuarias, la Comisión de

Investigaciones, la Coordinación de Relaciones Interinstitucionales, la Delegación de

Información y Comunicación Corporativa, el Centro de Computación, la

Coordinación de Publicaciones y demás dependencias de asesoría y apoyo de la

institución.

7

1.2.2 Visión

La Universidad de Oriente reafirmará su compromiso de ser el centro de

estudio, análisis y producción de ideas necesarias para el desarrollo social, económico

y político del Oriente del País, capaz de desarrollar métodos y tecnología

innovadoras, de asegurar la calidad por medio de los sistemas eficientes de

planificación, evaluación y motivación.

La Universidad será una Institución cuyo ambiente estimule la creatividad y

productividad de todos sus miembros. Así mismo deberá ocupar una posición de

liderazgo en investigación y logros académicos. Con intención de situarse en un lugar

privilegiado en los sueños de cada miembro de la Comunidad Universitaria.

1.2.3 Misión

Formar profesionales del más alto nivel de calidad, profesionales que atiendan

problemas de su particular formación y competencia, bajo un alto espíritu de

solidaridad y compromiso social. Se trata de formar profesionales creativos, capaces

de destacarse en un mercado cada vez más competitivo con el mejoramiento de la

calidad de vida y con el desarrollo.

Mantener una permanente vinculación con sus egresados para su actualización

constante. Así mismo, permanecer en contacto con los sectores sociales y

productivos.

Brindar a sus trabajadores tanto, en la parte académica, administrativa y

estudiantil las mejores condiciones para que estos encuentren el éxito en el

desempeño de sus funciones. Mantener un clima de respeto mutuo, de libertad de

expresión, organización, de pluralidad de todas las corrientes de pensamiento, dentro

8

de un ambiente de responsabilidad y tolerancia a todas las ideas e igualmente estar

vinculada con su entorno.

1.2.4 Objetivos

1. Impartir Educación Superior Universitaria de la más alta calidad, con el fin de

obtener profesionales de excelencia.

2. Promover y desarrollar labores de investigación científico, humanística y

tecnológica, en las áreas y disciplinas en las que considere necesaria su

participación en relación a los problemas regionales y nacionales.

3. Desarrollar actividades de proyección social y extensión Universitaria.

4. Hacia la obtención de estos objetivos deben orientarse las actividades básicas

de la Universidad: Docencia, Investigación y Extensión.

1.2.5 Estructura Organizativa

Para el desempeño de sus funciones y para el logro de sus objetivos la

Universidad de Oriente Núcleo de Monagas se encuentra dividida tal como se

muestra en la Figura 1, p.9.

9

Consejo de Núcleo

Decano

Delegación de Bienestar y

Desarrollo Estudiantil

Servicio

Médico-Dental

Coordinación Académica

Actividades

Extra-

Académicas

Servicio

Social

OrientaciónDivulgación y

Publicaciones

Control de

Estudios

Coordinación

Servicio

Comunitario

Coordinación

de Postgrado

Comisión de

Curicula

Coordinación

Administrativa

Delegación de

Presupuesto

Delegación de

Finanzas

Comedor

Universitario

Sección

Contabilidad

Bienes

Nacionales

Delegación de

Personal

Nómina

Bienestar

Social

Centro de

Computación

Sección de

Compras

Clínica

Universitaria

Coordinación

de Servicios

Generales

Almacén

Archivo y

Correspondencia

Transporte

Vigilancia

Mantenimiento

Aseo y

Limpieza

Talleres

Formación y

Desarrollo de

Recursos

Humanos

Delegación de

Planificación

Delegación de

Extensión y

Cultura

Delegación de

Deporte

Delegación de

Planta Física

Asesoría

Jurídica

Biblioteca

Central

Oficina

Información y

Relaciones

Públicas

Tecnología

Educativa

Escuela de Ing.

De PetróleoEscuela de Ciencias

Sociales y Administrativas

Instituto de

Investigaciones

Agropecuarias

Unidad de Cursos

Básicos

Escuela de

Zootecnia

Escuela de

Agronomía

Departamento de

Producción e

Industria Animal

Programa

Tecnológico de

los Alimentos

Departamento de

Biología y

Saneamiento

Animal

Departamento de

Nutrición Animal

y Forraje

Departamento de

Agronomía

Departamento de

Ing. Agrícola

Departamento de

Economía

Agrícola

Departamento de

Invest. Sector

Agrícola

Departamento de

Invest. Sector

Ambiente y

Recursos Naturales

Departamento

Administrativo

Agro-Industrial

Departamento de

Humanidades

Departamento de

Ciencias

Sección de

Ingles

Sección de

Castellano

Sección de

Ciencias Sociales

Programa de

Ingeniería de

Sistemas

Sección de

Física

Sección de

Matemática

Sección de

Quimica

Departamento de

Gerencia de

Recursos Humanos

Departamento de

Administración

Industrial

Departamento de

Contaduría

Pública

Sección de

Recursos

Humanos y

Psicología

Sección de

Investigación

Informática

Sección de

Coordinación

Administrativa

Sección de

Administración

y Derecho

Sección de

Contabilidad y

Finanzas

Sección de

Economía y

Mercadeo

Sección de

ContabilidadSección de

Investigación

Sección de

Administración

Economía y

Legislación

Figura 1. Estructura Organizativa de la Universidad de Oriente Núcleo Monagas. Fuente: Delegación de Personal. (2009).

10

1.3 Centro de Computación – Núcleo de Monagas

El Centro de Computación, es una dependencia adscrita a la Coordinación

Administrativa del Núcleo Monagas de la Universidad de Oriente, proyectada en

materia de políticas que sustenten la promoción de una cultura de comunicación

electrónica y de servicios informáticos en el área académico-administrativa.

1.3.1 Visión

Ser un centro de Computación competitivo, líder a nivel nacional en todas las

áreas de nuestro interés, contando con el apoyo de un personal altamente capacitado

y estableciendo una plataforma tecnológica útil que satisfaga las necesidades del

sector docente, estudiantil y administrativo de la Universidad de Oriente – Núcleo

Monagas.

1.3.2 Misión

Coordinar y mantener una estructura integral óptima en las áreas, de

comunicación electrónica y servicios informáticos, mediante el diseño y desarrollo de

servicios de redes, software y soporte técnico, para fortalecer las actividades

académico - administrativa y contribuir al desarrollo tecnológico de la Universidad de

Oriente - Núcleo Monagas.

1.3.3 Objetivos

1. Diseñar y desarrollar aplicaciones con fines didácticos y administrativos.

2. Asesorar a las autoridades universitarias del núcleo sobre las innovaciones

tecnológicas relacionadas con la computación e informática y su impacto en

la organización.

11

3. Generar conocimientos en las diversas áreas de la computación y sistemas

mediante proyectos de investigación.

4. Ofrecer servicios a la comunidad local y regional en los rubros de análisis,

diseño y auditoria de sistemas de información, redes y adiestramiento de

personal.

5. Coordinar la aplicación de servicios informáticos a otras unidades

organizativas de la Universidad de Oriente.

6. Desarrollar los sistemas de información que permitan la automatización de la

gestión administrativa de la Universidad de Oriente – Núcleo Monagas.

7. Capacitar el recurso humano de la institución con la finalidad de asegurar el

manejo eficiente de los equipos computacionales disponibles en diferentes

unidades de la organización.

8. Evaluar y controlar la plataforma operativa del Centro de Computación.

1.3.4 Funciones

1. Desarrollar y mantener los sistemas de información orientados al proceso de

automatización de la gestión administrativa de la Institución.

2. Coordinar y supervisar el funcionamiento de las unidades que integren el

Centro de Computación.

3. Distribuir, según la capacidad productiva, las tareas del personal adscrito al

Centro de Computación.

4. Procesar lo relacionado con la nómina de pago, el área de contabilidad y

presupuesto.

5. Brindar de forma permanente soporte técnico a las unidades administrativas

del núcleo Monagas de la Universidad de Oriente.

6. Capacitar al personal de la Institución en el manejo eficiente de los equipos de

computación, a través de cursos, charlas y seminarios de actualización y

charlas.

12

7. Prestar asesoría en el área de computación y Teleinformática a aquellas

unidades que integran la estructura administrativa y académica de la

Universidad de Oriente.

8. Procesa toda la información necesaria para el departamento de Admisión y

Control de Estudio. Así mismo presta todos los servicios necesarios en los

procesos de inscripción, informes al CNU y estadísticas académicas.

9. El Centro puede atender solicitudes de aplicaciones para el análisis estadístico

de datos generados por las investigaciones que se realizan en el núcleo.


El Centro de Computación, para el ejercicio de sus funciones y el logro de sus

objetivos, se encuentra organizado tal como se muestra en la siguiente figura:

Secretaria

Valor

Agregado

Sección de

Soporte Técnico

Soporte

TécnicoDesarrollo

Sección de Programas

y Proyectos

SeguridadRedes

Jefatura

Figura 2. Estructura Organizativa del Centro de Computación. Fuente: Centro de Computación. (2009).

13

1.3.6 Sección de Programas y Proyectos

En la Figura 2, p.12 se puede apreciar que el Centro de Computación se

encuentra dividido en varias secciones, entre las cuales se encuentra la sección de

programas y proyectos. Esta, es la encargada de desarrollar e implementar sistemas

de información que permitan la automatización de los procesos relacionados con las

áreas administrativa, académica y de personal. Asistir a las distintas dependencias del

Núcleo Monagas, en la realización de proyectos informáticos. Mantener actualizadas

las herramientas de hardware y software relacionadas con el diseño, desarrollo e

implementación de sistemas informáticos en el Núcleo. 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-Núcleo de Monagas

El comedor universitario de la Universidad de Oriente Núcleo de Monagas es

una unidad de trabajo, cuyo objetivo fundamental es proveer una alimentación sana y

balanceada a los estudiantes y trabajadores de la institución. Su función es obtener los

mejores resultados en la prestación de los servicios de alimentación, a través del

cuidadoso manejo de los fondos destinados a ese fin.

Esta dependencia comienza sus actividades en el años de 1965 en las

instalaciones de Jusepín, prestando el servicio de alimentación a la comunidad

universitaria de dicho núcleo que para esa época comprendía las escuelas de

Agronomía y Zootecnia. Luego, de acuerdo con el desarrollo del núcleo en 1968 se

puso en funcionamiento, junto con el establecimiento de la Unidad de Estudios

Básicos, una segunda área operativa en la sede del núcleo ubicada en la urbanización

Juanico de la ciudad de Maturín. Para el año de 1990 se fusionaron las dos áreas en su

actual infraestructura ubicada en el edificio Centro Comunal Estudiantil en el campus

Los Guaritos del núcleo en referencia.

14

En dicha infraestructura física, específicamente en el nivel planta baja del

mencionado edificio, se desarrollan las actividades operativas y de prestación 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 alimentación. 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 administración del servicio.


De acuerdo al manual de procedimientos y organización (1976), el comedor

universitario estará bajo la dirección 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 Núcleo de Monagas

(Figura 3, p.15).

15

Coordinación

Administrativa

Consejo de

Núcleo Decano

Delegación de

Finanzas

Administración

del Comedor

Cajero Secretaria

Dietista Almacenista Jefe de Cocina Personal

Figura 3. Estructura Organizativa del Comedor de la UDO Núcleo 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.

16

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 aplicación de las disposiciones relativas al

trabajo que les concierne.

4. Llevar el control de compras de equipos y reparación 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 Delegación 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 administración de su personal.

Dietista:

1. Coordinar y supervisar las actividades del servicio a su cargo.

2. Elaborar listas de menús considerando las facilidades de adquisición 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 menús alimentarios ofrecidos diariamente, cumpliendo con los

requerimientos nutricionales preestablecidos.

6. Calcular las cantidades y costos de los menús, de acuerdo con la estimación

del número de comensales.

17

7. Asesorar al jefe de cocina en cuanto al valor alimenticio de los materiales

usados.

8. Preparar una relación semanal, quincenal o mensual, según sea requerida por

el Administrador, de la cantidad y calidad de víveres necesarios para la

preparación 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 teléfono y los visitantes.

2. Mecanografiar las correspondencias, los informes y demás trabajos que se le

asignen.

3. Atender el archivo del comedor.

4. Las demás tareas normalmente a cargo de una secretaria.

Cajero:

1. Vender tickets durante el horario establecido para tal fin.

2. Elaborar una relación 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 almacén.

2. Relacionar diariamente todas las entradas y salidas, especificando cantidad y

valor de los artículos.

3. Levantar un inventario periódico de las existencias del almacén.

18

4. Asesorar al administrador en materia de precios y calidad de los artículos,

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 métodos de preparación 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 preparación de los alimentos y demás

actividades que le conciernan.

5. Asesorar al administrador en cuanto a calidad y cantidad en compras de

víveres.

6. Responder por los bienes entregados a su custodia y cuidado.

7. Responder, por la buena marcha de la cocina, preparación de alimentos y

agilidad en el servicio prestado.

Ayudantes de cocina:

1. Cumplir las tareas asignadas por el supervisor de cocina.

19

CAPITULO II

EL PROBLEMA Y SUS GENERALIDADES

2.1 Planteamiento del Problema

En los últimos años, la información 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 más

sustentables para determinar qué hacer y qué rumbo tomar para el logro de los

objetivos que se planearon.

Con el manejo de la información 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 información pasa a hacer un

elemento de vital importancia para el funcionamiento de toda la organización, 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 día, las organizaciones para poder competir y no

quedarse en el pasado, deben poseer una fuerte infraestructura tecnológica, en cuyo

centro se sitúe la tecnología de la información, que contribuyan a tomar decisiones

rápidas y a resolver los retos de la actualidad. Esto, con la ayuda de los sistemas

informáticos, que servirán de herramienta útil para el desarrollo, uso y administración

de la mencionada tecnología dentro de la organización.

Bajo este contexto, los sistemas y las tecnologías de información han cambia-

20

do la forma en que las organizaciones realizan sus operaciones. Pues a través de su

uso se logran importantes mejoras, automatizan los procesos operativos, proporcionan

información que sirva de apoyo para la toma de decisiones, y su implantación logra

ventajas competitivas frente a sus competidores.

En el caso de las universidades, el impacto de las tecnologías de información

y la comunicación ha sido considerable ya que se han introducido cambios

significativos en su organización. Además han venido emergiendo nuevas tecnologías

que constituyen un reto para los métodos de enseñanza y aprendizaje, la docencia e

investigación, los medios de organización y el funcionamiento interno e, incluso, la

definición misma de la universidad y del rol que esta desempeña en la sociedad.

Ahora bien, los procesos de transformación que viven actualmente las

instituciones universitarias y las organizaciones en general, también son

experimentados por las universidades venezolanas. Estas han venido adaptando e

incorporando dentro de su organización las tecnologías de información y actualizando

de manera creciente su plataforma tecnológica para realizar de manera más eficiente

y efectiva las actividades académico-administrativas y los procesos en general que

allí se realicen, con el fin de lograr una prestación de servicio de calidad que satisfaga

las necesidades de la comunidad.

Por su parte, la Universidad de Oriente como ente de educación 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 día 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.

21

En la Universidad de Oriente Núcleo de Monagas se prestan una gran

variedad de servicios para satisfacer las necesidades de los estudiantes en el

transcurso de su proceso de formación 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

energéticos diarios que propician un mejor rendimiento en el desempeño de sus

actividades académicas.

Este servicio de alimentación constituye uno de los más demandados por la

comunidad del núcleo, pues con este se benefician 4.000 estudiantes

aproximadamente, según información suministrada por la administración del comedor

universitario. Hay que tomar en cuenta, que la mayoría de estos beneficiados

provienen de familias de bajos ingresos económicos y/o residen en otras localidades

no pertenecientes a la ciudad de Maturín, 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 prestación del

servicio, éste debe ser eficiente brindando una alimentación sana, balanceada, variada

y atractiva para el comensal, con productos de calidad, con una excelente preparación

y presentación de los alimentos con las mejores condiciones higiénicas, acorde al

presupuesto establecido.

Estos recursos asignados al comedor universitario, deben ser administrados

con la máxima eficacia y eficiencia posible para lograr una calidad en el servicio

ofrecido a los estudiantes y a eventos especiales, que requiera de la colaboración del

comedor para la preparación de las comidas que deben ser entregadas a los

participantes de dicho evento. Como se denota, este estudio de ingeniería está

orientado tanto a la población estudiantil como al resto de la comunidad universitaria

22

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 planificación alimentaria de los menús que serán preparados. Para

esto, se estima el número de estudiantes que asistirán al comedor, y en base a esta

información se calculan las cantidades de insumos necesarias para la preparación de

las comidas. A partir de ese momento, se elaboran los pedidos que deben entregarse a

los proveedores para la adquisición de los mismos. Luego, de llevar a cabo los

aspectos anteriores, se debe controlar las existencias de insumos en almacén; para ello

se lleva un registro, tanto de los artículos adquiridos a través de los pedidos realizados

a los proveedores como de su salida de la despensa para preparar el menú del día. Por

último, para justificar los gastos ante la universidad este realiza un análisis de los

costos incurridos al prestarse dicho servicio.

Actualmente, la delegación de comedor realiza la mayoría de los procesos

antes mencionados de manera semi-manual, utilizando formatos llenados a través de

una computadora (formatos para realizar reportes de costos por ejemplo), donde la

información es manejada en archivos de Microsoft Excel; aplicación que a pesar de

ser muy potente y de tener múltiples 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 generación de informes y errores en los cálculos,

por la manipulación constante de las fórmulas cada vez que estos se elaboran.

Corriendo además el riesgo de que los datos y la información sean manipulados y

corrompidos.

Por otra parte, la administración del comedor elabora la planificación de los

menús alimentarios calculando, el número aproximado de estudiantes que acudirán al

comedor, apoyándose en la experiencia, en las circunstancias de cada día (por

ejemplo realizando el conteo manual de las bandejas de comidas utilizadas por los

23

estudiantes) y en las estadísticas del comedor. Esto último, con la ayuda de una

pequeña aplicación en Microsoft Access, que se encarga de registrar el número de

comensales que asisten al lugar para aprovechar el servicio. Sin embargo, éste

funciona de manera aislada, al igual que la aplicación mencionada anteriormente (La

hoja de Excel), sin que sea posible utilizar en red la información generada por él

mismo en el proceso de planificación.

Por el contrario, el control del inventario de insumos se realiza sin utilizar una

herramienta informática 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 específica de insumos.

Hay que destacar en este apartado, que el comedor universitario realiza una

planificación semanal de los insumos que se van a adquirir y depositar en la despensa

para su posterior utilización. 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 prácticamente sólo pueden depositarse aquellos

insumos que son necesarios para preparar los menús alimentarios de los días

correspondientes a una semana. Además, en el almacén la seguridad es precaria,

donde los insumos no pueden permanecer todo un fin de semana, debido a que se

verían expuestos a pérdidas o extravió por personas ajenas a la institución. 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 automatización de los procesos de planificación y control de los

insumos necesarios para prestar el servicio de alimentación por el comedor

universitario de la Universidad de Oriente Núcleo de Monagas. Con el cual se pueda

realizar la programación alimentaria de manera ágil y más aproximada a la realidad; y

24

que permita controlar los insumos adquiridos para asegurar el cumplimiento de lo

establecido en la planificación.

2.2 Objetivos de la Investigación

2.2.1 Objetivo General

Desarrollar un sistema Web para la planificación y control del servicio de

alimentación prestado por el comedor universitario de la Universidad de Oriente

Núcleo de Monagas.

2.2.2 Objetivos Específicos

1. Describir el funcionamiento actual de los procesos llevados a cabo dentro del

servicio de alimentación prestado por la Universidad de Oriente Núcleo de

Monagas.

2. Determinar los problemas y necesidades actuales relacionados con la

planificación y control del servicio prestado por el comedor universitario.

3. Definir los requerimientos de información del sistema, a través del estudio

realizado al comedor universitario y considerando las necesidades de los

usuarios del área administrativa del mismo.

4. Diseñar una arquitectura sólida para el sistema, que cumpla con los

requerimientos definidos.

5. Construir un prototipo inicial, de acuerdo a la arquitectura diseñada y a los

requisitos especificados del sistema.

2.3 Justificación de la Investigación

La necesidad de proponer el desarrollo de un sistema Web para la

planificación y control del servicio prestado por el comedor universitario de la

Universidad de Oriente Núcleo de Monagas, traerá consigo numerosos beneficios,

25

reflejados generalmente en el mejoramiento del servicio del comedor universitario

por la incorporación de la tecnología de información en esta área, contribuyendo por

ende al avance tecnológico de la institución 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 optimización de los mismos; lo que traerá

consigo, una reducción de tiempo y un control más efectivo de los recursos

adquiridos para la prestación del servicio de alimentación.

Asimismo, con el desarrollo del sistema se podrá llevar un mayor manejo y

control de la información, habiendo a su vez mejor disponibilidad de la misma para

los usuarios en tiempo real. Además, se evitará la duplicidad y pérdida de datos,

debido a que toda la información estará almacenada en una base de datos confiable,

que podrá ser accedida en todo momento para recuperar y utilizar dicha información

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 automatización de los procesos relacionados con la

planificación y control del servicio de alimentación, se podrá realizar la programación

alimentaria de manera rápida y sencilla, pudiendo también elaborar los menús con su

respectiva información nutricional para cumplir con los requerimientos alimenticios

necesarios para el buen desempeño de la comunidad universitaria en sus actividades

diarias.

Además, permitirá controlar el acceso de los comensales al comedor para

tener un registro del número de personas atendidas, generando estadísticas que

puedan ser utilizadas por la administración para realizar estimaciones más certeras de

la cantidad de menús que se deben servir para satisfacer la demanda del servicio en

las próximas semanas. Lo que servirá de ayuda para obtener una planificación

alimentaria más aproximada a la realidad.

26

Para determinar el estimado de personas que harán uso del servicio del

comedor en cada turno de la semana que se está planificando, se utilizará el modelo

de series de tiempo para pronóstico de demanda, denominado promedio móvil. Este

método, utilizará los datos históricos del número de comensales que asistieron al

comedor universitario en periodos anteriores para calcular la demanda promedio, y

obtener así el pronóstico de la siguiente semana.

Por otro lado, el sistema contará con un módulo 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 información veraz y confiable de las cantidades de artículos existentes. Por lo

tanto, se podrá corroborar en todo momento que están siendo utilizados

correctamente los insumos de acuerdo a lo programado en la planificación

alimentaria. También, con el sistema se agilizará la generación de reportes e informes

para mejorar la capacidad de respuesta ante las autoridades universitarias.

Con la futura implantación y uso del sistema desarrollado se beneficiarán de

manera directa los estudiantes, obreros, personal administrativo y docente que hacen

uso del servicio de alimentación. Pero principalmente aquellas personas que laboran

en el área administrativa del comedor universitario, pues ellas serán las que

manejarán directamente el sistema, para así aprovechar al máximo las ventajas de

utilizar una tecnología informática en la optimización de sus actividades diarias.

Entre las ventajas que le puede brindar el sistema al personal administrativo

del comedor se pueden mencionar: disminución de la carga de trabajo, ahorro

significativo de tiempo, celeridad en la elaboración de informes o reportes para

garantizar la entrega a tiempo de los mismos. Igualmente, el sistema automatizado

ofrece la ventaja de suministrar información de calidad, puesto que minimiza la

posibilidad de cometer errores al momento de realizar cálculos y operaciones.

27

Además dicha aplicación presenta una interfaz cómoda y sencilla para el usuario,

proporcionándole una interacción amigable y facilitándole así su uso y aprendizaje.

El sistema Web para la planificación y control del servicio de alimentación

prestado por el comedor universitario del núcleo de Monagas, podrá ser adaptado a

las necesidades de los otros núcleos de la Universidad de Oriente, puesto que para su

desarrollo se tomaron en consideración un conjunto de normas y reglamentos que son

propias de la institución y por las cuales deben regirse todos los comedores

universitarios de la UDO.

2.4 Alcance de la Investigación

Con este proyecto de investigación se pretende desarrollar un sistema

automatizado para la planificación y el control de los insumos necesarios para prestar

el servicio de alimentación por el comedor universitario de la Universidad de Oriente

Núcleo de Monagas. Para el desarrollo de dicho proyecto se emplearon las fases de

inicio, elaboración y construcción de la metodología de desarrollo de software RUP;

abarcando el análisis y diseño de todo el sistema, y llevándose a cabo la construcción

de un prototipo inicial en el que se incluyeron los módulos más esenciales para el

funcionamiento del servicio del comedor universitario.

El sistema desarrollado, se caracteriza por ser una aplicación bajo entorno

Web, donde las operaciones y los cálculos son transparentes para el usuario, pudiendo

garantizar rapidez y confiabilidad en los datos generados, y la reducción de errores.

Dicha aplicación, podrá ser utilizada por los usuarios, accediendo a un servidor a

través de una red mediante un navegador Web (como Mozilla Firefox, Internet

Explorer, entre otros) que estará instalado en cada una de las computadoras clientes.

Básicamente, para establecer la comunicación, el cliente enviará una petición al

servidor, y luego este efectuará un proceso y le responderá con el contenido que le

solicitó (devolviendo una página Web al cliente).

28

CAPITULO III

MARCO REFERENCIAL

3.1 Antecedentes de la Investigación

Barrios, D. (2009). Modelo de sistema viable para el comedor de la Universidad de

Oriente Núcleo Monagas. Trabajo de grado presentado en la Universidad de Oriente

Núcleo de Monagas para optar al título de Ingeniero de Sistemas. Este trabajo tuvo

como objetivo principal la aplicación teórica del Modelo de Sistema Viable a la realidad

del comedor de la Universidad de Oriente núcleo Monagas, permitiendo definir un

modelo organizacional con enfoque funcional para dicho comedor, el cual toma en

cuenta el entorno, visualizándolo hacia el logro de una organización que cumpla con

la adaptación, regulación 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 investigación, por lo que aportó conocimientos sobre aspectos

importantes de la realidad del comedor universitario de la Universidad de Oriente

Núcleo de Monagas.

Briceño, G. (2008). Sistema automatizado para la gestión de los procesos

administrativos de la delegación de planificación de la Universidad de Oriente

Núcleo Monagas. Trabajo de grado realizado para obtener el título de Ingeniero de

Sistemas en la Universidad de Oriente Núcleo de Monagas. Este consistió en el

desarrollo de un sistema automatizado para la gestión de los procesos de recepción,

seguimiento y control de los proyectos que las dependencias del núcleo elaboran con

la finalidad de ser incluidos en el Plan Operativo Anual de la universidad. Tal

investigación, sirvió de referencia para comprender el uso de la metodología RUP en

29

el proceso de desarrollo de software, así como también la utilización de los diferentes

diagramas de la herramienta UML para el modelado de sistemas.

Fonseca, R. (2008). Sistema de Gestión en Ambiente Web para Salas Situacionales en

Instituciones Públicas Adscritas a Entes Gubernamentales. Caso de Estudio: Centro

Internacional Miranda Caracas. Proyecto de Grado presentado ante la Universidad

Nacional Experimental del Táchira para optar al título de Ingeniero en Informática. El

propósito de esta investigación 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 institución donde se aplique),

medios de comunicación social y consejos comunales; además de generar una

herramienta de fácil 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

metodología de desarrollo de software RUP, y también como referencia para la

diagramación con UML.

Rojas, J. (2005). Sistema de Información Web para la Gestión y Control de Contratos

e Inventario de la Dirección de Ingeniería y Mantenimiento de la Universidad de Los

Andes. Proyecto de Grado presentado ante la ilustre Universidad de Los Andes para

optar al título de Ingeniero de Sistemas. Este trabajo tuvo la finalidad de desarrollar

un sistema de información para la automatización de los procesos de control de

inventario del almacén y de las obras contratadas realizadas por la Dirección de

Ingeniería y Mantenimiento de la ULA, de manera que se pudiera suministrar con el

menor retardo posible los materiales necesarios para la ejecución de obras bajo su

cargo y vigilar el desempeño de los contratistas a cargo de tales obras. Dicha

investigación, contribuyó a comprender el desarrollo de un software aplicando la

metodología RUP, conjuntamente con la herramienta UML.

30

3.2 Bases Teóricas

3.2.1 Metodología RUP

La metodología RUP, llamada así por sus siglas en inglés 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 propósito es asegurar la

producción de software de alta calidad que satisfaga las necesidades de los usuarios

finales, ajustándose 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 más que un simple proceso; es un marco de trabajo genérico que puede especializarse para una gran variedad de sistemas de software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaños de proyectos.(p.04)

El proceso unificado de desarrollo es el resultado de más de 30 años de

experiencia, con la unificación de técnicas de desarrollo y del trabajo de muchos

metodologístas. El antecedente más importante de esta metodología se ubica en 1967

con la Metodología Ericsson (Ericsson Approach) elaborada por Ivar Jacobson, que

fue una aproximación de desarrollo basada en componentes, y que introdujo el

concepto de Caso de Uso. Entre los años de 1987 a 1995 Jacobson fundó la compañía

“Objectory AB” y lanza el proceso de desarrollo Objectory (abreviación 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 fusión de Objectory 3.8 y del Enfoque Rational (Rational Approach)

31

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, destacándose 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 organización 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 pequeños como en grandes proyectos de

software.

Esta metodología de desarrollo también ofrece una forma coordinada de

trabajar; proporciona una guía 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 medición 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 guía

arquitectónica, para diseñar y probar el sistema de acuerdo a los requerimientos y a la

arquitectura realizada del mismo. Además, provee patrones, y describe qué

entregables producir y cómo desarrollarlos. RUP es soportado por herramientas que

automatizan entre otras cosas, el modelado visual, la administración de cambios y las

pruebas.

3.2.1.1 Características principales de RUP

Las características esenciales de RUP son las siguientes:

32

a) Proceso dirigido por casos de usos

Los casos de uso son una técnica de captura de requisitos potenciales de un

nuevo sistema o la actualización de un software ya existente. Cada caso de uso

proporciona uno o más escenarios que indican cómo debería interactuar el sistema

con el usuario o con otro sistema para conseguir un objetivo específico. En otras

palabras, un caso de uso es una secuencia de interacciones que se desarrollarán entre

un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre

el propio sistema.

Según 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 más 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 sólo una herramienta para especificar los

requisitos funcionales del sistema. También guían su diseño, implementación y

prueba, es decir, guían 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.

33

Figura 4. Los casos de uso integran el trabajo. Fuente: Autor (2009)

Como se muestra en la Figura 4, los casos de uso actúan como un elemento

integrador y guían el trabajo realizado durante el proceso de desarrollo. Pues, en base

a estos, se crean los modelos de análisis y diseño; luego la implementación 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 construcción de edificios. El edificio se mira desde diferentes

puntos de vista: estructura, servicios, plomería, electricidad, etc. Esto permite al

constructor ver una imagen completa antes de que comience la construcción.

Similarmente, la arquitectura en un sistema software se describe mediante diferentes

vistas del sistema en construcción.

La arquitectura de un sistema es la organización o estructura de sus partes más

relevantes, que permite tener una visión común entre todos los involucrados

(desarrolladores y usuarios) y una perspectiva clara del sistema completo, necesaria

para controlar el desarrollo.

34

La metodología RUP además de utilizar los casos de uso para guiar el

proceso, presta especial atención al establecimiento temprano de una buena

arquitectura que no se vea fuertemente impactada ante cambios posteriores durante la

construcción y el mantenimiento. RUP asume que no existe un modelo único que

cubra todos los aspectos del sistema. Por tal motivo existen múltiples modelos y

vistas que definen la arquitectura de software de un sistema.

La arquitectura involucra los aspectos estáticos y dinámicos más 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, también está

influenciada por muchos otros factores, tales como la plataforma en la que tiene que

funcionar el software (arquitectura hardware, sistema operativo, sistema de gestión de

base de datos, protocolo para comunicaciones en red), la disponibilidad de

componentes reutilizables, consideraciones de instalación, sistemas heredados y

requisitos no funcionales (por ejemplo rendimiento y confiabilidad).

Cada producto software tiene una función y una forma. La función

corresponde a los casos de uso y la forma a la arquitectura. Existe una interacción

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 evolución 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 modificándola dependiendo de las necesidades del proyecto.

En las fases finales lo que se tiene es una arquitectura más robusta del sistema.

35

Figura 5. Evolución 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 más de un año. Por lo tanto, una solución práctica para

esto, es tener un proceso iterativo e incremental, en donde el trabajo se divida en

partes más pequeñas o mini proyectos. Cada mini proyecto se puede ver como una

iteración (un recorrido más 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

través de un proceso iterativo e incremental. En el cual se plantea la implementación

del proyecto a realizar en Iteraciones, con lo cual se pueden definir objetivos por

cumplir en cada iteración y así poder ir completando todo el proyecto iteración por

iteración; con lo cual se tienen varias ventajas, entre ellas se puede mencionar la de

tener pequeños avances del proyecto, que son entregables al cliente el cual podría

probar mientras se está desarrollando otra iteración 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 iteración puede

realizarse por medio de una cascada, pasando por los flujos fundamentales

(Requisitos, Análisis, Diseño, Implementación y Pruebas), también existe una

36

planificación de la iteración, un análisis de la iteración y algunas actividades

específicas de la iteración. Al finalizar se realiza una integración de los resultados con

lo obtenido de las iteraciones anteriores.

Figura 6. Una iteración RUP. Fuente: (https://pid.dsic.upv.es)

Como se mencionó anteriormente un proceso iterativo e incremental consta de

una secuencia de iteraciones. Cada iteración aborda una parte de la funcionalidad

total, pasando por todos los flujos de trabajo relevantes y refinando la arquitectura. Al

finalizar cada iteración, esta se analiza; también se puede determinar si han aparecido

nuevos requisitos o han cambiado los existentes, afectando a las iteraciones

siguientes. Durante la planificación de la siguiente iteración, el equipo también

examina cómo afectarán los riesgos que aún quedan al trabajo en curso. Toda la

retroalimentación de la iteración pasada permite reajustar los objetivos para las

siguientes iteraciones. Se continúa con esta dinámica hasta finalizar por completo con

la versión actual del producto.

3.2.1.2 Estructura de RUP

La estructura de RUP puede ser descrita a través de dos dimensiones o ejes:

37

1. Eje horizontal: Representa el tiempo y es considerado el eje de los aspectos

dinámicos del proceso. Esta dimensión muestra las características del ciclo de

vida del proceso, expresado en términos de fases, iteraciones e hitos.

2. Eje vertical: Representa los aspectos estáticos del proceso. Esta dimensión

describe el proceso en términos 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 dinámica

como estática. A continuación, se detalla cada una de ellas:

a) Estructura Dinámica 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 versión

del producto para los clientes. Cada ciclo consta de cuatro fases: Inicio, Elaboración,

38

Construcción y Transición. Cada fase se subdivide a la vez en iteraciones, el número

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 duración y esfuerzo dedicado en cada fase es variable dependiendo de las

características del proyecto. Cada fase se termina con un hito bien definido (un punto

en el tiempo en el cual se deben tomar ciertas decisiones críticas 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 metodología RUP divide el proceso de

desarrollo de software en cuatro (4) fases:

39

1. Fase de Inicio

En esta fase se define el modelo del negocio y el alcance del proyecto. Permite

establecer una visión sobre el límite del sistema, el costo en recursos y tiempo.

También, se evalúa la viabilidad del proyecto, sobre todo cuando está en juego una

gran inversión de recursos; se estiman los riesgos asociados al proyecto y se

identifican los casos de uso críticos del sistema y los escenarios básicos 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, realizándose poco trabajo en los flujos de trabajo de

análisis y de diseño. Esta fase raramente realiza trabajo en los flujos de trabajo de

implementación y de prueba.

2. Fase de Elaboración

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 culminación 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 críticos identificados en la fase de inicio.

También debe demostrarse que se han evitado los riesgos más graves. Con esta fase

se busca definir, validar y cimentar la arquitectura, completar la visión y crear un plan

fiable el cual puede variar con las iteraciones.

En la fase de elaboración, mientras continua una cierta actividad dedicada a

completar los requisitos, los flujos de trabajo de análisis y de diseño reciben una gran

parte de la actividad, ya que son la base de la creación de la arquitectura. Para

alcanzar la arquitectura base sólida hay alguna actividad en los últimos flujos de

trabajo (implementación y pruebas).

40

3. Fase de Construcción

Lo que se busca en esta fase, es alcanzar la capacidad operacional del

producto de forma incremental a través de sucesivas iteraciones. Durante esta fase se

debe describir los requisitos restantes, refinar el diseño, e implementar, integrar y

probar en su totalidad, todos los componentes, características y requisitos, obteniendo

una versión aceptable del producto. En esta fase, por tanto, los distintos modelos del

sistema van creciendo hasta completarse. La descripción de la arquitectura, sin

embargo, no crece significativamente debido a que la mayor parte de esta arquitectura

se definió durante la fase de elaboración.

El propósito primordial de esta fase es dejar listo un producto software en su versión inicial, a veces llamada versión beta. El producto debería tener la calidad adecuada para su aplicación y asegurarse de cumplir los requisitos. La construcción debería tener lugar dentro de los límites del plan de negocio. (Jacobson, Booch y Rumbaug, 2000, p. 367).

En la fase de construcción el flujo de trabajo de los requisitos disminuye, el

análisis se aligera y los flujos de trabajo de diseño, de implementación y de pruebas

representan el grueso de la actividad.

4. Fase de Transición

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, configuración, instalación 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 características

que habían sido propuestas. Esta fase comienza normalmente con una versión beta del

sistema, que luego será reemplazada por la versión definitiva del producto.

41

En esta fase de transición la actividad de los distintos flujos de trabajo

depende de los resultados de las pruebas de aceptación y de las versiones beta del

sistema. Por ejemplo, si las pruebas de las versiones beta descubren algún defecto en

la implementación habrá una actividad considerable en los flujos de implementación

y prueba.

b) Estructura Estática de RUP

Está representada por cuatro elementos, que responden a las preguntas

¿Quién?, ¿Cómo?, ¿Qué? y ¿Cuándo? definidas en un proceso de desarrollo de

software: los roles, responden a la pregunta ¿Quién?, las actividades responden a la

pregunta ¿Cómo?, los productos, responden a la pregunta ¿Qué? y los flujos de

trabajo de las disciplinas responde a la pregunta ¿Cuándo? En la Figura 10 se

muestran algunos elementos de la estructura estática de RUP.

Figura 10. Relación entre roles, actividades, artefactos. Fuente: (https://pid.dsic.upv.es).

42

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

desempeñar 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 dueño de un conjunto de artefactos. RUP define grupos de

roles, agrupados por participación en actividades relacionadas.

2. Actividades

Una actividad en concreto es una unidad de trabajo que se le asigna a una

persona que desempeña un rol. Las actividades tienen un objetivo concreto,

normalmente expresado en términos de crear o actualizar algún producto, tales como

un modelo, una clase, un código 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 desempeñan roles, las cuales utilizan y van

produciendo estos artefactos para tener guías.

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 diseño.

43

- 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 filosofía 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, sólo al término del proceso se podría tener una versión definitiva y

completa de cada uno de ellos. Sin embargo, el resultado de cada iteración y los hitos

del proyecto están enfocados a conseguir un cierto grado de completitud y estabilidad

de los artefactos.

4. Flujos de trabajo (Disciplinas)

Con simplemente la enumeración 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 relación entre los mismos. Un flujo de trabajo es una

relación de actividades que producen unos resultados observables.

Las disciplinas conllevan los flujos de trabajo, los cuales son una secuencia de

pasos para la culminación 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 realización de un proyecto de software; entre ellas

se tienen: modelado del negocio, requerimientos, análisis y diseño, implementación,

pruebas y despliegue. Las de apoyo son las que como su nombre lo indica sirven de

apoyo a las de proceso y especifican otras características en la realización de un

proyecto de software; entre estas se tienen: entorno, gestión del proyecto, gestión de

configuración y cambios.

3.2.2 Lenguaje Unificado de Modelado

El Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified

Modeling Language) es el lenguaje de modelado de sistemas de software más

44

conocido y utilizado en la actualidad; está respaldado por el OMG (Object

Management Group). Este lenguaje se ha convertido en un estándar, debido a que ha

sido impulsado por los autores de los tres métodos más usados de orientación 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 estándar 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; además, es un lenguaje de modelado lo que significa que el vocabulario y

las reglas del que está compuesto se utilizan para la representación conceptual y física

del sistema. Es decir ofrece una notación estándar y semánticas 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 programación, esquemas de bases de datos y

componentes de software reutilizables.

Este lenguaje comenzó a gestarse en el año de 1994, cuando Rumbaugh se

unió a la compañía Rational fundada por Booch (dos reputados investigadores en el

área de la metodología del software). El objetivo de ambos era unificar dos métodos

que habían desarrollado: el método 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). Además, este lenguaje se abrió a

la colaboración de otras empresas para que aportaran sus ideas.

45

Todas estas colaboraciones condujeron a la definición de la primera versión de

UML. Esta primera versión se ofreció a la OMG para convertirlo en un estándar. Este

grupo, llamado OMG, que gestiona estándares relacionados con la tecnología

orientada a objetos (metodologías, bases de datos objetuales, CORBA, etc.), propuso

una serie de modificaciones y una nueva versión de UML (la 1.1), que fue adoptada

por el OMG como estándar en noviembre de 1997. Desde ese entonces, UML

atravesó varias revisiones y refinamientos hasta llegar a la versión actual: UML 2.0.

Las funciones del UML son:

- Visualizar: UML permite expresar de una forma gráfica un sistema de

manera que otro lo pueda entender.

- Especificar: UML permite especificar cuáles son las características de un

sistema antes de su construcción.

- Construir: A partir de los modelos especificados se pueden construir los

sistemas diseñados.

- Documentar: Los propios elementos gráficos sirven como documentación del

sistema desarrollado que pueden servir para su futura revisión.

UML puede usarse para modelar desde sistemas de información hasta

aplicaciones distribuidas basadas en Web, pasando por sistemas empotrados de

tiempo real. Sin embargo, UML es solamente un lenguaje por lo que es sólo una parte

de un método 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

46

software completo. Este les permite capturar sus ideas en una forma convencional y

fácil de comprender para comunicarlas a otras personas.

Cabe agregar que UML capta la información sobre la estructura estática y el

comportamiento dinámico de un sistema. La estructura estática define los tipos de

objetos importantes para un sistema y su implementación, así como las relaciones

entre los objetos. El comportamiento dinámico define la historia de los objetos en el

tiempo y la comunicación entre ellos para cumplir sus objetivos. El modelar un

sistema desde varios puntos de vista, separados pero relacionados, permite entenderlo

para diferentes propósitos.

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)

47

Como se puede apreciar, el lenguaje UML se compone de tres elementos

principales, los bloques básicos de construcción, las reglas de combinación de los

bloques básicos y algunos mecanismos comunes.

1. Bloques de construcción

Los bloques de construcción 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 máquinas de estado), elementos de agrupación (paquetes) y elementos de anotación

(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, según 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, asociación, generalización y realización; estas se describen a

continuación:

48

Dependencia

Es una relación semántica entre dos elementos, en la cual un cambio a un

elemento (el elemento independiente) puede afectar a la semántica del otro elemento

(el dependiente). Las dependencias generalmente representan relaciones de uso que

declara que un cambio en la especificación de un elemento puede afectar a otro

elemento que la utiliza, pero no necesariamente a la inversa. La mayoría de las veces

se utilizan en el contexto de las clases o paquetes, aunque también son habituales en

la vinculación de notas.

Figura 12. Representación de una dependencia. Fuente: Autor (2009)

Asociación

Es una relación estructural que describe un conjunto de enlaces, los cuales son

conexiones entre objetos. La agregación es un tipo especial de asociación y representa

una relación estructural entre un todo y sus partes. La asociación se representa con

una línea 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. Representación de una asociación. Fuente: Autor (2009)

49

Generalización

Es una relación de especialización/generalización 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. Gráficamente, la generalización se representa con una línea con punta de

flecha vacía (Figura 14).

Figura 14. Representación de una generalización. Fuente: Autor (2009)

Realización

Es una relación semántica entre clasificadores, en la que un clasificador

especifica un contrato que otro clasificador garantiza llevar a cabo. Se pueden

encontrar relaciones de realización 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 realización se representa como una mezcla entre la generalización

(Figura 14) y la dependencia (Figura 12, p.48), esto es, una línea discontinua con una

punta de flecha vacía (Figura 15).

Figura 15. Representación de una generalización Fuente: Autor (2009)

50

c) Diagramas

Un diagrama es la representación gráfica 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 sección 3.2.2.2

se detallan algunos de los diagramas UML que se utilizan más comúnmente.

2. Reglas

Los bloques de construcción 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 semánticamente auto

consistente y está en armonía con todos sus modelos relacionados.

UML tiene reglas semánticas para:

Nombres: Cómo llamar a los elementos, relaciones y diagramas.

Alcance: El contexto que da significado específico a un nombre.

Visibilidad: Cómo se pueden ver y utilizar esos nombres por otros.

Integridad: Cómo se relacionan apropiada y consistentemente unos elementos con

otros.

Ejecución: Qué significa ejecutar o simular un modelo dinámico.

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 adaptación no se

pierda la semántica propia de UML.

51

Existen cuatro mecanismos comunes que se aplican de forma consistente a

través de todo el lenguaje:

Especificaciones

Proporcionan la explicación textual de la sintaxis y semántica de los bloques

de construcción. Por ejemplo, detrás del símbolo o icono de una clase hay una

especificación que proporciona información de sus atributos, operaciones, signaturas

y comportamiento de la clase (visualmente el icono de la clase puede mostrar sólo

parte de la especificación). La notación gráfica de UML se utiliza para visualizar el

sistema, la especificación se utiliza para enunciar los detalles de dicho sistema.

Adornos

La mayoría de los elementos UML tienen una única y clara notación gráfica

que proporciona una representación visual de los aspectos más importantes del

elemento. Pero la especificación puede incluir otros detalles algunos de los cuales se

pueden incluir como adornos gráficos en la notación base. Los adornos son elementos

secundarios ya que proporcionan más 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 comprensión desde distintos puntos de vista, en primer lugar se tiene

la división entre clase y objeto (clase es una abstracción y objeto es una

manifestación de esa abstracción), en segundo lugar se tiene la división interfaz /

implementación donde la interfaz presenta un contrato (algo que se va a cumplir de

52

una determinada manera) mientras que la implementación es la manera en que se

cumple dicho contrato.

Mecanismos de extensibilidad

UML proporciona un lenguaje estándar 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 razón 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 semántica. Esta herramienta, por lo tanto, puede ajustarse a un sistema, proyecto o proceso de desarrollo específico 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 semántica 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 abstracción que consiste en un número de diagramas; y todos esos diagramas

juntos muestran una "fotografía" completa del sistema.

Los diagramas son de gran utilidad para trabajar en los requisitos, en el

análisis del sistema, en la construcción del mismo y en su posterior implementación.

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.

53

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 específicos del sistema. La vista de

Casos de uso provee información sobre el comportamiento y funcionalidad del

sistema. La vista de diseño: proporciona información del vocabulario y la

funcionalidad del sistema. Por otro lado la vista de interacción: muestra información

sobre el rendimiento del sistema, la escalabilidad del mismo y la capacidad de

procesamiento necesaria. La vista de implementación establece el ensamblado del

sistema y la gestión de la configuración. Y por último, la vista de despliegue permite

establecer la topología del sistema, su distribución y las pautas para su instalación.

1. Diagramas de UML

En la versión 2.0 de UML existen 13 tipos diferentes de diagramas. La Figura

17, p.54 muestra una clasificación de los distintos tipos de diagramas.

54

Figura 17. Clasificación 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 estática la estructura de la información que maneja el sistema y la

visibilidad que tiene cada una de las clases, dada por sus relaciones con los demás en

el modelo

55

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

específico, atributos y operaciones. Una clase se representa por un rectángulo en el

cual se inscriben tres secciones: en la sección superior se coloca el nombre de la

clase; en la intermedia, se presentan los atributos que caracterizan a la clase y en la

sección inferior se listan sus métodos u operaciones. En la Figura 18 se muestra un

ejemplo de representación de una clase.

Figura 18. Representación de una clase. Fuente: Autor (2009)

Los atributos o características de una Clase pueden ser de tres tipos, los que

definen el grado de comunicación y visibilidad de ellos con el entorno, estos son:

Privado (-): Indica que el atributo sólo será accesible desde dentro de la clase (sólo

sus métodos 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 métodos de la clase además de las subclases que se deriven.

Los métodos u operaciones de una clase son la forma en cómo ésta interactúa

con su entorno, éstos pueden tener las características:

56

Privado (-): Indica que el método sólo será accesible desde dentro de la clase (sólo

otros métodos de la clase lo pueden accesar).

Publico (+): Indica que el método será visible tanto dentro como fuera de la clase, es

decir, es accesible desde todos lados.

Protegido (#): Indica que el método no será accesible desde fuera de la clase, pero si

podrá ser accesado por métodos de la clase además de métodos de las subclases que

se deriven.

En un diagrama de clases, las relaciones entre clases se representan por líneas,

a las que se les da diferentes características, dependiendo del tipo de vinculación. En

los extremos de esas líneas que representan las relaciones puede colocarse tanto la

descripción del rol que asume cada clase en esa relación como la cardinalidad, que

describe cuántos objetos de cada clase pueden participar en la relación. En la Figura

19 se muestra un ejemplo de la relación entre dos clases.

Figura 19. Relación entre clases. Fuente: Autor (2009)

Existen diferentes tipos de relaciones entre clases: asociación, agregación,

composición, dependencias y generalización. A continuación en el Cuadro 1 se

muestran cada una de estas relaciones con sus respectivos detalles.

57

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

comunicación, que muestra la configuración en funcionamiento del sistema,

incluyendo su hardware y su software. Estos diagramas muestran la vista de

despliegue estática de una arquitectura y se relacionan con los componentes ya que,

por lo común, los nodos contienen uno o más 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 ejecución de un sistema, y muestra la configuración de los elementos de hardware.

También muestra cómo 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 través de interfaces.

58

Figura 20. Ejemplo Diagrama de despliegue. Fuente: Autor (2009).

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

físico en tiempo de ejecución 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 producción. Otro de los elementos son los

componentes, que representan todos los tipos de elementos software que entran en la

fabricación de aplicaciones informáticas. Por último, se tiene la interfaz que se utiliza

como lazo de unión entre unos componentes y otros.

b) Diagramas de Comportamiento

Enfatizan en lo que debe suceder en el sistema modelado. Estos diagramas

representan las características de comportamiento de un sistema o proceso de

negocios.

59

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, básicamente 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 método 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 gráfica para

modelar el proceso de un caso de uso específico. Por lo que sirve como un añadido a

una descripción textual del caso de uso, o para mostrar en forma grafica, los pasos del

caso de uso.

Gráficamente un diagrama de actividad es una colección de nodos y arcos. En

el Cuadro 2, p. 60 se observan algunos de los elementos que componen a este tipo de

diagrama.

60

Cuadro 2. Elementos Diagrama de Actividad

Fuente: Autor (2009)

b.2) Diagrama de Casos de uso

Un Diagrama de Casos de Uso muestra la relación entre los actores y los casos

de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se

refiere a su interacción externa. En el diagrama de casos de uso también se puede

representar el sistema como una caja rectangular con el nombre en su interior.

Mientras que los casos de uso están 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

línea.

Un diagrama de casos de uso muestra, por tanto, los distintos requisitos

funcionales que se esperan de una aplicación o sistema y cómo se relaciona con su

entorno (usuarios u otras aplicaciones). Estos, cubren la vista estática de los casos de

uso y son especialmente importantes para el modelado y organización del

comportamiento.

61

Es importante resaltar que los diagramas de casos de uso no están pensados

para representar el diseño y no puede describir los elementos internos de un sistema.

Estos diagramas sirven para facilitar la comunicación con los futuros usuarios del

sistema, y con el cliente, y resultan especialmente útiles para determinar las

características 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 cómo.

En la siguiente figura se muestran los elementos básicos que conforman al

diagrama de casos de uso:

Figura 21. Elementos Diagrama de casos de uso. Fuente: Autor (2009).

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 organización, y que realiza algún tipo de interacción con el sistema.

Se representa mediante una figura humana dibujada con palotes. Esta representación

sirve tanto para actores que son personas como para otro tipo de actores.

Los actores no representan a personas físicas o a sistemas, sino su papel. Esto

significa que cuando una persona interacciona con el sistema de diferentes maneras

62

(asumiendo diferentes papeles), estará representado por varios actores. Por ejemplo,

una persona que proporciona servicios de atención al cliente telefónicamente y realiza

pedidos para los clientes estaría representada por un actor «equipo de soporte» y por

otro actor «representante de ventas».

2. Caso de uso:

Un caso de uso es una descripción 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 específica. 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 específica que el actor

desea llevar a cabo usando el sistema.

3. Limite de un sistema

Resulta útil dibujar los límites 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. Relación

Entre los elementos de un diagrama de casos de uso se pueden presentar

cuatro tipos de relaciones, representadas por líneas dirigidas entre ellos. Estas son:

a) Relación de comunicación

Relación entre un actor y un caso de uso, denota la participación del actor en

el caso de uso determinado. Este tipo de relaciones no son obligatorias. Si en un

63

diagrama de casos de uso aparece una relación entre un actor y un caso de uso, indica

que puede que ese actor interactúe con el sistema en ese caso de uso.

b) Generalización

En un diagrama de casos de uso también pueden mostrarse generalizaciones

(relaciones de herencia) para mostrar que diferentes elementos están relacionados

como tipos de otros. Son aplicables a actores o casos de uso, pero para estos últimos

la semántica es muy similar a las relaciones “extend”.

c) Inclusión

Relación entre casos de uso, que especifica una situación 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

básica.

Los casos de uso se pueden incluir por uno o más casos de uso, ayudando a

reducir el nivel de duplicación de la funcionalidad realizando un factoreo del

comportamiento común en casos de uso que se usan muchas veces. Un caso de uso

“incluido” es básicamente un paso del caso de uso base, que se decide extraer aparte

para mejorar la comprensión, por la importancia que tiene el paso por sí mismo, o

para factorizar comportamiento común que se repite en varios casos de uso.

d) Extensión

Se puede incluir una relación entre dos casos de uso de tipo “extends” si se

desea especificar diferentes variantes del mismo caso de uso. Es decir, esta relación

implica que el comportamiento de un caso de uso es diferente dependiendo de ciertas

64

circunstancias. En principio esas variaciones pueden también mostrarse como

diferentes descripciones de escenarios asociadas al mismo caso de uso.

Este tipo de relación se utiliza cuando un caso de uso base tiene ciertos puntos

(puntos de extensión) en los cuales, dependiendo de ciertos criterios, se va a realizar

una interacción adicional. El caso de uso que extiende describe un comportamiento

opcional del sistema.

c) Diagramas de Interacción

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 representación 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 más efectivos

para modelar interacción entre objetos en un sistema. Este muestra la interacción de

un conjunto de objetos en una aplicación a través del tiempo y se modela para cada

método de la clase.

Este tipo de diagrama muestra una interacción ordenada según la secuencia

temporal de eventos y el intercambio de mensajes. En particular, muestra los objetos

participantes en la interacción y los mensajes que intercambian ordenados según 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 interacción, sin un orden prefijado.

Cada objeto o actor tiene una línea vertical, y los mensajes se representan mediante

flechas entre los distintos objetos. El tiempo fluye de arriba abajo. Se pueden colocar

65

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 símbolos básicos de este tipo de diagramas son los siguientes:

a) Línea de vida

La línea de vida de un objeto representa la vida del objeto durante la

interacción. En un diagrama de secuencia un objeto se representa como una línea

vertical punteada. Algunas veces un diagrama de secuencia tendrá una línea de vida

con un símbolo del elemento actor en la parte superior. Este usualmente sería el caso

si un diagrama de secuencia es contenido por un caso de uso.

Figura 22. Línea de vida de un objeto. Fuente: Autor (2009)

b) Activación

Muestra el período de tiempo en el cual el objeto se encuentra desarrollando

alguna operación, bien sea por sí mismo o por medio de delegación a alguno de sus

atributos. Se denota como un rectángulo delgado sobre la línea de vida del objeto.

66

Figura 23. Activación de un objeto. Fuente: Autor (2009)

c) Mensaje

El envío de mensajes entre objetos se denota mediante una línea sólida

dirigida, desde el objeto que emite el mensaje hacia el objeto que lo ejecuta.

Figura 24. Mensaje entre objetos. Fuente: Autor (2009).

3.2.3 Tarjetas CRC (clase, responsabilidad y colaboración)

Las tarjetas CRC son una metodología para el diseño de software orientado

por objetos creada por Kent Beck y Ward Cunningham. Es una técnica utilizada para

descubrir información acerca de las clases que luego es colocada dentro de los

diagramas de clases UML. Esta técnica se puede usar para guiar el sistema a través de

67

análisis 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 física de estas tarjetas enfatiza la división de responsabilidades a través de

los objetos. El tamaño físico de las tarjetas también ayuda a establecer límites para el

tamaño y complejidad de las clases. Estas tarjetas se dividen en tres secciones que

contienen información del nombre de la clase, sus responsabilidades y sus

colaboradores. A continuación se muestra cómo se distribuye esta información.

Figura 25. Tarjeta CRC. Fuente: Autor (2009).

Una clase es cualquier persona, cosa, evento, concepto, pantalla o reporte. Las

responsabilidades de una clase representan una descripción de alto nivel del propósito

de una clase. Los colaboradores de una clase son las demás clases con las que trabaja

en conjunto para llevar a cabo sus responsabilidades.

La técnica de las tarjetas CRC son especialmente eficaces cuando se está en

medio de un caso de uso para ver cómo 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

68

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

Están 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 análisis como

el diseño del sistema. Estos artefactos son los siguientes:

1. Documento Visión

Define la visión del producto desde la perspectiva de los participantes y

usuarios, especificando las necesidades y características 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 más alto nivel enfocados en el

cliente, con la finalidad de proporcionar una visión general y de lograr un lineamiento

y un acuerdo común entre los involucrados.

Más detalladamente, este artefacto contiene la declaración del problema, una

descripción de los participantes y usuarios, las necesidades particulares de los

diferentes grupos de usuarios, una descripción de la solución a proponer y el listado

de características. También en este documento se determinan las necesidades y

requerimientos a nivel de participantes, de hardware y de software.

2. Plan de Iteración General

Este artefacto presenta el plan general del proyecto, incluyendo el conjunto de

actividades y tareas que serán realizadas para desarrollar el proyecto y la dependencia

69

entre ellas. Además se muestra el conjunto de actividades que se realizan en las

iteraciones de cada fase.

3. Plan de Administración 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 términos de consecuencia y

posibilidad.

El Plan de Administración de Riesgos tiene como propósito determinar las

estrategias para detección, análisis y jerarquización 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 específicas de contingencia o

para su mitigación.

La lista de riesgos no es un instrumento estático, é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 Administración.

- Riesgos de Conocimiento.

70

Cada riesgo será ponderado a fin de darle un lugar en la jerarquía. Sin

embargo hay que aclarar que la ponderación es dinámica y puede aumentar o

disminuir con el devenir del proyecto que se esté realizando.

Tareas de Administración de Riesgos

La gestión de riesgos se realiza cumpliendo con las siguientes actividades:

- Mediante entrevistas con los involucrados (usuarios y equipo de proyecto)

- Análisis de los requerimientos verificando las variables que atentarían contra

la salud del proyecto.

- Deducción de los riesgos para cada uno de los requerimientos en el contexto

del sistema.

- Categorización de los riesgos en cuanto a probabilidad de ocurrencia y

expectativas de pérdida en caso de ocurrencia.

- Establecimiento de las estrategias de administración de los riesgos

(mitigación, esquivamiento o prevención) para cada uno de los riesgos más

importantes.

- Ponderación de los riesgos con fines de jerarquización.

- Seguimiento de métricas asociadas a riesgos con el propósito de monitorear su

posible ocurrencia. Esto implica la revisión por iteración de las variables

involucradas y la evaluación del estado del proyecto en general en contraste

con los requerimientos principales.

Las tareas antes mencionadas deben ser llevadas principalmente por el Líder

del Proyecto. En caso de materializarse alguno de los riesgos el Líder del Proyecto

invoca los planes de gestión para el riesgo o grupo de riesgos con la finalidad de

incluir las tareas de tratamiento dentro de las actividades de los equipos.

71

Herramientas y Técnicas.

Para la elaboración de la lista de riesgos se puede utilizar la Tabla de

Documentación de Riesgos, la cual permite visualizar cada uno de los riesgos con sus

aspectos involucrados. Esta tabla puede ser observada a continuación:

Cuadro 3. Tabla Documentación de Riesgos. Identificador: (Número Secuencial)

Descripción: (Lista de cada riesgo mayor al cual se enfrenta el proyecto. Se describe cada riesgo en

la forma “condición – consecuencia”.

Probabilidad: (¿Cuál es la

probabilidad de que el riesgo se

convierta en un problema?)

Pérdida: (¿Cuál es el daño si

el riesgo se convierte en un

problema?)

Grado de Exposición:

(Multiplicación de la

probabilidad por la pérdida)

Primer Indicador: (Describe el indicador más temprano o condición de disparo que podría indicar

que el riesgo se está convirtiendo en un problema)

Estrategia de Mitigación: (Ponderación de uno o más enfoques para controlar, evitar, minimizar, o

en última instancia mitigar el riesgo.

Propietario: (Asignación de cada acción de

mitigación de riesgos a un individuo para su

resolución.)

Fecha Prevista: (Determinar una fecha

mediante la cual la estrategia de mitigación

será implementada)


En la medida en que las iteraciones vayan avanzando, entonces, el Líder de

Proyectos irá reevaluando la probabilidad de ocurrencia con el fin de modificar, si es

necesario, el grado de exposición y como consecuencia la jerarquización de los

riesgos.

4. Modelado del Negocio

El modelado del negocio tiene la finalidad de comprender y describir los

procesos de negocio de la organización bajo estudio, especificando sus datos,

72

actividades, tareas y los roles desempeñados. Este artefacto abarca el modelo del

negocio y el modelo del dominio de UML.

El modelo del negocio describe a través del modelo de casos de uso del

negocio las funciones o procesos de negocio de la empresa u organización en

términos de casos de uso y actores del negocio, con el fin de comprender cuáles serán

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 específicos para este modelo.

Por otro lado el modelo del dominio del negocio captura los objetos más

importantes en el contexto del sistema. Este modelo se describe mediante diagramas

de clases de UML, que carecen de algunos de los detalles técnicos y están

compuestos por las clases que se han interpretado y descubierto en el análisis del

negocio. Estos diagramas muestran los objetos del dominio o clases conceptuales y

las relaciones entre ellas a través de asociaciones.

5. Especificación 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. Además, en estas especificaciones se muestran los actores que

intervienen en cada uno de los casos de uso, los flujos básicos o normales, los

posibles flujos alternativos de eventos; también incluye su diagrama de actividad.

6. Documento Glosario

Es un documento que define los principales términos usados en el proyecto de

desarrollo de software. Este glosario es muy útil para alcanzar un consenso entre las

73

personas involucradas en el desarrollo del proyecto en cuanto a la definición 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 términos que no estén claros, que sean ambiguos o que requieran

alguna elaboración relevante.

7. Especificación de Casos de Uso del Sistema

Artefacto donde están 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, además 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 según 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 ningún 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 diseño físico, así como

las restricciones arquitectónicas, de diseño y de implementación. (Jacobson, Booch y

Rumbaugh, 2000, p. 121)

74

9. Arquitectura del Sistema

Este documento proporciona una descripción de la arquitectura del software a

desarrollar a través 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: lógica, de datos y de

despliegue.

10. Documento de Casos de Prueba

Este artefacto especifica una forma de probar el sistema, incluyendo

condiciones de ejecución, entradas de la prueba, resultados esperados y la evaluación

de la prueba. Además, 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 también 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 discriminación hacia

cada uno de los productos. Esta persistencia en los valores de los movimientos de

almacén 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 almacén, y evitar rupturas de stocks y paradas

innecesarias en la fábrica o empresa.

75

Para llevar este control es necesario contar, para cada bien del almacén, con

una ficha que recoja sus movimientos (denominada ficha de almacén o tarjeta de

existencia). En dicha tarjeta, se registra cada unidad, su valor de compra, la fecha de

adquisición, 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 diseñado para proporcionar a los gerentes

información ú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 exploración óptica en las cajas registradoras

han abaratado mucho la implementación 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, también 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

físico y una valuación del inventario. El conteo físico debe efectuarse al menos una

vez al año, para verificar la exactitud de los registros continuos.

Asimismo, el sistema de inventario permanente permite identificar o detectar

pérdidas y mermas de existencias en almacenes, al comparar el valor controlado de

las existencias finales (inventario registrado), con el valor real obtenido mediante

recuento físico. Las causas de dichas mermas pueden ser extravíos, robos, pérdidas en

manipulación, 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:

76

- Evita las pérdidas de tiempo de personal y el cierre de instalaciones que se

producen durante el proceso de recuento del inventario físico periódico. En el

sistema de inventario permanente se realizan recuentos fijos realizados por

personal cualificado de almacén en tiempos en que no tienen otras

actividades, lo cual asegura, además 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 reducción de

existencias en almacén, con la consiguiente reducción de costos asociados a

su mantenimiento (personal de almacén, seguros, necesidades de financiación,

entre otros).

3.2.5.1 Valuación de los inventarios en el sistema permanente

La valuación de los inventarios y la determinación del costo de venta por el

sistema permanente, tiene el inconveniente con los valores de las mercancías, puesto

que éstas se adquieren en fechas diferentes con precios diferentes, por lo que es

imposible tener una homogeneidad en los valores de las mercancías compradas. Para

evitar este problema, la valuación de los inventarios se realiza mediante diferentes

métodos que buscan determinar el costo de la forma más real, dependiendo del tipo

de empresa.

Entre los métodos de valuación existentes se encuentran: Método PEPS,

Método UEPS, Método del promedio ponderado, entre otros.

Determinación del Costo del Inventario por método PEPS

Muchas empresas tratan de vender los artículos en el orden en que los

compran. Ello resulta especialmente válido en el caso de los bienes perecederos y

77

otros cuyos estilos o modelos cambian con frecuencia. Por ejemplo, los abastos

colocan en sus estantes los productos lácteos 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 método

de primeras entradas, primeras salidas suele ser compatible con el movimiento o flujo

físico de las mercancías. Siendo éste el caso, el método PEPS genera resultados casi

iguales a los obtenidos identificando los costos específicos de cada artículo vendido y

existente en el inventario.

El método PEPS, consiste básicamente en darle salida del inventario a

aquellos productos que se adquirieron primero, por lo que en los inventarios quedarán

aquellos productos comprados más recientemente. Es decir, cada vez que se realiza

una venta o salida de artículo, 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 método de

determinación de costo es también conocido como FIFO, por sus siglas en ingles.

A continuación se ilustra un ejemplo de esta metodología, con los datos del

artículo 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.

78

En la cuenta puede verse el número de unidades en existencia después de cada

transacción, junto con los costos totales y unitarios. Se supone que las unidades se

venden en $30 cada una, a crédito 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 después de vender 7

unidades el 04 de Enero se tenían 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 después de la compra del 10 de Enero se presenta en

dos líneas, 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 más a $21. En este punto, hay 7 unidades en el inventario, con costo

de $21 por unidad. El resto de la ilustración se explica de manera similar.

En cualquiera de los métodos de determinación 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 operación, es decir se le da salida del inventario por

79

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 según el método de valuación de inventarios manejado por la empresa.

3.2.6 Pronósticos de demanda

Pronosticar es el arte y la ciencia de predecir los eventos futuros. Puede

implicar el uso de datos históricos y su proyección hacia el futuro mediante algún tipo

de modelo matemático. Puede ser una predicción subjetiva o intuitiva, o puede ser

una combinación de ambos, es decir, un modelo matemático ajustado por el buen

juicio del administrador.

Existen dos enfoques generales al pronosticar, uno es el análisis cuantitativo y

el otro el enfoque cualitativo. Los pronósticos cuantitativos utilizan una variedad de

modelos matemáticos que se apoyan en datos históricos o en variables causales para

pronosticar la demanda. Los pronósticos cualitativos o subjetivos incorporan aquellos

factores como la intuición, las emociones, las experiencias personales y el sistema de

valores de quien toma la decisión para llegar al pronóstico. Las empresas emplean

uno u otro enfoque, pero en la práctica la combinación de ambos es casi siempre más

efectiva.

Dentro de los métodos cuantitativos para pronóstico de demanda se encuentra

el análisis 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, etcétera).

El análisis de serie de tiempo es un método estadístico que depende en alto

grado de datos históricos de la demanda, con los que proyecta la magnitud futura de

la misma y reconoce las tendencias y patrones estacionales. Este método se emplea

80

más frecuentemente para elaborar pronósticos a corto plazo (0 a 3 meses), y es una

forma relativamente económica y precisa de generar el gran número de pronósticos

requeridos.

Ahora bien, dentro de este tipo de pronóstico, se encuentra el método de

promedio móvil 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 aplicación de un modelo de promedio móvil implica simplemente calcular la

demanda promedio para los n periodos más recientes, con el fin de usarla como

pronóstico para el siguiente periodo. Para el periodo siguiente, una vez que se conoce

la demanda real, la demanda más antigua incluida en el promedio anterior se sustituye

por la demanda más reciente y luego se vuelve a calcular el promedio. De esta

manera se usan las n demandas más recientes, por lo cual el promedio se “mueve” de

uno a otro periodo.

En el método de promedio móvil pueden incluirse todos los periodos

pretéritos de demanda que se desee. Generalmente, la estabilidad de la serie

correspondiente a la demanda determina cuántos 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 método de pronóstico) cambia

solamente en forma infrecuente. Deberán utilizarse valores grandes de n para las

series de demanda que sean estables, y valores pequeños 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 móvil. 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 pequeño de n. En la práctica ese valor va de 2 a 10.

81

3.2.7 Sistemas de información

Según Jonás Montilva (1992), un sistema de información “es un

conjunto organizado de hombres, máquinas, programas y procedimientos para llevar a cabo unas funciones que cumplan unos objetivos deseados”. (p.17) También establece que un sistema de información “…procesa datos a fin de registrar los detalles originados por las transacciones que ocurren y las entidades que forman una organización y proporcionar información que facilite la ejecución de actividades, operaciones y funciones en una organización” (p.18)

De acuerdo a lo establecido anteriormente, los sistemas de información se

encuentran dentro de un sistema mayor, denominado organización; y además están

compuestos de elementos que interactúan entre sí para brindar a quienes adoptan

decisiones, la información que requieren para desarrollar sus respectivas funciones y

así apoyar a las actividades de la empresa u organización.

Esta información que necesita la organización se obtiene a través de las cuatro

actividades básicas que realizan los sistemas de información. A continuación se

detallan cada una de ellas:

1. Entrada de Información

Es un proceso que consiste en capturar los datos en bruto tanto del interior de

la organización como de su entorno externo. Las entradas pueden ser manuales o

automáticas. Las manuales son aquellas que se proporcionan en forma directa por el

usuario (a través del teclado, el mouse, la voz, los monitores sensibles al tacto, código

de barras, entre otros), mientras que las automáticas son datos o información que

provienen o son tomados de otros sistemas.

82

2. Almacenamiento de la información

Es una de las actividades más importantes que tiene una computadora, ya que

a través de esta propiedad el sistema puede recordar la información guardada en el

proceso de entrada de información. Esta información suele ser almacenada en

estructuras de información denominadas archivos. La unidad típica de

almacenamiento son los discos magnéticos o discos duros, diskettes, los discos

compactos (CDs), discos versátiles digitales (DVDs), entre otros.

3. Procesamiento de la información

Es la capacidad del Sistema de Información para efectuar cálculos de acuerdo

con una secuencia de operaciones preestablecida. Estos cálculos pueden efectuarse

con datos introducidos recientemente en el sistema o bien con datos que están

almacenados. Esta característica de los sistemas permite la transformación de datos

fuente en información que puede ser utilizada para la toma de decisiones.

4. Salida de información

Es la capacidad de un sistema de información para sacar los datos procesados

al exterior. Esta actividad implica producir información útil, por lo general en forma

de documentos y/o reportes. En algunos casos, la salida de un sistema de información

puede constituir la entrada a otro sistema o módulo. La salida puede producirse por

diversos medios. En referente a las computadoras entre los dispositivos de salida más

comunes están las impresoras y la pantalla. Sin embargo, la salida también puede ser

un proceso manual, pues a menudo supone informes y documentos manuscritos

En la actualidad, los sistemas de información cumplen tres objetivos básicos

dentro de las organizaciones: automatizar procesos, proporcionar información que

sirva de apoyo para la toma de decisiones y alcanzar ventajas competitivas.

83

Con frecuencia, los sistemas de información que logran la automatización de

procesos operativos dentro de una organización son llamados Sistemas

Transaccionales, ya que su función principal consiste en procesar transacciones tales

como pagos, planillas, entradas, salidas, entre otros. Por otra parte, los sistemas de

información 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 estratégicos, los cuales se desarrollan en las

organizaciones con el fin de lograr ventajas competitivas, a través del uso de la

Tecnología de Información (TI).

3.2.8 Aplicación WEB

En la ingeniería software, una aplicación Web es aquella aplicación que puede

ser utilizada accediendo a un servidor Web a través de Internet o de una intranet

mediante un navegador. En otras palabras, es una aplicación software que se codifica

en un lenguaje soportado por los navegadores Web (como HTML, JavaScript, Java,

etc.) en la que se confía la ejecución al navegador.

Berzal y Cubero (2005) definen a los sistemas Web como: aquellas aplicaciones cuya interfaz se construye a partir de páginas Web. Las páginas Web no son más que ficheros de texto en un formato estándar 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 aplicación Web desde una maquina concreta basta con tener instalado un navegador Web en esa máquina, ya sea este el Internet Explorer de Microsoft, el Netscape Navigator o cualquier otro navegador. (p.187).

La mayoría de las aplicaciones Web reales utilizan tecnologías tanto del lado

del cliente como del lado del servidor. Utilizar unas u otras es una cuestión de diseño

que habrá de resolverse en función de lo que resulte más adecuado para satisfacer las

necesidades particulares de cada aplicación.

84

Las aplicaciones Web ofrecen grandes ventajas que pueden ser aprovechadas

por muchas organizaciones, sobre todo ahora que la globalización es una realidad.

Entre estas ventajas se encuentran:

Son fáciles de usar, no requieren conocimientos avanzados de computación.

Compatibilidad multiplataforma : Las aplicaciones Web tienen un camino mucho

más sencillo para la compatibilidad multiplataforma que las aplicaciones de

escritorio. Utilizan tecnologías como PHP, Java, Flash, ASP y AJAX que permiten un

desarrollo efectivo de programas soportando todos los sistemas operativos

principales.

Actualización: Pueden existir miles de clientes pero una única aplicación instalada en

un servidor, por lo tanto se puede actualizar y mantener una única aplicación y todos

sus clientes verán los resultados inmediatamente.

Inmediatez de acceso: Este tipo de aplicaciones no necesitan ser descargadas,

instaladas y configuradas, pues usan tecnología Web. Cualquier usuario puede

acceder a su cuenta online y estar listo para trabajar sin importar cual es su

configuración o su hardware (no necesita tener un ordenador de grandes prestaciones

para trabajar con la aplicación Web).

Alta disponibilidad , ya que se puede realizar consultas en cualquier parte del mundo

donde tenga acceso a Internet y a cualquier hora.

Múltiples usuarios concurrentes: Los sistemas Web pueden ser utilizados por

múltiples usuarios al mismo tiempo. No hay más necesidad de compartir pantallas o

enviar instantáneas cuando múltiples usuarios pueden ver e incluso editar el mismo

documento de manera conjunta.

85

3.2.9 HTML

HTML, acrónimo inglés de HyperText Markup Language (Lenguaje de

Marcas de Hipertexto), es el lenguaje de marcado predominante para la creación de

páginas 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 estándar reconocido en todo el mundo y cuyas normas las define una

organización sin ánimo de lucro llamado World Wide Web Consortium, más

conocido como W3C. Este organismo desarrolla los estándares para normalizar el

desarrollo y la expansión de la Web y publica las especificaciones relativas al

lenguaje HTML.

Cabe destacar, que HTML es un lenguaje de descripción de hipertexto

compuesto por una serie de comandos, marcas, o etiquetas, también denominadas

“Tags” que permiten definir la estructura lógica de un documento Web y establecer

los atributos del mismo (color del texto, contenidos multimedia, hipervínculos, etc.).

(Cobo y Gómez, 2005, p.57).

Ahora bien, un documento HTML es un archivo de texto plano (también

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

creación de sitios Web o edición de código 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.

86

En cuanto al nombre de los archivos escritos en lenguaje HTML, estos deben

tener la extensión html o htm, para que puedan ser visualizados en los navegadores.

Estos son los encargados de interpretar el código HTML de los documentos, y de

mostrar a los usuarios las páginas Web resultantes del código 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 lógica del documento HTML y se pueden aplicar distintos estilos al texto

(negrita, cursiva,...). Con ellas también se puede incluir imágenes, archivos

multimedia (gráficos, vídeo, audio) e hiperenlaces, que permitirán 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 parámetros

que pueden tomar algún valor. Las etiquetas, que muestran la estructura básica de un

documento HTML se representan en la siguiente figura:

Figura 28. Estructura Básica de un documento HTML. Fuente: Autor (2009).

Ninguno de estos elementos es obligatorio, pudiendo crear documentos

HTML sin incluir estas etiquetas de identificación. No obstante es altamente

recomendable la construcción de páginas HTML siguiendo esta estructura, para una

buena estructuración y legibilidad del código.

87

3.2.10 Tecnologías de Programación del lado del cliente

En la programación del lado del cliente, los programas residen junto a las

páginas Web en el servidor, pero son transferidos al cliente para que éste los ejecute.

Dentro de los lenguajes de programación 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 estándar del

European Computer Manufacturers Association (ECMA) en 1997, y poco después

también 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 estándar,

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 mayoría de los navegadores

actuales como Explorer o Firefox.

Este lenguaje es utilizado principalmente para crear páginas Web dinámicas;

presenta una sintaxis semejante a la del lenguaje Java y el lenguaje C. Dentro de sus

características más importantes se pueden mencionar las siguientes:

Es un lenguaje interpretado, es decir, no requiere compilación. Este lenguaje

funciona del lado del cliente; es el navegador del usuario el que se encarga de

interpretar el codigo JavaScript contenido en una página HTML y ejecutarlo

adecuadamente.

88

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 información de una página 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 página Web.

El código JavaScript puede enlazarse o añadirse a las páginas Web

proporcionando un control total y dinámico sobre ellas. También permite controlar,

hasta cierto punto, las aplicaciones que lo ejecutan, habitualmente los navegadores. El

código de este lenguaje se encierra entre etiquetas <script> y se incluye en cualquier

parte del documento. Aunque es correcto incluir cualquier bloque de código en

cualquier zona de la página, es recomendable definir el código JavaScript dentro de la

cabecera del documento (dentro de la etiqueta <head>). También 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 Tecnologías de Programación del lado del servidor

En la programación del lado del servidor, los programas son ejecutados por el

servidor y lo que envía al cliente es la respuesta o resultado de dicha ejecución.

Lenguajes como PHP o Perl pertenecen a esta categoría.

3.2.11.1 PHP

PHP (PHP Hypertext Preprocessor) es un lenguaje de programación que fue

creado por Rasmus Lerdorf en 1994 para la creación de contenidos Web dinámicos,

89

orientados principalmente a la conexión 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 páginas PHP funcionen, el servidor donde están alojadas

debe soportar PHP.

Los programas escritos en PHP son embebidos o incrustados directamente en

el código HTML y ejecutados por un servidor Web a través de un intérprete antes de

transferir al cliente que lo ha solicitado un resultado en forma de código HTML puro.

PHP puede trabajar con la totalidad de los servidores Web conocidos, pero lo más

habitual es encontrar PHP sobre un servidor apache.

El lenguaje PHP presenta las siguientes características:

a. Es un lenguaje multiplataforma; los programas funcionan bien sobre

diferentes plataformas, trabajando sobre la mayoría 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 fácil acceso

para todos.

c. Integración con varias bibliotecas externas, permite generar

documentos en PDF, también analizar código XML.

d. Capacidad de conexión con la mayoría de los manejadores de base de

datos existentes, principalmente con MySQL.

e. No requiere la definición de tipos de variables.

f. Permite las técnicas de programación orientada a objetos.

g. Es Soportado por una gran comunidad de desarrolladores; como

producto de código abierto. PHP goza de la ayuda de un gran grupo de

90

programadores, permitiendo que los fallos de funcionamiento se

encuentren y reparen rápidamente.

3.2.12 Servidor Web Apache

El servidor Apache es un servidor Web HTTP de código abierto y de

distribución libre desarrollado por la Apache Software Foundation cuyo objetivo es

servir o suministrar páginas Web a los clientes o navegadores Web que las solicitan.

Es el servidor Web más utilizado en el mundo y esto debido a sus características:

robustez, rapidez, multiplataforma (con versiones para Linux, Windows, Macintosh,

etc.), modularizable, dispone de módulos 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 acrónimo de Asynchronous JavaScript

and XML (JavaScript Asíncrono y XML). Este es una técnica de desarrollo Web, por

la cual se pueden crear aplicaciones Web más rápidas y cómodas para el usuario.

AJAX engloba a un conjunto de tecnologías que trabajan conjuntamente.

Estas son:

XHTML (o HTML) y hojas de estilos en cascada CSS, para la presentación de la

información, basada en estándares.

Document Object Model (DOM), para la interacción y manipulación dinámica de la

información presentada. Se accede a este con un lenguaje de script por parte del

usuario,

XML, XSLT y JSON , para el intercambio y la manipulación de la información

solicitada al servidor.

91

El objeto XMLHttpRequest , para intercambiar información asíncronamente con el

servidor Web.

Y JavaScript, para unir todas las demás tecnologías.

En las aplicaciones construidas con AJAX se elimina la recarga constante de

paginas mediante la creación 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 comunicación asíncrona con el servidor en segundo plano. De esta

forma es posible realizar cambios sobre las páginas sin necesidad de recargarlas, lo

que significa aumentar la interactividad, velocidad y usabilidad en las aplicaciones.

Por ejemplo, al rellenar un formulario de una página Web, con AJAX se puede

actualizar la parte en la que se elige el país de residencia sin tener que actualizar toda

la página 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 sistemáticamente para su posterior uso. En la

actualidad, estas son esenciales para la supervivencia de cualquier organización, pues

los datos estructurados constituyen un recurso básico para todas las organizaciones.

También, éstas juegan un papel esencial en el desarrollo de aplicaciones Web debido

a que muchas de las páginas Web a las que se acceden habitualmente, a través de

internet, se generan como resultado de una consulta a una base de datos, poniendo de

manifiesto su carácter dinámico. Algunas razones que justifican su uso son su

capacidad para almacenar grandes volúmenes de información, la optimización de su

gestión, la facilidad para realizar consultas y la exactitud, rapidez y fiabilidad en su

administración.

92

3.2.14.1 Arquitectura de la Base de datos

El comité de planeación y requisitos de estándares del Instituto Nacional

Norteamericano de Estándares (ANSI/SPARC) ha establecido una arquitectura de tres

niveles para un DBMS: interno, conceptual y externo.

Nivel interno: el nivel interno determina dónde se almacenan realmente los datos en

el dispositivo de almacenamiento. Este nivel trata con métodos de acceso de bajo

nivel y cómo se transfieren los bytes hacia y desde el dispositivo de almacenamiento.

En otras palabras, el nivel interno interactúa directamente con el hardware.

Nivel Conceptual: el nivel conceptual, o comunitario, define el punto de vista lógico

de los datos y los diagramas de esquemas. Las funciones principales del DBMS están

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 interactúa directamente con el usuario (usuarios

finales o programas de aplicación). 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 lógico y de vistas de una base de datos es necesario

hacer uso de un modelo de datos. Un modelo de datos no es más que un conjunto de

herramientas conceptuales que sirven para describir los datos, sus relaciones, su

semántica y sus limitaciones. El modelo de datos que ha tenido mayor aceptación es

el Modelo Relacional.

93

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 características:

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 relación 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 inequívocamente 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 definición de vínculos de

tipo jerárquico entre ellas. El vínculo de referencia entre dos tablas se

establece mediante columnas de idénticos 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 característica importante conviene observar que es la propia

información 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 actúa como un

94

intermediario entre los usuarios y los datos. Este, se compone de un lenguaje de

definición de datos, de un lenguaje de manipulación 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 mayoría de estas funciones son

transparentes para los usuarios finales, y casi todas pueden realizarse sólo mediante

un SGBD. Estas funciones incluyen la administración de un diccionario de datos, la

administración del almacenamiento de datos, transformación y presentación de los

datos, administración de la seguridad, control de acceso a usuarios múltiples,

administración de respaldos y recuperación, administración de la integridad de los

datos, lenguajes de acceso a base de datos e interfaces de programación de

aplicaciones e interfaces de comunicación con base de datos. (Rob y Coronel, 2004,

p. 21).

Existe una gran variedad de herramientas para manejo de bases de datos y

prácticamente la totalidad de ellas trabajan con SQL (Structured Query Language o

Lenguaje Estructurado de Consultas), que es el lenguaje de programación de las bases

de datos, y es el más utilizado para construir las consultas a bases de datos

relacionales. Los distintos gestores se valen de SQL para realizar las distintas

operaciones de búsqueda, interrelación, presentación, etc. Así pues se puede trabajar

directamente con las bases de datos mediante SQL, aunque resulta mucho más fácil e

intuitivo realizar este trabajo a través 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 más

95

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 gestión de bases de datos relacionales (RDBMS) que proporciona, además

de un motor de base de datos, numerosas herramientas para el usuario, el

desarrollador y el administrador. Estas herramientas emplean un lenguaje común:

SQL.

Oracle permite gestionar los datos de una aplicación basándose en una lógica

que se ha convertido en un estándar: el modelo relacional. Con Oracle, se puede

asociar al SQL un lenguaje procedimental, el PL/SQL, que añade numerosas

posibilidades para la manipulación de los datos.

Desde la versión 8i, el sistema de gestión de bases de datos de Oracle

propone, como opción, un nuevo método de gestión de la información en la empresa

a través de la implementación del modelo objeto-relacional. El objetivo de este

método es simplificar el modelado de los datos permitiendo el almacenamiento y la

manipulación de nuevos tipos de datos. Estos objetivos reutilizables, propios de cada

sector de actividad o de cada empresa, deben permitir un modelado más eficiente.

La implantación de este modelo a través de las extensiones del lenguaje SQL

permite una migración 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 técnicas estándar (modelado de

aplicación a través de UML, técnicas de modelado de procesos empresariales y

técnicas tradicionales de modelado de base de datos) junto con las herramientas líder

96

de desarrollo (como .NET, Sybase WorkSpace, Sybase Powerbuilder, Java y Eclipse),

con el fin de ofrecer soluciones de análisis de negocio y diseño de bases de datos

formales al ciclo de vida tradicional para el desarrollo de software. Y además

funciona con la mayoría de los sistemas manejadores de bases de datos relacionales

de hoy en día.

Entre otras características, esta herramienta permite generar de manera rápida

los diagramas UML (diagramas de casos de uso, de actividades, de clases, de

secuencia, de paquetes, etc.) para representar los requisitos y el diseño de la

arquitectura del sistema. También, permite diseñar y generar el esquema de la base de

datos a través del modelamiento conceptual y físico de las bases de datos

relacionales.

3.2.17 Macromedia Dreamweaver 8

Dreamweaver 8 es un editor de HTML, diseñado para desarrolladores

profesionales, para diseñar, codificar y desarrollar sitios, páginas y aplicaciones Web.

Esta herramienta permite crear sitios de forma totalmente gráfica, a través de un

entorno de edición visual; y dispone de funciones para acceder al código HTML

generado.

Las funciones de edición visual de Dreamweaver permiten crear páginas de

forma rápida, sin escribir una sola línea de código, ya que se pueden visualizar todos

los elementos del sitio y se pueden arrastrar desde un panel fácil de usar directamente

hasta un documento. Dreamweaver también ofrece un entorno de codificación con

todas las funciones, que incluye herramientas para la edición de código (tales como

coloreado de código y terminación automática de etiquetas) y material de referencia

de lenguajes sobre hojas de estilos en cascada (CSS), JavaScript, y ColdFusion

Markup Language (CFML), entre otros.

97

Además del código HTML, Dremweaver puede administrar hojas de estilos

CSS y darle dinamismo a las páginas con JavaScripts. También integra un cliente

FTP (File Tranfer Protocol) para descargar los sitios Web en un servidor y permite

integrar todas las funciones para crear sitios dinámicos, basados en bases de datos y

empleando tecnologías de servidor como CFML, ASP.NET, ASP, JSP y PHP.

3.2.18 XAMPP

XAMPP es software libre y es el acrónimo 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

intérpretes para los lenguajes PHP y Perl. También incluye otros módulos como

OpenSSL y phpMyAdmin. Este programa es independiente de la plataforma en la

cual se está ejecutando y está liberado bajo la licencia GNU. Además, actúa como un

servidor Web libre, fácil de usar y capaz de interpretar páginas Web dinámicas.

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, según la cual el autor cede una serie de libertades básicas al usuario en el

marco de un acuerdo de concesión. Estas libertades de los usuarios del software,

recogidas en la filosofía de la Fundación para el Software Libre (Free Software

Foundation), son: la libertad de usar el programa con cualquier propósito; la libertad

de estudiar cómo funciona el programa y adaptarlo a sus necesidades; la libertad de

distribuir copias; y la libertad de mejorar el programa y hacer públicas las mejoras a

los demás, de modo que toda la comunidad se beneficie. (Martínez, J, 2007, pp. 15-

16).

98

Estas libertades del software libre tienen como consecuencia que la persona

que utilice este tipo de programas informáticos estará a salvo de ser controlado por

otros a través de esos programas. Ya que podrá utilizar los programas para lo que

quiera, de forma legal y libremente. Así como también estudiar cómo 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. Además, podrá distribuir esos programas informáticos a los

demás de forma legal y, por lo tanto, no se verá inmerso en dilemas morales entre la

ley y su propio espíritu de colaboración. 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 Administración Pública

Nacional Venezolana. Más específicamente en su primer artículo:

Artículo 1. La Administración Pública Nacional empleará prioritariamente Software Libre desarrollado con Estándares Abiertos, en sus sistemas, proyectos y servicios informáticos. A tales fines, todos los órganos y entes de la Administración Pública Nacional iniciarán los procesos de migración gradual y progresiva de éstos hacia el Software Libre desarrollado con Estándares Abiertos.

De esta manera, el Ejecutivo nacional establece que es prioridad del Estado

incentivar y fomentar la producción de bienes y servicios para satisfacer las

necesidades de la población, mediante el uso de estas herramientas desarrolladas con

estándares abiertos para robustecer la industria nacional, aumentando y aprovechando

sus capacidades y fortaleciendo la soberanía del país.

99

3.4 Definición de Términos

Arquitectura: Estructura organizativa que incluye su descomposición en partes,

conectividad, mecanismos de interacción y principios de guía que proporcionan

información sobre el diseño del mismo. (Jacobson, Booch y Rumbaugh, 2000, p.

130).

Artefacto: Pieza de información 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 descripción o un software. (Jacobson, Booch y Rumbaugh,

2000, p. 131).

Base de Datos: Colección de datos interrelacionados que son almacenados en un

soporte informático. (Cobo y Gómez, 2005, p.316).

Sistema gestor de base de datos: Paquete de software para la gestión 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 definición y manipulación de datos para bases de datos

relacionales. Es un lenguaje de definición porque permite definir la estructura de las

tablas que componen la base de datos, y de manipulación porque permite efectuar

consultas y realizar operaciones como inserción, borrado, y actualización de los datos

que contiene. (Cobo y Gómez, 2005, p.316).

Caso de uso: Es una secuencia de acciones que el sistema lleva a cabo para ofrecer

algún 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).

100

Cliente: Equipo que los usuarios individuales utilizan para conectarse a la red y

solicitar servicio a los servidores. (Cobo y Gómez, 2005, p.6).

Navegador Web: Programa informático que permite la comunicación con un

servidor para acceder a los recursos de internet e interpretar las etiquetas de los

documentos HTML. (López y Alonso, 2007, p. 105).

Servidor Web: Máquina 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).

101

CAPITULO IV

MARCO METODOLÓGICO

En este capítulo se detalla la metodología que permitió llevar a cabo el

desarrollo de la investigación. Es decir, en esta sección se describe la manera como se

realizó el estudio para responder al problema planteado, incluyendo aspectos como el

tipo, nivel y diseño de la investigación, la población y muestra objeto de estudio, y las

técnicas empleadas para recolectar y analizar los datos.

4.1 Tipo y Nivel de la Investigación.

El tipo de investigación queda definido en correspondencia con el objetivo

general del trabajo investigativo, por tal razón se puede afirmar que el trabajo

desarrollado es de tipo proyectivo, dicha valoración se hace teniendo presente la

definición dada por Hurtado (2000) la cual expresa que esta es:

…la elaboración de una propuesta o de un modelo como solución a un problema o necesidad de tipo práctico… a partir de un diagnóstico preciso de las necesidades del momento, los procesos explicativos o generadores involucrados y las tendencias futuras. (p. 325).

Por otra parte también señala la autora citada que “La investigación proyectiva

se ocupa de… diseñar o crear propuestas dirigidas a resolver determinadas

situaciones” (p. 49). Se puede inferir de las citas realizadas que una investigación

proyectiva busca dar una alternativa de solución a los estados problemáticos que se

plantean.

En correspondencia con el tipo, el nivel al cual pertenece la investigación es el

Nivel Comprensivo, debido a que ésta busca los orígenes de la problemática, sus

102

efectos y lo compara con otros hechos ocurridos para determinar los factores

causantes de la situación. Según Hurtado (2000) el nivel comprensivo “alude a la

explicación de las situaciones o causas que generan eventos” (p.71).

4.2 Diseño de la Investigación

El diseño de investigación constituye el plan general del investigador para

obtener respuestas a sus interrogantes o comprobar la hipótesis de investigación. Para

Namakforoosh (1995) citado por Hurtado, el diseño de la investigación es un “arreglo

de condiciones para recopilar la información de modo que permita alcanzar el

objetivo de la investigación a través de un procedimiento económico” (p. 149) El

diseño de investigación desglosa las estrategias básicas que el investigador adopta

para generar información exacta e interpretable. Hurtado (Ob.Cit.) señala que:

…corresponde a la estructura de la investigación, a la forma como la investigación va a ser desarrollada, a la manera como la indagación es concebida a fin de obtener respuestas a las interrogantes...además le señala al investigador lo que tiene que hacer y cómo hacerlo.... (p.407).

En correspondencia con la definición antes citada el diseño de la presente

investigación corresponde a una investigación de campo. La cual es definida por

Arias, F. (2006) como:

Aquella que consiste en la recolección 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 información pero no altera las condiciones existentes. (p.31).

Para este proyecto, los datos fueron recogidos directamente del comedor

universitario; es decir, la información fue suministrada principalmente por el personal

que labora en el área administrativa del comedor universitario de la Universidad de

Oriente Núcleo de Monagas. Pues ellos son los encargados de realizar todos los

103

procedimientos para la prestación del servicio de alimentación y por lo tanto conocen

a detalle el funcionamiento del área bajo estudio.

Además, la información pudo ser recabada de material impreso y electrónico, 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 investigación de campo también se emplean datos secundarios, sobre todo los provenientes de fuentes bibliográficas a partir de los cuales se construye el marco teórico. No obstante, son los datos primarios obtenidos a través del diseño de campo, los esenciales para el logro de los objetivos y la solución del problema planteado. (p.31).

4.3 Población y Muestra.

La población, según Arnau, J. (1981) “se refiere al conjunto de elementos,

seres o eventos, concordantes entre sí en cuanto a una serie de características, de los

cuales se desea obtener alguna información.” (p.248). En efecto, la población objeto

de estudio en esta investigación es finita, conocida y está representada por cinco (5)

individuos que laboran en la área administrativa del comedor universitario de la UDO

núcleo de Monagas. Este conjunto de personas son las encargadas de llevar a cabo las

actividades y procedimientos administrativos para prestar el servicio de alimentación

y conocen la realidad del área bajo estudio; por lo tanto son las más idóneas para ser

seleccionadas con el fin de estudiarlas y obtener de ellas la información necesaria

para el desarrollo del nuevo sistema de información automatizado.

Una vez determinada con precisión las unidades de estudio que conforman a

la población o universo de investigación, se procede a delimitar la muestra. Moreno,

M. (1993) expresa que “la muestra es una parte de la población en estudio,

seleccionada de manera que en ella queden representadas las características que

distinguen a la población de la que fue tomada” (p. 9). Sin embargo, Arias, F. (2006)

104

comenta lo siguiente: “Si la población, por el número 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 población objetivo.” (pp.

82-83).

En tal sentido, por ser la población objeto de estudio finita y pequeña, 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 población, es decir, la muestra tendrá

un tamaño de cinco (5) individuos o empleados del área administrativa del comedor

universitario de la Universidad de Oriente núcleo de Monagas, entre los cuales se

mencionan: el administrador del área, el nutricionista, la secretaria y los encargados

del almacén o despensa.

4.4 Técnicas e Instrumentos de Recolección de Datos.

Las técnicas de recolección de datos son las distintas formas o maneras de

obtener la información que será de utilidad para un estudio en particular. En el caso,

de la investigación realizada para llevar a cabo el desarrollo de un sistema Web para

la Planificación y el control del servicio de alimentación de la Universidad de Oriente

Núcleo de Monagas se emplearon distintas técnicas para recabar información, como

la observación directa, la entrevista no estructurada, la revisión documental; con el fin

de estudiar los distintos aspectos del problema y alcanzar los objetivos propuestos.

Con respecto a la técnica de observación directa, Tamayo y Tamayo (2003)

establecen que “es aquella en la cual el investigador puede observar y recoger datos

mediante su propia observación.” (p.183). En esta investigación se realizó

observación directa en el área de trabajo para obtener algún tipo de información sobre

el funcionamiento de los procesos administrativos llevados a cabo para la prestación

del servicio de alimentación de la Universidad de Oriente Núcleo de Monagas.

105

También, para obtener información 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 guía 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 investigación, el entrevistador preparó

previamente una especie de guía con los puntos básicos sobre los cuáles necesitaba

recabar información. 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 técnicas ya mencionadas se utilizó la revisión documental o

análisis de fuentes documentales, para complementar el trabajo de recolección y

ayudar a asegurar una investigación completa. Para Hurtado, J. (2007) esta técnica

“es un proceso mediante el cual el investigador recopila, analiza, selecciona y extrae

información de diversas fuentes, acerca de un tema en particular, con el propósito de

llegar al conocimiento y comprensión más profundo del mismo”. (p. 89). En lo que

respecta a esta investigación, se consultaron fuentes bibliográficas, 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 información que aportara los conocimientos

necesarios para llevar a cabo el desarrollo de este proyecto.

4.5 Técnicas de Análisis de Datos.

Para el análisis e interpretación de la información recolectada fue necesario

emplear el Análisis de Contenido. Esta técnica, según Hurtado, J. (2007) puede ser

utilizada en investigaciones descriptivas, cuando se pretende hacer un diagnóstico y

agrupar contenidos significativos de una serie de entrevistas, conversaciones u

observaciones (p. 57). Esto sirvió para organizar la información extraída, y así

106

describir aspectos importantes para dar respuesta a algunos de los objetivos

planteados.

4.6 Diseño Operativo.

Para llevar a cabo la investigación y lograr los objetivos planteados, se utilizó

la metodología RUP como guía 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 metodología se busca desarrollar de manera ordenada y eficiente

un sistema Web para la planificación y control del servicio de alimentación prestado

por el comedor universitario de la Universidad de Oriente Núcleo de Monagas.

Cabe agregar, que junto a la metodología RUP se empleó la herramienta

UML, para realizar el modelado del sistema a través de los diferentes diagramas que

este ofrece. Además, para desarrollar el sistema se siguieron las tres primeras fases en

la que la metodología RUP divide el proceso de desarrollo de software, abarcando

solo tres (3) iteraciones de la tercera fase (fase de construcción), por lo que a pesar de

llegar hasta esta fase no se realizó la codificación completa del sistema.

A continuación se presenta la descripción 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 dinámica de la organización bajo estudio, y también 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

107

aplicando, además, 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 organización y los actores involucrados.

También abarca el modelo del dominio que captura los objetos más importantes en el

contexto del sistema; y emplea los diagramas de actividad y de clases de la

herramienta UML.

Además, en esta etapa se define el alcance del proyecto, se realiza una

estimación del tiempo para realizar el proyecto y una lista de riesgos que pudieran

obstaculizar el desarrollo del nuevo sistema. También, se define el prototipo de

interfaz de usuarios, que es el medio a través del cual los usuarios podrán 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 iteración.

- Un documento visión, donde están definidas las características del producto a

desarrollar.

- Modelo del negocio.

- Especificación de casos de uso del negocio.

- Documento plan de riesgos.

La consecución de las actividades descritas anteriormente permitió alcanzar

los objetivos uno, y dos del proyecto. Lo que dio a conocer cómo funciona

actualmente el área bajo estudio, determinando su problemática actual y

estableciendo así el alcance del proyecto.

108

Etapa II. Diseño 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 además los requisitos de calidad del software. También se diseña la

arquitectura del sistema a través de la elaboración de modelos de diseños en UML,

como los diagramas de clases y diagramas de despliegue.

En esta etapa se obtienen los siguientes resultados o artefactos:

- Especificación de casos de uso del sistema.

- Especificaciones complementarias.

- Arquitectura del sistema.

Con la realización 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. Construcción del Software

En esta última etapa se lleva a cabo, de forma iterativa, la codificación del

sistema de acuerdo al diseño realizado del mismo, de tal manera que cumpla con los

requisitos establecidos. También, se refinan los casos de uso y se realizan pruebas a

los módulos del sistema que fueron codificados, para comprobar el buen

funcionamiento de los mismos.

Con la realización de las actividades anteriores se logró alcanzar el último

objetivo del proyecto. Obteniendo los siguientes resultados:

- Un prototipo inicial del sistema.

109

- Documento de casos de prueba

- Documento glosario.

A continuación 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 específicos establecidos:

110

Cuadro 4. Cuadro Operativo

Etapas Objetivos Específicos Metodología

RUP Actividades Asociadas

Etapa I:

Estudio del

Negocio

- Describir el

funcionamiento actual de

los procesos llevados a cabo

dentro del servicio de

alimentación prestado por la

Universidad de Oriente

Núcleo de Monagas.

- Determinar los problemas

y necesidades actuales

relacionados con la

planificación y control del

servicio prestado por el

comedor universitario.

Inicio

- Realizar entrevistas no

estructuradas al personal del

área administrativa de

comedor.

- Observación directa del

área bajo estudio.

- Revisión de documentos.

- Realizar el modelado del

negocio y las

especificaciones de casos de

uso del negocio.

- Elaborar los documentos

visión, plan de riesgos y plan

de iteración.

- Realizar prototipos de

interfaces de usuario.

Etapa II:

Diseño de la

Arquitectura

- Definir los requerimientos

de información del sistema,

a través del estudio

realizado al comedor

universitario y

considerando las

necesidades de los usuarios

del área administrativa del

mismo.

- Diseñar una arquitectura

sólida para el sistema, que

cumpla con los

requerimientos definidos.

Elaboración

- Elaborar las

especificaciones de casos de

uso del sistema.

- Especificaciones

complementarias.

- Arquitectura del software.

111

Cuadro 4. Cuadro Operativo (Continuación)

Etapas Objetivos Específicos Metodología

RUP Actividades Asociadas

Etapa III:

Construcción

del Software

- Construir un prototipo

inicial, de acuerdo a la

arquitectura diseñada y a

los requisitos especificados

del sistema.

Construcción

- Refinamiento de casos de

uso del sistema.

- Prototipo inicial del

sistema.

- Elaborar casos de prueba.

- Documento glosario.


112

CAPITULO V

RESULTADOS

En este capítulo se contemplan los resultados obtenidos, luego de haber

aplicado la metodología RUP como proceso de desarrollo de software para el logro de

los objetivos propuestos en el presente trabajo de investigación. Antes de presentar en

detalle estos resultados, se muestra un resumen de estos por cada uno de los objetivos

específicos establecidos:

- Para describir el funcionamiento actual del comedor universitario, fue

necesario aplicar una serie de técnicas de recolección de datos, como la

entrevista no estructura, la observación directa y revisión documental. Con

dicha información recabada, fue realizado el documento modelado del

negocio, donde se describió de manera general, a través 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. Además, cada uno de los procesos

identificados fueron descritos de manera detallada en el artefacto

especificación de casos de uso del negocio; entre estos procesos se

encuentran: planificar menús alimentarios, realizar pedidos de insumos,

registrar las entradas de insumos en almacén, solicitar los insumos requeridos

en la despensa para preparar el menú del día, registrar el acceso de

comensales al área de servicio y realizar reportes mensuales de costos.

- También 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 planificación y control

del servicio de alimentación. Para esto se realizó el artefacto denominado

113

documento visión, en el que además de exponerse la problemática presentada

en el área objeto de estudio, se fijó una visión del producto, especificando las

necesidades y características del mismo. Además se crearon los artefactos

plan de iteración general y plan de administración de riesgos, donde se

estableció la planificación del conjunto de actividades involucradas para el

desarrollo del proyecto de software y la gestión de los riesgos que pudieron

afectar la correcta realización del mismo.

- La definición de los requisitos de información del sistema, se logró a través de

la elaboración de los artefactos de especificación de casos de uso del sistema;

los cuales permitieron capturar y analizar los requisitos funcionales, a través

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 menús alimentarios, elaborar planificación

alimentaria, generar hoja de pedido, registrar existencia de artículo, registrar

entrada y salida de artículos de almacén, generar resumen de costos, elaborar

y consultar solicitudes del servicio del comedor, controlar acceso de

comensales, administrar usuarios del sistema y autenticar usuario. Además de

estos, fueron definidos otros requisitos adicionales (principalmente, requisitos

no funcionales) en el documento de especificaciones suplementarias, los

cuales fueron clasificados según el modelo FURPS+ (funcionalidad,

usabilidad, confiabilidad, desempeño, capacidad de soporte, entre otros).

- Por su parte, el diseño arquitectónico del software quedó plasmado en el

artefacto Arquitectura del sistema. Dicho diseño se realizó empleando

diferentes vistas o modelos que muestran diferentes aspectos de la

arquitectura del sistema; entre los que se mencionan: la vista lógica que

muestra las clases, sus relaciones, operaciones y atributos más 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, físico

114

y de base de datos relacional; y por último, la vista de despliegue, que muestra

la parte física de la arquitectura.

- Luego, a partir de la arquitectura diseñada, se procedió a la codificación de

algunas de las funcionalidades del sistema empleando ciertas herramientas de

programación y desarrollo WEB, como el lenguaje HTML, JavaScript, PHP,

AJAX, la aplicación Macromedia Dreamweaver, servidor Web Apache, el

manejador de base de datos ORACLE, entre otros. Y seguidamente, se

realizaron pruebas a los módulos programados del software para comprobar el

correcto funcionamiento de los mismos. Todo esto con el fin, de cumplir con

el último objetivo de la investigación, 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 planificación y control del servicio de alimentación prestado por

el comedor universitario de la Universidad de Oriente Núcleo 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 interactúan con el mismo (personas, sistemas,

etc.). Para esto, se emplearon las técnicas de recolección de datos, como las

entrevistas no estructuradas, la observación directa y la revisión documental.

Con ayuda de las entrevistas no estructuras se pudo conocer directamente de

los empleados y trabajadores del comedor universitario la situación actual de dicha

área, detectando además la problemática y las necesidades que se presentan al prestar

el servicio de alimentación a la comunidad universitaria. En combinación con esta

técnica se utilizó la observación directa, la cual permitió visualizar como el personal

115

del comedor universitario realizaba sus labores cotidianas, con la finalidad de

entender su funcionamiento. Además, se realizó la revisión documental del manual de

organización 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 información obtenida a través de la combinación de las técnicas

antes mencionadas, sirvió para elaborar el documento modelado del negocio y sus

respectivas especificaciones de casos de uso; y el documento visión, donde se

establece el alcance y por ende los requerimientos del sistema. Además de estos, se

pudieron generar otros documentos o artefactos de la metodología RUP, los cuales

son detallados a continuación:

UDO - DIRECCIÓN DE COMPUTACIÓN

116

PROYECTO: SISTEMA WEB PARA LA PLANIFICACION Y CONTROL DEL SER VICIO DE ALIMENTACION PRESTADO POR EL COMEDOR UNIVERSITAR IO


Plan de Iteración General

Versión 1.0

UDO - DIRECCION DE COMPUTACION

PROYECTO: Sistema Web para la Planificación y Control del Servicio de Alimentación Prestado por el Comedor Universitario de la Universidad de Oriente Núcleo de Monagas.

VERSIÓN: 1.0

FECHA : Marzo 2009 NOMBRE DEL DOCUMENTO: Plan de Iteración General.

Confidencial UDO - Centro de Computación Pág. 117

Plan de Iteración 1. Plan

1.1 Plan General

Cuadro 5. Plan General PROYECTO: Desarrollo de un sistema Web para la planificación y control del servicio

de alimentación prestado por el comedor universitario de la universidad de oriente núcleo de Monagas.

Fecha Inicio: 24/03/2008 Fecha Final: 19/06/2009 ITERACIÓN PROCESO FECHA

INICIO FECHA FINAL

ITERACIÓN 1 Documento Visión, Lista de Riesgos y Plan de Iteración General.

21/04/08 27/05/08

ITERACION 2 Administrar insumos. Administrar menús alimentarios.

28/05/08 09/07/08

ITERACIÓN 3 Planificación alimentaria. 10/07/08 25/09/08 ITERACIÓN 4 Elaborar y consultar solicitudes de servicio del

comedor universitario. Controlar acceso de comensales, Registrar Stock de artículos en almacén.

26/09/08 06/11/08

ITERACIÓN 5 Registrar Entrada de artículos en almacén. 07/11/08 18/12/08 ITERACIÓN 6 Registrar Salida de artículos en almacén. 19/12/08 13/02/09 ITERACIÓN 7 Generar Resumen de Costos. Administrar

usuarios. Autenticar usuario. 16/02/09 27/03/09

ITERACIÓN 8 Mantenimientos y configuración de semanas. Administrar insumos. Administrar menús alimentarios.

30/03/09 24/04/09

ITERACIÓN 9 Planificación alimentaria. Elaborar y consultar solicitudes de servicio del comedor universitario.

27/04/09 22/05/09

ITERACIÓN 10

Controlar acceso de comensales. Administrar usuarios. Autenticar usuario.

25/05/09 19/06/09




VERSIÓN: 1.0



1.2 Plan fase

Diagrama 1. Plan de Fase. Fuente: Autor (2008).



VERSIÓN: 1.0



1.3 Plan fase por Iteraciones

Diagrama 2. Segunda Iteración. Fuente: Autor (2008).

Diagrama 3. Tercera Iteración. Fuente: Autor (2008).



VERSIÓN: 1.0



Diagrama 4. Cuarta Iteración. Fuente: Autor (2008).

Diagrama 5. Quita Iteración.




VERSIÓN: 1.0



Diagrama 6. Sexta Iteración.


Diagrama 7. Séptima Iteración.




VERSIÓN: 1.0



Diagrama 8. Octava Iteración.


Diagrama 9. Novena Iteración.




VERSIÓN: 1.0



Diagrama 10. Décima Iteración.




VERSIÓN: 1.0



1.4 Plan de Reuniones

Cuadro 6. Cronograma de Reuniones


2 Recursos

Se necesita realizar reuniones con los clientes y responsables del proyecto

para definir las bases de desarrollo del proyecto.

3 Criterio de Evaluación

Se evaluará el lapso de tiempo que abarcará el sistema Web para la

Planificación y Control del Servicio de Alimentación prestado por el comedor

Universitario.

CRONOGRAMA DE REUNIONES PROYECTO: Desarrollo de un sistema Web para la planificación y control del servicio de

alimentación prestado por el comedor universitario de la universidad de oriente núcleo de Monagas.

ITERACION PROCESO FECHA INICIO

FECHA FINAL

ITERACIÓN 1 Documento Visión, Lista de Riesgos y Plan de Iteración General.

26/05/08 27/05/08

ITERACION 2 Administrar insumos. Administrar menús alimentarios.

27/06/08 27/06/08

ITERACIÓN 3 Planificación alimentaria. 11/08/08 11/08/08 ITERACIÓN 4 Elaborar y consultar solicitudes de servicio del

comedor universitario. Controlar acceso de comensales, Registrar Stock de artículos en almacén.

27/10/08 27/10/08

ITERACIÓN 5 Registrar Entrada de artículos en almacén. 08/12/08 08/12/08 ITERACIÓN 6 Registrar Salida de artículos en almacén. 03/02/09 03/02/09 ITERACIÓN 7 Generar Resumen de Costos. Administrar usuarios.

Autenticar usuario. 17/03/09 17/03/09

ITERACIÓN 8 Mantenimientos y configuración de semanas. Administrar insumos. Administrar menús alimentarios.

07/04/09 07/04/09

ITERACIÓN 9 Planificación alimentaria. Elaborar y consultar solicitudes de servicio del comedor universitario.

05/05/09 05/05/09

ITERACIÓN 10 Controlar acceso de comensales. Administrar usuarios. Autenticar usuario

02/06/09 02/06/09


125



Documento Visión Versión 1.0



VERSIÓN: 1.0

FECHA : Noviembre 2008 NOMBRE DEL DOCUMENTO: Documento Visión.


Visión

1. Introducción

1.1 Propósito

El propósito de este documento es la recolección, análisis y definición de las

características y necesidades para el desarrollo de un Sistema Web para la

Planificación y Control del Servicio de Alimentación Prestado por el Comedor

Universitario de la Universidad de Oriente Núcleo de Monagas. Con esto, el presente

documento servirá de soporte para la ejecución de dicho proyecto.

1.2 Alcance

Este documento se ocupa del sistema automatizado para la Planificación y

Control del Servicio de Alimentación Prestado por el Comedor Universitario de la

Universidad de Oriente Núcleo 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 creación y mantenimiento de los insumos y menús alimentarios;

considerando la información nutricional de los alimentos. Se podrá realizar la

planificación alimentaria de cada semana y generar la lista de los insumos requeridos

para la preparación de los menús planificados. También, permitirá el registro de

comensales que acceden al comedor para aprovechar el servicio de alimentación,

elaborar solicitudes de servicio del comedor en caso de eventos especiales, y además

controlar las entradas y salidas de insumos del almacén o despensa.



VERSIÓN: 1.0



2. Posicionamiento

2.1 Oportunidades de Negocio:

Las oportunidades que se presentan con el desarrollo de este proyecto son:

1. Agilizar el proceso de planificación alimentaria. En éste se podrá programar

menús variados, considerando los valores nutricionales requeridos para el

buen desempeño de los estudiantes en sus actividades académicas.

2. Controlar el acceso de comensales al área de comedor, a través de un registro

automatizado de cada estudiante que ingresa al mismo para el

aprovechamiento del servicio de alimentación.

3. Contar con estimaciones más certeras del número de estudiantes que asistirán

al comedor para realizar una planificación de comidas más aproximada a la

realidad.

4. Mayor disponibilidad y seguridad de la información manejada.

5. Mantener actualizado, el inventario de insumos del almacén o despensa.

6. Contar con datos más confiables y certeros para la generación de informes.

7. Mejorar la capacidad de respuesta ante las autoridades, logrando un mejor

desempeño en la entrega de informes por parte de la administración del


8. Acceso rápido y sencillo a los datos, gracias a interfaces gráficas 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 tecnológicas, que permitan estar acorde a las

nuevas exigencias.



VERSIÓN: 1.0



11. Generar estándares corporativos que permitan a la Universidad adaptarse al

cumplimiento del Decreto Presidencial 3390, el cual establece la utilización

prioritaria de software libre en las empresas públicas.

2.2 Planteamiento del problema:

Cuadro 7. Planteamiento del problema. El problema de - Planificar los menús alimentarios de manera semi-

manual.

- No contar con un medio para hacer una estimación del

número de estudiantes que asistirán al comedor.

- Llevar un registro manual de las entradas de insumos en

almacén.

- No llevar un control de los insumos que salen del

almacén.

- Manejo de los datos de forma semi-manual produciendo

lentitud en cuanto a cálculos y elaboración y generación

de informes o reportes de costos.

- La inexistencia de un sistema de información que posea

una base de datos única y que permita la comunicación

en red del área administrativa del comedor con las áreas

de almacén para monitorear el inventario de insumos.

Afecta a La comunidad universitaria, a los trabajadores de la UDO y a la

institución ante el gobierno nacional.



VERSIÓN: 1.0



Cuadro 6. Planteamiento del problema. (Continuación) Cuyo impacto es - Lentitud en la Generación de la planificación

alimentaria y que además 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 número de

comensales que fueron atendidos, generando gastos

innecesarios con desperdicios de alimentos, tiempo y/o

recursos.

- No tener actualizada las existencias de insumos en

almacén.

- Generación de información no fiable.

- Retardo en la generación y entrega de reportes a las

autoridades competentes.

Una adecuada solución

sería

El desarrollo de un sistema automatizado que permita gestionar

los procesos administrativos que se llevan a cabo en el comedor

universitario, a fin de agilizar dichos procesos, para realizar una

planificación alimentaria más aproximada a la realidad, tomando

en cuenta la información nutricional de los alimentos. Así como

también, un mejor control de los insumos adquiridos para

prestar el servicio de alimentación.




VERSIÓN: 1.0



2.3 Declaración de Posición del Producto:

Cuadro 8. Posición del Producto. Para Los trabajadores del área del comedor universitario.

Quienes Llevan a cabo los procedimientos y actividades de planificación

y administración del servicio de alimentación.

El Software Es una aplicación WEB bajo el enfoque de Software Libre.

Que Permitirá almacenar la información necesaria para realizar los

procesos que se llevan cabo en el área de comedor, de manera

automatizada, permitiendo generar datos más confiables,

agilizar la entrega y obtención de resultados rápidamente.

No como Los procesos actuales que se llevan a cabo de manera manual,

haciendo tedioso los cálculos y la obtención de resultados.

Nuestro producto Permitirá contribuir con el proceso de migración hacia el

software libre establecido en el Decreto Presidencial 3390.

Además de agilizar los procesos de planificación y control que

se llevan a cabo en el área administrativa del Comedor

Universitario.


3. Descripción 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. También 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.



VERSIÓN: 1.0



3.1. Roles y Responsabilidades de los Participantes

A continuación se muestra los roles y responsabilidades de los participantes

involucrados en el proyecto.

Cuadro 9. Roles y Responsabilidades. Rol Responsabilidad

Líder del Proyecto El Líder 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 Líder de proyecto

también establece un conjunto de prácticas que aseguran la

integridad y calidad de los artefactos del proyecto. Además, el

Líder de proyecto se encargará de supervisar el establecimiento de

la arquitectura del sistema. Gestión de riesgos. Planificación y

control del proyecto.

Analista de Sistemas Captura, específica y valida requisitos, interactuando con el cliente

y los usuarios mediante entrevistas. Elabora el Modelo de Análisis

y Diseño. Colabora en la elaboración de las pruebas funcionales y

el modelo de datos.

Analista de procesos

de negocio.

Es responsable de definir la arquitectura, definir los casos de uso y

actores y la interacción entre ellos.

Integrador Es el responsable de planear y realizar la integración de elementos

de la Aplicación.

Programador Construcción del Software. Colaboración en la elaboración de las

pruebas funcionales, modelo de datos y en las validaciones con el

usuario.

Especialista en

Pruebas (tester)

Es responsable de realizar las pruebas del software cada vez que se

realice una iteración y las pruebas finales anotando los resultados

de esa comprobación.




VERSIÓN: 1.0



A nivel de los sistemas administrativos:

Cuadro 10. Participantes y Rol Nombre Rol

Ing. Jesús Chaparro Responsable General del Proyecto

Ing. Rosángela García Líder 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 Alta

Taller de Metodología RUP dictado por la

Lic. Nohemi Pinto.

Curso de UML Alta

Curso de Herramienta UML dictado por la

Lic. Nohemi Pinto.

Curso de Macromedia Alta

Curso de Macromedia Dreamweaver

dictado por el TSU Francisco Oliveros.

Curso de PHP Alta

Curso de PHP dictado por el Ing. Rodolfo

Rodríguez.

Curso de Javascript Alta

Curso de Fundamentos de Javascript

dictado por Lic. Arturo Marcano.

Curso de Desarrollo Web Alta

Seleccionar una empresa que dicte cursos de

Desarrollo Web.




VERSIÓN: 1.0



3.2.2 Necesidades de participantes a nivel de Sistemas:

Cuadro 12. Necesidades de participantes a nivel de Sistemas. Necesidad Prioridad Soluciones Propuestas

Capturar los requerimientos de los

usuarios. Alta

Implementar aplicación WEB bajo

estándares abiertos.

Registrar los requerimientos de los

usuarios a través de la creación de

casos de uso.

Alta


estándares abiertos.

Documentar en forma incremental

la evolución de los casos de uso. Media-alta


estándares abiertos, mejorando la interfaz

Asignar los nuevos casos de uso a

la cartelera correspondiente. Alta


estándares abiertos con una interfaz

amigable.

Ordenar los casos de uso según

estado, prioridad, tipo. Alta

Mejorar el mecanismo para priorizar los

casos.

Migrar y estandarizar las

aplicaciones, según el decreto 3390. Alta

Desarrollo de una aplicación WEB bajo el

enfoque de software libre y el decreto 3390.

Permitir control de forma remota

del equipo del cliente. Alta

Implementar una aplicación libre,

multiplataforma y de alto desempeño.




VERSIÓN: 1.0



3.2.3 Necesidades de los usuarios:

Cuadro 13. Necesidades de los usuarios. Necesidad Prioridad Soluciones Propuestas

Elaborar la planificación alimentaria de manera

sencilla y dinámica. Alta

Desarrollar módulo de

Planificación Alimentaria.

Controlar el acceso de comensales al comedor

universitario. Alta

Desarrollar modulo Acceso

de Comensales.

Realizar estimaciones más certeras del número de

estudiantes que acudirán al comedor universitario

para aprovechar el servicio.

Alta

Desarrollar módulo de

Planificación Alimentaria

Controlar las entradas y salidas de insumos en

almacén. Alta

Desarrollar modulo de

Almacén

Mantener actualizado el inventario del almacén de

insumos. Alta

Desarrollar Modulo de

Almacén

Realizar el resumen mensual de de costos de manera

rápida y fácil. Alta

Desarrollar modulo de

reportes


4. Descripción Global del Producto

4.1 Perspectiva del producto

El producto a desarrollar es un Sistema Web para la Planificación y Control

del Servicio de Alimentación Prestado por el Comedor Universitario de la

Universidad de Oriente Núcleo de Monagas., a fin de agilizar dichos procesos,

utilizando herramientas de Software Libre que permita cumplir con el Decreto

Presidencial 3390.



VERSIÓN: 1.0



Este software estará conformado por distintos módulos, los cuales tendrán sus

respectivas funcionalidades:

Modulo de insumos y menús alimentarios: estos módulos permitirán la creación y

mantenimientos de los menús alimentarios y de los insumos de los que podrán estar

conformados dichos menús.

Modulo Planificación: permitirá realizar la planificación alimentaría de todos los

menús a ser preparados, semanalmente, por el comedor universitario. Además,

generará la lista de todos los insumos requeridos para la preparación de los menús

planificados para la semana. También este modulo permitirá realizar una estimación

del número de comensales que asistirán al comedor universitario y así poder realizar

mejores planificaciones para las semanas posteriores.

Modulo Acceso de Comensales: permitirá registrar y controlar el número de

estudiantes que asisten al área de comedor para el aprovechamiento del servicio de

alimentación.

Modulo Planificación 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 podrán ser

consultadas por la administración del comedor para realizar la planificación

alimentaria del evento.

Modulo Almacén: permite controlar las existencias de insumos del almacén. 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 almacén,

permitiendo conocer en todo momento el saldo exacto de los inventarios.

Módulo Reportes: permite la visualización e impresión de reportes como el resumen

mensual de los costos incurridos al prestar el servicio de alimentación.



VERSIÓN: 1.0



4.2 Arquitectura del producto

El producto a desarrollar está definido bajo la siguiente arquitectura:

Figura 29. Arquitectura del Producto. Fuente: Autor (2008).

4.3 Resumen de Capacidades

A continuación se mostrará un listado de las capacidades que ofrecerá el

producto:



VERSIÓN: 1.0



Cuadro 14. Sistema para el Comedor Universitario. Beneficios Funcionalidades

Capacidad para parametrizar y

configurar el sistema.

El sistema contará con un módulo de administración que

permitirá configurar los usuarios y las semanas en las que

se planificará el servicio.

Validación de la información de

manera permanente.

El sistema realizará validaciones, lo que permitirá reducir

la duplicación de trabajo.

Elaborar los menús alimentarios

considerando la información

nutricional de los alimentos.

El sistema tendrá un modulo de creación y mantenimientos

de insumos y menús alimentarios.

Mayor agilidad para elaborar la

planificación de menús

alimentarios.

El sistema contará con un modulo que permitirá elaborar la

Planificación Alimentaria de acuerdo al número de

comensales.

Generar de manera rápida la lista

de insumos necesarios para

preparar las comidas de toda la

semana.

El sistema contará con un modulo que facilitará la

generación de las lista de insumos requeridos para utilizarlas

al momento de realizar los pedidos.

Controlar el acceso de comensales

al comedor.

El sistema contendrá un modulo que permitirá registrar el

número de comensales que asisten al comedor para disfrutar

del servicio.

Estimación más acertada del

número de personas que asistirán

al comedor universitario.

El sistema poseerá un modulo que permitirá estimar la

cantidad de personas que acudirán al comedor universitario

para aprovechar el servicio, de acuerdo al historial de

registros de comensales.

Llevar un control de los insumos

que se encuentran en almacén.

El sistema contendrá un modulo que permitirá controlar la

entrada y salida de insumos del almacén.

Mayor agilidad para generar los

informes y reportes.

El sistema permitirá la visualización e impresión de

reportes.




VERSIÓN: 1.0



4.4 Presunciones y Dependencias

Se asume que el alcance expresado en primer término para este documento no

va a ser ampliado. En caso de que ocurriera una ampliación del alcance habría que

realizar modificaciones en las funcionalidades. En términos de implementación, 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

heterogéneas en cuanto a sistemas operativos y herramientas de productividad.

4.5 Licenciamiento e Instalación

El sistema se está realizando exclusivamente para la UDO. La instalación se

realizará en los equipos que la UDO disponga según las especificaciones deseadas y

serán administrados por el Centro de Computación del Núcleo, bajo la supervisión de

la Dirección de Computación 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.



VERSIÓN: 1.0



6. Requerimientos Mínimos 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 Mínimos

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

Lápiz y lapiceros 5

CD-ROM 4

Tonner 4




VERSIÓN: 1.0



6.4 Requerimientos de Servicios

Cuadro 18. Requerimientos de Servicios. Material Cantidad

Sistema de cableado estructurado del Edificio Centro Comunal

Estudiantil donde se encuentra ubicado el área administrativa del

comedor, la entrada del comedor y el almacén de insumos.

Puntos de

conexión de red

(10)

Interconexión del edificio Centro Comunal Estudiantil con la red

interna del campus.


6.5 Otros Requerimientos

Proporcionar cursos de actualización en las siguientes herramientas: Análisis y

Diseño de Desarrollo de software utilizando RUP y UML, Macromedia, Oracle, PHP,

Javascript, Apache, Web, Editor de Texto, con la finalidad de obtener capacitación

para el desarrollo del sistema; y así lograr la culminación del proyecto en el tiempo

establecido.


141



Plan de Administración de Riesgos Versión 1.0



VERSIÓN: 1.0

FECHA : Febrero 2009 NOMBRE DEL DOCUMENTO: Plan de Administración de Riesgo.


Plan de Administración de Riesgos 1. Introducción

Se requiere establecer un Plan de Administración 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 Planificación y

Control del Servicio de Alimentación Prestado por el Comedor Universitario de la

Universidad de Oriente Núcleo de Monagas, por lo tanto se realizará un análisis de

los riesgos globales inherentes al proyecto.

2. Elementos de Riesgo a Administrar

A continuación se incluye en este documento el contenido del artefacto Lista

de Riesgos, el cual presentará en forma jerárquica cada uno de los riesgos con las

descripciones establecidas mediante la Tabla de Documentación de Riesgos (Cuadro

3, p.89)

Nota: La especificación de cada riesgo en la mencionada tabla de documentación de

riesgos, fue realizada basándose en el trabajo hecho por otros autores en la

administración 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 gestión de proyectos como para darle un ponderación más

aproximada a la realidad.



VERSIÓN: 1.0



Cuadro 19. Identificador 001 Identificador: 001 Descripción: Comunicación no fluida entre el cliente e involucrados - Reducción de la retroalimentación y desviación en el cumplimiento de los requerimientos.

Probabilidad: 0,9 Pérdida: 9 Grado de Exposición: 8,1 Primer Indicador: Disminución de la frecuencia de reuniones con fines de revisión de artefactos entre los participantes del proyecto y los involucrados.

Estrategia de Mitigación: Para evitar la disminución en el flujo de la comunicación se requiere hacer reuniones periódicas (diaria y semanalmente para el área de servicio de comedor y mensualmente para el centro de computación) referentes al proyecto, con el fin de incrementar al máximo la retroalimentación.

Propietario: Líder del Proyecto Fecha Prevista: Marzo - Junio de 2008.


Cuadro 20. Identificador 002. Identificador: 002

Descripción: 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 Pérdida: 9 Grado de Exposición: 8,1

Primer Indicador: están sujeto al cumplimiento de estas actividades por ser parte de sus

funciones.

Estrategia de Mitigación: Para evitar el incumplimiento de las asignaciones, el

participante debe dar a conocer con anticipación la no participación en alguna iteración y

por consiguiente exponer con aval dicha solicitud.

Propietario: Líder del proyecto Fecha Prevista: Marzo - Mayo de 2008




VERSIÓN: 1.0




Descripción: Pérdida de tiempo ocasionada por la jornada de 120 horas de Trabajo

Comunitario – Incumplimiento en la entrega de artefactos

Probabilidad: 0,6 Pérdida: 6 Grado de Exposición: 3.6

Primer Indicador: Prestar Servicio Comunitario, por ser parte de sus funciones.

Estrategia de Mitigación: Para evitar el incumplimiento de las asignaciones, el

participante debe dar a conocer con anticipación la no participación en alguna iteración y

por consiguiente exponer con aval dicha solicitud.

Propietario: Líder del Proyecto Fecha Prevista: Enero – Abril 2009.



Descripción: Proyecto no se puede implantar por alta resistencia al cambio – Proyecto

Cancelado

Probabilidad: 0,7 Pérdida: 7 Grado de Exposición: 4,9

Primer Indicador: Rechazo constante de los artefactos ejecutables durante la fase de

construcción y transición.

Estrategia de Mitigación: Coordinar una estrategia de comunicación 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 retroalimentación

que permita incorporar cambios que reduzcan la resistencia natural al cambio.

Propietario: Líder del Proyecto Fecha Prevista: A partir Junio de 2008.




VERSIÓN: 1.0




Descripción: 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, distribución de trabajo de manera estructurada y no cumpliendo

con los lineamientos de la metodología de desarrollo de software.

Estrategia de Mitigación: Adaptarse al nuevo paradigma de trabajo en la parte de

desarrollo de software.

Propietario: Líder y Responsable del

proyecto.

Fecha Prevista: A partir de Abril 2008



Descripción: Requerimientos no capturados en forma clara y concisa - Determinación

errónea de funcionalidades y proceso con alto número de incrementos por corrección, lo

que genera un estiramiento no deseado del calendario.


Primer Indicador: Los primeros ejecutables no están ajustados a los requerimientos y

necesitan iteraciones por incremento que incluyen cambios drásticos.

Estrategia de Mitigación: Para evitar el problema, se deben establecer mecanismos de

supervisión de requerimientos por parte de los Analistas y expertos del negocio, cuyas

funciones se centrarían en ejecutar pruebas de desempeño funcional y aceptación. Mientras

más grande sea el contacto cliente – equipo de desarrollo mayor será la garantía de capturar

requerimientos reales y realizar la menor cantidad de incrementos por corrección.

Propietario: Analistas De Sistemas Fecha Prevista: Abril - Junio de 2008.




VERSIÓN: 1.0



Cuadro 25. Identificador 007 Identificador: 007

Descripción: Crecimiento no controlado de requerimientos y alcance - Proyecto fuera de

calendario y requerimientos.


Primer Indicador: Inclusión muy frecuente de nuevos requerimientos asociados a los

casos de uso principales o la creación de nuevos casos de uso que reflejen requerimientos

de mayor alcance.

Estrategia de Mitigación: El alcance del proyecto debe ser definido previo a la etapa de

operación. Cualquier nuevo requerimiento que se constituya en un subsistema no

indispensable para los ya previstos, debe considerarse para un nuevo proyecto.

Propietario: líder del Proyecto Fecha Prevista: A partir de Abril de

2008.



Descripción: Datos de los sistemas actuales no migrados eficientemente - Software con

datos no reales que inciden en su desempeño funcional.


Primer Indicador: Los datos básicos incorporados de sistemas no fueron incorporados de

acuerdo a las especificaciones del nuevo software.

Estrategia de Mitigación: Para evitar que esto ocurra, se debe prever la incorporación

paulatina de data básica real en la base de datos.

Propietario: Líder del Proyecto Fecha Prevista: A partir de Marzo de

2009.




VERSIÓN: 1.0



Cuadro 27. Identificador: 009. Identificador: 009

Descripción: No adecuación 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 están informados de

las situaciones en las cuales operar las diferentes opciones del sistema.

Estrategia de Mitigación: Definición de manuales de normas y procedimientos de las

funciones del sistema en general y su respectiva inducción a los usuarios.

Propietario: Líder del Proyecto Fecha Prevista: A partir Junio de 2008.

Fuente: Autor (2008). Cuadro 28. Identificador 010 Identificador: 010

Descripción: Poco conocimientos de las herramientas de desarrollo por parte de los

participantes.


Primer Indicador: Falta de conocimientos en las herramientas de modelado y métodos

(UML y RUP) y en las herramientas software a utilizar (como PHP, Power Designer,

Oracle)

Estrategia de Mitigación: Adiestramiento inmediato a los participantes del proyecto, con

el fin de prepararlos y así puedan cumplir con sus asignaciones.


2008.




VERSIÓN: 1.0



Cuadro 29. Identificador 011 Identificador: 011

Descripción: Suspensión de actividades administrativas por causas externas a la misma –

Retardo en la finalización de proyecto.


Primer Indicador: Problemática existente en los núcleos tanto a nivel docente,

administrativo y estudiantil.

Estrategia de Mitigación: Tratar de llevar la planificación del proyecto para poder mitigar

el efecto de retraso que pudiera ser causado por la situación descrita.


2008.



149



Modelado del Negocio

Versión 1.0



VERSIÓN: 1.0

FECHA : Julio 2008 NOMBRE DEL DOCUMENTO: Modelado del Negocio.


1. Introducción

1.1 Propósito

Identificar los procesos que se llevan a cabo en el comedor universitario, la

relación 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 más importantes en el contexto del sistema, incluyendo los actores

internos y externos que participan en él.

2. Representación 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 Núcleo de Monagas.

A continuación se presenta el diagrama de caso de uso general del comedor

universitario:



VERSIÓN: 1.0



<<include>>

<<extend>>

<<extend>>

Condicion {cantidad de insumos=requiere cambios}Punto de Extension: Chequear cantidad de insumos

Condicion {Planificacion de menus `Requiere cambio´}Punto de extension: Verificar Disponibil idad Insumos

Requeridos

Nutricionista

Planificar menus

Administrador de comedor

Almacenista

Realizar Resumen Mensual de Costos

Registrar entrada de insumos

Devolver Planificacion de menus

Verificar Disponibil idad Insumos Requeridos

Elaborar Orden de pago

Secretaria

Supervisor de CocinaSolicitar Insumos

Chequear Cantidad de Insumos

Modificar Planificacion de Menus

Registrar Comensales

Ayudante de Comedor Estudiante

<<include>>

Realizar pedido de insumos

Diagrama 11. Caso de uso General del Negocio. Fuente: Autor (2008).



VERSIÓN: 1.0



3. Descripción del Modelo del Negocio

3.1 El curso de eventos inicia cuando el nutricionista elabora una planificación

alimentaria, la cual contiene los menús 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 días jueves) la

planificación 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 mercancía, 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 almacén del comedor. El almacenista recibe dichos

insumos y los registra manualmente en un cuaderno.

3.4 Diariamente el supervisor de cocina se dirige al almacén o despensa y solicita los

insumos que van a ser utilizados para preparar el menú indicado en la planificación.

Este los recibe y los traslada al área de cocina para que los cocineros y auxiliares de

cocina preparen la comida, bajo su supervisión.

3.5 Al momento de prestar el servicio de alimentación, se debe registrar el número de

comensales (estudiantes) que asisten al comedor. Esto a través de una pequeña

aplicación 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



VERSIÓN: 1.0



autoridades universitarias, para esto utiliza una aplicación en Excel. Dicha aplicación

le servirá de ayuda para realizar los cálculos de costos en cada mes.

4. Vista del Modelo del Dominio del Negocio

Registra

Puede Consultar

1..*

1

1..*

11..*

1

11

1..*

1

1

1..*

1

1..*

Recibe

Recibe

Elabora

Entrega

Recibe

Realiza

Elabora

Elabora

1

1..*

1

1..*

1

1..*

1

1

1..*

1..*

1

1..*

1

1..*

Solicita

Registra

Elabora

Recibe

Recibe

Entrega

1 1..*

1

1..*

Nutricionista

Planificacion Alimentaria

Solicitud de Compra

AdministradorDeComedor

Resumen de Costos

Insumos

Supervisor de Cocina

Proveedor

Almacenista

Analisis de Cotizacion

Cotizacion

Secretaria

Orden de Pago

AutoridadUniversitaria

Comensal

Ayudante de Comedor

Diagrama 12. Modelo de Dominio del Negocio. Fuente: Autor (2008).



VERSIÓN: 1.0



5. Lista de Actor-Actividad

Cuadro 30. Actor-Actividad Actor Actividades

Administrador de Comedor

- Dirigir, coordinar y supervisar todas las actividades del comedor.

- Velar por el buen funcionamiento del comedor. - Aprobar la planificación de menús presentada por el

Nutricionista. - Llevar el control de compras de equipos y reparación 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 demás trabajos que se le asignen.

- Elaborar orden de pago para los proveedores. - Archivar notas de entregas, facturas.

Nutricionista - Elaborar listas de menús considerando las facilidades de adquisición de los alimentos y su valor nutritivo.

- Controlar cantidad y calidad de los insumos necesarios para preparar los menús.

- Calcular las cantidades y costos de los menús, de acuerdo con la estimación del número de comensales.

- Preparar una relación semanal, quincenal o mensual, según sea requerida por el administrador, de la cantidad y calidad de víveres necesarios para la preparación de las comidas.

- Realizar la planificación 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.



VERSIÓN: 1.0



Cuadro 30. Actor-Actividad (Continuación) Actor Actividades

Almacenista - Recibir y revisar los materiales que llegan al almacén. - Registrar diariamente todas las entradas y salidas

especificando cantidad y valor de los artículos. - Realizar periódicamente un conteo físico de las

existencias del almacén. - Entregar las planificaciones de menús solicitadas por el

supervisor de cocina. - Entregar la cantidad de insumos solicitadas por el

supervisor de cocina para la preparación de los menús. Supervisor de Cocina - Solicitar la Planificación alimentaria para verificar el

menú a ser preparado. - Solicitar la cantidad de insumos necesarios para la

preparación 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,

preparación de las comidas y agilidad en el servicio prestado.

Proveedor - Envía cotizaciones. - Recibe orden de compra. - Entrega mercancías de insumos en almacén.

Ayudante del Comedor - Registra comensales que acceden al comedor universitario.



156



Especificación de Casos de Uso del Negocio: Planificar menús

Versión 1.0



VERSIÓN: 1.0

FECHA : Julio 2008 NOMBRE DEL DOCUMENTO: Especificación de Casos de Uso del Negocio: Planificar Menús.


1. Introducción

1.1 Propósito

Generar el informe de planificación de menús alimentarios para realizar los

pedidos de los insumos necesarios.

1.2 Alcance

Elaborar la planificación alimentaria semanal de acuerdo a la estimación del

número de comensales, donde se especifican los menús, y la calidad y cantidad de

insumos a utilizar.

2. Nombre del Caso de Uso

2.1 Código de Caso de Uso

CCU_PM01.

2.2 Descripción del Caso de Uso

Planificar Menús Alimentarios.

3. Diagrama de Casos de Uso

Condicion {Planificacion de menus `requiere cambio'} Punto de extension: Verificar Disponibil idad Insumos

Requeridos

<<extend>>

Nutricionista

Planificar menus

Administrador de comedorVerificar Disponibil idad Insumos

Requeridos

Devolver Planificacion de menus

Diagrama 13. Casos de Uso Planificar Menús Fuente: Autor (2008)



VERSIÓN: 1.0



4. Flujo de Eventos

4.1 Curso Típico de Eventos

Para prestar el servicio, el comedor universitario realiza, semanalmente, una

planificación alimentaria, en la que se especifican la variedad de menús que serán

servidos en el transcurso de la semana, así como la calidad y cantidad de insumos o

alimentos requeridos para la preparación de los mismos. El informe de la

Planificación Alimentaria contiene la planificación de los menús 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 también, las hojas de pedidos

por tipo de menú y día de la semana; en donde se especifican las cantidades de

insumos a utilizar en cada menú.

4.1.1 Para elaborar la planificación alimentaria, el nutricionista primero debe

seleccionar para cada turno y día de la semana, el menú que va a ser preparado.

4.1.2 Luego identifica todos los insumos que se utilizarán para la preparación de los

menús 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 asistirán al comedor en cada turno y día

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 días de la semana, de acuerdo a la cantidad estimada de comensales.

4.1.6 También, determina la cantidad TOTAL de insumos necesarios para preparar

todos los menús de la semana.

4.1.7 Luego, con toda la información obtenida, elabora el informe de la

Planificación Alimentaria de la semana.



VERSIÓN: 1.0



4.1.8 Una vez realizado el informe de la Planificación de Menús semanal el

nutricionista se lo entrega al administrador del comedor.

4.1.9 El administrador recibe la Planificación Alimentaria semanal y la revisa.

4.1.10 Luego examina y verifica la disponibilidad de los insumos requeridos para

preparar los menús programados en la planificación alimentaria.

4.1.11 Por último, El Administrador del comedor aprueba y firma el informe de

Planificación de menús semanal.

4.2 Cursos Alternativos

En la línea 4.1.10:

4.1.10.1 El Administrador del comedor al momento de revisar la Planificación

alimentaria semanal y, examinar y verificar la disponibilidad de los insumos

requeridos puede considerar que dicha Planificación requiere cambios. Una de las

razones puede ser, por ejemplo, la escasez de ciertos insumos en los inventarios de las

empresas proveedores. También puede darse el caso de que el administrador estima

conveniente modificar la Planificación de menús semanal para incluir un alimento de

fácil adquisición e indispensable para la alimentación 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.



VERSIÓN: 1.0



6. Precondiciones

Necesidad de ofrecer el servicio de alimentación a la comunidad estudiantil.

Haber elaborado el listado de menús alimentarios, considerando las

facilidades de adquisición de los alimentos y los nutrientes necesarios para la

adecuada alimentación de los estudiantes y comensales en general, que utilizan el

servicio.

7. Postcondiciones

Lograr la aprobación del informe de la Planificación Alimentaria para realizar

los pedidos de los insumos requeridos.



VERSIÓN: 1.0



8. Diagrama de Actividad

Nutricionista Administrador de Comedor

[No]

[Si]

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 uti l izar por tipo de menú y dia

Calcula cantidad total de insumo a util izar 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

Planificación Requiere Cambios

Devuelve informe de Planificacion de menusRecibe Informe de Planificacion

Replanifica Menus

Verifica Disponibil idad de Insumos Requeridos

Firma informe de Planificacion de menus

Diagrama 14. Diagrama de Actividad Planificar Menús. Fuente: Autor (2008).


162



Especificación de Casos de Uso del Negocio:

Realizar Pedido de Insumos Versión 1.0



VERSIÓN: 1.0

FECHA : Julio 2008 NOMBRE DEL DOCUMENTO: Especificación de Casos de Uso del Negocio: Realizar Pedido de Insumos.


1. Introducción

1.1 Propósito

Lograr la adquisición de los insumos necesarios para prestar el servicio de

alimentación.

1.2 Alcance

Hacer, cada semana, los pedidos de los insumos necesarios para la preparación

de los menús alimentarios de la siguiente semana.



CCU_RP02.


Realizar Pedido de insumos.


<<include>>Administrador de comedor

Realizar pedido de insumos

Elaborar Orden de pago

Secretaria Diagrama 15. Casos de Uso Realizar Pedido de Insumos. Fuente: Autor (2008)



VERSIÓN: 1.0



4. Flujo de Eventos


4.1.1 El curso normal de eventos inicia cuando el Administrador, cada semana,

examina la Planificación del siguiente periodo (semana) para verificar los insumos

que van a ser necesarios en la preparación de los menús alimentarios.

4.1.2 El Administrador del comedor realiza un análisis de las cotizaciones entregadas

por los proveedores para seleccionar a quienes de ellos se les harán los pedidos.

4.1.3 Luego elabora las solicitudes de compra correspondientes a cada proveedor.

4.1.4 Seguidamente, el administrador envía por FAX las solicitudes de compras a los

distintos proveedores. Para acelerar el proceso el administrador puede realizar los

pedidos por teléfono y luego más adelante envía 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 mercancía de insumos y la envía al almacén

del comedor universitario.

4.1.6 El administrador entrega a la Secretaria las solicitudes de compras, las

cotizaciones y el análisis de las mismas para archivarlas para su posterior utilización

en la elaboración 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 almacén, 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.



VERSIÓN: 1.0




En la línea 4.1.5:

4.1.5.1 Si el proveedor no cuenta con ciertos insumos en sus almacenes, este

lo comunica a la administración del comedor.

4.1.5.2 El administrador del comedor recibe la notificación de escasez y

realiza el pedido a otro proveedor.

4.1.5.3 En caso de que ningún proveedor cuente con alguno de los insumos

necesarios para la prestación del servicio de la semana, el administrador notifica y

entrega al nutricionista la planificación 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 Precondición 1

Los proveedores deben entregar al administrador del comedor las cotizaciones

o listado de precios de todos los productos que ofrecen (La sección de compra es la

que se encarga a comienzos de semestre de buscar los proveedores, esto a través de

una licitación por prensa. Una vez seleccionados los proveedores la sección 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 cotización tanto a la sección de



VERSIÓN: 1.0



compra como al Administrador del comedor. Los proveedores volverán a hacer

entrega de nuevas cotizaciones cuando haya variaciones en los precios de los

productos que ofrecen).

6.2 Precondición 2

Que el administrador haya recibido y aprobado el informe de la Planificación

de Menús.

7. Postcondiciones

Pedidos realizados a los proveedores para adquirir los insumos necesarios para

la preparación de los menús alimentarios planificados para la siguiente semana.



VERSIÓN: 1.0




Proveedor Administradora

[Si]

[No]

Entrega Cotizacion

Recibe cotizacion

Examina Planificacion de Menus

Analiza Cotizaciones

Elabora Solicitudes de Compra

Envia Solicitudes de Compra por FAXRecibe Solicitud de Compra

Inspecciona Solicitud de Compra

Cuenta con todos los insumos

Elabora Pedido

Recibe Comunicacion de escacezComunica escacez de insumo

Diagrama 16. Diagrama de Actividad Realizar Pedido de insumos Fuente: Autor (2008).


168



Especificación de Casos de Uso del Negocio: Registrar Entrada de insumos

Versión 1.0



VERSIÓN: 1.0

FECHA : Julio 2008 NOMBRE DEL DOCUMENTO: Especificación de Casos de Uso del Negocio: Registrar Entrada de Insumos.


1. Introducción

1.1 Propósito

Tener registrados los insumos que ingresan al almacén.

1.2 Alcance

Registrar en un cuaderno todos aquellos insumos que ingresan al almacén.



CCU_RE03.


Registrar entrada de insumos.

3. Diagrama de Caso de Uso

<<include>>

Almacenista

Registrar entrada de insumos

Realizar Pedido de Insumos

Diagrama 17. Casos de Uso Registrar Entrada de Insumos. Fuente: Autor (2008)

4. Flujo de Eventos


4.1.1 El curso normal de evento inicia cuando los proveedores, al comienzo de cada

semana, trasladan la mercancía al almacén o despensa y la entregan al almacenista.

4.1.2 El almacenista recibe los insumos y una nota de entrega.



VERSIÓN: 1.0



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 mercancía correctamente.

4.1.4 Después 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, también los proveedores deben hacer entrega al Administrador de todas las

facturas para que sean archivadas y utilizadas por la secretaria para la elaboración de

las órdenes de pagos.


En la línea 4.1.5 Si alguna nota de entrega no cumple con las cantidades

insumos solicitadas, el administrador devuelve la mercancía.

5. Actores

5.1 Internos

Almacenista, Administrador del comedor, Secretaria.

5.2 Externos

Proveedor.

6. Precondiciones

Haber realizado los pedidos de insumos



VERSIÓN: 1.0



7. Postcondiciones

Insumos registrados en un cuaderno.



VERSIÓN: 1.0




Proveedor Almacenista Administrador de comedor Secretaria

[Si ][No]

Entrega mercancia de insumos y nota de entrega

Recibe mercancia de insumos y nota de entrega

Mide cantidad de insumos recibidos

Registrar Insumos recibidos

Entrega Notas de entregas Recibe notas de entrega

Revisa notas de entregas

Mercancia correcta

Entregar notas de entrega

Devolver mercancia

Recibe Notas de entrega

Archiva Notas de entrega

Firma Nota de entrega

Diagrama 18. Diagrama de Actividad Registrar Entrada de Insumos. Fuente: Autor (2008).


173



Especificación de Casos de Uso del Negocio: Solicitar Insumos

Versión 1.0



VERSIÓN: 1.0

FECHA : Julio 2008 NOMBRE DEL DOCUMENTO: Especificación de Casos de Uso del Negocio: Solicitar Insumos.


1. Introducción

1.1 Propósito

Retirar de almacén 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 almacén de aquellos insumos requeridos para preparar

el menú alimentario del turno que corresponda.



CCU_SI04.


Solicitar insumos.


<<extend>>

Condicion {cantidad de insumos=requiere cambios}Punto de Extension: Chequear cantidad de insumos

Supervisor de Cocina

Solicitar insumos

Chequear Cantidad de insumos

Modificar Planificacion de Menus

Diagrama 19. Casos de Uso Solicitar Insumos. Fuente: Autor (2008)



VERSIÓN: 1.0



4. Flujo de Eventos


4.1.1 El curso normal de eventos inicia cuando el almacenista examina la

Planificación 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, dejándolas listas para

el momento de su utilización.

4.1.3 Después, el supervisor de cocina se dirige al almacén 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 preparación 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 preparación de todos los platos de comida.


En la línea 4.1.3 debido a su experiencia el supervisor de cocina puede

necesitar menos o más 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 Planificación de menús que posee. Luego el nutricionista le

comunica y le entrega al Administrador del comedor la Planificación de menús

semanal modificada para que sea archivada.



VERSIÓN: 1.0



En la línea 4.1.4 Si al momento del Supervisor de cocina solicitar los insumos

al almacenista, para preparar el menú planificado para esa fecha, estos todavía no se

encuentran en almacén (debido a que algún proveedor no ha entregado la mercancía),

entonces el supervisor de cocina utiliza los insumos de un menú que estaba

planificado para otro día. Esto se lo participa el almacenista al nutricionista y este

hace anotaciones manuales a la Planificación de menús semanal por el cambio hecho.

Luego el nutricionista le comunica y le entrega al administrador de comedor la

Planificación de menús 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 planificación alimentaria

para saber que insumos se van a retirar del almacén.

7. Postcondiciones

Contar con los insumos requeridos para utilizarlos en la preparación de las

comidas o menús alimentarios.



VERSIÓN: 1.0




Administrador Nutricionista Almacenista Supervisor de Cocina

[No]

[Si]

Examina Planificación Alimentaria

Verifica menu a ser preparado

Verifica la cantidad de insumos a uti lizar

Mide o pesa las cantidades de insumos necesarias

Solici ta planificacion semanalEntrega plani ficacion semanal

Recibe planificacion semanal

Chequea menu a preparar

Chequea cantidad de insumos a uti lizar

cantidad de insumos requiere cambios

Sol ici ta cantidades de insumos a utilizarEntrega cantidades de insumos

Recibe Insumos

Traslada insumos al area de cocina

comunica cambios de cantidad de insumosHace cambios a las cantidades medidas

Notifica cambio de cantidades util izadasRecibe notificacion

Modifica Plani ficacion de menus

Entrega Planificacion modificadoRecibe Plani ficacion modificado

Cuadro 31. Diagrama de Actividad Solicitar Insumos. Fuente: Autor (2008).


178



Especificación de Casos de Uso del Negocio: Registrar Comensales

Versión 1.0



VERSIÓN: 1.0

FECHA : Julio 2008 NOMBRE DEL DOCUMENTO: Especificación de Casos de Uso del Negocio: Registrar Comensales.


1. Introducción

1.1 Propósito

Controlar el acceso de estudiantes al comedor universitario.

1.2 Alcance

Registrar el número de estudiantes que acceden al comedor para aprovechar el

servicio de alimentación.



CCU_RC05.


Registrar Comensales.


Ayudante de Comedor

Registrar Comensales

Estudiante

Diagrama 20. Casos de Uso Registrar Comensales. Fuente: Autor (2008)

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 código de barra de su carnet estudiantil por el escáner de

código de barra que se encuentra junto al sistema.



VERSIÓN: 1.0



4.1.2 La persona encargada de registrar a los comensales, busca los datos del

estudiante en la aplicación hecha en Access, de acuerdo a la cédula capturada por el

escáner.

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

alimentación.

4.1.5 El comensal accede al comedor universitario.


En la línea 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 número de la cedula

de identidad.

En la línea 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.



VERSIÓN: 1.0



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

identificación o distinción (Carnet estudiantil).

7. Postcondiciones

Lograr el registro de todos los estudiantes que asistieron al comedor para el

aprovechamiento del servicio de alimentación.



VERSIÓN: 1.0




Estudiante Ayudante de Comedor

[Si]

[No]

Identificarse en la Entrada

Buscar datos del estudiante

Datos encontrados

Registrar Comensal

Restringir Acceso

Permitir acceso al comensal

Accede al comedor

Diagrama 21. Diagrama de Actividad Registrar Comensales. Fuente: Autor (2008).


183



Especificación de Casos de Uso del Negocio: Realizar Resumen Mensual de Costos

Versión 1.0



VERSIÓN: 1.0

FECHA : Julio 2008 NOMBRE DEL DOCUMENTO: Especificación de Casos de Uso del Negocio: Realizar Resumen Mensual de Costos.


1. Introducción

1.1 Propósito

Generar un Resumen mensual de costos para entregarlo a las autoridades

Universitarias.

1.2 Alcance

Hacer todos los cálculos necesarios para generar el resumen mensual de

costos, el cual contendrá todos los gastos generados por prestar el servidor de

alimentación.



CCU_RC06.

2.2. Descripción del Caso de Uso



Administrador del comedor


Diagrama 22. Casos de Uso Realizar Resumen Mensual de Costos. Fuente: Autor (2008)



VERSIÓN: 1.0



4. Flujo de Eventos


4.1.1 El curso normal de evento comienza cuando el administrador examina todas las

planificaciones de menús y facturas archivadas del último mes en el que se prestó el

servicio.

4.1.2 De la examinación 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 aplicación en Excel, el administrador calcula los costos

totales de insumos que fueron entregados por almacén, esto de acuerdo a los planes

de menús. También calcula el total de comensales a quien se les prestó el servicio.

Además se determina el monto total de insumos recibidos por almacén, esto de

acuerdo a las facturas. El administrador también calcula el costo unitario por el

servicio prestado a cada comensal, diariamente.

4.1.4 Con la información 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.



VERSIÓN: 1.0



6. Precondiciones

Tener disponible todas las planificaciones alimentarias y facturas archivadas

de las compras realizadas en todo el mes.

7. Postcondiciones

Lograr la generación del resumen mensual de costos para entregarlo a las




VERSIÓN: 1.0




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. Fuente: Autor (2008).

188

5.2 Etapa II. Diseño de la Arquitectura

Esta etapa abarca la segunda fase de RUP y tiene por finalidad establecer una

base sólida de la arquitectura del software. Esto a través del análisis y diseño de los

requerimientos funcionales del sistema determinados en la etapa anterior, empezando

por aquellos que son críticos para establecer su arquitectura. Además, 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 estándares de calidad que se han de seguir en

el proyecto.

En esta etapa se generaron los siguientes artefactos de la metodología RUP:

Especificación de Casos de Uso del Sistema, Especificaciones Complementarias y la

Arquitectura del Sistema.


189



Especificación de Casos de Uso del Sistema: Autenticar Usuario.

Versión 1.0



VERSIÓN: 1.0

FECHA : Junio 2009 NOMBRE DEL DOCUMENTO: Especificación de casos de uso del Sistema: Autenticar Usuario.


1. INTRODUCCIÓN

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 continuación se muestra el diagrama general de

casos de uso del sistema:

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

Nutricionista

Registrar Insumos

Conformar Menús Alimentarios

Elaborar Planificación Alimentaria

Generar Hoja de Pedido

Registrar Existencia de Articulo

Autenticar Usuario

Registrar Entrada de Articulos en Almacen

Registrar Salida de Articulos de Almacen

Generar Resumen de Costos

Consultar Solicitud del Servicio del Comedor

Controlar Acceso de Comensales

Elaborar Solicitud de Servicio del Comedor

Administrar Usuarios del Sistema

Almacenista

Administrador del Comedor

Ayundante del Comedor

Usuario Solicitante

Adminis trador del Sis tema Diagrama 24. Caso de Uso General del Sistema. Fuente: Autor (2008)



VERSIÓN: 1.0



2. BREVE DESCRIPCIÓN

El siguiente caso de uso describe el proceso para autenticar al usuario que está

accediendo al sistema.

3. DIAGRAMA DE CASOS DE USO

Usuario del Sistema

Autenticar Usuario

Nutricionista

Almacenista

Ayudante del Comedor

Usuario Solicitante

Administrador del Sistema

Administrador del Comedor

Diagrama 25. Casos de Uso Autenticar Usuario Fuente: Autor (2008)

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.



VERSIÓN: 1.0



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 botón “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 línea 3 en caso de que los datos introducidos no coincidan con un

usuario registrado, el sistema emite un mensaje de usuario inválido.



VERSIÓN: 1.0



5. DIAGRAMA DE SECUENCIA

Si resp=false

Si resp=true

1.Escribe Nombre de Usuario y Clave

2.Presiona boton "Ingresar"3.Procesa

4.resp=validarUsuario(usuario,clave)

6.cargarOpciones()

7.Busca Opciones del usuario

8.buscarOpciones()

5.Usuario No Valido

9.Muestra Menú Principal del usuario

Usuario del Sistema

W:AutenticacionUsuario Usuario TipoUsuario

1.Escribe Nombre de Usuario y Clave

2.Presiona boton "Ingresar"3.Procesa

4.resp=validarUsuario(usuario,clave)

6.cargarOpciones()

7.Busca Opciones del usuario

8.buscarOpciones()

5.Usuario No Valido

9.Muestra Menú Principal del usuario

Diagrama 26. Diagrama de Secuencia Autenticar Usuario. Fuente: Autor (2008)



VERSIÓN: 1.0



6. PROTOTIPO DE INTERFAZ DE USUARIO.

Pantalla 1. Autenticar Usuario. Fuente: Autor (2008)

Pantalla 2. Menú Principal Usuario Administrador del Sistema. Fuente: Autor (2008)



VERSIÓN: 1.0



Pantalla 3. Menú Principal Usuario Nutricionista. Fuente: Autor (2008)

Pantalla 4. Menú Principal Usuario Administrador del Comedor. Fuente: Autor (2008)



VERSIÓN: 1.0



Pantalla 5. Menú Principal Usuario Almacenista. Fuente: Autor (2008)

Pantalla 6. Menú Principal Usuario Ayudante del Comedor. Fuente: Autor (2008)



VERSIÓN: 1.0



Pantalla 7. Menú Principal Usuario Solicitante. Fuente: Autor (2008)


198



Especificación de Casos de Uso del Sistema:

Administrar Usuarios del Sistema. Versión 1.0



VERSIÓN: 1.0

FECHA : Junio 2009 NOMBRE DEL DOCUMENTO: Especificación de casos de uso del Sistema: Administrar Usuarios del Sistema.



El siguiente caso de uso describe el proceso para administrar los usuarios que

tendrán acceso al sistema del comedor.


<<include>>

Administrador del Sistema

Administrar Usuarios

Autenticar Usuario

Diagrama 27. Casos de Uso Administrar Usuarios del Sistema. Fuente: Autor (2008)


3.1 Caso de uso

Administrar Usuarios del Sistema.


Administrador del Sistema.

3.3 Precondiciones

El usuario ha sido autenticado correctamente en el sistema (Ver

Especificación de Casos de uso Autenticar Usuario).


1. Este caso de uso inicia cuando el administrador del sistema selecciona del

menú principal la opción “Administrar Usuarios”.



VERSIÓN: 1.0



2. El sistema abre nueva ventana y muestra las opciones de administración

(“Nuevo”, “Modificar”, “Eliminar”, “Salir”). También, busca los usuarios que han

sido creados y los muestra en pantalla.

3. Crear Nuevo Usuario.

3.1 El administrador del sistema presiona el botón “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 botón

“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 búsqueda y presiona botón “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 botón

“Modificar” .

5.2 El sistema abre ventana, busca el usuario seleccionado, busca los tipos de

usuarios y muestra en pantalla el formulario con la información del usuario

seleccionado.

5.3 El administrador edita los datos del usuario y presiona el botón “Modificar” .

5.4 El sistema actualiza los datos del usuario.



VERSIÓN: 1.0



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 botón

“Eliminar” .

6.2 El sistema muestra un mensaje de confirmación para eliminar el usuario.

6.3 El usuario confirma eliminación.

6.4 El sistema elimina el usuario seleccionado.

6.5 El sistema envía un mensaje indicando que el usuario ha sido eliminado

exitosamente.

7. Salir.

7.1 El usuario administrador presiona el botón “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 línea 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 botón “Retornar” .

3.3.2 El sistema abre y muestra la pantalla anterior de administrar usuarios.

En la línea 3.4 en caso de que los datos introducidos del usuario sean inválidos o que

el nombre de usuario introducido ya exista, el sistema envía un mensaje para que el

usuario verifique la información.



VERSIÓN: 1.0




(Ver Página 365)

Diagrama 28. Diagrama de Secuencia Administrar Usuarios del Sistema. Fuente: Autor (2008)



VERSIÓN: 1.0



5. PROTOTIPO DE INTERFAZ DE USUARIO

Pantalla 8. Administrar Usuarios del Sistema. Fuente: Autor (2008)

Pantalla 9. Detalles de Usuario del Sistema. Fuente: Autor (2008)


204




Registrar Insumos. Versión 1.0



VERSIÓN: 1.0

FECHA : Abril 2009 NOMBRE DEL DOCUMENTO: Especificación de casos de uso del Sistema: Registrar Insumos.



El siguiente caso de uso describe el proceso para la creación y mantenimiento

de los insumos que serán utilizados para conformar los menús y planificar el servicio

de alimentación.


<<include>>

Usuario del Sistema

Registrar Insumos

Autenticar Usuario

Diagrama 29. Casos de Uso Registrar Insumos. Fuente: Autor (2008)

3. DESCRIPCION TEXTUAL DE CASOS DE USOS

3.1 Caso de uso

Registrar Insumos.

3.2 Actores principales

Nutricionista.

3.3 Precondiciones






VERSIÓN: 1.0



1. Este caso de uso inicia cuando el Usuario selecciona la opción “Cargar Insumos”

del Menú Principal.

2. El sistema abre nueva ventana y muestra opciones de “Nuevo”, “Modificar”,

“Salir”. También, 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 botón “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 envía 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 búsqueda.

4.2.1 El usuario llena campo de búsqueda y presiona el botón “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 botón “Modificar” .

5.2 El sistema abre nueva ventana; busca datos del insumo seleccionado; busca

unidades de medida, tipos de insumos, tipos de menús, grupos de alimentos, tipos de



VERSIÓN: 1.0



nutrientes y los nutrientes de acuerdo al tipo que este seleccionado. Por último,

muestra en pantalla el formulario con la información 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 edición 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.



VERSIÓN: 1.0



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 botón “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 botón “Retornar” .

6.2 El sistema abre y muestra la pantalla anterior.

7. Eliminar Insumo.

7.1 El usuario presiona el botón “Eliminar” .

7.2 El sistema muestra un mensaje de confirmación 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 envía un mensaje indicando que el insumo se ha eliminado.

8. Salir.

8.1 El usuario presiona el botón “Salir” .




VERSIÓN: 1.0



3.5 Postcondiciones

Insumos registrados para utilizarlos al momento de crear los menús

alimentarios y realizar la planificación alimentaria.


En la línea 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 línea 3.4 en caso de que los datos introducidos del insumo sean inválidos o que

la descripción ingresada ya exista, el sistema envía un mensaje para que el usuario

verifique la información.

En la línea 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.



VERSIÓN: 1.0




(Ver Página 366)

Diagrama 30. Diagrama de Secuencia Registrar Insumos.




VERSIÓN: 1.0




Pantalla 10. Listado de Insumos Registrados. Fuente: Autor (2008)

Pantalla 11. Ventana para Agregar Nuevo Insumo. Fuente: Autor (2008)



VERSIÓN: 1.0



Pantalla 12. Pantalla para editar datos de Insumo. Fuente: Autor (2008)


213




Conformar Menús Alimentarios. Versión 1.0



VERSIÓN: 1.0

FECHA : Abril 2009 NOMBRE DEL DOCUMENTO: Especificación de casos de uso del Sistema: Conformar Menús Alimentarios.



El siguiente caso de uso describe el proceso para conformar los menús que

serán utilizados en la planificación alimentaria.

2. DIAGRAMA DE CASOS DE USOS

<<include>>

Usuario del Sistema

Conformar Menús Al imentarios

Autenticar Usuario

Diagrama 31. Casos de Uso Conformar Menús Alimentarios. Fuente: Autor (2008)


3.1 Caso de uso

Conformar Menús Alimentarios.


Nutricionista

3.3 Precondiciones



Haber cargado los insumos necesarios para conformar los menús alimentarios.

(Ver Especificación de Casos de uso Registrar Insumos).



VERSIÓN: 1.0




1. Este caso de uso comienza cuando el usuario selecciona la opción “Conformar

Menú” del Menú Principal.


“Salir”. También, busca los tipos de menús y los menús que han sido creados y los


3. Crear Nuevo Menú Alimentario.

3.1 El usuario presiona el botón “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 envía mensaje a pantalla indicando que el menú alimentario ha sido

creado.

4. Buscar Menú Alimentario.

4.1 Buscar Menús Alimentarios por tipo.

4.1.1 El usuario selecciona un tipo de menú.

4.1.2 El sistema busca menús de acuerdo al tipo de menús seleccionado y los muestra

en pantalla.

4.2 Busca Menú Alimentario llenando campo de búsqueda.


4.2.2 El sistema busca los menús que coincidan con los caracteres tecleados y filtra la

lista de menús de acuerdo a esa cadena de caracteres.

5. Modificar Menú Alimentario.



VERSIÓN: 1.0



5.1 El usuario selecciona un menú alimentario de la lista y presiona el botón

“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 información del

menú escogido.

5.3 El usuario edita la información 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 estén 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 búsqueda y presiona botón “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 búsqueda, 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”.



VERSIÓN: 1.0



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 Composición 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 botón “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 botón “Eliminar” .



VERSIÓN: 1.0



7.2 El sistema muestra un mensaje de confirmación para eliminar el menú

alimentario.

7.3 El nutricionista confirma eliminación.

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 envía un mensaje indicando que el menú se ha eliminado.

8. Salir.



3.5 Postcondiciones

Lograr la creación de las variedades de menús alimentarios para luego

utilizarlas en la planificación alimentaria.


En la línea 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 línea 3.4 en caso de que los datos introducidos del menú sean inválidos o que la

descripción ingresada ya exista, el sistema envía un mensaje para que el usuario


En la línea 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.



VERSIÓN: 1.0




(Ver Página 367)

Diagrama 32. Diagrama de Secuencia Conformar Menús Alimentarios.




VERSIÓN: 1.0




Pantalla 13. Listado de Menús Alimentarios Registrados. Fuente: Autor (2008)

Pantalla 14. Ventana para Agregar Nuevo Menú. Fuente: Autor (2008)



VERSIÓN: 1.0



Pantalla 15. Pantalla para editar datos de Menú. Fuente: Autor (2008)


222



Especificación de Casos de Uso del Sistema: Elaborar Planificación Alimentaria.

Versión 1.0



VERSIÓN: 1.0

FECHA : Mayo 2009 NOMBRE DEL DOCUMENTO: Especificación de casos de uso del Sistema: Elaborar Planificación Alimentaria.



El siguiente caso de uso describe el proceso para realizar la planificación

semanal de los menús que van a ser preparados por el comedor universitario para la

prestación del servicio de alimentación.


<<include>>

Usuario del Sistema

Elaborar Planificación Alimentaria

Autenticar Usuario

Diagrama 33. Casos de Uso Elaborar Planificación Alimentaria. Fuente: Autor (2008)


3.1 Caso de uso

Elaborar Planificación Alimentaria.


Nutricionista

3.3 Precondiciones





VERSIÓN: 1.0



Haber cargado los insumos. (Ver Especificación de Casos de uso Registrar

Insumos).

Para realizar la planificación alimentaria es necesario conformar los menús

alimentarios, los cuales son los platos de comida que serán servidos en el día a día en

el que el comedor universitario presta el servicio. (Ver Especificación de Casos de

uso Conformar Menús Alimentarios).


1. Este caso de uso inicia cuando el usuario selecciona la opción “Planificar Servicio”

del menú principal.

2. El sistema abre nueva ventana y muestra opciones de creación, modificación,

eliminación e impresión de planificaciones. Además muestra la opción de consultar

los insumos que son necesarios para preparar los menús programados en las

planificaciones. También, busca las semanas en las que ya se ha planificado el

servicio y las planificaciones alimentarias planeadas para la última semana.

3. Crear Nueva Planificación Alimentaria Semanal.

3.1 El usuario presiona el botón “Nuevo” para crear una nueva planificación

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 planificación 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 están dentro del rango de la semana seleccionada y las


3.5 Agregar una Planificación de Menú a la Planificación Semanal.

3.5.1 El usuario selecciona una fecha de la lista.



VERSIÓN: 1.0



3.5.2 El sistema muestra día de la fecha seleccionada.

3.5.3 El usuario selecciona tipo de menú.

3.5.4 Incluir Menú a la Planificación Alimentaria.

1. El usuario presiona icono “Buscar Menú Alimentario”.

2. El sistema abre nueva ventana, busca y muestra en pantalla los menús de acuerdo

al tipo seleccionado en la pantalla anterior.

3. El usuario llena campo de búsqueda y presiona el botón “Filtrar”.

4. El sistema busca menús 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 información del menú seleccionado en el

formulario.

3.5.5 Estimar número de comensales.

1. El usuario pulsa icono “Estimar Número de comensales”.

2. El sistema abre nueva ventana, busca información de las planificaciones anteriores

e historial de comensales de acuerdo al día y turno seleccionados. Luego, muestra en

pantalla los menús servidos y el número de comensales atendidos en las fechas

anteriores de acuerdo al día y turno que se está planificando.

3. El usuario presiona botón “Estimar”.

4. El sistema calcula el estimado de comensales y lo muestra en pantalla.

5. El usuario presiona botón “Aceptar”.

6. El sistema cierra ventana y carga el estimado de comensales en el formulario.

3.5.6 El usuario presiona botón “Agregar”.

3.5.7 El sistema valida los datos introducidos.

3.5.8 El sistema agrega la planificación de menú a la semana que se está planificando.

3.5.9 Incluir insumo a la Planificación de Menú.



VERSIÓN: 1.0



1. El usuario selecciona una planificación de menú y presiona icono “Incluir Otros

insumos a la Planificación”.

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 búsqueda y presiona botón “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

Planificación.

3.5.10 Editar Insumo Requerido para la Planificación.

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 Planificación.

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 planificación.

3.6 Quitar una Planificación de Menú de la Planificación Semanal.

3.6.1 El usuario presiona el icono “Eliminar” de la planificación de menú a borrar.

3.6.2 El sistema elimina la planificación de menú y los insumos requeridos de dicha

planificación.

3.7 Guardar Planificación Alimentaria Semanal.

3.7.1 El usuario presiona botón “Guardar” .

3.7.2 El sistema cambia estado de la semana a activo (La semana ha sido planificada).



VERSIÓN: 1.0



3.7.3 El sistema muestra en pantalla un mensaje indicando que la Planificación

Semanal ha sido guardada.

4. Retornar.

4.1 El usuario Presiona botón “Retornar” .


5. Buscar Planificación 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 Planificación Alimentaria Semanal.

6.1 El usuario marca casilla “Seleccionar Planificación Alimentaria Semanal” y

presiona botón “Modificar” .

6.2 El sistema abre nueva ventana; busca los tipos de menús o turnos; busca

información de la semana y las planificaciones de menú programadas en esa semana.

Luego, muestra formulario con datos de la planificación 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 almacén.

6.4.1 El usuario selecciona una planificación alimentaria y presiona icono "Buscar

Menú de Planificaciones Anteriores".

6.4.2 El sistema abre nueva ventana, busca Información de planificaciones anteriores

de acuerdo al turno de la planificación seleccionada. También, busca información de

los menús planificados y los insumos requeridos tanto para preparar los menús como

para prestar el servicio en general.

6.4.3 El sistema busca las existencias de artículos en almacén.



VERSIÓN: 1.0



6.4.4 El Sistema comprueba la existencia en almacén de los insumos requeridos para

prestar el servicio de alimentación según lo indicado en las planificaciones.

6.4.5 El sistema solo muestra las planificaciones donde los menús alimentarios

pueden prepararse con los insumos existentes en almacén.

6.4.6 El usuario selecciona el menú alimentario de una Planificación Anterior

Disponible.

6.4.7 El sistema actualiza información de la planificación alimentaria que se está

modificando.

6.4.8 El sistema muestra en pantalla la planificación alimentaria con el menú y

estimado de comensales actualizados.

6.5 Luego, el usuario presiona el botón “Guardar” (Ver línea 3.7).

7. Eliminar Planificación Alimentaria Semanal.

7.1 El usuario marca casilla “Seleccionar Planificación Alimentaria Semanal” y

presiona botón “Eliminar” .

7.2 El sistema elimina las planificaciones de menús 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 planificación

alimentaria ha sido eliminada.

8. Imprimir Planificación Alimentaria Semanal.

El usuario marca casilla “Seleccionar Planificación Alimentaria Semanal” y presiona

botón “Imprimir” .

8.2 El sistema genera reporte de la Planificación Alimentaria Semanal seleccionada y

lo envía a la impresora en formato imprimible para que realice la impresión del

mismo.

9. Salir.



VERSIÓN: 1.0




9.2 Para terminar con el proceso, el sistema abre y muestra el menú principal de

opciones.

3.5 Postcondiciones

Lograr la programación de los menús alimentarios que van a ser preparados en

cada día y turno de las semanas posteriores, con las respetivas cantidades de

comensales que posiblemente asistirán al comedor a aprovechar el servicio.


En la línea 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 botón “OK”.

3.3.4 El sistema crea semana para evento especial y envía un mensaje

indicando que el evento ha sido creado.

En la línea 3.5.1 en caso de que se esté planificando para un evento especial el

usuario escribe la fecha.

En la línea 3.5.5 en caso de que se esté planificando para un evento especial el

usuario simplemente escribe el número de comensales señalado en la solicitud de

servicio recibida. Es decir, no podrá estimar el número de comensales, debido a que

el sistema deshabilitará el icono para estimación cuando se trate de eventos

especiales.

En la línea 3.5.7 en caso de que los introducidos sean inválidos o que ya exista una

planificación de menú con los datos introducidos, el sistema envía un mensaje para

que el usuario verifique la información.



VERSIÓN: 1.0



En la línea 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 planificación del servicio de alimentación, es necesario estimar

el número de comensales. Esto para saber aproximadamente cual será la demanda

futura del servicio y así poder determinar qué cantidades de insumos serán necesarias

adquirir para la preparación de las comidas. Para estimar el número de comensales se

empleará el modelo de series de tiempo para pronóstico de demanda llamado

Promedio móvil. Este método emplea la siguiente fórmula matemática para calcular

el pronóstico de la demanda del siguiente periodo t+1:

Fórmula 1. Fórmula de Promedio Móvil.

1 tperiodo el para pronóstico1tF

promedio elen incluidos periodos de totalnúmero n

tperiodo elen real demandatD Demanda

n

1ntD...2tD1tDtD

n

demandas últimasn las de Suma1tF

+=+

=

=

+−++−+−+==+

Fuente: Krajewski, L. y Ritzman, Larry. (2000).

Para el caso de la estimación del número de comensales que acudirán al

comedor universitario, se tomara n=3; es decir, para pronosticar la demanda de

comensales para un periodo futuro se tomarán como datos históricos el número real

de comensales que asistieron al comedor en los tres (3) periodos más recientes

anteriores al que se está pronosticando. Los periodos anteriores quedarán definidos en

base al día de la semana (lunes, martes, miércoles,…) y turno (desayuno, almuerzo,



VERSIÓN: 1.0



cena,…) del periodo futuro en el que se desea estimar la demanda de comensales. Por

ejemplo, si se va a pronosticar el número de comensales para el turno del desayuno

del día 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.



VERSIÓN: 1.0




(Ver Página 368)

Diagrama 34. Diagrama de Secuencia Elaborar Planificación Alimentaria.




VERSIÓN: 1.0




Pantalla 16. Vista de Planificaciones Alimentarias por Semana. Fuente: Autor (2008)



VERSIÓN: 1.0



Pantalla 17. Pantalla para editar datos de Planificación Alimentaria Semanal. Fuente: Autor (2008)



VERSIÓN: 1.0



Pantalla 18. Ventana para Estimación de Comensales. Fuente: Autor (2008)

Pantalla 19. Ventana para Modificar Menú de la Planificación Alimentaria. Fuente: Autor (2008)



VERSIÓN: 1.0



Pantalla 20. Ventana para Incluir Insumos a la Planificación Alimentaria. Fuente: Autor (2008)


237




Generar Hoja de Pedido. Versión 1.0



VERSIÓN: 1.0

FECHA : Mayo 2009 NOMBRE DEL DOCUMENTO: Especificación de casos de uso del Sistema: Generar Hoja de Pedido.



El siguiente caso de uso describe el proceso para generar la lista de los

insumos necesarios para preparar los menús programados en la planificación

alimentaria, y así poder realizar los pedidos de los mismos.


<<include>>

<<include>>Usuario del Sistema

Generar Hoja de Pedido

Autenticar Usuario

Elaborar Planificacion Alimentaria

Diagrama 35. Casos de Uso Generar Hoja de Pedido. Fuente: Autor (2008)


3.1 Caso de uso

Generar Hoja de Pedido.


Nutricionista

3.3 Precondiciones





VERSIÓN: 1.0



Haber realizado la planificación alimentaria. (Ver Especificación de Casos de

uso Elaborar Planificación Alimentaria).


1. Este caso de uso inicia cuando el usuario selecciona la opción “Planificar Servicio”


2. El sistema abre nueva ventana y muestra opciones de creación, modificación,

eliminación e impresión de planificaciones. Además muestra la opción de consultar

los insumos que son necesarios para preparar los menús programados en las

planificaciones. También, 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 Planificación Alimentaria.

3.1 El usuario selecciona una planificación alimentaria y presiona botón “Insumos”.

3.2 El sistema abre nueva ventana; busca información de la planificación selecciona;

busca los insumos requeridos del menú planificado y los otros insumos necesarios

para prestar el servicio en la planificación 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 almacén.

3.5 Luego, el sistema muestra en pantalla el formulario con las cantidades

planificadas de insumos requeridos y sus existencias en almacén.

3.6 El usuario edita las cantidades a comprar de los insumos requeridos.

3.7 El usuario presiona botón “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.



VERSIÓN: 1.0



3.10 Imprimir Hoja de Pedido.

3.10.1 El usuario presiona botón “Imprimir” .

3.10.2 El sistema genera reporte de Hoja de Pedido y lo envía a la impresora en

formato imprimible para que realice la impresión 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 menús programados en la planificación

alimentaria y prestar el servicio.


En la línea 3.7

3.7.1 En caso de que el usuario quiera volver a la pantalla anterior sin guardar

los datos, entonces presiona el botón “Retornar” .

3.7.2 El sistema abre y muestra la pantalla anterior.



VERSIÓN: 1.0




(Ver Página 369)

Diagrama 36. Diagrama de Secuencia Generar Hoja de Pedido.




VERSIÓN: 1.0




Pantalla 21. Listado de Insumos Requeridos de la Planificación Alimentaria. Fuente: Autor (2008)


243

PROYECTO: SISTEMA W EB PARA LA PLANIFICACION Y CONTROL DEL SERVICIO DE ALIMENTACION PRESTADO POR EL COMEDOR UNIVERSITAR IO


Especificación de Casos de Uso del Sistema: Controlar Acceso de Comensales.

Versión 1.0



VERSIÓN: 1.0

FECHA : Junio 2009 NOMBRE DEL DOCUMENTO: Especificación de casos de uso del Sistema: Controlar Acceso de Comensales



El siguiente caso de uso describe el proceso para registrar los estudiantes que

acceden al comedor universitario para aprovechar el servicio de alimentación.


<<include>>

Usuario del Sistema

Controlar Acceso de Comensales

Autenticar Usuario

Diagrama 37. Casos de Uso Controlar Acceso de Comensales. Fuente: Autor (2008)


3.1 Caso de uso

Controlar Acceso de Comensales.


Ayudante asignado, Estudiantes.

3.3 Precondiciones





VERSIÓN: 1.0




1. Este caso de uso comienza cuando el usuario selecciona la opción “Registrar

Acceso Comensales” del menú principal.

2. El sistema abre nueva ventana, busca los tipos de menús, genera la fecha actual y

muestra esta información 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

día.

3.2 El sistema busca información 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 código de barra de su carnet estudiantil por el escáner de

código de barra que se encuentra conectado al sistema.

4.2 El sistema (o escáner de código de barra) captura cédula de identidad.

4.3 El sistema busca datos del estudiante de acuerdo a la cédula capturada y los


4.4 El usuario presiona botón “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 envía un mensaje indicando que el acceso del estudiante ha sido

registrado.

5. Salir.

5.1 El usuario presiona botón “Salir” .

5.2 El sistema abre y muestra el menú principal.

6. Consultar Historial de comensales.



VERSIÓN: 1.0



6.1 El usuario selecciona Consultar Historial de Comensales.

6.2 El sistema abre nueva ventana y muestra los tipos de búsquedas que se pueden

realizar.

6.3 El usuario selecciona un tipo de búsqueda y presiona botón “Aceptar”.

6.4 El sistema busca comensales registrados de acuerdo al tipo de búsqueda

seleccionado y los muestra en pantalla.

6.5 Imprimir información consultada.

6.5.1 El usuario presiona botón “Imprimir” .

6.5.2 El sistema genera reporte de la información consultada y lo envía a la impresora

en formato imprimible para que realice la impresión del mismo.

3.5 Postcondiciones

Realizar con éxito el registro del número de comensales que asistieron al

comedor universitario para el aprovechamiento del servicio.


En la línea 3.2 en caso de que el sistema no encuentre información de menú

alimentario, este envía un mensaje indicando que no se realizó planificación

alimentaria para el día y turno seleccionado.

En la línea 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 línea 4.5 en caso de que el estudiante ya haya accedido al comedor a

aprovechar el servicio, el sistema envía un mensaje a pantalla indicando que el

estudiante ya se encuentra registrado y pregunta si se desea volver a registrarlo.



VERSIÓN: 1.0




(Ver Página 370)

Diagrama 38. Diagrama de Secuencia Controlar Acceso de Comensales. Fuente: Autor (2008)



VERSIÓN: 1.0




Pantalla 22. Pantalla para Registro de Acceso Comensales. Fuente: Autor (2009)

Pantalla 23. Pantalla para Consultar Historial de Comensales. Fuente: Autor (2009)


249




Elaborar Solicitud de Servicio del Comedor. Versión 1.0



VERSIÓN: 1.0

FECHA : Mayo 2009 NOMBRE DEL DOCUMENTO: Especificación de casos de uso del Sistema: Elaborar Solicitud de Servicio del Comedor.



El siguiente caso de uso describe el proceso para la elaboración de solicitud de

servicio del comedor, para que éste facilite las comidas en caso de realizarse eventos

especiales en la universidad.


<<include>>

Usuario Solicitante

Elaborar Solicitud de Servicio del Comedor

Autenticar Usuario

Diagrama 39. Casos de Uso Elaborar Solicitud de Servicio del Comedor. Fuente: Autor (2008)


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 opción “Elaborar

Solicitud de Servicio” del Menú Principal.



VERSIÓN: 1.0



2. El sistema abre nueva ventana, genera fecha y número de solicitud, busca datos de

usuario y los tipos de menús o turnos; y muestra formulario en pantalla con toda esta

información.

3. El usuario llena datos de la solicitud y presiona botón “Enviar” .

4. El sistema valida datos introducidos de la solicitud.

5. El sistema envía la solicitud al comedor universitario.

6. El sistema envía 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 revisión por la administración del comedor.


En la línea 4 en caso de que los datos introducidos de la solicitud sean

inválidos, el sistema envía un mensaje para que el usuario verifique la información.



VERSIÓN: 1.0




20.Guarda detalles de la solicitud

21.agregarDetalle()22.Sol icitud Enviada

18.Datos Invalidos

Si Resp=false

Si Resp=true

SALIR

1.Selecciona Elaborar Solicitud de Servicio

2.abreVentana()

3.Carga Información

4.generarFecha()

5.generarNumSolicitud()

6.cargarUsuario()

7.Busca datos del usuario sol icitante

buscarUsuario(CodUsuario)

9.cargarTipoMenu()

10.Busca Tipos de Menu

11.buscarT ipoMenu()

12.cargarFormulario()13.Muestra formulario

14.Llena datos de solici tud

15.Presiona boton "Enviar"16.Procesa

17.Resp=validar()

19.enviarSol icitud()

23.Presiona boton "Sal ir"

24.abreVentana()

25.Muestra pantalla del menu principal

Usuario

W:SolicituddServicio SolicitudServicio Usuario TipoMenu DetalleSolici tud

20.Guarda detalles de la solicitud

21.agregarDetalle()22.Sol icitud Enviada

18.Datos Invalidos

1.Selecciona Elaborar Solicitud de Servicio

2.abreVentana()

3.Carga Información

4.generarFecha()

5.generarNumSolicitud()

6.cargarUsuario()

7.Busca datos del usuario sol icitante

buscarUsuario(CodUsuario)

9.cargarTipoMenu()

10.Busca Tipos de Menu

11.buscarT ipoMenu()

12.cargarFormulario()13.Muestra formulario

14.Llena datos de solici tud

15.Presiona boton "Enviar"16.Procesa

17.Resp=validar()

19.enviarSol icitud()


24.abreVentana()

25.Muestra pantalla del menu principal

Diagrama 40. Diagrama de Secuencia Elaborar Solicitud Servicio del comedor. Fuente: Autor (2008)



VERSIÓN: 1.0




Pantalla 24. Pantalla para elaborar solicitud de servicio del comedor. Fuente: Autor (2009)


254




Consultar Solicitud de Servicio del Comedor. Versión 1.0



VERSIÓN: 1.0

FECHA : Mayo 2009 NOMBRE DEL DOCUMENTO: Especificación de casos de uso del Sistema: Consultar Solicitud de Servicio del Comedor.



El siguiente caso de uso describe el proceso para consultar solicitudes de

servicio del comedor elaboradas.


<<include>>

Usuario del Sistema

Consultar Solici tud de Servicio del Comedor

Autenticar Usuario

Diagrama 41. Caso de Uso Consultar Solicitud de Servicio del Comedor. Fuente: Autor (2008)


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 opción “Consultar

Solicitudes de Servicio” del Menú Principal.



VERSIÓN: 1.0



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 búsqueda.


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 botón “Consultar” .

4.2 El sistema abre nueva ventana; busca toda la información de la solicitud

seleccionada; busca los status de solicitudes. Y por último, muestra en pantalla la

información 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 botón “Imprimir” .

5.2 El sistema genera reporte de la solicitud consultada y lo envía a la impresora en


6. Retornar.




VERSIÓN: 1.0




7. Salir.



3.5 Postcondiciones

Solicitudes Revisadas.



VERSIÓN: 1.0




BUSCAR SOLICITUD

CONSULTAR SOLICITUD

IMPRIMIR SOLICITUD

RETORNAR

SALIR

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 l ista de solicitudes de servicio

9.Selecciona Status Solicitud10.Busca Solicitudes

11.buscarSolicitudes()12.Muestra solicitudes de acuerdo al status seleccionado

13.Llena campo de busqueda

14.Presiona boton "Fil trar"15.Busca solicitudes de acuerdo a caracteres tecleados

16.buscarSolicitudes()17.Filtra solicitudes de acuerdo a la cadena tecleada

18.Selecciona solicitud de la l ista

19.Presion boton "Consultar"

20abreVentana()

21.Cambia Ventana22.Carga informacion de la solicitud

23.buscarSolicitud(NumSolicitud)


25,Busca los diferentes status de solicitudes


27.cargarDetal leSolicitud()

28.Busca detalles de la solicitud seleccionada

29.buscarDetal leSolicitud()

30.cargarFormulario()31.Muestra informacion de la solicitud

32.Cambia Status de la solicitud33.Procesa

34.actualizarStatus()35.Solicitud Actualizada

36.Presiona boton "Imprimir"37.Procesa

38.generarReporte()

39.Envia Solicitud en formato imprimible

40.Solicitud Impresa

41.Presiona boton "Retornar"

42.abreVentana()43.Muestra pantalla anterior

44.Presiona boton "Salir"

45.abreVentana()

46.Muestra pantal la del menu principal

Usuario

W:ConsultaSolicitudes W:SolicitudServicio SolicitudServicio StatusSolicitud DetalleSolicitud

Impresora

1.Selecciona Consultar Solicitudes de Servicio

2.abreVentana()

3.Busca Solicitudes de Servicio


5.Busca los diferentes status de solicitudes


7.buscarSolicitudes()8.Muestra los diferentes status y la l ista de solicitudes de servicio

9.Selecciona Status Solicitud10.Busca Solicitudes

11.buscarSolicitudes()12.Muestra solicitudes de acuerdo al status seleccionado


14.Presiona boton "Fil trar"15.Busca solicitudes de acuerdo a caracteres tecleados

16.buscarSolicitudes()17.Filtra solicitudes de acuerdo a la cadena tecleada

18.Selecciona solicitud de la l ista

19.Presion boton "Consultar"

20abreVentana()

21.Cambia Ventana22.Carga informacion de la solicitud

23.buscarSolicitud(NumSolicitud)


25,Busca los diferentes status de solicitudes


27.cargarDetal leSolicitud()

28.Busca detalles de la solicitud seleccionada

29.buscarDetal leSolicitud()

30.cargarFormulario()31.Muestra informacion de la solicitud

32.Cambia Status de la solicitud33.Procesa

34.actualizarStatus()35.Solicitud Actualizada


38.generarReporte()

39.Envia Solicitud en formato imprimible

40.Solicitud Impresa



44.Presiona boton "Salir"

45.abreVentana()

46.Muestra pantal la del menu principal

Diagrama 42. Diagrama de Secuencia Consultar Solicitud Servicio del comedor. Fuente: Autor (2009)



VERSIÓN: 1.0




Pantalla 25. Listado de Solicitudes de Servicio Recibidas. Fuente: Autor (2009)

Pantalla 26. Pantalla para cambiar status de la solicitud de servicio del comedor. Fuente: Autor (2009)


260




Registrar Existencia de Articulo. Versión 1.0



VERSIÓN: 1.0

FECHA : Noviembre 2008 NOMBRE DEL DOCUMENTO: Especificación de casos de uso del Sistema: Registrar Existencia de Articulo.



El siguiente caso de uso describe el proceso para registrar las existencias de

insumos en almacén.


<<include>>

Usuario del Sistema

Registrar Existencia de Articulo

Autenticar Usuario

Diagrama 43. Casos de Uso Registrar Existencia de Articulo. Fuente: Autor (2008)


3.1 Caso de uso

Registrar Existencia de Articulo.


Almacenista.

3.3 Precondiciones




Insumos).



VERSIÓN: 1.0




1. Este caso de uso inicia cuando el usuario selecciona la opción “Registrar Insumos

en Almacén” del Menú Principal.


“Eliminar”, “Imprimir”, “Salir”. También, busca las existencias de artículos en

almacén y los muestra en pantalla.

3. Registrar Nuevo Insumo en Almacén.

3.1 El usuario presiona el botón “Nuevo” para agregar un nuevo artículo en almacén.

3.2 El sistema abre ventana y busca las ubicaciones en almacén creadas. Muestra en

pantalla el formulario para llenar los datos del nuevo artículo.

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 búsqueda y presiona el botón “Filtrar”.


pantalla.

7. Luego de realizar la búsqueda, 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 Almacén.

3.4.1 El usuario presiona botón “Guardar” .



VERSIÓN: 1.0




3.4.3 El sistema registra la existencia del insumo en el almacén.

3.4.4 El sistema envía mensaje a pantalla indicando que el artículo ha sido registrado.

4. Buscar Artículo Registrado.

4.1 El usuario llena campo de búsqueda y presiona botón “Filtrar”.

4.2 El sistema busca existencias de artículos que coincidan con los caracteres

tecleados y los muestra en pantalla.

5. Modificar Registro de Insumo en Almacén.

5.1 El usuario selecciona un artículo de la lista y presiona botón “Modificar” .

5.2 El sistema abre nueva ventana; busca datos del artículo seleccionado y las

ubicaciones en almacén. Luego, muestra en pantalla el formulario con la información

del artículo escogido.

5.3 El usuario edita datos del artículo existente en almacén y presiona botón

“Guardar” .

5.4 El sistema actualiza los datos del artículo existente en almacén.

5.5 El sistema envía un mensaje a pantalla indicando que el artículo ha sido

actualizado.

6. Eliminar Registro de Insumo en Almacén.

6.1 El usuario selecciona un artículo de la lista y presiona botón “Eliminar” .

6.2 El sistema muestra un mensaje de confirmación para eliminar el artículo

seleccionado.


6.4 El sistema elimina el artículo seleccionado.

6.5 El sistema envía un mensaje indicando que el artículo ha sido eliminado

exitosamente.

7. Imprimir.



VERSIÓN: 1.0



7.1 El usuario presiona el botón “Imprimir” .

7.2 El sistema genera reporte de existencias de artículos y lo envía a la impresora en


8. Salir.



3.5 Postcondiciones

Registro realizado de la existencia de insumo en almacén.


En la línea 3.3

3.3.1 En caso de que el usuario quiera volver a la pantalla anterior sin guardar

los datos, entonces presiona el botón “Retornar” .

3.3.2 El sistema abre y muestra la pantalla anterior.

En la línea 3.4.2 en caso de que los datos introducidos sean inválidos o que el insumo

ya este registrado en almacén, el sistema envía un mensaje para que el usuario




VERSIÓN: 1.0




(Ver Página 371)

Diagrama 44.Diagrama de Secuencia Registrar Existencia de Articulo.




VERSIÓN: 1.0




Pantalla 27. Lista de Stock de Artículos en Almacén. Fuente: Autor (2008)

Pantalla 28. Detalles de la Existencia de un Articulo en Almacén. Fuente: Autor (2008)


267



Especificación de Casos de Uso del Sistema: Registrar Entrada de Artículos en Almacén.

Versión 1.0



VERSIÓN: 1.0

FECHA : Diciembre 2008 NOMBRE DEL DOCUMENTO: Especificación de casos de uso del Sistema: Registrar Entrada de Artículos en Almacén.



El siguiente caso de uso describe el proceso para registrar la entrada en

almacén de la mercancía de insumos pedida a los proveedores.


<<include>>

Usuario del Sistema

Registrar Entrada de Articulos en Almacen

Autenticar Usuario

Diagrama 45. Casos de Uso Registrar Entrada de Artículos en Almacén. Fuente: Autor (2008)


3.1 Caso de uso

Registrar Entrada de Artículos en Almacén.


Almacenista, Administrador del Comedor.

3.3 Precondiciones




Insumos).



VERSIÓN: 1.0




1. Este caso de uso inicia cuando el usuario selecciona la opción “Registrar Entradas”


2. El sistema abre nueva ventana; busca información de las órdenes de compra del

comedor universitario y los proveedores respectivos. También, 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 información de los registros de entradas de

artículos.

3. Buscar Registros de Entradas de Artículos.

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 búsqueda.

3.2.1 El usuario llena campo de búsqueda y presiona botón “Filtrar”.

3.2.2 El usuario busca registros de entrada de acuerdo a caracteres tecleados y los


4. Registrar Entrada de Artículos.

4.1 El usuario selecciona un registro de entrada de la lista y presiona botón

“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

información de registro de entrada seleccionado.

4.3 El usuario llena datos generales del registro de entrada de artículos.

4.4 Registrar detalle de insumo o artículo entrante.



VERSIÓN: 1.0



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 búsqueda, 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 artículo y presiona botón “Registrar”.

4.4.10 El sistema agrega detalle de la entrada del artículo.

4.4.11 El sistema comprueba la existencia del artículo entrante en el almacén.

4.4.12 Si el artículo esta registrado, el sistema calcula la existencia actual de dicho

artículo.

4.4.13 El sistema muestra un mensaje en pantalla indicando que la entrada del

artículo ha sido registrada.

4.5 Modificar detalle de Insumo o Artículo Entrante.

4.5.1 El usuario edita datos de entrada de artículo.

4.5.2 El usuario edita precio unitario del artículo entrante.

4.5.3 El sistema actualiza detalle del artículo entrante y calcula el precio total de la

cantidad entrante de dicho artículo. Muestra el precio total calculado y envía un

mensaje en pantalla indicando que la entrada del artículo ha sido actualizada.

4.6 Guardar el registro de la entrada de Artículos.



VERSIÓN: 1.0



4.6.1 El usuario presiona botón “Guardar”.


4.6.3 El sistema actualiza el registro de la entrada de artículos.

4.6.4 El sistema muestra un mensaje en pantalla indicando que el registro de entrada

de artículos ha sido actualizada.

5. Imprimir


5.2 El sistema genera reporte de registro de entrada de artículos y lo envía a la

impresora en formato imprimible para que realice la impresión del mismo.

6. Retornar



7. Salir



3.5 Postcondiciones

Registro realizado de la entrada de artículos en almacén.


En la línea 4.4.11 si el artículo no está registrado en almacén, el sistema

registra la nueva existencia del artículo en la despensa.

En la línea 4.6.2 en caso de que los datos introducidos sean inválidos, el

sistema envía un mensaje para que el usuario verifique la información.



VERSIÓN: 1.0




(Ver Página 372)

Diagrama 46. Diagrama de Secuencia Registrar Entrada de Artículos en Almacén. Fuente: Autor (2008)



VERSIÓN: 1.0




Pantalla 29. Bandeja de Registro de Entradas. Fuente: Autor (2008)



VERSIÓN: 1.0



Pantalla 30. Registro de Entrada de Artículos al Almacén. Fuente: Autor (2008)


275



Especificación de Casos de Uso del Sistema: Registrar Salida de Artículos de Almacén.

Versión 1.0



VERSIÓN: 1.0

FECHA : Febrero 2009 NOMBRE DEL DOCUMENTO: Especificación de casos de uso del Sistema: Registrar Salida de Artículos de Almacén.



El siguiente caso de uso describe el proceso para registrar las salidas de

artículos de almacén.


<<include>>

Usuario del Sistema

Registrar Salida de Articulos de Almacen

Autenticar Usuario

Diagrama 47. Casos de Uso Registrar Salida de Artículos de Almacén. Fuente: Autor (2008)


3.1 Caso de uso

Registrar Salida de Artículos de Almacén.


Almacenista.

3.3 Precondiciones



Haber planificado los menús alimentarios que van a ser preparados en la

semana. (Ver Especificación de Casos de uso Elaborar Planificación Alimentaria).



VERSIÓN: 1.0




1. Este caso de uso comienza cuando el usuario selecciona la opción “Registrar

Salidas” del Menú Principal.

2. El sistema abre nueva ventana; genera fecha y número de salida y busca los tipos

de menús o turnos. Luego muestra en pantalla el formulario para realizar el registro

de la salida de artículos del almacén.

3. Buscar Menú Planificado para saber que artículos van a salir del almacén.

3.1 El usuario selecciona un tipo de menú de acuerdo al turno del día que corresponda

servir.

3.2 El sistema busca información de la planificación alimentaria programada para la

fecha y turno seleccionado. También, busca información 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 almacén de aquellos insumos que

son necesarios para prestar el servicio de alimentación.

3.4 El sistema verifica que las cantidades de insumos a utilizar se encuentran

disponibles.

3.5 El sistema muestra información para realizar el registro de la salida de artículos

de almacén.

4. Registrar Salida de Artículos del Almacén.

4.1 El usuario llena datos generales de salida.

4.2 Registrar Cantidad Saliente de Artículo del Almacén.

4.2.1 El usuario ingresa cantidad saliente del artículo.

4.2.2 El sistema verifica la cantidad saliente ingresada.

4.2.3 El sistema agrega el detalle de la salida del artículo y calcula el precio total de la

salida.



VERSIÓN: 1.0



4.2.4 El sistema calcula la existencia actual del artículo en almacén.

4.2.5 El sistema muestra en pantalla el precio total de la salida del artículo del

almacén.

4.3 Ajustar Existencia de Articulo en almacén.

4.3.1 El usuario selecciona artículo de la lista y presiona icono “Ajustar Existencia de

Articulo”.

4.3.2 El sistema abre nueva ventana, busca artículo y los tipos de ajustes.

4.3.3 El sistema muestra en pantalla el formulario para realizar el ajuste de existencia

de artículo.

4.3.4 El usuario llena formulario y presiona botón “Guardar”.

4.3.5 El sistema crea y realiza el ajuste de la existencia del artículo.

4.3.6 El sistema cierra ventana y envía un mensaje indicando que el ajuste ha sido

realizado.


4.5 El sistema crea registro de salida.

4.6 El sistema envía un mensaje a pantalla indicando que el registro de salida de

artículos ha sido registrado.

5. Modificar registro de salida de artículos del almacén.

5.1 El usuario edita cantidad saliente del artículo.

5.2 Modificar Cantidad Saliente de Artículo del Almacén.

5.2.1 El usuario edita cantidad saliente del artículo.

5.2.2 El sistema modifica el detalle de la salida del artículo y calcula el precio total de

la salida.

5.2.3 El sistema calcula la existencia actual del artículo en almacén.

5.2.4 El sistema muestra en pantalla el precio total de la salida del artículo del

almacén.



VERSIÓN: 1.0



5.3 Modificar Ajuste de Existencia de artículo de almacén.

5.3.1 El usuario presiona icono de Ajuste realizado a la existencia del artículo

seleccionado.

5.3.2 El sistema abre nueva ventana, busca los tipos de ajustes y el ajuste realizado a

la existencia del artículo seleccionado.

5.3.3 El sistema muestra en pantalla el formulario con información del ajuste del

artículo seleccionado

5.3.4 El usuario edita formulario y presiona botón “Guardar”.

5.3.5 El sistema modifica ajuste.

5.3.6 El sistema realiza ajuste a la existencia del artículo en almacén.

5.3.7 El sistema cierra ventana y envía un mensaje indicando que el ajuste ha sido

realizado.


5.5 El sistema modifica registro de salida.

5.6 El sistema envía un mensaje indicando que el registro de Salida de artículos ha

sido actualizado.

6. Imprimir.


6.2 El sistema genera reporte de registro de salida de artículos y lo envía a la

impresora en formato imprimible para que realice la impresión del mismo.

7. Salir.



3.5 Postcondiciones

Registro realizado de la salida de artículos de almacén.



VERSIÓN: 1.0




En la línea 3.4

3.4.1 En caso de que en almacén no existan suficientes cantidades de insumos

para preparar el menú planificado, el sistema envía un mensaje advirtiendo de dicha

escasez.

3.4.2 El usuario debe realizar cambios en la planificación para programar otro

menú de acuerdo a las existencias de insumos disponibles en el almacén. (Ver

Especificación de Casos de uso Elaborar Planificación Alimentaria).

En la línea 4.2.2 en caso de que la cantidad ingresada no coincida con lo planificado o

que no exista dicha cantidad en almacén, el sistema envía mensajes indicando que la

cantidad saliente ingresada no coincide con lo planificado o que no existente en

almacén la cantidad ingresada del articulo.



VERSIÓN: 1.0




(Ver Página 373)

Diagrama 48. Diagrama de Secuencia Registrar Salida de Artículos de Almacén.




VERSIÓN: 1.0




Pantalla 31. Registro de Salida de Artículos de Almacén. Fuente: Autor (2008)

Pantalla 32. Ventana de Ajuste de Existencia de Articulo. Fuente: Autor (2008)


283



Especificación de Casos de Uso de Sistema: Generar Resumen de Costos.

Versión 1.0



VERSIÓN: 1.0

FECHA : Marzo 2009 NOMBRE DEL DOCUMENTO: Especificación de casos de uso del Sistema: Generar Resumen de Costos.



El siguiente caso de uso describe el proceso para generar reportes de los

costos implicados al prestar el servicio y el número de comensales atendidos, tanto

diaria como mensualmente.


<<include>>

Usuario del Sistema

Generar Resumen de Costos

Autenticar Usuario

Diagrama 49. Casos de Uso Generar Resumen de Costos. Fuente: Autor (2008)


3.1 Caso de uso

Generar Resumen de Costos.


Administrador del Comedor Universitario.

3.3 Precondiciones





VERSIÓN: 1.0




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 botón “Aceptar”.

3.4 El sistema busca planificaciones alimentarias de acuerdo a la fecha ingresada y

los menús programados para esas planificaciones.

3.5 El sistema busca la salida de artículos de almacén 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 día de la fecha ingresada.

3.7 El sistema busca el número de comensales que acudieron al comedor universitario

en el día y turnos de la fecha ingresada.

3.8 El sistema calcula el costo unitario del servicio, por turno y del total del día.

3.9 Luego de realizar los cálculos automáticos, el sistema muestra en pantalla el

reporte del control diario de costos.

3.10 El usuario escribe observación.

4. Generar Reporte Relación Por Servicio y Número de Comensales.

4.1 El usuario selecciona “Relación Por Servicio y Numero de Comensales” de la

lista de reportes.

4.2 El sistema muestra lista de meses y años.

4.3 El usuario selecciona mes y año.

4.4 El usuario presiona botón “Aceptar”.



VERSIÓN: 1.0



4.5 El sistema busca planificaciones alimentarias de acuerdo al mes y año ingresado.

4.6 El sistema busca el número de comensales de acuerdo a los días y turnos

planificados en el mes y año seleccionados.

4.7 El sistema calcula el total de comensales por turno y por día y el total de

comensales atendidos en todo el mes del año seleccionado.

4.8 Luego de realizar los cálculos, el sistema muestra en pantalla el reporte relación

por servicio y número de comensales.

5. Generar Reporte Relación de Alimentos, Bebidas y Otros Recibidas por

Almacén.

5.1 El usuario selecciona “Relación de Alimentos, Bebidas y Otros Recibidas por

Almacén” 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 años.

5.3 El usuario selecciona un mes, un año y un proveedor.

5.4 Luego, este presiona el botón “Aceptar”.

5.5 El sistema busca las entradas de artículos en almacén de acuerdo al mes, año y

proveedor seleccionados. También busca información de las órdenes de compra y del

proveedor que entregó en almacén la mercancía de insumos.

5.6 El sistema calcula el costo total de la entrada de artículos en almacén.

5.7 El sistema muestra en pantalla el reporte relación de alimentos, bebidas y otros

recibida por almacén.

6. Generar Reporte Relación De Alimentos y Conexos Entregados Por Almacén.

6.1 El usuario selecciona “Relación de Alimentos y Conexos Entregados Por

Almacén” de la lista de reportes.




VERSIÓN: 1.0



6.3 El usuario selecciona mes y año.


6.5 El sistema busca registros de salidas de artículos de almacén con sus respectivos

detalles, de acuerdo al mes y año seleccionados.

6.6 El sistema calcula el costo total de salidas de artículos de almacén por día y de

todo el mes del año seleccionado.

6.7 El sistema muestra en pantalla el reporte relación de alimentos y conexos

entregados por almacén.

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 año seleccionado.

7.5 Luego, busca las salidas de artículos de almacén de acuerdo a los días y turnos

planificados en el año seleccionado.

7.6 El sistema calcula costo total de salida de artículos de almacén en el mes y años

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 Después, el sistema busca el número de comensales atendidos en los días y

turnos planificados en el año 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.



VERSIÓN: 1.0



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.1 El usuario presiona botón “Imprimir”.

8.2 El sistema genera reporte y lo envía a la impresora en formato imprimible para

que realice la impresión del mismo.

9 Salir.

9.1 El usuario presiona botón “Salir”.


3.5 Postcondiciones

Lograr generar los reportes de costos y del número de servicio atendidos por

el comedor universitario.



VERSIÓN: 1.0




(Ver Página 374)

Diagrama 50. Diagrama de Secuencia Generar Resumen de Costos. Fuente: Autor (2008)



VERSIÓN: 1.0




Pantalla 33. Reporte Control Diario de Costo. Fuente: Autor (2009)

Pantalla 34. Reporte Relación por Servicio y Número de Comensales. Fuente: Autor (2009)



VERSIÓN: 1.0



Pantalla 35. Reporte Relac. de alimentos., bebidas y otros recibidos por almacén. Fuente: Autor (2009)

Pantalla 36. Reporte Relación de alimentos y conexos entregados por almacén. Fuente: Autor (2009)



VERSIÓN: 1.0



Pantalla 37. Reporte Resumen Mensual de Costo. Fuente: Autor (2009)


293



Especificaciones Suplementarias Versión 1.0



VERSIÓN: 1.0

FECHA : Noviembre 2008 NOMBRE DEL DOCUMENTO: Especificaciones Suplementarias.


1. Introducción

1.1 Propósito

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

Planificación y Control del Servicio de Alimentación Prestado por el Comedor

Universitario de la Universidad de Oriente Núcleo de Monagas.

1.2 Alcance

Este documento abarca los requisitos del sistema clasificados según 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 acrónimo en ingles de las

diferentes categorías: funcionalidad (Functionality), usabilidad (Usability),

confiabilidad (Reliability), desempeño (Performance) y capacidad de soporte

(Supportability). El “+” en FURPS+ indica requisitos adicionales, tales como:

implementación, interfaz, diseño, operaciones, licencias, restricciones físicas, etc.

1.4 Apreciación Global

En este documento se describen los requisitos funcionales y no funcionales del

sistema, además de requerimientos mínimos 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 través del

sistema de software. Las funcionalidades se refieren a las funciones que el sistema



VERSIÓN: 1.0



ejecutará, es decir, un conjunto de características requeridas del sistema que expresan

una capacidad de acción del mismo. Estos requisitos son capturados a través de los

casos de uso del sistema, los cuales describen el comportamiento del sistema, y la

manera en que los actores interactúan con este.

Las funcionalidades o requisitos funcionales se valoran evaluando el conjunto

de características 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 interacción del usuario con el sistema, como por ejemplo: la estética, la

consistencia de la interfaz de usuario, ayuda en línea, entre otros. Esta se refiere a la

capacidad de un software de ser comprendido, aprendido, usado y ser atractivo para el

usuario, en condiciones específicas de uso.

Esta última definición hace énfasis en los atributos internos y externos del

producto, los cuales contribuyen a su usabilidad, funcionalidad y eficiencia. La

usabilidad depende no sólo del producto sino también del usuario. Por ello un

producto no es en ningún caso intrínsecamente usable, sólo 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 gráfica cómoda y sencilla para que

así el usuario aprenda fácilmente 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, disposición de la

información, logos, etc., así como también el encabezado típico establecido para los



VERSIÓN: 1.0



sistemas de información de la universidad y una serie de botones, que por su diseño y

características le indican al usuario las acciones que pueden realizar (como guardar la

información, 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 función, bajo ciertas condiciones y durante un período de

tiempo determinado. En otras palabras, es la habilidad de un sistema para

comportarse correctamente sobre su entorno de ejecución real. Se evalúa midiendo la

disponibilidad del sistema, la exactitud de las salidas, frecuencia y gravedad de los

fallos, el tiempo medio entre fallos, la capacidad de recuperación ante un fallo y la

capacidad de predicción del programa.

Dentro de los problemas que podrían presentarse y que podrían 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 irán haciendo respaldos o

copias de seguridad en medios extraíbles de toda la información almacenada en la

base de datos del sistema constantemente, esto para garantizar la recuperación de la

información. Y además para garantizar el efectivo funcionamiento del sistema se

harán revisiones y pruebas periódicas.

2.4 Rendimiento

El rendimiento es la medida o cuantificación 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.



VERSIÓN: 1.0



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

aplicación Web liviana, de rápido acceso; que no necesita de tantos recursos para

funcionar en las computadoras clientes. En cuanto al hardware del servidor el nivel de

rendimiento también es elevado puesto que el sistema cuenta con un servidor SUM

FIRE X2100, uno de los servidores con mayor rendimiento en el mercado, fácil de

gestionar y con una plataforma ideal para dar servicios Web, contando además con

dos procesadores AMD cuyo consumo energético 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 aplicación de forma

concurrente.

2.5 Soporte

a) Requisitos de instalación. El sistema es una aplicación Web que se cargará en el

servidor SUM FIRE X2100 del centro de computación de la Universidad de Oriente

Núcleo Monagas, al cual se le instalará previamente el sistema operativo CentOS

(acrónimo de Community ENTerprise Operating System), el administrador Web

Apache, PHP, los cuales son de libre distribución, luego el manejador de base de

datos Oracle 10G, el cual es licenciado.

b) Requisitos de configuración. Instalar producto Oracle en cliente que permitirá la

comunicación con el servidor. Habilitar dirección 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 preparación

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.



VERSIÓN: 1.0



2.6 Restricciones de Implementación

El sistema está siendo desarrollado en la Universidad de Oriente núcleo

Monagas, haciendo uso de la tecnología de esta casa de estudio, basándose en los

lenguajes de programación HTML, PHP 5, JavaScript, SAJAX.

2.7 Restricciones de Diseño

El diseño del software está sustentado en las normas y estándares que han sido

establecidas a nivel de rectorado; por lo que la codificación se realizó trabajando con

clases, es decir, una programación orientada a objetos. En cuanto al hardware se

utilizaron los equipos con los que cuenta el centro de computación de la UDO-

Monagas para el desarrollo de los sistemas informáticos. Por seguridad de la

información utilizada en el sistema se crearán 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 interconexión entre

dos entidades, elementos, sistemas, equipos, conceptos, etc. que les permite trabajar

juntos. Con respecto, a la interacción 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 interactúa, incluyendo pantallas, ventanas, menús, formularios, etc. Entre los

principios generales que cumple el diseño de la interfaz del sistema se encuentran los

siguientes:

a) Interfaz accesible e intuitiva: la interfaz ha de ser lo más simple posible. Se debe

dar al usuario el ambiente flexible para que pueda aprender rápidamente a usar la

aplicación.



VERSIÓN: 1.0



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 más 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) Diseño ergonómico: hacer usos de menús, 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:

- Planificación Alimentaria.

- Registro de comensales.

- Elaborar Solicitud de Servicio de Comedor.

- Registrar existencia de Insumos o artículos en almacén.

- Registrar Entradas de Insumos en almacén.

- Registrar Salidas de Insumos de almacén.

- Identificación 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

información sobre las órdenes de compra, las cuales son necesarias para realizar los

procesos de registro de entradas de insumos. También, el sistema debe comunicarse



VERSIÓN: 1.0



con el sistema de control de estudio, el cual servirá de colaboración externa para

llevar a cabo el proceso de control de acceso de comensales.

2.8.4 Interfaz de Comunicación

La interfaz de comunicación sirve de enlace entre los aparatos y la

computadora en el que reside el software. Dicha interfaz tiene por función adaptar el

protocolo y el enlace físico. La conexión puede ser realizada por el Centro de

Computación de diversas formas, a través de cable de trenzado, por red inalámbrica o

por fibra óptica, dependiendo cuál de ellos sea el más conveniente de utilizar.

2.9 Requisitos mínimos de Hardware destacables para una buena interacción

software, hardware y usuario.

- Monitores de 14 pulgadas, de resolución 800x600.

- Pentium 4, procesador de 2.4 GHz, 512 en memoria RAM, 40 Gb en disco

duro.

- Impresora Láser.

- Tarjeta de Red PCI (10-100)

Centro de Computación

Internet

Comedor Universitario

Figura 30. Representación de Equipos. Fuente: Autor (2008)



VERSIÓN: 1.0



3. Reglas del Dominio

Cuadro 32. Reglas del Dominio

ID Regla Grado de

Variación Fuente

Regla 1

Los servicios del comedor solo

podrán ser utilizados por los

usuarios naturales, o sea estudiantes,

trabajadores y profesores de la

UDO.

Bajo. Manual del Comedor

Universitario.

Regla 2

El administrador, de acuerdo y con

el apoyo de las autoridades del

núcleo, tomará las medidas

restrictivas y de control necesario

para el cumplimiento de la norma

anterior.


Universitario.

Regla 3

Los funcionarios del comedor, en

los actos de preparación y entrega

de las comidas, deben ceñirse a las

normas de higiene establecidas por

el Ministerio de Sanidad;

igualmente deben mantener un

aspecto limpio, especialmente los

que están en contacto con los

usuarios.


Universitario.

Regla 4

Los usuarios y los trabajadores

deben guardar el debido respeto en

sus obligadas relaciones.


Universitario.



VERSIÓN: 1.0



Cuadro 32. Reglas del Dominio (Continuación).

Regla 5

En la elaboración de los menús se

tendrá en cuenta tanto el valor

nutritivo de los alimentos, como su

costo y oportunidad de adquisición.


Universitario.

Regla 6

En la elaboración de los platos

deben considerarse la presentación,

el sabor y la cantidad per capita, de

manera que los usuarios se sientan

satisfechos, aunque no

necesariamente hartos.


Universitario.

Regla 7

No se servirá comida a los usuarios

que no entreguen el correspondiente

ticket o que entreguen uno que no

está de acuerdo con su categoría de

trabajador o profesor.


Universitario.

Regla 8

Los horarios deben ser respetados, a

cuyo efecto el Administrador tomará

las medidas que considere

convenientes.


Universitario.

Regla 9

El Administrador deberá procurar,

con los medios de que dispone,

adquirir los mejores materiales en

plaza.


Universitario.

Regla 10

El comedor procurará ofrecer

comida variada y balanceada, a cuyo

efecto podrá asesorarse con el

Instituto Nacional de Nutrición.


Universitario.




VERSIÓN: 1.0



4. Cuestiones Legales

Se recomienda seguir los procedimientos establecidos en los manuales de

organización y procedimientos del comedor universitario de la Universidad de

Oriente.


304



Arquitectura del Sistema

Versión 1.0



VERSIÓN: 1.0

FECHA : Marzo 2009 NOMBRE DEL DOCUMENTO: Arquitectura del Sistema.


1. Introducción

1.1 Propósito

El presente documento contiene el diseño arquitectónico del sistema Web para

la Planificación y Control del Servicio de Alimentación Prestado por el Comedor

Universitario de la Universidad de Oriente Núcleo de Monagas, el cual es producto

de un análisis minucioso de los requisitos del sistema.

1.2 Alcance

Abarca la vista lógica, de datos y de implementación de la arquitectura del

sistema.

1.3 Descripción General

La arquitectura del software consiste en un conjunto de patrones y

abstracciones coherentes que proporcionan el marco de referencia necesario para

guiar la construcción 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 diseño arquitectónico ha de ajustarse a las necesidades y requisitos del

proyecto. Esta sección describe en términos generales, las ideas principales detrás de

la arquitectura escogida para el mismo.

2. Vistas y Planos

Este documento contiene varias vistas que muestran aspectos distintos del

sistema. A continuación se detallan las vistas utilizadas en este proyecto para

describir la arquitectura del sistema.

2.1 Vista Lógica

Representa los elementos de diseño más importantes para la arquitectura del

sistema, ya que soporta los requisitos funcionales del sistema, presenta las clases



VERSIÓN: 1.0



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 estático que describe la

estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos.

Estos diagramas son el pilar básico del modelado con UML, siendo utilizados tanto

para mostrar lo que el sistema puede hacer, como para mostrar cómo puede ser

construido. A continuación se puede visualizar el modelo de clases del sistema:



VERSIÓN: 1.0



(Ver Página 375)

Diagrama 51. Modelo de Clases. Fuente: Autor (2009)



VERSIÓN: 1.0



Tarjetas CRC

Las tarjetas CRC son muy útiles para observar la relación entre cada una de

las clases que conforman el modelo de clases y las responsabilidades de cada una de

ellas.

Como una extensión informal a UML, la técnica de las tarjetas CRC se puede

usar para guiar el sistema a través de análisis guiados por la responsabilidad. Esta

técnica define las responsabilidades y colaboraciones de cada clase a través 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 continuación 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. Comprobar acceso de comensales. Registrar el acceso de los comensales. Buscar comensales registrados. Generar reporte de comensales registrados.

Estudiante Planificación

Figura 31. Tarjeta CRC AccesoComensal. Fuente: Autor (2008)



VERSIÓN: 1.0



Nombre de la Clase SolicitudServicio Responsabilidades Clases Colaboradoras Cargar datos de usuario Cargar status de solicitudes Generar fecha de envío de solicitud Generar numero de solicitud Buscar solicitudes Cambiar status de solicitud

Usuario StatusSolicitud

Figura 32. Tarjeta CRC SolicitudServicio. Fuente: Autor (2008)

Nombre de la Clase Insumo Responsabilidades Clases Colaboradoras Cargar tipos de insumos. Cargar unidades de medida. Cargar grupos de alimentos. Cargar tipos de nutrientes. Cargar nutrientes. Buscar insumos. Comprobar utilización de insumos

TipoInsumo Um Alimento

Figura 33. Tarjeta CRC Insumo. Fuente: Autor (2008)

Nombre de la Clase Menú Responsabilidades Clases Colaboradoras Cargar Tipos de Menús Cargar Insumos Requeridos del Menú. Cargar Nutrientes de los Alimentos. Calcular Nutrientes del Menú. Buscar Menús. Comprobar Utilización de Menú.

TipoMenu InsumoRequeridoMenu

Figura 34. Tarjeta CRC Menú. Fuente: Autor (2008)



VERSIÓN: 1.0



Nombre de la Clase Planificación Responsabilidades Clases Colaboradoras Cargar Semanas Crear Fechas de la Semana. Cargar Tipos de Menús Cargar número de comensales registrados Estimar Número de Comensales. Cargar insumos requeridos de la planificación Cargar el Menú planificado Calcular Cantidad Total de Insumos Requeridos a utilizar. Cargar Existencias de Artículos en Almacén Comprobar Existencias de insumos requeridos. Generar Reporte de Planificación. Generar Hoja de Pedido. Buscar Planificaciones Alimentarias.

Menú TipoMenú Semana InsumoRequeridoPlanificacion AccesoComensal

Figura 35. Tarjeta CRC Planificación. Fuente: Autor (2008)

Nombre de la Clase ExistenciaArticulo Responsabilidades Clases Colaboradoras Cargar ubicaciones de almacén. Buscar existencias de artículos en almacén. Comprobar existencia de artículo en almacén. Calcular existencia actual de artículo. Ajustar existencia de artículo en almacén. Generar reporte de existencias de artículos en almacén.

Insumo Ubicación DetalleEntradaArticulo DetalleSalidaArticulo AjusteExistencia

Figura 36. Tarjeta CRC ExistenciaArticulo. Fuente: Autor (2008)



VERSIÓN: 1.0



2.2 Vista de Datos

Esta vista especifica arquitectónicamente los elementos constantes en el

modelo de datos. Describe una apreciación global del modelo de los datos y su

organización por lo que se refiere a las tablas, vistas, índices, etc. También describe la

cartografía de clases constantes de la Vista Lógica 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

físico y modelo de base de datos relacional. A continuación se presentan cada uno de

estos modelos.



VERSIÓN: 1.0



Modelo Conceptual

(Ver Página 376)

Diagrama 52. Modelo Conceptual. Fuente: Autor (2009)



VERSIÓN: 1.0



Modelo Físico

(Ver Página 377)

Diagrama 53. Modelo Físico. Fuente: Autor (2009)



VERSIÓN: 1.0



Modelo de base de datos relacional del sistema

(Ver Página 378)

Diagrama 54. Modelo de Base de Datos Relacional del Sistema. Fuente: Autor (2009)



VERSIÓN: 1.0



2.3 Vista de Despliegue

Esta vista se representa mediante el modelo de despliegue y define la

arquitectura física 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 comunicación 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 información.

<HTTPS>

<HTTPS>

<HTTPS>

Usuarios Comedor Universitario

Sistema Web

Aplicacion Web

Explorador Web

Servidor Web

Servidor de Base de Datos Oracle 10G

Manejador de Base de Datos Oracle 10G

Base de Datos

Diagrama 55. Modelo de Despliegue. Fuente: Autor (2008)

316

5.3 Etapa III. Construcción del Software.

El objetivo de esta etapa es llegar a obtener la capacidad operacional inicial

del sistema. Acá se profundiza en el diseño de los componentes y de manera iterativa

se van añadiendo las funcionalidades al software a medida que se construyen y

prueban, permitiendo a la vez que se puedan ir incorporando cambios.

Más detalladamente, a través de diferentes iteraciones se fueron añadiendo

funcionalidades al sistema, hasta llegar a la construcción de un prototipo inicial. En

esta etapa, se realizó la codificación de los módulos de administración del sistema

como la configuración y su mantenimiento, incluyendo los procesos de validar y

administrar usuarios. También, se llevó a cabo la programación de los procesos de

creación de insumos y menús alimentarios, planificación alimentaria, elaboración y

consulta de solicitudes para eventos especiales; además del registro de acceso de

comensales al comedor universitario. Todos estos módulos se tomaron como

prioridad debido a que influyen en la realización de la planificación alimentaria, que

es uno de los procesos más indispensables para prestar el servicio de alimentación 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.


317



Especificación de Caso de Prueba Tipo de Menú

Versión 1.0



VERSIÓN: 1.0

FECHA : Abril 2009 NOMBRE DEL DOCUMENTO: Especificación de Caso de Prueba: Tipo de Menú.


1. Descripción

El presente artefacto cubre el conjunto de pruebas realizadas sobre el

mantenimiento “Tipo de Menú”. Dicho mantenimiento es utilizado para actualizar, a

través de una interfaz de usuario, la información del sistema, relacionada con los

diferentes tipos de menús o turnos en los que pueden ser servidos los menús

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 aplicación.

2. Agregar Tipo de Menú

2.1 Descripción

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

información respectiva para que quede guardado en el sistema para su posterior

utilización.

2.2 Condiciones de Ejecución

La única condición 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 contraseña.

3. Se pulsa el botón “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 opción “Mantenimientos Planificación” del

menú principal.



VERSIÓN: 1.0



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 menús registrados y las

opciones permitidas (“Nuevo”, “Modificar”, “Eliminar”, Búsqueda por filtro).

9. Se hace clic en el botón “Nuevo”.

10. El sistema muestra en pantalla unos campos vacíos para ingresar el código y

descripción del nuevo tipo de menú.

11. Se ingresa “03” en el campo para el código.

12. Se ingresa “CENA” en el campo para la descripción.

13. Se pulsa el botón “Agregar”.

14. El sistema envía 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 Evaluación de la Prueba

Prueba realizada satisfactoriamente.

3. Editar Tipo de Menú

3.1 Descripción


mantenimiento de “Tipos de Menú”, con el fin de modificar la información de un tipo

de menú registrado.




VERSIÓN: 1.0





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 envía un mensaje preguntando si se desea modificar el item

seleccionado.

11. Se pulsa el botón “OK”.

12. El sistema muestra en pantalla unos campos llenos con información del tipo de

menú seleccionado.

13. Se modifica el campo descripción introduciendo “MERIENDA”.

14. Se pulsa el icono “Modificar”.

15. El sistema envía un mensaje preguntando si se desea modificar el registro.




VERSIÓN: 1.0



17. El sistema regresa a la pantalla anterior y muestra en la lista el tipo de menú

modificado.


El sistema modifica la información del tipo de menú seleccionado.


Prueba superada con éxito.

4. Eliminar Tipo de Menú

4.1 Descripción


mantenimiento de “Tipos de Menú”, con el fin de eliminar la información de un tipo

específico.




4.3 Entrada





administrador.


menú principal.





VERSIÓN: 1.0





9. Se selecciona el tipo de menú “MERIENDA” de la lista y se hace clic en el icono

“Eliminar”.

10. El sistema envía un mensaje preguntando si se desea eliminar el item

seleccionado.


12. El sistema muestra en pantalla unos campos llenos con información del tipo de

menú seleccionado.

13. Se pulsa “Eliminar”.

14. El sistema envía un mensaje preguntando si se desea eliminar el registro.


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 Descripción


mantenimiento de “Tipos de Menú”, con el fin de buscar la información de un tipo

específico.




VERSIÓN: 1.0





5.3 Entrada





administrador.


menú principal.





9. Se introduce “DESAYUNO” en el filtro de búsqueda.

10. Se presiona el botón “Filtrar”.

11. El sistema muestra la información del tipo de menú solicitado.


El sistema busca el tipo de menú consultado.




324



Especificación de Caso de Prueba Nutrientes

Versión 1.0



VERSIÓN: 1.0

FECHA : Abril 2009 NOMBRE DEL DOCUMENTO: Especificación de Caso de Prueba: Nutrientes


1. Descripción

El presente artefacto cubre el conjunto de pruebas realizadas sobre el

mantenimiento “Nutrientes”. Dicho mantenimiento es utilizado para actualizar, a

través de una interfaz de usuario, la información 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 Descripción


mantenimiento de “Nutrientes”, con el fin de crear un nuevo nutriente con su

información respectiva para que quede guardado en el sistema para su posterior

utilización.




2.3 Entrada





administrador.


menú principal.



VERSIÓN: 1.0




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”, Búsqueda por filtro).


10. El sistema muestra en pantalla unos campos para ingresar el código, descripción,

unidad de medida y el tipo al que pertenece el nuevo nutriente.

11. Se ingresa “000008” en el campo para el código.

12. Se ingresa “NIACINA” en el campo para la descripción.

13. Se selecciona la unidad de medida “Gr” de la lista de selección.

14. Se selecciona el tipo de nutriente “Vitaminas” de la lista de selección.

15. Se presiona el botón “Agregar”.

16. El sistema envía un mensaje preguntando si se desea agregar el registro.


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 Descripción


mantenimiento de “Nutrientes”, con el fin de modificar la información de un nutriente

registrado.



VERSIÓN: 1.0






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 información del nutriente

seleccionado.

13. Se modifica el campo unidad de medida seleccionando de la lista la opción “Cal”.

14. Se pulsa el icono “Modificar”.

15. El sistema envía un mensaje preguntando si se desea modificar el registro.




VERSIÓN: 1.0



17. El sistema regresa a la pantalla anterior y muestra en la lista el nutriente

modificado.


El sistema modifica la información del nutriente seleccionado.



4. Eliminar Nutriente

4.1 Descripción


mantenimiento de “Nutrientes”, con el fin de eliminar la información de un nutriente

específico.




4.3 Entrada





administrador.


menú principal.





VERSIÓN: 1.0





9. Se selecciona el nutriente “ENERGIA” de la lista y se hace clic en el icono

“Eliminar”.

10. El sistema envía un mensaje preguntando si se desea eliminar el item

seleccionado.


12. El sistema muestra en pantalla unos campos llenos con información del nutriente

seleccionado.

13. Se pulsa “Eliminar”.

14. El sistema envía un mensaje preguntando si se desea eliminar el registro.


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 Descripción


mantenimiento de “Nutrientes”, con el fin de buscar la información de un nutriente

específico.



VERSIÓN: 1.0






5.3 Entrada





administrador.


menú principal.





9. Se selecciona el tipo de nutriente “MINERALES” de la lista de selección.

10. El sistema muestra una nueva lista con los nutrientes pertenecientes a ese tipo de

nutriente.

11. Se introduce “SODIO” en el filtro de búsqueda.


13. El sistema muestra la información del nutriente solicitado.


El sistema busca el nutriente consultado.




331



Especificación de Caso de Prueba

Insumos Versión 1.0



VERSIÓN: 1.0

FECHA : Abril 2009 NOMBRE DEL DOCUMENTO: Especificación de Caso de Prueba: Insumos


1. Descripción

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 Descripción

Se ingresa al sistema como usuario nutricionista para acceder a la sección de

insumos, con el fin de crear uno nuevo con su información respectiva para que quede

guardado en el sistema para su posterior utilización.


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 contraseña.



nutricionista.

5. Se posiciona el cursor del Mouse en la opción “Insumos” del menú principal.

6. El sistema despliega la lista disponible en esta opción.

7. Se selecciona “Cargar Insumos” de la lista.



VERSIÓN: 1.0



8. El sistema muestra una interfaz con la lista de insumos registrados y las opciones

permitidas (“Nuevo”, “Modificar”, Búsqueda por filtro).


10. El sistema muestra en pantalla unos campos para ingresar la descripción y el tipo

al que pertenece el nuevo insumo.

11. Se ingresa “CARNE DE RES” en el campo para la descripción.

12. Se selecciona el tipo de insumo “ALIMENTOS” de la lista de selección.

13. Se presiona el icono “Agregar Nuevo Insumo”.

14. El sistema muestra un mensaje avisando que insumo ha sido creado.


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 Descripción


insumos, con el fin de modificar la información de un insumo registrado.


La única condición es que el usuario esté registrado como nutricionista, para


3.3 Entrada





VERSIÓN: 1.0





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 vacíos para llenar la información del

insumo seleccionado.

13. Se selecciona la unidad de medida “Kg” de la lista de selección.

14. Se selecciona los tipos de menús “ALMUERZO” y “CENA” en los que el insumo

podrá ser utilizado para la creación de menús alimentarios de esos tipos.

15. Se marca la opción “Propiedades de Alimentos” (para darle a los insumos

características de alimentos, incluyendo su información nutricional).

16. El sistema muestra campos adicionales para llenar información 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 selección.

19. Se selecciona el tipo de nutrientes “MINERALES” de la lista de selección.

20. El sistema muestra la lista de nutrientes que pertenecen al tipo seleccionado.



VERSIÓN: 1.0



21. Se selecciona el nutriente “SODIO” para agregarlo a la composición nutricional

del insumo seleccionado.

22. El sistema envía 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

composición del insumo alimenticio seleccionado.

26. Se pulsa el icono “Actualizar”.

27. El sistema muestra un mensaje avisando que el insumo ha sido actualizado.


29. El sistema muestra la información del insumo actualizada.


El sistema actualiza la información del insumo seleccionado.



4. Buscar Insumo

4.1 Descripción


insumos, con el fin de buscar la información de un insumo registrado.




4.3 Entrada




VERSIÓN: 1.0






nutricionista.






9. Se selecciona el tipo de insumos “OTROS” de la lista de selección.

10. El sistema muestra una nueva lista con los insumos pertenecientes a ese tipo de

insumos.

11. Se introduce “VASOS” en el filtro de búsqueda.


13. El sistema muestra la información del insumos solicitado.


El sistema busca el insumo consultado.




337



Documento Glosario

Versión 1.0



VERSIÓN: 1.0

FECHA : Abril 2009 NOMBRE DEL DOCUMENTO: Glosario.


Glosario

1. Organización del Glosario

El presente documento está organizado por definiciones de términos

ordenados de forma ascendente según la ordenación alfabética tradicional del

español.

2. Definiciones

A continuación se presentan todos los términos manejados a lo largo de todo

el proyecto de desarrollo de sistema para la automatización de los procesos de

planificación y control llevados a cabo en el comedor universitario de la Universidad

de Oriente Núcleo de Monagas, así como sus respectivas definiciones:

2.1 Actor: conjunto de roles que los usuarios desempeñan con respecto al sistema.

2.2 Almacén: Es el espacio físico donde se guardan las mercancías de insumos.

2.3 Análisis 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 economía.

2.4 Automatización: Aplicación de procedimientos automáticos en la realización de

un proceso. Es la sustitución de procedimientos manuales por sistemas de cómputo.

2.5 Caso de uso: Es una técnica para capturar requisitos potenciales de un nuevo

sistema o una actualización de software. Cada caso de uso proporciona uno o más

escenarios que indican cómo debería interactuar el sistema con el usuario o con otro

sistema para conseguir un objetivo específico.

2.6 Comedor: Habitación de un establecimiento que dispone de lo necesario para

servir comidas.



VERSIÓN: 1.0



2.7 Comensal: Persona que hace uso del servicio de alimentación ofrecido por el


2.8 Cotización: Información 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

alimentación balanceada y variada a la población universitaria, ofreciendo una

excelente preparación y presentación de los alimentos, con las mejores condiciones

higiénicas 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 provisión

de un servicio, junto a la fecha de devengo, además de indicar la cantidad a pagar

como contraprestación. 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 producción de los menús

alimentarios.

2.13 Menú alimentario: Conjunto de alimentos que conforman los platos de comida

y que se sirven en el comedor universitario.

2.14 Mercancía: 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 reparación de sus

componentes.



VERSIÓN: 1.0



2.16 Nota de entrega: documento mercantil que acredita la entrega de un pedido. El

receptor de la mercancía 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

mercancías 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 Planificación Alimentaria: documento que contempla la programación de una

serie de menús alimentarios con sus respectivos insumos requeridos.

2.21 Postcondición: Una restricción que debe ser verdad tras terminar una operación.

2.22 Precondición: Una restricción que debe ser verdad antes de que se solicite una

operación.

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 Alimentación: Servicio básico que presta la universidad a la

comunidad universitaria donde se le suministra a través de los menús alimentarios o

platos de comida una alimentación sana y balanceada.

2.27 Sistema: Conjunto de partes o elementos organizados y relacionados que

interactúan entre sí para lograr un objetivo. Los sistemas reciben (entrada) datos,

energía o materia del ambiente y proveen (salida) información, energía o materia.



VERSIÓN: 1.0



2.28 Software: Conjunto de programas, documentos, procesamientos y rutinas

asociadas con la operación de un sistema de computadoras, es decir, la parte

intangible o lógica de una computadora.

2.29 Solicitud de compra: en esta se especifican, de manera detallada, lo insumos

necesarios para la prestación del servicio de alimentación.

2.30 Tipo de Menú: indica el turno en el que será servido un menú alimentario.

Ejemplo: desayuno, almuerzo, cena, merienda.

342

5.4 Análisis Costo – Beneficio.

El análisis costo-beneficio es una técnica que pretende determinar la

conveniencia de un proyecto mediante la enumeración y valoración en términos

monetarios de todos los costos y beneficios derivados de dicho proyecto. En otras

palabras, esta técnica proporciona una medida de la rentabilidad del proyecto, a través

de la comparación de los costos en que se incurren por la realización del proyecto con

los beneficios que se esperan obtener del mismo.

Este análisis se lleva a cabo para justificar económicamente el desarrollo de

este proyecto, además de determinar los beneficios tangibles e intangibles que se

generan.

5.4.1 Costos

A continuación se detallan los costos que fueron necesarios para llevar a cabo

el desarrollo del proyecto y lograr la construcción del sistema Web para la

planificación y control del servicio de alimentación prestado por el comedor

universitario de la Universidad de Oriente Núcleo 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 realización es el autor en

calidad de pasante, por lo que la Universidad de Oriente Núcleo Monagas no incurre

en ningún gasto de este tipo.

343

Costos de Equipos y Herramientas

Son los costos relacionados con la adquisición 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 Computación de la

Universidad de Oriente Núcleo de Monagas contaba con los equipos y herramientas

de trabajo requeridos.

Costos de Adiestramiento

Costos generados por la capacitación del personal involucrado en el proyecto

a través 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

metodología RUP, la herramienta UML, Power Designer, Lenguaje PHP y

Macromedia Dreamweaver que fueron dictados por el personal del Centro de

Computación de la Universidad de Oriente Núcleo de Monagas y por el personal que

labora en el Rectorado, incurriéndose solo en costos de viáticos. 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 adquisición de materiales como

resmas de papel necesarias para la documentación, carpetas, ganchos, cartuchos de

tinta para impresora, tóner, libreta de anotaciones, lápices, lapiceros, entre otros. Cabe

mencionar, que estos materiales fueron suministrados en su mayoría por el Centro de

Computación.

344

En el siguiente cuadro se presenta un resumen de los costos del proyecto,

detallando cada uno de ellos con sus respectivos valores en bolívares 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 impresión (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.

345

Beneficios Tangibles

Los beneficios tangibles son aquellas ventajas u oportunidades que se pueden

cuantificar, y que se obtienen al hacer uso del sistema informático desarrollado. Son

fácilmente cuantificables y medibles en unidades monetarias. Entre estos beneficios

se encuentran:

- Disminución de tiempo en la generación de la planificación alimentaria.

Con la utilización del sistema automatizado se reduce el tiempo en el que el

personal tarda en generar la lista de los menús que van a ser preparados en la

semana y la hoja de pedido que contiene todos los insumos necesarios para

realizar dichos menús en el turno y día indicados en la planificación.

Actualmente la delegación del comedor universitario tarda en elaborar este

documento (que incluye la planificación de los menús alimentarios y las hojas

de pedidos tanto de la semana como de cada día 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, lográndose por

lo tanto mayor agilidad en la materialización de los mismos. A continuación

se muestra en el siguiente cuadro la diferencia existente entre implementar o

no el sistema que se propone.

Cuadro 34. Disminución de tiempo en la generación del plan alimentario. Tarea Horas Hombres empleadas

Sistema Actual Sistema Propuesto Beneficios

Generar Planificación

Alimentaria de la Semana 24 h/h 0.75 h/h 23.25 h/h


- Reducción de tiempo en el análisis de costos y generación del resumen

mensual de costos. Actualmente, el personal administrativo del comedor

universitario utiliza aproximadamente 40 h/h para elaborar el reporte mensual

346

de costos de la prestación del servicio de alimentación. En cambio, con el uso

del sistema solo se emplearía 0.5 h/h para generar este tipo de reporte. Esta

diferencia se puede apreciar claramente en el siguiente cuadro.

Cuadro 35. Reducción de tiempo en la generación 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.

- Integración de la información manejada en el área administrativa con la del

almacén y la de los registros de acceso de comensales, teniendo los datos

centralizados en una base de datos única.

- Poder recuperar información de forma rápida.

Beneficios Intangibles

Los beneficios intangibles son aquellos beneficios asociados a una mejora que

por su naturaleza son muy difíciles de cuantificar, pero de los que, indiscutiblemente,

la organización se ve beneficiada al llevar a cabo el desarrollo del proyecto. Estos

beneficios son los siguientes:

- Manejo de información más confiable.

- Mejor control de las existencias de insumos en almacén.

- Mayor facilidad en la elaboración de informes y reportes.

- Aumento en la calidad de servicio del comedor universitario.

- Motivación del personal al utilizar herramientas modernas que le permitan

eliminar tareas rutinarias o tediosas.

- Mejor imagen de la universidad al implementar nuevas tecnologías.

347

CONCLUSIONES

- Del análisis realizado al negocio, se pudo diagnosticar que la planificación

alimentaria, resulta un proceso de gran importancia para lograr la prestación

del servicio, pues de ella depende cuales insumos necesitan adquirirse para

preparar los menús alimentarios y controlar su existencia en el almacén del


- El estudio del funcionamiento actual del comedor universitario, también

permitió determinar la problemática presentada en dicha sección. Entre ellas:

la demora en la elaboración de la planificación alimentaria e informes de

costos, carencia de un medio que permita estimar el número de personas que

acudirán al comedor para el aprovechamiento del servicio y falta de control en

cuanto a entradas, salidas y existencias de insumos en almacén.

- El estudio y descripción 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

sección.

- El estudio de la situación 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,

centrándose en el usuario y sus necesidades.

- El diseño del sistema empleando el lenguaje UML, permitió obtener una

visualización más detallada de su estructura, ya que dicha herramienta

348

proporciona diferentes diagramas para describir la arquitectura del sistema.

- La metodología RUP, resultó ser una guía 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 rápida y sencilla la planificación alimentaria,

considerando la información nutricional de los menús y la demanda promedio

del servicio; le permitirá controlar el acceso de comensales al área de servicio

y la entrada/salida de insumos del almacén. También, traerá consigo ahorro

significativo de tiempo en la generación 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 más que escribir código, incluye

aspectos como el modelado del negocio y las tareas de análisis y diseño del

sistema.

349

RECOMENDACIONES

- Incorporar en un futuro la funcionalidad de planificación vía Web por parte

del estudiante, para determinar los días de asistencia y su preferencia en

cuanto a menús alimentarios; y así tomar en cuenta su opinión al momento de

realizar las planificaciones alimentarias.

- Mejorar la seguridad en el acceso de comensales, a través de la incorporación

de un sistema o medio de identificación más efectivo que permita autenticar al

estudiante que está accediendo a las instalaciones del comedor universitario.

- Implementar el sistema desarrollado en la sección del comedor universitario,

para que los usuarios puedan desempeñar 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 máximo

provecho a cada una de sus funcionalidades.

- Fortalecer la plataforma tecnológica del núcleo para que todas las áreas

involucradas tengan acceso a la red, dado que el sistema propuesto es una

aplicación Web.

- Realizar la conexión del sistema del comedor universitario del núcleo de

Monagas con el sub-sistema de control de estudios para realizar la validación

de los estudiantes que acceden al área de servicio del comedor.

350

- Vincular el sistema desarrollado con el subsistema de compra para utilizar

información requerida de las órdenes de compra en los procesos de registro de

entrada de artículos en almacén.

- Ampliar el espacio físico del almacén y dotarlo del mobiliario adecuado para

el resguardo de los insumos tanto perecederos como no perecederos; además

contar con un mayor nivel de seguridad en el área. Luego de lograr este

mejoramiento en las instalaciones del almacén, se recomienda, aplicar un

modelo de inventario en el comedor universitario, que le sirva de herramienta

útil para generar una política de inventario óptima, respecto a la cantidad y el

momento en el que deben realizarse los pedidos para reabastecer su almacén

con nuevos lotes de artículos, y lograr así un equilibrio entre no tener un

excesivo inventario y quedarse con cero insumos en almacén que provoquen

la paralización del servicio.

351

BIBLIOGRAFÍA

Alcarria, J. Contabilidad financiera I. Editor Universitat Jaume I. ISBN 8469118099.

Anderson, D. y Sweeney, D. (2004). Principios de Administración de Operaciones.

Editorial Internacional Thomson, México.

Arias, F. (2006). El Proyecto de Investigación (3era Edición). 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 Núcleo Monagas”. Universidad de Oriente, núcleo Monagas, Venezuela.

Batini, C. y Navathe, S. (2004). Diseño conceptual de bases de datos. Ediciones Díaz

de Santos. 574 p. ISBN 0201601206.

Berzal, F y Cubero, J. (2005). “Desarrollo Profesional de Aplicaciones Web con

ASP.NET”. Editorial iKor Consulting.

Briceño, G. (2008). “Sistema automatizado para la gestión de los procesos

administrativos de la delegación de planificación de la Universidad de Oriente Núcleo

Monagas”. Universidad de Oriente, núcleo Monagas, Venezuela.

Cobo, A.y Gómez, P. (2005).”PHP y MySQL - Tecnologías para el desarrollo de

aplicaciones Web”. Ediciones Díaz de Santos.

352

DECRETO Nº 3.090 DE LA PRESIDENCIA DE LA REPÚBLICA

BOLIVARIANA DE VENEZUELA. Gaceta 38.095 del 28/12/2004, sobre uso del

Software Libre.

Fonseca, R. (2008). “Sistema de Gestión en Ambiente Web para Salas Situacionales

en Instituciones Públicas Adscritas a Entes Gubernamentales. Caso de Estudio:

Centro Internacional Miranda Caracas”. Universidad Nacional Experimental del

Táchira, Venezuela.

Forouzan, B. (2003). Introducción a la ciencia de la Computación. 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). Introducción a la Contabilidad

Financiera. Editorial Pearson Educación, México. 704 p. ISBN 9701703863.

Hurtado, J. (2007). El Proyecto de Investigación. Metodología de la Investigación

Holística. Caracas: Quirón.

Hurtado, J. (2000). El proyecto de investigación. Editorial Sypal, Caracas, Venezuela.

JACOBSON, Ivar , BOOCH, Grady y RUMBAUGH, James. El Proceso Unificado

de Desarrollo de Software. Madrid: Pearson Educación S.A., 2000. 464 p. ISBN: 84-

7829-036-2

353

JACOBSON, I., BOOCH, G. y RUMBAUGH, J. El Lenguaje Unificado de

Modelado. Manual de Referencia. Madrid: Pearson Educación S.A., 2000. 552 p.

ISBN: 84-7829-037-0.

JACOBSON, I. (2000) El Proceso Unificado de Desarrollo de Software. Editorial

Pearson Educación, S.A., Madrid.

Krajewski, L. y Ritzman, Larry. (2000). Administración de Operaciones. Editorial

Pearson Educación, México.

Laporta, J. y Miralles M. (2005). Fundamentos de Telemática. Ed. Univ. Politéc.

Valencia. 408 p. ISBN 8497059131.

López, C. y Alonso J. (2007). La Tercera Revolución. Editorial Netbiblo, Madrid.

165 p. ISBN 8497452143.

Martínez, J. y Lara, P. (2007). ”La Producción de Contenidos Web”. Editorial: UOC.

75 p. ISBN 8497886739

Mata (1976). Manual de Procedimiento y Organización. Servicio de Comedores.

Universidad de Oriente, Venezuela.

Montilva, J. (1992). Desarrollo de sistemas de información. Mérida, Venezuela:

Universidad de Los Andes.

Mora, E. y Zorrilla, M. (2003). Iniciación a las Bases de Datos con Access 2002.

Ediciones Díaz de Santos. 272 p. ISBN 8479785926.

Moreno, M. (1993). Introducción a la Metodología de la Investigación Educativa.

Editorial Progreso. ISBN 9684368682.

354

Rodriguez, N. y Martinez, W. Planificación y Evaluación de Proyectos Informáticos.

Editor EUNED.

Rojas, J. (2005). “Sistema de Información Web para la Gestión y Control de

Contratos e Inventario de la Dirección de Ingeniería y Mantenimiento de la

Universidad de Los Andes”. Universidad de Los Andes, Venezuela.

Rueda, J. (2006). “Aplicación de la metodología RUP para el desarrollo rápido de

aplicaciones basado en el estándar j2ee”. Universidad de San Carlos, Guatemala.

Render, B. y Heizer, J. (2004). Principios de Administración de Operaciones.

Editorial Pearson Educación, México.

Rob, P. y Coronel, C. (2004). Sistemas de bases de datos: Diseño, implementación y

administración. Cengage Learning Editores. 838 p. ISBN 9706862862.

Tamayo y Tamayo, M. (2003). El Proceso de la Investigación Científica. Editorial

Limusa, México.

Taha, H. (2004). Investigación de Operaciones. Editorial Prentice Hall, México.

Warren, C., Reeve, J. y Fess P. (2005). Contabilidad Financiera. International

Thomson Editores, México, D.F.

ALARCON, R. Diseño Orientado a objetos con UML. [Documento en Línea].

Disponible: http://monjes.org/tutoriales-y-manuales/3069-diseno-orientado-objetos-

con-uml-raul-alarcon-grupo-eidos.html [Consulta: 2009, Abril 20].

355

Departamento de Sistemas Informáticos y Computación. Universidad Politécnica de

Valencia. Rational Unified Process (RUP). . [Documento en línea]. Disponible:

http://www.pid.dsic.upv.es [Consulta: 2009, Marzo 07]

Eguíluz, J. Introducción a AJAX. [Documento en Línea]. Disponible:

http://www.librosweb.es/ajax/index.html [Consulta: 2009, Mayo 07].

Quirón (2005). Introducción a UML 2.0. [Documento en Línea]. 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. [Página en Línea]. Disponible:

http://jms32.eresmas.net/tacticos/UML/UML04/UML0402.html [Consulta: 2009,

Abril 23]

UDO. [Pagina Web en Línea]. Disponible: http://www.udo.edu.ve/ [Consulta: 2008,

Diciembre 04].

Universidad De Oriente – Núcleo Monagas. (s.f.). ”Instructivo del Informe

Preliminar” [Documento en línea]. Disponible en:

http://150.186.84.19/monagas/mod/resource/ view.php?id=1462. [Consulta: 2008,

Junio 05].

Universidad De Oriente – Núcleo Monagas. (s.f.). “Áreas Temáticas de

Investigación” [Documento en línea]. Disponible en:

356

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 línea].

Disponible: http://es.wikipedia.org/wiki/Universidad_de_Oriente [Consulta: 2008,

Noviembre 16]

Wikipedia, La Enciclopedia Libre. Aplicación WEB. [Documento en Línea].

Disponible: http://es.wikipedia.org/wiki/Aplicaci%C3%B3n_web [Consulta: 2008,

Julio 04].

Wikipedia, La Enciclopedia Libre. PHP. [Documento en Línea]. Disponible:

http://es.wikipedia.org/wiki/PHP [Consulta: 2009, Mayo 07].

Wikipedia, La Enciclopedia Libre. AJAX. [Documento en Línea]. Disponible:

http://es.wikipedia.org/wiki/AJAX [Consulta: 2009, Mayo 07].

Wikipedia, La Enciclopedia Libre. XAMPP. [Documento en Línea]. Disponible:

http://es.wikipedia.org/wiki/XAMPP [Consulta: 2008, Julio 04].

357

ANEXOS

358

FORMAS DE REGISTROS INDICADAS EN EL MANUAL DEL COME DOR UNIVERSITARIO. Anexo 1. Forma Menú y Alimentos Requeridos.

359

Anexo 2. Forma Mercancías Despachadas Por Despensa.

360

Anexo 3. Forma Comprobante de Entrega de Materiales.

361

Anexo 4. Forma Control de Existencias.

362

Anexo 5. Forma Control Diario de Costo.

363

Anexo 6. Forma Resumen Mensual de Costo.

364

Anexo 7. Forma Diario de Almacén.

365

C R E A R N U E V O U S U A R IO

S i R e sp = fa l se

S i R e sp = t ru e

R E T O R N A R

B U S C A R U S U A R IO

E D IT A R U S U A R IO

E L IM IN A R U S U A R IO

S A L IR

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 ta 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 sta d e u su a ri o s

6 .P re si o n a b o to n " N u e v o "


8 .C a m b i a v e n ta n a9 .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 stra F o rm u l a ri o

1 5 .L l e n a d a to s d e u su a ri o a c re a r

1 6 .P re si o n a b o to n " A g re g a r"1 7 .P ro c e sa

1 8 .R e sp = v a l i d a r()

2 0 . i n se rta r()

2 1 .U su a ri o C re a d o E x i t o sa m e n te

2 4 .P re si o n a b o to n " R e to rn a r"

2 5 .a b re V e n ta n a ()2 6 .M u e st ra P a n ta l l a A n te ri o r

2 7 .L l e n a c a m p o d e b ú sq u e d a

2 8 .P re si o n a b o to 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 te 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 stra 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 te c l e a d a

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

3 3 .P re si o n a b o to n " M o d i f i c a r"

3 4 .a b re V e n ta n a ()

3 5 .C a m b i a V e n ta n a3 6 .C a rg a F o rm u l a ri o c o n d a to 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 9 .B u sc a T i p o s d e U su a ri o


4 1 . c a rg a rF o rm u l a ri o ()4 2 .M u e st ra f o rm u l a ri o c o n d a to s d e u su a ri o

4 3 .E d i t a D a to s d e l u su a ri o

4 4 .P re si o n a b o to n " M o d i f i c a r"4 5 .P ro c e sa

4 6 .a c tu a l i z a r()


1 9 .D a to s i n v a l i d o s o y a e x i ste e l n o m b re d e u su a ri o

4 7 .U su a ri o A c tu a l i z a d o E x i t o sa m e n te

4 8 .a b re V e n ta n a ()4 9 .M u e stra P a n ta l l a a n te ri o 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

5 1 .P re si o n a b o to 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 to sa m e n te

5 5 .P re si o n a b o to n " S a l i r"


5 7 .M u e stra P a n ta l l a d e l M e n u P ri n c i p a l

U su a ri o A d m i n i st ra d o r

W :A d m i n U su a ri o s U su a ri oW :U su a ri o T i p o U su a ri o

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


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 sta d e u su a ri o s

6 .P re si o n a b o to n " N u e v o "


8 .C a m b i a v e n ta n a9 .C a rg a F o rm u l a ri o


1 1 .B u sc a T i p o s d e U su a ri o s


1 3 . c a rg a rF o rm u l a ri o ()1 4 .M u e stra F o rm u l a ri o

1 5 .L l e n a d a to s d e u su a ri o a c re a r

1 6 .P re si o n a b o to n " A g re g a r"1 7 .P ro c e sa

1 8 .R e sp = v a l i d a r()

2 0 . i n se rta r()

2 1 .U su a ri o C re a d o E x i t o sa m e n te

2 4 .P re si o n a b o to n " R e to rn a r"


2 7 .L l e n a c a m p o d e b ú sq u e d a

2 8 .P re si o n a b o to 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 te 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 stra 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 te c l e a d a

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

3 3 .P re si o n a b o to n " M o d i f i c a r"


3 5 .C a m b i a V e n ta n a3 6 .C a rg a F o rm u l a ri o c o n d a to 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 9 .B u sc a T i p o s d e U su a ri o


4 1 . c a rg a rF o rm u l a ri o ()4 2 .M u e st ra f o rm u l a ri o c o n d a to s d e u su a ri o

4 3 .E d i t a D a to s d e l u su a ri o

4 4 .P re si o n a b o to n " M o d i f i c a r"4 5 .P ro c e sa

4 6 .a c tu a l i z a r()


1 9 .D a to s i n v a l i d o s o y a e x i ste e l n o m b re d e u su a ri o

4 7 .U su a ri o A c tu a l i z a d o E x i t o sa m e n te

4 8 .a b re V e n ta n a ()4 9 .M u e stra P a n ta l l a a n te ri o 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

5 1 .P re si o n a b o to 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 to sa m e n te

5 5 .P re si o n a b o to n " S a l i r"


5 7 .M u e stra P a n ta l l a d e l M e n u P ri n c i p a l

366

C R E A R N U E V O I N S U M O

S i R e s p = f a l se

S i R e s p = t r u e

B U S C A R I N S U M O

M O D I F I C A R I N S U M O

A g r e g a r I n s u m o e n T i p o M e n u

Q u i t a r I n s u m o e n T i p o M e n u

A g r e g a r N u t r i e n t e s d e l

I n s u m o

E d i t a r N u t r i e n t e d e l I n s u m o

E l i m i n a r N u t r i e n t e d e l

I n s u m o

A c t i v a r P r o p i e d a d e s d e

A l i m e n t o

D e s a c t i v a r P r o p i e d a d e s d e

A l i m e n t o

R E T O R N A R

E L I M I N A R I N S U M O

S i R e s p = f a l s e


S A L I R

1 . S e l e c i o n a " C a r g a r I n s u m o "

2 . a b r e V e n t a n a ( )

3 . B u s c a I n su m o s

4 . c a r g a r T i p o I n su m o ( )

5 . B u s c a t i p o s

6 . b u s c a r T i p o I n su m o ( )

7 . b u s c a r I n su m o s ( )8 . M u e st r a t i p o s y l i s t a d e i n s u m o s e n c o n t r a d o s

9 . P r e s i o n a b o t o n " N u e v o "

1 0 . a b r e V e n t a n a D e A g r e g a r I n s u m o ( )

1 1 . L l e n a d a t o s d e I n s u m o

1 2 . P r e s i 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 r o c e s a

1 4 . R e s p = v a l i d a r ( )

1 6 . i n s e r t a r ( )

1 5 . L o s d a t o s i n g r e s a d o s s o n i n v a l i d o s

1 7 . I n s u m o C r e 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

1 9 . B u sc a i n su m o s

2 0 . b u sc a r I n su m o s ( )2 1 . M u e st 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

2 2 . L l e n a c a m p o d e b ú sq u e d a

2 4 . B u sc a i n su m o s d e a c u e r d o c a d e n a d e c a r a c t e r e s t e c l e a d o s

2 6 . F i l t r a L i s t 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 a2 5 . b u sc a r I n su m o s ( )

2 3 . P r e s i o n a b o t o n " F i l t r a r "

2 7 . S e l e c c i o n a I n s u m o d e l a l i s t a

2 8 . P r e s i o n a b o t o n " M o d i f i c a r "

2 9 . a b r e V e n t a n a ( )

3 0 . C a m b i a V e n t a n a3 1 . C a r g a f o r m u l a r i o c o n d a t o s d e i n s u 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 r g a r U M ( )

3 4 . b u s c a u n i d a d e s d e m e d i d a

3 5 . b u s c a r U M ( )

3 6 . c a r g a r T i p o I n su m o ( )

3 7 . B u s c a t i p o s

3 8 . b u sc a r T i p o I n s u m o ( )

3 9 . c a r g 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 s c a r T i p o M e n u ( )

4 2 . c a r g a r G r u p o A l i m e n t o ( )

4 3 . B u s c a G r u p o s d e a l i m e n t o s

4 4 . b u s c a r G r u p o A l i m e n t o ( )

4 5 . c a r g a r T i p o N u t r i e n t e ( )

4 6 . B u s c a T i p o s d e N u t r i e n t e s

4 7 . b u s c a r T i p o N u t r i e n t e ( )

4 8 . c a r g a r N u t r i e n t e ( )

4 9 . B u sc a N u t r i e n t e s d e a c u e r d o a l t i p o d e n u t r i e n t e se l e c c i o n a d o

5 0 . b u s c 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 r g a r F o r m u l a r i o ( )5 2 . M u e st r a f o r m u l a r i 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

5 4 . M a r c a e l t i p o d e m e n u d o n d e s e u t i l i z a r á e l i n s u m o5 5 . P r o c e sa

5 6 . i n s e r t a r ( C o d I n su m o , C o d T i p o M e n u )

5 7 . D e s m a r c a e l t i p o d e m e n u d o n d e s e u t i l i z a r á e l i n s u m o5 8 . P r o c e sa

5 9 . e l i m i n a r ( C o d I n s u m o , C o d T i p o M e n u )

6 8 . S e l e c c i o n a t i p o d e n u t r i e n t e6 9 . P r o c e sa

7 0 . c a r g a r N u t r i e n t e ( )7 1 . B u sc a N u t r i e n t e s d e a c u e r d o a l t i p o d e n u t r i e n t e se l e c c i o n a d o

7 2 . b u s c 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 r a N u t r i e n t e s d e a c u e r d o a l t i p o se l e c c i o n a d o

7 4 . S e l e c c i o n a u n n u t r i e n t e7 5 . P r o c e s a

7 6 . i n s e r t a r N u t r i e n t e ( C o d I n s u m o , C o d N u t r i 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 r i e n t e7 8 . P r o c e s a

7 9 . m o d i f i c a r N u t r i e n t e ( )

8 0 . P r e s i o n a I c o n o " E l i m i n a r " d e l n u t r i e n t e d e l i n su m o a b o r r a r8 1 . P r o c e s a

8 2 . e l i m i n a r N u t r i e n t e ( )

8 3 . P r e s i o n a b o t o n " A c t u a l i z a r "

6 0 . M a r c a C a s i l l a " P r o p i e d a d e s d e A l i m e n t o "6 1 . P r o c e s a

6 2 . i n s e r t a r ( )6 3 . M u e st r a f o r m u l a r i o p a r a e d i c i o n d e p r o p i e d a d e s d e a l i m e n t o

6 4 . D e s m a r c a C a s i l l a " P r o p i e d a d e s d e A l i m e n t o "6 5 . P r o c e s a

6 6 . e l i m i n a r ( )6 7 . O c u l t a f o r m u l a r i o p a r a e d i c i o n d e p r o p i e d a d e s d e a l i m e n t o

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 r o p i e d a d e s d e a l i m e n t o

8 7 . a c t u a l i z a r ( )8 8 . I n s u m o A c t u a l i z a d o

8 9 . P r e s i o n a b o t o n " R e t o r n a r "

9 0 . a b r e V e n t a n a ( )

9 2 . P r e s i o n a b o t o n " E l i m i n a r "9 3 . P r o c e sa

9 4 . R e sp = c o m p r o b a r ( )

9 6 . e l i m i n a r ( )

9 5 . N o p u e d e e l i m i n a r s e e s t a s i e n d o u t i l i z a d o

9 7 . I n s u m o E l i m i n a d o

9 8 . a b r e V e n t a n a ( )9 9 . M u e s t r a p a n t a l l a a n t e r i o r

9 1 . M u e st r a p a n t a l l a a n t e r i o r

1 0 0 . P r e s i o n a b o t o n " S a l i r "

1 0 1 . a b r e V e n t a n a ( )

1 0 2 . M u e s t r a p a n t a l l a d e l M e n u P r i n c i p a l

U s u a r i o

W : R e g i s t r o I n s u m o s I n s u m o T i p o I n s u m oW : E d i c i o n I n s u m o U M T i p o M e n u G r u p o A l i m e n t o T i p o N u t r i e n t e N u t r i e n t e T i p o M e n u I n s u m o N u t r i e n t e A l i m e n t oA l i m e n t o

1 . S e l e c i o n a " C a r g a r I n s u m o "

2 . a b r e V e n t a n a ( )

3 . B u s c a I n su m o s

4 . c a r g a r T i p o I n su m o ( )

5 . B u s c a t i p o s

6 . b u s c a r T i p o I n su m o ( )

7 . b u s c a r I n su m o s ( )8 . M u e st r a t i p o s y l i s t a d e i n s u m o s e n c o n t r a d o s

9 . P r e s i o n a b o t o n " N u e v o "

1 0 . a b r e V e n t a n a D e A g r e g a r I n s u m o ( )

1 1 . L l e n a d a t o s d e I n s u m o

1 2 . P r e s i 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 r o c e s a

1 4 . R e s p = v a l i d a r ( )

1 6 . i n s e r t a r ( )

1 5 . L o s d a t o s i n g r e s a d o s s o n i n v a l i d o s

1 7 . I n s u m o C r e 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

1 9 . B u sc a i n su m o s

2 0 . b u sc a r I n su m o s ( )2 1 . M u e st 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

2 2 . L l e n a c a m p o d e b ú sq u e d a

2 4 . B u sc a i n su m o s d e a c u e r d o c a d e n a d e c a r a c t e r e s t e c l e a d o s

2 6 . F i l t r a L i s t 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 a2 5 . b u sc a r I n su m o s ( )

2 3 . P r e s i o n a b o t o n " F i l t r a r "

2 7 . S e l e c c i o n a I n s u m o d e l a l i s t a

2 8 . P r e s i o n a b o t o n " M o d i f i c a r "

2 9 . a b r e V e n t a n a ( )

3 0 . C a m b i a V e n t a n a3 1 . C a r g a f o r m u l a r i o c o n d a t o s d e i n s u 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 r g a r U M ( )

3 4 . b u s c a u n i d a d e s d e m e d i d a

3 5 . b u s c a r U M ( )


3 7 . B u s c a t i p o s


3 9 . c a r g 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 s c a r T i p o M e n u ( )

4 2 . c a r g a r G r u p o A l i m e n t o ( )

4 3 . B u s c a G r u p o s d e a l i m e n t o s

4 4 . b u s c a r G r u p o A l i m e n t o ( )

4 5 . c a r g a r T i p o N u t r i e n t e ( )

4 6 . B u s c a T i p o s d e N u t r i e n t e s

4 7 . b u s c a r T i p o N u t r i e n t e ( )

4 8 . c a r g a r N u t r i e n t e ( )

4 9 . B u sc a N u t r i e n t e s d e a c u e r d o a l t i p o d e n u t r i e n t e se l e c c i o n a d o

5 0 . b u s c 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 r g a r F o r m u l a r i o ( )5 2 . M u e st r a f o r m u l a r i 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

5 4 . M a r c a e l t i p o d e m e n u d o n d e s e u t i l i z a r á e l i n s u m o5 5 . P r o c e sa

5 6 . i n s e r t a r ( C o d I n su m o , C o d T i p o M e n u )

5 7 . D e s m a r c a e l t i p o d e m e n u d o n d e s e u t i l i z a r á e l i n s u m o5 8 . P r o c e sa

5 9 . e l i m i n a r ( C o d I n s u m o , C o d T i p o M e n u )

6 8 . S e l e c c i o n a t i p o d e n u t r i e n t e6 9 . P r o c e sa

7 0 . c a r g a r N u t r i e n t e ( )7 1 . B u sc a N u t r i e n t e s d e a c u e r d o a l t i p o d e n u t r i e n t e se l e c c i o n a d o

7 2 . b u s c 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 r a N u t r i e n t e s d e a c u e r d o a l t i p o se l e c c i o n a d o

7 4 . S e l e c c i o n a u n n u t r i e n t e7 5 . P r o c e s a

7 6 . i n s e r t a r N u t r i e n t e ( C o d I n s u m o , C o d N u t r i 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 r i e n t e7 8 . P r o c e s a

7 9 . m o d i f i c a r N u t r i e n t e ( )

8 0 . P r e s i o n a I c o n o " E l i m i n a r " d e l n u t r i e n t e d e l i n su m o a b o r r a r8 1 . P r o c e s a

8 2 . e l i m i n a r N u t r i e n t e ( )

8 3 . P r e s i o n a b o t o n " A c t u a l i z a r "

6 0 . M a r c a C a s i l l a " P r o p i e d a d e s d e A l i m e n t o "6 1 . P r o c e s a

6 2 . i n s e r t a r ( )6 3 . M u e st r a f o r m u l a r i o p a r a e d i c i o n d e p r o p i e d a d e s d e a l i m e n t o

6 4 . D e s m a r c a C a s i l l a " P r o p i e d a d e s d e A l i m e n t o "6 5 . P r o c e s a

6 6 . e l i m i n a r ( )6 7 . O c u l t a f o r m u l a r i o p a r a e d i c i o n d e p r o p i e d a d e s d e a l i m e n t o

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 r o p i e d a d e s d e a l i m e n t o

8 7 . a c t u a l i z a r ( )8 8 . I n s u m o A c t u a l i z a d o


9 0 . a b r e V e n t a n a ( )

9 2 . P r e s i o n a b o t o n " E l i m i n a r "9 3 . P r o c e sa

9 4 . R e sp = c o m p r o b a r ( )

9 6 . e l i m i n a r ( )

9 5 . N o p u e d e e l i m i n a r s e e s t a s i e n d o u t i l i z a d o

9 7 . I n s u m o E l i m i n a d o

9 8 . a b r e V e n t a n a ( )9 9 . M u e s t r a p a n t a l l a a n t e r i o r

9 1 . M u e st r a p a n t a l l a a n t e r i o r

1 0 0 . P r e s i o n a b o t o n " S a l i r "

1 0 1 . a b r e V e n t a n a ( )

1 0 2 . M u e s t r a p a n t a l l a d e l M e n u P r i n c i p a l

367

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

1 1 3 . M e n u E l i m i n a d o1 1 2 .e l i m i n a r()

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

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

E d i ta r I n su m o R e q u e ri d o

Q u i t a r In su m o Re q u e ri d o

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

R E T O R N A R

E L I M IN A R M E NU A L IM E N T A R IO

S i R e sp = fa l se

S i Re sp = tru e

S A L I R

4 5 .P re si o n a I co n o "B u sc a r"


4 7 . C a m b i a V e n ta n a

5 1 .b u sc a rT i p o M e n u ()

5 4 .b u sc a rG ru p o A l i m e n t o ()

4 8 .C a rg a i n fo rm a c i ó n

4 9 . ca 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 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 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 o5 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 cu e rd o a l t i p o se l e cc i o n a d o

6 1 .L l e n a Ca 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 r6 3 . B u sca I n su m o s d e a cu e rd o a ca 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 cu e rd o a ca d e n a t e c l e a d a

6 6 .S e l e cc i o n a G ru p o d e A l i m e n to6 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 cu e rd o a l g ru p o d e a l i m e n to s se l e c ci o n a d o

7 0 . S e l e c ci o n a In su m o d e l a l i sta7 1 .P ro c e sa

7 2 .ca 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

7 9 . E d i t a C a n ti d a d d e l I n su m o Re q u e ri d o8 0 . P ro c e sa

8 1 .a ct u a l i za r()

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 r8 3 . P ro c e sa

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

8 6 .S e l e cc 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 o8 7 .P ro c e sa

8 8 . ca rg a rIn su m o R e q u e ri d o M e n u ()

8 9 . B u sca 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 sca rIn su m o R e q u e ri d o M e n u ()

9 1 . ca rg a rA l i m e n to ()

9 2 . B u sca p ro p i e d a d e s d e a l i m e n to s

9 3 .b u sca 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 sca N u tr i 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 7 .c a l cu l a rNu tr i e n t e M e n u ()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 ci o n a d o

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 ce sa

1 0 1 .a ct u a l i za 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"

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"1 0 7 . P ro ce sa

1 0 8 .R e sp = c o m p ro b a r()

1 1 0 .e l i m i n a r(C o d M e n u )

1 1 4 . a b re V e n t a n a ()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 6 .P re si o n a b o to n "S a l i r"

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

CR E A R N U E V O M E N U

A L I M E NT A R IO

S i Re sp = fa l se

S i R e sp = tru e

B U S C A R M E NU A L I M E NT A R IO

M O D IF IC A R M E N U A L IM E N T A RI O

In c l u i r In su m o a l M e n ú

1 .S e l e cc i o n a "C o n f o rm a r M e n u "


3 . B u sca M e n u s A l i m e n t a ri o s

4 . ca rg a rT i p o M e n u ()

5 . B u sca t i p o d e m e n u

6 .b u sc a rT i p o M e n u ()

7 .b u sc a rM e n u s()8 .M u e st ra t i p o y l i sta d e m e n u s e n c o n tra d o s

9 .P re si o n b o to n " Nu e vo "

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 co n o "A g re g a r N u e v o M e n u "1 3 .P ro c e sa

1 4 . R e sp = v a l i d a r()

1 6 .i n se rta r()1 7 .M e n u C re a d o

1 5 . L o s d a to s i n tro d u ci d o s so n i n v a l i d o s

1 8 . S e l e c ci o n a T i p o d e M e n u1 9 . B u sca M e n u s

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 t i p o se l e cc i o n a d o

2 2 .L l e n a ca 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 ct 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 cc i o n a M e n u d e l a l i st a

2 8 .P re si o n a b o to n "M o d i f i c a r"


3 0 .C a m b i a ve n ta n a3 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 . ca rg a rT i p o M e n u ()

3 4 . B u sca T i p o s d e M e n u

3 5 .b u sca 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 tr i e n te

3 8 . b u sca rT i p o N u t ri e n te ()

3 9 .c a rg a rIn su m o Re 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 2 . ca rg a rF o rm u l a ri o ()4 3 .M u e stra fo rm u l a ri o co n i n fo rm a c i ó n d e l m e n u

U su a ri o

W :C o n fo rm a c i o n M e n u M e n u T i p o M e n uW :E d i c i o n 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 uW :B u sc a d o rI n su m o G ru p o A l i m e n to In su m o A l i m e n t o N u tri e n te A l i m e n to

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

1 1 3 . M e n u E l i m i n a d o1 1 2 .e l i m i n a r()

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

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 co n o "B u sc a r"


4 7 . C a m b i a V e n ta n a

5 1 .b u sc a rT i p o M e n u ()

5 4 .b u sc a rG ru p o A l i m e n t o ()

4 8 .C a rg a i n fo rm a c i ó n

4 9 . ca 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 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 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 o5 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 cu e rd o a l t i p o se l e cc i o n a d o

6 1 .L l e n a Ca 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 r6 3 . B u sca I n su m o s d e a cu e rd o a ca 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 cu e rd o a ca d e n a t e c l e a d a

6 6 .S e l e cc i o n a G ru p o d e A l i m e n to6 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 cu e rd o a l g ru p o d e a l i m e n to s se l e c ci o n a d o

7 0 . S e l e c ci o n a In su m o d e l a l i sta7 1 .P ro c e sa

7 2 .ca 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

7 9 . E d i t a C a n ti d a d d e l I n su m o Re q u e ri d o8 0 . P ro c e sa

8 1 .a ct u a l i za r()

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 r8 3 . P ro c e sa

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

8 6 .S e l e cc 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 o8 7 .P ro c e sa

8 8 . ca rg a rIn su m o R e q u e ri d o M e n u ()

8 9 . B u sca 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 1 . ca rg a rA l i m e n to ()

9 2 . B u sca p ro p i e d a d e s d e a l i m e n to s

9 3 .b u sca 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 sca N u tr i 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 7 .c a l cu l a rNu tr i e n t e M e n u ()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 ci o n a d o

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 ce sa

1 0 1 .a ct u a l i za 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"

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"1 0 7 . P ro ce sa

1 0 8 .R e sp = c o m p ro b a r()

1 1 0 .e l i m i n a r(C o d M e n u )

1 1 4 . a b re V e n t a n a ()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 6 .P re si o n a b o to n "S a l i r"

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

1 .S e l e cc i o n a "C o n f o rm a r M e n u "


3 . B u sca M e n u s A l i m e n t a ri o s

4 . ca rg a rT i p o M e n u ()

5 . B u sca t i p o d e m e n u

6 .b u sc a rT i p o M e n u ()

7 .b u sc a rM e n u s()8 .M u e st ra t i p o y l i sta d e m e n u s e n c o n tra d o s

9 .P re si o n b o to n " Nu e vo "

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 co n o "A g re g a r N u e v o M e n u "1 3 .P ro c e sa

1 4 . R e sp = v a l i d a r()

1 6 .i n se rta r()1 7 .M e n u C re a d o

1 5 . L o s d a to s i n tro d u ci d o s so n i n v a l i d o s

1 8 . S e l e c ci o n a T i p o d e M e n u1 9 . B u sca M e n u s

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 t i p o se l e cc i o n a d o

2 2 .L l e n a ca 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 ct 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 cc i o n a M e n u d e l a l i st a

2 8 .P re si o n a b o to n "M o d i f i c a r"


3 0 .C a m b i a ve n ta n a3 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 . ca rg a rT i p o M e n u ()

3 4 . B u sca T i p o s d e M e n u

3 5 .b u sca 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 tr i e n te

3 8 . b u sca rT i p o N u t ri e n te ()

3 9 .c a rg a rIn su m o Re 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 2 . ca rg a rF o rm u l a ri o ()4 3 .M u e stra fo rm u l a ri o co n i n fo rm a c i ó n d e l m e n u

368

134.Selecciona una Plani ficacion Alimentaria

135.Presiona Icono "Buscar Menú de Planificaciones Anteriores"

136.abreVentana()

137.Cambia Ventana 138.Busca Información de plani ficaciones anteriores de acuerdo al turno de la planificacion seleccionada

139.buscarPlanificaciones()

140.cargarInsumoRequeridoPlani ficacion()

143.cargarMenu()

144.cargarInsumosRequeridoMenu()

141.Busca Insumos Requeridos Para Prestar el Servicio

142.buscarInsumoRequeridoPlani ficacion()

145.Busca Informacion de menu de cada una de las planificaciones encontradas

146.buscarMenu(codMenu)

147.Busca insumos requeridos del menu

148.buscarInsumoRequeridoMenu()

149.cargarExistenciaArticulo()

150.Busca Existencia de Articulos en Almacen

151.buscarExistenciaArticulos()

152.comprobarExistenciaInsumosRequeridos()153.Muestra Planificaciones donde los menus alimentarios pueden preparse con los insumos existentes en almacen

154.Selecciona el Menu Al imentario de una Plani ficacion Anterior Disponible155.Procesa

156.actualizar()157.Muestra Plani ficacion Al imentaria con e l Menu y Estimado de Comensales Actualizados

Inclui r Menú a la Planificación Al imentaria

Cambiar Menu Planificado de acuerdo a disponibi lidad

en almacen

81.buscarTipoInsumo()

80.Busca Tipos de Insumo

Si Resp=false

Si Resp=true

Qui tar una Plani ficacion de Menu de la Plan ificación

Semanal

Incluir Insumo a la Planificación

Editar Insumo Requerido

Qui tar Insumo Requerido

Guardar Planificacion Alimentaria Semanal

BUSCAR PLANIFICACION ALIMENTARIA POR

SEMANA

RETORNAR

MODIFICAR PLANIFICACION

ALIMENTARIA SEMANAL

ELIMINAR PLANIFICACION ALIMENTARIA SEMANAL

Si tipo_semana!=evento especial

Si tipo_semana=evento especial

IMPRIMIR PLANIFICACION ALIMENTARIA SEMANAL

SALIR

52.Cambia Ventana53.Carga plani ficaciones anteriores e historial de comensales de acuerdo al dia y turno

54.buscarPlani ficaciones()

55.cargarComensales()

56.Busca historial de comensales de acuerdo a dia y turno

57.buscarComensales()58.Muestra los menus servidos y comensales atentidos en las fechas anteriores de acuerdo al dia y turno que se esta plani ficando

59.Presiona boton "Estimar"60.Procesa

61.estimarComensales()62.Muestra Estimado de Comensales

63.Presion boton "Aceptar" 64.Procesa

65.cargarEstimadoComensales()66.Muestra cantidad estimada de comensales en formulario

67.Presiona boton "Agregar"68.Procesa

69.Resp=val idar()

72.insertar()

71.Los datos ingresados son inval idos

73.Planificación Al imentaria Agregada

102.Presiona Icono "Eliminar" de la plani ficacion a borrar

73.Selecciona una Planificacion Al imentaria

75.Presiona icono "Incluir otros insumos a Plan ificacion"

76.abreVentana()

77.Cambia Ventana78.Carga Información

79.cargarTipoInsumo()

82.buscarInsumos()83.Muestra l ista de insumos sin prop iedades al imenticias de acuerdo al tipo que este seleccionado

84.Selecciona Tipo de Insumo85.Busca Insumos

86.buscarInsumos()87.Muestra l ista de insumos de acuerdo al tipo seleccionado


89.Presiona boton "Fi ltrar" 90.Busca Insumos de acuerdo a caracteres tecleados

91.buscarInsumos()92.Fi ltra lista de insumos de acuerdo a cadena tecleada

93.Selecciona Insumo de la lista

96.Edita Cantidad del Insumo Requerido

99.Presiona Icono "El iminar" del insumo requerido a borrar

103.Procesa

104.el iminar()

104.Elimina insumos requeridos de la planificacion

105.el iminar()

94.Procesa

95.insertar()

97.Procesa

98.actual izar()

100.Procesa

101.el iminar()

106.Presiona boton "Guardar"107.Procesa 108.Activa Semana

109.actua lizarSemana()110.Plani ficación Semanal Guardada

111.abreVentana()112.Muestra Pantal la Anterior

116.Selecciona una semana117.Busca Plani ficaciones de Menu de acuerdo a la semana seleccionada

118.buscarPlan ificaciones()

119.Muestra Plani ficaciones de acuerdo a la semana selecciona


114.abreVentana()115.Muestra Pantalla Anterior

120.Marca casi lla "Seleccionar Plani ficacion Alimentaria Semanal"

121.Presiona boton "Modificar"

122.abreVentana()

123.Cambia Ventana 124.Carga formulario con informacion de las plani ficaciones que estan dentro de la planificacion semanal seleccionada

125.cargarSemana()

126.Busca Semana Planificada

127.buscarSemana(CodSemana)

128.cargarTipoMenu()

129.Busca tipos de menu

130.buscarTipoMenu()

131.buscarPlani ficaciones()132.Muestra formulario con datos de las planificaciones a limentarias que estan dentro de la planificacion semanal seleccionada

133.Edita datos de las plani ficaciones alimentarias de la semana seleccionada

158.Presiona boton "Guardar"


160.Presiona boton "Eliminar"161.Procesa

162.el iminarPlanificacion(CodPlanificacion)

163.El imina insumos requeridos de p lani ficacion alimentaria

164.el iminar()

165.Desactiva semana

166.actualizarSemana()

167.Elimina Semana

168.el iminarSemana()

169.Planificacion Alimentaria Eliminada



173.generarReporte()

174.Envia reporte en formato imprimible

175.Reporte Impreso


177.abreVentana()

178.Muestra Pantal la del Menu principal

CREAR NUEVA PLANIFICACION

SEMANAL

Plan ificar para eventos especia les

Plani ficar para una semana normal de

servicio

Agregar una Plani ficacion de Menu a la Planificación

Semanal

Estimar comensales

1.Selecciona Plani ficar Servicio

2.abreVentana()

3.Buscas Planificaciones Creadas por Semana

4.cargarSemana()

5.Busca Semanas Planificadas

6.buscarSemanas()

7.buscarPlanificaciones()8.Muestra Semanas y Plani ficaciones de acuerdo a la ul tima semana plan ificada

10.abreVentana()

11.Cambia Ventana12.Carga formulario

13.cargarSemana()

14.Busca Semanas no plani ficadas

15.buscarSemanas()

16.cargarTipoMenu()

17.busca tipos de menu

18.buscarTipoMenu()19.Muestra formulario

20.Marca casi lla "Evento Especia l"

21.Muestra campo para crear evento especial

22.Escribe nombre del evento

23.Presion boton "Ok"

27.crearSemana()

25.Procesa 26.Crea semana para evento especial

28.Evento Creado

28.Selecciona una semana29.Procesa

30.crearFechasSemana()31.Muestra fechas de la semana

9.Presiona boton "Nuevo"

32.Selecciona o escribe fecha

34.Selecciona Tipo de menu

35.Presiona icono "Buscar Menu"

36.abreVentana()

33.Muestra dia

37.Cambia Ventana38.Busca menus de acuerdo a l tipo de menu seleccionado en la ventana anterior

39.buscarMenus()40.Muestra lista de Menus


42.Presiona boton "Fi ltrar"43.Busca menus de acuerdo a caracteres tecleados

44.buscarMenus()45.Fil tra l ista de menus de acuerdo a cadena tecleada

46.Selecciona Menu de la lista47.Procesa

48.cargarMenu()49.Muestra información de menu en formulario

50.Presiona icono "Estimar Numero de Comensales"

51.abreVentana()

Usuario

W:VistaPlani ficaciones W:EdicionPlani ficacion Plani ficacion Semana TipoMenuW:BuscadorMenu MenuW.EstimarComensales AccesoComensalesW:BuscadorInsumo Insumo InsumoRequeridoPlani ficacion

Impresora

TipoInsumoW:BuscadorMenuPlani ficado InsumoRequeridoMenu ExistenciaArticulo

134.Selecciona una Plani ficacion Alimentaria

135.Presiona Icono "Buscar Menú de Planificaciones Anteriores"

136.abreVentana()

137.Cambia Ventana 138.Busca Información de plani ficaciones anteriores de acuerdo al turno de la planificacion seleccionada


140.cargarInsumoRequeridoPlani ficacion()

143.cargarMenu()

144.cargarInsumosRequeridoMenu()

141.Busca Insumos Requeridos Para Prestar el Servicio

142.buscarInsumoRequeridoPlani ficacion()

145.Busca Informacion de menu de cada una de las planificaciones encontradas

146.buscarMenu(codMenu)

147.Busca insumos requeridos del menu


149.cargarExistenciaArticulo()

150.Busca Existencia de Articulos en Almacen

151.buscarExistenciaArticulos()

152.comprobarExistenciaInsumosRequeridos()153.Muestra Planificaciones donde los menus alimentarios pueden preparse con los insumos existentes en almacen

154.Selecciona el Menu Al imentario de una Plani ficacion Anterior Disponible155.Procesa

156.actualizar()157.Muestra Plani ficacion Al imentaria con e l Menu y Estimado de Comensales Actualizados

81.buscarTipoInsumo()

80.Busca Tipos de Insumo

52.Cambia Ventana53.Carga plani ficaciones anteriores e historial de comensales de acuerdo al dia y turno

54.buscarPlani ficaciones()

55.cargarComensales()

56.Busca historial de comensales de acuerdo a dia y turno

57.buscarComensales()58.Muestra los menus servidos y comensales atentidos en las fechas anteriores de acuerdo al dia y turno que se esta plani ficando

59.Presiona boton "Estimar"60.Procesa

61.estimarComensales()62.Muestra Estimado de Comensales

63.Presion boton "Aceptar" 64.Procesa

65.cargarEstimadoComensales()66.Muestra cantidad estimada de comensales en formulario

67.Presiona boton "Agregar"68.Procesa

69.Resp=val idar()

72.insertar()

71.Los datos ingresados son inval idos

73.Planificación Al imentaria Agregada

102.Presiona Icono "Eliminar" de la plani ficacion a borrar

73.Selecciona una Planificacion Al imentaria

75.Presiona icono "Incluir otros insumos a Plan ificacion"

76.abreVentana()

77.Cambia Ventana78.Carga Información

79.cargarTipoInsumo()

82.buscarInsumos()83.Muestra l ista de insumos sin prop iedades al imenticias de acuerdo al tipo que este seleccionado

84.Selecciona Tipo de Insumo85.Busca Insumos

86.buscarInsumos()87.Muestra l ista de insumos de acuerdo al tipo seleccionado


89.Presiona boton "Fi ltrar" 90.Busca Insumos de acuerdo a caracteres tecleados

91.buscarInsumos()92.Fi ltra lista de insumos de acuerdo a cadena tecleada

93.Selecciona Insumo de la lista

96.Edita Cantidad del Insumo Requerido

99.Presiona Icono "El iminar" del insumo requerido a borrar

103.Procesa

104.el iminar()

104.Elimina insumos requeridos de la planificacion

105.el iminar()

94.Procesa

95.insertar()

97.Procesa

98.actual izar()

100.Procesa

101.el iminar()

106.Presiona boton "Guardar"107.Procesa 108.Activa Semana

109.actua lizarSemana()110.Plani ficación Semanal Guardada

111.abreVentana()112.Muestra Pantal la Anterior

116.Selecciona una semana117.Busca Plani ficaciones de Menu de acuerdo a la semana seleccionada

118.buscarPlan ificaciones()

119.Muestra Plani ficaciones de acuerdo a la semana selecciona


114.abreVentana()115.Muestra Pantalla Anterior


121.Presiona boton "Modificar"

122.abreVentana()

123.Cambia Ventana 124.Carga formulario con informacion de las plani ficaciones que estan dentro de la planificacion semanal seleccionada

125.cargarSemana()

126.Busca Semana Planificada

127.buscarSemana(CodSemana)

128.cargarTipoMenu()


130.buscarTipoMenu()

131.buscarPlani ficaciones()132.Muestra formulario con datos de las planificaciones a limentarias que estan dentro de la planificacion semanal seleccionada

133.Edita datos de las plani ficaciones alimentarias de la semana seleccionada

158.Presiona boton "Guardar"


160.Presiona boton "Eliminar"161.Procesa

162.el iminarPlanificacion(CodPlanificacion)

163.El imina insumos requeridos de p lani ficacion alimentaria

164.el iminar()

165.Desactiva semana

166.actualizarSemana()

167.Elimina Semana

168.el iminarSemana()

169.Planificacion Alimentaria Eliminada



173.generarReporte()

174.Envia reporte en formato imprimible

175.Reporte Impreso


177.abreVentana()

178.Muestra Pantal la del Menu principal

1.Selecciona Plani ficar Servicio

2.abreVentana()

3.Buscas Planificaciones Creadas por Semana

4.cargarSemana()


6.buscarSemanas()

7.buscarPlanificaciones()8.Muestra Semanas y Plani ficaciones de acuerdo a la ul tima semana plan ificada

10.abreVentana()

11.Cambia Ventana12.Carga formulario

13.cargarSemana()

14.Busca Semanas no plani ficadas

15.buscarSemanas()

16.cargarTipoMenu()

17.busca tipos de menu

18.buscarTipoMenu()19.Muestra formulario

20.Marca casi lla "Evento Especia l"

21.Muestra campo para crear evento especial

22.Escribe nombre del evento

23.Presion boton "Ok"

27.crearSemana()

25.Procesa 26.Crea semana para evento especial

28.Evento Creado

28.Selecciona una semana29.Procesa

30.crearFechasSemana()31.Muestra fechas de la semana

9.Presiona boton "Nuevo"

32.Selecciona o escribe fecha

34.Selecciona Tipo de menu

35.Presiona icono "Buscar Menu"

36.abreVentana()

33.Muestra dia

37.Cambia Ventana38.Busca menus de acuerdo a l tipo de menu seleccionado en la ventana anterior

39.buscarMenus()40.Muestra lista de Menus


42.Presiona boton "Fi ltrar"43.Busca menus de acuerdo a caracteres tecleados

44.buscarMenus()45.Fil tra l ista de menus de acuerdo a cadena tecleada

46.Selecciona Menu de la lista47.Procesa

48.cargarMenu()49.Muestra información de menu en formulario

50.Presiona icono "Estimar Numero de Comensales"

51.abreVentana()

369

Si no ha sido creado el pedido

Si ya ha sido creado el pedido

31.actualizar()



IMPRIMIR HOJA DE PEDIDO

RETORNAR

21.calcularCantidadTotalInsumoRequerido()

17.cargarInsumoRequeridoPlanificacion()

18.Buscar Insumos requeridos para prestar el servicio en la planificacion seleccionada

19.buscarInsumoRequeridoPlanificacion()

25.Muestra las cantidades planificadas de insumos requeridos y sus existencias en almacen

22.cargarExistenciaArticulo()23.Busca cantidades existentes de los insumos requeridos en almacen

24.buscarExistenciaArticulo()

26.Edita cantidades a comprar de insumos requeridos

28.Procesa27.Presiona boton "Guardar"

29.Guarda las cantidades a comprar de insumos requeridos para prestar el servicio de alimentacion

30.Insertar()

32.Lista de Pedido Guardada

33.Presion boton "Imprimir"34.Procesa

35.generarHojaPedido()

36.Envia Reporte Hoja de Pedido en formato imprimible

37.Reporte de Hoja de Pedido Impreso

CONSULTAR INSUMOS REQUERIDOS DE UNA

PLANIFICACION ALIMENTARIA

1.Selecciona Planificar Servicio

2.abreVentana()

3.Busca Planificaciones creadas por semana

4.cargarSemana()


6.buscarSemanas()

7.buscarPlanificaciones()8.Muestra Semanas y las planificaciones de acuerdo a la ultima semana planificada

9.Selecciona Planificacion alimentaria

10.Presiona boton "Insumos"

11.abreVentana()

12.Cambia Ventana13.Busca informacion de la Planificacion seleccionada

14.cargarInsumoRequeridoMenu()

15.Busca Insumos requeridos para los menus programados en la planificacion seleccionada



Usuario

W:VistaPlanificaciones Planificacion SemanaW:InsumosRequeridos InsumoRequeridoMenu InsumoRequeridoPlanificacion ExistenciaArticulo PedidoInsumo

Impresora

31.actualizar()



21.calcularCantidadTotalInsumoRequerido()

17.cargarInsumoRequeridoPlanificacion()

18.Buscar Insumos requeridos para prestar el servicio en la planificacion seleccionada

19.buscarInsumoRequeridoPlanificacion()

25.Muestra las cantidades planificadas de insumos requeridos y sus existencias en almacen

22.cargarExistenciaArticulo()23.Busca cantidades existentes de los insumos requeridos en almacen

24.buscarExistenciaArticulo()

26.Edita cantidades a comprar de insumos requeridos

28.Procesa27.Presiona boton "Guardar"

29.Guarda las cantidades a comprar de insumos requeridos para prestar el servicio de alimentacion

30.Insertar()

32.Lista de Pedido Guardada

33.Presion boton "Imprimir"34.Procesa

35.generarHojaPedido()

36.Envia Reporte Hoja de Pedido en formato imprimible

37.Reporte de Hoja de Pedido Impreso

1.Selecciona Planificar Servicio

2.abreVentana()

3.Busca Planificaciones creadas por semana

4.cargarSemana()


6.buscarSemanas()

7.buscarPlanificaciones()8.Muestra Semanas y las planificaciones de acuerdo a la ultima semana planificada

9.Selecciona Planificacion alimentaria

10.Presiona boton "Insumos"

11.abreVentana()

12.Cambia Ventana13.Busca informacion de la Planificacion seleccionada

14.cargarInsumoRequeridoMenu()

15.Busca Insumos requeridos para los menus programados en la planificacion seleccionada



370

17.Procesa16.capturaCedula()

41.Procesa

42.generarReporte()

43.Envia Reporte en formato imprimible

40.Presiona boton "Imprimir"

44.Reporte Impreso

Imprimir información consultada

BUSCAR MENU A SERVIR

REGISTRAR COMENSALES

Si Resp=false

Si Resp=true

SALIR

CONSULTAR HISTORIAL DE COMENSALES

1.Selecciona Registrar Acceso de comensales

2.abreVentana()

3.Carga información

4.cargarT ipoMenu()


6.buscarT ipoMenu()

7.generarFecha()8.Muestra tipos de menu y fecha actual

9.Selecciona T ipo de Menu

10.Procesa

11.cargarMenuAl imentario()

12.Busca Menu de acuerdo a tipo y fecha actual

13.buscarMenu(codMenu)14.Muestra Menu Al imentario de acuerdo a la fecha actual y tipo de menu seleccionado

15.Pasa codigo de barra de carnet estudiantil por escaner

18.Busca Datos de Estudiante

19.cargarDatosEstudiante()

20.Busca estudiante por cedula

21.buscarEstudiante()22.Muestra Datos del Estudiante

23.Presiona boton "Registrar"24.Procesa

25.Resp=comprobar()

27.registrarComensal()28.Estudiante Registrado


30.abreVentana()

31.Muestra Pantal la del Menú Principal

33.abreVentana()

34.Muestra tipos de busqueda

32.Selecciona Consultar Historial Comensales

35.Selecciona T ipo de búsqueda

36.Presion boton "Aceptar"37.Procesa

38.buscarComensales()

26.Estudiante ya ha sido registrado

39.Muestra l ista de comensales registrados de acuerdo al tipo de búsqueda

Ayudante de Comedor

W:RegistroComensales AccesoComensal T ipoMenu Menu

Estudiante

EstudianteW:HistorialComensales

ImpresoraEscaner de Codigo Barra

17.Procesa16.capturaCedula()

41.Procesa

42.generarReporte()

43.Envia Reporte en formato imprimible

40.Presiona boton "Imprimir"

44.Reporte Impreso

1.Selecciona Registrar Acceso de comensales

2.abreVentana()

3.Carga información

4.cargarT ipoMenu()


6.buscarT ipoMenu()

7.generarFecha()8.Muestra tipos de menu y fecha actual

9.Selecciona T ipo de Menu

10.Procesa

11.cargarMenuAl imentario()

12.Busca Menu de acuerdo a tipo y fecha actual

13.buscarMenu(codMenu)14.Muestra Menu Al imentario de acuerdo a la fecha actual y tipo de menu seleccionado

15.Pasa codigo de barra de carnet estudiantil por escaner

18.Busca Datos de Estudiante

19.cargarDatosEstudiante()

20.Busca estudiante por cedula

21.buscarEstudiante()22.Muestra Datos del Estudiante

23.Presiona boton "Registrar"24.Procesa

25.Resp=comprobar()

27.registrarComensal()28.Estudiante Registrado


30.abreVentana()

31.Muestra Pantal la del Menú Principal

33.abreVentana()

34.Muestra tipos de busqueda

32.Selecciona Consultar Historial Comensales

35.Selecciona T ipo de búsqueda

36.Presion boton "Aceptar"37.Procesa

38.buscarComensales()

26.Estudiante ya ha sido registrado

39.Muestra l ista de comensales registrados de acuerdo al tipo de búsqueda

371

REGIST RAR INSUM O EN

ALMACEN

Buscar Insumo a reg istrar

Guardar Existencia de Insum o en

Alm acen Si Resp=fa lse

S i Resp=true

RETORNAR

BUSCAR ART ICULO REGISTRADO

M ODIFICAR REGIST RO DE INSUM O EN ALM ACEN

ELIM INAR REGIST RO DE INSUM O EN ALM ACEN

IMPRIM IR

SALIR

1.Registra r Insum os en A lm acen

2.abreVentana()

3 .Busca Existencias de articu los en a lm acen

4.buscarExistenciaArticu los()5 .M uestra Existencias de articu los en a lm acen

6.Presiona bo ton "Nuevo"

7 .abreVentana()

8.Cam bia Ventana9.Carga Formulario

10.cargarUb icacion()

11 .Busca ub icaciones en a lm acen

12.buscarUb icacion()

13 .cargarForm ulario ()14 .M uestra Form ulario

15.L lena da tos de existencia de insum o en alm acen

16.Presiona Icono "Buscar Insum os"

17.abreVentana()

18 .Cam bia Ventana19.Carga In fo rmacion

20.cargarT ipo Insum o()

21 .Busca T ipos de Insum o

22.buscarT ipo Insum o()

23 .buscarInsumos()24 .M uestra L ista de Insumos

25.Se lecciona T ipo de Insum o26.busca Insum os

27.buscarInsumos()28 .Muestra l i sta de Insum os de acuerdo a l tipo seleccionado

29.L lena cam po de busqueda

30.Presiona bo ton "Fi l trar"31 .Busca insumos de acuerdo a caracteres tecleados

32.buscarInsumos()33.Fi l tra li sta de insum os de acuerdo a cadena tecleada

34.Se lecciona Insumo de la l i sta35.Procesa

36.carga Insumo()37 .M uestra info rm acion de insum o en fo rm ulario

38.Presiona bo ton "Guardar" 39 .Procesa

40.Resp=va l idar()

41 .agregar()43 .Articu lo Reg istrado

42.Datos inval idos

44.abreVentana()45 .M uestra Panta l la an terio r

46 .Presiona bo ton "Retornar"

47 .M uestra panta l la an terio r47 .abreVentana()

49 .Llena cam po de búsqueda

50.Presiona "Fi l tra r"51 .Busca Existencias de articu los de acuerdo a caracteres tecleados

52.buscarExistenciaArticu los()53.M uestra L ista de articu los existen tes en a lm acen de acuerdo a la cadena tecleada

54.Selecciona articulo de la l i sta

55.Presiona bo ton "M od i ficar"

56 .abreVentana()

57 .Cam bia Ventana()58.Carga fo rm ulario con da tos de l a rticulo




63 .cargarFormulario ()

59 .buscarArticu lo ()

64.M uestra fo rm ulario con in fo rmación de l a rticu lo existen te en a lm acen

65.Ed i ta datos de l articu lo existen te en a lmacen

66.Presiona bo ton "Guardar"67 .Procesa

68.actua l izar()69 .Articulo Actua l izado

70.abreVentana()71 .M uestra panta l la an terio r

72 .Se lecciona un articu lo de la l i sta

73.Presiona bo ton "E l im inar"74 .Procesa

75.e lim inar()76 .Articulo E l im inado

77.Presiona bo ton "Im prim i r"78 .Procesa

79.generarReporte ()

80.Envia Reporte de existencias de articu los en fo rm ato im prim ib le

81.Reporte de existencias de articu los im preso

82.Presiona bo ton "Sa l i r"

83 .abreVentana()

84 .M uestra Panta l la de l M enu principa l

Usuario

W:Existencias ExistenciaArticu loW:EdicionReg istroExistencia Ub icacionW:BuscadorInsumo Insumo T ipo Insum o

Impresora

1 .Registra r Insum os en A lm acen

2.abreVentana()

3 .Busca Existencias de articu los en a lm acen

4.buscarExistenciaArticu los()5 .M uestra Existencias de articu los en a lm acen

6.Presiona bo ton "Nuevo"

7 .abreVentana()

8.Cam bia Ventana9.Carga Formulario




13 .cargarForm ulario ()14 .M uestra Form ulario

15.L lena da tos de existencia de insum o en alm acen

16.Presiona Icono "Buscar Insum os"

17.abreVentana()

18 .Cam bia Ventana19.Carga In fo rmacion

20.cargarT ipo Insum o()

21 .Busca T ipos de Insum o

22.buscarT ipo Insum o()

23 .buscarInsumos()24 .M uestra L ista de Insumos

25.Se lecciona T ipo de Insum o26.busca Insum os

27.buscarInsumos()28 .Muestra l i sta de Insum os de acuerdo a l tipo seleccionado

29.L lena cam po de busqueda

30.Presiona bo ton "Fi l trar"31 .Busca insumos de acuerdo a caracteres tecleados

32.buscarInsumos()33.Fi l tra li sta de insum os de acuerdo a cadena tecleada

34.Se lecciona Insumo de la l i sta35.Procesa

36.carga Insumo()37 .M uestra info rm acion de insum o en fo rm ulario

38.Presiona bo ton "Guardar" 39 .Procesa

40.Resp=va l idar()

41 .agregar()43 .Articu lo Reg istrado

42.Datos inval idos

44.abreVentana()45 .M uestra Panta l la an terio r

46 .Presiona bo ton "Retornar"

47 .M uestra panta l la an terio r47 .abreVentana()

49 .Llena cam po de búsqueda

50.Presiona "Fi l tra r"51 .Busca Existencias de articu los de acuerdo a caracteres tecleados

52.buscarExistenciaArticu los()53.M uestra L ista de articu los existen tes en a lm acen de acuerdo a la cadena tecleada

54.Selecciona articulo de la l i sta

55.Presiona bo ton "M od i ficar"

56 .abreVentana()

57 .Cam bia Ventana()58.Carga fo rm ulario con da tos de l a rticulo




63 .cargarFormulario ()

59 .buscarArticu lo ()

64.M uestra fo rm ulario con in fo rmación de l a rticu lo existen te en a lm acen

65.Ed i ta datos de l articu lo existen te en a lmacen

66.Presiona bo ton "Guardar"67 .Procesa

68.actua l izar()69 .Articulo Actua l izado

70.abreVentana()71 .M uestra panta l la an terio r

72 .Se lecciona un articu lo de la l i sta

73.Presiona bo ton "E l im inar"74 .Procesa

75.e lim inar()76 .Articulo E l im inado

77.Presiona bo ton "Im prim i r"78 .Procesa

79.generarReporte ()

80.Envia Reporte de existencias de articu los en fo rm ato im prim ib le

81.Reporte de existencias de articu los im preso

82.Presiona bo ton "Sa l i r"

83 .abreVentana()

84 .M uestra Panta l la de l M enu principa l

372

B U S C A R R E G I S T R O S D E E N T R A D A S D E

A R T I C U L O S

R E G I S T R A R E N T R A D A D E A R T I C U L O S

R e g i s t r a r d e t a l l e d e I n s u m o o A r t i c u l o

E n t r a n t e



M o d i f i c a r d e t a l l e d e I n s u m o o A r t i c u l o

E n t r a n t e

G u a r d a r



I M P R I M I R

R E T O R N A R

S A L I R

1 . S e l e c c i o n a R e g i s t r a r E n t r a d a s

2 . a b r e V e n t a n a ( )

3 . C a r g a i n f o r m 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 s i 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 s t 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 s t r a s t a t u s d e e n t r a d a e i n f o r m a c i ó n d e 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

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 r a d a1 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 s t 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 s t 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 s q u e d a

2 0 . P r e s i o n a b o t o n " F i l t r a 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 2 . b u s c a r R e g i s t r o s E n t r a d a ( )2 3 . F i l t 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 d e a c u e r d o a c a d e n a t e c l e a d a

2 4 . S e l e c c i o n a u n r e g i s t r o d e e n t r a d a d e l a l i s t a

2 5 . P r e s i o n b o t o n " R e g i s t r a r "

2 6 . a b r e V e n t a n a ( )

2 7 . C a m b i a V e n t a n a2 8 . C a r g 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 s t r o d e e n t r a d a s e l e c c i o n a d o

2 9 . b u s c a r R e g i s t r o E n t r a d a ( n u m E n t r a d a )

3 0 . c a r g a r S t a t u s E n t r a d a ( )

3 1 . B u s c a l o s d i f e r e n t e s s t a t u s d e e n t r a d a


3 3 . c a r g a r D e t a l l e E n t r a d a A r t i c u l o ( )

3 4 . B u s c a d e t a l l e s d e l r e g i s t r o d e e n t r a d a d e a r t i c u l o s

3 5 . b u s c a r D e t a l l e ( )

3 6 . c a r g a r F o r m u l a r i o ( )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 s t 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 r a l e s d e l R e g i s t r o d e E n t r a d a d e A r t i c u l o s

3 9 . P r e s i o n I c o n o " B u s c a r I n s u m o s "

4 0 . a b r e V e n t a n a ( )

4 1 . C a m b i a V e n t a n a4 2 . C a r g a I n f o r m a c i ó n


4 4 . B u sc a t i p o s d e 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 o4 9 . b u s c a I n s u m o s

5 0 . b u s c a r I n s u 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 2 . L l e n a c a m p o d e b u s q u e d a

5 3 . P r e s i o n a b o t o n " F i l t r a r "5 4 . B u s c a i n s u m o s 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

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 I n s u m o d e l a l i s t a5 8 . P r o c e sa

5 9 . c a r g a r I n s u m o ( )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

6 1 . E s c r i b e c a n t i d a d e n t r a n t e d e l a r t i c u l o

6 2 . P r e s i o n b o t o n " R e g i s t r a r "6 3 . P r o c e s a

6 4 . A g r e g a

6 5 . a g r e g a r ( )

6 6 . A c t u a l i z a e x i s t e n c i a d e a r t 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 ( )

6 8 . c a l c u l a r E x i s t e n c i a A c t u a l ( )

6 9 . a g r e g a r ( )7 0 . E n t r a d a d e A r t i c u l o R e g i s t r a d a

7 1 . E d i t a d a t o s d e e n t r a d a d e a r t i c u l o

7 2 . E d i t a P r e c i o U n i t a r i o d e l A r t i c u l o E n t r a n t e7 3 . P r o c e s a

7 4 . A c t u a l i z a D e t a l l e d e l A r t i c u l o E n t r a n t e

7 5 . a c t u a l i z a r ( )

7 6 . c a l c u l a r P r e c i o T o t a l ( )7 7 . A r t i c u l o E n t r a n t e a c t u a l i z a d o

7 8 . P r e s i o n b o t o n " G u a r d a r "7 9 . P r o c e s a

8 0 . R e sp = v a l i d a r ( )

8 2 . a c t u a l i z a r R e g i s t r o E n t r a d a ( )8 3 . R e g i s t r o A c t u a l i z a d o

8 1 . D a t o s I n v a l i d o s

8 4 . P r e s i o n a b o t o n " I m p r i m i r "8 5 . P r o c e s a

8 6 . g e n e r a r R e p o r t e R e g i s t r o E n t r a d a ( )

8 7 . E n v i a R e p o r t e d e R e g i s t r o d e E n t r a d a e n f o r m a t o i m p r i 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


9 0 . a b r e 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 s i o n a b o t o n " S a l i r "

9 3 . a b r e V e n t a n a ( )

9 4 . M u e s t r a P a n t a l l a d e l m e n u p r i n c i p a l

U s u a r i o

W : V i s t a R e g i s t r o sE n t r a d a E n t r a d a A r t i c u l o s A l m a c e n O r d e n C o m p r a P r o v e e d o r S t a t u s E n t r a d aW : R e g i s t r o E n t r a d a D e t a l l e E n t r a d a A r t i c u l oW : B u s c a d o r I n s u m o I n su m o T i p o I n s u m o E x i s t e n c i a A r t i c u l o

I m p r e s o r a

1 . S e l e c c i o n a R e g i s t r a r E n t r a d a s

2 . a b r e V e n t a n a ( )

3 . C a r g a i n f o r m 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 s i 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 s t 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 4 . M u e s t r a s t a t u s d e e n t r a d a e i n f o r m a c i ó n d e 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

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 r a d a1 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 s t 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 s t 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 s q u e d a

2 0 . P r e s i o n a b o t o n " F i l t r a 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 2 . b u s c a r R e g i s t r o s E n t r a d a ( )2 3 . F i l t 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 d e a c u e r d o a c a d e n a t e c l e a d a

2 4 . S e l e c c i o n a u n r e g i s t r o d e e n t r a d a d e l a l i s t a

2 5 . P r e s i o n b o t o n " R e g i s t r a r "

2 6 . a b r e V e n t a n a ( )

2 7 . C a m b i a V e n t a n a2 8 . C a r g 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 s t r o d e e n t r a d a s e l e c c i o n a d o

2 9 . b u s c a r R e g i s t r o E n t r a d a ( n u m E n t r a d a )

3 0 . c a r g a r S t a t u s E n t r a d a ( )

3 1 . B u s c a l o s d i f e r e n t e s s t a t u s d e e n t r a d a


3 3 . c a r g a r D e t a l l e E n t r a d a A r t i c u l o ( )

3 4 . B u s c a d e t a l l e s d e l r e g i s t r o d e e n t r a d a d e a r t i c u l o s

3 5 . b u s c a r D e t a l l e ( )

3 6 . c a r g a r F o r m u l a r i o ( )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 s t 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 r a l e s d e l R e g i s t r o d e E n t r a d a d e A r t i c u l o s

3 9 . P r e s i o n I c o n o " B u s c a r I n s u m o s "

4 0 . a b r e V e n t a n a ( )

4 1 . C a m b i a V e n t a n a4 2 . C a r g a I n f o r m a c i ó n


4 4 . B u sc a t i p o s d e 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 o4 9 . b u s c a I n s u m o s

5 0 . b u s c a r I n s u 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 2 . L l e n a c a m p o d e b u s q u e d a

5 3 . P r e s i o n a b o t o n " F i l t r a r "5 4 . B u s c a i n s u m o s 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

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 I n s u m o d e l a l i s t a5 8 . P r o c e sa

5 9 . c a r g a r I n s u m o ( )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

6 1 . E s c r i b e c a n t i d a d e n t r a n t e d e l a r t i c u l o

6 2 . P r e s i o n b o t o n " R e g i s t r a r "6 3 . P r o c e s a

6 4 . A g r e g a

6 5 . a g r e g a r ( )

6 6 . A c t u a l i z a e x i s t e n c i a d e a r t 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 ( )

6 8 . c a l c u l a r E x i s t e n c i a A c t u a l ( )

6 9 . a g r e g a r ( )7 0 . E n t r a d a d e A r t i c u l o R e g i s t r a d a

7 1 . E d i t a d a t o s d e e n t r a d a d e a r t i c u l o

7 2 . E d i t a P r e c i o U n i t a r i o d e l A r t i c u l o E n t r a n t e7 3 . P r o c e s a

7 4 . A c t u a l i z a D e t a l l e d e l A r t i c u l o E n t r a n t e

7 5 . a c t u a l i z a r ( )

7 6 . c a l c u l a r P r e c i o T o t a l ( )7 7 . A r t i c u l o E n t r a n t e a c t u a l i z a d o

7 8 . P r e s i o n b o t o n " G u a r d a r "7 9 . P r o c e s a

8 0 . R e sp = v a l i d a r ( )

8 2 . a c t u a l i z a r R e g i s t r o E n t r a d a ( )8 3 . R e g i s t r o A c t u a l i z a d o

8 1 . D a t o s I n v a l i d o s

8 4 . P r e s i o n a b o t o n " I m p r i m i r "8 5 . P r o c e s a

8 6 . g e n e r a r R e p o r t e R e g i s t r o E n t r a d a ( )

8 7 . E n v i a R e p o r t e d e R e g i s t r o d e E n t r a d a e n f o r m a t o i m p r i 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


9 0 . a b r e 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 s i o n a b o t o n " S a l i r "

9 3 . a b r e V e n t a n a ( )

9 4 . M u e s t r a P a n t a l l a d e l m e n u p r i n c i p a l

373

M o d i f i ca r A j u st e d e E x i st e n c i a d e a rt i cu l o d e a lm a ce n

M o d i fi ca r re g i stro d e l a ca n ti d a d sa l i e n te d e

a rt i c u l o

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

6 9 .E d i t a C a n t id a d S a l i e n te d e l A rt i cu l o7 0 .P ro ce sa

7 1 . m o d i f i c a r()

7 2 . ca l cu la rP re c i o T o ta l ()7 3 . A c tu a l i z a E x iste n c ia d e l a rt i cu l o e n A lm a ce n

7 4 . ca l c u l a rE x i st e n c i a A c t u a l ()7 5 .M u e stra P re c io T o t a l d e la 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 za d o a l a e x i ste n c i a d e l a rt i cu l o se l e cc io n a d o

7 6 .a b re V e n t a n a ()

7 7 . C a m b ia V e n t a n a 7 8 . C a rg a F o rm u l a rio c o n i n f o rm a c io n d e a j u ste d e l a rt i cu lo se l e c c i o n a d o

7 9 . b u sc a r()

8 0 . ca rg a rT ip o A j u st e ()

8 1 . B u sc a

8 2 .b u sca rT i p o A ju st e ()8 3 . M u e st ra F o rm u l a rio 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 cu lo se l e c c i o n a d o

8 4 . E d i t a F o rm u l a ri o

8 5 .P re si o n a b o t o n " G u a rd a r"8 6 . P ro ce sa

8 7 . m o d i f i ca r()8 8 . R e a l i za 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 za 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 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 ist 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 za d o

G u a rd a r

IM P R IM I R

S A L I R

R E G I S T R A R S A L I D A D E A R T I C U L O S D E L

A L M A C E N .

M O D I F I C A R R E G IS T R O D E S A L ID A D E A R T I C U L O S

D E L A L M A C E N .

4 3 . S e l e c c i o n a a rt i cu l o d e l a l i st a

4 4 .P re si o n a i c o n o A ju 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 6 . C a m b ia V e n t a n a4 7 . C a rg a f o rm u l a ri o

4 8 .c a rg a rE x ist e n c ia A rti cu lo ()4 9 . B u sca

5 0 . b u sca rA rt i cu l o ()


5 2 . B u sc a

5 3 .b u sca rT i p o A ju st e ()5 4 .M u e stra f o rm u l a rio p a ra re a l i z a r e l a ju st e d e e x i st e n c i a d e a rt i c u l o

5 5 . L l e n a fo rm u la ri o


5 8 .c re a rA j u ste ()5 9 . R e a l i za A ju st e

6 0 .a j u st a rE x ist e n c ia ()6 1 . A j u ste R e a l i za d o



6 6 .c re a rR e g ist ro S a l i d a ()6 7 .R e g i st ro d e sa l id a d e a rt i c u l o s re g ist ra d o s

9 7 .P re si o n a b o t o n " I m p rim i r"9 8 . P ro ce 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 ist ro d e S a l id a e n f o rm a t o im 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 id a Im p re so

1 0 3 .P re si o n a b o t o n " S a l i r"

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 rin c i p a l

B U S C A R M E N U P L A N IF IC A D O

S i R e sp = fa lse

S i R e sp = t ru e

R e g i st ra r c a n t i d a d sa l ie n t e d e a rt i c u l o

A j u sta r E x ist e n c ia d e a rti c u l o d e a l m a ce n

1 . S e l e c c i o n a R e g i stra r S a l id a s

2 . a b re V e n t a n a ()

3 . C a rg a i n f o rm a c io 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 sca rT i p o M e n u ()

9 .c a rg a rF o rm u la ri o ()1 0 .M u e st ra F o rm u la ri o

1 1 . S e l e c c i o n a T ip o d e M e n u1 2 . P ro ce sa

1 3 . ca rg a rP la n i f i c a c i o n ()

1 7 .B u sc a In fo rm a c i o n d e la P la n i fi ca c i o n d e a cu e rd o a f e ch 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 io n ()

2 6 .c a rg a rE x ist e n c ia A rti cu lo ()

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 in su m o s re q u e rid o s d e l m e n u

2 2 .b u sca rI n su m o R e q u e rid o M e n u ()

2 3 .B u sc a r I n su m o s re q u e rid o s p a ra p re st a r e l se rv i c io

2 4 . b u sca rI n su m o R e q u e ri d o P l a n i f i ca c i o n ()

2 5 . ca lc 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 rid o ()

2 7 . B u sca E x ist e n c ia e n a l m a c e n d e l o s in su m o s re q u e rid o s

2 8 . b u sc a rA rti cu lo ()

1 4 . ca rg a rM e n u ()

1 5 .c a rg a rI n su m o R e q u e rid o M e n u ()

2 9 . R e sp = ve ri fi c a rD i sp o n i b i l i d a d I n su m o A lm a ce n ()

1 6 . ca rg a rIn su m o R e q u e ri d o P la n i fi ca c i o n ()

3 1 . M u e st ra i n f o rm a c io n p a ra re a l i za r e l re g ist ro d e sa l i d a d e a rti cu lo s d e a lm a ce n

3 0 . N o e x ist 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 la n i fi ca d o

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 ca n ti d a d sa l i e n te d e l a rt i cu lo3 4 . P ro ce sa

3 5 . ve ri fi c a rC a n t i d a d S a l i e n t e ()

3 7 .A g re g a

3 8 .a g re g a r()

3 9 . c a l cu l a rP re c io T o t a l ()

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

4 0 . A c tu a l i z a E x iste n c ia d e l a rt i cu l o e n A lm a ce n


U su a ri o

W : R e g istro S a l id a S a l i d a A rt i c u l o sA l m a ce n T ip o M e n u P l a n i f i c a c i o n M e n 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 rid o P l a n i f i c a c io 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 cu l oW : A ju st e E x i st e n c i a A j u st e E x ist e n c ia T i p o A ju st e

I m p re so ra

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

6 9 .E d i t a C a n t id a d S a l i e n te d e l A rt i cu l o7 0 .P ro ce sa

7 1 . m o d i f i c a r()

7 2 . ca l cu la rP re c i o T o ta l ()7 3 . A c tu a l i z a E x iste n c ia d e l a rt i cu l o e n A lm a ce n


7 6 .P re si o n a i c o n o d e A j u ste re a l i za d o a l a e x i ste n c i a d e l a rt i cu l o se l e cc io n a d o

7 6 .a b re V e n t a n a ()

7 7 . C a m b ia V e n t a n a 7 8 . C a rg a F o rm u l a rio c o n i n f o rm a c io n d e a j u ste d e l a rt i cu lo se l e c c i o n a d o

7 9 . b u sc a r()


8 1 . B u sc a

8 2 .b u sca rT i p o A ju st e ()8 3 . M u e st ra F o rm u l a rio 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 cu lo se l e c c i o n a d o

8 4 . E d i t a F o rm u l a ri o


8 7 . m o d i f i ca r()8 8 . R e a l i za 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 za d o



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 ist 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 za d o

4 3 . S e l e c c i o n a a rt i cu l o d e l a l i st a

4 4 .P re si o n a i c o n o A ju 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 6 . C a m b ia V e n t a n a4 7 . C a rg a f o rm u l a ri o

4 8 .c a rg a rE x ist e n c ia A rti cu lo ()4 9 . B u sca

5 0 . b u sca rA rt i cu l o ()


5 2 . B u sc a

5 3 .b u sca rT i p o A ju st e ()5 4 .M u e stra f o rm u l a rio p a ra re a l i z a r e l a ju st e d e e x i st e n c i a d e a rt i c u l o

5 5 . L l e n a fo rm u la ri o


5 8 .c re a rA j u ste ()5 9 . R e a l i za A ju st e

6 0 .a j u st a rE x ist e n c ia ()6 1 . A j u ste R e a l i za d o



6 6 .c re a rR e g ist ro S a l i d a ()6 7 .R e g i st ro d e sa l id a d e a rt i c u l o s re g ist ra d o s

9 7 .P re si o n a b o t o n " I m p rim i r"9 8 . P ro ce 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 ist ro d e S a l id a e n f o rm a t o im 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 id a Im p re so

1 0 3 .P re si o n a b o t o n " S a l i r"

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 rin c i p a l

1 . S e l e c c i o n a R e g i stra r S a l id a s

2 . a b re V e n t a n a ()

3 . C a rg a i n f o rm a c io 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 sca rT i p o M e n u ()

9 .c a rg a rF o rm u la ri o ()1 0 .M u e st ra F o rm u la ri o

1 1 . S e l e c c i o n a T ip o d e M e n u1 2 . P ro ce sa

1 3 . ca rg a rP la n i f i c a c i o n ()

1 7 .B u sc a In fo rm a c i o n d e la P la n i fi ca c i o n d e a cu e rd o a f e ch 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 io n ()

2 6 .c a rg a rE x ist e n c ia A rti cu lo ()

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 in su m o s re q u e rid o s d e l m e n u

2 2 .b u sca rI n su m o R e q u e rid o M e n u ()

2 3 .B u sc a r I n su m o s re q u e rid o s p a ra p re st a r e l se rv i c io

2 4 . b u sca rI n su m o R e q u e ri d o P l a n i f i ca c i o n ()

2 5 . ca lc 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 rid o ()

2 7 . B u sca E x ist e n c ia e n a l m a c e n d e l o s in su m o s re q u e rid o s

2 8 . b u sc a rA rti cu lo ()

1 4 . ca rg a rM e n u ()

1 5 .c a rg a rI n su m o R e q u e rid o M e n u ()

2 9 . R e sp = ve ri fi c a rD i sp o n i b i l i d a d I n su m o A lm a ce n ()

1 6 . ca rg a rIn su m o R e q u e ri d o P la n i fi ca c i o n ()

3 1 . M u e st ra i n f o rm a c io n p a ra re a l i za r e l re g ist ro d e sa l i d a d e a rti cu lo s d e a lm a ce n

3 0 . N o e x ist 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 la n i fi ca d o

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 ca n ti d a d sa l i e n te d e l a rt i cu lo3 4 . P ro ce sa

3 5 . ve ri fi c a rC a n t i d a d S a l i e n t e ()

3 7 .A g re g a

3 8 .a g re g a r()

3 9 . c a l cu l a rP re c io T o t a l ()

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

4 0 . A c tu a l i z a E x iste n c ia d e l a rt i cu l o e n A lm a ce n


374

3 . B u s c a T i p o s d e R e p o r t e

4 . b u s c a r ( )5 . M u e s t r a T i p o s d e R e p o r t e s

G E N E R A R R E P O R T E C O N T R O L D I A R I O D E

C O S T O S

G E N E R A R R E P O R T E R E L A C I O N P O R

S E R V I C I O Y N U M E R O D E C O M E N S A L E S

G E N E R A R R E P O R T 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 R O S R E 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 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 R E 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 R E S U M E N M E N S U A L D E

C O S T O S

I M P R I M I R R E P O R T E

S A L I R

1 . S e l e c c i o n a G e n e r a r R e s u m e n d e C o s t o s

2 . a b r e V e n t a n a ( )

6 . S e l e c c i o n a C o n t r o l D i a r i o d e C o s t o s

8 . I n t r o d u c e F e c h a

9 . P r e s i o n b o t o n " A c e p t a r "1 0 . P r o c e s a

1 4 . b u s c a r P l a n i f i c a c i o n ( )

1 5 . B u s c a M e n u P l a n i f i c a d o

1 6 . b u s c a r M e n u ( c o d M e n u )

1 1 . c a r g a r P l a n i f i c a c i o n ( )

1 2 . c a r g a r M e n u ( )

1 7 . c a r g a r S a l i d a A r t i c u l o s ( )

2 3 . c a r g a r N u m C o m e n s a l e s ( )

1 3 . B u s c a P l a n i f i c a c i o n e s d e a c u e r d o a f e c h a

1 8 . B u s c a s a l i d a d e a r t i c u l o s d e a c u e r d o a l o p l a n i f i c a d o p a r a e s a f e c h a

1 9 . b u s c a r R e g i s t r o S a l i d a ( )

2 0 . B u s c a d e t a l l e s d e a c u e r d o a n u m e r o d e s a l i d a

2 1 . b u s c a r D e t a l l e ( )2 2 . c a l c u l a r C o s t o S e r v i c i o ( )

2 4 . B u s c 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 r d o a l d i a y t u r n o s p l a n i f i c a d o s

2 5 . b u s c a r C o m e n s a l e s ( )2 6 . c a l c u l a r C o s t o U n i t a r i o S e r v i c i o ( )

2 7 . M u e s t r a R e p o r t e C o n t r o l D i a r i o d e C o s t o s

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 r v i c i o y N u m e r o d e C o m e n s a l e s

3 1 . S e l e c c i o n a m e s y a ñ o

3 2 . P r e s i o n a b o t o n " A c e p t a r "3 3 . P r o c e s a


3 5 . B u s c a P l a n i f i c a c i o n e s d e a c u e r d o a m e s y a ñ o



3 8 . B u s c 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 r d o a l o s d i a s y t u r n o s p l a n i f i c a d o s e n e l m e s y a ñ o s e l e c c i o n a d o s

3 9 . b u s c a r C o m e n s a l e s ( )4 0 . c a l c u l a r T o t a l C o m e n s a l e s M e s ( )

4 1 . M u e s t r a R e p o r t e R e l a c i o n p o r s e r v i c i o y n u m e r o d e c o m e n s a l e s

4 2 . 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 , B e b i d a s y O t r o s R e c i b i d a s P o r A l m a c e n 4 3 . B u s c a

4 4 . c a r g a r P r o v e e d o r e s ( )

4 5 . B u s c a P r o v e e d o r e s d e l C o m e d o r U n i v e r s i t a r i o

4 6 . b u s c a r P r o v e e d o r e s ( )4 7 . M u e s t r a l i s t a d e m e s e s , a ñ o s y p r o v e e d o r e s

4 8 . S e l e c c i o n a A ñ o y P r o v e e d o r M e s

4 9 . P r e s i o n a B o t o n " A c e p t a r "5 0 . P r o c e s a

5 1 . c a r g a r R e g i s t r o s E n t r a d a ( )

5 2 . B u s c a e n t r a d a d e a r t i c u l o s d e a c u e r d o a l o s e l e c c i o n a d o

5 3 . b u s c a r R e g i s t r o s E n t r a d a ( )

5 4 . b u s c a

5 5 . b u s c a r O r d e n C o m p r a ( n u m O r d e n )5 6 . b u s c a

5 7 . b u s c a r P r o v e e d o r ( c o d P r o v e e d o r )

5 8 . c a l c u l a r C o s t o T o t a l E n t r a d a ( )5 9 . M u e s t r a R e p o r t 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 r o s r e c i b i d a s p o r a l m a c e n

7 . M u e s t r a c a m p o F e c h a

3 0 . M u e s t r a l i s t a d e M e s e s y A ñ o s

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 r e g a d o s P o r A l m a c e n

6 1 . M u e s t r a L i s t a d e M e s e s y A ñ o s




6 6 . B u s c a s a l i d a s d e a r t i c u l o s d e a c u e r d o a m e s y a ñ o s e l e c c i o n a d o s



6 9 . b u s c a r D e t a l l e ( )7 0 . c a l c u l a r C o s t o T o t a l S a l i d a ( m e s , a ñ o )

7 1 . M u e s t r a R e p o r t 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 r e g a d o s P o r A l m a c e n

7 2 . S e l e c c i o n a R e s u m e n M e n s u a l d e C o s t o s





8 1 . B u s c a s a l i d a s d e a r t i c u l o s d e a c u e r d o a l o s d i a s y t u r n o s p l a n i f i c a d o s e n e l a ñ o s e l e c c i o n a d o



7 8 . B u s c a P l a n i f i c a c i o n e s d e a c u e r d o a l a ñ o s e l e c c i o n a d o


8 3 . c a l c u l a r C o s t o T o t a l S a l i d a ( m e s , a ñ o )

8 5 . c a l c u l a r C o s t 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 r i o r ( )

8 6 . c a l c u l a r C o s t o T o t a l A c u m u l a d o A L a f e c h a ( )

8 4 . c a l c u l a r C o s t o T o t a l M e s ( )


8 8 . B u s c 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 r d o a l o s d i a s y t u r n o s p l a n i f i c a d o s e n e l a ñ o s e l e c c i o n a d o

8 9 . b u s c a r C o m e n s a l e s ( )

9 0 . c a l c u l a r T o t a l C o m e n s a l e s M e s ( )

9 1 . c a l c u l a T o t a l C o m e n s a l e s H a s t a M e s A n t e r i o r ( )

9 2 . c a l c u l a r T o t a l C o m e n s a l e s A L a F e c h a ( )

9 3 . c a l c u l a r C o s t o U n i t a r i o S e r v i c i o M e s ( )

9 4 . c a l c u l a r C o s t o U n i t a r i o S e r v i c i o A L a F e c h a ( )9 5 . M u e s t r a R e p o r t e R e s u m e n M e n s u a l d e C o s t o s

9 6 . E d i t a R e p o r t e

2 8 . E s c r i b e O b s e r v a c i o n

9 7 . P r e s i o n B o t o n " I m p r i m i r "

9 8 . g e n e r a r R e p o r t e ( )

9 9 . E n v i a R e p o r t e e n F o r m a t o I m p r i m i b l e

1 0 0 . R e p o r t e I m p r e s o

1 0 1 . P r e s i o n a B o t o n " S a l i r "

1 0 2 . a b r e V e n t a n a ( )

1 0 3 . M u e s t r a P a n t a l l a d e l M e n u P r i n c i p a l

U s u a r i o

W : R e p o r t e C o s t o s P l a n i f i c a c i o n M e n uR e p o r t e C o s t o s S a l i d a A r t i c u l o s A l m a c e n D e t a l l e S a l i d a A r t i c u l o A c c e s o C o m e n s a l P r o v e e d o r E n t r a d a A r t i c u l o s A l m a c e n O r d e n C o m p r a

I m p r e s o r a

T i p o R e p o r t e

3 . B u s c a T i p o s d e R e p o r t e

4 . b u s c a r ( )5 . M u e s t r a T i p o s d e R e p o r t e s

1 . S e l e c c i o n a G e n e r a r R e s u m e n d e C o s t o s

2 . a b r e V e n t a n a ( )

6 . S e l e c c i o n a C o n t r o l D i a r i o d e C o s t o s

8 . I n t r o d u c e F e c h a

9 . P r e s i o n b o t o n " A c e p t a r "1 0 . P r o c e s a


1 5 . B u s c a M e n u P l a n i f i c a d o

1 6 . b u s c a r M e n u ( c o d M e n u )


1 2 . c a r g a r M e n u ( )



1 3 . B u s c a P l a n i f i c a c i o n e s d e a c u e r d o a f e c h a

1 8 . B u s c a s a l i d a d e a r t i c u l o s d e a c u e r d o a l o p l a n i f i c a d o p a r a e s a f e c h a



2 1 . b u s c a r D e t a l l e ( )2 2 . c a l c u l a r C o s t o S e r v i c i o ( )

2 4 . B u s c 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 r d o a l d i a y t u r n o s p l a n i f i c a d o s

2 5 . b u s c a r C o m e n s a l e s ( )2 6 . c a l c u l a r C o s t o U n i t a r i o S e r v i c i o ( )

2 7 . M u e s t r a R e p o r t e C o n t r o l D i a r i o d e C o s t o s

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 r v i c i o y N u m e r o d e C o m e n s a l e s




3 5 . B u s c a P l a n i f i c a c i o n e s d e a c u e r d o a m e s y a ñ o



3 8 . B u s c 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 r d o a l o s d i a s y t u r n o s p l a n i f i c a d o s e n e l m e s y a ñ o s e l e c c i o n a d o s

3 9 . b u s c a r C o m e n s a l e s ( )4 0 . c a l c u l a r T o t a l C o m e n s a l e s M e s ( )

4 1 . M u e s t r a R e p o r t e R e l a c i o n p o r s e r v i c i o y n u m e r o d e c o m e n s a l e s

4 2 . 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 , B e b i d a s y O t r o s R e c i b i d a s P o r A l m a c e n 4 3 . B u s c a

4 4 . c a r g a r P r o v e e d o r e s ( )

4 5 . B u s c a P r o v e e d o r e s d e l C o m e d o r U n i v e r s i t a r i o

4 6 . b u s c a r P r o v e e d o r e s ( )4 7 . M u e s t r a l i s t a d e m e s e s , a ñ o s y p r o v e e d o r e s

4 8 . S e l e c c i o n a A ñ o y P r o v e e d o r M e s

4 9 . P r e s i o n a B o t o n " A c e p t a r "5 0 . P r o c e s a

5 1 . c a r g a r R e g i s t r o s E n t r a d a ( )

5 2 . B u s c a e n t r a d a d e a r t i c u l o s d e a c u e r d o a l o s e l e c c i o n a d o

5 3 . b u s c a r R e g i s t r o s E n t r a d a ( )

5 4 . b u s c a

5 5 . b u s c a r O r d e n C o m p r a ( n u m O r d e n )5 6 . b u s c a

5 7 . b u s c a r P r o v e e d o r ( c o d P r o v e e d o r )

5 8 . c a l c u l a r C o s t o T o t a l E n t r a d a ( )5 9 . M u e s t r a R e p o r t 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 r o s r e c i b i d a s p o r a l m a c e n

7 . M u e s t r a c a m p o F e c h a

3 0 . M u e s t r a l i s t a d e M e s e s y A ñ o s

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 r e g a d o s P o r A l m a c e n





6 6 . B u s c a s a l i d a s d e a r t i c u l o s d e a c u e r d o a m e s y a ñ o s e l e c c i o n a d o s



6 9 . b u s c a r D e t a l l e ( )7 0 . c a l c u l a r C o s t o T o t a l S a l i d a ( m e s , a ñ o )

7 1 . M u e s t r a R e p o r t 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 r e g a d o s P o r A l m a c e n

7 2 . S e l e c c i o n a R e s u m e n M e n s u a l d e C o s t o s





8 1 . B u s c a s a l i d a s d e a r t i c u l o s d e a c u e r d o a l o s d i a s y t u r n o s p l a n i f i c a d o s e n e l a ñ o s e l e c c i o n a d o



7 8 . B u s c a P l a n i f i c a c i o n e s d e a c u e r d o a l a ñ o s e l e c c i o n a d o


8 3 . c a l c u l a r C o s t o T o t a l S a l i d a ( m e s , a ñ o )

8 5 . c a l c u l a r C o s t 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 r i o r ( )

8 6 . c a l c u l a r C o s t o T o t a l A c u m u l a d o A L a f e c h a ( )

8 4 . c a l c u l a r C o s t o T o t a l M e s ( )


8 8 . B u s c 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 r d o a l o s d i a s y t u r n o s p l a n i f i c a d o s e n e l a ñ o s e l e c c i o n a d o

8 9 . b u s c a r C o m e n s a l e s ( )

9 0 . c a l c u l a r T o t a l C o m e n s a l e s M e s ( )

9 1 . c a l c u l a T o t a l C o m e n s a l e s H a s t a M e s A n t e r i o r ( )

9 2 . c a l c u l a r T o t a l C o m e n s a l e s A L a F e c h a ( )

9 3 . c a l c u l a r C o s t o U n i t a r i o S e r v i c i o M e s ( )

9 4 . c a l c u l a r C o s t o U n i t a r i o S e r v i c i o A L a F e c h a ( )9 5 . M u e s t r a R e p o r t e R e s u m e n M e n s u a l d e C o s t o s

9 6 . E d i t a R e p o r t e

2 8 . E s c r i b e O b s e r v a c i o n

9 7 . P r e s i o n B o t o n " I m p r i m i r "

9 8 . g e n e r a r R e p o r t e ( )

9 9 . E n v i a R e p o r t e e n F o r m a t o I m p r i m i b l e

1 0 0 . R e p o r t e I m p r e s o

1 0 1 . P r e s i o n a B o t o n " S a l i r "

1 0 2 . a b r e V e n t a n a ( )

1 0 3 . M u e s t r a P a n t a l l a d e l M e n u P r i n c i p a l

375

1..*Pertenece

1..1Agrupa

1..*Tiene

1..1Corresponde

1..*Pertenece

1..1Agrupa

1..*Pertenece

1..1Agrupa

1..*EsComposicionDe

1..1EstaCompuestoDe

1..*EsRepresentadoPor

1..1Representa

1..*Pertenece

1..1Agrupa

1..*Tiene

1..1Corresponde

1..*Utiliza

1..1EsUtilizadoEn


1..1Representa

1..*Compone

1..1Consta


1..1Representa

1..1Contiene

1..*Existe

1..1Contiene

1..1Conforma

1..*Posee

1..1EsTurnoDe

1..*Compone

1..1Consta

1..1EsGeneradoDe

1..1Genera

1..*Corresponde

1..1Tiene

1..*EsUtilizadoEn

1..1Utiliza

1..*Tiene

1..1EsTurnoDe

1..1Contiene

1..*Compone

1..*Tiene

1..1EsEstadoDe

0..*EsElaboradoPor

1..1Elabora

1..*Pertenece

1..1Agrupa

1..*Correponde

1..1Tiene

1..1EstaSituadoEn

1..1Situa

1..1ContieneEntradaDe

1..1SeEncuentraEn

1..1Contiene

1..*Conforma

1..*Posee

1..1EsEstadoDe

1..1Contiene

1..1Pertenece

1..1ContieneDatosDe

1..1EstaContenidaEn

1..1ContieneSalidaDe

1..1SeEncuentraEn

1..1Contiene

1..*Conforma

0..1SeRealizanEn

1..1Tiene

1..1Cambia

1..1EsAjustadaPor

1..*Pertenece

1..1Agrupa

1..*Pertenece

1..1Agrupa

1..*Corresponde

1..*Genera


1..1Representa

1..*Pertenece

1..1Agrupa

1..1EsPropiedadDe

1..*TienePropiedadDe

1..1Corresponde

1..1Solicita

Insumo

-----

codInsumodescripcioncodUmcodTipoInsumoalimento

: String: String: String: String: String

+++++++++++++++

cargarTipoInsumo ()buscarInsumos ()validar ()insertar ()buscarInsumo (String codInsumo)cargarUm ()cargarTipoMenu ()cargarGrupoAlimento ()cargarTipoNutriente ()cargarNutriente ()cargarFormulario ()actualizar ()comprobar ()eliminar ()cargarInsumo ()

: void: void: void: void: void: void: void: void: void: void: void: void: void: void: void

Um

--

codUmdescripcionUm

: String: String

+++++

insertar ()actualizar ()eliminar ()buscarUm ()buscar (String codUm)

: void: void: void: void: void

TipoInsumo

--

codTipoInsumodescripcion

: String: String

+++++

insertar ()actualizar ()eliminar ()buscarTipoInsumo ()buscar (String codTipo)


TipoMenuInsumo

--

codInsumocodTipoMenu

: String: String

+++

insertar (String codInsumo, String codTipoMenu)eliminar (String codInsumo, String codTipoMenu)eliminar (String codInsumo)

: void: void: void

TipoMenu

--

codTipoMenudescripcionTipoMenu

: String: String

+++++

insertar ()actualizar ()eliminar ()buscarTipoMenu ()buscar (String codTipo)


Menu

---

codMenudescripcionMenucodTipoMenu

: String: String: String

+++++++++++++++

cargarTipoMenu ()buscarMenus ()validar ()insertar ()buscarMenu (String codMenu)cargarTipoNutriente ()cargarInsumoRequeridoMenu ()cargarFormulario ()cargarAlimento ()cargarNutrienteAlimento ()calcularNutrienteMenu ()actualizar ()comprobar ()eliminar (String codMenu)cargarMenu ()


Alimento

---

codInsumopesocodGrupo

: String: Double: String

+++++

insertar ()eliminar ()actualizar ()buscarAlimentos ()buscar (String codInsumo)


GrupoAlimento

--

codGrupodescripcionGrupo

: String: String

+++++

insertar ()actualizar ()eliminar ()buscarGrupoAlimento ()buscar (String codGrupo)


NutrienteAlimento

----

idcodInsumocodNutrientecantidad

: int: String: String: Double

++++

insertarNutriente (String codInsumo, String codNutriente)modificarNutriente ()eliminarNutriente ()buscarNutrienteAlimento ()

: void: void: void: void

Nutriente

----

codNutrientedescripcioncodUmcodTipoNutriente

: String: String: String: String

+++++

insertar ()actualizar ()eliminar ()buscarNutrientes ()buscarNutriente (String codTipoNutriente)


TipoNutriente

--

codTipoNutrientedescripcionTipoNutriente

: String: String

+++++

insertar ()actualizar ()eliminar ()buscarTipoNutriente ()buscar (String codTipo)

: int: int: int: int: int

InsumoRequeridoMenu

----

idcodInsumocodMenucantidadAjustada


++++

buscarInsumoRequeridoMenu ()insertar ()actualizar ()eliminar ()


InsumoRequeridoPlanificacion

----

idcodInsumocodPlanificacioncantidad


++++

insertar ()actualizar ()eliminar ()buscarInsumoRequeridoPlanificacion ()


PedidoInsumo

----



+++

insertar ()actualizar ()buscar ()

: void: void: void

ExistenciaArticulo

------

codExistenciacodInsumocodUbicacionexistenciaMaximaexistenciaActualprecioUnitario

: String: String: String: Double: Double: Double

++++++++++++

buscarExistenciaArticulos ()cargarUbicacion ()cargarFormulario ()validar ()agregar ()buscarArticulo ()actualizar ()eliminar ()generarReporte ()comprobarExistencia ()calcularExistenciaActual ()ajustarExistencia ()

: void: void: void: void: void: void: void: void: void: void: void: void

Planificacion

-------

codPlanificacionfechaestimadoComensalescodMenucodTipoMenucodigoSemanaespecial

: String: String: String: String: String: String: String

+++++++++++++++++++++

cargarSemana ()buscarPlanificaciones ()cargarTipoMenu ()creaFechasSemana ()cargarComensales ()estimarComensales ()cargarEstimadoComensales ()validar ()insertar ()eliminar ()cargarInsumoRequeridoPlanificacion ()cargarMenu ()cargarInsumoRequeridoMenu ()cargarExistenciaArticulo ()comprobarExistenciaInsumosRequeridos ()actualizar ()eliminarPlanificacion (String codPlanificacion)generarReporte ()calcularCantidadTotalInsumoRequerido ()generarHojaPedido ()buscarPlanificacion ()

: void: void: void: void: void: void: void: void: void: void: void: void: void: void: void: void: void: void: void: void: void

Semana

----

codigoSemananumeroSemanadescripcioncontrol


+++++

crearSemana ()actualizarSemana ()eliminarSemana ()buscarSemanas ()buscarSemana (String codSemana)


AccesoComensal

---

numeroAccesocedulacodPlanificacion


++++++++

cargarTipoMenu ()generarFecha ()cargarMenuAlimentario ()cargarDatosEstudiante ()comprobar ()registrarComensal ()buscarComensales ()generarReporte ()

: void: void: void: void: void: void: void: void

Estudiante

---

cedulanombresapellidos


+ buscarEstudiante () : void

SolicitudServicio

------

numSolicitudfechaSolicitudcodStatusidSolicitantedescripcionEventoobservacion

: String: String: String: String: String: String

+++++++++++++

generarFecha ()generarNumSolicitud ()cargarUsuario ()cargarTipoMenu ()cargarFormulario ()validar ()enviarSolicitud ()cargarStatusSolicitud ()buscarSolicitudes ()buscarSolicitud (String numSolicitud)cargarDetalleSolicitud ()actualizarStatus ()generarReporte ()

: void: void: void: void: void: void: void: void: void: void: void: void: void

DetalleSolicitud

-----

codDetallenumSolicitudfechaEventocodTipoMenunumComensales

: String: String: String: String: int

++

agregarDetalle ()buscarDetalleSolicitud ()

: void: void

Usuario

--------

idclaveusuariocodUsuarionombresapellidoscargoemail

: int: String: String: String: String: String: String: String

++++++++++

validarUsuario (String usuario, String clave)cargarOpciones ()buscarUsuarios ()cargarTipoUsuario ()cargarFormulario ()validar ()insertar ()buscarUsuario (String codUsuario)actualizar ()eliminar ()

: void: void: void: void: void: void: void: void: void: void

TipoUsuario

---

codUsuariodescripcionpagina


++

buscarOpciones ()buscarTipoUsuario ()

: void: void

StatusSolicitud

--

codStatusdescripcion

: String: String

+ buscarStatusSolicitud () : void

Ubicacion

--

codUbicaciondescripcion

: String: String

+++++

insertar ()actualizar ()eliminar ()buscarUbicacion ()buscar (String codUbicacion)

: int: int: int: int: int

SalidaArticulosAlmacen

----

numSalidafechaSalidaresponsablecodPlanificacion


+++++++++++++++

generarFecha ()generarNumSalida ()cargarTipoMenu ()cargarFormulario ()cargarPlanificacion ()cargarMenu ()cargarInsumoRequeridoMenu ()cargarInsumoRequeridoPlanificacion ()cargarExistenciaArticulo ()verificarDisponibilidadInsumoAlmacen ()verificarCantdadSaliente ()crearRegistroSalida ()modificarRegistroSalida ()generarReporteRegistroSalida ()buscarRegistroSalida ()


DetalleEntradaArticulo

-----

codDetallenumEntradacodExistenciacantidadEntranteprecioEntrada

: String: String: String: Double: Double

++++

buscarDetalle ()agregar ()actualizar ()calcularPrecioTotal ()


DetalleSalidaArticulo

-----

codDetallenumSalidacodExistenciacantidadSalienteprecioSalida

: String: String: String: Double: Double

++++

agregar ()calcularPrecioTotal ()modificar ()buscarDetalle ()


AjusteExistencia

------

numAjustenumSalidacodExistenciacantidadAjustadacodTipoAjusteobservacion

: String: String: String: Double: String: String

+++++

cargarExistenciaArticulo ()cargarTipoAjuste ()crearAjuste ()buscar ()modificar ()


EntradaArticulosAlmacen

--------

numEntradacodStatusnumOrdennumNotaEntregafechaNotaEntreganumFacturafechaFacturatotalFactura

: String: String: String: String: String: String: String: Double

++++++++++

cargarOrdenesCompra ()buscarRegistrosEntrada ()crearRegistroEntrada ()cargarStatusEntrada ()buscarRegistroEntrada (String numEntrada)cargarDetalleEntradaArticulo ()cargarFormulario ()validar ()actualizarRegistroEntrada ()generarReporteRegistroEntrada ()

: void: void: void: void: void: void: void: void: void: void

StatusEntrada

--

codStatusEntradadescripcion

: String: String

+ buscarStatusEntrada () : void

OrdenCompra

----

numOrdenfechaOrdenmontoTotalcodProveedor

: String: String: Double: String

++

buscarOrdenesCompra ()buscarOrdenCompra (String numOrden)

: void: void

Proveedor

--

codProveedornombre

: String: String

++

buscarProveedores ()buscarProveedor (String codProveedor)

: void: void

TipoAjuste

--

codTipoAjustedescripcion

: String: String

+ buscarTipoAjuste () : void

ReporteCostos

----

fechamesaniocodTipo


++++++++++++++++++

cargarPlanificacion ()cargarMenu ()cargarSalidaArticulos ()calcularCostoServicio ()cargarNumComensales ()calcularCostoUnitarioServicio ()calcularTotalComensalesMes ()cargarProveedores ()cargarRegistrosEntrada ()calcularCostoTotalEntrada ()calcularCostoTotalSalida (String mes, String anio)calcularCostoTotalMes ()cacularCostoTotalAcumuladoHastaMesAnterior ()calcularCostoTotalAcumuladoALaFecha ()calcularTotalComensalesHastaMesAnterior ()calcularTotalComensalesALaFecha ()calcularCostoUnitarioServicioMes ()calcularCostoUnitarioServicioALaFecha ()

: void: void: void: void: void: void: void: void: void: void: void: void: void: void: void: void: void: void

TipoReporte

--

codTipodescripcion

: String: String

+ buscar () : void

376

Association_8

Pertenece

Agrupa

Association_9

Tiene

Corresponde

Association_10

Pertenece

Agrupa

Association_7

Pertenece

Agrupa

Association_11

EsComposicionDe

EstaCompuestoDe

Association_12

EsRepresentadoPor Representa

Association_13

Pertenece

Agrupa

Association_14

Tiene

Corresponde

Association_15

Utiliza

EsUtilizadoEn

Association_16

EsRepresentadoPor

Representa

Association_17

Compone

Consta

Association_19


Association_20

Contiene

Existe

Association_21

Contiene

Conforma(D)

Association_22PoseeEsTurnoDe

Association_23

Compone

Consta

Association_24

EsGeneradoDe

Genera(D)

Association_26

Corresponde

Tiene

Association_27

EsUtilizadoEn

Utiliza

Association_28

Tiene

EsTurnoDe

Association_29

Contiene

Compone

Association_30

Tiene

EsEstadoDe

Association_31

EsElaboradoPor

ElaboraAssociation_32

Pertenece

Agrupa

Association_33

Correponde

Tiene

Association_34

EstaSituadoEn

Situa(D)

Association_35

ContieneEntradaDe

SeEncuentraEn(D)

Association_36

Contiene

Conforma

Association_37

Posee

EsEstadoDe

Association_38

Contiene

Pertenece(D)

Association_39

ContieneDatosDe

EstaContenidaEn(D)

Association_40

ContieneSalidaDe

SeEncuentraEn(D)

Association_41

Contiene

Conforma

Association_42

SeRealizanEn

Tiene(D)

Association_43

Cambia

EsAjustadaPor(D)

Association_44

Pertenece

Agrupa

Association_46

Pertenece

Agrupa

Association_47

Corresponde

Genera

Association_48

EsRepresentadoPor

Representa

Association_45

Pertenece

Agrupa

Association_6

EsPropiedadDe

TienePropiedadDe

Association_49

Corresponde

Solicita(D)

Insumo


Variable characters (254)Variable characters (254)Variable characters (254)Variable characters (254)Variable characters (254)

Um

codUmdescripcionUm

Variable characters (254)Variable characters (254)

TipoInsumo



TipoMenuInsumo



TipoMenu



Menu


Variable characters (254)Variable characters (254)Variable characters (254)

Alimento


Variable characters (254)NumberVariable characters (254)

GrupoAlimento



NutrienteAlimento


IntegerVariable characters (254)Variable characters (254)Number

Nutriente


Variable characters (254)Variable characters (254)Variable characters (254)Variable characters (254)

TipoNutriente



InsumoRequeridoMenu






PedidoInsumo



ExistenciaArticulo


Variable characters (254)Variable characters (254)Variable characters (254)NumberNumberNumber

Planificacion


Variable characters (254)Variable characters (254)Variable characters (254)Variable characters (254)Variable characters (254)Variable characters (254)Variable characters (254)

Semana


Variable characters (254)Variable characters (254)Variable characters (254)Variable characters (254) AccesoComensal



Estudiante



SolicitudServicio


Variable characters (254)Variable characters (254)Variable characters (254)Variable characters (254)Variable characters (254)Variable characters (254)

DetalleSolicitud


Variable characters (254)Variable characters (254)Variable characters (254)Variable characters (254)Integer

Usuario


IntegerVariable characters (254)Variable characters (254)Variable characters (254)Variable characters (254)Variable characters (254)Variable characters (254)Variable characters (254)

TipoUsuario



StatusSolicitud



Ubicacion








Variable characters (254)Variable characters (254)Variable characters (254)NumberNumber



Variable characters (254)Variable characters (254)Variable characters (254)NumberNumber

AjusteExistencia


Variable characters (254)Variable characters (254)Variable characters (254)NumberVariable characters (254)Variable characters (254)



Variable characters (254)Variable characters (254)Variable characters (254)Variable characters (254)Variable characters (254)Variable characters (254)Variable characters (254)Number

StatusEntrada



OrdenCompra


Variable characters (254)Variable characters (254)NumberVariable characters (254)

Proveedor

codProveedornombre


TipoAjuste



ReporteCostos

fechamesaniocodTipo


TipoReporte

codTipodescripcion


377

FK_INSUMO_ASSOCIATI_TIPOINSU

Pertenece

Agrupa

FK_INSUMO_ASSOCIATI_UM

Tiene

Corresponde

FK_MENU_ASSOCIATI_TIPOMENU

Pertenece

Agrupa

FK_ALIMENTO_ASSOCIATI_GRUPOALI

Pertenece

Agrupa

FK_NUTRIENT_ASSOCIATI_ALIMENTO

EsComposicionDe

EstaCompuestoDe

FK_NUTRIENT_ASSOCIATI_NUTRIENT

EsRepresentadoPorRepresenta

FK_NUTRIENT_ASSOCIATI_TIPONUTR

Pertenece

Agrupa

FK_NUTRIENT_ASSOCIATI_UM

Tiene

Corresponde

FK_TIPOMENU_ASSOCIATI_INSUMO

Utiliza

EsUtilizadoEn

FK_TIPOMENU_ASSOCIATI_TIPOMENU

EsRepresentadoPor

Representa

FK_INSUMORE_ASSOCIATI_MENU

Compone

Consta

FK_INSUMORE_ASSOCIATI_INSUMO


FK_INSUMO_ASSOCIATI_PEDIDOIN

Existe

Contiene

FK_PLANIFIC_ASSOCIATI_MENU

Contiene

Conforma

FK_PLANIFIC_ASSOCIATI_TIPOMENU

Posee

EsTurnoDe

FK_INSUMORE_ASSOCIATI_PLANIFIC

Compone

Consta

FK_PEDIDOIN_ASSOCIATI_PLANIFIC

EsGeneradoDe

Genera

FK_ACCESOCO_ASSOCIATI_ESTUDIAN

Corresponde

TieneFK_ACCESOCO_ASSOCIATI_PLANIFIC

EsUtilizadoEn

Utiliza

FK_DETALLES_ASSOCIATI_TIPOMENU

Tiene

EsTurnoDe

FK_DETALLES_ASSOCIATI_SOLICITU

Compone

Contiene

FK_SOLICITU_ASSOCIATI_STATUSSO

Tiene

EsEstadoDe

FK_SOLICITU_ASSOCIATI_USUARIO

EsElaboradoPor

ElaboraFK_USUARIO_ASSOCIATI_TIPOUSUA

Pertenece

Agrupa

FK_EXISTENC_ASSOCIATI_INSUMO

Correponde

Tiene

FK_EXISTENC_ASSOCIATI_UBICACIO

EstaSituadoEn

Situa

FK_DETALLEE_ASSOCIATI_EXISTENC

ContieneEntradaDe

SeEncuentraEn

FK_DETALLEE_ASSOCIATI_ENTRADAA

Conforma

Contiene

FK_ENTRADAA_ASSOCIATI_STATUSEN

Posee

EsEstadoDe

FK_ORDENCOM_ASSOCIATI_PROVEEDO

Contiene

Pertenece

FK_ENTRADAA_ASSOCIATI_ORDENCOM

ContieneDatosDe

EstaContenidaEn

FK_DETALLES_ASSOCIATI_EXISTENC

ContieneSalidaDe

SeEncuentraEn

FK_DETALLES_ASSOCIATI_SALIDAAR

Conforma

Contiene

FK_AJUSTEEX_ASSOCIATI_SALIDAAR

SeRealizanEn

Tiene

FK_AJUSTEEX_ASSOCIATI_EXISTENC

Cambia

EsAjustadaPor

FK_AJUSTEEX_ASSOCIATI_TIPOAJUS

Pertenece

Agrupa

FK_REPORTEC_ASSOCIATI_TIPOREPO

Pertenece

Agrupa

FK_INSUMORE_ASSOCIATI_INSUMO

EsRepresentadoPor

Representa

FK_PLANIFIC_ASSOCIATI_SEMANA

Pertenece

Agrupa

FK_INSUMO_ASSOCIATI_ALIMENTO

TienePropiedadDe

EsPropiedadDe

FK_SALIDAAR_ASSOCIATI_PLANIFIC

Corresponde

Solicita

FK_REPORTEC_ASSOCIATI_PLANIFIC

Corresponde

Genera

Insumo


varchar(254)varchar(254)varchar(254)varchar(254)varchar(254)

Um

codUmdescripcionUm

varchar(254)varchar(254)

TipoInsumo



TipoMenuInsumo



TipoMenu



Menu


varchar(254)varchar(254)varchar(254)

Alimento


varchar(254)numericvarchar(254)

GrupoAlimento



NutrienteAlimento


integervarchar(254)varchar(254)numeric

Nutriente


varchar(254)varchar(254)varchar(254)varchar(254)

TipoNutriente



InsumoRequeridoMenu






PedidoInsumo



ExistenciaArticulo


varchar(254)varchar(254)varchar(254)numericnumericnumeric

Planificacion


varchar(254)varchar(254)varchar(254)varchar(254)varchar(254)varchar(254)varchar(254)

Semana


varchar(254)varchar(254)varchar(254)varchar(254) AccesoComensal



Estudiante



SolicitudServicio


varchar(254)varchar(254)varchar(254)varchar(254)varchar(254)varchar(254)

DetalleSolicitud


varchar(254)varchar(254)varchar(254)varchar(254)integer

Usuario


integervarchar(254)varchar(254)varchar(254)varchar(254)varchar(254)varchar(254)varchar(254)

TipoUsuario



StatusSolicitud



Ubicacion








varchar(254)varchar(254)varchar(254)numericnumeric



varchar(254)varchar(254)varchar(254)numericnumeric

AjusteExistencia


varchar(254)varchar(254)varchar(254)numericvarchar(254)varchar(254)



varchar(254)varchar(254)varchar(254)varchar(254)varchar(254)varchar(254)varchar(254)numeric

StatusEntrada



OrdenCompra


varchar(254)varchar(254)numericvarchar(254)

Proveedor

codProveedornombre


TipoAjuste



ReporteCostos

fechamesaniocodTipo


TipoReporte

codTipodescripcion


378

Documents

TesisLuisfarias