GIN110 Tecnología y Sistemas de Información + Procesos - Elicitación de Requerimientos - 2024

GIN110 Tecnología y Sistemas de Información + Procesos Prof. Sebastián Cisterna, MBA Prof. Ignacio Alarcón, MSc. Contenidos Solemne 1.Todos los contenidos vistos en clases, por ejemplo: 1.Modelo de Enfoque Sistémico 2.Organización y Sistemas (Cultura, Cambio, Fuerzas, etc.) 3. TAM...

GIN110 Tecnología y Sistemas de Información + Procesos Prof. Sebastián Cisterna, MBA Prof. Ignacio Alarcón, MSc. Contenidos Solemne 1.Todos los contenidos vistos en clases, por ejemplo: 1.Modelo de Enfoque Sistémico 2.Organización y Sistemas (Cultura, Cambio, Fuerzas, etc.) 3. TAM 4. Desarrollo de Sistemas (Difusión Innovación, diversas Metodologías, etc). 5. Elicitación de Requerimientos y los textos: 2. Cap1. Principios de Sistemas de Información. Pág 2. a Pag 12 3. Cap 2. Principios de Sistemas de Información. Pág 60. a Pag 75 4. Limitaciones y oportunidades del Modelo de Aceptación Tecnológica TAM (LimitacionesyoportunidadesdelModelodeAceptacionTecnologica (1).pdf) 5. Pure Waterfall - Rapid Development, Steve McConnell (Pure Waterfall - McConnell.pdf)  ¡Tiempo de participar! ¿Qué recuerdan de la clase pasada? Elicitación de requerimientos ¿Dónde estamos en el curso? Datos, Info y Sistemas Metodologías Relevancia de los datos e La forma en que se decide información para la Adopción Sistemas en adoptar / implementar / organización y los sistemas Tecnológica la Organización desarrollar un nuevo que surgen a su alrededor. Modelos de adopción de Sistema de Tecnología e tecnología por parte de los El rol de los sistemas Información dentro de la usuarios dentro de la organización y organización. 1 los procesos que surgen de éste. 2 4 3 Elicitación (del latín elicitus, "inducido" y elicere, "atrapar") es un término asociado a la psicología que se refiere al traspaso de información de forma fluida de un ser humano a otro por medio del lenguaje. Responderemos 4 interrogantes: ¿Por qué? Fase de Análisis ¿Qué? Elicitación de Requerimientos ¿Quién? Stakeholders Técnicas de Elicitación ¿Cómo? de Requerimientos  ¿Por qué? 1. Fase de Análisis Fase de Análisis Waterfall Metodologías Ágiles Fase de Análisis: El principal foco de la fase de análisis es comprender las funciones de negocio (o procesos) y describir los requerimientos del sistema. Fase de Análisis Por ej: SDLC, (Software Development Life Cycle, Ciclo de Vida del Desarrollo de Software o ciclo cascada) – habilidades necesarias: Investigación de hechos (facts) para requerimientos del sistema Analista debe aprender sobre los detalles de los procesos de negocios y operaciones diarias Analista debe mostrarse conocedor del dominio del negocios de manera de construir credibilidad con los usuarios Analista debe traer una perspectiva fresca (nueva) al problema Modelar procesos de negocios basado en los requerimientos del sistema Fase de Análisis en detalle DEFINIR PROTOTIPOS EVALUAR RECOLECTAR REQUERIMIENTOS PRIORIZAR PARA REQUERIMIENTOS INFORMACIÓN DEL SISTEMA REQUERIMIENTOS FACTIBILIDAD DEL USUARIO (y nuevos requerimientos) Actividades claves en el análisis Actividades de Análisis Preguntas Claves Recolectar información ¿Tenemos toda la información (e insights) que necesitamos detallada para definir lo que debe hacer el sistema? Definir requerimientos ¿En particular qué necesitamos que haga el sistema? del sistema Priorizar requerimientos ¿Cuáles son las cosas más importantes que el sistema debe realizar? Crear prototipos / Nos aseguramos que todos los usuarios entienden a maquetas / diseños cabalidad qué va hacer el nuevo sistema? Evaluar requerimientos Deberíamos continuar y diseñar e implementar la del usuario funcionalidad que proponemos?  ¿Qué? 2. Elicitación de Requerimientos Recolección de Requerimientos 🏢 Comprendiendo lo que el negocio necesita ○ Funciones desempeñadas ○ Ambiente de operaciones ○ Problemas actuales que han llevado a iniciar el análisis de un nuevo sistema 󰪃 Comprendiendo las necesidades del usuario ○ Lo que los usuarios del sistema necesita hacer y ver de manera que apoye las necesidades del negocio ○ Las circunstancia en que las cosas son hechas Foco en recolección de requerimientos: Tres preguntas principales: 1. ¿Qué es lo que quieres hacer? 2. ¿Existe alguna forma particular en que lo quieras hacer? 3. ¿Qué es lo que quieres ver? ¿Qué es la recolección de requerimientos? Desarrollar un entendimiento profundo del dominio del Traer ”ojos frescos” al negocio problema Definir lo que necesita ser Identificar oportunidades provisto por la solución para para mejorar procesos de cumplir los requerimientos negocios Investigar requerimientos Revisar con el cliente el usando una amplia gama de entendimiento del técnicas apropiadas para la problema situación  ¿Quién? 3. Stakeholders ¿Quiénes son los interlocutores válidos para implementar la tecnología? ¿Para quién recolectamos estos requerimientos? Un amplio grupo de stakeholders ○ Gente interesada en el éxito (y a veces fracaso) de un sistema ○ Internos Usuarios (ocupan el sistema) Clientes (pagan y son dueños del sistema) Equipo técnico (aseguran el funcionamiento del sistema) ○ Externos ○ Pueden ser operacionales o ejecutivos ○ Puede ser el CEO de una multinacional o un dueño de un comercio local. Stakeholders: la fuente de los requerimientos del sistema 🔍 Identificar Stakeholders ⁉ Y para ello debemos averiguar… ¿Quién gana y quién pierde con este desarrollo? ✅ Necesitamos identificar a las personas correctas: ¿Quién controla los cambios en los procedimientos? ¿Con quién puedo hablar? ¿Quién tomará las decisiones? ¿Con quién debo hablar? ¿Quién se hace cargo de TI en la organización y quién decide qué comprar? ¿En quién podemos confiar? ¿Quién controla los recursos? ¿Quién tiene las habilidades que se necesitan para el proyecto? ¿Quién tiene influencia?  🎯 Priorizando Stakeholders Interés en el Problema Potencial de Amenaza Poder de Influenciar el Problema Alto Bajo Alto Bajo Potencial de Cooperación Stakeholder Prioritario Poder Latente Stakeholder Stakeholder Solidario Bendición Mixta Alto Alto Monitorear Involucrar Lobby con prioridad (y PR efectivo) Colaborar Stakeholder Clave Stakeholder de Baja Stakeholder Stakeholder Marginal Prioridad No-Solidario Bajo Bajo Monitorear Defender Monitorear Defender Fuente: Perrott (1996) Fuente: Blair et al. (1996) Tu rol: manejar las expectativas ○ Comprendiendo vistas dispares ○ … para crear una visión ○ (de los stakeholders) conjunta Recolectar requerimientos… … ahora sabemos: ¿Por qué queremos recolectar requerimientos? ¿Qué es lo que necesitamos investigar? ¿De quién necesitaremos involucrar para recolectar esos requerimientos? ¿Cómo podemos averiguar lo que los Stakeholders quieren?  ¿Cómo? 4. Técnicas de Elicitación de Requerimientos Técnicas de Elicitación de Requerimientos Análisis de Análisis de Brainstorming Focus Groups Entrevistas Documentos Interfaz Modelado de Workshops de Encuestas / Observación Prototipos Procesos Requerimientos Cuestionarios Investigar Historias de Solución de Conversar con “Riding the soluciones de Usuarios Proveedores Expertos trucks” vendors Brainstorming Conocido como "lluvia de ideas". Técnica para generar ideas en grupo sin juzgar su viabilidad, fomentando la creatividad y la diversidad de propuestas. Observación La Observación In Situ es una técnica para recolectar datos mediante la observación directa de los usuarios en su entorno, viendo su comportamiento en su entorno natural. Al observar a los usuarios interactuando con el sistema en su ambiente de uso diario, puedes obtener información invaluable sobre sus necesidades, problemas y sugerencias. Permite obtener información precisa sin intervenir en las condiciones. Puede ser estructurada o no estructurada, según el grado de control en la recolección de datos Focus Groups Método cualitativo de investigación donde un grupo pequeño de personas discute sobre un tema específico bajo la guía de un moderador. Se usa para explorar opiniones, actitudes y percepciones en profundidad. Prototipos Versión preliminar de un producto o servicio que se usa para probar conceptos y funcionalidades antes de su desarrollo completo. Permite identificar problemas 748 × 561 y hacer ajustes. Tipos: 1. Facade (maqueta simplificada) 2. Funcional (Working) Desechable (Throwaway): Construido para ser usado y luego descartado. Evolutivo (Evolutionary): Desarrollado y mejorado gradualmente. Entrevistas con Usuarios 🎯 Cumplen dos propósitos: 1. Comprender las necesidades y expectativas de los usuarios 2. Crear conocimiento del proyecto Entrevistas con Usuarios 󰗦 Ventajas Forma efectiva de comprender funciones del negocio y reglas Se obtiene una fuente directa de los requerimientos del negocio Crear lazos 󰗫 Desventajas Costoso Intensivo en tiempo Lo que la gente dice no siempre es lo que realmente hace Entrevistas con Usuarios 󰗦 Ventajas Forma efectiva de comprender funciones del negocio y reglas Se obtiene una fuente directa de los requerimientos del negocio Crear lazos 󰗫 Desventajas Costoso Intensivo en tiempo Lo que la gente dice no siempre es lo que realmente hace Preparándose para una entrevista exitosa 😎 Crear objetivos claros Pensar acerca del tipo de información que esperas obtener (tener una lista detallada de las preguntas preparadas) Prepararse para lo inesperado (podrás tener respuestas que no esperas) ¿Cuando entrevistar? ¿Dónde entrevistar? ¿Cuántas personas al mismo tiempo? Tipos de preguntas: cerradas vs abiertas Durante la entrevista 🎥 Tomar notas a cabalidad ○ Piensa si quieres grabar, podría alterar la disposición de tu entrevistado Identificar información faltante y preguntar Sondea por los detalles Busca excepciones y condiciones de error Después de la entrevista 🗒 Agradece a tu(s) invitado(s) por su tiempo Revisar las notas para asegurarte que sean lo más completas posibles Identifica áreas que necesitan más investigación Crear preguntas de seguimiento y nuevas entrevistas para clarificar áreas grises Ejemplo: Temas discutidos en una entrevista Temática Preguntas al usuario ¿Cuáles son los procesos de negocios? ¿A qué te dedicas? ¿Como se realizan los procesos de ¿Cómo lo haces? negocios? ¿Qué pasos sigues? ¿Se podrían hacer de otra manera? ¿Qué información se necesita para ¿Qué información utilizas? realizar esas operaciones? ¿Qué inputs utilizas? ¿Qué outputs genera?  Talleres – Workshops – JAD* Denominadas sesiones JAD (Joint Application Design) que se definen como “un proceso usado en el área del ciclo de vida de prototipado para reunir requerimientos en el desarrollo de nuevos sistemas de información para una organización.” * Joint Application Development ¿Qué hacer en el taller? Reunir a todas las partes interesadas en una sala durante un par de días y facilite la discusión. Construyan modelos con todos los presentes. Las personas intercambian ideas entre sí. Sin demora en confirmar o negar aspectos del modelo. Determinar un propósito claro para cada taller: informar objetivos y entregar material a usar previamente. Determinar los participantes. Asegurar su compromiso al 100%. Requiere una sala de conferencias, pizarra, etc., un facilitador y un escriba. Puede ser muy difícil de organizar, especialmente si se trata de personas mayores. Requiere sacar a la gente del trabajo durante una semana más o menos. Talleres Historias de usuario Una historia de usuario es una explicación general e informal de una función de software escrita desde la perspectiva del usuario final. Su propósito es articular cómo proporcionará una función de software valor al cliente. Se puede pensar que las historias de usuario son, en pocas palabras, requisitos del sistema de software. Pero no lo son. Historias de usuario Las historias de usuario son construcciones simples y potentes que describen una funcionalidad desde el punto de vista de su usuario. Son pequeñas descripciones de los requerimientos de un cliente. Para enunciarlas, se suele seguir la siguiente estructura: Como , quiero , para Ejemplos: Como usuario final, quiero restablecer mi contraseña de modo que pueda acceder a mi cuenta de nuevo. Como vendedor, quiero registrar los productos y cantidades que me solicita un cliente para crear un pedido de venta. Historias de usuario Cada historia de usuario tiene que ir acompañada de condiciones debe cumplir la funcionalidad que implementa la historia. Los criterios de aceptación serán utilizados tanto por los desarrolladores como por los testers (qa) para validar la conformidad de la aplicación con los requerimientos funcionales. Beneficios de utilizar historias de usuarios Pone a las personas en primer lugar. Pone a los usuarios finales reales en el centro de la conversación. Las historias utilizan lenguaje NO TÉCNICO. Acerca a las personas TI al Negocios. Promueven la colaboración. Las historias impulsan soluciones creativas. Encuestas y cuestionarios Puede ser: en línea, en papel, por e-mail 󰗦 Ventaja Cubrir un espectro amplio de gente rápidamente 󰗫 Desventaja Baja tasa de respuesta Preguntas pueden no entenderse Preguntas deben prepararse con precisión para ser efectivas. 🥼 Expertos en la materia A veces referidos como Expertos en el Dominio No son usuarios del sistema, pero tienen conocimiento relevante en el dominio del negocio. Se les debe usar para confirmar ○ Suposiciones y Afirmaciones ○ Reglas de Negocio Usualmente se les involucra ○ En los Workshops y sesiones JAD ○ Revisión y refinamiento de procesos para llevar el modelo inicial a un borrador de trabajo. 🚌 Riding the trucks Observación en terreno No solo depender de entrevistas y workshops para entender los procesos de negocio. A veces muestran diferencias significativas entre lo documentado y lo que realmente pasa. 🚌 Riding the trucks Salir a ver el proceso de negocio en acción: Hablar con el personal de primera línea, ver qué es lo que hacen. Ver como ocurren variaciones de la forma “oficial de hacer las cosas” en diferentes lugares. Ver cómo la gente interpreta y usa la misma data de formas distintas. Observar cómo la gente usa realmente el Sistema Ganar sensibilidad de la calidad de los datos. 🚌 Riding the trucks CEO (en aquel entonces) de Lyft. Click aquí 󰡱 Investigar soluciones de vendors Muchos problemas ya están resueltos 󰗦 Ventajas ○ Frecuentemente provienen nuevas ideas ○ Pueden ser “State-of-the-Art” ○ Más barato y menores riesgos 󰗫 Peligros ○ Comprar la solución antes de entender el problema ○ Puede no resolver todos los requerimientos ○ Soporte del vendedor, problemas de actualizaciones 󰡱 Técnicas útiles para Investigación de Vendors Pedir especificaciones técnicas al vendor Demostración o tiempo de prueba del Sistema Hablar con clientes actuales para referencias Visitas al sitio para ver funcionamiento Revisión de reportes y pantallas (screenshots) del sistema. RFP: Request for proposal ○ Generalmente es una licitación ○ “Brief” común para varios proveedores al mismo tiempo Revisión de Documentos Existentes 📃Revisar documentación interna del negocio y descripciones de procedimientos ○ Identificar reglas de negocio, discrepancias y redundancias ○ Tener precaución con materiales “anticuados” ○ Comprender preliminarmente los procesos ○ Usar como guías y elementos para guiar entrevistas. 🌎 Revisar fuentes externas de organizaciones profesionales de industria y publicaciones Técnicas de Elicitación de Requerimientos Análisis de Análisis de Brainstorming Focus Groups Entrevistas Documentos Interfaz Modelado de Workshops de Encuestas / Observación Prototipos Procesos Requerimientos Cuestionarios Investigar Historias de Solución de Conversar con “Riding the soluciones de Usuarios Proveedores Expertos trucks” vendors Gracias [email protected] [email protected]