Categorias de los WebApps

Categoría	Descripción
Informativa	El contenido de solo lectura con navegación.
Descarga	Descarga información del servidor apropiado.
Personalizable	El usuario personaliza sus necesidades especificas.
Interacción	La interacción entre una comunidad de personas lo que se le conoce como relaciones sociales a través de Internet
Entrada de usuario	La entrada un registro para una base de datos un mecanismo para la comunicación.
Orientación a transacciones	El usuario realiza una solicitud por ejemplo hace un pedido aquí podemos poner muchos ejemplos como la compra de ebay o el encardo de supermercado pero también las transacciones de base de datos.

Proceso de Scrum

Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos.

Hablando del proceso, un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones que normalmente son de 2 semanas, aunque en algunos equipos son de 3 y hasta 4 semanas, límite máximo de feedback y reflexión). Cada iteración tiene que proporcionar un resultado completo, un incremento de producto final que sea susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo solicite. El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa como plan del proyecto. En esta lista el cliente prioriza los objetivos balanceando el valor que le aportan respecto a su coste y quedan repartidos en iteraciones y entregas.

Planeacion de iteracion

Primera parte de la reunión:

-Se realiza en un timebox de cómo máximo 4 horas.

-El cliente presenta al equipo la lista de requisitos priorizada del producto o proyecto, pone nombre a la meta de la iteración (de manera que ayude a tomar decisiones durante su ejecución) y propone los requisitos más prioritarios a desarrollar en ella.

-El equipo examina la lista, pregunta al cliente las dudas que le surgen, añade más condiciones de satisfacción y selecciona los objetivos/requisitos más prioritarios que se compromete a completar en la iteración, de manera que puedan ser entregados si el cliente lo solicita.

Segunda parte de la reunión.

-Se realiza en un timebox de cómo máximo 4 horas.

-El equipo planifica la iteración, elabora la táctica que le permitirá conseguir el mejor resultado posible con el mínimo esfuerzo. Esta actividad la realiza el equipo dado que ha adquirido un compromiso, es el responsable de organizar su trabajo y es quien mejor conoce cómo realizarlo.

-Define las tareas necesarias para poder completar cada objetivo/requisito, creando la lista de tareas de la iteración (Sprint Backlog) basándose en la definición de completado.

-Realiza una estimación conjunta del esfuerzo necesario para realizar cada tarea.

-Cada miembro del equipo se autoasigna a las tareas que puede realizar.

Ejecucion de la iteracion

Cada iteración tiene que proporcionar un resultado completo, un incremento de producto que sea potencialmente entregable, de manera que cuando el cliente (Product Owner) lo solicite sólo sea necesario un esfuerzo mínimo para que el producto este disponible para ser utilizado. Para ello, durante la iteración el equipo colabora estrechamente y se llevan a cabo las siguientes dinámicas:

-Cada día el equipo realiza una reunión de sincronización, donde cada miembro inspecciona el trabajo de los otros para poder hacer las adaptaciones necesarias, comunica cuales son los impedimentos con que se encuentra, actualiza el estado de la lista de tareas de la iteración (Sprint Backlog) y los gráficos de trabajo pendiente (Burndown charts).

-El Facilitador (Scrum Master) se encarga de que el equipo pueda cumplir con su compromiso y de que no se merme su productividad.

    *Elimina los obstáculos que el equipo no puede resolver por sí mismo.

    *Protege al equipo de interrupciones externas que puedan afectar su compromiso o su       productividad.

El último día de la iteración se realiza la reunión de revisión de la iteración.

Tiene dos partes:

1. Demostración (4 horas máximo). El equipo presenta al cliente los requisitos completados en la iteración, en forma de incremento de producto preparado para ser entregado con el mínimo esfuerzo.

2. Retrospectiva (4 horas máximo). El equipo analiza cómo ha sido su manera de trabajar y cuáles son los problemas que podrían impedirle progresar adecuadamente, mejorando de manera continua su productividad.

Referencias

https://es.wikipedia.org/wiki/Scrum_(desarrollo_de_software)

http://juan-garcia-carmona.blogspot.mx/2012/08/mi-resumen-de-scrum.html

Historias de usuario

Historia de Usuario
Número: 10.	Nombre: Venta de tarjetas de metro
Modificación (o extensión) de Historia de Usuario (No. y Nombre):
Usuario: Usuario del metro y cajero		Iteración Asignada: 1
Prioridad  en Negocio: Alta		Puntos Estimados: 10 horas
Riesgo en Desarrollo: Medio		Puntos Reales:
Descripción: El usuario del metro irá a un cajero a comprar una tarjeta que posteriormente usará para poder usar el servicio de metro e ir de una zona a otra o permanecer en la misma.
Observaciones:

Caso de Prueba de Aceptación
Código:	Historia de Usuario (Nro. y Nombre): Venta de tarjeta No. 10
Nombre: Validación de tarjeta
Descripción: Al comprar la tarjeta que se valide su saldo y su id
Condiciones de Ejecución: El usuario debe haber pagado la tarjeta
Entrada / Pasos de ejecución: El usuario paga la tarjeta y la carga de saldo.
Resultado Esperado: El sistema da de alta su id y acumula la cantidad de dinero que deposito el usuario.
Evaluación de la Prueba:

Tarea de Ingeniería
Número Tarea: 2	Historia de Usuario (Nro. y Nombre): Venta de Tarjetas No. 10
Nombre Tarea: Tarifas de metro
Tipo de Tarea : Desarrollo		Puntos Estimados: 10 horas
Fecha de Inicio: 09/03/2017		Fecha de culminación. 09/03/2017
Programador Responsable: Cano Ramos Alfredo Erick y Sánchez Peña Axel
Descripción: Se hará un estándar de las tarifas para ir de una zona a otra especificando cuales son las estaciones que están en cada zona y así evitar confusiones. También se hará una tabla general en donde se coloquen todas las estaciones con sus posibles tarifas dependiendo de la zona  en que se encuentre y a las zonas en que puede acabar usando dicha estación.

Tarea de Ingeniería
Número Tarea: 1	Historia de Usuario (Nro. y Nombre): Venta de Tarjeta No. 10
Nombre Tarea: Registro de Tarjeta
Tipo de Tarea : Desarrollo		Puntos Estimados: 5 horas
Fecha de Inicio: 7/03/2017		Fecha de culminación. 7/03/2017
Programador Responsable: Cano Ramos Alfredo Erick y Sánchez Peña Axel
Descripción: Después de que el usuario haya comprado una tarjeta del metro se registrará la tarjeta y se validará para que pueda funcionar

Tarea de Ingeniería
Número Tarea: 3	Historia de Usuario (Nro. y Nombre): Venta de Tarjeta No.10
Nombre Tarea: Recarga de Tarjeta
Tipo de Tarea : Desarrollo		Puntos Estimados: 7
Fecha de Inicio: 08/03/2017		Fecha de culminación. 08/03/2017
Programador Responsable: Cano Ramos Alfredo Erick y Sánchez Peña Axel
Descripción: Posteriormente de que el usuario del metro haya comprado la tarjeta de metro y el cajero después de que la haya activado y entregado al usuario, el usuario podrá recargar la tarjeta para que cuente con el crédito necesario para poder usar el servicio del metro (Se debe contar con el saldo necesario para ir de la zona 1 a la zona 3 y viceversa).

Historia de Usuario
Número: 20.	Nombre: Entrada del metro
Modificación (o extensión) de Historia de Usuario (No. y Nombre):
Usuario: Usuario del metro		Iteración Asignada: 2
Prioridad  en Negocio: Alta		Puntos Estimados: 15 horas
Riesgo en Desarrollo: Baja		Puntos Reales:
Descripción: El usuario del metro tendrá acceso al servicio siempre y cuando tenga el saldo para cubrir la tarifa máxima.
Observaciones:

Caso de Prueba de Aceptación
Código:	Historia de Usuario (Nro. y Nombre): Entrada del metro No.20
Nombre: Checar monto
Descripción: Si el monto en la tarjeta es el necesario para pasar al metro.
Condiciones de Ejecución: El usuario previamente tuvo que haber comprado su tarjeta. El sistema tuvo que haber dado de alta el id del usuario.
Entrada / Pasos de ejecución: El usuario pasara la tarjeta por el lugar de cobranza con un monto por debajo de la tarifa estimada
Resultado Esperado: El sistema le pedirá al usuario que recargue su tarjeta en taquilla y vuelva cuando la tarjeta contenga más o igual monto del que se pide.
Evaluación de la Prueba:

Caso de Prueba de Aceptación
Código:	Historia de Usuario (Nro. y Nombre): Entrada del metro No.20
Nombre: Checar monto 2
Descripción: Si el monto en la tarjeta es el necesario para pasar al metro.
Condiciones de Ejecución: El usuario previamente tuvo que haber comprado su tarjeta. El sistema tuvo que haber dado de alta el id del usuario.
Entrada / Pasos de ejecución: El usuario pasara la tarjeta por el lugar de cobranza con un monto por encima de la tarifa estimada
Resultado Esperado: El sistema dejara entrar al usuario.
Evaluación de la Prueba:

Tarea de Ingeniería
Número Tarea: 1	Historia de Usuario (Nro. y Nombre): Entrada del metro No. 20
Nombre Tarea: Entrada
Tipo de Tarea : Desarrollo		Puntos Estimados: 15 horas
Fecha de Inicio: 09/03/2017		Fecha de culminación. 11/03/2017
Programador Responsable: Cano Ramos Alfredo Erick y Sánchez Peña Axel
Descripción: Teniendo ya validada la tarjeta en la previa venta y recarga el sistema reconocerá la tarjeta correspondiente al asignarle un id valido y tomando el monto solicitado del acumulado en la tarjeta. En el caso de que no tenga la cantidad requerida se le pedirá que vuelva a recargar en taquilla.

Historia de Usuario
Número: 10.	Nombre: Entrada del metro
Modificación (o extensión) de Historia de Usuario (No. y Nombre):
Usuario: Usuario del metro		Iteración Asignada: 2
Prioridad  en Negocio: Alta		Puntos Estimados: 15 horas
Riesgo en Desarrollo: Baja		Puntos Reales:
Descripción: El usuario del metro tendrá acceso al servicio siempre y cuando tenga el saldo para cubrir la tarifa máxima.
Observaciones:

Caso de Prueba de Aceptación
Código: Sección o parte del código  a probar	Historia de Usuario (Nro. y Nombre): Nombre de la historia de usuario a la cual se le aplicará el correspondiente caso de prueba
Nombre: Nombre que recibe el caso de prueba
Descripción: Se describe que es lo que el cliente pretende probar
Condiciones de Ejecución: Se describe las condiciones bajo las cuales se debe probar el caso de prueba por ejemplo. El usuario debe haber iniciado sesión El sistema tiene que estar conectado a internet
Entrada / Pasos de ejecución: Se describen los pasos necesarios para llevar a cabo el caso de prueba, o los diferentes datos que se quieren capturar para saber la respuesta que tendrá el sistema.
Resultado Esperado: Se anotan los resultados esperados que se cree arrojará el sistema.
Evaluación de la Prueba: Se hace una comparación de los resultados obtenidos con los esperados y se toman las decisiones pertinentes

Tarea de Ingeniería
Número Tarea: 1	Historia de Usuario (Nro. y Nombre): Entrada del metro No. 10
Nombre Tarea: Entrada
Tipo de Tarea : Desarrollo		Puntos Estimados: 15 horas
Fecha de Inicio: 09/03/2017		Fecha de culminación. 11/03/2017
Programador Responsable: Cano Ramos Alfredo Erick y Sánchez Peña Axel
Descripción: Teniendo ya validada la tarjeta en la previa venta y recarga el sistema reconocerá la tarjeta correspondiente al asignarle un id valido y tomando el monto solicitado del acumulado en la tarjeta. En el caso de que no tenga la cantidad requerida se le pedirá que vuelva a recargar en taquilla.