UNIVERSIDAD AUTÓNOMA DE NUEVO LEÓN

FACULTAD DE INGENIERÍA

MECÁNICA Y ELÉCTRICA

Análisis de Sistemas

Documentación de Análisis

Instructor: Blanca Elizabeth Montemayor Sauceda

Nombre Matrícula Carrera

Eduardo Efrén Cortez Ontiveros 1681213 IAS
Emiliano González Medina 1899211 IAS
Jorge Alain Briones Lucio 1930419 IAS

C.d. Universitaria, San Nicolás de los Garza N.L.,

a martes 22 de noviembre 2022

 Nombre del negocio: HARDSOFT SYSTEMS Analista(s) del sistema: Jesús Daniel
Proyecto: Sistema de información y venta a clientes Fecha de creación: 14/11/2022
Creado por: Roberto Jasso Actualizado por última vez por: Miguel Cruz
Administrador del proyecto: Miguel Cruz Fecha de última actualización: 22/11/2022

1. Fase de definición de alcance

1.1. Identificación de problemas y oportunidades

Partiendo de una solicitud de la empresa de software “Hardsoft Systems”, nuestro equipo de trabajo
ha hecho una evaluación de su actualidad y ha mostrado interés en su proyecto en el que podemos
lograr un mutuo beneficio.

A continuación, presentaremos una tabla informativa con los problemas, oportunidades y directrices.

Problema, oportunidad o directriz Urgencia Visibilidad Prioridad Solución Propuesta

1. El personal a cargo del manejo del Lo más Alta 1 Arreglo rápido, después
sistema no puede generar una entrada pronto nuevo desarrollo
de venta la mayoría de las veces. posible

2. Dificultad para el registro de nuevos 1 mes Alta 2 Nuevo desarrollo

artículos de la tienda en el sistema.

3. Inconsistencia en los datos de clientes 2 meses Alta 3 Nuevo desarrollo

y pedidos.

4. Base de datos desactualizada 4 meses Alta 3 Creación de un nuevo

impidiendo la sincronización de los servidor de base de datos
puntos de ventas con el almacén en la nube y tiempo real
general.

5. Oportunidad de implementar un 8 meses Mediana 4 Nuevo desarrollo para

sistema de compras en línea. implementación en página
web

6. Sistema desactualizado incompatible 6 meses Alta 4 Nuevo desarrollo

con la mayoría de software actual.
1.2. Negociación de alcance

 Se planteaba elaborar el proyecto en base al sistema actual, pero sus funciones han quedado
obsoletas en contra de las nuevas tecnologías y software de desarrollo. Retomando la idea
de partir de un sistema totalmente nuevo.
 El sistema no puede comenzar a desarrollarse sin la aprobación del propietario del sistema.
 Dentro del plazo acordado el objetivo principal es la finalización del sistema del negocio.
 El desarrollo del sistema no puede comenzar hasta tener los reportes de inventario de los
puntos de venta (3).

1.3. Beneficios del proyecto

Este proyecto tiene algunos puntos en contra sobre si vale la pena llevar a cabo un sistema, como
la ubicación de algunos puntos de venta y la baja taza de clientes en comparación a otros años.

Sin embargo, es una marca joven pero competitiva en cuanto a precios de mercado y servicio al
cliente. Lo que supone que elaborar dicho proyecto e implementando otros métodos de compra
disparara los ingresos y alcance de la marca.

Señalando de nuevo, la comunicación entre los negocios establecidos ayudara a evitar un derrame
económico considerable, teniendo la información necesaria desde una base de datos eliminando la
necesidad de comunicarse directamente entre ellas.

Beneficios clave:
1.4. Desarrollo de programa y presupuesto base

El proyecto abarcara dos partes básicas en el sistema. Una de ellas es la de la corrección,

implementación y optimización del sistema principal en todas las tiendas que administrara las
entradas y salidas de productos y efectivo, respectivamente. Así como también el de incorporar
datos fundamentales de los clientes y sus cuentas.

La segunda parte del sistema es la integración de un mercado comercial en línea en la página web
oficial. Proporcionándole a los clientes la posibilidad de adquirir productos de Hardsoft desde
cualquier lugar y hora.

Todo esto estará interconectado con nuestro servidor de base de datos en tiempo real en la que los
empleados seleccionados para el manejo del sistema puedan saber los artículos disponibles en ese
momento y evitar stocks vacíos o de sobre almacenamiento de los mismos.

Se requerirá la cooperación de los propietarios del sistema, así como los administradores y analistas
del sistema para la mayor parte del tiempo invertido en este proyecto. Y se tiene pensado (sujeto a
cambios) que utilicen las herramientas como MySQL para la base de datos y un desarrollo de la
página por PHP.

DEFINICION DE TRABAJO

OPTIMIZACION Y
ADMINISTRACION DE IMPLEMENTACION DE
ADMINISTRACION DE
CLIENTES DEL NEGOCIO COMPRAS EN LINEA
INVENTARIO DEL NEGOCIO

OBJETIVOS DE MEJORA DEL SISTEMA

Este proyecto tendrá una duración de 12 meses y requerirá de un presupuesto de $800,000 pesos.
Los posibles riesgos abarcarían desde costos inesperados hasta la presión del tiempo. Para poder
finalizar sin contratiempos se espera una comunicación clara con los miembros que integran este
proyecto y el menor número de cambios posibles del mismo.
2. Fase de análisis del problema

2.1. Entendimiento del dominio del problema

Teniendo como base el sistema antiguo y las reuniones con el equipo de trabajo y las personas
involucradas en el proyecto, se pudo saber con mayor detalle las funciones y manera de laborar con
el sistema mencionado.

Las ventas son operaciones habituales en la empresa, y deben quedar perfectamente

contabilizadas. Son transacciones que, en el corto y mediano plazo, pueden dar luces sobre la
liquidez y rentabilidad del negocio, y su registro es de gran importancia a la hora de declarar el
impuesto a la renta. En otras palabras, para mantener una buena salud financiera es fundamental
registrar las ventas debidamente.

En el caso de los pagos al contado, el asiento es bastante sencillo de realizar:

 Ingresa un débito a la cuenta de caja por el valor de la transacción, más el importe del IVA
en caso de que sea una venta gravada.
 Ingresa un crédito a la cuenta de Ventas por el mismo precio.

Luego, asigna las respectivas glosas que identifiquen el documento y evidencien el monto de la
operación y referencia el IVA, en caso de que se trate de una venta gravada con dicho impuesto.

El proceso de la venta está realizado de manera correcta, sin embargo, estas entradas con
frecuencia no logran registrarse cuando se requiere, congelando el sistema y teniendo que reiniciar
el equipo. También todo lo registrado queda guardado en una base de datos únicamente para los
equipos del punto de venta, no compartiendo la información con las demás tiendas existentes.

Además, tampoco hay una sincronización con el almacén principal, no pudiendo notificar números
bajos de stocks, devoluciones, y/o la no disponibilidad de mercancía. Teniendo que esperar la
finalización de semana para elaborar el reporte de ventas e inventario de cada tienda y enviarlo al
almacén.
Debajo se muestra un sencillo diagrama de contexto de cómo funciona actualmente la empresa.

2.2. Análisis de problemas y oportunidades

En base a los comentarios y observaciones de los propietarios del sistema y analistas de sistema
respectivamente, se ha encontrado que el programa no cumple con las demandas actuales del
negocio y requiere una actualización y optimización para solventar los siguientes problemas:

 Perdidas Económicas
Los artículos presentes en su bodega permanecen durante mucho tiempo almacenados,
dando poco movimiento a estos y dejando la inversión congelada.
 Perder una venta, y un cliente, por no contar con el stock requerido
Se solicita un producto y el punto de venta no cuenta en la bodega con existencias. Se pierde
una venta y la posibilidad de contar con un cliente fidelizado.
  Poca sincronización entre todos los puntos de venta
Se tiene un sistema local para cada punto de venta, no teniendo un control exacto de
mercancías disponibles.
 No hay un listado detallado de los clientes en el sistema
La base de datos no proporciona los datos completos y necesarios para la administración de
los clientes, sus compras y/o cuentas por cobrar.
 Dos sistemas para el control de inventario y control de gastos de servicios
Se duplican los costos de mantenimiento para dos sistemas que pueden ser uno solo.

Dado que los costos de estos cambios en el sistema no sobrepasan el presupuesto establecido se
puede continuar con el proyecto.

2.3. Análisis de los procesos del negocio

Debido a que es necesario el rediseño del proceso del negocio, se han realizado unos cambios en
el mismo, facilitando la entrada de las ventas, así como la sincronización en tiempo real tanto de los
puntos de venta y la tienda en línea con el servidor principal, que a su vez llevar la información a la
base de datos del almacén, devolviendo el inventario actualizado a los puntos de venta y base de
datos de la tienda web.
2.4. Establecer objetivos de mejora del sistema

 Eliminar el problema sobre la entrada de una venta en el sistema.

 Aumentar la eficiencia del sistema y que sea compatible con software actuales.
 Eliminar la necesidad de informes semanales manualmente entre puntos de venta y almacén.
 Mejora económica del negocio.
 Dar más movimiento a inventario disponible.
 Implementar un apartado de ventas online.
 Comunicación rápida de los puntos de venta y tienda online con almacén general.

Restricciones identificables.

 El nuevo sistema debe estar operativo para el 8 de mayo del 2024.

 La tienda en línea deberá estar operativa para el 2 de agosto de 2024
 La finalización del proyecto debe estar para el 20 de noviembre de 2024
 El costo del sistema no puede costar más de $510,000 pesos
 El nuevo sistema debe estar en línea y todos deben utilizar un sistema de administración de
base de datos MySQL.

2.5. Actualizar plan del proyecto

Programa: El nuevo sistema avanza sin demoras y sigue el esquema de tiempos esperado, no
teniendo de momento la necesidad de solicitar más tiempo para su finalización.

Costo: Al estar ligado con el programa, no ha habido gastos inesperados hasta la fase actual del
proyecto, pudiendo avanzar sin problemas.

Tecnología: Pudiendo comenzar a realizar una base de datos el sistema antiguo del negocio no
era compatible con este, y se ha tenido que continuar con el desarrollo de un sistema nuevo.

Política:

 Conteo continuo de stock: Este sistema de inventario se realiza a lo largo del año de
acuerdo con un plan de acción predeterminado y los artículos pueden ser contados a diario.
Esto implica un registro perpetuo de conteo para cada artículo mostrando todas las
transacciones, lo que permite que todas las validaciones sean completadas.
 Las investigaciones con respecto a las discrepancias pueden extenderse a lo largo del año
y, por tanto, se puede conseguir un análisis exhaustivo adecuado. Las cuentas de fin de año
también se pueden preparar con rapidez si la validación continua se ha cumplido de acuerdo
con un plan predeterminado.
El impacto debería ser mínimo, o no haber impacto, en las operaciones de las tiendas que
llevan a cabo un conteo continuo de stock a lo largo del año. Cualquier control puede
completarse de forma periódica en este tipo de conteo mediante informes y las anomalías
pueden ser identificadas.
 Validación de stock agotado: Este método de validación del stock se lleva a cabo cuando
un artículo en particular está fuera de stock o los niveles de stock del mismo son
excesivamente bajos. Este tipo de validación se hace generalmente por personal interno. Las
existencias que están fuera de stock son registradas y reordenadas, y se identifican las
razones por las que se ha producido esa falta de stock para asegurar que el problema no se
repita.

Alcance: El sistema sigue los límites establecidos, solo solicitando una aclaración de opciones
futuras para posibles puntos de venta nuevos, sin embargo, este caso aplicara solo al terminar el
proyecto y elaborándolo en un proyecto nuevo.

3. Fase de análisis de requerimientos

3.1. Identificar los requerimientos del sistema

Ya que el análisis de los problemas está definido, el siguiente paso es definir y priorizar los
requerimientos que tendrá el sistema. Ya que este sistema estará solo enfocado para los
propietarios del sistema y empleados que lo manejaran, el analista solo concentro en este círculo
del negocio y preguntó sobre que otras capacidades deben implementarse al nuevo sistema.

Terminando con las entrevistas, los requerimientos pueden definirse para tener al menos una idea
más aproximada de las necesidades del sistema, siendo estas:

 Poder tener un control detallado de todos los productos que comercializa. El sistema se
encargará de organizar las existencias, identificando cuáles son los artículos que realmente
necesita de acuerdo a la demanda que tenga, ayudándole a ahorrar dinero cuando tiene que
efectuar los pedidos.
  Al permitir que todos los usuarios que la empresa considere necesarios puedan ingresar al
software de inventarios desde el lugar que se necesite, se garantiza que la información se
centralice en un solo sistema y de esta manera todos los integrantes de la compañía sepan
en tiempo real, y en la nube, cómo se está comportando el inventario general.

 El software de inventarios debe alertar cuando las unidades disponibles estén llegando al
límite y sea necesario realizar un pedido.

 Poder contar con información al momento de los clientes, (Nombre, Dirección Postal, Email,
Teléfono) que tiene el negocio, así como sus adeudos pendientes.

 Implementación de compras en página web de la empresa.

DEFINICION DE REQUERIMIENTOS

REQUERIMIENTOS
REQUERIMIENTOS REQUERIMIENTOS REQUERIMIENTOS DE INFERFAZ DE
DE CONTROL DE DE SISTEMA EN DE INFORMACION WEB DEL
PRODUCTOS TIEMPO REAL DE CLIENTES NEGOCIO Y DEL
SISTEMA

En la siguiente página se mostrará una lista parcial de los casos de uso detallada junto a un
diagrama de los casos para poder ofrecer una comprensión mejor de lo que llevará a cabo en el
proyecto.
Identificación de Actores:

 Miembro potencial
 Miembro del club
 Ex miembro
 Centro de distribución
 Cuentas por cobrar

Lista parcial de los casos de uso:

Nombre del caso Descripción del caso de uso Actores y papeles participantes
de uso
Ingresar una En la compra de mercancía de la tienda con plazos  Miembro potencial (negocio primario)
orden de mayor o igual a 12 meses, acepta ser cliente regular  Centro de distribución (receptor externo)
suscripción del establecimiento, obteniendo también ofertas y
descuentos únicos dentro de los puntos de venta.

Ingresar una En la compra de mercancía de la tienda con plazos  Ex miembro (negocio primario)
orden de mayor o igual a 12 meses, acepta ser cliente regular  Centro de distribución (receptor externo)
renovación de del establecimiento, obteniendo también ofertas y
suscripción descuentos únicos dentro de los puntos de venta.

Ingresar los Ingresa cambios de su perfil, tales como dirección  Miembro del club (negocio primario)
cambios de perfil postal,
del miembro la dirección de e-mail y teléfono.

Colocar una Un miembro del club ingresa una orden para los  Miembro del club (negocio primario)
nueva orden productos de Hardsoft.  Centro de distribución (receptor externo)
 Cuentas por pagar/Cuentas por cobrar
(servidor externo)
Revisar la orden Un miembro del club que revisa una orden colocada  Miembro del club (negocio primario)
previamente. (La orden no debe haber sido  Centro de distribución (receptor externo)
mandada.)  Cuentas por pagar/Cuentas por cobrar
(servidor externo)
Cancelación de Un miembro del club que cancela una orden  Miembro del club (negocio primario)
orden previamente  Centro de distribución (receptor externo)
colocada. (La orden no debe haberse mandado.)  Cuentas por pagar/Cuentas por cobrar
(servidor externo)
Hacer una Un miembro del club que ve los productos para una  Miembro del club (negocio primario)
investigación de posible compra.
producto

Hacer una Un miembro del club que ve su historial de compra.  Miembro del club (negocio primario)
investigación
del historial de la
compra
Diagrama de casos de uso:

Subsistema de ordenes Subsistema de operaciones

Colocar nueva
orden Inicia Hacer una
Miembro del club investigación del
Inicia
historial de
compras
Revisar la Inicia
orden

Inicia
Cancelar la
orden
Inicia

Hacer una
investigación
del producto
Inicia
Miembro potencial

Subsistema de suscripciones

Ingresar los
cambios del
perfil de los
miembros Inicia

Ingresar una
orden de
suscripción

Ex miembro

Ingresar una Inicia

nueva orden de
renovación de
suscripción
3.2. Priorización de los requerimientos del sistema

REQUERIMIENTOS OBLIGATORIOS REQUERIMIENTOS DESEABLES

 La función correcta del sistema para  Implementar compras en plazos llevando
entrada de ventas, actualización del seguimiento de la cuenta del cliente
inventario  Implementar el registro de ventas del
 Apartado de registro de clientes mercado online en el servidor del
 El sistema debe estar enlazado al sistema
servidor de base de datos nuevo  Alertas de stocks vacíos y elaboración de
 El sistema debe mantener actualizada la informes semanales y mensuales de
información de inventario y costos del inventario
almacén
 Comunicación entre puntos de venta

3.3. Actualizar plan de proyecto

Programa: El nuevo sistema se desarrollará enfocado a objetos, utilizando el programa de

PowerBuilder 2022 y la página web utilizará el lenguaje de codigo abierto PHP, dando así la facilidad
de maniobra en el desarrollo del sistema todo enlazado al servidor de base de datos basado en
MySQL.

Costo: Al estar ligado con el programa, no ha habido gastos inesperados hasta la fase actual del
proyecto, pudiendo avanzar sin problemas.

Tecnología: La base de datos comienza a tomar forma, llevando a cabo una serie de entrevistas e
identificando los actores, definiendo los procesos del sistema y datos que ingresaran y administraran
dentro del mismo.

Política: El sistema no tendrá cambios con las técnicas seleccionadas anteriormente para el plan
determinado. Siguiendo utilizando el conteo continuo de stock y validación de stock agotado.
4. Fase de diseño lógico

4.1. Requerimientos funcionales de estructura

Entre los posibles requerimientos funcionales del sistema, se incluyen:

 Descripciones de los datos a ser ingresados en el sistema.

 Descripciones de las operaciones a ser realizadas por cada pantalla.
 Descripción de los flujos de trabajo realizados por el sistema.
 Descripción de los reportes del sistema y otras salidas.
 Definición de quien puede ingresar datos en el sistema.
 Como el sistema cumplirá los reglamentos y regulaciones de sector.

Requerimientos funcionales detallados:

 El sistema actualizara el apartado de ventas cuando se registre alguna de las siguientes

transacciones: pedido de venta de cliente, despacho de mercancía al cliente, emisión de
factura a cliente y registro de pago de cliente.
 Al aprobar un pedido, la solicitud pasará al siguiente paso del flujo de trabajo (workflow) de
aprobación configurado en el sistema.
 El sistema permitirá aprobar, cambiar o actualizar información de los clientes.
 El sistema permitirá el envío automatizado de cartas de entrega de órdenes directamente al
almacén.
 A cada orden se le asignará un identificador único, que será utilizado para identificarla en
todos los procesos subsecuentes que se realicen sobre esta.
 Al ingresar ordenes de entrega, toda orden de entrega estará asociada a un pedido de venta.
 La facturación de pedidos de venta se realizará en lotes, por medio de una pantalla de
pedidos pendientes de facturación, la cual mostrará los pedidos no facturados. Una vez
facturados los pedidos no se mostrarán en esta lista.
 El sistema también permitirá el registro de facturas manuales no asociadas a pedidos, sin
embargo, estas requerirán autorización por parte del grupo de Gerentes antes de ser
contabilizadas.
  Los elementos de la solicitud de cotización serán los mismos de la requisición asociada, al
igual que los de la orden de compra. El sistema permitirá la emisión de solicitudes de
cotización y órdenes de compra parciales.
 La contabilización de transacciones de facturas de venta y facturas de compra podrá
configurarse para realizarse de forma automatizada a su registro, o manualmente en lotes
(Proceso Batch).
 El software debe poder emitir los siguientes estados financieros: Balance general, Estado de
ganancias y pérdidas, Estado de flujos de efectivo.
 El sistema bloqueara pedidos de artículos con stock bajo hasta la actualización de los
mismos.
4.2. Validación de requerimientos funcionales

Los criterios de éxito están definidos en términos del negocio y sus objetivos, lo cual nos permitirá
medir los parámetros que usaremos para nuestros prototipos.

Los requerimientos funcionales han sido presentados y evaluados por los propietarios del sistema,
dueños y usuarios que utilizaran, no teniendo objeciones y pudiendo pasar a proceder con los
requerimientos acordados.

Usuarios: Al interactuar con el sistema en fase temprana y dando un reporte detallado de los
apartados y características del sistema, los usuarios están de acuerdo con lo mostrado y seguirán
estando disponibles para futuros cambios y seguir el proceso de desarrollo no saliendo del alcance
establecido.

Además, se ha presentado también un modelado de datos (base) con el que se puede empezar a
trabajar mostrando las descripciones de entidad relación el diagrama de procesos que tendrá. Así
como también un modelo de procesos funcional para el sistema tanto presente en los puntos de
venta como para el del mercado en línea. Quedando muy contentos con lo mostrado y pudiendo
avanzar con el proyecto.
MODELADO DE DATOS

DIAGRAMA Y DESCRIPCIONES ENTIDAD-RELACION

MODELADO DE PROCESOS
DIAGRAMA DE PROCESOS
IMPLEMENTACION PARA SISTEMA EN PUNTOS DE VENTA Y MERCADO EN LINEA
5. Fase de análisis de decisión

5.1. Identificar soluciones alternativas

Se ha llevado a cabo una lluvia de ideas sobre cómo debe funcionar específicamente el sistema,
hacia donde quiere ser llevado y como debe ser el producto final del mismo.

Para el tipo de Gestión de la base de datos se ha discutido sobre dos posibles soluciones.

 DBMS Orientado a Objetos

 DBMS Relacional

El proceso de compra está un poco más decidido, sin embargo, no está mal considerar otros
procesos en los que se mencionan:

 Empresa comercial
 Empresa de servicios

Para la arquitectura de la base de datos se ha decidido en grupo que base en la estructura de

MySQL.

En el tema de la solución de software para la aplicación se tienen demasiadas opciones, todas estas
con su respectiva ventaja, estas se discutirán más detalladamente en fases futuras del proyecto y
contando también con que nuestro equipo tenga el conocimiento necesario para usar alguna de
estas.

5.2. Analizar soluciones alternativas

1. Gestión de base de datos

a. DBMS Orientado a Objetos
Almacena los datos y los procedimientos que realizan oraciones sobre estos datos como
objetos que se puedan recuperar y compartir de manera automática.
b. DBMS Relacional
Organiza los datos en tablas que se pueden vincular internamente según los datos
compartidos. Esto permite que un usuario recupere fácilmente una o más tablas con una
sola consulta. Se puede aprovechar este modelo para procesar compras y realizar un
seguimiento del inventario.
2. Proceso de compra
a. Empresa comercial
Es un modelo donde compran artículos terminados para posteriormente revenderlos a un
precio superior y obtener de esa manera una ganancia. Consiste en la contabilización de
inventarios y tienen sólo inventarios de artículos terminados y disponibles para la venta.
b. Empresa de servicios
Manejan únicamente inventario de materiales y suministros necesarios para la prestación
del servicio.
3. Arquitectura de base de datos
Es un software de código abierto, lo que significa que puede ser usado libremente y
modificarlo a voluntad. Además, de ofrecer una versión comercial que da más flexibilidad
beneficio de un soporte adicional. La otra peculiaridad de MySQL es su modelo cliente-
servidor. Funciona de la siguiente manera: siempre que los clientes necesitan acceder a los
datos, se conectan al servidor de la base de datos.
4. Software de aplicación
a. Solución de software de paquete
Aunque existen diversas ventajas y desventajas del software de paquete, estos tipos de
tecnología de la información son los sistemas más antiguos que utilizan las
organizaciones, y que facilitan sus tareas diarias. Existen distintos tipos de paquetes
enfocados a varios puntos específicos.
b. Solución personalizada
Se utiliza si en dado caso necesitamos más de un paquete de software para distintos
procesos que llevara el sistema. En ocasiones se deberá dar más mantenimiento y
desarrollo con esta opción al combinar distintos paquetes y mantener su funcionamiento
óptimo.
5.3. Comparar soluciones alternativas

CARACTERISTICAS ALTERNATIVA 1 ALTERNATIVA 2

DBMS orientado a objetos, tipo DBMS relacional, organización
de solución de gestión de datos sencilla de tablas que pueden
Tipo de software para la donde las entidades representan vincular internamente según los
gestión de base de datos en objetos y se almacenan en la datos compartidos.
base de datos de la memoria.

Empresa comercial, compran Empresa de servicios, utilizan

artículos terminados para únicamente inventario de
Proceso de compra posteriormente revenderlos a un materiales y suministros
precio superior y obtener de esa necesarios para la prestación de
manera una ganancia. un servicio.
MySQL, flexible, de codigo
Arquitectura de base de abierto, adaptable a necesidades Lo mismo que la alternativa 1.
datos del negocio.

Software de aplicación Solución personalizada Solución de software de

paquete.
 Proporciona un entorno de  Reducción de tiempo en
programación unificado y manejo de inventario.
compatible con distintos  Permite relaciones más
lenguajes con los que simplificadas entre
programar, como JAVA, C++, entidades.
Beneficios .NET, Visual Basic y PHP  Costes mejores al enfocarse
para diseño web. en una sola solución de
 Mejora económica disparada software.
en corto plazo.
 Eficacia en el manejo de
inventario.
5.4. Actualizar plan el proyecto

Programa: El nuevo sistema se desarrollará enfocado a objetos, utilizando el programa de

PowerBuilder 2022 y la página web utilizará el lenguaje de codigo abierto PHP, dando así la facilidad
de maniobra en el desarrollo del sistema todo enlazado al servidor de base de datos basado en
MySQL.

Costo: Al estar ligado con el programa, no ha habido gastos inesperados hasta la fase actual del
proyecto, pudiendo avanzar sin problemas.

Tecnología: La base de datos está en una fase media y avanzando sin complicaciones, ingresando
la información del antiguo sistema para ofrecer un sistema de muestra para que los usuarios puedan
utilizar e informar de posibles cambios en los apartados y funcionamiento.

Se ha comenzado ya con la elaboración de la tienda en línea teniendo los requerimientos que

utilizara y un diseño visual temprano.

Política: El sistema no tendrá cambios con las técnicas seleccionadas anteriormente para el plan
determinado. Siguiendo utilizando el conteo continuo de stock y validación de stock agotado.

5.5 Recomendación de solución del sistema

Después de una comparativa de las soluciones alternas y reevaluando lo que necesita la empresa
realmente se ha decidido avanzar con la alternativa 1. Enfocando en un sistema orientado a objetos,
ya que permite trabajar en equipo gracias al encapsulamiento, puesto que minimiza la posibilidad
de duplicar funciones cuando distintas personas trabajan sobre un mismo objeto al mismo tiempo.

El proceso de compra de una empresa comercial es el mejor para este sistema, enfocado en la
compra de inventario a proveedores y la reventa de los artículos para obtener la ganancia que
espera la empresa.

Además, la arquitectura en base a SQL ofrece bastante flexibilidad en cuanto al manejo de

conexiones con distintos sistemas, y con un desarrollo de software personalizado podemos
aprovechar distintos paquetes con sus funciones específicas como: Software de aplicación y
Software de Gestión.