Producción de Software

Tema 1

El software es el conjunto de programas de cómputo, procedimientos, reglas, documentación y datos

asociados, que forman parte de las operaciones e un sistema de computación.

• Software de sistema: Controla los componentes físicos que integran un dispositivo.

• Software de programación: Nos permite crear más software.
• Software de aplicación: programas instalados por el usuario con propósito determinado.
o Características Operativas:
- Corrección: debe cumplir su función.
- Usabilidad: intuitivo.
- Integridad: propósito concreto.
- Fiabilidad: Sin errores.
- Eficiencia: uso correcto de los recursos.
- Seguridad: resistente a acciones y ataques externos.

o Características de transición:
- Interoperabilidad: intercambio de info con otras apps.
- Reutilización: cambio de propósito con modificaciones del software.
- Portabilidad: accesible desde diversos equipos.

o Características de revisión:
- Capacidad de mantenimiento: para corregir problemas futuros.
- Flexibilidad: poder ser modificado por desarrolladores.
- Extensibilidad: fácil de mejorar.
- Escalabilidad: fácil de actualizar.
- Modularidad: compuesto por módulos independientes.
- Capacidad de prueba: la prueba del software debe ser fácil.

La ingeniería del software es una metodología que representa el camino para desarrollar software de
manera sistemática.
Reúsa elementos, estandariza la organización, aplica procesos sistemáticamente, acelera y
profesionaliza el desarrollo.

En los años 70 empezó el Desarrollo Estructurado, en los 80 el Desarrollo orientado a Objetos, en los
90 las metodologías ágiles y en los 2000 se consolidaron estas últimas.
Modelo de construcción de Prototipos

• Ventajas
- Ayuda a identificar los requisitos
- Agrada tanto a los clientes como a los desarrolladores
• Inconvenientes
- El cliente considera al prototipo como el producto final, listo para usar.
- La calidad del software o la factibilidad de mantenimiento no se tienen en cuenta
- El desarrollador a menudo hace compromisos de implementación

Modelo Incremental

Combina elementos del modelo lineal con la filosofía de creación de prototipos.

El primer incremento a menudo es un producto esencial.

A partir de la evaluación se planea el siguiente incremento y así sucesivamente.

Es interactivo por naturaleza.

Es útil cuando el personal no es suficiente para la implementación completa.

• Ventajas
- Se puede financiar el proyecto por partes
- Apropiado para proyectos grandes de larga duración
- No se necesita tanto personal al principio como para una implementación completa
• Inconvenientes
- Se necesitan pruebas de regresión
- Pueden aumentar el coste debido a las pruebas

Modelo en espiral

• Comunicación con el cliente: Para establecer comunicación entre el desarrollador y el cliente.

• Planificación: Para definir los recursos, el tiempo y otras informaciones relacionadas con el
proyecto.
• Análisis de riesgos: Para evaluar riegos técnicos y operativos.
• Ingeniería: Para construir una o más representaciones de la aplicación.
• Construcción y adaptación: Para construir, probar, instalar y proporcionar soporte al usuario
• Evaluación del cliente: Para obtener la reacción del cliente según la evaluación de las
representaciones del software

Gestión Basada en procesos

Eficiencia, Calidad y repetibilidad.
El CMMI (1991) está orientado a la mejora de los procesos mediante prácticas para el desarrollo y
mantenimientos de sistemas software asociadas a su ciclo de vida.
La calidad del resultado depende de la calidad de los procesos.

TQM – CMM – CMMI

Metodologías ágiles

• Crystal: metodologías en las que el tamaño del equipo (por colores) indica el método a utilizar.
• Dynamic Systems Development Method (DSDM): Iterativo e incremental. Trabajo con el
usuario.
5 fases:
- Estudio de viabilidad
- Estudio del negocio
- Modelo functional
- Diseño y construcción
- Implementación

• Lean Software Development: tecnicas Lean, 7 principios.

- Eliminar los desperdicios
- Ampliar el aprendizaje
- Decidir lo más tarde posible
- Reaccionar rápido
- Potenciar el equipo
- Crear la integridad
- Ver todo el conjunto
Tema 2

2.1 Metodologías ágiles

Gestión predictiva

La gestión predictiva tiene como objetivo construir el producto planificado en el tiempo y con los
costes previstos. “La Forma más eficiente de hacer un trabajo, es hacerlo bien a la primera”.
Inconvenientes:
• Los proyectos reales rara vez siguen el flujo secuencial
• Es difícil establecer explícitamente al principio todos los requisitos
• Para ver resultados… hay que ser MUY pacientes
• Se producen estados de bloqueo
Gestión ágil

• Se anticipa la presencia en el mercado.

• Las previsiones inversión / ROI se suavizan.
• Se mantiene la ventaja innovadora del producto en un mercado en movimiento.

En el entorno actual se valora mucho la velocidad y la incertidumbre al cambio y evolución del

mercado es enorme. La eficiencia y la previsibilidad YA NO SON las claves del éxito.
Manifiesto ágil

• Individuos e interacciones sobre procesos y herramientas.

• Software funcionando sobre documentación extensiva.
• Colaboración con el cliente sobre negociación contractual.
• Respuesta ante el cambio sobre seguir un plan.
Esto no quiere decir que se elimine la documentación, que prioricemos puramente la velocidad o que
busquemos la solución cómoda.

“Un buen plan ejecutado contundentemente hoy, es mejor que un plan perfecto ejecutado dentro de
un mes” - George Patton
Se valora el Producto mínimo viable.
El éxito depende del conocimiento y la experiencia de las personas y de la comunicación y
compromiso con el cliente.

2.2 SCRUM y sus artefactos

Creado en 1986 por Hirotaka Takeuchi e Ikujiro Nonaka.

Es SCRUM es un Framework simple basado en un sistema iterativo incremental. Presupone requisitos

indefinidos y cambiantes. Hace uso del conocimiento tácito de las personas. Tiene entregas
continúas tempranas, auto-organización de equipos y visibilidad diaria del proyecto.
Desde un concepto, se empieza la iteración de Especulación → Exploración → Revisión →
Artefactos

Funcionalidades: Sprint Backlog:

El desarrollo ágil se sostiene en las premisas de que el sistema se puede descomponer en

funcionalidades y que tiene valor disponer de ellas de forma parcial y cuanto antes.
Lo primero que debe hacer el cliente es definir la visión objetivo, identificar sus necesidades y
asignarles prioridad según su valor de negocio.
Así nace la pila de producto, que es un listado con las funcionalidades, mejoras, correcciones, etc.
del proyecto.

Historias de usuario:

- Yo como <rol>
- Deseo <funcionalidad>
- Para <valor de negocio>
Las historias de usuario se usan para capturar la esencia del valor de negocio de un sistema usando
lenguaje cotidiano.
Deben cumplir INVEST : Independiente, Negociable, Valiosa, Estimable, Pequeña, Testeable.
Y seguir el formato CCC: Card Conversation Confirmation.
La historia solo define QUÉ haremos, no CÓMO lo haremos.
En el caso ideal, una historia de usuario requiere solo una tarea.
Los criterios de aceptación son descripciones explícitas que demostrarán cuando una historia de
usuario está finalizada.
- Dado <escenario>
- Cuando <acción>
- Entonces <respuesta>

Las historias técnicas son las tareas que no impliquen funcionalidades.

Product Backlog:
Es un artefacto.
Debe cumplir DEEP: Detallada y Estimada apropiadamente, Emergente y Priorizada por necesidades.
La prioridad puede ser asignada numéricamente o con la técnica MoSCoW (must, should, could,
won’t)
No debemos crear historias épicas, sino tener historias cortas, de pequeñas tareas que lleguen al
mismo objetivo.
Sprint
NO es un artefacto, es un evento, de unas semanas de duración que pretende entregar algo que
funcione.
El Sprint está compuesto por una serie de historias de usuario que tendremos como objetivo para
completar y obtener un incremento.
Podemos hacer uso de tablones de trabajo para facilitar la organización.
Incremento
Es un artefacto.
Es el resultado de un sprint, así que debe estar completamente terminado, probado y usable.
Cada iteración debería implicar un incremento y requiere la validación del cliente.

2.3 Estimación ágil

La gestión ágil no determina el avance mediante el trabajo realizado, sino mediante el pendiente.
Medir es costoso y estúpido (KISS).
- Estimación: tiempo y dificultad que se espera.
- Tiempo real: tiempo efectivo para realizar un trabajo. No es empírica.
- Tiempo ideal: sin ser una unidad de tiempo, es una medida de esfuerzo y trabajo.
- Velocidad: Cantidad de trabajo por unidad unidad de tiempo. Misma unidad q la
estimación.
Cáculo de velocidad
Factor de foco * Velocidad Media Sprint / Sum(Días de trabajo)
Estimación de Complejidad
Planning Poker:

• Se reúne el equipo (intentar que haya diferentes perspectivas).

• Cada persona explica que entiende de la historia (dado su perfil).
• Si algo no está claro se pregunta al propietario de la pila.
• Cada persona presente anotará su estimación sin colaborar con los demás.
• Debate hasta conseguir consenso.
• Controlar el tiempo.
Trabajo
Burn Down Chart:
- Herramienta gráfica que se usa para monitorizar el trabajo diario.
- Plan según las estimaciones iniciales del Sprint.
- Mide el trabajo que falta, no el realizado.
- Hace uso de la pila de Sprint, la duración y el valor de “quema de puntos” de ese Sprint.
- ¿Estamos cerca de conseguir el incremento esperado?
- Se actualiza a diario.
Burn Up Chart:
- Herramienta gráfica para la monitorización global del trabajo realizado
- Muestra el plan general de desarrollo del proyecto
- Ofrece una estimación realista del trabajo restante
- Hace uso de la pila de producto, la velocidad real de cada Sprint y el
- valor de “quema de puntos del Sprint”
- ¿Cuántos Sprints estimamos que nos faltan?

Mapeo de Historias:

• Vista general de TODA la pila de producto

• Identificar nuevas historias, planificar entregas, redefinir prioridades…
• Minimum Marketable Feature Historias más sencillas de “lanzar”
2.4 Roles y Eventos

Roles:
- Usuarios (Implicado)
- Inversores (Implicado)
- Scrum Master (Comprometido, Scrum Team)
- Equipo de desarrollo (Comprometido, Scrum Team)
- Product Owner (Comprometido, Scrum Team)

• Product Owner:
- Es el Puente entre los comprometidos y los implicados. Representa al cliente.
Identifica las necesidades del cliente, conoce el entorno de negocio y toma decisiones
de producto por el cliente. Establece las prioridades.
- Es responsable del producto, de la pila, de la toma de decisiones, de las prioridades y
de la visión del producto. Evalúa el incremento.
- Es responsable económico (financiación, presupuesto, etc).

• Scrum Master:
- Asesora al product Owner y comunica de eventos durante el sprint.
- Intermedia entre el equipo y el cliente, vigila la metodología, modera las reuniones,
aprende y enseña.
- Resuelve los conflictos que el equipo no puede, fortalece el trabajo en equipo y lo
dirige.

• Equipo de Desarrollo:
- De 3 a 9 personas, para ser funcional y ágil.
- Son los responsables del desarrollo y están autoorganizados.
- Para cada sprint, eligen las historias a realizar, organizan las tareas. El Product Owner
no interfiere durante el Sprint.
- Se evita que sean especialistas, la dependencia externa y se confían en las
capacidades de cada uno, preguntando si es necesario.
- Responden como equipo y comparte lugar de trabajo.
Eventos
Son el sprint, el ciclo de trabajo/scrum diario, el final del sprint y su revisión y retrospectiva.
Planificación del Sprint:
• ¿Están claros y accesibles los recursos?
• ¿Hay una pila de producto priorizada? Priorizarla
• ¿El equipo conoce las tecnologías empleadas y el valor de negocio?
• ¿Disponibilidad del equipo?
• ¿Cuánto va a durar el Sprint?
 • ¿Continúan las mismas condiciones de negocio y ambiente tecnológico?
• Asistentes: Product Owner, Equipo y Scrum Master.
Scrum Diario:
Reunión de 15 min, de pie, moderada por el líder del proyecto donde se mira el trabajo realizado el día
anterior, el trabajo a realizar ese día y sus necesidades.

Revisión del Sprint:

La duración de la reunión es proporcional a la del sprint, cuanto más largo el sprint, más larga la
reunión (~4 horas/1 mes).

Retrospectiva de Sprint:
Evaluación de qué ha ido bien y mal en el sprint para aprender de ello.
~3 horas / 1 mes.
2.5 Control de versiones

VCS (Version Control systemm)

Es la gestión de los cambios que se realizan sobre el producto.
Los VCS han pasado de conexión centralizada a Distribuida (git).
Las principales características son su almacenamiento de elementos, la capacidad para hacer
cambios y el registro del histórico de los elementos.
Gracias a los VCS es mucho más fácil gestionar los cambios, como conflictos entre desarrolladores,
revertir cambios y tener una copia de seguridad.
Los VCS permiten el uso de herramientas externas, comunicación entre implicados, medición y
monitorización del trabajo y automatización para pruebas y entregas.

Estados del Git:

- Directorio de Trabajo: Trabajo volátil. A través de un add pasa a la Zona de intercambio.

- Zona de intercambio: Trabajo listo para el commit, que lo llevará al repositorio.
- Repositorio Git: Aquí están los cambios definitivos y versiones. Con un reset volvemos al
intercambio.

La Head es un puntero que apunta al último commit de la rama actual. Si la rama a la que apunta no
es la master, es una Detached head.
El .gitignore es un fichero en el que puedes indicar que tipo de archivos quieres ignorar mediante
símbolos.

Comandos de git (git <comando>):

• Init: Inicializa un repositorio .git en el directorio indicado, contienes sus metadatos y crea un
head.
• Add: añade el fichero que se le indique al staging area
• Status: muestra el estado el repositorio, el último commit y las odificaciones pendientes de
enviar al repositorio.
• Reset: Deshace cambios. Se puede invocar para Head, para el índice de staging o en el
directorio de trabajo. Esencialmente, vuelve al commit anterior.
• Revert: crea un nuevo commit que contiene un estado previo del proyecto. De esta manera, no
afecta a los commits previos y el historial.
• Commit: Añade los cambios del staging área al repositorio. Usando -m podemos añadir un
comentario al commit. Si quieres añadir o corregir un comentario al último commit, usa --
amend.
• Rm: Elimina ficheros del repositorio del staging.
• Checkout: Se usa para cambiar entre ramas.
• Branch: Crea (<rama>), lista, y borra (-d o -D + <rama>) ramas.
• Merge: Combina 2 ramas y sus commits. Existen conflictos si hay ediciones de un mismo
trabajo en distintas ramas al hacer el merge.
• Remote add origin: relaciona un repositorio local con uno remoto.
• Clone: clona el repositorio en otro directorio.
• Pull: Obtiene el contenido de un repositorio remoto y lo integra en el local.
• Push: Publica el contenido del repositorio local en uno remoto.
• Log: Examina el historial. Tiene diversos parámetros para personalizar el resultado de la
búsqueda.
• Tag: referencias a puntos en un histórico.
• Blame: Muestra principalmente el autor de los últimos cambios.
• Clean: deshace cambios del directorio de trabajo.
• Request: envía una solicitud de incorporación de cambios en caso de colaboraciones.
2.6 Estrategias de gestión visual

KAIZEN – mejora continua

LEAN – eliminar desperdicio
MURA – Discrepancia. Visibilidad del flujo de trabajo.
MURI – Tensión. Sobrecarga del trabajo.
MUDA – Desperdicio.

En los proyectos TIC, los MUDAs habituales son la burocracia, la sobreproducción, el multiproyecto,
las esperas, los desajustes de capacidad y los bugs.

KANBAN
Es una tarjeta con órdenes que indican cómo debe hacerse el trabajo.
Para trabajar con Kanban, usualmente usamos tableros de tareas, con trabajo pendiente, en curso
(limitado) y terminado.
Work In process son las tareas máximas que se hacen simultáneamente.
Work in progress es el trabajo que se está realizando.
Hay que limitar correctamente el WIP para evitar gente ociosa, falta de productividad, exceso de
demanda, más tiempo de respuesta, etc.
Los Sistemas de flujo continuo no usan sprints para empaquetar tareas.

SCRUMBAN:
- Establecer periodos de entrega.
- Cálculo de velocidades.
- Comunicación ágil.
- Usar los roles que plantea SCRUM.
- Añadir el concepto de WIP a nuestro tablón de SCRUM.
- Utilizar la pila de producto.
- Plantearnos si nos interesa la pila de Sprints.

Fortalezas del KANBAN:

▪ Favorece la comunicación directa, colaboración y resolución.
▪ Los problemas se detectan y no quedan ocultos.
▪ Regula el flujo y la carga de trabajo, exponiendo los problemas.
▪ Evita la ley de Parkinson.
▪ Desarrollo continuo.
▪ Gestiona el seguimiento y avance sobre “unidades de valor”, no sobre un sistema completo.

Leyes de Parkinson:

• "El trabajo se expande hasta llenar el tiempo de que se dispone para su realización".
• "Los gastos aumentan hasta cubrir todos los ingresos".
• "El tiempo dedicado a cualquier tema de la agenda es inversamente proporcional a su importancia"
(Parkinson la llamaba ley de la trivialidad).
2.5 Docker

Docker es un proyecto open source que permite empaquetar, transportar y ejecutar cualquier
aplicación como un contenido ligero. Es un sistema de virtualización que crea una capa de
abstracción con el SO.
El contexto de ejecución de la aplicación es un contenedor compuesto por un sistema de ficheros
con dependencias aisladas del SO, pero usando su kernel.

Es ligero, portable y aislante.

Conceptos de Docker:

- Docker file
- Docker Image
- Docker container
- Demonio
- Persistencia de datos

Dockerfile: Archivo de texto que mediante comandos, le dice a Docker cómo construir una imagen.

Image: son plantillas que contienen todo lo necesario para ejecutar una aplicación. Cada instrucción
de la file es una capa, de esta manera, si hay un error, solo afectará a partir de la capa afectada.
Contenedor: encapsula el contenido de la imagen. Se ejecutan de manera aislada, cada uno con su
sistema independiente de archivos, y son portables.
Persistencia de datos: Si al eliminar un contenedor, queremos conservar su sistema de archivos,
podemos usar un bind mount (carpeta montada compartida con el anfitrión) o un volumen (carpeta
de almacenamiento exclusiva para contenedores).

Para el uso de Docker conviene usar DockerHub, para los tipos de aplicaciones, Docker CLI para la
interfaz de comandos y Docker Desktop por comodidad.
Aplicaciones Multi-contenedor

Docker Networks: Comunica contenedores para que trabajen juntos igual que en una red real, con
IPs y puertos.
Docker Compose: Herramienta para definir y gestionar aplicaciones multi-contedor, usando archivos
de configuración YAML.

2.8 Validación y Pruebas

BDD (Behavior Driven Development)

Se trata de llevar a cabo pruebas y test para validar el resultado de las historias de usuario.
Hay que aprender a construir correctamente una funcionalidad (TDD) y que la funcionalidad sea
correcta (BDD).
Sus ventajas son la estrecha colaboración, centrándose y creando algo fiable bajo el control del
cliente; y las pruebas como lengua común de especificación. Se cumplen las necesidades de
usuarios, los desarrolladores tienen más confianza y los costes son menores debido a la
minimización de riegos por seguir el código.

Pila de enfoque:
Los criterios de evaluación de las HU deben seguir el modelo:

• Título
• Narrativa:
- <rol>
- <efecto>
- <propósito/beneficio>

Gherkin:

• Perfiles de negocio: entienden el entorno.

• Perfiles tecnológicos: entienden la tecnología.

Escenarios:

• Dado <escenario>
• Cuando <acción>
• Entonces <resultado>

Así, siguiendo la pila de enfoque se van construyendo pruebas en BDD, que es básicamente como
código. La herramienta más destacada es Cucumber.

DevOps
Prácticas de desarrollo de software y operaciones TI coordinadas que pretenden acortar el ciclo de
desarrollo y proporcionar entregas de alta calidad.
Es complementaria al desarrollo ágil (Agile DevOps).
Su objetivo es comercializar antes y adaptarse al mercado, manteniendo estabilidad y mejorando el
tiempo de recuperación de errores.
Integración y entrega continua
Es el proceso de compilar y probar código mediante pruebas automáticas con cada commit (control
de versiones).
Los sistemas generan artefactos implementables, incluida la infraestructura y las aplicaciones.

3 Clean Code

Code Smells es el término que usamos para aquellos síntomas que indican que algo no se está
haciendo de forma correcta en el código.
La deuda técnica es la producida por solucionar las cosas rápido y no bien, lo que tendrá
consecuencias en el futuro.

En consecuencia, habrá menos tiempo para nuevas funcionalidades por invertirlo en correcciones.
La falta de documentación ES deuda técnica.

El código limpio es algo vital, y sus métricas son:

• Defectos: debemos tener seguimientos de bugs.

• Calidad del código: referente a su funcionamiento, complejidad ciclomática, árboles, etc.
• Adueñamiento de código: en equipos grandes puede faltar comunicación y participación
sobre el código, causando deudas técnicas.
• Cohesión de código: buscamos alta cohesión y bajo acoplamiento entre las partes, para
facilitar las pruebas individuales.
• Puntos calientes: lugares en los que se hacen más cambios. Conviene revisarlos para posible
reingeniería o refactorización.
La refactorización debe ser un proceso cotidiano.
El código limpio permite añadir rápidamente nuevas funcionalidades, facilita la reusabilidad y
encapsulación, es simple y directo, específico y no especulativo. Contiene pruebas y es legible.

Principios SOLID:

• Single responsability: cada parte hace una cosa, el código es limpio y enfocado.
• Open/closed: cada parte debe estar abierta a extensiones y cerrada a modificaciones.
• Liskov sustitution: si A es subclase de B, podremos reemplazar B con A.
• Interface segregation: el cliente no debe depender de métodos que no usa.
• Dependency inversión: no deben existir dependencias entre módulos.

Cualidades del código limpio:

- No usa soluciones ofuscadas
- No es redundante
- Es agradable a la vista
- Puede ser modificado fácilmente por cualquiera
- Tiene dependencias mínimas
- Es pequeño
- Tiene módulos de pruebas
- Es claro y expresivo (nombres de funciones y variables, evitar comentarios salvables)
4 Diseño de interfaces de usuario

La experiencia de usuario (UX) es cómo se siente usar el sistema.

La interfaz (UI) es cómo se ve el sistema.

Principios básicos:

• Familiaridad: El usuario no debe aprender a usarla. Hay que usar estructuras y objetos
familiares.
• Consistencia: activación similar de operaciones similares, mismo formato en menús y uso de
comandos clásicos.
• Minimizar la sorpresa: El sistema no debe tener cambios bruscos y debe haber indicadores
visuales.
• Recuperación: seguridad en operaciones destructivas, opción de deshacer y checkpoints.
• Asistencia al usuario: feedback de errores, ayudas informáticas y de uso.
• Diversidad de usuarios: interfaz intuitiva, con atajos y adaptada a discapacidades.

La información debe estar claramente distribuida, simple y cómoda a la vista. Hay que cuidar la
posición y apariencia de los botones.
Las funcionalidades deben ser claras y los errores deben ser informados de forma concisa y
específica.

El diseño de UI implica tener en cuenta cómo la usará un usuario ajeno al desarrollo.

La usabilidad se mide con pruebas empíricas (pruebas) y relativas (en comparación con sistemas
similares.

8 Reglas de oro de Shneiderman:

- Consistencia
- Usabilidad universal
- Informativa
- Flujo y cierre
- Prevenir errores
- Deshacer
- Sentir el control
- Memoria a corto plazo
El diseño debe ser comprensible, limitando el tiempo de aprendizaje y los errores, pero maximizando
la velocidad, la retención y la satisfacción.
Los 10 principios del buen diseño de Dieter Rams:

- Innovador
- Útil
- Estético
- Comprensible
- Discreto
- Honesto
- Duradero
- Consecuente
- Respetuoso
- Minimalista
Otras cualidades:
- Ético
- Eficaz
- Pragmático
- Elegante
De Don Norman:
- Visibilidad: de ella depende que un objeto sea percibido y entendido.
- Retroalimentación: las acciones deben tener una reacción (auditiva, verbal, táctil, etc).
- Viabilidad: el propósito de los elementos de ser claro.
- Restricciones: limitar las opciones disponibles al usuario.
- Mapeo: localización correcta de los elementos.
- Consistencia: los elementos deben seguir un mismo estándar/modelo/guía.
- Confirmación: en las operaciones críticas.
De Niesel and Molich:

- Consistencia y estándares
- Visibilidad del estado
- Encaje entre el sistema y el mundo
- Control de usuario
- Prevención y recuperación de errores
- Reconocimiento sobre memoria
- Flexibilidad y eficacia de uso
- Estética y diseño mínimo.
- Documentación y ayuda.
Color
Aporta atención, memoria, significa y reconocimiento.
Es lo más influyente entre los factores visuales y ante la elección de producto.
El color afecta a la psicología, por eso hay que tener en cuenta su combinación y su armonía
mediante monocromía, colores complementarios (opuestos), análogos (vecinos). Pero hay que tener
cuidado con los colores potentes, saturados y oponentes.

Rojo: peligro, importancia, pasión

Naranja: Confianza, energía, optimismo.

Amarillo: Atención, felicidad. Combinado con negro.

Verde: Crecimiento, naturaleza, éxito.

Azul: Confianza, comodidad, relajación.

Púrpura: Lujo, creatividad, romance.

Rosa: Feminidad, inocencia, juventud.

Negro: Formal, sofisticado, poder.

Blanco: Frescura, inocuo.

Gris: Formal, neutro, sofisticado.

Marrón: Conservador, estable, tierra.

Proceso de diseño:
1. Boceto, define ideas y concepto.
2. Maqueta, presentación + profesional de ideas.
3. Implementación a partir de maquetas y herramientas.