UNIVERSIDAD CENTRAL DEL ECUADOR

FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICA

INGENIERÍA INFORMÁTICA

TEMA:
Estándares para Calidad Software

MATERIA:
Control de la Calidad y Auditoria de Software

PROFESOR:
Mario Morales

INTEGRANTES:
Collaguazo Danilo
Guzmán Jonathan
Lara David

FECHA: 11-Octubre-2017
Tabla de contenido
Objetivo ........................................................................................................................... 3
Funcionalidades .............................................................................................................. 3
Vulnerabilidades Encontradas .................................................................................. 3
Análisis de resultados ..................................................................................................... 3
Errores de nivel Bajo ...................................................................................................... 4
Las importaciones inútiles deben eliminarse ........................................................... 5
Evite las líneas de código comentadas ...................................................................... 5
Los bloques de código anidados no deben dejarse vacíos ....................................... 5
Errores de nivel Medio ................................................................................................... 6
Las llaves correctas deben ubicarse al principio de las líneas de código ............... 6
Los manejadores de excepciones deberían proporcionar algún contexto y
preservar la excepción original ................................................................................. 7
Los nombres de los paquetes deben cumplir con una convención de
nomenclatura .............................................................................................................. 7
Las declaraciones deben utilizar interfaces de recopilación de Java, como
"Lista", en lugar de clases de implementación específicas, como "LinkedList". 7
Los literales de cadenas deben colocarse en el lado izquierdo cuando se busca la
igualdad ....................................................................................................................... 8
System.out y System.err no deben usarse como registradores ............................... 8
Los paréntesis inútiles alrededor de las expresiones deben eliminarse para evitar
cualquier malentendido.............................................................................................. 9
Las variables locales no utilizadas deben eliminarse .............................................. 9
Los nombres de los métodos deben cumplir con una convención de
nomenclatura .............................................................................................................. 9
Las clases de utilidad no deberían tener un constructor público ......................... 10
Índices de revisión ........................................................................................................ 10
Recomendaciones .......................................................................................................... 11
Objetivo
Analizar el proyecto “FITNESS_CENTER” con el software de análisis automático de
errores SonarQube, donde revisaremos los resultados que este arroje, categorizaremos
los mismos y verificaremos si cumple con los mínimos estándares de calidad, para dar
la aprobación de dicho proyecto.

Funcionalidades

Vulnerabilidades Encontradas
Número de
Detalle Vulnerabilidad
incidencias
Las llaves correctas deben ubicarse al principio de las líneas de 12
código
Los manejadores de excepciones deberían proporcionar algún 11
contexto y preservar la excepción original
Los nombres de los paquetes deben cumplir con una convención de 11
nomenclatura
Las declaraciones deben utilizar interfaces de recopilación de Java, 10
como "Lista", en lugar de clases de implementación específicas, como
"LinkedList".
Los literales de cadenas deben colocarse en el lado izquierdo cuando 9
se busca la igualdad
Los bloques de código anidados no deben dejarse vacíos 7
System.out y System.err no deben usarse como registradores 5
Las clases de utilidad no deberían tener un constructor público 5
Evite las líneas de código comentadas 4
Los nombres de los métodos deben cumplir con una convención de 2
nomenclatura
Las variables locales no utilizadas deben eliminarse 2
Los paréntesis inútiles alrededor de las expresiones deben eliminarse 1
para evitar cualquier malentendido
Los métodos no deberían tener demasiados parámetros 1
Los literales de cadena no deben duplicarse 6
Las importaciones inútiles deben eliminarse 3

Análisis de resultados
Con los resultados obtenidos se dará una breve explicación de cada error encontrado y
se asignara una calificación a dicho error

Nivel Descripción. Peso

 Estos errores podrían tener un potencial
Bajo 1
y menor impacto en la productividad.

Estos errores pueden tener un impacto

Medio 3
sustancial en la productividad.

Este error puede incurrir en un

comportamiento inesperado en
producción sin afectar a la integridad o
Alto 5
inestabilidad total o parcial de la
aplicación. Riesgo operacional y de
seguridad.

Se debe tomar en cuenta de porque está

Informativo dentro del código para sugerir 0
soluciones si fuera el caso.

De acuerdo al nuestro criterio el porcentaje de código aceptable que debe superar el

proyecto es del 85 %.

Errores de nivel Bajo

Los literales de cadena no deben duplicarse

Los literales de cadena duplicados son propensos a errores en la refactorización, ya que
se debe prestar atención para actualizar todas las instancias. Las constantes se pueden
referenciar desde muchos lugares, pero su valor se actualiza en un solo lugar.
(SonarQube, 2014).
El siguiente código:
Las importaciones inútiles deben eliminarse
La parte de importación de un archivo debe ser manejada por el Entorno de Desarrollo
Integrado (IDE), no manualmente por el desarrollador. Las importaciones no utilizadas
e inútiles no deberían ocurrir si ese es el caso. Dejarlos en reduce la legibilidad del
código, ya que su presencia puede ser confusa. (SonarQube, 2014).

Evite las líneas de código comentadas

Estas son las razones principales por las que el código comentado es un mal código:
Siempre plantea más preguntas que respuestas
Todos olvidarán muy rápidamente qué tan relevante es el código comentado
Esto es una distracción cuando se baja el código ya que detiene el flujo de ojos
Es un mal motor de SCM: ¡Sub-versión, CVS y Git son realmente más confiables!
El simple hecho de entender por qué el código fue comentado en primer lugar puede
tomar mucho tiempo.(SonarQube, 2014).

Los bloques de código anidados no deben dejarse vacíos

La mayoría de las veces, un bloque de código está vacío cuando falta un fragmento de
código. Entonces ese bloque vacío debe ser llenado o eliminado. Cuando un bloque
contiene un comentario, este bloque no se considera como vacío. (SonarQube, 2014).
El siguiente fragmento de código ilustra esta regla:
Errores de nivel Medio

Las llaves correctas deben ubicarse al principio de las líneas de código

Compartir algunas convenciones de codificación es un punto clave para que un equipo
pueda colaborar de manera eficiente. Esta regla obliga a colocar llaves correctas al
comienzo de las líneas de código. (SonarQube, 2014).
Los manejadores de excepciones deberían proporcionar algún contexto y
preservar la excepción original
Al manejar una excepción atrapada, se deben registrar dos informaciones obligatorias:
Algún contexto para facilitar la reproducción del problema.
La excepción del original, para su mensaje y seguimiento de la pila. (SonarQube, 2014).

Los nombres de los paquetes deben cumplir con una convención de nomenclatura
Compartir algunas convenciones de nombres es un punto clave para que un equipo
pueda colaborar de manera eficiente. Esta regla permite verificar que todos los nombres
de paquete coincidan con una expresión regular proporcionada.

El siguiente fragmento de código ilustra esta regla cuando el valor de la expresión

regular es "^ [az] + (\\. [Az] [a-z0-9] *) * $":(SonarQube, 2014).

Las declaraciones deben utilizar interfaces de recopilación de Java, como "Lista",

en lugar de clases de implementación específicas, como "LinkedList".
El objetivo de la API de colecciones de Java es proporcionar una jerarquía de interfaces
bien definida para ocultar todos los detalles de implementación. Las clases de
implementación se deben usar para crear una nueva colección, pero el resultado de una
creación de instancias debe almacenarse inmediatamente en una variable cuyo tipo es
una interfaz Java Collection. (SonarQube, 2014).

Los literales de cadenas deben colocarse en el lado izquierdo cuando se busca la

igualdad
Es preferible colocar literales de cadena en el lado izquierdo de una llamada de método
equals() o equalsIgnoreCase(). Esto evita que se generen excepciones de puntero nulo,
ya que un literal de cadena nunca puede ser nulo por definición.(SonarQube, 2014).

System.out y System.err no deben usarse como registradores

Se deben cumplir dos requisitos importantes al registrar mensajes:
El usuario debe poder recuperar fácilmente los registros.
El formato de todos los mensajes debe ser uniforme para que los usuarios puedan
navegar fácilmente por ellos.
Si un programa escribe directamente en la salida estándar, no hay absolutamente
ninguna forma de cumplir con estos requisitos. Por eso es muy recomendable definir y
usar un registrador dedicado. (SonarQube, 2014).
El siguiente fragmento de código ilustra esta regla:

Los paréntesis inútiles alrededor de las expresiones deben eliminarse para evitar
cualquier malentendido
Los paréntesis inútiles a veces pueden ser engañosos y, por lo tanto, deben eliminarse.
(SonarQube, 2014).
El siguiente fragmento de código ilustra esta regla

Las variables locales no utilizadas deben eliminarse

Si se declara una variable local pero no se utiliza en el programa, se puede considerar
código muerto y, por lo tanto, se debe eliminar. Esto mejorará la capacidad de
mantenimiento porque los desarrolladores no se preguntarán para qué se utiliza la
variable (SonarQube, 2014).

Los nombres de los métodos deben cumplir con una convención de nomenclatura
Compartir algunas convenciones de nombres es un punto clave para que un equipo
pueda colaborar de manera eficiente. Esta regla permite verificar que todos los nombres
de funciones / métodos coincidan con una expresión regular proporcionada (SonarQube
, 2014).
Las clases de utilidad no deberían tener un constructor público
Las clases de utilidad, que son una colección de miembros estáticos, no están destinadas
a crear instancias. Por lo tanto, no deberían tener constructores públicos.
Java agrega un constructor público implícito a cada clase que no define al menos una
explícitamente. Por lo tanto, se debe definir al menos un constructor no público.
El siguiente código

Índices de revisión
 Número de
Tipo de violación Peso Valor ponderado
violaciones

Bajo 20 1 20
Medio 69 3 207
Alto 0 5 0
Total 227

Líneas totales de código = 851

Error = 27
Porcentaje Aprobado = 73%

Recomendaciones
En el análisis actual del proyecto se recomienda crear un perfil de acuerdo a nuestros
estándares de calidad, modificando el nivel de error que se considere adecuado, incluir
una regla de tipo informativo para identificar apariciones en el código que no se ha
establecido y deshabilitar algunas reglas que no se considera necesarias.

Bibliografía
 SonarSource S.A. (2008-2017). Descargue SonarQube a continuación o úselo
en línea en SonarCloud: Switzerland :SonarQube: Recuperado de:
http://normasapa.com/como-citar-referenciar-paginas-web-con-normas-apa/