Reporte ads meson del sazon

Cd. Victoria Tamps. Agosto del 2013.

Integrantes del equipo:

1130131, Miguel Ángel García Wha.

1110027, Mónica Aurora Jaramillo Castro.

1130244, Francisco Maldonado Becerra.

Ingeniería En Tecnologías De La Información

Profesor: Jose Fidencio Lopez Luna.

Universidad Politécnica de Victoria

Materia: Analisis y Diseño de sistemas.

“El Mesón del Sazón”

(Sistema para control de inventario).

ANALISIS Y DISEÑO DE SISTEMAS

2

INDICE

Introducción……………………………………………………………………………………………………….3

Ámbito del sistema……………………………………………………………………………………….3

Visión general del documento………………………………………………………………………4

Descripción.…………………………………………………………………………………………………………4

Funciones del producto……………………………………………………………………………….5

Características de los usuarios……………………………………………………………….……. 6

Restricciones………………………………………………………………………..………………………7

Requisitos futuros……………………………………………………………………………………….7

WBS………………………………………………………………………………………………….………………8

Diagrama de WBS……………………………………………………………………..…………………8

Diagramas de casos de uso…………………………………………………………………………..9

Fichas de casos de uso…………………………………………………………………………10

Diagramas……………………………………………………………………………………………………………….26

Diagramas de clases…………………………………………………………………………………………….27

Diagrama de secuencia……………………………………………………………………………………………..28

Diagrama de comunicación…………………………………………………………………………………………..29

Requerimientos del sistema…………………………………………………………………………………………….30

Factibilidad del sistema……………………………………………………………………………………………………….33

Recomendaciones……………………………………………………………………………………………………………35


3

Introducción.

Ámbito del sistema.

Se llevó a cabo un estudio de factibilidad (viabilidad) en el negocio “el mesón del sazón” y se observó que actualmente no cuentan con ningún sistema o base de datos que les ayude al manejo de la información.

Se llegó a un acuerdo de que el sistema propuesto será rentable desde un punto de vista de negocios y, se puede lograr su creación con el presupuesto existente. Se lograron analizar los requerimientos o necesidades, esto se llevó a cabo por medio de la observación, discusiones con los usuarios potenciales y analizando las tareas. Al igual que se pensó usar a lo largo del desarrollo del sistema el modelo de cascada porque es más completo que cualquier otro modelo y va paso a paso.

El Mesón del Sazón (sistema para control de inventario) tiene como propósito como su nombre lo dice poder ayudar con el control del inventario del establecimiento, esta empresa tiene un giro de servicio. El Sistema tendrá la funcionalidad de poder tener el control de inventario, de las ventas y usuarios que ingresen a él.


4

Visión General del Documento.

Descripción.

En los siguientes puntos encontraremos la descripción general de sistema, perspectivas del sistema, funciones del sistema y un pos referente al mismo sistema.

El sistema lleva control del inventario en cual contiene entradas, salidas y recursos, se refiere al uso general de lo que se hace en las diferentes áreas de la empresa y lo que se utiliza.

Mejorar los procesos que están unidos a una serie de actividades que se pueden realizar en la empresa.

Tener un control de las materias primas, con actualización continua de la B.D del sistema, ya que genera una bitácora diaria de los procesos realizados en la empresa.

Tener un control del registro de los empleados, registros financieros y una mayor seguridad de acceso del personal, como autorización de la empresa para su acceso y a la vez realizar cualquier operación en sistema.


5

Funciones del producto.

Llevara a cabo un inventario del almacén del la empresa.

Control de usuarios.

Control de ventas.

Proporción de bitácora del almacén.

Automatizar procesos de sistemas anteriores.


6

Características de los usuarios.

Las personas que manipularan el sistema son personas de entre 40 años, por eso

el sistema deberá ser de fácil manejo. El nivel académico es de licenciatura sin

embargo no están familiarizados con nuevas tecnologías y es necesario una

capacitación. Cabe mencionar que la empresa es un negocio familiar y es

atendida por miembros de la misma.

Administrador.

El administrador es la persona encargada del mantenimiento del sistema

(actualizaciones del inventario, daño del equipo, restablecer contraseñas etc.).

Manager.

El manager es el dueño de la empresa, la persona encargada de mantener en

perfecto funcionamiento todos los procesos en la empresa, la persona que toma

las decisiones. Su acceso en el sistema es absoluto (puede realizar

modificaciones, actualizaciones eliminar datos etc.).

Chef.

Persona encargada de la supervisar y elaborar de los productos en la cocina. Su

acceso al sistema será restringido el chef solo podrá consultar inventario.

Cajero.

Persona encargada de cobrar y registrar las ventas. Si acceso al sistema será restringido solo podrá realizar registros de venta (cantidad, productos vendidos, porciones, tipo de venta etc.).


7

Requisitos futuros.

Restricciones

.

Tiempo.

Tiempo de desarrollo

o Entrega de prototipo.

o Periodo de pruebas.

Plan de presupuesto.

o Acoplamiento de costos, insumos, etc.

o Licencias de software.

o Equipo de desarrollo.

Políticas.

o Acceso más información de la empresa.

Inversión en seguridad.

Actualización de software.

Sitio web.

Compras en línea.

Expansión de sistema conforme la expansión de la empresa.


8

WBS.

Diagrama 1. Diagrama WBS, sistema “Mesón del Sazón”.


9

Casos de uso.

En esta sección se presenta los casos de uso de sistema propuesto. Se simplifica la utilización del mismo y la interacciona de los diferentes usuarios (actores) que contiene.

Diagrama 4.- Diagrama caso de uso (realizado por el equipo de trabajo).


10

Casos de uso.

1. CU1: AUTENTICACION DE USUARIOS EN EL SISTEMA.

Casos de uso:

Autentificación de usuario en el sistema (login).

CU1

Actores principales:

Administrador, Manager, chef, cajero.

Objetivo:

Autentificación de seguridad del sistema para su uso.

Disparador:

El usuario trata de tener acceso al sistema.

Descripción:

Los actores proporcionan una clave y un usuario para su acceso.

Pre-condición:

El usuario debe de estar registrado en el sistema previamente.

Post- condición:

El actor proporciona su usuario (sistema) y contraseña. Se realiza una orden de búsqueda

del usuario y su contraseña, si se encontró el usuario el sistema permite su acceso. Los

permisos se relegan según su cargo (chef, manager, administrador y cajero).

Fecha:

Versión:

0.1

Escenario.

Flujo normal:

Autores. (a) Sistema. (b)

1 El usuario ejecuta el sistema

(aplicación).

2 El usuario ingresa su usuario (sistema)

y coloca su contraseña.

4 El sistema procesa la información.

5 El sistema informa del estado al

usuario.

6 Muestra el menú.

7 Usuario navega por el sistema.

8 Obtiene permiso para selecciona una

opción del menú.

Flujo alternativo:

4b El sistema procesa la información. Solicita petición a la bases de datos para guardar.

Si surge error vuelve a 2.

5b El sistema muestra el estado del resultado que se llegó en el procesamiento de la

información. Los estados del sistema pueden ser denegado (usuario introdujo datos


11

erróneos o no está registrado) y permitido (el usuario tiene permiso de entrar al

sistema). Volver a 2.

6b El sistema muestra un menú con las diferentes opciones que fueron definidos para

este sistema.

Excepciones y soluciones:

Si el usuario se le denegó el acceso se le notificara el error.

Si el sistema encuentra que el usuario proporciono datos erróneos notificara al

usuario de lo ocurrido (usuario no encontrado, password erróneo).

En caso de que el usuario no se encuentre registrado consultar el administrador del

sistema para que, el registre y le cree una cuenta.

El sistema muestra el mismo menú con las mismas opciones, dependiendo del

usuario se le otorgaran permisos de las opciones que puede realizar en el mismo.

En caso de que no tenga permiso para cierta opción, el sistema notificara o

simplemente no ejecutara la acción.

Si el Manager, Administrador, Chef olvido sus datos. Deberá acudir con el

administrador para una solución.

2. CU2: SALIR/REGRESAR.

Casos de uso:

Salir/Regresar.

CU2


Administrador, Manager, chef, cajero.

Objetivo:

Proporcionarle al usuario la opción de salir o desplazarse a más opciones del menú.

Disparador:

Selección de opción o acciones de botones inferiores con los nombres de salir o regresar.

Descripción:

En la interfaces de cada una de las opciones del menú del sistema el usuario podrá

observar un par de botones los cuales le proporcionara una navegación en los diferentes

formularios o interfaces de la aplicación.


12

Pre-condición:

El usuario debe de estar en un estado autentificado para esta acción y a ver seleccionado

una de las opciones del menú. Estar dentro de un formulario o parte del sistema con las

opciones.

Post- condición:

El usuario devio a ver seleccionado un opción (Salida/regreso). Espera la operación. Si la

operación fue salir el sistema le da al usuario estado de no autentificado.

Fecha:

Versión:

0.1

Escenario.

Flujo normal:


1 << CU_1. Autentificación de usuario

en el sistema (login). >>

2 El usuario selecciono una opción del

menú.

4 El sistema interpreta la acción y

muestra la interfaz y opciones de

salir/regresar

3 El usuario realiza operaciones dentro

del sistema. 5 El sistema le da permiso de ejecutar

cualquier acción.

6 El usuario desea salir o regresar. 7 El sistema espera la acción de opciones

salir/regresar.

8 Si la opción seleccionada fue salir, sale

del sistema.

9 Si la opción fue regresar devuelve al

menú.

Flujo alternativo:

7b El sistema espera que el usuario seleccione una opción, si la opción fue salir el

sistema le da al usuario un estado de no autentificado. En caso contrario y selecciona

la opción de regreso, muestra la interfaz de menú, vuelve a 2.


3. CU3: CONSULTAS DE MATERIAS PRIMAS EN EL SISTEMA.

Casos de uso:

Consultas Materias primas.

CU3


Manager, Administrador, Chef.

Objetivo:


13

Consultas de las materias primas.

Disparador:

El usuario presiona la opción de consultas.

Descripción:

Los diferentes actores tratan de realizar una consulta y esperan obtener un resultado visual

sin muchas especificaciones, algo entendible.

Pre-condición:

El usuario debió a ver iniciado sesión.

Post- condición:

El usuario realiza una búsqueda en el sistema hacia la base de datos en la parte del almacén

y verifica los insumos que se encuentran en él. El usuario es informado de la cantidad de

los insumos o materias primas. Esto es un resultado de impresión de pantalla.

Fecha:

Versión:

0.1

Escenario.

Flujo normal:




2 El usuario selecciona la opción consulta

de materias primas.

3 El sistema muestra interfaz.

4 El usuario realiza una consulta de una

materia prima (búsqueda).

5 El sistema procesa la información y

devuelve un resultado.

6 Muestra los resultados en la interfaz.

7 El usuario obtiene los resultados de la

búsqueda. 8 << CU_2. Salida/Regreso. >>

Flujo alternativo:

5b Si el sistema no encurta lo buscado, volver a 4. Realiza petición a la base de datos

para regresar resultados.

8b En el momento de que el usuario se encuentre en la interfaz se le mostraran 2

opciones salida y regreso. El sistema espera una acción. Si presiona regreso volver a

1. Salir se retira del sistema.

11b Si el usuario selecciono una de las opciones de la interfaz. Si es salir sale del sistema

y termina su sección. Y selecciona la opción de regresa podar tomar otra opción del

menú.


Si se proporciona datos incorrectos. El sistema dará un aviso de lo ocurrido.

Si no se encuentra lo buscado el sistema avisara del problema.


14

4. CU4: CONSULTA DE PRODUCTO EN EL SISTEMA.

5. CU4: CONSULTAS DE PERSONAL EN EL SISTEMA.

Casos de uso:

Consultas de personal.

CU4


Manager, Administrador.

Objetivo:

Realizar consultas del personal que labora en el restaurante.

Disparador:

El usuario selecciona la opción de consulta de personal.

Descripción:

El usuario trata de consultar, o contabilizar el número de empleados con los que cuenta el

restaurante y poder observar sus datos personales dados por los trabajados.

Pre-condición:

El usuario debió a ver iniciado sesión en el sistema y a ver ejecutado la aplicación.

Post- condición:

Se produce una búsqueda en el sistema. El usuario recibe un resultado de la búsqueda. Y la

muestra en la interface.

Fecha:

Versión:

0.1

Escenario.

Flujo normal:



en el sistema. >>

2 El usuario selecciona la opción de

consulta de personal.

3 El sistema entra a la opción de consulta

de sistema.

4 El realiza una búsqueda. 5 El sistema procesa la búsqueda

6 Muestra lista o resultado de la

busequda.

5 El usuario obtiene el resultado de la

búsqueda.

6 << CU_2. Salida/Regreso. >>

Flujo alternativo:


15

5b El sistema muestra según la opción del sistema el resultado. Vuelve a 2. El sistema

hace petición de búsqueda a la base de datos. Base de datos regresa petición.


En caso de que el sistema no realiza la acción de búsqueda o no encuentre

resultados el sistema proporcionara aviso de lo ocurrido.

6. CU5: CONSULTA DE BITÁCORA EN EL SISTEMA.

Casos de uso:

Consultas de bitácora.

CU5



Objetivo:

Realizar consultas de la bitácora u observar todos los registros.

Disparador:

El usuario selecciona la opción de consulta de bitácora.

Descripción:

El usuario trata de consultar lo que contiene el establecimiento ya sea la venta del día,

insumos , etc.

Pre-condición:

El usuario debió a ver iniciado sesión en el sistema y a ver ejecutado la aplicación. Debe

de a ver registros almacenados.

Post- condición:

Se produce una búsqueda en el sistema. El usuario recibe un resultado de la búsqueda. Y la

muestra en la interface.

Fecha:

Versión:

0.1

Escenario.

Flujo normal:



en el sistema. >>


consulta de bitácora.

3 El sistema entra a la opción de consulta

de sistema. Y muestra la interfaz.

4 Usuario visualiza los resultados que 5 << CU_2. Salida/Regreso. >>


16

arroja el sistema.

Flujo alternativo:

4b El sistema muestra según la opción del sistema el resultado. Vuelve a 2. El sistema

hace petición de búsqueda a la base de datos. Base de datos regresa petición.


En caso de que el sistema no realiza la acción de búsqueda o no encuentre

resultados el sistema proporcionara aviso de lo ocurrido.

En caso de no obtener resultados el sistema notifica que no cuenta con los datos de

la búsqueda.

7. CU6: REGISTRO DE MATERIAS PRIMAS EN EL SISTEMA.

Casos de uso:

Registro de materias primas en el sistema.

CU6



Objetivo:

Rregistros de toda la materia prima a utilizar en el restaurante para la preparación de los

alimentos.

Disparador:

El usuario selecciona la opción de registro de materias primas.

Descripción:

El usuario podrá registrar las materias primas que se encuentran en el almacén del

restaurante.

Pre-condición:

El usuario debe de estar autentificado en el sistema.

Post- condición:

Se procesa la información se manda una petición de registro en el sistema.

Fecha:

Versión:

0.1

Escenario.

Flujo normal:




2 Elige la opción de registro de producto. 3 Muestra la interfaz formulario de


17

productos.

4 El usuario llena los campos que muestra

el formulario del sistema. 5 Procesa la información proporcionada

por el usuario.

6 Regresa estado de la operación.

7 El usuario confirma la operación. 8 Guarda los cambios.


Flujo alternativo:

3b El sistema muestra el formulario con campos obligatorios los cuales son llenados por

el usuario, volver a 4.validacion de campos.

8b Sistema registra a la base de datos los datos nuevos. base de datos regresa resultados

de la acción, volver a 7.


En caso de que los campos no sean llenados correctamente el sistema notificara lo

ocurrió.

Este formulario cuenta con ampos obligatorios los culés deben de ser llenado de no

hacerlo se notificara con una aviso de que campo es faltante.

8. CU7: REGISTRO DE PRODUCTOS EN EL SISTEMA.

Casos de uso:

Registro de productos.

CU7



Objetivo:

Realización de registros de producto en el sistema.

Disparador:

El usuario debe de seleccionar la opción del menú “registro de producto”.

Descripción:

El usuario tiene la opción de poder registrar productos nuevos que lleguen al

establecimiento.

Pre-condición:

El usuario debe de estar en un estado de autentificado en el sistema.

Post- condición:

Se procesa la información se manda una petición de registro en el sistema.

Fecha:

Versión:

0.1

Escenario.


18

Flujo normal:




2 El usuario selecciona la opción del

menú registro de productos. 3 El sistema obtiene la orden, muestra

interfaz de registro de producto.

4 El usuario hace uso del formulario y

llenas los datos correspondientes 5 El sistema procesa la información y

guarda.


Flujo alternativo:

5b El sistema manda petición a la base de datos. Base de datos guarda los datos nuevos.

Si son incorrectos volver a 4.


Si los campos no son llenados el sistema dará un aviso del ocurrido.

En caso de que cuente con campos obligatorios y no son llenados el sistema dará

aviso del error.

9. CU8: REGISTRO DE PERSONAL EN EL SISTEMA.

Casos de uso:

Registro de personal en el sistema.

CU8


Manager o administrador.

Objetivo:

El usuario podrá registrar personal nuevo al sistema.

Disparador:

El usuario selecciono en la opción del menú “registro del personal”.

Descripción:

El usuario podrá registrar personal nuevo y registrarlo dentro del sistema para su mejor

control.

Pre-condición:


Post- condición:

El usuario puede registrar todo el personal para un mejor manejo de la información.

Fecha:

Versión:

0.1


19

Escenario.

Flujo normal:





menú “Registro de personal”.

3 El sistema ejecuta acción y muestra

interfaz de registro.

4 El usuario hace uso de la interfaz. 5 El sistema procesa la información y

guarda.

6 Sistema muestra los resultados al

usuario. Mensaje.

7 El usuario acepta la notificación.


Flujo alternativo:

3b El sistema despliega interfaz con formulario para el llenado de los datos.

5b El sistema en conjunto con la base de datos guarda la información del formulario.

Datos erróneos, volver a 4.


En caso de que el formulario no se es llenado o se encuentran correctos el sistema

notificara de lo ocurrido.

10. CU9: REGISTRO DE VENTAS EN EL SISTEMA.

Casos de uso:

Registro de ventas.

CU9


Cajero.

Objetivo:

El usuario realiza registro de las ventas.

Disparador:

El usuario selecciona la opción del menú “registro de ventas”.

Descripción:

El usuario podrá registrar la venta en el sistema para un mejor manejo de la información.

Pre-condición:


Post- condición:

El usuario podar registrar la venta del el cliente y tener un historial financiero.

Fecha: Versión:


20

0.1

Escenario.

Flujo normal:




2 El usuario selecciono la opción del

menú “registro de venta”.

3 El sistema procesa la petición y

muestra interfaz.

4 El usuario utiliza la interfaz y llena los

datos proporcionados por el sistema.

6 El sistema procesa la información y

guarda.

7 El sistema manda mensaje de

confirmación.


Flujo alternativo:

6b El sistema hace petición a la base de datos para poder guardar la nueva información.


Si los datos son erróneo el sistema notificara de lo ocurrido.

Si no se logra guardar la información el sistema notifica del error de conexión.

11. CU10: MODIFICACIONES DE MATERIAS PRIMAS EN EL SISTEMA.

Casos de uso:

Modificación de materias primas.

CU10


Manager, administrador.

Objetivo:

Modificaciones de materias primas.

Disparador:

El usuario selecciono la opción del menú “modificaciones de materias primas”.

Descripción:

El usuario podar ser uso de esta sección para modificar cualquier error que se presente en

los registros de materias primas.

Pre-condición:


Post- condición:

El usuario podar tener acceso a los registros de materias primas para su modificación.


21

Fecha:

Versión:

0.1

Escenario.

Flujo normal:




2 El usuario selecciono la opción del

menú modificar materia prima. 3 El sistema procesa la petición y

muestra la interfaz de modificación.

4 El usuario hace uso dela interfaz e

ingresa los cambios necesarios. 5 Sistema procesa la información y

guarda.

6 Sistema notifica de lo ocurido.


Flujo alternativo:

3b Los campos son modificables.

4a El usuario trata de cambiar los datos ya almacenados pro errores de captura.

5b El sistema en conjunto con la ase de datos guardan lo modificado en el formulario.

Actualización.


Si los datos no son proporcionados correctamente el sistema notificara del error.

12. CU11: MODIFICACIONES DE PRODUCTOS EN EL SISTEMA.

Casos de uso:

Modificación de productos.

CU11



Objetivo:

El usuario podrá modificar datos que estén incorrectos.

Disparador:

El usuario selecciono la opción del menú “modificación de productos”.

Descripción:

El usuario podrá se usó de esta opción en caso de que un datos están mal capturados o dese

actualizar información.

Pre-condición:

El usuario debe de estar autentificados en e l sistema.

Post- condición:


22

El usuario puede modificar datos o actualizar datos de los algunos productos.

Fecha:

Versión:

0.1

Escenario.

Flujo normal:




2 El usuario selecciono del menú la

opción “modificar productos”.

3 El sistema ejecuta la acción y muestra

interfaz de modificación.

4 El usuario hace uso de la interfaz. 5 El sistema procesas la información y

actualiza los datos.

3 4 << CU_2. Salida/Regreso. >>

Flujo alternativo:

5b El sistema conjunto la base de datos guardan las actualizaciones. Volver a 4.

4a El usuario llena los datos que el formulario le pide para su actualización. Si son

incorrectos el sistema notifica.


En caso de producirse un error el sistema notificara del error ocurrido.

13. CU12: MODIFICACIONES DE PERSONAL EN EL SISTEMA.

Casos de uso:

Modificación de personal.

CU12



Objetivo:

Modificación de personal.

Disparador:

El usuario selecciona la opción del menú “modificación de personal”.

Descripción:

El usuario modifica datos incorrectos del personal o mal capturados.

Pre-condición:


Post- condición:

El usuario modifica o actualiza datos dentro del formulario del personal.

Fecha: Versión:


23

0.1

Escenario.

Flujo normal:





modificación de personal.

3 El sistema procesa la petición y

muestra la interfaz de modificación de

personal.

4 El usuario hace uso de la interface.

5 Guarda cambios 6 El sistema procesa la información y

guarda.


Flujo alternativo:

4a El usuario hace el llenado de los campos que se encuentran en el formulario y

selecciona actualizar.

5a El usuario decide que ya hizo los cambios necesarios así que decide guardar.

6a El sistema en conjunción con la base de datos guardan las actualizaciones.


Si los cambios fueron de manera errónea el sistema notificara sobre el error

ocurido.

14. CU13: REALIZACIÓN DE BAJA DE PRODUCTO DEL SISTEMA.

Casos de uso:

Bajas de productos.

CU13



Objetivo:

Dar de baja productos.

Disparador:

El usuario selecciono la opción del menú “baja de producto”.

Descripción:

En esta sección se buscaran y eliminara productos del inventario o registro de productos.

Pre-condición:

El usuario debe de estar autentificado en el sistema. Y el producto debe de estar registrado

posteriormente.


24

Post- condición:

El usuario podrá dar de baja productos que no existen o que ya no hay en existencia.

Fecha:

Versión:

0.1

Escenario.

Flujo normal:





menú “baja de producto”.

3 El sistema ejecuta la acción y muestra

interfaz de bajas.

4 El sistema muestra la lista de los

productos.

5 El usuario busca y selecciona lo que se

va a dar de baja.

6 Usuario da de baja 7 Sistema confirma la acción del usuario.

8 Mensaje de confirmación al usuario. 9 Se elimina el registro.


Flujo alternativo:

4b Sistema consulta base de datos y muestra los resultados de los diferentes productos.

9b El sistema elimina el registro de la base de datos.


Si no se confirma el mansaje de confirmación no se eliminara el registro.

15. CU14: REALIZACIÓN DE BAJA DE MATERIAS PRIMAS DEL SISTEMA.

Casos de uso:

Baja de materias primas.

CU14



Objetivo:

Dar de baja materias primas.

Disparador:

El usuario selecciona la opción del menú “bajas de materias primas”.

Descripción:

El usuario podrá eliminar registros de materias primas que ya no existen o no se

encuentran.


25

Pre-condición:

El usuario debe de estar autentificado en el sistema. La materia prima debe de estar

registrada previamente.

Post- condición:

El usuario dará de baja materias primas que ya no se encuentren en el inventario físico.

Fecha:

Versión:

0.1

Escenario.

Flujo normal:





manu “baja de materia prima”.

3 El sistema ejecuta la petición y muestra

interfaz.

4 Sistema muestra lista de materias

primas existentes.

5 El usuario selecciona o y realiza

acciones dentro de la interfaz y

selecciona guardar.

6 El sistema procesa las acciones y

ejecuta las acciones.

7 El sistema elimina el registro.

8 Sistema notifica de las acciones.

9 Usuario acepta la notificación y

confirma acción.


Flujo alternativo:

5b El sistema realiza una consulta a la base de datos y muestra resultados al usuario, ir a

5.

7b El sistema elimina el registro de la base de datos.


El sistema notifica de las acciones que se realizan y espera confirmación.

16. CU15: REALIZACIÓN DE BAJA DE PERSONAL DEL

SISTEMA.

Casos de uso:

Bajas de personal.

CU15



Objetivo:

Dar de baja personal en el sistema.


26

Disparador:

El usuario selecciona la opción del menú “baja de personal”.

Descripción:

El usuario podrá seleccionar y eliminar el registro y usuario del personal.

Pre-condición:

En usuario debe de estará autentificado en el sistema. Debe de a ver por lo menos una

persona registrada en el sistema.

Post- condición:

El usuario podrá eliminar un registro del personal.

Fecha:

Versión:

0.1

Escenario.

Flujo normal:




2 El usuario selecciona opción del menú

“baja de personal”.

3 Sistema procesa y ejecuta acción del

usuario, muestra interfaz de baja.

4 Usuario hace uso de la interfaz,

búsqueda del registro a eliminar.

5 Guarda cambios. 6 Procesa la información y procesa la

acción del usuario.

7 Manda mensaje de confirmación.

8 Usuario confirma acción. 9 Sistema elimina registro.


Flujo alternativo:

4a Usuario navega en interfaz. Realiza búsqueda. Obtiene resultados.

5a Selecciona botón de guardar cambios.

7b Si el usuario rechaza la confirmación el sistema cancela la acción, volver a 4.

8b El sistema hace petición a la base de datos para borrar el registro de usuario.


Los registros pueden ser borrados en excepción lo de categoría administrador del

sistema.

Por seguridad los registros de administrador son bloqueados en el sistema.


Diagrama de clases (realizado por el equipo de trabajo).

4.- Diagramas.


Diagrama de secuencia (realizado por el equipo de trabajo).


29

Diagrama de comunicación (realizado por el equipo de trabajo).


Los requerimientos del restaurante se muestran que los elementos y funciones son necesarias para el buen funcionamiento de la aplicación en su empresa y están comprendido en 3 partes: HARDWARE y SOFTWARE. SOFTWARE :

Sistema Operativo Windows 7 y Windows 8(el sistema deberá ser muy intuitivo debido a los usuarios que lo operaran)

Antivirus con licencia y actualizado de internet.

HARDWARE: Características CPU´s

Los equipos a utilizar deben tener mínimamente estas características: Ordenadores con procesador igual o mayor a un procesador de cuatro núcleos.

Memoria de un terabite para mantener los informes y espacio para el

almacenamiento sin peligro a perdidade datos por sobrecarga de el disco duro.

Tres equpos como requisito mínimo.( ya se cuenta con 1 equpo)

Implementcion de tres terminales totas tactiles.

Acceso a Internet (nota: este sistema no sera muy exigente asi que real mente no

se necesitan muchos requerimientos, el acceso a internet ya se tiene).

REQUERIMIENTOS DEL SISTEMA.


31

Impresoras:

o Cuentas: Impresoras térmicas estas impresoras por lo general son utilizadas para imprimir cuentas y pedidos en los puntos de producción.


32

El sistema beneficiara a la empresa en todos los sentidos, para un mejor

funcionamiento tanto interno como externo si mejora la calidad de los productos se

atraerán más clientes, abra más ventas, ganancias y todos los benéficos que todo

esto conlleva obviamente que esto está propenso y dispuesto a cambios,

conforme avanza el análisis completo de los problemas y oportunidades

encontradas y en el desarrollo del proyecto. Un tema también a tocar en este

análisis es la medición en que el sistema propuesto resolverá las oportunidades

encontradas el alcance de estas así como la satisfacción de los requerimientos

encontrados como la seguridad, capacidad etc. Que tan interesante o complejo le

parezca el equipo usado al usuario final (la interfaz de los usuarios con el

sistema), esto depende mucho del tiempo que el cliente este facilitando para el

estudio de factibilidad y la medición de costo-beneficio.

Los costos y beneficios se estiman por medio del análisis para determinar la

factibilidad económica.

FACTIBILIDAD DEL SISTEMA.


33

FACTIBILIDAD OPERATIVA:

Este sistema hace énfasis en la solución de un problema real, para mejorar

el servicio que se le da a los clientes, cuál es este, el hecho de que la

materia prima que es con que se elabora los platillos en el restaurante hay

ocasiones en que hace falta por ejemplo: al momento de que el mesero acuda

con el cliente y le solicite cierto platillo del menú, y el chef le diga que no se

puede hacer este platillo porque se acabo o no se puede preparar porque

faltan las materias primas para hacerlo. Con materias primas nos referimos a

los ingredientes con los que se preparan los alimentos, entonces va ha hacer

posible el uso de este sistema porque se va enfocar en un problema que existe

y que queremos solucionar para que el restaurante no vaya a perder clientes y

analizando la problemática se tendrá la posibilidad que los usuarios les interese

el uso de este sistema ya que se les va a ofrecer mejor servicio.

FACTIBILIDAD TÉCNICA:

El negocio aun no cuenta con el hardware necesario pero es posible conseguirlo

en el mercado ya que el restaurante es un lugar pequeño y por lo tanto el sistema

debe de ser accesible y fácil de entender como de manejar al igual que se debe de

contar con un paradigma de programación el cual se va a realizar de acuerdo a el

sistema del restaurante con un diseño muy apropiado por lo cual elegimos el uso

de el software Visual BASIC porque es fácil de utilizar nos referimos a que en

cuanto al manejo de este software será más entendible debido a sus interfaces y

el lenguaje empleado y esto será mucho mejor entendible para el usuario ya que

puede contener colores llamativos e intuitivos entre muchos otras cosas.


34

Recomendaciones.

Es necesario que la tecnología usada sea tecnología de vanguardia.

Toda la información deberá tener respaldo.

El sistema deberá tener un lugar exclusivo para él donde pueda estar bajo llave y

resguardado de personas ajenas solo el personal autorizado podrá tener acceso a

él.

Se debe realizar un examen alas persona con acceso al sistema, si no está

capacitado será necesario capacitarlo.

Documents

Reporte ads meson del sazon