Gestión de proyectos
informáticos
Nombre: Sergio Aravena.
Docente: Pilar Pardo
Fecha: 20-11-2016
¿Qué entendemos por caso de uso?
• Se describe como interactúa el usuario con el sistema.
• Solo describe que hace el sistema pero no especifica como lo hace.
• El caso de uso tiene las siguientes relaciones:
Comunicación Extend Include Herencia Actor Límite del
sistema
Representa la
relación entre
un caso de uso
y un actor.
Al contrario
del include
el extend es
la parte
opcional del
sistema.
El segundo es
parte esencial
del primero
sin el
segundo el
primero no
podría
funcionar.
El caso hijo
hereda el
comportamiento
y significado de
caso de uso
padre.
Puede ser tanto
entre actores
como dentro del
sistema.
Representa
quien o que
inicia una
acción
dentro del
sistema
Sirve para
delimitar los
límites del
sistema.
Relaciones del caso de uso
Actor
Comunicación
Caso de
uso
Caso de
uso
Include
Caso de
uso
Extend
Herencia
Límite del sistema
Ejemplo de Comunicación
Crítico
de
comida
Probar la
comida
Chef
Preparar
la
comida
Ejemplo de extend e include
Realiza
r venta
Vendedor
Cobrar
venta
Cancelar
venta
Cobrar
al
contado
Cobrar a
crédito
Include
Include
Include
Extend
Acumula
r puntos
Extend
Ejemplo herencia entre actores
Usuario
Profesor Estudiante
Consultar
material
de estudio
Secretaria
Consultar
lecciones
Extend
Ejemplo herencia entre casos de
usos
Asistente
Registrar
Vehículo
Registrar
Motos
Registrar
Autos
Registrar
Camiones
CRUD
• Es el acrónimo de crear, leer, actualizar y borrar, que se refieren a las
funciones básicas en base de datos o la capa de persistencia en un
software.
Historias de usuarios
• Historia de usuario se usa para potenciar la participación del equipo en la
toma de decisiones, apoya la cooperación, colaboración y conversación de
los miembros del equipo
• Las historias de usuarios son creadas durante la conversación con los
usuarios interesados, sobre las funcionalidades o mejoras del proyecto.
Componentes de una historia de usuario
• Ficha: Descripción escrita que sirve como identificación y recordatorio del
requerimiento y ayuda para la planificación mediante la priorización.
• Conversación: Esto ocurre entre los miembros del equipo y el Product Owner para
aclarar detalles y dudas sobre la historia de usuario (es la parte mas importante).
• Confirmación: Debe estar muy bien explicada para que el equipo de desarrollo sepa
qué es lo que se debe construir y que es lo que el Product Owner espera.
• Cada historia debe ser independiente de otras
• La ficha de la historia es sólo una descripción corta sin detallar.
• Cada historia debe tener valor para el cliente.
• El equipo debe poder estimar una historia.
• Debe ser pequeña, realizarla en menos de una semana.
• Una historia debe probarse y saber que la historia se ha completado
correctamente.
Producto Backlog
• Es un listado de ítems o
características del producto a
construir, priorizado por el
Product Owner.
• Aunque el equipo puede dar
sugerencias, es el product
owner quien tiene la última
palabra sobre la prioridad final
de los ítems del backlog.
Historias de usuario
• Toda historia de usuario
debe tener una
conversación con el
Product Owner para
intercambiar información
u opiniones.
Diferencias
Ejemplo historia de usuario
Reporte de desempeño de ventas
Prioridad Como Necesito Para Criterio de
aceptación
1 Vicepresidente de
mercado y venta
Revisar el
desempeño
histórico de las
ventas.
Poder identificar
las regiones
geográficas y
productos de
mejor desempeño.
Dividir por
regiones el
desempeño.

Caso de uso e historia de usuario

  • 1.
    Gestión de proyectos informáticos Nombre:Sergio Aravena. Docente: Pilar Pardo Fecha: 20-11-2016
  • 2.
    ¿Qué entendemos porcaso de uso? • Se describe como interactúa el usuario con el sistema. • Solo describe que hace el sistema pero no especifica como lo hace. • El caso de uso tiene las siguientes relaciones: Comunicación Extend Include Herencia Actor Límite del sistema Representa la relación entre un caso de uso y un actor. Al contrario del include el extend es la parte opcional del sistema. El segundo es parte esencial del primero sin el segundo el primero no podría funcionar. El caso hijo hereda el comportamiento y significado de caso de uso padre. Puede ser tanto entre actores como dentro del sistema. Representa quien o que inicia una acción dentro del sistema Sirve para delimitar los límites del sistema.
  • 3.
    Relaciones del casode uso Actor Comunicación Caso de uso Caso de uso Include Caso de uso Extend Herencia Límite del sistema
  • 4.
    Ejemplo de Comunicación Crítico de comida Probarla comida Chef Preparar la comida
  • 5.
    Ejemplo de extende include Realiza r venta Vendedor Cobrar venta Cancelar venta Cobrar al contado Cobrar a crédito Include Include Include Extend Acumula r puntos Extend
  • 6.
    Ejemplo herencia entreactores Usuario Profesor Estudiante Consultar material de estudio Secretaria Consultar lecciones Extend
  • 7.
    Ejemplo herencia entrecasos de usos Asistente Registrar Vehículo Registrar Motos Registrar Autos Registrar Camiones
  • 8.
    CRUD • Es elacrónimo de crear, leer, actualizar y borrar, que se refieren a las funciones básicas en base de datos o la capa de persistencia en un software.
  • 9.
    Historias de usuarios •Historia de usuario se usa para potenciar la participación del equipo en la toma de decisiones, apoya la cooperación, colaboración y conversación de los miembros del equipo • Las historias de usuarios son creadas durante la conversación con los usuarios interesados, sobre las funcionalidades o mejoras del proyecto.
  • 10.
    Componentes de unahistoria de usuario • Ficha: Descripción escrita que sirve como identificación y recordatorio del requerimiento y ayuda para la planificación mediante la priorización. • Conversación: Esto ocurre entre los miembros del equipo y el Product Owner para aclarar detalles y dudas sobre la historia de usuario (es la parte mas importante). • Confirmación: Debe estar muy bien explicada para que el equipo de desarrollo sepa qué es lo que se debe construir y que es lo que el Product Owner espera.
  • 11.
    • Cada historiadebe ser independiente de otras • La ficha de la historia es sólo una descripción corta sin detallar. • Cada historia debe tener valor para el cliente. • El equipo debe poder estimar una historia. • Debe ser pequeña, realizarla en menos de una semana. • Una historia debe probarse y saber que la historia se ha completado correctamente.
  • 12.
    Producto Backlog • Esun listado de ítems o características del producto a construir, priorizado por el Product Owner. • Aunque el equipo puede dar sugerencias, es el product owner quien tiene la última palabra sobre la prioridad final de los ítems del backlog. Historias de usuario • Toda historia de usuario debe tener una conversación con el Product Owner para intercambiar información u opiniones. Diferencias
  • 13.
    Ejemplo historia deusuario Reporte de desempeño de ventas Prioridad Como Necesito Para Criterio de aceptación 1 Vicepresidente de mercado y venta Revisar el desempeño histórico de las ventas. Poder identificar las regiones geográficas y productos de mejor desempeño. Dividir por regiones el desempeño.