-
Notifications
You must be signed in to change notification settings - Fork 0
calidad
- Introducción
- Configuración del servidor
- Configuración del cliente
- Análisis de la calidad de producto
- Análisis de la calidad de proceso
La aplicación Android desarrollada como proyecto integrado de las asignaturas de la mención de Ingeniería del Software ha de satisfacer unos umbrales de calidad mínimos. Por lo tanto, dentro de las tareas a realizar habrá que analizar la calidad de producto y llevar a cabo las correcciones necesarias para que cumpla los criterios establecidos.
Como herramienta utilizaremos SonarQube, que realiza análisis estático del código fuente detectando aspectos como código clonado, concordancia con estándares de programación, búsqueda de bugs o cobertura de pruebas. A cada uno de estos aspectos detectados, le asigna un valor de tiempo llamado "esfuerzo (effort)", que podríamos definir como el coste y los intereses a pagar por hacer las cosas funcionales pero con poca calidad (el sobre esfuerzo a pagar por mantener un software mal hecho). Hay que tener en cuenta que sólo una parte de este esfuerzo es intrínseca al código y podemos medirla mediante analizadores, y que también puede venir asociada a aspectos relacionados con el proceso, arquitectura, diseño, tecnologías, etc.
Dispondremos de un servidor donde se alojan los resultados de los análisis de calidad de los proyectos. Este servidor corresponde a la organización isuc de SonarCloud y en él están configurados los umbrales de calidad y el conjunto de reglas a usar en nuestros proyectos Android. Por otro lado, en el cliente podremos lanzar el análisis de SonarQube mediante línea de comandos o de forma automatizada dentro del proceso de integración contínua. Además, dispondremos del complemento SonarLint para Android Studio que permitirá enlazar con la configuración de nuestro servidor y así gestionar las incidencias de forma local desde nuestro IDE.
La manera de proceder será por sprint, de modo que para cada uno se designará una pareja de responsables de calidad. Dichos responsables deberán observar los análisis que aparecen en SonarCloud tras cada integración en la rama develop y observar si se cumplen o no los criterios de calidad exigidos. Si hay demasiadas integraciones en develop se podrá realizar un análisis de calidad cada 2 o 3 días.
Por cada análisis observado (cada integración), deberán analizar los datos y definir un plan de acciones que deberán realizar los desarrolladores para mejorar la calidad del código. Si el análisis indicaba que no se cumplen los criterios de calidad, el plan deberán incluir las acciones necesarias para pasarlo. Y en caso de que directamente se cumplan los criterios, el plan deberá incluir acciones preventivas para corregir los errores más importantes.
En el proyecto integrado se utilizará el servicio en la nube de SonarQube, llamado SonarCloud. Dentro de SonarCloud se ha creado una organicación isuc en la que se alojarán resultados de los análisis de calidad.
El servidor ya está configurado y no requiere de ninguna acción por parte de los alumnos para su puesta a punto.
El proyecto suministrado ya está configurado para utilizar Sonarqube como herramienta de análisis de calidad del producto, y SonarCloud como lugar en el que almacenar los resultados.
El análisis se lanza automáticamente en cada integración en las ramas
develop y main, mediante la configuración de Github Actions ya
establecida. El análisis también puede lanzarse de manera local mediante
el siguiente comando, que debe ser lanzado desde el directorio raíz del
proyecto Android:
./gradlew clean jacocoTestReport sonarqube
A continuación se muestra un extracto de la configuración suministrada
para integrar SonarQube y SonarCloud.
Tal y como puede observarse en el fichero de configuración
gradle.build, se hace uso del complemento oficial de SonarQube para
gradle y de una serie
de propiedades que establecen datos como la url del servidor, la
organización, en nombre y clave del proyecto y un token de autorización.
Asimismo se integra la librería Jacoco (Java Code Coverage), para capturar los resultados de la cobertura de los tests, e integrarlos dentro del análisis de SonarQube.
build.gradle (module)
plugins {
id 'com.android.application'
id "org.sonarqube" version "4.0.0.2929"
id 'jacoco'
}
apply plugin: "jacoco"
jacoco {
toolVersion = '0.8.10'
}
tasks.withType(Test) {
jacoco.includeNoLocationClasses = true
jacoco.excludes = ['jdk.internal.*'] // needed to support roboelectric with jacoco
}
task jacocoTestReport(type: JacocoReport, dependsOn: ['testDebugUnitTest']) {
reports {
xml.required = true
html.required = true
}
def fileFilter = ['**/R.class', '**/R$*.class', '**/BuildConfig.*', '**/Manifest*.*', '**/*Test*.*', 'android/**/*.*']
def mainSrc = "$project.projectDir/src/main/java"
def javaTree = fileTree(dir: "$project.buildDir/intermediates/javac/debug/classes", excludes: fileFilter)
sourceDirectories.setFrom(files([mainSrc]))
classDirectories.setFrom(files([javaTree]))
executionData.setFrom(fileTree(dir: project.buildDir, includes: ['jacoco/testDebugUnitTest.exec', 'outputs/code-coverage/connected/*coverage.ec']))
}
// to launch sonar: ./gradlew clean jacocoTestReport sonarqube
sonar {
properties {
property "sonar.host.url", "https://sonarcloud.io"
property "sonar.organization", "isuc"
property "sonar.login", "120537998e2c122476f30cade8d4a25865210fa6"
property "sonar.projectKey", "Calculadora-Juan"
property "sonar.projectName", "Calculadora-Juan"
// I need this property to avoid the error where sonarqube does not close some files and
// prevents a clean afterwards
property "sonar.scm.disabled", true
// this property is deprecated, now I use the xml file defined below it
// property "sonar.jacoco.reportPaths", "${project.buildDir}/jacoco/testDebugUnitTest.exec"
property "sonar.coverage.jacoco.xmlReportPaths", "${project.buildDir}/reports/jacoco/jacocoTestReport/jacocoTestReport.xml"
}
}Existe un complemento que podemos instalar en Android Studio para analizar la calidad del código de manera local, mostrándonos las incidencias con su clasificación (tipo, severidad, etc.), descripción de la regla que la ha activado, etc. Es bastante útil ya que nos permite seleccionar una incidencia e ir directamente a la parte del código donde se encuentra. Otra ventaja importante es que además de poder trabajar con una configuración por defecto, permite conectarnos a un servidor (propio o SonarCloud) y usar las reglas y quality gate configuradas para tu organización.
Para instalarlo la forma más sencilla es desde Preferencias -> Plugins -> Browse Repositories -> SonarLint, y al finalizar, reiniciar Android Studio. Debería aparecernos la pestaña de SonarLint en la parte baja de la interfaz.
Para la conexión con el servidor habrá que ir a Preferences -> Other Settings ->
- SonarLint General Settings. Permitirá agregar el servidor SonarCloud
o propio, meter nuestra clave y seleccionar nuestra organización
(dichos valores aparecen en el fichero
gradle.build). - SonarLint Project Settings. Una vez realizado el paso anterior podremos seleccionar un proyecto en concreto.
Tras la configuración, podremos ejecutar análisis para un único fichero o el proyecto completo, mediante el menú contextual del proyecto (botón derecho) dentro de las opciones de SonarLint.
Durante el proyecto integrado se realizarán 3 Sprints en los que se desarrollarán varias historias de usuario. En cada Sprint se deberá realizar un informe de calidad.
El objetivo del informe de calidad es el de describir los problemas principales de calidad de producto que presenta la aplicación, y proporcionar un plan de acción con el fin de corregir las principales incidencias detectadas.
El informe de calidad debe realizarse en algún punto intermedio del Sprint, de forma que, en la medida de lo posible, se pueda aplicar el plan de acción establecido antes de finalizar el Sprint.
El formato del informe de calidad es libre, pero se espera que contenga la siguiente información:
- Fecha de realización
- Breve análisis del estado del producto, identificando los principales problemas de calidad detectados. La información de este análisis debe sustentarse con capturas de pantalla.
- Plan de acción en el que se detallen qué incidencias concretas se van a solventar antes de finalizar el Sprint. El plan de acción tiene que estar debidamente priorizado y justificado, teniendo en cuenta tanto la importancia de las incidencias seleccionadas, como el tiempo disponible para solventarlas. Para ello se recomienda apoyarse en la información suministrada por el Burndown Chart en el momento de realizar el informe.
- Lista de tareas añadidas al sprint de acuerdo al plan de acción.
Se valorará la brevedad y concisión en el informe. Incluir información como capturas de pantalla que no sean relevantes o necesarias se valorará negativamente.
Los informes de calidad deberán guardarse en el repositorio Github del grupo, en el directorio y con el nombre de fichero determinados por la gestion de la configuracion. Adicionalmente, los informes de calidad se deberán subir a una tarea en el Moodle de la asignatura Calidad y auditoría creada para tal efecto. En dicha tarea de Moodle se proveerán tanto la calificación obtenida por el informe, como los comentarios de retroalimentación.
El informe formará parte de la evaluación de la asignatura Calidad y Auditoría, correspondiendo al elemento evaluable Informes de Calidad.
La forma en la que se ha realizado el producto (el proceso) representa otra dimensión de la calidad del software que debe ser analizada. La calidad de proceso está relacionada con la forma en la que se ha realizado, incluyendo especialmente aspectos metodológicos como la realización de diagramas, aplicación de técnicas, metodología de desarrollo, etc.
Existe cierta controversia en cuanto a si una buena calidad de proceso influye favorablemente en la obtención de una buena calidad de producto. Pensemos por ejemplo en la realización de un diagrama de clases (proceso) y si esto va a suponer que tengamos menos errores, vulnerabilidades, etc. en el código (producto interna). Existen defensores de ambas posiciones.
Dentro del proyecto integrado, se ha seguido una metodología concreta que abarca gestión de la configuración (ramas, integración continua, etc.), pruebas (plan, unitarias, integración. etc.), calidad de producto (proceso seguido, informes, etc.), documentación (diagramas, manuales, etc.), etc.
Una vez finalizados los sprints del proyecto integrado se procederá a un análisis de calidad del proceso seguido. Para ello distinguiremos dos etapas:
- Creación de una lista de comprobación. En esta fase, cada grupo deberá analizar la metodología seguida y pensar qué aspectos deberían comprobarse para saber si se ha aplicado correctamente el proceso solicitado. Con estos elementos confeccionará una lista de comprobación que servirá para auditar proyectos de este tipo.
- Auditorías cruzadas. Utilizando la lista de comprobación definida en la fase anterior, cada grupo realizará una auditoría del proceso seguido por otro grupo distinto.
La creación de las listas de comprobación, y la realización de las auditorías cruzadas, forman parte de la evaluación de la asignatura Calidad y Auditoría, correspondiendo a la parte de Calidad de Proceso.