Metodologías de Desarrollo PDF
Document Details
Uploaded by frsoal
Tags
Related
- Ingeniería De Software I 2024 PDF
- TEORÍA 3 USO DE HERRAMIENTAS CASE PDF
- Metodologías, Pruebas y Colaboración en Desarrollo de Software (2015-2016) - PDF
- Metodologías de desarrollo. Pruebas. Programas para control de versiones. Plataformas de desarrollo colaborativo de software (PDF)
- Diagrama de Secuencia PDF
- El Proceso Unificado de Desarrollo PDF
Summary
Este documento es una introducción a las metodologías de desarrollo de software, incluyendo las metodologías tradicionales como la cascada y el modelo en V, y las metodologías ágiles como XP y Scrum. También incluye información sobre pruebas y control de versiones.
Full Transcript
1. Metodologías de desarrollo 1.1. Introducción Metodología de desarrollo: es un conjunto de principios, prácticas, y procesos que guían cómo se debe planificar, gestionar, y ejecutar el ciclo de vida del desarrollo de software. Tipos de Metodología Metodologías Tradicionales (Predictiv...
1. Metodologías de desarrollo 1.1. Introducción Metodología de desarrollo: es un conjunto de principios, prácticas, y procesos que guían cómo se debe planificar, gestionar, y ejecutar el ciclo de vida del desarrollo de software. Tipos de Metodología Metodologías Tradicionales (Predictivas) ○ Cascada (Waterfall): metodología secuencial en la que cada fase del desarrollo debe completarse antes de pasar a la siguiente. Las fases típicas incluyen requisitos, diseño, implementación, pruebas, y mantenimiento. ○ Modelo en V (V-Model): extensión del modelo en cascada que enfatiza las fases de verificación y validación. Por cada fase de desarrollo hay una fase de prueba correspondiente. ○ Modelo en Espiral: Se centra en el análisis de riesgos y combina aspectos de desarrollo iterativo con la metodología en cascada. Es adecuado para grandes proyectos con mucha incertidumbre. Ágiles: busca máxima eficiencia. Está pegado al cliente ○ XP ○ Scrum ○ FDD ○ BDD - Behavior-driven development ○ Kanban: pizarra con tareas (To do - Doing - Done) Metodologías de desarrollo ○ Estructuradas, orientadas a procesos: SSDAM Merise Métrica 2-3 ○ Orientadas a objetos: RUP(Rational Unified Process - Iterativo e incremental) → OpenUp (ágil) Booch Method. Enfocada al diseño OMT (técnica de modelado de objetos) PPSE (Jacobson) - invento el diagrama de casos de uso 1.2. Métrica 3 Se concibe como una Metodología de Planificación, Desarrollo y Mantenimiento de Sistemas de Información. Puede ser utilizada libremente con la única restricción de citar la fuente de su propiedad intelectual Desarrollo. Procesos PSI: PLANIFICACIÓN DE SISTEMAS DE INFORMACIÓN. Gestión del proyecto EVS: ESTUDIO DE VIABILIDAD DEL SISTEMA ASI: ANÁLISIS DEL SISTEMA DE INFORMACIÓN DSI: DISEÑO DEL SISTEMA DE INFORMACIÓN CSI: CONSTRUCCIÓN DEL SISTEMA DE INFORMACIÓN IAS: IMPLANTACIÓN Y ACEPTACIÓN DEL SISTEMA MSI → MANTENIMIENTO DE SISTEMAS DE INFORMACIÓN. Gestión del cambio Interfaces: tareas transversales a todo el proyecto Calidad Gestión proyectos ○ GPI→ Actividades de Inicio del Proyecto ○ GPS → Actividades de Seguimiento y Control ○ GPF → Actividades de Finalización del Proyecto Gestión Configuración Seguridad 1.3. Pruebas Pruebas Unitarias: Pruebas de Integración. Pruebas del Sistema. Pruebas de Implantación. Pruebas de Aceptación. Pruebas de Regresión. 2. Clasificación pruebas Métrica 3 2.1. Unitarias Las pruebas unitarias tienen como objetivo verificar la funcionalidad y estructura de cada componente individualmente una vez que ha sido codificado. Caja Blanca/Negra: Poner definición 2.2. Integración Verificar el correcto ensamblaje entre los distintos componentes una vez que han sido probados unitariamente con el fin de comprobar que interactúan correctamente a través de sus interfaces, tanto internas como externas, cubren la funcionalidad establecida y se ajustan a los requisitos no funcionales especificados en las verificaciones correspondientes. Integración incremental ○ De arriba abajo (top-down). El primer componente que se desarrolla y prueba es el primero de la jerarquía (A). Los componentes de nivel más bajo se sustituyen por componentes auxiliares para simular a los componentes invocados. En este caso no son necesarios componentes conductores. Una de las ventajas de aplicar esta estrategia es que las interfaces entre los distintos componentes se prueban en una fase temprana y con frecuencia. ○ De abajo arriba (bottom-up). En este caso se crean primero los componentes de más bajo nivel (E, F) y se crean componentes conductores para simular a los componentes que los llaman. A continuación se desarrollan los componentes de más alto nivel (B, C, D) y se prueban. Por último dichos componentes se combinan con el que los llama (A). Los componentes auxiliares son necesarios en raras ocasiones. Este tipo de enfoque permite un desarrollo más en paralelo que el enfoque de arriba abajo, pero presenta mayores dificultades a la hora de planificar y de gestionar. ○ Estrategias combinadas. A menudo es útil aplicar las estrategias anteriores conjuntamente. De este modo, se desarrollan partes del sistema con un enfoque «top-down«, mientras que los componentes más críticos en el nivel más bajo se desarrollan siguiendo un enfoque «bottom-up«. En este caso es necesaria una planificación cuidadosa y coordinada de modo que los componentes individuales se «encuentren» en el centro. Integración no incremental: Se prueba cada componente por separado y posteriormente se integran todos de una vez realizando las pruebas pertinentes. Este tipo de integración se denomina también Big-Bang (gran explosión). 2.3. Sistema objetivo ejercitar profundamente el sistema comprobando la integración del sistema de información globalmente, verificando el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el resto de sistemas de información con los que se comunica. Pruebas funcionales. Dirigidas a asegurar que el sistema de información realiza correctamente todas las funciones que se han detallado en las especificaciones dadas por el usuario del sistema. Pruebas de comunicación. Determinan que las interfaces entre los componentes del sistema funcionan adecuadamente, tanto a través de dispositivos remotos, como locales. Asimismo, se han de probar las interfaces hombre/máquina. Pruebas de rendimiento. Consisten en determinar que los tiempos de respuesta están dentro de los intervalos establecidos en las especificaciones del sistema. Pruebas de volumen. Consisten en examinar el funcionamiento del sistema cuando está trabajando con grandes volúmenes de datos, simulando las cargas de trabajo esperadas. Pruebas de sobrecarga. Consisten en comprobar el funcionamiento del sistema en el umbral límite de los recursos, sometiéndole a cargas masivas. ○ El objetivo es establecer los puntos extremos en los cuales el sistema empieza a operar por debajo de los requisitos establecidos. Pruebas de disponibilidad de datos. Consisten en demostrar que el sistema puede recuperarse ante fallos, tanto de equipo físico como lógico, sin comprometer la integridad de los datos. Pruebas de facilidad de uso. Consisten en comprobar la adaptabilidad del sistema a las necesidades de los usuarios, tanto para asegurar que se acomoda a su modo habitual de trabajo, como para determinar las facilidades que aporta al introducir datos en el sistema y obtener los resultados. Pruebas de operación. Consisten en comprobar la correcta implementación de los procedimientos de operación, incluyendo la planificación y control de trabajos, arranque y rearranque del sistema, etc. Pruebas de entorno. Consisten en verificar las interacciones del sistema con otros sistemas dentro del mismo entorno. Pruebas de seguridad. Consisten en verificar los mecanismos de control de acceso al sistema para evitar alteraciones indebidas en los datos. 2.4. Implantación Comprobar el funcionamiento correcto del sistema integrado de hardware y software en el entorno de operación, y permitir al usuario que, desde el punto de vista de operación, realice la aceptación del sistema una vez instalado en su entorno real y en base al cumplimiento de los requisitos no funcionales especificados seguridad van dirigidas a verificar que los mecanismos de protección incorporados al sistema cumplen su objetivo rendimiento a asegurar que el sistema responde satisfactoriamente en los márgenes establecidos en cuanto tiempos de respuesta, de ejecución y de utilización de recursos, así como los volúmenes de espacio en disco y capacidad operación se comprueba que la planificación y control de trabajos del sistema se realiza de acuerdo a los procedimientos establecidos, considerando la gestión y control de las comunicaciones y asegurando la disponibilidad de los distintos recursos gestión de copias de seguridad y recuperación, con el objetivo de verificar que el sistema no ve comprometido su funcionamiento al existir un control y seguimiento de los procedimientos de salvaguarda y de recuperación de la información, en caso de caídas en los servicios o en algunos de sus componentes 2.5. Aceptación Validar que un sistema cumple con el funcionamiento esperado y permitir al usuario de dicho sistema que determine su aceptación, desde el punto de vista de su funcionalidad y rendimiento 2.6. Regresión Comprobar que los cambios sobre un componente de un sistema de información, no introducen un comportamiento no deseado o errores adicionales en otros componentes no modificados