Proyecto Final de Procesos - Final PDF

Universidad Politécnica de Pachuca
Procesos de Desarrollo de Software
Jazmín Rodríguez Flores
Jorge Ángel Díaz Mera

Marco Antonio Rosas Bárcenas
Alma Estefanía Vera Camacho
Segundo cuatrimestre
Grupo 80312
Martes 9 de abril de 2019.
2
Abstract
The principal reason to write this project is to demostrate and explain what is
the process of development for the restaurant Deli House. The following
pages explain in detail what you have to do in each phase of the WaterFall
Model, in which the outcome of one phase acts as the input for the next phase
sequentially. The phases include the initiation, analysis and design,
construction, production/implementation and maintenance.
While working on this Project with this methodology, everyone notice that if
something was wrong we could not pass to the next and we have have to start
all again. We use differents softwares like Pencil, Enterprise Architect and
Publisher to help us do the interfaces, use case and scenarios to understand
what were the principal things and how they interact with eachother and how
some of them depend of others, the elaboration of the system was think to be
develop in Java because it is very common plataforma to develop an app
Form in an independent way of any kind of interet conexión. The time of
development of the system will be of 3 months.
3
Resumen
La razón principal para escribir este proyecto es para mostrar y explicar el

proceso de desarrollo de un proyecto de software para el restaurante Deli
House. Las siguientes páginas explican a detalle que se debe de hacer en
cada fase del modelo de Cascada, en la que la fase siguiente depende de la
terminación de la anterior de manera secuencial. Las fases incluyen la etapa
de comunicación, planeación, modelado, construcción y despliegue.
Al estar trabajando con esta metodología se puede notar que, si algo está
mal, no se podía pasar a la siguiente fase y se debía empezar todo desde
cero. Se usaron diferentes herramientas para la elaboración como lo fue
Pencil, Enterprise Architect y Publisher para el diseño de interfaces, casos de
uso y escenarios, para tener un mayor entendimiento de como interactuaban
entre sí y como unas dependían de otras, la elaboración del sistema se pensó
desarrollar en el lenguaje de Java al ser un entorno muy común de desarrollo
para poder crear una aplicación de tipo Form independiente de cualquier tipo
de conexión por red. El tiempo de elaboración del sistema será de 3 meses.
La métrica utilizada fue la de ambigüedad para poder saber qué requisitos
eran entendibles y cuáles no.
Contenido
ABSTRACT ........................................................................................................ 2
RESUMEN ......................................................................................................... 3
JUSTIFICACIÓN ................................................................................................ 6
DESCRIPCIÓN DETALLADA DE LAS ETAPAS ................................................ 7
1. COMUNICACIÓN ..................................................................................... 7
1.1 Inicio .............................................................................................................. 7

1.1.1 Recabar requisitos ...................................................................................... 7
1.1.2 Requisitos funcionales (IEEE 830) ............................................................. 7
1.1.2.2.1 Propósito ............................................................................................... 10

1.2.1 Métrica de ambigüedad ............................................................................ 31
1.3 Representación ............................................................................................... 33

1.3.1 Diagrama de actividades .......................................................................... 34
2. PLANEACIÓN ........................................................................................ 35
2.1 Cronograma de actividades............................................................................. 35
2.2 Estimación ....................................................................................................... 36

2.2.1 Infraestructura para la implementación del desarrollo de software ........... 37
3. MODELADO ........................................................................................... 38
3.1 Análisis ............................................................................................................ 38
3.1.1 ESCENARIOS DE CASOS DE USO DEL USUARIO ADMINISTRADOR38

5
Flujo normal ....................................................................................................... 38

3.1.2 Escenarios de casos de uso del usuario Vendedor .................................. 44
Flujo normal ....................................................................................................... 44
3.2Modelado de datos ........................................................................................... 48

3.2.1 Diagrama de Entidad-Relación. ................................................................ 48
4.CONSTRUCCIÓN ......................................................................................... 53
4.1 Código ............................................................................................................. 53
4.2 Pruebas ........................................................................................................... 53
5. DESPLIEGUE .............................................................................................. 54
5.1 Entrega ............................................................................................................ 54
5.2 Asistencia ........................................................................................................ 54
5.3 Retroalimentación ........................................................................................... 54
5.4 Evaluación ....................................................................................................... 54
CONCLUSIÓN ................................................................................................. 55
Lecciones aprendidas ........................................................................................... 55
ANEXO A. CAPTURAS DEL DISEÑO ............................................................. 57
ANEXO 2 .......................................................................................................... 72
6
Justificación
Se eligió la metodología de cascada, porque aparte de tener mucho tiempo

para la entrega, es un modelo fácil de entender y de usar. Muy rara vez se
presentan errores ya que los procesos de revisión facilitan su cumplimiento.
Esta metodología ayuda a tener una mejor comprensión de los
requerimientos; en nuestro caso, los requerimientos estuvieron claros desde
el principio, no hubo un existente de problemas de acceso o comprensión de
tecnología. Al igual que esta metodología nos permitía tener más
documentación para poder entender de mejor manera lo que se estaba
haciendo y lo que se iba a realizar, para poder tener más control en la
terminación de las etapas y lo que se hace en cada una. Al igual que desde
el inicio se tuvo claro lo que se iba hacer y lo que el cliente necesitaba y nos
adecuamos a lo que el cliente ya tenía a su disposición en el lugar en el que
se iba a usar el software en cuestión.
7
Descripción detallada de las etapas
1. Comunicación
La etapa de comunicación se divide en tres partes inicio, requisitos y

representación. Para obtener los requisitos funcionales y no funcionales se
requiere realizar una entrevista para poder saber qué es lo que el cliente quiere
y necesita para su negocio, de acuerdo a la entrevista, se recaban los requisitos
funcionales y no funcionales para poder representarlos y poder realizar las
siguientes etapas.
1.1 Inicio
Se realizó una entrevista para obtener los requisitos. Fueron 3x

preguntas, que se pueden observar en el anexo 2.
1.1.1 Recabar requisitos
Se utilizó el formato IEEE830 para la representación de

requisito
1.1.2 Requisitos funcionales (IEEE 830)

8
Especificación de requisitos de software

Proyecto: Deli House
Revisión 1
9
Abril
1.1.2.1 Historial de Revisiones
Fecha Revisión Descripción Autor
25-01-2019 1.0 Inicio del proyecto Marco Antonio Rosas

Barcenas
Alma Estefanía Vera
Camacho
Jorge Ángel Díaz Mera
9/04/2019 2.0 Revisión 2 JRF
Documento validado por las partes en fecha: 25-01-2019
Por el cliente Por la empresa suministradora

-----------------
MFA .CO
Fdo. D./ Dña [Nombre] Fdo. D./Dña. Jorge Ángel Diaz Mera
Deli House Rev. [99.99]
Especificación de requisitos de software Pág. 10
1.1.2.2. Introducción
Este documento es una Especificación de Requisitos Software (ERS) para el
Sistema de información para la gestión de procesos y control de inventarios. El
software será desarrollado con java e implementará una BD de MySQL como gestor
de datos.
El Proyecto de Deli House tiene como objetivo proporcionar un servicio de control,

administración al manejo del establecimiento.
La especificación se ha estructurado basándose en las directrices dadas por el

estándar IEEE ANSI/IEEE 830, 1998.
1.1.2.2.1 Propósito
El presente documento tiene como propósito definir las especificaciones

funcionales, no funcionales para el desarrollo de un sistema de control
de negocio que será desarrollado para el establecimiento de Deli
House, que permitirá gestionar distintos procesos administrativos. Éste
será utilizado por empleados del establecimiento y por el propietario del
negocio.
1.1.2.2.2 Alcance
La especificación de requisitos está dirigida al usuario del sistema, para

la administración del negocio y para profundizar en la automatización
de ésta, la cual tiene por objetivo principal el gestionar los distintos
procesos administrativos (Inventario, Eventos, Información) y
financieros del establecimiento.
11
El sistema realizará la venta de productos y administración de clientes,

empleados y administración de inventario. El sistema no podrá realizar
facturación electrónica.
1.1.2.2.3 Personal involucrado

Nombre Jorge Ángel Diaz Mera
Rol Analista, Diseñador, Programador
Categoría Ing. Software
profesional
Responsabilidades Análisis de información, Diseño y Programación
del software
Información de angel_diaz_mera@outlook.com
contacto
Nombre Alma Estefanía Vera Camacho

Rol Analista, Diseñador, Programador
Categoría Ing. software
profesional
del software
Información de fanyverac58@gmail.com
contacto
Nombre Marco Antonio Rosas Barcenas

Rol Ing. Software
Categoría Ing. software
profesional
del software
Información de Antonio152.ma@gmail.com
contacto
1.1.2.2.4 Definiciones, acrónimos y abreviaturas

Nombre Descripción
Usuario Persona que usará el sistema para gestionar
procesos
ERS Especificación de Requisitos Software
RF Requerimiento Funcional
12
RNF Requerimiento No Funcional

CU Casos de uso
Moodle Aula Virtual
1.1.2.2.5 Referencias
Titulo del Referencia
Documento
Standard IEEE 830 - IEEE
1998
Anexo 2 Entrevista al cliente
1.1.2.2.6 Resumen
Se describen los requisitos funcionles y nofuncionales mediante la

metodología cscada para un restaurnt DELI house.
1.1.2.3 Descripción general
1.1.2.3.1 Perspectiva del producto
Se trata de un proyecto portable y modular independiente programado

en el lenguaje de Java teniendo como administración de datos un
gestor de BD MySQL con tendencia evolutiva, que permite el uso del
software en diversos sistemas operativos y agilizando el proceso de
ventas con herramientas para su control de inventario. Dicho proyecto
trata de solventar la problemática de automatización y uso de la
tecnología en el control de ventas en el negocio con el motivo de hacer
el proceso más eficaz.
1.1.2.3.2 Funcionalidad del producto

13
Figura 1. Casos de uso del vendedor
Figura 2. Casos de Uso del proyecto

14
El software realizara el manejo y administración de inventario del lugar,

así como la realización de algunas operaciones adicionales de gestión
de finanzas del establecimiento.
El sistema se encuentra dividido en módulos, lo que lo hace eficiente

el tiempo de respuesta, donde cada módulo realiza una acción
específica. Elaborado en el lenguaje de programación “Java” con la
implementación de una base de datos con MySQL gracias “XAMPP”.
Los submódulos se dividen en
a) Control de cocina.
Consiste en ayuda en el control del tiempo de elaboración de

platillos.
b) Control de ganancias.
El módulo realiza el cálculo de las ganancias del día, así mismo

en él, se puede realizar el corte de caja, según lo solicitado.
c) Control de inventario
El sistema se encuentra conectado con una base de datos, la

cual almacena los productos del establecimiento, registrándolos
según el usuario lo decida.
Dentro de la conexión de base de datos no solo se pueden

realizar el registro de los productos, sino también realiza bajas
y modificaciones.
15
1.1.2.3.3 Características de los usuarios
Tipo de usuario Administrador
Formación Ing. Software
Habilidades Administración de datos
Actividades Manejo del restaurante, control de cierre de caja.
Tipo de usuario Vendedor
Formación Vendedor/ Comerciante
Habilidades Administración de recursos económicos
Actividades Control de ganancias del establecimiento
1.1.2.3.4 Restricciones
-Solo se puede registrar un cliente a la vez
-Solo el administrador realiza corte de caja
-Si no se hizo corte de caja y se intenta cerrar el programa, avisar si

desea hacerlo
1.1.2.3.5 Suposiciones y dependencias
 El sistema operativo en el que el software será ejecutado debe de

cumplir los requisitos antes indicados para garantizar una ejecución
correcta de la misma.
 El software depende del gestor de BD para un correcto

funcionamiento.
16
1.1.2.3.6 Evolución previsible del sistema
-Control de tiempo en la elaboración de consumibles.
-Interoperabilidad del software.
-Facturación electrónica
1.1.2.4. Requisitos específicos
1.1.2.4.1 Requisitos Funcionales

12 de marzo del 2019
Número de requisito 1
Nombre de requisito Iniciar sesión como vendedor o administrador
Tipo Requisito
Fuente del requisito Cuestionario
Prioridad del requisito Alta/Esencial
Riesgo del requisito Bajo
Dependencias
o Al ejecutar el sistema el usuario debe de identificarse para poder

utilizar alguna de las funcionalidades del mismo.
Nombre de requisito Buscar existencia del cliente en la base de datos
Tipo Requisito
Dependencias RF 3, RF4, RF5,
o Durante el registro de algún cliente a la base de datos, el

programa lanzara un mensaje de alerta si este ya se
encuentra registrado.
17
Nombre de requisito Dar de alta al cliente en caso de no existir en la base
de datos
Tipo Requisito
o Si el cliente no se encuentra registrado en el

establecimiento
Nombre de requisito Si el cliente está registrado, registrar el pago por
anticipado
Tipo Requisito
o Si el cliente se encuentra en la base de datos, este podrá
realizar el pago de las comidas por anticipado.
Nombre de requisito Avisar cuando se acabe los créditos del cliente
Tipo Requisito
o Durante la compra de una comida en el establecimiento, el
sistema mandara un mensaje de alerta si el cliente que
compro, sus créditos están por agotarse o se agotaron.
Nombre de requisito Dar de alta al producto que se va a vender
18
Tipo Requisito
o Todos los productos que se venden se van registrando en

la BD, en caso de inexistencia se dará de alta en la BD.
Número de requisito 6.1

Nombre de requisito Insertar cantidad a vender del producto
Tipo Requisito
o Durante la venta de algún artículo se debe de ingresar la
cantidad del producto o las unidades que se venderán.
Nombre de requisito Calcular el precio de venta de cada producto
Tipo Requisito
o Se calcula el precio de cada producto antes de que este
sea vendido al cliente.
Nombre de requisito Mostrar un subtotal por producto dependiendo de la
cantidad y precio unitario del producto
Tipo Requisito
Dependencias RF 6, RF6.1
19
o Se determina el precio del producto dependiendo el precio

del mismo.

Nombre de requisito Mostrar el total a pagar
Tipo Requisito
Dependencias RF 8
o El sistema indica en la pantalla el total a pagar al cliente.
Nombre de requisito Especificar la mesa de donde proviene la orden
Tipo Requisito
Prioridad del requisito Baja
Riesgo del requisito Medio
Dependencias
o El sistema almacenara la orden e indicara en que mesa se
debe de entregar.
Nombre de requisito Especificar si hubo algún retiro de caja y el porqué
Tipo Requisito
Dependencias
o Cualquier retiro que se haga debe de ser reportado y se

deberá describir el motivo del retiro.
20
Nombre de requisito Contar con un temporizador que inicie al tomar la
orden
Tipo Requisito
Prioridad del requisito Media
Dependencias
o Por cada orden registrada en el sistema el programa
ejecutara un temporizador con un estimado de tiempo en
el que se debe de entregar la orden.
Nombre de requisito Avisar cuando la orden ha demorado más de 15
minutos
Tipo Requisito
Dependencias RF 11
o El sistema imprime en pantalla un mensaje de alerta
cuando un platillo lleva mucho tiempo de espera, esto
después de pasados 15 min.
Nombre de requisito Debe seleccionarse una opción de "orden entregada"
Tipo Requisito
Dependencias RF 11
21
o Cuando se entrega la orden solicitada al cliente, el

empleado debe de registrar en el sistema que se entregó
la orden.
Nombre de requisito Guardar en una base de datos todas las órdenes y
cantidades vendidas de cada platillo diariamente
Tipo Requisito
Prioridad del requisito Alta
Riesgo del requisito Alto
Dependencias RF 6, RF6.1, RF 7, RF 8, RF9
o Cada orden solicitada en el día debe ser almacenada en la

BD, asi como la cantidad solicitada del articulo o las
unidades que se vendieron, para que al final del día se
pueda realizar el corte de caja correctamente.
Nombre de requisito Dar acceso al administrador para ver las órdenes
realizadas durante el día
Tipo Requisito
Dependencias RF 14, RF 11, RF 1
o El administrador tendrá los permisos para acceder a los

registros de la BD para poder calcular o generar el reporte
de corte de caja
Nombre de requisito Mostrar al administrador de dónde provino cada
orden y la hora
22
Tipo Requisito
Dependencias RF 1, RF 8, RF 9, RF 11, RF 13, RF 17 RF 18,
o En el momento en que lo solicite el administrador podrá
consular de donde se tomó cada orden y la hora en que
fue solicitada.
Nombre de requisito Calcular la ganancia diaria y mostrarla
Tipo Requisito
Dependencias RF 18, RF 10, RF 21
o El sistema contará con un módulo en el cual se podrá
calcular la ganancia diaria del negocio y esta se imprimirá
en pantalla como un mensaje de alerta.
Nombre de requisito Realizar la suma de gastos y mostrar el total
Tipo Requisito
Dependencias RF 10, RF 26
o El sistema podrá obtener el cálculo de los gastos
realizados en el establecimiento y los indicará en pantalla.
Nombre de requisito El programa debe contar con un reloj y una etiqueta
que muestre la fecha en la que se encuentra
Tipo Requisito
23
Riesgo del requisito Baja

Dependencias
o El sistema contendrá en las interfaces un reloj y una
etiqueta que indicará la hora y la fecha en la que se
encuentra.

Nombre de requisito Cada venta debe ser registrada automáticamente
con la fecha y hora en la que fue realizada
Tipo Requisito
Dependencias RF 13
o Las ordenes solicitadas en el día se registran con la fecha

y hora en que fueron solicitadas.
Nombre de requisito Solo se puede registrar un cliente a la vez
Tipo Restricción
Nombre de requisito Sólo el administrador hará el corte de caja
Tipo Restricción
Dependencias RF 1

24
Nombre de requisito Si no se hizo corte de caja y se intenta cerrar el

programa, avisar si desea hacerlo
Tipo Restricción
Dependencias
1.1.2.4.1 Requisitos no funcionales

Nombre de requisito Contar con una ventana para seleccionar el usuario
Tipo Requisito no funcional

Dependencias
Nombre de requisito Que cuente con el logotipo y colores representativos del
restaurant

Dependencias
Nombre de requisito La interfaz es responsiva

Dependencias
25
Nombre de requisito Tiempo de respuesta eficiente

Dependencias
Nombre de requisito Interfaz intuitiva

Dependencias
Nombre de requisito Contar con un scrollbar que aparezca una vez que la
cantidad de productos exceda el límite que se tiene
diseñado para visualizarlos todos
Dependencias RNF 11
Nombre de requisito Cuando se cierre inesperadamente, mantener los datos
visibles que no se guardaron

Dependencias RNF 11
Nombre de requisito Cada pestaña cuente con una función única

26

Dependencias
Nombre de requisito Que se muestren los gastos realizados en el día con una
descripción y total del gasto.

Dependencias RNF 11
Nombre de requisito En la pestaña de ventas del día se muestre la
descripción de pedidos, hora de la venta y precio total

Dependencias
Nombre de requisito La pestaña de ventas, ventas por día, gastos por día y
cortes mensuales deben de mostrar los datos en forma
de tabla
Dependencias RNF 7
Nombre de requisito Que en la pestaña de cortes, muestre un registro
mensual de los cortes realizado, nombrando la cantidad
monetaria en ventas, gastos, ganancia y una
descripción.

27

Dependencias
Nombre de requisito Que en el cierre de caja no pueda modificar nada más
que la descripción del corte
Dependencias
Nombre de requisito Administrador y vendedor puedan acceder a la pestaña
de venta de un producto

Dependencias
Nombre de requisito En la pestaña de “ventas”, mostrar precio, cantidad,
producto y subtotal

Dependencias
Nombre de requisito En caso de que la contraseña como usuario haya sido
incorrecta en más de 3 veces de inicio de sesión,
mostrar un indicio de contraseña

28

Dependencias
Nombre de requisito Después de haber seleccionado un usuario, el programa
debe permitir ingresar una contraseña de acceso y
posteriormente accesar como el usuario seleccionado

Dependencias RNF 1
Nombre de requisito Después de haber seleccionado un usuario, el
programa debe permitir ingresar una contraseña de
acceso y posteriormente accesar como el usuario
seleccionado

Prioridad del Alta
requisito
Dependencias RNF 1
1.1.2.5 Requisitos comunes de los interfaces

El software recibirá como parámetros de entrada, los costos, precios y
cantidades de artículos y datos de los consumibles disponibles en el
establecimiento y tendrá como parámetros de salida el costo a pagar total por
el platillo consumido por el cliente, o precios de compras de unidades de
productos.
29
1.1.2.5.1.1 Interfaces de usuario
La interfaz con el usuario consistirá en un conjunto de ventanas

con botones, listas y campos de textos intuitivos. Ésta fue
construida específicamente para el sistema propuesto y, será
visualizada desde un archivo ejecutable dividido en submódulos
operables, mismo que contará con los colores representativos
del establecimiento.
1.1.2.5.1.2 Interfaces de hardware
Es indispensable contar con equipos de cómputo funcionales

en las mejores condiciones posibles, con las siguientes
características:
 De 1 a 2 Gb de RAM
 Espacio de disco duro minio 120 Mb
 Ratón
 Teclado
 Procesador de 1.66GHz
 Fuente de ventilación o refrigeración (solo en caso de ser

usado 24 horas).
1.1.2.5.1.3 Interfaces de software
-Sistema Operativo Windows XP o superior, en el se ejecutará

el software solicitado por el cliente
-Gestor de base de datos: XAMPP o MySQL o SQL Server, en

el se administrarán y almacenarán los datos del establecimiento
1.1.2.5.1.5Interfaces de comunicación
El software se conecta a MySQL mediante un driver que permite

la conexión y transferencia de datos del programa con el archivo
30
ejecutable, al mismo tiempo esto nos permite almacenar datos

en la BD.
1.1.2.5.2 Requisitos no funcionales
1.1.2.5.2.1 Requisitos de rendimiento
-El sistema soportara el uso de múltiples módulos en ejecución al

mismo tiempo, para que el sistema no recaiga en lentitud se debe de
comprobar que no exista otro proceso que afecte el desempeño de la
base de datos, ni considerablemente el tráfico de la red ya que de lo
contrario el sistema no trabajara con eficiencia.
-Soportara una limitada conexión con la BD para el registro,

modificación o actualización de los datos, la transferencia de datos se
realiza rápidamente.
1.1.2.5.2.2 Seguridad
-El sistema manejara como medio de protección un clave de acceso

para los datos más importantes del programa, así como las bases de
datos manejaran protección cada una de ellas con una contraseña
alfanumérica de 12 dígitos.
-Cada módulo realiza acciones específicas independientes lo que

garantiza que el acceso a los datos es seguro.
-Cuenta con una alerta en caso de que la contraseña de acceso a los

datos sea ingresada más de 5 veces de manera incorrecta
1.1.2.5.2.3 Fiabilidad
-Tiempo de respuesta del sistema de 10 segundos como mínimo.

31
-Almacenamiento correcto y adecuado de los parámetros.
-Cálculos precisos según las características que se lleguen a

considerar.
-Protección de datos contra intrusos.
-Cada módulo realiza las acciones que en él se indican.
-Cantidad de errores permisibles: 2
1.1.2.5.2.4 Disponibilidad
La disponibilidad de uso del software se encontrará en servicio para

los usuarios de 7 días por 24 horas 365 días al año, garantizando un
esquema adecuado en su uso.
1.1.2.5.2.5 Mantenibilidad
-Actualización constante de los registros de la BD por parte del

administrador.
- Limpieza de datos de los módulos diariamente por parte del usuario.
-Constante limpieza en la BD para evitar sobre llenado con datos

basura.
1.1.2.5.2.5 Portabilidad
La portabilidad del software dependerá de ser ejecutado en

dispositivos que cuenten con java específicamente en dispositivos con
sistema operativo Windows que soporten una BD y que cuenten con
las características antes mencionadas.
1.2.1 Métrica de ambigüedad
Esta métrica consiste en dar a leer los requisitos a 3 personas

ajenas al proyecto para que evalúen si los entienden o no, e
irlos marcando para poder hacer al cálculo correspondiente.
32
Nosotros después de hacer lo anterior, obtuvimos los siguientes

requisitos equivocados y que se reestructuraron:
Nombre de requisito Si el cliente está registrado, registrar el pago por
anticipado
Tipo Requisito
Dependencias RF 2, RF3,
RF5,
Nombre de requisito Realizar la suma de gastos y mostrar el total
Tipo Requisito
Nombre de requisito Que en el cierre de caja no pueda modificar nada
más que la descripción del corte
Tipo Requisito no
funcional
Dependencias
Número de requisitos: 37
Número de requisitos ambiguos: 3
Número de requisitos no ambiguos: 34
No ambigüedad:
Ambigüedad= 3 / 37 * 100 = 8.10%
33
1.3 Representación
Figura 3. Casos de uso del administrador
Figura 4. Casos de uso del vendedor

34
1.3.1 Diagrama de actividades
Figura 5. Diagrama de actividades.

35
2. Planeación
2.1 Cronograma de actividades
Figura 6. Estimación de tiempo de realización de actividades
Figura 7. Tiempo real de realización de proyecto

36
2.2 Estimación
Figura 8. Estimación del costo de software.
Figura 9. Costo real del software.

37
2.2.1 Infraestructura para la implementación del desarrollo de

software
Internet + Router $1000 (pago de instalación)
Router $1200
Renta internet $900
Agua $900
Luz $600
Consumibles $25000
Mantenimiento $600
Computadora de escritorio (por 3) $60000
Papelería $3000
Renta $6000
Impresora con copiadora y escáner $2000
Mobiliario(3 escritorios,3 sillas y un pizarrón) $6087

$6000
$1300
Total $114587
No tomamos en cuenta servidores, cableado y red ya que nos adaptamos a las

instalaciones del cliente y a lo que tenía.
38
3. Modelado
3.1 Análisis
Es la planeación de cómo se verá el sistema.
3.1.1 Escenarios de casos de uso del usuario Administrador
Caso de uso 1. Iniciar sesión como administrador
Flujo normal
1. Pulsar el botón “administrador”.
2. Ingresar contraseña.
3. Pulsar la tecla “Enter”.
Flujo alternativo
Si se seleccionó el usuario incorrecto, pulsar el botón

“Regresar”.
Precondición
Debe de haberse firmado en el sistema con su perfil de

usuario.
Postcondición
Caso de uso 2. Registrar cliente

Flujo normal
1. Ingresar el nombre del cliente
2. Ingresar la cantidad de créditos con los que quiera
registrarse
3. Pulsar el botón “Continuar”.
39
Flujo alternativo

“Regresar”.
Precondición
Se debió haber buscado el cliente y no debió haber sido

encontrado.
Postcondición
Guardar los datos del cliente en una base de datos.

Una vez registrado, podrán agregarse más créditos, si
los necesita o se podrá proceder con el descuento
correspondiente.
Caso de uso 3. Consultar cliente
Flujo normal
1. Seleccionar botón “Cliente registrado”
2. Ingresar el nombre del cliente.
3. Seleccionar el botón “buscar”.
Flujo alternativo
Si el cliente no se encuentra registrado, registrarlo.
Precondición
Postcondición
Una vez consultado, podrán agregarse más créditos, si

correspondiente
40
Caso de uso 4. Aplicar descuento en venta
Flujo normal
1. Después de haber consultado el cliente, seleccionar la

opción “continuar” para proceder con el descuento.
2. Pulsar el botón cerrar.
Flujo alternativo
Si el cliente no tiene créditos, seleccionar el botón

“Agregar créditos”.
Precondición
Postcondición
Caso de uso 5. Registrar pedido
Flujo normal
1. Pulsar el botón “Registrar pedido”.
2. Seleccionar la cantidad del producto y el nombre del

producto que se desee agregar.
3. Pulsar el botón “Registrar”
Flujo alternativo
Precondición
Postcondición
.
41
Caso de uso 6. Terminar venta
Flujo normal
1. Pulsar el botón “Terminar venta”
2. Seleccionar el botón “Cerrar” en la pestaña emergente

“Venta terminada”
Flujo alternativo
Precondición
Haber registrado los productos a vender.
Postcondición
Guardar la venta en una base de datos.
Caso de uso 7. Consultar ventas diarias
Flujo normal
1. Seleccionar la pestaña “Ventas del día”
Flujo alternativo
Precondición
Haber registrado ventas a lo largo del día, aunque no

necesariamente debieron haber existido ventas para
consultarla.
Postcondición
42
Caso de uso 8. Registrar los gastos diarios
Flujo normal
2. Pulsar el botón “gastos”.
3. Insertar el monto del gasto.
4. Insertar una descripción del gasto.
5. Pulsar el botón “continuar”.
Flujo alternativo
Precondición
Postcondición
Guardar los detalles del gato en una base de datos.
Caso de uso 9. Consultar los gastos diarios
Flujo normal
1. Seleccionar la pestaña “gastos del día”
Flujo alternativo
Precondición
Haber registrado gastos a lo largo del día, aunque no

necesariamente debieron haber existido gastos para
consultarla.
Postcondición
43
Caso de uso 10. Realizar corte de caja
Flujo normal
1. Seleccionar la pestaña “cierre de caja”.
2. Seleccionar el mes y día del corte.
3. Agregar una descripción.
4. Pulsar el botón “Realizar corte”.
Flujo alternativo
Precondición
Postcondición
Guardar los datos del corte en una base de datos.
Caso de uso 11. Consultar cortes mensuales
Flujo normal
1. Seleccionar la pestaña “cortes realizados”
2. Seleccionar el mes que desee consultar.
Flujo alternativo
Precondición
Postcondición
44
3.1.2 Escenarios de casos de uso del usuario Vendedor
Caso de uso 1. Iniciar sesión como vendedor
Flujo normal
4. Pulsar el botón “vendedor”.
5. Ingresar contraseña.
6. Pulsar la tecla “Enter”.
Flujo alternativo

“Regresar”.
Precondición
Debe de haberse firmado en el sistema con su perfil de

usuario.
Postcondición
Caso de uso 2. Registrar cliente

Flujo normal
4. Ingresar el nombre del cliente
5. Ingresar la cantidad de créditos con los que quiera
registrarse
6. Pulsar el botón “Continuar”.
Flujo alternativo

“Regresar”.
Precondición
Se debió haber buscado el cliente y no debió haber sido

encontrado.
45
Postcondición
Guardar los datos del cliente en una base de datos.

Una vez registrado, podrán agregarse más créditos, si
correspondiente.
Caso de uso 3. Consultar cliente
Flujo normal
4. Seleccionar botón “Cliente registrado”
5. Ingresar el nombre del cliente.
6. Seleccionar el botón “buscar”.
Flujo alternativo
Si el cliente no se encuentra registrado, registrarlo.
Precondición
Postcondición
Una vez consultado, podrán agregarse más créditos, si

correspondiente
Caso de uso 4. Aplicar descuento en venta
Flujo normal
3. Después de haber consultado el cliente, seleccionar la

opción “continuar” para proceder con el descuento.
4. Pulsar el botón cerrar.
Flujo alternativo
46
Si el cliente no tiene créditos, seleccionar el botón

“Agregar créditos”.
Precondición
Postcondición
Caso de uso 5. Registrar pedido
Flujo normal
4. Pulsar el botón “Registrar pedido”.
5. Seleccionar la cantidad del producto y el nombre del

producto que se desee agregar.
6. Pulsar el botón “Registrar”
Flujo alternativo
Precondición
Postcondición
Caso de uso 6. Terminar venta
Flujo normal
3. Pulsar el botón “Terminar venta”
4. Seleccionar el botón “Cerrar” en la pestaña emergente

“Venta terminada”
Flujo alternativo
47
Precondición
Haber registrado los productos a vender.
Postcondición
Guardar la venta en una base de datos.
Caso de uso 7. Consultar ventas diarias
Flujo normal
6. Seleccionar la pestaña “Ventas del día”
Flujo alternativo
Precondición
Haber registrado ventas a lo largo del día, aunque no

necesariamente debieron haber existido ventas para
consultarla.
Postcondición
48
3.2Modelado de datos
3.2.1 Diagrama de Entidad-Relación.
Este diagrama muestra la relación de los atributos en la base

de datos.
Figura 10. Diagrama de Entidad-Relación
3.2.1.1 Diseño
Se coloca el diseño de interfaces del programa clasificadas
por apartado e indicando los contenidos que tendrá.
49
3.2.1.1.2 Pantalla de selección de usuario
Figura 11. Selección de usuario
3.2.1.1.3 Pantallas de administrador
Figura 12. Ingresar como administrador

50
Figura 13. Pantalla de venta
Figura 14. Pantalla de ventas del día

51
Figura 15. Pantalla de gastos generados durante el día

52
Figura 16. Pantalla de cierre de caja
Figura 17. Pantalla de los cortes de caja realizados en el día
3.2.1.1.3 Pantallas de vendedor
Figura 18. Inicio de sesión como vendedor

53
Figura 19. Pantalla de ventas para el vendedor
4.Construcción
4.1 Código
Se coloca el código del sistema y se indica las funcionalidades de que hace
cada línea o como opera en relación con las otras; El sistema se encuentra
dividido en módulos por lo que se encuentra relacionado mediante métodos
compartidos, cada uno realiza acciones independientes y está diseñado para
la evolucionar.
4.2 Pruebas
Se realizan las pruebas unitarias y completas del programa, donde se estudia que
el programa opere completamente dando resultados correctos y completos,
cada etapa de pruebas se desarrolla en un lapso de tiempo y el sistema es
probado en múltiples plataformas para ver el comportamiento del mismo.
54
5. Despliegue
5.1 Entrega
Se realiza la entrega del software operando correctamente al cliente,

se realiza la instalación del software en el establecimiento y se entrega
el manual de usuario para que el cliente lo pueda operar
adecuadamente evitando problemas en el software.
5.2 Asistencia
La actualización de requisitos son funcionalidades nuevas que el

cliente quiere que tenga su software, estas actualizaciones pueden ser
pequeñas o muy grandes.
5.3 Retroalimentación
Retomar lo desarrollado en el software para implementarlo de nuevo

en algún otro sistema o para evitar los mismos errores que se
cometieron durante el desarrollo de este.
5.4 Evaluación
El equipo determina y se evalúa en tanto a la eficiencia con la que

trabajo y si se lograron los propósitos esperados en el software.
55
Conclusión
Como se puede ver en la gráfica de Gantt, no se realizó la programación

correspondiente ni la entrega del proyecto debido a la falta de conocimientos en el
área y tiempo para el desarrollo de un producto totalmente funcional.
Por lo que, a falta de ambas actividades, las etapas del modelo elegido que lograron
ser realizadas fueron: la comunicación, directamente en la aplicación de la
entrevista con el cliente, así como la recaudación y representación de requisitos; la
planeación, tanto temporal como presupuestal del proyecto; y finalmente, el
modelado del proyecto, abarcando así, el diseño de la base de datos con diagrama
de entidad relación, descripción de los casos de usos y la interfaz gráfica
(maquetada).
Como trabajo a futuro se piensa que el proyecto podría continuarse y

posteriormente, fabricar un software completo para el punto de venta del negocio
local Deli-House. En el cual, se realice la codificación y documentación
correspondiente, optimizando el uso de memoria para que el sistema pueda ser
soportado en computadoras de bajos recursos. Así mismo, la entrega y
retroalimentación del proyecto para terminar satisfactoriamente el despliegue de
este.
Lecciones aprendidas
1. Planeación de actividades
Los tiempos fijados para el desarrollo del sistema no contemplaron las

desviaciones que surgieron por el trabajo a distancia del equipo.
2. Implementación de herramientas case
La implementación de herramientas de maquetado para el software

fueron fuente fundamental de conocimiento de cómo se desarrollaría
la aplicación.
56
3. Trabajar en equipo
La colaboración en equipo es algo fundamental para poder cumplir

objetivos del desarrollo del proyecto, la subdivisión de actividades en
el equipo hace más eficiente el desarrollo rápido de la misma.
4. Comprensión del modelo de Cascada
El desarrollo de este proyecto de software siguiendo del modelo de

cascada, nos dio una vista más amplia sobre el funcionamiento de esta
metodología y de cómo se implementa está en los proyectos de
desarrollo de software.
57
Anexo A. Capturas del diseño
1. Inicio de sesión
Figura 19. Selección de usuario
Figura 20. Introducción de contraseña vendedor

58
Figura 21. Introducción de contraseña administrador

1.1. Proceso del administrador
1.1.1. Ventas
Figura 22. Pestaña de venta

59
Figura 23. Pestaña emergente de venta terminada

1.1.1.1. Búsqueda de cliente
Figura 24. Pestaña emergente de búsqueda del cliente.

60
Caso a. Cliente encontrado
Figura 25. Cliente registrado.
Figura 26. Agregar créditos.

61
Figura 27. Descuento aplicado.

Caso b. Cliente no encontrado
Figura 28. Cliente no encontrado.

62
Figura 29. Registrar cliente.

(Regresar al caso ‘a’)
1.1.1.2. Registro de venta
Figura 30. Registrar venta.

63
1.1.1.3. Registro de gasto
Figura 31. Registrar gasto.
Figura 32. Gasto registrado.

64
1.1.2. Ventas del día
Figura 33. Ventas del día.

1.1.3. Gastos del día
Figura 34. Gastos del día.

65
1.1.4. Cierre de caja
Figura 35. Cierre de caja.
.
Figura 36. Corte realizado.
66
1.1.5. Consulta de cortes realizados mensualmente
Figura 37. Consulta de cortes por mes.

1.2. Proceso del vendedor
1.2.1. Ventas
Figura 38. Pestaña de venta

67
Figura 39. Pestaña emergente de venta terminada

1.2.1.1. Búsqueda de cliente
Figura 40. Pestaña emergente de búsqueda del cliente.

68
Caso a. Cliente encontrado
Figura 41. Cliente registrado.
Figura 42. Agregar créditos.

69
Figura 43. Descuento aplicado.

Caso b. Cliente no encontrado
Figura 44. Cliente no encontrado.

70
Figura 45. Registrar cliente.

(Regresar al caso ‘a’)
1.2.1.2. Registro de venta
Figura 46. Registrar venta.

71
1.2.1.3. Registro de gasto
Figura 47. Registrar gasto.
Figura 48. Gasto registrado.

72
Anexo 2
1. ¿Cuántos empleados tiene? 5 empleados de base y de vez en cuando, se

cuentan con 2 empleados por alumnos que gustan trabajar ahí y se les
paga por horas.
2. ¿Cuál es el cargo de cada uno? 1 jefa de cocina, 2 cocineras, 1 lava trastes

y 1 mesera.
3. Aproximadamente, ¿Cuánto tiempo tardan en servir? Debido a que todos

los platillos son preparados en el momento, suelen tardarse de 12 – 15
minutos.
4. ¿Le gustaría un sistema para su negocio? Sí, uno similar a software

restaurant, pero no se ha logrado puesto que dicho software necesita
licencia y recursos ya sean físicos o monetarios con los que no cuenta el
local.
5. ¿Ha intentado automatizar su proceso administrativo? Sí, pero los recursos

no se tienen recursos suficientes. ¿Cuántos platillos diferentes tiene su
menú? Con 50 platillos.
6. ¿En base a qué y por qué tiene promociones? Desde que comenzó el
restaurant, los estudiantes comenzaron a pedir ya sean variaciones de
platillos o conjuntos de alimentos. Al percatarse de ello, a los paquetes de
mayo venta les decidió asignar una promoción y un día de la semana
puesto que así era mayormente aceptado por los alumnos. Además,
algunos, fueron inventados por los mismos miembros del restaurant.
7. ¿Cuántas mesas tiene? 13 y se encuentran numeradas.
8. ¿Cuál es el cupo máximo? En un día normal, aproximadamente 60

alumnos. Pero cuando entra un número de alumnos mayor de alumnos,
entre 80 y 100 alumnos.
9. ¿Cada cuánto compra mercancía? 2 veces por semana.
10. ¿Cuál es su porcentaje de ganancia? De 30% - 40% de utilidad.

73
11. Aproximadamente, ¿Cuál es el porcentaje de pérdida en desperdicios de

comida? Si bien el restaurante no genera desperdicios puesto que el
alimento desechado tiene un uso posterior, las “pérdidas” generadas por
ello, son del 10%
12. ¿Cuál es su inversión? $5000 por semana.
13. ¿Cuánto da de sueldo? $250 por día de trabajo ($1250 semanal) sin
embargo, puesto que las trabajadoras son madres solteras, a veces sus
horarios suelen variar por sus responsabilidades externas, pero cuando hay
suspensiones de cualquier tipo, no se les paga.
14. ¿Cuánto gasta en mantenimiento? (cloro, etc.) $500 por semana
15. ¿Cuánto gasta en servicios aproximadamente?

Luz - $2000 al mes.
Agua - $1000 al mes.
16. Televisión - $250 al mes.
17. Gas - $2000 al mes.
18. ¿A cuántos clientes atiende al día aproximadamente? Depende mucho de

la temporada y del cuatrimestre. En un día normal, de 50 a 70 personas; en
un día de clientela muy baja, aproximadamente 30; en un día con mucha
demanda, más de 100.
19. ¿Cree que los colores del establecimiento son los adecuados? Sí. Los
colores que representan el negocio se enfocan a ser activo y divertido.
20. ¿Cuáles son los colores representativos del establecimiento? Rojo, blanco y
verde.
21. ¿Cuenta con algún logotipo? Sí
22. ¿Cuáles son los días laborales? De lunes a viernes.
23. ¿Cuáles son los horarios de trabajo? De 8:00 A.M. a 6:00 P.M.
74
24. ¿Cuál es el gasto de transporte? $4000 al mes.
25. ¿Qué métodos de pago maneja? A los empleados se les paga en efectivo y
a los clientes se les cobra únicamente de esa forma.
26. ¿Cuánto paga de impuestos? El registro en hacienda sigue en proceso.
27. ¿Con que métodos de iluminación cuenta el establecimiento? La mayoría,

de luz natural, pero en caso de ser necesario, luz cálida por focos.
28. ¿Cuál es el intervalo de precios? En promedio, de $25 a $50 pesos. La

mayoría de los alimentos, cuestan $45. Sin embargo, cuentan con
elementos de desde $5 hasta $70.
29. ¿Le parece bien la ubicación? Sí, pues se planea que esté unos cuantos
metros alejado de la escuela porqué así se aseguran de que el estudiante
cuenta con el tiempo necesario para ir. Además, en esa ubicación se puede
vender comida menos procesada por los tiempos de preparación.
30. ¿Cada cuánto fumigan el establecimiento? Una vez al mes.

Proyecto Final de Procesos - Final PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Proyecto Final de Procesos - Final PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Universidad Politécnica de Pachuca

Procesos de Desarrollo de Software

Jazmín Rodríguez Flores

Jorge Ángel Díaz Mera

La razón principal para escribir este proyecto es para mostrar y explicar el

DESCRIPCIÓN DETALLADA DE LAS ETAPAS ................................................ 7

1.1 Inicio .............................................................................................................. 7

1.1.2.2.1 Propósito ............................................................................................... 10

1.3 Representación ............................................................................................... 33

2.1 Cronograma de actividades............................................................................. 35

2.2 Estimación ....................................................................................................... 36

3.1 Análisis ............................................................................................................ 38

3.1.1 ESCENARIOS DE CASOS DE USO DEL USUARIO ADMINISTRADOR38

Flujo normal ....................................................................................................... 38

3.2Modelado de datos ........................................................................................... 48

4.1 Código ............................................................................................................. 53

4.2 Pruebas ........................................................................................................... 53

5.1 Entrega ............................................................................................................ 54

5.2 Asistencia ........................................................................................................ 54

5.3 Retroalimentación ........................................................................................... 54

5.4 Evaluación ....................................................................................................... 54

Lecciones aprendidas ........................................................................................... 55

ANEXO A. CAPTURAS DEL DISEÑO ............................................................. 57

Se eligió la metodología de cascada, porque aparte de tener mucho tiempo

Descripción detallada de las etapas

La etapa de comunicación se divide en tres partes inicio, requisitos y

Se realizó una entrevista para obtener los requisitos. Fueron 3x

1.1.1 Recabar requisitos

Se utilizó el formato IEEE830 para la representación de

1.1.2 Requisitos funcionales (IEEE 830)

Especificación de requisitos de software

1.1.2.1 Historial de Revisiones

Fecha Revisión Descripción Autor

25-01-2019 1.0 Inicio del proyecto Marco Antonio Rosas

Documento validado por las partes en fecha: 25-01-2019

Por el cliente Por la empresa suministradora

El Proyecto de Deli House tiene como objetivo proporcionar un servicio de control,

La especificación se ha estructurado basándose en las directrices dadas por el

El presente documento tiene como propósito definir las especificaciones

La especificación de requisitos está dirigida al usuario del sistema, para

El sistema realizará la venta de productos y administración de clientes,

1.1.2.2.3 Personal involucrado

Nombre Alma Estefanía Vera Camacho

Nombre Marco Antonio Rosas Barcenas

1.1.2.2.4 Definiciones, acrónimos y abreviaturas

RNF Requerimiento No Funcional

Se describen los requisitos funcionles y nofuncionales mediante la

1.1.2.3 Descripción general

1.1.2.3.1 Perspectiva del producto

Se trata de un proyecto portable y modular independiente programado

1.1.2.3.2 Funcionalidad del producto

Figura 1. Casos de uso del vendedor

Figura 2. Casos de Uso del proyecto

El software realizara el manejo y administración de inventario del lugar,

El sistema se encuentra dividido en módulos, lo que lo hace eficiente

Los submódulos se dividen en

Consiste en ayuda en el control del tiempo de elaboración de

El módulo realiza el cálculo de las ganancias del día, así mismo

El sistema se encuentra conectado con una base de datos, la

Dentro de la conexión de base de datos no solo se pueden

1.1.2.3.3 Características de los usuarios

Tipo de usuario Administrador

Formación Ing. Software