Resumen MSI 1P PDF

Capítulo 1: Introducción a los Sistemas de Información Ralph M. Stair y George W. Reynolds 1.1 Definición de Sistemas de Información (SI) Un Sistema de Información (SI) es un conjunto de componentes interrelacionados que trabajan en conjunto para recopilar, procesar, almacenar y distribuir informaci...

Capítulo 1: Introducción a los Sistemas de Información Ralph M. Stair y George W. Reynolds 1.1 Definición de Sistemas de Información (SI) Un Sistema de Información (SI) es un conjunto de componentes interrelacionados que trabajan en conjunto para recopilar, procesar, almacenar y distribuir información, con el objetivo de apoyar la toma de decisiones, la coordinación y el control dentro de una organización. Los SI ayudan a gestionar las operaciones y mejorar la eficiencia, además de proporcionar herramientas para el análisis de problemas y la creación de nuevos productos. 1.2 Datos, Información y Conocimiento Datos: Son hechos sin procesar, como números o descripciones. Por ejemplo, las cifras de ventas diarias en una tienda. Estos datos no tienen un valor significativo hasta que son organizados. Información: Surge cuando los datos son procesados para tener un contexto y un propósito. La información es más útil que los datos porque proporciona una base para la toma de decisiones. Por ejemplo, las cifras de ventas procesadas pueden mostrar qué productos se vendieron más. Conocimiento: Es el uso e interpretación de la información para tomar decisiones bien fundamentadas. Cuando la información se convierte en conocimiento, puede generar ventajas competitivas. Por ejemplo, saber que ciertos productos se venden mejor en determinados días permite tomar decisiones estratégicas de marketing. 1.3 ¿Qué es un Sistema? Un sistema es un conjunto de elementos que interactúan entre sí para lograr un objetivo común. Todos los sistemas tienen componentes, límites, entradas, salidas y retroalimentación. Estos elementos interactúan entre sí y con su entorno, funcionando como un todo. Componentes de un Sistema: o Entradas: Lo que el sistema recibe para procesar. En un SI, las entradas pueden ser datos brutos. o Procesamiento: La transformación de las entradas en un producto útil. En un SI, esto podría ser el análisis de datos o la generación de informes. o Salidas: Los resultados del procesamiento. En un SI, las salidas suelen ser información útil para la toma de decisiones. o Retroalimentación: Es la información sobre las salidas que se utiliza para ajustar las entradas o el procesamiento futuro. Permite mejorar el funcionamiento del sistema. o Límites del Sistema: Definen lo que está dentro del sistema y lo que queda fuera. Establecen las fronteras del sistema y sus interacciones con el entorno. 1.4 Tipos de Sistemas de Información Los Sistemas de Información pueden clasificarse de diferentes formas según el nivel organizacional que apoyen y la función que desempeñan. Sistemas de Procesamiento de Transacciones (TPS): Se encargan de registrar las transacciones diarias que suceden en una organización, como las ventas o compras. Su objetivo es la eficiencia operativa. Sistemas de Información Gerencial (MIS): Estos sistemas ayudan a los gerentes a tomar decisiones al proporcionar informes regulares sobre el desempeño de la organización. Los MIS convierten los datos de los TPS en información útil para la gestión. Sistemas de Apoyo a la Toma de Decisiones (DSS): Son sistemas que ayudan a la toma de decisiones complejas o no rutinarias, proporcionando herramientas de análisis, simulación y modelado. Sistemas Expertos (ES): Imitan el proceso de toma de decisiones de expertos humanos en áreas específicas, utilizando reglas y bases de conocimiento. 1.5 Los Componentes de un Sistema de Información Un SI incluye cinco componentes principales: 1. Personas: Los usuarios que interactúan con el sistema, tanto los que introducen datos como los que usan los resultados para tomar decisiones. 2. Hardware: Los dispositivos físicos que soportan el SI, como computadoras, servidores y dispositivos de almacenamiento. 3. Software: Los programas y aplicaciones que procesan los datos y generan información. 4. Datos: Son los hechos brutos que se ingresan al sistema para ser procesados. Los datos bien estructurados son esenciales para producir información valiosa. 5. Procedimientos: Las políticas y reglas que guían el uso del SI, asegurando que se opere correctamente y de manera eficiente. 1.6 Entrada, Procesamiento, Salida y Retroalimentación Un SI sigue un ciclo que se puede describir en cuatro pasos fundamentales: Entrada: Los datos se ingresan en el sistema desde diversas fuentes, como registros de ventas, encuestas o cualquier otro medio que recoja información relevante para la organización. Procesamiento: Los datos ingresados son transformados en información útil a través de diversas operaciones, como la clasificación, el cálculo o la agregación. Salida: Es el producto final del procesamiento de los datos. Puede ser un informe, una gráfica, un análisis o cualquier otra forma de presentación de la información que permita la toma de decisiones. Retroalimentación: La salida o resultados del SI se utilizan para hacer ajustes en las entradas o en el procesamiento, mejorando así el sistema. La retroalimentación  es crucial para ajustar el sistema en tiempo real y corregir posibles errores o desajustes. Capítulo 1: La Naturaleza del Software – Roger S. Pressman 1.1 ¿Qué es el Software? El software es un conjunto de programas, datos y documentación que permiten realizar tareas específicas en una computadora. Además de ser intangible, el software tiene varias características que lo distinguen de otros productos de ingeniería: es fácil de modificar, no se degrada, y muchas veces se desarrolla de manera personalizada, lo que introduce complejidades adicionales. El software tiene varias características únicas: Instrucciones lógicas que determinan el comportamiento del sistema. Es fácil de modificar, pero los cambios pueden introducir errores. No se degrada, pero puede volverse obsoleto. Requiere un desarrollo personalizado, lo que lo hace más difícil de reutilizar. 1.6 ¿Qué es la Ingeniería de Software? La ingeniería de software es la disciplina que aplica principios de ingeniería al desarrollo y mantenimiento del software. Su objetivo es asegurar que el software sea confiable, eficiente y mantenible a lo largo del tiempo. Se enfoca en un enfoque sistemático para resolver problemas técnicos y organizativos. Aspectos clave: Métodos y herramientas: Utiliza técnicas y tecnologías organizadas, como análisis de requisitos, diseño y pruebas. Calidad y eficiencia: El objetivo es desarrollar software que cumpla con los requisitos del cliente. Enfoque sistemático: Aplica principios organizados para crear productos de software de alta calidad. 1.7 El Proceso del Software El proceso del software es un conjunto de actividades que se llevan a cabo para desarrollar software, organizando el trabajo de manera estructurada. Generalmente, un proceso de software incluye las siguientes fases: 1. Comunicación: Interacción entre desarrolladores y clientes para entender los requisitos. 2. Planificación: Se elaboran cronogramas y se asignan recursos. 3. Modelado: Se analiza y modela el problema y se propone una solución técnica. 4. Construcción: Fase de codificación y pruebas.  5. Despliegue: El software se entrega al cliente y se pone en operación. Estas fases se repiten y refinan según las necesidades del proyecto. Actividades Sombrillas del Proceso del Software Estas actividades abarcan todo el ciclo de vida del desarrollo de software, independientemente del modelo de proceso utilizado. Incluyen: Gestión de la configuración: Controlar y gestionar los cambios en el software. Garantía de calidad: Asegurar que el software cumple con los estándares y requerimientos de calidad. Revisión técnica: Revisiones formales para detectar errores en fases tempranas. Medición del software: Medir diversos aspectos del proceso de desarrollo y del producto de software. Gestión de riesgos: Identificar y mitigar riesgos potenciales a lo largo del proyecto. 1.8 El Modelo de Proceso del Software Un modelo de proceso describe la forma en que se organiza el desarrollo de software. Existen varios modelos, cada uno adaptado a diferentes tipos de proyectos: 1. Modelo en Cascada: Sigue un enfoque secuencial donde las fases de análisis, diseño, codificación, pruebas y mantenimiento se realizan una después de la otra. Es fácil de entender, pero rígido frente a cambios. 2. Modelo en V: variante del modelo de la cascada que ofrece una visualización más explícita de las fases de verificación y validación del proceso de desarrollo de software. Cada fase de desarrollo tiene una fase correspondiente de pruebas y validación. 3. Modelo de Prototipado: Se desarrolla un prototipo para que el cliente pueda probar y proporcionar retroalimentación. Ideal para cuando los requisitos no están claros desde el inicio. 4. Modelo de Desarrollo Incremental: El software se desarrolla en incrementos funcionales. Cada versión ofrece una parte funcional del sistema, que puede usarse o probarse mientras se completa el resto.  5. Modelo en Espiral: Combina el modelo en cascada con un enfoque iterativo, incluyendo análisis de riesgos. Se enfoca en la evaluación continua del progreso y ajustes del proyecto conforme se descubren nuevas necesidades. 6. Modelo de Desarrollo Ágil: Prioriza la colaboración constante con el cliente y la entrega iterativa de software funcional. Se adapta fácilmente a cambios en los requisitos, favoreciendo ciclos cortos de desarrollo como "sprints". Flujos de Proceso: Lineal: Las actividades se ejecutan en secuencia, comenzando por la comunicación y terminando con el despliegue. Iterativo: Se repiten una o más actividades antes de pasar a la siguiente. Evolutivo: Las actividades se realizan de manera circular, con cada ciclo generando una versión más completa del software.  Paralelo: Se ejecutan múltiples actividades simultáneamente (por ejemplo, modelado y construcción en paralelo). 1.9 El Modelo Extendido de Proceso del Software El modelo extendido incluye actividades adicionales que no forman parte directamente del desarrollo del software, pero son esenciales para asegurar la calidad y el éxito del proyecto: 1. Gestión de Proyectos de Software: Planificación y control de recursos, tiempo y esfuerzo. 2. Control de la Configuración del Software: Manejo de cambios en el software para evitar la introducción de errores.  3. Garantía de Calidad del Software: Actividades para asegurar que el software cumple con los estándares de calidad. 4. Revisión Técnica Formal: Evaluaciones regulares para identificar problemas en las primeras fases del desarrollo. 5. Mantenimiento del Software: Incluye corrección de errores y actualización de características. 1.10 Las Capas de la Ingeniería de Software La ingeniería de software se organiza en capas que proporcionan una base sólida para el desarrollo de productos de software. Estas capas son: 1. Capa de Proceso: o Proporciona un marco de trabajo para organizar y gestionar las actividades necesarias para el desarrollo de software, desde la definición de requisitos hasta el despliegue y mantenimiento. 2. Capa de Métodos: o Incluye técnicas y enfoques utilizados en el desarrollo del software. Estas técnicas aseguran que se sigan procedimientos sistemáticos y organizados. 3. Capa de Herramientas: o Las herramientas de software son tecnologías que automatizan o apoyan en la realización de las tareas. Los entornos de desarrollo integrado (IDE), sistemas de control de versiones y herramientas de prueba son ejemplos de esta capa. 4. Capa de Gestión de Calidad: o Esta capa asegura que todos los procesos y métodos se orienten a producir software de alta calidad. Se incluyen actividades de control y mejora continua a lo largo del ciclo de vida del proyecto. 1. Ingeniería de Requerimientos: Definición y Propósito – Ian Sommerville La ingeniería de requerimientos es el proceso de descubrir, analizar, documentar y validar los servicios que un sistema debe proporcionar y las restricciones bajo las cuales debe operar. Este proceso es crítico en el desarrollo de software porque define las bases para el diseño y la implementación. Requerimientos: Se refiere a una descripción del servicio que el sistema debe proporcionar o las restricciones en su desarrollo y operación. Los requerimientos pueden variar desde descripciones de alto nivel hasta especificaciones detalladas. 2. Tipos de Requerimientos Los requerimientos se dividen en dos categorías principales:  Requerimientos funcionales: Estos describen lo que debe hacer el sistema. Son declaraciones de las funciones, servicios o comportamientos específicos que el sistema debe realizar. Ejemplos de requerimientos funcionales incluyen cómo el sistema debe responder a determinadas entradas, cómo debe comportarse en situaciones particulares o qué servicios específicos debe ofrecer a los usuarios. o Requerimientos de transacción: Especifican cómo el sistema debe manejar las transacciones. o Requerimientos de usuario: Definen cómo los usuarios interactúan con el sistema. o Requerimientos de sistema: Detallan las interacciones con otros sistemas. Un ejemplo podría ser: "El sistema debe permitir a los usuarios recuperar su contraseña si la olvidan". Requerimientos no funcionales: Estos describen las restricciones sobre los servicios o funciones ofrecidos por el sistema. Pueden incluir restricciones de tiempo, capacidad, normas de calidad, rendimiento, seguridad, usabilidad, confiabilidad, mantenimiento, portabilidad, etc. Aunque no están directamente relacionados con las funciones del sistema, son cruciales para su éxito. o Requerimientos de rendimiento: Definen el tiempo de respuesta y capacidad del sistema. o Requerimientos de seguridad: Detallan las medidas necesarias para proteger el sistema. o Requerimientos de usabilidad: Describen la facilidad de uso del sistema. o Requerimientos de mantenimiento: Definen la facilidad con la que se pueden realizar actualizaciones y reparaciones. Ejemplo: "El sistema debe ser capaz de manejar hasta 10,000 usuarios simultáneamente". Estos requerimientos a menudo son más críticos que los funcionales, ya que pueden determinar si un sistema es aceptable para su uso en situaciones prácticas. Requerimientos de dominio: Estos son requerimientos derivados del entorno o dominio de la aplicación. Reflejan las particularidades específicas de la industria o área en la que se utiliza el sistema. Requerimientos Duraderos y Volátiles Requerimientos Duraderos: Son estables y tienden a permanecer sin cambios a lo largo del tiempo, como los relacionados con las reglas básicas de negocio o normativas legales. Requerimientos Volátiles: Son susceptibles a cambios debido a la evolución de las necesidades del usuario, el entorno de negocio o la tecnología. 3. Especificación de Requerimientos La especificación de requerimientos es el proceso de escribir los requerimientos de forma sistemática, con la finalidad de que sean entendidos tanto por los clientes como por los desarrolladores. Existen diferentes formas de especificar los requerimientos:  Especificaciones de usuario: Documentos legibles para los usuarios, que definen las funciones y restricciones del sistema de manera clara y accesible para personas sin conocimientos técnicos. Especificaciones del sistema: Documentos más técnicos que detallan los requerimientos desde un punto de vista técnico para los desarrolladores de software. Incluyen detalles como modelos de datos, diagramas de interacción y descripciones técnicas. Una especificación adecuada ayuda a evitar malentendidos y asegura que el desarrollo del sistema esté alineado con las expectativas del cliente. 4. Ingeniería de Requerimientos: Procesos y Actividades El proceso de ingeniería de requerimientos abarca varias actividades: Recopilación y Elicitación de requerimientos: Interacción con usuarios finales, clientes y otras partes interesadas para identificar sus necesidades y deseos. Se utilizan técnicas como entrevistas, cuestionarios, grupos focales, análisis de documentos y observación directa. Análisis de requerimientos: Interpretación de los requerimientos recopilados para asegurar que sean completos, consistentes y claros. Se identifican conflictos entre requerimientos y se evalúan sus prioridades. Modelado y especificación:Documentación precisa de los requerimientos mediante modelos como diagramas de flujo, casos de uso y modelos de datos. Se busca crear una representación clara para usuarios y detallada para desarrolladores. Validación de requerimientos:Verificación de que los requerimientos sean correctos, completos y viables. Se asegura que el sistema cumpla con las expectativas del cliente mediante prototipos, revisiones y casos de prueba. Gestión de requerimientos: Control de los cambios en los requerimientos a lo largo del proyecto. Incluye la gestión de versiones, análisis del impacto de cambios y ajuste de expectativas del cliente y del equipo. 5. Problemas Comunes en la Ingeniería de Requerimientos Existen varios desafíos en la ingeniería de requerimientos, como: Ambigüedad: Los requerimientos mal definidos o ambiguos pueden causar confusión y errores durante el desarrollo. Es importante que los requerimientos sean claros y específicos. Incompletitud: A veces, no se identifican todos los requerimientos necesarios, lo que puede llevar a que el sistema no cubra todas las expectativas del cliente. Conflictos entre requerimientos: Diferentes partes interesadas pueden tener diferentes prioridades o expectativas, lo que puede generar conflictos. Es esencial resolver estos conflictos de manera efectiva. 6. Requerimientos en los Sistemas Ágiles En los enfoques ágiles, los requerimientos son mucho más dinámicos. Se recogen de manera continua a lo largo del proyecto y se gestionan a través de historias de usuario y backlog. En lugar de una especificación exhaustiva al inicio, se priorizan las funcionalidades y se ajustan en iteraciones, con la colaboración constante de los clientes y usuarios. UNIDAD 2 1. Definición de Proyecto Un proyecto es un conjunto de actividades temporales diseñadas para alcanzar un objetivo único, dentro de un plazo y presupuesto determinados. El PMBOK define un proyecto como un esfuerzo temporal para crear un producto, servicio o resultado único, y se destacan varios puntos importantes: Un proyecto tiene un inicio y un fin definidos. Utiliza recursos limitados. Tiene un alcance claro y un presupuesto preestablecido. ¿Qué es una metodología? Una metodología de gestión de proyectos es un marco estructurado que proporciona pautas, procesos y técnicas para planificar, ejecutar y completar un proyecto con éxito. Metodología se refiere al estudio de los métodos en un campo particular de investigación. Es decir, se enfoca en la descripción, explicación y justificación de los métodos utilizados en una disciplina específica, en lugar de los métodos mismos. 2. Alcance o Scope del Proyecto El alcance de un proyecto define el trabajo que se necesita realizar para completar un proyecto y es crucial para evitar la adición no controlada de tareas y requisitos. Los procesos clave para la gestión del alcance incluyen: Planificación de la gestión del alcance: Especificar cómo se va a definir y gestionar el alcance. Recopilación de requisitos: Determinar las necesidades de las partes interesadas. Definición del alcance: Detallar los entregables y el trabajo necesario. Creación de la Estructura de Desglose del Trabajo (WBS): Descomponer el trabajo en componentes más pequeños y manejables. Validación y control del alcance: Asegurar que los entregables sean aceptados formalmente y que el proyecto no se desvíe. Un ejemplo aplicado en el desarrollo de software es definir qué funcionalidades como carrito de compras o búsqueda de productos serán parte del proyecto. Cualquier cambio en estos requisitos debe ser gestionado formalmente para evitar sobrecostos o retrasos. 3. Restricciones del Proyecto Las restricciones clave en un proyecto incluyen tiempo, costo y alcance. Estas conforman la Triple Restricción, y cualquier cambio en una de ellas afecta inevitablemente a las demás. La calidad del proyecto depende del equilibrio entre estas tres restricciones. En un proyecto de desarrollo de software, si el cliente solicita una nueva funcionalidad, esto puede extender el tiempo de entrega y aumentar el costo, a menos que se ajuste el alcance o se recorten otras áreas. Evolución de la Triple Restricción Además de las tres restricciones tradicionales, hoy en día se incluyen calidad, riesgos y recursos. Esto refleja la creciente complejidad de los proyectos modernos, donde no solo se debe considerar el tiempo, costo y alcance, sino también la gestión efectiva de la calidad del producto, la mitigación de riesgos y la optimización de los recursos. 4. Gestión Predictiva o Clásica La gestión predictiva es la metodología tradicional en la que se planifica detalladamente todo el ciclo de vida del proyecto desde el principio. Pressman menciona que este enfoque es adecuado cuando los requisitos son claros y estables. Las fases incluyen: Planificación detallada de todas las tareas. Desarrollo de un plan de proyecto que cubra todas las etapas. Gestión y control continuo para asegurar que el proyecto siga el plan. Ejemplo aplicado: En proyectos de construcción, este enfoque garantiza que el trabajo se realice conforme a un cronograma y presupuesto fijo, donde el proceso es altamente controlado y secuencial. 5. Gestión Ágil La agilidad es un enfoque más reciente que responde a la necesidad de gestionar proyectos en entornos dinámicos, donde los requisitos cambian con frecuencia. Se enfoca en ciclos de entrega cortos, flexibilidad y colaboración constante con el cliente. ¿Qué es la agilidad? La agilidad implica la capacidad de adaptarse rápidamente a los cambios en los requisitos del proyecto. En "Scrum Manager", se destacan los valores clave de la agilidad, tales como: Colaboración con el cliente por encima de contratos rígidos. Respuesta rápida al cambio más que seguir un plan estricto. Enfoque en personas e interacciones sobre herramientas y procesos. Resultados funcionales sobre documentación extensa. User Stories son descripciones breves y simples de funcionalidades descritas desde la perspectiva del usuario final. Se estructuran típicamente en el formato: COMO[tipo de usuario] QUIERO[función] PARA[objetivo o beneficio] Las historias de usuario ayudan a gestionar el alcance y facilitar la comunicación con el cliente en proyectos ágiles. Clasificación de User Stories: Temas(features): agrupan varias épicas o historias de usuario que están relacionadas conceptualmente o que se dirigen a un área específica del producto. Los temas son útiles para organizar el trabajo por áreas funcionales o por objetivos estratégicos más amplios. Épicas: iniciativa o funcionalidad que suele ser demasiado grande para completarse en un solo sprint. Generalmente se dividen en historias de usuario más pequeñas. Historias de usuario estándar: Describen una funcionalidad que puede completarse en un solo sprint. Criterios de aceptación: Cada historia debe tener criterios claros que indiquen cuándo se considera terminada. Ventajas de las User Stories: 1. Facilitan la comunicación entre el equipo y los stakeholders. 2. Proporcionan una visión clara del valor para el cliente. 3. Se pueden priorizar fácilmente en función del valor del negocio. Medición y Estimación Ágil En los proyectos ágiles, la medición se utiliza para evaluar el progreso del equipo, mientras que la estimación se utiliza para prever el esfuerzo necesario para completar tareas futuras. Técnicas como "Planning Poker" o el uso de "historias de usuario" son comunes en la estimación ágil. Agilidad y el costo del cambio Uno de los principios clave del agilismo es que el costo de cambiar los requisitos se reduce a lo largo del ciclo de vida del proyecto, permitiendo que las modificaciones se realicen sin generar grandes impactos en tiempo y presupuesto, algo difícil de lograr en enfoques predictivos. Manifesto Ágil y Enfoques Ágiles Valores del Manifiesto Ágil: 1. Individuos e interacciones sobre procesos y herramientas. 2. Software funcionando sobre documentación extensiva. 3. Colaboración con el cliente sobre la negociación de contratos. 4. Respuesta ante el cambio sobre seguir un plan. 12 principios del Manifiesto Ágil: 1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor. 2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. 3. Entregamos software funcional con frecuencia, en un plazo de entre unas semanas y unos meses. 4. Los responsables de negocio y los desarrolladores trabajan juntos de forma cotidiana a lo largo del proyecto. 5. Los proyectos se desarrollan en torno a individuos motivados, quienes deben contar con el entorno y el apoyo necesario. 6. La conversación cara a cara es el método más eficiente y efectivo para comunicar información. 7. El software en funcionamiento es la medida principal del progreso. 8. Los procesos ágiles promueven el desarrollo sostenible. 9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad. 10. La simplicidad es esencial. 11. Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados. 12. A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo y ajusta su comportamiento en consecuencia. 6. Scrum Scrum es uno de los marcos ágiles más populares, con un enfoque en la entrega de productos mediante ciclos iterativos y colaborativos. Definition of Done (DoD) DoD es una lista de criterios que deben cumplirse para que una historia o incremento se considere terminado, los definen los equipos por sí mismos. Puede incluir aspectos como: pasar todas las pruebas, la documentación esté actualizada, la revisión del código esté completa, y la funcionalidad esté desplegada y aprobada por el Product Owner. Origen de Scrum Scrum fue introducido por Ken Schwaber y Jeff Sutherland a mediados de los años 90 como una respuesta a la necesidad de un enfoque más flexible en el desarrollo de productos. Pilares de Scrum Scrum se basa en tres pilares fundamentales: Transparencia: Toda la información sobre el proyecto debe estar disponible para todas las partes interesadas. Inspección: Los artefactos y el progreso deben ser revisados frecuentemente. Adaptación: Los planes y estrategias deben ajustarse en función de las inspecciones y el progreso del proyecto. Ciclo de Scrum El ciclo de Scrum se divide en sprints, períodos cortos de trabajo que generalmente duran entre 2 y 4 semanas, al final de los cuales se entrega un incremento funcional del producto. Scrum Técnico y Scrum Avanzado Scrum Técnico: Se refiere a la aplicación de Scrum con un enfoque en los aspectos técnicos del desarrollo, como la implementación de buenas prácticas de codificación, automatización de pruebas y diseño técnico de alta calidad. Scrum Avanzado: Se centra en mejorar la eficiencia y efectividad del equipo Scrum mediante la optimización de los procesos de colaboración, la implementación de métricas avanzadas y la resolución de problemas complejos en proyectos grandes o distribuidos. Roles: 1. Product Owner: o Responsable de maximizar el valor del producto y gestionar el backlog del producto. o Comunica las prioridades del negocio al equipo y toma decisiones sobre el producto. o Representa los intereses del cliente y las partes interesadas.  2. Scrum Master: o Facilita la implementación de Scrum y elimina obstáculos para el equipo. o Asegura que el equipo siga los principios y valores de Scrum. o Promueve la auto-organización y mejora continua del equipo. 3. Development Team: o Un equipo multifuncional que es responsable de crear los incrementos del producto. o El equipo debe ser pequeño y auto-organizado. o Son responsables de completar las tareas durante el sprint. Artefactos: 1. Product Backlog: o Es una lista priorizada de todo lo que se necesita en el producto. o Se actualiza continuamente y el Product Owner es responsable de gestionarlo. 2. Sprint Backlog: o Es el conjunto de elementos del Product Backlog que se seleccionan para ser trabajados en un sprint. o Incluye las tareas que el equipo se compromete a completar durante el sprint. 3. Incremento: o Es el producto funcional que debe estar en un estado "DONE" al final de cada sprint. o Cada incremento es acumulativo y debe estar completamente probado. Ceremonias de Scrum: Sprint Planning: En esta reunión, el equipo planifica el trabajo para el próximo sprint. El Product Owner presenta las historias de usuario prioritarias y el equipo decide qué puede completar durante el sprint. o Duración: 2-4 horas para un sprint de dos semanas. Daily Scrum: Reunión diaria de 15 minutos donde el equipo discute el progreso hacia el objetivo del sprint. o Duración: 15 minutos diarios. Sprint Review: Al final del sprint, el equipo presenta el incremento completado al Product Owner y otras partes interesadas para obtener retroalimentación. o Duración: 1-2 horas.  Sprint Retrospective: Revisión de lo que salió bien y qué se puede mejorar en el próximo sprint. o Duración: 1 hora. MVP (Producto Mínimo Viable) El MVP (Minimum Viable Product) es una versión básica de un producto que incluye solo las funcionalidades esenciales para comenzar a entregar valor al usuario y recibir retroalimentación. El concepto central del MVP es probar rápidamente una idea en el mercado para aprender de los usuarios reales sin invertir demasiado tiempo ni recursos en el desarrollo de funcionalidades avanzadas. Ejemplo: Si estás construyendo una aplicación de entrega de alimentos, el MVP incluiría solo la funcionalidad básica de búsqueda de restaurantes y pedido de comida, sin características avanzadas como recomendaciones personalizadas o programas de lealtad. Story Points (SP) Los Story Points son una unidad de medida utilizada en Scrum para estimar el esfuerzo necesario para completar una historia de usuario. No están vinculados directamente a horas, sino que representan la complejidad, la cantidad de trabajo o esfuerzo y los riesgos o incertidumbre asociados con una historia. Métodos para calcular Story Points: 1. Planning Poker: Es una técnica comúnmente utilizada para estimar Story Points. Cada miembro del equipo asigna un puntaje a la historia de usuario usando una baraja de números (normalmente basada en la secuencia de Fibonacci), y luego se discuten las diferencias hasta llegar a un consenso. 2. Tamaño relativo: Los Story Points se basan en la comparación entre historias. Por ejemplo, si una historia que se completó previamente tenía 3 puntos y la nueva historia parece dos veces más compleja, entonces se podría asignar 6 Story Points. Spikes Un spike en Scrum es una tarea de investigación cuyo objetivo es reducir la incertidumbre técnica, funcional o de diseño. Los spikes son especialmente útiles cuando el equipo se enfrenta a un desafío desconocido y necesitan investigar antes de comprometerse con una solución. Tipos de spikes: Spike técnico: Implica investigar tecnologías, herramientas o frameworks que el equipo no ha utilizado antes. Spike funcional: Se utiliza para entender mejor los requisitos del cliente o usuario. Ejemplo: Si el equipo está considerando usar una nueva base de datos para la aplicación, pueden realizar un spike para investigar si esa base de datos cumple con los requisitos de escalabilidad y rendimiento. Capacidad y Velocidad en Scrum  Capacidad: Es la cantidad de trabajo que el equipo es capaz de completar en un sprint, generalmente medida en Story Points o tiempo disponible. Se calcula considerando el tamaño del equipo, las horas disponibles y cualquier impedimento que pueda reducir la capacidad total. Velocidad: Es la cantidad promedio de trabajo completado por el equipo durante un sprint, medida en Story Points. Se utiliza para estimar cuántos puntos pueden completarse en sprints futuros. Diferentes situaciones: 1. Capacidad y Velocidad iguales: o Esto significa que el equipo estimó bien su capacidad de trabajo, y al final del sprint completaron exactamente lo que planificaron. o Causa: Buen manejo del planning, estimaciones realistas, ausencia de bloqueos. o Consecuencia: El equipo tiene una buena comprensión de su rendimiento y puede hacer estimaciones más fiables a futuro. 2. Capacidad mayor que la Velocidad (Subrendimiento): o Aquí la capacidad planificada es mayor que la velocidad real, lo que significa que el equipo no completó todo lo que había planificado para el sprint. o Causa: Bloqueos, tareas subestimadas, falta de claridad en requisitos, emergencias no previstas, cambios de alcance. o Consecuencia: El equipo podría estar sobreestimando su capacidad real de entrega, lo que puede llevar a ajustes futuros. 3. Velocidad mayor que la Capacidad (Sobreproducción): o En este caso, el equipo terminó más trabajo de lo que había planeado, lo que indica que su capacidad estimada era menor que su rendimiento real. o Causa: Subestimación de la complejidad de las tareas, alta productividad, mayor eficiencia en la ejecución. o Consecuencia: El equipo podría estar infrautilizando su capacidad, y podrían planificar más trabajo en futuros sprints. Grafico de Quemado (Burn Down Charts) Los gráficos de quemado o Burn Down Charts en Scrum son herramientas visuales que permiten hacer seguimiento del progreso de un Sprint o un proyecto. Estos gráficos muestran la cantidad de trabajo que queda por hacer y cómo va evolucionando día a día o iteración por iteración. 1. Situación prevista o ideal (Burn Down Chart Ideal) Este gráfico muestra cómo debería ir quemándose el trabajo si todo va según lo planificado. Es una línea recta que desciende uniformemente desde la cantidad total de trabajo hasta cero al final del sprint.  Eje Y (vertical): cantidad de trabajo restante (pueden ser horas o historias de usuario). Eje X (horizontal): tiempo, generalmente días o iteraciones. En el gráfico ideal, la pendiente de la línea muestra el ritmo constante al que se debería reducir el trabajo día a día. Ejemplo gráfico: Supón que tienes 50 horas de trabajo al inicio del sprint. El sprint dura 10 días. La línea ideal desciende uniformemente de 50 a 0 en 10 días. 2. Situación optimista En esta situación, el equipo está avanzando más rápido de lo previsto. El gráfico de quemado descendería más rápido que la línea prevista (ideal), lo que indica que se está terminando más trabajo cada día que lo originalmente planificado. Consecuencia: El trabajo podría terminar antes de lo esperado. Ejemplo gráfico: Se empieza con 50 horas y, en lugar de disminuir a un ritmo constante, el equipo quema más trabajo en los primeros días, y en el día 7 o 8 ya han terminado el trabajo. 3. Situación pesimista Este gráfico refleja una situación en la que el equipo está quemando menos trabajo del esperado. La línea en el gráfico es más plana que la línea ideal, lo que indica que hay más trabajo acumulado y posiblemente no se termine a tiempo. Consecuencia: Es probable que no se termine todo el trabajo dentro del sprint, lo que requiere ajustes o renegociaciones. Ejemplo gráfico: El equipo empieza con 50 horas, pero al llegar al día 5 solo ha quemado 10 horas. Esto indica que el equipo está detrás del cronograma y deberá ajustar su plan.  Previsto (Ideal): Representado por la línea azul discontinua, que muestra un descenso constante de las horas de trabajo restantes durante los 10 días del sprint. Optimista: La línea verde, que desciende más rápidamente que la ideal, lo que indica que el equipo está avanzando más rápido de lo planeado y podría terminar antes de lo esperado. Pesimista: La línea roja, que desciende más lentamente, señalando que el equipo está quemando menos trabajo del esperado y probablemente no termine a tiempo. Análisis y posibles variantes: Situación Optimista (Terminar más rápido que lo previsto) 1. Subestimación de tareas o Las historias de usuario o tareas fueron sobreestimadas en términos de tiempo o esfuerzo, y se completaron más rápido de lo anticipado. 2. Alta productividad del equipo o El equipo está trabajando en un periodo de alto rendimiento, con gran colaboración, concentración y eficiencia. 3. Falta de complejidad o Las tareas no eran tan complicadas como se esperaba inicialmente, lo que permitió al equipo avanzar rápidamente. 4. Eliminación rápida de bloqueos o El equipo fue capaz de eliminar dependencias o resolver problemas más rápido de lo previsto, acelerando el progreso. 5. Buena planificación y claridad de tareas o Las historias de usuario fueron claras y bien definidas desde el principio, lo que redujo el tiempo dedicado a discusiones o aclaraciones. 6. Automatización o herramientas eficientes  o El equipo adoptó herramientas o procesos automatizados que redujeron el tiempo necesario para completar tareas repetitivas o mecánicas. 7. Menor tiempo en pruebas o validaciones o Si las pruebas o validaciones se hicieron de manera más eficiente o rápida (sin comprometer la calidad), el equipo podría haber terminado antes. Situación Pesimista (Terminar más lento que lo previsto) 1. Sobreestimación del equipo o Las tareas eran más complejas de lo previsto, lo que implicó que requerían más tiempo y esfuerzo del anticipado. 2. Bloqueos o dependencias no previstas o Surgieron obstáculos inesperados, como bloqueos técnicos, dependencias con otros equipos o sistemas, que retrasaron el progreso. 3. Subestimación de la complejidad o Algunas tareas o historias de usuario resultaron ser más complejas en su implementación o prueba de lo que se había anticipado en el planning. 4. Falta de claridad en los requisitos o Las historias de usuario o requisitos no estaban completamente claros o definidos, lo que llevó a retrabajo o más tiempo para alinear expectativas. 5. Problemas de comunicación o colaboración o La falta de comunicación efectiva dentro del equipo o entre equipos, o problemas de colaboración, pudieron ralentizar el progreso. 6. Tareas emergentes o nuevas prioridades o Se añadieron nuevas tareas o prioridades durante el sprint que no fueron consideradas en la planificación inicial, lo que desvió la atención del trabajo original. 7. Problemas técnicos o imprevistos o Fallos en el sistema, errores técnicos inesperados, o tiempos de inactividad de herramientas clave pueden haber provocado retrasos. 8. Falta de experiencia o conocimiento o Si el equipo no tiene suficiente experiencia o conocimiento en alguna área del proyecto, puede llevar más tiempo completar ciertas tareas, generando retrasos. Efecto posible de una Spike en el gráfico de quemado. 1. Spike planificada correctamente: Si la Spike se planifica desde el principio del sprint, el trabajo necesario para ella ya está incluido en el backlog y se refleja en el gráfico de quemado desde el comienzo. En este caso:  o Al principio del sprint, la cantidad total de trabajo será mayor debido a la Spike, pero el gráfico de quemado debería continuar como en cualquier otra tarea. o Impacto en el gráfico: Si la Spike se completa en el tiempo planificado, el gráfico no se verá afectado significativamente. Si la Spike se prolonga más de lo esperado, el gráfico de quemado puede volverse más pesimista, ya que consume tiempo y recursos que podrían haber sido usados para otras tareas del sprint. 2. Spike no planificada o emergente: Si la Spike surge de manera inesperada durante el sprint (por ejemplo, debido a un obstáculo técnico imprevisto), afectará el progreso, ya que el equipo deberá destinar tiempo no planificado a investigar o resolver problemas. o Impacto en el gráfico: La línea de quemado podría volverse más plana o desviarse hacia la situación pesimista, ya que la Spike consume tiempo que no estaba contemplado para las tareas principales. El equipo podría estar "quemando" menos trabajo visible mientras investiga, lo que se refleja en una menor reducción en las horas restantes. Ejemplo de cómo una Spike podría afectar el gráfico: 1. Inicialmente planificada: Supongamos que al inicio del sprint se asignan 10 horas para una Spike y se distribuyen a lo largo del sprint. El gráfico de quemado simplemente reflejaría ese trabajo adicional como parte del backlog. La línea seguiría bajando de manera regular si todo va según lo previsto. 2. Emergente: Si el equipo detecta un problema el día 4 y decide dedicar una Spike de 2 días, el progreso del sprint se vería afectado. Durante esos dos días, el trabajo en otras tareas podría disminuir significativamente, y la línea en el gráfico mostraría un descenso más lento (parecido al gráfico pesimista) hasta que se retome el trabajo habitual. 8. Objetivos Clave de la Gestión Ágil Los objetivos principales de la gestión ágil incluyen: Maximizar el valor entregado al cliente. Reducir el tiempo de salida al mercado. Asegurar flexibilidad y agilidad para adaptarse a cambios. Entregar resultados confiables en ciclos cortos. Metodología Lean La Metodología Lean tiene el objetivo de maximizar el valor entregado al cliente y minimizar los desperdicios (entendiendo "desperdicios" como cualquier actividad que no aporte valor directo). Lean se centra en los siguientes principios clave:  Eliminar desperdicios: Identificar y reducir actividades que no agregan valor. En el contexto de desarrollo de software, esto puede significar eliminar burocracia, reducir el tiempo de espera para revisiones, y evitar el trabajo innecesario. Mejora continua (Kaizen): Busca la mejora constante en cada ciclo de trabajo. Los equipos revisan continuamente sus procesos para hacer ajustes y ser más eficientes. Optimización del sistema global: En lugar de optimizar componentes individuales, Lean aboga por optimizar el flujo completo del trabajo, asegurando que el producto final se entregue lo más rápido y eficientemente posible. En software, el enfoque Lean implica reducir el trabajo en progreso (WIP), garantizar la entrega de valor constante, y enfocar los esfuerzos en lo que los usuarios necesitan. Método INVEST El método INVEST es una guía útil para definir buenas historias de usuario (user stories). Cada historia debe cumplir con estos seis criterios para asegurar su calidad y claridad: 1. I - Independiente: Cada historia de usuario debe poder implementarse sin depender de otras historias. 2. N - Negociable: Las historias deben ser flexibles para poder ajustarse si cambian los requerimientos. 3. V - Valiosa: Cada historia debe proporcionar valor al usuario final. 4. E - Estimable: Debe poder estimarse en términos de esfuerzo o tiempo necesario para completarla. 5. S - Pequeña: Lo suficientemente pequeña para ser implementada en un sprint. 6. T - Testeable: Debe ser clara y detallada para que pueda verificarse fácilmente mediante pruebas. Método SMART El método SMART es una técnica que ayuda a definir metas claras y alcanzables para el equipo. Cada objetivo debe ser: 1. S - Específico: Definir claramente lo que se quiere lograr, cómo "entregar una nueva funcionalidad para la autenticación de usuarios". 2. M - Medible: Establecer indicadores para medir el progreso, como "completar la funcionalidad con un 100% de cobertura de pruebas unitarias". 3. A - Alcanzable: Los objetivos deben ser realistas dados los recursos y el tiempo disponibles. 4. R - Relevante: El objetivo debe estar alineado con las metas generales del proyecto o negocio.  5. T - Temporal: Definir un plazo para alcanzar el objetivo, como "completar la funcionalidad en dos sprints". Método MoSCoW Se utiliza para priorizar requisitos o tareas de acuerdo a su importancia y necesidad. Must Have (Debe Tener): Estos son los requisitos o funcionalidades esenciales para que el proyecto tenga éxito. Son innegociables y deben completarse para que el producto funcione mínimamente. Should Have (Debería Tener): Estos requisitos son importantes pero no esenciales. Si no se implementan, el producto aún funcionará, aunque su valor podría disminuir. Could Have (Podría Tener): Estas son características deseables pero no prioritarias. Su inclusión depende de la disponibilidad de tiempo y recursos. No afectan de manera significativa el funcionamiento del producto. Won't Have (No Tendrá por Ahora): Estos elementos son aquellos que no se incluirán en el proyecto actual, ya sea porque no son necesarios en este momento o porque no hay suficiente tiempo o recursos para implementarlos. Pueden ser considerados en versiones futuras.