Verificación, validación y diseño de interfaz de usuario

Transcripción generada automáticamente de FI-7669-Fundamentos de Ingeniería SF-77901-AN_ N3A0826 _FIS 05-1.mp3.

Resumen

La sesión cierra el tema de requerimientos y abre el de diseño de interfaz de usuario. Se distingue verificación (interna, ¿construimos bien el producto?) de validación (externa, ¿construimos el producto correcto?). La verificación se aplica a los tres artefactos: lista de requerimientos, historias de usuario (criterio INVEST) y casos de uso (objetivo medible, actores, precondiciones, flujos alternativos). La validación busca confirmar que el sistema satisface necesidades y expectativas reales, con el prototipo como técnica principal del obligatorio. Se repasan buenas prácticas: involucrar interesados, revisiones formales, separar identificación de errores de su corrección, matriz de trazabilidad, gestión de cambios, priorización por riesgo y múltiples técnicas. Se presentan técnicas de verificación (revisiones, análisis estáticos, checklists, análisis de trazabilidad) y de validación (prototipado, análisis de casos de uso, talleres, pruebas de aceptación). Luego se introduce interfaz de usuario (componentes, información y controles) frente a experiencia de usuario (percepciones y respuestas). Se ven tipos de interfaz, metáforas, tendencias (esqueumorfismo, diseño plano, neumorfismo), principios de diseño (visibilidad, feedback, limitaciones, mapeo, consistencia, affordance) y dimensiones (naturalidad, precisión, densidad de información). Se aclara que no todos los requerimientos documentados deben programarse en el obligatorio.

Puntos clave

• Verificación es interna (¿construimos bien el producto?) y validación es externa (¿construimos el producto correcto?).
• La verificación aplica a lista de requerimientos, historias de usuario (INVEST) y casos de uso.
• La validación se hace con el cliente; el prototipo es la técnica principal del obligatorio.
• Buenas prácticas: involucrar interesados, revisiones formales, separar identificación de errores de su corrección, matriz de trazabilidad, gestionar cambios, priorizar por riesgo y usar múltiples técnicas.
• Técnicas de verificación: revisiones, análisis estáticos, checklists y análisis de trazabilidad.
• Técnicas de validación: prototipado, análisis de casos de uso, talleres de requerimientos y pruebas de aceptación.
• Interfaz de usuario son los componentes e información/controles; experiencia de usuario son las percepciones y respuestas.
• Principios de diseño: visibilidad, feedback, limitaciones, mapeo, consistencia y affordance (percibida y real).
• Dimensiones del diseño: naturalidad, precisión y densidad de la información.
• No todos los requerimientos documentados deben programarse en el obligatorio; documentar ampliamente y luego negociar el alcance.

Transcripción

Vamos a ponerlo serio. Bueno, muy bien. ¿Adiós qué vamos a hacer hoy? Hoy vamos a cerrar por fin el tema de requerimientos. Yo, muy esbalanzado, mirese la puerta pensando que hay que inventar iluso. ¿Cuál es el siguiente? Y después vamos a hablar de diseño, de interfazio usuario. ¿Está? De hecho hecho acá tengo el cronograma, quiero conversarles un poquito. Muy bien. Entonces hoy tendríamos que estar empezando con el tema de objetivos y características de interfazio usuario. Eso tengo la corazonada de que va a suceder, pero tenemos que terminar la parte de requerimientos todavía y eso lo vamos a terminar hablando de verificación y eso y pasa factura. Y el segundo, porque si comen la industria, ustedes se lo solen saltar en el obligatorio y yo no entiendo nunca por qué. Pero ya me imagino que este no va a ser el caso. Entonces, yendo al tema, tenemos verdad verificación, verificación y variación. ¿Te parecen estas palabras o no? ¿Qué dicen ustedes? Sí. ¿Ustedes en la diaria las utilizarían como sinónimos? En la diaria sí, siendo específicos ¿no? Ok, ¿y para qué especificarías con eso? Y en realidad verificar es corregoral que usted correcto, validar ya es que cumpla, ¿No? Claro, ahí está, entonces nosotros no vamos a poder apoyar en dos palabras clave, digamos, y es que cuando estamos hablando de verificación en el contexto yía de requerimientos, verificación va a ser a la interna. Y validación hacia afuera. ¿Qué significa esto? Hasta ahora nosotros hemos visto, digamos, tres entregables o artefactos en todo este tema de la ingeniería de requerimientos. Vimos la lista pluralizada de requerimientos. Ese es uno, ¿verdad? Y esos requerimientos podían ser funcionales o no funcionales. Después teníamos historias de usuario y casos de uso que eran en especificación, ¿verdad? Nosotros vamos a poder aplicar este proceso de verificación sobre esos tres artefactos, sobre los requerimientos, sobre nuestra historia de usuario y sobre nuestros casos de uso. Y sobre todo el conjunto de requerimientos per se vamos a aplicar la validación. ¿Qué significa esto? Que en tema obligatorio digamos la verificación la van a hacer entre ustedes porque van a preguntarse a ustedes mismos si los requerimientos y la especificación se hicieron de forma correcta y luego contra el cliente ustedes van a preguntarse si lo que expresa esos requerimientos y esa especificación realmente satisface lo que se supone que tenía que satisface entonces la verificación ustedes se preguntan ¿cómo ¿Qué significa esto? ¿Qué de vuelta cobra una relevancia? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿Qué significa esto? ¿caban hacer. ¿Qué significa esto? Que de vuelta cobra una relevancia importante el tema de las entrevistas porque eso implica que ya tienen una persona con la cual hacer este proceso de aligación. Sí. Y si hablamos del tema obligatorio, ustedes tendrían que poder decir a través del proceso de validación recibimos determinado feedback. ¿Qué pasa? Que si le dicen no está todo divino, ese feedback no nos sirve. Me necesitamos un feedback de verdad. O sea que hablando un poco del obligatorio, en el momento vamos a tener que enseñar esto a que diseñemos a las personas que nos estamos y recibimos igual. Para los obligatorios uno tiene que hacerlo. Bueno, no te preocupes. ¿Para qué tan teoría? Y por eso era valioso tener la entrega de echarse. Pero bueno, no importa. ciertas cosas o para tomar decisiones de priorización también sirve. Por ejemplo, si ustedes identifican tres necesidades en el proceso de explorar haciendo entrevistas, ¿verdad? Y ustedes quieren entender cómo priorizar los requerimientos asociados a esas necesidades pueden hacer una encuesta. Del uno en diez para usted que aporta más valor, esto a B o C. Y cuando se tenga el resultado de esa enc esa encuesta a bueno la mayor porcentaje está en la opción b bueno vamos a priorizar ese pero no confundir con que la encuesta como tal va a ser una técnica de validación per se. La técnica de validación como tal que nosotros vamos a utilizar para el obligatorio es el prototipa. Sí, ah, vi como una cara de, de qué, qué, estamos de acuerdo. Hacemos un mock up de la app y eso que se representamos a la gente. Sí. ¿Qué pasa? Si ustedes entrevistaron personas que les plantearon necesidades o problemas o dolencias y ustedes van a aplicar un proceso de identificar requerimientos, modelarlos, revisarlos y especificarlos y que todo eso va a corresponder a un prototipo, usted le llega con el prototipo a la persona que entrevistó. Esto se parece a algo que solventa las necesidades que me dijiste. Sí o no, es por qué y ese va a ser digamos el feedback que ustedes van a tener que documentar. ¿Se entienden? Bueno, perfecto. Entonces, mientras yo me quejaba de que no venía nadie, ahora hay gente, pero no tengo la actitud de que viera. Pero ya vamos a solventar eso. muy bien Sí, muy bien. Después de recién haber terminado de licitar, o sea haber hecho la entrevista y obtener información distinta a fuente, justo después de eso, es que íbamos a analizar requerimientos que le íbamos a priorizar y todo eso, justo después de eso. Recién después de eso íbamos a poder especificar a través de dos formas podemos especificar cuáles eran. ¿No recordamos? ¿Cómo nos hemos acordado? Eso es lo que identificábamos cuando analizábamos y después de que teníamos los RF y los RNF, los casos de uso eran uno y los otros eran… Ahí está, perfecto. Ahora que tenemos especificado el comportamiento del sistema a través de usuarios y de casos de uso, vamos a entrar en la etapa o actividad de validar que aquí estamos hablando un poco de la de las 2b que es verificario de la vida entonces qué nos interesa abordar acá definir cada una que un poco el hicimos pero lo vamos a ver como un poco más de profundidad objetivos y buenas prácticas que ya les aviso que esto va a ser un poco hacer un highlight de lo más importante pero van a tener que llevarse un poquito de lectura a ustedes porque necesitamos avanzar y luego vamos a ver técnicas de verificación y validación que acá si les pido o sea yo les pido que me presten atención toda la clase pero acá justo acá cuando empieza a hablar de esto, capas, capas, capas, hay de gente en el celular. ¿Por qué? Porque quiero que quede claro para el tema obligatorio porque generalmente piensan que tienen que verificar una cosa sola y tienen que verificar 13. Muy bien. Entonces verificación como les comentaba anteriormente es una actividad que se hace así adentro en la internet del equipo. Y aquí nos preguntamos si estamos construyendo el producto correctamente. ¿Qué pasa? Que si recordábamos ciertas conversaciones que tuvimos antes cuando la damos de CCM, llegamos a la conclusión de que la documentación era parte del producto. Entonces preguntarnos si estamos construyendo el producto correctamente, implica que nuestros requerimientos y la especificación de esos requerimientos estén hechos bien. Ahora, le hago una preguntita. Primero, me voy a hacer una pregunta de si o no, me voy a responder si o no. Nosotros hasta ahora vimos características que podían tener los requerimientos para poder decir que eran de mayor o menor calidad. Sí, no era que tenían que ser rangiles no…escalables en el tiempo. Ajá, ¿qué más? Algo de la nonvigüedad puede ser? que como es importante que suceda, tendría que haber una especie de instancia en la que el equipo como tal, si hay esas preguntas. Hay determinadas formas de aplicar esto de la verificación, pero siempre teniendo presente que tenemos que preguntarnos si estas características se cumplen o no. Entonces, no podemos verificar nada si no sabemos qué características estamos buscando. Por eso tenemos que tenerlas presentas. Ahora, de los casos de un sonor, pero de las historias de usuarios no se acuerdan de algo que hablamos, que nos permitía ver un poco qué tan prolija o no estaba hecha la historia de usuario o qué tanto cumplía con ciertas características de calidad? Era un acrónimo en el estilo de spoiler. No, era de investe. Exactamente. Entonces, ¿qué podemos hacer para verificar nuestras historias? Preguntarnos. Cumple con la ID de investe. Cumple con la N de investe. Y así sucesivamente. Con los casos de uso, nos vimos algo puntual, pero hoy se los voy a presentar. ¿Qué es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es recordemos separar una cosa son los requerimientos declarados y priorizados y otra cosa es la especificación de esos requerimientos que allí ya estamos hablando de casos de uso y de historias de usuario, son tres cosas al final lista de requerimientos y la especificación que se componen en otras dos, historias de usuario y casos de uso, ¿cuántas cosas son? En contraparte, la validación es la actividad hacia afuera y es un proceso que consiste en el que nos podamos asegurar de que el sistema cumple con las necesidades y expectativas del usuario final. Entonces, ¿qué pasa? Supongan que ustedes están verificando. Vamos a salirnos un poquito del contexto del software. Vamos a verificar si horneamos la torta de chocolate perfecta con los gistandres que se supone que tiene que ser entonces tenemos un almibar y el bizcocho está húmeda si perfecto esto lo cumple tiene ganas de chocolate si perfecto lo cumple tiene algún citricote corte con el exceso de ulcer si perfectple. Bueno, perfecto. Verificamos que lo que hicimos lo hicimos bien, ¿tá? Pero luego entregan la torta. ¿Tá? Pero yo quiero una torta de vainilla, no quiero una torta de chocolate. O sea, todo bien con que sea la mejor torta de chocolate, pero a mí no me gusta el chocolate, o sea, a la rica me voy a morir, así que no me sigo. Majo menos esa, digamos, es la clave que acá la presentamos como objetivos de negocio. Entonces, ¿qué pasa? Que si al final ustedes se inventan los requerimientos y esos requerimientos no nacen de una necesidad real puede ser que hayan hecho unos requerimientos divinos, unos casos de uso divino con el historio de usuario divino, pero después lo van a olvidar con un cliente o con una persona que hayan entrevistado y le va a decir, si está divino, no Si ustedes creen que yo veo alerta esta tabla, están equivocados. Eso no va a suceder. Pero, pero, hay dos cosas que si van a suceder. La primera es que se le tienen que estudiar porque puede ser una pregunta o cuestionaria acá. Y la segunda es que vamos a tratar de tocar un poquito lo más relevante. Cuando la voy a verificar los requerimientos, por lo menos, identificar errores en consistencia en la especificación es más clave ¿Por qué? Porque precisamente como es el insumo que va a tener el programador para empezar a codificar la solución nos conviene que sea claro para evitar ida y vueltas que impliquen retrabajo y perdida de tiempo. En la validación hay dos cositas que están buenas tener clara. La primera es esta de que los requerimientos sean realistas y factibles, que eso lo lavamos un poco el otro día. O sea, está todo bien con que el requerimiento esté especificado con las mejores prácticas del mundo, por si me estás viendo construir una máquina de tiempo, no puede suceder porque no es técnicamente factible, porque nadie sabe hacerlo bueno o que bajan gente que sí nosotros no sabemos bueno no importa y lo otro es confirmidad que los requerimientos documentados reflejan la necesidad y expectativas reales y que pasa que si esto no sucede hay que plantearnos la pregunta de que pasó o sea porque llegamos a la conclusión de que teníamos que hacer torta chocolate cuando nos pierden una torta vainilla hasta acá tenemos alguna punta pueden aprovechar para encajar junto al obligatorio eh pero que sea de esto sigue siendo obligatorio ojo que esto sigue siendo obligatorio uno, por las dudas. Bien, uy. Resumiendo, tema de buenas prácticas. La primera sería involucrar a los interesados correctos, realizar revisiones e inspecciones formales, separar la identificación de errores de su corrección, crear una matriz de trazabilidad, gestionar los cambios de requerimiento, priorizar las BIB basada en riesgo y utilizar múltiples técnicas de validación. Entonces, antes de las técnicas de la edificación, vamos a hacer un pequeño zoom en esto. Me interesa leer un poquito de esto. ¿Ustedes se acuerdan que cuando hablábamos de CCN, un poquito les pregunta qué era trazabilidad? ¿Tener un histórico, ¿no? ¿Y adivilen quién entra en juego allí. Las necesidades. ¿Cómo? No, no, no, la quería matriz y decirme, no. Claro, es que la matriz se construye sí, pero teniendo los requerimientos y enlazándolos a las necesidades puntuales que van a solventar y por eso es importante hacer la licitación primero. Ojito con esto que hice acá, de separar la identificación de errores de su corrección. ¿Qué pasa? A veces nosotros nos sentimos bastante tentados a ser sumamente productivos ¿Verdad? Entonces ¿Qué pasa? Que en este proceso de verificar los requerimientos que identificamos y verificar las especificaciones que diseñamos con las historias de usuario y los casos de uso, encontramos que un error, vamos a irlo reclamos de vez. Y no es lo más conveniente al final del día porque vas perdiendo el foco y la capacidad de identificar en consistencia se va perdiendo. Entonces, ¿cuál es la sugerencia acá? Hacer una sesión, empezar a hacer la auditoría de estos requerimientos y de las especificaciones y dejar el registro de los hallazgos y posteriormente tener un plan de cómo abordar las correcciones. Pero no juntarla. Es algo así como en las lluvias de ideas. No. Si estás haciendo una lluvia de ideas, no. No trates de definirse la idea sumo o no antes de tirarla. Vos tiras la idea y siguen tu flujo de tirar ideas que ya habrá un momento para clasificar entre ideas que nos aportan y ideas que no nos suman. Pero separar las instancias, no hacer las dos cosas juntas porque al final se va a incoter el proceso cognitivo en el que generamos las ideas. Eso por ese lado. Es importante también gestionar los cambios de requerimiento. ¿Por qué? Porque al final si nosotros estamos con esto de validar y al validar se resulta en que tenemos que hacer ajuste en los requerimientos que hemos identificado, tiene que haber un mecanismo o proceso en el que nosotros digamos el requerimiento RF005 va a cambiar y va a mutar a este por el feedback que recibimos y tener digamos el respaldo de lo que sucede allí porque si no al final del día nadie va a saber qué producto se está construyendo y eso termina siendo costoso al final bien esto lo leemos y ¿Qué vamos a ver cuál corresponde más a cada cosa. En general, en general, no apuntando todavía a ninguna, tenemos revisiones y análisis estáticos. Revisiones en una instancia en la que en efecto se estudia los productos que ya se generaron para identificar las cosas que se tengan que corregir. Son efectivos, pero pueden consumir mucho tiempo. Y por otro lado, tenemos análisis estáticos, que son herramientas automatizadas que hacen esa lectura por personas y van generar un reporte. Existe software especializado para eso, sí. Y hoy en día también tenemos herramientas de guía para llevar a cabo esta tarea. Luego tenemos la lista de verificaciones a Checklist que es básicamente todas las preguntas que nos hicimos anteriormente, verdad, bien sea para los requerimientos, bueno, es atómico, es ambiguo, es claro, tiene una única interpretación, todas esas preguntas se convierten en artefactos de Checklist y son las que se llevaron a cabo en un momento de generalidad. Y también está la analiza de trazabilidad. Generalmente, esto también se puede automatizar y es básicamente asegurarnos que los requerimientos tienen un origen y el origen es, por supuesto, una necesidad. Cuando tengamos la responsabilidad, hablamos de la especificación, requerimiento y la solución. Correcto. Ahora, ¿qué tenemos acá? Ya que estamos hablando de verificación para requerimientos, que es el primer elemento de lo que hablábamos, la lista de requerimientos como tal. Esa tablista que ustedes tienen que dice RF-001, el sistema DBET, bla, bla, bla, bla, prioridad most. Y esa lista que sigue, bueno, ese artefacto, esa lista es la que vamos a verificar con este checklist que tenemos acá. Fíjense que las tenemos categorizada en cuatro. Tenemos completitud, trazabilidad, correctitud y consistencia, verificabilidad y no ambigüedad. Y cada categoría tiene sus preguntas. ¿Ustedes lo que tienen que hacer es tomar esto y preguntarse si cada uno de esos requerimientos cumple con esto? ¿Es un trabajo o un ligero? No. La verdad que no. Ojito con algo. ¿Cómo digo esto? Bueno, prepárese porque aquí viene el momento del vacío legal. Ya que es donde te da provecha los vacíos legales. Pero… Que ustedes apliquen esta lista no es una camisa de fuerza a que absolutamente todos sus requerimientos cumplan con todo. ¿Qué significa esto? Que a mí me encantaría que todos sus requerimientos estén perfectos, pero el saber que en equipo identificaron cosas que no estaban bien de los requerimientos también me dice cosas. Entonces, si no todo lo requerimiento, a que voy con con esto sino todos los requerimientos están perfectos pero ustedes ya lo identificaron y lo transparentan está perfecto van a tener buena nota y a este punto emocional escala pero si en la verificación dicen que está todo divino y yo me di cuenta que en este todo divino bueno pas, pasan cosas. ¿Hasta acá se entiende lo que hay que hacer? Sí. Sí. Sí. En el momento de verificar si nacemos esta tabla y eso nos daba las preguntas y encontramos algún clara querimiento que la Bachel no cumplía con todo eso. ¿No es tal vez lo mejor? ¿Sagado de la especificación? No. No. Porque igual están más dando el requerimiento y no tanto en la especificación. En la especificación va a pasar lo mismo. Igual. Pero cuando le están haciendo se van a dar cuenta que no van a tener tanto tiempo. Entonces, a lo que voy es, si señalan las debilidades, estamos bien, no va a perdernos. Ahora venimos con la verificación de casos de uso, que esto sí es un poco más nuevo porque nunca hablamos de cómo verificar un caso de uso ni qué características tenía. Entonces, por eso lo voy a leer. Fíjense que hasta ahora venimos hablando de dos listas de verificación. de de uso describen la interacción actor-sistema, ¿cierto? ¿Qué pasa? Que a veces cuando tenemos muchos pasos en común entre casos de uso, nos empezamos a confundir y pensamos que nos podemos untar todos algunos solos y al final termina siendo un caso de uso que describió más de un objetivo. ¿Sí? Porque supongamos una aplicación web para el cine, para ir al cine. Entonces, la opción para comprarlo es snacks, requiere que haga login primero y también la opción de comprar entrada también requiere que haga login. Entonces hago una sola tabla y ya llegó las dos cosas. No, pero ahí estamos hablando de dos cosas diferentes. Son dos objetivos y ahí el caso de uso no está bien planteado. Que de hecho, si vieramos los diagramas de caso de uso esto es mucho más fácil de verlo, pero bueno no es el caso. ¿Es tu objetivo un resultado medible para el usuario? ¿Qué significa medible para el usuario? Que el usuario logra un objetivo. Entonces si al final de un caso de uso el usuario no logra un objetivo, entonces no es un caso de uso, le faltaron, si? Porque un caso de uso, bueno, imprimir un reporte, el usuario empezó y obtuvo un reporte. Ahora, si hago un caso de uso navegar, navegar en la web, el usuario se echó para adelante antes el usuario echó para atrás listo y y y qué pasó ahí no estamos hablando de un caso de uso y bueno preguntarse qué es lo que participa que tiene una secuencia lógica en los pasos es el nivel de extracción de las transacciones adecuado para el caso de uso eso quiere decir que no se vayan de mambo y hagan algo demasiado complejo que seguramente se puede descomponer. Y aquí continuamos con esas preguntitos. Fíjense que se preguntan si se documentan todos los posibles cursos alternativos. Entonces, acabo con esto, no crean que bueno, más poner un flujo alternativo y ya y cumplimos, no. Porque si yo identifico a qué podría pasar esto, esto y esto, esto, puede que tengamos una conversa. Preguntas hasta acá, no? Perfecto. Y como les había hecho spoiler anteriormente para verificar las historias de usuario, y vamos a hacer las preguntas de si cumplen con el criterio de investe. ¿Se acuerdas que significaba cada una de estas palabras, no? ¿Tienes de inscripción? tenemos revisiones que pueden ser entre pares o simplemente hacer un recorrido por los requerimientos. Y aquí ahora vamos a empezar a hablar sobre las técnicas de validación. Tenemos prototipado, análisis de casos de uso, talleres de requerimiento y pruebas de aceptación. ¿Qué pasa con las pruebas de aceptación? Que a veces el usuario no termine de entender si es una prueba aplicada a requerimientos o al sistema como tal, pero se puede hacer en amas. Igual eso más adelante en el Unidad de Test, vamos a ver el modelo en B y lo vamos a estudiar mejor. ¿Está la análisis de caso de uso en el que literalmente se le lleva al usuario la descripción de los casos de uso. ¿Por qué? Porque como muestra la interacción entre el actor y el sistema, bueno, un poco lo puede visualizar. Pero si nuestra intención al final es visualizar, nos conviene aplicar un prototipado. ¿Qué es la creación de modelos e simulaciones de este sistema? También tenemos modelos de simulación, pero bueno, esto, digamos, que nos aplica para todos los sistemas y cuando queremos definir comportamientos y que también tengan que visualizar de cálculos y cosas por el estilo, aquí es cuando este tipo de técnicas nos puede servir un poco. Aterrizamos el prototipado. ¿Qué técnica vamos a utilizar para validar en el oligotorio? de ¿Qué vamos a hacerciado de que era? igual cuando usted es la plasmen como tal en el obligatorio es algo que no no hace como demasiado notorio pero lo van a vivir cuando vayan a especificar esos requerimientos como equipo se van a poner acuerdo y va a entrar una conversación y ahí es donde se va a poder verlo de negocio muy bien entonces miren lo que vamos a hacer aguarduarde línea por favor. Por supuesto que lo voy a poner ahora. Y voy a hacer gordito. AguardeE por favor. ¿Te acuerdes del enunciado del gimnasio? Igual que tengas hablas, lo pueden abrir de vuelta cuando necesitas. Sí, vayan abriéndonos. de la ¿Puedo irte? No, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no ¿De qué? pero si no nos podemos hacer cosas dicen que la clase es aburrida que lo único que hacemos es escuchar este hombre delirando y hablando sin parar. ¿No está que buena secuencia? Sí, que buena secuencia. Al contrario, yo espero que digan. No, que buen profe, de un tema tan teórico, ¿Busca la forma de de hacerlo más dinámico? Así. No sé, me, me, que culo que podría pasar eso. A ver. ¿Puede hacer más algo de la que? No, los cuestionarios de usted se aburren. No, el cuestionario que se aburren. Los cuis. Los que? Los cuis. Bueno, puede ser que haya un cuis más tarde. No, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no ¿Pero qué? de que estén desarrollando cada punto y se iban a decir bueno, se detectó tal, tal, tal, tal, tal, de una forma un poco más general. No van a tener que no van a tener que hacer un un desarrollo de algún párrafo por preguntas, por requerimientos, porque imagínense sería sería mucho. Muy bien. Muy bien. Bueno, muchas gracias a Misimo. Seguimos con Luca. Comparto o te iros comento? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿ No, porque básicamente no están numerados por… Dice funcionan lo funcional, pero no en sí mismo no pueden ser referenciados desde otro. Por otro lado… Bueno, lo mismo. Se referencia correctamente los requerimientos entre sí, como no tiene idea, no pueden referenciarse, pero tomándolos con el nombre, aunque uno hable de guardar información y el otro de guardar ciertos datos. Que por… Como se llama, es un pre-requisito del otro, no está nombrado como precondición tampoco ni aún en el mal formato de esta tabla, así que tampoco lo cumple y si pueden ser referenciosos hacia su origen, nombre de que el usuario puede guardar, poner sus datos a la app, qué datos que usuario no da absolutamente ningún contexto, los endanguenses pueden hacer ejercicio para los clientes leyendo la letra yendo al punto específico, habla de crear rutinas, asignarlas, ejecutarlas, acá ni por asomo se da a entender esas cosas, se habla, son contextos tambagos que en sí mismo no bajan los requerimientos y tampoco se puede saber qué es lo que se quiere. Se guarda información. De alguna forma habla de que no se sabe sobre qué hacia dónde quiere ir o qué es lo que se precisa simplemente es un deseo tirado al aire sin nada específico. La expresión de "teo tirado al aire" me sumó muchísimo. Así con todos, o sea, todos están tan poco desarrollados en sí mismo en la idea de qué es lo que se quiere lograr por lo cual están totalmente mal definidos. Perfecto. Bueno, Jonathan, ¿qué tú también tragaste con trazabilidad? No sé si coincides con Luca o hay alguna cosita más o menos. Sí, sí es que me ag grandes rasgos si, no se si quieren que exponga o… No, te buscas si. Tiene delanco. Luca después compartía el toque. Le estaba mas calito para que me sonó. Ahí va, ahí va. Está bueno, si más o menos eso no, este por ejemplo puede… Hay que prolifar. Por ejemplo no haber requerimientos de que datos registrarme y nada, no puedo decir que puedes ser identificado de forma única. La que funciona en cualquier parte no hay un contexto del por qué se podría conectar con otras cosas, tampoco ni cómo ni a qué. Para que la plataforma sea bonita y fácil se debe comprender qué concepto se tiene por eso, de qué forma medible. Bueno, se referencian correctamente los requerimientos entre sí. Bueno, por ejemplo acá puse que al especificar que sea bonita y fácil, rápida y segura y de funcionar con internet no se establecen ni en qué modo los empatizan y por lo que no hay correlación tampoco. Tampoco sí, ahí se correlaciona cómo el usuario guarda los datos ni cómo los entrenadores especifican ejercicios. Y vas a darle un un párrafo como analizando todo junto pero no me dio tiempo. Puse la serie. Pude cada requerimiento se ha referenciado hasta su origen alguna necesidad de los stakeholders. Bueno no hay un planteo general de por qué surge la necesidad de hacerlo ni se especifica una estanda para llevarlo a cabo. Y acá la cual puso Lucas yo puse pareciera que fueron escritos en bruto desde los solicitados. ¿Qué es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que de lo que me dice la persona a la que estoy entrevistando o mi fuente de información. Tiene que haber un proceso que transforme esas dolencias o esas deseos de eso minúe problema en requerimientos técnicos y profesionales, que es lo que ustedes van a hacer. Entonces fíjense que que valioso que ustedes mismos lo lo señalen de esa forma. Me parece que está muy bueno. Bueno, muchas gracias, Jonathan. No continuo con Maximiliano. Tengo un tequiste pelado, pero si quieres. No, dale, dale, dale. No estamos compitiendo. Me mostrarás dos segundos, Profes, la tablita, ¿no? Que borré la cautera. Por lo menos para que me comparte. Mientras la comparto la comparto la tablita de los requerimientos no la que estaba ahí esa ya te saco de la captura que ya comparto ¿Te compart primera, no especifica qué dato, ni en qué pantalla pantalla, la segunda que tiene múltiples interpretaciones, hacer la rutina físicamente o que le ingresa al sistema y así básicamente con dos sitosas que la tercera el término de una forma es como que no se verifica nada y carece de precisión técnica y respond Y, está, responde, revisión o análisis. ¿Y entendemos que no? Puesto al final la pregunta y ya la corré para arriba porque me parecía que ya si partía de esa base no iba a poder cumplir con ningún de los otros requisitos como que tenía que estar bien desarrollada y específica en ese sentido. Ahí va, perfecto, muchas gracias Max. Bueno, vamos con este vano. Muy bien, con plenitud. Para, pero no te puedes subir a la sala capaz? de ¿Ustedes quieren que comparte pantalla o les basta con que lo lean? ¿Qué? Bueno, entendiste eso de la clase pasada. No, no, no. La consiguen a la mandar la pregunta por Tims. Ok. Está, decirle. Ok. ¿Se encuentran los requerimientos correctamente priorizados? No, no están priorizados. No, mirá, los ellos, mío. Ok. ¿Son todas las clases de usuario identificados y sus características descriptas? No. Los usuarios, sé, si están identificados, pero no todas las características necesarias. Claro, si yo, pero yo si yo tengo esto que te detenga y yo te detengo. Bueno, respeta la especificación, la estructura y apartados de estándar, ¿no? ¿Aplica? ¿Qué, qué, qué pusieron? ¿Qué pusieron? Ah, que no aplica a un estándar de ningún tipo. Pero me teléfono, hijita, sin un cuaderno. Es que lo tengo todo desordenado, le dije. Se identifican y describen las dependencias con otro sistema. No, se identifica que debe ser compatible con otro sistema, pero no como y no se describe. Está toda la característica de calidad tenías en cuenta en la especificación. Yo puse que sí la requiere de ser segura, rápida, agradable, bonita y ser funcional en cualquier lugar. Ok. Ok. Muchas gracias. Despide a tus compañeros. Cho compañero, hasta la próxima Ahora, ¿ustedes creen que es probable que alguna de estas preguntas se responda de forma negativa? Por lo menos uno, de una lista de requerimientos. O sea, es como bastante complejo tener presente todas estas preguntas y definir un requerimiento que quede el perfecto a la primero, ¿no? A lo que voy es, el objetivo que tenemos nosotros de darle gest este o transmitirle gesto es primero no subestimar el trabajo de identificar requerimientos y el segundo todas estas preguntas se hacen por el bienestar del proyecto y en el caso más particular que es el de ustedes en el obligatorio pueden puede bienestar de ustedes mismos también. Porque al final ustedes van a implementar esto. Y nos van a hacer preguntas que nosotros no vamos a responderles porque esto hicieron ustedes. Entonces, vamos arriba, vamos a tratar de que esto salga bien. Yo iba a hacer algo parecido a lo que hicimos ahora con esto, pero… zafaron. Que después de hace que… - Profes, consulta. Los… - Sí, Dios. -…requisitos funcionales, sí. - No, y me alegra mucho que traigas esa pregunta. Repito la pregunta porque había posado la grabación y esto creo que es que grabó. Pero me preguntaste si básicamente todo lo que vayan a definir como requerimiento lo tendrían que programar para el WD2. Esa era la pregunta ¿no? La respuesta es no. Y esto es una invitación a que no se limiten. Si, o sea por ejemplo si ven requerimientos de un actor pero eso no lo vamos a programar así que no lo no identifiquenlo y documenten lo igual porque es parte del análisis que ustedes hicieron después ustedes mismos van a definir el alcance lo van a negociar con nosotros pero no es que si identificaron 200 requerimientos los 200 requerimientos lo van a programar o sea no vean el documentar requerimientos para el obligatorio 1 como un azogal cuello que se hace ustedes mismos para obligatorios porque no es así va a funcionar así. que en el día de la entrevista se acortó a eso. Ustedes amplien, amplien, amplien que esto oligatorio es para ese y el oligatorio es para programar, no todo eso. Perfecto. Perfecto. Pero se va como se duda a nivel general en desarrollo en general, porque en este caso se da como que para desarrollar para un cliente pero en el caso que vos necesites que el producto se testee y ese testeo en sí lo tenés del lado del cliente como que las entrevistas no existirían vos lo que tendrías es un feedback de lo que de los que usan tu aplicación o no. Depende de la etapa en la que estés pero la entrevista en algún punto inicial punto inicial del proyecto, si lo tienes que tener, por más que el usuario lo vaya a testear, porque entonces ¿qué va a testear? Algo que te inventaste vos, entonces el margen de error ahí se vale infinito. Pero vos decís que todo desarrollo tiene un público objetivo. Claro. Bien. ¿En qué caso crees que no? No, desarrollo científico, cosas así más abocados a la ciencia, ¿no sé? El proyecto que no tengo entrando con desarrollo huevo. ¿Cómo ha sido el desarrollo científico? Claro, cosas que sean más funcionales que otra cosa, no tanto que tengan que interactuar con un público. Bueno, pero si por lo menos con un desarrollo científico te refiere a software envibido para ciertos dispositivos, al final tiene que haber una relevasión técnica para saber los componentes de hardware con los que se soador de la actual. Esa entrevista en ese caso sería con profesionales del área, ¿no? Claro. Y que tú te podres pensar, bueno, pero si ya sabes lo que vamos a construir, ¿qué tanto? Bueno, pero puede ser que sea un tercerizado que hace el software y otro tercerizado que hace los componentes y se tienen que poner de acuerdo entre ellos. Pero el amor al arte no lo hace nunca. Pero sí, más allá del software todo producto tiene un público porque para alguien se hace un producto porque si no estamos tirando pelotas al aire no más. Si, así la pregunta viene más por el lado de que el estándar lo pone cliente, ¿no? Y el alcance del producto lo va a definir cliente siempre. O, estándar es una cosa y alcance es otra. Y también ¿qué pasa? El cliente te puede dar un alcance imposible de cubrir y es como tenemos que empezar a darle procesos, entregas, iteraciones y todo eso, aporta valores tiempos tempranos pero por pedacitos, entonces no es tan absoluto, o sea no es tan absoluto de que el cliente tiene razón y lo que el cliente puede utuquiamen, o sea hay ciertos intercambios, fíjate que también hay las más requerimientos y una de las características que nos importa, que comprar los requerimientos es que sean factibles y ahí el tema de la factibilidad tiene mucho que ver también. Bien. Buena, buena, buena conversación filosófica. No lo es mismo. No, lo que pasa es siempre lo veo plasmado, la PPT, profe y como que se me hace ruido que esté tan formalizado algo que de repente es una entrevista del día a día, ponerle en trabajo o cosas así, entiendes. Víjate que eso… Ahora, para analizarlo un poco. Igual, fíjate que eso también depende mucho del contexto del proyecto, de la cultura, del equipo, del producto, porque capaz hay cosas que son más del día a día, ponéle, pero estamos hablando de un contexto un poco más volátil capaz o estamos hablando de un proceso más inmaduro también. Porque cuando empezan a ver el tema me pareciamos un tema burocrático de otra cosa, como que tienen que cumplir con esto, esto y esto por un tema de documentación y ciertos parámetros que hay que cumplir entonces. de y sino que también estas preguntas tienen que ayudarnos a construir las cosas que van a ser el insumo para programar de una forma correcta y que alivie dolores y no que los genere. Entonces, al final, ustedes se llevan un marco teórico denso y con criterio lo adaptan al contexto en el que estén. ¿Qué es cómo los procesos? No existe el proceso de desarrollo perfecto. Existe el mejor proceso que haga mejor fit con el contexto y la realidad de ese momento para ese proyecto. Y lo mismo pasa con esto. No, de nada, cualquier cosa me dice, es que esta charla me dijeron. Bueno, interfaz usuario. Ya casi hemos averustrad, que estoy seguro que muchos van a estar contentísimos, ¿eh? Bueno, interfaz y usuario. Voy a hacer una pregunta divertísima. ¿Qué es interfaz y usuario? -Yo le permití a la usuario integrar. -¿Con qué? que que vamos a ver interfaz de usuario, experiencia de usuario tipo interfaz de usuario, metáforas y tendencias de diseño principios de diseño y dimensiones de diseño entonces en palabras un poquito más formales es el conjunto de todos los componentes de un sistema interactivo interactivo porque claramente hay un intercambio verdad que provee información y controles para el usuario para lograr una determinada tarea en dichos sistemas. Fíjense que provee información y controles, o sea, no solamente es el medio, sino que provee cierta información también. ¿Qué es sistema interactivo en este contexto? La combinación de hardware, software, servicios, personas con las que los usuarios interactúan en orden de conseguir un objetivo y la interacción de usuarios y sistemas que es intercambio, que ya venimos a hablar, ¿verdad? Esto interfazan. Entonces, "componentes" es la palabra que se nos viene a la mente cuando hablamos de interfaz y usuario. Ahora, cuando hablamos de experiencia de usuario, ya hablamos de percepciones y respuestas del usuario que resultan del uso de un sistema, producto o servicio. Entonces, la interfaz de usuario es los inputs, los componentes, los labels, los botones. Y la experiencia de usuario es esta página me está tardando mil horas de cargar y yo ni siquiera subir esta tarea ya. No quiero matar. Esa es la experiencia. Entonces mientras que la interfaz no es el vehículo para poder darle nuestra información a cierto sistema para poder obtener algo, la experiencia es todo lo que sentimos cuando eso sucede. Por ejemplo, cuando yo estaba comprando las entradas para el "eras dur" me quería matar porque ese muñequito no avanzaba más y a pesar de que los componentes del interfaz estaban propiamente dispuestos y todo eso, no estaba obteniendo información que me aliviar un poco la ansiedad. Entonces la estaba pasando terrible a pesar de que la interfaz estaba bien hecha. Entonces eso nos ayuda un poco a marcar esa diferencia. Entonces, interfaz de usuario es pasión de se producen las interacciones entre humanos y máquinas y la experiencia de usuario, todos los sentimientos y percepciones asociados al uso de una interfaz de usuario. ¿Alguna vez alguien tiene algún rec. ¿Qué más? ¿Qué más se le ocurre? A ver, ya leí mi trago personal. En Aulas, o tenés que poner el Autidicator. Me asesino. Tenés que poner el S6 número, la contraseña. No, pero ahí puedes usar aplicaciones para autenticar. Se la ponemos fácil. Cuando defectúas una tarea que hay algo en la aplicación y no te damos mensaje con firmación a veces, se sale y no te dices si se envió, si se guardó, si está todo bien. Saben que también hay un tema de las cosas que ya uno espera que sucedan por convención, ¿no? Por ejemplo, ¿qué me mí? Yo no necesitaba bloquear un número en mi teléfono. Entonces, ¿qué pasa? Que yo voy a settings, más por lo privacidad de seguridad, contactos bloqueados y ahí te sale el control para ingresar el número y hasta que ingresar el número ya te sale un botoncito que dice bloquear contacto pero te sale desactivado y bueno si es obvio si no ingresas el número no va a estar habilitado perfecto entonces vos ingresas el número y que esperas que suceda que se habilite claro vos termina de escribir el número y el botón desaparece y le tienes que dar enter para que aparezca otra vez el botón pero que dore media hora tratando de bloquear el número y le toque a plantechas de pt me sentí mi padre no anciano me sentí no podía no puede ser yo no da bascaritos que no podía bloquear un número de teléfono Otra cosa que ahora me vino realmente, por ejemplo, la web de la D.K. Si vos entras para, especialmente, que esa es una de las de Tiene un título arriba pero no sabes a dónde ir. Hay un todo agrupado. ¿Y ahí te sientes? Estrés porque no… Tienes que leer todas. Todas, todas, todas. ¿Cuál es la que me estás buscando? Mira. Estaba muy aca, grabada, fuego. Intentaron ingresar a Discord desde el celular, una pelotúe. Errela, contraseñe, me saltó el error. Tipo, cocos en correita. Estuve casi una hora probando contraseñas hasta que me di cuenta que el error en un momento cambió y pasó de ser contraseña incorrecta a ingresar el código de verificación o verifique desde el mail pero con el mismo color de error entonces tipo nunca lo leí porque nunca tuve un input visual de que había cambiado error de contraseñas y me quedó grabado fuego y estuve en 40 minutos lo mismo mismo, me sentí una vieja, pero… Claro, de repente me llama y re-en, no, tremendo, tremendo. Sí, esas cosas pasan y es loquísimo porque al final del día podemos evitarles que malestar a las personas con una decisión de diseño un poco más acertada. Y ese es un poco lo que vamos a tratar de hacer ahora. Bueno, creo que tengo clara la diferencia entre la experiencia de la InterFace. Pero bueno, en la InterFace vamos a tener una entidad con guía de estilo, un diseño visual, colores, bocetos, tipografías, pero en la experiencia de usuario ya nos implica la arquitectura, la información, las características, definir usuarios y necesidades. Y qué pasa? Que si ustedes recuerdan, una de las técnicas de situación que era la user persona tiene una parte de frustración y cosas de ese estilo. Y justamente ese tipo de input que en las viser personas la podemos abordar muchísimo con la experiencia de usuario hay que tener ojo con eso incluso la propia accesibilidad que era lo que hablamos no sea supongo que estamos hablando de un sistema de un sistema de control dimentario para la gente que trabaja en tiendas tipo renner o algo así entonces que tienen que tener la tabla y poder buscar y no lo han puesto Y la disposición en la que me voy a mostrar la información. Entonces, esas cosas que son pequeñas, no son requerimientos funcionales necesariamente, pero aportan un valor tremendo al final del día. Tenemos un pequeño diagramita que nos habla de los objetivos de la usabilidad. Lo más importante siempre va a ser tener un uso eficiente, un uso efectivo, seguro de usar, buena utilidad, fácil de usar y fácil de recordar. Esto que está acá empieza a ser más vinculado a lo que es la experiencia de usuario. Luego, en tipo interfaz de usuario, tenemos interfaz gráfica de toda la vida que podemos ver en formularios, etc. Tenemos el "Clee", que es la línea de comandos, un interfaz táctil, como es en el caso de los celulares, las interfaces para los wearables o los que se usan como los smartwatch, interfaz por voz,, dispositivos internet of things, interfaz basado en gestos y para smart TV, entre otras, pero se clasifican como tal porque cada uno va a tener su contexto y por ende tiene que tener un pienso distinto. Sí, porque imagínense que yo en el smartwatch yo de edad no sé, un formular me muer. Entonces, ¿qué pasa con el tema de las metáforas? Que cuando hablamos de software tratamos de poder representar cosas de la realidad dentro de nuestro software para que sea más fácil de usar. Como por ejemplo el tema del escritorio, ¿ al al inicio de de toda esta era de las computadoras y todo esto? Se utilizaban más que todo para trabajar. Entonces uno asociaba a trabajar un escritorio con sus carpetas y sus papeles. Bueno, de ahí también sale el concepto de carpeta. ¿Qué otro tipo de metáforas se les ocurre? ¿De aplicaciones, digamos, modernas? ¿De Windows? ¿De ventanitas? ¿Qué tenés tipo de ventanitas ahí para el menú? Claro, pero eso es porque se llama Windows. No sé, como que no lo veo. Pero por ejemplo, otra, no sé. Losones de play de spotify tienen el mismo simbolito que tenían los equipos de música en fisio por ejemplo creo haber oído acerca de las historias de los nódicos y por qué se le llamaba el lobin en algún punto en los logs no creo que era algo porque usan mandabaaban mensajes en un tronco o algo así creo que era, entonces ahí quedó el concepto Loving, Logging de Loggeo de los logs, no de Logging de usuario. La metáfora ahí en ese caso, hallando por lo mismo en los bugs, como por lo menos, que eran bichcía que corto circuitaban sistemas gigantes. Hay va. Yo creo que ese me ocurre es el tema de a ver qué es de ustedes también. Bueno mismo la papelera. Sí, no. Como dice, yo no te perdon. No, que digo que igual estábamos hablando de me salteaba otro plano, me parece. Sí, no, pero es todo divertido, así que está bien. Estoy interesante. Bueno, así hay muchos. Tenemos tendencia de diseño también con el especimorfismo, diseño plano y neumorfismo, que al final es una combinación de ambas. Entonces, ¿qué pasa? Que al principio, bueno, no voy a decir el principio, pero…e pocas de épocas, ¿no? Pero el enmorfismo trata de que la interfaz sea muy, muy, muy parecida…a lo que busca emular de la realidad. Entonces, fíjense que teníamos diseños… ¡Ah, este telefonito! Siempre lo quise. Emulamos la sombra y todo ese nivel de detalle para que se parezca un montón pero luego dijimos bueno, capaz que conviene hacerlo más menos es más, dicen por ahí, vamos a hacer un poco más plano y bueno, llevaron cosas como esta supo ser lindo, supo ser bueno pero al principio también hay personas que se confundían un montón. Y después llegamos a un término medio, si se quiere, en el que bueno, vamos a agregar un reliever o alguna alegría, pero tampoco tratamos de hiper mega recontrar, hacerlo casi que una ilustración, porque al final se pierde un poco de eso. Ahora, principios de diseño, que ojo con esto, porque se acuerdan que los requerimientos no funcionan, le decimos, bueno, tiene que ser fácil de usar. Ojo, que ahora con principios de diseño, capaz podemos hacer cosas un poco más específicas en ese sentido. Siguiente que tenemos visibilidad, feedback, limitaciones, mapeo, consistencia y affordance. ¿Qué se divide? En percibida y real. Vamos viviendo cada una. Visibilidad, cuanto más visible sean los elementos, más posibilidades hay que el usuario sepa qué hacer y las utilicen. Por ejemplo, las funcionarias más importantes en un auto siempre están a la mano. Entonces, ¿qué pasa? Que, bueno, un poco el ejemplo que nos daba a Esteban, que a veces cosas que eran importantes, ubicarlas, no eran y y que de bueno, es un color de error pero no es el mismo mensaje entonces es quien tiene razón, la culpa es de la vaca al final. Pero bueno, fíjate que hay un tema ahí porque estoy muy seguro que al final Luca no fue la única persona que le pasó eso, capaz es que hay una estadística del porcentaje de usuarios al que le pasa y que no hay de ahí, no sé. El punto es que es importante que haya sido porque si yo hago una transferencia de mucha plata y la aplicación no me dice te queda todo bien, yo me veo poner un poco ansioso. Luego las limitaciones que es restringir la interacción del usuario según un momento dado. Por ejemplo, esto mismo que intentó hacer mi teléfono de bloquear, de deshabilitar el botón de bloquear hubiese estado bueno que me lo dejara visible después de que metí el número, pero bueno. Otro tipo de ejemplos con esto de las imitaciones son ciertos controles para utilizar. ¿Por qué? Porque si ya yo sé que estoy esperando dos respuestas o existen tres tipos de respuesta nada más para que pone el usuario a escribir, si puedo agregar un control en el que seleccione para tratar de velar la integridad de los datos. Luego tenemos el mapeo que es la relación intuitiva entre los controles y sus efectos. Por ejemplo, la fecha del teclado. Entonces, ¿qué pasa? Que casi siempre vamos a relacionar con éxito el color verde y con error o con peligro al color rojo. Entonces, si hacemos un botón de aceptar rojo le vamos a romper la cabeza del usuario. O si presentamos mucho un mensaje de éxito y un mensaje de error, ambos en rojo, capaz que vamos a tener un problema. Entonces, este tipo de mapeo es importante. Luego la consistencia que básicamente no tenemos el color, ambos en rojo, capaz que vamos a tener un problema. Entonces, ese tipo de mapeos es importante. Luego, la consistencia que básicamente no tengamos un carnaval en la interfaz y que si el botón de aceptar tiene un formato, se mantenga consistente a lo largo de la aplicación y no vaya cambiando. O que si está la derecha, el botón de aceptar, bueno, siempre esté a la derecha, de repente a la izquierda porque… Parkour. Luego el "appordance" que refiere a las propiedades de un objeto que sugieren cómo se puede usar e implicar dar una pista sobre cómo utilizarlo. Está la "percibida" y la "real". La "percibida" se refiere a lo que un objeto parece permitir a través de su diseño. Por ejemplo, un botón elevado parece que se puede apreciar mientras que una superficie plana sugiere lo contrario. Que esta vez se hace con cierto relieve o con un color de Ineve lo dice Evo. Y en la fordanz real son las acciones que realmente se puede realizar con un objeto. Por ejemplo, una puerta con manijas tiene a fordanz real para real para hacer abierta, entonces en este caso de interfaz que estamos hablando de bueno si el botón está o no está y es una cosa, los colores que me muestren que me puedan hacer intuir que puedo o no puedo hacer con ese botón es otro Dimensionen el diseño. Tenemos naturalidad, precisión y densidad de la información. Naturalidad se requiere a la facilidad con la que los usuarios pueden interactor con la interfaz de manera intuitiva. ¿Tá? Ustedes se acuerdan que había una técnica de licitación que eran los focus groups y que yo les decía que la principal diferencia de los focus group con los workshops es que nos vamos a permitir explorar más allá de validar un requerimiento. Entonces, parte de las cosas que se hacían en esa focus group era ver las expresiones faciales de las personas que estaban participando y si yo veía una cara rara al momento de intentar hacer una operación, ya yo me estoy enterando que capaz la aplicación es difícil de usar. Y de hecho, hay ciertas herramientas de observabilidad que van registrando logs en los productos y se hace un estudio de bueno, cuánto tiempo pasa entre que intenta generar un reporte, hasta que el imprime. Bueno, este reporte tardará más o tardará menos. ¿Por qué? ¿Será que es un problema de diseño? Esas cosas se estudian precisamente por esto. Claro. Que de hecho no sé si ustedes llegaron a ver una película que se llama "Pasante la moda", pero hay una parte en la que están hablando de eso, de los usuarios que están, o sea, están tardando mucho tiempo en llegar a la parte de comprar y simplemente se quedan aquí y resulta que era un error, un tema de diseño. que y básicamente el interfaz tendría que permitir al usuario lograr eso. Luego tenemos la densidad de la información y esto es importante, ojo, porque, a verdad, en cómo se presenta la información en la interfaz, ¿qué pasa? Hay procesos, por ejemplo, para hacer ciertos trámites que si requieren demasiada información. Entonces es lo mismo tirarle un formulario de mil campos a un usuario a presentarlo en stepers por ejemplo entonces tienes una primera etapa que dice bueno etapa uno datos personales y ahí solamente meter los datos personales y no lo abrumas con lo de man y vas avanzando eso para poder controlar la densidad de la información y que el usuario no se abrume y también reducir los riesgos a que se equivoque. Claro, y también les generas la necesidad de volver hacia arriba para ver que está todo bien.