Taller metricas

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER
PROGRAMA DE INGENIERIA DE SISTEMAS
INGENIERIA DE SOFTWARE
Taller METRICAS SW
TEMA : Métricas de producto y de calidad
Elizabeth Ramírez Código:1151256
Janes Durán Código:1151238
José Hernández Código:1151252
Objetivo
La medición es el proceso mediante el cual se pretenden describir entidades en el mundo real
asignándoles números a sus atributos con reglas de asignación no ambiguas. La medición es
clave para: tomar decisiones informadas acerca de riesgos, mejorar la calidad de los productos
y predecir acertadamente recursos. Además para lograr medidas acertadas de calidad y
productividad es necesario recoger y analizar métricas de ciclos de vida previos.
Las métricas ofrecen soporte cuantitativo para la toma de decisiones administrativas a lo largo
del ciclo de vida del software. Sin embargo, ningún plan de recolección de métricas es factible
su requiere un cómputo manual pesado. La métricas deben recolectarse iterativa y
automáticamente.
Para ello, debe:
Cada equipo de desarrollo tiene un proyecto, para ello debe explicar las principales métricas
de calidad de código e interpretar los resultados de estas métricas sobre sus proyectos a través
de la herramienta SonarQube.
§ Dar ejemplos de uso de diversos tipos de métricas (según el proyecto en desarrollo)
1. Métrica LOC
• LOC es un acrónimo de "Lines of Code". Se utiliza como métrica en diversas situaciones,
en las que se mide el número de líneas de código.
• Es fácil de medir.
• Es fácil de combinar.
• Ofrece una medida aproximada del tamaño de un software, y de su complejidad
• No es una medida fiable de productividad personal
• Penaliza a lenguajes de alto nivel
• La complejidad de un software no depende de su tamaño

2. Puntos de Función
La métrica del punto función es un método utilizado en ingeniería del software para medir
el tamaño del software. Pretende medir la funcionalidad entregada al usuario
independientemente de la tecnología utilizada para la construcción y explotación del
software, y también ser útil en cualquiera de las fases de vida del software, desde el diseño
inicial hasta la implementación y mantenimiento.
• El proceso requiere dos etapas fundamentales:
1) Se identifican los requerimientos funcionales del usuario y se organizan en cinco grupos:
• Entrada Externa (EI): Procesos en los que se introducen datos y que suponen
la actualización de cualquier archivo interno
• Salida Externa (EO): Procesos en los que se envían datos al exterior de la
aplicación
• Consulta Externa (EQ): Procesos consistentes en la combinación de una entrada
y una salida, en el que la entrada no produce ningún cambio en la aplicación
• Archivo lógico interno (ILF): Grupo de datos relacionados entre sí internos del
sistema
• Archivo interfaz externo (EIF): Grupo de datos que se mantienen externamente
Tipo/Complejidad Baja Media Alta
EI: Entrada Externa 3PF 4PF 6PF

EO: Salida Externa 4PF 5PF 7PF
EQ: Consulta Externa 3PF 4PF 6PF
ILF: Archivo Lógico Interno 7PF 10PF 15PF
EIF : Archivo Interfaz Externo 5PF 7PF 10PF
Id Nombre Tipo Complejidad Valor
RF1 Subir archivos (imágenes, doc de Word,
pdf, etc)
EI MEDIA 4PF
RF2 Modificar archivos EI BAJA 3PF
RF3 Eliminar archivos EI BAJA 3PF
RF4 Descargar archivo EI MEDIA 4PF
RF5 Mostrar noticias eventos y novedades EO BAJA 4PF
RF6 Modificar noticias eventos y novedades EI ALTA 6PF
RF7 Eliminar noticias eventos y novedades EI ALTA 6PF
RF8 Registrar noticias eventos y novedades EI ALTA 6PF
RF9 Mostrar registro de las actividades
semestrales
EQ ALTA 6PF
RF10 Generar reportes EI BAJA 3PF
RF11 Agregar un menú EI BAJA 3PF
RF12 Eliminar un menú EI BAJA 3PF
RF13 Modificar un menú EI BAJA 3PF
RF14 Agregar un submenú EI BAJA 3PF
RF15 Eliminar un submenú EI BAJA 3PF
RF16 Modificar un submenú EI BAJA 3PF

FACTORES DE AJUSTE PUNTUACIÓN
Comunicación de datos 3
Procesamiento distribuido 0
Objetivos de rendimiento 4
Configuración del equipamiento 2
Tasa de transacciones 0
Entrada de datos en línea 5
Interface con el usuario 2
Actualizaciones en línea 3
Procesamiento complejo 1
Reusabilidad del código 2
Facilidad de implementación 2
Facilidad de operación 0
Instalaciones múltiples 2
Facilidad de cambios 5
Factor de ajuste total 31
3. Métrica de Mantenimiento
• Todas las métricas del software pueden usarse para el desarrollo de nuevo software y
para el mantenimiento del existente. Sin embargo, se han propuesto métricas
diseñadas explícitamente para actividades de mantenimiento.
• El estándar EEE 982.1-1988 sugiere un índice de madurez del software (IMS) que
proporciona una indicación de la estabilidad de un producto software (basada en los
cambios que ocurren con cada versión del producto). Se determina la siguiente
información:

El índice de madurez del software se calcula de la siguiente manera:
• MT = 5 módulos
• Fc = 1 módulo
• Fa = 1 módulo
• Fd = 0 módulos
§ Describir la utilidad de las métricas de software
Debido a la cantidad creciente de aplicaciones de software que están disponibles para crear
y administrar contenidos de cursos basados en tecnología, se plantea la necesidad de
contar con técnicas que permitan medir y evaluar los productos desarrollados.
Utilidad de las Métricas:
Las métricas se utilizan para evaluar y controlar el proceso de desarrollo del software, de
forma que permitan:
o Indicar la calidad del producto.
o Evaluar la productividad de los desarrolladores
o Evaluar los beneficios (en cuanto a calidad y productividad).
o Derivados del uso de nuevos métodos y herramientas de ingeniería del software.
o Establecer una línea base para la estimación.
o Justificar el uso de nuevas herramientas o de formación adicional
o Pero es necesario utilizar las métricas más adecuadas para conseguir el control,
seguimiento y mejora de la calidad, y para ello es necesario determinar los factores de
calidad más importantes dentro del proyecto.
o Medición “objetiva antes que subjetiva”
o Especificar en el mundo formal, la correspondencia de un atributo del mundo empírico
o Servir de “base” a Métodos Cuantitativos de Evaluación o Predicción
§ Explicar la importancia de la medición en los procesos de calidad
Hay varias razones que justifican el uso de las métricas en el proceso de desarrollo de
software. Por un lado se dice que cuando se puede medir aquello de lo cual se está

hablando y se puede expresar en números, se sabe realmente acerca de ello; pero cuando
no puede medirse, y no puede expresarse en números, el conocimiento que se tiene de
ello es escaso e insatisfactorio.
La importancia de la medición es demostrar que tan porcentualmente está cumpliendo la
organización en sus procesos y evidenciar que las metas trazadas van por un buen camino.
En cada empresa, habrá unos procesos que serán clave y otros que tendrán una
importancia menos en el negocio. Como primera aproximación, los procesos de negocio,
que son los que aportan valor al cliente, son los que deberían tener una importancia mayor,
aunque no por ello deben descartarse los procesos de soporte. En función otros parámetros
adicionales al del valor aportado a los clientes, como es el impacto en la cuenta de
resultados, se podrá determinar cuáles son los procesos clave en los merece la pena
desplegar proyectos de mejora continua y medir resultados.
§ Diferenciar las principales métricas de productos de software orientados a objetos
Métricas para pruebas orientadas a objetos
o Falta de cohesión en métodos (FCOM). Mientras más alto sea el valor de la FCOM, más
estados deben ponerse a prueba para garantizar que los métodos no generan efectos
colaterales.
o Porcentaje público y protegido (PPP). Esta métrica indica el porcentaje de los atributos
de clase que son públicos o protegidos. Valores altos de PPP aumentan la probabilidad
de efectos colaterales entre las clases porque los atributos públicos y protegidos
conducen a alto potencial para acoplamiento.
o Acceso público a miembros de datos (APD). Esta métrica indica el número de clases (o
métodos) que pueden acceder a otros atributos de clase, una violación de la
encapsulación. Valores altos de APD conducen al potencial de efectos colaterales entre
clases. Las pruebas deben diseñarse para garantizar el descubrimiento de tales efectos
colaterales.
o Número de clases raíz (NCR). Esta métrica es un conteo de las distintas jerarquías de
clase que se describen en el modelo de diseño. Deben desarrollarse las suites de
prueba para cada clase raíz y la correspondiente jerarquía de clase. Conforme el NCR
aumenta, también aumenta el esfuerzo de prueba.
o Fan-in (FIN). Cuando se usa en el contexto OO, el fan-in (abanico de entrada) en la
jerarquía de herencia es un indicio de herencia múltiple. FIN > 1 indica que una clase
hereda sus atributos y operaciones de más de una clase raíz. FIN > 1 debe evitarse
cuando sea posible.

o Número de hijos (NDH) y profundidad del árbol de herencia (PAH). los métodos de
superclase tendrán que volverse a probar para cada subclase.
Métricas OO propuestas por Lorenz y Kidd
Tamaño de clase (TDC).El tamaño global de una clase puede determinarse usando las
siguientes medidas:
• El número total de operaciones (tanto heredadas como operaciones de instancia privada)
que se encapsulan dentro de la clase.
• El número de atributos (tanto heredados como de instancia privada) que encapsula la
clase.
Grandes valores para TDC indican que una clase puede tener demasiada responsabilidad.
Esto reducirá la reutilización de la clase y complicará la implementación y las pruebas.
En general, las operaciones y atributos heredados o públicos deben ponderarse más
para determinar el tamaño de clase. Mientras más bajos sean los valores promedio
para el tamaño, hay más probabilidad de que las clases dentro del sistema puedan
reutilizarse ampliamente.
Métricas para diseño orientado a objetos
o Tamaño. El tamaño se define en función de cuatro visiones: población, volumen,
longitud y funcionalidad.
o Complejidad. Como el tamaño, existen muchas visiones diferentes de la complejidad
del software. Whitmire ve la complejidad en términos de características estructurales
al examinar cómo se relacionan mutuamente las clases de un diseño OO.
o Acoplamiento. Las conexiones físicas entre elementos del diseño OO (por ejemplo, el
número de colaboraciones entre clases o el de mensajes que pasan entre los objetos)
representan el acoplamiento dentro de un sistema OO.
o Suficiencia. Whitmire define suficiencia como “el grado en el que una abstracción posee
las características requeridas de él o en el que un componente de diseño posee
características en su abstracción, desde el punto de vista de la aplicación actual”.
o Completitud. La única diferencia entre completitud y suficiencia es “el conjunto de
características contra las cuales se compara la abstracción o el componente de diseño”.
o Cohesión. La cohesividad de una clase se determina al examinar el grado en el que “el
conjunto de propiedades que posee es parte del problema o dominio de diseño.
o Similitud. El grado en el que dos o más clases son similares en términos de su estructura,
función, comportamiento o propósito se indica mediante esta medida.
o Volatilidad. La volatilidad de un componente de diseño OO mide la probabilidad de que
ocurrirá un cambio.

§ Formular metas y planes de calidad
Corregir todos todos los errores que se han encontrado durante el tiempo que el aplicativo
lleva en funcionamiento.
Realizar pruebas que permitan evaluar la corrección de los errores solucionados.
Realizar constantemente pruebas de seguridad con el objetivo de encontrar
vulnerabilidades de seguridad en el software que comprometan al aplicativo y la
información de sus usuarios.
Probar el aplicativo en ciertos escenarios donde haya un alto tráfico de usuarios en el sitio
con el fin de realizar pruebas de velocidad, estrés y carga.
§ Explicar la importancia de los datos históricos en los modelos predictivos
La Minería de Datos se centra en la búsqueda de patrones interesantes y regularidades
importantes en grandes bases de datos.
El aumento del volumen y variedad de información que se encuentran en bases de datos
digitales ha crecido espectacularmente en la última década. Gran parte de esta información
es histórica, es decir, representa transacciones o situaciones que se han producido
(bitácoras). Aparte de su función de “memoria de la organización”, la información histórica
es útil para predecir la información futura.
Áreas de Aplicación Soporte al Diseño de Bases de Datos.
o Reverse Engineering (dados una base de datos, desnormalizarla para que luego el
sistema la normalice).
o Mejora de Calidad de Datos.
o Mejora de Consultas (si se descubren dependencias funcionales nuevas u otras
condiciones evitables).
o Extracción de modelos sobre comportamiento de compuestos.
o Detección de piezas con trabas.
o Predicción de fallos
o Modelos de calidad.
o Estimación de composiciones óptimas en mezclas.
o Extracción de modelos de coste.
o Extracción de modelos de producción.
o Simulación costes/beneficios según niveles de calidad

§ Aplicar las métricas de software para asegurar la calidad del producto de manera
objetiva.
La medición en los procesos de calidad es importante ya que da a conocer los resultados que
se están obteniendo y si estos resultados cubren los objetivos previstos.
§ Identificar mecanismos de evaluación y adecuación de un proyecto
Mecanismos de evaluación y adecuación de un proyecto.
VAN(VALOR ACTUAL NETO): Identifica los costos, ingresos e inversiones de un proyecto,
relacionándolos mediante la construcción de un flujo de caja para cada período anual que dure el
horizonte de evaluación el proyecto.
TIR(TASA DE RENTABILIDAD INTERNA): Tasa Interna de Retorno es la tasa de descuento de los
flujos de caja que permite igualar el VAN a 0.
EVA(Valor Económico Agregado): Trata de medir el valor que un proyecto agrega a la empresa o el
valor que genera esta en un determinado período de tiempo.
Árboles de decisión: Es una técnica gráfica que permite representar y analizar una serie de
decisiones futuras de carácter secuencial a través del tiempo, vale decir los posibles escenarios que
podrían presentarse a medida que avance el proyecto.
Simulación de Montecarlo: Es una técnica de simulación de situaciones inciertas que permite definir
valores esperados y variabilidad para variables no controlables, mediante la selección aleatoria de
valores, donde la probabilidad de elegir entre todos los resultados posibles está en estricta relación
con sus distribuciones de probabilidades.
Opciones Reales: El concepto de opciones reales aplica las técnicas desarrolladas en la teoría de
opciones financieras para analizar activos no financieros o activos reales. Al igual que las opciones
financieras, la principal característica de las opciones reales es que confieren el derecho, pero no la
obligación, de tomar medidas en el futuro. Una opción real, plantea las alternativas de realizar, esperar,
agrandar, achicar o abandonar un proyecto, dependiendo del entorno y evolución de las variables que
influyen en el resultado de un proyecto, agregando de este modo un alto grado de flexibilidad en las
decisiones.

§ Buscar otras herramientas de software libre que permitan realizar métricas de software
diferentes a las anteriores. (por lo menos 3 por equipo de desarrollo)
Herramientas
Check Style
Herramienta de análisis estático de código que se utiliza para comprobar que el código
analizado cumple con una serie de reglas de estilo. Ejemplo, analiza el código según el estandar
“Sun Code Conventions” (mira las cabeceras, importaciones de paquetes, Javadoc, etc.).
Página oficial: http://checkstyle.sourceforge.net/. Trabaja para Java. La licencia es: GNU
Lesser General Public License Version 2.1.
SONAR
Una herramienta de software libre y gratuita que permite gestionar la calidad del código fuente.
Al instalarla podremos recopilar, analizar, y visualizar métricas del código fuente. Sonar es
básicamente la fusión de las siguientes herramientas Checkstyle y PMD, más otras que no
menciono en este post, como Findbugs, Clover y Cobertura. También realiza un histórico de
todas las métricas del proyecto. Permite visualizar informes con resumenes de las métricas.
Página oficial: http://www.sonarsource.org. Trabaja, principalmente, para Java. Aunque da
soporte, gracias a la amplia librería de plugins (algunos de pago), a los siguientes lenguajes:
ABAP, C, Cobol, C#, Delphi/Pascal, Flex/ActionScript, Groovy, JavaScript, Natural, PHP,
PL/SQL, Visual Basic 6, Web y XML. La licencia es: LGPL.
PMD à pmd.github.io
PMD es un analizador de código fuente. Encuentra fallas de programación comunes como
variables no utilizadas, bloques de captura vacíos, creación de objetos innecesarios,
etc. Soporta Java, JavaScript, Salesforce.com Apex y Visualforce, PLSQL, Apache
Velocity, XML, XSL.
Además, incluye CPD, el copiar-pegar-detector. CPD encuentra código duplicado en Java,
C, C ++, C #, Groovy, PHP, Ruby, Fortran, JavaScript, PLSQL, Apache Velocity, Scala,
Objective C, Matlab, Python, Go, Swift y Salesforce.com Apex y Visualforce.
Ø Google CodePro Analytix
Herramientas de calidad software, ofrece un entorno para evaluación de código, métricas,
análisis de dependencias, cobertura de código, generación de Test unitarios, etc. Mira

las excepciones, refactorizaciones potenciales, convenios de JavaDoc, métricas, etc.
Disponible como plugin de Eclipse. Página oficial: http://code.google.com/intl/es-
ES/javadevtools/codepro/doc/index.html. Trabaja para Java, concretamente en
Eclipse. La herramienta es gratis
HERRAMIENTAS
Metrics .
revisar http://metrics.sourceforge.net/
§ Metrics es un plugin de Eclipse para cálculo de métricas de un producto de software.
Tiene licencia CPL 1.0
§ Metrics permite exportar la metricas obtenidas de un proyecto a un archivo xml. Tambien
sirve para mostrar las dependencias entre paquetes.
§ Entre otras métricas calcula: Number of classes, Number of children, Number of
interfaces, Number of static methods, Number of static attributes, Number of
parámetros, Depth of inheritance tree (DIT), Number of Overriden Methods (NORM),
Number of Methods (NOM), Number of attributes, Líneas de código, Specialization
Index (SI), McCabe Cyclomatic Complexity, Weighted methods per class (WMC), Lack
of cohesion of methods (LCOM), Afferent Coupling (Ca), Efferent Coupling (Ce),
Instability (I), Abstractness (A), Normalized distance frommain sequence (Dn), Nested
block depth.
Nota: enviar el Taller al correo pilinrt@yahoo.es

Taller metricas

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Taller metricas

Ähnlich wie Taller metricas (20)

Mehr von Janes Durán

Mehr von Janes Durán (11)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Taller metricas