INSTITUTO TECNOLÓGICO SUPERIOR

LIBERTADOR “SIMÓN BOLÍVAR”

CARRERA DE SISTEMAS INFORMÁTICOS

SISTEMA WEB PARA EL REGISTRO Y CONTROL DE

VENTAS EN LA TIENDA

PROYECTO DE GRADO PARA OPTAR

EL TÍTULO DE TÉCNICO SUPERIOR
DE SISTEMAS INFORMÁTICOS

POSTULANTE:

TUTOR:

POTOSÍ – BOLIVIA
2023
 Resumen
Los negocios comerciales, actualmente, requieren de un registro sistemático para
evitar la desorganización y pérdida de datos, que son necesarios para regular la
actividad de ventas que se realizan en dichos negocios. El presente proyecto brinda
apoyo sistemático para la realización de un registro y control de ventas para la tienda
“Katsuki Store”, para la organización y mejor manejo al momento de realizar sus ventas
y elaborar un inventario; al ser una página web, los productos podrán ser expuestos
por internet para que la tienda pueda ofrecer sus artículos mediante la red, no
obstante, no se podrá realizar compras de los productos de la tienda “Katsuki Store”
por internet.
Esta tienda está ubicada en la ciudad de Llallagua, misma que se dedica al comercio
de artículos provenientes y comercializados en el continente Asiático; ofreciendo
productos a niños, jóvenes y adultos que tienen interés sobre esta interesante cultura.
El sistema desarrollado busca dar publicidad a la tienda “Katsuki Store”, mejorar el
manejo y control de sus ventas y poner a la población en conocimiento de los artículos
que se ofrecen mediante una página web, a la cual podrán acceder todas las personas
que lo deseen o tengan curiosidad sobre los artículos.
Para la realización del sistema se hizo manejo de la metodología OOHDM (Método de
Diseño Hipermedia Orientado a Objetos), metodología necesaria para el desarrollo del
proyecto. Las herramientas informáticas actuales como ser: Mysql, Xampp, Star UML y
Visual Studio Code fueron incluidas para la realización del sistema web, ayudando en
el desarrollo del mismo, todo con el fin de manejar un sistema web que cumpla con las
exigencias que se requieren.
 CAPÍTULO I
MARCO INTRODUCTORIO
1.1 Introducción:
Las tiendas comerciales requieren de mucha dedicación, ya que se cuenta con mucha
competencia al momento de querer sobresalir, es por eso que, en la actualidad, con el
desarrollo y expansión de la tecnología, muchos buscan ofrecer sus productos
mediante internet para expandir su negocio y así lograr tener reconocimiento en el
mundo del comercio. Además, los sistemas de información están basados en
computadoras que son objetos de gran consideración en la toma de decisiones
oportunas, confiables y efectivas en cuanto a técnicas de planificación, programación y
administración con el fin de garantizar su éxito, reducir costos y riesgos e incrementar
las ganancias.
El proyecto pretende lograr que todos los artículos que ofrece la tienda “Katsuki Store”
sean registrados y controlados correctamente, evitando así la desorganización y mal
manejo de sus productos, teniendo un buen inventario que se acomode a las
necesidades de la propietaria de la tienda; también se podrá ofrecer los productos
mediante la red y así controlar los servicios que se ofrece, las novedades y los
descuentos que puedan existir; exponiendo mediante la página web todos los artículos
que están disponibles en la tienda “Katsuki Store”.
Usando Visual Studio Code como uno de los programas principales para la realización
del sistema y con la obtención de los datos de cada producto y artículo que ofrece la
mencionada tienda, se dará un apoyo sistemático para la expansión del negocio
mediante internet, también regulando el registro de ventas que se efectúa en la tienda,
para que el administrador o administradora tenga un registro sobre cada artículo que
hay, a los que más recurre la clientela, los artículos más buscados y los ingresos
diarios y mensuales que se hace en el establecimiento.
El desarrollo del presente proyecto fue a causa de la necesidad que se tiene, ya que se
pudo observar que la administración de los productos de esta tienda es muy irregular y
no cuenta con algún método para registrar cada artículo, dando como resultado
pérdidas y robos en el lugar, se tiene registro de algunos productos, pero no se tiene
registrada la cantidad exacta ni los precios de adquisición y venta, por este motivo se
vio la necesidad de crear el sistema web.
 Para la elaboración del sistema actual se recopilarán datos de la tienda “Katsuki Store”
para crear un sistema acorde al ofrecimiento de productos del mismo, tendrá un
acceso por medio de la web para exponer los productos y ampliar el comercio del
lugar, además de dar a conocer a más gente sobre la existencia de dicha tienda y
sobre los productos que se llega a ofrecer.
Por otro lado, tendrá un acceso para observar el costo de cada producto y la cantidad y
detalle de cada uno para hacer el registro correspondiente a la hora de vender los
accesorios.
La parte estética del sistema irá enfocado a la temática del anime, mostrando
accesorios y logos que sean acorde a los productos expuestos en el establecimiento
comercial, es por eso que se denotará temas como el k-pop, anime, mangas y demás
que son los referentes de la cultura asiática y muchos de los productos puestos a venta
en el lugar.
1.2 Antecedentes
1.2.1 Antecedentes de la tienda “Katsuki Store”:
La tienda Katsuki Store abrió sus puertas a la población hace casi dos años atrás,
ubicándose a pocos pasos de la calle Linares, mismo lugar desde la apertura del
negocio. Cuenta con varios artículos asiáticos a la venta, como ser: Conservas de una
variedad de marcas de Corea y Japón, figuras de colección, cosplay de personajes de
animes, mangas, gabardinas referidas al anime, ropas con bordados y sublimados
referentes al anime, posters de personajes anime y artistas famosos del género k-pop,
almohadas, cojines, etc. También realiza pedidos por mayor y menor de los productos
que ofrece y adicionalmente realiza productos personalizados.
El registro de los ingresos económicos se realiza de manera manual, (usando un
cuaderno y un bolígrafo) en el cuál se anota la fecha y los productos que se venden por
día, también se hace registro de los pedidos por mayor y menor en el mismo cuaderno,
dando como resultado alguna serie de inconvenientes al momento en que el vendedor
rinde cuentas a la propietaria de la tienda.
El precio de cada producto se encuentra en una lista realizada manualmente, lista a la
cual se accede desde el mismo cuaderno de registro de ventas, de la misma forma por
medio de ese registro manual se puede anotar si se necesitan algunos artículos de
novedad o algunos productos que estén siendo buscados por los clientes.
El registro del inventario muchas veces es corregido por la propietaria para actualizar
los precios de cada producto, lo que ocasiona sobre escritos ilegibles que pueden
llegar a confundir al personal de la tienda o a la misma propietaria al momento de
revisar el costo de los productos. En dicho registro no se cuenta con todos los
productos enlistados a cabalidad, muchos artículos solo tienen anotados los precios en
sus empaques y no están registrados en la lista, lo que ha ocasionado robos y pérdidas
al cambiar de personal; al obtener nuevos productos la propietaria tampoco realiza el
registro de la adquisición actual, solo lo menciona al personal sin dar la cantidad
específica de los productos obtenidos, mencionando solo el precio con el que saldrá a
la venta.
Dentro de los artículos que salen a la venta existen anillos, collares y productos de
tamaño pequeño que pueden ser objeto de robo y nadie puede darse cuenta ya que en
el registro no se cuenta con la cantidad específica de cada artículo y algunos ni
siquiera se encuentran registrados en ese cuaderno, dando así una irregularidad que
ocasiona pérdida de ganancias para la propietaria.
1.2.2 Antecedentes de proyectos anteriores:
Frente a los antecedentes de proyectos anteriores realizados con el fin de controlar las
ventas y realizar inventario, se pudo encontrar distintos sistemas web realizados por
distintos estudiantes de distintas universidades. Por lo cual se mencionará a algunos
que se asemejen al sistema desarrollado en el presente proyecto.
Sistema web de control de ventas e inventarios caso: Michelline realizado por Patricia
Aduviri Perez en el año 2016. El proyecto fue realizado con el uso de la metodología
XP (Extreme Programming) y la utilización del lenguaje de programación PHP con el fin
de satisfacer las necesidades que se requerían en la elaboración del sistema, también
usando el gestor de base de datos MySQL.
Aplicación web para el registro y control de compras, ventas e inventarios caso
Asociación de productores en metalmecánica sur “Metal Sur” elaborado por Hugo
Hernán Aquino Achumiri en el año 2018. En este proyecto se diseña y desarrolla un
sistema que permite hacer el control de compras, ventas e inventario de la Asociación
ya mencionada anteriormente, haciendo el uso de la metodología de Desarrollo Ágil
XP.
Los sistemas mencionados anteriormente tienen algo en común, son sistemas
desarrollados para el control de ventas, que es una de las necesidades que se busca
 satisfacer con el presente proyecto, para facilitar el manejo de los ingresos que tiene la
tienda “Katsuki Store” y de esta manera mejorar la atención del mismo evitando varias
consecuencias negativas que podrían afectar a la propietaria.
1.3 Descripción del sistema actual:
Este sistema desarrollará un registro de inventario de todos los productos de la tienda
“Katsuki Store”. El acceso al sistema por parte del administrador será completa, podrá
añadir/eliminar/editar a los usuarios que son parte del personal de ventas y podrá
añadir/eliminar/editar los productos ofertados y los precios respectivos de cada artículo.
El personal podrá realizar el registro de las ventas diarias y registrar los reportes que
sean necesarios dentro del sistema, también tendrá acceso al registro de ventas donde
podrá realizar las gestiones necesarias dentro del transcurso de día de venta.
Los clientes vía internet podrán ver las ofertas de la tienda, mas no podrán realizar
compras por internet de los productos; tendrán acceso a la información de contactos
para dar a conocimiento de las promociones y actividades que tenga la tienda.
1.4 Planteamiento del problema:
La tienda “Katsuki Store”, que se encuentra en la localidad de Llallagua, como ya se
mencionó, tiene un control de ventas inseguro al ser manipulado de forma manual
(mediante la manipulación de un cuaderno y un bolígrafo) ya que puede llegar a
extraviarse o dañarse por algún acontecimiento, es por eso que se plantea la siguiente
pregunta:
1.4.1 Formulación del problema:
¿Cómo mejorar el registro y control de ventas para la tienda “Katsuki Store” de manera
que se tenga un mejor manejo de la información?
1.5 Definición de objetivos:
El resultado futuro que se busca en este proyecto es con la finalidad de lograr obtener
un sistema web que mejore el manejo de la información de los productos que
pertenecen a la tienda “Katsuki Store”, por esta razón se definirán los objetivos que
contribuirán con el desarrollo del proyecto.
1.5.1 Objetivo general:
Elaborar un sistema web de registro y control de ventas para la tienda “Katsuki Store”,
para tener un mejor manejo de la información.
1.5.2 Objetivos específicos:
* Hacer recopilación de documentos para profundizar en el tema de elaboración de un
sistema web de registro y control de ventas.
* Recopilar los datos necesarios sobre los productos, formando un inventario de todos
los artículos que se encuentran a la venta.
*Recaudar información para que la elaboración del sistema web sea acorde a las
expectativas de la propietaria de la tienda “Katsuki Store”.
* Obtener datos de los precios de cada producto y su cantidad actual, cotizando las
ganancias al realizar una venta.
* Desarrollar e implementar una base de datos relacional.
*Ofrecer, mediante el sistema web, todos los productos de manera organizada dando
referencias sobre la tienda y hacer que el sistema pueda ser accesible para todas las
personas por medio del internet para que la tienda ofrezca sus productos.
1.6 Justificación
1.6.1 Justificación técnica:
El sistema mejorará el acceso a los datos que requiere la tienda, además, al tener las
herramientas tecnológicas necesarias para la implementación del sistema web, tiene la
posibilidad de implementarlo para hacer un control más efectivo evitando perjudicar de
cualquier manera tanto al personal de ventas como al administrador de la tienda. El
sistema podrá manejar los datos de los productos de manera precisa, confiable y
eficiente para evitar la confusión o errores que puedan existir.
1.6.2 Justificación económica:
La implementación del sistema de información se realizará con software libre, además
la tienda cuenta con el hardware necesario para implementar este sistema, por lo que
no incurrirá a un gasto adicional. Con el desarrollo de este proyecto, el personal de
ventas de la tienda “Katsuki Store” realizará sus tareas cotidianas con mayor
comodidad y facilidad, posibilitando una mayor eficiencia en ellos.
1.6.3 Justificación social:
Este proyecto se realizará debido a la necesidad que tiene la tienda “Katsuki Store” de
manejar el registro de sus productos y venta de los mismos de manera eficaz y
eficiente, ya que se tiene mucha dificultad a causa de la manipulación del registro
manual, llegando en momentos a cometer equivocaciones al momento de ofrecer sus
productos, ya sea por el precio, o mayor aún, la disposición de los productos
existentes; es por esto que se busca facilitar el buen control y seguimiento y de esta
 forma mejorar la atención hacia el cliente y obtener el orden en relación a todos los
artículos pertenecientes a la tienda.
El contar con un gestor de inventario permitirá que el personal sea informado de los
diversos productos con los que cuenta el punto de venta, además tengan la
oportunidad de acceder y conocer el costo y características reales de los productos;
herramientas importantes con la que mejorará el desempeño dentro la tienda con
ayuda de formatos interactivos, además de los diferentes aspectos de negocios como
son el precio, la categorización de los productos y servicios.
1.7 Alcances y límites
1.7.1 Alcances:
Los alcances para el registro y control de ventas serán los siguientes:
 Se restringirá el acceso a ciertas áreas donde solo el personal autorizado tendrá
acceso.
 Se desarrollará una interfaz para el registro de productos.
 Se desarrollará una interfaz par el registro de clientes.
 El sistema efectuará el registro de las ventas que se realicen.
 Se podrá mostrar el stock de los productos.
 Se podrá activar o desactivar el acceso de los usuarios al sistema.
 Se podrá realizar reportes de ventas y productos.
1.7.2 Límites:
El sistema se limita a las siguientes excepciones:
 El sistema no posee un sistema de facturación.
 La actualización de datos será realizada por el personal autorizado.
 El sistema no contará envió de correos.
 El sistema no realizará compras por internet.
 El sistema no realizará el control del personal.
 CAPÍTULO II
MARCO TEÓRICO
2.1 Introducción:
El marco teórico, tiene el propósito de dar a la investigación un sistema coordinado y
coherente de conceptos y proposiciones que permitan abordar el problema. De este
modo, el fin que tiene el marco teórico es el de situar el problema que se está
estudiando dentro de un conjunto de conocimientos, que permita orientar la búsqueda
y ofrezca una conceptualización adecuada de los términos que se utilizaran en el
trabajo (Ana, 1997).
Entonces para conocer el sentido del proyecto es necesario saber algunos aspectos
fundamentales, como la incursión de las tecnologías de la información y la informática
en los pequeños negocios y, por otro lado, el uso de las aplicaciones web como
herramienta indispensable para el desarrollo de diferentes actividades dentro de un
emprendimiento de comercio.
2.2 Definiciones generales del sistema:
Dentro de la respectiva documentación es necesario desarrollar las definiciones
necesarias para la comprensión del presente proyecto y la finalidad que esta persigue,
de esta manera poder aclarar cualquier duda y evitar cualquier inconveniente en el
desarrollo del sistema; de esta manera se desarrollará las siguientes definiciones.
2.2.1 Software de registro de ventas:
Es necesario dar una definición sobre este sistema ya que el proyecto abordará el
tema del registro de ventas como una base para su elaboración. Douglas da Silva
(2022) refiere que el software de registro de ventas es un sistema que te permite reunir
en un solo lugar toda la información sobre la comercialización de tus productos y
servicios. Su objetivo es simplificar el acceso a los datos, aumentar la visibilidad del
embudo de ventas y mejorar la productividad del equipo. Por esta razón se necesita
recabar toda la información del inventario para lograr tener un registro acorde a los
productos que están siendo ofrecidos.
2.2.2 Desarrollo web:
Se hace referencia a desarrollo Web, como el conjunto de tecnologías de software del
lado del servidor1 y del cliente2 que sirven para la realización de determinadas tareas o
simplemente mostrar información a través de una aplicación informática. Proceso de
creación y mantenimiento de páginas web, generalmente para ser parte de un sitio web
disponible en la WWW. La o las personas encargadas de esta tarea son llamadas
desarrolladores o webmasters3.
Desarrollo web significa construir y mantener sitios web, es el trabajo que tiene lugar en
un segundo plano y que permite que una web tenga una apariencia impecable, un
funcionamiento rápido y un buen desempeño para permitir la mejor experiencia de
usuario. Los desarrolladores web son como duendes con poderes: nunca los ves, pero
son los que hacen que todo esté bien y funcione de manera rápida y eficiente
(Mercedes, 2017).
2.2.3 Página web:
Documento realizado en HTML (Hyper Text Markup Language o Lenguaje de Marcado
de Hipertexto) y que es parte de un sitio Web. Aparte de HTML se pueden utilizar otros
lenguajes complementarios como PHP, [Link], JPS, etc. Una página web puede
llevar una serie de contenidos como texto, sonido, video y demás, que podrá ser
observada mediante un navegador.
Las páginas web son hoy en día un medio de comunicación global a las necesidades
requeridas por las personas que navegan por internet, tener un sitio web es la principal
herramienta del siglo XXI para la comunicación, y muchas veces para la interacción
personal, sobre todo a través de las denominadas redes sociales que produjeron una
modificación importante y rápida en el modo y forma de relacionarnos (Nass De Ledo,
2012).
2.2.4 Sistemas de información web.
Es un tipo de dato emergente de sistema de información que incorpora la tecnología
Web y la red global de Internet; van más allá de un conjunto de páginas Web ya que

1 Servidor: En Informática, es un computador que, formando parte de una red, provee servicios a otras
computadoras denominadas clientes.

2 Cliente: Es una aplicación informática o un computador que consume un servicio remoto en otro
computador, conocido como servidor, normalmente a través de una red de telecomunicaciones.
3 Persona responsable del desarrollo, correcto funcionamiento y mantenimiento de una página web.
soportan el trabajo colaborativo y usualmente está estrechamente integrado con otros
sistemas, tales como bases de datos. Salisbury (1996).
En un ámbito empresarial, el desarrollar y utilizar aplicaciones web para sus procesos
de negocio son de gran importancia, ya que estos tipos de aplicaciones permiten una
comunicación activa entre los usuarios y la información accedida por ellos; por esta
razón el acceso a la información se hace de modo interactivo, esto quiere decir que
una página responde a cada petición hecha por los usuarios de manera individual
accediendo a la información de una manera centralizada.
Hasta ahora, en la web el tipo de registro dominante es el documento, ese documento
adopta típicamente la forma de la página web con la que, a día de hoy, una
considerable parte del mundo ya está familiarizada. Pero no únicamente, porque en la
web actual, se puede navegar entre una variedad amplísima de formatos
documentales.
La cuestión es que la web es capaz de aportar información a personas de todo el
planeta para casi cualquier clase de actividad útil y constructiva que estén llevando a
cabo (el lado oscuro consiste en que los interesados en actividades destructivas por
desgracia también suelen usar la web, pero esto es otro problema) (Marcos, 2009).
Los sistemas de información contienen información de los procesos de entrada,
almacenamiento, procesamiento y salida; actividades básicas que producen la
información que se necesita para su funcionamiento óptimo.
2.2.5 Base de datos
Una base de datos es una colección de información organizada de tal modo que sea
fácilmente accesible, gestionada y actualizada. En una sola vista, las bases de datos
pueden ser clasificadas de acuerdo con los tipos de contenido. (Enzo, Augusto)
La información en la base de datos a veces se clasifica de acuerdo a su enfoque
organizativo; el enfoque más frecuente es la base de datos relacional.
Una base de datos puede ser de diverso tipo, desde un pequeño fichero casero para
ordenar libros y revistas por clasificación alfabética hasta una compleja base que
contenga datos de índole gubernamental en un Estado u organismo internacional.
(VALLE, s.f.)
[Link] Base de datos relacional:
La base de datos relacional (BDR) es un tipo de base de datos (BD) que cumple con el
modelo relacional (el modelo más utilizado actualmente para implementar las BD ya
planificadas). (Rouse,).
Una base de datos relacional es básicamente un conjunto de tablas, similares a las
tablas de una hoja de cálculo, formadas por filas (registros) y columnas (campos). Los
registros representan cada uno de los objetos descritos en la tabla y los campos los
atributos. En el modelo relacional de base de datos, las tablas comparten algún campo
entre ellas. Estos campos compartidos van a servir para establecer relaciones entre las
tablas que permitan consultas complejas.
[Link] Base de datos no relacional:
También llamado NoSQL es un sistema de almacenamiento de información que se
caracteriza por no trabajar con estructuras definidas, por lo que la información no se
organiza en campos o registros y los datos tampoco se almacenan en tablas como lo
hace la base de datos relacional. Además, no usa el lenguaje SQL como herramienta
de consultas, solo como apoyo, es por ello que lo nombran No SQL.
Esta base de datos está pensada para la gestión de grandes volúmenes de datos por
lo tanto deja a un lado el uso de tablas, de esta forma cada elemento se guarda en
documentos que ya tienen incluidos todos sus atributos. Frente a sus características
también presenta distintos tipos de base de datos no relacionales como ser: Clave-
valor, documentos, en memoria y gráficos.
2.6 Funcionalidad del sistema
Es un método para cuantificar el tamaño y la complejidad del sistema en términos de
las funciones que se esté desarrollando. Se centra en la funcionalidad o utilidad del
programa.
Se puede valorar con una medida llamada punto función. Los puntos de función se
computan determinando cinco características de dominio de información que se define
a continuación.
1. Número de entradas de usuario.
2. Número de salidas de usuario.
3. Número de peticiones de usuario.
4. Número de archivos.
5. Número de interfaces externas.
Una vez que se han recopilado los datos anteriores, a la cuenta se asocia un valor de
complejidad.

2.6 Uso de la metodología de desarrollo web:

La web permite desarrollar otras capacidades y satisfacer otros servicios en el ámbito
de los sistemas informáticos, de este tema se valen personas que no necesitan tener
un aplicativo instalado en un computador, permitiendo mayor movilidad y acceso desde
cualquier parte y no depender estrictamente de un sistema operativo en el que la
aplicación se ejecute; en pocas palabras el punto decisivo es el acceso a la
información independiente de la ubicación del usuario.
El alcance de la aplicación y el tipo de usuarios a los que estará dirigida son
consideraciones tan importantes como las tecnologías elegidas para realizar la
implementación. Así como las tecnologías pueden limitar la funcionalidad de la
aplicación; decisiones de diseño equivocadas, también pueden reducir su capacidad
de extensión y reusabilidad. Es por ello que el uso de una metodología de diseño y de
tecnologías que se adapten naturalmente a ésta, son de vital importancia para el
desarrollo del sistema. (Darío Andrés Silva, 2001).
2.7 Metodología OOHDM (Object-Oriented Hypermedia Design Method)
El uso de una metodología de diseño es de vital importancia para el desarrollo de
aplicaciones web. OOHDM, viniendo a significar: Método de Diseño Hipermedia
Orientada a Objetos, es una metodología que se enfoca en el proceso incremental,
iterativo y que se basa en prototipos y tiene como objetivo simplificar y a la vez hacer
más eficaz el diseño de aplicaciones hipermedia.
En sus comienzos no contemplaba la fase de captura de requisitos, pero en la
actualidad propone el uso de UID´s (User Inteaction Diagrams). Esta propuesta parte
de los casos de uso que se considera una técnica muy difundida, ampliamente
aceptada y fácilmente entendible por los usuarios y clientes no expertos igualmente,
resalta la necesidad de empezar el diseño del sistema, especialmente en los entornos
web, teniendo un claro y amplio conocimiento de las necesidades de interacción o lo
que es lo mismo de la forma en la que el usuario va a comunicarse con el sistema.
(Vilain, P.,, Schwabe, D., & de Souza)
Por último, decir que OOHDM no es una propuesta estática. En la actualidad está
siendo mejorada y enriquecida. A partir del refinamiento del método OOHDM, se
formula uno nuevo, que se denomina “Método de Diseño de Hipermedia Orientado
Objetos - Mejorado” o presentado de manera resumida como “OOHDM+” en la cual las
falencias identificadas en el método original quedan eliminadas en OOHDM+, está
orientado al diseño de sitios web corporativos. (Mamani, M. & Mamani Villavicencio).
2.7.1 Etapas de la metodología OOHDM
Como se mencionó anteriormente, la metodología OOHDM presenta cinco etapas para
su desarrollo, de esta manera podrá elaborarse un sistema con las herramientas
necesarias y pasos adecuados para obtener el resultado deseado; las etapas
planteadas por esta metodología son mencionadas en la siguiente figura:

Diseño Conceptual

Obtención De Diseño Navegacional

Requisitos Implementación

Diseño de Interface

Figura 1. Etapas de la Metodología OOHDM

Fuente: (Valparaiso, s.f.)
En la Tabla 2 se presenta un sumario de la metodología OOHDM describiendo los
productos, mecanismos e interés de diseño que se utilizan en cada fase haciendo un
desglose detallado de cada etapa para un mejor entendimiento.

ACTIVIDADES PRODUCTOS MECANISMOS INTERÉS DEL DISEÑO

Obtención de Casos de uso, Escenario y análisis de Modelo gráfico que representa

Requisitos anotaciones. Casos de uso. el intercambio de Información
Entrevistas, Diseño de entre el usuario y el sistema.
UIDs para el modelo
conceptual.

Modelo Clases, subclases, Clasificación, Modelo semántico de la

relaciones, composición,
 Conceptual perspectivas de agregación, aplicación.
atributos. generalización y
especialización.
Diseño Nodos, Enlaces,
Clasificación, Considere el perfil del usuario.
Navegacional estructura de
composición, Establecer los recorridos que
acceso, contexto de
agregación, el usuario puede seguir por la
navegación,
generalización y aplicación.
transformación de la
especialización.
navegación.
Diseño de Navegación y los Modelado de los objetos
Objetos de interfaz
Interfaz objetos visibles. perceptibles por el usuario y de
abstracta, respuesta a
Abstracta cómo afecta a la aplicación los
eventos externos,
eventos externos.
transformaciones de
interfaz.

Implementación Aplicación ejecutable. Se realiza la puesta en

Estos proporcionados producción del sistema.
por el ambiente y los
ofrecidos por el
lenguaje.
Tabla 1. Metodología OOHDM.
Fuente: Gustavo Rossi y Daniel Schwabe. (2002)
[Link] Obtención de requerimientos:
Ésta es una de las fases más importantes y el primer paso, debido a que es aquí donde
se realiza la recogida de datos de los usuarios directamente involucrados y sus tareas
que ellos realizan. La etapa de captura de requisitos propone la especificación de
escenarios de uso, casos de uso y diagramas de interacción de usuarios (UID, User
Interaction Diagram). El UID utiliza una notación propietaria y representa la interacción
entre el usuario y la aplicación.
Esta actividad de levantamiento de requisitos define cuales son los usuarios de la
aplicación que se desarrolla y las tareas que deberán ser apoyadas. Estas actividades
se subdividen en las siguientes tareas. iVilain & Schwabe (2002)
a) Identificación de Actores y Tareas: En esta etapa se identifican los principales actores
que interactúan en el desarrollo del proyecto y sus respectivas tareas a realizar, ya que
este será el punto de inicio para diseñar los escenarios. (Schwabe, "Notación del
Método OOHDM"., 2002).
• Actor o rol: Es un agente que interactúa con el sistema. Es decir, un tipo de
usuario con un papel definido, así el actor puede representar diversos papeles y un
papel puede ser representado por varios actores. Por tanto, un actor o un rol es una
clase de usuario.
• Tarea: Representa un objetivo que el usuario desea alcanzar utilizando el
sistema.
En la Clasificación e identificación de roles se hace uso del modelo de entrevistas y
cuestionarios. La entrevista es una técnica muy utilizada puesto que permite conseguir
un mejor entendimiento del problema y por lo tanto de las posibles soluciones. Es
importante que las preguntas estén muy bien planteadas para poder conseguir un
acopio más preciso de los requerimientos que el sistema debe satisfacer.
b) Especificación de escenarios: Un escenario es una descripción narrativa que
explica detalladamente las tareas que un usuario debe realizar en el dominio.
c) Especificación de casos de uso: Un caso de uso es una manera de usar el
sistema. Los casos de uso tratan la interacción del usuario con el sistema sin abordar
el funcionamiento interno del sistema. Un caso de uso no representa lo mismo que un
escenario, pues representa un conjunto de potenciales escenarios que tratan una
misma tarea. Los casos de usos son historias o casos de utilización de un sistema.
La especificación de casos de uso se la realiza utilizando una plantilla de especificación
de casos de uso Soto &Palma (2004). Esta plantilla muestra las acciones o peticiones
que realiza el usuario y las respuestas de parte del sistema según la tabla 4.

Nombre Iniciar sesión

Actor Usuario administrador

Propósito El actor se autentifica

 Resumen En este módulo se debe ingresar los datos para su verificación para
una posterior autentificación.

Evento del actor Evento del sistema

Flujo Principal El actor selecciona el LINK El módulo muestra el formulario de

de inicio de sesión. inicio de sesión.
El actor ingresa su usuario y El módulo muestra el formulario de
su password. inicio de sesión.

Pre_Condición Estar en el formulario de inicio

Pos_Condición Estar en el menú principal de la página de inicio con sesión.

Tabla 2. Plantilla para la especificación de casos de uso.

Fuente: (Vilain, P., Schwabe, & de Souza, 2000)
d) Especificación de UID´s: un diagrama de interacción del usuario o UID´s, muestra la
interacción entre el usuario y un sistema descrito en el texto del caso de uso, describe
el intercambio de información entre el usuario y el sistema, sin entrar en detalles
relativos a la interfaz con el usuario. Se define un UID´s para cada caso de uso.
[Link] Diseño conceptual:
Durante esta actividad se lleva a cabo un esquema conceptual representado por los
objetos del dominio, las relaciones y colaboraciones existentes establecidas entre ellas.
El diseño conceptual hace referencia a la construcción del modelo conceptual del
dominio de la aplicación, utilizando para ello notación UML. OOHDM define en esta
etapa el comportamiento de la aplicación, especificando cada uno de los objetos del
dominio. El esquema conceptual está constituido por clases, relaciones y subsistemas.
Las clases descritas como en los modelos orientados a objetos con el UML.
 Figura 2. Modelo Entidad Relación.
Fuente: (Peter Chen , 1976)
[Link] Diseño navegacional:
Es la fase en que se plantea la manera de ¿cómo será? la navegación del usuario en el
hiperdocumento. Los sitios web y las aplicaciones hipermedia son aplicaciones
proyectadas para la navegación a través de un espacio de información. La fase anterior
de OOHDM (modelo conceptual), propone la construcción de un modelo conceptual en
el cual describe las clases de objetos y relaciones del dominio de la aplicación. De este
modelo conceptual se pueden originar varios modelos navegacionales, es decir, la
información que será presentada a los usuarios y como se efectuará la navegación
entre ella. (Hennrichs , 2005).
En esta metodología, la navegación es considerada un paso crítico en el diseño de
aplicaciones.
En esta fase la metodología esta subdividida en las siguientes sub fases. (Mamani, M.
& Mamani Villavicencio).
a) El esquema de clases del modelo navegacional por orientación:
En OOHDM, existe un conjunto de tipos predefinidos de clases navegacionales, nodos,
enlaces y estructuras de acceso. La semántica de los nodos y los enlaces son las
tradicionales de las aplicaciones web y las estructuras de acceso, tales como índices
recorridos o guiados, representan los posibles caminos de acceso a los nodos, este
esquema está definido por un diagrama conformado por nodos y enlaces similares al
esquema conceptual.
Con la finalidad de reducir el nivel de complejidad y ambigüedad en los elementos que
conforman el esquema de clases navegacionales, OOHDM plantea una representación
mucho más comprensible para el usuario según la figura 12 (German, D. , 2003), por lo
que este tipo de modelos debe ser sencillo y fácil de entender.

MENÚ PRINCIPAL

SUMARIO REPORTAJE JORNALISTAS

MATERIA POR REPORTAGE PERSONA

ALFABETICA
Figura 3. Representación de modelo navegacional – mejorado
Fuente: (Schwabe, "Notación del Método OOHDM"., 2002)
b) El esquema de contextos navegacionales mejorado:
Una vez que las clases navegacionales han sido definidas, es necesario estructurar el
espacio de navegación que está disponible para el usuario, en OOHDM, esta
estructura es definida por objetos de navegación agrupadas en conjuntos llamados
contextos.
Un contexto navegacional es un conjunto de nodos, enlaces, clases de contexto y otros
contextos navegacionales (contextos anidados). Se definen por comprensión o por
extensión, por enumeración de sus miembros. Los contextos navegacionales juegan un
rol similar a las colecciones y fueron inspirados sobre el concepto de contextos
anidados. (Schwabe, "Notación del Método OOHDM"., 2002).
[Link] Diseño de interfaz abstracta:
En esta actividad se especifica cuáles son los objetos de interfaz que el usuario
percibe. La especificación de interfaz abstracta incluye diferentes objetos
navegacionales, que objetos de interfaces serán activados por la navegación, la forma
en la cual los objetos de interfaz multimedia serán sincronizados.
Esto, significa definir la forma en la cual los objetos navegacionales pueden aparecer,
cómo los objetos de interfaz activarán la navegación y el resto de la funcionalidad de la
aplicación. El diseño de la interfaz de usuario es un paso crítico en aplicaciones
interactivas. En
OOHDM, se usa “la vista abstracta de datos” ADV (Adstract Data View), estos son
modelos formales de los objetos de interfaz.
[Link] Implementación:
En esta fase el diseñador debe implementar el diseño. Hasta esta fase, todos los
modelos fueron construidos de forma independiente de la plataforma de
implementación; en esta fase se tiene en cuenta el entorno particular en el cual va a
correr la aplicación. (SILVA &
MERCERAT)
En esta fase el sistema será puesto en marcha y depurado de errores si es necesario.
Que en esta fase el diseñador debe implementar el diseño. Todos los modelos han sido
construidos independientemente de la plataforma de implementación. Al llegar a esta
fase, el primer paso que debe realizar el diseñador es definir los ítems de información
que son parte del dominio del problema. Debe identificar también, como son
organizados los ítems de acuerdo al perfil del usuario y su tarea; decidir que interfaz
debería ver y como debería comportarse. A fin de implementar todo en un entorno
Web, el diseñador debe decidir además que información será almacenada.
El diseñador debe decidir si la base de datos podría contener los objetos conceptuales,
si los nodos navegacionales podrían ser vistas, si la interfaz implementada se realiza
con HTML, JavaScript, php, css u otros.
2.8 Herramientas de desarrollo
En el desarrollo del presente proyecto se tomó una serie de herramientas capaces de
colaborar con las funciones específicas que se necesitaron durante todo el trayecto de
la elaboración del sistema web de registro y control de ventas; para entender mejor
esta sección se describen las herramientas en la siguiente tabla.
Nivel Lenguaje

Cliente HTML, CSS

 Servidor Servidor web Apache

Lenguaje de scripts PHP

Servidor de datos Base de datos MySQL

Tabla 3. Herramientas tecnológicas.

Fuente: Elaboración propia.
2.8.1 MySQL
MySQL es un sistema de gestión de bases de datos relacional desarrollado bajo
licencia dual: Licencia pública general/Licencia comercial por Oracle Corporation y está
considerada como la base de datos de código abierto más popular del mundo, y una de
las más populares en general junto a Oracle y Microsoft SQL Server, sobre todo para
entornos de desarrollo web. (corporacion, 2022).
2.8.2 HTML
Cuando hablamos de HTML5 lo primero que tenemos que saber es que es la última
versión de la tecnología HTML, cuyas siglas corresponden a “HyperText Markup
Language” que tiene el siguiente significado:
- HyperText, que significa hipertexto, que no es más que un texto que enlaza con otros
contenidos, que pueden ser otro texto u otro archivo. Esto es la base del
funcionamiento de la web tal y como la conocemos, que no es más que páginas y
recursos interconectados.
- Markup, cuyo significado es marca o etiqueta, ya que todas las páginas web están
construidas en base a etiquetas, desde las primeras versiones hasta las últimas
etiquetas de HTML5.
- Language, que significa lenguaje, porque HTML es un lenguaje, es decir, tiene sus
normas, tiene su estructura y una serie de convenciones que nos sirven para definir
tanto la estructura como el contenido de una web.
HTML es un lenguaje de marcado de hipertexto que nos permite estructurar el
contenido y diseño de sitios y aplicaciones web mediante etiquetas; es muy fácil de
aprender, lo que permite el acceso a personas que no han programado; así que es una
serie de etiquetas que se utilizan para definir el contenido del documento y algún estilo.
2.8.3 PHP
PHP es un lenguaje de código abierto muy popular, adecuado para desarrollo web y
que puede ser incrustado en HTML. Es popular porque un gran número de páginas y
portales web están creadas con PHP. Código abierto significa que es de uso libre y
gratuito para todos los programadores que quieran usarlo. Incrustado en HTML
significa que en un mismo archivo vamos a poder combinar código PHP con código
HTML, siguiendo sus propias reglas.
PHP se utiliza para generar páginas Web dinámicas. Recordar que llamamos página
estática a aquella cuyos contenidos permanecen siempre igual, mientras que llamamos
páginas dinámicas a aquellas cuyo contenido no es el mismo siempre. Por ejemplo, los
contenidos pueden cambiar en base a los cambios que haya en una base de datos, de
búsquedas o aportaciones de los usuarios, etc.
De esta forma, se puede programar aplicaciones asociadas al servidor de web,
aumentando, así, la funcionalidad de dicho servidor y convirtiéndolo en un sistema de
desarrollo de aplicaciones cliente/servidor mucho más completo. Su principal objetivo
es hacer que desarrolladores de aplicaciones basadas en la web puedan escribir
páginas que se generan dinámicamente de una forma sencilla y rápida. (Enzo,
Augusto).
PHP proporciona, por tanto, una gran facilidad para acceder a diferentes tipos de bases
de datos como Oracle, Sybase, MySQL, PostgreSQL, Adabas, etc. De hecho, es
bastante sencillo portar una aplicación escrita con PHP para MySQL a cualquier otro
servidor de base de datos, ya que las funciones de acceso que ofrece PHP son, en
muchos casos, de sintaxis compartida. (Enzo, Augusto).
2.8.4 JAVASCRIPTS
JavaScript fue diseñado para ser un lenguaje de elaboración de scripts que pudieran
incrustarse en archivos HTML. No es compilado, sino que, en vez de ello, es
interpretado por el navegador. A diferencia de Java, que primero es convertido a código
de byte fácil de interpretar, JavaScript es leído por el navegador como código fuente.
Esto facilita el aprendizaje de JavaScript mediante ejemplos, debido a que se puede
ver la manera en que otros usan JavaScript en sus páginas.
JavaScript es un lenguaje que fue creado para darle más dinamismo a las páginas
web. Antes, con HTML, lo único que podías hacer era poner fotos, texto, sonido y
alguna que otra cosa más. Con este lenguaje, le podemos dar más movimiento a una
página web y lograr una verdadera interactividad con los usuarios, algo que todos
buscan en internet. (INNOVACIÓN Y CUALIFICACIÓN, 2001).
2.8.5 CSS:
El CSS es un lenguaje de estilos empleado para definir la presentación, el formato y la
apariencia de un documento de marcaje, sea html, xml, o cualquier otro. Comúnmente
se emplea para dar formato visual a documentos html o xhtml que funcionan como
espacios web. También puede ser empleado en formatos xml, u otros tipos de
documentos de marcaje para la posterior generación de documentos. (Puig, 2010)
Las hojas de estilos nacen de la necesidad de diseñar la información de tal manera
que podemos separar el contenido de la presentación y, así, por una misma fuente de
información, generalmente definida mediante un lenguaje de marcaje, ofrecer
diferentes presentaciones en función de dispositivos, servicios, contextos o aplicativos.
Por lo que un mismo documento html, mediante diferentes hojas de estilo, puede ser
presentado por pantalla, por impresora, por lectores de voz o por tabletas braille.
Separamos el contenido de la forma, composición, colores y fuentes. (Puig, 2010).
 CAPÍTULO III
MARCO APLICATIVO
3.1 Introducción:
En el presente capítulo se formalizará la estructura y funcionalidad del sistema de
información Web mediante la utilización de la metodología OOHDM, propuesta por
Rossi y Schwabe, con el uso de diagramas de diversas clases que facilitará y
garantizará la eficaz elaboración del sistema de control y registro de ventas del
presente proyecto.
3.2 Obtención de requisitos:
La tarea de obtención de requisitos es fundamental para dar inicio al desarrollo del
proyecto, ya que recabará información detallada de lo que se desea implementar en el
sistema. En la tabla 6 se presenta los requerimientos que fueron recabados para el
desarrollo del sistema de web.
Tabla de requisitos:

Identificador Requerimientos

R1 La tienda “Katsuki Store” requiere un sistema Web que ayude con el control
y registro de ventas.

R2
Se requiere que el sistema Web sea adecuado para la administración y
control de ventas por parte del personal, también sobre el registro de los
productos.

R3
El Administrador y personal de ventas requiere estar informado de todo lo
que sucede en el manejo de ventas realizadas diariamente.

R4 El programa desea mantener informado al administrador sobre el reporte de

ventas y el stock de cada producto.
 R5 El administrador requiere tener registro de los inventarios y la administración
de cada producto.

R6 El programa requiere tener el detalle de hora de acceso de cada usuario al

sistema.

R7 Requieren también el total de productos para así calcular la disponibilidad y

nueva adquisición de productos.

R8
Desean que los usuarios vean la disponibilidad de cada producto en oferta.

R9 Desean que el sistema gestione el inventario de los productos.

R10
Desea que se hagan los reportes de ventas realizadas por día.

R11
El sistema web requiere el registro de usuarios y clientes.

Tabla 4. Requerimientos funcionales para la formulación del proyecto

Fuente: Elaboración propia
3.2.1 Funcionalidades
[Link] Administrador:
 Registro de usuarios.
Introducción: Registro de un nuevo usuario.
Entrada: Datos del usuario.
Proceso: Almacenar al usuario en la base de datos.
Salida: Actualizar el control de acceso al sistema.
Añadir/Editar/Eliminar usuario.
Introducción: Gestión de la zona de usuarios.
Entrada: El administrador puede crear, modificar y eliminar a los usuarios.
 Proceso: Si el usuario es nuevo, se añaden los datos para la creación, si no es nuevo,
se localiza el usuario a modificar o eliminar y se aplica la acción.
Salida: Se actualiza la base de datos.
 Registro de categorías.
Introducción: Registro de nuevas categorías.
Entrada: Registrar datos de la nueva categoría.
Proceso: Almacenar la nueva categoría en la base de datos.
Salida: Actualización de la lista de categorías en la base de datos.
Añadir/Editar/Eliminar categorías.
Introducción: Administrar categorías.
Entrada: El administrador puede crear, modificar y eliminar las categorías.
Proceso: Si la categoría es nueva, se añaden los datos para la creación, si no es
nueva se localiza a la categoría para modificar o eliminar y se aplica la acción.
Salida: Se actualiza la base de datos.
 Registro de productos.
Introducción: Registro de nuevos productos.
Entrada: Registrar datos del nuevo producto.
Proceso: Almacenar el nuevo producto en la base de datos.
Salida: Actualización de la lista de productos en la base de datos.
Añadir/Editar/Eliminar productos.
Introducción: Administrar productos.
Entrada: El administrador puede crear, modificar y eliminar los productos.
Proceso: Si el producto es nuevo, se añaden los datos para la creación, si no es
nuevo se localiza al producto para modificar o eliminar y se le aplica la acción.
Salida: Se actualiza la base de datos con los nuevos datos.
[Link] Personal de ventas:
 Registro de clientes.
Introducción: Registro de nuevo cliente.
Entrada: Datos del cliente.
Proceso: Almacenar al cliente en la base de datos.
Salida: Se actualiza la base de datos.
Añadir/Editar/Eliminar cliente.
Introducción: Registrar clientes.
 Entrada: El administrador y personal de ventas puede crear, modificar a los clientes
admitidos y eliminarlos.
Proceso: Si el cliente admitido es nuevo, se añaden los datos para la creación, si no
es nuevo se localiza al cliente para modificar o eliminar y se le aplica la acción.
Salida: Se actualiza la base de datos y listado de los clientes.
 Registro de ventas.
Introducción: Registro de nuevas ventas.
Entrada: Datos de la venta realizada.
Proceso: Almacenar la venta en la base de datos.
Salida: Se actualiza la base de datos.
Añadir/Editar/ venta.
Introducción: Registrar ventas.
Entrada: El personal puede crear y modificar la venta.
Proceso: Si la venta es nueva se añaden los datos para la creación, si no es nueva se
localiza la venta para modificar los datos y se aplica la acción.
Salida: Se actualiza la base de datos.
3.2.2 Identificación de actores y tareas:
Dentro el dominio de la aplicación se tendrá los siguientes roles módulos y tareas tal
como se describe en la siguiente tabla 8.

ACTOR TAREAS
Administrador (Responsable del control del Iniciar sesión
sistema) Registro de usuarios
• Introducir datos
• Designación de rol del usuario o personal.
• Activar/desactivar acceso al usuario
Registro de categorías
• Introducir datos
• Crear categoría con su respectivo código
Gestión de productos
• Nuevo producto
• Lista de productos
• Detalle de productos
• Categoría de cada producto
• Stock de los productos

Personal de ventas (Encargado de realizar Iniciar sesión

ventas) Administrar Ventas
• Registro de ventas
• Lista de ventas
• Designar productos vendidos
• Realizar la venta
Registro de clientes
• Registrar datos del cliente
• Lista de clientes
• Modificar/eliminar clientes
Visitante  Ver actividades dentro del sistema
 Ver información de la tienda
Tabla 5. Identificación de actores y tareas.
Fuente: Elaboración propia
Por tanto, se puede identificar a los siguientes actores con los requerimientos
obtenidos de la propietaria de la tienda “Katsuki Store” como fuente de información.
[Link] Actor Usuario Administrador: Persona que se encarga de manejar y
administrar el sistema con sus privilegios del mismo, así mismo tiene la posibilidad de
gestionar el personal de ventas, gestionar los productos en oferta, administrar las
categorías y activar o desactivar el acceso al sistema de un determinado usuario.
[Link] Actor Usuario Personal de Ventas: Persona que está a cargo de administrar
las ventas diarias realizadas, manejo económico, el registro de nuevos clientes. En la
figura 17 se describe los actores principales del sistema.

Figura 4. Actores principales del sistema.

Fuente: Elaboración Propia
a) Usuarios anónimos/visitantes: Los usuarios anónimos son aquellos visitantes que
acceden a la información de carácter público sin necesidad de registrarse o iniciar
sesión en la plataforma. Estos usuarios tienen la capacidad de observar las
novedades, noticias u otro contenido que esté disponible para el público en general.
b) Usuarios: Los usuarios registrados en el sistema, incluyendo a la administradora
que es la propietaria de la tienda y personal de ventas, tienen acceso a diversas
funcionalidades, según sus perfiles, estas funcionalidades les permiten llevar a cabo
tareas específicas dentro del sistema con el fin de mejorar la experiencia de los
usuarios.
3.2.3 Especificación de casos de uso general nivel general:
En la figura 5 de detalla la especificación de casos de uso general, Sistema de Control
y Registro de Ventas para la Tienda “Katsuki Store” (SCRVTKS).
 S.C.R.V.T.K.S.

Figura 5. Casos de uso general.

Fuente: Elaboración Propia.
3.2.4 Identificación de casos de uso de alto nivel
En la figura 6 se describe el caso de uso registro de personal para el actor
administrador.
 REGISTRO DE PERSONAL

Datos del Registro

<<include>>
Registrar Usuario

<<include>>
A signación de rol al Usuario

<<include>>

A dministrador <<extend>>

Guardar datos del Registro

<<extend>>
A ctualizar Datos

<<extend>>

Mostrar Lista del Registro

<<extend>>
<<include>>
<<include>>

Eliminar Editar

Reporte del Registro

A ctivar/Desactivar acceso del Usuario

Figura 6. Casos de uso de registro de personal.

Fuente: Elaboración propia.
En la figura 7 se detalla el caso de uso Registro de Categorías por parte del actor
administrador.
 REGISTRO DE CATEGORÍAS

Datos de la Categoría
<<include>>
Registrar Categorías

<<include>>

Guardar datos registrados

<<extend>>

A dministrador
<<extend>>

A ctualizar Datos
M ostrar información registrada

<<include>> <<include>>

Eliminar Editar
Reporte del registro

Figura 7. Casos de uso de registro de categorías.

Fuente: Elaboración propia
En la figura 8 se describe la Gestión de Productos del actor Administrador.
 REGISTRO DE PRODUCTOS

Registrar Datos

<<include>>

Registro de Productos
<<include>>
A dministrador Guardar Datos

<<extend>>

<<extend>>

Mostrar información registrada

A ctualizar Datos

<<include>> Reporte del Producto

<<include>>
Modificar Eliminar

Figura 8. Caso de uso de gestión de productos

Fuente: Elaboración propia
En la figura 9 se detalla el caso de uso Registro de Clientes para el actor Administrador
y Personal de ventas.
 REGISTRO DE CLIENTES

Registro de datos del Cliente

<<include>>
Registro de Clientes
Administrador

<<include>>

<<extend>> Guardar datos del Cliente

<<extend>>

Actualizar Datos <<extend>> Mostrar lista de Registro

<<extend>>
<<include>>

Personal de Ventas
<<include>> Reporte del Registro

Modificar Eliminar

Figura 9. Casos de uso de aporte de producto.

Fuente: Elaboración Propia.
En la figura 10 se detalla el caso de uso Registro de Ventas para los actores
Administrador y Personal de ventas.
 REGISTRO DE VENTAS

Datos del producto

<<include>>

<<include>>
Registro de ventas
A dministrador
<<include>> Datos del cliente

<<include>>

M odificar Guardar registro

<<extend>>

<<extend>>
Personal de ventas

M ostrar información registrada

Reporte del registro

Figura 10. Casos de uso de registro de ventas.

Fuente: Elaboración Propia.
En la figura 11 se detalla el caso de uso Reportes para el actor Administrador y
Personal de Ventas.
 REPORTES

<<include>>

Registro de Reportes
Reporte de productos
<<include>>

Administrador

Reporte de ventas
<<extend>>

Actualizar datos

<<include>> Mostrar lista de reportes

<<extend>>
Personal de ventas <<include>>

Modificar Eliminar

Figura 11. Caso de uso de reportes.

Fuente: Elaboración Propia.
3.2.5 Descripción de casos de uso de alto nivel:
En la siguiente tabla se detalla los casos de uso de las figuras anteriormente
expuestas.

Registro Usuario
Nombre

Actor Administrador
 Propósito El actor se autentifica

Resumen El caso de uso se inicia cuando el administrador necesita adicionar,

modificar, eliminar los datos de las categorías y productos, así como
también al personal involucrado. El sistema debe proporcionarle las
opciones para realizar estas operaciones.

Evento del Actor Evento del Sistema

Flujo Principal 1 El actor se autentifica como

2 El módulo muestra el
administrador e ingresa al
formulario de inicio de sesión.
sistema.
4 El módulo muestra la página de
3 El actor ingresa su usuario y
inicio con el menú principal.
contraseña.

Pre_Condición Estar en el formulario de inicio del sistema.

Pos_Condición Estar en el menú principal de la página de inicio.

Tabla 6. Caso de uso registro de usuario.

Fuente: Elaboración Propia
En la tabla 7 detalla el registro de usuarios para el actor administrador.

Nombre Registro de Usuarios

Actor Administrador

Propósito El actor se autentifica

Resumen El caso de uso se inicia cuando el administrador necesita

adicionar, modificar, eliminar, los datos de un usuario. El
sistema debe proporcionarle las opciones para realizar estas
operaciones.
 Evento del Actor Evento del Sistema

Flujo Principal 1 El actor se autentifica como 2 El módulo muestra el

administrador e iniciar la formulario de inicio de
sesión. sesión.
3 El actor ingresa su usuario 4 El módulo muestra el
y su contraseña. formulario de registro de
usuario y asignación de
roles.
5 El módulo muestra lista de
usuarios con sus respectivas
opciones para administrar.

Pre_Condición Estar en el formulario de inicio del sistema.

Pos_Condición Estar en el menú principal de la página registro de usuarios.

Tabla 7. Caso de uso gestión de usuarios.

Fuente: Elaboración propia
En la tabla 8 se detalla el caso de uso para la gestión de categorías para el actor
administrador.

Nombre Registro de Categorías

Actor Usuario Administrador

Propósito El actor se autentifica

Resumen El caso de uso se inicia cuando el actor necesita adicionar,

modificar, eliminar y registrar una categoría. El sistema debe
proporcionarle las opciones para realizar estas operaciones.

Evento del Actor Evento del Sistema

 Flujo Principal 1 El actor se autentifica como
administrador e inicia la
2 El módulo muestra el
sesión.
formulario de inicio de
3 El actor ingresa su usuario
sesión.
y su contraseña.
4 El módulo muestra el
formulario de registro de
categorías.
5 El módulo muestra lista de
categorías con sus
respectivas opciones para
administrar.

Pre_Condición Estar en el formulario de inicio del sistema

Pos_Condición Estar en el menú principal de la página de gestión de

categorías.
Tabla 8. Caso de uso gestión de categorías.
Fuente: Elaboración propia
En la tabla 9 se detalla el caso de uso de Registro de productos para el actor
administrador.

Nombre Administración de productos

Actor Administrador.

Propósito El actor se autentifica

 Resumen El caso de uso se inicia cuando el actor necesita adicionar,
modificar, eliminar productos. El sistema debe
proporcionarle las opciones para realizar estas operaciones.

Evento del Actor Evento del Sistema

Flujo Principal 1 El actor se autentifica como 2 El módulo muestra el

administrador e iniciar la formulario de inicio de
sesión. sesión.
3 El actor ingresa su usuario 4 El módulo muestra el
y su contraseña. formulario de registro
productos.
5 El módulo muestra lista de
los productos con sus
respectivas opciones para
administrar.

Pre_Condición Estar en el formulario de inicio del sistema

Pos_Condición Estar en el menú principal de la página de administración de

productos.
Tabla 9. Caso de uso administración de aportes de producto de los padres de familia.
Fuente: Elaboración propia
En la tabla 10 se detalla el caso de uso para el registro de los clientes para el actor
administrador y personal de ventas.

Nombre Administración de clientes.

Actor Administrador y personal de ventas.

Propósito El actor se autentifica

Resumen El caso de uso se inicia cuando el actor necesita adicionar,

modificar, eliminar el registro de clientes. El sistema debe
proporcionarle las opciones para realizar estas operaciones.

Evento del Actor Evento del Sistema

Flujo Principal 1 El actor se autentifica como 2 El módulo muestra el

administrador e iniciar la formulario de inicio de
sesión. sesión.
3 El actor ingresa su usuario 4 El módulo muestra el
y su contraseña. formulario de registro de
clientes.
5 El módulo muestra la lista
de clientes con sus
respectivas opciones para
administrar.

Pre_Condición Estar en el formulario de inicio del sistema

Pos_Condición Estar en el menú principal de la página de registro de

clientes.
Tabla 10. Detalle del caso de uso registro de clientes
Fuente: Elaboración propia
En la tabla 11 se detalla el caso de uso registro de ventas para el actor administrador y
personal de ventas.

Nombre Registro de ventas.

Actor Administrador y Personal de ventas

Propósito El actor se autentifica

Resumen El caso de uso se inicia cuando el actor necesita adicionar,

modificar el registro de ventas. El sistema debe
proporcionarle las opciones para realizar estas operaciones.

Evento del Actor Evento del Sistema

Flujo Principal 1 El actor se autentifica como 2 El módulo muestra el

administrador e iniciar la formulario de inicio de
sesión. sesión.
3 El actor ingresa su usuario 4 El módulo muestra el
y su contraseña. formulario de registro de
ventas.
5 El módulo muestra lista del
registro de ventas con sus
respectivas opciones para
administrar.

Pre_Condición Estar en el formulario de inicio del sistema

Pos_Condición Estar en el menú principal de la página registro de ventas.

Tabla 11. Detalle del caso de registro e ventas

Fuente: Elaboración propia
En la tabla 12 se detalla el caso de uso reportes para el actor administrador y personal
de ventas.

Nombre Reportes

Actor Administrador y Personal de ventas.

Propósito El actor se autentifica

Resumen El caso de uso se inicia cuando el actor necesita adicionar,

modificar, eliminar reportes. El sistema debe proporcionarle
las opciones para realizar estas operaciones.

Evento del Actor Evento del Sistema

Flujo Principal 2 El módulo muestra el

formulario de inicio de
1 El actor se autentifica como sesión.
administrador e iniciar la El módulo muestra el
sesión. formulario de reportes.
3 El actor ingresa su usuario El módulo muestra lista del
y su contraseña. registro de reportes con sus
respectivas opciones para
administrar.

Pre_Condición Estar en el formulario de inicio del sistema.

Pos_Condición Estar en el menú principal de la página reportes.

Tabla 12. Detalle del caso de uso reportes.

Fuente: Elaboración propia.
3.3 Diseño conceptual:
En base a los requisitos del sistema para mejorar el registro y control de ventas, se
identificaron los objetos o clases relevantes, así como las relaciones y colaboraciones
entre ellos. En el enfoque OOHDM (Object-Oriented Hypermedia Design Method), las
clases se describen de manera similar a los modelos orientados a objetos
convencionales.
Un modelo de bases de datos es una descripción de un contenedor de datos o una
estructura en la que se guarda la información. Para ello se realiza un análisis del
modelo lógico, así como la presentación del modelo físico.
3.2.1 Diagrama del modelo entidad relación:

Figura 12. Relación de tablas de base de datos.

Fuente: Elaboración propia
3.3 Modelo de clase navegacional:
La figura 13 describe la clase de navegación del sistema de información web.
 Figura 13. Modelo de clases navegacionales.
Fuente: Elaboración propia.
3.4 Diseño de interfaz abstracta:
El gráfico representa la ventana principal del sistema de información Web, donde el
usuario puede ingresar utilizando su nombre de usuario y contraseña para acceder
según su rol correspondiente.
En el siguiente nodo se describe la ventana de inicio al ingresar con el respectivo
usuario y contraseña dando paso al panel de control.
 Figura 14. Ventana de ingreso al sistema.
Fuente: Elaboración Propia.
En el siguiente nodo se muestra la ventana de inicio, donde se puede visualizar los
productos de la tienda y ciertos detalles referidos al mismo.
 Figura 15. Ventana del sistema inicio.
Fuente: Elaboración Propia.
En la siguiente figura se visualiza el panel de control con los respectivos registros a los
cuales puede acceder el usuario según su rol designado.
 Figura 16. Primera Ventana del Sistema panel de control.
Fuente: Elaboración Propia.
En la siguiente figura se visualiza la ventana de registro de usuarios al que se puede
acceder para agregar, modificar o eliminar a los usuarios pertenecientes del sistema
que son actores partícipes en la tienda.
 Figura . Ventana agregar usuario
Fuente: Elaboración propia
En el siguiente nodo se puede visualizar el listado de usuarios en los cuales se
muestran sus distintos datos personales y la actividad que realizan dentro de la tienda.
 Figura 18. Visualización del listado de usuarios.
Fuente: Elaboración Propia.
Es de esta manera que se irá realizando cada ventana con los registros que requiere la
tienda, ocupando similitudes dentro del modo de manejar cada gestor o registro,
tratando de hacer que el sistema sea de fácil acceso y manipulación para los usuarios.
3.5 implementación y prueba del sistema:
Para realizar el sistema se utilizó distintas tecnologías y lenguajes de programación. En
primer lugar, se procedió a la instalación de un servidor web local con el fin de permitir
la visualización del sistema de información y poder observar las respuestas que
posteriormente se generan en un servidor real ubicado en la red.
 Para ello se opta por instalar XAMPP 3.2.3, que incorpora en un solo programa:
 Apache que es el servidor web.
 PHP versión 7.4.30, lenguaje de programación interpretado, para webs dinámicas.
 Utilizando MySQL para la creación y gestión de la base de datos, asegurando así la
persistencia de los datos de manera efectiva.
 Star UML para la creación de diagramas de casos de uso.
En el diseño de la interfaz de usuario se utilizan HTML y CSS, los cuales se combinan
para proporcionar una apariencia visual coherente en todas las páginas que muestra el
 sistema. Esta elección de tecnologías permite realizar modificaciones de manera fácil y
eficiente, reduciendo el esfuerzo que conlleva.
3.5.1 Detalles de implementación:
La página principal o índice del sistema es accesible para los usuarios, una vez que el
usuario se identifica en el sistema aquellos con roles de administrador o personal de
ventas tendrán acceso a las opciones de gestión del sistema. A continuación, se detalla
algunas de las funcionalidades más destacadas que se implementó en el sistema de
información web.
1) Primera pantalla: Identificación
En el archivo [Link] se realiza la verificación de la existencia del usuario y se valida
la coincidencia entre su contraseña y nombre de usuario. En esta pantalla, los usuarios
registrados por el administrador del sistema de información web, pueden acceder a
iniciar sesión mediante su usuario y contraseña, de esta manera lograr ingresar a la
página de inicio del sistema.

Fi
gura 19. Interfaz login.
Fuente: Elaboración Propia.
2) Ventana después de la Identificación como Usuario.
Una vez que el usuario ingresa su cuenta y contraseña correctamente, se le
proporcionará una ventana con las opciones y privilegios correspondientes a su perfil
de usuario. En este caso se muestra la ventana de administrador. (Ver Anexo 2, Figura
58) para su verificación del código fuente.
 Figura 20. Vista del administrador.
Fuente: Elaboración Propia.
3) Ventana de Registro de Usuarios:
En esta ventana, se realiza el registro del personal y se asigna el cargo o rol
correspondiente que se determina en el sistema. Aquí, se lleva a cabo el proceso de
agregar nuevos miembros al personal y asignarles su rol específico. (Ver Anexo 2
figura 59) para el código fuente.

Figura 21. Ventana de registro personal.

 Fuente: Elaboración Propia.
4) Ventana de Lista de personal:
En esta ventana se describe el personal registrado en el sistema con su respectivo
nombre, usuario, la foto que el usuario haya elegido al momento del registro, el perfil o
rol que ocupa dentro de la tienda, también muestra si el usuario está activado, su
último acceso y las acciones que se pueden realizar (editar/eliminar).

Figura 22. Ventana listar usuario.

Fuente: Elaboración Propia.
5) Ventana Administrar categorías:
En esta ventana se presenta el registro de categorías que tiene la tienda “Katsuki
Store” Aquí, el usuario puede acceder a las opciones y funcionalidades específicas que
le corresponden, como la modificación y eliminación de los registros realizados.
 Figura [Link] administrar categoría.
Fuente: Elaboración Propia.
6) Vista administración de productos:
En esta ventana, se lleva a cabo el proceso de administración de productos y se
asignan las categorías correspondientes con el respectivo código de registro, el actor
puede agregar, modificar o eliminar el producto si lo ve necesario. También muestra la
lista de productos ya registrados con los datos necesarios y el stock de cara producto.
(Ver Anexo 2, Figura 58) para su verificación del código fuente.
 Figura 24. Ventana de administración de productos.
Fuente: Elaboración propia.
7) Vista listado de clientes:
En esta ventana se muestra la lista de los clientes registrados por los actores
responsables, con sus respectivos datos de registro. El actor responsable podrá
realizar el registro, modificación y eliminación de cualquier cliente. (Ver Anexo 2 figura
61) para el código fuente.
 Figura 25. Ventana de lista de clientes.
Fuente: Elaboración propia:
8) Ventana agregar cliente:
En esta ventana se muestra el acceso a la opción de agregar clientes; realizando el
llenado de los datos correspondientes por parte de los actores se podrá incluir nuevos
clientes que sean partícipes de las compras en la tienda “Katsuki Store”. (Ver Anexo 2
figura 62) para el código fuente.

Figura 26. Ventana agregar cliente.

Fuente: Elaboración Propia.
3.5.3 Validación de entrada de datos:
Para la validación de entrada de datos en el sistema web de registro y control de
ventas, es importante considerar los siguientes aspectos:
Validación de formato:
- Verificar que los campos de fecha se ingresen en el formato correcto (por ejemplo:
aaaa/mm/dd).
- Validar el formato de correos electrónicos y números de teléfono.
Validación de longitud y rango:
-Establecer límites para la longitud de los campos de texto para evitar ingreso excesivo
de caracteres.
-Asegurar que los valores numéricos estén dentro de rangos válidos, como límites
mínimos y máximos.
Validación de campos obligatorios:
-Marcar los campos obligatorios y asegurarse de que los usuarios los completen antes
de enviar el formulario.
Validación de datos únicos:
-Verificar que los datos ingresados, como números de identificación o nombres de
estudiantes, no existan previamente en la base de datos para evitar dúplicas.
Mensajes de error claros:
-Proporcionar mensajes de errores claros y descriptivos para guiar a los usuarios en
caso de datos incorrectos o faltantes.
Pruebas exhaustivas:
-Realizar pruebas exhaustivas en diferentes escenarios para asegurar que todas las
validaciones funcionen correctamente.
Validación en el lado del cliente y del servidor:
-Implementar validaciones tanto en el lado del cliente (usando JavaScript) como en el
lado del servidor (usando PHP y MySQL) para garantizar una protección adecuada y
consistente.
Es importante que la validación de la entrada de datos sea una parte integral del
desarrollo del sistema. La aplicación de una validación sólida garantiza que los datos
ingresados sean correctos, consistentes y seguros, lo que aumenta la eficiencia y
confiabilidad del sistema de registro y control de ventas.
3.5.4 Pruebas de unidad:
De esta manera, se confirma que el sistema opera de manera exitosa al registrar y
controlar las ventas. Además, se logra mejorar el control y la gestión de los inventarios
de forma efectiva. El sistema proporciona una herramienta eficiente para realizar un
seguimiento a las ventas que se realizan.
[Link] Pruebas de integración.
Una vez completado las pruebas individuales de cada módulo de forma separada, se
procede a la etapa de integración por secciones. Durante esta etapa, los módulos se
van integrando gradualmente, y se realizan pruebas adicionales para identificar
posibles errores y realizar las correcciones necesarias. El objetivo es asegurar que los
diferentes componentes del sistema funcionen correctamente en conjunto y que no
surjan problemas de compatibilidad o funcionamiento entre ellos. En caso de encontrar
errores, se realizan las correcciones necesarias para garantizar un funcionamiento
fluido y coherente del sistema en su conjunto.
Durante este proceso de integración, se busca garantizar el correcto funcionamiento de
los diferentes módulos en conjunto. Se realizan pruebas exhaustivas para identificar
posibles problemas de comunicación, incompatibilidades o errores en la interacción
entre los módulos. Cada error detectado se registra y se realiza la corrección
correspondiente.
[Link] Módulo a probar: registro de personal
Los resultados esperados demuestran que se registra, modifica y elimina al usuario
registrado.
Resultado Esperado:
Los resultados esperados son satisfactorios en cuanto a la respuesta por sistema del
cliente-servidor; relación correcta entre datos y sistema.
Resultado Obtenido:
Todos los resultados obtenidos fueron satisfactorios.
Conclusión:
No se identificaron problemas en la conexión con el sistema.
3.5.4.3Módulo a probar: registro usuarios
Los resultados esperados demuestran que cada usuario tiene la posibilidad de ser
registrado en el sistema y designar el rol que ocupa, el registro es realizado por el
administrador recabando los datos que se requieren en el sistema.
Resultado Esperado:
Los resultados esperados son satisfactorios en cuanto a respuesta por sistema del
cliente-servidor; relación correcta entre datos y sistema.
Resultado Obtenido:
Todos los resultados obtenidos fueron satisfactorios.
Conclusión:
No se identificaron problemas en la conexión con el sistema.
3.5.4.5Módulo a probar: registro de categorías
Los resultados esperados indican que el formulario de registro completado por el actor
debe guardarse con el código correspondiente asignado.
Resultado Esperado:
Los resultados esperados son satisfactorios en cuanto a respuesta por sistema del
cliente-servidor; relación correcta entre datos y sistema.
Resultado Obtenido:
Todos los resultados obtenidos fueron satisfactorios.
Conclusión:
No se identificaron problemas en la conexión con el sistema.
[Link] Módulo a probar: registro de productos:
Los resultados esperados demuestran que el registro de productos, realizado por los
actores determinados, con los datos exigidos se realizan y guardan correctamente.
Resultado Esperado:
Los resultados esperados son satisfactorios en cuanto a respuesta por sistema del
cliente-servidor; relación correcta entre datos y sistema.
Resultado Obtenido:
Todos los resultados obtenidos fueron satisfactorios.
Conclusión:
No se identificaron problemas en la conexión con el sistema.
3.5.4.7Módulo a probar: registro de clientes:
Los resultados esperados demuestran que el registro de clientes es efectuado por el
administrador y personal de ventas.
Resultado Esperado:
Los resultados esperados son satisfactorios en cuanto a respuesta por sistema del
cliente-servidor; relación correcta entre datos y sistema.
Resultado Obtenido:
Todos los resultados obtenidos fueron satisfactorios.
Conclusión:
No se identificaron problemas en la conexión con el sistema.
[Link] Módulo a probar: registro de ventas
Los resultados esperados demuestran que el registro de ventas es efectuado por el
personal de ventas y el administrador.
Resultado Esperado:
Los resultados esperados son satisfactorios en cuanto a respuesta por sistema del
cliente-servidor; relación correcta entre datos y sistema.
Resultado Obtenido:
Todos los resultados obtenidos fueron satisfactorios.
Conclusión:
No se identificaron problemas en la conexión con el sistema.
[Link] Módulo a probar: creación de reportes
Los resultados esperados demuestran que se crean los reportes de necesarios dentro
del sistema.
Resultado Esperado:
Los resultados esperados son satisfactorios en cuanto a respuesta por sistema del
cliente-servidor; relación correcta entre datos y sistema.
Resultado Obtenido:
Todos los resultados obtenidos fueron satisfactorios.
Conclusión:
No se identificaron problemas en la conexión con el sistema.
ESTIMACIÓN Y CALIDAD DE SOFTWARE
CONFIABILIDAD DEL SISTEMA
La confiabilidad del sistema está directamente relacionada con la confiabilidad de los
subsistemas Ri (t), donde la probabilidad de errores y fallos (Λ) encontrados en 120
horas se toma en cuenta la siguiente ecuación:

𝑅(𝑡) = 𝑒−𝜆𝑡 (1).

Donde:
R(t) = Confiabilidad de un componente o subsistema.
e−λt = Probabilidad de falla de un componente o subsistema en tiempo.
T = Tiempo de trabajo sin falla.
λ = Tasa constante de fallos.
t = Periodo de operación de tiempo.
Posteriormente se realiza los cálculos para cada módulo utilizando la ecuación (1).
R1 = Autentificación de usuario.
R2 = Editar/eliminar datos del usuario.
R3 = Registro de categorías.
R4 = Editar/eliminar categorías.
R5 = Consulta de productos.
R6 = Editar/eliminar productos.
R7 = Ver lista de clientes.
R8 = Registrar/editar/eliminar clientes.
R9 = Consulta de ventas.
R10 = Registrar/editar/eliminar venta.
R11 = Reportes.
La tasa de fallo (Λ) y el tiempo (t [horas]) se obtuvo realizando pruebas a cada módulo
y se obtuvo los siguientes resultados.
Ri(t) Λ t[horas] R(t)
R1 0.01 5 0.95
R2 0.02 5 0.90
R3 0.05 5 0.77
R4 0.01 5 0.95
R5 0.01 5 0.95
R6 0.01 5 0.95
R7 0.01 5 0.95
R8 0.05 5 0.77
R9 0.01 5 0.95
R10 0.01 5 0.95
R11 0.01 5 0.95
 Tabla : Cálculo de confiabilidad del sistema
Fuente: Elaboración propia
En la tabla anterior se muestra la confiabilidad de cada componente o subsistema.
El nivel de confiabilidad con respecto a la función está dado por la siguiente
ecuación:

R = Ri ∗ Rs
Donde:
(2)
Ri = R1 = 0.95
El valor de RS, se obtiene con la siguiente formula:

Rs(t) = 1 − {(1 − R2(t)) ∗ (1 − R3(t)) ∗ … ∗ (1 − Rn−1(t)) ∗ (1 − Rn(t))}

(3)

Reemplazando los valores de la tabla 4.1 en la ecuación (3) obtendremos:

𝑹𝒔(𝒕) = 𝟏 − {(𝟏 − (𝟎. 𝟗𝟓)) ∗ (𝟏 − (𝟎. 𝟗𝟎)) ∗ (𝟏 − (𝟎. 𝟕𝟕)) ∗ (𝟏 − (𝟎. 𝟗𝟓))
∗ (𝟏 − (𝟎. 𝟗𝟓)) ∗ (𝟏 − (𝟎. 𝟗𝟓)) ∗ (𝟏 − (𝟎. 𝟗𝟓))∗ (𝟏 − (𝟎. 𝟕𝟕))

∗ (𝟏 − (𝟎. 𝟗𝟓))∗ (𝟏 − (𝟎. 𝟗𝟓)) ∗ (𝟏 − (𝟎. 𝟗𝟓))}

RS(t) = 0,99997875

Reemplazando en la ecuación (2) obtendremos:

R = 0.95 ∗ 0,9997875
R = 95%

R = 95%

Interpretación:
Con el resultado obtenido se puede decir que el sistema demuestra que del 100% un
95% es confiable y un 5% de que cualquiera de los componentes falle.
Funcionalidad del sistema:
 Una vez determinado las cinco características de la funcionalidad mencionadas en el
marco teórico realizaremos la clasificación detalladamente de las mismas.
4.1.1 Entradas de usuario:
Son entradas que proporcionan diferentes datos al sistema.
1) Registro de usuario.
2) Pantalla de Autentificación.
3) Registro de nuevos productos.
4) Registro de nuevas categorías.
5) Registro de nuevas ventas.
6) Reportes.
4.1.2 Número de salidas de usuario:
Es la información elaborada por el sistema que son transmitidas al usuario, también
actualizan algunos archivos; tiene una sola dirección del interior al exterior.
1) Pantalla de Ver mi perfil.
2) Pantalla de usuarios.
3) Datos de productos.
4) Pantalla de registro de ventas.
5) Pantalla de categorías.
6) Pantalla de lista de clientes.
7) Pantalla de permisos de sistema.
8) Pantalla de inicio.
9) Pantalla de reportes.
4.1.3 Número de peticiones de usuario:
Es una entrada interactiva que produce la generación de algunas respuestas del
sistema en forma de salida interactiva.
1) Autentificación de Usuario.
2) Modificar perfil (datos personales del usuario)
3) Modificar/eliminar productos.
4) Modificar/eliminar categorías.
5) Modificar/eliminar clientes.
 6) Modificar/eliminar/imprimir ventas.
7) Modificar/eliminar reportes.
4.1.4 Número de archivos
Son archivos que pueden ser de una base de datos o los archivos independientes
usados en el sistema.
1) Datos de usuario.
2) Index (pantalla principal).
3) Registro a módulos.
4) Reporte.
4.1.5 NÚMERO DE INTERFACES EXTERNAS
Son todas las interfaces legibles por la computadora que se utilizan para transmitir
información a otro sistema, por tanto, se puede observar las siguientes interfaces
externas.
1) Conexión.
2) Autentificación.
3) Datos usuarios.
4) Datos de productos.
5) Datos de clientes.
6) Datos de categorías.
7) Datos de ventas.
Cuenta Factores de Ponderación
Parámetros de Medición Simple Medio Complejo Total
Nº de entradas de usuario. 6X 4 6 = 36
3
Nº de salidas de usuario. 9X 4 5 7 = 63

Nº peticiones de usuario. 7X 4 6 = 42
3
Nº de archivos. 4X 10 15 = 60
7
Nº de interfaces externas. 7X 7 10 = 70
 5
Cuenta Total 271

Tabla 4.2: Factores de ponderación

Fuente: Elaboración propia
Para calcular los puntos de función se utiliza la siguiente ecuación.

𝑷𝑭 = 𝑪𝒖𝒆𝒏𝒕𝒂 𝑻𝒐𝒕𝒂𝒍 ∗ [ 𝟎. 𝟔𝟓 + 𝟎. 𝟎𝟏 ∗
∑ 𝑭𝒊 ]
Dónde: (4)
Cuenta Total = es la suma de todas las entradas de PF obtenidas en la tabla 4.2. Fi =
puede ser 1 hasta 14 valores de ajuste de complejidad, basados en las preguntas que
aparecen en la tabla 4.4, evaluando en una escala de 0 a 5, tomando en cuenta la
tabla 4.3.
Para evaluar cada factor de la tabla 4.4, se debe usar la siguiente tabla.
0 1 2 3 4 5
Sin Influencia Incidental Moderado Medio Significativo Esencial
Tabla 4.3: Escala de evaluación de los factores
Fuente: Elaboración propia
En la Tabla 4.3 se expresa los valores que toman las respuestas dependiendo cual
valor se ajusta al sistema y la explicación que se dio a cada pregunta.
Nº FACTORES FACTOR
Fi
1 ¿Requiere el sistema copias de seguridad y recuperación fiables? 5

2 ¿Se requieren comunicaciones de datos? 5

3 ¿Existen funciones de procesamiento distribuido? 2
4 ¿Es crítico el rendimiento? 2
5 ¿Será ejecutado el sistema en un entorno operativo existente y 4
fuertemente utilizado?
6 ¿Requiere el sistema entrada de datos interactiva? 4
¿Requiere la entrada de datos interactiva que las transacciones de4
 7 entrada se lleven a cabo sobre múltiples pantallas o variadas
operaciones?
8 ¿Se actualizan los archivos maestros de forma interactiva? 3
9 ¿Son complejas las entradas, las salidas, los archivos o las 3
peticiones?
10 ¿Es complejo el procesamiento interno? 4
11 ¿Se ha diseñado el código para ser reutilizable? 4
12 ¿Están incluidas en el diseño la conversión y la instalación? 1

13 ¿Se ha diseñado el sistema para soportar múltiples instalaciones 3

en diferentes organizaciones?
14 ¿Se ha diseñado la aplicación para facilitar los cambios y para ser 4
fácilmente utilizada por el usuario?
Sumatoria de Fi 48

Tabla 4.4: VALORES DE AJUSTE DE COMPLEJIDAD

Fuente: Elaboración propia
Finalmente calculamos los puntos de función del sistema en la ecuación (4).
𝑷𝑭 = 𝟒𝟏𝟎 ∗ [ 𝟎. 𝟔𝟓 + 𝟎. 𝟎𝟏 ∗ 𝟒𝟖 ] = 𝟒𝟔𝟑, 𝟑
Luego comparando los valores de funcionalidad del sistema con el punto función,
máximo (100%), que se puede alcanzar es decir Fi = 70 reemplazando en la formula
tenemos:
𝑷𝑭′ = 𝟒𝟏𝟎 ∗ [ 𝟎. 𝟔𝟓 + 𝟎. 𝟎𝟏 ∗ 𝟕𝟎 ] = 𝟓𝟓𝟑, 𝟓
Por tanto, la funcionalidad del sistema está dada por:
𝑷𝑭
𝑭𝒖𝒏𝒄𝒊𝒐𝒏𝒂𝒍𝒊𝒅𝒂𝒅 = ∗ 𝟏𝟎𝟎
𝑷𝑭′

𝟒𝟔𝟑, 𝟑
𝑭𝒖𝒏𝒄𝒊𝒐𝒏𝒂𝒍𝒊𝒅𝒂𝒅 = ( ) ∗ 𝟏𝟎𝟎
𝟓𝟓𝟑, 𝟓
 Funcionalidad = 84%

Interpretación:

De un 100% un 84% del sistema se concluye que es funcionable, pero un 16% puede
llegar a no ser funcionable.
4.2 MANTENIBILIDAD DEL SISTEMA
Para el procesamiento de datos de la mantenibilidad del sistema, utilizaremos las
medidas directas proporcionadas por la IEEE 982.1 – 1998, el cual propone un índice
de madurez del sistema, que consisten en los cambios que producen, en cada versión
del producto, para lo dicho se tiene la siguiente ecuación.

[𝑴𝑻 − (𝑭𝒂 + 𝑭𝒃 +
𝑰𝑴𝑺 𝑭𝒄)]
(5)
= ��
��
Donde:
IMS = Índice de madurez del sistema.
MT = Número de módulos en la versión actual.
Fa = Número de módulos en la versión actual que se han cambiado. Fb = Número de
módulos en la versión actual que se han añadido.
Fc = Número de módulos en la versión anterior que se han borrado en la versión
actual.
Si el valor del IMS se aproxima a 1, el sistema empieza a estabilizarse. Por lo tanto, los
valores encontrados son:
MT = 6
Fa = 1
Fb = 0
Fc = 0
Reemplazando estos valores en la ecuación (5) se obtiene:

IMS= [𝟔 − (𝟏 + 𝟎 + 𝟎)]
__________________
 6

IMS = 0.83 ∗ 100

IMS = 83%
 Interpretación:
Por lo tanto, se deduce que el índice de madurez del sistema en un 83% tiende a
estabilizarse, lo que indica es el sistema es estable.
4.3 COSTO DEL SISTEMA
Cocomo es uno de los modelos de estimación de costos mejor documentados y
utilizados. El modelo permite determinar el esfuerzo y tiempo que se requiere en un
proyecto de software a partir de una medida del tamaño del mismo expresada en el
número de líneas de código que se estimen generar para la creación del producto
software.
Se debe calcular todos los costos pronosticados asociados al sistema. Para establecer
el costo del software desarrollado, se utiliza el modelo constructivo COCOMO II, que
están orientados a los puntos de función. En la siguiente tabla que se observa la
estimación de puntos de función:
 Parámetro de Medición Cuenta Factor deTotal
Ponderación
Nº de entradas de usuario 6 6 = 36
Nº de salidas de usuario 9 7 = 63
Nº de peticiones de usuario 7 6 = 42
Nº de archivos 4 15 = 60
Nº de interfaces externas 7 10 = 70
Cuenta Total 271

Tabla 4.5: CÁLCULO DE PUNTO FUNCIÓN

Fuente: Elaboración propia
Para el cálculo del factor de complejidad técnica TCF, se toma en cuenta la tabla 4.4,
para considerar la siguiente formula:
TCF = (0.65+0.01*48)

TCF = 1.13

El procesamiento de datos del punto función se basa en la formula siguiente:

PF = Cuenta Total * TCF PF = 410 * 1.16

PF = 475.6

Conversión de los puntos de función a KLDC

Para determinar el esfuerzo nominal en el modelo COCOMO II los puntos función no
ajustados tienen que ser convertidos a miles de líneas de código fuente considerando
el lenguaje de implementación que se muestra en la siguiente tabla.
 LENGUAJE NIVEL FACTOR LDC/PF
CSS 2.5 128
Java 6 53
PHP 11 29

Tabla 4.6: CONVERSIÓN DE PUNTOS DE FUNCIÓN

Fuente: Elaboración propia Obtenemos el valor de LDC con la siguiente fórmula.
LDC = PF * Factor LDC/PF
LDC = 475.6* 29

LDC = 13792.4

Las líneas de código en su totalidad son 13792.4, entonces el número estimado de

líneas de código distribuidas en miles es:
KLCD = LCD / 1000 KLDC = 13792.4 / 1000

KLDC = 13.8

Por tanto, existen 13.8 líneas de código distribuidas para el proyecto.

Ahora se aplican las fórmulas básicas de esfuerzo, tiempo calendario y personal
requerido.
Las ecuaciones del COCOMO básico tienen la siguiente forma:

𝑬 = 𝒂𝒃(𝑲𝑳𝑫𝑪)𝒃𝒃
(6)

𝑫 = 𝒄𝒃𝑬𝒅𝒃
(7)

Donde:
E: Esfuerzo aplicado en personas por mes.
D: Tiempo de desarrollo en meses cronológicos.
KLDC: Número estimado de líneas de código distribuidas (en miles).
 Proyecto de software Ab Bb cb db
Orgánico 2.4 1.05 2.5 0.38
Semi – acoplado 3 1.12 2.5 0.35
Empotrado 3.6 1.2 2.5 0.32

TABLA 4.7: RELACIÓN DE VALORES DEL MODELO COCOMO

FUENTE: ELABORACIÓN PROPIA
En la tabla 4.7 se muestran los tipos de proyectos de software, como este es un
proyecto intermedio, en tamaño y complejidad, se elige semi-acoplado.
Reemplazando los datos en la ecuación (6) se tiene:
E = 3(13.8)1.12

E = 56.73 [programadores/mes]

Reemplazando los datos en la ecuación (7) se tiene:

D = 2.5(56.73)0.35

D = 10.27 [meses]

El personal requerido, en este caso el número de programadores (Nº Prog) se

obtiene con la siguiente fórmula:
Nº Prog = E/D
Nº Prog = 56.73 / 10.27
Nº Prog = 5.5

Nº Prog = 6 [programadores]

El salario de un programador puede oscilar entre los 300 $us, cifra que es tomada en
cuenta para la estimación siguiente:
Costo del software desarrollado por persona = Numero de programadores * salario
de un programador
Costo del software desarrollado por persona = 6 * 300 $us Costo del software
desarrollado por persona = 1800 $us Costo total del software desarrollado =
1800*10.27

Costo total del software desarrollado = 18486 $us

En conclusión, según los resultados obtenidos el proyecto de Sistema de Información

Web para el Control Académico y Económico en el Programa de Educación a
Distancia, se debería concluir aproximadamente en 10 meses y 2 semanas trabajando
6 personas en el desarrollo.
 CONCLUSIONES
De diversas experiencias y evaluación de las tareas desarrolladas en la
implementación del proyecto deseado, se puede concluir que se lograron los objetivos
generales y específicos.
 La base de datos ha sido diseñada e implementada de acuerdo a los
requerimientos para almacenar la información generada en la tienda utilizando
las herramientas actuales, brindando información rápida y confiable.
 Se ha desarrollado un portal de fácil navegación para permitir a los usuarios
realizar sus actividades de una manera amigable fácil.
 Se logró integrar los módulos desarrollados para lograr el sistema de
información con las herramientas adecuadas y propuestas.
RECOMENDACIONES
 Es fundamental capacitar al personal de la tienda en el uso y manejo del
sistema web elaborado.