calidad
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.
Se deberá realizar un informe de calidad de producto por cada uno de los sprints. Los integrantes del equipo encargados de este informe deberán consultar uno de los análisis que aparecen en SonarCloud al realizar una integración en la en la rama develop. Tras consultar esta información, se deberá definir un plan de acciones a realizar para mejorar la calidad del código. Si el análisis indicaba que no se cumplen los criterios de calidad, el plan deberá 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 encontrados más importantes. Podéis encontrar más detalles de cómo realizar este informe en el apartado de análisis de calidad del producto.
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 :app)
plugins {
id 'com.android.application'
id "org.sonarqube" version "5.1.0.4882"
id "jacoco"
}
apply plugin: "jacoco"
jacoco {
toolVersion = '0.8.12'
}
tasks.withType(Test) {
jacoco.includeNoLocationClasses = true
jacoco.excludes = ['jdk.internal.*'] // needed to support roboelectric with jacoco
}
task jacocoTestReport(type: JacocoReport, dependsOn: ['testDebugUnitTest', 'connectedAndroidTest']) {
reports {
xml.required = true
html.required = true
}
def fileFilter = ['**/R.class', '**/R$*.class', '**/BuildConfig.*', '**/Manifest*.*', '**/*Test*.*', 'android/**/*.*', 'hilt**', 'dagger']
def mainSrc = "$project.projectDir/src/main/java"
def javaTree = fileTree(dir: "$project.buildDir/intermediates/javac/debug/compileDebugJavaWithJavac/classes", excludes: fileFilter)
sourceDirectories.setFrom(files([mainSrc]))
classDirectories.setFrom(files([javaTree]))
executionData.setFrom(fileTree(dir: project.buildDir, includes: ['outputs/unit_test_code_coverage/debugUnitTest/testDebugUnitTest.exec', 'outputs/code_coverage/debugAndroidTest/connected/*/coverage.ec']))
}
sonar {
properties {
property "sonar.host.url", "https://sonarcloud.io"
property "sonar.organization", "isuc"
property "sonar.token", "120537998e2c122476f30cade8d4a25865210fa6"
property "sonar.projectKey", "App-Gasolineras-Grupo1"
property "sonar.projectName", "App-Gasolineras-Grupo1"
// 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, ${project.buildDir}/reports/coverage/androidTest/debug/connected/report.xml"
}
}
Para que en sonarcloud aparezca la información de la cobertura de pruebas de interfaz de usuario, asegurarse también de que en la sección BuildTypes aparece testCoverageEnabled true:
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}
debug {
testCoverageEnabled true
}
}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. Concretamente, el informe de calidad debería realizarse hacia el final de la primera semana de un Sprint, siendo necesario haber realizado anteriormente alguna integración en la rama develop durante ese Sprint (recordad que esto es lo que genera que aparezca un análisis en SonarCloud, y sin dicho análisis no se puede realizar el informe).
El formato del informe de calidad es libre. En cuanto al contenido, deben aparecer las siguientes partes:
-
Metadatos del informe:
- Número de grupo y de Sprint.
- Fecha de realización.
- Debe ser claramente visible el hash del commit sobre el que Sonar ha realizado el análisis.
-
Capturas de SonarCloud y Scrumdesk: lo primero que debe leerse al consultar un informe de calidad son una serie de capturas de la información generada por SonarCloud y Scrumdesk, lo que permitiría de un vistazo hacerse una idea de la situación actual de la calidad del repositorio. Dichas capturas solamente deberían ir acompañadas de un título o leyenda indicando su contenido. Las capturas serían las siguientes:
-
Captura resumen del análisis: indica si el quality gate ha pasado. Si alguno de los elementos principales del análisis no cumple el quality gate (Security, Reliability, Maintainability), también muestra esta información. Obtenido en la pestaña Summary > Overall Code.
-
Severidad de los issues de cada elemento principal: los issues de Security, Reliability o Maintainability pueden tener diferentes niveles de gravedad o severidad (Severity). Para obtener dichos valores, se debe ir a la pestaña de Issues y seleccionar por separado cada uno de los elementos del menú Software Quality. A continuación se muestra la captura de severidades del elemento Maintainability, debéis sacar una captura por cada elemento. (Nota: no utilizaremos la sección Clean Code Attribute propia de Sonar en estos informes)
-
Gráficas de evolución de la calidad: nos interesa también estudiar cómo evoluciona el estado de nuestro código, desde el comienzo del primer Sprint hasta la situación actual. Para ello, vamos a extraer gráficas de evolución de alguna de las métricas proporcionadas por SonarCloud. Estas métricas pueden consultarse en la pestaña Activity, y utilizaremos la opción Custom que ofrece la posibilidad de añadir varias métricas en la misma gráfica. Debe extraerse:
-
Gráfica de número de issues de cada uno de los tres elementos (Security, Reliability y Maintainability). La siguiente imagen muestra estos tres conteos:
-
Como puede verse en la imagen previa, aunque se pueden poner varias métricas en la misma gráfica, a veces la diferencia entre los valores de cada una hace difícil su consulta. Si esto sucede, es mejor utilizar dos gráficas diferentes.
-
Porcentaje de código repetido y complejidad ciclomática: permiten medir cómo de mantenible es nuestro código, en base a la cantidad de copy-paste presente y a lo complejos que son los algoritmos implementados.
-
-
Burndown Chart: este gráfico permite hacerse una idea de la situación temporal del Sprint, ya que indica cómo de bien va el desarrollo en base al tiempo restante en las tareas. Este gráfico se extrae de Scrumdesk, en el menú de Reports (se recomienda usar la vista Time en la captura).
-
-
Análisis de las capturas y Plan de acción: las capturas anteriores son datos objetivos y asépticos, que deben ser interpretados y procesados:
- Se debe proporcionar un breve análisis del estado del producto, identificando los principales problemas de calidad detectados. Por ejemplo, si SonarCloud indica que no se pasa el Quality Gate, se deben describir las razones detrás de dicho fallo.
- Es conveniente hacer referencia a las capturas anteriores a la hora de analizarlas.
- El resultado principal de este análisis es la elaboración de un 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 valorar el tiempo disponible se recomienda apoyarse en la información suministrada por el Burndown Chart en el momento de realizar el informe.
- Por último, se debe incluir la lista de tareas que se ha añadido a este Sprint para poder completar el 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.