Carpeta para Entregar PP3

PRACTICA PROFESIONALIZANTE III
“SISTEMA DE INFORMACION GHAFF”
ALUMNO: AVENDAÑO SERGIO RUBEN

AÑO DE CURSADO: 2018
Introducción al proyecto
El proyecto sobre la realización del trabajo final está encarado para el negocio
‘Ghaff’ que es una boutique de ropa de mujer, que se especializa sobre todo en
talles grandes.
Se viene trabajando sobre cada uno de los puntos de análisis, diseño e
implementación que propone cada una de las materias de trabajo final en las
materias anteriores.
Así mismo, se ha encarado el proyecto con una de las metodologías ágiles
como es ‘Scrum’ por lo que el proyecto ha sido dividido en varios sprints.
En la materia que nos compete se trabajará sobre los:
- Sprint 0:
- Sprint 1: ‘Planes de Tarjetas de Bancos’
- Sprint 2: ‘Ventas’
- Sprint 3: ‘Ventas 2’
- Sprint 4: ‘Gestión de usuario’
Se gestionará el desarrollo de estos sprints, elaborando el product backlog de la
materia, luego para cada uno de ellos, el sprint backlog en el que se podrá organizar
y diagramar los recursos y tareas necesarias para lograr el éxito del proyecto.
Este periodo de cursado también implicará revisar cada uno de los puntos en el
alcance, para poder tener la visión global de lo construido, refinar si es necesario y
dejar el sistema que esté adaptado a cada uno de los requerimientos del cliente.
.
Sistema de Inventario Práctica Profesional II
Modelo de Análisis y Diseño
Sergio Rubén Avendaño pág. 3

Introducción al modelo de análisis y diseño
El modelo de análisis y diseño es una etapa en la que se puede identificar

desde el criterio analítico las funcionalidades para realizar. Las mismas se agrupan
en un inventario de historias de usuario llamado ‘product backlog’. El mismo se inicia
con la descripción de cada una de las historias de usuario correspondientes a cada
sprint de la materia.
En este caso contamos con cuatro sprints a saber:
- Sprint 0:
- Sprint 1: ‘Planes de Tarjetas de Bancos’
- Sprint 2: ‘Ventas’
- Sprint 3: ‘Ventas 2’
- Sprint 4: ‘Gestión de usuario’
Cada uno de ellos está formado por cuatro o cinco historias de usuario, lo que
ayuda a analizar a cada una con detenimiento y reviendo las interfaces, validaciones
y reglas de negocio de cada una de ellas.
Con estas definiciones analíticas se puede direccionar el proyecto al diseño
del mismo, en donde se puede verificar que cada punto analizado cumpla con los
requerimientos del cliente. De acuerdo a esta verificación, se puede refinar las veces
que sea necesario hasta que el sistema cumpla con:
- Los requerimientos del cliente
- Navegabilidad funcional adecuada
- Interfaces amigables
Es una etapa primordial en un proyecto de software, por lo tanto, ¡manos a la obra!

Modelo de Implementación y Prueba

Product Backlog:
Identificador
Dimensión/
(ID) de la Enunciado de la Historia Alias Estado Iteración (Sprint)
Esfuerzo
Historia
Como usuario necesito poder Listado de Nro. 0

1 consultar todas las formas de pago forma de pago Finalizado 6hs
‘Preparación’
para poder gestionar las ventas
Como usuario necesito poder Registrar Nro. 0

2 registrar las formas de pago para Forma de pago Finalizado 8hs
‘Preparación’
poder gestionar las ventas
Como usuario necesito poder Nro. 0

Editar
3 editar las formas de pago para Finalizado 6hs
Forma de pago ‘Preparación’
Como usuario quisiera poder

borrar uno o más formas de pago Nro. 0
4 Eliminar Finalizado 6hs
que no se utilicen por ejemplo, o ‘Preparación’
Forma de pago
algún otro caso similar.

5 consultar todos los bancos con los bancos Finalizado 6hs
‘Preparación’
que trabaja la empresa

6 registrar uno o más bancos para banco Finalizado 8hs
‘Preparación’

Como usuario necesito poder

editar uno de los bancos Editar Nro. 0
7 Finalizado 6hs
registrados para poder gestionar banco ‘Preparación’
las ventas

borrar uno o más bancos que no Nro. 0
se utilicen por ejemplo, o algún ‘Preparación’
banco
otro caso similar.

9 registrar las tarjetas para poder tarjetas Finalizado 3hs
‘Preparación’
gestionar las ventas
Como usuario necesito poder Nro. 0

Editar
10 editar las tarjetas para poder Finalizado 3hs
tarjetas ‘Preparación’
gestionar las ventas

borrar uno o más tarjetas que no Nro. 0
se utilicen por ejemplo, o algún ‘Preparación’
tarjetas
otro caso similar.
Total de horas 67 horas

Nro. 1
conocer todos los planes de Listado de
12 Finalizado 7hs ‘Planes de
tarjetas que tengo registrados banco, tarjeta y
Tarjetas’
ordenados por banco plan

Nro. 1
registrar los planes de tarjetas de Registrar de
13 Finalizado 7hs ‘Planes de
los bancos con los que trabaja la Planes de
Tarjetas’
empresa tarjetas

Como usuario quisiera poder Eliminar Nro. 1

eliminar un plan de alguna tarjeta
14 (borrado lógico) Finalizado 7hs ‘Planes de
de uno o más bancos con los que Planes de Tarjetas’
trabaja la empresa tarjetas

15 consultar todas las ventas ventas Pendiente 10hs
‘Ventas 1’
generadas en la empresa
Como usuario necesito poder

registrar uno o más ventas para Registrar Nro. 2
16 venta Pendiente 16hs
poder registrar los ingresos de la ‘Ventas 1’
empresa
Como usuario necesito poder Registrar

registrar la anulación de una o anulación de Nro. 2
17 Pendiente 10hs
más ventas para poder registrar venta ‘Ventas 1’
los ingresos de la empresa
Como usuario quisiera poder emitir Nro. 3

18 una factura de venta para poder Emitir factura de Pendiente 16hs
‘Ventas 2’
darle a mis clientes venta

generar un listado de ventas por Generar listado Nro. 3
19 Pendiente 16hs
cliente para poder hacer beneficios de ventas por ‘Ventas 2’
personalizados clientes

Como usuario quisiera poder Generar reporte

generar un reporte de ventas Nro. 3
20 de ventas Pendiente 16hs
realizadas con tarjeta para poder ‘Ventas 2’
realizadas con
generar beneficios a mis clientes tarjeta
Como usuario quisiera poder Generar reporte

generar un reporte de ventas Nro. 3
21 de ventas Pendiente 16hs
realizadas al contado para poder ‘Ventas 2’
realizadas al
generar beneficios a mis clientes contado

consultar todos los usuarios del Nro. 4
22 Listado de Pendiente 6hs
sistema registrado para identificar ‘Usuarios’
usuarios
cada uno de sus roles y permisos

registrar uno o más usuarios del Nro. 4
23 Registrar Pendiente 10hs
sistema registrado para identificar ‘Usuarios’
usuario

editar uno o más usuarios del Nro. 4
24 Pendiente 10hs
sistema registrado para identificar Editar usuario ‘Usuarios’

eliminar uno o más usuarios del Nro. 4
25 Pendiente 6hs
sistema registrado para identificar Eliminar usuario ‘Usuarios’

registrar los roles y permisos a uno Registrar roles y Nro. 4
26 o más usuarios del sistema Pendiente 16hs
permisos a un ‘Usuarios’
registrado para identificar cada usuario
uno de sus roles y permisos


editar los roles y permisos a uno o Editar roles y Nro. 4
27 más usuarios del sistema Pendiente 10hs
permisos a un ‘Usuarios’
registrado para identificar cada usuario

consultar los roles y permisos de Consultar roles Nro. 4
28 uno o más usuarios del sistema Pendiente 6hs
y permisos de ‘Usuarios’
registrado para identificar cada un usuario
Aclaración:
Las historias de usuario que tienen como funcionalidad ‘Eliminar’, representa un borrado
lógico. Para el usuario a nivel de interfaz estará eliminado, pero internamente en la base de
datos, cada tabla poseerá un campo ‘Anulado’ o ‘Borrado’ de tipo BIT, que cuando se crea el
mismo o edita, este campo estará en FALSE, y cuando el usuario lo ‘elimine’ en la interfaz,
este campo se actualizará en TRUE. De ese modo, no se pierde histórico de los datos.
Estimación:
Se planifica dedicar por día 3 horas aproximadamente, por lo que el sprint 0
correspondiente a las historias de usuario de ‘Preparación’ tendrá una duración de 23 días.
correspondiente a las historias de usuario de ‘Planes de Tarjetas de bancos’ tendrá una
duración de 7 días.
correspondiente a las historias de usuario de ‘Ventas 1’ tendrá una duración de 12 días.
correspondiente a las historias de usuario de ‘Ventas 2’ tendrá una duración de 22 días.
correspondiente a las historias de usuario de ‘Usuarios’ tendrá una duración de 22 días.
Riesgos:
- Existen algunas funcionalidades que se presentan con dificultad respecto a la
programación de las mismas. Esto requerirá tiempo de investigación y consultas de
ayuda sobre el tema, afectando el tiempo definido de cada sprint
Aclaración: Para cada sprint se realiza una estimación de horas promedio por cada uno
teniendo en cuenta las horas estimadas respecto de las horas reales.

Planificación

Plan de Trabajo Sprint
FECHA INICIO 31/08/2018

Sprint 0 ‘Preparación’
Sprint 0 HU Esfuerzo Observaciones RRHH
HU 1 6 Listado de forma de pago Sergio Avendaño
HU 2 8 Registrar forma de pago Sergio Avendaño
HU 3 6 Editar forma de pago Sergio Avendaño
HU 4 6 Eliminar forma de pago Sergio Avendaño
HU 5 6 Listado de bancos Sergio Avendaño
HU 6 8 Registrar bancos Sergio Avendaño
HU 7 6 Editar bancos Sergio Avendaño
HU 8 6 Reporte de bancos Sergio Avendaño
HU 9 8 Registrar tarjeta Sergio Avendaño
HU 10 6 Editar tarjeta Sergio Avendaño
HU 11 6 Eliminar tarjeta Sergio Avendaño
FECHA FIN 27/09/2018
Sprint 1 ‘Planes de Tarjeta de Bancos’
FECHA INICIO 28/09/2018
HU 12 7 Listado de planes de Sergio Avendaño
tarjeta
HU 13 7 Registrar planes de Sergio Avendaño
tarjeta
HU 14 7 Eliminar planes de tarjeta Sergio Avendaño
FECHA FIN 05/10/2018
Observaciones: En el sprint 0 y el sprint 1 hubo cambios y correcciones en el armado de
los sprints, por lo que esto provocó un desfasaje de la primera planificación realizada.
Cuando se realizó la primera vez el desempeño 2 y 3, se definieron 7 sprints de cinco

historias de usuario cada una, sin embargo en base a definiciones de la clase, se

corrigió para que queden 4 sprint más el sprint 0 de preparación en total para la
materia PP3. Estas correcciones provocaron una re planificación en el plan de trabajo
de 21 días.
Sprint 2 ‘Ventas 1’
FECHA INICIO PLANIFICADA 02/10/2018
FECHA INICIO REAL 23/10/2018
HU 15 10 Listado de ventas Sergio Avendaño
HU 16 16 Registrar venta Sergio Avendaño
HU 17 10 Registrar anulación de Sergio Avendaño
venta
FECHA FIN PLANIFICADA 14/10/2018
FECHA FIN REAL 04/11/2018
Sprint 3 ‘Ventas2’
HU 18 16 Emitir factura de venta Sergio Avendaño
HU 19 16 Generar listado de ventas Sergio Avendaño
por clientes
HU 20 16 Generar reporte de Sergio Avendaño
ventas realizadas con
tarjeta de crédito
HU 21 16 Generar reporte de Sergio Avendaño
ventas realizadas al
contado
FECHA FIN REAL 27/11/2018
Sprint 4 ‘Usuarios’


HU 22 6 Listado de usuarios Sergio Avendaño
HU 23 10 Registrar usuario Sergio Avendaño
HU 24 10 Editar usuario Sergio Avendaño
HU 25 6 Eliminar usuario Sergio Avendaño
HU 26 16 Registrar roles y Sergio Avendaño
permisos a un usuario
HU 27 10 Editar roles y permisos a Sergio Avendaño
un usuario
HU 28 6 Eliminar roles y Sergio Avendaño
permisos a un usuario
FECHA FIIN REAL 12/12/2018
Objetivo de cada Sprint
- Sprint 0 ‘Preparación’:
 Gestionar los ABM de datos necesarios para los próximos sprints. Este sprint
es de preparación de los datos de soporte.
- Sprint 1 ‘Planes de Tarjetas de Bancos:
 Gestionar los datos de todos los bancos, sus tarjetas y sus planes con los
que trabaja la empresa que serán usadas para las ventas.
- Sprint 2 - 3 ‘Ventas’:
 Gestionar las ventas realizadas a los clientes y emitir la factura de la misma
- Sprint 4 ‘Usuarios’:
 Gestionar los usuarios del sistema como así también sus roles y permisos

Plan de trabajo - Diagrama de Gantt

En el primer plan de trabajo se presenta la planificación realizada de los sprints a principio
del dictado de clases. En el segundo plan de trabajo se presentan las fechas reales en las
que se fueron realizando las actividades, por lo que nos da una visión de lo planificado
versus lo real.
FECHA INICIO
TAREAS FECHA FIN PLANIFICADA
PLANIFICADO
Sprint 4 – Forma de Pago 31/08/2018 07/09/2018
Sprint 5 - Bancos 11/09/2018 21/09/2018
Demo 24/09/2018 (lunes)
Sprint 6 – Tarjetas 24/09/2018 27/09/2018
Sprint 7 – Planes de Tarjetas 28/09/2018 01/10/2018
Demo 01/10/2018 (lunes)
Sprint 8 – Ventas 1 02/10/2018 14/10/2018
Demo 15/10/2018 (lunes)
Sprint 9 – Ventas 2 15/10/2018 05/11/2018
Demo 05/11/2018 (lunes)
Sprint 10 - Usuarios 06/11/2018 26/11/2018
Release Final 26/11/2018 (lunes)
TAREAS FECHA INICIO REAL FECHA FIN REAL
Sprint 0: ‘Preparación’ 31/08/2018 27/09/2018
Sprint 1: ‘Planes de Tarjetas

de Bancos’ 28/09/2018 05/10/2018
Demo (primera presentación) 10/09/2018 (lunes)
Demo (segunda presentación) 01/10/2018 (lunes)
Demo (tercera presentación) 08/10/2018 (lunes)
Demo (cuarta presentación) 22/10/2018 (lunes)
Sprint 2 – Ventas 1 23/10/2018 04/11/2018
Demo 01/10/2018 (lunes)

Sprint 3 – Ventas 2 05/11/2018 26/11/2018
Demo 26/11/2018 (lunes)
Sprint 4 – Usuarios 20/11/2018 12/12/2018
Demo

Sprint Backlog Nro. 0: ‘Preparación’

- SPRINT BACKLOG
- GRAFICO DE AVANCE DEL SPRINT NRO. 0
El gráfico de avance nos permite monitorizar el ritmo de avance, y detectar de forma temprana
posibles desviaciones sobre la previsión que pudieran comprometer la entrega al final de sprint.
En este caso en el sprint 0 hubo desviaciones entre lo planificado y lo real, como se indica a
continuación en el gráfico:

Referencias del gráfico:
- la línea bordo del gráfico nos indica la línea de tiempo en la que se estimó realizar todas las
tareas del sprint, en la cual se puede observar cómo esta linea está en forma decreciente, ya
que en el día 1 (comienzo del sprint) se muestra que existen todas las tareas por realizar,
pero a medida que pasan los días, las tareas van reduciéndose hasta finalizar las mismas al
día 21.
- la línea azul del gráfico nos indica la línea de tiempo en el que se fueron realizando en la
realidad todas las tareas del sprint.
Es importante destacar que mientras más por debajo se encuentre esta línea azul de la línea
roja, significará que nuestro proyecto está adelantado a lo estimado, y mientras más por

arriba se encuentre la línea azul de la linea bordó, significará que nuestro proyecto se está
retrasando con respecto a los tiempos previstos.
- BASE DE DATOS

- PROTOTIPOS DEL SPRINT 0
Listado de formas de pago:
Registrar forma de pago:

Editar forma de pago:
Eliminar forma de pago:
Listado de Bancos:

Registrar Banco:
Editar Banco:
Eliminar Banco:

Reporte de Bancos:

Registrar Tarjeta:
Editar Tarjeta:

Eliminar Tarjeta:
Retrospectiva del sprint 0:
Una retrospectiva no sólo debe fijarse en la solución de problemas (podría quedar una sensación
demasiado negativa de que las cosas no van bien), si no también hacer reconocimiento de las cosas
que fueron bien e identificar las que hay que potenciar más.
Por eso en esta oportunidad, y haciendo la retrospectiva de lo recorrido en este sprint 0, se pueden
definir los siguientes puntos:
¿Qué ha funcionado bien?
Dado que he realizado un recorrido en la materia anterior de Práctica Profesionalizante 2, entonces
se tiene una agilidad en la programación y confección de los desempeños que se van solicitando, por
lo que en eso he podido avanzar. Así mismo, he podido organizar mis tiempos para proseguir y
cumplir con los tiempos previstos de la clase.
Ante los inconvenientes que se presentaron en la programación del sprint 0, se pudieron solucionar
más rápido ya que tengo la experiencia de los sprints anteriores del trabajo final.
¿Qué no ha funcionado bien?

En este sprint se presentaron varias revisiones de la carpeta y los desempeños solicitados. Esas
revisiones estuvieron enfocadas en la corrección de la división de los sprints propuestos.
Primero se propuso una división de sprints, pero al haber cambios solicitados, impacto en el tiempo
planificado, cambios en lo que se venía programando como así también cambios en la
documentación. Esto representó un marcado retraso de lo planificado.
Así mismo, las revisiones estuvieron afectadas por detectar que faltaba una entidad importante
como es la de ‘PlanesTarjetasBancos’ que si bien estaban contempladas, no estaba realizada la
entidad asociativa.

Plan de Acción:
- Tener definidos los temas solicitados por cada desempeño a principio del cuatrimestre, para
que la planificación de la realización de estos, se pueda realizar con tiempo para poder
cumplirlos.
- Que los cambios que se produzcan en cada desempeño sean los menores, para que el
impacto sea menor
- Dedicar mayor tiempo al mapeo de base de datos a principio, para que una vez completo y
correcto, no se provoquen cambios en cuanto a las tablas definidas, o que si surgen cambios
de tablas que no se encuentran, sean las menores.
Conclusión de la reunión de retrospectiva:

Creo que de cada situación se aprende, quizás mi objetivo es alto, ya que quiero poder llevar al día
mi carpeta de la materia como así también el sistema, para poder concluir la misma en la finalización
del cuatrimestre. Sin embargo, intento por completo lograr este objetivo.
Espero que el próximo sprint pueda aprender de estas conclusiones para que salga mejor.

Sprint Backlog Nro. 1: ‘Planes de Tarjetas de Bancos’

- SPRINT BACKLOG
En este caso en el sprint 1 hubo desviaciones entre lo planificado y lo real, como se indica a
continuación en el gráfico:

día 7.
- la línea azul del gráfico nos indica la línea de tiempo en el que se fueron realizando en la

- BASE DE DATOS

Listado de planes de tarjetas de bancos:
Registrar planes de tarjetas de bancos:

Editar planes de tarjetas de bancos:

Retrospectiva del sprint 1:
Una retrospectiva no sólo debe fijarse en la solución de problemas (podría quedar una sensación
demasiado negativa de que las cosas no van bien), si no también hacer reconocimiento de las cosas
que fueron bien e identificar las que hay que potenciar más.
Por eso en esta oportunidad, y haciendo la retrospectiva de lo recorrido en este sprint 1, se pueden
definir los siguientes puntos:
¿Qué ha funcionado bien?
En este sprint pude avanzar con los tiempos replanificados, así mismo se pudo avanzar rápidamente
cuando surgieron inconvenientes, o dudas en la programación como así también en la carpeta.
¿Qué no ha funcionado bien?

En este sprint si bien ya se tienen definidos cada uno de los sprints, se produjeron cuestiones
personales a los que debo estar enfocado. Por lo que en lugar de poder dedicar 3 hs cada día al
trabajo final, es podido dedicar quizás menos, tratando de algunos días en los que he podido estar
más horas para no atrasarme.
En lo personal, doy lo mejor de mí para proseguir con mis objetivos
Plan de Acción:
- Continuar organizado en los tiempos
- Continuar organizado en la programación
- Continuar organizado en la realización de la documentación
Conclusión de la reunión de retrospectiva:

Como dije anteriormente, mi objetivo es llevar la carpeta y el sistema al día. La realidad me está
presentando otras cuestiones, pero sigo firmemente con este objetivo, tratando de dar lo mejor de
mí

Sprint Backlog Nro. 2: ‘Ventas 1’

- SPRINT BACKLOG
En esta oportunidad no se está pudiendo avanzar con el sprint 2, por motivos personales.
Posibles Desviaciones:
- Planificado:
El sprint está previsto en una duración de 12 días, de esa forma se planificó iniciar el día
martes 23 de octubre para finalizar el día 04 de noviembre, teniendo en cuenta que por día
se planificó un total de 3 horas.
- Real:
Por motivos personales, no he podido dedicar 3 horas por día como se planificó, por lo que la
tendencia de lo planificado vs lo real, a mitad del sprint se puede observar una demora en la
fecha de entrega del sprint 2.

día 12.
- la línea azul del gráfico nos indica la línea de tiempo en el que se van realizando en la
En este caso se observa la linea azul hasta el día 7 que es el tiempo transcurrido, así mismo
como la línea azul que es la que marca lo esfuerzo real, se puede observar muy por encima
del esfuerzo planificado, representando un retraso en el sprint 2 respecto de lo planificado.

- BASE DE DATOS


Los prototipos del sprint 2 aún no están finalizados.

Apéndice

A.1 Alcance de PP2
O Brindar información en relación a todo el proceso que involucra el ingreso y

egreso de mercadería, lo que permitirá al cliente conocer de manera fidedigna su
stock.
O Favorecer el manejo eficaz y eficiente de la empresa mediante el uso de la
aplicación.
Requerimientos del Usuario
Requerimientos del Usuario

Como inconvenientes en relación al funcionamiento del local señalo:
 Saber efectivamente cual es el stock de mercadería con el que cuenta
 Tener un control preciso de lo que se vende por día, ya sea en efectivo o por
tarjeta
 Tener una lista de sus clientes” el trato es muy importante y saber cómo
se llaman mis clientas, numero de talla… me encartaría porque el trato
sería más familiar”.
Cabe aclarar que todos los movimientos (por ejemplo: el ingreso de la
mercadería, lo que se vende, stock, etc.) se hacen a la vieja usanza, expresando la
propietaria: “lo anotamos con lápiz y papel, eso en el mejor de los casos de que
todo quedara anotado”.
Las cuestiones detalladas con antelación fueron expuestas por la propietaria
durante las entrevistas, quedo en evidencia de que se convierten en dificultades de
importancia para la Sra. Contreras en relación al funcionamiento de su negocio.
Requerimientos Funcionales
El Sistema de Información Ghaff deberá:
Administrar productos RG

 Registrar productos por categoría RD

 Modificar productos RD
 Actualizar categoría RD
 Actualizar talle RD
 Consultar datos de productos RD
 Generar un listado de productos por categoría RD
 Generar reporte de inventario RD
Administrar clientes RG
 Registrar datos del cliente RD
 Actualizar barrio RD
 Actualizar localidad RD
 Modificar datos del cliente RD
 Consultar datos del cliente RD
 Emitir listado de clientes RD
 Generar listado de productos por clientes RD
Administrar ventas RG
 Registrar venta RD
 Consultar venta RD
 Actualizar forma de pago RD
 Actualizar Banco RD
 Actualizar Plan RD
 Registrar anulación de venta RD
 Emitir factura de venta
 Generar reporte de ventas realizadas de contado RD
 Generar reporte de ventas realizadas con tarjeta RD
Administrar Marketing RG
 Registrar producto por temporada RD

 Registrar promoción de producto por evento RD

 Modificar producto por temporada RD
 Modificar promoción de producto por temporada RD
 Consultar promociones RD
 Generar reporte de promociones por evento RD
 Generar reporte de producto por temporada RD
Requerimientos No Funcionales
o El sistema poseerá gestión de usuarios, cada uno con sus roles y sus
permisos correspondientes
o El Sistema de Información funcionara con permisos especiales para
Administración.
o El Sistema de Información registrara para cada usuario, según su rol, una
clave única teniendo en cuenta el área a la cual pertenezca, generando el
permiso que le corresponda.

A2. Modelo de Requisitos
Funcionalidades
que abarcan en
la materia PP2
Funcionalidades
que abarcan en
la materia PP2
Funcionalidades
que abarcan en la
materia PP2
Funcionalidades
que abarcan en la
materia PP2

Tablas de Actores y Roles
Actor Rol
Responsable de administrar y actualizar
la información general del sistema,
Administrador del Sistema.(R.AS)
incluida también la información de los
usuarios para ingreso al sistema
Nota: Las funcionalidades:
- Registrar cuenta de usuario

- Actualizar cuenta de usuario
- Actualizar forma de pago
- Actualizar banco
- Actualizar plan
Forman parte del desarrollo de la materia de PP3.
Actor Rol
Responsable administrar y actualizar los
Responsable de Productos (R.P)
productos en stock
Nota: Estas funcionalidades son las que se desarrollarán en la materia de PP2.

Actor Rol
Responsable de ventas (R.V) Responsable administrar y actualizar las
ventas del negocio

Actor Rol
Responsable administrar y actualizar la
información de los clientes
Responsable de Atención al Cliente
(R.A.C)
Actor Rol
Responsable del marketing de la Responsable administrar y actualizar la
Empresa información de marketing de la Empres
(R.M.E)

A3. Modelo de Diseño

Mapeo a BDR

Modelo Relacional de Base de Datos

Carpeta para Entregar PP3

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Carpeta para Entregar PP3

Cargado por

Copyright:

Formatos disponibles

PRACTICA PROFESIONALIZANTE III

“SISTEMA DE INFORMACION GHAFF”

ALUMNO: AVENDAÑO SERGIO RUBEN

Modelo de Análisis y Diseño

Sergio Rubén Avendaño pág. 3

Introducción al modelo de análisis y diseño

El modelo de análisis y diseño es una etapa en la que se puede identificar

Sergio Rubén Avendaño pág. 4

Modelo de Implementación y Prueba

Sergio Rubén Avendaño pág. 5

Como usuario necesito poder Listado de Nro. 0

Como usuario necesito poder Registrar Nro. 0

Como usuario necesito poder Nro. 0

Como usuario quisiera poder

Como usuario necesito poder Listado de Nro. 0

Como usuario necesito poder Registrar Nro. 0

Sergio Rubén Avendaño pág. 6

Como usuario necesito poder

Como usuario quisiera poder

Como usuario necesito poder Registrar Nro. 0

Como usuario necesito poder Nro. 0

Como usuario quisiera poder

Total de horas 67 horas

Como usuario quisiera poder

Como usuario quisiera poder

Sergio Rubén Avendaño pág. 7

Como usuario quisiera poder Eliminar Nro. 1

Total de horas 21 horas

Como usuario necesito poder Listado de Nro. 2

Como usuario necesito poder

Como usuario necesito poder Registrar

Total de horas 36 horas

Como usuario quisiera poder emitir Nro. 3

Como usuario quisiera poder

Sergio Rubén Avendaño pág. 8

Como usuario quisiera poder Generar reporte

Como usuario quisiera poder Generar reporte

Total de horas 64 horas

Como usuario quisiera poder

Como usuario quisiera poder

Como usuario quisiera poder

Como usuario quisiera poder

Como usuario quisiera poder

Sergio Rubén Avendaño pág. 9

Como usuario quisiera poder

Como usuario quisiera poder

Total de horas 64 horas

Sergio Rubén Avendaño pág. 10

Sergio Rubén Avendaño pág. 11

Plan de Trabajo Sprint

FECHA INICIO 31/08/2018

Sergio Rubén Avendaño pág. 12

historias de usuario cada una, sin embargo en base a definiciones de la clase, se

Sergio Rubén Avendaño pág. 13

Sprint 4 HU Esfuerzo Observaciones RRHH

Objetivo de cada Sprint

Sergio Rubén Avendaño pág. 14

Plan de trabajo - Diagrama de Gantt

Sprint 4 – Forma de Pago 31/08/2018 07/09/2018

Sprint 5 - Bancos 11/09/2018 21/09/2018

Demo 24/09/2018 (lunes)

Sprint 6 – Tarjetas 24/09/2018 27/09/2018

Sprint 7 – Planes de Tarjetas 28/09/2018 01/10/2018