INGENIERÍA DE SISTEMAS DE SOFTWARE

CURSO: SI385 IHC y Tecnologias Móviles

ENUNCIADO DEL TRABAJO FINAL

PROFESORES: Campos Benites, Silvia Adelma

Flores Moroco, Juan Antonio
Quispe Vilchez, Eder Ramiro
Velásquez Núñez, Ángel Augusto (Coordinador)
SECCIONES: SI41, SI42, SI43, SS4A, SV41, SX41, SX42, SX43, ZS4A
FECHA DE EVALUACIÓN: Semana 15
CICLO ACADEMICO: 2021-02

Objetivo:
El presente documento define el trabajo final y la rúbrica que permite evaluar el
logro del curso SI385 IHC y Tecnologías Móviles.

Logro del curso:

Al finalizar el curso, el estudiante diseña una propuesta innovadora de UX en base a
la identificación de necesidades y oportunidades, incluyendo la selección de las
interfaces y esquemas de interacción adecuados, considerando factores relevantes
para el público objetivo.

En Ingeniería de Software, el logro contribuye a alcanzar el:

ABET – EAC - Student Outcome 2: La capacidad de aplicar el diseño de ingeniería

para producir soluciones que satisfagan necesidades específicas con consideración
de salud pública, seguridad y bienestar, así como factores globales, culturales,
sociales, ambientales y económicos.

Enunciado
El curso de IHC Y Tecnologías móviles tiene una naturaleza teórico práctica, por lo
que es necesario evidenciar la capacidad para elaborar propuestas de UX aplicando
los conceptos, técnicas y buenas prácticas impartidos en el curso.
Este trabajo tiene por objetivo elaborar una propuesta de UX para un producto de
software que brinde soporte para un modelo de negocio, consistente en una
experiencia web y aplicación móvil para iOS y Android orientada a satisfacer

1/30
necesidades identificadas para un público objetivo, junto con un landing page,
haciendo uso de las herramientas y tecnología utilizadas en el curso, aplicando
conceptos y técnicas revisados en clase ó resultado de la investigación.

Exposición
La exposición forma parte de la nota. Si al momento de la exposición el profesor
determina que el alumno no ha hecho parte o la totalidad del trabajo debido a que el
alumno no supo responder correctamente a las preguntas realizadas el profesor
podrá considerar descontar puntos en funcionalidades ya implementadas del
trabajo. La frase “En esa parte me ayudaron” no será considerada como válida por lo
que el alumno deberá realizar el trabajo de forma total.

Instrucciones para la entrega del trabajo

Archivos
El Team Leader subirá los archivos en la actividad indicada por el docente, los
siguientes archivos: documento de Informe del Proyecto (en versión de Microsoft
Word y .PDF), documento de presentación (en versión PowerPoint y .PDF), Reporte
de participación (en Microsoft Word y .PDF), archivo .zip con artefactos y proyectos
de software (si fuera aplicable), video de exposición (como URL privado publicado en
YoutTube y como archivo en formato .mp4).
Videos de exposición
Todo video de exposición debe mostrar a cada uno de los integrantes ante cámara
explicando la construcción de los artefactos del trabajo, centrándose en mostrar los
artefactos según la rubrica correspondiente al hito, apoyándose en una presentación
de PowerPoint y demostrando los artefactos en las herramientas indicadas. La
duración máxima del video es de 30 minutos.
Horarios de entrega
Para TB1, TB2, TB3 y TB4, la entrega se realiza hasta 24 horas después del horario
programado regular de la sesión síncrona de la semana (en caso de dos sesiones
síncronas semanales, se considera la segunda sesión síncrona).
Para TP1 y TF1, la entrega se realiza 24 horas antes de la hora programada de la
sesión síncrona (en caso de dos sesiones síncronas semanales, es antes de la
segunda sesión síncrona).
Nomenclatura de Archivos
Documento de Informe de Proyecto: Seguir la estructura de nombre upc-pre-
202102-si385-<sección>-<startup>-report-<tbn/tp1/tf1> (.docx y .pdf)
Presentación de Proyecto: Seguir la estructura de nombre upc-pre-202102-<startup>-
si385-<sección>-keynote-<tbn/tp1/tf1> (.pptx y .pdf)
Documento de Informe de Participación: Seguir la estructura de nombre upc-pre-
202102-si385-<sección>-<startup>-performance-<tbn/tp1/tf1> (.docx y .pdf)
Video de exposición: Seguir la estructura de nombre upc-pre-202102-si385-
<sección>-<startup>-expo-<tbn/tp1/tf1> (.mp4)
Recomendaciones generales
Revisar con detenimiento los documentos Final Project Statement (este documento),
así como las rúbricas.

2/30 V1.0
Exposición
Para cada entrega, el equipo grabará en video su exposición con anticipación. El
video contará de una edición que muestre la presentación de PowerPoint junto con
la muestra en pantalla de artefactos como diagramas u otros que lo requieran,
sincronizado con la explicación ante cámara de los participantes. En la primera parte
de la exposición, debe incluirse tomas de cada participante hablando a la cámara y
presentándose. Debe editarse para que sólo sea un video cuidando que el contenido
no exceda el límite impuesto por YouTube.
El enlace privado del video debe incluirse en el Document Report, dentro de un
anexo titulado (Videos de Exposiciones) y especificando la entrega a la que
corresponde la Exposición. Debe entregarse además el archivo de video (ver anexos).
Sustentación síncrona
Para TP1 y TF1, la sesión de clase en la que esté programada la entrega se enfocará
en la sustentación de los proyectos. Cada equipo iniciará con una exposición con una
duración máxima de 12 minutos. Luego se realizará la sustentación con preguntas a
los participantes de forma indistinta, sobre diversos aspectos del proyecto
previamente entregado y expuesto (vía video pre-grabado).
Participant Performance Report
El Participant Performance Report es un documento en Word que elabora el Team
Leader, en el cual explica y califica el desempeño de cada uno de los miembros de su
equipo (ver anexos). En este Documento el coordinador resume la participación de
cada integrante y la asigna a cada uno una calificación entre 0 y 20. Cada entrega
debe incluir un Participant Performance Report sobre el desempeño de cada
participante en relación a dicha entrega.
Final Project Keynote
Cada entrega incluye una presentación de PowerPoint cuyo contenido se relaciona
con el ciclo de vida del proyecto, priorizando contenido relacionado con la entrega
en cuestión. Entre las diapositivas deben incluir una de presentación del equipo con
las fotos de los miembros de la startup, identificados por nombre, apellido y carrera.
Final Project Document Report
Tener cuidado con el respeto del Template y uso de los fonts institucionales que
aplica la plantilla del documento en Word.
User Stories, Product Backlog, Sprint Backlogs
De incluirse en la entrega artefactos con texto como los User Stories con Acceptance
Criteria y Work-items, deben estar redactados en el Document Report, no como
captura de imágenes de herramientas, como por ejemplo los Product Backlog en
PivotalTracker y los Task boards en Trello.
Artefactos de UX (Cuando corresponda)
Cuando corresponda, cada equipo tendrá creado un proyecto en UXPressia, en el
cual deben elaborar los artefactos de UX soportados por la herramienta. Capturas en
imagen de estos artefactos deben incluirse en el Document Report en las secciones
adecuadas y con las explicaciones y análisis que correspondan. Del mismo modo, los
diagramas en herramientas indicadas como LucidChart o Figma /Adobe XD, deben
incluirse como imágenes en el documento junto con su explicación, además de ser
mostradas y explicadas en el video de exposición.

3/30
Estructura del Informe

Informe de Proyecto del Curso

Documento en Microsoft Word según template. Respetar la estructura de contenido
indicada a continuación.

Carátula
Universidad, carrera, ciclo
Nombre del curso
Sección
Nombre del profesor
"Informe de Trabajo Final"
Nombre del startup
Nombre del producto
Relación de integrantes
Mes y año

Registro de Versiones del Informe

Contenido
Tabla de contenidos

Student Outcome

Capítulo I: Introducción
1.1. Startup Profile
1.1.1. Descripción de la Startup
1.1.2. Perfiles de integrantes del equipo
1.2. Solution Profile
1.2.1 Antecedentes y problemática
1.2.2 Lean UX Process.
1.2.2.1. Lean UX Problem Statements.
1.2.2.2. Lean UX Assumptions.
1.2.2.3. Lean UX Hypothesis Statements.
1.2.2.4. Lean UX Canvas.
1.3. Segmentos objetivo.

Capítulo II: Requirements Elicitation & Analysis

2.1. Competidores.
2.1.1. Análisis competitivo.
2.1.2. Estrategias y tácticas frente a competidores.
2.2. Entrevistas.
2.2.1. Diseño de entrevistas.
2.2.2. Registro de entrevistas.
2.2.3. Análisis de entrevistas.
2.3. Needfinding.

4/30 V1.0
2.3.1. User Personas.
2.3.2. User Task Matrix.
2.3.3. User Journey Mapping.
2.3.4. Empathy Mapping.
2.3.5. As-is Scenario Mapping.

Capítulo III: Requirements Specification

3.1. To-Be Scenario Mapping.
3.2. User Stories.
3.3. Impact Mapping.
3.4. Product Backlog.

Capítulo IV: Product UX/UI Design

4.1. Style Guidelines.
4.1.1. General Style Guidelines.
4.1.2. Web Style Guidelines.
4.1.3. Mobile Style Guidelines.
4.1.3.1. iOS Mobile Style Guidelines.
4.1.3.2. Android Mobile Style Guidelines.
4.2. Information Architecture.
4.2.1. Organization Systems.
4.2.2. Labeling Systems.
4.2.3. Searching Systems.
4.2.3. Navigation Systems.
4.3. Landing Page UI Design.
4.3.1. Landing Page Wireframe.
4.3.2. Landing Page Mock-up.
4.4. Mobile Applications UI Design.
4.4.1. Mobile Applications Wireframes.
4.4.2. Mobile Applications Wireflow Diagrams.
4.4.2. Mobile Applications Mock-ups.
4.4.3. Mobile Applications User Flow Diagrams.
4.5. Mobile Applications Prototyping.
4.5.1. Android Mobile Applications Prototyping.
4.5.2. iOS Mobile Applications Prototyping.

Capítulo V: Product Implementation

5.1. Software Configuration Management.
5.1.1. Software Development Environment Configuration.
5.1.2. Source Code Management.
5.1.3. Source Code Style Guide & Conventions.
5.1.4. Software Deployment Configuration.
5.2. Product Implementation & Deployment.
5.2.X. Sprint n
5.2.X.1. Sprint Backlog n.
5.2.X.2. User Interface & Execution.
5.2.X.3. Team Collaboration Insights.

5/30
5.3. Video About-the-Product.

Capítulo VI: Product Validation

6.1. Acceptance Tests
6.2. Entrevistas de validación.
6.2.1. Diseño de Entrevistas.
6.2.2. Registro de Entrevistas.
6.2.3. Evaluaciones según heurísticas.
6.3. Auditoría de Experiencias de Usuario
6.3.1. Auditoría realizada.
6.3.1.1. Información del grupo auditado.
6.3.1.2. Cronograma de auditoría realizada.
6.3.1.3. Contenido de auditoría realizada.
6.3.2. Auditoría recibida.
6.3.2.1. Información del grupo auditor.
6.3.2.2. Cronograma de auditoría recibida.
6.3.2.3. Contenido de auditoría recibida.
6.3.2.4. Resumen de modificaciones para subsanar hallazgos.

Conclusiones
Conclusiones y recomendaciones
Video About-The-Team

Bibliografía

Anexos

Consideraciones sobre los componentes

Registro de Versiones del Informe

El objetivo de esta sección es resumir las modificaciones relevantes que se realizan al
informe durante el ciclo de vida del proyecto.
Esta sección inicia en una página nueva y se incluye un cuadro con la siguiente
estructura:

Versión Fecha Autor Descripción de modificación

Como primera línea de la tabla se incluye la primera versión del informe. A partir de
ello, se considera modificaciones relevantes la adición de secciones, eliminación de
secciones, correcciones o mejoras producto de retroalimentación recibida del
docente o producto de la autocrítica del equipo.

Contenido
La sección inicia en una nueva página. Para esta sección utilice el generador de tablas
de contenido de Microsoft Word. Considere en la generación 4 niveles de esquema.
Recuerde actualizar y verificar la tabla de contenidos antes de cada entrega.

6/30 V1.0
Student Outcome
Cada participante del equipo debe colaborar a fin de que se redacte como grupo los
sustentos y evidencias de las actividades realizadas en el trabajo final han ayudado a
desarrollar cómo las dimensiones del student outcome. Por ello en esta sección debe
quedar descrito por escrito, la relación entre el outcome, sus dimensiones y el
trabajo que han realizado. Esto se complementa con lo reflejado en los testimonios
expuestos que forman parte del video About The Team.
A manera de referencia se incluye los aspectos específicos que corresponden al
Student Outcome del curso.

Diseña productos o componentes en ingeniería de software que satisfacen necesidades específicas

considerando el impacto en salud pública, seguridad, bienestar, así como factores globales,
culturales, sociales, ambientales y económicos
Diseña componentes al nivel detallado, sin embargo, la aplicación de estándares no es sistemática en
el diseño. Diseña algunos aspectos de la arquitectura no cubriendo todos los atributos de calidad.
Utiliza parcialmente metodologías de acuerdo con las características propias de la solución.
Diseña proyectos que permiten la implementación de soluciones en ingeniería de software
considerando el impacto en salud pública, seguridad, bienestar, así como factores globales,
culturales, sociales, ambientales y económicos
Diseña parcialmente un proyecto de desarrollo de soluciones en ingeniería de acuerdo con las
restricciones establecidas. Sustenta con dificultad el diseño de un proyecto de desarrollo de soluciones
en ingeniería cumpliendo estándares y buenas prácticas.
Diseña y ejecuta los procesos relacionados al desarrollo y mantenimiento de la solución de software
en ingeniería considerando el impacto en salud pública, seguridad, bienestar, así como factores
globales, culturales, sociales, ambientales y económicos
Selecciona y/o adapta procesos para el desarrollo del producto de software, asegurando que la
metodología sea la apropiada, pero no establece con claridad las variaciones que se requieren de
acuerdo con las condiciones del proyecto. Adopta correctamente solo algunos procesos de acuerdo
con los requisitos y características propias del proyecto.

La sección inicia en una nueva página. Debe incluir el cuadro de Student Outcome tal
como se indica en la sección de Anexos de este documento. En las celdas Acciones
realizadas, debe especificarse cada participante: Nombres y Apellidos, a
continuación, cada entrega (TB1, TB2, etc.) con las acciones específicas realizadas
que se relacionen con el criterio del Outcome al que corresponda la celda. Esta celda
se irá expandiendo en cada entrega. Las celdas Conclusiones se llenan de forma
grupal y son acumulables, es decir se van expandiendo en cada entrega.

Startup Profile
Incluye la descripción de startup1, perfiles de los miembros del equipo, incluyendo
foto de participante, nombres y apellidos, código de estudiante y descripción de
carrera, junto con párrafo de resumen indicando principales conocimientos técnicos
y habilidades que puede aportar en el equipo.

Solution Profile
Esta sección incluye dos secciones internas. La primera parte, Antecedentes y
Problemática, consta del enunciado de problema, y una descripción de los puntos

1
Una startup es una pequeña empresa de reciente creación, con alto potencial innovador y tecnológico, donde su modelo es
escalable y su crecimiento puede ser exponencial. En su traducción del inglés, el término start-up significa “puesta en marcha”.
Y, efectivamente, podemos definirlo como el periodo inicial de una empresa, el comienzo o arranque de un nuevo negocio.

7/30
más importante que debe resolver la solución propuesta, así como objetivos y
restricciones que delimiten el alcance del proyecto. La segunda parte, Lean UX
Process, es resultado de la ejecución del Lean UX Process sobre el dominio del
problema.
Antecedentes y Problemática
Aquí se incluye una aproximación preliminar a la descripción de los antecedentes y la
descripción de la problemática. Para la elaboración de esta descripción, el equipo
debe aplicar previamente la técnica de The 5 ‘W’s y 2 ‘H’s - Who, What, Where,
When, Why, How & How Much.
Lean UX Process
Aquí se aplica Lean UX Process y abarca la visión del modelo de negocio que será
soportado por el producto de software, incluyendo Problem Statements (incluyendo
aspectos como domain, customer segments, pain points, gap, visión/strategy, e
initial segment), Assumptions e Hypothesis Statements según Lean UX Process.
Finalizando esta sección se incluye el Lean UX Canvas.

Segmentos objetivo
Esta sección incluye la descripción de los segmentos asociados al dominio del
problema, incluyendo características demográficas e información estadística de
sustento.

Requirements Elicitation & Analysis

Se incluye el proceso de Needfinding junto con análisis de la competencia. Las
entrevistas se registrarán en video y se editarán para construir el video de evidencia
de entrevistas. El análisis de dichas entrevistas servirá de base para la identificación
de necesidades y la construcción de los User Persona para cada segmento objetivo,
así como la construcción del User Task Matrix, los User Journey Map para los User
Persona identificados, así como los Empathy Maps y los As-is Scenario Maps.

Competidores
En esta sección se realiza la identificación y descripción de los principales
competidores directos (3 como mínimo) con modelos de negocio basados en
productos digitales similares, o en su defecto competidores indirectos con ofertas
parcialmente similares.
Análisis competitivo
En esta sección tiene como objetivo que su startup conozca mejor a sus
competidores, en contraste con la idea inicial que pudiera tener sobre ellos.
Se debe desarrollar el siguiente Landscape:

Competitive Analysis Landscape

¿Por qué llevar a Escriba en el recuadro la pregunta que busca responder o el objetivo de este
cabo este análisis? análisis.

(En la cabecera colocar por Su startup Competidor 1 Competidor 2 Competidor 3

cada competidor nombre y
logo)
Overview
P
e
r
f
i
l

8/30 V1.0
 Ventaja
competitiva
¿Qué valor ofrece
a los clientes?
Mercado objetivo
Perfil de Marketing

Estrategias de
marketing

Productos &
Servicios
Perfil de Producto

Precios & Costos

Canales de
distribución (Web
y/o Móvil)

Realice esto para su startup y sus competidores. Sus fortalezas deberían apoyar sus
oportunidades y contribuir a lo que ustedes definen como su posible ventaja
competitiva.
Fortalezas
Análisis SWOT

Debilidades

Oportunidades

Amenazas

Para cada uno de ellos debe identificarse fortalezas y debilidades, así como las
oportunidades y amenazas asociadas.
Estrategias y tácticas frente a competidores.
Se debe incluir las estrategias y tácticas preliminares que aplicará su startup para
afrontar las fortalezas y aprovechar las debilidades, así como el contexto de
oportunidades y amenazas en relación a la competencia.

Entrevistas
En esta sección se aborda la investigación tomando como base la recolección de
información en base a entrevistas a representantes de los segmentos objetivo.

9/30
Diseño de entrevistas
Esta sección incluye la relación de preguntas principales y complementarias para
entrevistas, dirigidas a cada uno de los segmentos. Es importante considerar que
debe aplicarse buenas prácticas para diseño de entrevistas. También debe
considerar qué tipo de información principal y complementaria necesita recolectar
para construir los arquetipos (características demográficas como género, edad,
distrito de residencia, estado civil, familia, ocupación, al igual que otras
características como personalidad, habilidades, marcas e influencias, dispositivos de
preferencia, canales digitales de interacción, objetivos, frustraciones, biografía o
background).
Registro de entrevistas
Para cada segmento se requiere de 3 a 5 entrevistas. Para cada una de las entrevistas
se debe indicar la información de nombres, apellidos, edad, distrito, un screenshot
de un cuadro de video y el URL del video subido en YouTube incluyendo el timing
donde inicia la entrevista y su duración. La entrevista debe ser registrada en video,
que sirve de evidencia de entrevistas. Para cada entrevista debe redactarse en este
informe un resumen, que explique de forma descriptiva las principales respuestas
del entrevistado a las preguntas realizadas.
Análisis de entrevistas
En esta sección se debe realizar un análisis por cada segmento objetivo,
identificando con sustento estadístico (porcentajes) las características objetivas y
subjetivas que representan los aspectos más comunes de cada segmento y que son
necesarios para la construcción de los arquetipos. La fuente de información para
este análisis proviene de las entrevistas registradas. Debe evidenciarse que cada
característica tiene relación con las entrevistas registradas y los resúmenes
realizados para las mismas.

Needfinding.
En esta sección el equipo explica y presenta los artefactos resultantes del proceso de
análisis de la información recolectada. Aquí se incluye secciones internas para User
Personas, User Task Matrix, User Journey Maps, Empathy Mapping y As-Is Scenario
Mapping.
User Personas
En esta sección se incluye la elaboración de las fichas de User Persona. La sección
inicia con una introducción explicando la relación entre los artefactos a presentar y
las principales características que se están tomando en cuenta del análisis de
entrevistas y de la competencia. Se elabora una ficha de User Persona por cada
segmento objetivo. Considere las mejores prácticas y todos los ítems necesarios para
especificar un arquetipo. Utilice la herramienta indicada para este tipo de artefacto.
User Task Matrix
En esta sección se presenta el User Task Matrix, que concentra las tareas que los
User Persona (que representan a cada segmento) realizan para cumplir sus objetivos.
No confundir tareas (tasks) con opciones o características de software, pues las
tareas deben ser realizadas por los segmentos independientemente de la existencia
de su solución de software. Esta sección inicia con una introducción donde se
establece los segmentos que se están considerando. El cuadro debe incluir como
columna cada User Persona y para cada una como sub-columnas, la Frecuencia y la

10/30 V1.0
Importancia de cada tarea (task). Como filas se colocan las tareas identificadas.
Luego del cuadro se realiza una explicación resaltando las tareas con mayor
frecuencia e importancia, principales diferencias y coincidencias entre lo realizado
por los User Personas.
User Journey Mapping
En esta sección se elabora los User Journey Maps (uno por cada User Persona). La
sección inicia con una introducción que resume el end-to-end journey que se
pretende ilustrar. Debe incluirse capturas de imagen de los diagramas elaborados en
la herramienta indicada. En este caso se elabora las versiones As-Is de los User
Journey Maps, es decir los journey de cada segmento representado para la situación
actual, sin que exista su solución. Cada User Journey Map debe vincularse con el
User Persona correspondiente (cuya ficha de User Persona también debe haberse
elaborado en la misma herramienta indicada).
Empathy Mapping
En esta sección, el equipo resume el proceso de elaboración y presenta capturas de
los Empathy Maps realizados en la herramienta indicada, para cada uno de los User
Personas. El proceso de elaboración incluye la preparación, colocar al centro el User
Persona. Colocar en la sección correspondiente en la herramienta cada observación
de los miembros del equipo sobre el User Persona, buscando responder las
preguntas ¿Con quién estamos empatizando? ¿Qué necesita hacer? ¿Qué está
diciendo? ¿Qué está viendo? ¿Qué está haciendo? ¿Qué está escuchando? ¿Cómo se
siente y qué piensa? Identificar Pains y Gains en base a las preguntas ¿Qué le
preocupa? Y ¿Qué puede ayudar a resolver sus problemas? ¿Qué puede convencerlo
de que somos la alternativa correcta? ¿Qué dice?
As-is Scenario Mapping
En esta sección el equipo introduce, resume el proceso realizado por el equipo y
presenta una captura de los As-Is Scenario Mapping elaborados en la herramienta
indicada para cada User Persona, incluyendo las filas Phases, Doing, Thinking y
Feeling. El proceso de realización debe pasar por las etapas de preparación, lluvia de
ideas individual, revisión e identificación de fases como columnas, nombrar las fases,
identificar y etiquetar áreas positivas y negativas para los usuarios, junto con blank
areas (áreas que requieren aprender más sobre ellas).

Requirements Specification
Esta sección permite que el equipo realice en base al análisis de la información
obtenida en las investigaciones, la especificación de los requisitos de los productos
digitales. La sección inicia con una introducción e incluye secciones internas para el
To-Be Scenario Mapping, los User Stories, Impact Map y Product Backlog.
To-Be Scenario Mapping.
En esta sección el equipo introduce, resume el proceso realizado por el equipo y
presenta una captura de los To-Be Scenario Mapping elaborados en la herramienta
indicada para cada User Persona, incluyendo las filas Phases, Doing, Thinking y
Feeling. El proceso de realización debe pasar por las etapas de preparación, lluvia de
ideas individual, revisión e identificación de fases como columnas, nombrar las fases,
comparar el mapa con el As-Is Scenario Mapping, identificando cambios que podría
ofrecer el To-Be Scenario Mapping.

11/30
User Stories
Requisitos definidos junto con el conjunto de User Stories y Epics para los requisitos
identificados. Los User Stories incluyen Acceptance Criteria. En esta sección el
equipo redacta una introducción y presenta un cuadro con la estructura especificada
a continuación.

Epic / User Título Descripción Criterios de Relacionado

Story ID Aceptación con (Epic ID)

Impact Mapping.
En esta sección el equipo explica y presenta capturas del Impact Mapping para el
modelo de negocio digital, elaborado en la herramienta indicada. Para esto debe
haber elaborado previamente en la herramienta las fichas para cada User Persona.
La elaboración incluye la identificación de los Busines Goals (los business goals deben
cumplir con los criterios SMART2. Por ejemplo “Alcanzar los 600 usuarios suscritos al
plan A en el lapso de 8 meses.”). Debe considerar varios Business Goals. Debe incluir
como Actors/Personas a los User Personas previamente identificados, según
relaciones con los Business Goals, buscando responder la pregunta ¿Quiénes me
ayudarán a lograr la meta? La columna Impact debe incluir los enunciados de cómo
desea que los User Persona cambien o se comporten ¿Qué tendría él/ella que hacer
para ayudar a que se logre la meta? La columna Deliverables debe incluir los
elementos que respondan la pregunta ¿Qué puedo hacer como negocio digital para
provocar esos Impacts? La columna User Stories debe incluir la descripción de los
User Stories (en el formato “Como... deseo... para...”) que permitirán obtener los
features que ayudarán a producir los Deliverables identificados.
Product Backlog.
Los User Stories deben incluir su estimación y priorización en el Product Backlog.
Debe utilizar la herramienta indicada para el Product Backlog. Adicionalmente debe
elaborar en este documento una tabla con la siguiente estructura.

# Orden User Story Id Título Descripción Story Points

(1 / 2 / 3 / 5
/ 8)
1 US01 AAA… Como… deseo… para…. 3
Adicionalmente debe incluir una captura y una referencia de URL del enlace público
para el product backlog en la herramienta indicada. Recuerde que en el Product
Backlog, el orden lo determina el valor para el negocio. Elaborar un product backlog
colocando al inicio User Stories ligados a la seguridad o autenticación, por ejemplo,
se considera incorrecto.

Product UX/UI Design

En esta sección se abarca el planteamiento de la propuesta de UX para la experiencia
web y la experiencia móvil dirigida a las plataformas iOS y Android. Para ello se
tomará como base el conjunto de User Stories identificados así como el Impact Map.

2
Vea el artículo “Why are SMART Goals Necessary In Business?” en la sección de Referencias.

12/30 V1.0
Style Guidelines
En esta sección, el equipo sienta las bases para contar con un repositorio central y
organizado de uso común para todo el equipo, que incluye assets, fonts, etc. Esto
con el fin de mantener una presentación consistente y enfocada. Se incluye
secciones para General Style Guidelines, Web Style Guidelines y Mobile Style
Guidelines.
General Style Guidelines
Aquí se explica las decisiones y referencias visuales sobre conceptos generales
básicos como Branding, Typography, Colors y Spacing, así como las dimensiones a
adoptar para el tono de comunicación y lenguaje aplicado (Divertido/Serio,
Formal/Casual, Respetuoso/Irreverente, Entusiasta/Sereno). Puede tomarse como
referencia un Design System existente, sobre el cual se puede realizar adaptaciones.
Esta sección debe incluir el sustento de principios y elementos de diseño
considerados para las decisiones.
Web Style Guide.
En esta sección se explica e ilustra las decisiones sobre los estándares visuales y de
interacción para responsive web interfaces.
Mobile Style Guide.
En esta sección se explica e ilustra los estándares visuales y de interacción para las
interfaces de aplicaciones móviles. Debe considerarse las diferencias en
representación visual de los componentes en las dos principales plataformas
móviles, Android y iOS.

Information Architecture
En esta sección el equipo plantea las decisiones y sustento que dirigen la manera
como se organizará el contenido en las experiencias web y móvil, incluyendo el
Landing Page y las Aplicaciones. Dichas propuestas deben estar orientadas a que los
visitantes y usuarios se adapten con facilidad a la funcionalidad de cada producto y
puedan encontrar todo aquello que necesiten sin esfuerzo. Se incluyen las decisiones
sobre los Organization Systems, Labeling Systems, Navigation Systems y Searching
Systems.
Organization Systems.
En esta sección el equipo explica en qué grupos de información aplicará cuáles
sistemas de organización. Aquí se incluye la explicación de en qué casos se aplicará la
organización visual del contenido: de forma jerárquica (visual hierarchy),
organización secuencial (step-by-step to accomplish) o matricial. Por otro lado,
también se debe explicar en qué casos se utilizará qué esquemas de categorización
de contenido: alfabético, cronológico, por tópicos, según audiencia (grupos de
usuarios).
Labeling Systems.
Aquí el equipo explica de qué maneras se representarán los datos, considerando
simplicidad y buscando evitar la confusión para los visitantes y usuarios. En esta

13/30
sección se especifica las etiquetas (con el mínimo número de palabras) a utilizar para
representar los conjuntos de información y las asociaciones3 entre las mismas.
Navigation Systems
Aquí el equipo explica cuáles serán las acciones y técnicas que guiarán a los usuarios
a través del Landing Page y las aplicaciones, permitiéndoles cumplir sus metas e
interactuar de forma satisfactoria con el producto. Aquí se debe incluir de qué
maneras los usuarios irán recorriendo el contenido.
Searching Systems
En esta sección el equipo explica qué medios de ayuda se brindará al usuario para la
búsqueda de datos dentro del producto digital. Dichas decisiones sobre los sistemas
de búsqueda tratan de evitar que los usuarios se sientan perdidos entre el volumen
de información. Aquí se deben especificar qué opciones de búsqueda ofrecerán las
aplicaciones, con qué filtros contará el usuario en cada caso y cómo lucirán los datos
después de la búsqueda.

Landing Page UI Design

En esta sección el equipo elabora la propuesta de UI para el Landing Page. La sección
inicia con una introducción en la que el equipo explica cómo traduce las decisiones
de diseño y arquitectura de información.
Landing Page Wireframe
Esta sección incluye una sección interna donde se presenta y explica los Wireframes
del Landing Page para Desktop Web Browser y Mobile Web Browser. En la propuesta
y la explicación debe evidenciarse la aplicación de los principios, elementos de
diseño, diseño inclusivo y arquitectura de información.
Landing Page Mock-up
Esta sección presenta y explica los Mock-ups del Landing Page, tanto en su versión
para Desktop Web Browser como Mobile Web Browser. En la propuesta y la
explicación debe evidenciarse la aplicación de los principios, elementos de diseño,
diseño inclusivo y arquitectura de información, así como el Design System
establecido para los productos digitales.

Mobile Applications UX/UI Design

Esta sección incluye secciones internas donde se presenta y explica la propuesta
visual y de interacción para las aplicaciones que constituyen la experiencia de
usuario con los productos digitales.
Mobile Applications Wireframes
Esta sección incluye una sección interna donde se presenta y explica los Wireframes
de las aplicaciones móviles. En la propuesta y la explicación debe evidenciarse la
aplicación de los principios, elementos de diseño, diseño inclusivo y arquitectura de
información. Utilizar para los wireframes las herramientas indicadas.
Mobile Applications Wireflow Diagrams
Esta sección presenta la propuesta de Wireflows. Debe considerarse un Wireflow
para cada User goal, considerando los User Persona para cada aplicación que forma
parte del alcance. Es recomendable que el equipo elabore previamente los

3
Por ejemplo, la etiqueta ‘Contacto’ en un botón en el encabezado de una página sirve para asociar en
la mente del visitante que encontrará en otro lugar información de contacto como número de teléfono,
email y cuentas de redes sociales, sin necesidad de que todo esté aglomerado en un mismo lugar.

14/30 V1.0
correspondientes Task Flows, para establecer un consenso sobre las rutas típicas de
steps para cada User goal. Es importante recordar que la forma como se refleja un
cambio en una pantalla (Wireframe) como resultado de la interacción en un flujo es
agregar un paso con un Wireframe con la representación del nuevo estado. Utilizar
para los Wireflows las herramientas indicadas. Cada Wireflow diagram requiere que
se redacte el User goal y se complemente con una explicación del flujo especificado.
Mobile Applications Mock-ups
Esta sección presenta y explica los Mock-ups de las aplicaciones móviles. En la
propuesta y la explicación debe evidenciarse la aplicación de los principios,
elementos de diseño, diseño inclusivo y arquitectura de información, así como el
Design System establecido para los productos digitales. Utilizar para los mock-ups las
herramientas indicadas.
Mobile Applications User Flow Diagrams.
Esta sección presenta la propuesta de User Flows. Debe considerarse un User Flow
para cada User goal, considerando los User Persona para cada aplicación que forma
parte del alcance. Estos User Flows deben ser consistentes con los Wireflows de los
cuales se derivan. Debe recordarse que en el User Flow se incluyen los Mock-ups de
las vistas o pantallas de las aplicaciones, junto con los flujos que constituyen la ruta
esperada (happy path) y las rutas alternativas (unhappy paths). Utilizar para los User
Flows las herramientas indicadas. Cada User Flow diagram requiere que se redacte el
User goal y se complemente con una explicación de los flujos y condiciones
especificados.

Mobile Applications Prototyping.

Esta sección incluye Prototipos de mobile UI para Android y iOS con simulación de
interacción y navegación, acorde con la propuesta de paths de User Flow Diagrams.
Esta sección inicia con una introducción en la que se explica los principales criterios
para las decisiones de interacción. Es importante evidenciar la relación con las
decisiones de arquitectura de información, en particular sobre el sistema de
navegación y los tipos de interacciones seleccionadas. Esta sección debe incluir dos
secciones internas, que ilustren la propuesta para las dos principales plataformas
móviles, Android y iOS. Para cada caso debe incluirse 1 screenshot de video y un
enlace a un video subido a YouTube para cada aplicación, en el que se demuestre y
explique los principales flujos de interacción que cubren los prototipos.

Product Implementation & Deployment

En esta sección el equipo explica y evidencia el proceso de implementar un landing
page que aplique responsive web design y permita presentar el modelo de negocio y
las aplicaciones web y móvil. Abarca secciones para la organización del proceso de
trabajo en Sprints, la descripción y prácticas asociadas a Software Configuration
Management, el Video About-The-Product y las evidencias de Landing Page
Implementation en términos del producto y colaboración por Sprint.

Software Configuration Management

15/30
En esta sección el equipo establece las decisiones y convenciones que permitirán
mantener la consistencia durante el ciclo de vida. Se incluyen secciones internas para
Source Code Management, Development Environment Configuration y Deployment
Configuration.
Software Development Environment Configuration
En esta sección el equipo especifica, describe e indica la ruta de referencia (para
software basado en modelos SaaS) o ruta de descarga (para productos que se
ejecutan en el computador del miembro del equipo) de cada uno de los productos
de software que deben utilizar los miembros del equipo para colaborar en el ciclo de
vida del producto digital, considerando todos los tipos de actividades como Project
Management, Requirements Management, Product UX/UI Design, Software
Development, Software Testing, Software Documentation, respetando las
restricciones indicadas sobre productos de software y herramientas que se pueden
utilizar.
Source Code Management
En esta sección el equipo establece los medios y esquema de organización que
aplicará para el seguimiento de modificaciones. Para ello utilizará GitHub como
plataforma y sistema de control de versiones. Debe incluirse el URL del repositorio
de GitHub para el Landing Page, así como el repositorio donde se registrará los
archivos de pruebas de aceptación (archivos .feature).
En esta sección debe también explicarse de qué forma implementará GitFlow (Ver
artículo “A successful Git branching model” de Vincent Driessen en la sección de
Referencias) como Workflow de control de versiones, es decir qué branches (ramas)
creará además de main branch (rama principal), por ejemplo, develop branch. Para
GitFlow cada Feature requiere su propio branch, por ello debe especificar qué
convenciones se aplicará para nombrar los feature branches. Igualmente debe incluir
las convenciones para Release branches y Hotfix branches. Aplique semantic
versioning para nombrar sus Releases (Vea “Semantic Versioning 2.0.0” en la sección
de Referencias).
Aplique Conventional Commits para los textos de mensajes en sus commits (Vea
“Conventional Commits” en la sección de Referencias).
Source Code Style Guide & Coding Conventions
Aquí el equipo resume e indica las referencias que adoptará para nombrar
elementos y programar en los lenguajes que se utilizan en la solución (en este caso
HTML, CSS y JavaScript, así como Gherkin para los archivos .feature). Para todos los
lenguajes debe aplicar la nomenclatura en inglés. Adicionalmente, adopte
convenciones estándares para coding (Vea “HTML Style Guide and Coding
Conventions”, “Google HTML/CSS Style Guide” y “Gherkin Conventions for Readable
Specifications” en la sección de Referencias).
Software Deployment Configuration
En esta sección el equipo especifica la configuración del despliegue de la solución,
incluyendo los pasos necesarios para que, a partir de los repositorios de código
fuente, se pueda lograr el despliegue o publicación satisfactorio de cada uno de los
productos digitales en la solución (en este caso el Landing Page).
Video About-the-Product
En esta sección el equipo introduce y describe el contenido del Video About-the-
Product, el cual tiene como público objetivo los visitantes al Landing Page, quienes

16/30 V1.0
desean conocer sobre el modelo de negocio y las características principales de los
productos de software. El tono que utilice en la comunicación debe ser consistente
con el tono adoptado para el producto y debe incluirse al menos un testimonio
positivo de un usuario que haya participado en las entrevistas de validación. Debe
incluirse también en esta sección un screenshot del Video, el URL de la versión
publicada en YouTube y el timing (duración) del mismo.
Landing Page Implementation.
En esta sección se explica y evidencia el proceso de implementación del Landing
Page. Incluye una sección interna por cada Sprint relacionado con la implementación
(Sprint 1, Sprint 2, etc.).
Sprint n
En esta sección se registra y explica el avance en términos de producto y trabajo
colaborativo. Incluye dos secciones internas: Sprint Backlog n, User Interface &
Execution y Team Collaboration Insights.
Sprint Backlog n
Una sección de Sprint debe iniciar con una introducción que resuma el objetivo
principal del Sprint y a continuación presente un screenshot del Board para el Sprint
en la herramienta de control indicada (por ejemplo Trello), junto con el URL público
del Board. A continuación, debe incluir una tabla donde se especifique los User
Stories asignados al Sprint, junto con los Work-items/Tasks resultantes de la
descomposición de los User Stories o Tasks adicionales que no dependen de un User
Story en particular (por ejemplo, un task que debe realizarse para satisfacer un
constraint general).
A continuación, la estructura de la tabla de control de estado para un Sprint.
Sprint # Sprint n
User Story Work-Item / Task
Status
(To-do /
In-
Estimation
Id Title Id Title Description Assigned To Process /
(Hours)
To-
Review /
Done)

User Interface & Execution

Esta sección inicia con un resumen que explique lo alcanzado en este Sprint y
presenta screenshots de las principales vistas implementadas, junto con un enlace a
un video que ilustre y explique la visualización y navegación logrados en este Sprint.
Team Collaboration Insights
En esta sección el equipo explica cómo se han desarrollado las actividades de
implementación y se presenta capturas en imagen de los analíticos de colaboración y
commits realizados por los miembros del equipo. Todos los miembros del equipo
deben tener participación en la implementación del Landing Page.

Product Validation
En este capítulo, el equipo registra y explica las actividades de diseño de acceptance
tests, entrevistas de validación y los procesos de auditoría de UX en los que ha
participado durante el proyecto (sea como equipo auditor o como equipo auditado).

17/30
Acceptance Tests
Aproximación al conjunto de Acceptance Tests para los User Stories especificados.
Debe elaborarse los archivos .feature utilizando el lenguaje Gherkin. En esta sección
se debe incluir la relación de tests diseñados y el código de los .feature Files,
explicando con qué User Stories se relacionan. También debe incluirse la ruta del
repositorio de control de versiones para el conjunto de archivos .feature, así como
capturas de las vistas de analíticos de colaboración de los participantes en el equipo.

Entrevistas de validación.
Se debe realizar entrevistas de validación en las que usuarios de los segmentos
objetivo interactúen con el landing page y con los prototipos de experiencia mobile.
Incluye secciones internas para Diseño de Entrevistas, Registro de Entrevistas,
Evaluaciones según heurísticas. Para el proceso de validación debe aplicarse el
formato de evaluación heurística indicado para el proyecto.
Diseño de Entrevistas.
En esta sección el equipo establece por cada segmento objetivo los elementos a
incluir en la sesión de validación, incluyendo el Landing Page y las aplicaciones. Aquí
se especifica también cuáles serán los user flows de las aplicaciones, que formarán
parte del proceso de validación.
Registro de Entrevistas.
Para cada segmento se requiere de 3 a 5 entrevistas. Para cada una de las entrevistas
se debe indicar la información de nombres, apellidos, edad, distrito, un screenshot
de un cuadro de video y el URL del video subido en YouTube incluyendo el timing
donde inicia la entrevista y su duración. La entrevista debe ser registrada en video,
que sirve de evidencia de entrevistas. Para cada entrevista debe redactarse en este
informe un resumen, que explique de forma descriptiva las principales apreciaciones
del entrevistado con respecto a las tareas asignadas.
Evaluaciones según heurísticas.
Esta sección contiene el proceso de evaluación de las sesiones de validación basado
en heurísticas, considerando heurísticas de usabilidad, arquitectura de información e
inclusive design de la experiencia propuesta. Para esto la sección debe contener la
estructura del formato para evaluaciones de heurísticas indicado.

Auditoría de Experiencias de Usuario

Esta sección contiene los procesos de auditoría en los que el equipo ha participado,
sea como empresa auditora o como empresa auditada. Aquí se incluye dos secciones
internas, Auditoría realizada y Auditoría recibida.
Auditoría realizada.
En esta sección el equipo incluye la información del proceso de auditoría realizada a
otro equipo. Esta sección incluye secciones internas para detallar la información del
grupo auditado, el cronograma de auditoría, así como el contenido de la auditoría.

Información del grupo auditado.

En esta sección se incluye el nombre de startup a la cual se auditó y la relación de
integrantes incluyendo Nombres y Apellidos, junto con el Código de estudiante para
cada uno.

18/30 V1.0
Cronograma de auditoría realizada.
En esta sección el equipo especifica las fechas y horas para las actividades realizadas
como parte del proceso de auditoría. Se incluye la información las fechas, horas y
quiénes realizaron las actividades indicadas bajo el siguiente formato:

Actividad de auditoría realizada Fecha Hora Realizado por

Envío de solicitud de información YYYY/MM/DD HH:MM (Nombres y
y artefactos por email Apellidos)
Recepción de información y YYYY/MM/DD HH:MM (Nombres y
artefactos por email Apellidos)
Ejecución del proceso de YYYY/MM/DD HH:MM (Nombres y
auditoría Apellidos,
Nombres y
Apellidos…)
Elaboración del informe de YYYY/MM/DD HH:MM (Nombres y
auditoría Apellidos)
Envío del informe de auditoría YYYY/MM/DD HH:MM (Nombres y
Apellidos)

Contenido de auditoría realizada.

En esta sección se incluye el contenido de la auditoría según el formato especificado
para este proceso (Ver documento “upc-pre-202102-si385-ux-audit-report-
template_v1.docx”).

Auditoría recibida.
En esta sección el equipo incluye la información del proceso de auditoría recibida de
otro equipo. Esta sección incluye secciones internas para detallar la información del
grupo auditor, el cronograma de auditoría, así como el contenido de la auditoría.
Información del grupo auditor.
En esta sección se incluye el nombre de startup auditor y la relación de integrantes
incluyendo Nombres y Apellidos, junto con el Código de estudiante para cada uno.
Cronograma de auditoría recibida.
En esta sección el equipo especifica las fechas y horas para las actividades realizadas
como parte del proceso de auditoría. Se incluye la información las fechas, horas y
quiénes realizaron las actividades indicadas bajo el siguiente formato:

Actividad de auditoría recibida Fecha Hora Realizado por

Recepción de solicitud de YYYY/MM/DD HH:MM (Nombres y
información y artefactos por Apellidos)
email
Envío de información y artefactos YYYY/MM/DD HH:MM (Nombres y
por email Apellidos)
Recepción del informe de YYYY/MM/DD HH:MM (Nombres y
auditoría Apellidos)
Ejecución de modificaciones para YYYY/MM/DD HH:MM (Nombres y
subsanar hallazgos de auditoría. Apellidos,
Nombres y

19/30
 Apellidos…)

Contenido de auditoría recibida.

En esta sección se incluye el contenido de la auditoría recibida según el formato
especificado para este proceso (Ver documento “upc-pre-202102-si385-ux-audit-
report-template_v1.docx”).
Resumen de modificaciones para subsanar hallazgos.
En esta sección el equipo resume las modificaciones o adiciones realizadas con el fin
de subsanar los hallazgos identificados por el grupo auditor.

Conclusiones
En esta sección se incluye como secciones internas Conclusiones y recomendaciones,
así como Video About-The-Team.
Conclusiones y recomendaciones
En esta sección el equipo enuncia las conclusiones sobre el trabajo, incluyendo los
resultados a los que ha llegado en relación a los Problem Statements especificados,
los assumptions realizados frente al comportamiento real de los segmentos, los
Hypotheses Statements establecidos y los criterios de éxito especificados en el
proceso de Lean UX, en contraste con los resultados obtenidos de las validaciones.
Igualmente incluye recomendaciones sobre los siguientes pasos en relación a
Roadmap de los productos digitales que forman parte del alcance del modelo de
negocio digital.
Video About-The-Team
En esta sección el equipo elabora un resumen de los aspectos más relevantes del
video About-The-Team, la pauta de secuencias de contenido (secciones con el timing
de inicio de cada una, es decir hh:mm:ss de cada sección dentro del video)
incluyendo además un cuadro de video representativo del mismo, junto con el URL
de la versión publicada en YouTube.

Bibliografía
En esta sección el equipo especifica todas las referencias bibliográficas en formato
APA, utilizadas como base para el desarrollo del trabajo o referenciadas en secciones
del informe.

Anexos
En esta sección, el equipo incluye como anexos tablas, documentos, gráficos, u otros
elementos que por su extensión o grado de importancia ameriten aparecer en esta
sección. Cada sección de anexo debe iniciar en una nueva página diferenciando el
título con una letra mayúscula (Ejemplo: Anexo A, Anexo B, etc.)

El Equipo de Trabajo (Startup)

El equipo de desarrollo estará conformado por un grupo de estudiantes (el número
de integrantes será indicado por el docente), entre quienes se distribuirá los roles y
actividades a realizar como parte del proyecto. Es importante recalcar que
independientemente de la colaboración en los diversos aspectos relacionados al
proyecto, todos los participantes deben colaborar en la elaboración de las
propuestas de experiencias web y móviles en Android y iOS, así como la

20/30 V1.0
implementación del landing page, evidenciando el desarrollo de las competencias
objetivo de este curso.

Proceso de Trabajo
El proyecto se elaborará bajo un enfoque ágil, basado en un proceso enmarcado por
Lean UX, iterativo e incremental. El grupo llevará una bitácora en video de sus
actividades, lo cual junto con entrevistas de retrospectiva servirán para la
construcción del video About-The-Team.

Tecnologías
Para el desarrollo del Landing Page, se utilizará HTML5, CSS3 y JavaScript.
Para elaborar los User Persona se utilizará UXPressia.
Para los Journey Map e Impact Map se utilizará UXPressia .
Para el Empathy Map se utilizará UXPressia.
Para As-Is / To-Be Scenario Mapping se utilizará Lucidchart / Mural / Miro.
Para el desarrollo de la propuesta de UI y la simulación de interacción se utilizará
Figma / Adobe XD.
Para el control de proyectos, se utilizará PivotalTracker / JetBrains YouTrack / Jira
Software / Trello.
Para el almacenamiento y control de versiones de código se utilizará GIT gestionado
desde GitHub.

Convenciones
Para la nomenclatura de todos los tipos de objetos de ciclo de vida de software,
incluyendo requisitos, diseño, desarrollo y pruebas de software se utilizará
nomenclatura en inglés. Para convenciones en lenguajes de programación y scripting
debe respetar las indicaciones establecidas en las secciones correspondientes en
este documento.

Accessibilidad
Debe evidenciarse que el ciclo de vida de la solución y los productos elaborados
están dirigidos por un enfoque inclusivo. En el caso de los productos, éstos deben
incluir características de Accessibility bajo a11y (en el caso del Landing Page). Incluya
en el Landing Page la configuración de ARIA attributes y buenas prácticas de inclusive
design (por ejemplo, colocar valor para el alt attribute en imágenes).

21/30
 Evaluación del Trabajo Final
El trabajo se ha dividido en 6 entregables.

TB1 – Sprint Review – Semana 3

Final Project Mid-term Documentation Report
Final Project Mid-term Keynote
Final Project Mid-Term Individual Member Performance Report (by Team Leader)
Archivo .zip con archivos complementarios según corresponda (videos, proyectos de
software, documentos complementarios).
Consideraciones: Aspectos a considerar:
Carátula.
Registro de Versiones del Informe.
Contenido.
Student Outcome.
Capítulo I: Introducción
1.1. Startup Profile
1.1.1. Descripción de la Startup
1.1.2. Perfiles de integrantes del equipo
1.2. Solution Profile
1.2.1 Antecedentes y problemática
1.2.2 Lean UX Process.
1.2.2.1. Lean UX Problem Statements.
1.2.2.2. Lean UX Assumptions.
1.2.2.3. Lean UX Hypothesis Statements.
1.2.2.4. Lean UX Canvas.
1.3. Segmentos objetivo.
Avance de Conclusiones, Bibliografía y Anexos.

TB2 – Sprint Review – Semana 5

Final Project Mid-term Documentation Report
Final Project Mid-term Keynote
Final Project Mid-Term Individual Member Performance Report (by Team Leader)
Archivo .zip con archivos complementarios según corresponda (videos, proyectos de
software, documentos complementarios).
Consideraciones:
Debe incluir versión actualizada de Registro de Versiones de Informe y Sección Student
Outcome. Debe incluir versión corregida y mejorada de artefactos previamente
presentados. Debe incluir en el informe aspectos como:
Capítulo II: Requirements Elicitation & Analysis
2.1. Competidores.
2.1.1. Análisis competitivo.
2.1.2. Estrategias y tácticas frente a competidores.
2.2. Entrevistas
2.2.1. Diseño de entrevistas
2.2.2. Registro de entrevistas.
2.2.3. Análisis de entrevistas.
2.3. Needfinding.

22/30 V1.0
2.3.1. User Personas.
2.3.2. User Task Matrix.
2.3.3. User Journey Mapping.
2.3.4. Empathy Mapping.
2.3.5. As-is Scenario Mapping.
Avance de Conclusiones, Bibliografía y Anexos.

TP1 – Stage Review – Semana 7

Final Project Mid-term Documentation Report
Final Project Mid-term Keynote
Final Project Mid-Term Individual Member Performance Report (by Team Leader)
Archivo .zip con archivos complementarios según corresponda (videos, proyectos de
software, documentos complementarios).
Consideraciones:
Debe incluir versión actualizada de Registro de Versiones de Informe y Sección Student
Outcome. Debe incluir versión corregida y mejorada de artefactos previamente
presentados. Debe incluir en el informe aspectos como:
Capítulo III: Requirements Specification
3.1. To-Be Scenario Mapping.
3.2. User Stories.
3.3. Impact Mapping.
3.4. Product Backlog.
Capítulo IV: Product UX/UI Design
4.1. Style Guidelines.
4.1.1. General Style Guidelines.
4.1.2. Web Style Guidelines.
4.1.3. Mobile Style Guidelines.
4.1.3.1. iOS Mobile Style Guidelines.
4.1.3.2. Android Mobile Style Guidelines.
4.2. Information Architecture.
4.2.1. Organization Systems.
4.2.2. Labeling Systems.
4.2.3. Searching Systems.
4.2.3. Navigation Systems.
4.3. Landing Page UI Design.
4.3.1. Landing Page Wireframe.
4.3.2. Landing Page Mock-up.
4.4. Mobile Applications UI Design.
4.4.1. Mobile Applications Wireframes.
4.4.2. Mobile Applications Wireflow Diagrams.
Avance de Conclusiones, Bibliografía y Anexos.

TB3 – Sprint Review – Semana 11

Final Project Final Documentation Report
Final Project Final Keynote
Final Project Final Individual Member Performance Report (by Team Leader)
Archivo .zip con archivos complementarios según corresponda (videos, proyectos de
software, documentos complementarios).
Consideraciones:

23/30
Debe incluir versión actualizada de Registro de Versiones de Informe y Sección Student
Outcome. Debe incluir versión corregida y mejorada de artefactos previamente
presentados. Debe incluir en el informe aspectos como:
4.4.2. Mobile Applications Mock-ups.
4.4.3. Mobile Applications User Flow Diagrams.
4.5. Mobile Applications Prototyping.
4.5.1. Android Mobile Applications Prototyping.
4.5.2. iOS Mobile Applications Prototyping.
Capítulo V: Product Implementation
5.1. Software Configuration Management.
5.1.1. Software Development Environment Configuration.
5.1.2. Source Code Management.
5.1.3. Source Code Style Guide & Conventions.

Final Project Final Documentation Report

Final Project Final Keynote
Final Project Final Individual Member Performance Report (by Team Leader)
Avance de Conclusiones, Bibliografía y Anexos.

TB4 – Sprint Review – Semana 13

Final Project Final Documentation Report
Final Project Final Keynote
Final Project Final Individual Member Performance Report (by Team Leader)
Archivo .zip con archivos complementarios según corresponda (videos, proyectos de
software, documentos complementarios).
Consideraciones:
Debe incluir versión actualizada de Registro de Versiones del Informe y Sección Student
Outcome. Debe incluir versión corregida y mejorada de artefactos previamente
presentados. Debe incluir en el informe aspectos como:
5.2. Product Implementation & Deployment.
5.2.1. Sprint 1
5.2.1.1. Sprint Backlog 1.
5.2.1.2. User Interface & Execution.
5.2.1.3. Team Collaboration Insights.
5.3. Video About-the-Product.
Capítulo VI: Product Validation
6.1. Acceptance Tests
6.2. Entrevistas de validación.
6.2.1. Diseño de Entrevistas.
6.2.2. Registro de Entrevistas.
6.2.3. Evaluaciones según heurísticas.
6.3. Auditoría de Experiencias de Usuario
6.3.1. Auditoría realizada.
6.3.1.1. Información del grupo auditado.
6.3.1.2. Cronograma de auditoría realizada.
6.3.1.3. Contenido de auditoría realizada.
6.3.2. Auditoría recibida.
6.3.2.1. Información del grupo auditor.
6.3.2.2. Cronograma de auditoría recibida.

24/30 V1.0
6.3.2.3. Contenido de auditoría recibida.
6.3.2.4. Resumen de modificaciones para subsanar hallazgos.
Avance de Conclusiones, Bibliografía y Anexos.

TF1 – Release Review – Semana 15

Final Project Final Documentation Report
Final Project Final Keynote
Final Project Final Individual Member Performance Report (by Team Leader)
Archivo .zip con archivos complementarios según corresponda (videos, proyectos de
software, documentos complementarios).
Debe incluir versión corregida y mejorada de artefactos previamente presentados.
Debe incluir sección 5.2.2. Sprint 2.
Debe incluir en el informe versión final y evidencias de la conclusión del ciclo de vida y el
proyecto con todos los Capítulos.
Se incluye además versión final de Conclusiones, Bibliografía y Anexos.

25/30
Referencias

Seriously, what’s your (startup’s) problem?

https://medium.com/@jakemendel/seriously-whats-your-startup-s-problem-
b3a884c54ab4
5W+2H - Técnica de análisis de problemas
https://www.progressalean.com/5w2h-tecnica-de-analisis-de-problemas/
Lean UX – Chapter 3
http://leanuxbook.com/images/leanux-sampler.pdf
Mike Cohn’s Mountain Goat Software Blog – User Stories Articles
https://www.mountaingoatsoftware.com/blog/tag/user-stories
User vs. Buyer Persona: Differences and free template
https://uxpressia.com/blog/user-persona-vs-buyer-persona-difference
How to create an Impact Map in 4 easy steps?
https://uxpressia.com/blog/build-impact-map-4-easy-steps
Why are SMART Goals Necessary In Business?
https://mileiq.com/blog-en-gb/smart-business-goals
As-is Scenario Map: Build a better understanding of your users’ current experience.
https://www.ibm.com/design/thinking/page/toolkit/activity/as-is-scenario-map
To-be Scenario Map: Draft a vision of your user’s future experience to show how
your ideas address their current needs.
https://www.ibm.com/design/thinking/page/toolkit/activity/to-be-scenario-map
Empathy Map: Build empathy for your users through a conversation informed by
your team’s observations.
https://www.ibm.com/design/thinking/page/toolkit/activity/empathy-map
Empathy Mapping: The First Step in Design Thinking
https://www.nngroup.com/articles/empathy-mapping/
Adobe XD tutorials
https://helpx.adobe.com/xd/tutorials.html
Acceptance Criteria in Scrum: Explanation, Examples, and Template
https://dzone.com/articles/acceptance-criteria-in-software-explanation-exampl
A Beginner’s Guide to finding User Needs
https://jdittrich.github.io/userNeedResearchBook/
Using a Requirements Traceability Matrix to improve project quality
https://www.modernrequirements.com/blogs/using-a-requirements-traceability-
matrix-to-improve-project-quality/
A step-by-step guide to scenario mapping
http://www.uxforthemasses.com/scenario-mapping/
What are User Flows in User Experience (UX) Design?
https://careerfoundry.com/en/blog/ux-design/what-are-user-flows/
Design Systems 101
https://www.nngroup.com/articles/design-systems-101/
Front-End Style-Guides: Definition, Requirements, Component Checklist
https://www.nngroup.com/articles/front-end-style-guides/
The Four Dimensions of Tone of Voice
https://www.nngroup.com/articles/tone-of-voice-dimensions/
A successful Git branching model

26/30 V1.0
https://nvie.com/posts/a-successful-git-branching-model/
Semantic Versioning 2.0.0
https://semver.org/
Conventional Commits
https://www.conventionalcommits.org/
HTML Style Guide and Coding Conventions
https://www.w3schools.com/html/html5_syntax.asp
Google HTML/CSS Style Guide
https://google.github.io/styleguide/htmlcssguide.html
Gherkin Conventions for Readable Specifications
https://specflow.org/gherkin/gherkin-conventions-for-readable-specifications/

27/30
Anexos

Anexo A. Estructura para la sección Objetivo del Estudiante (Student Outcome)

El curso contribuye al cumplimiento del Student Outcome ABET:

ABET – EAC - Student Outcome 2

Criterio: La capacidad de aplicar el diseño de ingeniería para producir soluciones que
satisfagan necesidades específicas con consideración de salud pública, seguridad y
bienestar, así como factores globales, culturales, sociales, ambientales y económicos.
En el siguiente cuadro se describe las acciones realizadas y enunciados de
conclusiones por parte del grupo, que permiten sustentar el haber alcanzado el logro
del ABET – EAC - Student Outcome 2.

Criterio específico Acciones realizadas Conclusiones

Diseña productos o componentes en Jiménez Rosas, Arturo Eduardo Fusce cursus dolor et nulla suscipit,
ingeniería de software que satisfacen TB1 sit amet ullamcorper nibh
necesidades específicas considerando Morbi vel tortor id eros dictum vestibulum.
el impacto en salud pública, venenatis id ut dui. Nam ornare massa eu lobortis
seguridad, bienestar, así como Mauris quis tellus sed nunc hendrerit porttitor.
factores globales, culturales, sociales, vehicula ac id mauris. Nam ut erat feugiat libero pretium
ambientales y económicos Pellentesque volutpat tellus non semper at ac metus.
ligula blandit ullamcorper quis Sed at eros dapibus, fermentum
sodales erat. quam ut, bibendum lacus.
TB2 Curabitur eget orci eget urna varius
… commodo.
Rodríguez Peña, Jorge Andrés …
TB1
…..
Diseña proyectos que permiten la Jiménez Rosas, Arturo Eduardo Fusce mattis augue a nisl bibendum,
implementación de soluciones en TB1 quis fringilla neque scelerisque.
ingeniería de software considerando Cras sed diam suscipit, malesuada ex Vivamus commodo libero eget
el impacto en salud pública, rutrum, fringilla orci. venenatis imperdiet.
seguridad, bienestar, así como Vestibulum in nunc quis elit suscipit Etiam imperdiet quam condimentum
factores globales, culturales, sociales, sollicitudin. velit tempor porttitor.
ambientales y económicos. TB2 Suspendisse blandit nisl quis mauris
… vehicula faucibus.
Rodríguez Peña, Jorge Andrés …
TB1
…..
Diseña y ejecuta los procesos Jiménez Rosas, Arturo Eduardo Duis porta lectus sit amet tortor
relacionados al desarrollo y TB1 aliquam, in dictum magna
mantenimiento de la solución de Nunc vitae tellus mollis, facilisis ullamcorper.
software en ingeniería considerando sapien sed, viverra tortor. Nulla et dolor ac odio dignissim
el impacto en salud pública, Duis lacinia purus eu urna euismod, maximus vel aliquet ipsum.
seguridad, bienestar, así como at auctor felis pellentesque. Praesent mattis arcu ut nunc tempus
factores globales, culturales, sociales, TB2 facilisis.
ambientales y económicos. … …
Rodríguez Peña, Jorge Andrés
TB1
…..

28/30 V1.0
Anexo B. Estructura para el Informe de Participación

El Final Project Individual Member Performance Report (by Team Leader) es un

documento en word donde el coordinador resume la participación de cada
integrante y la asigna a cada uno, una calificación entre 0 y 20.
Nombre del archivo: upc-pre-202102-si385-<sección>-<startup> -performance-
sprint<n>.

Adjuntar el archivo en todas las entregas programadas junto al Final Project.

A continuación el cuadro con valores de ejemplo.

Participant Performance Report

Nombre de Startup Solvers Squad Nombre de Producto Health Advisor
Entrega TP1 Team Leader Jiménez Rosas, Arturo Eduardo
Ítem Estudiante Responsabilidades Cumplió a cumplió a cumplió no cumplió Calificación
tiempo destiempo parcialmente (Cero) asignada
(20 / 16 /
13 / 07 / 0)
Vivamus commodo X 13
1 Jiménez libero eget venenatis
Rosas, imperdiet.
Arturo
Etiam imperdiet quam X
Eduardo
condimentum velit
tempor porttitor.
… …
Suspendisse blandit X
nisl quis mauris
vehicula faucibus.
Duis lacinia purus eu X 20
2 Rodríguez urna euismod, at
Peña, Jorge auctor felis
Andrés pellentesque.
Duis porta lectus sit X
amet tortor aliquam,
in dictum magna
ullamcorper.
… …
Praesent mattis arcu X
ut nunc tempus
facilisis.
…
n Barrera No participó X 0
Robles, Luis
Miguel
…

29/30
Anexo C. Consideraciones sobre secciones que incluyen videos

Sección Características del video Sobre el contenido Integración y entrega

Needfinding Interviews Cantidad de videos: 1 Consolida todas las Subir el video en YouTube
Nomenclatura: entrevistas realizadas, con enlace privado.
upc-pre-202102-si385-<sección>-<startup>- incluyendo en cada Incluir en el informe
needfinding-sprint-<n> entrevista títulos con screenshot del video con
Formato: .mp4 información del enlace al mismo. Incluir
Duración: En función a cantidad de entrevistas entrevistado, el segmento redacción de introducción
(considerar edición de 3 a 5 minutos por entrevista). objetivo y la fecha de la a la sección y análisis de
entrevista. cada entrevista, así como
el análisis general donde
se identifican las variables
y los valores
representativos a nivel
objetivo y subjetivo que
servirán de base para la
definición de los User
Persona.
Prototypes Navigation / Product Cantidad de videos: 1 Consolida demostración del Subir el video en YouTube
Navigation Nomenclatura: flujo de navegación del con enlace privado.
upc-pre-202102-si385-<sección>-<startup>- Landing Page y las Incluir en el informe
<prototype/product>navigation-sprint-<n> aplicaciones, priorizando los screenshot del video con
Formato: .mp4 user flows relacionados con enlace al mismo.
Duración: En función a cantidad de user flows de el core business. Incluir redacción de
aplicaciones (considerar edición de 3 a 5 minutos por introducción a la sección,
aplicación). resumiendo los flujos de
navegación que se
incluyen en el video.
Validation Interviews Cantidad de Videos: 1 Consolida sesiones y Subir el video en YouTube
Nomenclatura: entrevistas de validación en con enlace privado.
upc-pre-202102-si385-<sección>-<startup>-validation- las que usuarios de los Incluir en el informe
sprint-<n> segmentos objetivo screenshot del video con
Formato: .mp4 interactúen con el landing enlace al mismo.
Duración: En función a cantidad de entrevistas page y con los prototipos de Incluir redacción de
(considerar edición de 3 a 5 minutos por entrevista). experiencias web y mobile, introducción a la sección y
manifestando sus redacción de análisis de
observaciones. Para cada cada entrevista, junto con
entrevista se debe incluir la evaluación de
títulos con información del heurísticas de usabilidad,
entrevistado, el segmento arquitectura de
objetivo y la fecha de la información y diseño
entrevista inclusivo para cada caso.
About the Product Cantidad de videos: 1 Orientación promocional, Subir el video en YouTube
Nomenclatura: resumiendo el modelo de con enlace privado.
upc-pre-202102-si385-<sección>-<startup>-about-the- negocio, las características y Incluir en el informe
product-sprint-<n> beneficios del producto, screenshot del video con
Formato: .mp4 incluyendo algunas escenas enlace al mismo.
Duración: De 1 a 3 minutos. de interacción con el Incluir redacción de
producto y al menos una introducción a la sección.
opinión por cada segmento Adicionalmente, incrustar
objetivo. el video en una sección
adecuada del Landing
Page.
About the Team Cantidad de videos: 1 Video que resume el Subir el video en YouTube
Nomenclatura: proceso de trabajo con enlace privado.
upc-pre-202102-si385-<sección>-<startup>-about-the- realizado, incluyendo Incluir redacción de
team-sprint-<n> escenas de sesiones de introducción a la sección,
Formato: .mp4 trabajo real del equipo, resumiendo el proceso de
Duración: En función al contenido (considerar 5 complementando con trabajo y los logros
minutos para la sección de retrospectiva del grupo y 1 narración (voz en off) del alcanzados por los
minuto por cada testimonio de miembro del equipo). proceso, junto con el miembros del requipo.
testimonio de cada Adicionalmente, incrustar
participante describiendo el video en una sección
actividades realizadas y adecuada del Landing
logro de outcomes Page.
desarrollo de competencias
alcanzados.

30/30 V1.0