Introducción a la Ingeniería de Software PDF

UNIDAD 1 INTRODUCCIÓN A LA INGENIERÍA DE SOFTWARE 1. ¿Qué es la Ingeniería de Software? ¿Por qué es importante? Es la disciplina de la ingeniería que se encarga de todo lo relacionado a la producción de software. La Ingeniería en Software es importante principalmente por dos razones :...

UNIDAD 1 INTRODUCCIÓN A LA INGENIERÍA DE SOFTWARE 1. ¿Qué es la Ingeniería de Software? ¿Por qué es importante? Es la disciplina de la ingeniería que se encarga de todo lo relacionado a la producción de software. La Ingeniería en Software es importante principalmente por dos razones : ○ Las organizaciones y los individuos cada vez más se apoyan en software para desempeñar sus trabajos. ○ El diseño adecuado del software es fundamental para reducir costos, automatizar tareas y tener un crecimiento más ordenado y sostenible de las organizaciones. 2. ¿Cuáles son algunos de los retos más significativos que enfrenta la Ingeniería de Software? Se enfrentan con una diversidad creciente, demandas por tiempos de distribución limitados y desarrollo de software confiable. Desafíos de la Ingeniería de Software: ○ Inteligencia Artificial y Machine Learning ○ Ciberseguridad ○ Habilidades y Competencias Técnicas ○ Escalabilidad y Rendimiento. ○ Gestión de proyectos: trabajo en equipo, comunicación y manejo de tiempo y recursos ○ Integración de Tecnologías Emergentes (Ejemplos: Big Data, IoT , computación en la Nube, Blockchain, otros) ○ 3. ¿Cuáles son los tres problemas generales que afectan a los distintos tipos de software? Problemas que afecta a los tipos de software: ○ Heterogeneidad: Es importante construir software que sean flexibles para poder adaptarse a distintos tipos de dispositivos que utilicen diferentes lenguajes. ○ Cambio empresarial y social: los negocios y la sociedad cambian muy rápido, conforme se desarrollan nuevas tecnologías. Ambos necesitan tener la posibilidad de cambiar su software existente y desarrollar rápidamente uno nuevo ○ Seguridad y confianza: es necesario asegurarse de que usuarios malintencionados no puedan atacar el software y que se conserve la seguridad de la información. ○ 4. ¿Cuál es el propósito del Código de Ética y Práctica Profesional de Ingeniería en Software? Determinar los principios que debe seguir un profesional para garantizar que los Ingenieros en Software desarrollen su trabajo contribuyendo al bienestar de la sociedad de manera responsable y ética Fue desarrollado por IEEE Computer Society y la ACM (Association for Computing Machinery) como una guía para promover la responsabilidad y respeto en la profesión. 5. ¿Cuáles son los principios de ética y práctica profesional? De ejemplos de cada uno Principio 1 - Sociedad: Los ingenieros de software actuarán en forma congruente con el interés social. Aceptar la responsabilidad total de su trabajo. Aprobar software sólo si se tiene una creencia bien fundamentada de que es seguro, cumple las especificaciones, pasa las pruebas apropiadas y no reduce la calidad de vida, la privacidad o daña el medio ambiente. Asegurar que los datos de los clientes estén protegidos y no sean compartidos sin permiso Ej: estar motivado a ofrecer voluntariamente asistencia técnica a buenas causas y contribuir a la educación pública relacionada con la profesión. Principio 2 - Cliente y empresario: actuarán de manera que se concilien los mejores intereses de sus clientes y empresarios Moderar los intereses del ingeniero de software, el empresario, el cliente y los usuarios con el bienestar social. Ej: No usar la información del cliente sin su previa autorización. Principio 3 - Producto: asegurará que sus productos y modificaciones correspondientes cumplen los estándares profesionales más altos posibles. Asegurar que las especificaciones del software en el que se trabaja están bien documentadas, satisfacen los requerimientos del usuario y cuentan con las aprobaciones adecuadas. Ej: Garantizar que el software no pone en riesgo la integridad de la información provista por los usuarios. Principio 4 - Juicio: mantendrán integridad e independencia en su juicio profesional. Exponer a las personas o autoridades apropiadas cualquier daño real o potencial al usuario, a la sociedad o el medio ambiente, asociado con el software o documentos relacionados. Ej: No involucrarse en prácticas financieras fraudulentas tal como corrupción, facturación doble u otras prácticas financieras impropias. Principio 5 - Administración: gerentes y líderes promoverán y se suscribirán a un enfoque ético en la administración del desarrollo y mantenimiento de software. Ofrecer una remuneración justa y equitativa. Ej: Asegurar una buena administración para cualquier proyecto en el cual trabaje, incluyendo procedimientos efectivos para promover la calidad y reducir riesgos. Principio 6 - Profesión: incrementarán la integridad y reputación de la profesión congruentemente con el interés social. Ayudar a desarrollar un ambiente organizacional favorable para actuar éticamente. Ej: promover el conocimiento público de la ingeniería en software. Principio 7 - Colegas: apoyarán y serán justos con sus colegas Ayudar a sus colegas en el desarrollo profesional. Principio 8 - Personal: participarán toda su vida en el aprendizaje relacionado con la práctica de su profesión y promoverán un enfoque ético en la práctica de la profesión. Mejorar su conocimiento de los avances en el análisis, especificación, diseño, desarrollo, mantenimiento, pruebas del software y documentos relacionados, junto con la administración del proceso de desarrollo 6. ¿Qué tipos de software existen? ○ Aplicaciones independientes: programas de software autónomos que funcionan en un dispositivo sin conexión a red. ○ Aplicaciones interactivas basadas en transacción: sistemas que permiten a los usuarios realizar transacciones en línea, como compras o pagos. ○ Sistemas de control embebido: Software diseñado para controlar dispositivos físicos, como sistemas de automóviles o electrodomésticos. ○ Sistemas de procesamientos en lotes: Sistemas que procesan grandes volúmenes de datos de forma secuencial sin intervención en tiempo real. ○ Sistemas de entretenimiento: Plataformas de ocio como videojuegos o servicios de streaming de música y video.  ○ Sistemas para modelado y simulación: Herramientas para crear modelos y simular situaciones, como simuladores de vuelo o negocios ○ Sistemas para adquisición de datos: Sistemas para recopilar y procesar datos de diversas fuentes, como sensores ambientales o de tráfico. ○ Sistemas de sistemas: Integración de múltiples sistemas independientes para un propósito común, como sistemas de gestión de cadena de suministro ○ Sistemas educativos: Plataformas y herramientas diseñadas para facilitar la enseñanza y el aprendizaje, como sistemas de gestión del aprendizaje. ○ Sistemas de seguridad: Soluciones diseñadas para proteger personas, propiedades y datos contra amenazas, como sistemas de seguridad física y cibernética. 7. ¿Cuál es la diferencia entre ingeniería de software e ingeniería de sistemas? La ingeniería de sistemas se interesa por todos los aspectos del desarrollo de sistemas basados en computadoras, incluidos hardware, software e ingeniería de procesos. La ingeniería de software es parte de este proceso más general. UNIDAD 2 PROCESOS Y MODELOS DE PROCESOS DE DESARROLLO DE SOFTWARE 1. ¿Qué es un proceso de desarrollo de software? Es una serie de actividades relacionadas que conducen a la elaboración de un producto de software. Estas actividades pueden incluir el desarrollo de software desde cero en un lenguaje de programación. Sin embargo en la actualidad se desarrolla extendiendo y modificando los sistemas existentes. 2. ¿Cuáles son las actividades fundamentales para la Ing. de Software? ○ Especificación del software: Tienen que definirse tanto la funcionalidad del software como las restricciones de su operación. ○ Diseño e implementación del software : Debe desarrollarse el software para cumplir con las especificaciones. ○ Validación del software: Hay que validar el software para asegurarse de que cumple lo que el cliente quiere. ○ Evolución del software : El software tiene que evolucionar para satisfacer las necesidades cambiantes del cliente. 3. ¿Que es un modelo de proceso de software? Es una representación simplificada de un proceso, cada modelo del proceso representa a otro desde una perspectiva, por lo tanto ofrece sólo información parcial de dicho proceso. 4. ¿En qué consiste el modelo en cascada y cuáles son sus ventajas y desventajas? El modelo en cascada es un enfoque secuencial donde cada fase del desarrollo debe completarse antes de que la siguiente comience. Ventajas: Fácil de entender y gestionar. Claridad en los requisitos desde el inicio. Estructura clara y sencilla. Desventajas: Difícil de cambiar los requisitos una vez comenzado. No se presta bien a proyectos complejos y largos. Dificultad para retroalimentación temprana del cliente  5. ¿Qué son los modelos incrementales e iterativos y cómo se diferencian? El desarrollo incremental se basa en la idea de diseñar una implementación inicial, exponer ésta al comentario del usuario, y luego desarrollarla en sus diversas versiones hasta producir un sistema adecuado. El modelo iterativo es un enfoque que involucra la repetición de ciclos de desarrollo que incluyen planificación, diseño, implementación y evaluación en múltiples iteraciones. Cada secuencia lineal produce “incrementos” de software susceptibles de entregarse 6. Comparación entre modelo iterativo, incremental y evolutivo  7. ¿Qué es el prototipado y cuándo se utiliza? El prototipado es la creación de un modelo funcional del software para que los usuarios puedan interactuar con él y proporcionar feedback. Se utiliza cuando los requisitos no están bien definidos o se necesita clarificación. 8. ¿Cuáles son las características del proceso unificado? Procesos Unificado Racional (RUP) Conjunta elementos de todos los modelos de proceso genéricos, ilustra la buena práctica en especificación y diseño, y apoya la creación de prototipos y entrega incremental. 9. ¿Qué son las metodologías ágiles y cómo se aplican en el desarrollo de software? Las metodologías ágiles son enfoques de desarrollo de software que se caracterizan por su flexibilidad, colaboración, adaptabilidad y enfoque en la entrega temprana y continua de valor al cliente Características principales : Entrega incremental y continua Iteración y retroalimentación Colaboración y trabajo en equipo Flexibilidad y adaptabilidad Enfoque en la calidad 10. ¿Qué es SCRUM? Es una metodología ágil de gestión de proyectos que se utiliza principalmente en el desarrollo de software, facilita el trabajo en equipo, la comunicación y la colaboración. Permite a los equipos adaptarse rápidamente a los cambios y entregas. 11. ¿Cuáles son los roles en SCRUM y qué responsabilidades tiene cada uno? Scrum Master: asegura que el equipo siga las prácticas de Scrum Product Owner:Define y prioriza el backlog del producto Equipo de desarrollo: grupo auto-organizado y multifuncional que trabaja en la entrega de incrementos del producto. Generalmente, el equipo es pequeño (de 3 a 9 miembros) User: Son las personas que utilizan el producto 12. ¿Qué son los artefactos en SCRUM y para qué se utilizan? Backlog: lista priorizada de todas las funcionalidades, mejoras y correcciones que se necesitan en el producto. Es gestionado por el Product Owner. Esas funcionalidades están descritas como historias de usuario. Sprint: conjunto de elementos del product Backlog seleccionados para trabajar durante un Sprint. 13. ¿Cuáles son los eventos en SCRUM y cuál es su propósito? Sprint : Periodo de tiempo fijo (de 1 a 4 semanas) durante el cual se crea un incremento del producto utilizable. Cada Sprint tiene un objetivo claro Sprint planning : Reunión al inicio de cada Sprint donde se define qué se hará (selección de elementos del Product Backlog) y cómo se hará (plan para alcanzar el objetivo del Sprint) Daily Scrum : Reunión diaria de 15 minutos donde el equipo de desarrollo sincroniza sus actividades y planifica las próximas 24 horas. Cada miembro responde a tres preguntas: ¿Qué hice ayer?, ¿Qué haré hoy?, ¿Hay algún impedimento?. Sprint Review: una reunión al final del Sprint donde el equipo muestra lo que se ha completado durante el Sprint a los interesados. Sprint Retrospective: una reunión al final del Sprint donde el equipo reflexiona sobre el Sprint pasado y discute qué fue bien, qué no fue bien, y cómo se puede mejorar en el próximo Sprint. 14. ¿Qué beneficios aporta SCRUM en el desarrollo de software? Flexibilidad y adaptabilidad, mejora continua, entregas rápidas, colaboración y comunicación UNIDAD 3 INGENIERÍA DE LOS REQUERIMIENTOS 1. ¿Qué técnicas se utilizan para la recolección de requerimientos? Cuestionarios, entrevistas, observación directa, análisis de documentos. 2. ¿Qué características debe tener un requerimiento de software? Un requerimiento debe ser claro, sin ambigüedades y verificable. 3. ¿Qué son los requerimientos funcionales y no funcionales? Requerimientos funcionales: describen lo que el sistema debe hacer. Requerimientos no funcionales: describen cómo debe comportarse el sistema 4. ¿En qué se diferencian los requerimientos de productos, organización y externos? ¿Qué tipo de requerimientos son? Los tres son requerimientos no funcionales Requerimiento de producto: son las necesidades o especificaciones que debe cumplir un sistema o producto. Por ejemplo, funcionalidades específicas, rendimiento, seguridad o compatibilidad. Requerimientos de organización (internos): relacionados con políticas y procedimientos de la organización. Por ejemplo, presupuesto y plazos, estándares de calidad. Requerimientos externos: Influencias externas, como regulaciones legales y condiciones ambientales y escalabilidad. Por ejemplo, el software debe cumplir con la normativa GDPR (General Data Protection Regulation) para la protección de datos personales en la Unión Europea. 5. ¿En qué se diferencian los requerimientos de usuarios y de sistema? ¿Qué tipo de requerimientos son? Los requerimientos de usuarios se centran en las acciones que los usuarios desean realizar con el sistema y cómo desean interactuar con él para lograr sus objetivos y los requerimientos de sistemas se centran en las acciones y comportamientos del sistema mismo, sin tener en cuenta quién o qué está interactuando con él. Estos requerimientos son funcionales  6. ¿Cómo se especifican los requerimientos de software? Tarjetas CRC (Class-Responsibility-Collaborator): las tarjetas CRC son una técnica utilizada en el diseño orientado a objetos para ayudar a identificar y organizar clases y sus responsabilidades Historias de usuario: las historias de usuario son descripciones breves y simples de una funcionalidad del software desde la perspectiva del usuario final Diagramas de caso de uso: Los diagramas de caso de uso son una representación gráfica de las interacciones entre los actores (usuarios u otros sistemas) y el sistema en desarrollo 7. ¿Qué son las historias de usuario? ¿Cuáles son sus características? Las historias de usuario son una técnica utilizada en metodologías ágiles para capturar descripciones de funcionalidades deseadas desde la perspectiva del usuario final. Son breves, simples y están escritas en un lenguaje comprensible tanto para los desarrolladores como para los stakeholders. 8. ¿Cómo se escribe una historia de usuario? Se escribe en el formato: "Como [tipo de usuario], quiero [funcionalidad] para [beneficio]". Yo como: persona que usa la funcionalidad. Quiero: funcionalidad. Para: para qué sirve, que resuelve. 9. ¿Qué son los criterios de aceptación? Son las cosas que me dicen si una historia de usuario quedó lista. Cada criterio de aceptación se tiene que validar antes de entregarse la historia de usuario. UNIDAD 4 ARQUITECTURA Y DISEÑO DE SOFTWARE 1. ¿Cuáles son los principios básicos de diseño y arquitectura en software? En el diseño y arquitectura de software se utilizan principalmente los principios SOLID y los principios orientados a objetos. 2. ¿Qué son los principios SOLID? SOLID es una regla mnemotécnica para cinco principios de diseño ideados para hacer que los diseños de software sean más comprensibles, flexibles y fáciles de mantener. 3. Explica cada uno de los principios SOLID con ejemplos. a. Principio de Responsabilidad Única (SRP): Cada clase debe tener una única responsabilidad.Cada clase es responsable de una única parte de la funcionalidad proporcionada por el software. Ejemplo: una clase Factura debe manejar solo la facturación, no la impresión. b. Principio de Abierto/Cerrado (OCP): Las clases deben estar abiertas para extensión pero cerradas para modificación. Ejemplo: Una clase Figura con un método área(), y diferentes clases Cuadrado, Círculo que extienden Figura. c. Principio de Sustitución de Liskov (LSP): Los objetos de una clase base deben poder ser sustituidos por objetos de una clase derivada sin afectar la funcionalidad del sistema. Ejemplo: Un Ave puede volar, y un Pingüino extiende Ave pero no puede volar. Esto rompe LSP. d. Principio de Segregación de Interfaces (ISP) : Las interfaces deben ser específicas y no obligar a implementar métodos innecesarios. Ejemplo: Separar la interfaz Vehículo en VehículoTerrestre y VehículoAcuático. e. Principio de Inversión de Dependencias (DIP): Las entidades de alto nivel no deben depender de las de bajo nivel. Ambas deben depender de abstracciones. Ejemplo: Una clase ServicioDePago debe depender de una interfaz IPasarelaDePago, no de PayPal directamente. UNIDAD 5 DISEÑO ORIENTADO A OBJETOS 1. ¿Qué es el diseño orientado a objetos y cuáles son sus principios fundamentales? Paradigma orientado a objetos Objetos : Un objeto es una instancia de una clase que representa una entidad del mundo real. Clase :Es una plantilla en la que se definen los atributos y métodos predeterminados de un tipo de objeto. Encapsulación : Se utiliza para ocultar detalles sobre los objetos y permitir el acceso a estos a través de interfaces controladas. Abstracción : La abstracción se refiere a la representación generalizada de elementos esenciales. Poner foco en qué hace un objeto sin tener en cuenta su implementación, es decir sin tener en cuenta cómo lo hace. Cohesión : La cohesión se refiere al grado de relación que tienen los elementos de un módulo o una clase, una alta cohesión quiere decir que hay una alta relación entre los elementos. Se recomienda una alta cohesión. Herencia : Mecanismo a través del cual una clase es definida en referencia a otra, heredando todos sus atributos y métodos. Facilita la creación de objetos a partir de otros ya existentes. Polimorfismo : El polimorfismo permite que un mismo método o clase se comporte de manera diferente en distintas clases. Acoplamiento : Se refiere al grado en el que las clases dependen unas de otras. En términos generales, se prefiere un bajo acoplamiento en el diseño de software ya que los módulos deben tener poca dependencia entre sí. Asociación de objetos : Relación entre objetos en donde uno utiliza los servicios o funcionalidades del otro. La asociación es una relación simple entre dos o más objetos. Es una conexión semántica entre clases que pueden interactuar entre sí. La asociación no implica propiedad ni vida compartida de los objetos.  2. ¿Qué relación tienen los principios SOLID con el diseño orientado a objetos? Los principios SOLID proporcionan una guía clara para aplicar conceptos fundamentales del diseño orientado a objetos de manera efectiva, asegurando que el software desarrollado sea de alta calidad y más fácil de mantener y escalar UNIDAD 6 CALIDAD DE SOFTWARE 1. ¿Qué es la calidad de software y cómo se define? La calidad de software se refiere a la medida en que un producto de software cumple con los requisitos especificados, satisface las necesidades del usuario, y es libre de defectos. 2. ¿Cuáles son las características y subcaracterísticas de calidad de un producto de software según el modelo de Calidad de la ISO 25010? CARACTERÍSTICAS ISO 25010 Adecuación Funcional: Representa la capacidad del producto software para proporcionar funciones que satisfacen las necesidades declaradas e implícitas de los usuarios cuando el producto se usa en las condiciones especificadas. Esta característica se subdivide a su vez en las siguientes subcaracterísticas: Completitud funcional. Grado en el que el conjunto de funcionalidades del producto cubre todas las tareas y los objetivos de usuario especificados. Corrección funcional. Capacidad del producto o sistema para proveer resultados exactos cuando es usado por los usuarios especificados. Pertinencia funcional. Capacidad del producto software para proporcionar un conjunto de funciones que facilitan la consecución de tareas y objetivos de usuario especificados. Eficiencia de Desempeño: Esta característica representa el desempeño de un producto en la realización de sus funciones dentro de unos parámetros de tiempo y rendimiento especificados y con un uso eficiente de recursos (CPU, memoria, almacenamiento, energía...) utilizados bajo determinadas condiciones. Esta característica se subdivide a su vez en las siguientes subcaracterísticas: Comportamiento temporal. Grado en que un producto realiza sus funciones de forma que el tiempo de respuesta y el ratio de rendimiento cumple los requisitos especificados. Utilización de recursos. Grado en que la cantidad y tipos de recursos utilizados por el producto al llevar a cabo su función bajo condiciones determinadas no exceden lo especificado. Capacidad. Grado en que el producto cumple los requisitos relativos a límites máximos para un parámetro (ítems almacenados, usuarios concurrentes, ancho de banda de comunicaciones...). Compatibilidad: Capacidad de un producto de intercambiar información con otros productos y/o llevar a cabo sus funciones requeridas cuando comparten un mismo entorno y recursos. Esta característica se subdivide a su vez en las siguientes subcaracterísticas: Coexistencia. Capacidad del producto para coexistir con otro software independiente, en un entorno común, compartiendo recursos comunes sin detrimento. Interoperabilidad. Capacidad de dos o más sistemas o componentes para intercambiar información y utilizar la información intercambiada. Capacidad de Interacción: Capacidad del producto software para que el usuario interactúe mediante su interfaz intercambiando información para completar determinadas tareas. Esta característica se subdivide a su vez en las siguientes subcaracterísticas: Reconocibilidad de la adecuación. Capacidad del producto que permite al usuario entender si el software es adecuado para sus necesidades. Aprendizabilidad. Capacidad del producto que permite al usuario aprender su funcionamiento dentro de un tiempo especificado. Operabilidad. Capacidad del producto que permite al usuario operarlo y controlarlo con facilidad. Protección contra errores de usuario. Capacidad del sistema para prevenir errores en su operación. Involucración del usuario. Capacidad del producto de presentar sus funciones e información de forma atractiva y motivadora, fomentando la interacción continua. Inclusividad. Capacidad de un producto para ser utilizado por personas con distintos contextos (edad, habilidades, cultura, raza, lenguaje, género...). Asistencia al usuario. Capacidad del producto que permite que sea utilizado por usuarios con determinadas características y capacidades logrando objetivos específicos. Auto-descriptividad. Capacidad de un producto para presentar la información adecuada, haciendo su uso inmediatamente evidente para el usuario sin interacciones excesivas con el producto u otros recursos (documentación, help desks, otros usuarios...). Fiabilidad: Capacidad de un sistema o componente para desempeñar las funciones especificadas, cuando se usa bajo unas condiciones y periodo de tiempo determinados sin interrupciones o fallos. Esta característica se subdivide a su vez en las siguientes subcaracterísticas: Ausencia de fallos. Capacidad del sistema de llevar a cabo sus funciones sin fallos bajo condiciones normales de operación. Disponibilidad. Capacidad del sistema o componente de estar operativo y accesible para su uso cuando se requiere. Tolerancia a fallos. Capacidad del sistema o componente para operar según lo previsto en presencia de fallos hardware o software. Capacidad de recuperación. Capacidad del producto software para recuperar los datos directamente afectados y reestablecer el estado deseado del sistema en caso de interrupción o fallo. Seguridad: Capacidad de protección de la información y los datos de manera que las personas u otros productos tengan el grado de acceso a los datos adecuado a sus tipos y niveles de autorización, y para defenderse de los patrones de ataque de agentes malintencionados.. Esta característica se subdivide a su vez en las siguientes subcaracterísticas: Confidencialidad. Capacidad de asegurar que los datos solo son accesibles a aquellos con autorización para ello. Integridad. Capacidad de un producto para garantizar que el estado de su sistema y sus datos están protegidos frente a modificaciones o eliminaciones no autorizadas, ya sea por acciones malintencionadas o por errores informáticos. No repudio. Capacidad de demostrar las acciones o eventos que han tenido lugar, de manera que dichas acciones o eventos no puedan ser repudiados posteriormente. Responsabilidad. Capacidad de rastrear de forma inequívoca las acciones de una entidad. Autenticidad. Capacidad de un producto para demostrar que la identidad de un sujeto o recurso es la que se afirma. Resistencia. Capacidad de mantener la operación de un producto bajo condiciones de ataque de un actor malicioso. Mantenibilidad: Esta característica representa la capacidad del producto software para ser modificado efectiva y eficientemente, debido a necesidades evolutivas, correctivas o perfectivas. Esta característica se subdivide a su vez en las siguientes subcaracterísticas: Modularidad. Capacidad de un producto para evitar que los cambios en un componente afecten a otros componentes. Reusabilidad. Capacidad de un activo que permite que sea utilizado en más de un sistema software o en la construcción de otros activos. Analizabilidad. Facilidad con la que se puede evaluar el impacto de un determinado cambio sobre el resto del software, diagnosticar las deficiencias o causas de fallos en el software, o identificar las partes a modificar. Capacidad para ser modificado. Capacidad del producto que permite que sea modificado de forma efectiva y eficiente sin introducir defectos o degradar su calidad. Capacidad para ser probado. Facilidad con la que se pueden establecer criterios de prueba para un sistema o componente y con la que se pueden llevar a cabo las pruebas para determinar si se cumplen dichos criterios. Flexibilidad: Capacidad del producto para adaptarse a cambios en sus requisitos, contextos de uso o entorno del sistema. Esta característica se subdivide a su vez en las siguientes subcaracterísticas: Adaptabilidad. Capacidad del producto que le permite ser adaptado de forma efectiva y eficiente a diferentes entornos determinados de hardware, software, operacionales o de uso. Escalabilidad. Capacidad del producto para gestionar cargas de trabajo crecientes o decrecientes y para adaptar su capacidad a la variabilidad. Instalabilidad. Facilidad con la que el producto se puede instalar y/o desinstalar de forma exitosa en un determinado entorno. Reemplazabilidad. Capacidad del producto para ser utilizado en lugar de otro producto software determinado con el mismo propósito y en el mismo entorno. Protección: Esta característica representa la capacidad del producto, en condiciones definidas, de evitar un estado en el que se ponga en peligro la vida humana, la salud, la propiedad o el medio ambiente. Esta característica se subdivide a su vez en las siguientes subcaracterísticas: Restricción operativa. Capacidad de un producto para limitar su funcionamiento a unos parámetros o estados seguros cuando se enfrenta a un peligro operativo. Identificación de riesgos. Capacidad de un producto para identificar situaciones u operaciones que pueden exponer la vida, la propiedad o el medio ambiente a un riesgo inaceptable. Protección ante fallos. Capacidad de un producto para ponerse automáticamente en un modo de funcionamiento seguro o para volver a una condición segura en caso de fallo. Advertencia de peligro. Capacidad de un producto para alertar de riesgos inaceptables, de modo que puedan reaccionar con tiempo suficiente para mantener la seguridad de las operaciones. Integración segura. Capacidad de un producto para mantener la seguridad durante y después de la integración con uno o varios componentes. 3. ¿Qué es el aseguramiento de la calidad del software (SQA)? Es un conjunto de técnicas y actividades que garantizan que un programa cumpla con los estándares de calidad establecidos. 4. ¿Qué son los patrones de diseño y cómo se clasifican? Los patrones de diseño (design patterns) son soluciones habituales a problemas comunes en el diseño de software. Cada patrón es como un plano que se puede personalizar para resolver un problema de diseño particular de tu código. Se clasifican en patrones de comportamiento, creacionales y estructurales. ○ Comportamiento : Estos patrones tratan con algoritmos y la asignación de responsabilidades entre objetos.  ○ Creacional : Estos patrones proporcionan mecanismos de creación de objetos que incrementan la flexibilidad y la reutilización del código existente. ○ Estructurales : Estos patrones explican cómo ensamblar objetos y clases en estructuras más grandes, mientras se mantiene la flexibilidad y eficiencia de la estructura. UNIDAD 7 PRUEBAS DE SOFTWARE 1. ¿Qué son las pruebas de software y para qué sirven? Determinan si un producto de software se ajusta a los requisitos del sistema. A su vez son el proceso de establecer confianza en que un programa hace lo que se supone que debe hacer. Las pruebas de software son esenciales para asegurar la calidad y el correcto funcionamiento del software. 2. ¿Cómo se define un error, un defecto y un fallo en el contexto del desarrollo de software? ○ Error : es una acción humana que produce un resultado incorrecto. ○ Defecto : es la presencia de un error en el software. ○ Fallo : es la manifestación visible de un defecto. Un error puede generar uno o más defectos y un defecto va a causar un fallo Un error de un desarrollador, causa un Defecto en el software, lo cual provoca un Fallo en el momento en el que la prueba se ejecuta. 3. ¿Cómo se clasifican las pruebas de software según el conocimiento del código? Pruebas Caja Blanca: se conocen los detalles y el funcionamiento interno del software que se está probando. Es una prueba basada en la ejecución, revisión y retroalimentación de las funcionalidades previamente diseñadas para el software. Están enfocadas a identificar debilidades en el diseño del código y no a detectar discrepancias entre los requerimientos y su implementación. Se piensan y diseñan casos de prueba conociendo el código del software. Pruebas de Caja Negra: Es una técnica de pruebas de software en la cual la funcionalidad se verifica sin tomar en cuenta la estructura interna de código, detalles de implementación o escenarios de ejecución internos en el software. Pruebas de Caja gris: Se tiene un conocimiento limitado del código y la estructura interna del software. Se establece un diálogo programador-tester o bien se estudia la documentación técnica para conocer sobre la estructura interna del sistema. 4. ¿Cúal es la diferencia entre pruebas funcionales y no funcionales? Pruebas Funcionales: Verifican que el software funciona según los requisitos especificados. Se centran en las acciones y salidas del sistema. Tipos de pruebas funcionales: Pruebas Unitaria Pruebas de Integración Pruebas de Regresión Pruebas de Sistemas Pruebas de Validación Pruebas No Funcionales: Evalúan aspectos no relacionados con la funcionalidad, como el rendimiento, la usabilidad, la fiabilidad y la seguridad. Tipos de pruebas no Pruebas de rendimiento (Performance Testing) ○ Pruebas de carga (load testing) ○ Pruebas de Estrés (Stress Testing)  Pruebas de seguridad Pruebas de Usabilidad Pruebas de compatibilidad (Compatibility Testing) pruebas de instalación (Install Testing) pruebas de recuperación (Recovery Testing) pruebas de confiabilidad (Reliability Testing) 5. ¿Qué son las pruebas unitarias y para qué sirven? Las pruebas unitarias consisten en probar de forma individual las funciones y/o métodos (de las clases, componentes y/o módulos que son usados por nuestro software). 6. ¿Qué tipo de pruebas de rendimiento hay? ¿En qué se diferencian? Existen pruebas de carga y de estrés. Carga: es determinar y validar la respuesta de la aplicación cuando esta está sometida a una carga de un cierto número de usuarios o de peticiones. Estrés: Validar características de rendimiento del sistema bajo condiciones superiores a lo previsto en las operaciones de producción (grandes volúmenes de carga). 7. ¿Quienes realizan las pruebas alfa y las pruebas beta? ¿Cúal es su finalidad? Prueba Alfa: Las pruebas alfa generalmente las realizan probadores que son empleados internos de la organización. Su finalidad es identificar y corregir los defectos antes de que el software sea probado externamente Pruebas Beta: Los clientes o usuarios finales que no están empleados en la organización se someten a pruebas beta. Su finalidad es obtener retroalimentación sobre el software en condiciones de uso real y detectar cualquier problema que no se haya identificado durante las pruebas alfa. 8. ¿Qué son las pruebas de integración y de regresión? ¿Cuando se utilizan? Pruebas de integración: Verifican que los diferentes módulos y/o servicios usados por nuestra aplicación funcione en armonía cuando trabajan en conjunto. Se utilizan cuando se combinan varios módulos para asegurarse de que funcionan juntos correctamente. Pruebas de regresión: son las más utilizadas mientras avanza un proyecto, ya que se realizan para validar que las correcciones o modificaciones del código no hayan impactado negativamente las funcionalidades existentes.Se realizan después de cualquier cambio en el código para asegurarse de que el software sigue funcionando correctamente. 9. ¿Qué tipos o enfoques de pruebas de integración y regresión hay? Prueba de Integración Big Bang Todos los componentes o módulos se integran simultáneamente, después de lo cual todo se prueba como un todo. Pruebas de Integración Incrementales  ○ Prueba de Integración Descendente Las pruebas se llevan a cabo de arriba a abajo, siguiendo el flujo de control o la estructura arquitectónica (por ejemplo, comenzando desde la GUI o el menú principal). Los componentes o sistemas se sustituyen por stubs. ○ Prueba de Integración Ascendente Las pruebas se llevan a cabo desde la parte inferior del flujo de control hacia arriba. Los componentes o sistemas se sustituyen por controladores. ○ Prueba de Integración de Sándwich Son una combinación de enfoques de arriba hacia abajo y de abajo hacia arriba. También se denomina prueba de integración híbrida o prueba de integración mixta. Pruebas de regresión Retestear todo: se ejecutan todas las pruebas del grupo o conjunto existente. Selección de pruebas de regresión: se ejecutan algunos casos de prueba seleccionados para verificar si el código modificado afecta o no a la aplicación. Esta opción normalmente se realiza cuando existe una trazabilidad clara entre el código y las funcionalidades a las cuales puede afectar. Priorización de casos de prueba: se priorizan los casos de prueba según el impacto comercial, las funcionalidades críticas y de uso frecuente. Esto permite reducir el conjunto de pruebas de regresión, minimizando el tiempo de los ciclos. 10. ¿Para qué sirve la documentación de prueba de software? La documentación de pruebas de software es esencial para asegurar que las pruebas se realicen de manera sistemática y efectiva. Los documentos de pruebas son fundamentales para la planificación, ejecución y seguimiento de las actividades de prueba, y ayudan a comunicar el estado y los resultados de las pruebas a los interesados 11. ¿Qué es la IEEE 829 y la IEEE 29119? ¿Qué incluye cada una? IEEE 829: Es un estándar para la documentación de pruebas de software, también conocido como Standard for Software Test Documentation. Incluye formatos para la planificación, diseño, ejecución y reporte de pruebas. IEEE 29119: Es un estándar más reciente para los procesos de pruebas de software, que incluye prácticas de prueba, terminología y documentación. Cubre un conjunto más amplio de prácticas de pruebas y se enfoca en la gestión y la mejora continua de las pruebas de software.