SlideShare uma empresa Scribd logo
1 de 11
Baixar para ler offline
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
UNIVERSIDAD FRANCISCO DE PAULA SANTANDER
PROGRAMA DE INGENIERIA DE SISTEMAS
INGENIERIA DE SOFTWARE
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
UNIVERSIDAD FRANCISCO DE PAULA SANTANDER
PROGRAMA DE INGENIERIA DE SISTEMAS
INGENIERIA DE SOFTWARE
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
UNIVERSIDAD FRANCISCO DE PAULA SANTANDER
PROGRAMA DE INGENIERIA DE SISTEMAS
INGENIERIA DE SOFTWARE
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:
UNIVERSIDAD FRANCISCO DE PAULA SANTANDER
PROGRAMA DE INGENIERIA DE SISTEMAS
INGENIERIA DE SOFTWARE
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á
UNIVERSIDAD FRANCISCO DE PAULA SANTANDER
PROGRAMA DE INGENIERIA DE SISTEMAS
INGENIERIA DE SOFTWARE
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.
UNIVERSIDAD FRANCISCO DE PAULA SANTANDER
PROGRAMA DE INGENIERIA DE SISTEMAS
INGENIERIA DE SOFTWARE
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.
UNIVERSIDAD FRANCISCO DE PAULA SANTANDER
PROGRAMA DE INGENIERIA DE SISTEMAS
INGENIERIA DE SOFTWARE
§ 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
UNIVERSIDAD FRANCISCO DE PAULA SANTANDER
PROGRAMA DE INGENIERIA DE SISTEMAS
INGENIERIA DE SOFTWARE
§ 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.
UNIVERSIDAD FRANCISCO DE PAULA SANTANDER
PROGRAMA DE INGENIERIA DE SISTEMAS
INGENIERIA DE SOFTWARE
§ 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
UNIVERSIDAD FRANCISCO DE PAULA SANTANDER
PROGRAMA DE INGENIERIA DE SISTEMAS
INGENIERIA DE SOFTWARE
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

Mais conteúdo relacionado

Mais procurados

Tecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto softwareTecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto softwareantonio
 
Factores de calidad según mc call
Factores de calidad según mc callFactores de calidad según mc call
Factores de calidad según mc callclauddiaa
 
Cuadro comparativo modelos para el desarrollo de software
Cuadro comparativo modelos para el desarrollo de softwareCuadro comparativo modelos para el desarrollo de software
Cuadro comparativo modelos para el desarrollo de softwarepaoaboytes
 
PLAN DE CAPACITACIÓN PARA USUARIOS FINALES
PLAN DE CAPACITACIÓN PARA USUARIOS FINALESPLAN DE CAPACITACIÓN PARA USUARIOS FINALES
PLAN DE CAPACITACIÓN PARA USUARIOS FINALESPablo Ospina
 
Tecnicas de estimacion de software
Tecnicas de estimacion de softwareTecnicas de estimacion de software
Tecnicas de estimacion de softwareAdes27
 
Metricas tecnicas del software
Metricas tecnicas del softwareMetricas tecnicas del software
Metricas tecnicas del softwareaimeemoir
 
2. Casos de uso y diagramas de casos de uso
2. Casos de uso y diagramas de casos de uso2. Casos de uso y diagramas de casos de uso
2. Casos de uso y diagramas de casos de usoSaul Mamani
 
Pmo informatica plantilla de plan de pruebas de software
Pmo informatica plantilla de plan de pruebas de softwarePmo informatica plantilla de plan de pruebas de software
Pmo informatica plantilla de plan de pruebas de softwareCarina Lifschitz
 
Métricas del Software
Métricas del SoftwareMétricas del Software
Métricas del SoftwareArabel Aguilar
 
Analisis de Sistema
Analisis de SistemaAnalisis de Sistema
Analisis de Sistemapamelacortez
 
Integridad Y Seguridad En Las Bases De Datos
Integridad Y Seguridad En Las Bases De DatosIntegridad Y Seguridad En Las Bases De Datos
Integridad Y Seguridad En Las Bases De DatosDrakonis11
 
Control de Calidad del Software
Control de  Calidad del SoftwareControl de  Calidad del Software
Control de Calidad del SoftwareIntellimedia
 
PROCESOS DE CALIDAD DE SOFTWARE
PROCESOS DE CALIDAD DE SOFTWAREPROCESOS DE CALIDAD DE SOFTWARE
PROCESOS DE CALIDAD DE SOFTWAREAlejandro Leon
 
Proyecto de software
Proyecto de softwareProyecto de software
Proyecto de softwaremonik1002
 
Estándares y modelos de calidad del software
Estándares y modelos de calidad del softwareEstándares y modelos de calidad del software
Estándares y modelos de calidad del softwarerodigueezleidy
 

Mais procurados (20)

Tecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto softwareTecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto software
 
Ieee 830
Ieee 830Ieee 830
Ieee 830
 
Factores de calidad según mc call
Factores de calidad según mc callFactores de calidad según mc call
Factores de calidad según mc call
 
Cuadro comparativo modelos para el desarrollo de software
Cuadro comparativo modelos para el desarrollo de softwareCuadro comparativo modelos para el desarrollo de software
Cuadro comparativo modelos para el desarrollo de software
 
PLAN DE CAPACITACIÓN PARA USUARIOS FINALES
PLAN DE CAPACITACIÓN PARA USUARIOS FINALESPLAN DE CAPACITACIÓN PARA USUARIOS FINALES
PLAN DE CAPACITACIÓN PARA USUARIOS FINALES
 
Tecnicas de estimacion de software
Tecnicas de estimacion de softwareTecnicas de estimacion de software
Tecnicas de estimacion de software
 
Metricas tecnicas del software
Metricas tecnicas del softwareMetricas tecnicas del software
Metricas tecnicas del software
 
PSW Unidad 1 PROCESO DE SOFTWARE
PSW Unidad 1 PROCESO DE SOFTWAREPSW Unidad 1 PROCESO DE SOFTWARE
PSW Unidad 1 PROCESO DE SOFTWARE
 
2. Casos de uso y diagramas de casos de uso
2. Casos de uso y diagramas de casos de uso2. Casos de uso y diagramas de casos de uso
2. Casos de uso y diagramas de casos de uso
 
Curso de BPMN 2.0
Curso de BPMN 2.0Curso de BPMN 2.0
Curso de BPMN 2.0
 
Pmo informatica plantilla de plan de pruebas de software
Pmo informatica plantilla de plan de pruebas de softwarePmo informatica plantilla de plan de pruebas de software
Pmo informatica plantilla de plan de pruebas de software
 
Métricas del Software
Métricas del SoftwareMétricas del Software
Métricas del Software
 
Analisis de Sistema
Analisis de SistemaAnalisis de Sistema
Analisis de Sistema
 
Integridad Y Seguridad En Las Bases De Datos
Integridad Y Seguridad En Las Bases De DatosIntegridad Y Seguridad En Las Bases De Datos
Integridad Y Seguridad En Las Bases De Datos
 
Control de Calidad del Software
Control de  Calidad del SoftwareControl de  Calidad del Software
Control de Calidad del Software
 
PROCESOS DE CALIDAD DE SOFTWARE
PROCESOS DE CALIDAD DE SOFTWAREPROCESOS DE CALIDAD DE SOFTWARE
PROCESOS DE CALIDAD DE SOFTWARE
 
Proyecto de software
Proyecto de softwareProyecto de software
Proyecto de software
 
metodología crystal clear
 metodología crystal clear metodología crystal clear
metodología crystal clear
 
Estándares y modelos de calidad del software
Estándares y modelos de calidad del softwareEstándares y modelos de calidad del software
Estándares y modelos de calidad del software
 
Metodología RUP
Metodología RUPMetodología RUP
Metodología RUP
 

Semelhante a Taller metricas

Medición de calidad
Medición de calidadMedición de calidad
Medición de calidadUTCH
 
Plantilla trabajo final_Ana_Jesus
Plantilla trabajo final_Ana_JesusPlantilla trabajo final_Ana_Jesus
Plantilla trabajo final_Ana_JesusAnnie Mrtx
 
Vídeo métricas del software 1151354
Vídeo métricas del software 1151354Vídeo métricas del software 1151354
Vídeo métricas del software 1151354Daniela Buitrago
 
Guia de calidad para desarrollo de software
Guia de calidad para desarrollo de softwareGuia de calidad para desarrollo de software
Guia de calidad para desarrollo de softwareAndres Epifanía Huerta
 
17727554-Metricas-de-Procesos-y-Proyecto.pdf
17727554-Metricas-de-Procesos-y-Proyecto.pdf17727554-Metricas-de-Procesos-y-Proyecto.pdf
17727554-Metricas-de-Procesos-y-Proyecto.pdfAndrea Alvarez
 
Metricas del producto para el Software
Metricas del producto para el SoftwareMetricas del producto para el Software
Metricas del producto para el SoftwareWalter Tejerina
 
12 introduccion a las metricas
12 introduccion a las metricas12 introduccion a las metricas
12 introduccion a las metricasUVM
 
Metricas de software
Metricas de softwareMetricas de software
Metricas de softwareMAYRA
 
Unidad 1_calidad del software
Unidad 1_calidad del softwareUnidad 1_calidad del software
Unidad 1_calidad del softwareraaf0001
 
Métricas de calidad de software
Métricas de calidad de softwareMétricas de calidad de software
Métricas de calidad de softwareCarlosLamanna1
 
Métricas de calidad de software
Métricas de calidad de softwareMétricas de calidad de software
Métricas de calidad de softwareVaalbarSoftware
 
Fundamentos del diseño y Garantías de Calidad del Software
Fundamentos del diseño y Garantías de Calidad del SoftwareFundamentos del diseño y Garantías de Calidad del Software
Fundamentos del diseño y Garantías de Calidad del SoftwareRichard J. Nuñez
 
La medición total del software
La medición total del softwareLa medición total del software
La medición total del softwareSoftware Guru
 
Modelo de un sistema de gestión de calidad basado en procesos
Modelo de un sistema de gestión de calidad basado en procesosModelo de un sistema de gestión de calidad basado en procesos
Modelo de un sistema de gestión de calidad basado en procesosDiana Muñoz
 

Semelhante a Taller metricas (20)

Medición de calidad
Medición de calidadMedición de calidad
Medición de calidad
 
Metricas01
Metricas01Metricas01
Metricas01
 
Metricas01
Metricas01Metricas01
Metricas01
 
Metricas01
Metricas01Metricas01
Metricas01
 
Metricas01
Metricas01Metricas01
Metricas01
 
Metricas01
Metricas01Metricas01
Metricas01
 
Plantilla trabajo final_Ana_Jesus
Plantilla trabajo final_Ana_JesusPlantilla trabajo final_Ana_Jesus
Plantilla trabajo final_Ana_Jesus
 
Vídeo métricas del software 1151354
Vídeo métricas del software 1151354Vídeo métricas del software 1151354
Vídeo métricas del software 1151354
 
Guia de calidad para desarrollo de software
Guia de calidad para desarrollo de softwareGuia de calidad para desarrollo de software
Guia de calidad para desarrollo de software
 
17727554-Metricas-de-Procesos-y-Proyecto.pdf
17727554-Metricas-de-Procesos-y-Proyecto.pdf17727554-Metricas-de-Procesos-y-Proyecto.pdf
17727554-Metricas-de-Procesos-y-Proyecto.pdf
 
Metricas del producto para el Software
Metricas del producto para el SoftwareMetricas del producto para el Software
Metricas del producto para el Software
 
12 introduccion a las metricas
12 introduccion a las metricas12 introduccion a las metricas
12 introduccion a las metricas
 
Metricas de software
Metricas de softwareMetricas de software
Metricas de software
 
Unidad 1_calidad del software
Unidad 1_calidad del softwareUnidad 1_calidad del software
Unidad 1_calidad del software
 
Métricas de calidad de software
Métricas de calidad de softwareMétricas de calidad de software
Métricas de calidad de software
 
Métricas de calidad de software
Métricas de calidad de softwareMétricas de calidad de software
Métricas de calidad de software
 
Fundamentos del diseño y Garantías de Calidad del Software
Fundamentos del diseño y Garantías de Calidad del SoftwareFundamentos del diseño y Garantías de Calidad del Software
Fundamentos del diseño y Garantías de Calidad del Software
 
La medición total del software
La medición total del softwareLa medición total del software
La medición total del software
 
Modelo de un sistema de gestión de calidad basado en procesos
Modelo de un sistema de gestión de calidad basado en procesosModelo de un sistema de gestión de calidad basado en procesos
Modelo de un sistema de gestión de calidad basado en procesos
 
Unidad1_EMDS.pptx
Unidad1_EMDS.pptxUnidad1_EMDS.pptx
Unidad1_EMDS.pptx
 

Mais de Janes Durán

Mais de Janes Durán (11)

Cmmi
CmmiCmmi
Cmmi
 
Cpm
CpmCpm
Cpm
 
Pert
PertPert
Pert
 
Plan de Gestion
Plan de GestionPlan de Gestion
Plan de Gestion
 
Tipos de equipos
Tipos de equiposTipos de equipos
Tipos de equipos
 
Taller 2 generalidasdes
Taller 2 generalidasdesTaller 2 generalidasdes
Taller 2 generalidasdes
 
Articulo resumen
Articulo resumenArticulo resumen
Articulo resumen
 
Articulo acm
Articulo acmArticulo acm
Articulo acm
 
1151256 ref. bibliograficas
1151256 ref. bibliograficas1151256 ref. bibliograficas
1151256 ref. bibliograficas
 
Pruebas de aceptacion info vaie 1151238_1151252_1151256
Pruebas de aceptacion info vaie 1151238_1151252_1151256Pruebas de aceptacion info vaie 1151238_1151252_1151256
Pruebas de aceptacion info vaie 1151238_1151252_1151256
 
Ingenieria inversa
Ingenieria inversaIngenieria inversa
Ingenieria inversa
 

Último

Fundamentos - Curso Desarrollo Web (HTML, JS, PHP, JS, SQL)
Fundamentos - Curso Desarrollo Web (HTML, JS, PHP, JS, SQL)Fundamentos - Curso Desarrollo Web (HTML, JS, PHP, JS, SQL)
Fundamentos - Curso Desarrollo Web (HTML, JS, PHP, JS, SQL)EmanuelMuoz11
 
gabriela marcano estructura iii historia del concreto
gabriela marcano  estructura iii historia del concretogabriela marcano  estructura iii historia del concreto
gabriela marcano estructura iii historia del concretoGabrielaMarcano12
 
1_Tipos Básicos de Motores - funcionamientos
1_Tipos Básicos de Motores - funcionamientos1_Tipos Básicos de Motores - funcionamientos
1_Tipos Básicos de Motores - funcionamientosMaicoPinelli
 
aplicacion-del-metodo-cientifico-de-roberto-hernandez-carlos-fernandez-y-pila...
aplicacion-del-metodo-cientifico-de-roberto-hernandez-carlos-fernandez-y-pila...aplicacion-del-metodo-cientifico-de-roberto-hernandez-carlos-fernandez-y-pila...
aplicacion-del-metodo-cientifico-de-roberto-hernandez-carlos-fernandez-y-pila...AmeliaJul
 
analisis matematico 2 elon lages lima .pdf
analisis matematico 2 elon lages lima .pdfanalisis matematico 2 elon lages lima .pdf
analisis matematico 2 elon lages lima .pdfJOHELSANCHEZINCA
 
CV_SOTO_SAUL 30-01-2024 (1) arquitecto.pdf
CV_SOTO_SAUL 30-01-2024  (1) arquitecto.pdfCV_SOTO_SAUL 30-01-2024  (1) arquitecto.pdf
CV_SOTO_SAUL 30-01-2024 (1) arquitecto.pdfsd3700445
 
PPT_Conferencia OBRAS PUBLICAS x ADMNISTRACION DIRECTA.pdf
PPT_Conferencia OBRAS PUBLICAS x ADMNISTRACION DIRECTA.pdfPPT_Conferencia OBRAS PUBLICAS x ADMNISTRACION DIRECTA.pdf
PPT_Conferencia OBRAS PUBLICAS x ADMNISTRACION DIRECTA.pdfANGHELO JJ. MITMA HUAMANÌ
 
CALCULISTA AGUA POTABLE ALCANTARILLADO RURAL CURACAVÍ
CALCULISTA AGUA POTABLE ALCANTARILLADO RURAL CURACAVÍCALCULISTA AGUA POTABLE ALCANTARILLADO RURAL CURACAVÍ
CALCULISTA AGUA POTABLE ALCANTARILLADO RURAL CURACAVÍArquitecto Chile
 
Poder puedo, pero no lo haré - T3chfest
Poder puedo, pero no lo haré - T3chfestPoder puedo, pero no lo haré - T3chfest
Poder puedo, pero no lo haré - T3chfestSilvia España Gil
 
BROCHURE EDIFICIO MULTIFAMILIAR LIMA. PERU
BROCHURE EDIFICIO MULTIFAMILIAR LIMA. PERUBROCHURE EDIFICIO MULTIFAMILIAR LIMA. PERU
BROCHURE EDIFICIO MULTIFAMILIAR LIMA. PERUSharonRojas28
 
Diseño de Algoritmos Paralelos con la maestra Rina
Diseño de Algoritmos Paralelos con la maestra RinaDiseño de Algoritmos Paralelos con la maestra Rina
Diseño de Algoritmos Paralelos con la maestra RinaLuisAlfredoPascualPo
 
Cuadro de las web 1.0, 2.0 y 3.0 pptx
Cuadro de las web 1.0, 2.0 y 3.0     pptxCuadro de las web 1.0, 2.0 y 3.0     pptx
Cuadro de las web 1.0, 2.0 y 3.0 pptxecarmariahurtado
 
Presentación de Ciencia, Cultura y Progreso.pptx
Presentación de Ciencia, Cultura y Progreso.pptxPresentación de Ciencia, Cultura y Progreso.pptx
Presentación de Ciencia, Cultura y Progreso.pptxwilliam atao contreras
 
IA T3 Elaboración e interpretación de planos.pptx
IA T3 Elaboración e interpretación de planos.pptxIA T3 Elaboración e interpretación de planos.pptx
IA T3 Elaboración e interpretación de planos.pptxcecymendozaitnl
 
Mecánica vectorial para ingenieros estática. Beer - Johnston. 11 Ed.pdf
Mecánica vectorial para ingenieros estática. Beer - Johnston. 11 Ed.pdfMecánica vectorial para ingenieros estática. Beer - Johnston. 11 Ed.pdf
Mecánica vectorial para ingenieros estática. Beer - Johnston. 11 Ed.pdfaaaaaaaaaaaaaaaaa
 
concreto pretensado y postensado- reseña historica
concreto pretensado y postensado- reseña historicaconcreto pretensado y postensado- reseña historica
concreto pretensado y postensado- reseña historicaamira520031
 
Principios de Circuitos Eléctricos (Thomas L. Floyd) (Z-Library).pdf
Principios de Circuitos Eléctricos (Thomas L. Floyd) (Z-Library).pdfPrincipios de Circuitos Eléctricos (Thomas L. Floyd) (Z-Library).pdf
Principios de Circuitos Eléctricos (Thomas L. Floyd) (Z-Library).pdfYADIRAXIMENARIASCOSV
 
Método inductivo.pdf-lizzeh cuellar cardenas
Método inductivo.pdf-lizzeh cuellar cardenasMétodo inductivo.pdf-lizzeh cuellar cardenas
Método inductivo.pdf-lizzeh cuellar cardenas182136
 
Modulo 4 - Monitoreo Hidrobiológico de monitoreo ambiental
Modulo 4 - Monitoreo Hidrobiológico de monitoreo ambientalModulo 4 - Monitoreo Hidrobiológico de monitoreo ambiental
Modulo 4 - Monitoreo Hidrobiológico de monitoreo ambientalAcountsStore1
 
Modulo 5 - Monitoreo de Ruido Ambiental de monitoreo ambiental
Modulo 5 - Monitoreo de Ruido Ambiental de monitoreo ambientalModulo 5 - Monitoreo de Ruido Ambiental de monitoreo ambiental
Modulo 5 - Monitoreo de Ruido Ambiental de monitoreo ambientalAcountsStore1
 

Último (20)

Fundamentos - Curso Desarrollo Web (HTML, JS, PHP, JS, SQL)
Fundamentos - Curso Desarrollo Web (HTML, JS, PHP, JS, SQL)Fundamentos - Curso Desarrollo Web (HTML, JS, PHP, JS, SQL)
Fundamentos - Curso Desarrollo Web (HTML, JS, PHP, JS, SQL)
 
gabriela marcano estructura iii historia del concreto
gabriela marcano  estructura iii historia del concretogabriela marcano  estructura iii historia del concreto
gabriela marcano estructura iii historia del concreto
 
1_Tipos Básicos de Motores - funcionamientos
1_Tipos Básicos de Motores - funcionamientos1_Tipos Básicos de Motores - funcionamientos
1_Tipos Básicos de Motores - funcionamientos
 
aplicacion-del-metodo-cientifico-de-roberto-hernandez-carlos-fernandez-y-pila...
aplicacion-del-metodo-cientifico-de-roberto-hernandez-carlos-fernandez-y-pila...aplicacion-del-metodo-cientifico-de-roberto-hernandez-carlos-fernandez-y-pila...
aplicacion-del-metodo-cientifico-de-roberto-hernandez-carlos-fernandez-y-pila...
 
analisis matematico 2 elon lages lima .pdf
analisis matematico 2 elon lages lima .pdfanalisis matematico 2 elon lages lima .pdf
analisis matematico 2 elon lages lima .pdf
 
CV_SOTO_SAUL 30-01-2024 (1) arquitecto.pdf
CV_SOTO_SAUL 30-01-2024  (1) arquitecto.pdfCV_SOTO_SAUL 30-01-2024  (1) arquitecto.pdf
CV_SOTO_SAUL 30-01-2024 (1) arquitecto.pdf
 
PPT_Conferencia OBRAS PUBLICAS x ADMNISTRACION DIRECTA.pdf
PPT_Conferencia OBRAS PUBLICAS x ADMNISTRACION DIRECTA.pdfPPT_Conferencia OBRAS PUBLICAS x ADMNISTRACION DIRECTA.pdf
PPT_Conferencia OBRAS PUBLICAS x ADMNISTRACION DIRECTA.pdf
 
CALCULISTA AGUA POTABLE ALCANTARILLADO RURAL CURACAVÍ
CALCULISTA AGUA POTABLE ALCANTARILLADO RURAL CURACAVÍCALCULISTA AGUA POTABLE ALCANTARILLADO RURAL CURACAVÍ
CALCULISTA AGUA POTABLE ALCANTARILLADO RURAL CURACAVÍ
 
Poder puedo, pero no lo haré - T3chfest
Poder puedo, pero no lo haré - T3chfestPoder puedo, pero no lo haré - T3chfest
Poder puedo, pero no lo haré - T3chfest
 
BROCHURE EDIFICIO MULTIFAMILIAR LIMA. PERU
BROCHURE EDIFICIO MULTIFAMILIAR LIMA. PERUBROCHURE EDIFICIO MULTIFAMILIAR LIMA. PERU
BROCHURE EDIFICIO MULTIFAMILIAR LIMA. PERU
 
Diseño de Algoritmos Paralelos con la maestra Rina
Diseño de Algoritmos Paralelos con la maestra RinaDiseño de Algoritmos Paralelos con la maestra Rina
Diseño de Algoritmos Paralelos con la maestra Rina
 
Cuadro de las web 1.0, 2.0 y 3.0 pptx
Cuadro de las web 1.0, 2.0 y 3.0     pptxCuadro de las web 1.0, 2.0 y 3.0     pptx
Cuadro de las web 1.0, 2.0 y 3.0 pptx
 
Presentación de Ciencia, Cultura y Progreso.pptx
Presentación de Ciencia, Cultura y Progreso.pptxPresentación de Ciencia, Cultura y Progreso.pptx
Presentación de Ciencia, Cultura y Progreso.pptx
 
IA T3 Elaboración e interpretación de planos.pptx
IA T3 Elaboración e interpretación de planos.pptxIA T3 Elaboración e interpretación de planos.pptx
IA T3 Elaboración e interpretación de planos.pptx
 
Mecánica vectorial para ingenieros estática. Beer - Johnston. 11 Ed.pdf
Mecánica vectorial para ingenieros estática. Beer - Johnston. 11 Ed.pdfMecánica vectorial para ingenieros estática. Beer - Johnston. 11 Ed.pdf
Mecánica vectorial para ingenieros estática. Beer - Johnston. 11 Ed.pdf
 
concreto pretensado y postensado- reseña historica
concreto pretensado y postensado- reseña historicaconcreto pretensado y postensado- reseña historica
concreto pretensado y postensado- reseña historica
 
Principios de Circuitos Eléctricos (Thomas L. Floyd) (Z-Library).pdf
Principios de Circuitos Eléctricos (Thomas L. Floyd) (Z-Library).pdfPrincipios de Circuitos Eléctricos (Thomas L. Floyd) (Z-Library).pdf
Principios de Circuitos Eléctricos (Thomas L. Floyd) (Z-Library).pdf
 
Método inductivo.pdf-lizzeh cuellar cardenas
Método inductivo.pdf-lizzeh cuellar cardenasMétodo inductivo.pdf-lizzeh cuellar cardenas
Método inductivo.pdf-lizzeh cuellar cardenas
 
Modulo 4 - Monitoreo Hidrobiológico de monitoreo ambiental
Modulo 4 - Monitoreo Hidrobiológico de monitoreo ambientalModulo 4 - Monitoreo Hidrobiológico de monitoreo ambiental
Modulo 4 - Monitoreo Hidrobiológico de monitoreo ambiental
 
Modulo 5 - Monitoreo de Ruido Ambiental de monitoreo ambiental
Modulo 5 - Monitoreo de Ruido Ambiental de monitoreo ambientalModulo 5 - Monitoreo de Ruido Ambiental de monitoreo ambiental
Modulo 5 - Monitoreo de Ruido Ambiental de monitoreo ambiental
 

Taller metricas

  • 1. 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. UNIVERSIDAD FRANCISCO DE PAULA SANTANDER PROGRAMA DE INGENIERIA DE SISTEMAS INGENIERIA DE SOFTWARE 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
  • 3. UNIVERSIDAD FRANCISCO DE PAULA SANTANDER PROGRAMA DE INGENIERIA DE SISTEMAS INGENIERIA DE SOFTWARE 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
  • 4. UNIVERSIDAD FRANCISCO DE PAULA SANTANDER PROGRAMA DE INGENIERIA DE SISTEMAS INGENIERIA DE SOFTWARE 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:
  • 5. UNIVERSIDAD FRANCISCO DE PAULA SANTANDER PROGRAMA DE INGENIERIA DE SISTEMAS INGENIERIA DE SOFTWARE 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á
  • 6. UNIVERSIDAD FRANCISCO DE PAULA SANTANDER PROGRAMA DE INGENIERIA DE SISTEMAS INGENIERIA DE SOFTWARE 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.
  • 7. UNIVERSIDAD FRANCISCO DE PAULA SANTANDER PROGRAMA DE INGENIERIA DE SISTEMAS INGENIERIA DE SOFTWARE 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.
  • 8. UNIVERSIDAD FRANCISCO DE PAULA SANTANDER PROGRAMA DE INGENIERIA DE SISTEMAS INGENIERIA DE SOFTWARE § 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
  • 9. UNIVERSIDAD FRANCISCO DE PAULA SANTANDER PROGRAMA DE INGENIERIA DE SISTEMAS INGENIERIA DE SOFTWARE § 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.
  • 10. UNIVERSIDAD FRANCISCO DE PAULA SANTANDER PROGRAMA DE INGENIERIA DE SISTEMAS INGENIERIA DE SOFTWARE § 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
  • 11. UNIVERSIDAD FRANCISCO DE PAULA SANTANDER PROGRAMA DE INGENIERIA DE SISTEMAS INGENIERIA DE SOFTWARE 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