ilovepdf_merged.pdf

GIN110 Tecnología y Sistemas de Información + Procesos Prof. Ignacio Alarcón, MSc. Prof. Sebastián Cisterna, MBA ¡Tiempo de participar! ¿Qué recuerdan de la clase pasada? Recap TAM ¿Qué mejoras trae el TAM2 y UTAUT? Diffusion of Innovations ¡Tiempo de participar! ¿Qué es Innovación? Vehículo autónomo https://www.youtube.com/shorts/0s2qfIkgo80 chotuKool https://youtu.be/gyxPxcE_4to ChatGPT https://youtu.be/4EvNxWhskf8 Drones delivery https://www.youtube.com/watch?v=DOWDNBu9DkU Robots delivery https://www.youtube.com/watch?v=IXd1jNV1f4s ¡Tiempo de participar! ¿Qué otros ejemplos de Innovaciones tienes en mente? ¿Cómo podemos deﬁnir innovación? “Es el establecimiento de una nueva función de producción” (Schumpeter, 1939, p87) “Un nuevo proceso cuando todo es enteramente nuevo” (Levitt, 1966, p.63) “La adopción de un cambio que es nuevo para una organización” (Knight, 1967, p. 479) “Mejoras de tecnología y métodos o maneras de hacer las cosas” (Porter, 1990, p45) “Una importante distinción es normalmente hecha entre la invención e innovación. Invención es la primera ocurrencia de una idea para un nuevo procesos o producto. Innovación es la primera comercialización de la idea” (Rogers 1995) Innovación Es la aplicación de nuevas ideas para los productos, procesos y actividades de una organización, siempre y cuando esto sea conducente a incrementar su valor. Una de las clasiﬁcaciones más reconocidas de innovación es la que nos entrega Clayton Christensen: Innovación sostenida resulta de una mejora de un producto o servicio existente o una mejora en las formas de operar las actividades de una organización Innovación disruptiva es una que inicialmente proporciona bajos niveles de desempeño en el mercado. Sin embargo, con el tiempo la innovación disruptiva mejora para proporcionar nuevas características, convirtiéndose en más atractivo para los usuarios. 1962 Everett Rogers, PhD. Sociólogo La Difusión de Innovaciones y su Impacto en los S.I ¿Por qué es relevante? → Marco teórico fundamental: La teoría de Rogers explica cómo las innovaciones (tecnologías, sistemas, ideas) se difunden en una sociedad. Aplicación en Sistemas de Información: Adopción tecnológica: Entender las categorías de adoptantes (innovadores, primeros adoptantes, mayoría temprana, etc.) es crucial para la implementación efectiva de nuevos sistemas en una organización. Estrategias de implementación: La difusión de innovaciones guía las estrategias para maximizar la adopción de nuevos sistemas de información. Curva de adopción de la innovación Fila para el iPhone : ¿En qué parte de la curva estarían estos usuarios? ¡Tiempo de participar! Innovadores 2.5% Estas personas están ansiosas por ser las primeras en probar un artículo innovador. Están dispuestos a asumir riesgos y suelen tener acceso a recursos ﬁnancieros y conocimientos tecnológicos. Adoptadores tempranos 13.5% Estos consumidores representan líderes de opinión, quienes compran productos después de los innovadores. Adoptan nuevas tecnologías después de los innovadores y juegan un papel crucial en la difusión de la innovación, porque inﬂuyen en otros grupos. Mayoría temprana 34% Estas personas rara vez son líderes, porque necesitan ver evidencia de la eﬁcacia de la tecnología antes de adoptarla. Pero, adoptan nuevas ideas mucho antes que la persona promedio. Mayoría tardía 34% Estas personas son escépticas ante el cambio. Adoptan la tecnología después de la mayoría del mercado, y a menudo necesitan presión social o la percepción de que la mayoría ya ha adoptado la tecnología. Laggards (Rezagados) 16% Estas personas también son escépticas ante el cambio. Son los últimos en adoptar una nueva tecnología y suelen hacerlo solo cuando ya no tienen otra opción. Caso S-Curve El consumo se adopta más rápido ¡Tiempo de participar! ¿Por qué algunas personas adoptan la tecnología más pronto que otras? Adoptantes tempranos: ¿Por qué algunas personas adoptan la tecnología más pronto que otras? Socioeconómico: Tienen más años de educación formal, mayor estatus social, mayor grado de movilidad ascendente. Personalidad: Tienen mayor racionalidad, inteligencia, actitud favorable hacia el cambio, son mejor capaces de lidiar con la incertidumbre. Comportamiento de comunicación: Tienen más participación social, están más interconectados en su sistema social, tienen más contacto con agentes de cambio, tienen mayor exposición a los medios de comunicación masiva, tienen un mayor grado de liderazgo de opinión. Bell Curve La Curva de Adopción de Innovaciones de Rogers muestra los diferentes grupos de personas adoptan una nueva tecnología a lo largo del tiempo. La Curva S de adopción de tecnología ilustra cómo una innovación es adoptada en el mercado, comenzando con un crecimiento lento (adoptadores tempranos), seguido de un crecimiento acelerado (mayoría temprana y tardía), y ﬁnalmente estabilizándose a medida que se alcanza la saturación del mercado (rezagados). S-Curve Ciclos de las curvas S El abismo (Chasm) (Moore, 1991) El Abismo (Chasm) de Moore es la brecha crítica que existe entre los primeros adoptantes (early adopters) y la mayoría temprana (early majority) en el ciclo de adopción de una innovación, donde muchas tecnologías fallan en avanzar hacia la adopción masiva. ¡Tiempo de participar! Shark-Fin Effect (Nunes and Downes, 2018) El Shark-Fin Effect (efecto aleta de tiburón) describe un ciclo de vida de productos donde la adopción crece rápidamente hasta un punto máximo, y luego cae abruptamente, similar a la forma de una aleta de tiburón, debido a la rápida obsolescencia y cambios en las preferencias del mercado. ¡Tiempo de participar! ¿Algún ejemplo de tecnología que sufrió el Shark-Fin Effect ? Disruptive Innovation - Clay Christensen Disruptive Innovation - Clay Christensen La innovación disruptiva, propuesta por Clayton Christensen describe un proceso mediante el cual un producto o servicio inicialmente comienza en aplicaciones simples en la base de un mercado, pero luego se mueve a través del mercado, desplazando a competidores establecidos. Estas innovaciones suelen ser más accesibles y económicas, capturando segmentos de mercado ignorados por los incumbentes y eventualmente transformando la industria. Ej: Mall Chino Ejemplos Ejemplos x Ciclo de Hype de Gartner Es una herramienta utilizada para entender cómo las expectativas y el interés en nuevas tecnologías o innovaciones evolucionan con el tiempo. El Ciclo de Hype de Gartner es un modelo gráﬁco que representa la madurez, adopción y aplicación de tecnologías emergentes, mostrando las expectativas y el interés a lo largo del tiempo desde la sobreexpectación inicial hasta la desilusión y eventual estabilización en su uso. Ciclo del hype Máximo de expectativas inﬂadas 😍 Meseta de productividad Rampa de 🙂 consolidación 🤔 Valle de la desilusión 😢 Lanzamiento 😱 El Ciclo de Hype de Gartner es un modelo gráﬁco que representa la madurez, adopción y aplicación de tecnologías emergentes, mostrando las expectativas y el interés a lo largo del tiempo desde la sobreexpectación inicial hasta la desilusión y eventual estabilización en su uso. Fuente: Gartner Fuente: Gartner Ciclo del hype Máximo de expectativas inﬂadas 😍 Lanzamiento 😱: En esta fase, una nueva tecnología Meseta o de productividad innovación se presenta al mercado. Existe un alto nivel Rampa de 🙂 de curiosidad e interés, pero también incertidumbre. consolidación 🤔 Las expectativas comienzan a aumentar rápidamente. Valle de la desilusión 😢 Lanzamiento 😱 El Ciclo de Hype de Gartner es un modelo gráﬁco que representa la madurez, adopción y aplicación de tecnologías emergentes, mostrando las expectativas y el interés a lo largo del tiempo desde la sobreexpectación inicial hasta la desilusión y eventual estabilización en su uso. Fuente: Gartner Fuente: Gartner Ciclo del hype Máximo de expectativas inﬂadas 😍 Máximo de Expectativas Inﬂadas 😍: Aquí es donde el entusiasmo alcanza su punto máximo. Las expectativas sobre Meseta de lo que la tecnología puede lograr suelen productividad estar sobredimensionadas. Rampa de Muchos 🙂 creenconsolidación que será una solución 🤔 revolucionaria sin considerar completamente las limitaciones. Valle de la desilusión 😢 Lanzamiento 😱 El Ciclo de Hype de Gartner es un modelo gráﬁco que representa la madurez, adopción y aplicación de tecnologías emergentes, mostrando las expectativas y el interés a lo largo del tiempo desde la sobreexpectación inicial hasta la desilusión y eventual estabilización en su uso. Fuente: Gartner Fuente: Gartner Ciclo del hype Máximo de expectativas inﬂadas 😍 Valle de la Desilusión 😢: Después del punto máximo, las expectativas Meseta de comienzan a caer. Los primeros productividad experimentos y proyectos pueden no Rampa de 🙂 cumplir con las expectativas, lo que consolidación 🤔 lleva a la decepción. Algunos incluso abandonan la tecnología en esta fase. Valle de la desilusión 😢 Lanzamiento 😱 El Ciclo de Hype de Gartner es un modelo gráﬁco que representa la madurez, adopción y aplicación de tecnologías emergentes, mostrando las expectativas y el interés a lo largo del tiempo desde la sobreexpectación inicial hasta la desilusión y eventual estabilización en su uso. Fuente: Gartner Fuente: Gartner Ciclo del hype Máximo de expectativas inﬂadas 😍 Rampa de Consolidación 🤔: En esta etapa, la tecnología comienza a madurar. Se comprenden mejor sus Meseta de productividad verdaderas capacidades y limitaciones. 🙂 Rampa de Las organizaciones que persisten con la consolidación 🤔 tecnología la adaptan de manera más realista a sus necesidades. Valle de la desilusión 😢 Lanzamiento 😱 El Ciclo de Hype de Gartner es un modelo gráﬁco que representa la madurez, adopción y aplicación de tecnologías emergentes, mostrando las expectativas y el interés a lo largo del tiempo desde la sobreexpectación inicial hasta la desilusión y eventual estabilización en su uso. Fuente: Gartner Fuente: Gartner Ciclo del hype Máximo de expectativas inﬂadas 😍 Meseta de Productividad 😊: Finalmente, la tecnología se estabiliza y se integra en Meseta de procesos productivos. Aquí es donde se productividad demuestra su valor real y sostenible.Rampa La de 🙂 consolidación 🤔 mayoría de las empresas que han adoptado la tecnología en esta fase la utilizan de manera eﬁciente y efectiva. Valle de la desilusión 😢 Lanzamiento 😱 El Ciclo de Hype de Gartner es un modelo gráﬁco que representa la madurez, adopción y aplicación de tecnologías emergentes, mostrando las expectativas y el interés a lo largo del tiempo desde la sobreexpectación inicial hasta la desilusión y eventual estabilización en su uso. Fuente: Gartner Fuente: Gartner Gracias [email protected] [email protected] GIN110 Tecnología y Sistemas de Información + Procesos Prof. Ignacio Alarcón, MSc. Prof. Sebastián Cisterna, MBA ¡Tiempo de participar! ¿Qué recuerdan de la clase pasada? Metodologías de Desarrollo Formalizando el proceso de diseño, desarrollo, e implementación Metodologías, Técnicas y Herramientas Metodologías: Marcos generales estructurados o un conjunto de procesos y prácticas organizadas que guían las diferentes fases de un proyecto, desde planiﬁcación hasta implementación y mantenimiento. Técnicas: Enfoques y procedimientos especíﬁcos utilizados en cada fase del desarrollo. → Mientras que las metodologías proporcionan el "qué" y "cuándo" en un proyecto, las técnicas se centran en el "cómo". Herramientas: Recursos tecnológicos o herramientas que facilitan y optimizan el proceso de desarrollo. Vamos a hablar de estos términos pero en otros contextos… Cocina Metodologías Técnicas Herramientas ¡Tiempo de participar! Cocina Metodologías La metodología sería el proceso general o la "receta" que sigues para lograrlo. Esto incluiría decidir el menú, comprar los ingredientes, preparar cada plato en un orden específico y servir la cena. Cocina Metodologías Técnicas La metodología sería el proceso En la cocina, esto podría ser general o la "receta" que sigues cosas como cómo picas las para lograrlo. Esto incluiría verduras, la manera en que decidir el menú, comprar los sazonas y cocinas la carne, o el ingredientes, preparar cada plato método que utilizas para mezclar en un orden específico y servir la y hornear un pastel. cena. Cocina Metodologías Técnicas Herramientas La metodología sería el proceso En la cocina, esto podría ser Estos son los utensilios físicos general o la "receta" que sigues cosas como cómo picas las que utilizas para llevar a cabo las para lograrlo. Esto incluiría verduras, la manera en que técnicas. En el caso de la decidir el menú, comprar los sazonas y cocinas la carne, o el preparación de la cena, las ingredientes, preparar cada plato método que utilizas para mezclar herramientas serían cosas como en un orden específico y servir la y hornear un pastel. cuchillos, sartenes, una batidora, cena. o el horno. Construcción Metodologías Técnicas Herramientas ¡Tiempo de participar! Construcción Metodologías Tu metodología podría ser el conjunto de pasos que planeas seguir: primero, diseñarás los planos, luego prepararás el terreno, después construirás la estructura, instalarás la electricidad y la plomería, y finalmente decorarás el interior. Este plan global y estructurado que estás siguiendo es tu metodología. Construcción Metodologías Técnicas Tu metodología podría ser el Las técnicas son los métodos conjunto de pasos que planeas específicos que utilizas para seguir: primero, diseñarás los completar cada paso. Por planos, luego prepararás el ejemplo, podrías usar una terreno, después construirás la técnica de construcción en estructura, instalarás la particular para levantar las electricidad y la plomería, y paredes, como mampostería o finalmente decorarás el interior. construcción con madera. Este plan global y estructurado Cuando instalas la electricidad, que estás siguiendo es tu podrías usar una técnica de metodología. cableado específica. Construcción Metodologías Técnicas Herramientas Tu metodología podría ser el Las técnicas son los métodos Estas son las cosas físicas que conjunto de pasos que planeas específicos que utilizas para usas para hacer el trabajo. Al seguir: primero, diseñarás los completar cada paso. Por construir tu casa, usarías planos, luego prepararás el ejemplo, podrías usar una martillos, sierras, niveles y terreno, después construirás la técnica de construcción en taladros, entre otras cosas. Cada estructura, instalarás la particular para levantar las una de estas es una herramienta electricidad y la plomería, y paredes, como mampostería o que te ayuda a llevar a cabo tus finalmente decorarás el interior. construcción con madera. técnicas y metodologías. Este plan global y estructurado Cuando instalas la electricidad, que estás siguiendo es tu podrías usar una técnica de metodología. cableado específica. 🛠 Herramientas Recursos tecnológicos o herramientas que facilitan y optimizan el proceso de desarrollo. Artefactos usados para ayudar al diseñador a llevar a cabo sus técnicas Ejemplos de Softwares ○ Visio ○ Jira ○ Visual Paradigm ○ Lucid ○ Erwin ○ OmniGraﬄe ○ Dia ○ Database Management Systems (ej. SQLServer) ○ Integrated Development Environments (ej. VisualStudio) Pizarras, plumones, lápices y papel! entre otros Herramientas según Avison & Fitzgerald Project management tools (Herramientas de gestión de proyectos): Facilitan la planiﬁcación, seguimiento y coordinación de tareas en proyectos. Database management systems (Sistemas de gestión de bases de datos): Permiten la creación, administración y consulta eﬁciente de bases de datos. Data dictionary systems (Sistemas de diccionario de datos): Documentan y estandarizan los términos y estructuras de datos utilizados en un proyecto. Systems repositories (Repositorios de sistemas): Almacenan y gestionan todos los artefactos y documentos del sistema desarrollado. Drawing tools (Herramientas de dibujo): Facilitan la creación de diagramas y modelos visuales para la planiﬁcación y diseño del sistema. Computer-Assisted Software Engineering (CASE) tools (Herramientas CASE - Ingeniería de Software Asistida por Computadora): Automatizan partes del proceso de desarrollo de software, desde el diseño hasta la implementación. Técnicas Las técnicas son procedimientos o estrategias utilizadas para llevar a cabo una tarea especíﬁca en el desarrollo de sistemas de información. Son - El “cómo” o “de qué manera” Actividades que son llevadas a cabo por diseñadores para conseguir algún resultado Forman el ‘arte’ del diseñador El resultado es la documentación, un modelo o alguna otra forma de especiﬁcación Diferentes metodologías serán basadas desde técnicas distintas Técnicas según Avison & Fitzgerald Entity Relationship Modelling (Modelado de Relaciones de Entidades): Visualiza cómo las entidades (tablas) en una base de datos están interconectadas. Normalisation (Normalización): Proceso de organización de datos en una base de datos para minimizar redundancias y dependencias. Data Flow Diagramming (Diagramas de Flujo de Datos): Representan el ﬂujo de información dentro de un sistema, mostrando cómo los datos se mueven entre procesos. Structured English (Inglés Estructurado): Lenguaje simple y formal para describir algoritmos y lógica de sistemas de manera clara y precisa. Action Diagrams (Diagramas de Acciones): Ilustran secuencia de acciones o pasos dentro de un proceso especíﬁco. Structure Diagrams and Entity Life Cycles (Diagramas de Estructura y Ciclos de Vida de Entidades): Muestran la estructura del sistema y el ciclo de vida de las entidades dentro del mismo. → Son técnicas de modelado de datos, técnicas de programación, técnicas de pruebas, entre otros. Metodologías Proponer herramientas y técnicas en las distintas fases de un proyecto de diseño. Comprenden una forma de hacer las cosas y resolución de problemas En el desarrollo de sistemas de información, las metodologías son marcos de trabajo estructurados que se utilizan para planiﬁcar y controlar el proceso de desarrollo de un sistema de información. Las metodologías pueden ser formales o informales y se utilizan para ayudar a los equipos de desarrollo a coordinarse y alcanzar sus objetivos de manera eﬁciente. Nos ayudan a proporcionar el "qué" y "cuándo" ¿Cuáles podrían ser las ventajas y desventajas de usar Metodologías? ¡Tiempo de participar! Metodologías - Beneﬁcios Pone el proceso de solución de problemas en pasos más manejables Identiﬁca y deﬁne todo lo que necesita ser realizado, y como debe ser realizado Identiﬁca los recursos que son necesarios en cada paso Identiﬁca quién realizará cada actividad y cuándo lo harán Provee las bases para la planiﬁcación de un proyecto ○ Fases del Proyecto y pasos / Entregables / Milestones Metodologías: El enfoque ortodoxo The Waterfall Model ¡Tiempo de participar! The Waterfall Model ¿Por qué creen que se le podría llamar método ortodoxo? Modelo original Royce, 1970 El enfoque tradicional El Ciclo de Vida de Desarrollo de Sistemas (SDLC, por sus siglas en inglés), también conocido como Modelo de Cascada Iniciación Análisis Diseño Implementación Prueba Mantención Initiation / Iniciación ¿Por qué desarrollamos el sistema? Una investigación preliminar de los problemas, oportunidades, limitantes, y recursos disponibles de manera de poder decidir un curso de acción. ○ ¿Mejorar el sistema existente? ○ ¿Desarrollar un nuevo sistema? ○ ¿Hacer nada?... ¿Mandarlo al backlog? Deﬁnir el ámbito del sistema: ○ Las funciones/actividades que serán desarrolladas o re-desarrolladas. Una mala gestión del ámbito del sistema llevará al fracaso del sistema Initiation / Iniciación Deﬁniendo el ámbito del Proyecto: ○ Grupos claves de stakeholders (proveedores, empleados, expertos en la temática, etc) ○ Problemas percibidos y oportunidades ○ Limitantes ○ Soluciones posibles y expectativas del cliente Entregable: ○ Feasibility report / Reporte de factibilidad (análisis costos y beneﬁcios para cada solución) Análisis ¿Cuál es el problema que debe ser resuelto? Estudiar el sistema existente para comprender profundamente los problemas y oportunidades Revisar lo encontrado con los clientes y revisar ámbito si es necesario Deﬁnir claramente “QUÉ” es lo que el nuevo sistema debe hacer Acordar qué criterios se utilizarán para la entrega. (signoff) ○ ¿Deberían estas especiﬁcaciones ser congeladas? Evaluar factibilidad nuevamente Backlog es una lista priorizada de tareas o requisitos pendientes que deben completarse para alcanzar los objetivos de un proyecto. - Signoff es el proceso de aprobación formal de un proyecto por las partes interesadas, indicando que se ha completado de acuerdo a los requisitos y está listo para pasar a la siguiente etapa o ser entregado. Diseño ¿Cómo resolveremos el problema? Generación de un número de opciones de diseño basados en limitantes técnicas, operacionales, económicas, plazos y licitaciones. El cliente selecciona la mejor opción para sus necesidades (evaluar factibilidad nuevamente) Adquirir el software y hardware necesario Diseñar interfaces, bases de datos, redes Especiﬁcar requisitos de integración y de software Diseño - Wireframes Implementación o codiﬁcación Construir/Modiﬁcar bases de datos y redes Construir y testear programas (apps) Preparar usuarios para un nuevo sistema ○ Acceptance testing ○ Documentación ○ Capacitación de usuarios ○ Procedimientos de mantención Finalizar sistema y documentación técnica Instalar el sistema Testeo / Pruebas Evaluación rigurosa y sistemática de los componentes del sistema Juzgar contra las especiﬁcaciones ○ ¿Hace el sistema lo que se supone debe hacer? No sólo trazar BUGS Los bugs son errores o fallos en el software que causan que funcione incorrectamente o de manera inesperada. Mantención Existen de distinto tipo: Correctiva: Arreglar errores Adaptativa: Satisfacer necesidad de cambios Perfectible: Mejorar desempeño Preventiva: Arreglar problemas potenciales → Si el costo de mantención es muy alto considerar otras opciones como por ejemplo: Nuevo Desarrollo, comprar un paquete de software, re-ingeniería, etc ¡Tiempo de participar! The Waterfall Model ¿Cuáles podrían ser los problemas de esta metodología tan estructurada? El problema con el modelo cascada El problema con el modelo cascada Cambios en los procesos de negocios poco ﬂexibles. Cambios en las necesidades de información o diﬁcultad para adaptarse. Cambios en decisiones de diseño por parte de los stakeholders pueden impactar signiﬁcativamente el cronograma y el presupuesto. Foco (mucho) en documentación técnica, que puede ralentizar el progreso. Si existen errores y problemas se descubren en fases avanzadas, lo que puede resultar en costosos retrasos y correcciones. Resumen de una Metodología Las metodologías formales consisten en gente, herramientas y técnicas Proveen estructura para la planiﬁcación y administración de proyectos Nunca sigas a ciegas SÓLO una metodología. Cada proyecto es diferente, y ten siempre en cuenta las ventajas y desventajas de usarlas: Resumen de una Metodología Las metodologías formales consisten en gente, herramientas y técnicas Proveen estructura para la planiﬁcación y administración de proyectos Nunca sigas a ciegas SÓLO una metodología. Cada proyecto es diferente, y ten siempre en cuenta las ventajas y desventajas de usarlas: Ventajas Desventajas Estructura y organización Rigidez y falta de ﬂexibilidad Mejora de la calidad Sobrecarga administrativa Comunicación y colaboración Resistencia al cambio Facilitan la gestión de riesgos Pueden sofocar la creatividad y limitar Alineación con objetivos y plazos soluciones innovadoras si se aplican en forma estricta. Gracias [email protected] [email protected] GIN110 Tecnología y Sistemas de Información + Procesos Prof. Ignacio Alarcón, MSc. Prof. Sebastián Cisterna, MBA ¡Tiempo de participar! ¿Qué recuerdan de la clase pasada? Otras metodologías Desarrollo Iterativo o Evolucionario Desarrollo Iterativo o Evolucionario Desarrollo Iterativo o Evolucionario Filosofía fundamentalmente diferente al Ciclo de Vida de Desarrollo de Sistemas (SDLC): Desarrollo Iterativo Enfoque escalonado o incremental ○ El diseño no es perfecto ○ Acomoda cambios ○ Los requisitos no están congelados ○ No tiene que ser exhaustivo Normalmente, hay un período de aprendizaje entre cada etapa Es más útil cuando los requisitos no están claros. Modelo en Espiral de Desarrollo de Ingeniería de Software Modelo en Espiral Combina elementos del enfoque en cascada y del desarrollo iterativo. Fue propuesto como una alternativa al modelo de desarrollo en cascada, con el objetivo de abordar las limitaciones de este último en proyectos de software más complejos y cambiantes. El modelo en espiral se basa en la idea de que el desarrollo de software es un proceso iterativo y cíclico en el que el producto se va reﬁnando y mejorando a lo largo del tiempo a través de múltiples iteraciones. A medida que el equipo avanza en cada iteración, se aprenden lecciones y se toman en cuenta las experiencias pasadas para mejorar el producto y reducir los riesgos asociados con el desarrollo. Modelo en Espiral Problema “Los usuarios solo ven los sistemas al momento de la implementación cuando ya es muy tarde para hacer cambios” ¿Cómo lo solucionamos? Prototyping Prototyping 1) Façade: 2) Working: Tipo de prototipo que representa la Se reﬁere a una versión funcional o operativa visualización de un concepto de producto o del producto o servicio en desarrollo. servicio. Suelen ser ocupados para identiﬁcar y Suele ser simpliﬁcado o superﬁcial. solucionar problemas, testear usabilidad y experiencia del usuario. Es valiosos dado que permite tener una versión bastante simpliﬁcada antes de 2 tipos de working prototype asignar recursos. Throwaway prototype Evolutionary prototype Working Prototyping: Throwaway y Evolutionary 2.1) Throwaway: 2.2) Evolutionary: En este enfoque, se crea un modelo del En este enfoque, el prototipo se construye y mejora de manera iterativa hasta que se convierte sistema, normalmente usando herramientas en el sistema ﬁnal. bien generales con el objetivo principal de entender los requerimientos del sistema que Este método puede ser muy útil cuando los requerimientos del sistema son difíciles de deﬁnir aún no están claros. al principio, o se esperan que cambien con Una vez que estos requerimientos son frecuencia. entendidos y las funcionalidades están bien Sin embargo, esto también puede llevar a un deﬁnidas, este prototipo se descarta o se tira. código menos óptimo, ya que las iteraciones tempranas del prototipo pueden no haber sido Sin embargo, puede implicar un trabajo "extra" diseñadas con la totalidad del sistema en mente. porque el prototipo se desecha. Si una empresa hace un formulario de Google para pedir la opinión de sus usuarios o clientes, y luego, al ver que funciona crea una web propia para hacer esta encuesta de mejor manera, dejando de lado este google form… ¿Qué tipo de Prototyping podría ser este ejemplo? Etapas Fase de Análisis Comprender el sistema actual y sugerir mejoras y requerimientos funcionales Fase de Prototipeo Construir el prototipo para ser evaluado por usuarios Etapa de Evaluación y Modiﬁcación del Prototipo Puede ser multiples etapas (iterativo) Diseño y desarrollo del sistema objetivo El prototipo constituye la base para la especiﬁcación del sistema Críticas comunes Diseños incompletos e inadecuados – “quick and dirty” Diﬁcultad para administrar y controlar – Falta o mala documentación Se puede convertir “EL” sistema sin la “adecuada” ingeniería Agile ¿Qué es Agile? Agile o "Ágil" es una metodología de desarrollo de software que enfatiza la entrega continua de valor al cliente, la adaptabilidad, y la colaboración constante entre los equipos de desarrollo y los stakeholders (o partes interesadas). Esta metodología promueve el desarrollo iterativo e incremental, en lugar de seguir un plan rígido y predeﬁnido. Agile Manifesto Agile Manifesto Los principios fundamentales de Agile se deﬁnen en el "Maniﬁesto Ágil", que incluye los siguientes puntos clave: Individuos e interacciones sobre procesos y herramientas: El trabajo en equipo y la comunicación eﬁcaz son más valiosos que adherirse estrictamente a las herramientas y procedimientos. Software funcional sobre documentación exhaustiva: Aunque la documentación es importante, Agile prioriza la entrega de software que funcione y aporte valor. Colaboración con el cliente sobre negociación de contratos: La implicación directa del cliente o usuario en el proceso de desarrollo es esencial para entender y satisfacer sus necesidades. Respuesta al cambio sobre seguir un plan: En un entorno de desarrollo de software, las necesidades y requerimientos pueden cambiar rápidamente. Agile promueve la adaptabilidad y ﬂexibilidad para responder a esos cambios. Beneﬁcios de Agile Algunos beneﬁcios incluyen la entrega frecuente de incrementos de productos, la colaboración continua con el cliente, la transparencia en el proceso, y la evaluación continua para maximizar el valor. También resalta la importancia de trabajar con equipos empoderados y autoorganizados, limitando el trabajo en progreso (Limited WIP) para evitar sobrecargas, y desarrollando una arquitectura emergente que sea ﬂexible y respaldada por pruebas automatizadas. Es una colección de metodologías Kanban Kanban (señal visual en Japonés) es un marco popular utilizado para implementar el desarrollo de software ágil y DevOps. Requiere una comunicación en tiempo real de la capacidad y una total transparencia del trabajo. Los elementos de trabajo se representan visualmente en un tablero kanban, lo que permite a los miembros del equipo ver el estado de cada pieza de trabajo en cualquier momento. Kanban Scrum Scrum es un marco que ayuda a los equipos a trabajar juntos.... A menudo considerado como un marco ágil de gestión de proyectos, scrum describe un conjunto de reuniones, herramientas y funciones que funcionan de forma conjunta para ayudar a los equipos a estructurar y gestionar su trabajo. Piense en Scrum como una forma de hacer el trabajo en equipo en pequeñas partes a la vez, con experimentación continua y ciclos de retroalimentación a lo largo del camino para aprender y mejorar a medida que avanza. Es un marco de trabajo que proporciona la estructura justa para que las personas y los equipos se integren en su forma de trabajar, al tiempo que agrega las prácticas adecuadas para optimizar sus necesidades especíﬁcas. Scrum – Ciclo de Vida Scrum Algunos conceptos en torno a Scrum Sprint Un sprint es un período de tiempo deﬁnido durante el cual se realiza un conjunto especíﬁco de actividades. Los sprints generalmente duran entre una y cuatro semanas, durante las cuales el equipo se compromete a completar un conjunto de objetivos o tareas, normalmente expresados como "historias de usuario". Sprints Etapas del sprint Planning (Planificación): En esta etapa, el equipo de desarrollo y el Product Owner se reúnen para planificar el trabajo que se realizará durante el Sprint. Se seleccionan los elementos del Product Backlog que se incluirán en el Sprint Backlog, definiendo los objetivos y las tareas necesarias para cumplir con los requisitos. Implementation (Implementación): Esta fase es el núcleo del Sprint, donde el equipo trabaja en la implementación de las tareas planificadas. El objetivo es completar las funcionalidades acordadas y garantizar que el trabajo cumple con los estándares de calidad esperados. Se sigue un ciclo iterativo e incremental, permitiendo adaptaciones según sea necesario. Review (Revisión): Al final del Sprint, se lleva a cabo una revisión donde el equipo presenta lo que se ha completado durante el Sprint. El Product Owner verifica si los resultados cumplen con los criterios de aceptación y se discuten posibles ajustes o prioridades para futuros Sprints. Retro (Retrospectiva): Después de la revisión, el equipo se reúne para reflexionar sobre el proceso de trabajo en el Sprint. Se identifican áreas de mejora y se proponen cambios para optimizar el rendimiento del equipo en los siguientes Sprints. La retroalimentación es clave para el crecimiento y la mejora continua del equipo. Algunos conceptos en torno a Scrum Backlog Es una lista de pendientes priorizada de tareas o historias de usuario que deben ser completadas. Existen dos tipos: el Product Backlog (que incluye todas las tareas o características deseadas para el producto en su totalidad), y el Sprint Backlog (que es un subconjunto del Product Backlog seleccionado para ser completado durante el próximo sprint). Algunos conceptos en torno a Scrum Increment En Scrum, un incremento es el sumatorio de todos los elementos del Product Backlog completados durante un sprint y todos los sprints anteriores. Es una parte del producto que es funcional y potencialmente entregable, lo que signiﬁca que cumple con los estándares de calidad necesarios para ser utilizado por los usuarios Algunos conceptos en torno a Scrum Retro Abreviatura de "Retrospectiva". Es una reunión que se realiza al ﬁnal de cada sprint, donde el equipo reﬂexiona sobre el sprint pasado. Durante esta reunión, el equipo discute lo que funcionó bien, lo que no y cómo pueden mejorar en el próximo sprint. El objetivo principal de la Retro es promover la mejora continua del proceso de desarrollo. Roles Scrum Roles Scrum: Product Owner El Product Owner es el encargado de optimizar y maximizar el valor del producto, siendo la persona encargada de gestionar el ﬂujo de valor del producto a través del Product Backlog. Es fundamental su labor como interlocutor con los stakeholders y sponsors del proyecto, así como ser altavoz de los requerimientos de los clientes. Si el Product Owner también juega el rol de representante de negocio, su trabajo también aportará valor al producto. Tradicionalmente, se ha entendido la labor del Product Owner como un gestor de requisitos o un cliente que se encarga de gestionar el Product Backlog, pero es mucho más que eso. No solo tiene la responsabilidad de mantener el Product Backlog bien estructurado, detallado y priorizado, sino que además tiene que entender perfectamente que se desea para el producto, debiendo poder explicar y transmitir a los stakeholders cuál es el valor del producto en el que están invirtiendo. Roles Scrum: Product Owner Con cada Sprint, el Product Owner debe hacer una inversión en desarrollo que tiene que producir valor. Marcar el Sprint Goal de manera clara y acordada con el equipo de desarrollo, hace que el producto vaya incrementando constantemente su valor. Es fundamental otorgar el poder necesario al Product Owner para que este sea capaz de tomar cualquier decisión que afecte al producto. En el caso de que el Product Owner no pueda tomar estas decisiones sin consultarlas previamente con otra persona, deberá ser investido para tomarlas él mismo, o ser sustituido por esa persona. A su vez, el Product Owner debe convertirse en el altavoz del cliente, en el transmisor de las demandas y del feedback otorgado por los mismos. Roles Scrum: Scrum Master Tiene dos funciones dentro del marco de trabajo: Gestionar el proceso Scrum: Gestiona y asegura que el proceso Scrum se lleva a cabo correctamente, así como de facilitar la ejecución del proceso y sus mecánicas. Eliminar impedimentos: Ayuda a eliminar progresivamente sus impedimentos que van surgir en la organización y que afectan a su capacidad para entregar valor, así como a la integridad de esta metodología. El Scrum Master debe ser el responsable de velar porque el Scrum se lleve adelante, transmitiendo sus beneﬁcios a la organización facilitando su implementación. Se encarga también de las labores de mentoring y formación, coaching y de facilitar reuniones y eventos si es necesario, además de que el Scrum Master puede que esté compartido entre varios equipos, pero su disponibilidad afectará al resultado ﬁnal del proceso Scrum. Roles Scrum: Scrum Team El equipo de desarrollo suele estar formado por entre 3 a 9 profesionales que se encargan de desarrollar el producto para conseguir entregar un incremento de software al ﬁnal del ciclo de desarrollo. Este encargará de crear un incremento terminado a partir de los elementos del Product Backlog seleccionados (Sprint Backlog) durante el Sprint Planning. Es importante que en la metodología Scrum todos los miembros del equipo de desarrollo conozcan su rol, siendo solo uno común para todos, independientemente del número de miembros que tenga el equipo y cuales sean sus roles internos. Roles Scrum: Scrum Team Cómo el equipo de desarrollo decida gestionarse internamente es su propia responsabilidad y tendrá que rendir cuentas por ello como uno solo; hay que evitar intervenir en sus dinámicas. Habitualmente son equipos ‘cross-funcional’, capaces de generar un incremento terminado de principio a ﬁn, sin otras dependencias externas. Ejemplo en marketing Ejemplo en data science Ceremonias y artefactos Ejemplo: Daily stand-up Ejemplo: Daily stand-up 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 ﬁnal, 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 Para que una historia de usuario se considere lista por parte del equipo de desarrollo se ha de establecer un criterio. Uno de los más comunes es INVEST: INDEPENDENT: Mínimo nivel de descomposición funcional pero con identidad propia. NEGOTIABLE: Su implementación debe ser ﬂexible según restricciones y requisitos de negocio. VALUABLE: Representa un incremento del producto que se puede demostrar a un usuario. ESTIMABLE: El equipo cuenta con el conocimiento suﬁciente para poder realizar una estimación del tiempo de implementación. SIZED TO FIT: Se puede completar en un sprint (intervalo preﬁjado en el que se entrega un incremento del producto) para minimizar el time to market y la recogida de feedback. TESTABLE: Que se podrá veriﬁcar que se han cubierto las necesidades de los usuarios de la forma esperada Historias de usuario El User Story Mapping es un método para organizar en un mapa las historias de usuarios de forma que consigamos crear una visión más holística de cómo encajan en la experiencia general del usuario. EJE HORIZONTAL DEL MAPA Marcamos los pasos fundamentales del Customer Journey deﬁnido para el producto en su fase de ideación. Se ordenan cronológicamente de izquierda a derecha según el usuario va avanzando en su experiencia. EJE VERTICAL Representa la prioridad otorgada a cada historia de usuario ordenada previamente en el eje horizontal. En la parte superior se recogen las funcionalidades a incluir en el MVP, y en los niveles siguientes se van deﬁniendo nuevos releases del producto. Epics En el contexto del desarrollo de software ágil, un "Epic" es un elemento de trabajo grande que no puede ser completado en un solo sprint (el sprint es un período de tiempo ﬁjo durante el cual se realiza cierto trabajo, normalmente entre una y cuatro semanas). Los epics son esencialmente agrupaciones de historias de usuario relacionadas que juntas cumplen una meta mayor o funcionalidad completa del producto. Epics - ejemplo Por ejemplo, si estás desarrollando una aplicación de comercio electrónico, podrías tener un epic llamado "Gestión del carrito de compras", que incluiría varias historias de usuario como "Como usuario, quiero añadir productos a mi carrito" "Como usuario, quiero eliminar productos de mi carrito" "Como usuario, quiero cambiar la cantidad de un producto en mi carrito", etc. Jerarquía de Epics / User Stories Mi experiencia con Agile eXtreme Programming (XP) ¿Cómo funciona? Iterativo, pequeñas entregas de software en cada iteración (1-2 semanas) Técnicas: ○ User Stories (”As a… i’d like to… so that…”) ○ Planiﬁcación a 3 niveles Planiﬁcación de liberaciones (releases) Planiﬁcación de iteración Planiﬁcación diaria ○ Mapeo de historias ○ Descomposición de historias (ej. Epics) ○ Elaboración de historias Gente: Cliente, Desarrollador, Monitor The XP loop Flujo XP Agile vs XP Dimensión Agile XP Duración de la iteración 2-4 semanas 1-2 semanas ¿Puedes hacer cambios en la No, el Scrum Master debe proteger Sí, siempre y cuando el tiempo sea iteración? que no se hagan cambios similar ¿Requiere priorizar las características No Sí / pedidas? Prácticas de ingeniería Son estrictas, pero no tanto como XP Son muy estrictas. Hay poco espacio a ﬂexibilidad para hacer todo tan rápido Técnicas Scrum, Kanban Programación en parejas, desarrollo orientado por pruebas, etc Resumen Las metodologías formales consisten en gente, herramientas y técnicas Proveen estructura para la planiﬁcación y administración de proyectos Cuando son utilizadas de mala forma, pueden sofocar un proyecto y limitar soluciones creativas Cuando son utilizadas bien, proveen una estructura para el diseño y desarrollo creativo. Nunca sigas a ciegas una metodología. Cada proyecto es diferente. Gracias [email protected] [email protected] 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 deﬁnir lo que debe hacer el sistema? Deﬁnir 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 🔍 Identiﬁcar Stakeholders ⁉ Y para ello debemos averiguar… ¿Quién gana y quién pierde con este desarrollo? ✅ Necesitamos identiﬁcar 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 conﬁar? ¿Quién controla los recursos? ¿Quién tiene las habilidades que se necesitan para el proyecto? ¿Quién tiene inﬂuencia? 🎯 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íﬁco 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 identiﬁcar problemas 748 × 561 y hacer ajustes. Tipos: 1. Facade (maqueta simpliﬁcada) 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 Identiﬁcar 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 Identiﬁca áreas que necesitan más investigación Crear preguntas de seguimiento y nuevas entrevistas para clariﬁcar á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 deﬁnen 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 conﬁrmar 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 ﬁnal. 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 ﬁnal, 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. Beneﬁcios de utilizar historias de usuarios Pone a las personas en primer lugar. Pone a los usuarios ﬁnales 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 conﬁrmar ○ Suposiciones y Aﬁrmaciones ○ Reglas de Negocio Usualmente se les involucra ○ En los Workshops y sesiones JAD ○ Revisión y reﬁnamiento 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 signiﬁcativas 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 “oﬁcial 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 especiﬁcaciones 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 ○ Identiﬁcar 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]

ilovepdf_merged.pdf

Related

Transcript

Tags

Upgrade to continue