miércoles, 28 de enero de 2015
lunes, 19 de enero de 2015
conceptos de metrica
2.1
Concepto de métrica.
2.1.1.
Medición
Es el proceso por el cual los
números o símbolos son asignados a atributos o entidades en el mundo real tal
como son descritos de acuerdo a reglas claramente
definidas” [Fenton ´91].
2.1.2
Medida
“proporciona una indicación
cuantitativa de extensión, cantidad, dimensiones, capacidad y tamaño de algunos
atributos de un proceso o producto” [Pressman´98].
2.1.3
Métrica
“Es una medida cuantitativa del grado en que
un sistema, componente o proceso posee un atributo dado” [Len O. Ejiogo
´91].
2.1.4 Métricas de Software
Michael [‘99] define las
métricas de software como “La aplicación continua de mediciones basadas en
técnicas para el proceso de desarrollo del software y sus productos para
suministrar información relevante a tiempo, así el administrador junto con el
empleo de estas técnicas mejorará el proceso y sus productos”. Las métricas de
software proveen la información necesaria para la toma de decisiones técnicas.
Las métricas son la
maduración de una disciplina, que, según Pressman [’98] van a ayudar a la evaluación de los modelos de análisis y de
diseño, en donde proporcionarán una
indicación de la complejidad de diseños procedimentales y de código fuente, y ayudaran
en el diseño de pruebas más efectivas. Es por eso que propone un proceso de
medición, el cual se puede caracterizar por cinco actividades:
1.
Formulación: La obtención de medidas y
métricas del software apropiadas para la representación de software en
cuestión.
2.
Colección: El mecanismo empleado para
acumular datos necesarios para obtener las métricas formuladas.
3.
Análisis: El cálculo de las métricas y
la aplicación de herramientas matemáticas.
4.
Interpretación: La evaluación de los
resultados de las métricas en un esfuerzo por conseguir una visión interna de
la calidad de la representación.
5.
Realimentación: Recomendaciones obtenidas de
la interpretación de métricas técnicas trasmitidas al equipo de software.
2.1.5
Características de las métricas
Simple y fácil de calcular: debería ser relativamente
fácil de aprender a obtener la métrica y su cálculo no obligara a un esfuerzo o
a una cantidad de tiempo inusuales.
Empírica e intuitivamente
persuasiva: la métrica debería satisfacer las
nociones intuitivas del ingeniero de software sobre el atributo del producto en
cuestión (por ejemplo: una métrica que mide la cohesión de un módulo debería
aumentar su valor a medida que crece el nivel de cohesión).
Consistente en el empleo de
unidades y tamaños: el cálculo matemático de la métrica
debería utilizar medidas que no lleven a extrañas combinaciones de unidades.
Por ejemplo, multiplicando el número de personas de un equipo por las variables
del lenguaje de programación en el programa resulta una sospechosa mezcla de
unidades que no son intuitivamente concluyentes.
Independiente del lenguaje de
programación: las métricas deberían apoyarse en el
modelo de análisis, modelo de diseño o en la propia estructura del programa. No
deberían depender de los caprichos de la sintaxis o semántica del lenguaje de
programación.
Un mecanismo eficaz para la
realimentación de calidad: la métrica debería suministrar al
desarrollador de software información que le lleve a un producto final de
superior calidad.
2.2
Tipos de métricas de calidad de software.
2.2.1
Clasificación de las Métricas
La clasificación de una
métrica de software refleja o describe la conducta del software. A continuación
se muestra una breve clasificación de métricas de software, descritas por Lem
O. Ejiogu [‘91]:
a) Según criterios
Métricas de complejidad:
Son todas las
métricas de software que definen de una u otra forma la medición de la
complejidad; Tales como volumen, tamaño, anidaciones, costo (estimación),
agregación, configuración, y flujo. Estas son los puntos críticos de la
concepción, viabilidad, análisis, y diseño de software.
Métricas de calidad: Son todas las métricas de
software que definen de una u otra forma la calidad del software; Tales como
exactitud, estructuración o modularidad, pruebas, mantenimiento, reusabilidad,
cohesión del módulo, acoplamiento del módulo, etc. Estas son los puntos
críticos en el diseño, codificación, pruebas y mantenimiento.
Métricas de competencia: Son todas las métricas que
intentan valorar o medir las actividades de productividad de los programadores
o practicantes con respecto a su certeza, rapidez, eficiencia y competencia. No
se ha alcanzado mucho en esta área, a pesar de la intensa investigación
académica.
Métricas de desempeño: Corresponden a las métricas
que miden la conducta de módulos y sistemas de un software, bajo la supervisión
del sistema operativo o hardware. Generalmente tienen que ver con la eficiencia
de ejecución, tiempo, almacenamiento, complejidad de algoritmos
computacionales, etc.
Métricas estilizadas: Son las métricas de
experimentación y de preferencia; Por ejemplo: estilo de código, identación,
las convenciones denominando de datos, las limitaciones, etc. Pero estas no se
deben confundir con las métricas de calidad o complejidad.
Variedad de métricas: tales como portabilidad, facilidad de
localización, consistencia. Existen pocas investigaciones dentro del área.
Estas
clasificaciones de métricas fortalecen la idea, de que más de una métrica puede
ser deseable para valorar la complejidad y la calidad del software.
b) Según el contexto en que
se aplican:
Métricas de proceso: Se recopilan de todos los
proyectos y durante un largo periodo de tiempo y se caracteriza por control y ejecución Del proyecto y Medición de tiempos de las
fases.
Métricas de proyecto: Permiten evaluar el estado
del proyecto y seguir la pista de los riesgos.
Métricas de producto: Se centran en las características del
software y no en cómo fue producido, también son productos los
artefactos, documentos, modelos, y componentes que conforman el
software. Se miden cosas como el tamaño, la calidad, la totalidad, la
volatilidad, y el esfuerzo.viernes, 16 de enero de 2015
miércoles, 14 de enero de 2015
Compatibilidad
La compatibilidad es importante debido a que los
sistemas software no se desarrollan en el vacío: necesitan interactuar con
otros. Pero con mucha frecuencia los sistemas tienen dificultades para
interactuar porque hacen suposiciones contradictorias sobre el resto del mundo.
Un ejemplo es la amplia variedad de formatos de archivos soportados por muchos
sistemas operativos. Un programa puede usar directamente como entrada los
resultados de otro sólo si los formatos de archivos son compatibles. La clave
de la compatibilidad recae en la homogeneidad del diseño y en acordar
convenciones estándares para la comunicación entre programas. Los enfoques
incluyen:
- Formatos
de archivos estándares, como en el sistema Unix, donde cualquier archivo
de texto es simplemente una secuencia de caracteres.
- Estructuras
de datos estándares como en los sistemas Lisp, donde tanto los datos como
los programas, se representan mediante árboles binarios.
- Interfaces
de usuario estándares, como en las diferentes versiones de Windows donde todas
las herramientas utilizan un solo paradigma para la comunicación con el
usuario, basado en componentes estándares tales como ventanas, íconos,
menús, etc.
Oportunidad:
La oportunidad es una de las mayores
frustraciones de nuestra industria. Un gran producto software que aparece
demasiado tarde puede no alcanzar su objetivo. Esto es cierto en otras
industrias también, pero pocas evolucionan tan rápidamente como el software. La
oportunidad es todavía, para grandes proyectos, un fenómeno poco común. Cuando
Microsoft anunció que la última versión de su principal sistema operativo, que
llevaba realizando varios años, saldría al mercado un mes antes de lo previsto,
el suceso fue lo suficientemente relevante como para encabezar los titulares de
Computer World.
lunes, 12 de enero de 2015
Factores y características que determinan la calidad del software. Factores comunes a la calidad del software
1.1
Factores y características que determinan la calidad del software.
Factores comunes a la calidad del software
Funcionalidad:
Se aprecia evaluando el
conjunto de características y capacidades del programa, la generalidad de las
funciones entregadas y la seguridad del sistema global.
Uno de los problemas más difíciles a los
que se enfrenta un jefe de proyecto es conocer cuanta funcionalidad es
suficiente. La presión para ofrecer más facilidades (conocida como featurism),
está constantemente presente. Sus consecuencias son malas para los proyectos
internos, donde las presiones vienen de los usuarios de la misma compañía, y
son peores para los productos comerciales, ya que la parte más destacada de los
análisis comparativos suele ser una tabla donde se enumeran una por una las
propiedades que ofrecen los distintos productos analizados.
El featurism es realmente
la combinación de dos problemas, uno más difícil que el otro. El problema más
fácil es la pérdida de consistencia como consecuencia de estar añadiendo nuevas
propiedades, lo que puede afectar a su facilidad de uso. Los usuarios se quejan
con razón de que toda la parafernalia que acompaña a una nueva versión de un
producto lo hace tremendamente complejo. Tales comentarios no deberían
preocuparnos en exceso, puesto que las nuevas propiedades no surgen de la nada:
la mayor parte de las veces han sido solicitadas por los usuarios –otros usuarios.
Lo que a unos les puede resultar algo superfluo puede ser una facilidad
indispensable para otros.
La solución aquí es trabajar una y otra
vez sobre la consistencia del producto global, tratando de que todo encaje en
un molde general. Un buen producto software está basado en un número pequeño de
potentes ideas; incluso si tiene muchas propiedades especializadas, éstas
deberían explicarse como consecuencia de los conceptos básicos. El “gran plan”
debe estar visible y todo debería ocupar su sitio dentro de él.
Corrección:
La corrección es la
cualidad principal. Si un sistema no hace lo que se supone que debe hacer, poco
importan el resto de consideraciones que hagamos sobre él – si es rápido, si
tiene una bonita interfaz de usuario…
Pero esto es más fácil de decir que de
lograr. Incluso el primer paso hacia la corrección es ya difícil: debemos ser
capaces de especificar los requisitos del sistema de una forma precisa, lo que
es en sí una ardua tarea.
Los métodos que aseguran la corrección son
usualmente condicionales. Un sistema de software importante,
incluso uno pequeño según los estándares de hoy, implica a tantas áreas que
sería imposible garantizar su corrección manejando todas las componentes y
propiedades en un solo nivel. En cambio, es necesaria una solución multinivel,
en la que cada nivel confía en la corrección de los inferiores:
Hardware ----> Sistema Operativo---->
Compilador ----> Sistema de Aplicación
En la solución condicional de la
corrección, sólo hay que preocuparse en garantizar que cada nivel sea
correcto bajo el supuesto de que los niveles inferiores son
correctos.
Confiabilidad:
El
conjunto de atributos que soporta la capacidad del software para mantener su
nivel de rendimiento bajo condiciones establecidas por un periodo de tiempo
establecido.
Eficiencia:
El conjunto de recursos informáticos
y de código necesarios para que un programa realice su función.
Casi sinónimo de eficiencia es la palabra
“rendimiento”. La comunidad del software muestra dos tipos de actitud con
relación a la eficiencia:
- Algunos
desarrolladores tienen una obsesión con las cuestiones de rendimiento y le
dedican gran cantidad de esfuerzos a presuntas optimizaciones.
- Por
otro lado, existe la tendencia de soslayar las cuestiones de eficiencia,
como se evidencia en las frases de la industria “hágalo correcto antes de
hacerlo rápido” y “de todos modos los modelos de computadoras del año que
viene van a ser un 50% más rápidos”.
De manera más general, la preocupación por
la eficiencia debe sopesarse con otros objetivos tales como la extensibilidad y
la reutilización; optimizaciones extremas pueden hacer al software tan especializado
que limite el cambio y la reutilización. Es más, la potencia creciente del
hardware de las computadoras nos permite tener una actitud más relajada con
respecto a tratar de ganar hasta el último byte o microsegundo.
miércoles, 7 de enero de 2015
Concepto de Calidad
De acuerdo a la investigación, con tus propias palabras define el concepto de Calidad.
.jpg)
Deja tu Definición en un comentario.
Suscribirse a:
Entradas (Atom)