Resumen 2do Parcial MSI V2.pdf

Unidad 3 1. Propósito de UML: UML (Unified Modeling Language) es un lenguaje estándar que se utiliza para visualizar, especificar, construir y documentar los artefactos de un sistema basado en software. Sus propósitos son: Visualizar: Ayuda a representar gráficamente un sistema complejo. UML p...

Unidad 3 1. Propósito de UML: UML (Unified Modeling Language) es un lenguaje estándar que se utiliza para visualizar, especificar, construir y documentar los artefactos de un sistema basado en software. Sus propósitos son: Visualizar: Ayuda a representar gráficamente un sistema complejo. UML permite ver las diferentes estructuras, interacciones y comportamientos dentro del sistema de manera gráfica y clara, lo cual facilita la comunicación entre los desarrolladores y otros actores involucrados. Especificar: UML ayuda a definir con precisión los distintos elementos de un sistema. Esto incluye los detalles necesarios para el análisis, diseño y construcción del sistema, garantizando que las especificaciones sean claras y comprensibles. Construir: Aunque UML no es un lenguaje de programación en sí mismo, sus diagramas pueden ser utilizados para generar código en lenguajes como Java, C++ o Visual Basic mediante la ingeniería directa. El modelo UML puede conectarse con el código de programación para facilitar el desarrollo. Documentar: UML permite documentar todos los artefactos de software, incluyendo requisitos, arquitectura, diseño y código fuente, lo que es útil para la planificación, el control del proyecto, las pruebas y las versiones de software. 2. Bloques de construcción de UML: Para entender y trabajar con UML, es importante conocer sus tres bloques de construcción principales: 1. Elementos: Elementos estructurales: Son los bloques estáticos del sistema. Estos incluyen: o Clases: Definen las propiedades y comportamientos de los objetos. o Interfaces: Describen un conjunto de operaciones que una clase o componente debe implementar. o Casos de uso: Describen cómo los actores externos interactúan con el sistema para cumplir con algún objetivo. o Componentes: Representan partes modulares del sistema, como módulos o bibliotecas. o Nodos: Representan dispositivos físicos o recursos donde se ejecutan los componentes (ej.: servidores). Elementos de comportamiento: Son los elementos dinámicos que describen el comportamiento de un sistema a lo largo del tiempo.  o Interacciones: Representan el flujo de mensajes entre objetos. o Máquinas de estado: Modelan las secuencias de estados que atraviesa un objeto en respuesta a eventos. Elementos de agrupación: Son contenedores que organizan otros elementos. o Paquetes: Agrupan elementos estructurales y de comportamiento. Elementos de anotación: Son explicaciones adicionales sobre el modelo. Se representan mediante notas que aclaran o detallan el comportamiento o restricciones. 2. Relaciones: 1. Asociación: Definición: Es la relación más básica entre dos o más clases, donde una clase puede hacer referencia o usar otra. Características: o No implica una fuerte dependencia, simplemente establece que existe una conexión entre los elementos. o Puede ser bidireccional (sin restricciones de navegación) o unidireccional (un objeto puede acceder al otro, pero no viceversa). o Multiplicidad: Se especifica cuántos objetos de una clase pueden estar asociados con objetos de otra clase, usando valores como 1, 0..1, * (muchos), 1..* (uno o más), etc. Ejemplo: Un Doctor está asociado a varios Pacientes. Aunque tienen una relación, ambos pueden existir por separado. 2. Agregación: Definición: Es un tipo especial de asociación que representa una relación "parte-todo" donde una clase (el todo) contiene o agrupa otras clases (las partes), pero las partes pueden existir independientemente del todo. Características: o Se representa gráficamente con una línea continua que tiene un rombo vacío en el extremo del todo (la clase contenedora). o La vida de los objetos es independiente; es decir, si se destruye el objeto "todo", las partes aún pueden seguir existiendo. Ejemplo: Un Club está compuesto por Socios. Si el club desaparece, los socios siguen existiendo. 3. Composición:  Definición: Es una relación más fuerte que la agregación. También representa una relación "parte-todo", pero en este caso, las partes no pueden existir independientemente del todo. Características: o Se representa gráficamente como una línea continua con un rombo relleno en el extremo del todo. o Si el "todo" se destruye, las partes también lo hacen. o Representa una fuerte dependencia entre las clases. Ejemplo: Un Taller Mecánico tiene varias Estaciones de Trabajo. Si el taller se cierra, las estaciones de trabajo dejan de existir como elementos independientes. 4. Dependencia: Definición: Una clase depende de otra cuando necesita su funcionalidad para operar correctamente. Es una relación más débil que la asociación, pero aún implica una conexión temporal entre los elementos. Características: o Se representa mediante una línea discontinua con una flecha. o Implica que si la clase de la que depende cambia, puede afectar el funcionamiento de la otra. Ejemplo: Un Estudiante depende de un Libro de Texto para estudiar. Si cambia el libro, el estudiante debe adaptarse al nuevo contenido. 5. Generalización (Herencia): Definición: Representa una relación entre una clase padre (superclase) y una clase hija (subclase), donde la subclase hereda atributos y comportamientos de la superclase. Características: o Se representa mediante una línea continua con una flecha vacía (no rellena) apuntando de la subclase a la superclase. o La clase hija es una especialización de la clase padre, y puede añadir o modificar comportamientos y atributos. o Permite reutilizar código y comportamientos, estableciendo una jerarquía de clases. Ejemplo: Las clases Perro y Gato heredan de la clase Animal, compartiendo atributos y comportamientos comunes, pero con sus propias especificaciones. 6. Realización:  Definición: Es una relación entre una interfaz y una clase concreta que implementa dicha interfaz. Indica que la clase se compromete a realizar todas las operaciones definidas en la interfaz. Características: o Se representa mediante una línea discontinua con una flecha vacía apuntando desde la clase que realiza la interfaz hacia la interfaz. o Interfaz: Define un conjunto de métodos que deben ser implementados por cualquier clase que la realice, pero no tiene implementación propia. o La relación de realización es clave para definir comportamientos comunes sin especificar cómo deben ser implementados. Ejemplo: Un Instructor de Yoga realiza las actividades definidas por un Programa de Yoga. El programa especifica qué ejercicios se deben hacer, y el instructor los lleva a cabo. Otras características importantes: Navegación: o Las relaciones pueden ser navegables en un solo sentido o en ambos. Esto indica si una clase puede acceder a la otra y en qué dirección. o Por ejemplo, si la clase Factura conoce al Cliente (navegación unidireccional), podrá acceder a los detalles del cliente, pero no al revés. Multiplicidad: o Indica el número de instancias que puede haber en cada extremo de una relación. o Ejemplo: En la relación entre una Orden y un Producto, podría indicarse que una orden tiene "1.." productos, mientras que un producto podría estar en "0.." órdenes. 3. Diagramas: Los diagramas de UML permiten visualizar los sistemas desde diferentes perspectivas. A continuación, veremos los tipos más importantes. 3. Diagramas de UML: UML ofrece varios tipos de diagramas que ayudan a visualizar y comprender diferentes aspectos de un sistema. Estos diagramas se dividen en dos categorías principales: diagramas estructurales y diagramas de comportamiento. Diagramas estructurales: Los diagramas estructurales muestran los componentes estáticos de un sistema, como clases, objetos y relaciones entre ellos. Diagrama de clases: Muestra las clases del sistema, sus atributos, métodos y relaciones. Se utiliza para visualizar la estructura estática y las relaciones como herencia, asociación y agregación. Es uno de los diagramas más importantes porque captura las características fundamentales del sistema. Diagrama de objetos: Similar al diagrama de clases, pero muestra instancias de las clases en un momento particular del tiempo. Diagrama de componentes: Visualiza los componentes de software y sus relaciones. Muestra cómo están organizados los componentes de un sistema y cómo interactúan entre sí. Es útil para representar módulos o bibliotecas dentro del sistema. Diagrama de despliegue: Representa la distribución física de los componentes de software en los nodos de hardware. Por ejemplo, muestra qué servidores alojan qué componentes o bases de datos. Diagramas de comportamiento: Los diagramas de comportamiento modelan el flujo de trabajo y las interacciones dentro del sistema. Diagrama de casos de uso: Representa las interacciones entre los actores externos (usuarios u otros sistemas) y el sistema en sí. Cada caso de uso representa una funcionalidad que proporciona valor a un actor. Los casos de uso también incluyen relaciones entre ellos, como inclusión y extensión. Diagrama de secuencia: Muestra cómo los objetos interactúan entre sí a lo largo del tiempo. Se utiliza para representar la secuencia de mensajes que se envían entre objetos a lo largo de una línea de tiempo, especificando el orden en que ocurren las interacciones. Diagrama de estado: Modela el conjunto de estados por los que pasa un objeto durante su vida útil en respuesta a eventos. Se utiliza para modelar el ciclo de vida de un objeto en particular, mostrando cómo cambia su estado en respuesta a estímulos. Diagrama de actividad: Representa el flujo de control entre actividades. Es similar a un diagrama de flujo, pero más enfocado en modelar el comportamiento de alto nivel en el sistema, describiendo secuencias de actividades y condiciones para el flujo de ejecución. Diagrama de colaboración: Similar al diagrama de secuencia, pero pone más énfasis en las relaciones y colaboraciones entre los objetos, en lugar del orden cronológico de los mensajes. 4. Modelo de vistas 4+1: Este modelo, propuesto por Philippe Kruchten, se utiliza para describir la arquitectura de sistemas complejos desde diferentes puntos de vista. El objetivo del modelo es abordar las distintas perspectivas que los usuarios pueden tener sobre un sistema de software. Las vistas son: Vista lógica: Muestra la funcionalidad del sistema, utilizando principalmente diagramas de clases. Representa los servicios que el sistema proporciona a los usuarios. Vista de procesos: Muestra los aspectos dinámicos del sistema, como concurrencia, sincronización y comunicación entre procesos. Utiliza diagramas de actividad y de secuencia. Vista de desarrollo: Describe cómo está organizado el sistema desde la perspectiva de los desarrolladores, como los componentes y módulos de software. Utiliza diagramas de componentes y paquetes. Vista física: Representa la infraestructura física del sistema, como servidores, nodos y dispositivos de red. Utiliza diagramas de despliegue. Vista de escenarios: Relaciona las cuatro vistas anteriores y describe los casos de uso y los requisitos del sistema. 5. UML y el Proceso Unificado de Desarrollo (PUD): El Proceso Unificado de Desarrollo (PUD) es una metodología iterativa e incremental que se utiliza para guiar el desarrollo de sistemas complejos. UML es una parte fundamental del PUD porque permite modelar el sistema en cada fase del proceso. Las características principales del PUD son: Centrado en casos de uso: Los casos de uso son la base para definir los requisitos y funcionalidades del sistema. A partir de ellos se generan otros modelos. Centrado en la arquitectura: La arquitectura del sistema es fundamental y sirve como la columna vertebral durante el desarrollo. Iterativo e incremental: El desarrollo se realiza en fases que se repiten y mejoran con el tiempo. Cada ciclo agrega más funcionalidad al sistema. 6. Modelo de dominio: El modelo de dominio representa los conceptos y entidades que pertenecen al dominio del problema. Es una abstracción que describe las clases y objetos del mundo real o de un entorno específico, así como sus relaciones. Diagrama de clases del modelo de dominio: Describe las entidades del negocio, sus atributos y relaciones. Estas clases no están directamente ligadas a la implementación, sino que ayudan a comprender el problema que debe resolver el sistema. Especificación de requisitos: Muchas de las clases del dominio pueden deducirse de la especificación de requisitos o entrevistas con los expertos del dominio. El objetivo es representar los elementos esenciales que definen el problema del sistema.  Unidad 4 1. Verificación y Validación (V&V): Verificación y Validación son dos actividades esenciales en el proceso de testing para garantizar la calidad del software: Verificación: Asegura que el software está siendo desarrollado de la manera correcta, es decir, que sigue los estándares y especificaciones establecidas. El objetivo principal es detectar y corregir errores en etapas tempranas del desarrollo mediante revisiones de código, inspecciones y pruebas estáticas. Se verifica que cada fase del ciclo de vida del software cumpla con los requisitos previamente definidos. Validación: Evalúa si el producto final cumple con las expectativas y necesidades del cliente. Es un enfoque que se centra en el producto terminado, asegurando que satisface los requerimientos funcionales y no funcionales a través de pruebas dinámicas, como pruebas funcionales y pruebas de aceptación. La validación es crucial para determinar si el software está listo para ser utilizado por los usuarios finales. 2. Principios del Testing: El testing sigue ciertos principios fundamentales que guían a los profesionales en la ejecución de pruebas efectivas: 1. El testing muestra la presencia de defectos, no su ausencia: Aunque las pruebas pueden identificar defectos, no garantizan que el software esté completamente libre de errores. Siempre existe la posibilidad de que algunos defectos no se detecten durante las pruebas. 2. El testing exhaustivo es imposible: Dada la complejidad de los sistemas, es impracticable probar todas las combinaciones posibles de entradas y escenarios. Por lo tanto, es necesario priorizar las pruebas, concentrándose en las áreas más críticas y de mayor riesgo. 3. Testing temprano (Early Testing): Cuanto antes se detecten los defectos en el ciclo de vida del desarrollo, más económico será corregirlos. Las pruebas deben comenzar en las fases iniciales, como en la definición de requisitos y el diseño.  4. Agrupación de defectos (Defect Clustering): Según el principio de Pareto, el 80% de los defectos suelen encontrarse en el 20% de los módulos. Este conocimiento permite a los testers concentrar sus esfuerzos en las áreas más propensas a errores. 5. Paradoja del Pesticida: Si se repiten constantemente los mismos casos de prueba, eventualmente dejarán de detectar nuevos defectos. Para mantener la efectividad, las pruebas deben actualizarse y ampliarse regularmente. 6. El testing depende del contexto: Las pruebas deben adaptarse al tipo de software que se está evaluando. Por ejemplo, un sistema crítico, como uno de control médico, requerirá pruebas más rigurosas que un sistema de comercio electrónico. 7. Falsedad de la ausencia de errores (Absence of Errors Fallacy): Incluso si se corrigen todos los defectos técnicos, el software puede fallar si no satisface las necesidades del usuario final o si los requisitos no estaban correctamente definidos. 3. Errores, Defectos y Fallos: Es crucial entender la diferencia entre estos conceptos en el contexto del testing: Error: Es una equivocación humana en alguna fase del desarrollo, como al escribir código o al documentar los requisitos. Por ejemplo, un programador podría cometer un error al utilizar el operador "==" en lugar de "=". Defecto (Bug): Es el resultado de un error introducido en el software. El defecto es un error que está presente en el código y puede provocar un comportamiento no deseado en la ejecución del programa. Fallo: Es la manifestación visible de un defecto durante la ejecución del software. Un fallo ocurre cuando el sistema no se comporta como se espera debido a un defecto en el código. Los defectos pueden clasificarse según su severidad y prioridad: Severidad: Se refiere al impacto que el defecto tiene en el sistema. Los defectos críticos pueden causar que el sistema se bloquee o falle en realizar tareas esenciales. Prioridad: Se refiere a la urgencia con la que el defecto debe ser corregido. Un defecto con baja severidad puede tener alta prioridad si afecta una funcionalidad crítica para el negocio. 4. Niveles de Pruebas: Los niveles de pruebas en el desarrollo de software se dividen en diferentes categorías, cada una con un propósito específico para garantizar la calidad global del sistema:  Pruebas Unitarias (Unit Testing): Estas pruebas verifican el comportamiento de componentes individuales, como funciones o métodos, en aislamiento. Los desarrolladores suelen escribir pruebas unitarias para asegurar que cada unidad de código funciona correctamente antes de integrarla con otros módulos. Pruebas de Integración (Integration Testing): En esta etapa, se prueban las interacciones entre diferentes módulos o componentes del sistema. El objetivo es detectar problemas en las interfaces y la comunicación entre módulos que podrían no aparecer en las pruebas unitarias. Pruebas de Sistema (System Testing): Estas pruebas evalúan el sistema completo e integrado, verificando que todos los componentes funcionen en conjunto. Incluyen pruebas funcionales y no funcionales, como pruebas de rendimiento, seguridad y usabilidad. Pruebas de Aceptación (User Acceptance Testing - UAT): Son la última fase antes del lanzamiento del producto. Los usuarios finales prueban el sistema en un entorno real para asegurarse de que cumple con los requisitos y expectativas antes de su implementación. 5. Casos de Prueba (Test Cases): Un caso de prueba es un conjunto de condiciones bajo las cuales un tester determinará si una función específica del software se comporta como se espera. Un buen caso de prueba debe ser preciso, repetible y rastreable, y generalmente incluye los siguientes elementos: Objetivo: Qué funcionalidad o comportamiento del sistema se va a validar. Datos de entrada y ambiente: Valores que se utilizarán para ejecutar la prueba y las condiciones en las que se realizará. Resultados esperados: Descripción de lo que debería ocurrir si el software funciona correctamente. Resultados actuales: Lo que realmente ocurre durante la ejecución de la prueba. 6. Tipos de Testing: Pruebas Funcionales: Estas pruebas verifican que el sistema cumpla con los requisitos funcionales especificados. Se centran en el comportamiento esperado de las funcionalidades del software. Un ejemplo sería probar si un sistema de pagos en línea acepta correctamente los datos de una tarjeta de crédito. Pruebas No Funcionales: Evalúan aspectos del sistema no relacionados directamente con las funcionalidades, como rendimiento, escalabilidad, seguridad y usabilidad. Un ejemplo sería medir el tiempo de respuesta de una aplicación bajo carga.  Pruebas Manuales: En este tipo de pruebas, un tester humano sigue un conjunto de pasos predefinidos para verificar el comportamiento del sistema. Son útiles para detectar problemas de usabilidad y la interacción entre el usuario y el software. Pruebas Automatizadas: Utilizan herramientas para ejecutar pruebas de forma automática, lo que permite repetirlas de manera más rápida y eficiente. Son especialmente útiles para pruebas repetitivas o regresivas. 7. Automatización y Herramientas de Testing: La automatización de pruebas es clave en el desarrollo moderno de software, ya que permite ejecutar pruebas repetitivas de forma eficiente y asegura que el código sea verificado continuamente a medida que se realizan cambios. Herramientas como Selenium, JUnit, y TestNG permiten automatizar pruebas de interfaces de usuario y funcionalidad, mientras que otras herramientas como Jenkins facilitan la integración continua y la ejecución automatizada de pruebas en cada nuevo cambio de código. Gestión de Riesgos en Proyectos de Software (Somerville) La gestión de riesgos es un aspecto clave en la dirección de proyectos de software debido a la naturaleza incierta y compleja de estos proyectos. El proceso implica identificar, analizar y responder a los riesgos que puedan afectar al proyecto, al producto o a la organización, con el fin de minimizar los impactos negativos y aumentar las probabilidades de éxito. La gestión de riesgos tiene las siguientes etapas: 1. Identificación del Riesgo: o Se deben identificar los riesgos potenciales que podrían impactar al proyecto, ya sea retrasándolo, afectando su calidad o incluso comprometiendo la organización. o Tipos de riesgos: § Riesgos de proyecto: Relacionados con el cronograma y los recursos, como la posible salida de personal clave o retrasos en la disponibilidad de hardware. § Riesgos de producto: Pueden afectar la calidad del software, como errores en componentes reutilizados o bajo rendimiento de herramientas CASE. § Riesgos empresariales: Impactan a la organización en su conjunto, como la aparición de productos competidores o cambios tecnológicos que desactualicen el sistema. 2. Análisis de Riesgos: o Para cada riesgo, se evalúa su probabilidad de ocurrencia y sus potenciales consecuencias.  o La probabilidad se clasifica en categorías como baja (75%). o Los efectos pueden ser catastróficos (amenazan la viabilidad del proyecto), graves (causan retrasos importantes), tolerables (demoras manejables) o insignificantes. o Es útil clasificar los riesgos y priorizarlos en función de su gravedad y probabilidad. Esto ayuda a los administradores a enfocar sus esfuerzos en los riesgos de mayor impacto. 3. Planificación del Riesgo: o Una vez identificados y evaluados, se desarrollan estrategias para enfrentar los riesgos clave: § Estrategias de evitación: Reducen la probabilidad de que el riesgo ocurra, como diseñar redundancias para compensar posibles fallos. § Estrategias de minimización: Reducen el impacto del riesgo en caso de que ocurra, como la reorganización de equipos para que más miembros conozcan funciones críticas. § Planes de contingencia: Preparan al equipo para actuar si el riesgo se materializa, como un plan alternativo en caso de problemas financieros. 4. Monitorización del Riesgo: o La monitorización continua es necesaria para revisar los riesgos y los planes. Se verifica si los riesgos previamente identificados han cambiado en probabilidad o impacto y si han surgido nuevos riesgos. o Se utilizan indicadores para evaluar los riesgos, como una alta rotación de personal, peticiones de cambio de requisitos o problemas tecnológicos frecuentes. Estudio de Factibilidad y Viabilidad en Proyectos de Software (Guía Anexo Factibilidad) Un estudio de factibilidad es una evaluación inicial que se realiza antes de iniciar un proyecto para determinar si puede llevarse a cabo con éxito con los recursos disponibles. La viabilidad va un paso más allá al analizar si el proyecto es rentable y sostenible a largo plazo. Ambos conceptos ayudan a tomar decisiones informadas y reducir los riesgos en la fase de planificación. 1. Tipos de Factibilidad Factibilidad Técnica:  o Evalúa si el equipo tiene la capacidad tecnológica y humana para desarrollar el proyecto. o Elementos Clave: § Hardware: Revisión de la capacidad y compatibilidad de los equipos existentes. § Software: Análisis de si el software necesario puede desarrollarse internamente, comprarse o subcontratarse, y verificar que sea compatible con el sistema actual. § Procesamiento y Rendimiento: Simulaciones para probar el sistema bajo condiciones de uso extremo y evaluar si soporta la carga de trabajo. § Seguridad y Escalabilidad: Asegura que el sistema esté protegido frente a amenazas y pueda adaptarse a un aumento en la demanda. o Herramientas de Evaluación: § Matriz de Homogeneización: Estándariza la tecnología en la organización para evitar problemas de compatibilidad. § Pruebas de Concepto (PoC): Permiten probar una tecnología o enfoque a pequeña escala para evaluar su viabilidad antes de una inversión mayor. § Simulación de Rendimiento y Estudio de Capacidad: Identifican cuellos de botella en el procesamiento y verifican si el sistema puede soportar la carga de trabajo proyectada. Factibilidad Económica: o Determina si el proyecto será rentable, comparando costos y beneficios esperados. o Herramientas Clave: § Análisis de Retorno sobre la Inversión (ROI): Mide el porcentaje de ganancia sobre la inversión inicial. § Análisis Costo-Beneficio (CBA): Compara los costos totales con los beneficios esperados para verificar si el proyecto es económicamente favorable. § Valor Presente Neto (VPN): Evalúa los flujos de caja futuros descontados a una tasa de interés para comprobar si la inversión inicial se justifica. § Análisis de Sensibilidad Económica: Examina cómo variaciones en costos o ingresos proyectados podrían afectar la viabilidad económica del proyecto. Factibilidad Operativa:  o Examina si la organización tiene la capacidad para adoptar el sistema en sus operaciones diarias. o Elementos Clave: § Recursos Humanos y Aceptación de Usuarios: Asegura que el personal esté capacitado y dispuesto a adoptar el nuevo sistema. § Impacto en los Procesos Actuales: Analiza cómo el sistema afectará el flujo de trabajo y los procesos organizacionales, incluyendo cambios en infraestructura y capacitación. § Momento de Implementación: Selecciona el momento adecuado para minimizar interrupciones operativas y asegurar una transición eficiente. o Capacitación de Usuarios: Incluye manuales, guías rápidas, y otros recursos de apoyo para preparar a los usuarios finales y asegurar una adopción efectiva del sistema. 2. Importancia del Análisis de Factibilidad y Viabilidad Reducción de Riesgos: Identifica limitaciones y riesgos potenciales en las etapas iniciales del proyecto, permitiendo tomar medidas proactivas. Optimización de Recursos: Garantiza que los recursos (económicos, humanos y tecnológicos) se utilicen de manera eficiente y alineada con los objetivos organizacionales. Toma de Decisiones Informadas: Facilita decisiones estratégicas sobre la viabilidad, modificación o cancelación del proyecto. Alineación con Objetivos Estratégicos: Asegura que el proyecto contribuya a los objetivos organizacionales y que los usuarios finales encuentren valor en la solución propuesta.