Metodologías, Pruebas y Colaboración en Desarrollo de Software (2015-2016) - PDF

2015-2016 Bloque 3 - Tema 10 REPOSITORIOS: ESTRUCTURA Y ACTUALIZACIÓN. GENERACIÓN DE CÓDIGO Y DOCUMENTACIÓN. METODOLOGÍAS DE DESARROLLO. PRUEBAS. PROGRAMAS PARA CONTROL DE VERSIONES. PLATAFORMAS DE DESARROLLO COLABORATIVO DE SOFTWARE PREPARACIÓN OPOSICIONES TÉCNICOS AUXILIARES DE INFORMÁTICA ÍNDICE B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI ÍNDICE.............................................................................................................................................................. 1 1. HERRAMIENTAS CASE: CARACTERÍSTICAS................................................................................................ 3 1. Componentes....................................................................................................................................... 3 2. Clasificación......................................................................................................................................... 4 3. Características...................................................................................................................................... 4 4. Ventajas............................................................................................................................................... 5 2. HERRAMIENTAS PARA EL DESARROLLO SOFTWARE................................................................................. 6 3. GENERACIÓN DE CÓDIGO Y DOCUMENTACIÓN...................................................................................... 11 1. Generación automática de código..................................................................................................... 11 2. Generación automática de documentación....................................................................................... 11 4. MANTENIMIENTO DEL SOFTWARE, INGENIERÍA INVERSA Y REINGENIERÍA........................................... 14 1. Ingeniería inversa y reingeniería........................................................................................................ 14 2. Problemas del código......................................................................................................................... 16 3. Ingeniería inversa y reingeniería........................................................................................................ 17 5. METODOLOGÍAS DE DESARROLLO SOFTWARE....................................................................................... 18 1. Rapid Application Development (RAD)............................................................................................... 18 2. Rational Unified Process (RUP).......................................................................................................... 19 3. Scrum................................................................................................................................................. 20 4. Extreme Programming (XP)................................................................................................................ 21 5. Métrica v3.......................................................................................................................................... 23 6. PRUEBAS DEL SOFTWARE........................................................................................................................ 26 1. Introducción....................................................................................................................................... 26 2. Pruebas UNITARIAS............................................................................................................................ 27 3. Pruebas de INTEGRACIÓN.................................................................................................................. 31 4. Pruebas del SISTEMA.......................................................................................................................... 33 5. Pruebas de IMPLANTACIÓN............................................................................................................... 34 6. Pruebas de ACEPTACIÓN.................................................................................................................... 35 7. Pruebas de REGRESIÓN...................................................................................................................... 36 8. Otros tipos de pruebas....................................................................................................................... 37 9. Herramientas para pruebas del software.......................................................................................... 38 10. ISO/IEC 29119 Pruebas del software.................................................................................................. 39 7. PROGRAMAS PARA CONTROL DE VERSIONES......................................................................................... 40 1. Características de los SCV.................................................................................................................. 40 2. Terminología básica........................................................................................................................... 40 3. Tipos de arquitectura......................................................................................................................... 42 8. ESTUDIO DE UN SCV: GIT......................................................................................................................... 44 1. Fundamentos de Git........................................................................................................................... 44 2. Particularidades de Git....................................................................................................................... 45 3. Configuración de Git.......................................................................................................................... 47 4. Operaciones sobre repositorios.......................................................................................................... 47 5. Operaciones con archivos.................................................................................................................. 49 6. Ramas................................................................................................................................................ 52 7. Repositorios remotos......................................................................................................................... 56 8. Etiquetas............................................................................................................................................ 57 9. Resumen Git....................................................................................................................................... 57 9. PLATAFORMAS DE DESARROLLO COLABORATIVO DE SOFTWARE.......................................................... 58 PABLO ARELLANO www.theglobeformacion.com Página 2 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI 1. HERRAMIENTAS CASE: CARACTERÍSTICAS El ciclo de vida es el conjunto de fases por las que pasa el sistema que se está desarrollando, desde que nace la idea inicial hasta que el software es retirado o remplazado (muere). Tradicionalmente las fases han sido: Teniendo en cuenta esto y que el término CASE (Computer Aided/Assisted Software Engineering) significa "Ingeniería del Software asistida por computador", una herramienta CASE es un software que se utiliza para dar soporte a las actividades del proceso software permitiendo la automatización del proceso de producción de desarrollo de software. Se puede definir también como el conjunto de metodologías y herramientas que dan un soporte automatizado a la ingeniería del software en todas o algunas de las etapas del desarrollo del software. 1. Componentes De manera genérica una herramienta CASE está formada por: - Repositorio: almacén que alberga TODOS los elementos definidos. - Metamodelo: constituye el marco para la definición las técnicas y metodologías soportadas por la herramienta. - Herramienta de carga/descarga de datos: permiten cargar datos externos en el repositorio y generar datos como código, esquemas de bases de datos, etc. - Comprobación de errores: módulo encargado de realiza un análisis para comprobar la exactitud, integridad y consistencia de los esquemas generados por la herramienta. Interfaz de usuario: se encarga de la comunicación entre la herramienta y los desarrolladores. PABLO ARELLANO www.theglobeformacion.com Página 3 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI 2. Clasificación Las herramientas CASE, en función de las fases del ciclo de vida que abarcan, se pueden agrupar de la forma siguiente: - Upper CASE (U-CASE): se centran en las primeras fases del ciclo de vida del software: planificación, análisis de requisitos y estrategia de desarrollo. Usan diagramas UML. - Middle CASE (M-CASE): se centran en las etapas intermedias del ciclo de vida del software: análisis y diseño. - Lower CASE (L-CASE): se centran en las últimas fases del ciclo de vida del software: diseño detallado, la implementación y las pruebas. Las L-CASE se encargan de la generación del código, la generación de la documentación, la depuración de programas y las pruebas. - Integrated CASE (I-CASE): abarcan todas las fases del ciclo de vida del software. - CAST (Computer Aided Software Testing): herramientas de soporte a la prueba de software. - IPSE (Integrated Programming Support Environment): se encargan de la gestión de proyectos y de la gestión de la configuración. - MetaCASE: permiten definir y construir herramientas CASE. 3. Características Las características más destacables de las herramientas CASE son: - Generación de diagramas UML a partir de código y viceversa: DFD, diagrama entidad- relación, diagrama de clases, diagrama de estructura de datos. - Generación de esqueletos de código anotados. - Generación de un prototipo al inicio del proyecto que permite visualizar la aplicación antes de ser generada. - Generación de casos de prueba. - Generación automática de documentación. - Conversión del código fuente en un formato a un formato estándar. - Editores de código. - Compiladores. - Depuradores. - Herramientas para el diseño de interfaces. - Análisis estático: ayuda a generar casos de prueba bien basados en código fuente de tal manera que analiza las ramificaciones y las condiciones del código fuente para generar los casos de prueba. O bien, comprueba que se cumple los requisitos específicos del usuario. PABLO ARELLANO www.theglobeformacion.com Página 4 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI - Análisis dinámico: son pruebas que se realizan con un programa en ejecución. - Métricas y gestión de calidad. - Planificación de proyectos. - Medición del coste o el esfuerzo de un proyecto. 4. Ventajas El beneficio adicional obtenido por la utilización de un CASE actual (si se compara con la utilización de una metodología sin el uso de un CASE) se representa en los siguientes aspectos: - Facilita la verificación y mantenimiento de la consistencia de la información del proyecto. - Facilita el establecimiento de estándares en el proceso de desarrollo y documentación. - Facilita el mantenimiento del sistema y las actualizaciones de su documentación. - Facilita la aplicación de las técnicas de una metodología. - Disponibilidad de funciones automatizadas tales como: obtención de prototipos, generación de código, generación de pantallas e informes, generación de diseños físicos de bases de datos, verificadores automáticos de consistencia. - Facilita la aplicación de técnicas de reutilización y reingeniería. - Facilita la planificación y gestión del proyecto informático. PABLO ARELLANO www.theglobeformacion.com Página 5 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI 2. HERRAMIENTAS PARA EL DESARROLLO SOFTWARE Un proyecto de integración continua necesita, al menos, los siguientes componentes: - Herramienta de gestión y construcción de proyectos. - Repositorio de código (sistema de control de versiones). - Servidor de integración continua. - Herramienta para análisis estático de la calidad del código. - Repositorio de artefactos. - Entornos de ejecución. - Despliegue. - Herramientas de monitorización. Se detallan las herramientas agrupadas según el estado en la producción de software: - Desarrollar (Codificar): en esta categoría están aquellas herramientas encaminadas a mejorar el rendimiento del desarrollo. Las podemos dividir en subcategorías: o IDEs (entornos de desarrollo integrado) para el desarrollo: Eclipse, IntelliJ IDEA, NetBeans, Visual Studio (Microsoft), Xcode (Mac), Android Studio. o Editores de texto: Sublime Text, Notepad++, GNU nano, GNU Emacs. o Sistemas de gestión de repositorios para control de versiones: Git, GitHub, GitLab, Bitbucket, FishEye. o Herramientas de análisis (estático) de calidad de código: SonarQube. El análisis nos dice cómo de bueno es nuestro código, los errores que tiene, los tipos de errores encontrados y las causas, y añade una serie de posibles soluciones. También, califica la calidad del código, valor que se actualiza continuamente tras cada modificación del código del proyecto, por lo que puede evolucionar tanto positiva como PABLO ARELLANO www.theglobeformacion.com Página 6 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI negativamente. Esto permite supervisar de forma continua la calidad del código del software de cada proyecto, y analizar tendencias. SonarQube evalúa aspectos como la complejidad ciclomática del código (número de caminos independientes), número de comentarios o las líneas de código que no se ejecutan. Asimismo, informa sobre código duplicado, estándares de codificación, pruebas unitarias, cobertura de código, posibles errores y diseño del software. o Revisión de código: Crucible, Gerrit. o Seguimiento de errores y bugs: Jira, Redmine, Bugzilla, MantisBT, Trac. o Herramientas para hacer merges (fusiones) y comparar diferencias entre versiones: KDiff3, DiffMerge, P4Merge, JDiff. - Build: en esta categoría estarían encuadradas aquellas herramientas cuya finalidad es la de preparar el código para su ejecución y prueba. El rol de estas herramientas es verificar que un desarrollo se ha validado y puede pasarse a un entorno de staging o de producción. Si se utilizan de forma correcta permiten eliminar gran parte del tiempo de pruebas que tienen que emplear los desarrolladores y además asegura la detección de problemas inesperados introducidos en partes del desarrollo que antes del cambio funcionaban bien. Herramientas: o Integración continua (compilación y ejecución pruebas de todo el proyecto): Jenkins (open source y escrito en Java), Bamboo, CircleCI, CruiseControl, Go.CD, Travis CI. o Automatización de los builds: ▪ Apache Maven: gestión y construcción de proyectos software. Utiliza el Project Object Model (POM, fichero pom.xml) para describir el proyecto software a construir, sus dependencias con módulos externos y el orden de construcción de los elementos. ▪ Apache Ant: automatización de tareas repetitivas y mecánicas como construcción de paquetes y proyectos. ▪ Make, Gradle, Kotlin DSL, MSBuild (.NET). - Test: el objetivo de las herramientas de test es reducir los casos de prueba manual al mismo tiempo que se incrementa la cobertura, y por tanto ahorrando tiempo de creación de la automatización y esfuerzo y tiempo de ejecución de los tests. Herramientas de test: o Continuo web: Selenium. o Continuo móvil: Appium. o Iterativo: Lux, Expect. o Para criterios de aceptación: FitNesse, FIT, EasyAccept. PABLO ARELLANO www.theglobeformacion.com Página 7 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI o Unitarios: XUnit, JUnit, Unit.js, ATF. o Servicios web: SoapUI y Postman (RESTful). - Empaquetado: en esta categoría se agrupan las herramientas encaminadas a evitar la dependencia de proveedores y repositorios externos en los procesos de build y para poder mantener controladas las librerías propias de la organización, así como para poder compartir con clientes externos los desarrollos. Herramientas: o Repositorio de artefactos: Nexus 3, Artifactory. Útiles para subir y compartir librerías de terceros así como para publicar los artefactos (por ejemplo, WAR o JAR) de nuestra aplicación. o Contenedores: Docker. o Gestión documental: Confluence (wiki), Owncloud (alojamiento de archivos, open source). - Gestión de la configuración: esta categoría agrupa aquellas herramientas diseñadas con el propósito de usar scripts, recetas, blueprints (plan software), playbooks, plantillas, etc. para la simplificación de la automatización y orquestación en los entornos de ejecución de la organización. El objetivo es proporcionar un modo estándar y consistente de realización de los despliegues y sus configuraciones. Herramientas: o Puppet, Salt, Chef, Ansible, Vagrant, Terraform y GitOps (prácticas para gestionar configuraciones de aplicaciones y las infraestructuras utilizando Git). - Despliegue: dentro de esta categoría se incluyen las herramientas y servicios que permiten la ejecución sobre infraestructura tanto de las herramientas necesarias para DevOps como de los desarrollos realizados. Herramientas: o Orquestación de infraestructura privada: Gradiant ITBox, MaaS, Openstack, Kubernetes. o Orquestación de servicios: Docker Compose, Docker Swarm. o Orquestación multicloud: Gradiant ITBox, Cloudify, Apache Brooklyn. o Virtualización: Docker, KVM (Kernel-based Virtual Machine). o Cloud públicos: AWS (Amazon Web Services), Microsoft Azure, Google CE (Compute Engine). - Monitorización: Uno de los muros que DevOps trata de romper es la falta de feedback sobre las aplicaciones puestas en producción una vez se ha realizado el despliegue por PABLO ARELLANO www.theglobeformacion.com Página 8 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI parte del departamento de operaciones. La monitorización debe ser algo transversal y debe llegar sin filtros al departamento de desarrollo que podrán detectar e interpretar los resultados del día a día de sus desarrollos. Herramientas: o Rendimiento de aplicaciones: Zabbix, Nagios, Influxdb, Telegraf, Grafana. o Revisión de logs: GrayLog, Logstash, Kibana, Elasticsearch. o Experiencia de usuario y analíticas web: Piwik PRO, Matomo (PHP/MySQL), Google Web Analytics. Sistema de integración continua Definimos un sistema de integración continua (compilación y ejecución pruebas de todo el proyecto) sencillo que persigue que cada vez que un programador haga un push en el repositorio remoto (en este caso, Git) y suba código a la rama master, Jenkins lo detecte, compile la aplicación, llame a SonarQube para ejecutar los test y realizar el análisis de la calidad del código y, si todo ha ido bien, publique un WAR del proyecto en Nexus PABLO ARELLANO www.theglobeformacion.com Página 9 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI Resumen de herramientas PABLO ARELLANO www.theglobeformacion.com Página 10 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI 3. GENERACIÓN DE CÓDIGO Y DOCUMENTACIÓN 1. Generación automática de código Un generador de código fuente es una herramienta que a partir de diagramas UML (clases, secuencia) genera de manera automática el código correspondiente sin necesidad de programador, acelerando el proceso de desarrollo del software. Listamos las herramientas más usadas: - Altova Umodel: herramienta que genera código Java, C++, C# o VB.NET a partir de las clases del diagrama de clases de UML. Por otro lado, a partir de los diagramas de secuencia se genera el código de los métodos. - Visual Paradigm: herramienta que, a partir de diagramas UML, genera de forma automática código para diversos lenguajes de programación como Java, C#, C++, Python, PHP, Ruby o VB.NET. 2. Generación automática de documentación Un generador de documentación es una herramienta que, a partir de un código fuente produce como salida de forma automática documentación en uno o varios formatos dirigida a desarrolladores. De entre las herramientas existentes se relacionan las más destacadas: - Javadoc: herramienta que genera documentación API en formato HTML a partir de un código fuente en lenguaje Java. El código contiene una serie de etiquetas para que esta herramienta pueda crear la documentación: Etiqueta Descripción @author Autor @version Versión de la clase o método PABLO ARELLANO www.theglobeformacion.com Página 11 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI @param Definición de un parámetro de un método @return Información del valor que devuelve un método @throws Excepción lanzada por el método @see Asociado o vinculado con otro método o clase @since Versión del producto @serial Significado del campo y valores aceptados @deprecated Método o clase que no se recomienda su uso Ejemplo de javadoc: a partir del código fuente anotado con las etiquetas de javadoc se ejecuta la herramienta produciendo la salida que muestra en la imagen. public class Main { public static void main(String[] args) { System.out.println("Hola mundo"); } } PABLO ARELLANO www.theglobeformacion.com Página 12 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI - JSDoc: herramienta que genera documentación a partir del código fuente JavaScript, al estilo de javadoc. - Doxygen: herramienta multiplataforma escrita en C++, bajo licencia GPLv2, que genera documentación a partir del código. - phpDocumentor: herramienta dirigida al análisis el código fuente PHP y produce documentación basada en comentarios. - NaturalDocs: herramienta escrita en C# que genera documentación a partir del código fuente. Es multilenguaje y bajo licencia GPL. - Sphinx: herramienta escrita en Python bajo licencia BSD que genera documentación en HTML y otros formatos. - DocFX: herramienta que genera documentación en formato HTML a partir de código fuente en lenguaje C#, VB y F#. - SandCastle: herramienta de Microsoft para.NET escrita en C# que produce de manera automática documentación del código al estilo MSDN a partir de comentarios XML incluidos en el mismo. - VSdocman: herramienta integrada en Visual Studio que genera documentación del código C# y VB.NET. - YARD: herramienta dirigida a generar documentación a partir de código fuente en lenguaje Ruby. PABLO ARELLANO www.theglobeformacion.com Página 13 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI 4. MANTENIMIENTO DEL SOFTWARE, INGENIERÍA INVERSA Y REINGENIERÍA Una vez que un producto software es entregado, es decir, entra en producción, pasamos a la fase de mantenimiento de su ciclo de vida (ver fases del ciclo de vida en apartado 1). El mantenimiento engloba una serie de tareas vinculadas a la modificación del producto software, que pueden ser correcciones, mejoras, adaptaciones a cambios en el entorno o motivadas por la especificación de nuevos requisitos. METRICA v3 distingue entre 4 tipos de mantenimiento: - CORRECTIVO: abarca los cambios precisos para corregir errores del producto software. - ADAPTATIVO: son las modificaciones que afectan a los entornos en los que el sistema opera, como son la configuración del hardware, el software de base, las comunicaciones, etc. - EVOLUTIVO: son las incorporaciones, modificaciones y eliminaciones necesarias en un producto software para cubrir la expansión o cambio en las necesidades del usuario. - PERFECTIVO: son las acciones llevadas a cabo para mejorar la calidad interna de los sistemas en cualquiera de sus aspectos: reestructuración del código, definición más clara del sistema y optimización del rendimiento y eficiencia. Un grave problema que se puede presentar durante el mantenimiento es el software complejo. Es posible medir la complejidad que representa el mantenimiento de un software concreto basado en medir el desorden de ese software, concepto que se denomina ENTROPÍA del software. 1. Ingeniería inversa y reingeniería Las actividades que se van a proponer son necesarias en sistemas heredados (legacy systems), ya que se han podido utilizar tecnologías o técnicas “anticuadas” u obsoletas, no existe documentación o ha finalizado el soporte de la aplicación. También se aplica en sistemas nuevos en los que se quiere mejorar el rendimiento o establecer un diseño diferente al dado. Para cubrir la necesidad de realizar evoluciones más amplias de un sistema es necesario trabajar en los diferentes niveles de abstracción (requisitos, diseño, implementación) con el objetivo de realizar cambios más drásticos. A esta forma de modernización se le denomina reingeniería. PABLO ARELLANO www.theglobeformacion.com Página 14 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI Por otro lado, ante la necesidad de recuperar requisitos o el diseño de un sistema desde el código surge la ingeniería inversa que se ocupa de estudiar el sistema en orden inverso al establecido en el ciclo de vida habitual. Por tanto, este modelo considera tres niveles de abstracción en un sistema: requisitos, diseño e implementación; y define los siguientes conceptos: - Ingeniería INVERSA (Reverse Engineering): es el proceso de analizar un sistema para identificar los componentes y las interrelaciones entre ellos, creando representaciones del sistema en otra forma distinta a la original o bien a un nivel superior de abstracción. - Ingeniería HACIA DELANTE o DIRECTA (Forward Engineering): es el proceso que va desde un alto nivel de abstracción, que es independiente de la implementación concreta, hasta la propia implementación física del sistema. Es el proceso habitual. - REINGENIERÍA (Reengineering): es el examen y modificación de un sistema para ser reconstruido de una forma nueva y además realizar la implantación derivada de esa nueva forma. Normalmente, podemos definirla como: Reingeniería = Ingeniería inversa + [Reestructuración] + Ingeniería directa - REESTRUCTURACIÓN (Reestructuring): es la transformación de una forma de representación del sistema (código) en otra distinta, pero del mismo nivel de abstracción, sin modificar el comportamiento externo del sistema. También denominado refactorización (refactoring). Por último, se describen los tipos de migración de aplicaciones: - Refronting o refacing: consiste en modificar únicamente la interfaz gráfica de una aplicación, sin necesidad de reescribir la aplicación completa. - Rehosting (“lift and shift” o realojamiento): consiste en mover la aplicación de un entorno hardware (legacy system) a otro entorno más moderno, sin modificar el código ni la arquitectura. PABLO ARELLANO www.theglobeformacion.com Página 15 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI - Rearchitecting (reescritura): consiste en desarrollar de nuevo la aplicación utilizando nuevos paradigmas de programación (por ejemplo, desarrollo web, orientación a objetos, u otros) y que puede requerir el empleo de técnicas de reingeniería e ingeniería inversa para determinar la funcionalidad completa de la aplicación antes de migrarla. - Replacement (sustitución): consiste en sustituir la aplicación de forma completa por una o varias aplicaciones nuevas. - Retirada. - Wrapping o interoperation: consiste en encapsular la aplicación o algunos de sus componentes para que sean utilizados por otras aplicaciones o infraestructura con tecnología más moderna. - Retain: no es una migración en modo estricto, es decir, consiste en no migrar una aplicación a la nube. - Migración a la nube. 2. Problemas del código En programación estructurada y OO destacamos los siguientes problemas: - Código espagueti: compuesto por complejas estructuras de control de flujo. - Código ravioli: formado por clases simples y comprensibles que al interactuar entre sí se vuelven muy complejas desde un punto de vista global. - Código lasaña: compuesto por muchas capas complejas e interconectadas entre sí que ante un cambio en una capa conlleva cambios en otras capas. - Código pizza: aquel que tiene una arquitectura plana. - Overengineering (sobreingeniería): código más complicado de lo que debería para realizar lo que se espera, ya sea por la amplitud de la funcionalidad, el exceso de seguridad o por estar centrado en el rendimiento. En POA (programación orientada a aspectos) tenemos los siguientes problemas: - Scattered code (código disperso): para la definición de una propiedad o comportamiento las líneas de código están distribuidas en diferentes lugares de la aplicación. Dificulta desarrollo y mantenimiento - Tangled code (código enmarañado): un mismo módulo implemente diferentes aspectos del sistema de forma simultánea. PABLO ARELLANO www.theglobeformacion.com Página 16 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI Por último, tenemos el término "code smell" (código que huele) que hace referencia a aquel código mal diseñado candidato a ser reestructurado o refactorizado. La herramienta vista SonarQube va dirigida a localizar este tipo de código. Así pues, podemos considerar code smell: - Código duplicado. - Clases o métodos grandes. - Clases con escasa funcionalidad (lazy). - Métodos/funciones/procedimientos con un número elevado de parámetros. - Complejidad forzada por la aplicación inadecuada de patrones de diseño. 3. Ingeniería inversa y reingeniería Se proponen una lista de acciones o buenas prácticas para generar código de calidad: - Aplicación de los principios SOLID y otros concordantes. - Uso de patrones de diseño. - Uso de estándares y convenciones para la codificación. - Documentación del código. - Análisis estático de la calidad (por ejemplo, con SonarQube). PABLO ARELLANO www.theglobeformacion.com Página 17 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI 5. METODOLOGÍAS DE DESARROLLO SOFTWARE Una metodología es un conjunto integrado de técnicas y métodos que permite abordar de forma homogénea y abierta cada una de las actividades del ciclo de vida de un proyecto de desarrollo. Es un proceso de software detallado y completo. Una metodología de desarrollo de software es un marco de trabajo que se usa para estructurar, planificar y controlar el proceso de desarrollo de sistemas de información. Una gran variedad de estos marcos de trabajo ha evolucionado durante los años, cada uno con sus propias fortalezas y debilidades. Una metodología de desarrollo de sistemas no tiene que ser necesariamente adecuada para usarla en todos los proyectos. Cada una de las metodologías disponibles es más adecuada para tipos específicos de proyectos, basados en consideraciones técnicas, organizacionales, de proyecto y de equipo. Según la filosofía de desarrollo se pueden clasificar las metodologías en dos grupos. - Metodologías tradicionales (formales o pesadas): se basan en una fuerte planificación durante todo el desarrollo. Se focalizan en la documentación, planificación y procesos. - Metodologías ágiles: en las que el desarrollo de software es incremental, cooperativo, sencillo y adaptado. Ponen de relevancia que la capacidad de respuesta a un cambio es más importante que el seguimiento estricto de un plan. 1. Rapid Application Development (RAD) La metodología de desarrollo rápido de aplicaciones (RAD) se desarrolló para responder a la necesidad de entregar sistemas muy rápido. El enfoque de RAD no es apropiado para todos los proyectos. El alcance, el tamaño y las circunstancias, todo ello determina el éxito de un enfoque RAD. El método RAD tiene una lista de tareas y una estructura de desglose de trabajo diseñada para la rapidez. El método comprende el desarrollo iterativo, la construcción de prototipos y el uso de utilidades CASE. Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y rapidez de ejecución. RAD requiere el uso interactivo de técnicas estructuradas y prototipos para definir los requisitos de usuario y diseñar el sistema final. Usando técnicas estructuradas, el desarrollador primero construye modelos de datos y modelos de procesos de negocio preliminares de los requisitos. Los prototipos ayudan entonces al analista y los usuarios a verificar tales requisitos y a refinar formalmente los modelos de datos y procesos. El ciclo de modelos resulta a la larga en una combinación de requisitos de negocio y una declaración de diseño técnico para ser usado en la construcción de nuevos sistemas. PABLO ARELLANO www.theglobeformacion.com Página 18 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI 2. Rational Unified Process (RUP) El proceso unificado Rational (RUP) es un marco de trabajo de proceso de desarrollo de software iterativo creado por Rational Software Corporation, una división de IBM desde 2003. RUP no es un proceso preceptivo concreto individual, sino un marco de trabajo de proceso adaptable, con la idea de ser adaptado por las organizaciones de desarrollo y los equipos de proyecto de software que seleccionarán los elementos del proceso que sean apropiados para sus necesidades. RUP resultó de la combinación de varias metodologías y se vio influenciado por métodos previos como el modelo en espiral. Las consideraciones clave fueron el fallo de proyectos usando métodos monolíticos del estilo del modelo en cascada y también la llegada del desarrollo orientado a objetos y las tecnologías GUI, un deseo de elevar el modelado de sistemas a la práctica del desarrollo y de resaltar los principios de calidad que aplicaban a las manufacturas en general al software. El proceso fue diseñado con las mismas técnicas con las que el equipo solía diseñar software; tenía un modelo orientado a objetos subyacente, usando UML (Unified Modeling Language). Fases RUP determina que el ciclo de vida del proyecto consiste en cuatro fases. Estas fases permiten que el proceso sea presentado a alto nivel de una forma similar a como sería presentado un proyecto basado en un estilo en cascada, aunque en esencia la clave del proceso recae en las iteraciones de desarrollo dentro de todas las fases. También, cada fase tiene un objetivo clave y un hito al final que denota que el objetivo se ha logrado. Las cuatro fases en las que divide el ciclo de vida del proyecto son: - Fase de iniciación: se define el alcance del proyecto. Termina con el hito objetivos del desarrollo. - Fase de elaboración: se analizan las necesidades del negocio en mayor detalle y se define sus principios arquitectónicos. Termina con el hito arquitectura del sistema. - Fase de construcción: se crea el diseño de la aplicación y el código fuente. Termina con el hito obtención de una funcionalidad completa. - Fase de transición: se entrega el sistema a los usuarios. Termina con el hito publicación del producto. Cada una de ellas es, a su vez, dividida en una serie de iteraciones que ofrecen como resultado un incremento del producto desarrollado, que añade o mejora las funcionalidades del sistema en desarrollo. Es decir, un “incremento” no implica necesariamente una ampliación de dicho sistema. Durante cada una de estas iteraciones se realizarán a su vez las actividades definidas en el ciclo de vida clásico: requisitos, análisis, diseño, implementación, prueba e implantación. Aunque todas las iteraciones suelen incluir trabajo en casi todas estas actividades, el grado de esfuerzo dentro de cada una de ellas varía a lo largo del proyecto. Por ejemplo, en la fase PABLO ARELLANO www.theglobeformacion.com Página 19 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI de inicio se centrarán más en la definición de requisitos y en el análisis, y durante la de construcción quedarán relegadas en favor de la implementación y las pruebas. Dentro de cada iteración, las tareas se categorizan en nueve disciplinas: - Seis disciplinas de ingeniería: modelaje de negocio, requisitos, análisis y diseño, implementación, pruebas, despliegue. - Tres disciplinas de soporte: gestión de la configuración y del cambio, gestión de proyectos y entorno. 3. Scrum Scrum es un proceso ágil que se puede usar para gestionar y controlar desarrollos complejos de software y productos usando prácticas iterativas e incrementales. Scrum es un esqueleto de proceso que incluye un conjunto de prácticas y roles predefinidos. Los roles principales en Scrum son el “ScrumMaster” que mantiene los procesos y trabaja junto con el jefe de proyecto, el “Product Owner” que representa a las personas implicadas en el negocio y el “Team” que incluye a los desarrolladores. Durante cada iteración (sprint- periodos de tiempo), típicamente un periodo de 2 a 4 semanas (longitud decidida por el equipo), el equipo crea un incremento de software operativo. El conjunto de características que entra en una iteración viene del “backlog” del producto, que es un conjunto priorizado de requisitos de trabajo de alto nivel que se han de hacer. Los ítems que entran en una iteración se determinan durante la reunión de planificación de la iteración. Durante esta reunión, el Product Owner informa al equipo de los ítems en el backlog del producto que quiere que se completen. El equipo determina entonces a cuanto de eso puede comprometerse a completar durante la siguiente iteración. Durante una iteración, nadie puede cambiar el backlog de la iteración, lo que significa que PABLO ARELLANO www.theglobeformacion.com Página 20 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI los requisitos están congelados para esa iteración. Cuando se completa una iteración, el equipo demuestra el uso del software. Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar sus pensamientos sobre lo que quieren y necesitan, y de que los desafíos que no se pueden predecir no se pueden tratar fácilmente de una forma predictiva o planificada tradicional. Por esto, Scrum adopta un enfoque empírico, aceptando que el problema no se puede entender o definir completamente, centrándose en cambio en maximizar las habilidades del equipo para entregar rápidamente y responder a los requisitos emergentes. 4. Extreme Programming (XP) La programación extrema (XP) es un enfoque de la ingeniería del software formulado por Kent Beck. Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos. Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto y aplicarlo de manera dinámica durante el ciclo de vida del software. XP es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en el desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en la realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico. PABLO ARELLANO www.theglobeformacion.com Página 21 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI Elementos de la metodología: - Las historias de usuario: son la técnica utilizada para especificar los requisitos del software. Se trata de tarjetas de papel en las cuales el cliente describe brevemente las características que el sistema debe poseer, sean requisitos funcionales o no funcionales. El tratamiento de las historias de usuario es muy dinámico y flexible. Cada historia de usuario es lo suficientemente comprensible y delimitada para que los programadores puedan implementarlas en unas semanas. Las historias de usuario se descomponen en tareas de programación y se asignan a los programadores para ser implementadas durante una iteración. - Roles XP: o Programador: el programador escribe las pruebas unitarias y produce el código del sistema o Cliente: escribe las historias de usuario y las pruebas funcionales para validar su implementación. Además, asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración centrándose en apoyar mayor valor al negocio. o Encargado de pruebas (tester): ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para las pruebas. o Encargado de seguimiento (tracker): proporciona realimentación al equipo. Verifica el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, para mejorar futuras estimaciones. Realiza el seguimiento del progreso de cada iteración. o Entrenador (coach): es el responsable del proceso global. Debe proveer guías al equipo de forma que se apliquen las prácticas XP y se siga el proceso correctamente. o Consultor: es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto, en el que puedan surgir problemas. o Gestor (big boss): es el vínculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinación. - Proceso XP: el ciclo de desarrollo consiste en los siguientes pasos: 1) El cliente define el valor de negocio a implementar. 2) El programador estima el esfuerzo necesario para su implementación. 3) El programador construye ese valor. 4) Vuelve al paso 1. En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No se debe presionar al programador a realizar más trabajo que el estimado, ya que se perderá calidad en el software o no se cumplirán los plazos. De la misma forma el cliente tiene la obligación de manejar el ámbito de entrega del producto, para asegurarse de que el sistema tenga el mayor valor de negocio posible. PABLO ARELLANO www.theglobeformacion.com Página 22 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI El ciclo de vida ideal de XP consiste en 6 fases: exploración, planificación de la entrega, iteraciones, producción, mantenimiento y muerte del proyecto. 5. Métrica v3 La metodología Métrica v3, desarrollada por el extinto Ministerio de Administraciones Públicas, ofrece a las Organizaciones (particularmente las Administraciones Públicas) un instrumento útil para la sistematización de las actividades que dan soporte al ciclo de vida del software. Las características principales de Métrica v3 son: - Tiene un enfoque orientado al proceso. - Cubre el proceso de Desarrollo y el proceso de Mantenimiento de Sistemas de Información. - Ha sido concebida para abarcar el desarrollo completo de sistemas de información sea cual sea su complejidad y magnitud, por lo cual su estructura responde a desarrollos máximos y deberá adaptarse y dimensionarse en cada momento de acuerdo a las características particulares de cada proyecto. - La metodología descompone cada uno de los procesos en actividades, y éstas a su vez en tareas. Para cada tarea se describe su contenido haciendo referencia a sus principales acciones, productos, técnicas, prácticas y participantes. - El orden asignado a las actividades no debe interpretarse como secuencia en su realización, ya que éstas pueden realizare en orden diferente a su numeración o bien en paralelo, como se muestra en los gráficos de cada proceso. Sin embargo, no se dará por acabado un proceso hasta no haber finalizado todas las actividades del mismo determinadas al inicio del proyecto. Así los procesos de la estructura principal de Métrica v3 son los siguientes: - Planificación de Sistemas de Información (PSI): el objetivo es proporcionar un marco estratégico de referencia para los sistemas de información de un determinado ámbito de la Organización. El resultado del plan de sistemas debe, por tanto, orientar las actuaciones en materia de desarrollo de sistemas de información con el objetivo básico de apoyar la estrategia corporativa, elaborando una arquitectura de información y un plan de proyectos informáticos para dar apoyo a los objetivos estratégicos. - Desarrollo de Sistemas de Información: contiene todas las actividades y tareas que se deben llevar a cabo para desarrollar un sistema, cubriendo desde el análisis de requisitos hasta la instalación del software. Se han abordado los dos tipos de desarrollo: estructurado y orientado a objeto, por lo que ha sido necesario establecer actividades específicas a realizar en alguno de los procesos cuando se utiliza la tecnología de orientación a objetos. PABLO ARELLANO www.theglobeformacion.com Página 23 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI Para facilitar la comprensión y dada su amplitud y complejidad de este proceso, se ha subdividido en 5 procesos: o Estudio de Viabilidad del Sistema (EVS): el propósito de este proceso es analizar un conjunto concreto de necesidades, con la idea de proponer una solución a corto plazo. Los criterios con los que se hace esta propuesta no serán estratégicos sino tácticos y relacionados con aspectos económicos, técnicos, legales y operativos. o Análisis del Sistema de Información (ASI): el propósito de este proceso es conseguir la especificación detallada del sistema de información, a través de un catálogo de requisitos y una serie de modelos que cubran las necesidades de información de los usuarios para los que se desarrollará el sistema de información y que serán la entrada para el proceso de Diseño del Sistema de Información. o Diseño del Sistema de Información (DSI): el propósito es obtener la definición de la arquitectura del sistema y del entorno tecnológico que le va a dar soporte, junto con la especificación detallada de los componentes del sistema de información. A partir de dicha información, se generan todas las especificaciones de construcción relativas al propio sistema, así como la especificación técnica del plan de pruebas, la definición de los requisitos de implantación y el diseño de los procedimientos de migración y carga inicial, éstos últimos cuando proceda. o Construcción del Sistema de Información (CSI): tiene como objetivo final la construcción y prueba de los distintos componentes del sistema de información, a partir del conjunto de especificaciones lógicas y físicas del mismo, obtenido en el proceso DSI. Se desarrollan los procedimientos de operación y seguridad y se elaboran los manuales de usuario final y de explotación, estos últimos cuando proceda. o Implantación y Aceptación del Sistema (IAS): tiene como objetivo principal, la entrega y aceptación del sistema en su totalidad, que puede comprender varios sistemas de información desarrollados de manera independiente, según se haya establecido en el proceso EVS, y un segundo objetivo que es llevar a cabo las actividades oportunas para el paso a producción del sistema. - Mantenimiento de Sistemas de Información (MSI): El objetivo de este proceso es la obtención de una nueva versión de un sistema de información desarrollado, a partir de las peticiones de mantenimiento que los usuarios realizan con motivo de un problema detectado en el sistema o por la necesidad de una mejora del mismo. Solo se considerarán los tipos de mantenimiento correctivo y evolutivo, quedando excluidos los tipos de mantenimiento adaptativo o perfectivo. PABLO ARELLANO www.theglobeformacion.com Página 24 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI Métrica v3 Planificación SI Desarrollo SI Mantenimiento SI EVS ASI DSI CSI IAS La estructura de Métrica v3 incluye también un conjunto de interfaces que definen una serie de actividades de tipo organizativo o de soporte al proceso de desarrollo y a los productos, que en el caso de existir en la organización se deberán aplicar para enriquecer o influir en la ejecución de las actividades de los procesos principales de la metodología y que si no existen habrá que realizar para complementar y garantizar el éxito del proyecto desarrollado. Las interfaces descritas en la metodología son: - Gestión de Proyectos (GP): tiene como finalidad principal la planificación, el seguimiento y control de las actividades y de los recursos humanos y materiales que intervienen en el desarrollo de un Sistema de Información. Como consecuencia de este control es posible conocer en todo momento qué problemas se producen y resolverlos o paliarlos lo más pronto posible, lo cual evitará desviaciones temporales y económicas. - Seguridad (SEG): el análisis de los riesgos constituye una pieza fundamental en el diseño y desarrollo de sistemas de información seguros. Si bien los riesgos que afectan a un sistema de información son de distinta índole: naturales (inundaciones, incendios, etc.) o lógicos (fallos propios, ataques externos, virus, etc.) siendo estos últimos los contemplados en la interfaz de Seguridad de Métrica v3. - Gestión de la Configuración (GC): consiste en la aplicación de procedimientos administrativos y técnicos durante el desarrollo del sistema de información y su posterior mantenimiento. Su finalidad es identificar, definir, proporcionar información y controlar los cambios en la configuración del sistema, así como las modificaciones y versiones de los mismos. Este proceso permitirá conocer el estado de cada uno de los productos que se hayan definido como elementos de configuración, garantizando que no se realizan cambios incontrolados y que todos los participantes en el desarrollo del sistema disponen de la versión adecuada de los productos que manejan. - Aseguramiento de la Calidad (CAL): el objetivo esta interfaz es proporcionar un marco común de referencia para la definición y puesta en marcha de planes específicos de aseguramiento de calidad aplicables a proyectos concretos. PABLO ARELLANO www.theglobeformacion.com Página 25 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI 6. PRUEBAS DEL SOFTWARE Inspecciones sobre CÓDIGO Walkthrough (simulación con datos) Pruebas ESTÁTICAS (sin ejecutar código) Revisión requisitos sobre DOCUMENTOS Revisión diseño Unitarias Pruebas Integración Sistema Pruebas DINÁMICAS (ejecución código) Implantación Aceptación Regresión 1. Introducción Las pruebas son prácticas a realizar en diversos momentos de la vida del sistema de información para verificar: - El correcto funcionamiento de los componentes del sistema. - El correcto ensamblaje entre los distintos componentes. - 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. - El funcionamiento correcto del sistema integrado de hardware y software en el entorno de operación. - Que el sistema cumple con el funcionamiento esperado y permite al usuario de dicho sistema que determine su aceptación, desde el punto de vista de su funcionalidad y rendimiento. - 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. PABLO ARELLANO www.theglobeformacion.com Página 26 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI Las diversas pruebas a que debe ser sometido un sistema deben ser realizadas tanto por el equipo de desarrolladores, como por los usuarios, equipos de operación y mantenimiento en la implantación, aceptación y mantenimiento del sistema de información. Según Métrica v3, los tipos de pruebas que deben realizarse son: - Pruebas Unitarias. - Pruebas de Integración. - Pruebas del Sistema. - Pruebas de Implantación. - Pruebas de Aceptación. - Pruebas de Regresión. 2. Pruebas UNITARIAS Las pruebas unitarias tienen como objetivo verificar la funcionalidad y estructura de cada componente individualmente una vez que ha sido codificado. Las pruebas unitarias constituyen la prueba inicial de un sistema y las demás pruebas deben apoyarse sobre ellas. Existen dos enfoques principales para el diseño de casos de prueba: - Enfoque estructural o de CAJA BLANCA (logic driven). Se verifica la estructura interna del componente con independencia de la funcionalidad establecida para el mismo. Por tanto, no se comprueba la corrección de los resultados si éstos se producen. Ejemplos de este tipo de pruebas pueden ser ejecutar todas las instrucciones del programa, localizar código no usado, comprobar los caminos lógicos del programa, etc. Dentro de este enfoque distinguimos las siguientes técnicas de pruebas: o De interfaz: analiza el flujo de datos hacia y desde el componente, para asegurar que la información fluye adecuadamente. o De estructuras de datos locales: asegura la integridad de los datos durante la ejecución del código. Las pruebas que se realizan en los datos: referencias (accesos a PABLO ARELLANO www.theglobeformacion.com Página 27 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI los datos), declaraciones (definiciones), cálculos (errores de uso de datos) y comparaciones (errores en sentencias condicionales o repetitivas). o Del camino básico: permite la obtención de una medida de la complejidad lógica del diseño procedimental. Se divide en: ▪ Cobertura de sentencias: se crean casos de prueba para probar todas las sentencias de un componente. N.º SENTENCIAS EJECUTADAS EN LA PRUEBA COBERTURA DE SENTENCIAS = 𝑁.º TOTAL SENTENCIAS ▪ Cobertura de condiciones: se crean casos de prueba para probar todos los posibles valores en sentencias condicionales y repetitivas. N.º CONDICIONES EJECUTADAS EN LA PRUEBA COBERTURA DE CONDICIONES = 𝑁.º TOTAL CONDICIONES Estos dos tipos de pruebas son complementarios entre sí y están orientados a cubrir la ejecución de cada una de las sentencias, cada una de las decisiones y cada una de las condiciones en las decisiones, tanto en su vertiente verdadera como falsa. o De bucles o de condiciones límite: se comprueba la validez de un bucle. De INTERFAZ De ESTRUCTURAS DE DATOS LOCALES Técnicas Cobertura de sentencias CAJA BLANCA Del CAMINO BÁSICO Cobertura de decisiones De BUCLES o de CONDICIONES LÍMITE PABLO ARELLANO www.theglobeformacion.com Página 28 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI - Enfoque funcional o de CAJA NEGRA (data driven). Se comprueba el correcto funcionamiento de los componentes del sistema de información, analizando las entradas y salidas y verificando que el resultado es el esperado. Se consideran exclusivamente las entradas y salidas del sistema sin preocuparse por la estructura interna del mismo. Dentro de este enfoque destacamos las siguientes técnicas de prueba: o Particiones de equivalencia: se basa en definir juegos de prueba que representen el conjunto de todas las entradas posibles. Técnica sustentada en el concepto de clase de equivalencia, agrupación de un conjunto de valores de una determinada entrada donde el comportamiento del componente es igual, considerándose su estado como válido o inválido. ¿Cómo determinar las clases de equivalencia? Por ejemplo, si un parámetro de entrada debe estar comprendido en un cierto rango, surgen 3 clases de equivalencia: una clase para los valores por debajo del límite inferior, una clase para los valores dentro del rango y otra clase para los valores que superan el límite superior. Si es obligatorio que una entrada tome un valor de entre los de un conjunto dado, tenemos 2 clases de equivalencia: una clase para los valores dentro del conjunto y otra clase para los valores fuera del conjunto dado. o Análisis de los valores límite o frontera: parte de la base que proporciona la experiencia de que los errores suelen aparecer con mayor probabilidad en los extremos de los campos de entrada. Se seleccionan los valores justo por encima y por debajo de los límites de la clase de equivalencia. Complementa la técnica anterior y maximiza el número de errores con un menor número de pruebas. Ejemplo: si una condición de entrada especifica un rango delimitado por los valores a y b, se deben diseñar casos de prueba para los valores a y b, y para los valores justo por debajo y justo por encima de a y b, respectivamente. o Valores típicos de error y valores imposibles: consiste en probar ciertos valores según la entrada concreta que, a priori, deben causar un error. La elección de los valores depende de la experiencia de los desarrolladores. o Tabla de decisión: se identifican las condiciones (a menudo entradas) y las acciones resultantes (a menudo salidas) del sistema. Éstas conforman las filas de la tabla, generalmente con las condiciones en la parte superior y las acciones en la parte inferior. Cada columna corresponde a una regla de decisión que define una combinación única de condiciones que resulta en la ejecución de las acciones asociadas a esa regla. Los valores de las condiciones y acciones, normalmente se PABLO ARELLANO www.theglobeformacion.com Página 29 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI muestran como valores booleanos (verdadero o falso) o valores discretos (por ejemplo, rojo, verde, azul), pero también pueden ser números o intervalos de números. Estos diferentes tipos de condiciones y acciones pueden estar juntos en la misma tabla. Valores para las condiciones: Verdadero o 1, Falso o 0. Valores para las acciones: X si debe ocurrir, en blanco si no debe ocurrir. o Transición de estado: un diagrama de transición de estado muestra los posibles estados del software, así como la forma en que el software entra, sale y realiza las transiciones entre estados. Una transición se inicia con un evento (por ejemplo, la entrada de un valor por parte del usuario en un campo). El evento resulta en una transición. Si el mismo evento puede resultar en dos o más transiciones diferentes desde el mismo estado, ese evento puede estar condicionado por una condición de guarda. El cambio de estado puede provocar que el software tome una acción (por ejemplo, emitir el resultado de un cálculo o un mensaje de error). Una tabla de transición de estado muestra todas las transiciones válidas y las transiciones potencialmente inválidas entre estados, así como los eventos, las condiciones de guarda y las acciones resultantes para las transiciones válidas. Los diagramas de transición de estado, normalmente, sólo muestran las transiciones válidas y excluyen las transiciones no válidas. La prueba de transición de estado se utiliza para aplicaciones basadas en menús y es extensamente utilizada en la industria del software embebido. La técnica también es adecuada para modelar un escenario de negocio con estados específicos o para probar la navegación en pantalla. o Caso de uso: las pruebas se obtienen a partir de casos de uso, que son una forma específica de diseñar interacciones con elementos software, incorporando requisitos para las funciones del software representadas por los casos de uso. o Grafo causa-efecto. o Pruebas de comparación. PABLO ARELLANO www.theglobeformacion.com Página 30 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI Particiones de equivalencia Análisis de valores límite Valores típicos de error y valores imposibles Tabla de decisión Técnicas CAJA NEGRA Transición de estado Caso de uso Grafo causa-efecto Pruebas de comparación El enfoque que suele adoptarse para una prueba unitaria está claramente orientado al diseño de casos de caja blanca, aunque se complemente con caja negra. El hecho de incorporar casos de caja blanca se debe, por una parte, a que el tamaño del componente es apropiado para poder examinar toda la lógica y por otra, a que el tipo de defectos que se busca coincide con los propios de la lógica detallada en los componentes. Los pasos necesarios para llevar a cabo las pruebas unitarias son los siguientes: - Ejecutar todos los casos de prueba asociados a cada verificación establecida en el plan de pruebas, registrando su resultado. Los casos de prueba deben contemplar tanto las condiciones válidas y esperadas como las inválidas e inesperadas. - Corregir los errores o defectos encontrados y repetir las pruebas que los detectaron. Si se considera necesario, debido a su implicación o importancia, se repetirán otros casos de prueba ya realizados con anterioridad. La prueba unitaria se da por finalizada cuando se hayan realizado todas las verificaciones establecidas y no se encuentre ningún defecto, o bien se determine su suspensión. 3. Pruebas de INTEGRACIÓN El objetivo de las pruebas de integración es 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. PABLO ARELLANO www.theglobeformacion.com Página 31 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI En las pruebas de integración se examinan las interfaces entre grupos de componentes o subsistemas para asegurar que son llamados cuando es necesario y que los datos o mensajes que se transmiten son los requeridos. Debido a que en las pruebas unitarias es necesario crear módulos auxiliares que simulen las acciones de los componentes invocados por el que se está probando y a que se han de crear componentes "conductores" para establecer las precondiciones necesarias, llamar al componente objeto de la prueba y examinar los resultados de la prueba, a menudo se combinan los tipos de prueba unitarias y de integración. Los tipos fundamentales de integración son los siguientes: (1) Integración INCREMENTAL Se combina el siguiente componente que se debe probar con el conjunto de componentes que ya están probados y se va incrementando progresivamente el número de componentes a probar. Con el tipo de prueba incremental lo más probable es que los problemas que surjan al incorporar un nuevo componente o un grupo de componentes previamente probado sean debidos a este último o a las interfaces entre éste y los otros componentes. Se distinguen las siguientes estrategias de integración: - 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. PABLO ARELLANO www.theglobeformacion.com Página 32 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI (2) 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). 4. Pruebas del SISTEMA Las pruebas del sistema tienen como 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. Son pruebas de integración del sistema de información completo, y permiten probar el sistema en su conjunto y con otros sistemas con los que se relaciona para verificar que las especificaciones funcionales y técnicas se cumplen. Dan una visión muy similar a su comportamiento en el entorno de producción. Una vez que se han probado los componentes individuales y se han integrado, se prueba el sistema de forma global. En esta etapa pueden distinguirse los siguientes tipos de pruebas, cada uno con un objetivo claramente diferenciado: - 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 comunicaciones. 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. PABLO ARELLANO www.theglobeformacion.com Página 33 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI - 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. 5. Pruebas de IMPLANTACIÓN El objetivo de las pruebas de implantación es 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. Una vez que hayan sido realizadas las pruebas del sistema en el entorno de desarrollo, se llevan a cabo las verificaciones necesarias para asegurar que el sistema funcionará correctamente en el entorno de operación. Debe comprobarse que responde satisfactoriamente a los requisitos de rendimiento, seguridad, operación y coexistencia con el resto de los sistemas de la instalación para conseguir la aceptación del usuario de operación. Los tipos de pruebas de implantación son: - Las pruebas de SEGURIDAD van dirigidas a verificar que los mecanismos de protección incorporados al sistema cumplen su objetivo. - Las pruebas de RENDIMIENTO tienen como objetivo 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. - Las pruebas de OPERACIÓN se dirigen a comprobar 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. - Las pruebas de GESTIÓN DE COPIAS DE SEGURIDAD Y RECUPERACIÓN tienen como objetivo 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. Para comprobar estos últimos, se provoca el fallo del sistema, verificando si la recuperación se lleva a cabo de forma apropiada. En el caso de realizarse de forma automática, se evalúa la inicialización, los mecanismos de recuperación del estado del sistema, los datos y todos aquellos recursos que se vean implicados. PABLO ARELLANO www.theglobeformacion.com Página 34 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI Las verificaciones de las pruebas de implantación y las pruebas del sistema tienen muchos puntos en común al compartir algunas de las fuentes para su diseño como pueden ser los casos para probar el rendimiento (pruebas de sobrecarga o de stress). El responsable de implantación junto al equipo de desarrollo determina las verificaciones necesarias para realizar las pruebas, así como los criterios de aceptación del sistema. Estas pruebas las realiza el equipo de operación, integrado por los técnicos de sistemas y de operación que han recibido previamente la formación necesaria para llevarlas a cabo. 6. Pruebas de ACEPTACIÓN El objetivo de las pruebas de aceptación es 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. Las pruebas de aceptación son definidas por el usuario del sistema y preparadas por el equipo de desarrollo, aunque la ejecución y aprobación final corresponden al usuario. Estas pruebas también son conocidas por su acrónimo en inglés, UAT (pruebas de aceptación de usuario). Estas pruebas van dirigidas a comprobar que el sistema cumple los requisitos de funcionamiento esperado, recogidos en el catálogo de requisitos y en los criterios de aceptación del sistema de información, y conseguir así la aceptación final del sistema por parte del usuario. El responsable de usuarios debe revisar los criterios de aceptación que se especificaron previamente en el plan de pruebas del sistema y, posteriormente, dirigir las pruebas de aceptación final. La validación del sistema se consigue mediante la realización de pruebas de caja negra que demuestran la conformidad con los requisitos y que se recogen en el plan de pruebas, el cual define las verificaciones a realizar y los casos de prueba asociados. Dicho plan está diseñado para asegurar que se satisfacen todos los requisitos funcionales especificados por el usuario teniendo en cuenta también los requisitos no funcionales relacionados con el rendimiento, seguridad de acceso al sistema, a los datos y procesos, así como a los distintos recursos del sistema. La formalidad de estas pruebas dependerá en mayor o menor medida de cada organización, y vendrá dada por la criticidad del sistema, el número de usuarios implicados en las mismas y el tiempo del que se disponga para llevarlas cabo, entre otros. PABLO ARELLANO www.theglobeformacion.com Página 35 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI Por último, cabe destacar dentro de las pruebas de aceptación otros dos tipos de pruebas de validación: - Pruebas ALFA: realizadas en las instalaciones de la organización que desarrolla, no por el equipo de desarrollo, sino por los clientes o un equipo de prueba independiente. - Pruebas BETA: realizadas por los clientes en sus propias instalaciones. Estas pruebas también se conocen como pruebas de campo. Estas pruebas pueden tener lugar después de las pruebas alfa o puede ocurrir sin que se haya realizado ninguna prueba alfa previa. 7. Pruebas de REGRESIÓN El objetivo de las pruebas de regresión es eliminar el efecto onda, es decir, 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. Las pruebas de regresión se deben llevar a cabo cada vez que se hace un cambio en el sistema, tanto para corregir un error como para realizar una mejora. No es suficiente probar sólo los componentes modificados o añadidos, o las funciones que en ellos se realizan, sino que también es necesario controlar que las modificaciones no produzcan efectos negativos sobre el mismo u otros componentes. Normalmente, este tipo de pruebas implica la repetición de las pruebas que ya se han realizado previamente, con el fin de asegurar que no se introducen errores que puedan comprometer el funcionamiento de otros componentes que no han sido modificados y confirmar que el sistema funciona correctamente una vez realizados los cambios. Las pruebas de regresión pueden incluir: - La repetición de los casos de pruebas que se han realizado anteriormente y están directamente relacionados con la parte del sistema modificada. - La revisión de los procedimientos manuales preparados antes del cambio, para asegurar que permanecen correctamente. - La obtención impresa del diccionario de datos de forma que se compruebe que los elementos de datos que han sufrido algún cambio son correctos. El responsable de realizar las pruebas de regresión será el equipo de desarrollo junto al técnico de mantenimiento, quien a su vez, será responsable de especificar el plan de pruebas de regresión y de evaluar los resultados de dichas pruebas. PABLO ARELLANO www.theglobeformacion.com Página 36 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI 8. Otros tipos de pruebas Las pruebas de humo (smoke testing) son una revisión rápida de un producto de software para comprobar que funciona y no tiene defectos evidentes que interrumpan la operación básica del mismo. Las pruebas de humo pueden resultar útiles justo después de realizar una compilación nueva para decidir si se pueden ejecutar o no pruebas más caras, o inmediatamente después de una implementación, para asegurar que la aplicación funciona correctamente en el entorno. Las pruebas fuzzing testing son un conjunto de pruebas de caja negra que permiten descubrir errores de implementación mediante la introducción de datos al azar, inválidos o malformados. El fin último de estas pruebas es provocar comportamientos inesperados, como fallos que lleguen a hacer que la aplicación deje de funcionar. Este tipo de pruebas permiten, de forma automática o semiautomática, detectar potenciales vulnerabilidades de una forma rápida. Las herramientas utilizadas para llevar a cabo estas pruebas se conocen con el nombre de fuzzers. Las pruebas de usabilidad permiten determinar hasta qué punto el software es comprendido, aprendido, usado y atractivo para los usuarios en condiciones específicas de uso. Esto significa que la UX (User eXperience) es fundamental y para lograrla el software debe ser autoexplicativo e intuitivo, debe permitir los errores de usuario y su comportamiento debe ser consistente. PABLO ARELLANO www.theglobeformacion.com Página 37 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI 9. Herramientas para pruebas del software NOMBRE OBSERVACIONES JUnit Pruebas unitarias para Java Mockito Pruebas unitarias para Java, basado en mock1 PHPUnit Pruebas unitarias para PHP CPPUnit Pruebas unitarias para C++ NUnit Pruebas unitarias para.NET xUnit Pruebas dirigidas por el desarrollo para.NET TestNG Pruebas unitarias para Java, basado en JUnit y NUnit PyUnit Pruebas unitarias para Python QUnit Pruebas unitarias para JavaScript Selenium Entorno de pruebas para web app Cypress Entorno de pruebas para web app JMeter Pruebas de rendimiento para Java Entorno de pruebas para web app que captura la Badboy navegación del usuario. Usado con JMeter. SoapUI Pruebas para WS en Java Postman Pruebas para WS tipo RESTful ATF (Automated Testing Framework) Framework de pruebas Unit.js Framework de pruebas para JS Framework de pruebas JS usado en TypeScript, Jest Node.js, React, Angular, Vue… Jasmine Framework de pruebas JS Framework de pruebas JS para Node.js. Ofrece Mocha pruebas asincrónicas Soporte a BDD (desarrollo guiado por el Cucumber comportamiento) Appium Pruebas en apps móviles 1 Objetos simulados que imitan el comportamiento de objetos reales de forma controlada. Se usan para probar otros objetos en pruebas unitarias. PABLO ARELLANO www.theglobeformacion.com Página 38 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI UFT (Unified Functional Testing) Pruebas funcionales y de regresión Herramienta para la gestión de pruebas basado en TestLink web FitNesse Pruebas de aceptación EasyAccept Pruebas de aceptación FIT (Framework for integrated test) Pruebas de aceptación Robotium Framework de pruebas para apps Android 10. ISO/IEC 29119 Pruebas del software Estándar internacional para pruebas de software. Se organiza en 4 partes: (1) Conceptos y definiciones, (2) Procesos, (3) Documentación y (4) Técnicas. PABLO ARELLANO www.theglobeformacion.com Página 39 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI 7. PROGRAMAS PARA CONTROL DE VERSIONES El control de versiones hace referencia a la gestión de los cambios realizados en un archivo o conjunto de archivos a lo largo del tiempo, es decir, en los elementos de un proyecto, de modo que se puede trabajar, revisar y recuperar las distintas versiones de dicho proyecto. Un Sistema de Control de Versiones (SCV o VCS2) es una aplicación que permite gestionar los cambios que se realizan sobre los elementos de un proyecto o repositorio, guardando así las diferentes versiones del mismo en todas sus fases de desarrollo. 1. Características de los SCV Resaltamos las siguientes características de los SCV: - Registra cada cambio en el proyecto o repositorio, quién y cuándo lo hace, en una base de datos. - Permite volver a estados previos del desarrollo. - Permite gestionar diferentes versiones del proyecto (ramas) para trabajar en paralelo y luego fundirlas. - Posibilita la colaboración entre diferentes usuarios en un mismo repositorio, facilitando la resolución de conflictos. - Se utiliza principalmente en proyectos de desarrollo de software, pero sirve para cualquier otro tipo de proyecto. 2. Terminología básica Para el manejo de este tipo de sistemas conviene aclarar previamente el vocabulario concreto que utilizan: - Repositorio (repository): es el lugar en el que se almacenan los datos actualizados e históricos de cambios. - Revisión (revision): es una versión determinada de la información que se gestiona. Hay sistemas que identifican las revisiones con un contador. Hay otros sistemas que identifican las revisiones mediante un código de detección de modificaciones. - Etiquetar (tag): permiten identificar de forma fácil revisiones importantes en el proyecto. Por ejemplo, se suelen usar tags para identificar el contenido de las versiones publicadas del proyecto. 2 Version Control System PABLO ARELLANO www.theglobeformacion.com Página 40 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI - Rama (branch): un conjunto de archivos puede ser ramificado o bifurcado en un punto en el tiempo de manera que, a partir de ese momento, dos copias de esos archivos evolucionan de forma independiente. - Cambio (change): un cambio (o diff, o delta) representa una modificación específica de un documento bajo el control de versiones. La granularidad de la modificación que es considerada como un cambio varía entre los sistemas de control de versiones. - Desplegar (checkout): es crear una copia de trabajo local desde el repositorio. Un usuario puede especificar una revisión en concreto u obtener la última. El término checkout también se puede utilizar para describir la copia de trabajo. - Confirmar (commit): es escribir o mezclar los cambios realizados en el repositorio. Los términos commit y checkin también se pueden utilizar como sustantivos para describir la nueva revisión que se crea como resultado de confirmar. - Conflicto (conflict): se produce cuando diferentes usuarios realizan cambios en el mismo documento y el sistema es incapaz de conciliar los cambios. Un usuario debe resolver el conflicto mediante la integración de los cambios, o mediante la selección de un cambio en favor del otro. - Cabeza (head): también a veces se llama tip (punta) y se refiere a la última confirmación, ya sea en el tronco (trunk) o en una rama (branch). El tronco y cada rama tienen su propia cabeza, aunque HEAD se utiliza para referirse al tronco. - Tronco (trunk): La única línea de desarrollo que no es una rama (a veces también llamada línea base, línea principal o máster). - Fusionar, integrar, mezclar (merge): una fusión o integración es una operación en la que se aplican dos tipos de cambios en un archivo o conjunto de archivos. Algunos escenarios de ejemplo son los siguientes: o Un usuario, trabajando en un conjunto de archivos, actualiza o sincroniza su copia de trabajo con los cambios realizados y confirmados, por otros usuarios, en el repositorio. o Un usuario intenta confirmar archivos que han sido actualizado por otros usuarios desde el último despliegue (checkout) y el software de control de versiones integra automáticamente los archivos. o Un conjunto de archivos se bifurca, un problema que existía antes de la ramificación se trabaja en una nueva rama, y la solución se combina luego en la otra rama. o Se crea una rama, el código de los archivos es independiente editado, y la rama actualizada se incorpora más tarde en un único tronco unificado. PABLO ARELLANO www.theglobeformacion.com Página 41 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI 3. Tipos de arquitectura Los SCV se clasifican en función de la arquitectura, tenemos: - Arquitectura LOCAL: los cambios son guardados y usados en un equipo local, sin posibilidad de compartición o colaboración. Consiste básicamente en copiar los archivos a otro directorio (indicando, por ejemplo, la fecha y hora de los cambios). - Arquitectura CENTRALIZADA o cliente/servidor: tienen un único servidor que contiene todos los archivos versionados (repositorio) y varios clientes que descargan los archivos desde ese punto central. Este tipo de sistemas se denominan CVCS (Centralized VCS). Se detalla esta arquitectura mediante las figuras siguientes: De entre los productos que siguen esta arquitectura destacamos: SOFTWARE OBSERVACIONES CVS Código abierto Subversion (SVN) Código abierto Código propietario (Microsoft). Antes Azure DevOps Server conocido como Teams Foundation Server (TFS) ClearCase Código propietario (Rational Software) Perforce Código propietario - Arquitectura DISTRIBUIDA: cada cliente posee una réplica del repositorio. Los repositorios intercambian y fusionan revisiones entre sí. Este tipo de sistemas se denominan DVCS (Distributed VCS). Las imágenes siguientes nos muestran de forma gráfica esta arquitectura: PABLO ARELLANO www.theglobeformacion.com Página 42 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI Productos software que siguen esta arquitectura: SOFTWARE OBSERVACIONES Git Código abierto Mercurial Código abierto. Escrito en Python Bazaar Código abierto Monotone Código abierto. Escrito en C++ Darcs Código abierto. Escrito en Haskell Plastic SCM Código propietario (Codice Software) Por último y de manera no exhaustiva se establece una comparativa entre las arquitecturas centralizada y distribuida: Ventajas arquitectura CENTRALIZADA Ventajas arquitectura DISTRIBUIDA - Permite trabajar sin conexión. - La colaboración entre clientes no se interrumpe - Mayor control al tener un único repositorio por la caída del servidor ya que cada nodo central. posee una copia del repositorio que puede ser - Versiones identificadas por número de copiada. versión, en lugar de por etiquetas - Establecimiento de varios flujos de trabajo (arquitectura distribuida). gracias a la posibilidad de colaboración con diferentes repositorios pertenecientes a distintos grupos de trabajo PABLO ARELLANO www.theglobeformacion.com Página 43 B3T10 METODOLOGÍAS, PRUEBAS Y COLABORACIÓN TAI 8. ESTUDIO DE UN SCV: GIT Git es un sistema de control de versiones distribuido de código abierto ideado por Linus Torvalds (el padre del sistema operativo Linux) y actualmente es el sistema de control de versiones más extendido. A diferencia de otros SCV Git tiene una arquitectura distribuida, lo que significa que, en lugar de guardar todos los cambios de un proyecto en un único sitio, cada usuario contiene una copia del repositorio con el historial de cambios completo del proyecto. Esto aumenta significativamente su rendimiento. 1. Fundamentos de Git La principal diferencia entre Git y cualquier otro SCV es la forma en la que manejan sus datos. Conceptualmente, la mayoría de SCV (CVS, Subversion, Perforce, Bazaar, etc.) almacenan la información como una lista de cambios en los archivos, esto es, como un conjunto de archivos y las modificaciones hechas a cada uno de ellos a través del tiempo. Se ilustra en la siguiente figura: En cambio, Git no maneja ni almacena sus datos de esta forma. Git maneja sus datos como un conjunto de copias instantáneas de un sistema de archivos miniatura. Cada vez que el usuario confirma un cambio, o guarda el estado de su proyecto en Git, básicamente toma una foto del aspecto de todos los archivos en ese momento y guarda una referencia a esa copia instantánea. Para ser eficiente, si los archivos no se han modificado Git no almacena el archivo de nuevo, sino un enlace al archivo anterior idéntico que ya tiene almacenado. Git maneja sus datos como una secuencia de copias instantáneas, tal como se muestra en la im

Metodologías, Pruebas y Colaboración en Desarrollo de Software (2015-2016) - PDF

Document Details

Tags

Related

Summary

Full Transcript

Upgrade to continue