Elicitación y análisis de requerimientos

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

Resumen

La clase se centró en la actividad de elicitación dentro del proceso de ingeniería de requerimientos, retomando la diferencia entre requerimientos funcionales y no funcionales, y los dominios del problema y de la solución. Se presentaron diversas técnicas para obtener información: entrevistas (libres y estructuradas), encuestas, user persona, workshop, focus group, observación, análisis de interfaz, análisis de documentación, brainstorming y prototipado. Se discutió cuándo conviene aplicar cada una según el conocimiento previo del problema y el objetivo (explorar, validar o priorizar). Se hizo hincapié en formular preguntas orientadas al dominio del problema y evitar indagar prematuramente en la solución. Luego se introdujo el análisis de requerimientos, abarcando la clasificación y priorización mediante MoSCoW (must, should, could, won't have), y el modelo conceptual (diagrama de clases o entidad-relación) como representación abstracta del dominio. Se mencionó el uso de Google Stitch para prototipado y se dieron pautas para el obligatorio, como la necesidad de incluir user persona, workshop y focus group, y priorizar los requerimientos en una tabla con ID, descripción y prioridad.

Puntos clave

• Diferencia entre requerimientos funcionales (qué hace el sistema) y no funcionales (cómo lo hace).
• Dominio del problema (necesidades, dolencias) vs. dominio de la solución (cómo resolver).
• Técnicas de elicitación: entrevistas, encuestas, user persona, workshop, focus group, observación, análisis de interfaz, análisis de documentación, brainstorming y prototipado.
• La elección de la técnica depende del conocimiento previo del problema y del objetivo (explorar, validar, priorizar).
• Las entrevistas pueden ser libres o estructuradas; en el primer contacto conviene una entrevista libre para explorar el problema.
• Las encuestas sirven para cuantificar tendencias y validar decisiones; se recomienda un mínimo de 10 respuestas.
• El user persona es una representación ficticia basada en la investigación, útil para enfocar el diseño en el usuario y detectar frustraciones.
• El workshop busca priorizar y definir requisitos con los actores clave, mientras que el focus group explora percepciones e ideas.
• La observación directa permite comprender el contexto real y detectar detalles que las entrevistas no revelan.
• El análisis de interfaz y de documentación son útiles para sistemas existentes, aunque pueden tener información desactualizada.
• El brainstorming debe separar la generación de ideas de su categorización para no bloquear la creatividad.
• El prototipado es parte de la elicitación y ayuda a validar requisitos con los usuarios.
• En el análisis se clasifican y priorizan requisitos; MoSCoW (Must, Should, Could, Won't) es la técnica destacada.
• El modelo conceptual (diagrama de clases o entidad-relación) abstrae entidades y relaciones del dominio; debe ser consistente con la implementación.
• Para el obligatorio: incluir user persona, workshop y focus group; priorizar requerimientos en tabla con ID, descripción y prioridad.

Transcripción

Bueno, ahora sí arrancamos. Hay una buena noticia y hay dos malas noticias. La buena noticia es que como solo estás voz presencial y como solo está Jonathan remoto, entonces hoy la clase va a ser lo siguiente personalizado. No, pero ahora van a llegar un poco… tan poco notizados. Sí, un poco. Y la segunda es que mientras que los compañeros lleguen, si les pregunto algo, me tienen que decir si sea una barbaridad, pero no me pueden hacer prestaban atención mientras hablabas cosas acá, pues muchos, yo se. Pero bueno, lado bueno, nos vimos, nos conocimos, feliz, conojí, no podemos hacer muchas cosas. Lo cierto es que luego de que terminamos la evaluación, yo di clase, aunque ustedes no lo creen, y aunque estaban acá, yo sé que la capacidad de prestar atención no fue la mejor, lo sentí. Pero no importábamos hacer un pequeño recap y vamos a tratar de continuar, sobre todo porque la clase de hoy es un insumo importante para arrancar con el obligatorio. Dato no menor, recordemos que la semana que viene tenemos el checkpoint. y al alcance del checkpoint. Vamos a quedarnos con el hecho de que lo que vamos a ver hoy lo tenemos que poner en práctica ya. Igual no debería ser tan desafiante y vamos a tener unas actividades. El contenido es teórico es denso pero yo voy a tratar de que no sea denso. Así que nada, vamos a agarrar todos chicos. Muy bien. ¿Qué te estamos viendo ahora? ¿De qué venimos hablando la última clase? Y ¿cuál es la diferencia entre ellos? Funcionales, lo que sí o sí tiene que hacer y no funciona, es como que le agrega valor, digamos, ¿no? No. No, no, no. Porque de hecho, según una documentación de requerimientos, lo que se define como requerimiento funcional y un requerimiento no funcional para un sistema, si es que tiene que cumplir, eso aplica para ambos. Buen, nada. Te estaba buscando los apuntes. En funcionales que hace el sistema y no funciones como como lo hace eso dijimos. Exactamente. El K. Perfecto. Y el C. Perfecto. Esto al final habíamos dicho que era un artefacto. ¿Verdad? Pero también había otra cosa que era más grande y que era, empieza por "P". Hasta ahí me voy yo. Proceso. Y acá es cuando hablamos de ingeniería de requerimiento. ¿Qué es lo que estamos estudiando ahora? Entonces, ¿qué pasa? Que este proceso de ingeniería de requerimientos tenía un conjunto de actividades y esas actividades, esta no son actividades, y esas actividades eran estas. ¿Verdad? Elicitar, analizar, validar y especificar y cuando yo les sé cuáles vamos a hacer para el obligatorio ustedes muy sabiamente me dijeron perfecto eso sí lo retuvieron al toque son lo máximo muy bien entonces cuál es la idea que hoy veamos la actividad de elicitar que elicitar obtener información distintas fuentes, recolectar necesidades y expectativas. Me regreso a la tableta y a la pizarra de vuelta para hablar una cosita. Esa es la encuesta básicamente, es la encuesta de la cifra. No es tan simple como eso. No. Eso es la punta de la isla. A mi. ¿Vas? ¿Vos no te preocupes que va? Tenés con que entretenerte. Ahora, la clase? Bienvenido, Maki. ¿Lominio del problema y dominio de la solución? No te acuerdas. ¿Qué te acuerdas? ¿Tú qué siempre me defiendes y dices que él lo dijo? A ver, a ver, ¿qué? Esto, ¿qué era? ¿Lominioción. Y dominio del problema. ¿Qué y cómo no era? Como. ¿Cómo? Escribir aquí cómo así que era. Eso era qué? Dominio de la solución. Ajá, ¿y el dominio del problema qué era? Necesidades, volvencias. ¿Lo escribí en la pizarra? ¿Te acordaste? Ah, no, falta, muy bien. Ah, así contento. Es su ofricción. Pero, es aquí la referencia de dolencias. Dolencias, dolencias pueden ser pérdida de información, pérdida de clientes, pérdida de oportunidades, etcétera, etcétera, etcétera. Al final, dolencias están muy relacionadas a pérdida de plata. La lentitud habíamos hablado, ¿no? Como parte de la dolencia o… ¿Qué cosa? ¿Llamo a dar el ejemplo de la lentitud de eso como dolencia o no? Sí, solamente que la lentitud no necesariamente tiene que ser un sistema lento puede ser la ausencia de un sistema también. Y? Claro, ahí estamos hablando de buenas prácticas para definir requerimiento. ¿Sí? Entonces, sabiendo esto, sí vamos a hablar de la actividad de licitación en que dominio nos vamos a meter ahora. Solución. ¿Serdad? Entonces, ¿Qué pasa? Mi objetivo hoy es que nos vayamos con que esto hay que entenderlo bien antes de empezar a hablar de esto. Sí, ese es mi objetivo el día de hoy. Si lo logro, cool. Y si no, la verdad que también. O sea, mal por ustedes, pero bien por mí. No, no, no, de ninguna manera. Entonces, hay una palabra que ha sido medio trending topic para Agustín, que lo menciono varias veces, al momento de la redelicitación que ha sido encuesta. Pero ahora les hago una pregunta. ¿A ustedes les ocurren otras formas de recaudar informe? No puede ser tan difícil. ¿Te les ocurren otras formas de recopilar información? Sí. Investigación. Igual claro que pasa que al final investigación engloba todo esto porque si te fijan la investigación va a tener como propósito descubrir algo y todas estas son estrategias para descubrir necesidades, dolencias, divertiduras. ¿Tá? No, igual del mercado me refería como como lo que ya existe. Ajá. esto ya lo has hecho, deberían. ¿Por qué? Porque hubo cierta clase en las que le di el nombre de cierta aplicación y les dije que ahí van a estar un poco analizándola y ese era el nombre de una técnica que ya existe y que le damos a ver cómo se llamaba, no se acuerdan. Genería reversa era ¿no? Esa muy bien. Genería. Genería. Perfecto. Ahora, ¿qué pasa? Que cuando estamos haciendo este proceso de licitación para descubrir necesidades, dolencias, incertidumbres, no siempre nos van a servir estas o no siempre vamos a poder sacar el mayor provecho a partir de estas. Vamos a necesitar otras. ¿De qué va a depender eso? ¿De qué tanto ya sepamos del problema? ¿Sí? ¿Qué pasa? Hay otras como encuesta. Esta la voy a borrar. Me interesa hacer la discrepancia de colores por una razón. Tenemos encuesta, vamos a hablar de otra que se llama user persona. Tenemos otra que se llama Workshop. Otra que se llama Pococlub. Otra que se llama Pococlub. Tratamos esa documentación, entrevista a esas. La de positivo ya nos lo más probable es que no tengan ni idea del problema. Entonces hay de pronto ciertas estrategias que les van a servir más que otras porque precisamente nos van a proveer de una estructura menos rígida que nos va a permitir explorar desde cero pero van a ver otras técnicas que nos van a permitir partir de una base ya establecida y que nos va a servir para aclarar, refinar o validar esa información que ya tenemos. ¿Sí? Y porque es importante aplicar la estrategia correcta en el momento correcto, porque algunas van a demandar más tiempo que otras. Y recordemos que al estar colaborando con personas del dominio y del problema, estamos consumiendo de su tiempo también. Entonces, eso es una de las cosas valiosas de poder identificar cuándo hacer cada una. Entonces, la dinámica de hoy va a ser así. Yo les voy a conversar esto y después vamos a hacer el contraste con la edad positiva, lo que no quede claro se va repasando ahí y vamos para poder avanzar con flujo un poco más dinámico y no perder su valiosa y ahora la atención tan rápido. Muy bien. Qué una entrevista en la vida. Diálogo persona intercambio de. Está perfecto. Entonces, voy a hacer el zoom aquí en entrevista y voy a colocar acá preguntas ¿Verdad? Esto suena obvio. Y recuerda lo que yo le dije de las cosas obvias. Siempre hay una anécdota de todo. Pero ah no hay un color que me guste. ¿Qué pasa? De entrevistas, vamos a tener dos tipos. Vamos a Y las libres. En la de positiva, seguro tiene otro nombre, pero no importa. Y las libres. Entonces, ¿qué pasa? Que algunas van a requerir de una preparación un poco más formal y va a ser de un alcance más acotado. Mientras que las otras van a ser más libres, como su nombre lo dice, valga la redundancia. Yo me prometí nunca tener que decir eso, pero ya lo dije. Bueno. Y ¿qué pasa? Que van a tener un desafío intrínseco que va a ser el poder tomar la situación y a pesar de no tener preguntas ya definidas no permitir que la persona a la que estamos entrevistando se vaya por la tangente de la tangente de la tangente porque al final nadie le interesa eso un caso que suele ocurrir de eso bueno estamos entrevistando a alguien porque le vamos a hacer una aplicación para gestionar sus viajes porque las que existen en el mercado no les sirven y es una persona que deja mucho. Entonces claro, ustedes quieren saber temas de itinerarios, temas de frecuencia con la que viaja, temas de qué es lo que no tienen, las aplicaciones que ya existen y les empiezo a decir lo que pasa es que a mí me gusta mucho el café europeo. No me importa si te gusta el café europeo, me interesa el tema de la aplicación en evasta. Esas cosas ocurren un montón y son las que tienen que tratar de manejar la persona que aplica la entrevista libre para poder sacar el provecho en instancia. ¿Sí? Ahora le hago una pregunta. ¿Apáez lo que acaba de llegar a no mentir? Pero le hago le haga una pregunta qué tipo de entrevistas harían ustedes la primera vez el primer contacto con el cliente o potencial usuario o persona a la que están entrevistando ¿cuál creen que le sirve más si es la primera? libre ¿por qué? por un tema de ir agarrando confianza con el cliente y aparte de humana un poquito más. Pero podemos ser humanos con la entrevista cerrada, tampoco somos chatépte después. Porque para agarrar una estructura, tenés que saber de qué pasán bingo perfecto va por ahí base para hacer preguntas más específicas ¿Tá? ¿Qué podríamos hacer antes de una entrevista? Una primera entrevista que va a ser libre y para poder tener cierto marco? ¿Será que yo les dije vayan haciendo este análisis de esta aplicación? Puede ser, puede ser, puede ser, puede ser, pero bueno ¿Por qué puse preguntas acá en Bordeaux? Magenta, eso. Es tan fácil creen ustedes que es formular preguntas por una entrevista. Preguntas que aporten valor. Depende de la complejidad de problemas que ir a resolver ¿no? Muy bien, muy bien, depende de la complejidad del problema, porque si vamos a hacer un sistema para, no sé, un laboratorio de maquillaje que me va a hablar de fórmulas y composiciones químicas y cosas, mi idea. Y por eso queremos entender bien cuál es el problema, ¿vieron? Entonces, se estaba insistiendo desde hacer casi dos clases el tema del dominio del problema y el dominio de la solución y se supone que estas preguntas tienen que indagar en esto. ¿Qué pregunta no apropiada se les ocurre para una primera entrevista? Una pregunta que me llevia esto en vez de esto. ¿Verdad? Entonces si yo en una primera entrevista le pregunto de una. ¿Quiere un formulario? O un Excel. O sea, ¿por qué tu cabeza generó la synapse para preguntarme eso? O sea, ¿pasado pasado en que tenemos que encontrar primero la base. ¿Sí? Entonces, yo quiero hacer un pequeño experimento, porque nunca lo había hecho en este semestre. Pero nunca había tenido un que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo otra. Está, Agustín con Julieta, Lucca, si voy a decir Manuel, Lucca con Pablo. Y lo que van a hacer es formular preguntas para una primera interacción con ese cliente ¿Está? ¿Qué qué qué queremos de esas preguntas? ¿Qué lácte de qué es? Ya te lo voy a mostrar. ¿Qué queremos? Identificar necesidades, dolences e incertidumbre. Ahora, aguarden línea por favor mientras busco el enunciar. ¿Cuántas preguntas tienen? No llegamos a ni a las cuatro. Ah, este me guardé. Y Luca no es casi competitivo. Bueno, ¿se animaron a compartirlas? Sí, sí, sí. Con la pantalla o como? No, no, no, no. Vos decímenos. Acá no más.. -Pero tal. Sí, sí. Las preguntas fueron básicamente ascientes. -En qué presentó. -Ah, perfecto. Copies, pego. -Ah, ok. Sí. -No, pero decílas, decílas. Yo pensé… -Bueno, ¿en qué presentaba dificultad de ese sistema anterior? Por ejemplo, como más… Socavando un poco más el problema puntual que tiene la persona con eso porque es como que no queda tan claro de que… en qué le fallaba lo otro y si se le pisaban las agendas no, capaz que era un tema de mala gestión. No sabemos en ese sentido. ¿Qué tarea es la que le quita más tiempo? ¿Cómo para ir descartando y tratar de automatizar ciertos procesos. Ok. Y bueno, ¿y qué conocimientos tiene herramientas informáticas? Más que nada para adecuar una interfaz o una experiencia usuario al nivel más óptimo. Muy bien, muchas gracias chico. chicos es una sala bueno que vamos a coment búsqueda de tabarra. - ¿Y que a uno de los pacientes? - Y hoy, ¿y que están el higüeto o como está? - Quedan los visitantes de pacientes. - Ok. - Yo creo que no hay si que ver, que hay que ir a la búsqueda de tabarra. - Ok. - ¿Cuándo se alabran los puntos que se ven alabran? - ¿Cuándo se acaban los turnos? ¿Cuánto estaba en promedio cada tipo de nosullta? Si a mí me interesa la confirmación previa del paciente, o sea, si les consulta antes y si tienen un mecanismo para cancelar o reocular la mosuda. Todo es el mismo. Sí, podemos estar los tranquilamente. Sí, creo que eran los… Bueno, tenemos hoy. Decíbalo… ¿Qué pizas? ¿Sabéis de la confirmación previa del paciente? Ajá. Y si ahí sí está un mecanismo para cancelar o reocular los síntomas. ¿Cómo hace cuando no está en la rece seleccionista? Y si tiene alguna forma de implementar las reservas automáticamente, como nadie hueve, como… Perfecto, muchas gracias, muy amables que estamos hablando mucho. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba. No me preguntaba ¿Cuál es suele que tiene? muy bueno muy buena pregunta Vamos a ver Am Amor a esta pregunta. Pero fíjate que esta pregunta en realidad es muy buena. Sí. Pasa que hay que desglosarlo un poquito más. Pero ¿por qué? Porque esta pregunta al final lo que me puede obtener. Es un flujo de negocio y eso nos interesa. Y si le hace preguntas direccionadas a lo que ya te dijo no vas a sacar. No y sobre todo que te puede contar el día y hay problemas que ya no se da cuenta que tienen. Exactamente. Exactamente. Muy bien eso. Para que me hablan otro al mismo tiempo. Lucas, ¿Verdad? Y Lucas tenías razón, ¿No? Ay, Dios. Está. Muy bien. Me llamó la atención algo por acá. Y fue esto. Disposal. Esto. Esto… ¿Por qué? Pero sigue sin ser parte de la exploración del problema de la dolencia. Esto simplemente es una guía para saber cuál es la mejor forma de implementar mi solución. Pero no es una pregunta que explore las necesidades del dominio del problema. Ojo con eso. Después de que tengamos todo ese dominio del problema levantado, capaz puedo aplicar otra encuesta o mejor dicho una encuesta u otra entrevista en la que explore este tipo de cosas para tomar una decisión estratégica. de De todas formas, cuando veamos el user persona, se van a dar cuenta que estas preguntas empezan a tomar relevancias, pero en este momento. Yo tenía por acá… ¿De acá? Ya les pasa? que aquí tiene esto, se lo deja. No, no me importa. Vamos a aulas y fíjense que tenemos el notebook LEM de ingeniería requerimientos y ahí lo tengo abierto acá, entonces fíjense que aquí en la parte de licitación y análisis podemos dejar solamente la yabositiva y tratar de iterar sobre esto, fíjense que ya había hecho un poco el ejercicio de preguntas y fíjense el prompt que le puse, genera un set de preguntas orientadas a entender el dominio del problema para un dentista que necesita optimizar la gestión de su agenda, pero fíjense que el prompt dice preguntas orientadas a entender el dominio del problema, entonces no era lo mismo Bueno, vamos a ver si… ¿Qué pasa? Si eso sucede, me encantaría que en la reflexión del obligatorio eso esté documentado. Porque puede ser que haya puntos emocionales involucrados. ¿Qué es esto? identificar y priorizar requisitos. Entonces, ¿qué va a pasar acá? Generalmente, cuando se lleva a cabo un workshop, es porque has de tener identificado algo a resolver, ya sea, ¿cómo terminamos de definir este requerimiento? ¿Qué tan importante es? ¿O cómo lo terminamos de plasmar para que realmente represente la solución que estamos buscando? Se necesita de un moderador para que la lleve a cabo y es importantísimo que participen las partes realmente importantes. O sea, los roles que estén muy involucrados en esa parte de la solución tienen que estar ahí. Ventajas, visión integral de requisito de distintas perspectivas. Desventaja, requiere planificación y facilitación cuidadosa. Eso quiere decir que tener que ver un moderador que se va a manejar la cuestión. No puede ser que los cuatro estén usando el teléfono en mi cara. Túrnese por lo menos. Buenas prácticas para los workshop. Definitivamente los objetivos y el alcance del taller, seleccionar cuidados precisamente a los participantes y utilizar tiempo fijo para discutir cada tema. Muy bien. El focus group también es una sesión grupal, pero tiene una diferencia clave y es que mientras que en el workshop ya vamos en miras de solucionar algo, en el focus group estamos tratando de explorar un un poco entonces del workshop yo me llevo soluciones y del focusgroup yo me llevo ideas o percepciones la aplicación comprender necesidades de los usuarios ventajas nos da información cualitativa rica y detallada para los focusgroup generalmente ya se tiene un poco del producto hecho y podemos empezar a evaluar reacciones no verbales. Por ejemplo, si estamos mostrando un prototipo y la persona pone cara de que es esto, ya sacará de que esto nos dice el diseño no está bien. Ahora vamos con observación. ¿A qué se les ocurrió usted que pueda hacer referencia a observación? No digan observar porque me voy a querer morir. Pero ¿en qué casos ustedes creen que no basta con que me hablen nada más y yo tendría que ver un poco la dinámica del dominio del problema? No sé que lo pregunto, profe. recién como que no, no nos imaginamos que haga mucha falta que yo vaya al consultorio y vea cómo la señora reescribe el cozo en el cuaderno, o sea, eso está bien. Pero será que en todos los casos es así o habrá casos en los que es valioso que vayamos al lugar y presenciemos la dinámica en la que se desenvuelve ese dominio del problema? Yo cuando lo hice, damos una oficina con 20 con 20 personas, sí, que trabajan todos sobre el mismo sistema. No sé, ¿quién da más? No, en este caso de entidad te dice que nos hace más o menos para ese problema. No es nada para que alguien sabe que hay un problema, pero no sabe dónde. Ok, ¿qué otra cosa se le ocurre? tan obvio entre comillas. ¿Por qué? Porque manejó de una agenda, no lo podemos imaginar porque si bien no somos la recepcionista, somos personas que a veces agendan cosas y se nos pueden y podemos pensar en escenarios. Pero si por ejemplo yo les digo que vamos a hacer un sistema, una aplicación para el traqueo de producción de vino. Es capaz que no saben cómo funciona eso. Y por más que les digan y les den conceptos de negocio y les describan flujos eso en su mente no se va a graficar tan real, no? Entonces, ¿qué pasa? Que si de pronto vamos y hacemos un trabajo en la situación de campo, vemos la maquinaria, vemos las bodegas, vemos los barriles, vemos todo, capaz que podemos entender mejor donde pueden estar las dolencias, incluso podríamos ya no solamente identificar mejores preguntas para entender el problema sino que también cuando estemos en la parte de la solución entenderemos mejor el contexto, porque no va a ser lo mismo hacer una aplicación a una persona que tiene las manos grandes y que los botones sean chicos y que encima va a estar en un ambiente húmedo y que se le puede su y se le daba mucho la mano o sea este tipo de pequeñezes al final genera mucho valor y nos damos cuenta de esos detalles que están en el lugar. Entonces la observación básicamente implica poder percibir de forma directa en lugar cómo es ese flujo, como es esa dinámica del dominio del problema para poder aprender y entender mejor como podemos ayudar con una solución de software ¿no? ¿Qué desventajas tienes? Consume mucho tiempo y recursos pueden ser intrusivos, imagínense ustedes ahí nomás el tipo tratando de no ser al ser sucozo y este es ahí igual y eso es incómoda a veces y la interpretación subjetiva de los resultados también puede suceder sobre todo porque no tenemos mucho conocimiento aún de ese problema qué buenas prácticas tiene definir objetivos y alcance de la observación obtener de los… con sentimientos de los usuarios, no intervenir en las tareas de las personas observadas y documentar las observaciones de forma precisa. Este es el obligatorio, muy difícilmente lo van a aplicar. A mí me encantaría poner una letra que les toque, pero bueno, lo pasan a… Ahora llegamos a las encuestas. ¿Pero ustedes qué diferencia hay entre una entrevista y una encuesta busca una objetividad. Quantificar las tendencias. Eso quería llegar. Disarrita dónde está. En tueltas. Quantificar tendencias. ¿Cuánta esan aplicación para varias personas, esas son las opiniones de varias personas. ¿Qué más? Cuando ya creo que tengas una noción del producto en sí, ¿no? Sí. Y de hecho, fíjense que aquí quantificar tendencias me sirve porque el objetivo que va a tener esto al final es tomar decisiones. Entonces, ¿qué pasa? Estamos de acuerdo en que ustedes vamos a aplicar encuestas personas, ¿verdad? Por obligatorio. ¿Sí o no? Y ahí vamos a entender un poquito cómo vive las personas en las que estamos entrevistando el tema de Ilum evento no o el tema de ¿Pero que es? que pasa que al momento en el que queramos definir ciertas cosas, vamos a tener que decidir entre una opción A y una opción B y como eso lo que buscamos es que aporte valor a las personas involucradas en el dominio, entonces ahí si no sirve una encuesta, ¿por qué? porque si tenemos que elegir entre una opción A y una opción B, se envía esa encuesta, se difunde y las estadísticas nos dará la respuesta que necesitemos saber. Entonces se podría decir que el mejor uso que le podemos dar a la encuesta es validar antes de tomar una decisión. Tengo obligatorio, ¿a cuántas personas tendrán que mandarle la encuesta? A ver, antes nos poníamos un poquito crazy y decíamos número que yo considero que ya no deberíamos, pero mínimo 10 personas por lo menos. ¿Verdad? Mínimo. Mínimo y nos están dando poco, pero no les refutaría. ¿Por qué? Porque le dejes que puedan precisamente generar estadísticas y decir que están tomando decisiones de una forma un poco más fundamentada. En la práctica tendrían que ser 50, 100, etc. ¿Sí? Muy bien. Encuestas. Hay buenas prácticas que si quiero reforzar acá y es para poder sacar el mayor proye posible a las encuestas hay que tratar es que las respuestas estén definidas si suele suceder que hay encuestas con respuestas de libre texto pero generalmente estamos tratando de que las preguntas sean acotadas y poder validar que esas respuestas no sean viciadas para que esa métrica sea pura y no sea información real. No hacer muchas para que la gente no se embolicie y la responda y tener cuidado de que las preguntas no se contradiguen entre ellas. Bien. Vaya, me recreo y volvemos G40. Bueno, retomamos entonces con… Ya está bien lo que pasó. Análisis de UI o ingeniería inversa. Que es básicamente examinar la interfaz gráfica de usuario para comprender sus funcionalidades. Si a mí inversa precisamente porque pasamos de hago ya hecho, identificar requerimiento. Esto persigue comprender los requisitos del sistema existente, identificar funcionalidades y generar ideas por el diseño de una nueva interfaz. Y la aplicación es comprender sistemas existentes. Nos da información, sí. Pero como de vistas, tenemos que requiere conocimientos técnicos del interfaz, dificultad para comprender la lógica subyacente y no proporcionó información sobre la necesidad de los usuarios. La dificultad para comprender la lógica subyacente sucede mucho también cuando la mueve de sistemas que son muy viejos y de repente por X razón la necesitan migrar y no hay requerimientos que ya existen, entonces claro, empieza un trabajo arduo de las personas que son más nuevas en el equipo a entenderlo y no todo queda tan claro, entonces al final tiene que combinar el análisis de la interfaz con leer el código y con suerte y la bendición de Dios se logra entender algo. Estuve ahí y es bastante doloroso. Bueno, en práctica utilizar herramientas análisis de interfaz y usuario, complementar con otras técnicas de situación, documentar los resultados del análisis, esto es importante porque si no, al final estamos haciendo lo mismo. Queremos identificar requerimientos que no los teníamos y no lo documentamos, entonces bueno, está sorbentido, total. Luego tenemos análisis de documentación que no necesariamente tiene que ser documentación de sistemas ya existentes, sino también sobre el negocio como tal. Pero cuando hablamos de la documentación de sistemas, sirve mucho cuando se va a reemplazar un sistema existente. Ventajas nos da información detallada sobre los requisitos cuando estamos analizando documentación del sistema como tal. Pero a veces puede suceder que esa documentación no esté actualizada, spoiler sucede todo el tiempo y está sujeto a una posible interpretación subjetiva. Luego tenemos el brainstorming, que básicamente la llevo vida y edad de toda la vida y aquí el consejo más útil que les puedo dar es que no fusionen la etapa de generar ideas con la etapa de categorizar y ordenar las ideas. Porque, ¿qué ocurre? Que acá estamos tratando de usar un poco también el hemisferio derecho del cerebro, que es el más creativo, pero cuando estamos generando esas ideas y de una vez las queremos clasificar o ordenar, estamos un poco ya haciendo filtros que van a hacer que las ideas fluyan de una forma menos dinámica. Entonces, generen ideas y vacíenlas, escribenlas. Y cuando terminan, recién ahí se fijan que escribieron y recién ahí lo ordenan. Pero no traten de hacer todo el mismo tiempo porque les va a bloquear un poco el proceso de precisamente generar estas cosas. Luego tenemos el prototipado, el protíamos visto también en la parte de buenas prácticas de requerimientos y es la creación de modelos del sistema para obtener retroalimentación de los usuarios. Un dato importante que quiero dejar en claro, los prototipados son parte de la oligotoria. Eso lo tienen que hacer. Pasa que en la rúbrica hay una etcétera y debería decir prototipos, pero por las dudas se los digo. Entonces, ¿cuál es el objetivo? Entenderlo mejor los requisitos y poder comunicarlo de una forma mucho más eficiente al usuario, o potencia del usuario o cliente para poder obtener validación en mejores tiempos. Más tarde vamos a hacer una actividad con eso y profundizamos más. Luego tenemos el user persona que esto ya les adelanto en un currículo. Algo que quiero que declaro, el user persona es una persona de ficticio. ¿Qué pasa? potencial o cualquier rol que esté involucrado en el dominio del problema y básicamente todas estas características que ven acá son digamos una especie de síntesis de todas las personas que entrevistaron y de toda la información que recabaron. Entonces para generar esto primero investigamos, luego analizamos y luego plasmamos. Fíjense que acá si le damos un, no le voy a dar un, tenemos como una breve descripción demográfica de la persona y tenemos características que son más personales si se quiere. Fíjense que hablan de frustraciones relacionadas al dominio del problema, hablamos también de comportamientos y hábitos, objetivos, motivaciones y personalidad. Y eso porque no es que importa. Se acuerdan que cuando estaban haciendo el ejercicio se hablaron de bueno, pero surgió la pregunta, surgió la idea de preguntar, bueno capaz que preguntarle la edad para ver qué onda, cómo se lleva con la tecnología y eso. Y esas son el tipo de detalles que sí nos van a interesar, capaz no le da propiamente, pero si entender su relación con la tecnología y cuáles son las frustraciones que presenta al convivir con el modelo de negocio en el cual interactúa. La mayor ventaja es que un enfoque orientado al usuario, pero hay que tener cuidado con esto, que es el riesgo a estereotipos y que y todo esto y esto que nos sugeren que en realidad la user persona es de las últimas técnicas de licenciación que van a aplicar o sea nunca van a comenzar por la user persona y tratar evitar este reotipo y generalización esto no lo vamos a hacer, ¿que les digo? voy a buscar otro ejemplo como va a ser el tercer persona hay muchas plantillas en cambio inclusive y eso les puedo ayudar pero fíjense que el tema de las frustraciones es algo importante porque nos puede hablar un poco de cómo diseñar nuestro sistema para que esto baje y esto no necesariamente es un requerimiento escrito en palabra pero cuando se expresa en forma de frustraciones entonces capaz estamos identificando requerimientos no funcionales también así que hay que tener cuidado con eso imagínense un sistema de cocina que digamos por alguna razón las personas que están trabajando dentro de una cocina tienen que interactuar con una aplicación que no se que actualiza el inventario de los ingredientes o algo así entonces capaz que una de sus frustraciones puede ser que estoy demasiado ocupado y yo no tengo tiempo para estar excroleando ni ni ni estar con botones demasiado chicos porque estoy muy muy acelerado entonces eso no da información que nos diría que pronto el diseño de nuestro sistema tiene que ser amigable con esa dinámica. Y no es algo que necesariamente vamos a identificar en una entrevista cuando nos está hablando de problemas a una capa un poco más alta. ¿Tienes una investigación exhaustiva? Que aplique casi todas las técnicas. Igual hay las técnicas mencionadas. Les digo si o si usar personas. Si no tienen que usar personas van a perder puntos. Eso sí les digo. Claramente, WorkShop y Focus Group son técnicas que no entendemos que no estén. y Pero hablando de análisis de requerimiento, sea naturalmente junto a las actividades de otempción y especificación de requerimiento y conceptualmente implica detectar y resolver conflictos, definir las fronteras del software y cómo esto la actúa con el ambiente de la organización y al laborar requisitos del sistema para derivar los requisitos del software. Entonces, acá, ¿qué actividades vamos a tener? Clasificación de requerimiento entre funciones, enginos funcionales, pero también prioridad, alcance y estabilidad, o con la palabra prioridad. Luego vamos a tener el modelo conceptual y negociación de requisitos. En la etapa 1 ya nosotros sabemos identificar requerimientos funcionales y enginos funcionales, ¿verdad? Ahora vamos a hablar un poquito de prioridad. Acá hay varias técnicas de priorización, pero nosotros vamos a hacer enfasis en Moscú, que significa must have, should have, could have y won't have. El must have es el debe tener, el should have, el debería, el couldría", "hear want", el "no tendrá". Y nosotros identificamos requerimientos que está bien que los identifiquen y está bien que los plasmen en su obligatorio, no significa que los van a implementar. Entonces, lo que nos va a permitir esta estrategia de priorización es alinear al equipo con las personas interesadas para poder entender hacia dónde vamos a ir y en dónde vamos a invertir los principales esfuerzos. Entonces, lo primero que hay que hacer es identificar estas partes clave para poder tener un input valioso, revisar estas tareas y priorizar en equipo. Dentro de las buenas prácticas, nos podemos hacer ciertas preguntas para guiar el proceso, como las siguientes. ¿Cómo salen esta funcionalidad con los objetivos del negocio, que el riesgo conlleva no incluir esta funcionalidad en la versión inicial? Y ¿Cómo afecta la exclusión de esta funcionalidad a la experiencia de usuario? Esto va a darle el peccionario muy posiblemente. Entonces, estudiando. Lo mismo para cada categoría, que que vieron que ustedes tienen, no, ustedes me tiran. Ahí está. Ustedes van a tener un repositorio, ¿verdad? Entonces nosotros quisiéramos ver algo así como una tablita. Entonces, de pronto, aquí tener funcionales y en una tablita pasa que que no tengo el herramienta tener un ID de requerimiento verdad que no va a ser uno vas a hacer un ID digamos un poquito más formal por ejemplo para los requerimientos funcionales puede ser RF_G0-01 recuerden una tablita, en maldado, pasa que ahora no lo tengo. El sistema debe poder mostrar un reporte de rentas por mes, por ejemplo significa alta, que significa media, que significa baja. Pero si van a hacer Moscú, entonces pueden poner aquí "chult". Y obviamente aquí un titular, ahí vi descripción, prioridad. Ah, qué pena. Bueno. Alguien. Está, algo así. ¿Sí? Sí. Por favor, por favor, por favor, no dejen de priorizar los requerimientos. Es una de las razones por las que menos me gusta que tan. Bien. Entonces, resumiendo hasta acá, que hemos visto hoy. Vimos la actividad de licitación con varias técnicas. Entendimos que hay técnicas que son más convenientes al inicio del proceso y otras más hacia el final y empezamos con el análisis y ya sabemos que parte del análisis lo que nos va a decir es identificar requerimientos funcionales y no funcionales y priorizarlos y ahora venimos con otra parte del análisis que es el modelo conceptual. Que es el modelo conceptual, una representación abstracta de los conceptos clave y las relaciones dentro del dominio, el problema que el sistema debe resolver. Que estos lo han hecho ya ustedes en otras materias, en diagramas como el diagrama de clase o el diagrama de relación. Que son, en realidad, diagramas de de la solución pero son una forma de abstraer las entidades del problema y cómo se relacionan entre ellas ¿Sí? Entonces, ¿qué le damos nosotros digamos a pedir a ustedes? ¿Qué nos den un diagramita? Y mucho más sencillo que este igual si es de clase lo único que le vamos a pedir es el nombre de la clase, los atributos y la relación entre ellas. Más nada, no tienen que colocar métodos. Si es gente a relación, la cardinalidad, las relaciones, el nombre y los atributos. Nada más. Primero les identificamos, definimos los atributos, establecemos las relaciones y construimos el diagrama. ¿Por qué es importante esto? Porque recuerde que en el obligatorio 2, ustedes van a implementar la solución, ¿verdad? Y recuerden que nosotros vamos a tener de forma muy similar a los ejercicios que hemos hecho una carpeta de domain y una carpeta de interface y dentro de domain nosotros vamos a tener clases y esas clases tendrían que corresponder con lo que ustedes presenten acá ¿Qué pasa? que obviamente en el camino eso puede mutar por alguna razón eso lo tienen que documentar ¿Qué pasa? Que obviamente en el camino eso puede mutar por alguna razón, eso lo tienen que documentar. ¿Qué? Ok. ¿Preguntas de estas casas? Muy bien. En realidad me surgió una pequeña duda. Te digo. Porque vamos a usar OML y al usar un MERS implicaría que tenemos que hacer una base de datos o no no no es precisamente o no no no de ninguna manera tiene que hacer base de datos aquí lo que nosotros queremos evaluar es que analizaron un dominio de problemas identificaron entidades y cómo se relacionan entre ellas ese es lo nosotros queremos saber. Que si vas a tener que tener presente que cuando implementen la solución, este diagrama tendría que ser consistente con las clases que vas a implementar. Sí? Bien. Sí, porque en realidad nosotros estamos como arrancando digamos el tema que no tenemos bien claro ahora mismo que hacemos con el kit flow, que convenciones nos amamos, no sé si las clases van a servir de apoyo a eso ahora y vamos a empezar a implementar en base a las clases, las clases acatebóricas o ya tenemos que ir adelantando bastante. Yo te diría que se preocupen por lo que hice la rubrica de la obligatoria 1. No por el informe per se. No, sí, el informe per se es importantísimo. Por eso. Por eso. Y eso va a me volar. Preocúpense por las convenciones de comits, por las estrategias de ramas y la definición del objetivo de cada ramas. Eso les importa y les importa definir esto. No se preocupen por más. Si. Ok, ok, ok. Bien. Bien. ¿Alguna otra pregunta? -Tamo. -Gracias, apropiado. No de nada. Bueno, vamos a ir a Aulas. Y se van a poner un parejo otra vez. Bueno, aquí te ganan un poquito solo de un momento. Y van a ver que tenemos… si vamos a aulas a la pestaña material en la parte de requerimientos vamos a tener este ejercicio que se llama ejercicio prototipado. ¿Cuál es la idea de esta actividad? Que hacer un prototipo con una herramienta de ida que se llama Google Stitch para que interactúen con ella y te puedan apoyar en ella durante el obligatorio. No traje conto. ¿Y Julieta tampoco? No. No, es la Julieta. Eh,? ¿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é?