PROCESO DE GESTIÓN DE FORMACIÓN PROFESIONAL INTEGRAL

FORMATO GUÍA DE APRENDIZAJE

IDENTIFICACIÓN DE LA GUIA DE APRENDIZAJE

 Denominación del Programa de Formación: ANÁLISIS Y DESARROLLO DE SOFTWARE

 Código del Programa de Formación: 228118
 Nombre del Proyecto (si es formación Titulada): Construcción de software integrador de
tecnologías orientadas a servicios
Fase del Proyecto (si es formación Titulada): Análisis
 Actividad de Proyecto:
o Validación a través de historias de usuario a través de listas de chequeo de todas las
tareas que necesitan ser realizadas para completar el proyecto formativo.
o Estimación y categorización a través de técnicas como MoSCoW (Must have, Should
have, Could have, Won't have) con el cliente
 Competencia: Establecer requisitos de la solución de software de acuerdo con estándares y
procedimiento técnico
 Resultados de Aprendizaje Alcanzar:
03. ESTABLECER LOS REQUISITOS DEL SOFTWARE DE ACUERDO CON LA
INFORMACIÓN RECOLECTADA.
04. VALIDAR EL INFORME DE REQUISITOS DE ACUERDO CON LAS NECESIDADES
DEL CLIENTE.
 Duración de la Guía: 4 clases (20 horas)

2. PRESENTACIÓN

En esta guía de aprendizaje, exploraremos la gestión de requerimientos de aplicaciones.

Aprenderemos los pasos esenciales para convertir una idea en una aplicación funcional,
desde la identificación de funcionalidades hasta la validación, Estimación y categorización
de las mismas.

GFPI-F-135 V02
Objetivo
 Motivar al trabajo autónomo y sistemático a través de tecnicas de
storytelling.

 Validar el informe de requisitos ya creado y realizar su estimación.

 Promover el aprendizaje colaborativo.
3. FORMULACIÓN DE LAS ACTIVIDADES DE APRENDIZAJE

Tema 1: Desarrollo del Backlog

El backlog es una lista dinámica de todas las tareas que necesitan ser realizadas para completar un
proyecto. Aquí te presento algunos pasos clave para desarrollar un backlog efectivo:
Identifica las funcionalidades: Comienza por identificar todas las funcionalidades que quieres que tenga tu
producto o aplicación. Hazlo de manera detallada y específica para esto vamos a ayudarnos de un
wireframe rápido que se dibujará a mano en papel y se hará lo más lugubre posible; eso si lúgubre es
diferente a feo y/o desorganizado pues todo tiene sentido. En la fase de diseño retomaremos aún más en
este producto.

Insertar Requerimientos en Jira: Guía Paso a Paso

1. Crear un Tipo de Incidencia para Requerimientos:

• Accede a Administración > Tipos de Incidencia.

• Haz clic en Crear Tipo de Incidencia.
• Ingresa un nombre, como "Requisito".
• Selecciona Scrum como flujo de trabajo.
• En Campos Personalizados, agrega campos relevantes, como:

GFPI-F-135 V02
 • Prioridad (elegir de una lista)
• Fecha Límite (fecha)
• Módulo Afectado (lista desplegable)
• Descripción (campo de texto)
• Haz clic en Crear.

Configura los módulos entre estos Estimación y Criterios de aceptación

GFPI-F-135 V02
2. Crear un Proyecto para tu Producto:
• Accede a Proyectos > Crear Proyecto.
• Ingresa un nombre para el proyecto, como "Nombre del Producto".
• Selecciona Scrum como metodología.
• Elige el tipo de incidencia "Requisito" creado anteriormente.
• Haz clic en Crear.

3. Agregar Requerimientos como Incidencias:

• Accede al proyecto creado.
• Haz clic en Crear Incidencia.
• Selecciona el tipo de incidencia "Requisito".
• Completa los campos:
• Resumen: Un resumen breve del requerimiento.
• Descripción: Detalle del requerimiento, incluyendo pasos a seguir, criterios de aceptación, etc.
• Prioridad: Selecciona la prioridad del requerimiento.
• Fecha Límite: Indica la fecha límite para completar el requerimiento.
• Módulo Afectado: Indica el módulo del software al que afecta el requerimiento.
• Otros campos personalizados: Completa según sea necesario.
• Adjunta archivos relevantes, como capturas de pantalla o documentos.
• Haz clic en Crear.

GFPI-F-135 V02
4. Gestionar los Requerimientos:
• Puedes ordenar, filtrar y buscar las incidencias de requisitos.
• Puedes asignar las incidencias a miembros del equipo.
• Puedes agregar comentarios y discutir los requisitos.
• Puedes cambiar el estado de las incidencias a medida que se avanza en su desarrollo.
• Puedes utilizar el panel de control para obtener una vista general del progreso de los requisitos.

GFPI-F-135 V02
Tema 2: Prioriza las funcionalidades con MoSCoW: Una vez que tienes una lista de funcionalidades, es
hora de priorizarlas. Puedes utilizar técnicas como MoSCoW (Must have, Should have, Could have, Won't
have) para ayudarte a clasificarlas por importancia.

Must have (Debe tener): Son los requisitos o funcionalidades críticas y fundamentales para el éxito
del proyecto. Estos elementos son imprescindibles y deben ser implementados en la primera
iteración del desarrollo.
Should have (Debería tener): Son los requisitos o funcionalidades importantes pero no críticas. Si es
posible, deben ser implementados después de los elementos "Must have", pero antes que los
"Could have". Estos elementos pueden esperar un poco, pero se consideran esenciales para el éxito
final del proyecto.
Could have (Podría tener): Son los requisitos o funcionalidades deseables pero no esenciales. Estos
elementos son opcionales y pueden ser considerados para futuras versiones del producto si el
tiempo y los recursos lo permiten.

GFPI-F-135 V02
 Won't have (No debería tener): Son los requisitos o funcionalidades que se han decidido
explícitamente no incluir en el proyecto actual. Estos elementos pueden ser considerados para
futuras versiones, pero no son prioritarios en el contexto actual del proyecto.

Todo el proceso se identificará en FIGMA y se entregará en pdf

Tema 3: Construye las historias de usuario a través del storytelling en las tareas del backlog

Ya contamos con el listado de requerimientos ahora vamos a definir las historias de usuario para validar
internamente cada una de ellas, este insumo nos servirá para exponer todo nuestro trabajo directamente al
Interesado

Como [tipo de usuario], quiero [funcionalidad], para

[razón o beneficio].
las historias de usuario son descripciones cortas y simples de una funcionalidad o característica del sistema
desde la perspectiva del usuario. Estas historias se utilizan para capturar los requisitos del cliente y ayudar
al equipo de desarrollo a comprender qué debe hacer el sistema para satisfacer las necesidades del usuario
final.

Cada historia de usuario suele seguir un formato simple, como el siguiente:

Como usuario registrado, quiero poder iniciar sesión con

mi correo electrónico y contraseña, para acceder a mi
perfil y ver mis publicaciones.

Enfoquemoslo a una aplicación real

GFPI-F-135 V02
Historia de Usuario 1: Como usuario nuevo, quiero poder
registrarme en TaskMaster para comenzar a gestionar mis
tareas.
Y como uso el Storytelling adicional para tareas importante, técnica de contar historias, puede ser una
herramienta poderosa no solo para crear historias de usuario, sino también para comunicar la importancia
y el impacto de ciertas tareas dentro del desarrollo de software. Aquí te presento cómo podrías aplicar el
storytelling para destacar tareas importantes:

Las tareas más importantes, que requieren de varios criterios de aceptación contarán con un escenario
especifico así:

Escenario:
María es una usuaria activa de nuestra red social. Ella quiere compartir una foto
de sus vacaciones recientes con sus amigos y seguidores. María inicia sesión en
la aplicación y accede a su perfil. Luego, hace clic en el botón "Publicar" y
selecciona la opción de "Subir Foto". Después de seleccionar la foto de sus
vacaciones en la galería de su teléfono, María escribe un breve título y una
descripción para acompañar la foto. Finalmente, hace clic en el botón "Publicar"
para compartir la foto con sus amigos y seguidores

Escenario 2:
En un soleado día de verano, María, una estudiante universitaria, escucha sobre
una nueva aplicación llamada TaskMaster que puede ayudarla a organizar sus
tareas académicas. Emocionada por la perspectiva de una mayor productividad,
María busca la aplicación en la tienda de aplicaciones de su teléfono. Al
encontrarla, se le presenta la opción de registrarse como nuevo usuario. María
completa el proceso de registro con facilidad, proporcionando su nombre,

GFPI-F-135 V02
dirección de correo electrónico y una contraseña segura. Una vez registrado,
María está lista para comenzar a utilizar TaskMaster y mejorar su gestión del
tiempo.

Tema 4: Criterios de aceptación:

Los criterios de aceptación son condiciones específicas y objetivas que deben cumplirse para considerar
una tarea o una historia de usuario como completada satisfactoriamente. Estos criterios definen las
expectativas y los estándares que deben alcanzarse para que el trabajo realizado sea considerado exitoso y
aceptable. Aquí te presento una definición más detallada y algunos ejemplos de criterios de aceptación:

Criterios de Aceptación:

1. ☑ El usuario debe poder iniciar sesión en la aplicación.

2. ☒ El usuario debe poder acceder a su perfil.
3. ☒ El usuario debe poder seleccionar la opción de "Publicar".
4. ☑ El usuario debe poder seleccionar la opción de "Subir Foto" para adjuntar una imagen.
5. ☑ El usuario debe poder escribir un título y una descripción para la publicación.
6. ☑ El usuario debe poder publicar la foto para compartirla con sus amigos y seguidores.

Luego de ello estimaremos su desarrollo

Estima el esfuerzo requerido: Asigna una estimación de esfuerzo a cada tarea. Puedes utilizar
unidades de medida como puntos de historia o horas de trabajo, según lo que funcione mejor para
tu equipo.
Mantén el backlog actualizado: El backlog es una herramienta viva que evoluciona a lo largo del
proyecto. Asegúrate de revisarlo y actualizarlo regularmente para reflejar los cambios en los
requerimientos del cliente o las prioridades del equipo.
Desglosa las funcionalidades en tareas: Cada funcionalidad puede dividirse en tareas más pequeñas y
manejables. Esto te ayudará a estimar el tiempo y los recursos necesarios para completar cada una.
Puedes crear estas cards por cada persona de tu equipo de trabajo y estima las respectivas tareas
asignando un punto de historia a través del planning poker así

GFPI-F-135 V02
 Planning POCKET:

Por favor, ingrese su estimación para cada tarea utilizando cartas de

Planning Poker: Tarea DA1: [ 3 ] Tarea DA2: [ 5 ] Tarea DA3: [ ] Tarea DA4: [
] Tarea DA5: [ ]

Tarea DA1: El sistema debe permitir a los usuarios iniciar sesión utilizando su dirección de correo
electrónico y contraseña. PUNTOS 3.

Verificación: Los usuarios pueden ingresar su dirección de correo electrónico y contraseña en los campos
correspondientes y acceder con éxito al sistema.

Tarea DE2: La función de búsqueda debe devolver resultados relevantes basados en la ubicación del
usuario y sus preferencias de comida. PUNTOS 5.
Verificación: Al realizar una búsqueda en la aplicación, los resultados mostrados deben estar geográficamente
cercanos al usuario y deben incluir opciones que se ajusten a sus preferencias de comida.

4. ACTIVIDADES DE EVALUACIÓN
Evidencias de Aprendizaje
Desarrollo del Backlog
Criterios de Evaluación Técnicas e Instrumentos
de Evaluación
- El estudiante puede identificar y describir - Revisión del backlog
las funcionalidades necesarias para el desarrollado por el
producto. estudiante.

GFPI-F-135 V02
 - El estudiante puede priorizar las
funcionalidades de acuerdo a su - Listado de requerimientos
importancia. minimo 50 RF y 20 RNF

- El estudiante comprende los principios

Prioriza las funcionalidades con
MoSCoW
detrás del método MoSCoW.
- El estudiante puede aplicar el método
MoSCoW para priorizar funcionalidades.
- Ejercicios prácticos donde
el estudiante debe priorizar
funcionalidades utilizando
MoSCoW.

- El estudiante puede crear historias de - Revisión de las historias de

Construye historias de usuario
Criterios de Aceptación
usuario creadas por el
usuario claras y concisas.
estudiante.
- El estudiante utiliza el storytelling para - Presentaciones donde el
comunicar eficazmente las historias de estudiante explica las
usuario creando distintos escenarios. historias de usuario
utilizando storytelling.
- Discusión grupal sobre la
- El estudiante comprende la importancia de importancia y aplicación de
los criterios de aceptación en el desarrollo los criterios de aceptación.
de software. <br> - El estudiante puede - Ejercicios prácticos donde
definir criterios de aceptación claros y el estudiante debe definir
medibles para las historias de usuario. criterios de aceptación para
diferentes historias de
usuario.

5. GLOSARIO DE TÉRMINOS

Backlog: Definición: En el desarrollo de software, un backlog es una lista dinámica de todas las tareas,
funcionalidades, mejoras y correcciones que deben realizarse para completar un proyecto. Estas tareas se
organizan en orden de prioridad y se utilizan como referencia durante el proceso de planificación y
desarrollo del proyecto.

MoSCoW: es una técnica de priorización utilizada en el desarrollo de software para clasificar los requisitos
o funcionalidades en cuatro categorías: Must have (debe tener), Should have (debería tener), Could have
(podría tener) y Won't have (no debería tener). Esta técnica ayuda a establecer claridad sobre qué
funcionalidades son críticas para el éxito del proyecto y cuáles pueden ser pospuestas o excluidas.

GFPI-F-135 V02
Historia de Usuario: En el desarrollo ágil de software, una historia de usuario es una descripción breve y
específica de una funcionalidad o característica del sistema desde la perspectiva del usuario final. Estas
historias se utilizan para capturar los requisitos del cliente y ayudar al equipo de desarrollo a comprender
qué debe hacer el sistema para satisfacer las necesidades del usuario.

Criterios de Aceptación: Los criterios de aceptación son condiciones específicas y objetivas que deben
cumplirse para considerar una tarea o una historia de usuario como completada satisfactoriamente. Estos
criterios definen las expectativas y los estándares que deben alcanzarse para que el trabajo realizado sea
considerado exitoso y aceptable.

6. REFERENTES BIBLIOGRÁFICOS

Construya o cite documentos de apoyo para el desarrollo de la guía, según lo establecido en la guía de
desarrollo curricular

7. CONTROL DEL DOCUMENTO

Nombre Cargo Dependencia Fecha

Autor (es) Darwin Yusef Gonzalez Instructor CDMC 11/03/2024

Triana

8. CONTROL DE CAMBIOS (diligenciar únicamente si realiza ajustes a la guía)

Nombre Cargo Dependencia Fecha Razón del Cambio

Autor (es)

GFPI-F-135 V02