Please enable JavaScript.

Coggle requires JavaScript to display documents.

TEMA 48 : ANÁLISIS DE REQUERIMIENTOS DE LOS S.I. . ASEGURAMIENTO DE LA…

- - - - A nivel de software :hacen referencia a qué debe y qué no debe hacer el software a desarrollar
        
        Funcionales :especifican el funcionamiento del software a construir
        
        No Funcionales :especifican aspectos adicionales (accesibilidad, seguridad, rendimiento, portabilidad..
      - A nivel de sistema :hacen referencia otros elementos del sistema, como las comunicaciones, hardware..
    - - Válidos :describen lo que el usuario realmente necesita
      - Completos :describen toda la información necesaria
      - No ambiguos :dejan claras las características del sistema que describen
      - Consistentes :no deben contradecirse
      - Comprensibles :deben ser fáciles de entender, tanto por los usuarios como por los desarrolladores
      - Rastreables :permite identificar de dónde procede el requisito y a qué elementos del sistema afecta
      - Verificables :deben poder ser verificado cuando el sistema esté construido, para probar que cumple las necesidades del usuario
  - - - Desarrollador :es quien construye y pone en marcha el sistema . (analista, programador, técnico de pruebas, jefe de proyecto...)
      - Cliente :es quien paga la construcción del sistema
      - Usuario :pertenece a la organización del cliente y tiene un conocimiento avanzado sobre una o varias áreas que abarca el proyecto
    - - Educción de Requisitos (ASI 2.1 Obtención de Requisitos): loas analistas obtienen las necesidades del cliente a partir de todas las fuentes de información que tienen disponibles
      - Análisis y negociación (ASI 2.3 Análisis de Requisitos) :se confecciona una lista de requisitos que defina las necesidades del cliente. Se estudian en busca de conflictos e incoherencias, información no obtenida y aspectos no resueltos. Se clasifican y se evalúa la viabilidad y se integran posibles nuevos requisitos y se desechan los no factibles previa negociación
      - Documentación de requisitos (ASI 2.2 Especificación de Casos de Uso) :se obtiene un modelo de análisis, mediante lenguaje formal, lenguaje natural, representaciones gráficas (DFD, Modelo E/R, Casos de Uso o Diagramas de Clases) y donde queda descrito con exactitud todo lo que el sistema debe hacer, y que debe ser revisada y aprobada por los diversos participantes en el desarrollo
      - Validación (ASI 2.4 Validación de requisitos) :se definen una serie de criterios y técnicas que permitirán comprobar que la especificación cumple los requisitos.
  - - - Es necesario para el proyecto que cada requisito se pueda identificar de forma única
        
        Código único
        
        Nombre descriptivo
        
        Descripción
        
        Fecha de creación
        
        Número de versión
        
        Autor
        
        Prioridad
        
        Obligatorio/Opcional
        
        Estado
        
        Estabilidad
        
        Subsistema / funcionalidad
        
        Beneficio, penalización , coste y riesgo
      - Proceso de obtención de requisitos
        
        Identificar las fuentes
        
        Preguntar las cuestiones apropiadas
        
        Analizar la información obtenida
        
        Confirmar la comprensión
        
        Sintetizar y documentar
      - Tácnicas
        
        Entrevista :encuentro "cara a cara" entre usuario y analista, basada en conversación con preguntas y respuestas
        
        Sesión JAD (Joint Application Design):promueve la cooperación entre los usuarios y los desarrolladores. Suele hacerse en pocas sesiones pero de larga duracón
        
        Brainstorming :para la generación de un grupo de ideas en los casos en los que su aparición no es obvia. Genera múltiples puntos de vista de un problema.
        
        Prototipos :productos software que solo implementan una parte del sistema, y se emplean para obtener requisitos del usuario cuando estos no están completamente claros mediante la interacción del usuario con el prototipo
        
        Factores críticos de éxito :se identifica un pequeño conjunto de factores de los que depende el éxito del sistema, y se centra en ellos el análisis usando cualquiera de las demás técnicas. Para sistemas complejos
        
        Pieces :define 6 categorías de aspectos que el analista debe estudiar con los usuarios :
        
        Rendimiento
        
        Información y Datos
        
        Economía
        
        Control
        
        Eficiencia
        
        Servicios
        
        Escenarios y casos de uso :los escenarios son ejemplos de las sesiones de interacción, comenzando con un esbozo y agregando detalles para crear una descripción completa. Los casos de uso se basan en escenarios para la obtención de requisitos, identificando el tipo de interacción y los actores involucrados.
        
        Etnografía :técnica de observación que se puede utilizar para entender los requisitos sociales y organizacionales. El analista observa el entorno laboral de trabajo diario donde se utlizará el isistema y anota las tareas reales en las que los participantes están involucrados
    - - Una vez identificados y reunidos los requisitos, se necesita evaluar o analizar los mismos a fin de determinar si son adecuados para el cliente o usuario.
      - Si son completos, correctos, no ambiguos y tienen un nivel aceptable de riesgo técnico y económico
      - Puede verse como la definición de todas las posibles soluciones software a un problema, que cumplen todas las necesidades y restricciones
      - Se eliminarán conflictos y se clasificarán los requisitos atendiendo a diversos criterios (prioridades, funcionales, no funcionales..)
      - Un sistema puede ser modelizado atendiendo a 3 perspectivas :
        
        Estática :(orientado a datos y orientado a objetos), estructura estática de los objetos y sus relaciones
        
        Dinámica (orientado a estados) : aspectos que cambian con el tiempo y representan los distintos estados que puede tener el sistema, así como sus condiciones y eventos
        
        Funcional (orientado a procesos) :describe como se transforman los datos en el contexto del problema
    - - EL documento ERS (Especificación de Requisitos del Software) es la declaración formal que debe definir de forma clara, precisa, completa y verificable todas las funcionalidades y restricciones del sistema que se desea construir
        
        Requisitos de comportamiento del sistema (funcionales)
        
        Requisitos del sistema que no son de comportamiento (no funcionales)
        
        Requisitos de relación externa del sistema (interfaces, comunicaciones, hardware y usuarios..)
      - Estándar : IEEE/ANSI 830-1998: define estructura para constrirlo
    - - Es la comprobación de que los requisitos definen el sistema que desea el usuario.
      - Técnicas
        
        Revisiones formales :se analizan por un grupo de revisores, formado por desarrolladores y usuarios, buscando omisiones y errores.
        
        Construcción de prototipos :se construye un prototipo del sistema en base a los requerimientos y se le entrega al cliente para que pueda experimentar con él y pueda determinar si es lo que necesita.
        
        Generación de casos de prueba :
  - - - Se realiza durante toda la vida del proyecto, cuando aparecen nuevas necesidades que generan nuevos requisitos.
      - Es muy importante la trazabilidad, es decir, la capacidad para poder relacionar los requisitos entre sí, y poder analizar el impacto de un cambios
      - Es necesario definir en la organización un Procedimiento de Gestión de Requisitos para garantizar que son actualizados de forma coherente y consistente y que se sigue un control de dicha actividad
    - - Control de cambios :todas las actividades desde la petición formal hasta la puesta en marcha o decisión de rechazo/aplazamiento
      - Control de versiones :es necesario definir lo que se denomina una linea base, que constituye el marco de referencia estable para el desarrollo del producto, conteniendo un conjunto de requisitos completo, coherente y correcto, es decir, las últimas versiones aprobadas de los requisitos (Subversion, usado por la GVA)
      - Trazabilidad :indica cómo se llega a un requisito a partir de otros, mediante la relación entre ellos
  - - - Un usuario realiza una petición solicitando que le sea resuelta una necesidad
      - Del estudio de la petición se obtienen los documentos TOMREQ (obligatorio), IMPAEV y ANCOBE (opcionales)
      - Los documentos VAREQ2 y VACOBE validan el TOMREQ y ANCOBE, respectivamente
      - El catálogo de requisitos CATREQ se construye de forma incremental a partir de cada TOMREQ
  - - - Si su modo de funcionamiento se adapta a la organización
      - Que su alto coste generalmente sólo se justifica para proyectos muy grandes
    - - Gestión de toda la información asociada a los requisitos
      - Gestión de versiones y cambios
      - Facilitar el análisis de impactos
      - Seguimiento del estado de requisitos
      - Asociar requisitos con personas afectadas
- - - - Ingeniería del software (IEEE) :aplicación de un enfoque sistemático, disciplinado y cuantificable hacia el desarrollo, operación y mantenimiento del software
        
        Objetivos
        
        Conseguir un producto software fiable, de alta calidad y bajo coste
        
        Conducir un proceso de desarrollo y mantenimiento software de manera eficiente y con éxito, mediante el uso de metodologías y herramientas
      - Software :conjunto de procedimientos, normas y reglas, documentación y programas de ordenador, cuyo funcionamiento conjunto y armonizado permite satisfacer las necesidades del usuario
        
        Características
        
        Es un producto abstracto
        
        Se desarrolla, no se fabrica
        
        No se deteriora con el tiempo
        
        El software con errores no se rechaza
      - Calidad del software :aspectos o características que se refieren a su capacidad de satisfacer los requisitos
        
        Hay una valoración cuantitativa, es medible la calidad, por lo que hay que determinar
        
        Los factores y criterios que intervienen en la calidad del software
        
        Los valores de referencia de las métricas y los métodos objetivos para cuantificarlas
    - - El centrado exclusivamente en garantizar la calidad del producto final que se va a entregar al cliente. Control de calidad
      - El que se centra en garantizar la calidad del proceso mediante el cual se desarrolla y mantiene el producto final. Garantía de calidad
      - El enfoque de calidad total, centrado en buscar la máxima satisfacción del cliente en todos los aspectos en los que se relaciona con la empresa y organización y en el logro de la excelencia empresarial
    - - Definición :aspecto de la función de gestión que determina y aplica la política de calidad, los objetivos y las responsabilidades y que lo realiza con medios tales como la planificación de la calidad, el control de la calidad, la garantía de la calidad y la mejora de la calidad
        
        Debe evitar que se generen errores
        
        Detectar los errores y corregirlos
        
        Rediseño de procesos para evitar que no se produzcan errores de nuevo
      - Sistema de gestión de la calidad :conjunto de la estructura de la organización, de responsabilidades, procedimientos, procesos y recursos que se establecen para llevar a término la gestión de calidad
      - Es responsabilidad de todos los niveles ejecutivos, guiada por la alta dirección. Involucra a todos los miembros de la organización y se tienen en cuenta también criterios de rentabilidad.
      - Es la alta dirección quien debe expresar la política de calidad, planificarla estratégicamente, asignar recursos y elegir los planes y evaluaciones sistemáticos
  - - - Los modelos o estándares agrupan normas o directrices de como se deben implementar las acciones de la gestión de la calidad del proceso y producto software
      - En los modelos de calidad, la calidad se define de forma jerárquica y tiene los siguientes elementos comunes
        
        En el nivel más alto de la jerarquía se encuentran los factores de calidad o atributos de calidad externos, que representan la calidad desde el punto de vista del usuario
        
        Cada uno de los factores se descompone en un conjunto de criterios de calidad o atributos de calidad internos, que representan la calidad desde el punto de vista del producto o del proceso
        
        Para cada atributo de calidad se definen un conjunto de métricas, que son medidas cuantitativas de ciertas características del producto o proceso que cuando están presentes, indican el grado que posee un determinado atributo de calidad
      - Ventajas de los modelos de calidad :la calidad se convierte en algo concreto que se puede definir, medir y planificar
      - Tipos de factores : los que se pueden medir directamente (nº de defectos) y los que se pueden medir solo indirectamente (facilidad de uso, de mantenimiento...)
      - Tipos de modelos
        
        Orientados a la calidad del producto :
        
        Orientados a la calidad de los procesos
    - - Es uno de los más antiguos (1977) y extendidos y ha sido tomado como referencia para otros modelos de medida de calidad del siftware
      - Se descompone en 11 factores de calidad de alto nivel, que representan la calidad desde el punto de vista del usuario.
      - Son descompuestos en 23 criterios de calidad, que son asociados a 41 atributos directamente medibles mediante métricas de calidad
      - Factores de calidad :son elementos externos y hacen referencia al comportamiento del software (operación del producto) , a la facilidad de cambio del software (revisión del producto) y a la facilidad de conversión del software (transición del producto)
        
        Características operacionales
        
        Corrección
        
        Fiabilidad
        
        Eficiencia
        
        Usabilidad
        
        Integridad
        
        Características de modificación o revisión
        
        Facilidad de mantenimiento
        
        Flexibilidad
        
        Facilidad de prueba
        
        Características de transición
        
        Portabilidad
        
        Reusabilidad
        
        Interoperabilidad
      - Criterios de calidad :descomposición de los factores de calidad en un conjunto de criterios o atributos internos de calidad que, cuando están presentes, contribuyen al aspecto de la calidad que el factor de calidad representa. Es una visión desde el punto de vista del producto software
      - Métricas de calidad del software :se aplican durante todo el ciclo de vida del software y se basan en el examen detallado de todos los productos generados
        
        Indicadores (ejemplos para la fiabilidad)
        
        Nº de errores en el programa/ nº de líneas de código
        
        Nº de errores aparecidos /meses de uso
        
        Porcentaje de usuarios con problemas
    - - La familia de normas ISO 9000 proporciona un conjunto de estándares para la Gestión de la Calidad en cualquier actividad relacionada con el proceso de producción
      - Las principales normas ISO relacionadas con la calidad del software son
        
        Norma ISO/IEC 25000 (SQuaRE) (Software product Quality Requirements and Evaluation)
        
        Su objetivo principal es guiar el desarrollo de los productos software mediante la especificación de requisitos y evaluación de características de calidad (orientada a producto)
        
        Define 6 características de calidad (factores de calidad)
        
        Funcionalidad
        
        Fiabilidad
        
        Usabilidad
        
        Eficiencia
        
        Mantenibilidad
        
        Portabilidad
        
        27 subcaracterísticas de calidad: cada una está dividida en atributos que pueden ser verificados y medidos
        
        Norma ISO 9000-3
        
        Es una guía para la implementación de la norma ISO 9001 en organizaciones que desarrollan y/o comercializan software (para certificar y enfocada a la calidad)
        
        Ideas básicas
        
        Debe existir una estricta colaboración entre la organización que adquiere el software y el proveedor del mismo
        
        El proveedor de software debe definir sus sistema de calidad y asegurarse que toda la organización ponga en práctica este sistema
        
        El control de calidad debe ser aplicable a todas las fases de la producción del software, incluido el mantenimiento y tareas posteriores a su implantación
    - - Es un modelo de Gestión de Calidad que gira alrededor del concepto de madurez de una organización en 5 niveles
      - Desarrollado por el SEI (Software Engineering Institute), ayuda a las organizaciones a producir de manera consistente y predecible productos de calidad superior, mediante la evaluación de los procesos de una organización, describiendoa los principios y prácticas asociadas necesarias pare definir el grado de madurez de las prácticas de gestión de dichos procesos.
      - Caracteristicas CMM
        
        Descriptivo :describe los atributos esenciales que caracterizan cada nivel de madurez
        
        Normativo :las prácticas descritas son las que se espera de una organización que desee alcanzar un determinado nivel
        
        No prescriptivo :dice a la organización qué se debe hacer para mejorar pero no como hacerlo
      - Composición de CMM
        
        5 niveles de madurez :el nivel representa la capacidad del proceso analizado. Se definen unos objetivos para los procesos, que cuando son satisfechos permiten evolucionar al siguiente nivel
        
        Áreas clave del proceso :en cada nivel, se definen un conjunto de éstas áreas que describen las funciones que deben llevarse a cabo para el desarrollo de una buena práctica. Mediante métricas se determina la calidad de cada una de las áreas clave
        
        Características comunes :5 secciones en que se organiza cada una de las áreas clave
        
        Compromiso: asegurar que el proceso es repetible y duradero
        
        Capacidad: precondiciones del proyecto u organización
        
        Actividades: roles y procedimientos
        
        Medidas y análisis: necesidad de hacer mediciones y analizarlas
        
        Verificación: asegurar que las actividades se realizan según los procesos establecidod
        
        Prácticas clave :se especifican en cada característica común y son normas, procedimientos y actividades que llevan a la consecución de los objetivos del área
        
        Indicadores clave :prácticas clave o componentes de prácticas clave que ofrecen una visión mayor de la consecución de los objetivos de un área clave de proceso
      - Niveles de madurez de CMM
        
        1. Inicial :el proceso de software es un proceso improvisado y caótico , por el continuo cambio o modificación a medida que avanza el trabajo
        
        2. Repetible:se establecen políticas y procedimientos de administración e implantación del proceso básico para determinar costos, calendarios y funcionalidades
        
        Áreas clave : gestión de requisitos, planificación del proyecto y seguimiento y control del proyecto, gestión de configuración, gestión de proveedores, aseguramiento de la calidad
        
        3. Definido: el proceso de software está documentado, homogeneizado e integrado en un proceso de software estándar dentro de la organización
        
        Áreas clave : desarrollo y mejora de los procesos de la organización, definición de los procesos de la organización, programa de formación, gestión integrada del software, ingeniería de producto software, coordinación intergrupos, revisión conjunta
        
        4. Gestionado: se obtienen y controlan medidas cuantitativas del proceso de software y de la calidad del producto. Se pueden predecir las tendencias en la calidad del producto
        
        Áreas clave : gestión cuantitativa del proyecto, gestión de calidad del software
        
        5. Optimizado :la mejora continua del proceso es garantizado por la retroalimentación cuantitativa y desde las pruebas de técnicas y herramientas innovadoras. Su actividad clave es el análisis de las causas de defectos y su prevención
        
        Áreas clave : prevención de defectos, gestión de cambios tecnológicos, gestión de cambios en los procesos
      - CMMI
        
        Surgió para desarrollar un marco de trabajo para organizaciones que persiguen la mejora en todos los niveles y ámbitos de la empresa.
        
        Se basa en la aplicación de todos los principios de CMM a lo largo de todo el ciclo de vida de ingeniería, no únicamente al ciclo de vida del desarrollo del producto software. Diseñado para mantener compatibilidad y correspondencia con SPICE
        
        Diferencias con CMM
        
        Cambio de nomenclatura de los 5 niveles de madurez
        
        No gestionado
        
        Gestionado
        
        Definido
        
        Administrado cuantitativamente
        
        Optimizado
        
        Creación y reorganización de áreas clave
        
        Definición de mejores y más modernas prácticas clave
        
        Existencia de un objetivo genérico para cada área
    - - Es un marco para métodos de evaluación y mejora de los procesos de desarrollo y mantenimiento de sistemas de información y productos software
      - Enfocado a la Gestión de Calidad como CMM-CMMI, pero no es un método o modelo en sí mismo
      - Desarrolla un conjunto de medidas de capacidad estructuradas para todos los procesos del ciclo de vida y para todos los participantes
      - Estructura basada en 2 dimensiones
        
        Proceso:son los procesos a evaluar, agrupados en 5 categorías
        
        CUS : cliente-suministrador
        
        ENG ; ingeniería
        
        SUP : soporte
        
        MAN : gestión
        
        ORG : organización
        
        Capacidad de proceso: define una escala de medida para determinar la capacidad de cualquier proceso
        
        N (No alcanzado)
        
        P (Parcialmente alcanzado)
        
        L (Ampliamanete alcanzado)
        
        F (Totalmente alcanzado)
      - Niveles de capacidad
        
        0. Incompleto : la organización no tiene una implementación efectiva de los procesos
        
        1. Realizado : la organización implementa y alcanza los objetivos de los procesos
        
        2. Gestionado : la organización gestiona los procesos y productos resultantes se establecen, controlan y mantienen
        
        3. Establecido :la organización utiliza procesos definidos basados en estándares
        
        4. Predecible : la organización gestiona cuantitativamente los procesos
        
        5. Optimizado ; la organización mejora continuamente los procesos para cumplir los objetivos de negocio
  - - - Análisis estáticos :analizan el objeto sin necesidad de ejecutarlo
        
        Auditorías: investigación para determinar el grado de cumplimiento
        
        Revisiones :reunión formal en la que se presenta el estado actual de los resultados de un proyecto a los usuarios, y se realiza un análisis estructurado de los mismos
        
        Verificación formal:demostración matemática la corrección de un programa con respecto a sus especificaciones. So,o se usa en sistemas críticos, por su coste
      - Pruebas dinámicas :requieren la simulación o ejecución del objeto que está siendo probado o de un modelo del mismo
        
        Prueba unitaria :de cada módulo aislado del resto del sistema
        
        Prueba de integración :comprueba que las interfaces entre los módulos son correctas
        
        Prueba del sistema:comprueba que el sistema satisface todos los requisitos
        
        Prueba de aceptación :una vez implantado, su objetivo es demostrar al usuario que el sistema satisface sus necesidades
        
        Prueba de regresión : comprueba que toda nueva versión de un producto software es de no menos calidad que la versión anterior
  - - - Dentro de la gestión de calidad hay que elaborar un Plan de Métricas para que nos permitan cuantificar lo cerca o lo lejos que está el producto o proceso respecto de los atributos de calidad que se desea alcanzar
      - Tipos de atributos a medir
        
        Procesos : las métricas de proceso cuantifican atributos del conjunto de actividades establecidas para el desarrollo del software (tareas, hitos, etc)
        
        Productos :las métricas de producto son medidas del resultado de los procesos , del producto software (programas , documentación y otras entregas)
        
        Recursos :las métricas de los recursos son medidas del conjunto de elementos (personal, herramientas y métodos) que son necesarios para la producción del software
      - Técnicas utilizadas para la implantación del Plan de Métricas
        
        Selección de métricas: basándonos en los objetivos de mejora que perseguimos.
        
        De tamaño/volumen
        
        De organización /gestión del proyecto
        
        De productividad y plazo de entrega
        
        De productividad y tiempos de respuesta en mantenimiento
        
        De defectos
        
        De pruebas
        
        De código
        
        Divulgación de las métricas:explicando las razones y objetivos que deben cumplir
        
        Establecimiento de objetivos, medición y publicación :
    - - Propiedades de las métricas adecuadas
        
        Simplicidad
        
        Objetividad
        
        Facilidad de recolección
        
        Robustez
        
        Validez
      - Métodos de selección de métricas
        
        GQM (Goal Question Metric) :el más ampliamente aplicado y conocido
        
        Es necesario considerar 3 componentes
        
        Un proceso donde pudieran articularse metas y objetivos para sus proyectos
        
        Un proceso donde estas metas pudieran ser traducidas a datos del proyecto que reflejasen dichas metas u objetivos en términos de software
        
        Un proceso que interpretara los datos del proyecto con el fin de entender los objetivos
        
        Proporciona una serie de plantillas útiles para los desarrolladores. Los objetivos de GQM pueden articularse por medio de 3 plantillas
        
        Propósito :se utiliza para definir lo que está siendo estudiado
        
        Perspectiva :se usa para analizar qué factores son importantes dentro del proceso o producto
        
        Entorno :se usa para analizar al personal, la organización y los recursos en los que se desarrolla el proyecto
        
        SEI (Software Engineering Institute) :
        
        Identificar los objetivos de negocio
        
        Identificar lo que se desea saber o aprender
        
        Identificar los subobjetivos
        
        Identificar las entidades y atributos relativos a los objetivos
        
        Formalizar los objetivos de la medición
        
        Identificar preguntas que puedan cuantificarse y los indicadores relacionados
        
        Identificar elementos de datos que se van a recoger
        
        Definir las medidas a usar
        
        Identificar las acciones que serán tomadas para mejorar las medidas
        
        Preparar un plan para implementar estas medidas
    - - Métricas de proceso
        
        Orientadas al tamaño : COCOMO y COCOMO II
        
        Orientaqdas a la funcionalidad : Puntos función (Albrecht) y Mark II (Symmons)
      - Métricas de producto
        
        Métricas de complejidad : Técnica de Halstead, técnica de McCabe
        
        Métricas de fiabilidad
    - - Métricas de proceso
        
        Casos de uso, número de clases clave, número de subsistemas
      - Métricas de producto
        
        Serie métricas CK
        
        Métricas de Lorenz y Kidd
        
        Métricas MDOO
  - - - El coste de diseñar una organización de calidad adecuada en la que queden definidos los procedimientos de calidad a utilizar y las funciones de cada responsable
      - Costes de formación específica en los procedimientos de calidad
      - Costes de las metodologías y herramientas adecuadas
      - Incremento de los costes de desarrollo
    - - Asegurar la obtención de los objetivos del proyecto dentro de los plazos previstos y bajo los costes presupuestados
      - Obtención de una mejor solución técnica
      - Incremento de la productividad
      - Reducción de los tiempos, costes y esfuerzos en los mantenimientos
- - - - Arquitectura y diseño
      - Duplicidades
      - Pruebas unitarias
      - Complejidad ciclomática
      - Errores potenciales
      - Reglas de codificación
      - Comentarios
    - - Analizar el código fuente desde el IDE de desarrollo
      - Trasladar los resultados al servidor SONAR / SONARQUBE
  - - - Tamaño
      - Diseño
      - Duplicidad
      - Pruebas unitarias y cobertura
      - Complejidad ciclomática
      - Código innnecesario
      - Documentación
    - - Bloqueante :error muy grave que debe ser inmediatamente corregido
      - Crítica :error muy grave cuyo código debe ser revisado de inmediato
      - Mayor :defecto de calidad que puede tener un alto impacto en la productividad de los desarrolladores
      - Menor :defecto de calidad con un leve impacto en la productividad de los desarrolladores
      - INFO :hallazgo que no significa error ni defecto.
  - - - Una de las métricas de calidad que proporciona SONAR es la medida de la deuda técnica, mediante el indicador SQALE (Software Quality Assessment based on Lifecycle Expectations)
        
        9 características base
        
        Reusabilidad, portabilidad, mantenibilidad, seguridad, usabilidad, eficiencia, fiabilidad, capacidad de ser probado, cambiabilidad
        
        La clasificación SQALE va desde A hasta E, siendo A el valor más alto y positivo
        
        El nivel se obtiene calculando el Ratio de Deuda Técnica (relación entre la deuda técnica actual y el esfuerzo para reescribir todo el código desde el principio)
  - - - Se detectan defectos en fases muy tempranas
      - No se necesita que la aplicación está finalizada y en ejecución
      - Garantiza propiedades específicas del software
      - Legibilidad del código, que implica facilidad de comprensión
      - Facilidad para mantenerlo
      - Portabilidad
      - Reusabilidad
      - Capacidad para ser probado