Sistema de Venta de Boletos Online

INDICE DE CONTENIDO
I. INTRODUCCION.....................................................................................................................1
1.1. PRESENTACIÓN DEL PROBLEMA DE INVESTIGACIÓN.........................................1
1.2. ANTECEDENTES.............................................................................................................4
1.2.1. ANTECEDENTES DEL PROBLEMA..............................................................................4
1.2.2. ANTECEDENTES DEL PROYECTO...............................................................................5
1.3. ARGUMENTACIÓN DE LA IMPORTANCIA DEL TEMA DE ESTUDIO...................6
1.4. SIGNIFICACIÓN TEÓRICA............................................................................................7
I. DESARROLLO.........................................................................................................................7
CAPÍTULO 1. MARCO TEÓRICO..................................................................................................7
1.5. INGENIERIA DE SOFTWARE........................................................................................7
1.6. METODOLOGIAS DE DESARROLLO...........................................................................8
1.6.1. METODOLOGIA AGIL....................................................................................................8
1.7. METODOLOGÍA ÁGIL SCRUM.....................................................................................9
1.7.1. PRINCIPALES CARACTERÍSTICAS............................................................................10
1.8. LAS REUNIONES...........................................................................................................10
1.8.1. PRODUCT BACKLOG LIST..........................................................................................10
1.8.2. SPRINTS..........................................................................................................................10
1.9. LOS ROLES EN SCRUM................................................................................................12
1.9.1. DUEÑO DE PRODUCTO (PRODUCT OWNER)..........................................................12
1.9.2. SCRUM MASTER...........................................................................................................13
1.9.3. EL SCRUM TEAM..........................................................................................................13
1.10. FASES DE SCRUM.........................................................................................................14
1.10.1. PRE-GAME.....................................................................................................................14
1.10.2. GAME..............................................................................................................................14
1.10.3. POST-GAME...................................................................................................................14
1.10.4. HISTORIAS DE USUARIO............................................................................................15
1.11. CODIGO QR....................................................................................................................16
1.11.1. CARACTERÍSTICAS GENERALES..............................................................................16
1.11.2. CÓDIGOS QR EN DIVERSOS TIPOS DE DATOS.......................................................17
1.12. HERRAMIENTAS DE DESARROLLO DE SOFTWARE.............................................18
1.12.1. LARAVEL.......................................................................................................................18
1.12.2. BOOTSTRAP...................................................................................................................18
1.12.3. VUE.JS.............................................................................................................................19
1.12.4. LENGUAJES DE PROGRAMACIÓN............................................................................19
1.12.4.1. PHP..............................................................................................................................20
1.12.5. BASE DE DATOS...........................................................................................................20
1.12.5.1. MYSQL........................................................................................................................20
1.12.6. HERRAMIENTAS...........................................................................................................20
1.12.6.1. SUBLIME TEXT.........................................................................................................20
1.13. INGENIERÍA WEB.........................................................................................................20
1.14. LENGUAJE UNIFICADO DE MODELADO (U.M.L.)..................................................21
1.14.1. VISTAS DEL UML.........................................................................................................21
1.14.2. DEFINICIÓN DE MODELO...........................................................................................23
1.14.3. DIAGRAMAS UML........................................................................................................23
1.14.3.1. DIAGRAMAS ESTRUCTURALES............................................................................25
1.14.3.2. DIAGRAMAS DE COMPORTAMIENTO.................................................................26
CAPÍTULO 2. JUSTIFICACIÓN DEL PROYECTO......................................................................27
1.1. JUSTIFICACIÓN TÉCNICA...........................................................................................27
1.2. JUSTIFICACIÓN ECONÓMICA....................................................................................27
1.3. JUSTIFICACIÓN SOCIAL.............................................................................................27
3. CAPÍTULO 3. DISEÑO TEORICO DE LA INVESTIGACIÓN.............................................28
3.1. PLANTEAMIENTO DEL PROBLEMA.........................................................................28
3.2. FORMULACIÓN DEL PROBLEMA..............................................................................28
3.3. DELIMITACIÓN DEL CONTENIDO............................................................................28
3.4. DELIMITACIÓN TEMPORAL.......................................................................................29
3.5. DELIMITACIÓN ESPACIAL.........................................................................................29
3.6. OBJETIVOS.....................................................................................................................29
3.6.1. OBJETIVO GENERAL...................................................................................................29
3.6.2. OBJETIVOS ESPECÍFICOS...........................................................................................29
4. CAPÍTULO 4. DISEÑO O DISPOSITIVO DE PRUEBA.......................................................29
4.1. ARGUMENTACIÓN DEL TIPO DE INVESTIGACIÓN...............................................29
4.1. DISEÑO DE INVESTIGACIÓN..............................................................................................30
4.2. MÉTODOS, TÉCNICAS E INSTRUMENTOS DE INVESTIGACIÓN A UTILIZAR. .30
CAPÍTULO 5. DESCRIPCIÓN DEL PROYECTO.........................................................................30
5.1. LISTA DE REQUERIMIENTOS.............................................................................................30
5.2. ANÁLISIS Y DISEÑO.............................................................................................................31
5.2.1. MODELO DE CASOS DE USO............................................................................................31
5.2.2.1. CASOS DE USO.................................................................................................................32
5.2.3. DIAGRAMA DE SECUENCIA.............................................................................................40
5.2.4. DIAGRAMA DE CLASE DE ALTO NIVEL........................................................................45
5.3. MÉTRICAS DE CALIDAD DEL SOFTWARE.......................................................................45
5.3.1. FUNCIONALIDAD...............................................................................................................45
5.3.2. CONFIABILIDAD.................................................................................................................47
5.3.3. FIABILIDAD.........................................................................................................................47
5.3.4. FACILIDAD DE USO...........................................................................................................48
5.3.5. CAPACIDAD DE MANTENIMIENTO................................................................................48
5.3.5.1. MANTENIMIENTO CORRECTIVO.................................................................................49
5.3.5.2. MANTENIMIENTO ADAPTATIVO.................................................................................49
5.3.5.3. MANTENIMIENTO PREVENTIVO.................................................................................50
5.3.6. PORTABILIDAD..................................................................................................................50
5.3.6.1. FACILIDAD DE INSTALACIÓN......................................................................................50
5.3.6.2. FACILIDAD DE AJUSTE..................................................................................................50
5.3.6.3. FACILIDAD DE ADAPTACIÓN.......................................................................................50
5.4. RESULTADOS ESPERADOS.................................................................................................51
5.4.1. APORTES..............................................................................................................................51
5.4.2. IMPACTOS...........................................................................................................................51
5.4.3. OPORTUNIDADES..............................................................................................................51
5.5. PRESUPUESTO DEL PROYECTO.........................................................................................52
5.5.1. MODELO COCOMO II.........................................................................................................52
5.5.1.1 COSTO DEL SOFTWARE..................................................................................................58
5.5.1.2. COSTO DEL HARDWARE...............................................................................................59
5.5.1.3. COSTO DE LA INVESTIGACIÓN....................................................................................60
5.5.1.4. COSTO TOTAL DEL PROYECTO...................................................................................60
5.5.2. CALCULO DEL VAN Y EL TIR..........................................................................................61
5.5.2.1. VALOR ACTUAL NETO (VAN)......................................................................................61
5.5.2.2. TASA INTERNA DE RENTABILIDAD (TIR)..................................................................63
CONCLUSIONES...........................................................................................................................65
RECOMENDACIONES..................................................................................................................66
ANEXOS.........................................................................................................................................68
UNIVERSIDAD PRIVADA FRANZ TAMAYO
Facultad de Ingeniería
Carrera de Ingeniería de Sistemas
PROYECTO
“SISTEMA DE INFORMACION WEB PARA LA
VENTA, RESERVA Y FACTURACION DE
BOLETOS DE CINE CON CODIGO QR”
Integrantes: Univ. Lima Sillero Mauricio

Univ. Mamani Cori Erick Gabriel
Univ. Patón Saavedra Kevin Alejandro
El Alto – Bolivia
2018
I. INTRODUCCION
En los últimos años con el constante crecimiento de la tecnología, se implementan

sistemas para satisfacer las necesidades que existe en la sociedad, el poder brindar
confort, control, supervisión, automatización y optimización son procesos que
mejoran la calidad de vida.
El crecimiento de la tecnología en cuanto al manejo de la información se ha

convertido en un factor crucial para el seguimiento de procesos. Hoy en día, existen
diferentes plataformas, metodologías, modelos, entre otros que permiten un mejor
planeamiento, seguimiento y control del manejo e integración de enormes
cantidades de información. La misma que debe ser difundida de manera inmediata y
evitando los procesos manuales.
Continuamente las empresas buscan distintos medios para lograr mejorar la relación
con sus clientes, ya que los mismos tienen un papel importante para el
funcionamiento o puesta en marcha de una empresa o negocio.
Para esta necesidad básica y a la vez principal, de las empresas, el código QR

permite mejorar la relación con los clientes y así lograr la fidelización de los
mismos a través de mecanismos como ser: información centralizada y actualizada
contantemente.
El uso de páginas web, ha ido generando un consumo excesivo en la sociedad,

donde un gran porcentaje de esta, lo usa para realizar tareas día a día.
1.1. PRESENTACIÓN DEL PROBLEMA DE INVESTIGACIÓN
Las empresas que deseen tener una presencia en internet más efectiva no se pueden
conformar con una página corporativa que tan sólo proporcione información. En los
tiempos que corren el comercio electrónico se ha revelado como una gran vía de
negocio para aquellos que sepan aprovechar sus posibilidades.
Los consumidores ya están totalmente acostumbrados a realizar sus compras online

y los procedimientos de pago son cada vez más diversos y seguros, gracias a
productos como PayPal, por ejemplo. Esto acerca mucho más al consumidor a la
experiencia de compra en internet, con más confianza y ya totalmente adaptados al
uso.
Las prácticas online siguen y crecen, y si un negocio no está preparado para internet,
está muerto.
Una de las causas que pueden llevar a la muerte a un cine, es sin duda el tema de
hoy. Hacer fila para adquirir algún boleto ha pasado de moda y lo que se lleva es
utilizar las aplicaciones móviles o el ordenador para casi todo. Hablamos
de reservas, un negocio en alza en el que destacan empresas como Multicine.
El sistema es interesante: Multicine ofrece a sus clientes una aplicación mediante el
cual controlan cuántas carteleras de películas quedan disponibles y en qué horarios.
Así, cuando el cliente final hace su solicitud online, es su sistema la que le confirma
al cliente su reserva. Dicha constancia llega instantáneamente para que no se
produzcan confusiones ni sobre-ventas.
El cliente se evita la molestia de ir a hacer filas, puede reservar en el momento que
quiera y, cuando llega al cine, con sus datos personales puede confirmar su reserva.
Para Multicine la gran ventaja es contar con un “aliado” que se encarga de esta parte
del negocio y optimiza los tiempos.
El Comercio Electrónico:
El comercio electrónico o e-commerce consiste fundamentalmente en el desarrollo

de acciones de mercado, ventas, servicio al cliente, gestión de cartera, gestión
logística y en general, todo evento de tipo comercial e intercambio de información
llevado a cabo por medio de internet. otra definición podría ser. el comercio
electrónico como aquel intercambio financiero que se realiza, a través de la red,
entre sujetos que pueden estar a una gran distancia física, y que se materializa
generalmente por medios de pago electrónicos.
En la actualidad el E-Commerce se ha convertido en una herramienta con gran éxito

para el mundo de los negocios gracias a la apertura y facilidad de acceso al Internet.
Para poder diferenciar a un negocio “virtual” entre un negocio “real” debemos
identificar los tipos de negocio E-Commerce que existen en el mercado:
 B2B (comercio entre las empresas)
 C2C (Compra y venta de productos y servicios entre particulares)
 B2C (Comercio entre empresas)
Las ventajas que se manejan en los negocios virtuales son la expansión de mercado
globalizada que se alcanza, y la rapidez con la que se manejan los negocios. Aunque
las relaciones con los clientes son interpersonales y pueden causar complicaciones
en los negocios, el uso de las nuevas tecnologías y su innovación han creado
cambios que han mejorado la comunicación con el cliente y la empresa.
Gracias al comercio electrónico se puede efectuar casi cualquier transacción sin

moverse de casa. Las empresas instalan una tienda virtual que despliega un catálogo
de diversos productos, el cliente selecciona los de su interés e inicia el
procesamiento de pago que, por coherencia y comodidad debe ser también
electrónico. Finalmente, el pedido llega a la casa o al ordenador dependiendo del
producto seleccionado. Para esto existe un excelente soporte, atención de quejas y
procesamiento de devoluciones es un punto fundamental para el comercio
electrónico, esta característica es el inicio de la diferenciación en cualquier empresa
que lo implemente. Este sistema cambia totalmente la dinámica de las relaciones
cliente-empresa en cuanto al marketing, es la estructura misma de la empresa que
cambia.
Ventajas del comercio electrónico
 Creación de oportunidades de negocio y nuevas formas de distribución de sus

productos y servicios.
 Acceso a clientes de cualquier zona geográfica sin limitación, apertura y
expansión hacia nuevos mercados.
 Aumento de la competitividad y calidad de servicio.
 Respuesta rápida a las necesidades y cadenas de entrega más cortas o
inexistentes lo que puede dar lugar a una reducción de precios finales.
 Control de pedidos y clientes.
1.2. ANTECEDENTES
1.2.1. ANTECEDENTES DEL PROBLEMA
Cine Vega es una empresa boliviana dedicada a la operación de complejos

cinematográficos y exhibición de películas que inició sus operaciones en Julio
del 2018. La historia del Cine Vega empieza, a mediados de 2016, con una idea
originada por tres jóvenes bolivianos, quienes, decidieron identificar
oportunidades de inversión y desarrollar nuevos proyectos.
El Cine Vega está compuesta por diferentes áreas que lo distinguen, las mismas
que se mencionan a continuación:
 Área de Ventas: Encargada del manejo y control de todas las ventas

registradas dentro del cine.
 Área de Boletería: Es la encargada de gestionar la venta de entradas para las
películas que se encuentran en cartelera.
 Área de Dulcería: Es la encargada de las ventas y entregas de productos y/o
combos (pop corn, bebidas, chocolates o dulces).
 Área de Marketing: Se encarga de dar pautas a la empresa a fin de motivar
al espectador para que vaya cine, utilizando distintos medios como
publicidad, estudio de mercados, comportamiento de los precios y
promociones.
 Área Administrativa: Esta área tiene como misión atender todo lo inherente
a la administración general del cine (física, financiera, contable y recursos
humanos) y brindar apoyo técnico a las demás áreas en aspectos
administrativos.
 Área de Finanzas: Su función principal es la administración del presupuesto
del cine de forma eficiente.
 Área de Recursos Humanos: Está encargada de la mejora del clima laboral
y el crecimiento de los colaboradores dentro de la organización.
Director
General
Gerente del
Complejo
Area de
Area Area de Area de
Area de ventas Recursos
administrativa Finanzas marketing
Humanos
Area de
boleteria
Area de dulceria
Grafico 1: Organigrama del Cine Vega

Fuente: Elaboración Propia
En vista del crecimiento de esta industria lo que llegaban a ser simples salas de
cines se han convertido en establecimientos que tienen múltiples servicios, para
los cuales se ha visto la necesidad de crear un sistema de información y control
el cual comprende a los servicios de cartelera, boletería. El sistema ayudara a
tener una mejor administración de lo que llegarían a ser estos establecimientos,
como los que ya conocemos en nuestra ciudad.
La administración de un cine implica coordinar desde las taquillas, la venta

online de entradas, los asientos, las funciones y las salas. Con el software para
cine adecuado se puede estar seguro de que nada falle y que la sala se distinga
por su buena organización.
1.2.2. ANTECEDENTES DEL PROYECTO
En una búsqueda realizada acerca de proyectos similares sobre el tema de
sistemas de información web para la venta de boletos destinada a las empresas
de cine se encontró lo siguiente:
Autor Titulo Universidad

Rendon Sabase Análisis, diseño, desarrollo e Escuela Politécnica del
Gabriela implementación de un sistema de Ejercito
venta de boletos de cine para
smartphones utilizando Visual Studio
.net
Descripción Este proyecto tuvo como finalidad realizar la compra de boletos a
través de una aplicación web y una aplicación para dispositivo
móvil donde utilizaron normas de la IEEE 830, además, se
publicó el sitio en el IIS y a través de un router wifi se logró
acceder con dispositivos móviles al sistema de venta de boletos
de cine.
Tabla 1: Análisis, diseño, desarrollo e implementación de un sistema de

venta de boletos de cine para smartphones utilizando Visual Studio .net
Fuente: Sabase (2012)
Autor Titulo Universidad

José Nicolás Aplicación web para la venta de Universidad de Sevilla
López Calzada entradas de cine
Descripción Con el proyecto se pudo desarrollar una aplicación web que
permite publicitar el negocio del cine a través de internet y que
soporte la venta de localidades para los eventos y películas que
se expondrán.
Tabla 2: Aplicación web para la venta de entradas de cine

Fuente: López (2017)
1.3. ARGUMENTACIÓN DE LA IMPORTANCIA DEL TEMA DE ESTUDIO
El sistema de información web para la venta de boletos tendrá principalmente la
función de realizar compras de boletos. Este sistema contara con una interfaz donde
se mostrará la cartelera de películas disponibles, una vez que el cliente haya
seleccionado la película que desee ver se mostrará otra interfaz donde podrá realizar
la reserva, seleccionando así la función que desee y la butaca de preferencia.
1.4. SIGNIFICACIÓN TEÓRICA

Para la implementación del presente sistema y para lograr su funcionamiento, se
dará uso de una metodología ágil SCRUM, este marco de trabajo está diseñado para
satisfacer a los usuarios finales o dueños del producto.
Para el modelado del sistema se utilizará Unified Modeling Language UML que es
un lenguaje estándar en el análisis y diseño de sistemas.
I. DESARROLLO
CAPÍTULO 1. MARCO TEÓRICO

1.5. INGENIERIA DE SOFTWARE
Según Pressman, la ingeniería del software es una disciplina o área de la informática

o ciencia de la computación, que ofrece técnicas y métodos para desarrollar y
mantener software de calidad que resuelva todo tipo.
Según Sommerville, para muchas personas los softwares son solo programas de
computadora, sin embargo, nos comenta que son todos aquellos documentos
asociados a la configuración de datos que se necesitan para hacer que estos
programas operen de manera adecuada. Estos productos de software se desarrollan
para algún cliente en particular o para un mercado en general. Para el diseño y
desarrollo de proyectos de software se aplican metodologías, modelos y técnicas que
permiten resolver los problemas. En los años 50 no existían metodologías de
desarrollo, el desarrollo estaba a cargo de los propios programadores. De ahí la
importancia de contar con analistas y diseñadores que permitieran un análisis
adecuado de las necesidades que se deberían de implementar.
Entre los objetivos de la ingeniería de software están:
 Mejorar el diseño de aplicaciones o software de tal modo que se adapten de

mejor manera a las necesidades de las organizaciones o finalidades para las
cuales fueron creadas.
 Promover mayor calidad al desarrollar aplicaciones complejas.
 Brindar mayor exactitud en los costos de proyectos y tiempo de desarrollo de los
mismos.
 Aumentar la eficiencia de los sistemas al introducir procesos que permitan medir
mediante normas específicas, la calidad del software desarrollado, buscando
siempre la mejor calidad posible según las necesidades y resultados que se
quieren generar.
 Detectar a través de pruebas, posibles mejoras para un mejor funcionamiento del
software desarrollado.
1.6. METODOLOGIAS DE DESARROLLO
Las metodologías de desarrollo de software son marcos o modelos de trabajos que

se utilizan para construir, planificar y controlar el proceso de desarrollo de sistemas.
Hoy en día existen infinidades de metodologías para desarrollar software. Entre
ellas encontramos las Metodologías Tradicionales, las Metodologías
Iterativas/Evolutivas, las Metodologías basadas en Tecnología Web, y las
Metodologías Ágiles.
1.6.1. METODOLOGIA AGIL
Según Trigas, las metodologías ágiles son una serie de técnicas para la gestión
de proyectos que han surgido como contraposición a los métodos clásicos de
gestión como CMMI (Integración del modelo de madurez de capacidad).
Aunque surgieron en el ámbito del desarrollo de software, también han sido
exportadas a otro tipo de proyectos.
Inicialmente, mucha gente asocia metodologías ágiles con falta de

documentación o control sobre el proyecto, pero esto es totalmente falso. Lo que
se desea es minimizar el impacto de las tareas que no son totalmente
imprescindibles para conseguir el objetivo del proyecto. Se pretende aumentar la
eficiencia de las personas involucradas en el proyecto y, como resultado de ello,
minimizar el coste. Llegados a este punto, nos preguntamos si son mejores las
metodologías ágiles que las tradicionales. La respuesta es que no. Entonces,
¿son mejores las tradicionales frente a las ágiles? Tampoco. Como otras muchas
cosas en la vida, depende del tipo de proyecto en el que se apliquen y aquí es
donde tienen su punto de unión con los principios Lean Startup. 2 En el grafico
2 se puede observar las fases de una metodología ágil.
1.7.
1.7.
Grafico 1: Metodología Ágil
METODOLOGÍA ÁGIL SCRUM
Fuente: [Trigas, 2016]
Según Averbud, Scrum es un proceso ágil para desarrollar software que fue aplicado
por primera vez por Ken Schwaber y Jeff Sutherland., quienes lo documentaron en
detalle en el libro Agile Software Development with Scrum. Esta metodología
centra su atención en las actividades de Gerencia y no especifica prácticas de
Ingeniería. Fomenta el surgimiento de equipos autos dirigidos cooperativos y aplica
inspecciones frecuentes como mecanismo de control.
Scrum parte de la base de que los procesos definidos funcionan bien sólo si las
entradas están perfectamente definidas y el ruido, ambigüedad o cambio es muy
pequeño. Por lo tanto, resulta ideal para proyectos con requerimientos inestables, ya
que fomenta el surgimiento de los mismos.
El ciclo de vida definido por Scrum es incremental iterativo y se caracteriza por ser
muy adaptable.
1.7.1. PRINCIPALES CARACTERÍSTICAS

 Equipos auto dirigidos
 Utiliza reglas para crear un entorno ágil de administración de proyectos
 No prescribe prácticas específicas de ingeniería
 Los requerimientos se capturan como ítems de la lista Product Backlog
 El producto se construye en una serie de Sprints de un mes de duración
1.7.2. HERRAMIENTAS Y PRÁCTICAS
Scrum no requiere ni provee prácticas de Ingeniería. En lugar de eso, especifica

prácticas y herramientas de gerencia que se aplican en sus distintas fases para
evitar el caos originado por la complejidad e imposibilidad de realizar
predicciones.
1.8. LAS REUNIONES

1.8.1. PRODUCT BACKLOG LIST
Es una lista priorizada que define el trabajo que se va a realizar en el proyecto.
Cuando un proyecto comienza es muy difícil tener claro todos los
requerimientos sobre el producto. Sin embargo, suelen surgir los más
importantes que casi siempre son más que suficientes para un Sprint.
La Product Backlog list puede crecer y modificarse a medida que se obtiene más
conocimiento acerca del producto y del cliente. Con la restricción de que solo
puede cambiarse entre Sprints. El objetivo es asegurar que el producto definido
al terminar la lista es el más correcto, útil y competitivo posible y para esto la
lista debe acompañar los cambios en el entorno y el producto.
Existe un rol asociado con esta lista y es el de Product Owner. Si alguien quiere
realizar cualquier modificación sobre la lista, por ejemplo: agregar o
incrementar la prioridad de sus elementos tiene que convencer al Product
Owner.
1.8.2. SPRINTS
Un Sprint es el procedimiento de adaptación de las cambiantes variables del

entorno (requerimientos, tiempo, recursos, conocimiento, tecnología). Son ciclos
iterativos en los cuales se desarrolla o mejora una funcionalidad para producir
nuevos incrementos.
Durante un Sprint el producto es diseñado, codificado y probado. Y su
arquitectura y diseño evolucionan durante el desarrollo.
El objetivo de un Sprint debe ser expresado en pocas palabras para que sea fácil
de recordar y esté siempre presente en el equipo. Es posible definir una serie de
restricciones que el equipo deba aplicar durante un Sprint.
Un Sprint tiene una duración planificada de entre una semana y un mes. No es

posible introducir cambios durante el Sprint, por lo tanto, para planificar su
duración hay que pensar en cuanto tiempo puedo comprometerme a mantener
los cambios fuera del Sprint. Dependiendo del tamaño del sistema, la
construcción de un release puede llevar entre 33 y 8 Sprints. Por otra parte,
podrían formarse equipos para desarrollar en forma paralela distintos grupos de
funcionalidad.
Las actividades que se desarrollan durante el Sprint son: Sprint Planning

Meeting, Sprint Backlog, Daily Scrum, Meetings y Sprint Review Meeting.
En el grafico 3, se pueden ver las prácticas involucradas en un Sprint.
Grafico 2: Ciclo de desarrollo Scrum

Fuente: [ProyectosAgiles.org, 2016]
1.9. LOS ROLES EN SCRUM
Scrum propone tres roles diferenciados que deben formalizarse: Dueño de Product
(Product Owner), Scrum Master y Scrum Team. Pero allí, no termina. Scrum
permite, además, que todas aquellas personas que, ya sean inversores, interesados en
el producto como usuarios, y demás, formen parte del proyecto, respetando los roles
formales, participando como audiencia.
1.9.1. DUEÑO DE PRODUCTO (PRODUCT OWNER)
El Dueño de Producto es la única persona autorizada para decidir sobre cuáles

funcionalidades y características funcionales tendrá el producto. Es quien
representa al cliente, usuarios del software y todas aquellas partes interesadas en
el producto.
Funciones y responsabilidades:
 Canalizar las necesidades del negocio, sabiendo "escuchar" a las partes

interesadas en el producto y transmitirlas en "objetivos de valor para el
producto", al Scrum team.
 Maximizar el valor para el negocio con respecto al Retorno de Inversión
(ROI), abogando por los intereses del negocio.
 Revisar el producto e ir adaptándole sus funcionalidades, analizando las
mejoras que éstas puedan otorgar un mayor valor para el negocio.
Aptitudes que debe tener un Dueño de Producto:
 Excelente facilidad de comunicación en las relaciones interpersonales

 Excelente conocimiento del negocio
 Facilidad para análisis de relaciones costo/beneficio
 Visión de negocios
1.9.2. SCRUM MASTER

El Scrum Master es el alma mater de Scrum. Un error frecuente es llamarlo
"líder", puesto que el Scrum Master no es un líder típico, sino que es un
auténtico Servidor neutral, que será el encargado de fomentar e instruir sobre los
principios ágiles de Scrum.
Funciones y responsabilidades:
Garantizar la correcta aplicación de Scrum. Esto incluye, desde la correcta

trasmisión de sus principios a las altas gerencias, hasta la prevención de la
inversión roles (es decir, guardar especial cuidado en que el dueño de producto
no actúe en nombre del Scrum Team y viceversa, o que la audiencia se
inmiscuya en tareas que no le son propicias)
Resolver los conflictos que entorpezcan el progreso del proyecto.
Incentivar y motivar al Scrum Team, creando un clima de trabajo colaborativo,

fomentar la auto-gestión del equipo e impedir la intervención de terceros en la
gestión del equipo.
Aptitudes que debe tener un Scrum Master:
 Excelentes conocimientos de Scrum

 Amplia vocación de servicio
 Tendencia altruista
 Amplia capacidad para la resolución de problemas
 Analítico y observador
 Saber incentivar y motivar
 Capacidad docente e instructiva
 Buen carisma para las negociaciones
1.9.3. EL SCRUM TEAM
El Scrum Team (o simplemente "equipo"), es el equipo de desarrolladores

multidisciplinario, integrado por programadores, diseñadores, arquitectos,
testers y demás, que en forma auto organizada, será los encargados de
desarrollar el producto.
a) Funciones y responsabilidades:
Llevar el Backlog de producto, a desarrollos potencialmente funcionales y
operativos.
Aptitudes que deben tener los integrantes de un Scrum Team:
 Ser profesionales expertos o avanzados en su disciplina
 tener "vocación" (la buena predisposición no alcanza) para trabajar en
equipo
 capacidad de auto-gestión.
1.10. FASES DE SCRUM
Scrum comprende las siguientes fases:
1.10.1. PRE-GAME
Planificación: Definición de una nueva versión basada en la pila actual, junto

con una estimación de coste y agenda. Si se trata de un nuevo sistema, esta fase
abarca tanto la visión como el análisis. Si se trata de la mejora de un sistema
existente comprende un análisis de alcance más limitado. Arquitectura: Diseño
de la implementación de las funcionalidades de la pila. Esta fase incluye la
modificación de la arquitectura y diseño generales.
1.10.2. GAME
Desarrollo de sprints: Desarrollo de la funcionalidad de la nueva versión con

respeto continúo a las variables de tiempo, requisitos, costo y competencia. La
interacción con estas variables define el final de esta fase. El sistema va
evolucionando a través de múltiples iteraciones de desarrollo o sprints.
1.10.3. POST-GAME
Preparación para el lanzamiento de la versión, incluyendo la documentación

final y pruebas antes del lanzamiento de la versión.
1.10.4. HISTORIAS DE USUARIO

Las Historias de Usuario son un elemento básico para aplicar metodologías
Ágiles y especialmente para poder aplicar SCRUM.
La historia de usuario es una definición de la necesidad del usuario, como un

recordatorio de la conversación con el cliente, siendo un acuerdo final de
mínimos para dar por buena la funcionalidad escrita y esperada.
La Historia de Usuario está escrita en lenguaje coloquial al ser simplemente el

recordatorio de la conversación con el cliente, y un acuerdo formal de mínimos
para dar por buena la funcionalidad descrita y esperada.
Son mucho más humanas y entendibles que los casos de uso o los
requerimientos funcionales, que necesitan de un conocimiento técnico para
entenderlos. Un usuario normal no entiende la nomenclatura UML, ni los casos
de uso y tampoco llega a entender perfectamente los requisitos funcionales.
Se utilizan las Historias de Usuario porque siguen los principios básicos de los
requisitos ágiles:
 Potencian la participación del equipo en la toma de decisiones

 Se crean y evolucionan a medida que el proyecto avanza
 Son peticiones concretas y pequeñas
 Contiene la información imprescindible. Menos, es más
 Apoyan la cooperación, colaboración y conversación entre los miembros del
equipo, lo que es fundamental.
Grafico 3: Ejemplo de historia de usuario
Fuente: [ProyectosAgiles.org, 2016]
1.11. CODIGO QR
Un código QR (del inglés Quick Response code, "código de respuesta rápida") es un

módulo para almacenar información en una matriz de puntos o en un código de
barras bidimensional. Fue creado en 1994 por la compañía japonesa Denso Wave,
subsidiaria de Toyota. Presenta tres cuadrados en las esquinas que permiten detectar
la posición del código al lector. El objetivo de los creadores (un equipo de dos
personas en Denso Wave, dirigido por Masahiro Hara), fue que el código permitiera
que su contenido se leyera a alta velocidad. Los códigos QR son muy comunes en
Japón, donde es el código bidimensional más popular.
1.11.1. CARACTERÍSTICAS GENERALES
Aunque inicialmente se usó para registrar repuestos en el área de la fabricación

de vehículos, hoy los códigos QR se usan para administración de inventarios en
una gran variedad de industrias. La inclusión de software que lee códigos QR en
teléfonos móviles ha permitido nuevos usos orientados al consumidor, que se
manifiestan en comodidades como el dejar de tener que introducir datos de
forma manual en los teléfonos.
Las direcciones y los URLs se están volviendo cada vez más comunes en
revistas y anuncios. El agregado de códigos QR en tarjetas de presentación
también se está haciendo común, y permite simplificar en gran medida la tarea
de introducir detalles individuales del nuevo cliente en la agenda de un teléfono
móvil.
Se afirma que no es realmente nueva, ya que se registró originalmente su patente

en 1952, pero hasta los años ochenta no tuvo un importante éxito comercial que
ahora vemos diariamente en envases, paquetes y hasta tarjetas de presentación
(Sánchez, 2013).
Sin embargo, la web especializada en creación de Códigos QR, Unitag.io (S.F.)

afirma que este tipo de códigos como los conocemos hasta la fecha fueron
creados en 1994 por Denso Wave, una subsidiaria japonesa del Grupo Toyota.
El uso de esta tecnología actualmente es libre e incluso no es el único código de
barras de dos dimensiones que vemos en el mercado.
Los códigos QR también pueden leerse desde computadores personales,

teléfonos inteligentes o tabletas mediante dispositivos de captura de imagen
como escáners o cámaras de fotos, programas que lean los datos QR y una
conexión a Internet para las direcciones web.
Gracias a los smartphones podemos recuperar la información cifrada de este tipo

de Códigos QR, y será tan sencillo como descargar alguna aplicación que nos
permita usar la cámara para descifrar los datos. Menciona Computer Hoy (2014)
que “la ventaja de los códigos QR es el acceso directo e inmediato a la
información a la que hacen referencia”. Pero, a pesar de que este es un aspecto
muy positivo de ello, pueden resultar peligrosos ya que la forma inmediata que
nos brindan la información o nos envían a un sitio web puede vulnerar el
dispositivo a que acceda a páginas infectadas o instalación de programas
maliciosos.
1.11.2. CÓDIGOS QR EN DIVERSOS TIPOS DE DATOS

También existe la posibilidad de generar el código QR correspondiente a
diversos tipos de datos: a un texto alfanumérico, a una dirección de Internet
(URL) para un hiper link, a un número de teléfono, a un SMS, a una dirección
de correo electrónico, a una meCard, a una vCard, o a una configuración Wifi,
sin necesidad de instalar ninguna extensión. También existe la posibilidad de
utilizar los códigos con datos personales, como enfermedades, alergias, entre
otros.
El grafico 4 representa el link de una página web.
Grafico 4: Código QR que representa el link a la Página:

www.informatica.bo, generado en http://es.qr-code-generator.com/
1.12. HERRAMIENTAS DE DESARROLLO DE SOFTWARE

1.12.1. LARAVEL
Laravel es un framework de código abierto para desarrollar aplicaciones y

servicios web con PHP 5 y PHP 7. Su filosofía es desarrollar código PHP de
forma elegante y simple, evitando el “código espagueti”. Fue creado en 2011 y
tiene una gran influencia de frameworks como Ruby onRails, Sinatra y
ASP.NET MVC.
Laravel tiene como objetivo ser un framework que permita el uso de una sintaxis
elegante y expresiva para crear código de forma sencilla y permitiendo multitud
de funcionalidades. Intenta aprovechar lo mejor de otros frameworks y
aprovechar las características de las últimas versiones de PHP.
Gran parte de Laravel está formado por dependencias, especialmente de
Symfony, esto implica que el desarrollo de Laravel dependa también del
desarrollo de sus dependencias.
1.12.2. BOOTSTRAP
Es un framework originalmente creado por Twitter, que permite crear interfaces
web con CSS y JavaScript, cuya particularidad es la de adaptar la interfaz del
sitio web al tamaño del dispositivo en que se visualice. Es decir, el sitio web se
adapta automáticamente al tamaño de una PC, una Tablet u otro dispositivo.
Esta técnica de diseño y desarrollo se conoce como responsive, design o en
español diseño adaptativo.
1.12.3. VUE.JS
Vue es un framework open source de JavaScript, el cual permite construir

interfaces de usuarios de una forma muy sencilla. La curva de aprendizaje,
desde el punto de vista de un desarrollador, es relativamente baja.
Vue fue creado por Evan You ex trabajador de Google, quien, es importante

mencionar, fue desarrollador Angular. Vue fue lanzado en el año 2014. Aunque
inicialmente fue pensado para ser una biblioteca personal, la comunidad hizo
que el proyecto creciera a un ritmo impresionante, posicionándolo hoy en día
como uno de los Frameworks web más populares, junto con Angular y React.
Una de las características más importantes de Vue es el trabajo con

componentes. Un componente Vue, en términos simples, es un elemento el cual
se encapsula código reutilizable. Dentro de un componente podremos encontrar
etiquetas HTML, estilos de CSS y código JavaScript. Los componentes
permiten desarrollar proyectos modularizados y fáciles de escalar, si asi lo desea
se puede reemplazar un componente por otro de una forma muy sencilla, como
si de piezas de lego se tratasen.
1.12.4. LENGUAJES DE PROGRAMACIÓN

Es un lenguaje diseñado para describir el conjunto de acciones consecutivas que
un equipo debe ejecutar. Por lo tanto, un lenguaje de programación está
organizado para que se entiendan entre si y a su vez interprete las instrucciones
en un modo práctico para que los seres humanos puedan dar instrucciones a un
equipo. Además, existen lenguajes de programación de bajo los cuales son
utilizados para controlar el hardware dependiendo directamente de la máquina y
alto nivel que no dependen de la máquina, sirven principalmente para crear
programas informáticos que puedan solucionar distintos tipos de necesidades.
1.12.4.1. PHP
PHP identifica a un lenguaje de programación que nació como Personal

Home Page (PHP) Tools, PHP suele procesarse directamente en el servidor,
aunque también puede usarse a través de software 27 capaz de ejecutar
comandos y para el desarrollo de otra clase de programas, sin embargo, en la
actualidad está vinculado a PHP Hypertext Pre-Processor.
1.12.5. BASE DE DATOS

1.12.5.1. MYSQL
MySQL es un sistema de gestión de base de datos relacional, es un sistema

de administración y almacenamiento de base de datos que sirve para
almacenar, agregar y procesar información de manera inmediata. Esto agrega
velocidad y flexibilidad, las tablas son enlazadas al definir relaciones que
hacen posible combinar datos de varias tablas cuando se necesitan consultar
datos.
1.12.6. HERRAMIENTAS
1.12.6.1. SUBLIME TEXT
Sublime Text es un editor de texto avanzado especialmente diseñado para

desarrolladores y se destaca por sus funcionalidades e interfaz del usuario.
Sublime Text es ligero, multiplataforma y cuenta con abundaste plugins. No
es software libre o de código abierto.
1.13. INGENIERÍA WEB

El área de Ingeniería Web es relativamente una nueva dirección de la Ingeniería de
Software para el desarrollo de Aplicaciones Web (Kappel, Pröll, Reich, &
Retschizegge, 2006). La Ingeniería Web trata varios aspectos, metodologías,
herramientas y técnicas que hacen único del desarrollo y construcción de
aplicaciones que se ejecutan en la World Wide Web.
Pressman (2010) refiere que el diseño de webapps4 incluye actividades técnicas y

no técnicas, que incluyen lo siguiente: establecer la vista y sensación de la webapp,
creando la distribución estética de la interfaz de usuario, definiendo la estructura
arquitectónica general, desarrollando el contenido y la funcionalidad que residen en
la arquitectura y planeando la navegación que ocurre dentro de la webapp.
Para el desarrollo de modelos conceptuales de aplicaciones Web existen varios

métodos de diseño en Ingeniería Web, por ejemplo: OOHDM (Object-Oriented
Hypermedia Design Model), WebML (Web Modeling Language), OO-H (Object
Oriented approach), UWE (UML Web Engineering), entre otros. UWE fue uno de
los primeros proyectos usado especialmente para aplicaciones Web.
La Ingeniería Web basada en UML, es un proceso del desarrollo para aplicaciones

Web enfocado sobre el diseño sistemático, la personalización y la generación
semiautomática de escenarios que guíen el proceso de desarrollo de una aplicación
Web. UWE describe una metodología de diseño sistemática, basada en las técnicas
de UML, la notación de UML y los mecanismos de extensión de UML.
1.14. LENGUAJE UNIFICADO DE MODELADO (U.M.L.)
UML se define como un "lenguaje que permite especificar, visualizar y construir los
artefactos de los sistemas de software". Es un lenguaje notacional (que, entre otras
cosas, incluye el significado de sus notaciones) destinado a los sistemas de
modelado que utilizan conceptos orientados a objetos.
UML es un estándar para construir modelos orientados a objetos. Nació en 1994 por
iniciativa de Grady Booch y Jim Rumbaugh para combinar sus dos famosos
métodos: el de Booch y el OMT (Object Modeling Technique, Técnica de
Modelado de Objetos). Más tarde se les unió Ivar Jacobson, creador del método
OOSE (Object-Oriented Software Engineering, Ingeniería de Software Orientada a
Objetos).
1.14.1. VISTAS DEL UML
En la construcción de software usando UML, existen cinco vistas para

visualizar, especificar, construir y documentar la arquitectura del software.
UML permite representar cada vista mediante un conjunto de diagramas, las
vistas se muestran en la siguiente tabla:
Vistas Descripción
Vista de casos de uso Muestra la funcionalidad del sistema
desde el punto de vista de un actor
externo que interactúa con él. Esta vista
es útil a clientes, diseñadores y
desarrolladores.
Vista de diseño Muestra la funcionalidad del diseño
dentro del sistema en términos de la
estructura estática y comportamiento
dinámico del sistema.
Esta vista es útil a diseñadores y
desarrolladores. Se definen propiedades
tales como: persistencia, concurrencia,
interfaces y estructuras internas a las
clases
Vista de procesos Muestra la organización de los
componentes de código.
Útil a desarrolladores.
Vista de implantación (también Muestra la implantación del sistema en la
conocida como vista de despliegue) arquitectura física.
Útil a desarrolladores, integradores y
verificadores.
Tabla 3: Representación de vistas mediante

diagramas
Fuente: (Booch, Rambaugh, & Jacobson, 1998)
1.14.2. DEFINICIÓN DE MODELO
Un sistema (tanto en el mundo real como en el mundo del software) suele ser
extremadamente intrincado, por ello es necesario dividir el sistema en partes o
fragmentos si queremos entender y administrar su complejidad. Estas partes
podemos representarlas como modelos que describan y abstraigan sus aspectos
esenciales. Un modelo captura una vista de un sistema del mundo real. Es una
abstracción de dicho sistema considerando un cierto propósito. Así, el modelo
describe completamente aquellos aspectos del sistema que son relevantes al
propósito del modelo y a un apropiado nivel de detalle.
Los modelos se componen de otros modelos, de diagramas y documentos que

describen detalles del sistema. El UML especifica varios diagramas. Si
queremos caracterizar los modelos, podemos poner de manifiesto la información
estática o dinámica de un sistema. Un modelo estático describe las propiedades
estructurales del sistema; en cambio, un modelo dinámico describe las
propiedades de comportamiento de un sistema.
Es importante mencionar que el UML es un lenguaje para construir modelos; no

guía al desarrollador en la forma de realizar el análisis y diseño orientado a
objetos ni indica cuál proceso de desarrollo adoptar. Para modelar un sistema es
suficiente utilizar una parte de UML, "el 80 por ciento de la mayoría de los
problemas pueden modelarse usando alrededor del 20 por ciento de UML".
1.14.3. DIAGRAMAS UML

UML es un lenguaje notacional. Parte importante de esta notación son los
diagramas que nos permiten modelar un sistema.
Un diagrama es una representación gráfica de una colección de elementos de

modelado, la mayoría de las veces mostrados como grafo conexo de vértices
(cosas) y arcos (relaciones). Los buenos diagramas hacen el sistema que se está
desarrollando más comprensible y cercano a los objetivos.
En UML se definen nueve diagramas, los cuales se pueden mezclar en cada

vista, ver gráfico 5 y 6.
Figura 5: Diagramas empleados por UML

Fuente: (Booch, Rambaugh, & Jacobson,
1997)
1.14.3.1. DIAGRAMAS ESTRUCTURALES
Los cuatro diagramas estructurales de UML, tabla 2.10, existen para

visualizar, especificar, construir y documentar los aspectos estáticos del
sistema. Están organizados sobre grupos de objetos que se encontrarán
cuando se esté modelando un sistema.
Nombre del diagrama Descripción

Diagrama de clases Un diagrama de este tipo muestra un
conjunto de clases, interfaces, y sus
relaciones
Diagrama de objetos Muestra un conjunto de objetos y sus
relaciones. A diferencia de los diagramas
anteriores, estos diagramas se enfocan en
la perspectiva de casos de uso, y
prototipos
Diagrama de componentes Muestra el conjunto de componentes y
sus relaciones y se utilizan para ilustrar la
vista de la implementación estática de un
sistema
Diagrama de implantación Muestra un conjunto de nodos y sus
relaciones, se usan para ilustrar la vista
de implantación estática de un sistema.
Tabla 4: Diagramas Estructurales

1.14.3.2. DIAGRAMAS DE COMPORTAMIENTO

Los cinco diagramas comportamiento de UML, ver tabla 2.11, son usados
para visualizar, especificar, construir y documentar los aspectos dinámicos
de un sistema. Se puede pensar en los aspectos dinámicos como las
representaciones de las partes cambiantes del sistema
Nombre del diagrama Descripción

Diagrama de casos de uso Muestra el conjunto de casos de uso y
actores (incluyendo sus relaciones). Estos
diagramas se utilizan para ilustrar la vista
del caso de uso del sistema
Diagrama de secuencia Es un diagrama de interacción que
enfatiza el orden en tiempo de los
mensajes.
Diagrama de colaboración Es un diagrama de interacción que
enfatiza la organización estructural de los
objetos que envían y reciben mensajes. El
diagrama de colaboración muestra un
conjunto de objetos, las ligas entre ellos y
los mensajes enviados y recibidos por
dichos objetos.
Diagrama de estado Muestra una máquina de estado,
consistente en estados, transiciones,
eventos y actividades. Estos diagramas
enfatizan el comportamiento.
Tabla 5: Diagramas de Comportamiento

CAPÍTULO 2. JUSTIFICACIÓN DEL PROYECTO
1.1. JUSTIFICACIÓN TÉCNICA

Para el desarrollo del sistema de información web para la venta de boletos se hizo
uso del framework Laravel, el gestor de base de datos se utilizará en MySQL, para la
interfaz gráfica se hará uso de Bootstrap con HTML5 y el lenguaje PHP.
1.2. JUSTIFICACIÓN ECONÓMICA

La implementación de un sistema de información web para la venta de boletos del
cine Vega, permitirá incrementar los beneficios en la empresa, mejorando y haciendo
un manejo eficiente de la información, reduciendo el tiempo de elaboración de
informes.
El sistema de información web permite que las empresas disminuyan las pérdidas
económicas producidas por la falta de clientes por el mal servicio en sus ventas,
tendrán un mejor manejo de la información sobre cómo se distribuirán los horarios,
butacas, pero sobre todo el precio y facturación de los boletos, así el administrador
tendrá un mejor control de estos procesos, también habrá un ahorro en material
usado para la facturación.
1.3. JUSTIFICACIÓN SOCIAL

Las personas adquieren boletos de cualquier evento en la web por varias razones,
comodidad y facilidad de uso, posibilidad de poder comparar espacios a menores
precios, rapidez, eficiencia, placer de la compra en internet, información detallada
sobre los boletos, la ausencia de presión del comprador y el servicio de atención al
cliente es mejor.
El proyecto beneficia de gran manera a los clientes, ya que podrán realizar la

adquisición de boletos para películas mediante la web y pagando con su propia
tarjeta de débito sin la necesidad de tener que ir al cine Vega por la compra o en la
búsqueda de información, también la empresa será beneficiada permitiendo que los
procesos de venta sean mucho más agiles y sencillos, como también poder contar
con un mejor proceso a la hora de tomar decisiones. Esto ayudará a la empresa a
tener más afluencia de clientela por la mejora de los servicios que en primera
instancia no eran de los mejores.
3. CAPÍTULO 3. DISEÑO TEORICO DE LA INVESTIGACIÓN
3.1. PLANTEAMIENTO DEL PROBLEMA

El Cine Vega se enfrenta a un notorio aumento de demanda tanto para adquirir entradas
para el cine como para ingresar a las salas, esto genera insatisfacción en la población al
momento en que quieren adquirir boletos para los estrenos de películas más populares.
Esto genera pérdidas debido a la falta de información acerca de la disponibilidad de las

butacas ya que la población prefiere a la competencia que cuenta con un sistema de
reserva de butacas antes que al cine “Vega” debido a la incertidumbre acerca de la
disponibilidad de butacas que ellos generan.
Por otro lado, se observa que no cuentan con especialistas en el área informática para
solventar estos problemas para generar una respectiva evaluación acerca de cómo
solucionar estos problemas.
3.2. FORMULACIÓN DEL PROBLEMA

Con base en los párrafos precedentes se plantea la siguiente pregunta:
¿Cómo mejorar la venta, reserva y facturación de entradas del cine “Vega”?
3.3. DELIMITACIÓN DEL CONTENIDO

El sistema realizara operaciones en cuanto a los siguientes módulos:
 Módulo venta de boletos.

 Módulo reportes para la facturación de boletos.
 Modulo para el historial de compras del usuario.
 Módulo de gestión de funciones dónde se exhiben las películas.
El sistema tiene límites en cuanto a:
 La actualización de datos de registro de películas en cartelera y horarios será

realizada por el personal autorizado.
 El sistema será implementado para una empresa en particular.
 Se limitará a un idioma (español) para los clientes.
 La actualización de la información será realizada solo por el personal autorizado.
 No realiza control de personal, como ser los horarios de llegada y salida.
3.4. DELIMITACIÓN TEMPORAL

El comenzó en 2 de septiembre de 2019 y concluyo el 12 de diciembre de 2019, en
donde el periodo transcurrido se pudo realizar la recopilación necesaria para su
posterior diseño y desarrollo del sistema de información web para la venta de boletos.
3.5. DELIMITACIÓN ESPACIAL

El sistema de información web para la venta de boletos se desarrolló en la ciudad de La
Paz, situado en la calle Sánchez Lima Nro 1855, Sopocachi.
3.6. OBJETIVOS
3.6.1. OBJETIVO GENERAL

Desarrollar un sistema de información web para la venta, reserva y facturación
de boletos en el Cine “Vega” con código QR en la ciudad de La Paz en la gestión
2019.
3.6.2. OBJETIVOS ESPECÍFICOS

 Desarrollar un módulo para la selección de butacas mediante un mapa de la sala
donde se exhibe la película.
 Desarrollar un módulo para la preventa de boletos para películas próximas a
estrenarse con alertas tempranas.
 Generar el módulo del historial de compras para la impresión de boletos
adquiridos.
 Desarrollar el módulo de selección de horarios y películas para la adquisición de
boletos del Cine Vega.
4. CAPÍTULO 4. DISEÑO O DISPOSITIVO DE PRUEBA
4.1. ARGUMENTACIÓN DEL TIPO DE INVESTIGACIÓN

La presente investigación es de tipo: Descriptiva, porque se analizará los datos
recogidos a través de nuestro instrumento de recopilación para luego procesarlos, que
luego serán explicado.
4.1. DISEÑO DE INVESTIGACIÓN
El diseño de investigación será cuantitativo, ya que se llevará a cabo en los casos en los que
es importante tener conclusiones estadísticas para recopilar información procesable. Los
números proporcionan una mejor perspectiva para tomar decisiones importantes.
4.2. MÉTODOS, TÉCNICAS E INSTRUMENTOS DE INVESTIGACIÓN A

UTILIZAR
Para la recolección de información, se utilizará la adecuada de acuerdo a para el caso.
Para el desarrollo del sistema se utilizará dos técnicas: la entrevista, que a través de esta
técnica se podrá recabar información acerca de los procesos requeridos. Y la técnica de
observación, donde podremos conocer la situación del cine y asi poder recoger la
información relevante para el desarrollo.
CAPÍTULO 5. DESCRIPCIÓN DEL PROYECTO
5.1. LISTA DE REQUERIMIENTOS

Se realizará la respectiva lista de requerimientos en base a las necesidades del Cine Vega a
cubrir con el sistema de información web.
R1. El sistema incluirá un procedimiento de autenticación, en el cual debe identificarse

usando un nombre de usuario y contraseña.
R2. El sistema debe registrar los datos personales, en el caso que no tenga una cuenta de
usuario.
R3. El sistema debe realizar altas, modificaciones y bajas de los usuarios.
R4. El sistema debe incluir la compra/venta de una entrada.
R4.1. El cajero debe efectuar la venta de entradas a los clientes para una o varias
películas, mediante el uso del sistema de información.
R4.2. El cliente podrá efectuar la compra de una o varias películas mediante el uso del
sistema de información accediendo al sitio web del Cine Vega.
R5. El cliente debe poder verificar su historial de compras.
R6. El sistema debe poder emitir facturas.

R6.1. El Administrador del sistema debe poder ver las facturas ya emitidas e
imprimirlas si es que fuera necesario.
R7. El Sistema de Información debe tener la capacidad para administrar las funciones
de cada película y sus respectivas fechas y horas de proyección y finalización de cada
una de las mismas.
R8. El Sistema de Información debe brindar información de cada película que está
disponible en cartelera.
Tabla 1. Lista de requerimientos

Fuente: Elaboración propia
5.2. ANÁLISIS Y DISEÑO
5.2.1. MODELO DE CASOS DE USO

Una vez que se haya realizado la recopilación de los requerimientos y de las necesidades de
la empresa, se realizara la diagramación de los casos de uso, mismo representara la
funcionalidad del sistema. Los casos de uso representan una descripción de las
funcionalidades del Sistema de Información, además se verán acompañadas de su
respectiva historia de usuario según planteado por la metodología Scrum.
En la Figura 40, se observa el diagrama general de casos de uso del Sistema de

Información:
Figura 1. Caso de uso general
5.2.2.1. CASOS DE USO

HISTORIA DE USUARIO
Número: 1 Usuario: Cajero
Nombre de la historia: Inicio de sesión
Prioridad de Negocio: alta Riesgo de desarrollo: media
Puntos estimados: 0.1 Iteración designada: 1
Programador responsable: Mauricio Lima
Descripción:
En la pantalla home se dirigirá hacia la parte superior-derecha donde está el botón de
login para posteriormente introducir los datos de sesión.
Luego el sistema debe validar estos datos.
Validaciones: Si la validación es correcta se redirigirá hacia el dashboard, caso contrario
se redirigirá a la vista anterior.
Tabla 2. Historia de Usuario inicio de sesión
Figura 2. Caso de uso inicio de sesión

HISTORIA DE USUARIO
Número: 2 Usuario: Administrador
Nombre de la historia: Crear nueva función de cine

Programador responsable: Mauricio Lima
Descripción:
Desde el dashboard se deberá dirigir hacia el menú izquierdo para seleccionar
"Funciones"
Luego en la nueva ventana se mostrará en la parte superior un botón para crear una nueva
función. Se abrirá una ventana modal al seleccionar dicho botón en el cuál se deberá
seleccionar la película que se quiere mostrar en la función, así como seleccionar la Sala
en la que se proyectará y la fecha y hora en la que empezará la proyección de la película.
El formulario de creación de nueva función consiste de:
 Lista seleccionable con las películas disponibles
 Lista seleccionable con las salas disponibles
 Fecha y hora de proyección
 Fecha y hora de finalización
Una vez llenado los campos en la parte inferior añadir 2 botones:

 El primero denominado guardar que procederá a crear la nueva función.
 En caso de oprimir el botón cancelar se cerrará la ventana modal.
Validaciones: Se debe validar los campos del formulario al momento de crear la función,
si la validación es correcta se redirigirá hacia el dashboard, caso contrario se redirigirá a
la vista anterior.
Tabla 3. Historia de Usuario crear nueva función de cine
Figura 3. Caso de uso crear nueva función de cine
HISTORIA DE USUARIO
Número: 3 Usuario: Cajero
Nombre de la historia: Venta de boletos
Programador responsable: Erick Mamani
Descripción:
Desde el dashboard se deberá dirigir hacia el menú izquierdo para seleccionar "Ventas"
Luego en la nueva ventana se mostrará una lista de las funciones disponibles vigentes,
entonces seleccionamos una y nos redirigirá a otra pantalla en la cual se mostrará un
mapa de la sala, donde si la butaca presenta un color gris esta disponible, rojo para
ocupado y verde los asientos seleccionados. Así que seleccionamos los asientos deseados
y clickeamos el botón siguiente
En la siguiente ventana se mostrará un formulario en el cual se deberá introducir los
datos del cliente que esta adquiriendo las entradas: NIT o Carnet y Apellido (Si el cliente
no desea proporcionar datos para su factura llenar el formulario con ‘0’ para NIT y “S/N”
para Apellido). Una vez llenados estos datos clickear el botón “Generar factura” que
automáticamente nos devolverá un PDF con la factura lista para imprimir
Validaciones: Se debe validar los campos del formulario al momento de crear la función,
si la validación es correcta se redirigirá hacia el dashboard, caso contrario se redirigirá a
la vista anterior.
Tabla 4. Historia de usuario venta de boletos
Figura 4. Caso de uso venta de boletos

HISTORIA DE USUARIO
Número: 4 Usuario: Administrador
Nombre de la historia: Generar reporte de factura
Programador responsable: Erick Mamani
Descripción:
Desde el dashboard se deberá dirigir hacia el menú izquierdo para seleccionar "Ventas"
Luego en la parte superior derecha se mostrará un botón llamado “Facturas”, el mismo al
clickearlo abrirá una ventana modal con una lista de las facturas ya emitidas mostrando a
la derecha de cada fila un botón para imprimir las facturas y también para solamente
verlas.
Validaciones: Se debe validar la sesión, caso contrario se redirigirá a la vista anterior.
Tabla 5. Historia de usuario generar reporte de factura
Figura 5. Caso de uso generar reporte de factura

HISTORIA DE USUARIO
Número: 5 Usuario: Cliente
Nombre de la historia: Compra de boletos vía Web
Prioridad de Negocio: alta Riesgo de desarrollo: bajo
Programador responsable: Kevin Patón
Descripción:
Se deberá ingresar a la página web del cine www.vega.com.bo, posteriormente dirigirse a
la esquina superior derecha en el apartado de inicio de sesión, que nos redirigirá a la
pantalla de “logueo” en la cual debemos introducir las credenciales del cliente
previamente registrado.
Una vez iniciada la sesión se podrá seleccionar una de las películas que se encuentran en
la página web, y de esa manera ver las funciones disponibles para esa película y
posteriormente seleccionar una.
Esto nos llevara a una pantalla en la que se mostrará el mapa de la sala en la que se
exhibe la función, luego se deberá seleccionar los asientos que se deseen y presionar el
botón siguiente.
En la siguiente pantalla se deberá introducir el código de la factura que emite “Tigo
money” para que posteriormente un administrador pueda validar la misma.
Una vez que el administrador apruebe el código de “Tigo Money” la compra estará
finalizada
Tabla 6. Historia de Usuario compra de boletos vía web
Figura 6. Caso de uso compra de boletos vía web

HISTORIA DE USUARIO
Número: 6 Usuario: Cliente
Nombre de la historia: Acceso a historial de compras
Prioridad de Negocio: alta Riesgo de desarrollo: bajo
Programador responsable: Kevin Patón
Descripción:
Se deberá ingresar a la página web del cine www.vega.com.bo, posteriormente dirigirse a

la esquina superior derecha en el apartado de inicio de sesión, que nos redirigirá a la
pantalla de “logueo” en la cual debemos introducir las credenciales del cliente
previamente registrado.
Una vez iniciada la sesión se podrá acceder en el navbar superior a “Historial de
compras”, en la cual se vera el estado de las compras de un cliente en una tabla.
Tabla 7. Historia de Usuario acceso a historial de compras
Figura 7. Caso de uso acceso a historial de compras

5.2.3. DIAGRAMA DE SECUENCIA
Figura 8. Diagrama de secuencia inicio de sesión

Figura 9. Diagrama de secuencia crear nueva función de cine
Figura 10. Diagrama de secuencia venta de boletos
Figura 11. Diagrama de secuencia generar reporte de factura
Figura 12. Diagrama de secuencia compra de boletos vía web

Figura 13. Diagrama de secuencia acceso a historial de compras
5.2.4. DIAGRAMA DE CLASE DE ALTO NIVEL
Figura 14. Diagrama de clases

5.3. MÉTRICAS DE CALIDAD DEL SOFTWARE

Existe diversos métodos para medir la calidad del software, para el presente proyecto se
seleccionó el estándar ISO/IEC 25010, misma está conformada por un conjunto de seis
características que se desarrollará a continuación:
5.3.1. FUNCIONALIDAD
Para la medición de la funcionalidad se emplea la siguiente formula:
PF ( real )=UFP∗(0,85+ 0,01∗GI )
El proceso para hallar los valores del punto de función UFP y del grado total de influencia
GI explicados en el punto 5.5.1, se procede a reemplazar en la formula dada:
PF ( real )=91∗(0,85+ 0,01∗40)
PF ( real )=113,75
Donde se puede concluir que la funcionalidad del Sistema de Información es

SUFICIENTE, ya que el resultado se encuentra entre los rangos de 100 y 200, en la Tabla
35 se observa la escala de punto de función.
Escala Observación
PF>=300 OPTIMO
200<PF<300 BUENO
100<PF<200 SUFICIENTE
PF<100 DEFICIENTE
Tabla 8. Escala de punto de función
Para calcular el porcentaje de funcionalidad del Sistema de Infromación se calculará con un
valor de 100% y ambos se dividirán.
PF ( esperado )=91∗( 1+ 0,01∗40)

PF ( esperado )=127,4
El porcentaje del punto de función es el siguiente:
PF real
%PF=
PF esperado
113,75
%PF= =0,90
127,4
Por lo que se observa el Sistema de Información desarrollado tiene un 90 % de

funcionalidad.
5.3.2. CONFIABILIDAD
La confiabilidad es la cantidad de tiempo en que el software está disponible para su uso,
definida por la probabilidad libre de fallos que se encuentra en la escala de 0 a 1. La
confiabilidad tiene la siguiente formula:
−λ
( ∗12)
5
F ( t )=Fc∗( e )
Donde:
Fc=¿ Funcionalidad del sistema.
λ=¿ Tasa de fallas en 5 ejecuciones dentro de 1 mes.
Reemplazando los valores en la formula se tiene lo siguiente:
−1
( ∗12)
5
F ( t )=0,90∗(e )
F ( t )=0,08
La siguiente formula es de la probabilidad de no hallar una falla:
1−F (t)
1−0,08=0,92
Por lo que se observa en los resultados, el Sistema de Información presenta una

confiabilidad de 0,92 , dicho de otra manera el 92 % de las ocasiones el Sistema de
Información funciona sin presentar fallas y el 8 % presentan fallas, las cuales no representa
un riesgo en el Sistema de Información.
5.3.3. FIABILIDAD
La fiabilidad es esencial para la reutilización de software, misma tiene la siguiente formula:
¿ errores
Fiabilidad=1−( )
¿ lineas de codigo
Reemplazando valores se tiene lo siguiente:
245
Fiabilidad=1−( )
57792
Fiabilidad=0,99
Por lo tanto se concluye que el Sistema de Información es fiable en un 99 % .
5.3.4. FACILIDAD DE USO

La facilidad de uso es el grado de comprensión que tiene el usuario acerca del
funcionamiento del Sistema de Información, en este punto se realizó una calificación de 0 a
100 %, de acuerdo al nivel de comprensión del usuario (cajero), para ello se evaluó a 5
usuarios (cajero).
Usuarios Facilidad de Facilidad de

comprensión operación
Usuario 1 92,00% 95,00%
Usuario 2 99,00% 92,00%
Usuario 3 95,00% 98,00%
Usuario 4 90,00% 95,00%
Usuario 5 90,00% 98,00%
Promedio 93,2% 95,6%
Total 94,4%
Tabla 9. Resultados de la facilidad de uso del Sistema de Información
De acuerdo a los resultados que se reflejan en la Tabla 36, se concluye que de un 100 % un
94 % del Sistema de Información es comprensible.
5.3.5. CAPACIDAD DE MANTENIMIENTO

La capacidad de mantenimiento es la facilidad con la que una modificación puede
realizarse dentro del Sistema de Información. La facilidad de mantenimiento tiene la
siguiente formula:
TCM =TA+TD +TI + TP
Donde:
TCM =¿Tiempo de capacidad de mantenimiento.
TA=¿Tiempo en el que se analiza la petición de cambio.

TD=¿ Tiempo que se emplea para diseñar una modificación adecuada.
TI =¿ Tiempo necesario para implementar el cambio.
TP=¿Tiempo para probar y distribuir el cambio a todos los usuarios.
5.3.5.1. MANTENIMIENTO CORRECTIVO

El mantenimiento correctivo se realizó durante el tiempo en el que se estaba desarrollando
el Sistema de Información, debido a que constantemente se presenta algún tipo de falla. La
fórmula para el cálculo de corrección del Sistema de Información es el siguiente:
En el mejor de los casos
Los datos se expresan en minutos.
TCM =30+58+74+ 100
TCM =262 minutos=4,36 horas
En el peor de los casos
Los datos se expresan en horas.
TCM =9+11+26+77
TCM =123 horas
El promedio en el que se demora al realizar un mantenimiento correctivo es de 63,68 horas.
5.3.5.2. MANTENIMIENTO ADAPTATIVO

El mantenimiento adaptativo es la facilidad con lo que el Sistema de Información se
acomoda a cambios de su entorno externo, dicho de otra manera, es el cómo se adapta a un
sistema operativo, servidor o a las políticas de la empresa. La fórmula del cálculo de los
tiempos de corrección del Sistema de Información es la siguiente:
En el mejor de los casos
Los datos se expresan en minutos.
TCM =64+ 41+50+112
TCM =267=4,45 horas

En el peor de los casos
Los datos se expresan en horas.
TCM =10+28+61+26
TCM =125 horas
El promedio en el que se demora al realizar un mantenimiento adaptativo es de 64,73 horas.
5.3.5.3. MANTENIMIENTO PREVENTIVO

No se aplicará el mantenimiento preventivo, debido a que el Sistema de Información fue
implementado recientemente, este tipo de mantenimiento se aplica a sistemas que tienen
cierto tiempo de funcionamiento.
5.3.6. PORTABILIDAD
La portabilidad es la capacidad que tiene el producto software para ser usado en lugar de
otro producto software. A continuación, se observa las características más importantes de la
portabilidad:
5.3.6.1. FACILIDAD DE INSTALACIÓN

El Sistema de Información fue desarrollado con el lenguaje de programación PHP y el
gestor de Base de Datos MySQL, mismos no necesitan de licencia, por lo que el sistema
puede ser implementado en el sistema operativo Windows 7 o versiones superiores al
mismo, también puede ser implementado en otro sistema operativo.
5.3.6.2. FACILIDAD DE AJUSTE

Un ajuste se efectúa cuando el sistema no cumpla con los requerimientos o con los
objetivos para el que fue creado. Los ajustes es la creación de un nuevo módulo o el
rediseño de los módulos existentes en el sistema, un ajuste de todo el Sistema de
Información se realizará en un promedio de 30 días hábiles, esto una vez que el mismo
haya pasado por el periodo de adecuación.
5.3.6.3. FACILIDAD DE ADAPTACIÓN

El Sistema de Información se adaptará a los cambios en los registros de la Base de Hechos
y a los cambios que se realizan dentro del mismo. El usuario (administrador) podrá
modificar o agregar las funciones de acuerdo a las películas que se estrenarán en el cine.
En la Tabla 37, se observa los valores obtenidos de las métricas de calidad:
Métricas de calidad
Métrica Valor
Funcionalidad 90%
Confiabilidad 92%
Fiabilidad 99%
Tabla 10. Métricas de calidad
Facilidad de uso del Sistema de94%
Información
Capacidad de mantenimiento 64,74 hrs.
5.4. RESULTADOS ESPERADOS
5.4.1. APORTES
Los aportes del presente proyecto se mencionan los siguientes:
Disminuir documentación física, ya que en el sistema estarán almacenados la

información de los clientes del cine.
Reducción en el esfuerzo al momento de realizar la venta de boletos y asignación de
asientos.
El sistema elabora facturas de una manera más rápida y confiable.
El sistema proporciona una gran ventaja al vender los boletos vía web, lo que
reduce exponencialmente la venta de boletos en boletería de las instalaciones.
5.4.2. IMPACTOS
El presente proyecto tiene un impacto positivo en cuanto a lo siguiente:
Se reduce el tiempo de atención a los clientes al momento de realizar la venta de

boletos.
El sistema efectúa la venta de boletos vía web.
Información del seguimiento en historial de compras del cliente.
5.4.3. OPORTUNIDADES
Con el Sistema de Información se podrá obtener una mejor administración de la
información de las funciones del cine, el cual permitirá al cajero brindar una mejor atención
y realizar la venta de boletos en menos cantidad de tiempo, por lo cual podrán brindar una
venta rápida y eficiente.
5.5. PRESUPUESTO DEL PROYECTO
5.5.1. MODELO COCOMO II

El modelo COCOMO II permite realizar la estimación de costo del software, con el tiempo
ha evolucionado a un modelo más completo que su antecesor COCOMO I. A continuación,
se observa las etapas del modelo COCOMO II:
Funciones de usuario. En la primera etapa están definidos cinco funciones de usuario:

Entradas externas al sistema.
Salidas externas.
Consultas externas.
Ficheros lógicos internos.
Ficheros o interfaces externos.
Para ajustar el modelo en función de la complejidad del proceso, se debe realizar el cálculo
de las funciones de usuario, la cual tiene tres niveles de complejidad que son:
Simple.
Medio.
Complejo.
Tras esta división de las funciones de usuario según su tipo y complejidad se debe aplica un
peso, y de esta manera se obtendrá el total de los puntos de función sin ajustar UFP , que se
observa en la Tabla 38.
Métrica de los puntos de función:
Funciones
Ficheros lógicos internos (ILF) 4
Ficheros de interface externos (EIF) 1
Entradas externas (EI) 3
Salidas externas (EO) 6

Consultas externas (EQ) 4
Tabla 11. Funciones de usuario

Luego se realiza el conteo de las funciones atendiendo el nivel de complejidad:
Para ILF y EIF

Elemen Elementos dato
to
1-19 20-50 51+
registr
o
1 Bajo Bajo Medio
2-5 Bajo Medio Alto
6+ Medio Alto Alto
Tabla 12. Nivel de complejidad de las funciones ILF Y EIF
Para EO y EQ
Tipos Elementos dato
de
1-5 6-19 20+
fichero
0o1 Bajo Bajo Medio
2–3 Bajo Med Alto
io
4+ Medio Alto Alto
Tabla 13. Nivel de complejidad de las funciones EO y EQ
Para EI
Tipos Elementos dato
de
1-4 5-15 16+
fichero
0o1 Bajo Bajo Medio
2-3 Bajo Medio Alto
3+ Medi Alto Alto
o
Tabla 14. Nivel de complejidad de la función EI
Luego se procede a aplicar los pesos asignados a cada nivel de complejidad, que se observa
en la Tabla 42.
Calculo de funciones
Tipo de función Nivel de complejidad Resultados
Bajo Medio Alto
Ficheros lógicos 4 x 7 = 28 __x10 =_ __x15 =__ 28
internos
Ficheros de interface 0x5=5 __x7 =_ __x10 =__ 0
externos
Entradas externas __x3 =__ 3 x 4 = 12 __ x6 =__ 12
Salidas externas __x4 =__ 6 x 5 = 30 __ x7 =__ 30
Consultas externas __x3 =__ 4 x 4 = 16 __ x6 =__ 16
UFP (Puntos de función sin ajustar) = 86
Tabla 15. Pesos asignados a cada nivel de complejidad
La complejidad se ve afectada según el método COCOMO II por catorce características, el
valor asignado a cada característica es el siguiente: (Ver Tabla 43)
0: No presenta o sin influencia
1: Influencia incidental
2: Influencia moderada
3: Influencia media
4: Influencia significativa
5: Fuerte influencia
Característica Peso
Comunicación de datos 2
Procesamiento distribuido de 1
datos
Rendimiento 4
Configuraciones fuertemente 3
utilizadas
Frecuencia de transacciones 3
Entrada de datos online 0
Eficiencia del usuario final 4
Actualizaciones online 4
Procesamiento complejo 3
Reusabilidad 4
Facilidad de instalación 3
Facilidad de operación 4
Instalación en distintos 2
lugares
Facilidad de cambio 3
Tabla 16. Valor asignado a cada característica
Grado total de influencia:
GI =40
Factor de ajuste:
AF=GI∗0,01+ 0,65=40∗0,01+0,65=1,05
Puntos de función ajustados:
FP=UFP∗AF=86∗1,05=90,3
Para hallar la variable KDLC (Kilo-líneas de código), donde FP=90,3 y las líneas por cada
FP equivalen a 64 según la siguiente Tabla 44.
Lenguaje LDC/PF
Ensamblador 320
C 150
Cobol 105
Pascal 91
Prolog/LISP 64
Php 64
Visual Basic.Net 32
SQL 12
Tabla 17. Líneas por cada punto de función
Reemplazando en la formula se obtiene lo siguiente:
KDLC=( FP∗Lineas de codigo por cada FP de Php)/1000
KDLC=( 64∗90,3)/1000
KDLC=5,78
A continuación se procede a hallar la variable FAE , que se obtiene a través de la

multiplicación evaluada en quince conductores de coste que se refleja en la Tabla 45:
CONDUCTORES DE COSTE VALORACIÓN
Muy Bajo Nominal Alto Muy Extra

bajo alto alto
Fiabilidad requerida del 0,75 0,88 1,00 1,15 1,40 -

software
Tamaño de la Base de Datos - 0,94 1,00 1,08 1,16 -
Complejidad del producto 0,70 0,85 1,00 1,15 1,30 1,65
Restricciones del tiempo de - - 1,00 1,11 1,30 1,66

ejecución
Restricciones del - - 1,00 1,06 1,21 1,56
almacenamiento principal
Volatilidad de la máquina - 0,87 1,00 1,15 1,30 -

virtual
Tiempo de respuesta del - 0,87 1,00 1,07 1,15 -

ordenador
Capacidad del analista 1,46 1,19 1,00 0,86 0,71 -
Experiencia en la aplicación 1,29 1,13 1,00 0,91 0,82 -
Capacidad de 1,46 1,19 1,00 0,86 0,70 -

programadores
Experiencia en S.O. utilizado 1,21 1,10 1,00 0,90 - -
Experiencia en el lenguaje de 1,14 1,07 1,00 0,95 - -

programación
Prácticas de programación 1,24 1,10 1,00 0,91 0,82 -

modernas
Utilización de herramientas 1,24 1,10 1,00 0,91 0,83 -

de software
Limitaciones de planificación 1,23 1,08 1,00 1,04 1,10 -

del proyecto
Tabla 18. Calculo FAE, conductores de coste

FAE=1,15∗1,00∗1,00∗1,11∗1,00∗1,00∗1,07∗0,86∗0,82∗0,70∗1,00∗0,95∗1,00∗0,91∗1,08=0,629511536
Esfuerzo estimado:
1,05
E=2,4∗KDCL ∗FAE
E=2,4∗5,771,05∗0,629511536=9,51 hombre−mes
E=10 hombre−mes
Tiempo de desarrollo
T =2,5∗E0,38
0,38
T =2,5∗9,51
T =5,88 meses
T =6 meses
Productividad
PR=KLDC / E
PR=5,7792/9,51=607,69
PR=607,69 lineas /hombre−mes
Número medio de personas:
E
P=
T
P=9,51/5,88=1,61
P=2 hombre
5.5.1.1 COSTO DEL SOFTWARE

Como último paso se obtendrá el costo del producto software, que se expresa de la
siguiente manera:
COSTO SISTEMA=P∗T∗salario minimo(en Bolivia)
COSTO SISTEMA=1,61∗5,88∗2100
COSTO SISTEMA=19.880,28 Bs .
A partir del costo del sistema se obtiene el costo total de desarrollo de software, que se
detallará a continuación:
Costo del Software Precio

Sistema de Información 19.880,28 Bs
Licencia del Lenguaje de Programación (PHP) 0,00 Bs
Licencia del Sistema Gestor de Base de Datos (MySQL) 0,00 Bs
Costo Total del Software en Bolivianos 19.880,28 Bs
Costo Total del Software en Dólares (cambio del dólar actual 6,96 Bs 2.856,36 $us
)
Tabla 19. Costo Total del Software
Como se observa de los datos obtenidos se concluye que el costo total del software ( CSW )
es:
CSW =19.880,28 Bs
5.5.1.2. COSTO DEL HARDWARE

Para el presente proyecto es un Sistema de Información, se necesitará de los siguientes
recursos de hardware, que se describirá en la Tabla 47:
Requisitos Descripción Costo

Microprocesador Intel Core i3 115$us
Tarjeta madre ASUS H81M 55$us
Memoria RAM 4 GB DDRIII 23$us
Tarjeta de video 2 GB GT610 40$us
Disco duro 1 TB 84 $us
Case Delux 53$us
Monitor 19” Samsung 75$us
Teclado y mouse Genius USB 20$us
Impresora Epson 160$us
Cámara web 30$us
Costo total de Hardware en Dólares 655,00 $us
Costo total de Hardware en Bolivianos 4.585,00 Bs
Tabla 20. Costo total de Hardware
Como se observa de los datos obtenidos se concluye que el costo total del hardware ( CHW )
es:
CHW =4.585,00 Bs
5.5.1.3. COSTO DE LA INVESTIGACIÓN

El costo de la investigación hace referencia al material invertido durante todo el proceso de
investigación del presente proyecto, como ser: Papelería, fotocopias, impresiones, entre
otros. En la Tabla 48, se detallará el costo de la investigación.
Material Costo
Papelería 150 Bs
Pasajes 180 Bs
Impresiones 210 Bs
Fotocopias 75 Bs
Costo total del material en Bolivianos 615,00 Bs
Costo total del material en Dólares 87,86 $us
Tabla 21. Costo Total de la Investigación
Como se observa de los datos obtenidos se concluye que el costo total de la investigación
( CIN ) es:
CIN=615,00 Bs
5.5.1.4. COSTO TOTAL DEL PROYECTO

Con los valores obtenidos anteriormente, se determinará el costo total del proyecto, el cual
tiene la siguiente forma:
CTP=CSW +CHW +CIN
Reemplazando los valores, se obtiene lo siguiente:
CTP=19.880,28 Bs+ 4.585,00 Bs+ 615,00 Bs
CTP=25.080,28 Bs ≈ 3.582,89 $ us
Por lo tanto el costo total del proyecto es de 25.080,28 Bs .
A continuación, se detallará el presupuesto total del proyecto, que se observa en la Tabla

49:
DETALLE COSTO
Costo de Software
Costo total de Software en Bolivianos 19.880,28 Bs
Costo total de Software en Dólares 2.856,36 $us
Costo del Hardware
Costo total de Hardware en Bolivianos 4.585,00 Bs
Costo total de Hardware en Dólares 655,00 $us
Costo de la investigación
Costo total de investigación en Bolivianos 615,00 Bs
Costo total de investigación en Dólares 87,86 $us
Costo de servicios Básicos
Costo total de servicios básicos en Bolivianos 600,00 Bs
Costo total de servicios básicos en Dólares 85.71 $us
Costo total
Costo total en Bolivianos 25.680,28 Bs
Costo total en Dólares 3.668,61 $us
Tabla 22. Presupuesto total del proyecto
5.5.2. CALCULO DEL VAN Y EL TIR
5.5.2.1. VALOR ACTUAL NETO (VAN)

El valor actual neto permite calcular el valor actual en cantidad monetaria a partir de
determinados flujos de los ingresos y egresos futuros, originados de una inversión inicial, el
VAN se puede interpretar del siguiente modo:
VAN > 0: Que la empresa genera beneficio.

VAN =0: No hay beneficio ni perdidas, pero si se pierde el tiempo.
VAN < 0: Hay pérdidas en la empresa, además de perder el tiempo.
El VAN tiene la siguiente formula:
n
Ct
VAN =−C 0+ ∑ ¿
t =0
¿¿
Donde:
C = Flujo de caja anual.

n = Cantidad de meses que se planifico para el proyecto.
k = Es la tasa de inversión.
C 0= Inversión inicial.
Para el cálculo del valor actual neto se restará los ingresos de cada periodo con los egresos,
por lo que se obtendrá el flujo de caja que se observa en la Tabla 50:
PERIODO FLUJO DE INGRESOS FLUJO DE EGRESOS FLUJO DE CAJA

Primer mes 6.000,00 1.800,00 4.200,00
Segundo mes 6.500,00 1.500,00 5.000,00
Tercer mes 6.300,00 1.500,00 4.800,00
Cuarto mes 6.500,00 1.900,00 4.600,00
Quinto mes 6.800,00 1.600,00 5.200,00
Sexto mes 7.000,00 1.900,00 5.100,00
Séptimo mes 7.200,00 1.800,00 5.400,00
Total 46.300,00 12.000,00 34300
Tabla 23. Flujo de caja
Reemplazando los datos en la formula con una tasa de retorno del 7% definido por el
Estado Plurinacional de Bolivia se tiene lo siguiente:
PERIODO VALORACIÓN VAN RESULTADO

Mes 0 25.080,28
Mes 1 VA=4.200/(1+0,7)1=4.200/1.07 3.925,23 -21.155,05
Mes 2 VA=5.000/(1+0,7)2=5.000/1.14 4.385,96 -16.769,09
Mes 3 VA=4.800/(1+0,7)3=4.800/1.2250 3.918,36 -12.850,73
Mes 4 VA=4.600/(1+0,7)4=4.600/1.310 3.511,45 -9.339,28
Mes 5 VA=5.200/(1+0,7)5=5.200/1.4025 3.707,66 -5.631,42
Mes 6 VA=5.100/(1+0,7)6=5.100/1.500 3.400,00 -2.231,42
Mes 7 VA=5.400/(1+0,7)7=5.400/1.605 3.364,48 1.133,06
Tabla 24. Tabla del Valor Actual Neto (VAN)

VAN = 1.133,06
Por lo que se observa el VAN es mayor a cero, indica que el proyecto puede aceptarse
puesto que producirá ganancias por encima de la rentabilidad exigida.
5.5.2.2. TASA INTERNA DE RENTABILIDAD (TIR)

Es la tasa interna de retorno es aquel tipo de actualización que hace igual a cero el valor del
capital. El VAN nos informa el beneficio absoluto que se obtendrá del proyecto de
inversión, pero el TIR nos informa de la rentabilidad de la inversión, por lo tanto, es un
indicador relativo al capital invertido.
n
Q0
TIR=−I + ∑ ¿
i=1
¿¿
Donde:
I = Inversión inicial.
Q0= Flujo de caja del proyecto (ingresos menos egresos).
i = Tasa de descuento.
t = Tiempo.
n =Vida útil del proyecto.
El VAN tiene una tasa de retorno del 7% es positivo, el valor del mismo incrementará con
el fin de obtener un valor cercano a cero.
3.925,23
¿¿
TIR=15586,28−15.560,30
TIR=25,96 %
El resultado 25,96 es el que más se aproxima a 0, tendremos un:
TIR=17 %
CONCLUSIONES
Una vez concluido el sistema implementado titulado Sistema de Información Web para la
Venta, Reserva y Facturación de Boletos de Cine con Alertas Tempranas y Código QR, se
logró cumplir el objetivo general planteado en un inicio.
Tomando en cuenta los objetivos previamente planteados se llegó a las siguientes

conclusiones:
 Se facilitó el proceso de venta de los boletos para los clientes al momento de

adquirir boleto(s), disminuyendo el tiempo y dando comodidad de realizarlo
desde cualquier lugar mediante el sitio web.
 Se pudo mejorar el registro de los clientes en salas con sus respectivas
características más relevantes, para mejorar la asignación de butacas.
 El sistema lleva un historial de compras de tal manera que el cliente este
informado sobre los boletos adquiridos
 El sistema controla la adquisición de boletos, generando un reporte de la
cantidad de boletos vendidos.
RECOMENDACIONES
 Se espera que el sistema de información se siga actualizando conforme avance el
tiempo, dándole el mantenimiento adecuado.
 Ejecutar programas de capacitación para que los cajeros puedan usar
adecuadamente el sistema
 Dar publicidad a la pagina web del cine para que esta adquiera renombre además
de confianza entre la población en general.
 Realizar un estudio acerca de cómo aplicar la teoría de colas para así mejorar aún
más la eficiencia en la venta de boletos de cine

BIBLIOGRAFIA
Trigas, M. (2011). Gestión de Proyectos informáticos, metodología Scrum [en línea]

[Consulta: 29 de mayo de 2015].
Pressman Roger, (2006). Ingeniería de software. ed. Mexico, MCGraw-Hill. 968p.

Sommerville, (2005). Ingeniería de software. ed. España. Pearson Addison Wesley.
Patiño Jessit (2014). Sistema de información para una clínica veterinaria con código QR
caso: Clínica veterinaria SERVIVET. Proyecto de grado de licenciatura informática.
Universidad Mayor de San Andrés
Chastian, P. (18 de 05 de 2017). Ingeniería de software [en línea], de

Wikipedia:https://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software, [consulta: el
10 de 06 de 2017]
ANEXOS
1. Pantalla principal de la página web del sistema
2. Funciones disponibles de una determinada pelicula

3. Selección de asientos para la compra de boletos
4. Pago de boletos por código Tigo-Money

5. Modulo salas de cine
6. Modulo Películas
7. Modulo usuarios
8. Modulo Funciones
9. Modulo Ventas

Sistema de Venta de Boletos Online

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Sistema de Venta de Boletos Online

Cargado por

Copyright:

Formatos disponibles

INDICE DE CONTENIDO

Integrantes: Univ. Lima Sillero Mauricio

En los últimos años con el constante crecimiento de la tecnología, se implementan

El crecimiento de la tecnología en cuanto al manejo de la información se ha

Para esta necesidad básica y a la vez principal, de las empresas, el código QR

El uso de páginas web, ha ido generando un consumo excesivo en la sociedad,

1.1. PRESENTACIÓN DEL PROBLEMA DE INVESTIGACIÓN

Los consumidores ya están totalmente acostumbrados a realizar sus compras online

El comercio electrónico o e-commerce consiste fundamentalmente en el desarrollo

En la actualidad el E-Commerce se ha convertido en una herramienta con gran éxito

Gracias al comercio electrónico se puede efectuar casi cualquier transacción sin

Ventajas del comercio electrónico

 Creación de oportunidades de negocio y nuevas formas de distribución de sus

Cine Vega es una empresa boliviana dedicada a la operación de complejos

 Área de Ventas: Encargada del manejo y control de todas las ventas

Grafico 1: Organigrama del Cine Vega

La administración de un cine implica coordinar desde las taquillas, la venta

Autor Titulo Universidad

Tabla 1: Análisis, diseño, desarrollo e implementación de un sistema de

Autor Titulo Universidad

Tabla 2: Aplicación web para la venta de entradas de cine

1.4. SIGNIFICACIÓN TEÓRICA

CAPÍTULO 1. MARCO TEÓRICO

Según Pressman, la ingeniería del software es una disciplina o área de la informática

 Mejorar el diseño de aplicaciones o software de tal modo que se adapten de

Las metodologías de desarrollo de software son marcos o modelos de trabajos que

1.6.1. METODOLOGIA AGIL

Inicialmente, mucha gente asocia metodologías ágiles con falta de

1.7.1. PRINCIPALES CARACTERÍSTICAS

Scrum no requiere ni provee prácticas de Ingeniería. En lugar de eso, especifica

1.8. LAS REUNIONES

Un Sprint es el procedimiento de adaptación de las cambiantes variables del

Un Sprint tiene una duración planificada de entre una semana y un mes. No es

Las actividades que se desarrollan durante el Sprint son: Sprint Planning

En el grafico 3, se pueden ver las prácticas involucradas en un Sprint.

Grafico 2: Ciclo de desarrollo Scrum

1.9.1. DUEÑO DE PRODUCTO (PRODUCT OWNER)

El Dueño de Producto es la única persona autorizada para decidir sobre cuáles

 Canalizar las necesidades del negocio, sabiendo "escuchar" a las partes

Aptitudes que debe tener un Dueño de Producto:

 Excelente facilidad de comunicación en las relaciones interpersonales

1.9.2. SCRUM MASTER

Garantizar la correcta aplicación de Scrum. Esto incluye, desde la correcta

Resolver los conflictos que entorpezcan el progreso del proyecto.

Incentivar y motivar al Scrum Team, creando un clima de trabajo colaborativo,

Aptitudes que debe tener un Scrum Master:

 Excelentes conocimientos de Scrum

El Scrum Team (o simplemente "equipo"), es el equipo de desarrolladores

Scrum comprende las siguientes fases:

Planificación: Definición de una nueva versión basada en la pila actual, junto

Desarrollo de sprints: Desarrollo de la funcionalidad de la nueva versión con

Preparación para el lanzamiento de la versión, incluyendo la documentación

1.10.4. HISTORIAS DE USUARIO

La historia de usuario es una definición de la necesidad del usuario, como un

La Historia de Usuario está escrita en lenguaje coloquial al ser simplemente el

 Potencian la participación del equipo en la toma de decisiones

Un código QR (del inglés Quick Response code, "código de respuesta rápida") es un

1.11.1. CARACTERÍSTICAS GENERALES

Aunque inicialmente se usó para registrar repuestos en el área de la fabricación

Se afirma que no es realmente nueva, ya que se registró originalmente su patente

Sin embargo, la web especializada en creación de Códigos QR, Unitag.io (S.F.)

Los códigos QR también pueden leerse desde computadores personales,

Gracias a los smartphones podemos recuperar la información cifrada de este tipo