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 (Coordinador del curso)
Quispe Vilchez, Eder Ramiro
Requejo Chaname, Walter Juan
Reyes Rodriguez, Eduardo Martin
SECCIONES: SI41, SI42, SI43, SI44, SI45, SI46, SS34, SS4A, SS4B,
SV41, SV42, SX41, SX42, SX43
FECHA DE EVALUACIÓN: Semana 15
CICLO ACADEMICO: 2022-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

1/31
experiencia web y aplicación móvil para iOS y Android orientada a satisfacer
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).
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ínima del video es de 10 minutos y
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-
202202-si385-<sección>-<startup>-report-<tbn/tp1/tf1> (.docx y .pdf)
- Presentación de Proyecto: Seguir la estructura de nombre upc-pre-202202-
<startup>-si385-<sección>-keynote-<tbn/tp1/tf1> (.pptx y .pdf)
- Documento de Informe de Participación: Seguir la estructura de nombre upc-
pre-202202-si385-<sección>-<startup>-performance-<tbn/tp1/tf1> (.docx y
.pdf)

2/31 V1.0
Recomendaciones generales
Revisar con detenimiento los documentos Final Project Statement (este
documento), así como las rúbricas.
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.
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 con 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.

3/31
 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.

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.

4/31 V1.0
 2.2.1. Diseño de entrevistas.
2.2.2. Registro de entrevistas.
2.2.3. Análisis de entrevistas.
2.3. Needfinding.
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.3. 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/31
 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.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

6/31 V1.0
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.
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.

7/31
 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 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.

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.

8/31 V1.0
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
Perfil

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
Análisis SWOT

competitiva.
Fortalezas

9/31
 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.
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.

10/31 V1.0
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 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?

11/31
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.
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.

User Story ID Epic ID

Title
Description
Acceptance criteria:

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

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

12/31 V1.0
 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 Description Story Points (1 /

2 / 3 / 5 / 8)
1 US01 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.
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.

13/31
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
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.

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/31 V1.0
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
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

15/31
 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
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).

16/31 V1.0
 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 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 tres 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).

17/31
 A continuación, la estructura de la tabla de control de estado para un Sprint.
Sprint # Sprint n
Work-Item / Task
Status (To-do / In-
User Story Estimation Assigned
Id Description Process / To-Review
ID (Hours) To
/ 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).
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

18/31 V1.0
 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.
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)

19/31
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-202202-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
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-202202-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 con 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

20/31 V1.0
 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 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.

21/31
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).

22/31 V1.0
 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 incluir:
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.

23/31
 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.

24/31 V1.0
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:
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.3. 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.
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.

25/31
 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.
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
5.2.2.1. Sprint Backlog 2.
5.2.2.2. User Interface & Execution.
5.2.2.3. Team Collaboration Insights.
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.

26/31 V1.0
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

27/31
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/

28/31 V1.0
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
…..

29/31
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-202202-si385-<sección>-<startup>-performance-
<tbn/tp1/tf1> (.docx y .pdf).

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
…

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

31/31