matemÁticas ciencias

UNIVERSIDAD NACIONAL DE TRUJILLO

FACULTAD DE CIENCIAS FÍSICAS Y MATEMATICAS

ESCUELA PROFESIONAL DE INFORMATICA

Aplicación Web para reducir el tiempo y aumentar la precisión en la

generación de requisiciones en el servicio de alimentación colectiva de

la Empresa Alinorte - Chile

TRABAJO DE SUFICIENCIA PROFESIONAL

PARA OPTAR EL TITULO DE INGENIERO INFORMATICO

Autor:

Rojas Castillo Edward Hilton

Asesor:

Dr. Gutiérrez Gutiérrez Jorge Luis

TRUJILLO - PERU

2021

Biblioteca Digital - Dirección de Sistemas de Informática y Comunicación - UNT

Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No Comercial-Compartir bajola misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licences/by-nc-sa/2.5/pe/

BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

II



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

III

Dedicatoria

Dedico este informe de suficiencia profesional a A mis padres por haberme forjado como persona que ahora soy, por sus consejos de vida y mostrarme el camino de la superación de nunca declinar antes las adversidades. A mi amada esposa y compañera de vida Rocío por haberme motivado constantemente en la realización de mis metas y por estar siempre ahí en las buenas y malas. A mis adorados hijos, que sería de mi sin ellos, quizás no entiendan en estos momentos mis palabras por todo lo que significan para mí, por ser mi razón de seguir adelante, mis hijos Stefano y Fabio.



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

IV

Agradecimientos

Agradezco a Dios por haberme bendecido con salud para mi y todos mis familiares A mis profesores del Departamento de Informática, de los cuales recibí una gran cantidad de conocimientos. A mis amigos que siempre me apoyaron superar las dificultades.



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

V

Resumen

El presente informe aborda uno de los principales problemas sobre Planificación de Menú

en la Empresa Alinorte S.A.C. en Chile, dentro del rubro de Alimentación Colectiva, considerando

las funciones operativas realizadas en dicha empresa, así como en las anteriores empresas del

mismo rubro de negocio.

Bajo las condiciones y recursos proporcionados por la empresa, se estableció como

objetivo principal desarrollar una aplicación web para la gestión de menús como herramienta que

permitiría reducir el tiempo y aumentar la precisión en la generación de requisiciones (listado de

ingredientes a entregar) en beneficio de la Empresa Alinorte S.A.C.

Los resultados obtenidos durante el uso de la aplicación web, se compararon con aquellos

obtenidos sin el uso de la aplicación y haciendo uso de técnicas de estadística descriptiva y

técnicas de Inferencia de prueba de hipótesis para comparación de dos medias en muestras

independientes se hizo uso del Software Estadístico SPPS, (Tabla 3.1, Tabla 3.3, Tabla 3.4 y Tabla

3.5) , se confirmó el objetivo trazado: la reducción del tiempo empleado, y el aumento en la

precisión de su información para la toma de decisiones.

Palabras Clave: Alimentación Colectiva, Menú, Recetas, Requisiciones, Aplicación Web.



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

VI

Abstract

This report deals with one of the main problems about Menu Planning in the Alinorte

S.A.C. in Chile, within the Collective Food category, considering the operational functions

performed in that company, as well as in the previous companies in the same business area.

Under the conditions and resources provided by the company, the main objective was to

develop a web application for menu management as a tool that will reduce time and increase

precision in the generation of requisitions (list of ingredients to be delivered), to benefit the

Alinorte company.

The results obtained during the use of the web application were compared with those

obtained without the use of an application, which confirmed the drawn up objective: the

reduction of the time taken, and the increase in the precision of its information for decision

making. In addition, it also provided a widely accessible and user-friendly application for

operational and administrative staff.

Palabras Clave: Menu Planning, Menu, Recipe, Requisitions, Web Application.



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

VII

Índice de Figuras

2.1 Organigrama de la Empresa Alinorte……………………………………………………………….. 2

3.1 Diagrama de Procesos Generales…………………………………………………………………….. 5

3.2 Diagrama de Proceso de Planificación de Minutas…………………………………………… 6

3.3 Ciclos del Marco de Trabajo SCRUM………………………………………………………………… 24

3.4 Diagrama de Arquitectura Web……………………………………………………………………….. 28

3.5 Diagrama de Despliegue………………………………………………………………………………….. 29

3.6 Diagrama General de Casos de Uso…………………………………………………………………. 30

3.7 Diagrama de Caso de Uso de Gestión de Datos…………………………………………….…. 30

3.8 Diagrama de Caso de Uso de Gestión de Menús…………………………………….….….. 31

3.9 Diagrama de Caso de Uso de Obtener Reportes Consolidados………………………. 32

3.10 Diagrama de Proceso General…………………………………………………………….………... 32

3.11

3.12

Diagrama de Proceso de Acceso Restringido…………………..…………………………….

Diagrama de Proceso de Gestión de Datos……………………………………………………

33

33

3.13 Modelo Relacional………………………….……………………………………………………………. 34

3.14 Interface Registro de Receta……………………………………………………………………………. 35

3.15 Interface Consultar, Modificar y Eliminar Receta…………………………………………….. 35

3.16 Interface Ingreso de Minutas………………………………………………………………………….. 36

3.17 Interface Consultar, Modificar y Eliminar Minutas………………………………………….. 36

3.18 Interface Generar Reportes de Requisiciones y Listado de Compras……………….. 37

3.19 Interface Inicio de Sesión para Acceso Restringido………………………………………….. 38

3.20 Interface Ingreso de Alimentos……………………………………………………………………….. 39

3.21 Interface Consulta de Alimentos……………………………………………………………………… 39

3.22 Interface Ingreso Factores de Alimentos…………………………………………………………. 40

3.23 Interface Ingreso de Tipo de Plato…………………………………………………………………… 40

3.24 Interface Consultas de Tipo de Plato……………………………………………………………….. 41

3.25 Reporte en Excel de Requisición generado a mano…………………………………………. 44

3.26 Reporte de Requisiciones generado con el Aplicativo Web…………………………….. 45

3.27 Listado de Tablas de Base de Datos MySQL en el servidor Linux……..……………… 46

3.28 Listado de Archivos y directorios del código fuente en el Servidor Linux 47

3.29 Pantalla del Menú de la Aplicación Web a través de la URL ……………. 48



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

VIII

Índice de Cuadros

3.1 Costos de Equipos Computacionales……………………………………………………………….. 13

3.2 Características de cada Equipo de Cómputo……………………………………………………. 14

3.3 Costos de Software………………………………………………………………………………………….. 14

3.4 Costos de Personal de acuerdo a Roles……………………………………………………………. 15

3.5 Equipos Computacionales solo en Unidades……………………………………………………. 16

3.6 Software solo en Unidades………………………………………………………………………………. 16

3.7 Roles y Horas requeridas…………………………………………………………………………………. 17

3.8 Equipos Computacionales y Costos………………………………………………………………….. 17

3.9 Software y Costos……………………………………………………………………………………………. 18

3.10 Roles y Costos de las Horas requeridas……………………………………………………………. 19

3.11 Cronograma de Tareas según Estimación Inicial………………………………………………. 22

3.12 Product Backlog………………………………………………………………………………………………. 31



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

IX

Índice de Tablas

3.1 Tiempo Empleado en Horas en cada Semana…………………………………………………… 43

3.2 Costo en Dólares Americanos de Tiempo Empleado en Horas…………………………. 45

3.3

3.4

3.5

Margen de Error de acuerdo a valores incorrectos…………………………………………..

Resumen de medidas Estadísticas descriptivas a través del SPSS del

tiempo, Costo y Error según el tipo de planificación de menú en cada

semana…………………………………………………………………………………………………..

Prueba de Muestras Independientes……………………………………………………..

46

65

67



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

X

Índice General Dedicatoria ...................................................................................................................................................... III

Agradecimientos............................................................................................................................................. IV

Resumen .......................................................................................................................................................... V

Abstract .......................................................................................................................................................... VI

Índice de Cuadros ......................................................................................................................................... VIII

Índice de Tablas .............................................................................................................................................. IX

Índice General ................................................................................................................................................. X

1. Capítulo I............................................................................................................................................... 1

1.1. Nombre o Razón Social de la Empresa ......................................................................................... 1

1.2. Cargo Desempeñado .................................................................................................................... 1

1.3. Descripción del Cargo Desempeñado .......................................................................................... 1

1.4. Lugar (ciudad) y fecha (de inicio y fin del vínculo laboral) ........................................................... 1

2. Capitulo II.............................................................................................................................................. 2

2.1. Servicios Integrales Alinorte S.A. .................................................................................................. 2

2.1.1. Descripción ................................................................................................................................... 2

2.1.2. Área de Planificación y Programación .......................................................................................... 3

2.1.3. Cargo............................................................................................................................................. 4

2.1.4. Jefe Inmediato Superior ............................................................................................................... 5

3. Capitulo III............................................................................................................................................. 6

3.1. Fundamentación ........................................................................................................................... 6

3.1.1. Realidad Problemática .................................................................................................................. 8

3.1.2. Formulación del Problema .........................................................................................................10

3.1.3. Justificación ................................................................................................................................10

3.1.4. Limitaciones ................................................................................................................................10

3.1.5. Objetivos: Generales y Específicos .............................................................................................11

3.1.6. Planteamiento de la Solución .....................................................................................................12

3.1.7. Análisis de la Viabilidad ..............................................................................................................13

3.1.8. Recursos (Humanos, Hardware, Software, Materiales, Servicios, etc.) .....................................19

3.1.9. Presupuesto ................................................................................................................................20

3.1.10. Cronograma ................................................................................................................................22

3.2. Desarrollo ...................................................................................................................................25

3.2.1. Marco de Trabajo Ágil: SCRUM ..................................................................................................25

3.2.2. Tareas Realizadas .......................................................................................................................27



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

XI

3.3. Resultados Obtenidos ................................................................................................................47

3.3.1. Resultados Teóricos y/o Académicos .........................................................................................47

3.3.2. Resultados computacionales y/o aplicativo y/o valorativo y/o estadísticos .............................48

3.4. Consideraciones Finales .............................................................................................................63

3.4.1. Conclusiones ...............................................................................................................................63

3.4.2. Recomendaciones ......................................................................................................................64

3.4.3. Evaluación crítica [de tu formación universitaria respecto a la labor que se describe] ............64

REFERENCIAS ..........................................................................................................................................66

ANEXOS...................................................................................................................................................67



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

1

1. Capítulo I

1.1. Nombre o Razón Social de la Empresa

Servicios Integrales Alinorte S.A. con RUT N°76.192.570-9 con domicilio en Calle Covadonga

#1029 – Iquique, Chile

1.2. Cargo Desempeñado

Jefatura de Planificación y Control de Programación

1.3. Descripción del Cargo Desempeñado

Estaba encargado de recepcionar las cantidades de comensales de cada centro de costo, para

a su vez calcular la proyección de compra de insumos proyectados mes a mes. También generar

con la planificación realizada un listado de requisiciones para el área de almacén para luego ser

entregada a las áreas operativas(cocina), así como la generación de otros reportes para las

distintas áreas operativas.

De manera adicional por mi formación en Ingeniería Informática, se me asignaron tareas

enfocadas en el análisis de la automatización de algunos procesos de negocio en los que me

encontraba involucrado.

1.4. Lugar (ciudad) y fecha (de inicio y fin del vínculo laboral)

Se inicia en la Ciudad de Iquique, la fecha de inicio es el 29.05.2007 y el fin del vínculo laboral

con Sede en chile es 01.04.2016



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

2

2. Capitulo II

2.1. Servicios Integrales Alinorte S.A.

2.1.1. Descripción

La Empresa Servicios Integrales Alinorte S.A., es una compañía Regional chilena dedicada a la

prestación de servicios de alimentación colectiva/institucional hacia el personal de empresas con

sedes administrativas, industriales, extractivas, mineras con actividades remotas, instituciones de

sector educación y salud.

Sus operaciones se remontan a inicios de febrero de 2004 (hace 15 años aproximadamente),

cuando el dueño crea en Iquique, una empresa pionera en el rubro de la alimentación colectiva.

Luego se suma u n socio, y juntos impulsaron el desarrollo de esta compañía cuyo objetivo

es atender las necesidades de las empresas con el compromiso de un servicio del más alto nivel.

El 2008 La Empresa se consolida una de sus mayores líneas de negocio, la Alimentación Colectiva

donde brindaron un servicio personalizado, sofisticado, de excelente calidad y presentación.

Desde el año 2009 y hasta el día de hoy, La Empresa renueva su compromiso con la innovación

y el proceso tecnológico y certifica además la calidad de sus procesos a través de la norma ISO

9001 y HACCP.

El año 2013, la Empresa empieza sus operaciones en Perú brindando servicio integral

(alimentación, hotelería y lavandería) en la cuidad de Huancavelica al Consorcio Rio Mantaro en

la construcción de la Central Hidroeléctrica Cerro del Águila.

Hoy, en base a su participación de mercado, es la segunda empresa de este rubro en Iquique.

Entrega más de 6 millones de raciones al año, cuenta con 400 colaboradores y más de 15 clientes

ubicados principalmente en la región de Tarapacá, Arica, Lima y Toquepala.

▪ Razón Social es Servicios Integrales Alinorte S.A

▪ RUT: El Rut es el 76.192.570-9

▪ Dirección: Calle Covadonga N° 1029, Iquique, Chile

▪ Rubro: Alimentación Colectiva y Catering



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

3

▪ Organigrama

Figura 2.1: Organigrama de la Empresa Alinorte

Fuente: Manual de Operación y Funciones de la Empresa

2.1.2. Área de Planificación y Programación

▪ Breve Descripción

Consolidar las peticiones de las cantidades de comensales que nos brindan los Clientes y con ello

realizar las proyecciones necesarias para poder generar la planificación y compras que se

requieran para cada contrato. También sirve para poder evaluar y sincerar el comportamiento de

los costos de los contratos para la toma de decisiones a nivel gerencial.

▪ Funciones

Recepcionar y coordinar con los clientes las cantidades de comensales muy importante para la

planificación de menús.

Generación de Reportes de Requisiciones para las Áreas Operativas (Cocina Caliente, Cocina Fría

y Repostería y Almacén) para la entrega de los insumos según lo planificado.



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

4

Generación de Reporte s de Food Cost que sirve para poder saber el costo operacional de cada

contrato.

2.1.3. Cargo

▪ Breve Descripción

Estaba encargado de recepcionar las cantidades de comensales de cada centro de costo, para a su

vez calcular la proyección de compra de insumos proyectados mes a mes. También generar con la

planificación realizada un listado de requisiciones para el área de almacén para luego ser

entregada a las áreas operativas(cocina), así como la generación de otros reportes para las

distintas áreas operativas.

De manera adicional por mi formación en Ingeniería Informática, se me asignaron tareas

enfocadas en el análisis de la automatización de algunos procesos de negocio en los que me

encontraba involucrado.

▪ Actividades Desarrolladas

o Coordinaciones directas con las áreas de:

o Producción de Nutrición y Cocina, que determinaban la estructura de valor de un

menú y su preparación.

o Almacén, para poder cuales eran las necesidades para la generación de reportes

de requisiciones.

o Compras, para poder sintetizar todos sus requerimientos con el uso de la

Aplicación Web.

o Propuesta de una solución a través de la implementación de una Aplicación Web que

automatice la Planificación de Menús, Generación de Requisiciones.

o Organización del Proyecto Informático, Recolección y Análisis de Información, Diseño y

Modelado e Implementación.



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

5

▪ Logros

o Procesos de planificación mejorados, acortando interacciones entre las áreas para

identificar actividades sustanciales.

o Concientización del personal sobre la necesidad del uso del aplicativo web que agilizara el

trabajo y asegurara el manejo de la información.

o Desarrollo de una aplicación web de apoyo para las labores operativas de las áreas y toma

de decisiones en Gerencia General.

o Generación de manera oportuna de la Planificación / Proyección de Menús para cubrir la

demanda periódica de los clientes.

▪ Resultados

o Disminución de interacciones entre el personal, quedando identificadas las esenciales y

eliminando aquellas que no lo son.

o Empleados de las áreas involucradas concientizados en el uso de la aplicación web

o Aplicación web disponible para los responsables de los procesos de planificación, que

permite gestionar la información de los menús.

o Reportes Depurados que aportasen verdadero valor para las áreas, generados en menor

tiempo y con mayor precisión.

2.1.4. Jefe Inmediato Superior

▪ Nombres y Apellidos

Andro Antonio Versalovic Clotec

▪ Cargo

Gerente General

▪ Correo

[email protected]



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

6

▪ Teléfono

+56 994899524

3. Capitulo III

3.1. Fundamentación

El presente estudio se enmarcó dentro del ámbito de Alimentación Colectiva, el cual es un servicio

orientado a elaborar alimentos para una cantidad de comensales superior a los que comprenden un

grupo familiar.

Como punto de partida es importante conocer aquellos conceptos que se interrelacionan entre sí

dentro de este ámbito:

Receta: Se compone de los ingredientes (materias primas) y cantidad de gramaje por porción.

Plato: Se compone de 2 o más recetas

Minuta: También conocido como Menú. Es un conjunto de platos programados que se brindaron a un

cliente, teniendo en detalle la variedad disponible y asignada durante un periodo de tiempo. Por lo

general, se parte de un periodo diario y se compone de entre 3 a 5 platos (para desayuno, almuerzo y

cena), que se presentan como alternativas de elección para el comensal. Sin embargo, también se

consideran de manera Semanal (minuta diaria para cada día de la semana) y Mensual (minuta semanal

para cada semana del mes).

Requisición: Es el listado de recetas que corresponden a un servicio (Desayuno, almuerzo, cena),

exigida por el área de Almacén para entregar la materia prima con destino a las distintas áreas

operativas.

Flujo General de Información

Desde el momento en que se establecen los requerimientos de un cliente, se inicia el flujo de

información desde el Área de Planificación (Proceso de Planificación de Minutas), quien define las

minutas (diarias, semanales, mensuales) generando un documento de planificación que contiene el

detalle de éstas (tipos de platos, cantidades a preparar, periodo de tiempo), el cual una vez aprobado



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

7

es proporcionado al Área de Producción para tener en claro los platos que preparará y las cantidades

de ingredientes que debe considerar. Esta información es de vital importancia para el Área de

Compras, quien a partir de ella recién puede determinar qué y cuánto se comprará, así como los costos

parciales y totales que deberá asumir. También es un documento que permitirá al Área de Almacén

validar sus existencias de insumos según lo adquirido y lo utilizado.

Figura 3.1: Diagrama de Procesos Generales

Fuente: Elaboración Propia

Proceso de Planificación de Minutas

Este proceso es realizado por el Área de Planificación, la cual está integrada por nutricionistas y

personal administrativo. El proceso de elección de platos y construcción de minutas, se realiza por

decisiones de los planificadores, teniendo en consideración el costo de los platos y condiciones

comerciales acordadas con el cliente.

Inicialmente se trabaja con recetas existentes o nuevas a partir de una lista tipificada de alimentos que

contienen gramajes crudos y cocidos, las cuales se combinan de acuerdo a los valores nutricionales

acordados con el cliente, para dar como resultado una variedad de platos. Luego, se genera una

“Minuta Base”, la cual sirve como su nombre lo indica, para tener una base que se utilizará



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

8

posteriormente para la personalización de minutas del resto de los comedores. Esta minuta Base, se

utiliza para individualizarla según los acuerdos comerciales de cada comedor, de esta manera, no se

parte planificando desde cero todos los comedores. Posteriormente, los planificadores se demoran

entre 4 y 5 días en “Personalizar” la minuta base para cada uno de los comedores de la empresa.

Figura 3.2: Diagrama de Proceso de Planificación de Minutas


3.1.1. Realidad Problemática

Se llegó a identificar de manera precisa la problemática puntual a resolver: la falta de reportes

consolidados sobre requisiciones y/o listas de ingredientes a comprar, con cantidades y costos

calculados, de manera precisa y en el menor tiempo posible. Dado que se trataban de procesos

principales en la empresa, debido a que podían determinar el éxito o fracaso del negocio.

Sin embargo, para llegar a dicha problemática específica se fue desglosando cada problema

general encontrado, y se buscó la causa raíz del problema. Este proceso de búsqueda se describe

a continuación:



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

9

- Los procesos generales encontrados, presentaban la siguiente problemática:

o Se requería una especial atención y esfuerzo adicional en la coordinación para consensuar

y distribuir la información, ya que ésta se originaba desde una sola fuente a modo de

copias manuales hacía las demás áreas involucradas, no existiendo una base única y

común de consulta.

o El proceso de planificación de menús no proporcionaba la información (reportes)

necesaria para satisfacer y/o agilizar los demás procesos relacionados, muchas veces

siendo la causa principal para la demora o falta de precisión en los resultados esperados.

Por esta razón, se decide profundizar en este proceso para identificar problemas más

específicos.

- El proceso de planificación de menús, presentaba la siguiente problemática:

o La búsqueda de platos y creación de menús se realizaba en un medio [digital/físico] que

no facilitaba su edición ni aseguraba su permanencia y distribución, y en la mayoría de

casos también se corría el riesgo de no contar con datos fidedignos ya que, por la

naturaleza manual del proceso, la probabilidad del error era considerable, tomando en

cuenta que los datos iban en aumento en cada planificación.

o Los reportes consolidados que se generaban a partir de los menús planificados, referidos

a ingredientes totales involucrados para su preparación y compra, presentaban

limitaciones en cuanto a precisión en los cálculos, implicando también mucho tiempo

obtenerlos, dado que la validación como la actividad en sí, como en el proceso anterior,

también se realizaba manualmente.

- Al no contar con una lista de ingredientes necesarios para la producción de manera precisa y

oportuna, tampoco se podía tener los costos parciales y totales para realizar las compras que

abastecieran el servicio planificado. Y si bien, era posible de alguna manera tener los

consolidados, el tiempo que tomaba generarlos era muy extenso, afectando toda la cadena de

abastecimiento y producción. Esta problemática, adicionalmente evitaba realizar análisis de

rendimiento y costos, y en ocasiones al no tenerlo impedía medir y ajustar las cantidades como

parte de las mejoras del negocio.



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

10

3.1.2. Formulación del Problema

¿El uso de la aplicación web permitirá reducir el tiempo y aumentar la precisión en la generación de

requisiciones, de la Empresa Alinorte Chile en el Rubro de Alimentación Colectiva?

3.1.3. Justificación

Al aumentar la variedad de platos implicaba replicar y/o realizar más cálculos en relación a éstos,

directa y principalmente en la planificación de menús, si tomamos en cuenta que solo había una

persona encargada de realizar dicha labor con una frecuencia a corto plazo (semanal) para el

procesamiento de información. El aumento de nuevos contratos y menús a planificar aumentaría la

designación de recursos y tareas manuales, impactando directamente en las posibilidades de error y

tiempo empleado. Considerar una automatización de procesos en este punto, a través de una

aplicación web, posibilitaría una mejora sustancial en cuanto al tiempo y precisión en los cálculos.

De esta manera, la aplicación web beneficiaría a la empresa mejorando la atención de sus contratos

actuales y de recibir nuevos contratos, alineándose a los objetivos financieros respecto al aumento

de utilidades. Por otro lado, marcaría un hito dentro de ésta, al incorporar una mejora sustancial en

la manera de obtener, procesar y generar información dentro del Área de Planificación.

3.1.4. Limitaciones

- El contexto de información se circunscribe solo al ámbito del Área de Planificación, desde los

datos que se necesitan para la proyección de menús de acuerdo a instalación y rangos de tiempo,

enfocándose directamente en los reportes que detallen los insumos [ingredientes] necesarios

para la producción y compras (costos), asumiendo que los involucrados cuentan con el

conocimiento y los recursos para disponer de dicha información.

- En cuanto a los recursos económicos no existía un presupuesto considerado para este tipo de

proyectos, ya que el área contable no lo tenía contemplado dentro de sus proyecciones anuales.

- Los recursos humanos a considerar para el desarrollo eran parte del personal ya contratado para

labores operativas lo que no permitiría una dedicación exclusiva al proyecto.



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

11

- Los recursos de infraestructura, tales como las computadoras, escritorios y espacios de trabajo,

eran los que la empresa ya tenía como activos, de los cuales las computadoras no representaban

lo último en tecnología.

- El tiempo deseado para tener la aplicación web, al menos con la generación de los reportes de

requisiciones, no debía ser mayor a 4 meses.

3.1.5. Objetivos: Generales y Específicos

Objetivo General:

- Desarrollar la aplicación web para reducir el tiempo y aumentar la precisión en la generación de

requisiciones en el servicio de alimentación colectiva de la empresa Alinorte Chile.

Objetivos Específicos:

- Definir los recursos necesarios y disponibles que permitan elegir la alternativa de solución

apropiada de acuerdo a: las posibilidades manifestadas por la empresa y las consideraciones

técnicas para obtener resultados en periodos cortos de tiempo.

- Diseñar un modelo de datos coherente a la necesidad para establecer una base común y

compartida de información disponible en cualquier momento y desde cualquier lugar.

- Construir una aplicación web de manera incremental con la posibilidad de realizar revisiones

periódicas hasta obtener las funcionalidades esperadas. Contemplado las funcionalidades

mínimas que permitan incorporar los datos sobre insumos [ingredientes], platos y menús,

necesarios para generar una planificación adecuada de menús.

- Desplegar la aplicación web en un servidor remoto para lograr la disponibilidad que permita

mostrar avances a los involucrados sin depender del lugar.



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

12

3.1.6. Planteamiento de la Solución

- Al tener en claro el problema central se definió de manera general la solución, que consistía en

contar con una aplicación web conformada por las características más esenciales que permitiesen

obtener los reportes de información para requisiciones y compras.

- Se consideró la posibilidad de externalizar el desarrollo de la aplicación web con una consultora,

pero se presentaba lo siguiente:

o Existían algunos detalles que se planeaban ir refinando en el camino. Y el proveedor no

aseguraba reuniones periódicas que permitieran ir manejando los cambios inmediatos.

o No se aseguraban los entregables de prueba de manera periódica, es decir, contar con

incrementos a corto plazo que permitieran ir evaluando las funcionalidades.

o El plazo de entrega de un producto terminado no se adecuaba a la necesidad, y esto

repercutía también en los costos que se salían del presupuesto asignado.

- Se consideró la posibilidad de realizar de manera interna el desarrollo de la aplicación web

íntegramente con recursos propios, debido a que:

o Se contaba con el personal comprometido y conocedor de los procesos del negocio, con

las cualidades y condiciones para involucrarse en un proyecto interno.

o Se contaba con un profesional en sistemas que se desempeñaba como Asesor de TI, con

conocimiento y experiencia en desarrollo de software libre en entorno web.

o Existía disponibilidad de recursos ya adquiridos para implementación, tales como:

humanos y de infraestructura (computadoras y muebles).

- Al evaluar las alternativas de desarrollo, se decidió iniciar el proyecto tomando en cuenta las

siguientes consideraciones:

o El grupo de usuarios, a quienes estaba orientada el aplicativo Web, era pequeño y

limitado, pues consistía en: el personal que actualizaría la información y el personal que

obtendría los reportes solicitados.



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

13

o La forma de trabajo debía tener un seguimiento a corto plazo, de manera iterativa,

obteniendo un producto de manera incremental que permitiese ajustes en caso de que

fuese necesario y manteniendo en lo posible documentos o modelos de datos.

o El aplicativo Web a construir debía concebirse como una herramienta computacional,

para permitir un fácil acceso y disponibilidad, con la capacidad de replicar los cambios de

manera inmediata.

o Se debía minimizar en lo posible el uso de licencias, tanto para su construcción como para

su uso de manera permanente.

- La necesidad de obtener resultados en corto plazo con la optimización de los pocos recursos

presentes en la empresa, sin perder la magnitud del objetivo, requería ser ligeros tanto en la

gestión de proyectos como en el desarrollo de software, para proporcionar entregables

funcionales, pero sin perder los modelos formales de información. Es así que se decidió abordar

una forma de trabajo enfocada en la utilización de prácticas ágiles tomando como referencias

PMI-AGIL y AGILE-Scrum, bases desde la cual se afrontan las acciones para gestionar el proyecto

y desarrollar el software. Sin embargo, una guía ágil no ha significado una serie de pasos estrictos,

pero dichas prácticas sí han sido adaptadas/ajustadas a la realidad presente en el proyecto.

- Al enfocar la aplicación bajo una arquitectura web de cliente-servidor, ya se tenía en claro que el

tiempo de respuesta dependía principalmente de los siguientes factores: las características del

servidor (servicio de hosting rentado), la conexión a internet y del lenguaje de programación. Fue

fundamental la experiencia del desarrollador web, quien ya había encarado la implementación

de proyectos similares y que conocía los factores antes indicados, lo cual ayudo a decantarnos

por el uso de PHP como lenguaje de programación y MySQL como gestor de base de datos.

3.1.7. Análisis de la Viabilidad

Viabilidad Operativa

- Al determinar que existía personal con las capacidades para implementar internamente

(totalmente con recursos propios) el proyecto, se reestablecieron las funciones de estos para dar

cabida a las nuevas tareas que demandaría el proyecto, reorganizando aquellas propias de la

operatividad de tal manera que no se vean afectadas.



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

14

- En cuanto al impacto de los cambios en las áreas involucradas, se vislumbraba una clara mejora

en la usabilidad de la aplicación web versus sus métodos manuales de trabajo, esto debido que

la aplicación apuntaba a unificar la información y facilitar la obtención de reportes. La aplicación

web no generó algún tipo de rechazo a pesar de que sería una nueva forma de trabajo, tampoco

pretendía desplazar a ningún colaborador, por el contrario, pretendía optimizar su tiempo.

- Se consideraron breves cursos al usuario con el fin de asegurar que la aplicación web sea utilizada

para los fines en que fue construida y planeada, iniciando una capacitación de 3 días repartiendo

las horas de tal manera que no impactase en la rutina laboral de los colaboradores.

Por tanto, en el aspecto operativo se determinó que el proyecto operacionalmente era factible, ya

que se contaban con los recursos humanos para desarrollarlo y la buena voluntad del personal para

aprender a manejarlo. Además, la empresa tenía toda la disposición para integrar metodologías

nuevas, ya que era consciente que para el éxito de las tareas diarias del departamento se debía

marchar a la par con los avances y tecnologías que el mundo ofrece.

Viabilidad Legal

- Para el desarrollo del sistema se consideró el uso de software libre, por tanto, no se debía

considerar la adquisición de licencias de ningún tipo, por ese aspecto no había posibilidad de

incurrir en algún tipo de delito siempre que se respetasen las condiciones de uso que puede cada

uno de ellos.

- Como la mayoría de los equipos que se encontraban en la empresa tenían como sistema operativo

Microsoft Windows (7), fue el área legal quién nos confirmó que tenían las licencias de uso

originales correspondientes por ser software que ya se encontraba presente en las computadoras

proporcionadas por la empresa, en tanto no se incurriría en falta.

- Con respecto a la confidencialidad de información que se deseaba guardar en la base de datos,

se tomarán todas las medidas necesarias para no incurrir en ningún tipo de delito.

De acuerdo a lo anterior legalmente era viable, ya que la aplicación web como producto se enmarca

dentro de la normativa de Ley de propiedad Intelectual (Ley N° 17.336) de Chile, específicamente

para los trabajos realizados por personas dependientes dentro de una empresa. En cuanto al software

libre utilizado, las principales licencias son compatibles a licencias tipo GPL (GNU General Public



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

15

License), salvo PHP que a partir de su versión 4 solo presenta su licencia PHP estableciendo algunas

restricciones para uso, que de todas maneras se mantiene gratuito.

Viabilidad Técnica

- Desde la perspectiva de desarrollo, las dos personas involucradas en el proceso contaban con las

habilidades técnicas y experiencia, así también con los recursos necesarios, dado que las

características de sus equipos informáticos cubrían las necesidades para el modelado y

construcción de la aplicación web.

- Desde la perspectiva de despliegue para la arquitectura Cliente-Servidor, el Cliente (usuario final

del área de planificación de la empresa), no poseía ningún tipo de sistema informático a medida,

pero sí al menos una computadora dentro de sus oficinas con aplicativos de oficina (MS Office) y

conexión a internet. Con respecto al Servidor, la empresa no contaba con un servidor propio y

dedicado que permitiese proveer servicios web y base de datos, pero se consideró la alternativa

de obtener dichos servicios a través de un servidor remoto rentado, lo cual trajo consigo un

beneficio en asignación y delegación de recursos, costos y por ende también una importante

disminución de tiempo y riesgos.

Se concluyó a partir de los descrito anteriormente, que el sistema técnicamente era factible

construirlo, ya que los recursos técnicos para implementarlo eran accesibles y conocidos por los

involucrados.

Evaluación Económica

En el estudio no se pudo realizar una viabilidad económica por no contar con los elementos necesarios

para poder calcular valores como el VAN, el TIR o el ROI, ya que ello fue delegado al área contable y

fue ésta quien daba el visto bueno. Sin embargo, sí se logró hacer una evaluación económica que fue

imprescindible para conocer la totalidad de la inversión en que incurrirá la empresa al incorporar el

nuevo sistema, considerando la adquisición de hardware a pesar que en la práctica se reutilizarían

equipos (activos) ya existentes en la empresa. Referente al software no incurriría en gastos ya que el

único software con pago por licencia ya era parte de los gastos asumidos por la empresa dentro lo

proporcionado para labores operativas.



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

16

Costos de hardware

Para Desarrollo del Software:

Cuadro 3.1: Costos de Equipos Computacionales


Equipo Unidades Costo Unitario ($

USD)

Costo Total ($ USD)

Computadora Escritorio compatible 02 575.00 1,150.00

Modem/Router D-Link 01 96.00 96.00

TOTAL 1,246.00

Cuadro 3.2: Características de cada Equipo de Computo


CPU: Core2Duo, 2.8GHz, 1MB Cache, 800MHz

Memoria RAM: DIMM 4GB, DDR2, 667MHz (2x1), Dual Ranked

Disco Duro: Disco Duro de 500GB, SATA, RAID 0

Tarjeta de Red: Adaptador de Red integrado de un solo puerto Gigabit



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

17

Costos de Software

Cuadro 3.3: Costos de Software


Software Tipo Licencia Costo $ USD

Windows 7 Sistema Operativo Cliente Empresa cuenta con

licencia

0.00

Microsoft Office

2010

Ofimática Empresa cuenta con

licencia

0.00

Sublime Text IDE Desarrollo Versión Gratuita 0.00

MySQL

Workbench

Gestor Modelado y Base de

Datos

Versión Gratuita 0.00

XAMPP Servidor Web Local Versión Gratuita 0.00

Chrome/Firefox Navegador Web Versión Gratuita 0.00

PHP 5 Lenguaje de Programación Versión Gratuita 0.00

MySQL 5.3 Base de Datos Versión Gratuita 0.00

Bizagi Modeler Modelado de Procesos Versión Gratuita 0.00

StarUML Modelado y Desarrollo Versión Gratuita 0.00

TOTAL 0.00

Costos de Personal

- En el proyecto trabajaron 2 personas a medio tiempo (24 horas a la semana), y por la envergadura

del proyecto a implementar se estimó 624 horas (entre 6 y 7 meses).

- El personal involucrado cubrió los siguientes roles:

o Encargado Proyecto/Analista de Sistemas

o Analista de Sistemas/Programador de Aplicaciones Web



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

18

- Tenemos el costo total de la siguiente manera

Cuadro 3.4: Costos de Personal de acuerdo a Roles


Roles Tiempo Total Estimado

(horas)

Costo por hora

($ USD)

Costo Total Estimado

($ USD)

Encargado Proyecto / Analista

de Sistemas

262 7.51 1,967.62

Analista de Sistemas /

Programador de Aplicaciones

Web

518 5.25 2,719.50

TOTAL 4,687.12

COSTOS TOTALES:

Está dado por la suma de los costos de Hardware, Software y Personal:

• Costo Total = Costo Hardware + Costo Software + Costo Personal

Como se mencionó anteriormente, los costos de hardware y software se valorizaron en CERO por

ser activos ya existentes, y el costo del personal involucrado fue incluido dentro de los costos ya

asumidos en sus labores operativas, por disposición del área de administración y contabilidad. De

igual forma la empresa dispuso que esta área también sea quien tenga la responsabilidad de

validar la factibilidad, según el presupuesto disponible (con una partida designada para posibles

proyectos de pequeña magnitud) y según sus proyecciones financieras a mediano plazo. Siendo

así que dicha área comunicó que el proyecto piloto era económicamente viable ya que dentro de

su análisis se podía asumir el gasto total.



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

19

3.1.8. Recursos (Humanos, Hardware, Software, Materiales, Servicios, etc.)

Cuadro 3.5: Equipos Computacionales solo en Unidades


Equipo Unidades

Computadora Escritorio compatible 02

Modem/Router D-Link 01

Cuadro 3.6: Software solo en Unidades


Software Tipo Licencia Unidades


licencia

02

Microsoft Office

2010


licencia

02

Microsoft Project

2010

Proyectos Empresa cuenta con

licencia

01

Sublime Text IDE Desarrollo Versión Gratuita 01

MySQL

Workbench

Gestor Modelado y Base

de Datos

Versión Gratuita 01

XAMPP Servidor Web Local Versión Gratuita 01

Chrome/Firefox Navegador Web Versión Gratuita 02

PHP 5 Lenguaje de

Programación

Versión Gratuita 01



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

20

MySQL 5.3 Base de Datos Versión Gratuita 01

Bizagi Modeler Modelado de Procesos Versión Gratuita 02

StarUML Modelado y Desarrollo Versión Gratuita 01

Cuadro 3.7: Roles y Horas requeridas



(horas)

Encargado Proyecto / Analista de Sistemas 262

Analista de Sistemas / Programador de

Aplicaciones Web / Administrador de Servidor

518

3.1.9. Presupuesto

Cuadro 3.8: Equipos Computacionales y Costos


Equipo Unidades Costo Unitario ($

USD)

Costo Total ($ USD)

Computadora Escritorio compatible 02 575.00 1,150.00

Modem/Router D-Link 01 96.00 96.00

TOTAL 1,246.00



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

21

Cuadro 3.9: Software y Costos


Software Tipo Licencia Costo $ USD


licencia

0.00

Microsoft Office

2010


licencia

0.00

Sublime Text IDE Desarrollo Versión Gratuita 0.00

MySQL

Workbench

Gestor Modelado y Base de

Datos

Versión Gratuita 0.00

XAMPP Servidor Web Local Versión Gratuita 0.00

Chrome/Firefox Navegador Web Versión Gratuita 0.00

PHP 5 Lenguaje de Programación Versión Gratuita 0.00

MySQL 5.3 Base de Datos Versión Gratuita 0.00

Bizagi Modeler Modelado de Procesos Versión Gratuita 0.00

StarUML Modelado y Desarrollo Versión Gratuita 0.00

TOTAL 0.00



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

22

Cuadro 3.10: Roles y Costos de las Horas requeridas



(horas)

Costo por hora

($ USD)

Costo Total Estimado

($ USD)

Encargado Proyecto / Analista

de Sistemas

262 7.51 1,967.62

Analista de Sistemas /

Programador de Aplicaciones

Web

518 5.25 2,719.50

TOTAL 4,687.12

3.1.10. Cronograma

Cuadro 3.11: Cronograma de Tareas según Estimación Inicial


Nombre de tarea Duración Predecesoras

Desarrollo de Proyecto 624 horas

Inicio 12 horas

Elaborar el Acta de Constitución 8 horas

Identificar a los Interesados 4 horas 4

Planificación 40 horas 3

Definir el Alcance del Proyecto 12 horas 5

Definir Requerimientos del Proyecto 16 horas 7

Estimar Recursos 12 horas 8

Ejecución 572 horas 6

Adquirir Recursos 36 horas 6

Definir Personal y Roles 8 horas

Desarrollar Roles 16 horas 12

Adquirir Equipos Tecnológicos 8 horas 13

Instalar Equipos Tecnológicos 4 horas 14

Desarrollar la Aplicación Web (Sprint 1 de N) 452 horas 11

Iteración 0 92 horas 15

Análisis 12 horas 15



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

23

Alcance del Sistema 8 horas 15

Product Backlog: Requerimientos Funcionales 4 horas 19

Diseño 76 horas 18

Arquitectura Sistema 4 horas 20

Diagramas de Casos de Uso 24 horas 22

Casos de Uso Generales 8 horas 22

Casos de Uso Extendidos 16 horas 24

Diagramas de Actividades 8 horas 23

Modelo de Datos 8 horas 26

Bocetos de Interfaces 12 horas 27

Importación de Datos 20 horas 28

Presentación Interfaces Incremento 0 4 horas 21



Retroalimentación 0 8 horas 30

Construcción 110 horas 32

Generación de Base de Datos 4 horas 33

Gestión de Recetas 36 horas 35

Maquetación 8 horas 35

Codificación de Procesos 24 horas 37

Pruebas Funcionales 4 horas 38

Gestión de Minutas 70 horas 36




Presentación Aplicación Web Incremento 1 4 horas 34





Reporte 01: Requisiciones 32 horas 47




Reporte 02: Listado para Compras 26 horas 49









Acceso Restringido 56 horas 60




BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

24



Reporte 03: Minutas Proyectadas 30 horas 62









Gestión de Tipos de Alimentos 14 horas 73




Gestión de Alimentos 19 horas 75



Pruebas Funcionales 1 hora 81

Gestión de Tipos de Platos 11 horas 79




Gestión de Tipos de Personas 11 horas 83




Gestión de Instalaciones 19 horas 87





Despliegue 48 horas 16

Instalación y Configuración del Dominio y Hosting 8 horas 71

Instalación de la Aplicación Web en Hosting 24 horas 97

Pruebas y Correcciones 16 horas 98

Mantenimiento 36 horas 96



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

25

3.2. Desarrollo

Se determinó que una serie de acciones basadas en prácticas ágiles eran las más indicadas, desde una

posición cautelosa al considerar qué fases de gestión de proyectos y qué artefactos UML se deberían

incluir de tal manera que proporcionase lo suficiente y necesario, pero a su vez se mantuviese la

ligereza para iniciar la construcción del producto software obteniendo incrementos a corto plazo que

permitiesen ir depurando y mejorando las funcionalidades, teniendo en cuenta el tiempo y el equipo

de trabajo prácticamente estaba conformado solo por 2 personas. De igual manera se planteó partir

de un enfoque según el marco de trabajo SCRUM para abordar la construcción del producto software,

donde se procuró identificar cómo se emparejaban los roles y fases requeridas, tomando en cuenta

los documentos y/o artefactos necesarios definidos previamente que proporcionaron la claridad de lo

que se pretendía construir.

3.2.1. Marco de Trabajo Ágil: SCRUM

El marco de trabajo Scrum, no obligó a seguir una serie de pasos estrictos, sino que facilitó la

incorporación y combinación de otras prácticas alineadas a sus principios [4][5], tales como los

documentos propios de una gestión de proyectos como los artefactos de un desarrollo de software.

Es por ello que una de las primeras tareas fue aportar algo de formalización como proyecto a través

de un acta de constitución, para luego dar paso a la definición de los requerimientos de manera

general y los recursos humanos necesarios para llevarlos a cabo.

En una reunión previa a las iteraciones entre los involucrados, se definieron los roles requeridos por

Scrum, donde se designó al Jefe de Planificación como el Product Owner por ser el conocedor de los

procesos y tener una idea clara de lo que se esperaba de la aplicación. Se designó al Asistente de

Planificación para el rol de Scrum Master por su perfil académico y por el conocimiento recientemente

adquirido sobre lo necesario para el desarrollo de software. El Development Team estuvo

conformado principalmente por un desarrollador web, quien por su experiencia asumió diversos

roles, tales como: maquetador, programador, tester y lo necesario como administrador del servidor.

Si bien Scrum como parte de su teoría prescribe cuatro eventos formales (contenidos dentro del

Sprint) para la inspección y adaptación, en la práctica para el contexto de la empresa, éstos se dieron

de la siguiente manera:



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

26

- Sprint: Sí se llevaron a cabo, estimando en promedio de 20 a 25 días.

- Sprint Planning: Sí se llevó a cabo, pero solo una vez (en la Iteración 0).

- Daily Scrum: Sí se llevó a cabo, pero no todos los días, al menos se procuró que sea interdiario.

- Sprint Review: Sí se llevó a cabo, al finalizar cada Iteración.

- Sprint Retrospective: No se llevó a cabo.

A pesar de que no hubo rigidez en los eventos, se procuró tener siempre presente el comportamiento

y la relación de éstos para mantener esa cercanía a las mejores prácticas de Scrum, siguiendo el

esquema de resumen siguiente:

Figura 3.3: Ciclos del Marco de Trabajo SCRUM

Fuente: Esquema de proyectosagiles.org



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

27

Así mismo con la documentación sugerida por Scrum, se procuró manejar lo necesario, teniendo en

cuenta lo siguiente:

- Product Backlog: Sí se usó, pero solo se modificó al inicio para priorizar los requerimientos,

es decir la lista no cambió durante todos los sprints. Esta lista se puede apreciar en la

Iteración 0.

- Sprint Backlog: No se usó, ya al ser una sola persona y ser pocas tareas concretas (según la

división presente en cada Sprint del cronograma) el control de su trabajo sería manejable.

3.2.2. Tareas Realizadas

Iteración 0

Denominada CERO porque se contempló aspectos de análisis de la cual se desprendió la primera lista

de requerimientos Product Backlog priorizada de acuerdo al valor para el Product Owner.

Esta iteración inicia con una reunión con el Product Owner y el Scrum Master, donde se definió el

alcance del sistema para obtener una lista de requerimientos realistas. Luego siguió una reunión

donde el Product Owner iba manifestando lo que esperaba del software mientras el Scrum Master

iba escribiendo en una pizarra a modo de historia de usuario, y luego de que él validaba la definición

de cada una de ellas, el Scrum Master recién procedía a anotarlas en un post-it que iba pegando en

otra sección de la pizarra. Para finalizar la reunión se realizó la priorización de las historias (Product

Backlog) de acuerdo a las necesidades más relevantes del Product Owner, siendo ésta una de las

principales finalidades.



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

28

Cuadro 3.12: Product Backlog (Requerimientos como Historias de Usuarios)


ID Historia de Usuario Descripción Criterios Aceptación Tamaño

HU1

COMO Planificador QUIERO guardar los datos de las recetas PARA tenerlos disponibles en cualquier momento

El formulario que permite vincular recetas con ingredientes. Considera los siguientes datos: Nombre Receta, Tipo de Plato, Unidad, Color, Gramaje de Plato.

HU2

COMO Planificador QUIERO guardar los datos de las minutas PARA generar planificaciones por periodos de tiempo

El formulario que permite vincular minutas con instalaciones, recetas, ingredientes y personas. Considera los siguientes datos: Fecha, Jornada, Instalación, Cantidad de Tipos de Platos, Recetas, Ingredientes.

HU3

COMO Planificador QUIERO consultar el reporte de requisiciones PARA saber las cantidades a utilizar en la preparación de minutas

El listado que permite ver las cantidades en gramajes que se deben utilizar en la producción de platos

HU4

COMO Planificador QUIERO consultar el reporte de listado de compras PARA saber las cantidades y sus precios de los ingredientes a comprar

El listado que permite ver las cantidades y costos a asumir en las compras de las minutas planificadas

HU5

COMO Usuario QUIERO un acceso restringido PARA evitar que otras personas puedan manipular los datos registrados

El formulario que permite ingresar y validar un nombre de usuario y contraseña



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

29

HU6

COMO Planificador QUIERO consultar el reporte de minutas PARA saber la cantidad de minutas por atender

El listado que permite ver las minutas por periodos de tiempo seleccionados

HU7

COMO Planificador QUIERO guardar los datos de los tipos de alimentos PARA tenerlos disponibles en cualquier momento

El formulario que permite ingresar los datos de tipos de alimentos. Considera los siguientes datos: Nombre Tipo de Alimento.

HU8

COMO Planificador QUIERO guardar los datos de los alimentos PARA tenerlos disponibles en cualquier momento

El formulario que permite ingresar los datos de alimentos. Considera los siguientes datos: Nombre Alimento, Tipo de Alimento, Costo, Código, Unidad de Medida de uso, Unidad de Medida de compra, Color, Factores.

HU9

COMO Planificador QUIERO guardar los datos de los tipos de platos PARA tenerlos disponibles en cualquier momento

El formulario que permite ingresar los datos de los tipos de platos. Considera los siguientes datos: Nombre de Tipo de Platos, Gramaje.

HU10

COMO Planificador QUIERO guardar los datos de los tipos de personas PARA tenerlos disponibles en cualquier momento

El formulario que permite ingresar los datos de los tipos de personas. Considera los siguientes datos: Nombre de Tipo de Persona

HU11

COMO Planificador QUIERO guardar los datos de las instalaciones PARA tenerlos disponibles en cualquier momento

El formulario que permite ingresar los datos de las instalaciones. Considera los siguientes datos: Alias, Nombre, Rut, Dirección, Teléfono, Tipos de Personas, Cantidad de Raciones, Tipos de Platos, Total Raciones.



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

30

Como ya se ha mencionado, fue determinante la experiencia del programador (Development Team),

pues cuando se le comunicó que se trabajaría con Scrum su receptividad fue positiva, dado que se

adaptó para realizar estimaciones de tiempo cortas para los Sprint, definiendo un tiempo promedio

de 22 días hábiles para lograr entregables, lo que llevó a que él mismo propusiese hacer una

codificación que solo se acercase a Extreme Programming (XP) sincerando que no aseguraría ser tan

rígido con esa metodología, ya que se enfocaría en avanzar pudiendo dejar de lado ciertos principios

como la refactorización de código entre otros.

Otra finalidad de este Sprint también fue obtener las primeras interfaces a manera de un incremento,

que permitieron brindar al Product Owner una primera idea más “tangible” de lo que sería la

aplicación web, pasando a través de algunos diagramas y artefactos UML como se verán a

continuación.

Arquitectura de la Solución: Cliente - Servidor

El Scrum Master estableció la arquitectura física sobre la cual se basaría la solución, que corresponde

al modelo Cliente-Servidor, ya que era parte de la disponibilidad deseada.



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

31

Figura 3.4: Diagrama de Arquitectura Web


Vista de despliegue

Este pretendió mostrar el despliegue de la configuración de los componentes del sistema. Con este

modelo se permitió tener una idea general de los elementos/componentes necesarios y su

interacción.



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

32

Figura 3.5: Diagrama de Despliegue


Modelo de Caso de Usos del Sistema

El modelo de Casos de Uso del Sistema presentó las interacciones entre el sistema y los actores

involucrados. Se representó mediante un Diagramas de Casos de Uso.



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

33

Figura 3.6: Diagrama General de Casos de Uso


Dado que casi todos los grupos de información compartieron una gestión parecida de sus datos, se planteó

establecer un caso de uso en común:

Figura 3.7: Diagrama de Caso de Uso de Gestionar Datos




BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

34

Para los Casos de Uso Gestionar Menús, se requirió una serie de acciones particulares por ser la parte que

integraba los demás datos ya ingresados (Instalaciones, Recetas, Tipos de Personas, etc.), por lo que se

plantearon casos de uso de acuerdo a la necesidad específica:

Figura 3.8: Diagrama de Caso de Uso de Gestionar Menús


También se planteó una serie de casos de uso particulares para Obtener Reportes Consolidados:

Figura 3.9: Diagrama de Caso de Uso de Obtener Reportes Consolidados




BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

35

Diagrama de Actividades

Este diagrama definió las actividades manuales y los procedimientos automatizados habituales que

se incorporarían en el sistema de acuerdo a los casos de uso definidos anteriormente. Para lo cual se

utilizó una notación BPMN, ya que era una representación que podría aportar mayor familiaridad a

los involucrados.

Se consideró mostrar un diagrama que reflejase el orden de las actividades generales:

Figura 3.10: Diagrama de Actividades Generales




BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

36

Figura 3.11: Diagrama de Actividad de Acceso Restringido


Figura 3.12: Diagrama de Actividad de Gestión de Datos




BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

37

Modelo de Datos Relacional

En esta actividad se diseñó el modelo de clases y las relaciones entre ellas, así también como su

cardinalidad, además se bosquejó las relaciones de las entidades integradas en el sistema. Se tuvo en

cuenta dar forma al sistema en función del modelo de análisis y de los requisitos establecidos.



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

38

Figura 3.13: Modelo Relacional



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

39

Iteración 1

Se generó la estructura de la base de datos y se construyó el primer entregable con funcionalidades

básicas para Gestión de Recetas y Gestión de Minutas (Registro, Modificación y Eliminación).

En esta iteración el Scrum Master se reunió con el Development Team para poder levantar las

observaciones realizadas por el cliente en la presentación del Incremento 0 lo que se denominó como

la Retroalimentación 0 (en referencia a la iteración 0) y proseguir de acuerdo a la lista de

características prioritarias (Product Backlog) para iniciar con los dos primeros requerimientos

definiendo las tareas a realizar. De esta manera si bien no se llevó un control a través de un Sprint

Backlog, por tratarse de una sola persona en el Development Team, el Scrum Master lograba hacer el

seguimiento a través de interacciones personales y verificación visual de avances. Cabe mencionar

que, en este punto, luego de la actividad de Generación de Base de datos, se debía agregar la

Migración de Datos de aquel grupo de datos que permitirían que este primer incremento funcione,

tales como: Tipos de Alimentos, Alimentos, Tipos de Platos, Tipos de Personas, Instalaciones.

Afortunadamente ya se contaba con estos datos en archivos Excel lo que facilito su adaptación y carga

en la base de datos creada.

Una vez logrado el Sprint 1 se procedió a la presentación con el cliente de la presentación de la

aplicación web con el Incremento 1. En esta reunión el Product Owner acoto que se debería simplificar

más el ingreso de datos, así como aumentar sus validaciones (por ejemplo: verificaciones de tipo, de

formato, etc.), sin embargo, se aclaró que se mantendrían solo las necesarias y las demás se

agregarían más adelante, esto para no repercutir en el tiempo de desarrollo.



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

40

1. Recetas

Figura 3.14: Interface Registro de Receta


Figura 3.15: Interface Consultar, Modificar y Eliminar Receta




BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

41

2. Minutas

Figura 3.16: Interface Ingreso de Minutas


Figura 3.17: Interface Consultar, Modificar y Eliminar Minutas




BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

42

Iteración 2

Se construyó el primer grupo importante de reportes: Requisiciones y Listado de Compras.

Se generó la estructura de Reportes de Requisiones y la estructura del Listado de Compras y se

agregaron las funcionalidades básicas para los Reportes de Requisiones y Listados de Compras.

Esta iteración el Scrum Master se reunió con el Development Team para poder levantar las

observaciones realizadas por el cliente en la presentación del Incremento 1 lo que se denominó como

la Retroalimentación 1 (en referencia a la iteración 1). De esta manera, de acuerdo a la lista de

características prioritarias (Product Backlog), no se pudo proseguir con la lista de requerimientos, y

definir las tareas a realizar, que consistían en otro incremento importante ya que era el desarrollo de

los reportes de acuerdo a los datos ya ingresados en la Iteración 1. El Scrum Master continuó con el

seguimiento a través de interacciones personales y verificación visual de avances.

Una vez logrado el Sprint 2 se procedió a la presentación con el cliente del Incremento 2. En esta

reunión el Product Owner acotó que se debería mejorar algunos aspectos visuales en algunos

encabezados de los reportes, tales como: el color, el tamaño botones o de la letra, etc. Sin embargo,

se aclaró que se agregarían más adelante, recordándole que sería así para no repercutir en el tiempo

de desarrollo.

Figura 3.18: Interface Generar Reportes de Requisiciones y Listado de Compras




BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

43

Iteración 3

Se agregó la funcionalidad para restringir el acceso a la aplicación web (a través de un usuario y

contraseña) y se construyó el segundo grupo de reportes: Proyección de Minutas.

Esta iteración el Scrum Master se reunió con el Development Team para poder levantar las

observaciones realizadas por el cliente en la presentación del Incremento 2 lo que denominé como la

Retroalimentación 2 (en referencia a la iteración 2). De esta manera, de acuerdo a la lista de

características prioritarias (Product Backlog), pudimos proseguir con la lista de requerimientos, y

definir las tareas a realizar. Se continuó con el seguimiento a través de interacciones personales y

verificación visual de avances. Una vez logrado el Sprint 3 se procedió a la presentación con el cliente

del Incremento 3. En esta reunión el Product Owner ya no hizo observaciones sobre detalles visuales

o de interacción, dado que pudo comprobar y comprender que se estaba logrando lo más relevante

a nivel de aplicación web como solución: el ingreso y reporte de la información.

Figura 3.19: Interface Inicio de Sesión para Acceso Restringido




BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

44

Iteración 4

En esta Ultima Iteración se construyeron los últimos grupos de información definidos como los que

menos valor aportaban y de los cuales al inicio se podían prescindir, referidos a la Gestión de: Tipos

de Alimentos, Alimentos, Tipos de Platos, Tipos de Personas, e Instalaciones.

En esta iteración ya no se consideró realizar una reunión de Retroalimentación, dado que no hubo

feedback de la Iteración 3 y además la presentación del logro de esta iteración fue breve, dado que

estas funcionalidades ya contenían y mostraban datos que fueron ingresados en la iteración 1 como

parte de la carga previa de datos que se mencionó en dicha iteración.

Figura 3.20: Interface Ingreso de Alimentos




BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

45

Figura 3.21: Interface Consulta de Alimentos


Figura 3.22: Interface Ingreso Factores de Alimentos




BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

46

Figura 3.23: Interface Ingreso de Tipo de Plato


Figura 3.24: Interface Consultas de Tipo de Plato




BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

47

Despliegue

Para ello se configuró y agregó en el servidor un directorio donde se alojaría toda la aplicación web

(scripts, css, JavaScript, imágenes, etc.), de la misma manera se procedió a configurar y vincular la

base de datos.

3.3. Resultados Obtenidos

3.3.1. Resultados Teóricos y/o Académicos

- Documentos puntuales que establecieron una idea clara de la necesidad, así como artefactos

suficientes y necesarios para la construcción inicial de la aplicación web. Tales como:

o Acta de Constitución

o Alcance

o Requerimientos

o Recursos

o Cronograma

- Lista de requerimientos priorizados (backlog) que se actualizaron en cada iteración (sprint) de

acuerdo a las necesidades cambiantes del usuario, en coordinación cercana con el equipo de

desarrollo.

- Entregables que permitieron al usuario un acercamiento real a la aplicación web para validarla,

confirmando o corrigiendo el rumbo de lo que se esperaba como apoyo para su labor.

- Una metodología propia de trabajo con fundamentos ágiles, tanto en lo que respecta a gestión,

así como en una serie de pasos para la construcción del producto (aplicación web).



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

48

3.3.2. Resultados computacionales y/o aplicativo y/o valorativo y/o

estadísticos

Los resultados se obtuvieron de acuerdo a planificaciones realizadas bajo una muestra con las

siguientes características:

- Cantidad de Personas encargadas: 01

- Cantidad de Comensales a atender: 300 comensales

- Periodo de planificación: 10 semanas

- Cantidad de Servicios a Planificar: Desayuno, Almuerzo y Cena

- Cantidad de platos por Servicio

✓ Desayuno: 400 recetas

✓ Almuerzo: 400 Recetas

✓ Cena: 400 Recetas

Base de Datos Disponible: Comparación Información de platos y minutas Manual vs Automatizada

(Aplicación Web)

El proceso manual que se realizaba consistía en la utilización de 02 hojas de cálculo (MS Office Excel

2010) y un documento físico (formato A3) elaborado a mano para cada semana de planificación. De

acuerdo a ello se generaron 03 copias (para Planificación, Compras y Almacén) por cada semana,

obteniendo:

- 10 registros (planificaciones) distintos x 3 copias = 30 copias en total repartidas



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

49

Figura 3.25: Reporte en Excel Generado a Mano


- Fuente de datos centralizados para consultas: 0

Con el proceso automatizado no se generaron documentos físicos, toda la información fue

manipulada y almacenada digitalmente, generando los reportes (planificaciones) en archivos como

hojas de cálculo (MS Office Excel 2010), teniendo como principales parámetros: tiempo y margen de

error (“precisión”), obteniendo:

- 10 registros (planificaciones) generados automáticamente como reportes



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

50



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

51

Figura 3.26: Reporte de Requisiciones Generado automáticamente desde la Aplicación Web




BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

52

- Fuente de datos centralizados para consultas (base de datos de Recetas ingresadas) a través de

la aplicación web disponible mediante internet:

Figura 3.27: Listado de Tablas de la Base de Datos MySQL en el Servidor Linux




BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

53

Figura 3.28: Listado de Archivos y Directorios del Código Fuente en el Servidor Linux




BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

54

Figura 3.29: Pantalla de Menús de Aplicación Web a través de la URL




BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

55

Reportes más precisos en valores y en menor tiempo:

Comparación Planificación de Minutas Manual vs Automatizada (Aplicación Web)

Los principales parámetros a tener en cuenta: tiempo, costo y margen de error (“precisión”). De

donde se desprende los siguientes seguimientos:

Tiempo Empleado en Horas

Tabla 3.1: Tiempo Empleado en Horas en cada Semana


Semana Manual Automatizado

1 40 19

2 43 15

3 39 14

4 41 10

5 40 8

6 38 6

7 37 5

8 37 4

9 36 4

10 39 4

Figura 3.30: Gráfico de Tiempo de Reporte Manual vs Automatizado


0

5

10

15

20

25

30

35

40

45

50

1 2 3 4 5 6 7 8 9 10

Reporte Manual vs Reporte AutomatizadoTiempo Empleado

Manual Automatizado

Horas

Semanas



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

56

Costo de Tiempo Empleado (Horas) en Dólares Americanos

De acuerdo a la media de USD $ 5.00 por hora de trabajo

Tabla 3.2: Costo en Dólares Americanos de Tiempo Empleado en Horas (por Semana)



1 $200.00 $ 95.00

2 $215.00 $ 75.00

3 $195.00 $ 70.00

4 $205.00 $ 50.00

5 $200.00 $ 40.00

6 $190.00 $ 30.00

7 $185.00 $ 25.00

8 $185.00 $ 20.00

9 $180.00 $ 20.00

10 $195.00 $ 20.00

Figura 3.31: Gráfico de Costo de Reporte Manual vs Automatizado


$-

$50.00

$100.00

$150.00

$200.00

$250.00

1 2 3 4 5 6 7 8 9 10

Reporte Manual vs Reporte AutomatizadoCosto por Tiempo Empleado

Manual Automatizado

Costo

Semanas



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

57

Margen de Error (Precisión) de acuerdo a valores incorrectos

Tabla 3.3: Margen de Error de acuerdo a valores incorrectos



1 5 1

2 4 0

3 4 1

4 3 0

5 4 0

6 2 0

7 3 0

8 3 1

9 2 0

10 2 0

Figura 3.32: Gráfico de Errores cometidos en Reporte Manual vs Automatizado


0

1

2

3

4

5

6

1 2 3 4 5 6 7 8 9 10

Reporte Manual vs Reporte AutomatizadoTiempo Empleado

Manual Automatizado

Cantidad Errores

Semanas



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

58

Demostración Científica utilizando Prueba Estadística

La Metodología aplicada al presente Trabajo de Suficiencia corresponde al uso de técnicas de

estadísticas descriptivas y técnicas de Inferencia de prueba de hipótesis para comparación de dos

medias utilizando el software estadístico SPPS

Tabla 3.4: Resumen de Medidas Estadísticas Descriptivas a través de SPSS del Tiempo, Costo y

Errores según Tipo de Planificación de Menú en cada Semana


Tipo de Planificación N Media

Desv.

Desviación

Desv. Error

promedio

Tiempo de Planificación de

Menú

Planificación Manual 10 39,00 2,108 0,667

Planificación Software 10 8,90 5,405 1,709

Costo por Tipo en $ Planificación Manual 10 195,30 10,584 3,347


Numero de Errores según

Tipo

Planificación Manual 10 3,20 1,033 0,327


Contrastación de Hipótesis Para el tiempo de Planificación del Menú

Hipótesis Nula (H0): El tiempo promedio en horas de planificación del menú de manera manual es

igual al tiempo de planificación del menú usando el Software.

Hipótesis Alterna (H1): El tiempo promedio en horas de planificación del menú de manera manual es

diferente al tiempo de planificación del menú usando el Software.

H0: �̅�𝑚𝑎𝑛𝑢𝑎𝑙 − �̅�𝑠𝑜𝑓𝑡𝑤𝑎𝑟𝑒 = 0

H1: �̅�𝑚𝑎𝑛𝑢𝑎𝑙 ≠ �̅�𝑠𝑜𝑓𝑡𝑤𝑎𝑟𝑒 = 0

Para probar la Hipótesis tengo que calcular el coeficiente muestral que es el estadístico t, este valor

del estadístico t viene a ser el punto de referencia que tengo que comparar con la Tabla T Student, y

comparo si el valor es menor o mayor y en qué región de probalidad cae.

Formula del estadístico de prueba T y la región de rechazo en la campana de Gauss



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

59

Figura 3.33: Gráfico de rechazo en la campana de Gauss


De la muestra se obtuvo un coeficiente muestral t = 16,407 con un p=0,000, el cual es menor de 0,05

(Nivel de Significancia); es decir se rechaza la Hipótesis Nula (H0) y se concluye que el tiempo

promedio en horas de planificación del menú de manera manual no es igual al tiempo de

planificación del menú usando el Software.

Así mismo del intervalo de confianza de las diferencias de medias ( �̅�𝑚𝑎𝑛𝑢𝑎𝑙 − �̅�𝑠𝑜𝑓𝑡𝑤𝑎𝑟𝑒) de rango

positivo (26,091 a 34,109) se concluye que el tiempo promedio de planificación de menú en forma

manual es mayor que el tiempo de planificación usando la Aplicación Web.

Contrastación de Hipótesis para el Costo del tiempo empleado

Hipótesis Nula (H0): El Costo del tiempo de planificación del menú de manera manual es igual al costo

de planificación del menú usando el Software.

Hipótesis Alterna (H1): El Costo del tiempo de planificación del menú de manera manual no es igual

al costo de planificación del menú usando el Software.

H0: 𝐶�̅�𝑎𝑛𝑢𝑎𝑙 − 𝐶�̅�𝑜𝑓𝑡𝑤𝑎𝑟𝑒 = 0

H1: 𝐶�̅�𝑎𝑛𝑢𝑎𝑙 ≠ 𝐶�̅�𝑜𝑓𝑡𝑤𝑎𝑟𝑒 = 0



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

60


(Nivel de Significancia); es decir se rechaza la Hipótesis Nula (H0) y se concluye que el Costo por

tiempo de planificación del menú de manera manual no es igual al tiempo de planificación del menú

usando el Software.

Así mismo del intervalo de confianza de las diferencias de medias ( 𝐶�̅�𝑎𝑛𝑢𝑎𝑙 − 𝐶�̅�𝑜𝑓𝑡𝑤𝑎𝑟𝑒) de rango

positivo (130,746 a 170,854) se concluye que el Costo de planificación de menú en forma manual es

mayor que el Costos de planificación usando la Aplicación Web.

Contrastación de Hipótesis para el número de margen de Error por Tipo de Planificación

Hipótesis Nula (H0): El Margen de error por valores incorrectos en la de planificación del menú de

manera manual es igual al margen de error por valores incorrectos de planificación del menú usando

el Aplicativo Web.

Hipótesis Alterna (H1): El Margen de error por valores incorrectos en la planificación del menú de

manera manual no es igual al margen de error por valores incorrectos de planificación del menú

usando el Aplicativo Web.

H0: �̅�𝑚𝑎𝑛𝑢𝑎𝑙 − �̅�𝑠𝑜𝑓𝑡𝑤𝑎𝑟𝑒 = 0

H1: �̅�𝑚𝑎𝑛𝑢𝑎𝑙 ≠ �̅�𝑠𝑜𝑓𝑡𝑤𝑎𝑟𝑒 = 0


(Nivel de Significancia); es decir se rechaza la Hipótesis Nula (H0) y se concluye que el margen de error

por valores incorrectos en la planificación del menú de manera manual no es igual al margen de error

por la planificación del menú usando el Aplicativo Web.

Así mismo del intervalo de confianza de las diferencias de medias ( �̅�𝑚𝑎𝑛𝑢𝑎𝑙 − �̅�𝑠𝑜𝑓𝑡𝑤𝑎𝑟𝑒) de rango

positivo (2,143 a 3,567) se concluye que el marguen de error de la planificación de menú en forma

manual es mayor que el marguen de error de la planificación usando la Aplicación Web.



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

61

Prueba de Hipótesis de Diferencia de dos Medias utilizando el SPSS

Tabla 3.5: Prueba de Hipótesis de muestras independientes de acuerdo al SPSS


Prueba de muestras independientes

Prueba de

Levene de

igualdad de

varianzas Prueba T para la igualdad de medias

F Sig. t

Grados

de

Liberta

gl

Sig.

(bilateral)

Diferencia

de medias

Diferencia

de error

estándar

95% de intervalo

de confianza de la

diferencia

Inferior Superior

Tiempo de

Planificación

de Menú

Se asumen

varianzas

iguales

9,746 0,006 16,407 18 0,000 30,100 1,835 26,246 33,954

No se asumen

varianzas

iguales

16,407 11,677 0,000 30,100 1,835 26,091 34,109

Costo por

Tipo en $

Se asumen

varianzas

iguales

9,547 0,006 16,431 18 0,000 150,800 9,178 131,519 170,081

No se asumen

varianzas

iguales

16,431 11,697 0,000 150,800 9,178 130,746 170,854

Numero de

Errores

según Tipo

Se asumen

varianzas

iguales

5,513 0,031 8,043 18 0,000 2,900 0,361 2,143 3,657

No se asumen

varianzas

iguales

8,043 12,758 0,000 2,900 0,361 2,120 3,680



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

62

En los tres casos para probar la Hipótesis Nulas tengo que calcular un valor que es el coeficiente de muestra

que se va denominar el coeficiente T-Student, este coeficiente T es el punto de referencia que tengo que

comparar en la tabla T. Si el coeficiente T que comparo en la tabla es menor que la significancia(p), donde

p es el coeficiente muestral si p<0.005, quiere decir que es significativo por lo que se rechaza las hipótesis

nulas (Ho) y se acepta las Hipótesis alternativas que son promedios diferentes.



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

63

3.4. Consideraciones Finales

3.4.1. Conclusiones

1. Se logró desarrollar una aplicación web que permitió reducir el tiempo en la generación de

requisiciones en el servicio de alimentación colectiva, para el área de Planificación de Menús

de la empresa Alinorte Chile. Esto se demuestra en las tablas 3.1, 3.4, 3.5 y figura 3.3,

utilizando Técnicas de Estadística Descriptiva y Técnicas de Inferencia de prueba de

hipótesis para comparación de dos medias, en la cual se aprobó la hipótesis planteada y se

concluyó que el tiempo promedio de planificación de menú en forma manual es mayor que

el tiempo de planificación usando el Aplicativo Web

2. Se logró desarrollar una aplicación web que permitió aumentar la precisión en la generación

de requisiciones en el servicio de alimentación colectiva, para el área de Planificación de

Menús de la empresa Alinorte Chile. Esto se demuestra en las tablas 3.3, 3.4, 3.5 y figura

3.3, utilizando Técnicas de Estadística Descriptiva y Técnicas de Inferencia de prueba de

hipótesis para comparación de dos medias, en la cual se aprobó la hipótesis planteada y se

concluyó que el margen de error de la planificación de menú en forma manual es mayor

que el marguen de error de la planificación usando la Aplicación Web.

3. La evaluación de las distintas alternativas de solución, permitió seleccionar aquella que se

adecuó mejor a las necesidades y realidad de la empresa. Ya que en un principio se

consideró contratar los servicios de una consultora tecnológica externa, pero ésta no

aseguraba lo requerido en cuanto a tiempos. Es así que se reafirmó la idea de abordarlo

como un piloto con recursos propios en infraestructura como en personal, por tanto, un

desarrollo interno era lo más adecuado.

4. Se diseñó una base común y centralizada de datos, que permitiría manejar información

histórica disponible para consultas inmediatas o procesamientos posteriores, al ser

acondicionada para accesos sin importar la hora y el lugar (figura 3.27)

5. Se construyó la aplicación web con las funcionalidades mínimas requeridas para retornar

valor a los usuarios, en primer lugar, en su labor de planificación y luego en la información

proporcionada a las demás áreas. A nivel funcional en un principio contó con el registro de

recetas y menús, en el cual se iban incorporando, evaluando y refinando más

funcionalidades hasta obtener la aplicación web final con los reportes deseados (figura

3.29).



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

64

6. Al desplegar la aplicación web en un servidor de acceso público (pero controlado) se logró

la disponibilidad completa independiente del lugar y el momento para los usuarios

involucrados, lo cual facilitaría a futuro una posible propagación hacia otras sucursales de la

empresa (figura 3.28).

3.4.2. Recomendaciones

1. Si bien la identificación de roles en la planificación de menús fue esencial durante el desarrollo del

proyecto, la separación formal de éstos podría aportar una enorme mejora en los procesos, ya que

algunas tareas se podrían realizar en paralelo y de manera más eficiente de acuerdo con un enfoque

de responsabilidades.

2. La planificación es parte neural del giro de la empresa, sus datos procesados podrían ser

aprovechados en otras áreas, a través de la construcción de módulos informáticos que permitan

acoplarse a lo ya existente las funcionalidades de procesamiento. Por ejemplo, de manera general:

para el área de Almacén, que se permita validar y actualizar el stock de los alimentos usados en la

planificación. Para el área de compras, que se permita calcular y actualizar los gastos del mes, de un

periodo preestablecido o a demanda, según lo que se plantea abastecer para los menús planificados.

3. Así como la aplicación web es propensa a mejorar y a crecer en cuanto a funcionalidades, el control

y organización de ésta también deben ser mejorados, a través de la utilización de un framework

(ligero en php), que puede implicar un periodo de tiempo y su curva de aprendizaje, pero permitiría

aumentar la escalabilidad y mayor organización de código.

3.4.3. Evaluación crítica [de tu formación universitaria respecto a la labor que

se describe]

• Para la realidad problemática que me tocó enfrentar, fue determinante en gran parte

aquellos fundamentos proporcionados por cursos relacionados a Desarrollo de Software, así

como las nociones básicas en lenguajes de programación, algoritmia y redes de

computadoras, que permitiesen identificar en primer lugar el QUÉ aplicar antes que el CÓMO.



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

65

• Otro pilar importante fue la actitud analítica, inculcada en las horas de clase y fuera de ellas

mediante las interacciones con los docentes, en concordancia con el afán de investigación

que apunte a considerar más de una posible solución a un determinado problema.

• Puede percibir la necesidad de contar con una experiencia base para afrontar las necesidades

reales de una empresa, que si bien por lo general queda en cada profesional el conseguirla,

pienso que debería exigirse alineada a un acompañamiento académico, hasta amalgamar el

conocimiento adquirido día a día en clases, con la aplicación real en un centro de labores.



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

66

REFERENCIAS

Betancourt, D. F. (2018). Los 5 Por qué: Análisis de causa raíz basado en preguntas. Recuperado de

Ingenio Empresa: www.ingenioempresa.com/los-5-por-que

(2015). 5 Porqués, Análisis de la causa raíz de los problemas. Progressa Lean. Recuperado de

https://www.progressalean.com/5-porques-analisis-de-la-causa-raiz-de-los-problemas/

Beedle Mike, Arie van Bennekum, Agile Team. (2001). Manifiesto por el Desarrollo Ágil de Software.

Recuperado de http://agilemanifesto.org/iso/es/manifesto.html

Schwaber Ken y Jeff Sutherland. (2016). Scrum Guide.

Qué es Scrum. Proyectos Ágiles. Recuperado de https://proyectosagiles.org/que-es-scrum/

Scrum No es una Metodología. The Home of Scrum. Recuperado de

https://www.scrum.org/resources/blog/scrum-no-es-una-metodologia-es-un-framework

Gómez Julián. (2018). La guerra de las Metodologías ¿Scrum es una metodología ¿Lo es la Agilidad?

¿Lo es el Pmbok?. Laboratorioti. Recuperado de https://www.laboratorioti.com/2018/07/16/la-

guerra-de-las-metodologias-scrum-es-una-metodologia-lo-es-la-agilidad-lo-es-el-pmbok/



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

http://www.ingenioempresa.com/los-5-por-que

http://agilemanifesto.org/iso/es/manifesto.html

https://proyectosagiles.org/que-es-scrum/

https://www.scrum.org/resources/blog/scrum-no-es-una-metodologia-es-un-framework

https://www.laboratorioti.com/2018/07/16/la-guerra-de-las-metodologias-scrum-es-una-metodologia-lo-es-la-agilidad-lo-es-el-pmbok/

https://www.laboratorioti.com/2018/07/16/la-guerra-de-las-metodologias-scrum-es-una-metodologia-lo-es-la-agilidad-lo-es-el-pmbok/

67

ANEXOS



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

68

Aplicación Web de Minutas

Acta de Constitución del Proyecto

Desarrollo de la Aplicación Web

Periodo: 05/2009



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

69

Información del Proyecto

Datos

Empresa / Organización Alinorte S.A.C.

Proyecto Desarrollo de una Aplicación Web para brindar información sobre menús

Fecha de preparación

Cliente

Patrocinador principal Gerente General

Jefe de Proyecto ...

Patrocinador / Patrocinadores

Nombre Cargo Departamento / División Rama Ejecutiva

Descripción del Proyecto

El proyecto consiste en desarrollar una aplicación web para gestionar la información relacionada a las Minutas. Esto se logrará utilizando una metodología ágil (SCRUM) para el desarrollo de la aplicación web. Equipo del Proyecto:

● Patrocinador: --

● Líder Usuario: --

● Jefe de Proyecto: Edward Rojas

● Analistas Desarrolladores: Edward Rojas, Vladimir Prieto

Definición del Producto del Proyecto

Producto(s):



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

70

1. Aplicación Web que, mediante interfaces gráficas amigables, permita una interacción intuitiva con

los principales procesos automatizados, por parte de:

● El usuario planificador, relacionados a la creación, modificación y eliminación de su

información: ingredientes, recetas y minutas.

● El usuario planificador, relacionados a obtener reportes consolidados de ingredientes y costos.

Servicios:

● Gestión de una base de información única y compartida

● Informes periódicos de minutas: requisiciones y listado de ingredientes a comprar.

Definición de Requisitos del Proyecto

Proyecto

● Definir los requerimientos esenciales y ordenarlos de mayor a menor prioridad.

● Demarcación de los tiempos y sus entregables.

● Formalidad media de los entregables en lo que respecta a la arquitectura y documentación.

El Patrocinador tiene los siguientes requisitos:

● Cumplir con los acuerdos presentados en la propuesta, y respetar los requerimientos del cliente.

● Participar en el inicio y término de cada fase o cuando el Jefe de Proyecto estime conveniente

convocar su participación.

● Proponer al Líder Usuario como participante del proyecto.

● Promover la participación de los usuarios.

● Respaldar el proyecto respecto a la disponibilidad de recursos e información.

El Líder Usuario tiene los siguientes requisitos:

● Proporcionar al Equipo de Trabajo el detalle funcional de cada uno de los requerimientos de la

solución.

● Participar activamente en algunas fases del proyecto.

● Definir los usuarios que usarán los entregables del proyecto.

● Coordinar la disponibilidad de los usuarios para la ejecución de las pruebas del proyecto.

● Actuar como intermediario entre el Jefe de Proyecto y los usuarios.

● Aprobar los entregables dirigidos a los usuarios finales que elabora el equipo de trabajo a lo largo

del proyecto.

El jefe de proyecto tiene los siguientes requisitos:

● Adoptar una metodología y/o marco de trabajo ágil para flexibilizar las tareas y la respuesta al

cambio.

● Velar por el éxito y cumplimiento de los objetivos propuestos en el proyecto.

● Establecer hitos de control del proyecto.

● Convocar a las reuniones de seguimiento del proyecto.

● Convocar al Comité del Proyecto, cuando existan cambios que impacten la ejecución del proyecto.

● Entregar los incrementos del producto en los plazos establecidos en el plan de trabajo, cumpliendo

con los objetivos definidos y los estándares mínimos de calidad.

● Conocer el detalle funcional de los procesos de negocio asociados al proyecto.

● Gestionar riesgos y problemas.

● Entregar la documentación actualizada del proyecto.



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

71

Los Analistas Desarrolladores tienen los siguientes requisitos: ● Realizar las actividades de desarrollo de la solución de acuerdo a los alcances y metodología

definidos.

● Ejecutar las pruebas integrales.

● Asegurar la calidad de la información presentada.

● Elaborar la documentación mínima relacionada a la tarea asignada.

Se define al correo electrónico como canal oficial de comunicación, por el cual para los siguientes eventos:

● Envío de documentación.

● Aprobar acuerdos/documentos.

● Presentar avances del proyecto.

Objetivos del Proyecto

Concepto Objetivos Criterio de Éxito

1. Alcance Cumplir con la elaboración de los siguientes entregables:

● Módulo Web de Autenticación de

Usuario, para Administración.

● Módulo Web Panel, para:

○ Gestión de: Tipos de Ingredientes,

Ingredientes, Tipos de Platos, Tipos

de Personas, Instalaciones, Recetas,

Minutas

○ Reportes de: Minutas Periódicas,

Requisiciones, Listado de Compras

Aprobación de todos los Entregables por parte de:

1. Líder Usuario

2. Usuarios

3. Cliente

2. Tiempo Concluir el proyecto en el plazo solicitado por el cliente.

Concluir el proyecto en X Semanas, de 03 de Octubre de 2016 hasta el 28 de Febrero de 2017.

3. Costo Cumplir con el presupuesto estimado del proyecto de S/. ___

No exceder el presupuesto del Proyecto.

4. Calidad Cumplir con el ingreso completo y correcto de los datos. Cumplir con el almacenamiento de todos los datos requeridos.

Aprobación de los Casos de Prueba. Aprobación de los reportes obtenidos.

Finalidad del Proyecto

Propósito General Facilitar información relacionada a la planificación de minutas pertenecientes a la empresa Alinorte S.A.C, a través de una aplicación web.

Fin Último



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

72

● Obtener una base de información única, centralizada y disponible.

● Aumentar la precisión en los cálculos de las minutas y los datos relacionados y derivados.

● Reducir el tiempo de respuesta para obtener reportes sobre minutas, requisiciones e ingredientes a

comprar.

Justificación del Proyecto

Cualitativa Cuantitativa

No existe dentro de la empresa una base de datos consensuada y disponible sobre este ámbito de información.

El Área de Planificación requiere permanentemente una fuente de consulta sobre acciones a tomar en relación a las minutas generadas y los ingredientes involucrados, para prevenir, diagnosticar y resolver.

La empresa busca la optimización de recursos esenciales como es el caso de los ingredientes, tener a disposición datos que lo afecten directamente en el menor periodo de tiempo posible.

Designación del Jefe de Proyecto

Nombre: Niveles de Autoridad:

Reporta a:

Supervisa a:

Cronograma de Hitos del Proyecto

Hito o Evento Significativo Fecha Programada

Inicio del Proyecto

1. Gestión de Proyectos

● Acta de Constitución Aprobada

2. Análisis

● Lista de Requerimientos Priorizados (Según

mayor valor de negocio)

3. Diseño

● Interfaces Aprobadas

● Modelo de Datos Validado

4. Desarrollo



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

73

● Iteración 1

● Iteración 2

● Iteración 3

● Iteración 4

5. Despliegue

6. Pruebas en Producción

7. Capacitación

Fin del Proyecto

Organizaciones o Grupos Organizacionales que intervienen en el Proyecto

Organización o Grupo organizacional Rol que desempeña

Principales Amenazas del Proyecto

● Cambios de los requerimientos o reasignación de las prioridades de los requerimientos por parte

del cliente.

● Los entregables no sean entregados en la fecha correspondiente, originando retrasos en el piloto y

validación con el Líder Usuario.

● No se realicen oportunamente, reuniones de definición, cambios y control del proyecto que el

equipo técnico requiera.

● No exista apoyo y compromiso total por parte de los involucrados (En caso de ausencia durante el

desarrollo del proyecto debe asignarse un reemplazo)

● No se dé un correcto trabajo en equipo de los Analistas de Sistemas involucrado en la construcción

de los productos.

● No se cuente con disponibilidad de los usuarios asignados para la ejecución de las pruebas

funcionales según las fechas indicadas en el cronograma del proyecto.

● Ausencia de miembros del equipo por vacaciones, descansos médicos o renuncias.

● Pérdida de información por siniestros naturales y técnicos.

● Variación de costos en contrataciones de recursos.

Principales Oportunidades del Proyecto

● Ofrecer nuevos servicios que aporten mayor valor a los procesos del área de planificación y su

repercusión en la empresa.

● Ampliar el mercado de potenciales clientes en las diferentes zonas del país.



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

74

● Fortalecer el conocimiento del equipo del proyecto sobre el ámbito de planificación de minutas.

Presupuesto Preliminar del Proyecto

Concepto Costo Unidades SubTotal



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

75


Requisitos del Proyecto

Desarrollo de la Aplicación Web

Periodo:05/2009



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

76

Nombre del Proyecto Siglas del Proyecto

Desarrollo de una Aplicación Web para brindar información sobre minutas

AWM

Necesidad del Negocio u Oportunidad a Aprovechar: Limitaciones y Razones

● Ampliar los servicios de alimentación colectiva proporcionados a las empresas clientes, generando

mayores fuentes de ingresos.

● Gran número de atenciones diarias por instalación, que requieren mayor atención y control por la

carga laboral.

Objetivos del Negocio y del Proyecto: Para Trazabilidad

● Facilitar el acceso a la información generada durante el proceso de atención a los comensales de las

empresas.

● Desarrollar una aplicación web, según los requerimientos priorizados a partir del modelo de

negocio.

● Concluir el proyecto en el plazo solicitado por el cliente, y con el presupuesto estimado.

Requisitos del Proyecto:

Interesado Prioridad (Otorgada por el Interesado)

Requerimientos

Código Descripción

Jefe de Proyecto Muy Alta Priorizar los requisitos de mayor a menor contribución a los servicios planteados, o según el modelo de negocio.

Patrocinador Alta Diseñar el plan de trabajo para cumplir los plazos establecidos

Patrocinador Alta Ejecutar y Coordinar con los involucrados para el cumplimiento de dicho plan.

Patrocinador Alta Presentar el incremento de producto con su respectivo informe, en periodos mensuales.



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

77

Requisitos Funcionales: Procesos del Negocio, Información, Interacción con el Producto, etc.


Requerimientos


Alta ...

En la Aplicación Web:

Alta Proporcionar al área de Planificación de Minutas un Panel Web de acceso restringido, que recuerde la sesión de manera permanente.

Alta Permitir al Jefe del Área, el registro de nuevos tipos de alimentos, alimentos, instalaciones, minutas y usuarios.

Alta Permitir al Jefe del Área la actualización de la información involucrada en la generación de minutas.

Alta Permitir al Jefe del Área la generación de los principales reportes: Requisición de Ingredientes, Listado de Ingredientes a Comprar y Minutas planificadas según periodo de tiempo

Requisitos No Funcionales: Requisitos de nivel de servicio, performance, seguridad, adecuación, etc.


Requerimientos


Alta Disponibilidad las 24 horas del día, todos los días del año.

Media Establecer escalabilidad, tanto en la aplicación de software web, como en la infraestructura y sus características.

Media Contar con procesamiento y respuesta de gama media, en la etapa inicial. Y de acuerdo a demanda se migrará a gama alta.

Alta Utilizar componentes de software libre teniendo en cuenta sus ventajas y grado de aceptación por las plataformas.



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

78

Requisitos de Calidad: Normas o Estándares, o Satisfacción de factores , etc.


Requerimientos


Criterios de Aceptación del Producto: Requisitos que deben cumplirse, antes de aceptar

Conceptos Criterios de Aceptación

1. Técnicos Cumplir con los diseños de arquitectura definidos, así como con la integración de la aplicación web.

2. De Calidad Haber pasado como aceptables todas las prueba relacionadas al registro y obtención de datos.

3. Administrativos La aprobación de todos los entregables del proyecto por parte del Equipo del Proyecto (Líder Usuario principalmente).

4. Comerciales Ninguna

5. Sociales Ninguna

6. Otros Ninguna

Reglas del Negocio: Reglas principales que fijan los principios guías de la Organización

● Comunicación constante entre el equipo de proyecto, respecto a la ejecución del proyecto.

● Emitir informes periódicos del rendimiento del proyecto, y tomar acciones correctivas de ser el

caso.

● La gestión del proyecto se realiza de acuerdo a la Metodología de Gestión de Proyectos de PMI y

Scrum.

Impactos en Otras Áreas Organizacionales



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

79

Ninguna

Impactos en Otras Entidades: Dentro o Fuera de la Organización Ejecutante

Se espera que como resultado del proyecto el personal del Área de Planificación obtenga el conocimiento y la capacidad de mejorar sus actividades y decisiones en relación con otras Áreas de la Empresa.

Requisitos de Soporte y Entrenamiento

● Para los usuarios de las aplicaciones, en cuanto a su acceso, uso y proceso de interacción general.

Supuestos Relativos a Requisitos

● No se modificará el alcance, el costo y tiempo.

● Se dispondrá de los recursos humanos en las fechas estimadas.

● Los involucrados cumplirán lo correspondiente en el momento acordado.

● Se tendrá disponibilidad y acceso a la información necesaria.

Restricciones Relativas a Requisitos

● Al finalizar el proyecto se tendrá la aplicación web en versión beta, que cumplirá los servicios bajo

funcionalidades de interacción simple.



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

80


Alcance del Proyecto

Desarrollo de la Aplicación

Periodo: 05/2009



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

81

Nombre del Proyecto Siglas del Proyecto

Una aplicación web para reducir el tiempo y aumentar la precisión en la generación de requisiciones en el servicio de alimentación colectiva de la empresa Alinorte Chile

AWM

Descripción del Alcance del Producto

Requisitos Características

1. Lograr que se establezca una base de

información relacionada a Cultivos, Fenología,

Plagas, Comparaciones de Muestras y Datos

Meteorológicos.

Una base de datos consensuada y depurada.

2. Lograr que el personal del Área de Planificación

pueda actualizar la información referente a:

Recetas, Minutas, Tipos de Alimentos,

Alimentos, Tipos de Platos, Tipos de Personas,

Instalaciones.

Manuales de Uso, Capacitación y Uso del Aplicativo Web para el responsable de Planificación de Minutas (Encargado de la administración de la información)

3. Lograr que el personal del Área de Planificación

pueda obtener los reportes referidos a:

Requisiciones de Ingredientes, Listado de

Ingredientes a comprar, Minutas planificadas

Manuales de Uso, Capacitación y Uso del Aplicativo Web para el responsable de Planificación de Minutas (Encargado de la administración de la información)

Criterios de Aceptación del Producto: Requisitos que deben cumplirse, antes de aceptar

Conceptos Criterios de Aceptación

1. Técnicos Cumplir con los diseños de arquitectura definidos, así como con la integración de la aplicación web y sus funcionalidades que reflejan los requerimientos.

2. De Calidad Haber pasado como aceptables todas las pruebas relacionadas al registro y obtención de datos por parte de los usuarios.

3. Administrativos La aprobación de todos los entregables del proyecto por parte del Equipo del Proyecto (Líder Usuario principalmente).

4. Comerciales Ninguna

5. Sociales Ninguna



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

82

Entregables del Proyecto: Intermedios y Finales en cada Fase

Fase del Proyecto Productos Entregables

1. Gestión del Proyecto Proyecto Gestionado

2. Adquisición Recibos por Honorarios

3. Ejecución – Análisis Documento de Requerimientos Funcionales y No Funcionales

4. Ejecución – Diseño y

Modelado (S0)

Documento con imágenes de Interfaces Gráficas de Aplicaciones. Documento con diseño de Modelo de Datos. Base de Datos instalada en Servidor.

5. Ejecución – Programación

(S1)

Aplicación Web con panel básico de administración. Aplicación Móvil con ...

Exclusiones del Proyecto: Lo que no será abordado por el Proyecto

Restricciones del Proyecto: Factores que limitan el rendimiento de algún aspecto del proyecto

Internos Ambientales o Externos

Si luego de cumplir los objetivos principales hay un tiempo para agregar algunas interacciones extras, sería bueno considerar también esa situación de cuando el usuario puede incurrir en errores y necesidades de corrección.

Supuestos del Proyecto: Factores que se consideran reales o ciertos

Internos Ambientales o Externos



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

83



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

84



BIBL

IOTE

CA D

E CI

ENCI

AS F

ÍSIC

AS

Y M

ATEM

ÁTIC

AS

matemÁticas ciencias

Documents