Parcial II Flashcards
Explique conceptualmente que es un patrón de diseño y para que se utiliza
Los patrones de diseño son esenciales en la ingeniería de software, facilitando la
reutilización efectiva de diseños y arquitecturas de manera acelerada. Funcionan como soluciones nombradas y reutilizables que ayudan a elegir alternativas de diseño, promoviendo sistemas más reutilizables. Cada patrón actúa como un par problema/solución que puede adaptarse a variados contextos, acompañado de guías
sobre cómo implementarlo adecuadamente. Esto permite a los desarrolladores aplicar soluciones previamente probadas a problemas comunes, optimizando así el proceso de desarrollo y promoviendo la creación de sistemas robustos y eficientes.
Proponga una aplicación para el patrón adaptador (figura 1
Una aplicación de análisis de datos necesita pasar de una biblioteca de gráficos
desactualizada a una más actual y tiene una interfaz distinta, el patrón de adaptador es la solucion ya que facilita la transición permitiendo que la aplicación llame a la interfaz antigua, mientras que el adaptador se encarga de traducir estas llamadas con una estructura que la nueva biblioteca puede entender. De esta manera, la aplicación puede usar la nueva biblioteca de gráficos sin cambios significativos en su código.
- Cliente: La aplicación de análisis de datos que necesita generar visualizaciones.
- IFTarget (Interfaz Target): La interfaz que la aplicación usa actualmente para interactuar con la biblioteca de gráficos.
- Adaptee: La nueva biblioteca de visualización con una interfaz distinta.
- Adapter: El adaptador que implementa la interfaz IFTarget y hace compatible las llamadas de la aplicación a la nueva biblioteca
¿Qué es una responsabilidad, y cuáles son los tipos básicos de responsabilidades?
Una responsabilidad, según el texto, se refiere a un contrato u obligación de una clase con respecto a su comportamiento, y no es necesariamente un método, aunque los métodos se implementan para llevar a cabo responsabilidades.
Cada objeto, dependiendo de su rol y propósito, tendrá diferentes responsabilidades que pueden abarcar tanto el hacer acciones específicas como el conocer ciertos datos o relaciones. Se dividen en dos categorías básicas: “Hacer” y “Conocer”.
Responsabilidades de “Hacer”:
- Realizar una acción por sí mismo.
- Iniciar una acción en otros objetos.
- Controlar y coordinar actividades en otros objetos.
Responsabilidades de “Conocer”:
- Estar al tanto de los datos privados encapsulados.
- Conocer los objetos relacionados.
- Saber sobre cosas que pueden derivarse o calcularse
Explique mediante el formato problema-solución, los patrones
Experto; Creador; Bajo Acoplamiento; Alta Cohesión; Controlado
Experto
Problema: ¿Cuál es el principio fundamental en virtud del cual se asignan las
responsabilidades en el diseño orientado a objetos?
Solución: Asignar una responsabilidad al experto en información: la clase que
cuenta con la información necesaria para cumplir la responsabilidad.
Creador
Problema: ¿Quién debería ser responsable de crear una nueva instancia de alguna
clase?
Solución: Asignarle a la clase B la responsabilidad de crear una instancia de la clase
A en uno de los siguientes casos:
- B agrega los objetos de A.
- B contiene los objetos de A.
- B registra las instancias de los objetos de A.
- B tiene los datos de inicialización que serán enviados a A cuando este objeto sea creado (B es un experto respecto a la creación de A).
Bajo acoplamiento
- Problema: ¿cómo soportar bajas dependencias, bajo impacto en el cambio e
incremento en la reutilización?
- Solución: asignar las responsabilidades a las clases de manera de mantener el
acoplamiento bajo.
- Alta Cohesión
Problema: ¿como mantener la complejidad manejable?
Solución: asignar las responsabilidades de manera que las cohesión permanezca
alta.
- Controlador
Problema: ¿Quién debe ser el responsable de gestionar un evento de entrada al
sistema? (Un evento del sistema de entrada es un evento generado por un actor
externo)
Solución: asignar la responsabilidad de recibir o manejar un mensaje de evento del
sistema a una clase que:
a) represente el sistema global
b) represente un escenario de caso de uso donde tiene lugar el evento
¿Qué son las metodologías ágiles?
Las metodologías ágiles son un conjunto de enfoques para el desarrollo de software que se subscriben a los valores y principios expresados en el Manifiesto Ágil. Se fundamentan en la colaboración iterativa tanto de los desarrolladores como de los clientes, y en la flexibilidad para adaptarse a los cambios durante el proceso de desarrollo. En contraposición a las metodologías tradicionales o “en cascada”, que siguen un enfoque más rígido y lineal, las metodologías ágiles enfatizan la entrega rápida y continua de partes funcionales del software, permitiendo una respuesta más ágil a las necesidades cambiantes de los clientes o del mercado
¿Cuáles son las ventajas de aplicar metodologías ágiles?
Flexibilidad y Adaptabilidad: Permiten mejor adaptación a los cambios, ya sea en
requisitos del cliente, tecnología o mercado.
Entrega Continua de Valor: Con entregas iterativas y frecuentes, se proporciona valor al cliente de manera continua, permitiendo un retorno de inversión más temprano.
Colaboración Mejorada: Fomentan la comunicación constante y la colaboración
estrecha tanto dentro del equipo de desarrollo como con los stakeholders.
Satisfacción del Cliente: Al involucrar al cliente en el proceso de desarrollo y permitirle hacer cambios, se incrementa su satisfacción y se asegura que el producto final cumpla con sus expectativas.
Eficiencia en el Desarrollo: Las metodologías ágiles optimizan el proceso de desarrollo al eliminar actividades redundantes o innecesarias, lo que se traduce en un uso más eficiente de los recursos.
Mejora Continua: La reflexión y adaptación al final de cada iteración (sprints en Scrum) conduce a una mejora continua del producto y del proceso de desarrollo.
Riesgo Reducido: El desarrollo iterativo permite identificar tempranamente los riesgos y los problemas, reduciendo el impacto negativo que podrían tener en el proyecto.
Transparencia: Con la implementación de reuniones regulares y el seguimiento del
progreso, hay una mayor transparencia en el estado del proyecto.
Motivación del Equipo: Al dar más control y propiedad al equipo sobre su trabajo, se
puede mejorar la moral y la motivación.
Calidad del Producto: La integración continua y el desarrollo dirigido por pruebas (TDD) son prácticas que pueden aumentar la calidad del software desarrollado
¿Cuál es la diferencia entre las metodologías tradicionales y las ágiles? Ejemplifique.
Las metodologías tradicionales, como el modelo en cascada (Waterfall), y las metodologías
ágiles difieren principalmente en su enfoque del ciclo de vida del desarrollo del software:
Metodologías Tradicionales (Waterfall):
Son lineales y secuenciales; cada fase debe completarse antes de comenzar la
siguiente.
Tienen un alcance definido y fijo al inicio del proyecto, lo que hace difícil adaptarse a
cambios.
La fase de prueba ocurre después de la fase de desarrollo, lo que puede retrasar la
identificación de errores hasta etapas tardías del proyecto.
La entrega del producto es única y al final del ciclo de vida del desarrollo.
Ejemplo: En el modelo en cascada, primero se completa la documentación de
requerimientos, luego se diseña el sistema, después se escribe el código, se realizan
las pruebas y, finalmente, se entrega el software al cliente.
Metodologías Ágiles:
Son iterativas e incrementales; las fases se solapan y se repiten en ciclos (iteraciones
o sprints).
Aceptan y se adaptan a cambios en el alcance a lo largo del proyecto.
La fase de prueba se integra en el desarrollo y ocurre de manera continua a lo largo
del proyecto.
Se entrega valor de manera continua en forma de incrementos funcionales del
software.
Ejemplo: En Scrum, se trabaja en sprints de 2-4 semanas, al final de los cuales se
entrega una parte funcional del software. Los requerimientos pueden ser
reevaluados y priorizados al inicio de cada sprint, y se realizan pruebas de forma
constante
¿En qué consiste el concepto Scrum?
Scrum es un marco de trabajo ágil que estructura el desarrollo de software en ciclos
iterativos llamados sprints. Establece roles claros: Product Owner, Scrum Master y Equipo de Desarrollo. Se enfoca en reuniones regulares como el Sprint Planning, Daily Scrum, Sprint Review y Sprint Retrospective. Utiliza artefactos como el Product Backlog y Sprint Backlog para organizar y priorizar el trabajo. Scrum promueve la transparencia, la inspección y la adaptación continua para maximizar el valor del producto entregado.
Explique el Manifesto Ágil
El Manifiesto Ágil es una proclamación que establece los valores y principios fundamentales para el desarrollo de software ágil. Prioriza individuos e interacciones sobre procesos y herramientas, y valora más el software funcionando que la documentación exhaustiva. Se enfoca en la colaboración con los clientes más que en la negociación de contratos rigurosos, y responde al cambio en lugar de seguir un plan estricto. Fue formulado en 2001 por 17 desarrolladores de software como una respuesta a las metodologías pesadas y rígidas de desarrollo de software. Su objetivo es proporcionar un enfoque más eficiente, flexible y colaborativo para desarrollar productos de software.
¿En qué consiste el concepto Sprints?
Los sprints son ciclos de desarrollo de tiempo fijo en el marco de trabajo Scrum,
generalmente de 2 a 4 semanas. Durante un sprint, el equipo se enfoca en completar un conjunto seleccionado de tareas del backlog del producto. El objetivo es producir un incremento de software potencialmente entregable al final de cada sprint. Los sprints permiten una revisión y adaptación constantes del producto en desarrollo. Al final de cada sprint, se realiza una revisión y retrospectiva para evaluar el progreso y planificar mejoras
¿En qué consiste el concepto Product Owner?
El Product Owner en Scrum es una figura clave responsable de maximizar el valor del
producto resultante del trabajo del Equipo de Desarrollo. Esta persona es la voz del cliente y del usuario final dentro del equipo de Scrum, asegurando que las características del producto, los requisitos y las prioridades estén claramente definidos y comprendidos. El Product Owner mantiene y prioriza el Product Backlog, que es una lista dinámica de características, funcionalidades, requisitos, mejoras y correcciones que funcionan como el plan de trabajo para el equipo de Scrum. También es responsable de la claridad de los ítems del backlog y de la comunicación de las expectativas del stakeholder al equipo, así como de aceptar o rechazar los incrementos de producto al final de cada sprint. Su papel es crucial para el éxito del proyecto Scrum, ya que es el enlace principal entre el equipo y los stakeholders, y toma decisiones críticas relacionadas con el desarrollo del producto
¿Cuál es la función más relevante del ScrumMaster?
La función más relevante del ScrumMaster es facilitar y asegurar que el equipo de Scrum siga los principios y prácticas de la metodología ágil Scrum. Actúa como un coach tanto para el equipo de desarrollo como para el Product Owner, ayudando a remover obstáculos que puedan impedir el progreso del equipo, garantizando una comunicación fluida y promoviendo un ambiente de trabajo colaborativo y autoorganizado. Además, el ScrumMaster protege al equipo de interrupciones externas, maximizando la productividad y permitiendo la entrega continua de valor
Explique el concepto “actividad adaptativa” a nivel Estimación
La “actividad adaptativa” en la estimación en metodologías ágiles implica ajustar
continuamente las estimaciones de trabajo basándose en la experiencia y el aprendizaje adquiridos durante el ciclo de desarrollo. Se caracteriza por la retroalimentación iterativa de cada sprint, lo que permite que el equipo de desarrollo refine sus estimaciones y expectativas para los futuros sprints. Herramientas como Planning Poker fomentan la estimación colaborativa y la toma de decisiones basada en el consenso. Además, el product backlog es revisado y reestimado regularmente para garantizar que las prioridades y esfuerzos reflejen los cambios y nuevos descubrimientos. Esta adaptabilidad asegura que la planificación y ejecución del proyecto sean realistas y estén en sintonía con las condiciones cambiantes y las capacidades del equipo
Explique porque la estimación de tiempo es diferente a la estimación de duración.
La estimación de tiempo se centra en la cantidad de horas de trabajo requeridas para
completar una tarea, sin tomar en cuenta los recursos disponibles. En contraste, la
estimación de duración considera el calendario de trabajo y cuántas personas estarán
asignadas a la tarea, reflejando el tiempo de inicio a fin del trabajo. Por ejemplo, una tarea que requiere 40 horas de trabajo podría durar una semana si una persona trabaja a tiempo completo, o dos semanas si trabaja a tiempo parcial. Por lo tanto, mientras que la estimación de tiempo es una medida de esfuerzo, la duración es una medida del tiempo transcurrido hasta la finalización
¿Por qué en metodologías ágiles la estimación la lleva el equipo de trabajo?
En las metodologías ágiles, la estimación la lleva a cabo el equipo de trabajo porque son quienes mejor comprenden la ejecución técnica y los desafíos del proyecto. Este enfoque promueve la propiedad y el compromiso del equipo hacia las tareas y objetivos. Además, al trabajar directamente en el desarrollo, el equipo tiene una perspectiva más clara de la complejidad y los recursos necesarios. La colaboración durante las sesiones de estimación, como Planning Poker, fomenta la precisión al combinar diversas experiencias y habilidades. Esto también mejora la comunicación y la transparencia, elementos clave para el éxito en un entorno ágil.
